Bug#926455: mail_autoremovals: incorrect version number in email warning

[Matthijs Kooijman <matthijs@stdin.nl>]

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 +0000
  From: Debian testing watch <noreply@release.debian.org>
  To: grfcodec@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 +0000
  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