amurray | 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? | 00:37 |
---|---|---|
tsimonq2 | 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. | 01:01 |
amurray | 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:09 |
amurray | 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:10 |
tsimonq2 | 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 |
tsimonq2 | I usually don't do it that way otherwise. :) | 02:35 |
amurray | ah ok - thanks | 02:47 |
tsimonq2 | bdrung: triggers> I'll look into it further, but it's possible this is what Debian will do. | 03:49 |
tsimonq2 | bdrung, juliank: I've been told HiDPI Plymouth works in Fedora. | 03:52 |
tsimonq2 | bdrung: Also per previous discussions: https://launchpad.net/ubuntu/+source/dracut/105-2ubuntu3 | 04:06 |
=== hgwbzjezmokhepyv is now known as axpphndmpygoodzy | ||
=== axpphndmpygoodzy is now known as georgiag | ||
coconason | Can I access a git repository to get the ubuntu-glibc source code? | 07:15 |
=== pushkarnk1 is now known as pushkarnk | ||
tjaalton | 3~3~ | 09:41 |
tjaalton | uh | 09:41 |
=== cpaelzer_ is now known as cpaelzer | ||
woky_ | late thanks! Odd_Bloke | 15:33 |
=== dbungert1 is now known as dbungert | ||
=== woky_ is now known as woky__ | ||
=== woky__ is now known as woky_ | ||
halves | 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 | 16:55 |
enr0n | 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:07 |
cjwatson | Yes, I think that's the best way. It's in dpkg-source(1) FWIW | 17:11 |
cjwatson | Before that existed people used to have to uuencode/base64-encode/whatever binary files added in Debian diffs, which was clearly worse | 17:12 |
cjwatson | Post-xz-compromise I suppose you should expect more scrutiny of compressed files added in stable updates though :) | 17:13 |
adrien | 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:28 |
cjwatson | adrien: If not for knowing the context, though, I'd say that was a weird policy | 17:53 |
cjwatson | Post-freeze changes are usually where you want _more_ testing | 17:53 |
schopin | !dmb-ping | 19:03 |
ubottu | bdmurray, bdrung, rbasak, schopin, teward, tsimonq2, utkarsh2102: DMB ping | 19:03 |
halves | 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 |
halves | but this is already super helpful confirmation, thank you both! | 19:26 |
liushuyu | 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:28 |
liushuyu | 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:29 |
-ubottu:#ubuntu-devel- Merge 5 in utopia-team/polkit-gnome "Merge Ubuntu deltas" [Opened] | 19:30 | |
jbicha | liushuyu: it's not practical to push our Ubuntu changes for that package to Debian | 19:31 |
liushuyu | 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 |
liushuyu | * opinions | 19:32 |
liushuyu | 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 |
jbicha | 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:33 |
liushuyu | 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:34 |
liushuyu | (... including me) | 19:35 |
jbicha | oh, it's a universe package and there is no package owner like there are for packages in main (and select flavor packages) | 19:36 |
liushuyu | erm... then what should we be doing in this case? | 19:38 |
jbicha | someone needs to review the Launchpad merge. The one comment disrupted the normal review that should have happened months ago | 19:40 |
liushuyu | 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:44 |
jbicha | 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:45 |
liushuyu | 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:47 |
jbicha | 👍 | 19:48 |
=== ebarretto_ is now known as ebarretto | ||
RikMills | MoM is not updating | 21:01 |
adrien | 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 | 21:17 |
cjwatson | 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 | 22:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!