Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1111382 > unrolled thread

Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel Jérémy Lal <kapouer@melix.org> - 2022-07-29 19:40 +0200
    Bug#1016287: closed by Paul Gevers <elbrus@debian.org> (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel) Jérémy Lal <kapouer@melix.org> - 2022-07-29 22:30 +0200
      Bug#1016287: closed by Paul Gevers <elbrus@debian.org> (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel) Paul Gevers <elbrus@debian.org> - 2022-07-29 22:40 +0200
    Bug#1016287: closed by Paul Gevers <elbrus@debian.org> (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel) Yadd <yadd@debian.org> - 2022-07-30 16:10 +0200
      Bug#1016287: closed by Paul Gevers <elbrus@debian.org> (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel) Paul Gevers <elbrus@debian.org> - 2022-07-30 16:50 +0200
        Bug#1016287: closed by Paul Gevers <elbrus@debian.org> (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel) Yadd <yadd@debian.org> - 2022-07-30 18:30 +0200

#1111382 — Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel

Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: britney


Hi,

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.

The problem is that it happens when a package depends on a package
that is not available in a given architecture.

Specific example:

excuses:
Migration status for node-node-rest-client (3.1.1-1 to 3.1.1-2): Waiting for test results or another package, or too young (no action required now - check later)
Issues preventing migration:
∙ ∙ Too young, only 2 of 5 days old
Additional info:
∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/n/node-node-rest-client.html
∙ ∙ autopkgtest for node-node-rest-client/3.1.1-2: amd64: Pass, arm64: Pass, armel: Not a regression, armhf: Pass, i386: Pass, ppc64el: Pass, s390x: Pass
Not considered


Jérémy

[toc] | [next] | [standalone]

#1111417 — Bug#1016287: closed by Paul Gevers <elbrus@debian.org> (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel)

[Multipart message — attachments visible in raw view] — view raw

Le ven. 29 juil. 2022 à 22:00, Debian Bug Tracking System <
owner@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

[toc] | [prev] | [next] | [standalone]

#1111420 — Bug#1016287: closed by Paul Gevers <elbrus@debian.org> (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel)

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1111469 — Bug#1016287: closed by Paul Gevers <elbrus@debian.org> (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

[toc] | [prev] | [next] | [standalone]

#1111476 — Bug#1016287: closed by Paul Gevers <elbrus@debian.org> (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel)

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1111481 — Bug#1016287: closed by Paul Gevers <elbrus@debian.org> (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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web