On Fri, Jun 21, 2024 at 04:55:53PM -0600, Zixing Liu wrote:
> ### libxml-grddl-perl / libxml-libxslt-perl
> These require a no-change rebuild due to mismatching libxml sover.
> I can't do that since I am not a CoreDev.
But you know where some core-devs live ;)
There's also no reason in principle that you can't submit a changelog-only
MP to the sponsorship queue.
Can you provide further details here about what precisely is the reason for
a no-change rebuild, so that someone can pick this up?
I do see in the failure log the following:
253s # Warning: program compiled against libxml 212 using older 209
But I think that warning comes from libxml-libxslt-perl, not from the
packages under test? And I've seen this kind of nonsense before with
inappropriately strict checks of compile-vs-runtime versions of C libraries
from perl extensions (quite probably from this one in particular).
libxml2 | 2.9.14+dfsg-1.3ubuntu3 | oracular | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
libxml2 | 2.12.7+dfsg-3 | oracular-proposed | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
The issue is that libxml-libxslt-perl depends on libxml2 (>= 2.7.4), because
THE ABI HASN'T CHANGED; so I think libxml-libxslt-perl's runtime warning is
wrong and the correct solution here is a sourceful change to remove it.
> ### ypy
>
> This package requires the introduction of new Rust packages
> (`rust-yrs` and `rust-lib0`).
> Since Ubuntu does not maintain Rust micropackages, those need to be
> added through Debian.
Rather than leaving this in -proposed, I've added ypy to the
sync-blocklist's extra-removals file documenting its prerequisite, and
removed the unbuildable source.
> ### rust-imperative
>
> This package requires the introduction of new Rust packages (`rust-stemmers`).
> Since Ubuntu does not maintain Rust micropackages, those need to be
> added through Debian.
Idem
> ### tiledarray / btas
> Lies deep in the abyss, `tiledarray` seems to attract a lot of
> unwanted attention from countless people doing +1 shifts.
> My new findings are, `tiledarray` and `btas` need to be upgraded
> (probably needs to be done in Debian) so that they will build with new
> BLAS + LAPACK.
> The upstream for those two projects is still very much alive; they are
> just too shy to make new releases:
> https://github.com/ValeevGroup/BTAS.
> My recommendation is to remove those packages from the archive and
> re-introduce them once `btas` is upgraded in Debian.
The process for requesting removal of a source package from the archive is
to file a bug against the package and subscribe ~ubuntu-archive to it.
This should include a rationale for why it's correct to remove the current
package. It is unclear to me given the evidence available that btas needs
to be removed; it has failed to build from source on riscv64 in
oracular-proposed but dots would need to be connected showing that this is a
problem requiring an upgrade to a new upstream version for compatibility
with current BLAS + LAPACK, as opposed to some riscv64-specific issue.
> ### node-get-stream
> This package had the autopkgtest crash on ppc64el and s390x.
> Upon investigation, the crash was caused by Node.js Garbage Collector
> being unable to perform GC collections under memory pressure
> (translation: consumed too much memory and then went out of memory).
> This package blocked several Node.js micropackages.
> I am not entirely sure how to fix the issue, maybe we can add
> swapfiles in the autopkgtest runners? The tests in `node-get-stream`
> seem to require about 4 GiB of RAM.
big_packages in
https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-package-configs
declares a list of packages per arch whose tests require more than the usual
amount of memory (or cpu) to run. It may become obsolete once all runners
have fully moved over to PS6, but in the meantime I've added
node-get-stream/{ppc64el,s390x} to the list and re-triggered (and it
passed).
FWIW, if big_packages ever becomes insufficient for running tests on a
package like this, I'm -1 on introducing swapfile tricks to make them pass.
The value of per-arch test passes of an arch: all node package which eats
this much memory is marginal, and we should probably just hint it as a bad
test at that point.
> ### rust-secret-service
> This package requires `rust-zbus` package version to be 3.x, while we
> have 4.x in the archive.
> `rust-zbus` underwent a major API overhaul with the 3.x -> 4.x update,
> so patching it is not feasible.
> I don't know what to do with this situation, as upgrading the package
> to a newer version will have a snowball effect.
rust-secret-service is only in oracular-proposed and is not releasable in
its present version because it depends on a too-old version of another
crate. No snowball effect, this can just be removed. (This is a special
case where I don't need a bug report against the package before removing it
- done now.)
> ### ruby-rackup / ruby-rack-session
> Those require `ruby-rack` v3. This version was removed from Ubuntu
> (also only in Debian experimental).
> My recommendation is to remove those packages from the archive and
> reintroduce them once the `ruby-rack` v3 transition is completely
> finished.
The main issue with this is that we have no way to track when such packages
should be re-added.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
