Wednesday 27 May 2020

Re: +1 maintenance report

On Wed, 27 May 2020 at 06:00, Dimitri John Ledkov <xnox@ubuntu.com> wrote:
On Tue, 26 May 2020 at 11:02, Michael Hudson-Doyle
<michael.hudson@canonical.com> wrote:
>
> Hi,
>
> I've spend today working on +1 maintenance (https://wiki.ubuntu.com/PlusOneMaintenanceTeam, https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Status).
>
> We have a few transitions ongoing (gsl, hdf5, perl, ...) which are showing signs of all getting entangled together.
>
> I re-uploaded haskell-hmatrix-gsl which had been uploaded too early (before gsl has been published on riscv64). It built fine.
>
> I found some more blockers for the gsl transition: https://people.canonical.com/~ubuntu-archive/transitions/html/html/auto-gsl.html. The cpl-* ones are semi-typical mysterious failures for a new port, probably down to bugs in our emulated builders. The ea-utils one is a bit of a mess though, in some ways: it should never have built in the first place! There is a package (pegjs) in focal and groovy release that Provides: nodejs. This means that things that transitively build-depend on nodejs don't end up in depwait like they should. There is a pegjs in groovy proposed that fixes this, I guess it needs to be forced to migrate and any binaries this makes uninstallable removed (it's not like packages which depend on nodejs and are erroneously installable are actually going to _work_).
>

That's a nice triange of nodejs / pegjs. Did you open an RM bug report
against pegjs, and subscribe ~ubuntu-archive to it, such that they can
process the binary-only removal on riscv64?

No because I wasn't sure what the best approach was. It would also be possible to force pegjs to migrate to release and remove things that become uninstallable on riscv as a result.
 
As documented at
https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing_Packages


> I fixed pbsuite's autopkgtest and sent a patch off to Debian, this has migrated and been applied to the Debian repo already.
>
> I looked at the pbcopper ftbfs on armhf and ppc64el. Debian has a report about the armhf failure and the packaging repo on salsa already has changes to disable the build on 32 bit architectures so I guess we should follow that. The ppc64el failure was strange and I spent probably too long coming to the conclusion that it's a bug in the "simde" header library Debian uses to compile the x86-intrinsic-using code on other architectures: https://github.com/nemequ/simde/issues/325. I've uploaded a workaround and sent it to Debian.
>
> I'm doing this again tomorrow, I expect I'll mostly keep on picking at proposed migration.

This is mostly what I've been doing. I don't remember exactly which packages I poked at, I'm afraid.

pbcopper got through new (it has a new library name) but its rdep pbbam ftbfs (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959643). There's a new upstream version, 1.0.7 which does build but it might be best to wait to see what Debian does before moving in Ubuntu. My pbbam package is in my PPA at https://launchpad.net/~mwhudson/+archive/ubuntu/devirt if someone wants to take it and upload it to the main archive (the other deps in this mini transition, pbseqlib and blasr, appear to build fine with this new pbbam).

One thing I did a lot of was retrying of things with all-proposed=1 on the end. I thought that autopkgtest was supposed to do that by itself when a test dependency wasn't installable? Did that regress somehow?

I spent quite a long time looking into the r-cran-lwgeom failures. Steve removed the upstream version that appears to have endianness issues (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961211) and patched it to build. But the autopkgtests still failed. I've cribbed a patch by looking at some upstream changes which passes locally but I think in general upgrading to the new upstream version would be a good idea.

Cheers,
mwh