Need advice on raku-* package mess

[Dominique Dumont]

Hi

We've requested removal of raku-* packages from ARMs arches on the assumption
that moarvm build was not reliable on arm arches.

Currently, these packages are removed from unstable, but not yet from testing
because of dependencies knots that prevent migration.

Turn out that moarvm builds fine on ARM once moarvm was patched [1]. Timo got
confused with the build daemon reports before and after patch.

So, since raku-* packages are *not* removed from testing, can we re-upload all
raku package in unstable with Architecture: any ?

In theory, all packages should build fine on all arches and migration should go
through.

Last but not least, we're sorry for the mess and the extra work we've imposed
on release team.

All the best

[1] https://salsa.debian.org/perl6-team/moarvm/-/blob/debian/sid/debian/
patches/0006-Make-accesses-to-spesh-arg-guard-atomic.patch?ref_type=heads

[Paul Gevers]

Hi Dominique

Post by Dominique Dumont
We've requested removal of raku-* packages from ARMs arches on the assumption
that moarvm build was not reliable on arm arches.

There are arch:all binaries involved, and the migration software doesn't
allow packages on amd64 and arm64 that are currently installable to
become non-installable without the Release Team overriding that.

Post by Dominique Dumont
Currently, these packages are removed from unstable, but not yet from testing
because of dependencies knots that prevent migration.

And without the help of the Release Team, it will just not migrate.

Post by Dominique Dumont
So, since raku-* packages are *not* removed from testing, can we re-upload all
raku package in unstable with Architecture: any ?

I don't think it matters if they are or are not removed from testing,
unless you need bootstrapping. And in the latter case it doesn't help
that there are binaries in testing.

And did you update the Architecture field for all packages? That must
have been a PITA. Please note that keeping a list of supported
architectures in the Architecture field is not really recommended
anymore, see
https://salsa.debian.org/debian/developers-reference/-/merge_requests/60/diffs
and the bug the comment links too. So if you don't need bootstrapping
you should be fine with fixing the Architecture field again.

Post by Dominique Dumont
Last but not least, we're sorry for the mess and the extra work we've imposed
on release team.

Before you sent this mail, it wasn't on my radar, so it's not yet a hell
of a lot of "extra work". ;)

Paul

[Dominique Dumont]

Post by Paul Gevers
There are arch:all binaries involved, and the migration software doesn't
allow packages on amd64 and arm64 that are currently installable to
become non-installable without the Release Team overriding that.

Which explains this message seen on raku-zef package tracker:

Issues preventing migration:
∙ ∙ removing raku-zef/0.13.8-1/arm64 from testing makes raku/6.d.7/arm64 uninstallable

The latter is arch all.

Post by Paul Gevers
And without the help of the Release Team, it will just not migrate.

Given our 180° turn, it's a good that that migration is blocked ;-)

Post by Paul Gevers

Post by Dominique Dumont
So, since raku-* packages are *not* removed from testing, can we re-upload
all raku package in unstable with Architecture: any ?

I don't think it matters if they are or are not removed from testing,
unless you need bootstrapping. And in the latter case it doesn't help
that there are binaries in testing.

We should be good to go: I've taken care of avoiding build-dependency loops.

Post by Paul Gevers
And did you update the Architecture field for all packages? That must
have been a PITA.

Not that much as I've used cme.

First I've created a local cme script:

$ cat ~/.cme/scripts/rm-arm-arch
app: dpkg-control
load: binary:~".*" Architecture="amd64 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x x32 loong64"
commit: Remove all arm architectures

This script makes and commit the modification on all binary packages in a debian/control file.

Then I've run this script with a loop:

$ for i in raku-* ; do echo $i; (cd $i ; cme run rm-arm-arch); done

This was still awkward, so I've added a --foreach option to cme . This new version of cme will land soon in experimental. For more details, please see:
https://github.com/dod38fr/config-model/wiki/Managing-Debian-packages-with-cme#run-script-many-times

