On Fri, Jul 01, 2022 at 03:25:39PM -0700, Bryce Harrington wrote: > 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.)
The tests weren't actually timing out so I tried testing it on a large instance in canonistack where it passed, so I then added it to big_packages and ran the test in production where it also passed. https://autopkgtest.ubuntu.com/packages/juce/kinetic/arm64 Cheers, -- Brian Murray -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
