Report forwarded
to debian-bugs-dist@lists.debian.org, Kilian Krause <kilian@debian.org>: Bug#766758; Package ekiga.
(Sat, 25 Oct 2014 14:57:06 GMT) (full text, mbox, link).
Acknowledgement sent
to Vincent Lefevre <vincent@vinc17.net>:
New Bug report received and forwarded. Copy sent to Kilian Krause <kilian@debian.org>.
(Sat, 25 Oct 2014 14:57:06 GMT) (full text, mbox, link).
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: ekiga is half-installed
Date: Sat, 25 Oct 2014 16:55:44 +0200
Package: ekiga
Version: 4.0.1-5
Severity: critical
Justification: breaks unrelated software
ekiga has been half-installed. I didn't got any error, though.
From /var/log/dpkg.log (lines matching ekiga):
2014-10-25 10:54:27 upgrade ekiga:amd64 4.0.1-4+b2 4.0.1-5
2014-10-25 10:54:27 status half-configured ekiga:amd64 4.0.1-4+b2
2014-10-25 10:54:27 status unpacked ekiga:amd64 4.0.1-4+b2
2014-10-25 10:54:27 status half-installed ekiga:amd64 4.0.1-4+b2
2014-10-25 10:54:27 status half-installed ekiga:amd64 4.0.1-4+b2
2014-10-25 10:54:29 status triggers-pending gconf2:amd64 3.2.6-3
2014-10-25 10:54:29 status half-installed ekiga:amd64 4.0.1-4+b2
2014-10-25 10:54:29 status half-installed ekiga:amd64 4.0.1-4+b2
2014-10-25 10:54:31 status half-installed ekiga:amd64 4.0.1-4+b2
2014-10-25 10:54:37 status half-installed ekiga:amd64 4.0.1-4+b2
2014-10-25 10:54:37 status unpacked ekiga:amd64 4.0.1-5
2014-10-25 10:54:37 status unpacked ekiga:amd64 4.0.1-5
[...]
2014-10-25 10:56:55 configure ekiga:amd64 4.0.1-5 <none>
2014-10-25 10:56:55 status unpacked ekiga:amd64 4.0.1-5
2014-10-25 10:56:55 status half-configured ekiga:amd64 4.0.1-5
2014-10-25 10:56:55 status triggers-awaited ekiga:amd64 4.0.1-5
and from the /var/log/aptitude log file:
Aptitude 0.6.11: log report
Sat, Oct 25 2014 13:33:45 +0200
IMPORTANT: this log only lists intended actions; actions which fail due to
dpkg problems may not be completed.
Will install 0 packages, and remove 0 packages.
===============================================================================
[HOLD, DEPENDENCIES] gir1.2-gudev-1.0:amd64
[HOLD, DEPENDENCIES] gnome-control-center-data:amd64
[HOLD, DEPENDENCIES] gnome-themes-standard-data:amd64
[HOLD, DEPENDENCIES] libevdocument3-4:amd64
[HOLD, DEPENDENCIES] libevview3-3:amd64
[HOLD, DEPENDENCIES] libgtk-3-common:amd64
[HOLD, DEPENDENCIES] libgtksourceview-3.0-1:amd64
[HOLD, DEPENDENCIES] libpam-systemd:amd64
[HOLD, DEPENDENCIES] libsystemd-daemon0:amd64
[HOLD, DEPENDENCIES] libsystemd-journal0:amd64
[HOLD, DEPENDENCIES] libsystemd-login0:amd64
[HOLD, DEPENDENCIES] libudev1:amd64
[HOLD, DEPENDENCIES] systemd:amd64
[HOLD, DEPENDENCIES] totem-common:amd64
[HOLD] cheese:amd64
[HOLD] cheese-common:amd64
[HOLD] eog:amd64
[HOLD] epiphany-browser:amd64
[HOLD] epiphany-browser-data:amd64
[HOLD] evince:amd64
[HOLD] evince-common:amd64
[HOLD] file-roller:amd64
[HOLD] four-in-a-row:amd64
[HOLD] fvwm:amd64
[HOLD] gedit:amd64
[HOLD] gedit-common:amd64
[HOLD] gir1.2-evince-3.0:amd64
[HOLD] gir1.2-gtk-3.0:amd64
[HOLD] gir1.2-gtksource-3.0:amd64
[HOLD] gir1.2-totem-1.0:amd64
[HOLD] gnome-chess:amd64
[HOLD] gnome-control-center:amd64
[HOLD] gnome-mahjongg:amd64
[HOLD] gnome-sudoku:amd64
[HOLD] gnome-system-monitor:amd64
[HOLD] gnome-themes-standard:amd64
[HOLD] gnuplot:amd64
[HOLD] gnuplot-doc:amd64
[HOLD] gnuplot-qt:amd64
[HOLD] grep:amd64
[HOLD] gthumb:amd64
[HOLD] gthumb-data:amd64
[HOLD] initramfs-tools:amd64
[HOLD] libcheese-gtk23:amd64
[HOLD] libcheese7:amd64
[HOLD] libgail-3-0:amd64
[HOLD] libgtk-3-0:amd64
[HOLD] libgtk-3-0-dbg:amd64
[HOLD] libgtk-3-bin:amd64
[HOLD] libgtk-3-dev:amd64
[HOLD] libgtkmm-3.0-1:amd64
[HOLD] libgudev-1.0-0:amd64
[HOLD] libnautilus-extension1a:amd64
[HOLD] libtotem0:amd64
[HOLD] libxml2:amd64
[HOLD] libxml2-dbg:amd64
[HOLD] libxml2-dev:amd64
[HOLD] libxml2-utils:amd64
[HOLD] libyelp0:amd64
[HOLD] nautilus:amd64
[HOLD] nautilus-data:amd64
[HOLD] pavucontrol:amd64
[HOLD] pavucontrol-dbg:amd64
[HOLD] systemd-shim:amd64
[HOLD] totem:amd64
[HOLD] totem-plugins:amd64
[HOLD] udev:amd64
[HOLD] xmlcopyeditor:amd64
[HOLD] xmlcopyeditor-dbg:amd64
[HOLD] yelp:amd64
[UNCONFIGURED] ekiga:amd64
[UNCONFIGURED] gconf2:amd64
===============================================================================
Log complete.
Because of that, the status file is in an improper state, and
this breaks deborphan at least:
# deborphan
deborphan: The status file is in an improper state.
One or more packages are marked as half-installed, half-configured,
unpacked, triggers-awaited or triggers-pending. Exiting.
"apt-get install -f" just says:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
[...]
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 70 not upgraded.
and does nothing.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages ekiga depends on:
ii gconf-service 3.2.6-3
it gconf2 3.2.6-3
ii gnome-icon-theme 3.12.0-1
ii libatk1.0-0 2.14.0-1
ii libavahi-client3 0.6.31-4
ii libavahi-common3 0.6.31-4
ii libavahi-glib1 0.6.31-4
ii libboost-signals1.55.0 1.55.0+dfsg-3
ii libc6 2.19-12
ii libcairo2 1.14.0-2
ii libdbus-1-3 1.8.8-2
ii libdbus-glib-1-2 0.102-1
ii libfontconfig1 2.11.0-6.1
ii libfreetype6 2.5.2-2
ii libgcc1 1:4.9.1-19
ii libgconf-2-4 3.2.6-3
ii libgdk-pixbuf2.0-0 2.31.1-2+b1
ii libglib2.0-0 2.42.0-2
ii libgtk2.0-0 2.24.25-1
ii libidn11 1.29-1
ii libldap-2.4-2 2.4.40-2
ii libloudmouth1-0 1.4.3-12
ii libnotify4 0.7.6-2
ii libopal3.10.10 3.10.10~dfsg-2.2+b2
ii libpango-1.0-0 1.36.8-2
ii libpangocairo-1.0-0 1.36.8-2
ii libpangoft2-1.0-0 1.36.8-2
ii libpt2.10.10 2.10.10~dfsg-4.1
ii libsasl2-2 2.1.26.dfsg1-12
ii libspeexdsp1 1.2~rc1.2-1
ii libstdc++6 4.9.1-19
ii libx11-6 2:1.6.2-3
ii libxext6 2:1.3.3-1
ii libxml2 2.9.1+dfsg1-3
ii libxv1 2:1.0.10-1
Versions of packages ekiga recommends:
ii gvfs 1.22.1-1
ii yelp 3.12.0-1
Versions of packages ekiga suggests:
pn asterisk <none>
pn ekiga-plugin-evolution <none>
pn gnugk <none>
pn mediaproxy <none>
pn rtpproxy <none>
pn ser <none>
pn siproxd <none>
pn yate <none>
-- no debconf information
Information forwarded
to debian-bugs-dist@lists.debian.org, Kilian Krause <kilian@debian.org>: Bug#766758; Package ekiga.
(Sat, 25 Oct 2014 15:15:17 GMT) (full text, mbox, link).
Acknowledgement sent
to Vincent Lefevre <vincent@vinc17.net>:
Extra info received and forwarded to list. Copy sent to Kilian Krause <kilian@debian.org>.
(Sat, 25 Oct 2014 15:15:17 GMT) (full text, mbox, link).
Control: retitle -1 ekiga is partially installed (triggers-awaited)
I could solve the problem with "apt-get install --reinstall" on gconf2
and ekiga, but it shouldn't have occurred in the first place. An
upgrade should complete with no partially installed packages.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Changed Bug title to 'ekiga is partially installed (triggers-awaited)' from 'ekiga is half-installed'
Request was from Vincent Lefevre <vincent@vinc17.net>
to 766758-submit@bugs.debian.org.
(Sat, 25 Oct 2014 15:15:17 GMT) (full text, mbox, link).
Reply sent
to Eugen Dedu <eugen.dedu@univ-fcomte.fr>:
You have taken responsibility.
(Sat, 25 Oct 2014 16:12:08 GMT) (full text, mbox, link).
Notification sent
to Vincent Lefevre <vincent@vinc17.net>:
Bug acknowledged by developer.
(Sat, 25 Oct 2014 16:12:09 GMT) (full text, mbox, link).
To: Vincent Lefevre <vincent@vinc17.net>, 766758-done@bugs.debian.org
Subject: Re: Bug#766758: ekiga is half-installed
Date: Sat, 25 Oct 2014 18:01:10 +0200
On 25/10/14 17:11, Vincent Lefevre wrote:
> Control: retitle -1 ekiga is partially installed (triggers-awaited)
>
> I could solve the problem with "apt-get install --reinstall" on gconf2
> and ekiga, but it shouldn't have occurred in the first place. An
> upgrade should complete with no partially installed packages.
I have had this error since a few days with other packages. It appeared
to me twice or three times.
This is not related to ekiga, for the best of my knowledge. The only
difference between -5 (your version) and -4 (packaged long time ago) is
a small patch for mips.
So I would close this bug. If you have additional information, feel
free to inform me or reopen the bug.
--
Eugen
Information forwarded
to debian-bugs-dist@lists.debian.org, Kilian Krause <kilian@debian.org>: Bug#766758; Package ekiga.
(Sun, 26 Oct 2014 23:57:14 GMT) (full text, mbox, link).
Acknowledgement sent
to Vincent Lefevre <vincent@vinc17.net>:
Extra info received and forwarded to list. Copy sent to Kilian Krause <kilian@debian.org>.
(Sun, 26 Oct 2014 23:57:14 GMT) (full text, mbox, link).
Control: reopen -1
Control: reassign -1 dpkg 1.17.21
Control: retitle -1 partially installed packages (triggers pending) after upgrade
On 2014-10-25 18:01:10 +0200, Eugen Dedu wrote:
> I have had this error since a few days with other packages. It appeared to
> me twice or three times.
This happens again, this time with man-db triggers (see below).
> This is not related to ekiga, for the best of my knowledge. The only
> difference between -5 (your version) and -4 (packaged long time ago) is a
> small patch for mips.
>
> So I would close this bug. If you have additional information, feel free to
> inform me or reopen the bug.
So, I've reopened the bug, and reassigned it to dpkg (aptitude
hasn't changed since June, so that it doesn't seem to be the
cause).
Here's the output of the upgrade with aptitude:
Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 506699 files and directories currently installed.)
Preparing to unpack .../sysvinit_2.88dsf-57_amd64.deb ...
Unpacking sysvinit (2.88dsf-57) over (2.88dsf-53.4) ...
Setting up sysvinit (2.88dsf-57) ...
(Reading database ... 506699 files and directories currently installed.)
Preparing to unpack .../bootlogd_2.88dsf-57_amd64.deb ...
Unpacking bootlogd (2.88dsf-57) over (2.88dsf-53.4) ...
Preparing to unpack .../sysvinit-utils_2.88dsf-57_amd64.deb ...
Unpacking sysvinit-utils (2.88dsf-57) over (2.88dsf-53.4) ...
Processing triggers for man-db (2.7.0.2-2) ...
Setting up sysvinit-utils (2.88dsf-57) ...
(Reading database ... 506699 files and directories currently installed.)
Preparing to unpack .../libpipeline1_1.4.0-1_amd64.deb ...
Unpacking libpipeline1:amd64 (1.4.0-1) over (1.3.1-1) ...
Preparing to unpack .../sysv-rc_2.88dsf-57_all.deb ...
Unpacking sysv-rc (2.88dsf-57) over (2.88dsf-53.4) ...
Setting up sysv-rc (2.88dsf-57) ...
(Reading database ... 506699 files and directories currently installed.)
Preparing to unpack .../initscripts_2.88dsf-57_amd64.deb ...
Unpacking initscripts (2.88dsf-57) over (2.88dsf-53.4) ...
Setting up initscripts (2.88dsf-57) ...
Installing new version of config file /etc/init.d/bootmisc.sh ...
Installing new version of config file /etc/init.d/checkfs.sh ...
Installing new version of config file /etc/init.d/checkroot.sh ...
Installing new version of config file /etc/init.d/checkroot-bootclean.sh ...
Installing new version of config file /etc/init.d/halt ...
Installing new version of config file /etc/init.d/killprocs ...
Installing new version of config file /etc/init.d/mountall.sh ...
Installing new version of config file /etc/init.d/mountall-bootclean.sh ...
Installing new version of config file /etc/init.d/mountnfs.sh ...
Installing new version of config file /etc/init.d/mountnfs-bootclean.sh ...
Installing new version of config file /etc/init.d/mountdevsubfs.sh ...
Installing new version of config file /etc/init.d/mountkernfs.sh ...
Installing new version of config file /etc/init.d/rc.local ...
Installing new version of config file /etc/init.d/reboot ...
Installing new version of config file /etc/init.d/sendsigs ...
Installing new version of config file /etc/init.d/single ...
Installing new version of config file /etc/init.d/umountfs ...
Installing new version of config file /etc/init.d/umountnfs.sh ...
Installing new version of config file /etc/init.d/umountroot ...
(Reading database ... 506699 files and directories currently installed.)
Preparing to unpack .../console-setup-linux_1.114_all.deb ...
Unpacking console-setup-linux (1.114) over (1.113) ...
Preparing to unpack .../console-setup_1.114_all.deb ...
Unpacking console-setup (1.114) over (1.113) ...
Preparing to unpack .../keyboard-configuration_1.114_all.deb ...
Unpacking keyboard-configuration (1.114) over (1.113) ...
Preparing to unpack .../libsvn-dev_1.8.10-3_amd64.deb ...
Unpacking libsvn-dev (1.8.10-3) over (1.8.10-2) ...
Preparing to unpack .../subversion-dbg_1.8.10-3_amd64.deb ...
Unpacking subversion-dbg (1.8.10-3) over (1.8.10-2) ...
Preparing to unpack .../libapache2-mod-svn_1.8.10-3_amd64.deb ...
Unpacking libapache2-mod-svn (1.8.10-3) over (1.8.10-2) ...
Preparing to unpack .../subversion_1.8.10-3_amd64.deb ...
Unpacking subversion (1.8.10-3) over (1.8.10-2) ...
Preparing to unpack .../subversion-tools_1.8.10-3_amd64.deb ...
Unpacking subversion-tools (1.8.10-3) over (1.8.10-2) ...
Preparing to unpack .../libsvn1_1.8.10-3_amd64.deb ...
Unpacking libsvn1:amd64 (1.8.10-3) over (1.8.10-2) ...
Preparing to unpack .../python-subversion_1.8.10-3_amd64.deb ...
Unpacking python-subversion (1.8.10-3) over (1.8.10-2) ...
Preparing to unpack .../libsvn-perl_1.8.10-3_amd64.deb ...
Unpacking libsvn-perl (1.8.10-3) over (1.8.10-2) ...
Preparing to unpack .../sysvinit-core_2.88dsf-57_amd64.deb ...
Unpacking sysvinit-core (2.88dsf-57) over (2.88dsf-53.4) ...
Setting up sysvinit-core (2.88dsf-57) ...
sysvinit: restarting... done.
(Reading database ... 506705 files and directories currently installed.)
Preparing to unpack .../alacarte_3.11.91-2_all.deb ...
Unpacking alacarte (3.11.91-2) over (3.11.91-1) ...
Preparing to unpack .../archives/bdf2psf_1.114_all.deb ...
Unpacking bdf2psf (1.114) over (1.113) ...
Preparing to unpack .../gkrellm_2.3.6~rc1-1_amd64.deb ...
Unpacking gkrellm (2.3.6~rc1-1) over (2.3.5-6+b1) ...
Preparing to unpack .../gnome-calculator_3.14.1-1_amd64.deb ...
Unpacking gnome-calculator (3.14.1-1) over (3.14.0-1) ...
Preparing to unpack .../gnustep-common_2.6.6-3_amd64.deb ...
Unpacking gnustep-common (2.6.6-3) over (2.6.6-2) ...
Preparing to unpack .../gnustep-base-common_1.24.7-1_all.deb ...
Unpacking gnustep-base-common (1.24.7-1) over (1.24.6-2) ...
Preparing to unpack .../libgnustep-base1.24_1.24.7-1_amd64.deb ...
Unpacking libgnustep-base1.24 (1.24.7-1) over (1.24.6-2) ...
Preparing to unpack .../gnustep-base-runtime_1.24.7-1_amd64.deb ...
[info] GNUstep distributed object mapper disabled.
Unpacking gnustep-base-runtime (1.24.7-1) over (1.24.6-2) ...
Preparing to unpack .../how-can-i-help_9_all.deb ...
Unpacking how-can-i-help (9) over (8) ...
Preparing to unpack .../libdigest-sha-perl_5.93-1_amd64.deb ...
Unpacking libdigest-sha-perl (5.93-1) over (5.92-1+b1) ...
Preparing to unpack .../libtext-levenshtein-perl_0.11-1_all.deb ...
Unpacking libtext-levenshtein-perl (0.11-1) over (0.10-1) ...
Preparing to unpack .../libxml-twig-perl_1%3a3.48-1_all.deb ...
Unpacking libxml-twig-perl (1:3.48-1) over (1:3.44-1) ...
Preparing to unpack .../python-libxml2_2.9.2+dfsg1-1_amd64.deb ...
Unpacking python-libxml2 (2.9.2+dfsg1-1) over (2.9.1+dfsg1-3) ...
Preparing to unpack .../xserver-xorg-input-mouse_1%3a1.9.1-1_amd64.deb ...
Unpacking xserver-xorg-input-mouse (1:1.9.1-1) over (1:1.9.0-1+b3) ...
Processing triggers for hicolor-icon-theme (0.13-1) ...
Processing triggers for mime-support (3.57) ...
Processing triggers for gnome-menus (3.13.3-2) ...
Processing triggers for desktop-file-utils (0.22-1) ...
Processing triggers for menu (2.1.47) ...
Processing triggers for libglib2.0-0:amd64 (2.42.0-2) ...
Setting up bootlogd (2.88dsf-57) ...
Setting up libpipeline1:amd64 (1.4.0-1) ...
Setting up keyboard-configuration (1.114) ...
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Setting up console-setup-linux (1.114) ...
Installing new version of config file /etc/console-setup/compose.ISO-8859-1.inc ...
Installing new version of config file /etc/console-setup/compose.ISO-8859-13.inc ...
Installing new version of config file /etc/console-setup/compose.ISO-8859-14.inc ...
Installing new version of config file /etc/console-setup/compose.ISO-8859-15.inc ...
Installing new version of config file /etc/console-setup/compose.ISO-8859-2.inc ...
Installing new version of config file /etc/console-setup/compose.ISO-8859-3.inc ...
Installing new version of config file /etc/console-setup/compose.ISO-8859-4.inc ...
Installing new version of config file /etc/console-setup/compose.ISO-8859-7.inc ...
Installing new version of config file /etc/console-setup/compose.ISO-8859-9.inc ...
Setting up console-setup (1.114) ...
Setting up libsvn1:amd64 (1.8.10-3) ...
Setting up libsvn-dev (1.8.10-3) ...
Setting up subversion (1.8.10-3) ...
Setting up libapache2-mod-svn (1.8.10-3) ...
apache2_invoke authz_svn: already enabled
[ ok ] Restarting web server: apache2.
apache2_invoke dav_svn: already enabled
[ ok ] Restarting web server: apache2.
Setting up subversion-tools (1.8.10-3) ...
Setting up python-subversion (1.8.10-3) ...
Setting up libsvn-perl (1.8.10-3) ...
Setting up subversion-dbg (1.8.10-3) ...
Setting up alacarte (3.11.91-2) ...
Setting up bdf2psf (1.114) ...
Setting up gkrellm (2.3.6~rc1-1) ...
Setting up gnome-calculator (3.14.1-1) ...
Setting up gnustep-common (2.6.6-3) ...
Setting up gnustep-base-common (1.24.7-1) ...
Setting up libgnustep-base1.24 (1.24.7-1) ...
Setting up gnustep-base-runtime (1.24.7-1) ...
Installing new version of config file /etc/default/gdomap ...
Installing new version of config file /etc/init.d/gdomap ...
[info] GNUstep distributed object mapper disabled, see /etc/default/gdomap.
Setting up how-can-i-help (9) ...
Setting up libdigest-sha-perl (5.93-1) ...
Setting up libtext-levenshtein-perl (0.11-1) ...
Setting up libxml-twig-perl (1:3.48-1) ...
Setting up python-libxml2 (2.9.2+dfsg1-1) ...
Setting up xserver-xorg-input-mouse (1:1.9.1-1) ...
Processing triggers for libc-bin (2.19-12) ...
Processing triggers for menu (2.1.47) ...
and dpkg -l says:
it man-db 2.7.0.2-2 amd64 on-line manual pager
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug reopened
Request was from Vincent Lefevre <vincent@vinc17.net>
to 766758-submit@bugs.debian.org.
(Sun, 26 Oct 2014 23:57:14 GMT) (full text, mbox, link).
Bug reassigned from package 'ekiga' to 'dpkg'.
Request was from Vincent Lefevre <vincent@vinc17.net>
to 766758-submit@bugs.debian.org.
(Sun, 26 Oct 2014 23:57:15 GMT) (full text, mbox, link).
No longer marked as found in versions ekiga/4.0.1-5.
Request was from Vincent Lefevre <vincent@vinc17.net>
to 766758-submit@bugs.debian.org.
(Sun, 26 Oct 2014 23:57:16 GMT) (full text, mbox, link).
Marked as found in versions dpkg/1.17.21.
Request was from Vincent Lefevre <vincent@vinc17.net>
to 766758-submit@bugs.debian.org.
(Sun, 26 Oct 2014 23:57:17 GMT) (full text, mbox, link).
Changed Bug title to 'partially installed packages (triggers pending) after upgrade' from 'ekiga is partially installed (triggers-awaited)'
Request was from Vincent Lefevre <vincent@vinc17.net>
to 766758-submit@bugs.debian.org.
(Sun, 26 Oct 2014 23:57:17 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#766758; Package dpkg.
(Mon, 27 Oct 2014 01:18:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Vincent Lefevre <vincent@vinc17.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Mon, 27 Oct 2014 01:18:04 GMT) (full text, mbox, link).
I've just upgraded another machine, and:
$ COLUMNS=70 dpkg -l | grep -v '^ii'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
iW ekiga 4.0.1-5 amd64 H.323 and SIP compatible VoIP cli
it gconf2 3.2.6-3 amd64 GNOME configuration database syst
it man-db 2.7.0.2-2 amd64 on-line manual pager
So, this is similar to the other one.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#766758; Package dpkg.
(Mon, 27 Oct 2014 01:48:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Mon, 27 Oct 2014 01:48:04 GMT) (full text, mbox, link).
To: Vincent Lefevre <vincent@vinc17.net>, 766758@bugs.debian.org
Cc: Eugen Dedu <eugen.dedu@univ-fcomte.fr>
Subject: Re: Bug#766758: ekiga is half-installed
Date: Mon, 27 Oct 2014 02:44:38 +0100
Control: severity -1 important
Let's lower this for now, as this is certainly not critical in any
way, and I don't think it's serious for now, too many unknowns, but
I'll bump it again if it happens to be so.
On Mon, 2014-10-27 at 02:14:32 +0100, Vincent Lefevre wrote:
> I've just upgraded another machine, and:
>
> $ COLUMNS=70 dpkg -l | grep -v '^ii'
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name Version Architecture Description
> +++-==============-============-============-=================================
> iW ekiga 4.0.1-5 amd64 H.323 and SIP compatible VoIP cli
> it gconf2 3.2.6-3 amd64 GNOME configuration database syst
> it man-db 2.7.0.2-2 amd64 on-line manual pager
>
> So, this is similar to the other one.
Ok, I know you set the version affecting the other system to 1.17.21,
but is this one too that version? was it upgraded to that on the same
upgrade run?
Just installing and reinstalling ekiga here does not reproduce that.
Could you backup that dpkg status file anyway, and check if
«dpkg --configure -a» fixes it for you?
If it does not, I'd be interested in the -D77777 output from that, or
the status file (feel free to send privately, for privacy reasons, etc).
Thanks,
Guillem
Severity set to 'important' from 'critical'
Request was from Guillem Jover <guillem@debian.org>
to 766758-submit@bugs.debian.org.
(Mon, 27 Oct 2014 01:48:04 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#766758; Package dpkg.
(Mon, 27 Oct 2014 03:15:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Vincent Lefevre <vincent@vinc17.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Mon, 27 Oct 2014 03:15:04 GMT) (full text, mbox, link).
Cc: 766758@bugs.debian.org, Eugen Dedu <eugen.dedu@univ-fcomte.fr>
Subject: Re: Bug#766758: ekiga is half-installed
Date: Mon, 27 Oct 2014 04:11:33 +0100
On 2014-10-27 02:44:38 +0100, Guillem Jover wrote:
> Let's lower this for now, as this is certainly not critical in any
> way, and I don't think it's serious for now, too many unknowns, but
> I'll bump it again if it happens to be so.
IMHO, it would be bad if it affected stable.
> On Mon, 2014-10-27 at 02:14:32 +0100, Vincent Lefevre wrote:
> > I've just upgraded another machine, and:
[...]
> > So, this is similar to the other one.
>
> Ok, I know you set the version affecting the other system to 1.17.21,
> but is this one too that version? was it upgraded to that on the same
> upgrade run?
1.17.21 too, because I had upgraded dpkg first, then upgraded
everything else later.
> Just installing and reinstalling ekiga here does not reproduce that.
> Could you backup that dpkg status file anyway, and check if
> «dpkg --configure -a» fixes it for you?
# dpkg --configure -a
Setting up gconf2 (3.2.6-3) ...
Setting up man-db (2.7.0.2-2) ...
Building database of manual pages ...
Setting up ekiga (4.0.1-5) ...
Processing triggers for menu (2.1.47) ...
which fixes the problem.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#766758; Package dpkg.
(Mon, 27 Oct 2014 03:36:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Christoph Anton Mitterer <calestyo@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Mon, 27 Oct 2014 03:36:04 GMT) (full text, mbox, link).
From: Christoph Anton Mitterer <calestyo@gmail.com>
To: 766758@bugs.debian.org
Subject: Re: partially installed packages (triggers pending) after upgrade
Date: Mon, 27 Oct 2014 04:32:38 +0100
I've also had this today on all my nodes (with 1.17.21).
Triggers for man-db were not run at the last update run...
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#766758; Package dpkg.
(Mon, 27 Oct 2014 16:48:09 GMT) (full text, mbox, link).
Acknowledgement sent
to Sven Joachim <svenjoac@gmx.de>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Mon, 27 Oct 2014 16:48:09 GMT) (full text, mbox, link).
I'm another person observing the problem, after a routine upgrade
shared-mime-info and xboard ended up in status triggers-pending and
triggers-awaited, respectively.
Attached is the part of dpkg.log from the upgrade, as you can see
shared-mime-info's trigger never got processed.
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#766758; Package dpkg.
(Tue, 28 Oct 2014 05:03:12 GMT) (full text, mbox, link).
Acknowledgement sent
to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Tue, 28 Oct 2014 05:03:12 GMT) (full text, mbox, link).
To: Vincent Lefevre <vincent@vinc17.net>, 766758@bugs.debian.org
Cc: Eugen Dedu <eugen.dedu@univ-fcomte.fr>
Subject: Re: Bug#766758: ekiga is half-installed
Date: Tue, 28 Oct 2014 06:00:43 +0100
Hi!
On Mon, 2014-10-27 at 04:11:33 +0100, Vincent Lefevre wrote:
> On 2014-10-27 02:44:38 +0100, Guillem Jover wrote:
> > Let's lower this for now, as this is certainly not critical in any
> > way, and I don't think it's serious for now, too many unknowns, but
> > I'll bump it again if it happens to be so.
>
> IMHO, it would be bad if it affected stable.
It would be an undesirable regression sure, I want to understand
what's going on first. It could be an issue in how apt invokes dpkg,
that only showed up now that triggers are only processed when they
have their dependencies satisfied.
In any case, I want to see 1.17.21 migrate first, and then if this is
a regression in dpkg I'll be immediately uploading .22 with a fix for
it, and requesting an unblock for just .22 to the release team. I don't
want to have to deal with a request to unblock 1.17.13..1.17.22 at all,
TBH.
> > On Mon, 2014-10-27 at 02:14:32 +0100, Vincent Lefevre wrote:
> > > I've just upgraded another machine, and:
> [...]
> > > So, this is similar to the other one.
> >
> > Ok, I know you set the version affecting the other system to 1.17.21,
> > but is this one too that version? was it upgraded to that on the same
> > upgrade run?
>
> 1.17.21 too, because I had upgraded dpkg first, then upgraded
> everything else later.
Yes, I've got now a reliable reproducer on my kfreebsd-amd64 system.
It's not processing the man-db triggers because libpipeline1 is not
configured yet, but I don't know yet why it's not marked as being
configured in that run. I'll be checking how apt is calling dpkg
tomorrow, so see where this fails.
> > Just installing and reinstalling ekiga here does not reproduce that.
> > Could you backup that dpkg status file anyway, and check if
> > «dpkg --configure -a» fixes it for you?
>
> # dpkg --configure -a
> Setting up gconf2 (3.2.6-3) ...
> Setting up man-db (2.7.0.2-2) ...
> Building database of manual pages ...
> Setting up ekiga (4.0.1-5) ...
> Processing triggers for menu (2.1.47) ...
>
> which fixes the problem.
Yeah, so while quite annoying, this is actually just self-healing,
which is good.
Thanks,
Guillem
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#766758; Package dpkg.
(Wed, 29 Oct 2014 16:45:07 GMT) (full text, mbox, link).
Acknowledgement sent
to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Wed, 29 Oct 2014 16:45:07 GMT) (full text, mbox, link).
To: Vincent Lefevre <vincent@vinc17.net>, 766758@bugs.debian.org
Cc: Eugen Dedu <eugen.dedu@univ-fcomte.fr>,
Christoph Anton Mitterer <calestyo@gmail.com>,
apt@packages.debian.org
Subject: Re: Bug#766758: apt: does not process pending triggers
Date: Wed, 29 Oct 2014 17:41:25 +0100
Control: retitle -1 apt: does not process pending triggers
Control: reassign -1 apt
Control: affects -1 dpkg
This should probably be considered an RC bug, but I'll let the apt
maintainers deal with that.
Hi!
On Tue, 2014-10-28 at 06:00:43 +0100, Guillem Jover wrote:
> On Mon, 2014-10-27 at 04:11:33 +0100, Vincent Lefevre wrote:
> > On 2014-10-27 02:44:38 +0100, Guillem Jover wrote:
> > > Let's lower this for now, as this is certainly not critical in any
> > > way, and I don't think it's serious for now, too many unknowns, but
> > > I'll bump it again if it happens to be so.
> >
> > IMHO, it would be bad if it affected stable.
>
> It would be an undesirable regression sure, I want to understand
> what's going on first. It could be an issue in how apt invokes dpkg,
> that only showed up now that triggers are only processed when they
> have their dependencies satisfied.
> > > On Mon, 2014-10-27 at 02:14:32 +0100, Vincent Lefevre wrote:
> > > > I've just upgraded another machine, and:
> > [...]
> > > > So, this is similar to the other one.
> > >
> > > Ok, I know you set the version affecting the other system to 1.17.21,
> > > but is this one too that version? was it upgraded to that on the same
> > > upgrade run?
> >
> > 1.17.21 too, because I had upgraded dpkg first, then upgraded
> > everything else later.
>
> Yes, I've got now a reliable reproducer on my kfreebsd-amd64 system.
> It's not processing the man-db triggers because libpipeline1 is not
> configured yet, but I don't know yet why it's not marked as being
> configured in that run. I'll be checking how apt is calling dpkg
> tomorrow, so see where this fails.
Ok, here's the minimal reproducer and analysis:
,---
# apt-get install --reinstall libpipeline1 wget
[…]
(Reading database ... 232896 files and directories currently installed.)
Preparing to unpack .../libpipeline1_1.4.0-1_amd64.deb ...
Unpacking libpipeline1:amd64 (1.4.0-1) over (1.4.0-1) ...
Preparing to unpack .../archives/wget_1.16-1_amd64.deb ...
Unpacking wget (1.16-1) over (1.16-1) ...
Processing triggers for install-info (5.2.0.dfsg.1-5) ...
Setting up libpipeline1:amd64 (1.4.0-1) ...
Setting up wget (1.16-1) ...
Processing triggers for libc-bin (2.19-12) ...
# dpkg -C
The following packages have been triggered, but the trigger processing
has not yet been done. Trigger processing can be requested using
dselect or dpkg --configure --pending (or dpkg --triggers-only):
man-db on-line manual pager
`---
,---
# apt-get -o Debug::pkgDPkgPM=true install --reinstall libpipeline1 wget
[…]
/usr/bin/dpkg --status-fd 28 --unpack --auto-deconfigure \
/var/cache/apt/archives/libpipeline1_1.4.0-1_amd64.deb \
/var/cache/apt/archives/wget_1.16-1_amd64.deb
/usr/bin/dpkg --status-fd 30 --configure libpipeline1:amd64 wget:amd64
`---
So, what's happening here is this. apt tells dpkg to unpack those two
packages, libpipeline1 is a depenendcy of man-db, and wget contains a
man page which will activate the man-db trigger.
Because during wget unpack the man-db dependencies are not satisfied
anymore, as libpipeline1 is also unpacked, its trigger cannot be
processed (starting with dpkg 1.17.17), so they get deferred for later.
Then, on the second dpkg invocation, apt tells dpkg exactly what it
wants configured, and that does not include man-db, so dpkg does not
process that one, because it's not required to configure them.
So apt needs to either pass man-db to the --configure call, or just
do a final --triggers-only/--configure --pending call. A trivial fix
would be to change the default value for DPkg::TriggersPending to
true.
,---
apt-get -o DPkg::TriggersPending=true install --reinstall libpipeline1 wget
[…]
(Reading database ... 232896 files and directories currently installed.)
Preparing to unpack .../libpipeline1_1.4.0-1_amd64.deb ...
Unpacking libpipeline1:amd64 (1.4.0-1) over (1.4.0-1) ...
Preparing to unpack .../archives/wget_1.16-1_amd64.deb ...
Unpacking wget (1.16-1) over (1.16-1) ...
Processing triggers for install-info (5.2.0.dfsg.1-5) ...
Setting up libpipeline1:amd64 (1.4.0-1) ...
Setting up wget (1.16-1) ...
Processing triggers for libc-bin (2.19-12) ...
Processing triggers for man-db (2.7.0.2-2) ...
`---
This should be pretty safe as a default, because a --pending call when
there's nothing pending is always successful.
Thanks,
Guillem
Changed Bug title to 'apt: does not process pending triggers' from 'partially installed packages (triggers pending) after upgrade'
Request was from Guillem Jover <guillem@debian.org>
to 766758-submit@bugs.debian.org.
(Wed, 29 Oct 2014 16:45:07 GMT) (full text, mbox, link).
Bug reassigned from package 'dpkg' to 'apt'.
Request was from Guillem Jover <guillem@debian.org>
to 766758-submit@bugs.debian.org.
(Wed, 29 Oct 2014 16:45:08 GMT) (full text, mbox, link).
No longer marked as found in versions dpkg/1.17.21.
Request was from Guillem Jover <guillem@debian.org>
to 766758-submit@bugs.debian.org.
(Wed, 29 Oct 2014 16:45:09 GMT) (full text, mbox, link).
Added indication that 766758 affects dpkg
Request was from Guillem Jover <guillem@debian.org>
to 766758-submit@bugs.debian.org.
(Wed, 29 Oct 2014 16:45:10 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>: Bug#766758; Package apt.
(Wed, 29 Oct 2014 17:45:05 GMT) (full text, mbox, link).
Acknowledgement sent
to Vincent Lefevre <vincent@vinc17.net>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>.
(Wed, 29 Oct 2014 17:45:05 GMT) (full text, mbox, link).
Cc: 766758@bugs.debian.org, Eugen Dedu <eugen.dedu@univ-fcomte.fr>,
Christoph Anton Mitterer <calestyo@gmail.com>,
apt@packages.debian.org
Subject: Re: Bug#766758: apt: does not process pending triggers
Date: Wed, 29 Oct 2014 18:42:09 +0100
On 2014-10-29 17:41:25 +0100, Guillem Jover wrote:
> Control: retitle -1 apt: does not process pending triggers
> Control: reassign -1 apt
> Control: affects -1 dpkg
>
> This should probably be considered an RC bug, but I'll let the apt
> maintainers deal with that.
Note that aptitude has the same problem.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Information forwarded
to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>: Bug#766758; Package apt.
(Wed, 29 Oct 2014 19:33:11 GMT) (full text, mbox, link).
Acknowledgement sent
to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>.
(Wed, 29 Oct 2014 19:33:11 GMT) (full text, mbox, link).
Cc: 766758@bugs.debian.org, Eugen Dedu <eugen.dedu@univ-fcomte.fr>,
Christoph Anton Mitterer <calestyo@gmail.com>
Subject: Re: Bug#766758: apt: does not process pending triggers
Date: Wed, 29 Oct 2014 20:29:54 +0100
Hi!
On Wed, 2014-10-29 at 18:42:09 +0100, Vincent Lefevre wrote:
> On 2014-10-29 17:41:25 +0100, Guillem Jover wrote:
> > Control: retitle -1 apt: does not process pending triggers
> > Control: reassign -1 apt
> > Control: affects -1 dpkg
> >
> > This should probably be considered an RC bug, but I'll let the apt
> > maintainers deal with that.
>
> Note that aptitude has the same problem.
A fix in apt would also fix any such issue in aptitude AFAICS:
,---
# aptitude reinstall libpipeline1 wget
[…]
(Reading database ... 232896 files and directories currently installed.)
Preparing to unpack .../libpipeline1_1.4.0-1_amd64.deb ...
Unpacking libpipeline1:amd64 (1.4.0-1) over (1.4.0-1) ...
Preparing to unpack .../archives/wget_1.16-1_amd64.deb ...
Unpacking wget (1.16-1) over (1.16-1) ...
Processing triggers for install-info (5.2.0.dfsg.1-5) ...
Setting up libpipeline1:amd64 (1.4.0-1) ...
Setting up wget (1.16-1) ...
Processing triggers for libc-bin (2.19-12) ...
# dpkg --audit
The following packages have been triggered, but the trigger processing
has not yet been done. Trigger processing can be requested using
dselect or dpkg --configure --pending (or dpkg --triggers-only):
man-db on-line manual pager
# dpkg --configure --pending
Processing triggers for man-db (2.7.0.2-2) ...
# aptitude -o DPkg::TriggersPending=true reinstall libpipeline1 wget
[…]
(Reading database ... 232896 files and directories currently installed.)
Preparing to unpack .../libpipeline1_1.4.0-1_amd64.deb ...
Unpacking libpipeline1:amd64 (1.4.0-1) over (1.4.0-1) ...
Preparing to unpack .../archives/wget_1.16-1_amd64.deb ...
Unpacking wget (1.16-1) over (1.16-1) ...
Processing triggers for install-info (5.2.0.dfsg.1-5) ...
Setting up libpipeline1:amd64 (1.4.0-1) ...
Setting up wget (1.16-1) ...
Processing triggers for libc-bin (2.19-12) ...
Processing triggers for man-db (2.7.0.2-2) ...
`---
Thanks,
Guillem
Information forwarded
to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>: Bug#766758; Package apt.
(Sun, 02 Nov 2014 14:30:12 GMT) (full text, mbox, link).
Acknowledgement sent
to David Kalnischkies <david@kalnischkies.de>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>.
(Sun, 02 Nov 2014 14:30:13 GMT) (full text, mbox, link).
Cc: Vincent Lefevre <vincent@vinc17.net>,
Guillem Jover <guillem@debian.org>,
Eugen Dedu <eugen.dedu@univ-fcomte.fr>,
Christoph Anton Mitterer <calestyo@gmail.com>,
apt@packages.debian.org, dpkg@packages.debian.org
Subject: Re: Bug#766758: apt: does not process pending triggers
Control: reassign -1 dpkg
On Wed, Oct 29, 2014 at 05:41:25PM +0100, Guillem Jover wrote:
> Control: retitle -1 apt: does not process pending triggers
> Control: reassign -1 apt
> Control: affects -1 dpkg
>
> This should probably be considered an RC bug, but I'll let the apt
> maintainers deal with that.
Every libapt-based tooling has this problem and will all be fixed by the
same fix, BUT this bug effects stable upgrades as apt (/aptitude/
synaptics/…) will upgrade dpkg pretty early in the upgrade process and
the new dpkg (with its behaviour change) will deal with the rest of the
upgrade and so everyone will have unprocessed triggers. This is
unacceptable IMHO and nothing we can paper over with a release notes
entry.
I dislike bug-pingpong, but in this case I have to move it back to dpkg
as we can't change apt to make upgrades work (at least it was never
allowed in the past, so I doubt it is an option now) and its a behaviour
change in dpkg, not a apt regression per-se, so dpkg/jessie has to behave
as expected by libapt-pkg/wheezy here regardless of how dumb that might
be.
I would suggest that "--configure foo" is extended to implicitly run
all pending triggers by default for jessie (at least those which can be
run as their dependencies are satisfied). We (as in apt) will change
apt/jessie to run "dpkg --triggers-only --pending" after the last dpkg
invocation and you can change dpkg/jessie+1 to behave like it does now.
(assuming the release team agrees to this plan)
Not the most efficient solution as dpkg and apt in jessie will both waste
some time doing stuff they don't have to just for the sake of upgrades,
but compared to the time they take to do their actual work, its
negligible and doing funky stuff to detect an upgrade in progress
are probably going to explode…
If you agree just clone the bug back to us and I will take care of it
from the apt side. You might want to clone it to other dpkg-callers as
well as I presume that at least some have the same problem. Otherwise,
I am all ears for alternative solutions.
> So apt needs to either pass man-db to the --configure call, or just
> do a final --triggers-only/--configure --pending call. A trivial fix
> would be to change the default value for DPkg::TriggersPending to
> true.
The option exists in apt/wheezy already, but it runs --triggers-only after
EVERY explicit --configure call¹, which can be quiet frequent as e.g.
every (pseudo-)essential package is configured on its own. I had it
implemented to circumvent #526774. Now it isn't needed anymore…
(well, it never was as the whole option group was never the default.
I hope to have some time after jessie release to look into this as its
kinda embarrassing that I wanted to do it for 5 years now…)
Anyway, we can't enable this option retroactively even if we wanted to…
Best regards
David Kalnischkies
¹ so basically, it would do what my suggestion is above to be done by
default, BUT I would expect the call to fail if a pending trigger can't
be run while the implicit suggested one would carry on as normal.
Bug reassigned from package 'apt' to 'dpkg'.
Request was from David Kalnischkies <david@kalnischkies.de>
to 766758-submit@bugs.debian.org.
(Sun, 02 Nov 2014 14:30:13 GMT) (full text, mbox, link).
Marked as found in versions dpkg/1.17.21.
Request was from Vincent Lefevre <vincent@vinc17.net>
to control@bugs.debian.org.
(Sun, 02 Nov 2014 18:18:08 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#766758; Package dpkg.
(Fri, 14 Nov 2014 23:33:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Fri, 14 Nov 2014 23:33:04 GMT) (full text, mbox, link).
To: David Kalnischkies <david@kalnischkies.de>, 766758@bugs.debian.org
Cc: Vincent Lefevre <vincent@vinc17.net>,
Eugen Dedu <eugen.dedu@univ-fcomte.fr>,
Christoph Anton Mitterer <calestyo@gmail.com>,
apt@packages.debian.org, dpkg@packages.debian.org,
cupt@packages.debian.org
Subject: Re: Bug#766758: apt: does not process pending triggers
Date: Sat, 15 Nov 2014 00:28:07 +0100
Control: severity -1 serious
Control: clone -1 -2
Control: retitle -1 dpkg: Needs to workaround apt not processing pending triggers
Control: affects -1
Control: reassign -2 apt
[ CCed cupt maintainers, please see below. ]
On Sun, 2014-11-02 at 15:26:06 +0100, David Kalnischkies wrote:
> On Wed, Oct 29, 2014 at 05:41:25PM +0100, Guillem Jover wrote:
> > This should probably be considered an RC bug, but I'll let the apt
> > maintainers deal with that.
I've bumped it to serious now for both, if you disagree, please lower
the one on your end.
> Every libapt-based tooling has this problem and will all be fixed by the
> same fix, BUT this bug effects stable upgrades as apt (/aptitude/
> synaptics/…) will upgrade dpkg pretty early in the upgrade process and
> the new dpkg (with its behaviour change) will deal with the rest of the
> upgrade and so everyone will have unprocessed triggers. This is
> unacceptable IMHO and nothing we can paper over with a release notes
> entry.
Right.
> I dislike bug-pingpong, but in this case I have to move it back to dpkg
> as we can't change apt to make upgrades work (at least it was never
> allowed in the past, so I doubt it is an option now) and its a behaviour
> change in dpkg, not a apt regression per-se, so dpkg/jessie has to behave
> as expected by libapt-pkg/wheezy here regardless of how dumb that might
> be.
Sure, although the current apt behavior goes against the written
triggers spec, where apt/aptitude even have their own section. :)
> I would suggest that "--configure foo" is extended to implicitly run
> all pending triggers by default for jessie (at least those which can be
> run as their dependencies are satisfied). We (as in apt) will change
> apt/jessie to run "dpkg --triggers-only --pending" after the last dpkg
> invocation and you can change dpkg/jessie+1 to behave like it does now.
> (assuming the release team agrees to this plan)
Now that I've been able to track down and fix all remaining triggers
fallout in dpkg, I've implemented something like this locally. When
using «dpkg --configure pkgname...» w/o --no-triggers, dpkg will
populate the deferred triggers queue with any package pending trigger
processing. This queue is processed at the end of the dpkg run, but
is opportunistic, and will not fail if the dependencies for those
packages cannot be satisfied, which *might* sill leave packages in
not fully installed states, but if that happens then that's probably
either a packaging or apt bug anyway.
It seems to me this might not conform to the triggers spec, with a very
strict reading of it. But given that dpkg has not honored dependencies
for them up to very recently, it does not make sense to try to be holier
than the pope here.
> Not the most efficient solution as dpkg and apt in jessie will both waste
> some time doing stuff they don't have to just for the sake of upgrades,
> but compared to the time they take to do their actual work, its
> negligible and doing funky stuff to detect an upgrade in progress
> are probably going to explode…
Yeah, it's just annoying code-wise, work-wise it's just a matter of
scanning all installed packages, which should be quick. The trigger
processing would have been performed on a previous run before dpkg
was checking dependency satisfiability anyway, so no visible additional
work due to that either, maybe even less work.
> If you agree just clone the bug back to us and I will take care of it
> from the apt side. You might want to clone it to other dpkg-callers as
> well as I presume that at least some have the same problem. Otherwise,
> I am all ears for alternative solutions.
Only apt seems to be affected. dselect properly uses “dpkg transactions”
and as such queues all configuration in a final «--configure --pending»
call. And cupt seems to behave correctly by calling dpkg with
«--triggers-only --pending», but Eugene might know for sure.
If you know of other frontends, I'd be interested to know.
> > So apt needs to either pass man-db to the --configure call, or just
> > do a final --triggers-only/--configure --pending call. A trivial fix
> > would be to change the default value for DPkg::TriggersPending to
> > true.
>
> The option exists in apt/wheezy already, but it runs --triggers-only after
> EVERY explicit --configure call¹, which can be quiet frequent as e.g.
> every (pseudo-)essential package is configured on its own. I had it
> implemented to circumvent #526774. Now it isn't needed anymore…
> (well, it never was as the whole option group was never the default.
> I hope to have some time after jessie release to look into this as its
> kinda embarrassing that I wanted to do it for 5 years now…)
> Anyway, we can't enable this option retroactively even if we wanted to…
Sure, but enabling it for Jessie would allow for this to be fixed
properly during Stretch, and for the dpkg workaround to possibly be
removed immediately in dpkg 1.18.x.
Thanks,
Guillem
Severity set to 'serious' from 'important'
Request was from Guillem Jover <guillem@debian.org>
to 766758-submit@bugs.debian.org.
(Fri, 14 Nov 2014 23:33:04 GMT) (full text, mbox, link).
Bug 766758 cloned as bug 769609
Request was from Guillem Jover <guillem@debian.org>
to 766758-submit@bugs.debian.org.
(Fri, 14 Nov 2014 23:33:05 GMT) (full text, mbox, link).
Changed Bug title to 'dpkg: Needs to workaround apt not processing pending triggers' from 'apt: does not process pending triggers'
Request was from Guillem Jover <guillem@debian.org>
to 766758-submit@bugs.debian.org.
(Fri, 14 Nov 2014 23:33:06 GMT) (full text, mbox, link).
Removed indication that 766758 affects dpkg
Request was from Guillem Jover <guillem@debian.org>
to 766758-submit@bugs.debian.org.
(Fri, 14 Nov 2014 23:33:07 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#766758; Package dpkg.
(Sat, 15 Nov 2014 09:51:05 GMT) (full text, mbox, link).
Acknowledgement sent
to "Eugene V. Lyubimkin" <jackyf@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Sat, 15 Nov 2014 09:51:05 GMT) (full text, mbox, link).
Subject: Re: Bug#766758: apt: does not process pending triggers
Date: Sat, 15 Nov 2014 11:43:02 +0200
Hello!
[ some CC's dropped, please tell if I missed someone ]
Did not touch trigger stuff for a while, let's see if I catched up what
happens here:
2014-11-15 00:28, Guillem Jover:
> [...]
> Only apt seems to be affected. dselect properly uses “dpkg transactions”
> and as such queues all configuration in a final «--configure --pending»
> call. And cupt seems to behave correctly by calling dpkg with
> «--triggers-only --pending», but Eugene might know for sure.
Cupt calls '--triggers-only --pending' in the end of run when
"trigger deferring" (i.e. '--no-triggers') is enabled, which is the
default (both in wheezy and jessie).
Do I read your explanation [1] correctly that '--triggers-only
--pending' needs to be invoked (in the end) always, since dpkg may
choose not to process triggers not just because '--no-triggers' is
passed, but also because dependencies of a 'triggers-pending' package
are not satisfied right at that time?
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766758#69
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#766758; Package dpkg.
(Sat, 15 Nov 2014 17:27:05 GMT) (full text, mbox, link).
Acknowledgement sent
to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Sat, 15 Nov 2014 17:27:05 GMT) (full text, mbox, link).
Subject: Re: Bug#766758: apt: does not process pending triggers
Date: Sat, 15 Nov 2014 18:24:16 +0100
Hi!
On Sat, 2014-11-15 at 11:43:02 +0200, Eugene V. Lyubimkin wrote:
> Did not touch trigger stuff for a while, let's see if I catched up what
> happens here:
>
> 2014-11-15 00:28, Guillem Jover:
> > [...]
> > Only apt seems to be affected. dselect properly uses “dpkg transactions”
> > and as such queues all configuration in a final «--configure --pending»
> > call. And cupt seems to behave correctly by calling dpkg with
> > «--triggers-only --pending», but Eugene might know for sure.
>
> Cupt calls '--triggers-only --pending' in the end of run when
> "trigger deferring" (i.e. '--no-triggers') is enabled, which is the
> default (both in wheezy and jessie).
Good then.
> Do I read your explanation [1] correctly that '--triggers-only
> --pending' needs to be invoked (in the end) always, since dpkg may
> choose not to process triggers not just because '--no-triggers' is
> passed, but also because dependencies of a 'triggers-pending' package
> are not satisfied right at that time?
Well, yes and no. If the frontend is smart enough, it might decide to
call «dpkg --triggers-only --pending» only if there are actually
packages pending trigger processing, otherwise it could just skip that
dpkg run. If the frontend is using “dpkg transactions”, then it will
be doing a final «dpkg --configure --pending» which will perform all
configuration and trigger processing, so that'd work too (that's what
dselect is doing for example). Otherwise always calling unconditionally
either --configure or --triggers-only with --pending as a last dpkg run
should do it too, as those calls never fail. But in the end, yeah,
depending on how the frontend interacts with dpkg, the latter might
leave packages pending trigger processing (but not with the workaround
targetting 1.17.22 though).
And w/o wanting to get tiresome with this, take into account that
frontends that use any of the dpkg --force-* options as normal course
of action, will most probably produce intermediate broken states. For
example in #768852 I found that apt was removing libaudit0 before
readahead-fedora had been upgraded, so its dependencies were not
satisfiable when going to process triggers. If apt would have instead
marked libaudit0 for removal using selections, then dpkg would have
been able to remove it in case it needed to, due to conflicts or
similar.
Thanks,
Guillem
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#766758; Package dpkg.
(Sun, 23 Nov 2014 17:42:05 GMT) (full text, mbox, link).
Acknowledgement sent
to David Kalnischkies <david@kalnischkies.de>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Sun, 23 Nov 2014 17:42:05 GMT) (full text, mbox, link).
On Sat, Nov 15, 2014 at 12:28:07AM +0100, Guillem Jover wrote:
> > I dislike bug-pingpong, but in this case I have to move it back to dpkg
> > as we can't change apt to make upgrades work (at least it was never
> > allowed in the past, so I doubt it is an option now) and its a behaviour
> > change in dpkg, not a apt regression per-se, so dpkg/jessie has to behave
> > as expected by libapt-pkg/wheezy here regardless of how dumb that might
> > be.
>
> Sure, although the current apt behavior goes against the written
> triggers spec, where apt/aptitude even have their own section. :)
I don't want to be seen as picky, but it doesn't. Especially the
mentioned section isn't violated. We know these states and we call
configure for them if we see them, but the next line says we usually
will not see them. What you did now is changing the "usual" in this
sentence to "in the way you are using it, it will be close to always".
Triggers are from our viewpoint an implementation detail of dpkg (which
is also what the spec suggests), which leaks into our domain more and
more for "good" reasons, but at the same time its bad as we can't really
deal with them as there is no way to predict what will happen…
> > If you agree just clone the bug back to us and I will take care of it
> > from the apt side. You might want to clone it to other dpkg-callers as
> > well as I presume that at least some have the same problem. Otherwise,
> > I am all ears for alternative solutions.
>
> Only apt seems to be affected. dselect properly uses “dpkg transactions”
> and as such queues all configuration in a final «--configure --pending»
> call. And cupt seems to behave correctly by calling dpkg with
> «--triggers-only --pending», but Eugene might know for sure.
>
> If you know of other frontends, I'd be interested to know.
Well, I don't know, but I would guess that at least the various
(cross-)bootstrappers need to be checked. smartpm (although, it might be
better to just remove it). d-i maybe, but I guess it doesn't use dpkg
directly (and/or later states with apt will "fix" that up). codesearch
might help if you can come up with a good search pattern (I couldn't).
> > > So apt needs to either pass man-db to the --configure call, or just
> > > do a final --triggers-only/--configure --pending call. A trivial fix
> > > would be to change the default value for DPkg::TriggersPending to
> > > true.
I just realized that we also have a dpkg::ConfigurePending option
causing apt to run a "dpkg --configure --pending" after all other dpkg
calls, so I will opt for this one as it is more future proof and does
what we need just as well.
Reasoning: I just tried the following sequence:
dpkg -i trigdepends-interest_1.0_all.deb triggerable-interest_1.0_all.deb
# ^ dependency ^ interest /usr/share/doc
dpkg --unpack trigdepends-interest_1.0_all.deb
dpkg --unpack trigstuff_1.0_all.deb
dpkg --configure trigstuff
# ^ trigstuff is iW as dependencies of trigger aren't statisfied
dpkg --triggers-only --pending
My expectation I expressed in the previous mail was that the last
command here would fail as a pending trigger can't be run. It doesn't,
so my biggest concern with dpkg::TriggersPending isn't really existing,
but I still think that running it all the time isn't needed if we can
just do the more general ConfigurePending once.
Best regards
David Kalnischkies
P.S.: I will respond to other parts of the mail/thread in other
threads/bugs to keep all reasonably ordered… if that is possible.
tag 766758 pending
thanks
Hello,
Bug #766758 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:
http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=75a857d
---
commit 75a857d79d3d3a5cb8367bbd49d5e89bb94af0a1
Author: Guillem Jover <guillem@debian.org>
Date: Fri Nov 14 18:35:32 2014 +0100
libdpkg: Register all pending triggers for deferred processing
Trigger processing on the deferred stage is just opportunistic, but
we enqueue all currently pending triggers that might have been
activated on a previous unpack run, only when being called as
«dpkg --configure pkgname…».
This is a mostly conformant workaround for frontends like apt that do
not correctly call «dpkg --configure -a» or «dpkg --triggers-only -a»
after their normal runs, and leave packages in triggers-pending and
triggers-awaited states.
Closes: #766758
diff --git a/debian/changelog b/debian/changelog
index e58d88d..ba10d7e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -28,6 +28,11 @@ dpkg (1.17.22) UNRELEASED; urgency=low
should only fail on the former but ignore the latter. Closes: #768852
* Do not ignore trigger cycles for direct dependencies, these are just
normal trigger cycles, and as such should not be special cased.
+ * Register all pending triggers for deferred processing when being called
+ as «dpkg --configure pkgname…». This is a mostly conformant workaround
+ for frontends like apt that do not correctly call «dpkg --configure -a»
+ or «dpkg --triggers-only -a» after their normal runs, and leave packages
+ in triggers-pending and triggers-awaited states. Closes: #766758
[ Updated programs translations ]
* German (Sven Joachim).
Reply sent
to Guillem Jover <guillem@debian.org>:
You have taken responsibility.
(Fri, 28 Nov 2014 03:21:14 GMT) (full text, mbox, link).
Notification sent
to Vincent Lefevre <vincent@vinc17.net>:
Bug acknowledged by developer.
(Fri, 28 Nov 2014 03:21:14 GMT) (full text, mbox, link).
Source: dpkg
Source-Version: 1.17.22
We believe that the bug you reported is fixed in the latest version of
dpkg, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 766758@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Guillem Jover <guillem@debian.org> (supplier of updated dpkg package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Format: 1.8
Date: Fri, 28 Nov 2014 02:02:34 +0100
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source all
Version: 1.17.22
Distribution: unstable
Urgency: low
Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
Changed-By: Guillem Jover <guillem@debian.org>
Description:
dpkg - Debian package management system
dpkg-dev - Debian package development tools
dselect - Debian package management front-end
libdpkg-dev - Debian package management static library
libdpkg-perl - Dpkg perl modules
Closes: 752123766724766758767573767918767934768485768599768852769119769211769843770280771237771255771256
Changes:
dpkg (1.17.22) unstable; urgency=low
.
[ Guillem Jover ]
* Add version introducing --ctrl-tarfile in dpkg-deb(1) man page.
* Bump minimal version for dir_to_symlink and symlink_to_dir commands
to 1.17.14 in dpkg-maintscript-helper(1) man page. Closes: #769843
* Reintroduce update-alternatives, dpkg-divert and dpkg-statoverride
compatibility symlinks under /usr/sbin/. There are still packages
using those paths, but the relevant lintian check did not list any,
so this got removed prematurely.
* Add Breaks on old man-db, fontconfig and readahead-fedora packages using
awaiting triggers, as they produce trigger cycles. Closes: #768599
* Escape package and architecture names on control file parsing warning,
as those get injected into a variable that is used as a format string,
and they come from the package fields, which are under user control.
Regression introduced in dpkg 1.16.0. Fixes CVE-2014-8625. Closes: #768485
Reported by Joshua Rogers <megamansec@gmail.com>.
* Do not match partial field names in control files. Closes: #769119
Regression introduced in dpkg 1.10.
* Fix build on Mac OS X. Regression introduced in dpkg 1.17.11.
Reported by Dominyk Tiller <dominyktiller@gmail.com>.
* Normalize tar entry uid and gid from the current system only in dpkg
unpack. Regression introduced in dpkg 1.17.14. Closes: #769211
* Restore multiple processing instances check for packages and archives
specified on the command-line. Regression introduced in dpkg 1.17.20.
* Fail on trigger processing when it is required to progress. Trigger
processing is sometimes required and sometimes opportunistic, and we
should only fail on the former but ignore the latter. Closes: #768852
* Do not ignore trigger cycles for direct dependencies, these are just
normal trigger cycles, and as such should not be special cased.
* Register all pending triggers for deferred processing when being called
as «dpkg --configure pkgname…». This is a mostly conformant workaround
for frontends like apt that do not correctly call «dpkg --configure -a»
or «dpkg --triggers-only -a» after their normal runs, and leave packages
in triggers-pending and triggers-awaited states. Closes: #766758
.
[ Updated programs translations ]
* Catalan (Guillem Jover).
* Danish (Joe Dalton).
* French (Sébastien Poher).
* German (Sven Joachim).
* Japanese (Kenshi Muto). Closes: #771255
* Polish (Łukasz Dulny).
* Simplified Chinese (Zhou Mo). Closes: #766724, #770280
* Swedish (Peter Krefting).
* Turkish (Mert Dirik).
* Vietnamese (Trần Ngọc Quân)
.
[ Updated scripts translations ]
* French (Sébastien Poher).
* German (Helge Kreutzmann).
* Swedish (Peter Krefting).
.
[ Updated manpages translations ]
* French (Sébastien Poher). Closes: #767934
* German (Helge Kreutzmann). Closes: #752123
* Simplified Chinese (Zhou Mo). Closes: #767573
* Swedish (Peter Krefting).
.
[ Updated dselect translations ]
* Danish (Joe Dalton).
* Dutch (Frans Spiesschaert). Closes: #771237
* French (Sébastien Poher). Closes: #767918
* Japanese (Kenshi Muto). Closes: #771256
* Swedish (Peter Krefting).
Checksums-Sha1:
21507f78265a433132704b01601a5e8771809601 2057 dpkg_1.17.22.dsc
3ebdd854b7864f699cf7d5b7ae815dfdf77f3c2c 4361648 dpkg_1.17.22.tar.xz
da56f069f0f98fa80b201e94de7da8359ea53977 1514060 dpkg-dev_1.17.22_all.deb
e9c1553165deda307d95f278877838b4b31d9b15 1042412 libdpkg-perl_1.17.22_all.deb
Checksums-Sha256:
674b74e45f757f90fe0f22933bdeb5cea121febd46b9d56b9a3a028f4ac6e005 2057 dpkg_1.17.22.dsc
389b2b2fdb6c8946a4cff737c6921e707074cfee249b3803202e3c8e1360c5f3 4361648 dpkg_1.17.22.tar.xz
5296ab2e31bf4eea912cc56dc983bd4732fde3f2ddcd182e86c6d665019aa905 1514060 dpkg-dev_1.17.22_all.deb
48fd415760df7b073eaa8cd397607028e4686fc444064f7fa04c5a5b302d9f8c 1042412 libdpkg-perl_1.17.22_all.deb
Files:
0ec774870ab98d8eb7fd716e8297d71a 2057 admin required dpkg_1.17.22.dsc
c9c46c5318c98c9162fbd03d24f2f95b 4361648 admin required dpkg_1.17.22.tar.xz
b52c79006cb483141d26395f189efd74 1514060 utils optional dpkg-dev_1.17.22_all.deb
150b889a638b89f4f0b363efc149de44 1042412 perl optional libdpkg-perl_1.17.22_all.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJUd9I7AAoJELlyvz6krlejI/YQALNwJpc4YJUkwNQh6dPX56fy
627GJtUrM9aDLkvgdmuraHvk5TSBTIZbinG9OJTe1gZhMAqG9rqlQu/GHLHuLMU+
0JjlswBQF2lc9qg8WUz83x/FMpRZpRbDW2LprckDsqrTmF69FxmO1pmr/WNT1D16
yLl0e8/OTOOIf7yeLjqrEY53bWzTQ76xcVYp7T5BBDJYtY+2YtAQm2rQb0s+J8CO
2uoPp+9yuJTHUXBajAVUC0GChAnuvcwqV51L5uE8sG1VeNBtJ1feIcZKQlbuxe4c
iSm+vB/SueVFNOXq1oBDLf1d8lYsAS/TchvvJgHteljC5pUcsexjE8im68hswT9x
Ooqq9Reb3Fpf5q285ZrKTxH3XVp/l/nDl/QGqYX/VoPv26TwQriM9P1MtyUILQnx
zblQPYRWNL/K+VBFFPjfx4DIb1muqPdwtM47gvtCX1kFG1LRJNUEKwL2AvWWeXuj
r7p8t6nzohCXVdvbP/BZsHMiS6kmp5IgrWojkNl821dHeYTNKhrwDMpKd4nvk5g8
97dVrIJo8TW1Gfv+vi/JxnCvUOEXrOaUaMBHUXN4C92GZ3Ckk4FhdtFz+1ry0ncj
UnzT953jfTWE6ekrV/mMBo2S/rCc8gXM7c7JuUjIBtjFNrA/uQMq1BUKQ0MngFOR
NxkIJ4b0SsV2kLtlyZOf
=iF5C
-----END PGP SIGNATURE-----
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Mon, 19 Jan 2015 07:30:03 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.