=== Eickmeyer5 is now known as Eickmeyer
[17:33] <Eickmeyer[m]> arraybolt3: Hey! If you want to put 22.04.2 RCs through the paces, we (finally!) have an image: http://cdimage.ubuntu.com/ubuntustudio/jammy/dvd/20230216.1/
[17:33] <arraybolt3> Eickmeyer[m]: \o/
[17:33] <Eickmeyer[m]> I'm zsyncing right now.
[17:33] <arraybolt3> OK, guess I'll be tackling 22.04.2 RCs and LXQt today.
[17:33] <Eickmeyer[m]> Technically, testing could go for everyone.
[17:33]  * arraybolt3 disassembles victim laptop
[17:36] <arraybolt3> How on earth did I get a fingernail clipping stuck in my fan vent...
[17:39] <arraybolt3> Alright, dual testing laptops ready.
[17:48] <arraybolt3> Sigh. The ISO tracker is linking to MD5SUMS files rather than SHA256SUMS...
[17:48] <arraybolt3> Here's hoping my URL mod works.
[17:53] <Eickmeyer[m]> arraybolt3: zsync does the sums automatically, hence the big long reading of the seed file.
[17:53] <arraybolt3[m]> True, but it's not GPG-protected.
[17:53] <arraybolt3[m]> (I'm one of those kinda weird overly-security-cautious people who like to check stuff like that ;P)
[17:54] <arraybolt3[m]> (As opposed to HTTPS.)
[17:54] <Eickmeyer[m]> Not sure why that matters since it can't be man-in-the-middled.
[17:54] <arraybolt3[m]> It's an HTTP download over a cellular connection so...
[17:54] <arraybolt3[m]> Eickmeyer: Over unencrypted HTTP and multiple wireless connections, yeah technically it could be.
[17:54] <arraybolt3[m]> Is it going to be? Almost certainly not.
[17:55] <arraybolt3[m]> I mean I have never had a single maliciously interfered download in my life so far, but then again it only takes one to cause Serious Problems(TM).
[17:55] <Eickmeyer[m]> Yeah, but it would be caught by zsync since it's not pulling the entire file but hashes of it. If the hashes don't match what it's looking for, it'll error.
[17:55] <arraybolt3[m]> True, and it would have to be a pretty involved and targeted attack for someone to MiTM both the ISO and the zsync data.
[17:55] <Eickmeyer[m]> Exactly.
[18:12] <arraybolt3> Yikes, I need a faster flash drive. This red USB 2 drive has been rock-solid for reliability but good grief it is slow.
[18:12] <arraybolt3> Or I need one of those IODD devices you have :P
[19:06] <arraybolt3> Eickmeyer[m]: OK, a secure boot + UEFI install worked, but the GTK theming seems a bit wonky in GIMP. I assume this probably isn't a regression, but FYI. The Flame tool has a couple of spots where the theming makes text near-impossible to read, though it's still usable.
[19:06] <Eickmeyer[m]> arraybolt3: GTK theming in GIMP is rendered by GIMP's internal theme, not by the GTK theme in Studio.
[19:07] <Eickmeyer[m]> So, beyond our control.
[19:07] <arraybolt3> Oh yuck.
[19:07] <arraybolt3> Wonder why they do that :P
[19:07] <Eickmeyer[m]> You can set it to use the system GTK theme, but it's not default.
[19:08] <arraybolt3> And yeah, the 22.04.1 ISO has the same problem, so no regression.
[19:08] <arraybolt3> Alright, one successful test. Next!
[19:08]  * arraybolt3 fishes out Ethernet cable
[19:34] <arraybolt3> OK so the Broadcom WiFi driver problem is back, in Jammy this time.
[19:34] <arraybolt3> https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1993370
[19:34] -ubottu:#ubuntustudio-devel- Launchpad bug 1993370 in software-properties (Ubuntu Jammy) "Cannot install proprietary Broadcom WiFi drivers on Ubuntu Studio Kinetic" [Undecided, New]
[19:36] <arraybolt3> Hopefully bdmurray can fix that too, he fixed it in Lunar and has the fix committed in Kinetic.
[19:36] <arraybolt3> (I forgot to do verification for that in Kinetic though >_<)
[19:36] <arraybolt3> Actually the fix landed in LP upstream, is this something that we can just hork tsimonq2 for?
[19:37] <Eickmeyer[m]> arraybolt3: Report on the iso tracker please.
[19:37] <arraybolt3> Will do.
[19:38] <arraybolt3> Sigh. I enjoy testing but I always feel like I'm always depressing everyone else when something actually does go awry :P
[19:46] <Eickmeyer[m]> arraybolt3: No, not depressed. The broadcom thing is useful and much better knowing now than last minute.
[19:48] <Eickmeyer[m]> Now the fluidsynth bug in kinetic that's being reported.... that's depressing because there's nothing that can be done without rebuilding about 1/2 of the audio packages.
[20:35] <arraybolt3> Anyway, good news, I was able to install bcmwl-kernel-source, enroll a MOK, and then WiFi worked.
[20:35] <arraybolt3[m]> Gah, I keep using IRC because it's more comfy for me, but we can actually react and whatnot here.
[23:07] <OvenWerks> Eickmeyer[m]: We have a real time kernel? https://www.youtube.com/watch?v=1RAtZCkVMZs
[23:10] <arraybolt3> OvenWerks: It's an Ubuntu Pro feature, and I think Eickmeyer[m] wanted to avoid realtime kernels intentionally, or at least that's what I read from one of the Wiki pages.
[23:11] <OvenWerks> arraybolt3: No worries, I was just surprised to see that
[23:13] <OvenWerks> RT kernels _can_ cause more trouble than they are worth, such as lockups
[23:17] <Eickmeyer[m]> OvenWerks Yeah, not only an Ubuntu Pro feature, but intended for IoT and embedded devices per my conversations with Dimitri Ledkov.
[23:18] <OvenWerks> The kernel team has resisited RT for ever it seems  ;)
[23:20] <Eickmeyer[m]> Because of the maintenance costs. This would be part of the paid tiers of Ubuntu Pro for IoT and Embedded, as I understand it.
[23:20] <arraybolt3> Is it not free anymore? In beta you could use it with a free Ubuntu Pro token.
[23:21] <Eickmeyer[m]> arraybolt3 (@arraybolt3:libera.chat): It was never meant to be for regular desktops, per my conversations with Dimitri (xnox).
[23:21] <arraybolt3> I mean I don't particularly care I guess, I use desktop hardware.
[23:21] <arraybolt3> Eickmeyer[m]: I saw some people using it on desktops I thought? Could be wrong.
[23:21] <Eickmeyer[m]> In fact, as I understand it, won't even be available for such.
[23:22] <Eickmeyer[m]> And beta is just that: for testing. Final is different in scope.
[23:22] <arraybolt3> Huh, weird. Part of me now wants to try and enable it on a VM just to see what happens :P
[23:23] <OvenWerks> arraybolt3: your computer will go slower :)
[23:23] <Eickmeyer[m]> This is true. Realtime kernels actually make your computer respond slower on the GUI.
[23:24] <arraybolt3> ?! That's the opposite of what I would have expected...
[23:25] <Eickmeyer[m]> realtime is for hardware <-> hardware mostly.
[23:25] <arraybolt3> I can see various linux-image-realtime kernels in esm.ubuntu.com.
[23:25] <OvenWerks> arraybolt3: RT/lowlatency is about scheduling not speed
[23:25] <arraybolt3> So they at least advertise that they still have them.
[23:26] <arraybolt3> OvenWerks: Right but the lowlatency kernel sacrifices some raw speed in exchange for more responsiveness, right?
[23:26] <arraybolt3> (I know RT != lowlatency but I thought the concepts were similar.)
[23:27] <arraybolt3> Though this may be me showing just how little I know in this area ;P
[23:28] <OvenWerks> The difference betrween RT and low latency is very small actually. In RT an RT thread can take all CPU resources in low latency the rt thread can take most of it but some is set aside for everythign else.
[23:28] <OvenWerks> However, one can have more "throughput" by dealing with bigger chunks of data at a time
[23:29] <OvenWerks> this will seem faster. But if the cpu allows a big chunk to finish it's work scheduling for something like audio can be missed
[23:30]  * arraybolt3 has to go afk, brb
[23:31] <OvenWerks> So with big chucks of data going from the CPU to the video chip, video will redraw quicker, data will transfer to net faster, etc. but  small bit of audio might be missed giving a click or pop in the audio stream