=== mnepton is now known as mneptok
=== ted_ is now known as ted
[10:25] <adrien> is it possible to create a git-ubuntu-style commit from the beginning? I can't track the history-rewrite that git-ubuntu merge does and most often only need to author a single commit
[10:33] <schopin> adrien: I think you'd be better off explaining what your end-goal is and what are the issues you're seeing with "tracking the history-rewrite"? Because as it is I can't make sense of your question :/
[10:34] <schopin> If only need to to author a single commit, why are you talking about merges? You should just commit on top of ubuntu/devel and post that as a MP (I believe that'd be `git ubuntu submit`)
[10:35] <adrien> right; context is https://code.launchpad.net/~adrien-n/ubuntu/+source/gnutls28/+git/gnutls28/+merge/458092
[10:35] <adrien> how should one do: "Also, I didn't sponsor this in git-ubuntu style, as the commit(s) do not match that structure (d/changelog and logical changes as part of the same commit). You could consider splitting it for git-ubuntu in the future."
[10:35] <adrien> purely by hand?
[10:38] <sudip> adrien: I think the problem was that you only had one commit. you should have done the change as a separate commit and d/changelog as separate commit
[10:38] <schopin> Well we're not expecting you to craft the blob, tree and commit object files by hand, but e.g. `git add debian/conf/config; git commit; git add debian/changelog; git commit -m "changelog"`. It does indeed make merging easier.
[10:41] <adrien> I'm almost fine doing that by hand due to typos and that's also quite obvious but it's really not mentioned anywhere I think and coupled with the fact that git-ubuntu is sometimes quite opaque, it became something I never tried
[10:42] <adrien> I'll try it next, thanks (well, I'll script on top of g-u I guess)
[12:30] <philroche> Are there any core devs able to review https://code.launchpad.net/~toabctl/livecd-rootfs/+git/livecd-rootfs-1/+merge/459010  ?. This fixes a regression in livecd-rootfs and all new Jammy cloud images - bug defined @ https://bugs.launchpad.net/cloud-images/+bug/2049860. I have upload rights but a condition is that I get a core dev approval before uploading
[12:30] -ubottu:#ubuntu-devel- Launchpad bug 2049860 in cloud-images "cloud-init cloud-config for ssh broken in jammy" [High, In Progress]
[12:40] <philroche> request cancelled :) utkarsh has uploaded
[12:45] <philroche> tjaalton vorlon As SRU vanguards today. Can you help accept `2.765.36` Jammy in to -proposed ? To address https://bugs.launchpad.net/cloud-images/+bug/2049860
[12:45] -ubottu:#ubuntu-devel- Launchpad bug 2049860 in cloud-images "cloud-init cloud-config for ssh broken in jammy" [High, In Progress]
[12:46] <philroche> Ah sorry I need to move this request to #ubuntu-release
=== caribou_ is now known as caribou
[14:18] <adrien> is "git ubuntu style" defined somewhere? or alternatively, how can I check that what I produce is correct?
[15:17] <rbasak> adrien: there isn't a style as such. What are you trying to avoid? MP comments telling you to change style? Or rich history not being adopted or something else?
[15:17] <rbasak> adrien: one thing that comes to mind is that we try to keep changes to debian/changelog and that kind of thing in separate commits, but that's not mandatory - that's only to make cherry-picking easier.
[15:19] <rbasak> Although, having said that, if you're doing a "package merge", then people who use the workflow are much more specific about the method used and the steps presented. Not because it's strictly technically necessary, but because it's not practical to review someone else's merge without completely redoing it _unless_ our method is used.
[15:19] <rbasak> That method is defined at
[15:19] <rbasak> https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageMerging.md
=== bdmurray_ is now known as bdmurray
[15:24] <adrien> thanks; I was never on the reviewer side so I didn't know that
[15:25] <adrien> as for style, I'd like to follow good practice but git ubuntu merge is pretty heavy and it seems there's far fewer stuff needed when history is already rich but that's where I'm looking for details
[15:26] <adrien> for instance, what are rules for the commit message for the logical commits?
[15:34] <schopin> Pretty much the same contents as what you'd want to see in the changelog, that way you can use stuff like gbp dch.
[15:41] <rbasak> philroche: in bug 1968873, perhaps verification-failed-focal is more appropriate if you are confident the current focal-proposed package is bad and must not land?
[15:42] -ubottu:#ubuntu-devel- Bug 1968873 in livecd-rootfs "Regression: images ship with modified configuration file" [High, In Progress] https://launchpad.net/bugs/1968873
[15:42] <rbasak> That will highlight red in the pending-sru report
[15:50] <adrien> so the commit message would be a chunk of d/changelog, with whitespace kept?
[15:54] <rbasak> Yes - if you ignore normal git commit formatting convention and make it exactly the lines of the changelog that will be inserted, then the git-ubuntu.reconstruct-changelog tool will build your changelog for you from those commits, which you then add as another commit. That's the current convention, though we might eventually have something better.
[15:55] <rbasak> So keep the leading whitespace, bullet point marker, wrap like you'd want the changelog to wrap, none of the usual summary line and blank line or that kind of thing.
[15:56] <adrien> and I keep d/changelog _out_ of the commit?
[15:57] <rbasak> Correct.
[15:57] <rbasak> Do not touch debian/changelog normally at all.
[15:58] <rbasak> Once you have all your commits in this fashion, run git-ubuntu.merge-changelogs with the correct parameters and commit the debian/changelog changes it produces as a single commit, *OR* run "git ubuntu merge finish" which does that for you.
[15:59] <rbasak> Then run git-ubuntu.reconstruct-changelog and commit the debian/changelog changes it produces as a second commit.
[16:00] <adrien> so, let's say I git ubuntu clone a repo with rich history, and I want to add a patch, I would: add the patch in d/patches, edit d/patches/series, git add d/patches/foo.diff d/patches/series, git commit -m "  * add foo.diff patch", git-ubuntu.reconstruct.changelog, git commit -m changelog d/changelog
[16:00] <adrien> ?
[16:00] <rbasak> Yeah if you want to do it like that.
[16:00] <ahasenack> git-ubuntu.reconstruct-changelog takes a commit as a parameter, so you need to give it, say, pkg/ubuntu/devel
[16:01] <philroche> rbasak: I have updated https://bugs.launchpad.net/livecd-rootfs/+bug/1968873 to use verification-failed-focal as suggested
[16:01] -ubottu:#ubuntu-devel- Launchpad bug 1968873 in livecd-rootfs "Regression: images ship with modified configuration file" [High, In Progress]
[16:01] <rbasak> Thanks!
[16:01] <adrien> ahasenack: ok, thanks
[16:02] <adrien> rbasak: I see, thanks! are there other alternative ways besides git ubuntu merge?
[16:03] <rbasak> adrien: only really that you can do what git ubuntu merge does directly instead
[16:04] <adrien> ok, thanks again; I'll have a go in the coming working hours (so maybe monday, because I'm trying to use canonistack in parallel)
[16:07] <rbasak> Note that git-ubuntu itself doesn't require or expect much itself. It's just expectations of others, and future automation that's impacted. So for example if you want to prepare debian/changelog yourself, then it doesn't matter what you put in commit messages.
[16:10] <adrien> I see, that's something that was bothering me too (and overall, understand what I get back after a round trip through review and merge by uploader)
[16:10] <rbasak> But then if you choose to use git-ubuntu.reconstruct-changelog then it'll make a mess, and the next person to do the package merge won't be able to either without fixing up their rebased commit messages first.
[16:10] <rbasak> However, you can always just create a commit (or multiple) that fixes up debian/changelog as you want it.
[16:11] <adrien> but the result of reconstruct-changelog has the same constraints any edit of d/changelog, right?
[16:14] <rbasak> It's so small it's probably easier to show you it :-)
[16:14] <rbasak> https://git.launchpad.net/git-ubuntu/tree/bin/git-reconstruct-changelog
[16:14] <rbasak> All it's doing is the equivalent of calling "dch" for each commit.
[16:37] <adrien> it's tiny indeed :)
[16:41] <rbasak> the equivalent of calling "dch" for each commit> but without any change to formatting
[16:41] <rbasak> :)
[17:16] <ahasenack> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: ahasenack
[17:19] <tsimonq2> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: tsimonq2, ahasenack
[17:19] <tsimonq2> ahasenack: Light flight planned today, bug 785051 bug 2049188 are the only ones on my radar.
[17:19] -ubottu:#ubuntu-devel- Bug 785051 in libnss-extrausers (Ubuntu) "groupsfile is ignored when any entry has id < 500" [Undecided, Confirmed] https://launchpad.net/bugs/785051
[17:19] -ubottu:#ubuntu-devel- Bug 2049188 in hiredis (Ubuntu) "hiredis FTBFS on ppc64el" [Undecided, New] https://launchpad.net/bugs/2049188
[17:19] <tsimonq2> (And it'll be my last patch pilot session for the week.)
[17:29] <ahasenack> first one I picked was https://bugs.launchpad.net/ubuntu/+source/backport-iwlwifi-dkms/+bug/2046871
[17:29] -ubottu:#ubuntu-devel- Launchpad bug 2046871 in backport-iwlwifi-dkms (Ubuntu) "migrate to upstream release/coreNN branch" [High, In Progress]
[17:29] <ahasenack> epoch version seems to be the topic
[17:29] <ahasenack> it's the oldest from http://sponsoring-reports.ubuntu.com/
[17:33] <tsimonq2> Good call/agree with reasoning :)
[17:33] <tsimonq2> xorg still needs a tjaalton or similar ping: https://code.launchpad.net/~jeff250/ubuntu/+source/xorg-server/+git/xorg-server/+merge/457781
[17:33] <tsimonq2> I raised https://launchpad.net/bugs/2039873 yesterday - apparently Server is looking into it, not touching :)
[17:33] -ubottu:#ubuntu-devel- Launchpad bug 2039873 in lxc (Ubuntu) "liblxc-dev was built with LXC_DEVEL=1 in Ubuntu 22.04 and later releases" [Undecided, Confirmed]
[17:35] <tsimonq2> TIL about the +ucd suffix
[18:08] <tsimonq2> hiredis is in noble-proposed, libnss-extrausers is waiting for an email ... sometime in the next hour or two ... telling me it was accepted to Debian.
[18:08] <tsimonq2> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: ahasenack
[18:08] <ahasenack> tjaalton: :w
[18:08] <ahasenack> :q
[18:08] <ahasenack> hm, n/m
[18:08] <tsimonq2> :wq
[18:10] <arraybolt3> :q!
[20:04] <mhickford> Is anyone familiar with uploading packages from Debian to Ubuntu PPA without editing debian/changelog? I tried to follow https://help.launchpad.net/Packaging/PPA/Uploading#Using_packages_from_other_distributions , my package uploads okay but the PPA remains empty. Any ideas?
[20:08] <mhickford> In dput.cf I'm using `incoming                = ~hickford/ubuntu/git-credential-oauth/mantic` which looks right to me https://launchpad.net/~hickford/+archive/ubuntu/git-credential-oauth unless I'm missing something
[20:10] <jbicha> mhickford: my dput.cf just has a section [ppa] with method = sftp and login = jbicha
[20:10] <ahasenack> mhickford: I always put the ubuntu release name in there
[20:10] <ahasenack> i.e., I use dch -R
[20:10] <ahasenack> and edit
[20:10] <jbicha> I also use backportpackage from ubuntu-dev-tools to make it easier to upload from Debian to my ppa
[20:11] <jbicha> assuming the package is already in Debian, but I might have misunderstood you
[20:12] <mhickford> Yes the package is already in Debian. According to https://help.launchpad.net/Packaging/PPA/Uploading#Using_packages_from_other_distributions  "You can upload a source from any Debian-compatible distribution straight to your PPA with no changes required and it will be built and published in the targeted Ubuntu suite. The suite you specify [in
[20:12] <mhickford> dput.cf] will override the suite named in the upload changelog when you upload it"
[20:17] <enr0n> mhickford: I usually do something like `copy-package --from=debian --from-suite=sid --to-suite=noble --to=~enr0n/ubuntu/<my ppa> <source package name>`, without any special edits to dput config
[20:21] <mhickford> That sounds sensible. In which package is `copy-package`?
[20:25] <tsimonq2> mhickford: It's actually in a Git repository, sec.
[20:26] <enr0n> mhickford: argh, I just realized that it's in a git repo (https://git.launchpad.net/ubuntu-archive-tools), apparently not published in a package
[20:26] <tsimonq2> ^^ that :)
[20:26] <enr0n> But it's a useful script nonetheless
[20:26] <enr0n> Probably could/should be in ubuntu-dev-tools
[20:26] <mhickford> Thanks I'll try it
[20:26] <tsimonq2> enr0n: I'm glad I'm not the only one who was thinking that!
[20:28] <enr0n> tsimonq2: yeah I think that would make the most sense
[20:31] <tsimonq2> I really do think we also need a move-package command... one that copies the package over, ensures the copy was successful, then deletes it from the source.
[20:32] <tsimonq2> I remember from my time writing britney-ppa that the archive literally uses a combination of copy-package and remove-package...
[20:32] <tsimonq2> (To my recollection, of course.)
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: N/A
[21:00] <ahasenack> @pilot out