Many r-cran-* packages are arch:all but (test-)depend on other packages
that are only available on some architectures (usually, only the 64-bit
little-endian ones).  Hence, autopkgtests on other architectures fail as
uninstallable.

If an older version of the package is already in testing and fails on
the same architectures, this is ignored as a non-regression failure.
However, if the package is not currently in testing at all, then this
blocks migration.  According to a previous discussion (
https://lists.debian.org/debian-release/2025/01/msg00020.html ), the
preferred solution to this is to ask you to unblock them.

(Other possibilities would be to add Restriction: skip-not-installable
or Architecture: !armhf !i386 !s390x to these autopkgtests, but the
first would allow packages to go completely untested if their tests
accidentally became uninstallable everywhere, while the second is
another thing to change if the set of installable architectures changes.)

Hence, please allow these packages to migrate despite their i386 and/or
s390x autopkgtest failures:

(arch:all)
r-cran-animation/2.8+dfsg-1
r-cran-benchmarkme/1.0.8-2
r-cran-benchmarkmedata/2.0.0-1
r-cran-cubelyr/1.0.2-2
r-cran-dbplyr/2.5.2+dfsg-1
r-cran-dtplyr/1.3.3-1
r-cran-elliptic/1.5-1-2
r-cran-gargle/1.6.1-1
r-cran-gh/1.5.0-3
r-cran-httptest2/1.2.2+ds-1
r-cran-httr2/1.2.2-1
r-cran-labelled/2.16.0-1
r-cran-lgr/0.5.2+dfsg-1
r-cran-modeldata/1.5.1-1
r-cran-mumin/1.48.19-1
r-cran-prroc/1.4-1
r-cran-sjmisc/2.8.11-1
r-cran-skimr/2.2.2+dfsg-1

(arch:any)
r-cran-lobstr/1.2.1-1
r-cran-magick/2.9.1+dfsg-2
r-cran-svglite/2.2.2-2
r-cran-vdiffr/1.0.9-2
r-cran-webfakes/1.5.0-1

Hi,


Hint added for the arch:all packages. Doing that for the arch:<any>
packages won't work as these packages can't be installed on i386/s390x
as the autopkgtest shows. The migration software will block the
migration during the installability phase. For avoidance of doubt, I'll
added the hints anyways to show it.

Paul

Hi,


At least for the last log I checked this isn't true. It's just that the
migration software doesn't often retrigger failing tests for packages
that aren't already in new to avoid hammering the system with stuff that
broken for ages. I'll hit the retry button here and there.

Paul

It's also quite likely that the packages are installable on the affected
architectures but their test-Depends aren't: none of them list
installability problems on the excuses page itself (as opposed to the
autopkgtest failure logs), and the uninstallable test-dependency is
often r-cran-covr, a test coverage checker and hence probably not a
runtime Depends.

If they don't migrate soon, I'll investigate further.