[10:14] <ikonia> waveform: that's incredibly useful, thank you, I've got to take that in and check a few things now, thanks so much for typing hat
[10:16] <waveform> ikonia, no prob -- I'll try and sort out (some of) the mess that is raspi-config shortly but it'll take a while to SRU from kinetic (where the fix will initially wind up) to jammy. And while I can fix it looking at the right location (/boot/firmware/config.txt instead of /boot/config.txt) some stuff is much more complex (e.g. raspi-config assumes a dhcpcd networking setup and has no knowledge of netplan so all the networking stuff in their may/may
[10:16] <waveform>  not work and may/may not get undone by the next netplan apply)
[10:20] <ikonia> waveform: I was about to offer some help tidying up raspi-config
[10:20] <ikonia> dissapointing that stuff is getting added to the repos like this (it's not the first I've seen) 
[10:20] <waveform> ikonia, heh -- I'd look at the code before offering any help ;)
[10:21] <ikonia> waveform: I have the fear...but also the will
[10:21] <waveform> ikonia, imagine a mess of ~3000 lines of bash with a bit of lua thrown in for text manipulation (because ... why not)
[10:21] <waveform> lots of it *heavily* raspios specific, so it'll never fit ubuntu particularly well
[10:23] <waveform> (there's a reason I resisted calls for it to be added to the archive, but oh well)
[10:23] <ikonia> waveform: that's interesting, I will take a look 
[11:02] <ikonia> I'm curious do you have any understanding/view why 'podman' isn't in the ubuntu repos until 22.04 ? I'm looking at my debian 11 pi host, which has podman in 'main' (an old version 3.0.1) but that's not in the ubuntu repos, yet Jammi has 3.4 in it
[11:07] <ikonia> also are any of you running Jammy yet ? I'm curious to how you're finding it (especially on a pi) I'm currently copying the image to my SD card to test 
[11:07] <waveform> ikonia, erm - not sure I'm afraid -- looks like it was added in impish (https://launchpad.net/ubuntu/+source/libpod) but I'm not sure why it wasn't around before that -- I could hazard a guess it would be something to do with the dependencies
[11:08] <ikonia> waveform: I did think a similar thing on the dependencies, until I checked my debian host and at a glance they all line up with ubuntu 20.04 
[11:08] <ikonia> it doesn't matter, it's in 22.04 which is what I'm porting to 
[11:08] <waveform> (and I'm running jammy, but then I have to :)
[11:08] <ikonia> I was just curious as it seems an odd one to exclude
[11:09] <ikonia> waveform: I suspected you would be, curious to how you're finding it after you put a lot of work into it
[11:11] <waveform> a mixed bag -- on the one hand, I'm happy we've now got an LTS without u-boot in the default sequence (much less headaches for me!), and the server side of things is working pretty nicely (e.g. cloud-init handles wifi "out of the box" ... although not wifi regulatory domain which is still a bug-bear of mine because raspios does that "right" and we don't). So I can spin up a new pi server image, have my ssh keys imported, my keyboard layout set and
[11:11] <waveform>  within a minute of it booting it all "Just Works"
[11:12] <ikonia> that's cool, I've been working around that by having a puppet or ansible run straight after provisioining to pull in my settings
[11:13] <ikonia> maybe I can move away from that
[11:17] <waveform> the desktop side still has a lot of bits I (and others) need to work on, e.g. broken rendering of embedded browser controls, all the pain that the firefox snap caused (nativemessaging (argh!), initial seeding taking a while, etc.), wifi regulatory domain (again!), differing default user permissions for gpio (still!), and probably several other things I've forgotten (my bug bookmarks folder is currently several hundred items long)
[11:20] <ikonia> I'm still not feeling snap is a good way for ubuntu to move
[11:21] <ikonia> it feels like unity against, in terms of the attitude / disconnect from both the community and the wider linux world
[11:27] <waveform> I can understand the rationale for it but there's a couple of sides to snaps: there's the "shipping desktop apps" side (which is all the wider public tend to see of it), and the "embedded/secure infrastructure" side (Ubuntu Core and the like), which has far less visibility
[11:29] <waveform> the latter makes sense to me (but took a *long* time for me to get up to speed on, and I still get bitten by corner cases here and there)
[11:32] <waveform> the former (desktop apps) ... I understand the reasons: the modern browser release cycle is sufficiently brutal that it's basically impractical to ship a browser any other way (trying to keep them interwoven with the larger eco-system of stuff in the archive, especially across multiple releases and architectures, is all but impossible -- or at least far too expensive to contemplate). However (and I should stress this is my personal opinion), the 
[11:32] <waveform> results so far are ... less than ideal. I'm still using the debs from the mozilla PPA on my pi desktop because otherwise I can't use my password database (keepassxc)
[11:34] <ikonia> odd that you see it like that, as I was coming from the server/security aspect that 'I' see mostly (although I'm sure I have gaps) and I do see the value in principal to things like ubuntu core
[11:35] <ikonia> the desktop stuff I've never really looked at because I don't use the desktop really any more, but also the model for the server/security stuff just seems wrong at a basic level and I can't imagine it working well translating to a more complex need of the desktop
[11:36] <ikonia> so that's really useful to hear your (acknwledged) personal view, different perspective is interesting
[11:42] <waveform> on the core/iot side of things: once I dug under the veneer that snapd plasters over it and understood things like snap-interfaces == apparmor-profiles, and (some bits of) the signing/boot-fallback mechanisms (there's still plenty there I don't get, but a lot of it doesn't apply to the pi (yet) so I haven't read far into it), it largely made sense, at least when seen from the perspective of an embedded device (something with limited/no user 
[11:42] <waveform> interface that performs a single, or very limited number of tasks that you want to stay up to date and "Just Work")
[11:44] <waveform> at a server level (where you may well have an interactive console, and it's a much more complex prospect that's potentially running multiple services) that's a different story however
[11:49] <ikonia> waveform: so that part I can see the benifit off the linking into apparmor-profiles, I just wish it was more 'open' in terms of the work, but also more an approach across distros/pojects, it feels like this is another thing the wider community are not using inside ubuntu, and certainly not outside ubuntu
[11:49] <ikonia> so it's going to do the unity thing of making it a niche/propritary setup against the rest of the linux world
[11:50] <ikonia> eg: Ubuntu != Linux
[11:50] <ikonia> some quality ideas/things are being done in ubuntu, like netplan, but they are not being agreed with/adopted by the rest of the world
[11:53] <ogra> just be aware that the PPA might silently stop updating eventually ... mozilla asked to nuke all FF debs so i exoect this PPA to be gone eventually too
[11:54] <ikonia> really ?
[11:54] <waveform> ogra, indeed -- unfortunately that's my one option for password manager integration currently (the other workaround suggested was "use the auto-type facility" which .. doesn't work on wayland :)
[11:54] <ikonia> why would Mozilla ask for all FF debs to be removed ?
[11:54] <ogra> because they are not maintained 
[11:55] <ogra> the PPA is a community thing
[11:55] <ikonia> yeah, but I thought that community PPA was still actively maintained ?
[11:55] <ogra> mozilla switched to the snap as default for ubuntu ... not sure they will accept community maintained packages that are not within the trademark agreement
[11:56] <ikonia> that's interesting, I hadn't realised that
[11:56] <waveform> (the old iceweasel/firefox story basically)
[11:56] <waveform> (or whatever the "non-trademark" name was)
[11:56] <ikonia> I think that's an interesting statement (not picking on your wording) 'switched to snap for ubuntu' - this is the point I was trying to make that ubuntu appears to be going it's own way
[11:56] <ogra> but i guess until the one major missing feature (nativee-messaging controller) is fixed they wont move 
[11:57] <ogra> *native-
[11:57] <ogra> once that is there all missing features (gnome extension installation, keepassxc, smartcard support) should work
[11:58] <waveform> indeed -- and once that is in place, I will be moving back to the snap because (frankly) I *ought* to be using it to dog-food the ubuntu desktop experience on the pi (but, obviously, password manager integration is rather critical so I don't realistically have an option currently)
[11:59] <ogra> ikonia, well, this was really on mozillas initiative
[11:59] <ogra> (happily accepted on the ubuntu side indeed ... but they were the ones pushing for it basically) 
[11:59] <ogra> snaps save immense amounts of manpower 
[12:01] <ogra> packaging is 100x easier than debs (if you are actually not just re-packing deb binaries, which is usually creating an utter mess, but properly use snapcraft) and you only need to QA one single context, not 4 releases of different age with 5 architectures
[12:02] <waveform> this is indeed what I'd heard -- I'm not on the desktop team but had heard it was a request from mozilla which was eagerly jumped on because browser packaging/backporting/testing is a *very* time consuming and resource-intensive thing so offloading it to upstream is hugely preferable
[12:05] <ogra> sadly there is still some issue with FF first-startup time ... on the Pi this is hilarious 25sec for me ... (which is funny since chromium nearly starts instantly (well 5-8sec on first start 2-3 on subsequent)
[12:05] <ogra> theer must be somethign with the FF binary itself that makes it so slow ... since the packaging between FF and chromium doesnt really differ a lot 
[12:08] <waveform> however, while I'm sure firefox is "100x easier" to package in snaps than debs (even the deb included a ton of vendored-in/statically-bound stuff), I'd take issue with that as a general statement (certainly wasn't my experience when taking over the rpi-imager snap; but then that largely seems to be down to "cross-arch qt5 stuff")
[12:09] <ogra> ah, yeah, cross is always awful, no matter what packaging system you use (probably with the exception of tarballs 🙂 ) 
[12:11] <ogra> i thought rpi-imager was electron though ? 
[12:13] <waveform> nope, qt5
[12:13] <waveform> (it does "look" electron-esque though, it's true :)
[12:33] <ikonia> for all my moaning, it's still worth pointing out that the ubuntu pi images is pretty mega, and arguably the best modern linux image for the pi (hence keen to move to 22.04) 
[12:34] <ikonia> the effort creating and maintaining it is appreciated and worth it, so easy to moan, but thanks is also due 
[12:34] <waveform> ikonia, heh -- glad you think so -- still plenty to do on my side but nice to see it's appreciated!
[12:34] <ikonia> nothing is every pefect, and the worst critic are those involved, so I'd expect you to say that, but I get a huge ammount of value from it
[12:53] <Maik> honestley, 22.04 desktop is one of the best releases on the Pi 4