Hi, I believe that it was the case before that if the autoremoval was due a specific RC bug, any activity on that specific bug would reset the timer for autoremoval.
But it might have changed since… or my memory is failing me. Cheers, Ondrej > On 19 Feb 2019, at 08:46, Andreas Tille <andr...@an3as.eu> wrote: > > Hi, > > toulbar2 is > > Marked for autoremoval on 22 February: #916715 > > However, this bug was closed in > > > toulbar2 (1.0.0+dfsg3-1.1) unstable; urgency=medium > > * Non-maintainer upload. > * Add the missing build dependency on zlib1g-dev. (Closes: #916715) > > -- Adrian Bunk <b...@debian.org> Fri, 11 Jan 2019 13:47:51 +0200 > > > The problem is that the package did not migrated due to #920459 (doxygen > currently breaks lots of packages and I wonder in general what will > happen with those packages). I now uploaded > > > toulbar2 (1.0.0+dfsg3-2) unstable; urgency=medium > ... > * Prevent generation of PDF documentation since otherwise toulbar2 does > not build (see bug #920459). This means should be reverted once doxygen > is fixed. > ... > -- Andreas Tille <ti...@debian.org> Mon, 18 Feb 2019 22:17:10 +0100 > > > Which enabled the build on all release architectures. > > I'm simply wondering what will happen with toulbar2 (and other packages > - I'm actually not that much involved in this, it is just a random > Debian Science package) once it was removed from testing. As far as I > understood there will be no migrations from unstable to testing any more > if there is no version of that package in testing. Does that mean that > the doxygen issues will kick several packages out of Buster or is there > any way to prevent this? > > Kind regards > > Andreas. > > -- > http://fam-tille.de >