Why not use a poll on our own Discourse instance?

Finally resolved in 3.2.19.1.

@The_LoudSpeaker could you evaluate where we're at with this and what next steps we need to take, if any?

And now we have a new upstream bug linked. tl;dr it's calling the wrong path to udevadm.

Could you make a bug that describes the issue with the PDF and the workaround and link it here, please?

Just tagging @Leok on this one since he discovered the issue originally.

I think not.

Either way, we're not going to please everyone. I think you and I are in agreement.

PDF export with certain fonts seems less important than a consistent look and feel.

So crazy scripted the installs and had failures both ways but had less failures with the script. It seems more appropriate to do things that way, anyways. Someone want to drum that up?

Since we have a solution that works well for almost everything, I say we keep it. We can include the workaround in release notes for the PDF export issue (we should make a bug for it and link it to the upstream bug). Once we have that in place (maybe we should start working on release notes now?), let's close this.

Ship it!

LGTM but please give @EinarMostad credit in the changelog for the idea.

Nevermind the above, I got it to fail anyways.

Although I find it really circumstantial and fails to explain why we suddenly had this problem nor why renaming os-prober seems to work around the issue, upstream sees the problem to be the way we're calling things. Apparently just running sudo calamares "solves" the problem and while I'm skeptical of that, it does seem to work. Subsequently, upstream has changed the docs to reflect this fact.

@kc2bed sadly, no. While I agree that D82 works as intended to automatically use nm-connection-editor as opposed to nmtui-edit and while I see that as a vast improvement, it's still not the Qt-based solution we want. We probably should drop this from 20.04, though.

Agreed. I did make a comment in the Ubuntu Discourse thread that we did this so I would expect an alert if they changed something elsewhere.

Confirmed it's got the fix and that version is in the 20200217 ISO and
that it works perfectly. I'm calling this officially good.

LGTM though I'd append a "no changes needed" to the standards bump in
the changelog to clarify that we didn't need to do anything other than
just switch the version number.

Why is this assigned to me BTW? :)

P.S. I suggest kdialog.

We got a showstopper with auto-resize in i386. sil200 escalated it to jibel and mwhudson on #ubuntu-release after franksmcb confirmed it didn't have a problem in 18.04.3.

Yeah this is the last of the 32 bit, so we definitely should do that. I don't have anything exclusively 32 bit anymore I don't think.

I did a quick entire disk run through on vbox and it worked fine, so we should be good to go.

@hmollercl Of course I don't want it, but it's the best we got. I had supported the change here but only decided against it because I didn't feel it was fair to non-Lubuntu users. For some reason we didn't thing it was XDG-respecting, but it turns out it is. I think my last comment should explain why.

To make this a little neater to review, I created a paste. See P65.

@hmollercl not to dig up the past but I think I was a little too rash to shoot this down. Looking at this post on Discourse got me thinking on the subject and I realize we can instead implement this change in rDEFAULTSETTINGS by using $XDG_CONFIG_DIRS, specifically dropping our own nm-tray.conf in /etc/xdg/xdg-Lubuntu/nm-tray. I just tested this in 19.10 and it works fine and overrides the default in /usr/share/nm-tray. Interestingly, though [/usr/share traditionally is in $XDG_DATA_DIRS](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) (and it is for us), we also have it in $XDG_CONFIG_DIRS so it works. nm-tray uses QSettings to manage configuration and [it uses $XDG_CONFIG_DIRS](https://doc.qt.io/qt-5/qsettings.html#locations-where-application-settings-are-stored) so this makes sense. So want to fix this once and for all in Focal?

@teward could this be as simple as provisioning additional resources from the host? Which resource(s)?

Sorry for the long delay. I can indeed confirm that the clientActions in lxqt-panel do little more than desktop switching or task switching to a particular task number. I can also confirm that it will likely be problematic even if it was supported based on the bug you mention. I *do* think this is worth mentioning as something to improve. On the other hand, another part of me thinks they'll probably say this is a job for the window manager. And indeed, this is a bit of a window manager-specific task.

Aw you're no fun @kc2bez XD

@kc2bez as i said with the other fix, I think we should just keep rolling with this and test it hard. It doesn't hurt to have it a little broken in the development release, contrary to what folks may imagine XD

ARRRRRRRRRRRRRRRRRRGH why doesn't dch -r "" ever work???????????????????????????????????????? I swear it worked for me last time. Sigh. Please run that to change UNRELEASED to focal.

Just putting it down on record that I tested this by applying the changes manually as well as on a fresh install yesterday in vbox and all worked fine for me. dpkg --print-foreign-architectures returns i386 and Steam installs without problem in Discover.

I'm adding @teward here as ultimately this becomes an issue of needing to set up Weblate again. I don't think we have a task for doing that. Is there any reason to think this would be particularly difficult or problematic?

Just tested with new testcase (or rather more detailed one) and worked like a charm all the way through.

Ok, then please drop it.

BTW I suggested a change in casper and mwhudson suggested building images with the change. There hasn't been much movement on either front so we may have to do this.

Maybe we should just do it while we wait for a more universal solution.

Is there any other way to make this work? Or hope that upstream will fix it?

Yeah I guess it should have something similar to the original where this was inspired by so-and-so and we modified it and so it should have a Lubuntu copyright. I wonder who Dino Duratović is and where the original came from.

Are you suggesting we drop this?

BTW ka-sync-archive is here.

@hmollercl update from the various upstreams? I think at the very least we can implement the changes to LXQt applications for everyone.

Well maybe I'm backpedalling on all of that:

As I said before, I trust you fully as far as theming is concerned. So I'm not too worried about the aesthetics of the theme.

I presume you wanted reviewers here? :)

Wishlist? You have some reason to think this is not feasible?

Flipping this to upstream since we'll wait for them and if it gets down to the wire, we'll do what @hmollercl suggests and take the git version.