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?

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

Reply via email to