[00:32] <arraybolt3[m]> Dan Simmons: If you don't mind, could you look over the XScreenSaver file I have here and give it a final thumbs-up so I can throw it into the packaging and upload it, and maybe also work on getting it SRU'd into Kinetic?
[00:38] <arraybolt3[m]> I did make one change more since last I submitted it for review, which is I changed the URL that the Help button on the XScreenSaver splash screen goes to (it now points to a man page on manpages.ubuntu.com rather than to XScreenSaver's website). I changed that because the guy who wrote XScreenSaver is... uh... intense and highly opinionated, and I'm not sure users want to get a face full of that if they click the Help button.
[00:38] <arraybolt3[m]> This renders the button still helpful, but avoids pointing to that website. This is a matter of taste, so it really needs input from others who may have different ideas than I do about this.
[00:38] <arraybolt3[m]> Anyway, here's the file: https://termbin.com/bpiu
[00:53]  * guiverc has never liked xflame either, but I've never seen it as offensive
[00:54] <arraybolt3> Again, it's just a matter of taste - if I don't like it, I'll just turn it off on my own system. I mention it since I think it might be helpful to others to have it off, but if that's not a good idea, no problem.
[00:56]  * guiverc doesn't like flurry either (default), a couple of video cards I QA on 'glitch' with it & as I result I fear it looks 'buggy'...
[00:57] <arraybolt3> Heh, that happens to my systems too (particularly slower ones). I just chalked it up to the system's speed. But if we're rewriting the file anyway, we could disable it by default and switch to a different default. (Also, it looks like I may have accidentally made a change that caused arbitrary screen savers that were enabled to be selected, rather than defaulting to just one? I should
[00:57] <arraybolt3> definitely change that too.)
[00:58] <guiverc> maybe related to system speed; I do use a few core2duo
[00:59] <arraybolt3> If any Ubuntu distro is going to be used on a slow system, it will likely be Lubuntu, so slow speed problems are definitely a concern here.
[00:59] <guiverc> Someone chose that default (I have a bug report) feeling it was best for us.. I don't mind what it is though
[01:01] <guiverc> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/1855220  I think
[01:01] -ubot93:#lubuntu-devel- Launchpad bug 1855220 in xserver-xorg-video-nouveau (Ubuntu) "xscreensaver is choppy on lubuntu 20.04 daily qa-test (flurry)" [Undecided, New]
[01:02] <guiverc> Hey thanks arraybolt3 for noticing that other xscreensaver bug & commenting....
[01:02] <arraybolt3> If we wanted a different one, I particularly like Beats, that might be a good default.
[01:03] <arraybolt3> (Noticed it in my email, glad to help! Also I just commented on the one you linked to.)
[01:03] <guiverc> I think it was the "one you linked to" I just noted & caused me to comment
[01:16] <arraybolt3> OK, well since I accidentally regressed default behavior with this new file, I guess I'm retracting my request for approval since I need to fix what I broke :P
[08:29] <arraybolt3> I said earlier I liked the Beats screensaver and that it might be good as a default, but I've noticed it also has some glitches in it, so that's probably not a good default option after all.
 I use matrix screensaver
[08:31] <arraybolt3> That's a pretty good one.
[08:32] <arraybolt3> XMatrix is a bit startling and the "SYSTEM FAILURE" message in it looks alarming, but GLMatrix is really nice IMO.
[17:45] <arraybolt3[m]> Well, bad news. PPA tests show that using a Breaks or Replaces line in apt does not convince it to install lubuntu-update-notifier first. It just keeps insisting on doing SDDM first.
[17:47] <arraybolt3[m]> I guess that was probably our last easy way out. I don't think we can have everyone who needs to replace a config file also add a lubuntu-update-notifier-workaround script to their packaging. And this isn't a regression in anything, it's just a bug being uncovered that we didn't know about before.
[17:48] <arraybolt3[m]> If no one else objects, I'll get the SRU for our fix into Kinetic, Jammy, and Focal, and then we'll see where we can go from there.
[17:48]  * arraybolt3[m] needs to go afk again
[17:53] <arraybolt3[m]> Actually, I wonder if a preinst script would help here.
[17:58] <arraybolt3[m]> Yeah, preinst won't help here, the package won't be unpacked.
[18:06] <Eickmeyer[m]> arraybolt3: I can delay the SDDM SRU until a week after the lubuntu-update-notifier update gets released, hopefully giving people enough time.
[18:07] <Eickmeyer[m]> Can't guarantee other updates won't cause the bug to surface in the meantime, though.
[18:07] <Eickmeyer[m]> Just doing my part.
[18:23] <arraybolt3[m]> I think we should add a "fix a broken upgrade" feature to lubuntu-update-notifier before SRU-ing. That way:
[18:23] <arraybolt3[m]> 1. The user attempts to update and breaks the system.
[18:23] <arraybolt3[m]> 2. The user reboots trying to fix it.
[18:24] <arraybolt3[m]> 3. The updater pops back up, fixes the broken update, and then everything works.
[18:24] <arraybolt3[m]> That way at least "turn it off and back on" will work.
[18:28] <arraybolt3[m]> The upgrader managed to unpack before SDDM configures and causes the problem, I believe, so it will be available on the next boot if all goes as expected.
[18:52] <arraybolt3[m]> Anyway, that's going to be my next test.
[20:02] <arraybolt3[m]> Alright, I have a working prototype. It ends up keeping the old version of /usr/share/sddm/scripts/Xsetup, which isn't quite what we want, BUT, it does allow the user to unbreak the system without the use of the command line in a fairly intuitive way.
[20:04] <arraybolt3[m]> The PPA with the fix is here: https://launchpad.net/~arraybolt3/+archive/ubuntu/lubuntu-upgrader-test2 (Warning to log readers, do not use this on a system you care about!)
[20:36] <arraybolt3[m]> (It also displays no progress, and doesn't even allow the window to pop up until after it finishes fixing things, so it really needs help.)
[22:44] <arraybolt3[m]> I think all this needs now is GUI-ified, and then that's a working solution! Then we can SRU it and be done.