Post by Paul Gevers
Please note that keeping a list of supported
architectures in the Architecture field is not really recommended
anymore, see
https://salsa.debian.org/debian/developers-reference/-/merge_requests/60/diffs
and the bug the comment links too. So if you don't need bootstrapping
you should be fine with fixing the Architecture field again.

Good to know.

Now, I need to update dpkg model of cme to support this "bolted-on" feature...

Thanks for the quick reply.

All the best

[Charles Plessy]

Thanks Dominique for writing CME
and thanks Paul for the explanations,

on my side I have added a --64 option to the `routine-update` script (from the
same-named package) that adds a build-dependency on architecture-is-64-bits,
and plan to do the same for little-endian architectures.

I wrote recently that I plan to restrict all the team-maintained r-cran-*
packages to 64-bit, little-endian. I have delayed that because of worries of
delaying migration of some packages with a mass upload, but...

I would like to ask you "what about the architecture-independant packages"?
They will be built on amd64 and be available for the excluded architectures.
Is there a risk that a mixed dependency chain of architecture-specific and
architecture-independant packages which are all already in Trixie but will
disappear from some architectures in Sid will create a mess and therefore be
not able to migrate?

Have a nice day,

Charles

[Simon McVittie]

Post by Charles Plessy
on my side I have added a --64 option to the `routine-update` script (from the
same-named package) that adds a build-dependency on architecture-is-64-bits,
and plan to do the same for little-endian architectures.

This seems like a sufficiently common situation to encounter that the
ability to automate it is a useful thing, so thank you for doing this.

Post by Charles Plessy
I wrote recently that I plan to restrict all the team-maintained r-cran-*
packages to 64-bit, little-endian. I have delayed that because of worries of
delaying migration of some packages with a mass upload, but...

Please note that we are about halfway through the soft freeze period for
trixie (2025-04-15 to 2024-05-15), and the release team writes:

new transitions, new versions of packages that are part of
(build-)essential or large/disruptive changes remain inappropriate
— https://release.debian.org/testing/freeze_policy.html#soft

I see from https://bugs.debian.org/release-critical/other/testing.html
that some of the r-bioc-* and r-cran-* family have been unable to
migrate to testing. How many of those bugs would be resolved by removing
their relevant packages from 32-bit and BE architectures, and how many
are orthogonal?

I am not a release team member, but I suspect that if removals are
necessary, at the current stage in the release process the release team
would likely prefer the R/CRAN team to remove only the packages that
genuinely do not work on 32-bit or BE, plus any packages that depend on
them and would be broken by their removal. For other removals that are not
necessary to resolve RC bugs, if it was up to me, I would defer them
until forky opens. (It is not up to me.)

I see that on #1099927, Rebecca already said some very similar things
about targeted removals being lower-risk and more appropriate at this
stage of the release process.

The usual way to research "what would happen if I removed..." is to log
in to the developer-accessible archive mirror machine
(coccia.debian.org, aka mirror.ftp-master.debian.org) and run commands
like for example:

# Architecture: all
dak rm -R -n r-cran-survminer

# Architecture: any
dak rm -R -n r-cran-sparr

