[11:17] <rbasak> juliank: o/
[11:17] <juliank> o/
[11:17] <rbasak> So on the upcoming apt SRU and how to organise the bugs...
[11:18] <rbasak> Bug 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/2060721
[11:18] <rbasak> I 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] <rbasak> So 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:19] <juliank> Indeed, and the follow up bug is worded in terms of it
[11:19] <rbasak> If 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] <rbasak> Then the SRU would only touch the latter bug I think?
[11:20] <juliank> Oh I guess bug 2073126 tracks the NIST curves only
[11:20] -ubottu:#ubuntu-devel- Bug 2073126 in apt (Ubuntu Noble) "More nuanced public key algorithm revocation" [Undecided, Fix Committed] https://launchpad.net/bugs/2073126
[11:20] <rbasak> There 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] <rbasak> I 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:21] <rbasak> And have some "null" SRU information in the bug explaining that, to avoid review questions.
[11:21] <rbasak> And that this would be acceptable.
[11:21] <juliank> rbasak: Do we then re-open it when we have a new crypto ratchet mechanism / after migration to -updates?
[11:21] <juliank> Because the bug remains valid of course after that
[11:21] <juliank> But htat technically works
[11:22] <rbasak> If the bug accidentally gets closed incorrectly then I think yes just re-open it afterwards.
[11:22] <juliank> Launchpad auto-closes them, no?
[11:22] <juliank> Or is that semi-manual SRU team work?
[11:22] <rbasak> It's automatic.
[11:23] <rbasak> This part is no different to what would happen in the development release, I think?
[11:23] <juliank> I think so yes
[11:23] <rbasak> Eg. 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:24] <juliank> +1
[11:24] <rbasak> juliank: 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:25] <juliank> I think that's fine, I just need to build packages :D
[11:25] <juliank> * that's all
[11:26] <juliank> The 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 risky
[11:30] <juliank> Ugh I have to merge some valgrind cleaning fixes for old releases because it's unclean
[11:32] <juliank> -      *Cache.HeaderP = pkgCache::Header();
[11:32] <juliank> +      new (Cache.HeaderP) pkgCache::Header();
[11:32] <juliank> These are different!
[11:32] <juliank> If you haven't guessed it; the assignment constructs the Header on the stack and copies it. But that copies uninitialized padding bytes
[11:32] <juliank> Sigh
[11:32] <rbasak> Ah 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-changelogs
[11:32] <rbasak> In this case it's not exactly that situation, but I think we can handle it in the same way
=== tribaal_ is now known as tribaal
[14:58] <jbicha> @pilot in
=== 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
[19:02] <jbicha> @pilot out
=== 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
[19:58] <liushuyu> Hi, can someone take a look at https://code.launchpad.net/~liushuyu-011/ubuntu/+source/xfsprogs/+git/xfsprogs/+merge/473935 (SRU)?
=== oraculo is now known as Guest7039
=== mIRC-rockcavera2 is now known as oraculo
[20:47] <enr0n> liushuyu: sponsored
[20:47] <liushuyu> enr0n: Thanks!
[21:34] <tsimonq2> Qt 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/475261