[09:55] <bdrung> dbungert, subiquity could ship the apport hook by itself, but currently apport does not support snap shipping those hooks.
[10:36] <seb128> ginggs, hey, could you give a retry to dee , gnome-keyring and udisks2 in the lunar archive rebuild?
[10:50] <ginggs> seb128: .
[10:50] <seb128> ginggs, thanks!
[12:27] <ahasenack> rbasak: do you happen to know if it's possible to git cherry-pick just a specifig file change from a commit?
[12:28] <ahasenack> specific*
[12:28] <ahasenack> like (made up) git cherry-pick <commit> -- debian/kdc.conf
[12:28] <ahasenack> (which didn't work)
[12:32] <rbasak> ahasenack: you could use -n, "git reset" everything, then "git add" just that file.
[12:32] <rbasak> Or do "git checkout <commit> -- debian/kdc.conf" and then commit that?
[12:33] <ahasenack> ah, good alternatives
[12:33] <rbasak> But yeah, I don't know of a more specific way
[12:33] <rbasak> The second way there assumes that the file hasn't changed
[12:33] <rbasak> But the first method would be a proper cherry-pick I think
[12:34] <cjwatson> Also "git apply" has --include/--exclude options, which might help
[12:34] <cjwatson> Though that only deals with the patch part, not copying the commit message
[12:34] <rbasak> Another way might be to check out <commit>, "git reset HEAD^", git add the file, and commit just that in detached HEAD mode. Then check back out where you were, and cherry-pick HEAD@{1}
[12:35] <rbasak> To copy the commit message "git commit -c <commit>" is useful
[12:35] <rbasak> This last method allows "git add -p" as well, for picking a subset of a change to a file.
[12:36] <cjwatson> Yeah, personally I tend to just cherry-pick and then amend/rebase, rather than always trying to get the commit right first time
[12:36] <ahasenack> that commit is actually a big chunk of changes, it's a git ubuntu import commit, one single commit for new usptream version and lots of other stuff
[12:36] <rbasak> I was thinking about trying to avoid having to deal with merge conflicts in other files
[12:36] <cjwatson> Good point about commit -c, I always forget that that exists
[12:37] <ahasenack> yeah, cherrypick -n doesn't work, lots of conflicts because of the other changes which I'm not interested in
[12:37] <cjwatson> (I mean git's surface area is basically fractal, so ...)
[12:51] <rbasak> bdrung: tzdata in Bionic has quite a bit of churn in debian/tzdata.templates, including the removal of Pacific-New from tzdata/Zones/US. I didn't see any removals in the later series. Do we have anything that demonstrates that this is safe? Shouldn't the choice be preserved somehow?
[13:05] <rbasak> arraybolt3: your lubuntu-meta upload to Jammy is missing bug references
[13:05] <rbasak> I'm therefore not sure how to proces it
[13:19] <rbasak> xnox: sorry, I had no intention of being sneaky. I'll leave an annotation in future.
[13:53] <bdrung> rbasak, previous SRUs forgot to regenerate debian/tzdata.templates. You could use 2022g and regenerate debian/tzdata.templates to see what previous SRUs should have included in their debdiff.
[13:54] <bdrung> rbasak, Pacific-New was added but was never used. upstream removed Pacific-New some time ago.
[14:13] <bdrung> rbasak, checked that. 2018a removed Pacific-New
[14:19] <rbasak> bdrung: yeah but I wouldn't expect removals to be followed in SRUs. If it was user-selectable, then wouldn't dropping it be a regression for users who might have selected it previously?
[14:22] <bdrung> rbasak, yes. That regression would have been happened years ago when upstream removed Pacific-New.
[14:26] <rbasak> bdrung: OK, so Pacific-New in bionic-updates today is already broken?
[14:27] <rbasak> If that's the case then there will be no SRU regression so that's fine, but I'd like to document that somewhere. Can you confirm and I'll just stick this conversation into a bug comment?
[14:28] <bdrung> rbasak, I checked the history. Even 2018d-1 did not have Pacific-New as option (the source package has an outdated tzdata.templates). So it was never selectable for bionic users.
[14:29] <bdrung> 2018d-1 was the version of the bionic release.
[14:42] <rbasak> bdrung: accepted, thanks
[16:51] <rbasak> ahasenack: are you asking for an early SRU release of bug 2000817 for Jammy?
[16:51] -ubottu:#ubuntu-devel- Bug 2000817 in openldap (Ubuntu Kinetic) "Wrong SHA256-value computed on kinetic" [Undecided, Fix Committed] https://launchpad.net/bugs/2000817
[16:52] <ahasenack> rbasak: I thought initially that it had been in jammy proposed for longer
[16:52] <ahasenack> and wanted to get that green before our housekeeping meeting from today
[16:53] <ahasenack> but now it's past the meeting, and this is not urgent. Except now it will be only monday before somebody looks at it again for a release
[16:53] <ahasenack> so yeah, would be a nice to have if it could be released today, but I don't have more arguments for it (it's not an urgent bug, and it's not blocking another openldap SRU atm)
[16:55] <rbasak> I've reviewed it now. It's ready for release in all other respects.
[16:56] <rbasak> ahasenack: how about you consider this a +1, and release it yourself given I've reviewed it - now or on Monday? Feel free to cite this conversation.
[16:56] <ahasenack> ok, thanks
[16:56] <rbasak> For both Jammy and Kinetic.
[16:57] <rbasak> Consider though that we're about to have a long weekend for some people.
[16:57] <rbasak> For dealing with any fallout. I'm out on Friday and Monday (UK public holidays).
[16:59] <ahasenack> I'm out Friday, but back on Monday
[17:27] <bdmurray> ahasenack: I'm here Friday and Monday
[17:27] <ahasenack> yes, but we don't release srus on fridays :)
[17:28] <ahasenack> monday will be fine
[17:28] <bdmurray> Okay, I didn't read everything just wanted to say I'm here to help.
[17:28] <bdmurray> enr0n: bug 2015346 looks like a hardware failure to me
[17:28] -ubottu:#ubuntu-devel- Bug 2015346 in ubuntu-release-upgrader (Ubuntu) "cannot update Ubuntu to the newest version, it crashes on the 2nd pinpoint during installation" [Undecided, New] https://launchpad.net/bugs/2015346
[17:28] <bdmurray> enr0n: Do you agree?
[17:35] <enr0n> bdmurray: maybe. The error message definitely isn't very helpful. Have you seen similar reports in the past that ended up being a hardware issue?
[17:50] <bdmurray> enr0n: Oh, sorry look at dmesg
[17:52] <enr0n> bdmurray: oh, yes I agree
[18:03] <kanashiro[m]> ginggs: could you please retry puma and ruby3.1 builds in your test rebuild PPA? I was not able to reproduce them locally
[18:19] <lvoytek> ginggs: would you also be able to retry mysql-8.0 armhf? I was able to build it successfully in a PPA
[18:43] <ginggs> kanashiro[m]: .
[18:43] <ginggs> lvoytek: .
[19:02] <kanashiro[m]> ginggs: ty!
[19:15] <NexusPrism> Quick question about submitting merge requests to Ubuntu's fork of GRUB, there is https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu & https://code.launchpad.net/ubuntu/+source/grub2. I submitted a merge request to the first one but it seems like the second one is actually where you submit merge requests?
[19:16] <NexusPrism> At least based off the quantity of merge requests on the second link, but there also haven't been any MRs on it since 2019 so maybe not?
[19:44] <bdmurray> The second one is an import of the first (~ubuntu-core-dev).
[19:44] <bdmurray> So use this for an MP https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+ref/ubuntu NexusPrism
[19:45] <bdmurray> Oh, I see you did
[19:55] <NexusPrism> Ah sweet, so I'm good then
[22:33] <arraybolt3> rbasak: My lubuntu-meta upload to Jammy was a boffo because I forgot to change the codename in the changelog before uploading. Please toss it into the abyss never to return. :D
[22:34] <arraybolt3> (I asked for it to be rejected when I first did it but I guess no one who could do so was around at the time. I've since started using dput-ng which should hopefully tell me next time I nearly do that.)
[22:37] <arraybolt3> The upload was intended for Lunar (and a fixed version of said upload was accepted into Lunar).
[22:56] <rbasak> arraybolt3: no problem. I see that Brian did it already.
[23:01] <bdmurray> Because I wouldn't expect rbasak to be around!