At the time of writing, the results of those are that r-cran-survminer
could be removed without breaking anything else (it's a leaf package)
but r-cran-sparr could not be removed unless/until r-cran-kernelheaping was
also removed.

For your convenience, the r-bioc-* and r-cran-* RC bugs currently
relevant to testing:

* #1103217: FTBFS with newer compilers, fixed in sid, just needs migration
* #1103198: FTBFS with newer compilers, fixed in sid, just needs migration
* #1103227: FTBFS with newer compilers, fixed in sid, just needs migration
* #1103199: FTBFS with newer compilers, fixed in sid, just needs migration
* #1103200: FTBFS with newer compilers, fixed in sid, just needs migration
* #1102189: r-cran-argparser, autopkgtest regressions including 64-bit LE
* #1102589: r-cran-broom.helpers, see below, 32-bit autopkgtest already ignored
* #1102590: r-cran-fansi, see below
* #1100292: r-cran-fastcluster, build-time regressions including 64-bit LE
* #1104158: r-cran-testthat, is this fixed in 3.2.3-1?
* #1104159: r-cran-testthat, is this fixed in 3.2.3-1?
* #1104160: r-cran-testthat, seems i386 specific
* #1099927: r-cran-testthat, already has some useful analysis from Rebecca
* #1103228: FTBFS with newer compilers, fixed in sid, just needs migration
* #1102956: FTBFS with newer compilers, fixed in sid, just needs migration
* #1102345: seems fixed in sid, just needs migration
* #1103369: r-cran-webgestaltr, could be armhf specific
* #1102591: r-cran-units, seems arm{el,hf}-specific

#1104160 seems i386-specific and therefore could be helped by targeted
32-bit removals.

In #1102591 r-cran-units migration is blocked by autopkgtest regressions
on arm{el,hf}. At first glance this seems arm{el,hf}-specific and
therefore could be helped by targeted 32-bit removals.

#1103369 seems possibly armhf-specific and therefore could be helped by
targeted 32-bit removals, but I would suggest that a maintainer should
see whether the FTBFS is reproducible on 64-bit LE first (it doesn't
seem particularly 32-bit-specific).

In #1099927 in r-cran-testthat, migration is blocked by autopkgtest
regressions on 32-bit architectures (for which architecture-specific
removals might help) but also by an autopkgtest regression on riscv64
(which is 64-bit LE, so will be unaffected by your proposed removals).

#1104158 in r-cran-testthat refers to autopkgtest regressions. It seems
some of those might be fixed in 3.2.3-1? If this is the case, please
close the bug as fixed in the version in which it is fixed, so that the
release team can have some visibility into what it will take to get this
fixed in testing. Migration of r-cran-testthat/3.2.3-1 is blocked by
#1099927.

#1104159 in r-cran-testthat is similar to #1104158.

r-cran-broom.helpers #1102589 is blocked by #1102511 in r-cran-cards
(which would also require a freeze exception to get a new package into
trixie after the soft freeze deadline). It could be addressed by
removing r-cran-cards from i386, but it could also be addressed by
skipping one test using the patch that was already provided by Adrian
Bunk, which seems like a lower-risk change. Or r-cran-broom.helpers
could be rolled back to 1.20.0+really1.14.0 to avoid needing
r-cran-cards.

r-cran-fansi #1102590 seems to be failing all of its autopkgtests in
trixie on all architectures. Maybe one or more of its dependencies needs
to be raised to a higher version? Or maybe it should be rolled back to
1.0.6+really1.0.5 as a lower risk change at this stage. I don't see how
architecture-specific removals would help here.

#1102189, #1100292 seem like they would be a problem even if only amd64
was supported, so architecture-specific removals seem unlikely to help
here.

Post by Charles Plessy
I would like to ask you "what about the architecture-independant packages"?
They will be built on amd64 and be available for the excluded architectures.
Is there a risk that a mixed dependency chain of architecture-specific and
architecture-independant packages which are all already in Trixie but will
disappear from some architectures in Sid will create a mess and therefore be
not able to migrate?

I would have expected that the R/CRAN team will know better than anyone
else how frequent this situation is, and therefore be able to assess the
risk more accurately than anyone else.

If you have this dependency chain:

r-cran-archall -> r-cran-archany -> other dependencies

then I believe the rule is that for either r-cran-archall or
r-cran-archany to be allowed to migrate, the installability of
r-cran-archall must not regress on amd64 or arm64. (Reference:
NOBREAKALL_ARCHES in https://release.debian.org/britney/britney.conf)

But if you have

larger-archany-package -> r-cran-archany -> ...

or

larger-archany-package -> r-cran-archall -> r-cran-archany -> ...

then larger-archany-package would need to be removed from the affected
architectures too, otherwise its installability would regress on the
affected architectures, which the migration scripts generally don't allow.

smcv
(not a release team member)