[09:06] -queuebot:#lubuntu-devel- Packageset: Added qtxdg-tools to lubuntu in lunar
[14:15] <lubot> [telegram] <teward001> *drops a brick on @tsimonq2 for reasons*
[14:44] <lubot> [matrix] <arraybolt3> *Qt6 explodes as the brick lands and goes all over teward's infra*
[15:56] <lubot> [matrix] <arraybolt3> OK so I think I have at least a prototype of the lubuntu-upgrader fix. I'm going to upload it to a PPA and see if it builds, then we can test it out. I have a list of eight test cases to go with, too.
[15:56] <lubot> [matrix] <arraybolt3> ```
[15:56] <lubot> [matrix] <arraybolt3> List of cases to test:
[15:56] <lubot> [matrix] <arraybolt3> 
[15:56] <lubot> [matrix] <arraybolt3> 1. lubuntu-upgrader installation, local machine. Upgrader should die and restart.
[15:56] <lubot> [matrix] <arraybolt3> 2. discover installation, local machine. Upgrade should proceed silently.
[15:56] <lubot> [matrix] <arraybolt3> 3. apt installation, local machine. Upgrade should proceed silently.
[15:56] <lubot> [matrix] <arraybolt3> 4. apt installation while lubuntu-upgrader is waiting in the background, local machine. Upgrade should proceed silently.
[15:56] <lubot> [matrix] <arraybolt3> 5. discover installation while lubuntu-upgrader is waiting in the background, local machine. Upgrade should proceed silently.
[15:56] <lubot> [matrix] <arraybolt3> 6. apt installation over SSH while lubuntu-upgrader is waiting in the background. Upgrade should proceed silently.
[15:56] <lubot> [matrix] <arraybolt3> 7. lubuntu-upgrader installation over SSH. Upgrader should die and restart.
[15:56] <lubot> [matrix] <arraybolt3> 8. lubuntu-upgrader installation over SSH while lubuntu-upgrader is waiting in the background. Both upgraders should die, one should restart.
[15:56] <lubot> [matrix] <arraybolt3> ```
[15:57] <arraybolt3> Yikes, didn't realize that code block was going to come over looking like that, probably should do code blocks on the other homeserver.
[15:58] <lubot> [telegram] <RikMills> FYI, Qt 5.15.7 transition landing in lunar proposed
[15:58] <lubot> [telegram] <RikMills> some lxqt things will have been rebuilt as part of that
[17:17] <tsimonq2> Qool
[17:25] <arraybolt3[m]> Simon Quigley: Can I hand the GUI part of this over to you? I'm not familiar enough with lubuntu-upgrader's code to be able to get the fix_incomplete_install() call to plug into the UI and update the progress bar and all that cool stuff.
[17:26] <arraybolt3[m]> I mean I probably could do it with enough work, but you already know how this works.
[17:27] <arraybolt3[m]> I'm about to test the prototype before having us do that, but that's what I'm thinking. Right now the fix_incomplete_install() call is just going to run before the rest of everything.
[18:17] <arraybolt3> Uploaded the new test build of lubuntu-update-notifier to a PPA for testing. (Also, wow, being made a Lubuntu Developer gave me all sorts of fancy new buttons in the bug tracking UI! :P This is kinda fun!)
[18:49] <lubot> [matrix] <arraybolt3> Oh nice, I uploaded the upgrader for lunar when I needed it for jammy. :P
[19:40] <tsimonq2> <arraybolt3[m]> "Simon Quigley: Can I hand the..." <- Certainly 
[19:40] <arraybolt3> tsimonq2: Thanks. Still fighting with a PPA and other stuff to get the POC fix working, so bear with me.
[19:41] <tsimonq2> Fair warning, I'll be mostly AFK until Saturday afternoon, I'll put details in -members. I can still firefight absolute emergencies but would prefer others take that on for the time being
=== tomreyn_ is now known as tomreyn
[22:34] <arraybolt3[m]> With regard to lubuntu-update-notifier:
[22:35] <arraybolt3[m]> Our plan of using Pre-Depends to get lubuntu-update-notifier to install SDDM appears to be a failure. In my testing, SDDM insists on installing itself first (causing the problematic prompt).
[22:35] <arraybolt3[m]> I have tried simply pre-depending on lubuntu-update-notifier in lubuntu-desktop, I have tried pre-depending on a particular version of lubuntu-update-notifier (Pre-Depends lubuntu-update-notifier (>= 0.5.1), both have failed.
[22:36] <arraybolt3[m]> My PPA currently has a version of lubuntu-update-notifier that attempts to kill lubuntu-upgrader and aptd upon configuration, indiscriminately, as a test. However, using both lubuntu-upgrader and apt has revealed that the code isn't called until it's too late.
[22:37] <arraybolt3[m]> The PPA, for those who are interested, is https://launchpad.net/~arraybolt3/+archive/ubuntu/lubuntu-upgrader-test. (WARNING: If you enable that PPA, it will break your ability to update your system as a result of my postinst script. Don't enable this on a system you care about, like really don't. It's intended for a Lubuntu Jammy VM.)
[22:38] <arraybolt3[m]> So, if my Pre-Depends line in lubuntu-meta isn't wrong (and I don't think it is), this solution will not work.
[22:38] <arraybolt3[m]> So, anyone else have ideas? Should I take this to #ubuntu-devel and ask for help there?
[22:39] <arraybolt3[m]> (I don't think this qualifies as an absolute emergency, no servers are on fire, nothing's hacked, etc., but this is pretty bad.)
[22:52] <arraybolt3[m]> At this point, the best solution I can think of is to try and hold back SDDM until the release of 22.04.2, at which point the fix will be in the ISO. When that happens, hopefully everyone who's using Lubuntu will have the updated updater, and things will go smoothly. Anyone who doesn't have the new updater by that time will have neglected to update their system for a while, at which point they will hopefully either force-shutdown
[22:52] <arraybolt3[m]> the system and try to update via the command line, or they will chalk up the issue to having not updated in a while and will simply reinstall from 22.04.2, which will fix the problem. That won't cover those who keep installing from 22.04.1, but hopefully that will be the vast minority of users.
[22:52] <arraybolt3[m]> (And of course if something comes through that causes this bug to surface other than SDDM, then we're toast, but it took two or more years for this to surface so hopefully this is a rare enough occurrence that we'll be OK.)
[22:55] <arraybolt3[m]> Anyway, for now I'm out of ideas for a seamless solution here. I'm going to tackle $PERSONAL_LIFE business and then I guess work on other areas of development that need help.
[22:55]  * arraybolt3[m] goes afk, will read backlog when I get back if there is any
[23:16] <arraybolt3[m]> There actually is one more solution, but it would require cooperation from the rest of the Ubuntu developers.
[23:16] <arraybolt3[m]> We maintain Focal, Jammy, and Kinetic VMs, which we upgrade daily, including proposed updates, while the lubuntu-upgrader version in use is the problematic one. If we encounter a freeze in any one of those VMs, we mark whatever SRU is in progress as verification-failed and ask for the SRU's creator to do something to work around the issue (detect Lubuntu and display a "There's problems, here's how to unbreak them" message? Or
[23:16] <arraybolt3[m]> perhaps they can use a method of updating the file in question that doesn't result in the problematic prompt?). We would do this on a daily basis until Kinetic goes EOL (at which point Jammy will be a point release or two ahead). Then we can consider the problem fixed. This will reduce the number of people who are affected, and allow things to go smoothly. We will have to coordinate that with the rest of the Ubuntu development
[23:16] <arraybolt3[m]> team, but I think that's an even better solution than the above. (It still won't help with people who have problematic updates in packages that aren't in Lubuntu by default, but at least the Lubuntu packageset will be guarded.
[23:17] <lubot> [matrix] <kc2bez> I can't stay long either but I think the best we can currently do utilizing the resources we have is to SRU the updater we have in lunar.
[23:17] <arraybolt3[m]>  * There actually is one more solution, but it would require cooperation from the rest of the Ubuntu developers.
[23:17] <arraybolt3[m]> We maintain Focal, Jammy, and Kinetic VMs, which we upgrade daily, including proposed updates, while the lubuntu-upgrader version in use is the problematic one. If we encounter a freeze in any one of those VMs, we mark whatever SRU is in progress as verification-failed and ask for the SRU's creator to do something to work around the issue (detect the bad version of lubuntu-upgrader and display a "There's problems, here's how to
[23:17] <arraybolt3[m]> unbreak them" message? Or perhaps they can use a method of updating the file in question that doesn't result in the problematic prompt? Or maybe even just specify a Breaks against the bad version of lubuntu-upgrader so that the good version gets installed?). We would do this on a daily basis until Kinetic goes EOL (at which point Jammy will be a point release or two ahead). Then we can consider the problem fixed. This will reduce
[23:17] <arraybolt3[m]> the number of people who are affected, and allow things to go smoothly. We will have to coordinate that with the rest of the Ubuntu development team, but I think that's an even better solution than the above. (It still won't help with people who have problematic updates in packages that aren't in Lubuntu by default, but at least the Lubuntu packageset will be guarded.
[23:18] <lubot> [matrix] <kc2bez> Option number 2 isn't really an option.
[23:18] <lubot> [matrix] <kc2bez> We don't have the resources for that
[23:18] <lubot> [matrix] <arraybolt3> A Breaks line against the bad lubuntu-upgrader version might fix the problem (I could test it).
[23:19] <lubot> [matrix] <arraybolt3> Yeah. I mean I could *try* to do it but there's no guarantee I'd succeed.
[23:20] <lubot> [matrix] <kc2bez> It isn't *that* broken. Folks can still update from the terminal.
[23:20] <lubot> [matrix] <arraybolt3> Quite true.
[23:20] <lubot> [matrix] <kc2bez> It is bad but not resolvable with some notification
[23:21] <lubot> [matrix] <kc2bez> *unreasonable
[23:21] <lubot> [matrix] <kc2bez> Golly phone
[23:21] <lubot> [matrix] <arraybolt3> Auto-incorrect strikes again!
[23:21] <lubot> [matrix] <kc2bez> You know what I mean
[23:21] <lubot> [matrix] <arraybolt3> I think so, at least. :P
[23:22] <lubot> [matrix] <kc2bez> 🤔Maybe I should switch to talk with Texans?
[23:23] <lubot> [matrix] <arraybolt3> Anyway, if we can delay SDDM until 22.04.2, that *should* fix the problem entirely for 90% or more of users. Or if a Breaks line does the trick, we can just add a Breaks line to SDDM and call it a day. Then I can at least try to catch rogue updates every so often that need an extra Breaks line. That would be close to painless and not take a whole lot of resources.
[23:24] <Eickmeyer> arraybolt3[m]: I can only wholesale delay the whole SRU, so that's going to affect Kinetic users as well.
[23:24] <lubot> [matrix] <arraybolt3> Anyway I'll experiment with Breaks and see what I can come up with, and if it works, then we can ask for some cooperation with Eickmeyer. And if it works in production, then I'll try to catch anything else with what spare time I have.
[23:25] <Eickmeyer> What you're doing is asking me to delay this until February.
[23:25] <arraybolt3[m]> Eickmeyer: Good point. If Breaks works, though, we have a total solution for this one particular scenario, and hopefully won't have any more scenarios to deal with (and we'll have an easy way out of any other scenarios that come up).
[23:25] <arraybolt3[m]> Yeah I'd really, really like to avoid that.
[23:25] <arraybolt3[m]> (Delaying until February I mean.)
[23:25] <arraybolt3[m]> Thus the Breaks idea.
[23:25] <arraybolt3[m]> Which is what I'm going to try next, once I finish some other business I have to attend to.
[23:26] <arraybolt3[m]> arraybolt3[m]: I think we all want to avoid that if at all possible.
[23:26] <Eickmeyer> And Breaks is going to land you in a world of hurt with fresh installations.
[23:26] <arraybolt3[m]> How come? If the fixed version of lubuntu-update-notifier is available, won't apt be able to figure it out?
[23:26] <Eickmeyer> Race condition. Which one gets installed first?
[23:27] <lubot> [matrix] <kc2bez> If we're voting, I am not super keen on holding SDDM back that long.
[23:27] <arraybolt3[m]> apt has all of the info to avoid installing the wrong one first.
[23:27] <arraybolt3[m]> Whether it uses all that info or not, dunno, will test.
[23:28] <arraybolt3[m]> "When one binary package declares that it breaks another, dpkg will refuse to allow the package which declares Breaks to be unpacked unless the broken package is deconfigured first, and it will refuse to allow the broken package to be reconfigured." So apt can just deconfigure the bad lubuntu-update-notifier, install the good one, then install SDDM or whatever else. At which point the postinst script actually will help.
[23:28] <Eickmeyer> That's a good point, basically just to buy time until you get it figured out.
[23:28] <arraybolt3[m]> (Or it could decide to deconfigure the bad lubuntu-update-notifier, install SDDM, and hang up, leaving lubuntu-update-notifier uninstalled, which would look even more broken.)
[23:29] <Eickmeyer> And that's a good theory too.
[23:29] <arraybolt3[m]> "This use of Breaks will inform higher-level package management tools that the broken package must be upgraded before the new one."
[23:29] <arraybolt3[m]> (From the Debian policy manual.)
[23:29] <Eickmeyer> What about Conflicts?
[23:29] <arraybolt3[m]> The full paragraph is "Normally a Breaks entry will have an “earlier than” version clause; such a Breaks is introduced in the version of an (implicit or explicit) dependency which violates an assumption or reveals a bug in earlier versions of the broken package, or which takes over a file from earlier versions of the package named in Breaks. This use of Breaks will inform higher-level package management tools that the broken
[23:29] <arraybolt3[m]> package must be upgraded before the new one."
[23:29] <arraybolt3[m]> Eh, Conflicts is too strong I think.
[23:29] <arraybolt3[m]> arraybolt3[m]: I think this is *exactly* what Breaks is intended for.
[23:30]  * arraybolt3 keeps using the Reply feature in Element and it's making things look ewird
[23:30] <Eickmeyer> I say give it a shot in a PPA and see how it goes.
[23:30] <Eickmeyer> Yeah, it looks like you're replying to yourself.
[23:31] <arraybolt3> Yeah. I'm trying to reference things I said earlier and it's just making a mess :P
[23:31] <arraybolt3> OK, will test some more! Thank you guys for your patience and help!
[23:31] <lubot> [matrix] <kc2bez> +1 on giving it a shot in a PPA
[23:31]  * arraybolt3 afk