Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Andreas Beckmann]

[ added Guillem to the recipients, he is the expert for trigger cycles ]
[ added Doko to the recipients, since #863820 is a possible solution ]
[ therefore resending a full-quote ]

On 2017-06-11 12:00, Niels Thykier wrote:
> Cyril Brulebois:
>> Package: upgrade-reports
>> Severity: critical
>> Justification: makes upgrade from stable abort
>>
>> [ X-D-Cc:
>>   debian-release at lists.debian.org
>>   pkg-java-maintainers at lists.alioth.debian.org
>>   pkg-gnome-maintainers at lists.alioth.debian.org ]
>>
>> Hi,
>>
>> Regression spotted by Pere in some debian-edu job, but also seen since
>> the 2nd of June in normal gnome chroot installation then upgrade from
>> jessie to stretch:
>>   https://jenkins.debian.net/view/edu_devel/job/chroot-installation_jessie_install_education-desktop-gnome_upgrade_to_stretch/
>>   https://jenkins.debian.net/job/chroot-installation_jessie_install_gnome_upgrade_to_stretch/
>>
> 
> Hi,
> 
> Thanks for reporting this.
> 
> Timing being what it is, we need to act fast if we want to fix this for
> stretch.  I have CC'ed maintainers of (presumably) relevant packages;
> please be ready to upload a fix to your package if needed.
> 
> Long story short:
> =================
> 
>  * dpkg reports a trigger cycle between gnome-menus and
>    desktop-file-utils.
> 
>  * desktop-file-utils has an "interest" (implicit "-await") trigger, so
>    it is plausible.  I have not verified the dependency relationship.
> 
>  * shared-mime-info also has an "interest" (implicit "-await") trigger.
>    It may (or may not) be an accomplice to this issue.
> 
>  * gnome-menus only have "interest-noawait" and should therefore not be
>    able to start the trigger cycle (but it can be part of one).
> 
> Things to do / research:
> =======================
> 
>  * @desktop-file-utils: The trigger seems to be used for a cache.  Is
>    there any reason for using the implicit "-await" trigger or can this
>    cache update be deferred like the "man-db" cache can?
> 
>  * @shared-mime-info: The trigger seems to be used for a cache.  Is
>    there any reason for using the implicit "-await" trigger or can this
>    cache update be deferred like the "man-db" cache can?
> 
>  * @Andreas: Could you have a look at the upgrade ordering in this case.
>    You are usually pretty good at spotting if we need Breaks, so I would
>    be delighted if you could give it a go.
>    (E.g. if gnome-menus need to break desktop-file-utils in jessie even
>     if desktop-file-utils in stretch uses a "-noawait" trigger)

I could reproduce the failure in piuparts (after adding support for
two-stage (apt-get upgrade && apt-get dist-upgrade) upgrades.

I sent a full upgrade log to the bug (#864597) with trigger debugging
enabled (debug=70000), hopefully Guillem can get a clue from it.
If you need more debug output, just tell me.
I could also test with a proposed dpkg/stretch patch.

Breaks probably won't help much since gnome-menus, desktop-file-utils
and shared-mime-info are already upgraded during the apt-get upgrade phase.

Switching desktop-file-utils or/and shared-mime-info to -noawait
triggers does not solve the problem.

I can confirm that the ca-certificates-java change triggered the bug
(i.e. backing it out makes the problem go away, but this is not a solution).

I can also confirm that the changes I suggested in #863820 (adding
adding Breaks: tzdata-java to gcc-6-base) would fix this upgrade path.
It shakes the upgrade order quite well for this case ...
(I can post the log if someone is interested.)
According to piuparts, the upgrade paths of about 860 packages in
jessie2stretch-rcmd would be affected by this change (because
tzdata-java gets installed in jessie). These can be retested quickly.

I'm planning to do piuparts tests doing the two-stage jessie->stretch
upgrade on piuparts.d.o, too. (So far we only do one-stage
apt-get dist-upgrade)


Andreas

> I have left the remaining parts of KiBi's mails below for the newly
> CC'ed people.
> 
> Thanks,
> ~Niels
> 
> 
>> I've managed to reproduce it locally with basically a debootstrap of
>> jessie, installation of gnome, then switch sources.list from jessie to
>> stretch, then update & upgrade & dist-upgrade.
>>
>> I've bisected the archive using snapshot.debian.org and found out:
>>  - 20170601T212625Z = last timestamp found to be OK;
>>  - 20170602T033358Z = first timestamp to be KO.
>>
>> Since logs are a bit too heavy for a bug report, I've uploaded them
>> there:
>>   https://people.debian.org/~kibi/jessie2stretch/gnome/
>>
>> $timestamp.log is the output of the installation & dist-upgrade process,
>> while $timestamp.log.clean is a cleaned version (with Get: lines edited
>> to remove the package indice and the timestamp, then sort them by block,
>> so as to avoid a huge diff).
>>
>> Then I've generated upgrade.diff by diffing both clean versions:
>>   https://people.debian.org/~kibi/jessie2stretch/gnome/upgrade.diff
>>
>> This file consists mainly of some differences which should help us
>> pinpoint the exact issue (first part of the diff), but also of a big
>> diff at the end, since the OK log goes on with the install while the KO
>> one is cut rather quickly. Actual error follows:
>> | Unpacking default-jre-headless (2:1.8-58) over (2:1.7-52) ...
>> | Processing triggers for libc-bin (2.24-10) ...
>> | Processing triggers for hicolor-icon-theme (0.15-1) ...
>> | Processing triggers for desktop-file-utils (0.23-1) ...
>> | Processing triggers for man-db (2.7.6.1-2) ...
>> | Processing triggers for libglib2.0-0:amd64 (2.50.3-2) ...
>> | (Reading database ... 129883 files and directories currently installed.)
>> | Removing openjdk-7-jre:amd64 (7u111-2.6.7-1~deb8u1) ...
>> | Removing openjdk-7-jre-headless:amd64 (7u111-2.6.7-1~deb8u1) ...
>> | Removing tzdata-java (2017b-0+deb8u1) ...
>> | Processing triggers for hicolor-icon-theme (0.15-1) ...
>> | dpkg: cycle found while processing triggers:
>> |  chain of packages whose triggers are or may be responsible:
>> |   gnome-menus -> desktop-file-utils
>> |  packages' pending triggers which are or may be unresolvable:
>> |   gnome-menus: /usr/share/applications
>> |   shared-mime-info: /usr/share/mime/packages
>> |   desktop-file-utils: /usr/share/applications
>> | dpkg: error processing package gnome-menus (--remove):
>> |  triggers looping, abandoned
>> | Processing triggers for desktop-file-utils (0.23-1) ...
>> | Errors were encountered while processing:
>> |  gnome-menus
>> | E: Sub-process /usr/bin/dpkg returned an error code (1)
>>
>> By looking at the diff before that, this might have been triggered (no
>> pun intended) by the ca-certificates-java update, which included changes
>> in the required java version, which might explain why this block was
>> present in the OK log but no longer in the KO one?
>> | -dpkg: openjdk-7-jre-headless:amd64: dependency problems, but removing anyway as you requested:
>> | - ca-certificates-java depends on openjdk-7-jre-headless | java7-runtime-headless; however:
>> | -  Package openjdk-7-jre-headless:amd64 is to be removed.
>> | -  Package java7-runtime-headless is not installed.
>> | -  Package openjdk-8-jre-headless:amd64 which provides java7-runtime-headless is not configured yet.
>> | -  Package default-jre-headless which provides java7-runtime-headless is not configured yet.
>> | -  Package openjdk-7-jre-headless:amd64 which provides java7-runtime-headless is to be removed.
>> | - ca-certificates-java depends on openjdk-7-jre-headless | java7-runtime-headless; however:
>> | -  Package openjdk-7-jre-headless:amd64 is to be removed.
>> | -  Package java7-runtime-headless is not installed.
>> | -  Package openjdk-8-jre-headless:amd64 which provides java7-runtime-headless is not configured yet.
>> | -  Package default-jre-headless which provides java7-runtime-headless is not configured yet.
>> | -  Package openjdk-7-jre-headless:amd64 which provides java7-runtime-headless is to be removed.
>> | -
>>
>> I don't see any immediate solutions (mostly because it's the first dpkg
>> triggers cycle I encounter), but this looks like something that really
>> should be fixed before the stretch release, hence the severity and the
>> x-d-cc list.
>>
>>
>> KiBi.
>>
>