Re: +1 maintenance report
On Tue, Aug 04, 2020 at 12:05:10PM +0100, Dimitri John Ledkov wrote: > On Tue, 4 Aug 2020 at 10:54, Michael Hudson-Doyle > wrote: > > Hi all, > > I noticed golang-gopkg-square-go-jose.v2 times out on armhf, filed > > https://github.com/square/go-jose/issues/326. > > Then I looked at the icu transition. > > 0ad fails to build due to gcc-10, I found the fix for this upstream and > > backported it. > > I retried some ucto builds which appeared to have run before a build > > dependency had been built (maybe fallout from the build farm outage). > > And retried "frog" builds when these completed. > > doxygen autopkgtests are failing because the json-c in proposed has > > moved its Doxyfile. > > multipath-tools has britney complaining about impossible depends -- > > turns out its udebs are still in main but its dependencies are now in > > universe. Apparently a bunch of udebs turned up on component mismatches > > and got demoted, but shouldn't have. They got repromoted again and if > > they appear on mismatches again someone should debug it :) (or mass > > demote all udebs to universe or stop building or at least publishing > > udebs or or ...) > I'm not sure. > kpartx-udeb & multipath-udeb themselves are up for demotion. Unless > the reports I'm looking at are old. So it shouldn't be a problem > Or as you say repromotion was incomplete. > Imho we should just demote all of udebs to the universe en masse. In general this is what we're doing, however this is driven by components-mismatches, and I'm also inspecting cases of source demotions to see whether these are Ubuntu-specific packages which should be removed as no longer used, instead of demoted. In the case of multipath-tools, the udebs are listed as candidates for demotion in the release pocket and NOT in the proposed pocket. This is why it wouldn't be an immediate obvious candidate for demotion. However I don't see anything that explains why it's being kept in main in -proposed, so I'm going to demote in both pockets and see if that gives us more information. -- 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
Launchpad builder VMs upgraded to bionic
The VMs in Launchpad's build farm have been on Ubuntu 16.04 (xenial) for some time. We're intentionally fairly conservative about upgrading the base VMs, but it's about time to have something newer, so we've just upgraded them to Ubuntu 18.04 (bionic). The actual builds still run in chroots or LXD containers of the appropriate Ubuntu series just as before, so most builds shouldn't notice any difference, but the kernel version is now 4.15 rather than 4.4. (As I type this, some VMs are still on xenial, but they'll be replaced with bionic once they're reset at the end of their next build.) The powerpc (as opposed to ppc64el) VMs are an exception to this: bionic doesn't include the powerpc architecture any more, so these will stay on xenial until such time as we no longer need to dispatch any powerpc builds and can decommission those builders entirely. Regards, -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- 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, 4 Aug 2020 at 10:54, Michael Hudson-Doyle wrote: > > Hi all, > > I noticed golang-gopkg-square-go-jose.v2 times out on armhf, filed > https://github.com/square/go-jose/issues/326. > > Then I looked at the icu transition. > > 0ad fails to build due to gcc-10, I found the fix for this upstream and > backported it. > > I retried some ucto builds which appeared to have run before a build > dependency had been built (maybe fallout from the build farm outage). And > retried "frog" builds when these completed. > > doxygen autopkgtests are failing because the json-c in proposed has moved its > Doxyfile. > > multipath-tools has britney complaining about impossible depends -- turns out > its udebs are still in main but its dependencies are now in universe. > Apparently a bunch of udebs turned up on component mismatches and got > demoted, but shouldn't have. They got repromoted again and if they appear on > mismatches again someone should debug it :) (or mass demote all udebs to > universe or stop building or at least publishing udebs or or ...) I'm not sure. kpartx-udeb & multipath-udeb themselves are up for demotion. Unless the reports I'm looking at are old. So it shouldn't be a problem Or as you say repromotion was incomplete. Imho we should just demote all of udebs to the universe en masse. > > I noticed that udisks2 was failing autopkgtests, found a bug about this, > found the bug had a comment to a potential fix upstream so I applied the > patch, tested locally and uploaded it. > > I tricked xnox into uploading s390-tools-signed, which should unstick > s390-tools. > > frr is failing autopkgtests, and has the most unhelpful autopkgtests I've > seen in a while (I have no idea what the tests are expressing). The package > has no rdeps and is the last thing keeping json-c in proposed so maybe > removal is appropriate for now. I filed a bug for this: > https://bugs.launchpad.net/ubuntu/+source/frr/+bug/1890259 > > libyang is failing to build on riscv64 because of symbols file differences in > libyang-cpp1. I don't understand how to fix this, other than by removing the > symbols file entirely. > > dee's tests are timing out on riscv64 :( > > libreoffice's tests seem to be very flaky on armhf. > > cmake-extras autopkgtest was failing, which I fixed and also submitted > upstream https://github.com/ubports/cmake-extras/pull/14 > > doxygen's tests fail with the json-c in proposed: it builds the documentation > for json-c in an autopkgtest but json-c has moved it's Doxyfile into a > different directory. Easy to fix once json-c has migrated. > > 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
+1 maintenance report
Hi all, I noticed golang-gopkg-square-go-jose.v2 times out on armhf, filed https://github.com/square/go-jose/issues/326. Then I looked at the icu transition. 0ad fails to build due to gcc-10, I found the fix for this upstream and backported it. I retried some ucto builds which appeared to have run before a build dependency had been built (maybe fallout from the build farm outage). And retried "frog" builds when these completed. doxygen autopkgtests are failing because the json-c in proposed has moved its Doxyfile. multipath-tools has britney complaining about impossible depends -- turns out its udebs are still in main but its dependencies are now in universe. Apparently a bunch of udebs turned up on component mismatches and got demoted, but shouldn't have. They got repromoted again and if they appear on mismatches again someone should debug it :) (or mass demote all udebs to universe or stop building or at least publishing udebs or or ...) I noticed that udisks2 was failing autopkgtests, found a bug about this, found the bug had a comment to a potential fix upstream so I applied the patch, tested locally and uploaded it. I tricked xnox into uploading s390-tools-signed, which should unstick s390-tools. frr is failing autopkgtests, and has the most unhelpful autopkgtests I've seen in a while (I have no idea what the tests are expressing). The package has no rdeps and is the last thing keeping json-c in proposed so maybe removal is appropriate for now. I filed a bug for this: https://bugs.launchpad.net/ubuntu/+source/frr/+bug/1890259 libyang is failing to build on riscv64 because of symbols file differences in libyang-cpp1. I don't understand how to fix this, other than by removing the symbols file entirely. dee's tests are timing out on riscv64 :( libreoffice's tests seem to be very flaky on armhf. cmake-extras autopkgtest was failing, which I fixed and also submitted upstream https://github.com/ubports/cmake-extras/pull/14 doxygen's tests fail with the json-c in proposed: it builds the documentation for json-c in an autopkgtest but json-c has moved it's Doxyfile into a different directory. Easy to fix once json-c has migrated. Cheers, mwh -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
