+1 Maintenance Report

Sat Jul 2 00:39:38 UTC 2022

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