[00:37] tsimonq2: hey, for intel-microcode 3.20241112.1ubuntu2 you included a link to a debian bug number - shouldn't we have an equivalent LP bug number to track that change in Ubuntu? Or ideally shouldn't this land directly in debian first? then we can merge it for Ubuntu? [01:01] amurray: At the time the change was blocking some work I was doing for the Lubuntu ISOs, and it matches amd64-microcode. I'm not particular on having a Launchpad bug, if you think that's the best course of action I can certainly file one. [02:09] tsimonq2: I just found it a bit odd to reference a debian bug number in a ubuntu package upload - seems like an impedence mismatch - either it should be an upload to debian to reference the debian bug or a LP bug number [02:10] also since it doesn't actually close the debian bug as the upload hasn't landed there right, it seemed odd to use the Closes: syntax [02:35] amurray: It's more of a reference for the next person doing the Debian merge, so they know to check for that in the incoming upload(s). [02:35] I usually don't do it that way otherwise. :) [02:47] ah ok - thanks [03:49] bdrung: triggers> I'll look into it further, but it's possible this is what Debian will do. [03:52] bdrung, juliank: I've been told HiDPI Plymouth works in Fedora. [04:06] bdrung: Also per previous discussions: https://launchpad.net/ubuntu/+source/dracut/105-2ubuntu3 === hgwbzjezmokhepyv is now known as axpphndmpygoodzy === axpphndmpygoodzy is now known as georgiag [07:15] Can I access a git repository to get the ubuntu-glibc source code? === pushkarnk1 is now known as pushkarnk [09:41] 3~3~ [09:41] uh === cpaelzer_ is now known as cpaelzer [15:33] late thanks! Odd_Bloke === dbungert1 is now known as dbungert === woky_ is now known as woky__ === woky__ is now known as woky_ [16:55] hello ubuntu-devel! what's the preferred way to add a binary file to an SRU? (e.g. a .bz2 file for a regression test case) - I found debian/source/include-binaries, but it's not addressed in the Debian policy or packaging docs [17:07] halves: I have done something similar in the past, and the SRU team did not have a problem with using d/s/include-binaries. I can't find the logs now, but IIRC I asked my team about it and could not come up with any alternatives [17:11] Yes, I think that's the best way. It's in dpkg-source(1) FWIW [17:12] Before that existed people used to have to uuencode/base64-encode/whatever binary files added in Debian diffs, which was clearly worse [17:13] Post-xz-compromise I suppose you should expect more scrutiny of compressed files added in stable updates though :) [17:28] A probably little-known thing with xz-utils is that Jia Tan was adamant that the change to "fix the valgrind issues" should also include the updated test cases, which was against policy for post-freeze changes. [17:53] adrien: If not for knowing the context, though, I'd say that was a weird policy [17:53] Post-freeze changes are usually where you want _more_ testing [19:03] !dmb-ping [19:03] bdmurray, bdrung, rbasak, schopin, teward, tsimonq2, utkarsh2102: DMB ping [19:26] enr0n cjwatson thanks! yes, I thought that was a cleaner way (as opposed to having a big binary chunk in the diff). Ideally I'd also like to have some kind of sha256sum integrated into it, for precisely those xz concerns :) [19:26] but this is already super helpful confirmation, thank you both! [19:28] jbicha: Hi sorry for bringing up this again, but are we doing the "dual maintenance on Salsa" thing for https://salsa.debian.org/utopia-team/polkit-gnome? [19:29] Because I will forget https://salsa.debian.org/utopia-team/polkit-gnome/-/merge_requests/5 this exists for another year (it's November) and we won't be able to do anything about it if it's not maintained by us [19:30] -ubottu:#ubuntu-devel- Merge 5 in utopia-team/polkit-gnome "Merge Ubuntu deltas" [Opened] [19:31] liushuyu: it's not practical to push our Ubuntu changes for that package to Debian [19:32] jbicha: I received conflict opinons in https://code.launchpad.net/~liushuyu-011/ubuntu/+source/policykit-1-gnome/+git/policykit-1-gnome/+merge/465737 [19:32] * opinions [19:33] Someone else said: "We maintain the package in salsa, so no need to do a PR here. If there are ubuntu-only changes they need to be synchronized there." [19:33] Marco's comment there was a mistake. Most similar packages are maintained on the Salsa side but we haven't done that for this package yet [19:34] jbicha: Can someone from related teams make a comment on that Launchpad MP to state the situation? Because I can see everyone else are very confused [19:35] (... including me) [19:36] oh, it's a universe package and there is no package owner like there are for packages in main (and select flavor packages) [19:38] erm... then what should we be doing in this case? [19:40] someone needs to review the Launchpad merge. The one comment disrupted the normal review that should have happened months ago [19:44] jbicha: Okay, then I should record the summarised version of this conversation on Launchpad, is that correct? Because otherwise nobody will know the original comment is not the intended solution [19:45] yes please. This is a short week for me with US holidays so I'm not sure whether I'll get to it this week myself [19:47] jbicha: I know it's going to be the Turkey consumption festival in US very soon, but I will still subscribe you to that bug so that if someone else has more questions you will see them too [19:48] 👍 === ebarretto_ is now known as ebarretto [21:01] MoM is not updating [21:17] cjwatson: I think I told them that it was fine and that the testsuite wouldn't be used for the package but it would still get exercised locally :P [22:11] halves: I don't really see the point of a sha256sum here - packages are already signed as part of uploading them to the archive, so it doesn't really help