| === artur is now known as artur-at-work | ||
| 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:31 |
| 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:33 |
| 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:37 |
| 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:38 |
| 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:43 |
| 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:50 |
| 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:54 |
| 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:56 |
| 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:57 |
| 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:58 |
| rbasak | s/you/that person; I didn't mean bdrung/ | 09:59 |
| 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:00 |
| rbasak | Thanks! | 10:01 |
| adrien | related question: is there any logic somewhere to help users enable (ext4) features on existing filesystems after upgrades? | 10:08 |
| rbasak | tune2fs? | 10:10 |
| rbasak | Or do you mean some higher level UI? | 10:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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 | 10:17 |
| ginggs | @pilot in | 12:00 |
| === 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 | ||
| 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] | 13:42 | |
| ginggs | @pilot out | 16:00 |
| === 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 | ||
| ginggs | thank you for flying Ubuntu Air! | 16:00 |
| ginggs | mkukri: I'll look at the gdb SRU shortly | 16:00 |
| mkukri | thank you | 16:07 |
| adrien | did you know there's an openssl SRU too? | 16:09 |
| 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:10 |
| jbicha | @pilot in | 16:34 |
| === 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 | @pilot in | 17:42 |
| === 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 | ||
| tsimonq2 | jbicha: I'm just taking kitty, that's it. ;) (And, I'm here for questions.) | 17:43 |
| tsimonq2 | Here, kitty kitty kitty. | 17:43 |
| tsimonq2 | ogayot: 🐱🐱🐱🐱🐱🐱🐱🐱🐱🐱 :D | 17:48 |
| tsimonq2 | @pilot out | 17:48 |
| === 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 | (Top five favorite package names.) | 17:49 |
| Eickmeyer | tsimonq2 with the shortest flight ever. | 17:52 |
| tsimonq2 | XD | 17:53 |
| tsimonq2 | [PSA] When uploading to Ubuntu, use SSH, not FTP: lists.ubuntu.com/archives/ubuntu-devel/2023-November/042843.html | 17:57 |
| enr0n | adrien: your openssl SRU is at the stage where it needs SRU review, that's not something a patch pilot will do | 18:50 |
| 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:51 |
| enr0n | adrien: if you haven't already, you can ping ubuntu-sru in #ubuntu-release | 18:53 |
| adrien | I did some real-life pings last week but that wasn't very effective; I'll start this other kind of pings tomorrow :) | 19:05 |
| jbicha | @pilot out | 20:47 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!