Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1064428: [Britney] does not migrate new arch:all packages after initial migration of same source
1 view
Skip to first unread message
Paul Gevers
Feb 22, 2024, 1:10:04 AM2/22/24
to
Hi Dalton,
Good to have this discussion. I'll add a few remarks on behavior in
Debian in this e-mail.
On 21-02-2024 23:50, Dalton Durst wrote:
> test-src migrated after its amd64 and i386 binaries appeared. It also
> has architecture-independent binaries that miraculously only showed up
> after migration was complete (maybe someone hinted through the package
> too early).
Well, if somebody hinted a package to testing that's supposed to have an
arch:all build, than they can keep the pieces ;) (or in other words, it
should be on their radar and they could deal with it). Not saying that
that's ok, but the hint is obviously wrong in that case.
> If the
> package were binNMU'd, though, britney would migrate everything
> including the arch:all package if it passed checks.
In Debian, binNMU-ing a arch:all package is known to not work. I don't
know if this bug is the reason why it doesn't work, but I've been taught
this when I joined the Release Team. I think I tried once by accident
(or ignorance) and the binNMU didn't work.
> This behavior
> instability might be undesirable.
But there _might_ be more infrastructure problems than britney2.
> The code which skips arch:all packages dates all the way back to
> britney2's original import[1], so it's not clear if it's still
> load-bearing.
In the old days, an arch:all package was never build on a buildd, but
uploaded by the uploader (together with the source). It's very possible
that that fact is related to the original intent.
> Should britney be given the ability to test arch:all packages in
> ExcuseFinder by removing the block of code? If not, should it at least
> give a REJECTED_CANNOT_DETERMINE_IF_PERMANENT output to help an archive
> admin figure out what's going on?
I am currently working an a change to britney2 that (based on
Package-List entries in the Sources) will prevent migration of sources
which build arch:all binaries. That will also work around bug #915948
(in dak) and fix bug #887060 (in britney2 for Sources build from
source.changes files). From our conversation on IRC I take it that that
wouldn't solve *your* case as you're using aptly and apparently that
builds the Sources (with or without a Package-List) from what's in the
archive so it would still run into this issue.
Paul
Good to have this discussion. I'll add a few remarks on behavior in
Debian in this e-mail.
On 21-02-2024 23:50, Dalton Durst wrote:
> test-src migrated after its amd64 and i386 binaries appeared. It also
> has architecture-independent binaries that miraculously only showed up
> after migration was complete (maybe someone hinted through the package
> too early).
Well, if somebody hinted a package to testing that's supposed to have an
arch:all build, than they can keep the pieces ;) (or in other words, it
should be on their radar and they could deal with it). Not saying that
that's ok, but the hint is obviously wrong in that case.
> If the
> package were binNMU'd, though, britney would migrate everything
> including the arch:all package if it passed checks.
In Debian, binNMU-ing a arch:all package is known to not work. I don't
know if this bug is the reason why it doesn't work, but I've been taught
this when I joined the Release Team. I think I tried once by accident
(or ignorance) and the binNMU didn't work.
> This behavior
> instability might be undesirable.
But there _might_ be more infrastructure problems than britney2.
> The code which skips arch:all packages dates all the way back to
> britney2's original import[1], so it's not clear if it's still
> load-bearing.
In the old days, an arch:all package was never build on a buildd, but
uploaded by the uploader (together with the source). It's very possible
that that fact is related to the original intent.
> Should britney be given the ability to test arch:all packages in
> ExcuseFinder by removing the block of code? If not, should it at least
> give a REJECTED_CANNOT_DETERMINE_IF_PERMANENT output to help an archive
> admin figure out what's going on?
I am currently working an a change to britney2 that (based on
Package-List entries in the Sources) will prevent migration of sources
which build arch:all binaries. That will also work around bug #915948
(in dak) and fix bug #887060 (in britney2 for Sources build from
source.changes files). From our conversation on IRC I take it that that
wouldn't solve *your* case as you're using aptly and apparently that
builds the Sources (with or without a Package-List) from what's in the
archive so it would still run into this issue.
Paul
0 new messages