Web lists-archives.com

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@xxxxxxxx> 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@xxxxxxxxxx>  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@xxxxxxxxxx>  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
>