[00:04] Perhaps we should make a lubuntu-extras package that we can use to deliver packages to users in any release? [00:04] I guess lubuntu-desktop sort of does that already. [00:04] Hmm, why isn't there a way to deliver the new packages then? Not able to know what language they installed in? [00:06] [telegram] Ack (re @tsimonq2: @guiverc @Leokolb @Roberalz etc. I'd appreciate some testing help with Backports Staging/Backports (if you see this later) :) ^^^^) [00:15] [telegram] Yeah, precisely arraybolt3. We could give them a debconf prompt, but that could potentially get messy. [00:15] yeah [00:15] [telegram] I don't know that I would SRU such a change that way, to be honest. [00:16] [telegram] I mean, we might consider backporting the installer change and such, but meh, depends if we want to put all that effort into what will soon be our LTS-1. [00:17] I don't like the idea of SRU-ing in a debconf prompt much either. [00:17] The installer change might be worth it though. Some people will probably still want to use 22.04 for a while while 24.04 "stabilizes". [00:43] Found why encrypted installations are failing: https://bugs.launchpad.net/ubuntu/+source/calamares/+bug/2043301/comments/7 [00:43] -ubottu:#lubuntu-devel- Launchpad bug 2043301 in calamares (Ubuntu) "lubuntu noble install failure - encryption" [Undecided, Confirmed] [00:43] apt-file find isn't telling me what package owns /etc/default/grub, any thoughts? [00:44] also perhaps we just need to ship a new file inside /etc/default/grub.d somehow [02:00] [telegram] Tbh I think it belongs hereish: https://github.com/lubuntu-team/calamares-settings-ubuntu/blob/ubuntu/noble/common/modules/before_bootloader_context.conf [02:00] [telegram] There is no file that *ships* it [02:00] [telegram] And we should be absolutely careful that we do not *duplicate* it [02:01] [telegram] Anyway, yeah your approach seems correct, except it's something done on runtime. [02:05] [matrix] https://github.com/calamares/calamares/releases/tag/v3.3.0-alpha5 [02:07] [telegram] Ooooooooh. [02:08] [telegram] I honestly think, by the way, that I'll hold off on a final release of 1.4 into Backports for maybe another 12-36 hours since this one seems to be a little more prickly than the last... [02:09] [telegram] That will be a major change for us. I'm going to wait somewhere between 3-7 days before uploading that, so we can get some existing stuff ironed out [02:58] Is shipping a new alpha maybe a bit too adventurous for the LTS? [02:58] (new alpha of Calamares) [02:58] Or are we willing to give it a shot and revert if something goes too wrong? [02:59] arraybolt3, the calamares in noble is a newer version already than mantic/23.10 had [03:00] though sorry if you were asking about something else.. I don't see an issue with new installer this early... unless the QA testers are hopeless :) [03:01] I meant there was an alpha5 of Calamares 3.3.0 released six hours ago. [03:02] guiverc: you and the testers do an amazing job, so I'm sure we'll have everything ironed out with your guys' help :) [03:03] tsimonq2: Thanks for your insight, I thought we might end up doing something like that :) If I have time, I'll try to shove a fix out the door tonight. [03:03] Actually... I mean, I'm sitting right here... [03:04] *fires up VM and starts making a mess* [03:12] tsimonq2: I'm actually not so sure this is the way to do things - how can we be sure that the file Calamares generates in this way will stick around? And if it gets deleted, it could result (probably will result) in update failures. [03:12] Also what would the repercussions be of having the option being specified in two different files? One will override the other but since they both say the same thing, who cares? [04:13] But, I have a working fix \o/ [04:13] Sheesh, took forever. [04:13] Trying to fight spam and code+test at the same time is not easy. [05:40] thanks arraybolt3 :) [12:07] [telegram] arraybolt3: show me the monaaay [12:07] [telegram] https://matterbridge.lubuntu.me/8b093c57/make_it_rain_money.mp4 [12:52] [telegram] arraybolt3: protip: always Git push. Even if you don't upload (and thus tag), I'm curious to see where you're at :) [12:53] [telegram] As far as I'm aware (@teward001 and @kc2bez probably know more), /etc/default/grub is automatically generated, and updates to it are handled via debconf. [12:54] [telegram] If we insert a value, we should make sure it's already there. If we insert a new value, even through a no-change rebuild, we should check that updates to GRUB correctly handle this [12:54] [telegram] I'd say that's an important element to a robust LTS [12:55] [telegram] *not already there [13:02] [telegram] We also need to consider some GUI option exposing a system-wide GRUB search, for Windows dual booting. I have this as a catch-all GRUB option on my local install, but I suspect we can narrow that down slightly to "okay, only the local disk" and have a clear warning/pop-up for the user [13:03] [telegram] Support for dual booting is already implemented, so we might just be able to push it there. I'll add this to my list [13:03] [telegram] Anyway, I'm going to wait for maybe one or two more QA signoffs while I finish the release announcement, then check back around lunch time to get that published [13:04] [telegram] As usual, Mr. Mitchell Tunnell and Marius Nestor will get the scoop a few hours ahead of time, per our existing agreement [13:05] [telegram] I'm also considering going on the Ask Noah podcast tonight to talk about Calamares. Let's see how far I get today, and if I need to push that interview back a week, I will [13:07] [telegram] @kc2bez also you're a Lubuntu Member, you get exclusives too ;) (re @tsimonq2: As usual, Mr. Mitchell Tunnell and Marius Nestor will get the scoop a few hours ahead of time, per our existing agreement) [14:47] Kay, looks like the rest of the 1.4 stack is waiting on armhf autopkgtests. Thanks to arraybolt3 for following up in -release about that. :) [15:02] I'll be working on $dayjob for the next 3-4 hours; if you need me just ping, but when I come back, I'd like to get the 1.4 announcement finished and the packages published. :) [16:05] tsimonq2: If you're talking about lxqt-menu-data re git push, I intentionally didn't push that since Git needs some unraveling (you have history that isn't uploaded yet). If you mean Calamares, I made a comment documenting the fix, didn't get it into code yet. [16:05] I mean Calamares. :) [16:05] But thanks for clarifying! :D [16:07] re /etc/default/grub, we don't need to modify that file. We can just drop an option in a file in /etc/default/grub.d. We already to that to make our GRUB menu look right, I don't see why that's not a viable solution here. [16:08] Just make a file like /etc/default/grub.d/lubuntu-crypto-grub.cfg and presto. That worked in my testing (though I used Calamares to drop the file, but I'm sure it will work if a package puts it there. [17:37] how about adding the GRUB config to um grubcfg.conf https://github.com/calamares/calamares/blob/calamares/src/modules/grubcfg/grubcfg.conf [17:38] lol wait that's a thing? [17:38] Sounds like the best idea so far. [17:49] tsimonq2: If you don't mind, I'd like to combine the upgrade to Calamares alpha5 and the encrypted installation fix into one upload. Is that OK, or should I push them out separately? [18:21] Okay, so I'm back. [18:22] arraybolt3: I would normally say hey, go for it, but unless you extensively test the Python-based modules (including automirror), I would say keep it separate for the time being. [18:22] +1 [18:22] arraybolt3: This was a pretty massive, alpha-level update that caused problems already in optimistic Arch distros. [18:24] Ouch. [18:27] OK, I'll throw together a fix for encrypted installs and maybe also hurl a wallpaper scaling solution into the mix. [18:27] First gotta test and make sure that the grubcfg.conf fix will actually work though. [18:28] well well well what have we here [18:28] grubcfg.conf already has "GRUB_ENABLE_CRYPTODISK: true" in it. [18:28] So is the appropriate cala module being ran correctly? [18:28] 'bout to find out [18:29] arraybolt3: Also, you don't happen to have any specific feedback for or against shipping an update to Backports, right? [18:29] Not yet, I haven't actually gotten a test VM together. [18:29] (Life has been very busy.) [18:29] No worries. I'll cut off the RFC on that in the next hour or so, doing another set of manual testing, before I push 'er all out. [18:30] kk, if it looks good to you then it probably is good. [18:30] I'll try and throw together a Jammy VM real quick though. [18:33] I noticed we didn't have "always_use_defaults" set to "true" in grubcfg.conf, so I set that and we'll see what happens. [18:33] That may be all that's needed. [18:33] If not, I'll try to debug why the module isn't gettig run. [18:33] *getting [18:34] * tsimonq2 grabs some food [18:34] arraybolt3: Thanks, for the millionth time, for your exceptional work in helping us get these big features through. [18:34] It'll calm down soon. :) [18:35] Glad to help :) [18:35] Also I should work more on the network manager... and there's another install failure. Fun. [18:36] oooooooo, found something [18:36] tsimonq2: Did something change with mkinitcpio recently? [18:37] The grubcfg module is "silently" bombing out with "Target cmd: ("sh", "-c", "grep -q \"^HOOKS.*systemd\" /etc/mkinitcpio.conf") Exit code: 2 output: grep: /etc/mkinitcpio.conf: No such file or directory" [18:38] though... it survived a nonzero exit code earlier in the process so...? [18:39] At any rate the module is loading and running but it seems to die for before it actually edits the file. [18:40] um [18:40] we shouldn't be using mkinitcpio? [18:41] that's what arch uses for initramfs [18:41] we use update-initramfs [18:42] the module looks for it but I think it should ignore it if it's not there. [18:44] could this be a red herring? just a check it does before moving on? or does the module actually die there? [18:44] I think it's a red herring looking at the code. [18:45] oh now here's something weird, the module seems to add LUKS-related stuff to the config file successfully. But... cryptodisk isn't set? [18:47] if cryptodevice_params and not unencrypted_separate_boot: [18:47] grub_config_items["GRUB_ENABLE_CRYPTODISK]" = "y" [18:47] so now the question I guess is how those are getting set [18:47] does anyone know when this stuff broke anyway? Was it right after a Calamares update or something? [18:51] i don't know but i don't think we want always_use_defaults [18:51] it didn't fix anything either so you're probably right [18:51] Just tried adding some debugging lines to the main.py file for the grubcfg module, now running Calamares in hyper-debug mode. [18:54] oh wow, it actually tries to set the cryptodisk setting [18:54] alright, digging further [19:02] why on earth! We don't even use a newer version of Python or anything! [19:24] ah great, it's a Cala alpha4 bug almost certainly. Found the commit that most likely broke things, and it's an overhaul of the grubcfg module. [19:33] Well at least that means I'm not barking up the wrong tree :P The function (method? function? whatever those are called in Python) that actually updates the config file has some, er, questionable logic in it, so I'm guessing that's where our bug is. [19:34] in particular it sorta looks like they're just printing things to stdout when they meant to save them to a file [19:42] ah ok, it's not as bad as I thought, they're using things correctly, they seem to just be forgetting that there may be options in grub_config_items that aren't in the file yet. [19:52] alright, this should work [19:52] In the mean time, /me prepares an upstream bug report [19:54] ahem, need to not reference variables that don't exist [19:58] YAY it worked! Woohoo! [20:10] https://github.com/calamares/calamares/issues/2233 [20:10] -ubottu:#lubuntu-devel- Issue 2233 in calamares/calamares "[REGRESSION] grubcfg module fails to append missing items to the end of /etc/default/grub" [Open] [20:13] tsimonq2: Encryption failure bug has been cornered, captured, and emtombed in a bug report to upstream. Shall I patch it downstream now or wait for upstream to fix it? [20:14] I would say throw it in an upstream PR, patch it downstream, and link your PR in the DEP-3 headers. [20:14] * arraybolt3 likes it [20:14] [ade] is usually pretty quick about merging clearly solid patches with good bug reports. [20:14] Not like LXQt XD [20:14] though I'm not sure they'll like my choice of variable names [20:14] Meh, figure out something agreeable and ShipIt :) [20:14] kk, sounds good [20:14] Thanks for your help! [20:15] Hey, what was that other issue with the cdrom stuff? [20:15] Do we have clear instructions to reproduce that? [20:15] Other issue? the slow install times I think [20:15] No clue how to reproduce that [20:15] I don't see them as particularly slow, hm [20:15] We could take a peek at which rsync flags we're using, though. [20:16] Perhaps you're installing in English and lotuspsychje is installing in Dutch? [20:16] They said that the file copying seems to go fast but the package downloading slows things down, I believe. [20:16] In which case the whole issue may have been the archive being a bit slow. [20:16] Here's my general take on this... [20:17] It *will* require a new upstream feature, but we should really have a way to background a job. [20:17] I'd like to be able to download snaps and packages in the background while the squashfs is extracting. [20:17] If we implement some kind of limiters on either end, we could also take care of locale-gen in the background. [20:18] We might have a real opportunity to speed some of this up, but it's going to take quite a bit of upstream work, so we might punt it, at least a few weeks. [20:18] Anyway, if someone does side-by-side installs of 23.10 and Noble, and Noble is significantly slower, I'd say we have a bug. [20:18] If they're the same speed but slow anyway, yeah, we're working on it. Heh. [20:19] Also, let's confirm that locale-gen is done *after* langpacks are installed (I mean, unless we have another step at the end to run it twice, confirming). [20:20] Upstream there are existing "prototype" functions that can be extended for a job, either to background something in a Special way, or create a new class of job. [20:20] I have some issues upstream regarding consistency in functionality between a few of those. Beware, there be dragons. That being said, seems like a good first step. [20:20] Anyway, I digress. [20:21] $dayjob did take me a little later, but when I get back from a short break, I think I'll finally push Backports out. [20:21] I'll migrate the packages and set a one-hour timer at the same time, to give the Launchpad publisher (and our media folks) time to process things. [20:22] Once that timer is up, the blog post goes out. [20:26] I never did manage to test them :P but you and I think guiverc did that already so push away! [20:32] Just doing one more smoke test, grabbing screenshots, then I'll press Buttons. [20:47] Let's see if this works, in the meantime: https://launchpad.net/ubuntu/+source/calamares-settings-ubuntu/1:24.04.2 [20:53] Nah, I'm going to wait and dogfood this one first... [20:54] My hope is that the power management doesn't continue to crash, like it's doing. [20:55] * arraybolt3 goes and takes a shower, will be gone for a while [20:55] Have fun, don' [20:55] t slip :P [20:55] (Like I apparently just did, when typing. :P) [21:23] Kay, all of those packages have been copied. [21:26] Lead time given to Marius Nestor, ETA about 4:15-4:20 PM US Central Time. [21:45] Kay, looks like I also need to prepare *two* hotfixes... [21:45] One for the power manager to not automatically spill the hot beans all over itself on desktop machines, due to my new change. [21:45] And another, it seems, to add the "Leave" menu back to lxqt-menu-data... >_< [21:46] Neither are showstoppers but both are high-priority... [21:54] My *guess* is that the issue with lxqt-powermanagement is the way I nested things, let's see if this works. [21:56] Missing build dependencies: liblxqt-globalkeys-ui1-dev (>= 1.4.0), liblxqt-globalkeys1-dev (>= 1.4.0), liblxqt1-dev (>= 1.4.0) [21:57] Well, waiting on this guy to migrate, it looks like. [21:57] I copied it all in one run, so I'm thinking it'll all *publish* in one run, too. [21:57] If it doesn't, prepare for anarchy. :P [21:58] (There's a reason I gave it this much time; Backports Staging actually got to 500+ MB, so copying all of that *will* take time.) [21:58] Especially serially and on one thread, Launchpad-style. :P [22:00] I think on that note, I'll wait a minute before doing the lxqt-menu-data stuff (that is, assuming I figure it out). :P [22:13] ugh, sorry to hear things are being sticky [22:15] * arraybolt3 is having a convo with dalto8 in the Calamares bug report, and between my typos and a disagreement about the source of the bug things are a bit sticky there too [22:19] I see that ;) no worries [22:20] I have the menu data fix done and uploaded, that should honestly migrate right at the next Britney run. [22:20] We'll want to have some stricter depends to explicitly pull that in with Backports. [22:20] I just retried powermanagement, let's see how many times I have to poke it. [22:20] nice [22:25] Whoops, powermanagement has been one of those weird packages that need a backport. [22:25] Uploaded a better copy, that might actually be it this time. [22:25] In the meantime, lxqt-menu-data will be going straight through once it's published. [22:25] I'll be brainstorming ways to get it on everyone's installs. [22:30] Kay, so this is problematic. I'm just going to revert my powermanagement patch altogether, and see what that does. [22:36] Taking a quick break. [22:36] https://lubuntu.me/jammy-backports-22-04-3-lxqt-1-4/ [22:36] Already blasted on Twitter and Telegram. [22:36] I also translated it into Spanish ;) [22:37] woot woot! [22:37] sigh, wish we knew why X-Leave is happening but oh well, definitely livable. [22:37] and soon enough we'll probably figure it out and push a fix [22:40] [telegram] That's the lxqt-menu-data fix I literally just uploaded ;) [22:42] oh lol, nice! [22:42] * arraybolt3 must be tired and not paying enough attention [22:44] [telegram] Ain't no rest for the wicked XD [22:45] oh dang [22:47] Or weary [22:50] Alright, patching Calamares now. [22:51] [telegram] Wheeeeeeeee. [22:51] [telegram] /me passes arraybolt3 a Red Bull and hides from RikMills :P [22:53] Sigh. Guess what's broken. [22:53] watch file for Calamares. [22:54] * arraybolt3 hopes my watch file hack from way earlier still works [23:02] can I just say I hate watch files? [23:02] They're so convenient in theory and such a massive pain in practice. [23:04] [telegram] I mean, regexps are super powerful. [23:06] yes, but uscan gives rather bad debugging info, and my regex matches in regex101.com and not in uscan. [23:08] hrm, well it almost works now [23:19] Sheesh, difficult, but got it working. [23:19] Watch it stop working as soon as we're done with alpha versions >_< [23:20] anyway, doing a build of Cala with the patch, wish me luck [23:31] I: calamares: spelling-error-in-binary aKS ask [usr/bin/calamares] [23:31] seriously? :P [23:32] [telegram] LMFAO [23:33] [telegram] arraybolt3: Hey, real quick, do you have a Backports machine handy? [23:33] Not yet :-/ [23:33] * arraybolt3 starts the install that I'll inevitably need [23:34] Installation underway. [23:35] [telegram] When you do, in a VM (or Desktop), could you try the following steps? [23:35] [telegram] 1) upgrade to the current Backports repo, reboot, confirm it's crashy [23:35] [telegram] 2) install my wonderful update from Backports Staging, reboot [23:35] will do [23:35] [telegram] 3) potentially celebrate since powermanagement is less crashy [23:35] [telegram] thanks :) [23:36] [telegram] Dinner time here, I'll be back in < 1 hour [23:37] Gotta do The Works on this package before it's ready to publish (copyright update, fixing weird Lintian errors, etc.) so... yeah. [23:40] * arraybolt3 really wishes Quilt would let me modify the header of a patch that isn't applied yet [23:49] alright let's see how much damage I did [23:51] also btw Backports installation is in progress [23:54] Rebooting into Backports LXQt 1.4.0... [23:55] Power Management crashed too many times. So yes, crashy. [23:56] lxqt-menu-data is recognized as a NEW package, interestingly [23:58] And crashy after upgrade. [23:58] tsimonq2: Backports Staging did **not** fix Power Management being crasy. [23:58] *crashy [23:59] X-Leave is solved nicely though :)