=== artur is now known as artur-at-work
[09:31] <upils> o/ rbasak
[09:31] <rbasak> upils: hi! On bug 2025339, I think you need to consider patching snapd if that is what is required.
[09:31] -ubottu:#ubuntu-devel- Bug 2025339 in e2fsprogs (Ubuntu Lunar) "FDE image fails to run e2fsck" [Undecided, In Progress] https://launchpad.net/bugs/2025339
[09:31] <rbasak> We can't be SRUing a performance regression just because snapd has expectations that were not met at release time.
[09:33] <rbasak> I think it's OK to regress this in Noble so that we have LTS-to-LTS forwards and backwards compatibility, but I don't see why we should compromise our quality on Lunar for all users just because it's harder to work around somewhere else for a niche set of users.
[09:37] <upils> what do you mean "regress this is Noble"? This is already disabled disabled in mantic and the feature did not exist in Jammy
[09:38] <upils> in the comments you can also see some users encountered the bug outside of the use case of snapd
[09:38] <rbasak> I mean that a user redeploying something on Noble that was previously on Lunar, using default mkfs.ext4, will lose this performance feature, resulting in a performance regression. I'm saying that's OK, in order to fix Noble so that it will be compatible both ways with Jammy.
[09:43] <rbasak> upils: some users encountered the bug outside of the use case of snapd> just bdrung I think? But yes, it's a valid issue. That doesn't necessarily mean that an SRU to Lunar is the best solution.
[09:43] <upils> But users on lunar will still be able to use this feature is they want to. Here this is more about the expected default behavior
[09:50] <rbasak> The expected default behaviour is what we released Lunar with. We break that expectation in a performance-regressing way if we change the default behavior during the lifetime of a stable release. This issue does not justify doing it for Lunar, IMHO.
[09:54] <bdrung> rbasak, yes, I ran into this issue because I used a newer live system for partitioning and copying an older Ubuntu installation onto it. This is probably not a common use case.
[09:56] <rbasak> I think it's a common enough use case that it makes sense for us to ensure that an LTS defaults to settings the previous LTS supports.
[09:57] <rbasak> That's fixed in Noble, although I asked for dep8 tests and it seems that nobody considers this important enough to bother.
[09:57] <rbasak> From an SRU perspective I don't think it's appropriate to regress the default from a performance perspective  _after_ release though.
[09:58] <rbasak> Which is why a dep8 test is even more important.
[09:58] <rbasak> If this regresses again post Noble and somebody asks for an SRU again without having written a test given the current opportunity, well that won't make you look good.
[09:58] <bdrung> I fully agree that we need dep8 tests for that.
[09:59] <rbasak> s/you/that person; I didn't mean bdrung/
[10:00] <upils> ok, I understand. I will abandon the SRU then and talk to the snapd team to define the best way to fix it
[10:01] <rbasak> Thanks!
[10:08] <adrien> related question: is there any logic somewhere to help users enable (ext4) features on existing filesystems after upgrades?
[10:10] <rbasak> tune2fs?
[10:10] <rbasak> Or do you mean some higher level UI?
[10:11] <rbasak> The problem is that users may have expectations of compatibility with older systems, so they have to be asked, so I don't think we've ever done the latter.
[10:11] <adrien> I mean poiting out to users that they might want to tune2fs
[10:11] <rbasak> I guess it would make sense to implement in some kind of "tune up" tool, but yeah I don't think that's ever been done.
[10:11] <adrien> ok, thanks
[10:12] <adrien> and I guess the benefit would require knowing how long people upgrade rather than re-install
[10:12] <rbasak> Good point
[10:12] <rbasak> Also how many users would really notice the performance difference.
[10:13] <rbasak> In the above case my fear is that there is some small set of users who will really notice, but for the trade-off to make a tuning tool worth it, it's probably the majority case that matters more.
[10:17] <adrien> agreed, and it's probably difficult to know how much there is to win before spending most of the time required to ship something that would do this
[12:00] <ginggs> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: ginggs
=== sem2peie- is now known as sem2peie
[13:42] <mkukri> https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2040113 lunar gdb SRU anyone? :)
[13:42] -ubottu:#ubuntu-devel- Launchpad bug 2040113 in gdb (Ubuntu) "gdb crashes upon `run` on some arm64 machines" [Low, New]
[16:00] <ginggs> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: N/A
[16:00] <ginggs> thank you for flying Ubuntu Air!
[16:00] <ginggs> mkukri: I'll look at the gdb SRU shortly
[16:07] <mkukri> thank you
[16:09] <adrien> did you know there's an openssl SRU too?
[16:10] <adrien> I'll probably start nagging people on tomorrow or friday because it comes with a lot of changed lines (rationale is in the SRU) and you can't just spend 10 minutes on this SRU: one probably has to plan it
[16:34] <jbicha> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: jbicha
[17:42] <tsimonq2> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: jbicha, tsimonq2
[17:43] <tsimonq2> jbicha: I'm just taking kitty, that's it. ;) (And, I'm here for questions.)
[17:43] <tsimonq2> Here, kitty kitty kitty.
[17:48] <tsimonq2> ogayot: 🐱🐱🐱🐱🐱🐱🐱🐱🐱🐱 :D
[17:48] <tsimonq2> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: jbicha
[17:49] <tsimonq2> (Top five favorite package names.)
[17:52] <Eickmeyer> tsimonq2 with the shortest flight ever.
[17:53] <tsimonq2> XD
[17:57] <tsimonq2> [PSA] When uploading to Ubuntu, use SSH, not FTP: lists.ubuntu.com/archives/ubuntu-devel/2023-November/042843.html
[18:50] <enr0n> adrien: your openssl SRU is at the stage where it needs SRU review, that's not something a patch pilot will do
[18:51] <adrien> enr0n: hmm, that's right; I guess I'm kind of desperate to get it reviewed and jump in whenever I see "SRU" somewhere :D
[18:53] <enr0n> adrien: if you haven't already, you can ping ubuntu-sru in #ubuntu-release
[19:05] <adrien> I did some real-life pings last week but that wasn't very effective; I'll start this other kind of pings tomorrow :)
[20:47] <jbicha> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: N/A