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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel