As William Wilson and Graham Inggs mentioned, there seems to be a higher
than usual amount of FTBFS compared with autopkgtest failures. There
doesn't seem to be a common pattern going on, just a lot of package
ecosystems in flux. Like them, I focused mostly on FTBFS issues, and a
little attention on the sponsoring queue.
(There are also a large number of NBS package issues currently, although
I didn't look at them. Several transitions like icu, libphobos2,
libpoppler118, and libqgis appear to be in process.)
### riscv64 ftbfs ###
Bunch of packages were failing to build on riscv64, but succeeded on
retry:
- rust-fd-find
- mathcomp-zify
- mathcomp-finmap
- mathcomp-bigenough
- mathcomp-algebra-tactics
- rust-xcb
- rust-idna
- rust-tokio-util
- libmseed
- gsequencer
gsequencer took a suprisingly long amount of time to rebuild (nearly a
full day), and I suspect its prior failure could easily have just been
hw/nw flakiness during such a long run.
### xnee / dia (libpoppler transition) ###
xnee (riscv64) was ftbfs due to missing build dependency on dia-common.
Dia was ftbfs due to needing updated for the new poppler API. I pulled
a patch from an upstream PR that fixed it:
https://gitlab.gnome.org/GNOME/dia/-/merge_requests/88
With dia successfully migrated, I rebuilt xnee for riscv64 and that also
succeeded and xnee appears like it should migrate over the weekend.
### pdf2djvu (libpoppler transition) ###
I sponsored Nathan Teodosio's fix for pdf2djvu to update pdf2djvu to the
new poppler API, similar to dia.
(LP: #1980518)
### debian-goodies (merge sponsorship) ###
Nathan Teodosio also had a merge proposed for debian-goodies, just
carrying a single bit of delta forward. I sponsored the upload.
(LP: #1979538)
### anacron (merge sponsorship) ###
Another merge uploaded for nteodosio. (LP: #1977739)
### mkosi ##
Succeeded on retrigger for ppc64el and migrated successfully.
I suspect it was just test flakiness on the hw.
### redis-py-cluster ###
Test failure resolved on retrigger, and migrated successfully.
### bibtool / texlive-base ###
texlive-base was blocked by test failure with bibtool. It passed
on retrigger however texlive-base is still bocked by
auto-multiple-choice and latexml which I didn't investigate.
### node-zx and node-core-js ###
node-core-js is missing node-zx as build dependency. node-zx FTBFS due
to a test case that is trying to access example.com. I disabled the
test case and enabled node-zx to build and migrate; node-core-js also
succeeded in its build at that point. I tried to flag the issue for
upstream (https://github.com/google/zx/issues/462), which they've closed
as fixed but I don't think they understood the issue.
### node-babel7 ###
This is failing its autopkgtest due to "RangeError: Invalid array
length". I filed update excuse LP: #1980411 for it, and filed a
corresponding bug with upstream. It affects Debian too but didn't spot
a patch or bug report there or upstream for it.
### libxcrypt, kopanocore and apache2 ###
Test failure for apache2 on s390x. The error shown in the log is:
<h1>Forbidden</h1>
<p>You don't have permission to access this resource.Reason: Cannot perform
Post-Handshake Authentication.<br /></p>
However, in my experience the autopkgtests around apache2 seem
especially flaky and resolve on a retrigger or two, and indeed the
retrigger has passed.
kopanocore also has a test failure blocking libxcrypt, but on amd64. It
also appears to be a service detection issue, and possibly also just
flaky so I retriggered it and it also passed.
libxcrypt also shows perl as blocking on autopkgtests on all arches.
I didn't invesgitate this one; it doesn't look like a flaky test, but
rather something with missing perl packages in the archive. I'm
guessing Perl is in a transition, and eventually the perl dependencies
will become available, at which point libxcrypt should complete its
migration.
### oscrypto and androguard ###
androguard's v3.4.0~a1-2 FTBFS is due to dependence on oscrypto, which
itself FTBFS due to an SSL 3 incompatibility. This is fixed upstream,
and there's a cherrypickable patch, but I think it might be preferable
to wait for upstream's 1.3.0 release to be included in Debian and let it
sync in.
I filed LP: #1980298 as update-excuse for tracking, and pinged Debian
about the solution to the FTBFS, since it affects them too.
### pygments / pytest ###
pygments is stuck in Dependency Wait due to it requiring pytest 7,
however we're on pytest 6, and moving to 7 seems like a bold jump, since
pytest is used by a couple thousand packages. I think pygments will
need to wait until pytest is ready to be transitioned. I filed
update-excuse LP: #1980296 to track.
### mkdocstrings / pymdown-extensions ###
The -proposed versions for mkdocstrings-python-handlers and
mkdocstrings-python-legacy are FTBFS due to requiring newer
mkdocstrings, however that package is ftbfs due to now requiring
pymdown-extensions, which is still in Debian's new queue by a few days.
Guessing this will resolve itself once Debian has processed the new
package, so we can wait for now and only consider taking action once
we're closer to FF. I have filed bug LP: #1980261 for tracking the
Debian bug and the update-excuses.
### hugin autopkgtest on i386 ###
hugin was deleted for jammy due to a (now fixed) gcc 11 issue (Deb:
#984049), and is reintroduced in kinetic-proposed. It does not build
for i386 (and didn't in impish either), but autopkgtest seems to expect
to run tests against it, and fails due to the obviously missing binary.
I'm not sure what the procedure is for addressing this. Does the
package's "Architecture: any" need tweaked, or something else...?
Maybe the deletion from jammy should be continued into kinetic?
### panicparse autopkgtest on i386 ###
Like hugin, panicparse also does not build i386 binaries but autopkgtest
tries to run i386 tests and fails. There seems to also be some golang
missing binary involved too. Also like hugin, this was deleted in jammy
(due to FTBFS Deb: #997589, apparently fixed now?) and is re-introducing
itself. I'm guessing however hugin is handled, panicparse will need the
same.
### lua-system / lua-mediator ###
There appears to be a circular dependency among several lua-* packages.
I attempted to soften the version requirement for lua-mediator on
lua-system in order to bypass the Missing Build Dependency issue,
however this merely enabled it to directly FTBFS.
I suspect the actual solution will need to be for an AA to delete
binaries and sources for lua-mediator and lua-system back to 1.1.2-0-3
and 0.2.1-2 respectively, and then introduce the intermediary versions
one by one. This is probably best to stage out in PPA first to prove
the sequencing works, before contacting AAs. I am out of +1 time for
the week so leave this to future +1'ers.
Once lua-system 0.2.1-3 is built, it should be possible to build
lua-mediator on top of that, and I'll bet that lua-say and lua-cliargs
will also be able to be rebuilt successfully and resolve those FTBFS as
well.
I'm not spotting other rdepends of lua-system that might be affected,
but it wouldn't surprise me if there are some other affected lua-* bits.
### juce autopkgtest on arm64###
This is failing tests just on arm64, with an error like:
Compiling include_juce_gui_basics.cpp
g++ ... -c "../../JuceLibraryCode/include_juce_gui_basics.cpp"
g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
The referenced file is #including a bunch of other code (see
https://sources.debian.org/src/juce/7.0.0~ds0-1/modules/juce_gui_basics/juce_gui_basics.cpp/),
and I wonder perhaps if it just hits a timeout? If so, perhaps upping
the allowed test runtime would resolve this?
I've run out of time to explore this but I think next steps would be to
verify its autopkgtests work fine locally (with no timeouts set), and
then consider setting it as long-test (I'd ask Brian Murray for help at
this point.)
Bryce
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
