[08:09] <Unit193> Seems the answer to my question earlier is LP 2078895
[08:09] -ubottu:#ubuntu-devel- Launchpad bug 2078895 in ubuntu-release-upgrader (Ubuntu) "Upgrade from 22.04 to 24.04.1 not offered anymore" [Undecided, Confirmed] https://launchpad.net/bugs/2078895
[08:24] <mitya57> Unit193: it looks like https://changelogs.ubuntu.com/meta-release-lts doesn't list 24.04.1 anymore
[08:24] <Unit193> Exactly.
[08:26] <dviererbe> ubuntu-qa: What could be the problem when an autopkgtest run against a PPA can not find the package, even though it is published (I tested in an lxc container that I can install that package from the PPA). Example: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy-dviererbe-dn9-preview7+amd64bootstrap-ppa2/jammy/amd64/d/dotnet9/20240905_081052_270ff@/log.gz
[10:05] <paride> dviererbe, hi, figured it out, it's https://bugs.launchpad.net/auto-package-testing/+bug/2076721
[10:05] -ubottu:#ubuntu-devel- Launchpad bug 2076721 in Auto Package Testing "Failure to source ppa with '++' in name" [Undecided, New]
[10:05] <paride> dviererbe, you have a single +, but it's the same bug
[10:06] <paride> dviererbe, and the issue is: PPA .list file is based on the repository (ppa) name, in your case autopkgtest-dviererbe-dn9-preview7+amd64bootstrap-ppa2.list
[10:06] <paride> dviererbe, and apt does not like that
[10:07] <paride> dviererbe, we
[10:08] <paride> dviererbe, we'll get to fix it properly, but for now as a workaround I suggest using a different ppa name
[10:15] <dviererbe> paride: thanks!
[14:14] <sergiodj> bdrung: hi, is DEB_BUILD_MAINT_OPTIONS=qa=-elfpackagemetadata still the recommended way to disable ELF packaging metadata?
[14:15] <bdrung> sergiodj, yes - and the only one that will work with all implementations.
[14:16] <bdrung> (including the final implementation once the upstream code changes land)
[14:16] <sergiodj> bdrung: ACK. I was unexporting ELF_PACKAGE_METADATA on d/rules so I will change it to use DEB_BUILD_MAINT_OPTIONS
[14:16] <sergiodj> thanks
[14:50] <ahasenack_> bdrung: hi, around? I don't see the lvm2 binaries in your verification at https://bugs.launchpad.net/ubuntu/+source/dracut/+bug/2065180/comments/66
[14:50] -ubottu:#ubuntu-devel- Launchpad bug 2065180 in miniramfs (Ubuntu Noble) "performance regression in dracut-install 060" [Undecided, New]
[14:51] <ahasenack_> I see you are grepping for lvm2, but it's not in the output
[14:53] <bdrung> ahasenack_, lvm2 was already verified in https://bugs.launchpad.net/ubuntu/+source/dracut/+bug/2065180/comments/58
[14:53] -ubottu:#ubuntu-devel- Launchpad bug 2065180 in miniramfs (Ubuntu Noble) "performance regression in dracut-install 060" [Undecided, New]
[14:53] <liushuyu> kanashiro: We will need to remove ruby-gsl from the archive to get ruby-defaults migrated, since gsl transition isn't even close to be finished
[14:53] <ahasenack_> bdrung: confirmed, thanks
[15:00] <kanashiro> liushuyu did someone remove it last time you mentioned this?
[15:00] <liushuyu> kanashiro: The package is still there, might be someone copied it back?
[15:01] <kanashiro> I mean we could ping the same person this time (?)
=== john-cabaj1 is now known as john-cabaj
[16:14] <rbasak> doko: have you seen bug 2070443?
[16:14] -ubottu:#ubuntu-devel- Bug 2070443 in mercurial (Ubuntu Noble) "SRU: Fix critical regression in Mercurial 6.7.x < 6.7.4" [High, Incomplete] https://launchpad.net/bugs/2070443
[16:43] <liushuyu> kanashiro: After some guidance from vorlon, I determined that Britney just don't know ruby-defaults can't be migrated on its own and also not with ruby-gsl. We might need some help from an AA to get ruby-sdbm and ruby-defaults migrated at the same time
=== mfo is now known as Guest9172
[18:21] <mitchdz> tjaalton: btw - got the multipath-tools dep8 fix in oracular-proposed, so we should be seeing green from now on :)
[18:22] <tjaalton> mitchdz: great :)
[18:32] <sergiodj> bdrung: it seems like the DEB_BUILD_MAINT_OPTIONS trick isn't working: https://launchpadlibrarian.net/747628850/buildlog_ubuntu-oracular-amd64.edk2_2024.05-1ubuntu1_BUILDING.txt.gz
[18:32] <sergiodj> I'll upload a fix using unexport for now
[18:32] <sergiodj> ahasenack_: ^
[18:33] <ahasenack_> ok
[19:50] <kanashiro> liushuyu which kind of help do we need? Is this migration done manually in some way?
[20:06] <liushuyu> kanashiro: No Britney currently can't migrate ruby-defaults because it does not know it should be migrated with ruby-sdbm
[20:06] <kanashiro> liushuyu and what should be done to guarantee that?
[20:25] <liushuyu> kanashiro: I don't know, maybe an AA is needed to override some Britney behaviors?
[20:29] <kanashiro> liushuyu I was asking because you talked to vorlon, I'd relay the info to cpaelzer to help us with that :)
[20:52] <liushuyu> kanashiro: Okay, I previously talked to vorlon about removing the package. It seems like that only prevented Britney from trying to migrate the package but not considering it
[21:44] <mfo> enr0n, hey Nick o/ We'd like to apply an upstream udev rule fix to systemd in Oracular and older (bug 2077779), thus wanted to check/coordinate with you.
[21:44] -ubottu:#ubuntu-devel- Bug 2077779 in systemd (Ubuntu Oracular) "PTP device symlink missing after running udevadm trigger command" [Undecided, In Progress] https://launchpad.net/bugs/2077779
[21:44] <mfo> While we have sponsors with upload rights to stable releases in SEG (would need help for Oracular anyway), we're aware src:systemd is maintained in its Vcs-Git, with a slightly different process than the traditional debdiff/source package uploads (i.e., MRs/commits/changelog entry format).
[21:45] <mfo> In that case, if you are OK with the change, how would you prefer us to move forward? Send MRs to ubuntu-core-dev:systemd in that style (to devel+stable releases), or the traditional upload would be fine in this case (for stable relesaes)?
[21:45] <mfo> Thanks!
[21:47] <enr0n> mfo: I can include it in my next oracular upload which should be tomorrow
[21:47] <enr0n> regarding other releases, how much of a priority is this?
[21:48] <enr0n> typically I like to batch several bugs into SRUs for systemd; doing an SRU just for one udev rule is not really worth it in my opinion
[21:48] <enr0n> so ideally I would stage the change in git now, but not upload until some other things come up
[21:49] <mfo> enr0n, re: Oracular, awesome, nice timing!
[21:49] <mfo> enr0n, for other stable releases: this is regular severity, not urgent nor critical, and can wait for the next batched updates.
[21:50] <mfo> enr0n, would you like us to send the MRs, or prefer staging it yourself?
[21:51] <enr0n> mfo: awesome. Since it's an upstream patch I will just stage it myself. I have a script to do that
[21:52] <mfo> enr0n, ok, cool. we'll just continue watching the bug.
[21:52] <mfo> enr0n, if you need any help, just let us know.
[21:52] <mfo> enr0n, thank you very much! o/
[21:57] <enr0n> mfo: no problem