=== sem2peie- is now known as sem2peie
=== sem2peie- is now known as sem2peie
=== cpaelzer_ is now known as cpaelzer
=== sem2peie- is now known as sem2peie
[12:42] <ahasenack> +1 maintenance: since the queue is clogged, I'm going after FTBFSs. Current one is git on s390x (https://launchpad.net/ubuntu/+source/git/1:2.38.1-1ubuntu1/+build/24633504)
[12:45] <kanashiro[m]> ahasenack: thanks, git FTBFS is making docker.io a FTBFS as well
[12:48] <ahasenack> and ubuntu-advantage-tools
[12:48] <ahasenack> so, the heat is on!
[13:02] <xypron> Hello, I am looking for a sponsor for LP #1997371
[13:02] -ubottu:#ubuntu-devel- Launchpad bug 1997371 in flash-kernel (Ubuntu) "[SRU] add Sipeed Lichee RV Dock and Microchip PolarFire-SoC Icicle Kit in Jammy" [Undecided, New] https://launchpad.net/bugs/1997371
[14:00] <ahasenack> kanashiro[m]: do you have a log to your failure related to git?
[14:00] <ahasenack> I got it once on amd64, but not anymore, and am still trying to spawn an s390x instance in canonistack
[14:00] <ahasenack> the ftbfs is happening on s390x according to launchpad
[14:00] <ahasenack> but canonistack is non-cooperative
[14:13] <kanashiro[m]> ahasenack: I did not reproduce the build failures locally, it failed only on s390x, in LP builders
[14:13] <ahasenack> but what's the log? You said it was docker.io?
[14:14] <kanashiro[m]> yes
[14:18] <ahasenack> <ahasenack> but what's the log? You said it was docker.io?
[14:18] <ahasenack> the log?
[14:30] <kanashiro[m]> ahasenack: sorry, it was a test failures because the binary is not available. The build is actually waiting for git in s390x: https://launchpad.net/ubuntu/+source/docker.io/20.10.21-0ubuntu1/+build/24843203
[14:33] <ahasenack> ok, same thing I saw
[14:35] <cpaelzer> lvoytek: thanks for combining https://launchpad.net/ubuntu/+source/libvirt/8.6.0-0ubuntu4 with my uploads
[14:36] <cpaelzer> lvoytek: do you want to drive the 3 K and 2 L SRUs from here or do you want me to do so?
[14:36] <cpaelzer> I've updated my bugs - they have good SRU descriptions already IMHO, so it should be easy
[14:40] <cjwatson> jbicha: that sbuild-launchpad-chroot issue should be fixed now
[15:00] <lvoytek> cpaelzer: I can drive the SRUs over the next few weeks, sure!
[15:00] <cpaelzer> lvoytek: oh, sorry I considered you busy after seeing no response and realizing your are in meeting with sally
[15:00] <cpaelzer> lvoytek: i've already MRs up :-/
[15:01] <cpaelzer> lvoytek: https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/433443 + https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/433444
[15:03] <lvoytek> cpaelzer: Ah thanks! The SRU mps look good to me at least in terms of my commit
[15:04] <cpaelzer> you can review them at any time that you get to
[15:04] <cpaelzer> lvoytek: and add a proper SRU statement to your bug
[15:04] <lvoytek> cpaelzer: Alright, will do
[15:04] <cpaelzer> lvoytek: if you end up happy with that over today I can tomorrow upload them to -unapproved
[15:05] <cpaelzer> lvoytek: the overall context might still have some more work for you though :-)
[15:05] <cpaelzer> just saw this
[15:05] <cpaelzer> lvoytek: https://launchpad.net/ubuntu/+source/libvirt/8.6.0-0ubuntu4
[15:05] <cpaelzer> that worked a bit back IIRC, so probably some other lunar changes made it break now
[15:06] <cpaelzer> we need to analyze and fix those
[15:07] <cpaelzer> hmm - libxlxml2domconfigtest - seems like something xen related broke on lunar arm builds
[15:07] <lvoytek> yeah interesting
[15:07] <cpaelzer> lvoytek: suggestion, you'll have a look as that is a great debugging case. Then let me know where you end before leaving to thanksgiving and I can continue as time permits
[15:08] <lvoytek> cpaelzer: sounds good, I'll get started on that
[15:10] <cpaelzer> lvoytek: it is the value for shadow_memkb in xen. So whatever happens, the tests generate a different value than expected (smaller)
[15:10] <cpaelzer> expected values are in ./tests/libxlxml2domconfigdata/...
[15:11] <cpaelzer> lvoytek: https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=2c992810854a15b41be920519ce83a4a328d5168
[15:11] <cpaelzer> lvoytek: https://gitlab.com/libvirt/libvirt/-/commit/72d4709ab901dd3699d342f15ca3aff9bffddf96
[15:11] -ubottu:#ubuntu-devel- Commit 72d4709 in libvirt/libvirt "tests: Fix libxlxml2domconfigtest with latest xen"
[15:12] <cpaelzer> lvoytek: sorry I'm in the flow :-)
[15:12] <cpaelzer> lvoytek: I'll throw 72d4709 on top, if it builds fine - otherwise you can have a look
[15:18] <cpaelzer> lvoytek: hopefully has all we need https://launchpad.net/ubuntu/+source/libvirt/8.6.0-0ubuntu5
[15:26] <cpaelzer> lvoytek: arm64 already built \o/
[15:27] <lvoytek> cpaelzer: Nice, thanks!
[20:46] <ahasenack> so I'm getting this build error:
[20:46] <ahasenack>  git : Depends: git-man (< 1:2.37.2-.) but 1:2.38.1-1ubuntu2 is to be installed
[20:46] <ahasenack> git comes from whatever image the builder is using
[20:46] <ahasenack> 2.38.1-1u2 is in proposed
[20:46] <ahasenack> for some reason, apt is refusing to upgrade the installed git
[20:46] <ahasenack> https://launchpadlibrarian.net/635412147/buildlog_ubuntu-lunar-s390x.ubuntu-advantage-tools_27.12~23.04.1_BUILDING.txt.gz
[20:47] <ahasenack> I'm suspiscious of that proposed pinning
[20:50]  * ahasenack checks the build-deps of u-a-t carefully
[20:50] <sergiodj> isn't it too soon to retrigger the build?  you've uploaded git one or two hours ago, maybe it needs more time to reach the archive?
[20:51] <sergiodj> (just thinking out loud here)
[20:51] <cjwatson> what installed git?
[20:51] <cjwatson> sorry, that was confusingly phrased.  I mean, "apt is refusing to upgrade the installed git" is a confusing statement to me because I would not expect git to be installed yet
[20:51] <ahasenack> I checked with apt-cache policy that the new build is visible in lunar-proposed
[20:52] <ahasenack> and it takes a long time, indeed. Between 1h and 2h after the build is done
[20:52] <cjwatson> rmadison seems to disagree at the moment so perhaps it was very recent
[20:52] <cjwatson> $ rmadison -s lunar,lunar-proposed git
[20:52] <cjwatson>  git | 1:2.37.2-1ubuntu1 | lunar          | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
[20:52] <cjwatson>  git | 1:2.38.1-1ubuntu1 | lunar-proposed | arm64, armhf, riscv64
[20:52] <cjwatson>  git | 1:2.38.1-1ubuntu2 | lunar-proposed | source, amd64, i386, ppc64el
[20:52] <cjwatson> no lunar-proposed/s390x
[20:52] <ahasenack> apt-cache sees it in proposed
[20:52] <ahasenack> ah, wait a sec, I did it on amd64
[20:52] <ahasenack> jiu9tu429thiH(#$U#(*@$!#()U$
[20:52] <cjwatson> important detail there :)
[20:52] <ahasenack> and I don't have the s390x vm anymore
[20:53] <ahasenack> I did see discepancies between rmadison and apt before, that's why I was trusting apt more
[20:53] <ahasenack> but I have to be in the right arch :/
[20:53] <sergiodj> heh.  just wait a couple more hours, I'd say
[20:53] <cjwatson> looks like it just finished publishing
[20:53] <cjwatson> retry now
[20:54] <ahasenack> I don't see s390x yet in rmadison
[20:54] <cjwatson> the only reason you'd see discrepancies between rmadison and apt is if the publishing run completed only very recently and so the dists mirror used by rmadison hasn't quite caught up yet (or, rarely, if the mirroring process is stuck)
[20:55] <cjwatson> this is the "only very recently" case, but I checked ftpmaster logs
[20:56] <ahasenack> ok, retrying
[20:58] <cjwatson> (rmadison shows it now)
[20:59]  * ahasenack crosses fingers
[21:09] <ahasenack> it built \o/
[21:09] <ahasenack> " s390x (Accepted)"
[21:09] <ahasenack> (u-a-t)
[21:12] <ahasenack> kanashiro[m]: I'll kick the s390x build of docker.io too for youk
[21:12] <ahasenack> I think LP eventually retries, but I don't know when or what triggers it, so I'm clicking the button :)
[21:18] <kanashiro[m]> ahasenack: thanks!
=== tuxifreund_ is now known as tuxifreund