Re: toulbar2: What will happen if testing migration takes longer than removal from testing
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 <andreas@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 <bunk@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 <tille@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
>
Reply to: