| arraybolt3[m] | OK, small mystery to be solved at some point. For some reason in a fresh install of Lubuntu 22.04.1, pcmanfm-qt is set to use xterm as the default terminal (which isn't installed by default, which leads to the "Open in terminal" feature being entirely broken). I suspected a problem in our configuration and dug around in lubuntu-default-settings, only to discover that the default settings for pcmanfm-qt specifically set the default | 04:19 |
|---|---|---|
| arraybolt3[m] | terminal emulator to qterminal. I dug in /home/user/.config to see if the settings were getting overridden, and while the terminal was set to qterminal (since I had specifically set it to that), I noticed that there were conflicting settings in there (the default archiver being set to file-roller even though the defaults set it to lxqt-archiver or something). Any clue why a brand-new user would have faulty overriding settings? | 04:19 |
| arraybolt3[m] | Also I've not noticed this problem in Lunar. | 04:21 |
| arraybolt3[m] | I'm also not noticing the problem in the live Jammy ISO. I'm doing an install test now. (I'm currently not working on LXQt since my brain isn't working at max performance and I'm trying to multitask) | 04:27 |
| arraybolt3[m] | Interesting, a fresh, non-updated installation doesn't have this problem. | 04:38 |
| * arraybolt3[m] updates and sees what happens, hopefully this isn't a case of user-done-mangled-something-and-forgot-about-it | 04:39 | |
| arraybolt3[m] | (The user being me, in this instance...) | 04:39 |
| arraybolt3[m] | grr... ran an update and everything's still working fine. So I dunno what went wrong with my desktop installation, but it turns out I can't reproduce the error now. Guess that's one less thing to worry about! | 04:56 |
| lubot | [telegram] <Leokolb> New bug updating Jammy daily 1998937 | 14:54 |
| lubot | [telegram] <Leokolb> https://bugs.launchpad.net/ubuntu/+source/calamares/+bug/1981879 | 14:54 |
| -ubot93:#lubuntu-devel- Launchpad bug 1981879 in calamares (Ubuntu) "Calamares install fails - Bootloader installation error" [Undecided, New] | 14:54 | |
| lubot | [telegram] <Leokolb> Sorry ..https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1998937 | 14:56 |
| -ubot93:#lubuntu-devel- Launchpad bug 1998937 in update-notifier (Ubuntu) "Lubuntu Jammy - full upgrade freeze waiting for config file prompt" [Undecided, New] | 14:56 | |
| tsimonq2 | Looks like lubuntu-update-notifier - could be wrong | 14:59 |
| tsimonq2 | And I've heard some rumblings about a GRUB update, so if that's reproducible, let me know so I can escalate to the right people | 15:00 |
| lubot | [telegram] <Leokolb> Yes - reproducible on another machine in a live session!! (re @lubuntu_bot: (irc) <tsimonq2> And I've heard some rumblings about a GRUB update, so if that's reproducible, let me know so I can escalate to the right people) | 15:47 |
| lubot | [telegram] <Leokolb> THe error appears after the text preparing confuguration of ssdm...see the screenshot in the bug report | 15:48 |
| tsimonq2 | @Leokolb Is the first one a Jammy-only bug? (Re: Calamares) | 15:54 |
| tsimonq2 | Re: the second one, let me take a peek | 15:56 |
| LeoK[m] | The first one not reproducable ...the second one reproducible | 15:59 |
| LeoK[m] | Disregard the Calamares bug... | 16:00 |
| tsimonq2 | Okay, no worries | 16:01 |
| tsimonq2 | Re: the Calamares bug, could you change the bug status appropriately, if you have the time? (If you can't reproduce it, have heard nothing about it, and it doesn't seem to be a thing anymore, maybe it's worth marking it as Invalid... I would have to read up on bug statuses again) | 16:02 |
| LeoK[m] | Will do ...invalid.. | 16:02 |
| tsimonq2 | (Just a technicality since Launchpad cleans it up at that point. Easier when triaging later... ;) ) | 16:02 |
| tsimonq2 | Er, I'm sorry | 16:03 |
| LeoK[m] | Done | 16:03 |
| tsimonq2 | Not invalid, incomplete heh | 16:03 |
| tsimonq2 | (That was my bad, I'll fix it, I'm sorry about that) | 16:03 |
| LeoK[m] | ok redone!! | 16:04 |
| tsimonq2 | https://wiki.ubuntu.com/Bugs/Bug%20statuses :) good reading | 16:05 |
| tsimonq2 | Leo K: bug 1998254 seems relevant | 16:13 |
| -ubot93:#lubuntu-devel- Bug 1998254 in sddm (Ubuntu Kinetic) "[SRU] sddm with multiple monitors can result in screen overlays and insets" [High, Fix Committed] https://launchpad.net/bugs/1998254 | 16:13 | |
| tsimonq2 | Eickmeyer: ^^^^ bug 1998937 seems to indicate a slight issue with the SDDM patch | 16:14 |
| -ubot93:#lubuntu-devel- Bug 1998937 in lubuntu-update-notifier (Ubuntu) "Lubuntu Jammy - full upgrade freeze waiting for config file prompt" [Undecided, New] https://launchpad.net/bugs/1998937 | 16:14 | |
| Eickmeyer[m] | Config file prompt? | 16:15 |
| tsimonq2 | hmm | 16:16 |
| tsimonq2 | maybe | 16:16 |
| tsimonq2 | ugh that would be a fun bug to fix... | 16:16 |
| Eickmeyer[m] | That makes no sense. | 16:16 |
| Eickmeyer[m] | No, that's not the patch as it only changes the xrandr. | 16:17 |
| Eickmeyer[m] | And if it were the patch, there'd be no gui, therefore no prompt for username/password to begin with. | 16:18 |
| Eickmeyer[m] | Script is long-since exited by the point of that bug. | 16:19 |
| Eickmeyer[m] | Oh, this is an upgrade. | 16:20 |
| Eickmeyer[m] | Still, doesn't make sense as it's patching a file before it's written. | 16:20 |
| tsimonq2 | sddm0.19.0-2ubuntu2 | 16:21 |
| tsimonq2 | (that's what's in Jammy daily) | 16:21 |
| Eickmeyer[m] | It's literally a Quilt patch though. | 16:21 |
| Eickmeyer[m] | It'd be one thing if it were a postinst patch, but it's not. | 16:21 |
| Eickmeyer[m] | All dpkg knows to do in this case is replace one file with another. | 16:22 |
| Eickmeyer[m] | Has anybody else tried to reproduce this? | 16:22 |
| tsimonq2 | I'm able to reproduce it, just now, yeah | 16:25 |
| * tsimonq2 sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/10856892c62afc943d425cea6b45416cf96e96d9 | 16:25 | |
| lubot | [telegram] <Leokolb> Just upgraded an older Jammy VM and got the bug ..makes 3 boxes for me 2 barebone and one VM | 16:25 |
| Eickmeyer[m] | Ok, so there's the problem, it's a mainscript issue. update-manager (and Discover) know how to graphically prompt the user. lubuntu-update-manager has no such mechanism. Therefore, it's not a bug in the sddm patch. | 16:28 |
| tsimonq2 | concur | 16:28 |
| lubot | [telegram] <Leokolb> More on the bug ...after trying to shutdown Lubuntu by selecting leave and the shutdown ..the system just logs the user out ..no shutdown .. | 16:33 |
| * tsimonq2 sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/e730d6499be58b65842eaf5b8dbedb130621f58e | 16:37 | |
| * tsimonq2 sighs | 16:38 | |
| LeoK[m] | Just updated the VM and now new updates and all good ..will test the other 2 barebone machines | 16:39 |
| lubot | [telegram] <Leokolb> Updated box #1 and now all good... | 16:42 |
| kc2bez[m] | > <@tsimonq2:linuxdelta.com> ```... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/868010e8598d0faf3565cf92b8147f497afd8ac8>) | 16:44 |
| tsimonq2 | I don't know... | 16:50 |
| tsimonq2 | This bug really sucks. | 16:50 |
| lubot | [telegram] <Leokolb> Really weird ...now box number 2 has bug after install..but I again rebooted and did another full system upgrade (manually selected from menu) and all now good..can someone else also test this? | 16:51 |
| tsimonq2 | Maybe RikMills has more information on this particular issue, but when you use Discover to do the updates, Xsetup.dpkg-dist now has the config, not Xsetup - so it's a Kubuntu bug, too (kind of) | 16:51 |
| tsimonq2 | I have zero idea what Kubuntu uses for release and distro updates these days, I would imagine Discover | 16:51 |
| tsimonq2 | I asked about this in #ubuntu-devel, and vorlon is NACK on re-implementing update-notifier without depending on its core library | 16:52 |
| tsimonq2 | Obviously we don't want to ship a GTK frontend for anything by default unless we have to | 16:53 |
| tsimonq2 | This leaves us in a tricky spot... | 16:53 |
| tsimonq2 | A) This will break pretty obviously once that SDDM update lands. We have about that long to get a patch done, tested, and released | 16:53 |
| lubot | [telegram] <Leokolb> What about users the have Jammy and get update notifications? | 16:54 |
| tsimonq2 | Yeah, the SDDM update breaks that usecase completely | 16:55 |
| tsimonq2 | And again | 16:55 |
| tsimonq2 | It's NOT SDDM itself breaking it | 16:55 |
| tsimonq2 | It's a lack of implementation in Qt-based frontends | 16:55 |
| Eickmeyer[m] | tsimonq2: Considering Studio uses the *exact same mechanism* I can tell you . It's Discover, which uses PackageKit as the backend. For release upagrades, it's do-release-upgrade with the Qt frontend. | 16:56 |
| tsimonq2 | Qt frontend or KDE frontend, for the latter? | 16:57 |
| tsimonq2 | (Has anyone actually successfully done a GUI do-release-upgrade with Lubuntu OOTB?) | 16:57 |
| Eickmeyer[m] | Well, DIscover is a KDE frontend, so there you go. | 16:58 |
| Eickmeyer[m] | Oh, you mean do-release-upgrade. | 16:58 |
| Eickmeyer[m] | Well, there is a recently implemented (by me) update notifier: plasma-distro-release-upgrader, just backported into Jammy, Focal, and Kinetic. | 16:59 |
| Eickmeyer[m] | Pretty sure it won't work in LXQt. | 17:00 |
| Eickmeyer[m] | The exact command that we tell users to pass is do-release-upgrade -m desktop -f DistUpgradeViewKDE in Krunner. | 17:01 |
| Eickmeyer[m] | Though, with plasma-distro-release-upgrader, that'll soon be moot. | 17:01 |
| Eickmeyer[m] | I think the interface is simply Qt despite the flag saying "KDE". Remember, back in the early days, KDE was the only Qt-based desktop. | 17:02 |
| kc2bez[m] | <Eickmeyer[m]> "The exact command that we tell..." <- Our instructions are the same and yes we have tested it. I guess sub either Qterminal or lxqt-runner for Krunner but yeah the same. | 17:06 |
| lubot | [telegram] <Leokolb> I test this numerous times using that command for every release....just info (re @lubuntu_bot: (irc) <kc2bez[m]> <Eickmeyer[m]> "The exact command that we tell..." <- Our instructions are the same and yes we have tested it. I guess sub either Qterminal or lxqt-runner for Krunner but yeah the same.) | 17:08 |
| Eickmeyer[m] | Honestly, I could probably, in the sddm package, override all of this by making a "maintscript" with "rm_conffile /usr/share/sddm/scripts/Xsetup 0.19.0-2ubuntu2~" in it. Simon Quigley thoughts? | 17:11 |
| tsimonq2 | <tsimonq2> "I asked about this in #ubuntu-..." <- To clarify, what I am hearing is that a platform requirement is using do-release-upgrade + update-manager-core. Whatever is built on top of that is up to us. | 17:12 |
| tsimonq2 | Eickmeyer[m]: -1 | 17:13 |
| tsimonq2 | We still have to account for the fact that this is a global configuration file | 17:13 |
| tsimonq2 | I would certainly be mad if I put quite a bit of work into my own Xsetup and an update just flat out wiped it | 17:13 |
| Eickmeyer[m] | Fair, and there might be user overrides. | 17:13 |
| tsimonq2 | Yeah | 17:13 |
| tsimonq2 | Again, I don't think SDDM needs to be patched further for this issue | 17:14 |
| tsimonq2 | The existing changes are appropriate... enough | 17:14 |
| tsimonq2 | And, how we didn't catch this sooner is beyond me | 17:15 |
| tsimonq2 | We need a few things... | 17:15 |
| kc2bez[m] | me too | 17:15 |
| tsimonq2 | A) Is there a GUI for release upgrader? At least a desktop entry? | 17:15 |
| tsimonq2 | A.1) Does that frontend look like KDE theming or is it just generic Qt theming? | 17:15 |
| tsimonq2 | B) lubuntu-update-notifier needs to be rewritten | 17:15 |
| tsimonq2 | B.1) In PyQt6 | 17:15 |
| tsimonq2 | B.2) Using upgrade-manager-core on the backend | 17:16 |
| tsimonq2 | B.3) And tested, with packages just like this | 17:16 |
| tsimonq2 | This should have been in the autopkgtest... | 17:16 |
| tsimonq2 | Overall, from a user perspective, I'm surprised this hasn't been raised yet, simply because a pure GUI workflow is broken | 17:16 |
| lubot | [telegram] <Leokolb> I test Jammy lubuntu 2 or 3 times a week ...so I have no idea either (re @lubuntu_bot: (irc) <tsimonq2> And, how we didn't catch this sooner is beyond me) | 17:16 |
| kc2bez[m] | The release upgrade tool does not have a desktop entry, it needs to be invoked manually. | 17:16 |
| kc2bez[m] | I agree with B but I think we already do B.2 | 17:17 |
| tsimonq2 | Are you 100% sure? | 17:18 |
| kc2bez[m] | No | 17:18 |
| kc2bez[m] | I am not looking at the code. | 17:18 |
| * tsimonq2 sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/86e1dde1ecfd86585f604123f057b80589bcf6d6 | 17:18 | |
| tsimonq2 | ...which depends on update-manager-core | 17:19 |
| tsimonq2 | okay | 17:19 |
| kc2bez[m] | cool | 17:20 |
| kc2bez[m] | still need to prompt folks somehow | 17:20 |
| tsimonq2 | "vorlon> it's the update-manager functionality rather than the update-notifier functionality that concerns me. Having independent implementations of the notifications is all nice and good, but update-notifier dispatches to update-manager (which supports multiple UI frontends) for the actual upgrade" | 17:22 |
| lubot | [telegram] <Leokolb> Just tested todays Jammy (landed a few mins ago ) no bug in live session . am running an install now hang on .. | 17:22 |
| tsimonq2 | sddm0.19.0-2ubuntu2.2 that's because the new SDDM is now on the ISO | 17:23 |
| lubot | [telegram] <Leokolb> ok.. | 17:23 |
| kc2bez[m] | I mean any config change could spark this. It just happened to be SDDM this time. | 17:24 |
| lubot | [telegram] <Leokolb> At any rate todays ISO is good and error free... | 17:25 |
| kc2bez[m] | We'll take the small wins when we can get them I guess. | 17:26 |
| tsimonq2 | https://pythonhosted.org/aptdaemon/aptdaemon.client.html#AptTransaction.config_file_conflict | 17:34 |
| tsimonq2 | https://pythonhosted.org/aptdaemon/aptdaemon.client.html#aptdaemon.client.AptTransaction.resolve_config_file_conflict | 17:34 |
| tsimonq2 | https://pythonhosted.org/aptdaemon/aptdaemon.client.html#signal-config-file-conflict | 17:35 |
| arraybolt3[m] | OK well someone's been busy while I've been gone. | 18:00 |
| * arraybolt3[m] reads backlog | 18:00 | |
| tsimonq2 | I now have a local prototype of the dialog box in lubuntu-update-notifier | 18:12 |
| arraybolt3[m] | So what happened? I missed something skimming through. | 18:13 |
| tsimonq2 | > <@tsimonq2:linuxdelta.com> ```... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/8243b9e6dbde857a98811ddfd035c22827f4712b>) | 18:14 |
| arraybolt3[m] | Ohhhhhh. | 18:14 |
| arraybolt3[m] | And that prompt is occurring because why? | 18:15 |
| arraybolt3[m] | How did an SDDM patch cause that? I ask because that doesn't make sense with my understanding of how packaging works. | 18:16 |
| arraybolt3[m] | (A Quilt patch shouldn't do that, I don't think.) | 18:16 |
| tsimonq2 | Because the SDDM update modifies a configuration file, and by default apt will prompt before clobbering global config files | 18:16 |
| tsimonq2 | arraybolt3[m]: A quilt patch to a configuration file :P | 18:16 |
| arraybolt3[m] | Oh. I didn't realize that file was already there by default. | 18:17 |
| arraybolt3[m] | Tar. | 18:17 |
| tsimonq2 | In LXQt we work around that by making a copy of the global config and storing it in the home directory | 18:17 |
| tsimonq2 | That way, config file updates are delivered smoothly and it's up to the user to adapt their config accordingly | 18:17 |
| tsimonq2 | In this case, it's for SDDM... so there is no "let's just copy this to $HOME" :P | 18:18 |
| * tsimonq2 uploaded an image: (33KiB) < https://libera.ems.host/_matrix/media/v3/download/linuxdelta.com/vHciBPrwEFmiIeVVkZVZKyzs/image.png > | 18:19 | |
| tsimonq2 | That's my prototype GUI | 18:19 |
| tsimonq2 | And, that works | 18:20 |
| arraybolt3[m] | Throw a PPA at me and I'll try it. | 18:25 |
| arraybolt3[m] | Or a .apt file. | 18:26 |
| arraybolt3[m] | Or shoot, just hand me the code and I'll package it in. | 18:26 |
| tsimonq2 | I'll throw it in a PPA and get you some instructions here shortly | 18:26 |
| tsimonq2 | arraybolt3: In the meantime, please download + install 22.04.1 in a VM somewhere | 18:29 |
| arraybolt3[m] | Got the ISO, booting. | 18:29 |
| tsimonq2 | (You can fully update the installation, but just ensure you don't have -proposed enabled. The perfect test case would be a fully-updated Jammy system with sddm version 0.19.0-2ubuntu2) | 18:30 |
| arraybolt3[m] | tsimonq2: Just to be sure, the SDDM update is in -proposed, or I'm supposed to update everything but leave SDDM at the older version, then try to upgrade it? | 18:31 |
| tsimonq2 | arraybolt3[m]: The SDDM update is in jammy-proposed | 18:31 |
| arraybolt3[m] | K, got it. | 18:31 |
| tsimonq2 | Once you're at that baseline, you should enable the PPA/install the debs manually for just the upgrade notifier, enable -proposed in your sources.list file, run sudo apt update, and then run lxqt-sudo lubuntu-upgrader | 18:32 |
| tsimonq2 | * Once you're at that baseline, you should enable the PPA/install the debs manually for just lubuntu-update-notifier, enable -proposed in your sources.list file, run sudo apt update, and then run lxqt-sudo lubuntu-upgrader | 18:32 |
| arraybolt3[m] | Alright, install done, updating. | 18:33 |
| tsimonq2 | https://launchpad.net/~tsimonq2/+archive/ubuntu/lubuntu-update-notifier/+packages | 18:42 |
| arraybolt3[m] | Still about 20s of download left on updates. | 18:42 |
| tsimonq2 | Still about 20h left for the LP publisher ;P | 18:43 |
| arraybolt3[m] | OK, now they're installing. | 18:43 |
| arraybolt3[m] | Blah, who needs to wait for LP? /me horks source package and sbuild's it | 18:43 |
| tsimonq2 | XD | 18:44 |
| arraybolt3[m] | Oh tar, I don't have a Jammy sbuild env yet. | 18:45 |
| arraybolt3[m] | tsimonq2: Seriously, though... if we could rewrite some of LP's Python stuff in C, we could make the lives of Ubuntu devs around the world better. | 18:47 |
| arraybolt3[m] | (Or better yet still, Rust.) | 18:47 |
| arraybolt3[m] | Imagine a Rust-based, optimized Britney. We'd have all of #ubuntu-devel cheering. | 18:48 |
| arraybolt3[m] | (ok so maybe not really but I've seen the slowdowns and backlog.) | 18:48 |
| tsimonq2 | <arraybolt3[m]> "Seriously, though... if we could..." <- It's networking at this point, I think | 18:52 |
| tsimonq2 | arraybolt3[m]: And that's apparently due to SQLite | 18:52 |
| tsimonq2 | If you're volunteering, I won't stop you ;) | 18:52 |
| * tsimonq2 goes for lunch, today has been quite a day... | 18:52 | |
| arraybolt3[m] | tsimonq2: I've thought about it :P But there's too much other stuff we're doing right now. | 18:53 |
| arraybolt3[m] | > * <@tsimonq2:linuxdelta.com> goes for lunch, today has been quite a day... | 18:53 |
| arraybolt3[m] | o/ See you later! | 18:53 |
| tsimonq2 | You're telling me... :) | 18:53 |
| arraybolt3[m] | lol right? | 18:53 |
| arraybolt3[m] | Heh, manually building it actually did let me beat the LP publisher. | 18:56 |
| arraybolt3[m] | Simon Quigley: The prototype works over here. It popped up the confirmation window, I told it to overwrite the config file. | 18:58 |
| arraybolt3[m] | Looks like the file was overwritten too. I'm going to do one more test, this time clicking the "don't overwrite" button just to be thorough. | 19:01 |
| arraybolt3[m] | And if I had been thinking, I would have made a snapshot and been able to do this super easy, but now I'm going to create a whole new VM :P | 19:02 |
| arraybolt3[m] | Verified that the "Keep existing" option works! | 19:32 |
| tsimonq2 | Sweet. I'll get this uploaded to Lunar, arraybolt3 if you want practice I can certainly let you fill out the SRU report :) | 19:48 |
| tsimonq2 | Or, if you've had enough, let me know that too :P | 19:48 |
| arraybolt3[m] | Sure, why not. | 19:48 |
| tsimonq2 | https://bugs.launchpad.net/ubuntu/+source/lubuntu-update-notifier/+bug/1998937 | 19:48 |
| -ubot93:#lubuntu-devel- Launchpad bug 1998937 in lubuntu-update-notifier (Ubuntu) "Lubuntu Jammy - full upgrade freeze waiting for config file prompt" [Undecided, New] | 19:48 | |
| arraybolt3[m] | Simon Quigley: OK, this is my SRU paperwork:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/f94e581b2aa4f5d30af3f89d70514cb3f2345725>) | 20:05 |
| arraybolt3[m] | (If that's safe to do here.) | 20:05 |
| * arraybolt3[m] reformats that messy code block | 20:05 | |
| arraybolt3[m] | * Simon Quigley: OK, this is my SRU paperwork:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/b250653be1709c6740d80fc081ff3772ddc3865d>) | 20:06 |
| arraybolt3[m] | > <@arraybolt3:matrix.org> Simon Quigley: OK, this is my SRU paperwork:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/56fd5ef73b065f15b02fb24edabc0d2d0ff8021a>) | 20:06 |
| arraybolt3[m] | Eickmeyer: ^ | 20:06 |
| arraybolt3[m] | Sigh. This time I even made a snapshot... but not until I had done the full system upgrade! Ha ha. Alright, making a third VM from scratch. | 20:07 |
| Eickmeyer[m] | arraybolt3: That is an option, but sddm isn't what's breaking it. It's just pointing out the breakage. | 20:08 |
| Eickmeyer[m] | That's not fair to everyone that uses SDDM. | 20:08 |
| arraybolt3[m] | True. My point was that sddm going through before lubuntu-update-notifier would result in problems for Lubuntu users, since it will make their upgrades freeze. It's not the cause of the problem, it's just setting off the tripwire. Either we hold back SDDM until lubuntu-update-notifier comes through, or we try to get the SRU team to push lubuntu-update-notifier through fast (my hope), or we let things run their course and hope not | 20:09 |
| arraybolt3[m] | too many Lubuntu users get hung up :-/ Option 1 would be the best according to policy, Option 2 would be the best for usability, and Option 3 hopefully isn't an option. | 20:09 |
| arraybolt3[m] | I would like to know which one we're doing, since that will influence how I write the SRU paperwork. | 20:11 |
| tsimonq2 | Option 3 isn't an option. The reason the 7 day waiting period exists is to get testing done, to ensure the user benefits from the update. Regressions are a no-go no matter what, so "waiting it out" would be neglectful.... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/b6856f2c144badcfc3a3c39282910242bb5ea09a>) | 20:18 |
| Eickmeyer[m] | FWIW, even a grub update of /etc/default/grub would've caused this too. | 20:23 |
| tsimonq2 | Doesn't matter. For the fourth time, it's not SDDM's fault specifically :P | 20:24 |
| Eickmeyer[m] | Which is why I don't think holding back SDDM is a good idea because it's not SDDM's regression. | 20:25 |
| tsimonq2 | To be fair, the fix won't be installed at all on Plasma. | 20:25 |
| tsimonq2 | Since Discover is used and the default is to not clobber config files, yeah, it'll take some manual work for the end user. | 20:26 |
| tsimonq2 | That's only using the Plasma GUI | 20:26 |
| Eickmeyer[m] | Yeah, meaning 1) I have more work to do, and 2) I need to file a bug against PackageKit and 3) bug juliank. | 20:27 |
| tsimonq2 | So, wouldn't you agree that we should wait to release this fix until users can actually apply it? | 20:27 |
| Eickmeyer[m] | Well, it's going to be marked as verification-failed, so let me put it this way: I just bought you some time. | 20:28 |
| arraybolt3[m] | Hold on, what? | 20:30 |
| arraybolt3[m] | Isn't there an option to hold back an update without doing that? | 20:30 |
| tsimonq2 | Please clarify :) | 20:31 |
| arraybolt3[m] | https://wiki.ubuntu.com/StableReleaseUpdates#Staging_an_upload | 20:31 |
| tsimonq2 | ohhhhhhhhhhhhhhhhhhh | 20:31 |
| tsimonq2 | yeah I always forget about that :) | 20:32 |
| arraybolt3[m] | Can't we just do that to SDDM until lubuntu-update-notifier is ready to come out and then once that happens, say "alright, release SDDM"? | 20:32 |
| tsimonq2 | How are you sure users are going to upgrade immediately once it's released? | 20:32 |
| arraybolt3[m] | Yeah, that's a problem, but not one that can be easily fixed. | 20:33 |
| arraybolt3[m] | I mean unless we add a postinst script to do some sort of magic. | 20:33 |
| tsimonq2 | You know what tool this is possible with? | 20:33 |
| arraybolt3[m] | Theoretically, no matter how long SDDM is delayed after lubuntu-update-notifier is released, a user could still hit this freeze. | 20:33 |
| tsimonq2 | Ubuntu's update-manager | 20:33 |
| tsimonq2 | Guess what we don't use on the backend? | 20:33 |
| tsimonq2 | Ubuntu's update-manager :P | 20:33 |
| arraybolt3[m] | arraybolt3[m]: Or anything else that causes a freeze. | 20:34 |
| arraybolt3[m] | Even if SDDM and lubuntu-update-notifier come through good, like Eickmeyer points out, an /etc/default/grub update could cause this problem, and a user who didn't get lubuntu-update-notifier until then could run into it too. | 20:34 |
| arraybolt3[m] | My thinking is we could use a postinst script to somehow "hijack" lubuntu-update-notifier and force it to do the right thing mid-update. Dunno how feasible that is, though. | 20:35 |
| Eickmeyer[m] | I'm not verification-failing for this, I'm verification-failing because it's not applying via an expected update mechanism (Plasma Discover and/or this.). Basically, I'm going to have to change it from a quilt patch to a postinst injection. | 20:35 |
| arraybolt3[m] | Oh. | 20:35 |
| tsimonq2 | Eickmeyer[m]: That misses the entire point of the step, how do we know the user doesn't already have this fix applied locally? The user should be prompted with this decision. | 20:36 |
| arraybolt3[m] | <Eickmeyer[m]> "Yeah, meaning 1) I have more..." <- Now I get what you were saying here. | 20:36 |
| tsimonq2 | The fact that PackageKit has no such option is a red flag | 20:36 |
| tsimonq2 | Specifically because it clobbers any changes you might make to your GRUB config | 20:36 |
| * arraybolt3[m] <del>loves</del> *hates* edge cases | 20:37 | |
| Eickmeyer[m] | tsimonq2: That's true. | 20:37 |
| tsimonq2 | lubuntu-update-notifier will need one though :( | 20:38 |
| arraybolt3[m] | Eickmeyer: What about a postinst injection that prompts the user with a pop-up console window? | 20:38 |
| Eickmeyer[m] | This is one reason I wish Kubuntu would've just kept update-manager and left discover out of the update process. | 20:38 |
| * tsimonq2 uploaded an image: (23KiB) < https://libera.ems.host/_matrix/media/v3/download/linuxdelta.com/lnsVsZXfATEfBtysLJNpHvmK/image.png > | 20:39 | |
| tsimonq2 | sigh. | 20:39 |
| arraybolt3[m] | arraybolt3[m]: Meh, that would mess up automated workflows I would guess :-/ | 20:39 |
| Eickmeyer[m] | arraybolt3[m]: It also wouldn't work from a TTY. | 20:40 |
| arraybolt3[m] | Simon Quigley: What if we added to lubuntu-update-notifier's debian/control "Breaks sddm (> whatever version)" (not sure if that's the right syntax) so that SDDM is held back *just on Lubuntu*? | 20:42 |
| arraybolt3[m] | Then we can wait, say, a month or so, then release another update that removes the breaks line. | 20:42 |
| arraybolt3[m] | (Also dunno if that's how Breaks works but you get what I'm going for.) | 20:43 |
| Eickmeyer[m] | Uh, that would break a whole lot more. | 20:43 |
| Eickmeyer[m] | And would be an improper use of that. | 20:44 |
| Eickmeyer[m] | ERR:RaceCondition | 20:44 |
| arraybolt3[m] | True, it would be improper use, but I'm kind of grasping at straws here. But there's no way to somehow hold back SDDM just on systems with lubuntu-update-notifier so that they don't get hung up? | 20:44 |
| Eickmeyer[m] | Imagine a GRUB update. | 20:44 |
| arraybolt3[m] | Ohh. Forgot about those. Hate race conditions. | 20:44 |
| arraybolt3[m] | Maybe tricky use of Pre-Depends? | 20:45 |
| tsimonq2 | So, I'm curious... how does apt actually tell which packages to configure before others? | 20:46 |
| tsimonq2 | In my VM, lubuntu-update-notifier is installed and configured before SDDM is | 20:46 |
| tsimonq2 | ...how does it know :P | 20:46 |
| Eickmeyer[m] | That's another juliank question. | 20:46 |
| arraybolt3[m] | The ideal solution (IMO) would be to somehow: | 20:47 |
| arraybolt3[m] | 1. Update lubuntu-update-notifier first. | 20:47 |
| arraybolt3[m] | 2. Interrupt the update. | 20:47 |
| arraybolt3[m] | ...(truncated) | 20:47 |
| tsimonq2 | > <@arraybolt3:matrix.org> The ideal solution (IMO) would be to somehow:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/824308cef90fc4f88e14f56f754430af4c87a298>) | 20:48 |
| arraybolt3[m] | Failing that, some sort of "recovery guide" might help, but then we'd be looking at having an Arch Linux like News update, and that is so very not Ubuntu-like. This should just transparently work for the end user. | 20:48 |
| arraybolt3[m] | > <@arraybolt3:matrix.org> The ideal solution (IMO) would be to somehow:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/7cd3ffb4c56509db494f39b119b4f2d87c3ca0fb>) | 20:49 |
| tsimonq2 | I think we've found ourselves with a fun chicken and egg situation... | 20:57 |
| Eickmeyer[m] | 🐔🥚🤦♂️ | 21:01 |
| arraybolt3[m] | OK, here's another idea (discussing this mess with my best friend, she had a good idea). If we're using lubuntu-update-notifier, the user has a working GUI, we know because lubuntu-update-notifier is a GUI application. Might there be some way to add a postinst script to lubuntu-update-notifier that could do the update-notifier reboot in the middle of the update? | 21:03 |
| arraybolt3[m] | It might even just replace the existing updater with a "bootstrapping" updater for just this one update to handle things. | 21:03 |
| arraybolt3[m] | (Kind of like how sometimes Windows Update needs to update before Windows can update.) | 21:03 |
| arraybolt3[m] | Or, here's an idea. You can fix an interrupted apt update with a particular dpkg command. What if the postinst script for lubuntu-update-notifier just killed apt outright, ran the "fix" script, and then restarted lubuntu-update-notifier, if that was even necessary? Then we could just worry about getting lubuntu-update-notifier to update first. | 21:04 |
| tsimonq2 | Well, Windows Update knows to check for updates to Windows Update before it tries to update Windows Update | 21:05 |
| tsimonq2 | arraybolt3[m]: I'm on that same thought process right now | 21:05 |
| arraybolt3[m] | Right, but we can add that functionality to lubuntu-update-notifier with a postinst script. | 21:05 |
| tsimonq2 | How do you deploy the update then? :) | 21:06 |
| arraybolt3[m] | tsimonq2: Yeah, you get me. (I may be phrasing myself poorly.) | 21:06 |
| arraybolt3[m] | tsimonq2: I just misphrased myself, you understood what I was going for. | 21:06 |
| tsimonq2 | Let me know if you come up with a solution first heh | 21:08 |
| arraybolt3[m] | Looking for one. Right now I'm wishing Debian had a "Post-Depends" field for debian/control :P | 21:08 |
| arraybolt3[m] | Simon Quigley: I just had an awful but possibly good idea. | 21:15 |
| arraybolt3[m] | What if we make lubuntu-meta Pre-Depends a dummy package who's sole job is to unravel this mess? | 21:15 |
| arraybolt3[m] | Or even make it Pre-Depends lubuntu-update-notifier? | 21:15 |
| arraybolt3[m] | (The second one would probably be better so that we don't have to introduce an new package into the archive.) | 21:16 |
| arraybolt3[m] | Then lubuntu-desktop would get an update too, BUT, because of the Pre-Depends, it would (hopefully) force lubuntu-update-notifier to be installed before almost anything else. Then it's postinst script could wrangle the rest of everything into submission. | 21:17 |
| arraybolt3[m] | s/it's/its/, s/submission/working right/ | 21:17 |
| arraybolt3[m] | I'm gonna try it real quick. | 21:33 |
| arraybolt3[m] | Technically it is possible that this won't work (Debian policy doesn't require all pre-depends to be handled first, just before the package that pre-depends on them), but it seems likely to me that a sane implementation of apt would handle all pre-depends first just because it would be easier to code it that way. | 21:36 |
| tsimonq2 | That seems sane to me, I'll also try it on my end... | 21:40 |
| arraybolt3[m] | Simon Quigley: Maybe you can just add the packaging to the PPA and we can use that? I can give you the packaging I have if you'd like. | 21:43 |
| arraybolt3[m] | Save Launchpad a bit of compute power and publisher time, hopefully. | 21:43 |
| tsimonq2 | I'll take the packaging you have to make sure we're on the same track :) | 21:44 |
| tsimonq2 | I was just going to use a local PPA setup lol | 21:44 |
| arraybolt3[m] | Ah, good point. I don't know how to set up a full-force local PPA that I can use within apt in a VM, so I was going to do PPA. | 21:44 |
| * arraybolt3[m] posted a file: (18KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/wayoPLKGcukXFupxEpwosBaO/lubuntu-meta_22.04.3ubuntu2.tar.xz > | 21:45 | |
| arraybolt3[m] | Simon Quigley: ^ | 21:45 |
| arraybolt3[m] | s/Ah,/Makes/, s/good point/sense/ | 21:46 |
| tsimonq2 | Yeah, we're on the same page :) | 21:47 |
| tsimonq2 | arraybolt3: https://pythonhosted.org/aptdaemon/aptdaemon.client.html#aptdaemon.client.AptClient.fix_incomplete_install | 21:49 |
| arraybolt3[m] | Hmm, that would work if we were doing it in Python, but for a postinst script, why not just run "dpkg --configure -a" in native Bash? | 21:50 |
| tsimonq2 | arraybolt3[m]: That's redundant, and by nature they should be as self-contained as possible | 21:51 |
| arraybolt3[m] | For some reason that just flew entirely over my head. | 21:51 |
| arraybolt3[m] | they meaning the postinst script? | 21:51 |
| arraybolt3[m] | and how is it redundant? | 21:51 |
| tsimonq2 | It seems like unsafe practice to configure all other packages in the postinst script for one package | 21:53 |
| arraybolt3[m] | Ohhh, right. Stack overflow, trying to multitask and work my brain here. | 21:54 |
| arraybolt3[m] | (Why I thought that was a good idea, I do not know now that you say that.) | 21:54 |
| arraybolt3[m] | So basically the postinst script's job should be to killall apt, then relaunch lubuntu-update-notifier, maybe with a "--finish-installation" switch. Then we can use that Python feature to finish the job. | 21:56 |
| tsimonq2 | Crudely, yeah | 21:58 |
| tsimonq2 | arraybolt3: Take a look at this dpkg log, I think your idea worked... | 22:13 |
| * tsimonq2 sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/a33244b4cc917da2d2d4cb042773bde2bf241434 | 22:13 | |
| arraybolt3[m] | That does indeed look hopeful! | 22:14 |
| arraybolt3[m] | The `conffile /usr/share/sddm/scripts/Xsetup install` line happens way far after `configure lubuntu-update-notifier:all 0.4.1~22.04~ppa1 <none>`. | 22:15 |
| * arraybolt3[m] is hacking at the Python code in lubuntu-update-notifier to see if we can do this "crash and then auto-resurrect" everything hack | 22:15 | |
| arraybolt3[m] | Simon Quigley:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/42486830da1b2abd8f532b20ce6d276dad3496dd>) | 22:21 |
| arraybolt3[m] | * Simon Quigley:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/0a0ca63f4911c2488b15051283bd9a68bd562144>) | 22:21 |
| tsimonq2 | Close... I think killall needs to be the absolute path to lubuntu-upgrader | 22:23 |
| tsimonq2 | This is so hacky... I can't even believe we're going down this road :P | 22:23 |
| Eickmeyer[m] | I read "Horribly messy hack" as something completely different and almost called you out for it. | 22:23 |
| Eickmeyer[m] | And ew... nohup.... 👀 | 22:24 |
| arraybolt3[m] | tsimonq2: Uh... I may have misunderstood, don't we have to killall apt in order to stop the upgrade? Otherwise the previous one is going to still be in progress and the new updater can't replace the old one. | 22:25 |
| tsimonq2 | This has to be as safe as we can get it... | 22:27 |
| arraybolt3[m] | Also double-check my understanding of foreign code:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/84323e42591c0558a27538f3769a8b7a7534ce35>) | 22:27 |
| arraybolt3[m] | And then down near the bottom,... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/3ca6285b69d6fb1854565d9f2538cfe8a2913143>) | 22:27 |
| arraybolt3[m] | tsimonq2: True, but think of it this way. In the event anything goes awry, the user can fix it by loading a terminal and doing "dpkg --configure -a", which they're going to have to do anyway if the bug is left as-is since they're going to have to interrupt the upgrade. | 22:28 |
| arraybolt3[m] | (At least that's my understanding of it, I could be wrong here but I think that's right.) | 22:28 |
| arraybolt3[m] | (We do still have to get past the SRU vanguard though, and considering the epic level of "you did WHAT" involved in this, that's going to be hard enough as it is, so being very careful will be good if for no other reason than to get it SRU'd through, not to mention that we want to be careful with our user's systems.) | 22:32 |
| tsimonq2 | Here's a few fundamental flaws... | 22:33 |
| tsimonq2 | 1. There's only an actionable step if this is ran within lubuntu-upgrader. That means ensuring lubuntu-upgrader is currently running. | 22:33 |
| tsimonq2 | 2. "When a package is upgraded a combination of the scripts from the old and new packages is called during the upgrade procedure. If your scripts are going to be at all complicated you need to be aware of this, and may need to check the arguments to your scripts." https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html | 22:33 |
| arraybolt3[m] | > <@tsimonq2:linuxdelta.com> Here's a few fundamental flaws...... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/0b2bc43d953184aa28d84eccaec729eead3e770b>) | 22:35 |
| * arraybolt3[m] sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/66663a6f6ced390237abca1dccf0bf53ef749e38 | 22:35 | |
| arraybolt3[m] | Gah. This is going to be way harder than I thought. | 22:36 |
| arraybolt3[m] | I have to go afk for a bit, but I will be right back, hopefully. | 22:37 |
| Eickmeyer[m] | FYI, because per apt upgrade methods, and because I verified that the sddm patch does in fact work, I marked it as verification-done. It's not the patch's fault that it raised other issues. Probably won't see the light of day for another week, so there's still time. | 22:59 |
| Eickmeyer[m] | I did extensively comment on the issue though. | 22:59 |
| Eickmeyer[m] | https://bugs.launchpad.net/ubuntu/+source/sddm/+bug/1998254/comments/8 | 23:00 |
| -ubot93:#lubuntu-devel- Launchpad bug 1998254 in sddm (Ubuntu Kinetic) "[SRU] sddm with multiple monitors can result in screen overlays and insets" [High, Fix Committed] | 23:00 | |
| arraybolt3[m] | <arraybolt3[m]> "> <@tsimonq2:linuxdelta.com..." <- So the question is, how do we stop the upgrade process without also driving apt crazy? I'm guessing we'll have to do the "killall apt" bit from within lubuntu-upgrader? | 23:02 |
| tsimonq2 | The more I think about this, the less convinced I am that forcing lubuntu-upgrader to restart is a good option | 23:02 |
| arraybolt3[m] | That makes sense. No matter how you come at this, doing it this way *requires* using some sort of convoluted "crash-repair-fix" sequence that doesn't feel right for an SRU. | 23:03 |
| kc2bez[m] | tsimonq2: As I read the backlog I was wondering the same. It might be better dealing with the edge failed updates. I mean we don't know who uses our tool. They may all use the command line or discover or something. | 23:04 |
| arraybolt3[m] | Dan Simmons: If by "dealing with the edge failed updates", you mean that we let the updater freeze and have the user sort it out, helping them if they ask for hellp, I think that's a bad idea because a) Lubuntu uses this updater by default, it's the most likely thing a new (and inexperienced) end-user will use because it's the first thing that presents itself. b) Since it's what all the inexperienced users are going to use, it | 23:07 |
| arraybolt3[m] | means that this bug throws a curveball at the users who are least likely to be able to figure it out. And not everyone knows to pop their head into #lubuntu or our Discourse forum. | 23:07 |
| arraybolt3[m] | I might have just misunderstood what you were saying, that was just my first thoughts. | 23:07 |
| arraybolt3[m] | s/hellp/help/ | 23:07 |
| arraybolt3[m] | * Dan Simmons: If by "dealing with the edge failed updates", you mean that we let the updater freeze and have the user sort it out, helping them if they ask for help, I think that's a bad idea because a) Lubuntu uses this updater by default, it's the most likely thing a new (and inexperienced) end-user will use because it's the first thing that presents itself. b) Since it's what many of the inexperienced users are going to use, | 23:08 |
| arraybolt3[m] | it means that this bug throws a curveball at the users who are least likely to be able to figure it out. And not everyone knows to pop their head into #lubuntu or our Discourse forum. | 23:08 |
| arraybolt3[m] | I might have just misunderstood what you were saying, that was just my first thoughts. | 23:08 |
| kc2bez[m] | It has to fail though right? Not every update will bomb out. | 23:09 |
| arraybolt3[m] | Something has to fail, true. Either the update freezes and the user has to force-terminate it, or we do something to terminate the update. | 23:13 |
| arraybolt3[m] | However. If we do make it so that lubuntu-update-notifier gets fully updated before sddm hits, then when it freezes, the user can force-terminate it and relaunch it (turn it off and back on again, this is something hopefully most users will think to do), and then it will just work. Perhaps we just need to insert code into lubuntu-update-notifier that repairs the interrupted update when the user terminates it themselves. | 23:14 |
| arraybolt3[m] | And we already seem to be able to get lubuntu-update-notifier to fully install properly before anything else with a Pre-Depends hack in lubuntu-desktop. So that might mean that the problem is solved, so long as it is easy for a user to unravel the broken update. | 23:15 |
| tsimonq2 | The case I repeatedly get hung up on is if the user does both updates at once | 23:17 |
| tsimonq2 | We have the fresh install case covered, we have the "I'm installing the lubuntu-update-notifier update first, then SDDM once it comes down the pike later" scenario, how about the case of installing a fresh 22.04.1 instance and simply running system updates? It will fail | 23:17 |
| arraybolt3[m] | True. Then the user will have to "power-cycle" the updater, since hopefully it will already have installed by that time. | 23:18 |
| tsimonq2 | I don't even think lubuntu-upgrader has a desktop entry... | 23:18 |
| arraybolt3[m] | It has an entry in the Application Menu. | 23:19 |
| arraybolt3[m] | Preferences > Apply Full Upgrade | 23:19 |
| arraybolt3[m] | Maybe we should make the postinst script put an icon on the user's desktop that says "Double-click me!" :P | 23:20 |
| tsimonq2 | hah | 23:20 |
| tsimonq2 | Honestly, I don't see a better way, meaning, let it crash and let the user open a new instance of the newly updated notifier | 23:22 |
| arraybolt3[m] | Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1131 (aptd) Crud. Force-closing the updater doesn't close the background process that actually does the updating. | 23:23 |
| arraybolt3[m] | And like Leo K pointed out (I think), pressing Reboot just logs the user out, since aptd running in the background prevents a reboot. | 23:24 |
| arraybolt3[m] | And then you log in and try to update and get told "Status: Waiting", since that aptd process is still running. | 23:24 |
| tsimonq2 | I'm going to try to sleep on this... but we really do need to submit a response to bug 1998254. I'm quite uncomfortable watching that migrate before our Is are dotted and Ts are crossed... | 23:25 |
| -ubot93:#lubuntu-devel- Bug 1998254 in sddm (Ubuntu Kinetic) "[SRU] sddm with multiple monitors can result in screen overlays and insets" [High, Fix Committed] https://launchpad.net/bugs/1998254 | 23:25 | |
| * tsimonq2 goes afk for dinner | 23:25 | |
| arraybolt3[m] | I'll keep fighting with it in the mean time. | 23:26 |
| arraybolt3[m] | Hey, you know how some packages will pop up a screen asking for user input during installation, like apt-cacher-ng? How do they do that? | 23:27 |
| arraybolt3[m] | (actually, I can just look) | 23:28 |
| arraybolt3[m] | We could use that feature to tell the user how to intervene and fix the problem (something like `Due to a bug, this update will probably get stuck. To resolve this problem, please save your work, close all open windows, open a terminal, and run "systemctl reboot -i". When the reboot is complete, finish the update.`) | 23:30 |
| arraybolt3[m] | Of course that presents a problem for non-English speakers unless we want to also include translations for the instructions... | 23:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
