Your message dated Thu, 27 May 2021 23:34:28 +0200
with message-id <[email protected]>
and subject line Re: Bug#989182: apt-listbugs fails to detect a fix an unpin
has caused the Debian Bug report #989182,
regarding apt-listbugs fails to detect a fix and unpin
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
989182: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989182
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: apt-listbugs
Version: 0.1.35
Severity: normal
Dear Maintainer,
* What led up to the situation?
Early this month apt-listbugs reported a significant error in
newer versions of exim4, bug 988086. I told it to hold the upgrade.
This pinned exim4-daemon-light, but upgraded a number of other exim
components. aptitude wanted to "upgrade" exim4-base, which
triggered dependency problems whose solution involved removing
exim. So I put a manual hold on exim4-base.
On May 15 a fix for the problem was released, marked as fixed in
4.94.2-4. I got no emails from apt-listbugs about the fix (I'm not
sure if it's supposed to send them, but some of the code looks like
that), and the preferences file pinning the package remained.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Today I saw the bug was fixed and directed aptitude to upgrade
exim4-base. This led again to conflicts and the solution of
uninstalling most exim4 packages and replacing them with
nullmailer.
I believe the cause was the fact that exim4-daemon-light was
still pinned, making my upgrade of exim4 base unable to pull in the
appropriate version.
In aptitude I manually selected the most recent version of
exim4-daemon-light and the upgrade was able to proceed.
During my debugging, described later, I seem to have triggered a
proper run of the cleaner that removed the pin.
* What was the outcome of this action?
exim4 is now fully upgraded to 4.94.2-5.
Before the debugging, apt-listbugs' pin entry remained in place.
aptitude did not want to downgrade to the pinned version. I'm not
sure if the pin would have prevented future upgrades.
* What outcome did you expect instead?
Naively, that when the bug was fixed the pin would be removed and
my packages upgraded.
On reflection, it seems unlikely apt-listbugs would undo the hold I
put on exim4-base manually. A more realistic expectation is that
apt-listbugs would remove the pin on exim4-daemon-light when the
fixed version became available and send me an email about it (or at
least generate a message in the logs).
* Further diagnostic and debugging info
Note results of trying to recreate the daily run with diagnostics at
the bottom. Apparently I did better than recreate it, since it
actually worked.
--------------- /etc/apt/preferences.d/apt-listbugs -------------------
Explanation: Pinned by apt-listbugs at 2021-05-05 10:57:20 -0700
Explanation: #988086: Exim delivery process crashes on each mail with
NULL-pointer
Package: exim4-daemon-light
Pin: version 4.94-17
Pin-Priority: 30000
-----------------------------------------------------------
Status of exim4 packages before the steps above:
un exim4 <none> <none> (no description available)
hi exim4-base 4.94-19 amd64 support files for all Exim
MTA (v4) packages
ii exim4-config 4.94.2-5 all configuration for the Exim
MTA (v4)
un exim4-config-2 <none> <none> (no description available)
un exim4-daemon-custom <none> <none> (no description available)
un exim4-daemon-heavy <none> <none> (no description available)
ii exim4-daemon-light 4.94-17 amd64 lightweight Exim MTA (v4)
daemon
un exim4-doc-html <none> <none> (no description available)
ii exim4-doc-info 4.94-2 all documentation for the Exim
MTA (v4) in info format
un exim4-localscanapi-4.1 <none> <none> (no description available)
un eximdoc4-info <none> <none> (no description available)
ii eximon4 4.94.2-5 amd64 monitor application for
the Exim MTA (v4) (X11 interface)
and after:
un exim4 <none> <none> (no description available)
ii exim4-base 4.94.2-5 amd64 support files for all Exim
MTA (v4) packages
ii exim4-config 4.94.2-5 all configuration for the Exim
MTA (v4)
un exim4-config-2 <none> <none> (no description available)
un exim4-daemon-custom <none> <none> (no description available)
un exim4-daemon-heavy <none> <none> (no description available)
ii exim4-daemon-light 4.94.2-5 amd64 lightweight Exim MTA (v4)
daemon
un exim4-doc-html <none> <none> (no description available)
ii exim4-doc-info 4.94-2 all documentation for the Exim
MTA (v4) in info format
un exim4-localscanapi-4.1 <none> <none> (no description available)
--------------------------------------------------------------------------------------------
root@debtest:~# date; journalctl -S 2021-05-25 -u apt-listbugs
Thu 27 May 2021 10:24:16 AM PDT
-- Journal begins at Mon 2021-04-26 16:32:26 PDT, ends at Thu 2021-05-27
10:23:55 PDT. --
May 25 11:31:20 debtest systemd[1]: Starting Daily apt-listbugs preferences
cleanup...
May 25 11:31:21 debtest systemd[1]: apt-listbugs.service: Succeeded.
May 25 11:31:21 debtest systemd[1]: Finished Daily apt-listbugs preferences
cleanup.
May 26 11:35:20 debtest systemd[1]: Starting Daily apt-listbugs preferences
cleanup...
May 26 11:35:22 debtest systemd[1]: apt-listbugs.service: Succeeded.
May 26 11:35:22 debtest systemd[1]: Finished Daily apt-listbugs preferences
cleanup.
May 27 10:01:20 debtest systemd[1]: Starting Daily apt-listbugs preferences
cleanup...
May 27 10:01:22 debtest systemd[1]: apt-listbugs.service: Succeeded.
May 27 10:01:22 debtest systemd[1]: Finished Daily apt-listbugs preferences
cleanup.
This is with my modification of the timer so it only runs daily.
----------------------------------------------------------------------
My first attempt to run the daily job didn't do much because it
detected the recent run. I manually changed the datestamp to get it
to fire.
root@debtest:~# # manually reset last run time
root@debtest:~# cat /var/spool/apt-listbugs/lastprefclean
20210526
root@debtest:~# date; sh -x /usr/libexec/apt-listbugs/prefclean
Thu 27 May 2021 10:34:00 AM PDT
+ test -d /run/systemd/system
+ test -x /usr/sbin/sendmail
+ dailyprefclean
+ myoutput=+ date +%Y%m%d -d now - 7 hours
+ today=20210527
+ lastrunfile=/var/spool/apt-listbugs/lastprefclean
+ cat /var/spool/apt-listbugs/lastprefclean
+ lastrunday=20210526
+ test 20210527 -le 20210526
+ prefclean
+ file=/etc/apt/preferences.d/apt-listbugs
+ backup=/var/backups/apt-listbugs.preferences
+ test -x /usr/libexec/apt-listbugs/aptcleanup
+ test -x /usr/bin/apt-listbugs
+ test -f /etc/apt/preferences.d/apt-listbugs
+ mktemp --tmpdir apt-listbugs_tmp_preferences.XXXXXX
+ tmp=/tmp/apt-listbugs_tmp_preferences.N3v2Ma
+ /usr/libexec/apt-listbugs/aptcleanup
+ diff -B /tmp/apt-listbugs_tmp_preferences.N3v2Ma
/etc/apt/preferences.d/apt-listbugs
+ /bin/rm -f /tmp/apt-listbugs_tmp_preferences.N3v2Ma
+ printf %s\n 20210527
+ test x+ date +%Y%m%d -d now - 7 hours
+ today=20210527
+ lastrunfile=/var/spool/apt-listbugs/lastprefclean
+ cat /var/spool/apt-listbugs/lastprefclean
+ lastrunday=20210526
+ test 20210527 -le 20210526
+ prefclean
+ file=/etc/apt/preferences.d/apt-listbugs
+ backup=/var/backups/apt-listbugs.preferences
+ test -x /usr/libexec/apt-listbugs/aptcleanup
+ test -x /usr/bin/apt-listbugs
+ test -f /etc/apt/preferences.d/apt-listbugs
+ mktemp --tmpdir apt-listbugs_tmp_preferences.XXXXXX
+ tmp=/tmp/apt-listbugs_tmp_preferences.N3v2Ma
+ /usr/libexec/apt-listbugs/aptcleanup
+ diff -B /tmp/apt-listbugs_tmp_preferences.N3v2Ma
/etc/apt/preferences.d/apt-listbugs
+ /bin/rm -f /tmp/apt-listbugs_tmp_preferences.N3v2Ma
+ printf %s\n 20210527 != x
+ hostname
+ myhost=debtest
+ /usr/sbin/sendmail -t -odi
Hmm, that actually seems to have done something; it sent this mail:
-----------------------------------------
Date: Thu, 27 May 2021 10:01:21 -0700
From: apt-listbugs timer <root@debtest>
To: [email protected]
Subject: prefclean output on debtest
/usr/libexec/apt-listbugs/prefclean:
Fixed packages : exim4-daemon-light
-----------------------------------------
And /etc/apt/preferences.d/apt-listbugs is now length 0.
-- System Information:
Debian Release: 11.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-6-amd64 (SMP w/3 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages apt-listbugs depends on:
ii apt 2.2.3
ii ruby 1:2.7+2
ii ruby-debian 0.3.10+b4
ii ruby-gettext 3.3.3-2
ii ruby-soap4r 2.0.5-5
ii ruby-unicode 0.4.4.4-1+b1
ii ruby-xmlparser 0.7.3-4
Versions of packages apt-listbugs recommends:
ii ruby-httpclient 2.8.3-2
Versions of packages apt-listbugs suggests:
ii konqueror [www-browser] 4:20.12.0-4
ii reportbug 7.10.3
ii sensible-utils 0.0.14
ii xdg-utils 1.1.3-4.1
-- no debconf information
-- debsums errors found:
debsums: changed file /lib/systemd/system/apt-listbugs.timer (from apt-listbugs
package)
--- End Message ---
--- Begin Message ---
On Thu, 27 May 2021 11:20:19 -0700 Ross Boylan wrote:
[...]
> Dear Maintainer,
Hello (again) Ross!
Thanks for your bug report.
>
> * What led up to the situation?
> Early this month apt-listbugs reported a significant error in
> newer versions of exim4, bug 988086. I told it to hold the upgrade.
I did the same on one of my boxes.
> This pinned exim4-daemon-light, but upgraded a number of other exim
> components. aptitude wanted to "upgrade" exim4-base, which
> triggered dependency problems whose solution involved removing
> exim. So I put a manual hold on exim4-base.
This looks strange.
Was it an "aptitude safe-upgrade" or an "aptitude full-upgrade"?
On my box, safe-upgrade is not touching any other exim4* package
(except for exim4-config) and does not see any dependency problem.
Just a dependency-related reason not to upgrade the other exim4*
packages!
>
> On May 15 a fix for the problem was released, marked as fixed in
> 4.94.2-4. I got no emails from apt-listbugs about the fix (I'm not
> sure if it's supposed to send them, but some of the code looks like
> that), and the preferences file pinning the package remained.
On May, the 15th the fixed package was [uploaded] to Debian unstable.
But you are tracking Debian testing, not Debian unstable.
Hence, on your system, you have to wait for a fixed package to migrate
to testing, before apt-listbugs can notice and remove the pin.
[uploaded]:
<https://tracker.debian.org/news/1241182/accepted-exim4-4942-4-source-into-unstable/>
>
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
> Today I saw the bug was fixed
On May, the 25th, a fixed package [migrated] to Debian testing.
[migrated]:
<https://tracker.debian.org/news/1241740/exim4-4942-5-migrated-to-testing/>
Then, it had to reach the mirror you are using (could even delay by one
more day or so). And you have to actually update the package indexes
("aptitude update"). At that point, the cleanup job can notice.
Provided it has a chance to run successfully, with a working Internet
link (it does so once a day, at most).
Reducing the check frequency to only one attempt a day does not help,
as discussed in bug #987839 ...
> and directed aptitude to upgrade
> exim4-base. This led again to conflicts and the solution of
> uninstalling most exim4 packages and replacing them with
> nullmailer.
Do you mean that you removed the hold on exim4-base, but not the pin on
exim4-daemon-light?
This should not allow the upgrade: either you also manually remove the
pin (by editing /etc/apt/preferences.d/apt-listbugs), or you wait for
the pin to be removed automatically by apt-listbugs cleanup job...
Usually, the second choice (waiting for the automatic cleanup) is the
recommended one.
>
> I believe the cause was the fact that exim4-daemon-light was
> still pinned, making my upgrade of exim4 base unable to pull in the
> appropriate version.
This is the most likely explanation, although, as I said, I cannot
understand why aptitude wants to upgrade the rest of exim4* packages,
without honoring the pin and the package relationships (dependencies,
conflicts, and so forth).
Unless you use "full-upgrade", I mean.
In that case, you are telling aptitude to try hard to find a way to
upgrade anything that's not directly pinned.
If this is the case, then no surprise it wants to remove any roadblock
it finds on its way to obey your command...
I recommend to use "safe-upgrade", especially when you have a pin on
some package.
>
> In aptitude I manually selected the most recent version of
> exim4-daemon-light and the upgrade was able to proceed.
Then you basically overrode the pin...
>
> During my debugging, described later, I seem to have triggered a
> proper run of the cleaner that removed the pin.
My guess is that the cleanup would have happened anyway, just a bit
later than you expected.
Please give it time (and re-enable the hourly check...).
>
> * What was the outcome of this action?
> exim4 is now fully upgraded to 4.94.2-5.
>
> Before the debugging, apt-listbugs' pin entry remained in place.
> aptitude did not want to downgrade to the pinned version. I'm not
> sure if the pin would have prevented future upgrades.
The pin should prevent upgrades (with "safe-upgrade"), as long as it is
in place.
>
> * What outcome did you expect instead?
> Naively, that when the bug was fixed the pin would be removed and
> my packages upgraded.
Only after all the events I explained above have had a chance to happen!
> On reflection, it seems unlikely apt-listbugs would undo the hold I
> put on exim4-base manually.
Well, apt-listbugs does not interfere with manual holds.
And I believe it should not interfere: if you manually hold a package,
you are saying "I do not want this package to be upgraded, no matter
what".
What the cleanup job does is to check which version would be installed
in the absence of the pin (the "unpinned candidate version").
If this version does not have the bugs that convinced the user to pin
the package (the "bugs the user fear"), then the pin is removed.
> A more realistic expectation is that
> apt-listbugs would remove the pin on exim4-daemon-light when the
> fixed version became available and send me an email about it (or at
> least generate a message in the logs).
[...]
See my explanations above: I think this would have happened, given
enough time.
I am closing this bug report, since there seems to be nothing to be
fixed in apt-listbugs.
Bye!
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpp0geGwGNRx.pgp
Description: PGP signature
--- End Message ---
