On Wed, 27 May 2020 at 06:00, Dimitri John Ledkov <x...@ubuntu.com> wrote:

> On Tue, 26 May 2020 at 11:02, Michael Hudson-Doyle
> <michael.hud...@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
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Reply via email to