[00:22] <quidnunc> rbasak: https://docs.huihoo.com/debian/manuals/maint-guide/ch-update.en.html this says "simply copy the debian/ directory if it was packaged with quilt". I think that package uses quilt (?). Can I do that?
[00:23] <quidnunc> Does gbp work with Fossil too?
=== didrocks999 is now known as didrocks
[07:40] <cpaelzer> git-build-recipe --allow-fallback-to-native makes the content contiain a .git dir
[07:40] <cpaelzer> some packages build behavior changes in presence of one
[07:41] <cpaelzer> I should be able to remove the .git in d/rules as part of the recipe delta, but wanted to know if there is a more declarative/systematic way to avoid getting that .git in the final result?
[07:45] <cpaelzer> oh and local git-build-recipe behaves different than the one running on LP, I'm assuming one finds the tarball and makes it native and the others does not?
=== alan_g_ is now known as alan_g
=== sem2peie- is now known as sem2peie
[15:50] <jawn-smith> bdmurray, enr0n: my u-r-u MP has been approved
[15:54] <bdmurray> jawn-smith: great
[15:55] <enr0n> jawn-smith: thanks for the heads up
[15:57] <jawn-smith> Now that we have the code in good shape I'll make another MP to ubuntu/devel
[15:58] <jawn-smith> but first, a sandwich
[17:02] <jawn-smith> actually after discussing with waveform I don't think this needs a kinetic PR. Rather, the remove_uboot should be removed from kinetic
[17:05] <bdmurray> jawn-smith: is remove_uboot a quirk?
[17:05] <jawn-smith> bdmurray: yes, it is
[17:07] <bdmurray> jawn-smith: if its not relevant for an upgrade from J to K then it can be removed. Additionally, if your new quirk isn't relevant for J to K then it doesn't need to be in K even though its being SRU'ed to J
[17:07] <jawn-smith> bdmurray: that is correct, neither of these quirks are relevant for J to K upgrades
[17:08] <bdmurray> jawn-smith: Although given that the quirk is late you should think about people who have already upgraded to J
[17:12] <waveform> both the netplan and remove-uboot quirks are relevant for upgraders *to* jammy, but correct me if I'm wrong, as you can't skip an LTS when upgrading, that means all upgraders to kinetic (or ++) would *have* to pass thru jammy and so neither is necessary beyond that. The only reason I can think to leave either in beyond jammy is in case there's some future SRU back to jammy (so it *might* be worth gating both quirks on version <= 22.04?)
[17:15] <jawn-smith> bdmurray: since this breaks networking I don't think it's something that could be ignored for a long period of time. It therefore seems unlikely that someone would make it all the way to a kk upgrade without fixing this manually
[17:22] <bdmurray> jawn-smith: ack
[21:15] <dbungert> May I get assistance with a retest? https://autopkgtest.ubuntu.com/request.cgi?release=kinetic&arch=arm64&package=chkrootkit&trigger=binutils/2.38-4ubuntu1
[21:17] <kanashiro> dbungert, done
[21:20] <dbungert> kanashiro: thanks!
[21:28] <bdmurray> While there isn't much in the queues right now I think it'd be better to provide a `retry-autopkgtest-regressions` command to run as taht will check for any existing queued tests.
[22:03] <dbungert> bdmurray: I actually asked that before, but it wasn't run yet, so I thought I might have better luck with the URL