| bdrung | dbungert, subiquity could ship the apport hook by itself, but currently apport does not support snap shipping those hooks. | 09:55 |
|---|---|---|
| seb128 | ginggs, hey, could you give a retry to dee , gnome-keyring and udisks2 in the lunar archive rebuild? | 10:36 |
| ginggs | seb128: . | 10:50 |
| seb128 | ginggs, thanks! | 10:50 |
| ahasenack | rbasak: do you happen to know if it's possible to git cherry-pick just a specifig file change from a commit? | 12:27 |
| ahasenack | specific* | 12:28 |
| ahasenack | like (made up) git cherry-pick <commit> -- debian/kdc.conf | 12:28 |
| ahasenack | (which didn't work) | 12:28 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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? | 12:51 |
| 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:05 |
| rbasak | xnox: sorry, I had no intention of being sneaky. I'll leave an annotation in future. | 13:19 |
| 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:53 |
| bdrung | rbasak, Pacific-New was added but was never used. upstream removed Pacific-New some time ago. | 13:54 |
| bdrung | rbasak, checked that. 2018a removed Pacific-New | 14:13 |
| 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:19 |
| bdrung | rbasak, yes. That regression would have been happened years ago when upstream removed Pacific-New. | 14:22 |
| rbasak | bdrung: OK, so Pacific-New in bionic-updates today is already broken? | 14:26 |
| 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:27 |
| 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:28 |
| bdrung | 2018d-1 was the version of the bionic release. | 14:29 |
| rbasak | bdrung: accepted, thanks | 14:42 |
| 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:51 | |
| 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:52 |
| 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:53 |
| rbasak | I've reviewed it now. It's ready for release in all other respects. | 16:55 |
| 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:56 |
| 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:57 |
| ahasenack | I'm out Friday, but back on Monday | 16:59 |
| bdmurray | ahasenack: I'm here Friday and Monday | 17:27 |
| ahasenack | yes, but we don't release srus on fridays :) | 17:27 |
| 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:28 |
| 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:35 |
| bdmurray | enr0n: Oh, sorry look at dmesg | 17:50 |
| enr0n | bdmurray: oh, yes I agree | 17:52 |
| 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:03 |
| lvoytek | ginggs: would you also be able to retry mysql-8.0 armhf? I was able to build it successfully in a PPA | 18:19 |
| ginggs | kanashiro[m]: . | 18:43 |
| ginggs | lvoytek: . | 18:43 |
| kanashiro[m] | ginggs: ty! | 19:02 |
| 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:15 |
| 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:16 |
| 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:44 |
| bdmurray | Oh, I see you did | 19:45 |
| NexusPrism | Ah sweet, so I'm good then | 19:55 |
| 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:33 |
| 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:34 |
| arraybolt3 | The upload was intended for Lunar (and a fixed version of said upload was accepted into Lunar). | 22:37 |
| rbasak | arraybolt3: no problem. I see that Brian did it already. | 22:56 |
| bdmurray | Because I wouldn't expect rbasak to be around! | 23:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!