Bug#1016287: closed by Paul Gevers (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel)
On 30/07/2022 16:45, Paul Gevers wrote: Control: reopen -1 Control: retitle -1 britney recursive installability test in autopkgtest Hi Yadd, On 30-07-2022 15:58, Yadd wrote: Node.js isn't available on armel, and the consequence will be to not fix some CVEs/BTS during freeze. Hope none of them will appear... For those we have unblock requests and the normal process to get packages into testing during the freeze. The autopkgtest process wasn't designed to change that. Maybe Britney could not consider autopkgtest as failing when a build dependency is missing in one arch (at least for arch=all) ? Why *build* dependencies? britney takes dependencies into account and doesn't schedule the jobs if all binaries are uninstallable. However, looking at your example, there might be an issue that it doesn't resolve that recursively during the policy phase of britney. (There's also a problem for britney that involves source packages that build both arch:all and arch:any binaries, which it fundamentally can't always resolve correctly, I thought we were in that case here). Let's see if I can come up with a reproducer in our test suite. Thanks! Most of node-* package build depends on nodejs but are usable without it. See libjs-bootstrap4 for example Again, what do build dependencies have to do with the problem? If they don't need nodejs to run, they shouldn't have a dependency on them and everything is fine. You'll recall that I recently stripped the unneeded nodejs dependency from all node-d3-* packages. Now they are installable on armel. Paul By "build dependencies", I meant "test dependencies" (Build-Depends contains often both). All JS test framework needs nodejs (mocha, jest, tape,...) and all node-d3-* autopkgtests will fail with armel. Cheers, Yadd
Processed: Re: Bug#1016287: closed by Paul Gevers (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel)
Processing control commands:
> reopen -1
Bug #1016287 {Done: Paul Gevers } [release.debian.org]
release.debian.org: autopkgtest 2 to 5 days since addition of armel
Bug reopened
Ignoring request to alter fixed versions of bug #1016287 to the same values
previously set
> retitle -1 britney recursive installability test in autopkgtest
Bug #1016287 [release.debian.org] release.debian.org: autopkgtest 2 to 5 days
since addition of armel
Changed Bug title to 'britney recursive installability test in autopkgtest'
from 'release.debian.org: autopkgtest 2 to 5 days since addition of armel'.
--
1016287: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016287
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1016287: closed by Paul Gevers (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel)
Control: reopen -1 Control: retitle -1 britney recursive installability test in autopkgtest Hi Yadd, On 30-07-2022 15:58, Yadd wrote: Node.js isn't available on armel, and the consequence will be to not fix some CVEs/BTS during freeze. Hope none of them will appear... For those we have unblock requests and the normal process to get packages into testing during the freeze. The autopkgtest process wasn't designed to change that. Maybe Britney could not consider autopkgtest as failing when a build dependency is missing in one arch (at least for arch=all) ? Why *build* dependencies? britney takes dependencies into account and doesn't schedule the jobs if all binaries are uninstallable. However, looking at your example, there might be an issue that it doesn't resolve that recursively during the policy phase of britney. (There's also a problem for britney that involves source packages that build both arch:all and arch:any binaries, which it fundamentally can't always resolve correctly, I thought we were in that case here). Let's see if I can come up with a reproducer in our test suite. Most of node-* package build depends on nodejs but are usable without it. See libjs-bootstrap4 for example Again, what do build dependencies have to do with the problem? If they don't need nodejs to run, they shouldn't have a dependency on them and everything is fine. You'll recall that I recently stripped the unneeded nodejs dependency from all node-d3-* packages. Now they are installable on armel. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1016287: closed by Paul Gevers (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel)
> Hi Jérémy, > > On 29-07-2022 19:36, Jérémy Lal wrote: > > when a package pass all autopkgtests it can migrate in 2 days, > > however if it depends on an architecture that reports "Not a > > regression", > > it seems that the bonus is lost and the package must wait 5 days. > > That's by design. > > > The problem is that it happens when a package depends on a package > > that is not available in a given architecture. > > Unfortunately, that's indeed the price of that design. As we're > supposed > to try and support all architectures equally well, I decided that's > acceptable. > > Paul [...] > Hi Jérémy. > > On 29-07-2022 22:17, Jérémy Lal wrote: > > I don't see how artificially adding migration days will improve > > debian quality in any way. > > We're not adding days, we're just not giving the bounty for success on > all architectures where we run autopkgtests, which was the rule for > the bounty. > > Paul Hi, this is not just a matter of bounty, but the key to upload during freeze. Node.js isn't available on armel, and the consequence will be to not fix some CVEs/BTS during freeze. Hope none of them will appear... Maybe Britney could not consider autopkgtest as failing when a build dependency is missing in one arch (at least for arch=all) ? Most of node-* package build depends on nodejs but are usable without it. See libjs-bootstrap4 for example
Bug#1016287: closed by Paul Gevers (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel)
Hi Jérémy. On 29-07-2022 22:17, Jérémy Lal wrote: I don't see how artificially adding migration days will improve debian quality in any way. We're not adding days, we're just not giving the bounty for success on all architectures where we run autopkgtests, which was the rule for the bounty. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1016287: closed by Paul Gevers (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel)
Le ven. 29 juil. 2022 à 22:00, Debian Bug Tracking System < ow...@bugs.debian.org> a écrit : > Hi Jérémy, > > On 29-07-2022 19:36, Jérémy Lal wrote: > > when a package pass all autopkgtests it can migrate in 2 days, > > however if it depends on an architecture that reports "Not a regression", > > it seems that the bonus is lost and the package must wait 5 days. > > That's by design. > > > The problem is that it happens when a package depends on a package > > that is not available in a given architecture. > > Unfortunately, that's indeed the price of that design. As we're supposed > to try and support all architectures equally well, I decided that's > acceptable. > > I don't see how artificially adding migration days will improve debian quality in any way. It will do exactly the opposite during freeze. Jérémy
