[00:14] <arraybolt3[m]> I'm thinking, any kernel module in the Ubuntu archives must either be signed, or it has a severe and unfixable bug (namely inability to use it with Secure Boot without overhauling the Secure Boot configuration in a way that doesn't even work on all systems).
[00:17] <arraybolt3[m]> We have tons of other "weird" kernel modules that are in Main I believe (usbip for one - that's something virtually no one uses, though I used it one time and it was really cool). I don't see why a video loopback module would be excluded, especially since that sounds way more like something people would use, like for sharing screens. Way more people are going to need to share their screens live than there are people who need to
[00:17] <arraybolt3[m]> attach USB devices over an Ethernet link. (At least I'd think so.)
[00:18] <arraybolt3[m]> (I guess I don't know if there's tons of weird modules in Main, actually, but I think my argument stands anyway.)
 there is a workaround.  sign it locally on system with a selfsigned cert
 its why mokutil exists among other things
[00:38] <arraybolt3[m]> That's the overhauling of the Secure Boot configuration. And it doesn't work on all systems.
[00:44] <arraybolt3[m]> Hmm. I thought I read that it didn't work on all systems in the Ubuntu wiki, but I can't find that now, so maybe it does work?
 unless your claim is substantiated nobody will believe it.  i have yet to see the local-sign-and-accept-key-in-mokutil fail
 except in like specialized archs or systems thatre using FIPS
[04:17] <guiverc> releae notes:  mention of 21.10 gone, wording on 20.04 changes massaged due to less text with 21.10 removal..
[04:17]  * guiverc just noting where I change/alter
[04:18] <guiverc> firefox snap issue altered @ end of paragraph (ie. improvements found on 22.04.1 media)
[04:20]  * guiverc notes the 20.04 to 22.04 upgrade looks good, did Dan work on it?  and I even see a link i wanted to include already there :)
[04:23] <guiverc> I've added a second #Installer section with the new 3.2.60 calamares; the original will need deletion 
[04:24]  * guiverc wonders if we should highlight the calamares upgrade with an extra line?
[04:25] <guiverc> I added a line about later.calamares; it can be removed if required/better-without
[04:31]  * guiverc skipping btrfs for now
[04:34] <guiverc> I've added a simple backports ppa paragraph just prior to 'upgrading to 22.04'
[04:43] <guiverc> ISO includes changes to "calamares-settings-lubuntu    1:22.04.4.1 , calamares-settings-ubuntu-common      1:22.04.4.1 , casper        1.470" so all tests need re-doing :(  but we can ignore the PROPOSED table on testing checklist :)
[05:05] <guiverc> note: casper changed to .1 with 20220715; yet older casper returned on 20220728.1 so I'm missing something..
[06:01] <guiverc> if anyone gets to confirm 22.04.1 BTRFS installs without issue; please ping me.. (I fear I'll not get to testing it today; next 24hrs)
 Will be testing this next 1 to 2 hours and will ping @guiverc when finished (re @lubuntu_bot: (irc) <guiverc> if anyone gets to confirm 22.04.1 BTRFS installs without issue; please ping me.. (I fear I'll not get to testing it today; next 24hrs))
[06:20] <guiverc> thanks @Leokolb
 @guiverc confirm BTRFS no error ISO JAmmy 2022-07-29.1
[06:20] <guiverc> record in the upper (main) section on testing checklist  & THANK YOU !!!!   YIPPEE !
[06:21]  * guiverc edited to update bits before, alas aborted when I got to casper... I'll recheck & edit testing-checklist later (working on UWN currently; just in from bird feed actually)
 ✔️ (re @lubuntu_bot: (irc) <guiverc> record in the upper (main) section on testing checklist  & THANK YOU !!!!   YIPPEE !)
[06:24] <guiverc> Thanks :)
 Just noticed that manifest for 2022.07.29.1 says casper 1.470 not 1.470.1 is this correct? @guiverc
[09:51] <guiverc> that's what I got, and had me confused... right now I'm doing UWN & not lubuntu so haven't explored far; I'd look for bug reports and why 1.470.1 was reverted maybe, but for now I'm happy to wait for next ISO, or I have time to chase up, read back logs in -release maybe
 casper 1.470.1 is proposed for jammy ... (re @lubuntu_bot: (irc) <guiverc> that's what I got, and had me confused... right now I'm doing UWN & not lubuntu so haven't explored far; I'd look for bug reports and why 1.470.1 was reverted maybe, but for now I'm happy to wait for next ISO, or I have time to chase up, read back logs in -release maybe)
[09:51] <guiverc> If we test what we have so far, ie. current ISO, that's all we can currently do I suspect
 agree.. (re @lubuntu_bot: (irc) <guiverc> If we test what we have so far, ie. current ISO, that's all we can currently do I suspect)
[09:52]  * guiverc waiting for my rmadison command to show details..
[09:53] <guiverc> yes I see what you do, we test what we have now & watch I guess :)
 Will call it good for this am and wait for next ISO (evening my time)
[09:56] <guiverc> :)   fyi:  my ^ (hours ago) will read incorrectly as I noted casper package change, but NOT the reversion... then confusion once I noted .1 was 15th July ISO... then finally noted mistake, why some of ^ makes no sense to any later readers
[17:05] <kc2bez[m]> Thanks for your work on the notes guiverc I have done some more work on it.
[17:05] <kc2bez[m]> Proofreaders welcome. https://notes.lubuntu.me/kN5uW5gMRBKXb0eyzF0RsA?both