**** BEGIN LOGGING AT Fri May 06 02:59:56 2022
May 06 11:14:26 <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
May 06 11:16: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
May 06 11:16:17 <waveform>  not work and may/may not get undone by the next netplan apply)
May 06 11:20:21 <ikonia> waveform: I was about to offer some help tidying up raspi-config
May 06 11:20:38 <ikonia> dissapointing that stuff is getting added to the repos like this (it's not the first I've seen) 
May 06 11:20:40 <waveform> ikonia, heh -- I'd look at the code before offering any help ;)
May 06 11:21:16 <ikonia> waveform: I have the fear...but also the will
May 06 11:21:39 <waveform> ikonia, imagine a mess of ~3000 lines of bash with a bit of lua thrown in for text manipulation (because ... why not)
May 06 11:21:58 <waveform> lots of it *heavily* raspios specific, so it'll never fit ubuntu particularly well
May 06 11:23:12 <waveform> (there's a reason I resisted calls for it to be added to the archive, but oh well)
May 06 11:23:55 <ikonia> waveform: that's interesting, I will take a look 
May 06 12:02:47 <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
May 06 12:07:42 <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 
May 06 12:07:44 <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
May 06 12:08:23 <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 
May 06 12:08:31 <ikonia> it doesn't matter, it's in 22.04 which is what I'm porting to 
May 06 12:08:37 <waveform> (and I'm running jammy, but then I have to :)
May 06 12:08:39 <ikonia> I was just curious as it seems an odd one to exclude
May 06 12:09:02 <ikonia> waveform: I suspected you would be, curious to how you're finding it after you put a lot of work into it
May 06 12:11:56 <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
May 06 12:11:56 <waveform>  within a minute of it booting it all "Just Works"
May 06 12:12:59 <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
May 06 12:13:17 <ikonia> maybe I can move away from that
May 06 12:17:23 <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)
May 06 12:20:51 <ikonia> I'm still not feeling snap is a good way for ubuntu to move
May 06 12:21:29 <ikonia> it feels like unity against, in terms of the attitude / disconnect from both the community and the wider linux world
May 06 12:27:44 <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
May 06 12:29:28 <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)
May 06 12:32:16 <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 
May 06 12:32:16 <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)
May 06 12:34:45 <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
May 06 12:35:33 <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
May 06 12:36:02 <ikonia> so that's really useful to hear your (acknwledged) personal view, different perspective is interesting
May 06 12:42:40 <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 
May 06 12:42:40 <waveform> interface that performs a single, or very limited number of tasks that you want to stay up to date and "Just Work")
May 06 12:44:26 <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
May 06 12:49:33 <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
May 06 12:49:52 <ikonia> so it's going to do the unity thing of making it a niche/propritary setup against the rest of the linux world
May 06 12:50:01 <ikonia> eg: Ubuntu != Linux
May 06 12:50:38 <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
May 06 12:53:23 <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
May 06 12:54:01 <ikonia> really ?
May 06 12:54:12 <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 :)
May 06 12:54:19 <ikonia> why would Mozilla ask for all FF debs to be removed ?
May 06 12:54:28 <ogra> because they are not maintained 
May 06 12:55:00 <ogra> the PPA is a community thing
May 06 12:55:16 <ikonia> yeah, but I thought that community PPA was still actively maintained ?
May 06 12:55:41 <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
May 06 12:56:01 <ikonia> that's interesting, I hadn't realised that
May 06 12:56:20 <waveform> (the old iceweasel/firefox story basically)
May 06 12:56:36 <waveform> (or whatever the "non-trademark" name was)
May 06 12:56:38 <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
May 06 12:56:56 <ogra> but i guess until the one major missing feature (nativee-messaging controller) is fixed they wont move 
May 06 12:57:02 <ogra> *native-
May 06 12:57:46 <ogra> once that is there all missing features (gnome extension installation, keepassxc, smartcard support) should work
May 06 12:58: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)
May 06 12:59:02 <ogra> ikonia, well, this was really on mozillas initiative
May 06 12:59:29 <ogra> (happily accepted on the ubuntu side indeed ... but they were the ones pushing for it basically) 
May 06 12:59:42 <ogra> snaps save immense amounts of manpower 
May 06 13:01:13 <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
May 06 13:02:13 <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
May 06 13:05:01 <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)
May 06 13:05:35 <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 
May 06 13:08:15 <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")
May 06 13:09:01 <ogra> ah, yeah, cross is always awful, no matter what packaging system you use (probably with the exception of tarballs 🙂 ) 
May 06 13:11:14 <ogra> i thought rpi-imager was electron though ? 
May 06 13:13:12 <waveform> nope, qt5
May 06 13:13:32 <waveform> (it does "look" electron-esque though, it's true :)
May 06 13:33:58 <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) 
May 06 13:34:25 <ikonia> the effort creating and maintaining it is appreciated and worth it, so easy to moan, but thanks is also due 
May 06 13:34:30 <waveform> ikonia, heh -- glad you think so -- still plenty to do on my side but nice to see it's appreciated!
May 06 13:34:55 <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
May 06 13:53:00 <Maik> honestley, 22.04 desktop is one of the best releases on the Pi 4
**** ENDING LOGGING AT Sat May 07 02:59:56 2022