Cyril Brulebois:
> Package: upgrade-reports
> Severity: critical
> Justification: makes upgrade from stable abort
>
> [ X-D-Cc:
> debian-rele...@lists.debian.org
> pkg-java-maintain...@lists.alioth.debian.org
> pkg-gnome-maintain...@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 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.
>
