oem-config hangs when removing ubquity

Also incuding a tarball of /var/log at the point of falure. Not sure if anything useful is in here, but might help.

Might be a super easy fix. In Raring, it seems `ubiquity-frontend-gtk` is one of the package present after an OEM mode install. But `ubiquity-frontend-gtk` is not one of the packages in the remove list in bin/oem-config-remove-gtk:

def main():
    purge = []
    for pkg in ('ubiquity', 'ubiquity-casper',
                'ubiquity-ubuntu-artwork', 'ubiquity-slideshow-ubuntu',
                'oem-config-slideshow-ubuntu'):
        if glob.glob('/var/lib/dpkg/info/%s.list' % pkg):
            purge.append(pkg)

    if not using_cryptsetup():
        purge.append("cryptsetup")

    ac = client.AptClient()
    ac.commit_packages(
        install=[], reinstall=[], remove=[], purge=purge, upgrade=[],
        downgrade=[], error_handler=_on_failure, reply_handler=_on_transaction)
    loop.run()

This bug was fixed in the package ubiquity - 2.14.1

---------------
ubiquity (2.14.1) raring; urgency=low

  * Pass --identifier-prefix=Ubiquity via
    UbiquityMockResolver_1_0_gir_SCANNERFLAGS rather than
    UbiquityMockResolver_1_0_gir_CFLAGS, fixing build failure with
    gobject-introspection >= 1.35.9.
 -- Colin Watson <email address hidden> Sat, 30 Mar 2013 23:15:26 +0000

Okay, I just tried 2.14.1, but unfortuanately it didn't fix the problem.

`ubiquity-frontend-gtk` now gets removed without any complaints, but things still hang at "Purging configuration files for Ubiquity..." (see new screenshot).

So I think the problem wasn't realted to `ubiquity-frontend-gtk` not being in the remove list. I'll dig into this more on Tuesday.

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1161943

Reopening since the fix doesn't seem to have worked

The issue of ubiquity hanging does not occur with the latest desktop images (20130402.1 amd64 and i386).

Yeah, it doesn't occur for us either as of updates yesterday. We have a snapshot on which it does occur, so we're going through the package updates so we can track down what fixed it.

It's possible that aptdaemon 1.0-0ubuntu9 fixed this.

Yes, I can confirrm that aptdaemon 1.0-0ubuntu9 fixes this.

On a sytem with aptdaemon 1.0-0ubuntu8 (and everything else updated), the problem is present. Upgrade to latest apdaemon, works fine.