[00:05] <jbicha> tsimonq2: Ubuntu completed usr-merge years ago so there isn't much interest in those reports
[00:21] <tsimonq2> jbicha: Bah, I'm always going to lean on the side of more data, not less.
[00:22] <tsimonq2> jbicha: Even if it doesn't result in anything major, I'm curious about the results.
[00:23] <tsimonq2> It doesn't cost much to run and didn't take a massive amount of my time anyway. :)
[01:08] <Eickmeyer> jbicha: Why punsh good behavior?
[01:29] <jbicha> Eickmeyer: I don't think I'm punishing good behavior
[01:35] <jbicha> people are of course free to have their own personal projects, but since non-usr-merged systems haven't been supported in so long, I don't see how this work benefits Ubuntu
[01:36] <jbicha> sorry for the negative energy, not sure how I could have expressed this gentler :/
[02:48] <themill> jbicha: dumat isn't about supporting non-merged-usr, it's about not losing files during upgrades when the file path inside the shipped .deb changes. Given ubuntu also seems to be in the process of moving the files to /usr, merged-/usr is not a finished project in ubuntu and I would have expected those failure modes to hit ubuntu just as much as Debian at this stage.
[09:39] <sudip> tsimonq2: about the patch header, I think (I might be wrong) is according to dep3. Please check "A patch cherry-picked from upstream:" at https://dep-team.pages.debian.net/deps/dep3/
[09:41] <sudip> about autopkgtest of linux-show-player, it should be pretty easy to setup an autopkgtest for this. I have superficial autopkgtest in some of my packages which checks if the gui has been displayed or not and if the title of the window is as expected. This package can have similar autopkgtest
[15:42] <tsimonq2> sudip: I see, you're good IMO :)
[16:02]  * sudip blushes
[16:07] <tsimonq2> PSA: ubuntu-dev-tools 0.199 has just been uploaded to Unstable, introducing vorlon's pm-helper tool. I would recommend everyone start using it right away, just so we can iron out any bugs. I'll be keeping a better eye on ubuntu-dev-tools MPs; if you come across a bug, feel free to ping me directly, I'm happy to get (tested, well-written) fixes in quick.
[16:10] <tsimonq2> Once it actually migrates to noble[-release, I'll
[16:10] <tsimonq2> ...send something to the mailing list/Discourse. Whoops. :)
[16:35] <vorlon> tsimonq2: so why is the launchpad main git branch being used for tracking uploads to Debian instead of to Ubuntu? also, you had review comments on the MP, did you address those code changes? I don't see that in the git history
[16:36] <vorlon> (I disagree with one of them, I don't care about supporting Launchpad staging with this script; but the other question about where tools in ubuntu-dev-tools should store a shared cache is salient)
[16:57]  * sudip thought Ubuntu changes are tracked in ubuntu/devel branch of all repo in launchpad
[17:02] <vorlon> git-ubuntu is intended to provide a consistent interface for all packages.  But git-ubuntu is not authoritative for the majority of packages maintained in git.
[21:02] <tsimonq2> vorlon: VCS status> To be fair, it's historical, mapreri may be able to speak better about why that fence is up. When thinking about it though, the maintainer is Ubuntu Developers, we should be able to collectively commit and upload to it. Hosting it on Salsa would introduce a problem in which some people should have permissions but don't. With Launchpad being the SSOT for permissions, this is
[21:02] <tsimonq2> exceptional, sure, but it seems sane.
[21:03] <vorlon> well my position on this is that I don't care about the package in Debian only in Ubuntu
[21:03] <tsimonq2> mapreri's position has always been "so why do we need an Ubuntu delta again?" and I tend to share that with this package.
[21:05] <tsimonq2> Anyway, as for the inline diff comments, ack.
[21:37] <dannf> How can I report an issue about the config of our autopkgtest instances? https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2043579
[21:37] -ubottu:#ubuntu-devel- Launchpad bug 2043579 in initramfs-tools (Ubuntu) "initramfs-tools autopkgtest fails on armhf: stderr: cryptsetup: ERROR: Couldn't resolve device /dev/sda2" [Undecided, Triaged]
[22:06] <sergiodj> adrien: heya, you might have noticed that I sponsored your ruby3.1 upload, but unfortunately it's FTBFSing on armhf. I retried it once and the same error happened. could you take a look when possible, please?
[22:10] <adrien> sergiodj: thanks; just saw the e-mails and I'll have a go at it tomorrow
[22:10] <adrien> (I was expecting a timeout initially)
[22:11] <sergiodj> thanks!
[22:11] <sergiodj> yeah, me too.  OK, since you'll only be able to look into this tomorrow, I'll do another retry
[22:34] <tsimonq2> dannf: https://bugs.launchpad.net/auto-package-testing/+filebug :)
[22:35] <dannf> tsimonq2: thx!
[22:35] <tsimonq2> of course :)
[23:44] <sergiodj> adrien: the build passed, so it's all good