Re: Help understanding the package set we need to maintain for partial i386
On Tue, May 26, 2020 at 09:44:37AM +0200, Christian Ehrhardt wrote: > > We will then also have to remove the rdma-core binaries on i386 in the > > release pocket. > Yes I've filed a removal bug for that. > => https://bugs.launchpad.net/ubuntu/+source/rdma-core/+bug/1880651 Not really needed fwiw; we don't usually require a launchpad bug paper trail for binary removals since those are always a matter of archive cleanup, and I have a script here that processes removals of any no-longer-whitelisted i386 binaries (which is what I've run now, and found a couple other binaries to be removed). > P.S. As for the former parts of this discussion I have put (my) new > insight into the i386 wiki page to help everyone else as well Thanks! -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Tue, 26 May 2020 at 11:02, Michael Hudson-Doyle 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
help required: golang-github-containers-image
Hi, Long time no see :-) I've been working on getting buildah, skopeo, podman into Debian, and finally those tools are available. Now I wanted to dust of my Ubuntu packaging skills and bring them over to ubuntu, and am encountering issues. I figure most of them are due to changes I wasn't able to pay as much attention as I wish I could, so please bear with me. I've had to patch golang-github-containers-image to add an additional build-dependency because of differences in the golang-github-docker-docker-dev package. In Debian, it provides significantly "heavier" dependencies so much more code is available. I've added the additional dependencies to the debian package, so on the next sync we should be able to drop the delta. The upload went through and the build passed, including the run of the test-suite. However, the package is stuck in the proposed migration because there the very same test-suite fails. I'm puzzled by this and haven't managed to reproduce this with an autopkgtest vm (I've tried following the instructions at https://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test but got different errors). Any chance someone could assist me with diagnosing what the issue is and what needs to be done to get golang-github-containers-image-dev migrated? - I'd love to proceed with getting golang-github-containers-buildah properly migrated so that what I described at http://tauware.blogspot.com/2020/04/building-packages-with-buildah-in-debian.html also works in ubuntu. Thanks and Best, -rt -- regards, Reinhard -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
+1 maintenance report
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_). 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
Re: Help understanding the package set we need to maintain for partial i386
On Mon, May 25, 2020 at 11:44 PM Steve Langasek wrote: > > On Mon, May 25, 2020 at 01:48:28PM +0200, Christian Ehrhardt wrote: > > Hi Steve (and all of Ubuntu-dev), > > so far things almost worked as expected :-) > > > The change for openmp [1] worked and migrated to groovy-release. > > The new dependency worked as well and germinate [2] now reports to no > > more pull in rdma-core on i386. > > But on the subsequent sync of rdma-core [3] I see i386 is still trying > > to be built. > > So I face the obvious "missing build on i386: ibacm, ..." [4] in > > update-excuses. > > > I wonder what to do now, is this another case not yet documented in [5]? > > Do I need to call for an archive admin to update the "effective > > whitelist" accordingly? > > Yes, that's exactly what needs to happen. The whitelist is not > automatically updated, it requires an archive admin to review any > autogenerated changes and commit them. > > I've rerun the script now, and rdma-core has dropped out of the whitelist. Thanks, I have uploaded a no-change rebuild and can confirm it picked this up now. > We will then also have to remove the rdma-core binaries on i386 in the > release pocket. Yes I've filed a removal bug for that. => https://bugs.launchpad.net/ubuntu/+source/rdma-core/+bug/1880651 P.S. As for the former parts of this discussion I have put (my) new insight into the i386 wiki page to help everyone else as well > > Thanks in advance, > > Christian > > > > [1]: https://launchpad.net/ubuntu/+source/openmpi/4.0.3-6ubuntu2 > > [2]: > > https://people.canonical.com/~ubuntu-archive/germinate-output/i386.groovy/i386+build-depends > > [3]: https://launchpad.net/ubuntu/+source/rdma-core/29.0-1 > > [4]: > > https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html > > [5]: https://wiki.ubuntu.com/i386 > > > > > > > But then I have realized that while there are not more runtime > > > > > dependencies, build dependencies in i386 seem to be quite a lot still > > > > > (reverse-depends --release=groovy --arch=i386 --build-dep > > > > > src:rdma-core shows 41). > > > > > > > > As far as I know these are all false-positives; I don't know that > > > > reverse-depends --build-dep --arch=foo ever does anything useful. > > > > Spot-checking the output, I see that most of these packages only have > > > > arch: > > > > all packages published on i386. > > > > > > > > > With this mail I'd look for: > > > > > a) general guidance on `is the effective i386 build = whitelist + > > > > > build-deps` > > > > > b) feedback on the suggestion to remove the rdma-core build dep on > > > > > openmpi; or would all 41 build-deps have to go away? > > > > > c) other alternatives > > > > > > > > > The answers to (a) we could add to the wiki [4]. > > > > > The answers to (b)+(c) will hopefully help me to go on with this, it > > > > > might eventually come down to keeping the current Delta (trivial) in > > > > > rdma-core, but along the way understanding the inner workings better > > > > > would be great. > > > > > > > > > > [1]: https://launchpad.net/ubuntu/+source/rdma-core/28.0-1ubuntu1 > > > > > [2]: > > > > > https://github.com/linux-rdma/rdma-core/pull/756#issuecomment-630138899 > > > > > [3]: > > > > > https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility/12598 > > > > > [4]: https://wiki.ubuntu.com/i386 > > > > > [5]: > > > > > https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/i386/tree/i386 > > > > > [6]: > > > > > https://people.canonical.com/~ubuntu-archive/germinate-output/i386.focal/i386+build-depends.sources > > > > > > > > -- > > > > Steve Langasek Give me a lever long enough and a Free > > > > OS > > > > Debian Developer to set it on, and I can move the > > > > world. > > > > Ubuntu Developer > > > > https://www.debian.org/ > > > > slanga...@ubuntu.com > > > > vor...@debian.org > > > > > > > > > > > > -- > > > Christian Ehrhardt > > > Staff Engineer, Ubuntu Server > > > Canonical Ltd > > > > > > > > -- > > Christian Ehrhardt > > Staff Engineer, Ubuntu Server > > Canonical Ltd > > > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developer https://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
