Bug#926455: mail_autoremovals: incorrect version number in email warning
Hi, On Mon, Aug 17, 2020 at 10:33:09AM +0200, Matthijs Kooijman wrote: > Looking at the mailer script [1], it seems it tracks the most recent autorm > email notification timestamp (to make sure to send out a notification only > every 20 days) for each package version separately. So this makes me suspect > that when a package migrates to testing that is subject to autorm: > > 1 the new version is first inserted into the `testing_autoremovals` table > 2 the mail_autoremovals.pl script runs, sees this new version for which no >notification was sent before, so immediately sends out a mail notification > 3 the autorm status is cleared for the package, because the fixing version > was >migrated to testing > > I'm not quite sure where all this is orchestrated, so I couldn't check this in > any code (other than the mail_autoremovals.pl code). Also, I can't remember > seeing this behaviour before for packages where autorm was cleared by an > upload, so I suspect that there might be a race condition between two > processes > here. > > Regardless, it seems that the new, fixing, version should *never* end up in > the > `testing_autoremovals` table, since that version is really never subject to > autorm AFAICS. So if my analysis is correct, maybe that's something that can > be > fixed? The main issue is that the 'affects_testing' field in the udd bugs table doesn't provide information about the version that was used to decide if the bug affects testing or not. When a new version migrates to testing, it can take some time for this information to be recalculated based on the new version. Until that is done, this information is wrong. The autoremoval info will be calculated based on that. The correct way to solve this would be to somehow include version information in the importer for bug information. To work around the mailing problem, I changes the autoremoval importer to reset the 'first_seen' timestamp when the version changes, and I changed the mail script to avoid sending mail on the first day. When a new version migrates, this should prevent a mail from being sent in the first 24 hours. By the time those are passed, the bug status and the autoremoval info should be up-to-date. Please let me know if this doesn't solve the mail issue. Thanks, Ivo
Bug#926455: mail_autoremovals: incorrect version number in email warning
Package: release.debian.org Followup-For: Bug #926455 Hi, I also ran into this today. To me, it seems the observable problem is not so much an incorrect version number in the email warning, but the fact that the email warning is sent out at pretty much exactly the moment the autorm for a package is *cleared*, which makes it a very confusing email. The version number in there is also wrong, or at least contains the version that fixed the bug that caused autorm, indeed. I noticed this for the grfcodec package: Date: Mon, 17 Aug 2020 04:39:06 + From: Debian testing watch To: grfco...@packages.debian.org Subject: grfcodec 6.0.6-5 MIGRATED to testing FYI: The status of the grfcodec source package in Debian's testing distribution has changed. Previous version: 6.0.6-4 Current version: 6.0.6-5 Date: Mon, 17 Aug 2020 04:39:05 + Subject: grfcodec is marked for autoremoval from testing grfcodec 6.0.6-5 is marked for autoremoval from testing on 2020-09-11 It is affected by these RC bugs: 957307: grfcodec: ftbfs with GCC-10 https://bugs.debian.org/957307 Looking at the mailer script [1], it seems it tracks the most recent autorm email notification timestamp (to make sure to send out a notification only every 20 days) for each package version separately. So this makes me suspect that when a package migrates to testing that is subject to autorm: 1 the new version is first inserted into the `testing_autoremovals` table 2 the mail_autoremovals.pl script runs, sees this new version for which no notification was sent before, so immediately sends out a mail notification 3 the autorm status is cleared for the package, because the fixing version was migrated to testing I'm not quite sure where all this is orchestrated, so I couldn't check this in any code (other than the mail_autoremovals.pl code). Also, I can't remember seeing this behaviour before for packages where autorm was cleared by an upload, so I suspect that there might be a race condition between two processes here. Regardless, it seems that the new, fixing, version should *never* end up in the `testing_autoremovals` table, since that version is really never subject to autorm AFAICS. So if my analysis is correct, maybe that's something that can be fixed? Gr. Matthijs [1]: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl
Bug#926455: mail_autoremovals: incorrect version number in email warning
Package: release.debian.org Severity: normal I received the following warning mail regarding an autoremoval: > Subject: duc is marked for autoremoval from testing > Date: Fri, 05 Apr 2019 04:39:19 + > > duc 1.4.3-6 is marked for autoremoval from testing on 2019-04-20 > > It is affected by these RC bugs: > 924473: duc: FTBFS (dh_installman: Cannot find "debian/build-nox/doc/duc.1") In fact, #924473 affected duc 1.4.3-5, and 1.4.3-6 contained the bug fix. (I got a separate, correct email for 1.4.3-5, earlier.) In terms of time frame, the wrong mail was received on 5th Apr, the fix was uploaded on 30 Mar and transitioned to testing on 5th Apr, it seems 6 seconds after this mail's Date header was generated: https://tracker.debian.org/news/1037367/duc-143-6-migrated-to-testing/ -- System Information: Debian Release: 9.7 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
