[11:24] <rbalint> @pilot
[11:24] <udevbot_> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[11:24] <rbalint> @pilot in
[11:26] <rbalint> hi all, i'm doing +1 maintenance today and tomorrow, feel free to ping me if you need quick help in moving proposed migration forward / uploading patches
[11:26] <rbalint> i start with revisiting http://reqorts.qa.ubuntu.com/reports/sponsoring/ for items targeting devel
[11:39] <cpaelzer> doko: LocutusOfBorg: I have finished libvirt 6.9 and uploaded it - since I track it anyway I'll retrigger builds for libsys-virt-perl and libguestfs later today
[11:39] <cpaelzer> that should further unblock perl
[11:39] <LocutusOfBorg> thanks
[11:40] <rbalint> plusone: sponsoring kbd
[11:42] <cpaelzer> rbalint: is that a new message style&place that was agreed on or just your own try to improve communication ?
[11:42] <rbalint> cpaelzer, i'm just trying it, how do you like it?
[11:43] <doko> well, up to now,, you don't see much ...
[11:43] <rbalint> cpaelzer, i just looked at the memo and i think we don't have an agreed call sign yet, but i added myself to piloting
[11:44] <cpaelzer> I like it
[11:44] <cpaelzer> I could easily add a highlight rule in +1 weeks and follow
[11:44] <cpaelzer> even across channels
[11:44] <cpaelzer> but I was the one pro-messaging - it is "the others" that need to like/adopt it
[11:45] <cpaelzer> rbalint: you could on the next +1 call share your lessons learned from it so that we can make (or not) it an official recommendation to do so
[11:45] <doko> @pilot in
[11:45] <doko> @pilot out
[11:45] <rbalint> cpaelzer, ok!
[11:46] <doko> so that's for patch piloting only?
[11:46] <rbalint> doko, yes, as i understand
[11:47] <cpaelzer> In my dream that would be used if you start to spend more than a few minutes on anything in proposed
[11:47] <cpaelzer> not enough for a update-excuse bug yet
[11:47] <rbalint> doko, in general i like the queue-based processing, but wanted to try that
[11:47] <doko> dream on
[11:47] <cpaelzer> hehe
[11:47] <cpaelzer> I'm a little dreamer, ...
[11:48] <doko> dreamer, but little? ;p
[11:48] <cpaelzer> context switch --- rbalint I'm looking at postgresql transition atm and have a question
[11:48] <cpaelzer> you once did https://launchpad.net/ubuntu/+source/gvmd/9.0.1-3ubuntu1
[11:48] <cpaelzer> did that ever go to Debian?
[11:48] <rbalint> cpaelzer, hm, let's see
[11:49] <cpaelzer> don't see MRs https://salsa.debian.org/pkg-security-team/gvmd/-/merge_requests nor bugs  https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=gvmd
[11:49] <cpaelzer> and it makes us miss https://tracker.debian.org/news/1182635/accepted-gvmd-901-41-source-into-unstable/
[11:49] <cpaelzer> which would fix an issue blocking the migration
[11:50] <cpaelzer> I'm ok to retest if we still need your fix, rebase and upload it - but long term a submission to Debian would be good so we can drop the delta later on
[11:53] <rbalint> cpaelzer, as I recall I did not forward it to Debian because it was fixed upstream, Debian does not have glibc 2.32 yet and it has popcon of 20
[11:54] <rbalint> cpaelzer, also salsa has 20.8.9-1
[12:05] <cpaelzer> ok, now I understand why it wasn't forwarded
[12:05] <cpaelzer> thanks rbalint
[12:05] <cpaelzer> and yes - 20.8.9-1 will then include it and can be a sync
[12:05] <cpaelzer> but we will need a rebase of your fix for the time being, I'll do that later
[12:06] <rbalint> cpaelzer, thanks!
[12:07] <cpaelzer> pgpool2 needs a custom trigger to use the new version which I'll do as well
[12:12] <rbalint> xnox, there are many oem mir items in the sponsorship queue, do you (or someone else) process those regularly?
[12:14] <cpaelzer> rbalint: IIRC that was usually done by Laney (at least the initial spike on oem-*), he might know who does it now
[12:16] <rbalint> cpaelzer, ok, i skip them for now
[12:16] <Laney> me or anybody really, it would be good for someone to help out with the sponsoring so it's not always me :-)
[12:17] <Laney> basically the debdiff to oem-qemu-meta which fourdollars usually attaches should be minimal/mostly name changes, then you can sponsor
[12:17] <Laney> trying to work with the DMB to get sponsors out of this process but it's moving a bit slowly I'm afraid
[12:18] <Laney> (sponsor to focal, these are LTS only)
[12:22] <rbalint> Laney, ok since they are targeting LTS imo we can skip those in +1
[12:22] <rbalint> at least in non-LTS cycles :-)
[12:23] <Laney> bah
[12:23] <Laney> that doesn't help me :p
[12:24] <rbalint> Laney, i see, i think there needs to be declared owners of sponsorship requests for stable releases and imo the natural people would be the ones on SRU rotation
[12:25] <Laney> it's ok, I'm just trying to avoid having to do it
[12:26] <Laney> but I will, hopefully all the debdiffs are good
[12:27] <rbalint> Laney, thanks!
[12:30] <rbalint> plusone ok, i've cleared many packages from the sponsoring queue
[12:31] <rbalint> plusone: afk for lunch
[13:05]  * rbalint is back
[14:09] <cpaelzer> doko: in regard to perl you mentioned that vim also gets a rebuild
[14:10] <cpaelzer> doko: I've seen risc jobs fail with "vim-tiny : Depends: vim-common (= 2:8.2.1913-1ubuntu1) but it is not going to be installed"
[14:10] <cpaelzer> doko: is vim known to currently be in flight due to those uploads you mentioned?
[14:11] <cpaelzer> oh ok, looking at https://launchpad.net/ubuntu/+source/vim/2:8.2.1913-1ubuntu1 explains
[14:12] <cpaelzer> doko: I have cleared all I could out of perls way that I could, libguestfs will resolve once vim dependencies work out avoiding  https://launchpadlibrarian.net/507673988/buildlog_ubuntu-hirsute-riscv64.libguestfs_1%3A1.42.0-11ubuntu2_BUILDING.txt.gz
[14:31] <doko> cpaelzer: yes, I hope vim is on bdmurray's todo list ...
[16:53] <rbalint> doko, is there a bug for cross-toolchain-base test failures on arm64?
[16:54] <rbalint> doko, i tried runing them on big test vms, but apparently that did not help
[17:02] <rbalint> doko, now we have one: LP: #1904760
[17:03] <rbalint> plusone hinting cross-toolchain-base for arm64
[17:26] <rbalint> plusone, bdmurray looking at vim
[17:48] <doko> rbalint: most likely https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97314 try building with -j 3 or -j 2
[17:49] <rbalint> plusone while waiting for vim to build i'm going through the perl regressions
[17:51] <rbalint> doko, thanks this looks like that, indeed, adding it to the bug
[18:31] <ItzSwirlz> hey uh, now that ca-certs are fixed, is mobile-tweaks-common needed to be fixed aswell?
[19:20] <tdaitx> Laney: openjdk-8, -13, -14, and -15 have been blocked in the past by triggering autopkgtests from reverse-deps, but ideally they shouldn't even trigger those, as they are basically satisfying alternative deps and openjdk-11 (source:openjdk-lts) already satisfies the direct deps, is there something that we could do to prevent it from happening without adding more custom policies into britney2/policies/autopkgtest.py (as gcc has)?
[19:22] <cpaelzer> doko: 3 successful runs with the older gcc already, might be ok to switch to the nex bisect step before I go to bed :-)
[19:23] <doko> cpaelzer: yes, I think that should be enough
[20:07] <tdaitx> Laney: I have opened bug 1903929 in case you prefer to discuss that directly there
[20:22] <rbalint> @pilot out
[21:31] <ItzSwirlz> Huh. My builds are failing: pinephone-tweaks conflicts with mobile-tweaks
[23:28] <ItzSwirlz> yikes. is mine the only one?