In addition to the 3 packages mentioned here, there are 11-13 other R
packages that are broken only on less common architectures; these are
*not* blocking r-cran-testthat / r-base, but need to be dealt with (e.g.
by partial removal) at some point if we want to keep them on amd64.
https://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=r-pkg-team%40alioth-lists.debian.net&archive=no&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious
On 23/04/2025 03:25, Charles Plessy wrote:
Please let me know if there is a better way.
An approach I've often used in statsmodels is to ignore the test and
print a warning on import/use, on the affected architecture(s):
currently
https://sources.debian.org/src/statsmodels/0.14.4%2Bdfsg-1/debian/patches/xfail_i386_ets.patch/
, previously also #968210 and #924036 but those have since been fixed.
This has the advantages that we only have to upload the directly
affected packages, not upload their whole reverse dependency tree and
wait for a partial removal to be processed, and that users can continue
to use non-broken parts of the package, but the disadvantage that users
might not see the warning if e.g. they're using the package in a script
that runs headless.
I want to solve that once for all by removing all 32-bit and big-endian architectures from the r-cran-* packages in Trixie. I do not know a way that could be done without a mass update of all the packages,
If we are removing 32-bit packages, we still don't need to remove *all*
of them to solve this bug, just the broken 3 and their reverse
dependencies. My usual script says these are r-cran-marginaleffects, r-cran-seurat, r-cran-sf, r-cran-spdep (all arch:any), r-cran-devtools (arch:all), but it only checks build and runtime depends/recommends, not autopkgtest depends.
(There is a separate proposal to remove all 32-bit R packages (except
r-base + r-recommended) to reduce general maintenance burden, but during
the freeze might not be the time for that.)
but I still hope to do
so in a week or two.
Given that the next stage of the freeze is 15 May (i.e. upload before 5
May), and the risk that we don't get it right first time (or that it
ends up blocked by some unrelated bug in one of this large set of
packages), I'd also rather not need to wait that long.
Also, I worry that any upload risks to
delay the transition of r-base to Trixie.
If you're not sure what's allowed during the freeze, the place to ask is debian-release.
All the options we're considering involve uploading _something_ that
needs to migrate with or before r-base and hence reset the 10-day clock.
Anything that involves partial removals also needs permission to ignore
some arch:all packages (i.e. their reverse dependencies) becoming
uninstallable on 32-bit architectures. (By default, arch:all packages
are expected to be installable there,
https://salsa.debian.org/release-team/britney2/-/blob/master/etc/britney_nobreakall.conf?ref_type=heads#L30
)
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)