=== chris14_ is now known as chris14 === chris14_ is now known as chris14 === haggertk_ is now known as haggertk [11:17] ubuntu-archive: hello! o [11:18] ugh, s/o/o [11:18] wow, it refuses to type the right thing [11:18] o/ [11:19] can someone look at xe-guest-utilities from the lunar queue and accept it (if all looks good)? [11:19] TIA! [12:15] cpaelzer: https://bugs.launchpad.net/ubuntu/+source/xe-guest-utilities/+bug/1923616 [12:15] -ubottu:#ubuntu-release- Launchpad bug 1923616 in xe-guest-utilities (Ubuntu) "Please remove rax-nova-agent and xe-guest-utils source and binaries from Hirsute" [Undecided, Fix Released] [12:21] cpaelzer: https://github.com/utkarsh2102/xe-guest-utilities [12:28] ok, independent [12:42] utkarsh2102: checked, sorry it took a while [12:42] that was pretty fast for me :) [12:42] thank you! [12:43] utkarsh2102: LGTM, but please could you push the branch you used to the VCS you refer to and import the missing versions so that it is up to date? [12:43] o/ [12:43] yes, will do in a bit or later! [12:47] sorry, should have been lunar - need to make up my mistake [12:47] just a sec [12:50] utkarsh2102: cleaned up, please re-upload the jammy version [12:50] utkarsh2102: correctly accepted lunar now as intended [12:52] done, thank you! [13:11] are autopkgtests queues stuck? [13:11] amd64 is scary... [13:38] seems so (clogged) [13:55] (deal.ii build didn't fail this time, lol!) [13:56] vorlon, maybe next time you merge deal.ii you might want to use parallel=1 on riscv64? [13:56] https://patches.ubuntu.com/d/deal.ii/deal.ii_9.4.0-1ubuntu4.patch [13:56] or maybe -g1 on riscv64 [14:00] * LocutusOfBorg nvm, it was syncd in the meanwhile [14:17] LocutusOfBorg: why parallel=1 on riscv64? then it would take 3.5 days to build instead of "only" 1.7 [16:17] vorlon: it looks like pkgconf has been approved for main by the MIR team, bug 1998095 . As part of promotion, did you want to ignore autopkgtest failures since new packages keep getting added to the pending list there? [16:17] -ubottu:#ubuntu-release- Bug 1998095 in pkgconf (Ubuntu) "[MIR] pkgconf, replacement for pkg-config" [Medium, In Progress] https://launchpad.net/bugs/1998095 [16:20] jbicha: 'in progress' is not the expected state for promotion, but 'Fix Committed'; waiting for the MIR team to click a button there. As for ignoring autopkgtest failures, I don't see anything particularly urgent about doing so; it should migrate on its own once the autopkgtest queues settle out (and I understand forward progress is being made on sorting the latest infra disaster) [16:25] bdmurray: crontab maintenance on cdimage-master led me to notice the fix for LP: #1990326 had been verified but the tags hadn't been set. I'm going to turn the cronjob back on but it would be good to get debian-installer released [16:25] -ubottu:#ubuntu-release- Launchpad bug 1990326 in debian-installer (Ubuntu Focal) "ubuntu server 20.04.5 cannot be installed after enable secure boot" [Critical, Fix Committed] https://launchpad.net/bugs/1990326 [16:28] sil2100: fwiw it appears you added jammy/stable and jammy/dangerous-stable core builds to etc/crontab last year but that these were never deployed to the running crontab... [16:28] (or if they were, they were deleted again at some point?) [16:35] vorlon, maybe we should ignore pkg-config autopkgtests failures? [16:38] failures of pkg-config autopkgtests against other packages? [16:40] vorlon: my only thinking with pkgconf urgency was Feature Freeze? [16:40] autopkgtest for pkg-config/unknown: amd64: Regression ♻ , arm64: Regression ♻ , armhf: Regression ♻ , i386: Regression ♻ , ppc64el: Regression ♻ , s390x: Regression ♻ [16:40] this one [16:40] jbicha: feature freeze doesn't block promotion of packages already in -proposed [16:40] and we've got loooots of those [16:41] LocutusOfBorg: ack, I only just realized that was pkg-config not pkgconf. Yes, will ignore but I'll wait until later to ignore [16:46] its now fix committed... [17:00] change-overrides is the first time I've realized we're replacing a shell implementation of pkg-config with a C implementation, oh joy [17:03] is it a good or a bad thing? [17:04] bad if you ask me [17:04] but there is a library now! [17:04] ... and who needs that [17:29] pkgconf! [17:30] and a symbols file. joy [17:33] symbols files are just good practice for sharedlibs. it's the sharedlib itself that's >_< here [17:37] vorlon: can i temp you to review bindgen in lunar and jammy new? it is a build of old bindgen, with it's deps vendored (since the archive has moved on), to enable building rust enabled kernels - https://launchpad.net/ubuntu/jammy/+queue?queue_state=0&queue_text=rust-bindgen https://launchpad.net/ubuntu/lunar/+queue?queue_state=0&queue_text=rust-bindgen [17:37] vorlon: I know that is true. doesn't stop them being a PITA on occasion [17:37] we already have the versioned rustc-1.62 which is the other piece that was needed here. [17:38] the packaging was reviewed by the debian-rust team with consesus being "it's not too bad" [17:38] but yes, when they are it is usually bad upstream with the shared lib [19:17] vorlon, muon-meson depends on the library! [19:17] muon is an implementation of the Meson build system in c99 with minimal [19:17] dependencies. [19:18] of course, do we need a c implementation of meson build system? :) [19:46] hahaha === chris15 is now known as chris14