/srv/irclogs.ubuntu.com/2024/10/16/#ubuntu-devel.txt

rbasakjuliank: o/11:17
julianko/11:17
rbasakSo on the upcoming apt SRU and how to organise the bugs...11:17
rbasakBug 2060721 in particular is what is in question here I think? I'm not entirely clear on whether the set of weak keys covered by that bug has changed.11:18
-ubottu:#ubuntu-devel- Bug 2060721 in apt (Ubuntu Noble) "APT 2.8.0: Promote weak key warnings to errors" [Undecided, Fix Committed] https://launchpad.net/bugs/206072111:18
rbasakI find it easier to think about bugs in the "describe a specific problem" sense, rather than "presume the solution", since the latter changes and that can cause confusion as to what the bug is tracking, whereas the former can't really change and makes it really obvious if the bug is Invalid or Won't Fix after discovering more and getting other opinions.11:18
rbasakSo I'd consider LP: #2060721 to be something like "weak key warnings should now be errors" and would have named it like that if it were up to me. I would then attempt not to change the definition of the bug. But I'm not clear which set of key types we're talking about.11:18
juliankIndeed, and the follow up bug is worded in terms of it11:19
rbasakIf we're now moving the NIST curves to not warnings nor errors, then that sounds like it should be tracked in a separate bug to me.11:19
rbasakThen the SRU would only touch the latter bug I think?11:19
juliankOh I guess bug 2073126 tracks the NIST curves only11:20
-ubottu:#ubuntu-devel- Bug 2073126 in apt (Ubuntu Noble) "More nuanced public key algorithm revocation" [Undecided, Fix Committed] https://launchpad.net/bugs/207312611:20
rbasakThere was a thread a few months ago about how to handle a collision between bugs not needing to be tracked by SRU, but nevertheless appearing in the changelog.11:20
rbasakI think the general conclusion was that we'd keep the data correct, and where it collides with SRU process by "accidentally" including additional bugs not related to the SRU, we'd just ignore them, marking verification-done-<series> with a comment explaining that they aren't actually involved.11:20
rbasakAnd have some "null" SRU information in the bug explaining that, to avoid review questions.11:21
rbasakAnd that this would be acceptable.11:21
juliankrbasak: Do we then re-open it when we have a new crypto ratchet mechanism / after migration to -updates?11:21
juliankBecause the bug remains valid of course after that11:21
juliankBut htat technically works11:21
rbasakIf the bug accidentally gets closed incorrectly then I think yes just re-open it afterwards.11:22
juliankLaunchpad auto-closes them, no?11:22
juliankOr is that semi-manual SRU team work?11:22
rbasakIt's automatic.11:22
rbasakThis part is no different to what would happen in the development release, I think?11:23
juliankI think so yes11:23
rbasakEg. a Debian uploader fixes a bug and uses LP: #XXX in the changelog, reverts in a subsequent upload, then we merge that package, using -v. We'd end up with the bug autoclosing but we'd actually like to keep it open. So we'd wait for Launchpad to auto-close, and then re-open with an explanation.11:23
juliank+111:24
rbasakjuliank: great! Do we have anything outstanding then on how to organise the apt SRU? I think we've covered everything but I don't have the full picture.11:24
juliankI think that's fine, I just need to build packages :D11:25
juliank* that's all11:25
juliankThe new APT SRU adds a test running valgrind so I need to go upload to PPA and check it passes autopkgtests everywhere lol, valgrind tests are risky11:26
juliankUgh I have to merge some valgrind cleaning fixes for old releases because it's unclean11:30
juliank-      *Cache.HeaderP = pkgCache::Header();11:32
juliank+      new (Cache.HeaderP) pkgCache::Header();11:32
juliankThese are different!11:32
juliankIf you haven't guessed it; the assignment constructs the Header on the stack and copies it. But that copies uninitialized padding bytes11:32
juliankSigh11:32
rbasakAh here are the docs on the extra bug references in changelogs: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#bug-references-in-changelogs11:32
rbasakIn this case it's not exactly that situation, but I think we can handle it in the same way11:32
=== tribaal_ is now known as tribaal
jbicha@pilot in14:58
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Final Freeze | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Oracular | Patch Pilots: jbicha
=== pushkarnk1 is now known as pushkarnk
=== sudip_ is now known as sudip
jbicha@pilot out19:02
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Final Freeze | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Oracular | Patch Pilots: N/A
liushuyuHi, can someone take a look at https://code.launchpad.net/~liushuyu-011/ubuntu/+source/xfsprogs/+git/xfsprogs/+merge/473935 (SRU)?19:58
=== oraculo is now known as Guest7039
=== mIRC-rockcavera2 is now known as oraculo
enr0nliushuyu: sponsored20:47
liushuyuenr0n: Thanks!20:47
tsimonq2Qt 6 port of software-properties-qt, if anyone wants to take a look: https://code.launchpad.net/~ubuntu-core-dev/software-properties/+git/software-properties/+merge/47526121:34

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!