dist-upgrade fails when debconf-gnome is invoked during the upgrade

[Michael Vogt]

If debconf wants to do something durig a upgrade (e.g. show a note) and the frontend is debconf-gnome bad things happen when the gnome stack is in a in-between state.

Attached is a log where debconf is not able to load it's gnome frontend and segfaults (because pango is not working yet). This causes postgresql-common to fail in its preinst script and kills the upgrade.

[Michael Vogt (mvo)]

Log of a failure when debconf is invoked

[Michael Vogt (mvo)]

A rather gross hack to solve (part of) the problem would be add add a "pre-depends: libpango1.0-0 (>= 1.12.0).

This will move libpango into a early install/configure run during the dist-upgrade and makes it much less likely that the problem happens.

The "correct" solution should be that libgnome2-perl dosn't segfault but fall back to dialog if invoking the frontend fails.

I'll attach a apt-get dist-upgrade -s log with the pre-depends added.

[Michael Vogt (mvo)]

Dist-Upgrade with added pre-dep to libgnome2-perl on libpango1.0-0 (>= 1.12.0).

[Michael Vogt (mvo)]

Another possible solution would be to use the much more robust dialog frontend but expand the terminal as soon as a debconf interaction is required. This would mean to hook into debconf.

[Michael Vogt (mvo)]

Subscribed Kamion, I would value his opinion on the matter and if it is feasible to add something to use the dialog frontend internally.

[Michael Vogt (mvo)]

Using dialog internally would also fix the problem that the debconf-gnome window can open in the background (because 1) we have no way to make it transient for the upgrader 2) the upgrader uses always_on_top currently)

[Colin Watson (cjwatson)]

I think this is probably mostly the fault of the GNOME stack (libraries or bindings, I'm not sure which). The debconf Gnome frontend already goes to some lengths to try to avoid being killed if bits of GNOME fall over, since those libraries have the appalling habit of dying hard instead of returning an error; but it's possible it doesn't go far enough.

Still, if you don't really want the Gnome frontend anyway, you can always set DEBIAN_FRONTEND=dialog in the environment.

[Michael Vogt (mvo)]

Well, if possible I would love to use the gnome frontend. But when it segfaults the preinst of the package fails and that stops the upgrade.

The problem with dialog is that it will run in the build-in terminal that is hidden by default. I would need a way to know when debcofn was activated to expand it and display it to the user. My prefered method would be gnome.

[Michael Vogt (mvo)]

I tried snooping the terminal to look for a ansi clear screen patter that would indicate something interessting happening on the terminal. Unfortunately the vte widget gives me no acces to "raw" codes but only to user visible stuff. So if I use dialog, I can't detect the frontend by looking at the ansi codes send to the terminal.

[Michael Vogt (mvo)]

The root of the pango problem is that "/usr/sbin/update-pango-modules" was not run yet (it is run from the libpango-common postinst). This leads to a incorrect /etc/pango/pango.modules files (refering to pathes from version 1.4 of the modules when 1.4 is already removed and 1.5 is installed).

[Michael Vogt (mvo)]

After a bit of pondering I'm convinced that generating the pango.modules file in the postinst is wrong. It needs to be shipped pre-generated. I also think that shipping it in /etc/ is not required as it is automatically generated anyway. We need some sort of dynamic solution for packages like pango-libthai that ship custom pango modules.

My prefered solution would be to have a /var/lib/pango/pango.modules.d directory where the packages can put there pango.modules file that includes the modules they ship. But this requires extending pangos config code to add a feature to read directories with config-files.

A less intrusive solution would be to move the file out of /etc/pango to /var/lib/pango/, ship a default file with libpango1.0-common and patch pango to look in /var/lib/pango/pango.modules by default. update-pango-modules needs patching as well to write the file there. The upgrade should probably remove the /etc/pango/pango.modules file (if the md5sum indicates that it wasnt touched). We need to check if pango-libthai uses update-pango-modules (or something home-grown) and fix it if needed.

[Michael Vogt (mvo)]

Implements solution b):
 move /etc/pango/pango.modules to /var/lib/pango/pango.modules and ship a default version in the package. This fixes a bad race during the upgrade of pango (ubuntu: #41297). update-pango-modules uses the new path too.

[Michael Vogt (mvo)]

Updated the debdiff, exclude var/lib/pango/pango.conf from the md5sum generation, fix a problem with query-module from the old patch.

[Michael Vogt (mvo)]

This should be fixed with the upload of pango1.0_1.12.2-0ubuntu2_source.changes.