Re: toulbar2: What will happen if testing migration takes longer than removal from testing
> Hi Thomas, >> Dear Andreas, >> >> Thanks for taking care of toulbar2. I did spend some time to try to go >> around this #920459 bug but even a postprocessing of the LaTeX output of >> doxygen (removing inclusion of the xcolor package that generates the >> LaTeX compilation issue) did not work (another bug popped up, that was >> apparently already met by other people using doxygen using the same >> TexLive update but I found no workaround). > I think doxygen is severly broken and just skipping refman.pdf (finally > users can read other format) the only safe solution to keep the package > in. I added several FIXMEs to get it back for Buster+1. My current (partial) understanding is that TexLive/LaTeX is broken (not doxygen): TeXlive provides the tabu LaTeX package (https://ctan.org/pkg/tabu) that doxygen uses but this tabu package does not work anymore in TeXlive (not only for doxygen, but for all tabu users). See #920621/#921272 saying that "upstream is working on it". Probably this will not be fast as the README.md of tabu on CTAN says: The original author of tabu appears out of contact, and tabu had not been updated for several years, finally becoming unusable in 2019 as updates to other packages mean some of its patched code did not work as intended. The package is not being actively maintained however any major required fixes may be reported to the https://github.com/tabu-fixed/tabu repository and volunteers there (currently members of the LATEX3 Team) will attempt to update the package with any fixes required. Getting rid of the PDF output as you suggest for eg. HTML is probably best. Thomas
Re: toulbar2: What will happen if testing migration takes longer than removal from testing
Sorry, missed the Reply-All as Andreas pointed out. See attached mail. Thomas --- Begin Message --- Hi Thomas, On Tue, Feb 19, 2019 at 11:15:13AM +0100, Thomas Schiex wrote: > Dear Andreas, > > Thanks for taking care of toulbar2. I did spend some time to try to go > around this #920459 bug but even a postprocessing of the LaTeX output of > doxygen (removing inclusion of the xcolor package that generates the > LaTeX compilation issue) did not work (another bug popped up, that was > apparently already met by other people using doxygen using the same > TexLive update but I found no workaround). I think doxygen is severly broken and just skipping refman.pdf (finally users can read other format) the only safe solution to keep the package in. I added several FIXMEs to get it back for Buster+1. > If there is anything I can do, please do not hesitate to ask for > support. I'm not sure I'll be able to quickly allocate time, but I at > least I would be happy to try. I do not think that there is anything to do now but hoping that the package will be kicked for no good reason. Kind regards Andreas. PS: Its better to write in public - at least CCing the bug would have made sense. Feel free to quote me. > Le 19/02/2019 à 08:46, Andreas Tille a écrit : > > 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 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 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 --- End Message ---
Re: toulbar2: What will happen if testing migration takes longer than removal from testing
On Tue, Feb 19, 2019 at 11:13:29AM +0100, Andreas Tille wrote: > On Tue, Feb 19, 2019 at 09:07:24AM +0100, Ondřej Surý wrote: > > 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. > > I've thought the same but despite the activity it is not reset (at least > not according to tracker[1] or the autoremovals query[2]). >... There are a few hours delay until the UDD autoremovals notice bug activity, and the rest is based on this information. Check again in the evening, and you should see the autoremoval of toulbar2 in 15 days. > Kind regards > >Andreas. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: toulbar2: What will happen if testing migration takes longer than removal from testing
On Tue, Feb 19, 2019 at 09:07:24AM +0100, Ondřej Surý wrote: > 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. I've thought the same but despite the activity it is not reset (at least not according to tracker[1] or the autoremovals query[2]). > But it might have changed since… or my memory is failing me. I think you are right but that has obviously changed (either due to freeze or in general). Kind regards Andreas. [1] https://tracker.debian.org/pkg/toulbar2 [2] https://udd.debian.org/cgi-bin/autoremovals.cgi > > On 19 Feb 2019, at 08:46, Andreas Tille 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 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 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 > > > > -- http://fam-tille.de
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 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 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 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 >
toulbar2: What will happen if testing migration takes longer than removal from testing
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 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 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
