Tuesday 26 May 2020

Re: +1 maintenance report

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?

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.
>
> Cheers,
> mwh
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

--
Regards,

Dimitri.

--
Regards,

Dimitri.

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel