[00:51] arraybolt3: Did we ever finish that packaging audit in the Ubuntu archive? [00:51] I'm going full send once we get a codename and would like to know if you noticed anything off. [00:51] tsimonq2: We did most of it, there are still a few loose ends that will have to wait. [00:51] (Mainly just the copyright files need updated.) [00:51] All of the Debian sync stuff was repaired. [00:52] Note that I'm still writing a guide that I intend to plug into the release notes. [00:52] tsimonq2: ^ [00:52] Thank you for that, by the way. [00:53] And the copyright files only need updated on just a few packages. [00:54] I'll keep an eye out for copyright, otherwise I also want to get Qt 6 builds started. Native theming is the first thing, then getting applications ported one by one. That will take us through the LTS, I'd imagine [00:55] Pretty sure LXQt 1.3.0 doesn't support Qt 6 yet. [00:55] They're waiting on KF6. [00:56] * arraybolt3 now understands what you said, nvm [00:57] Preliminary Qt 6 builds exist for the frameworks we need. I'll have to ask about naming convention for KF6, probably on debian-qt-kde@debian - then once those are through NEW and buildable, we work through the LXQt stack to lxqt-qtplugin to start [00:57] I'd imagine by that point, we'd start to see some Qt 6 patches being merged upstream [00:58] Now, I'm unsure whether 2.0 will be LWQt, or whether it will be Qt 6, or both. So we'll have to be careful about naming convention there [00:58] That being said, Arch already has some Qt 6 LXQt builds in their archive [00:59] Anyway, that all comes next cycle, plus our current projects [01:01] I think the last things we really need for our try or install screen are a) some minor UI polish and b) a locale chooser, potentially one that changes the entire desktop environment. That will be a huge leap [01:01] OEM is also currently possible, just needs to be implemented. I get why we haven't done it yet [01:02] That, plus some other installer polish. We now have a ZFS module in Calamares so I'd like to enable that by default (not as the default, but as an option, alongside a few others). Minimal install comes with that, I dunno if we'll get as far as snap or AD integration like Ubiquity, but hey [01:03] tsimonq2: Did you see the polish I did on the install prompt? [01:03] There's a PR in Gitea for it. [01:03] Oh yeah? [01:03] https://git.lubuntu.me/Lubuntu/installer-prompt/pulls/1 [01:03] -ubottu:#lubuntu-devel- Pull 1 in Lubuntu/installer-prompt "Functionality and UI overhaul" [Open] [01:04] (I saw a headline come across today about Ubuntu's new installer missing ZFS support entirely and I kinda chuckled. I almost wonder if we should release note how to enable it.) [01:06] There's an attached video on the PR showing the modified installer prompt in action. [01:07] (Also Ubuntu Unity 22.10 poking its head out in the background. Had fun with that for a couple of months.) [01:08] Unity is what I started on. Great stuff. We could totally steal the HUD (like MATE did) :D [01:09] But yeah, I think with a locale/language panel it'd be great [01:10] The installer prompt? That sounds like a good idea. [01:11] I loved the idea of having it in the boot menu like the old days, idk why that can't be a thing again :( [01:13] What on earth... I just broke Google somehow :P [01:13] Doesn't show any websites in the search results at first... [01:14] Works in an incognito window. Wonder what happened there. [01:16] ROFL even clearing my cookies didn't fix it?! [01:20] Weird. Well, I can still Google with Incognito mode, so I guess that's good. Hopefully that will shake itself out in a bit. (I don't see anything weird security-wise on my account so I think I'm OK there, and I use 2FA so...) [01:46] tsimonq2: I'm thinking of intentionally *not* documenting the process to allow a blank password at install time since that could result in user data loss thanks to XScreenSaver's shenanigans. I documented autologin, passwordless sudo, and deleting a password. Is that enough? [01:49] "That, plus some other installer..." <- We could enable the FS selection drop down on the erase disk selection. [01:49] Google started working for me again \o/ [02:28] I think that's LC quorum on enabling the FS dropdown, lol [02:28] Heh, it is indeed. [02:29] guiverc: If you could review and approve my new "how to disable your password" post in the Documentation section of Discourse, that would be great. I'm hoping to integrate it into the release notes. [02:29] I think putting a small reference to that link wouldn't hurt then [02:29] ack [02:30] approved cause I trust the source.. will read it now (second) [02:33] * guiverc screams; visudo opened nano on this box; I didn't expect that! [02:34] lol [02:34] * guiverc useful right now... I've obviously not used `visudo` since installing back in feb. [02:37] arraybolt3, the "Deleting the password entirely" section doesn't mention disabling screensaver locking; should it? [02:38] It does say that it "does not ask for a password to unlock the screen", though I guess that doesn't fully communicate just *how* disabled it is :P [02:39] So yeah, it should say that. [02:39] I took that as being sddm, not xscreensaver [02:39] Ah, it is xscreensaver. Though just moving the mouse is enough to "unlock" the screen, unlike Windows which still makes you click a button to do it. [02:40] do as you see fit; as you tested it (not me!) [02:40] it's very good arraybolt3 ; my only dislike was the Nano, esp. the discover that its still default on this box!!!! [02:40] Thanks! [02:41] * guiverc got flashbacks to wordstar back on CP/M with the ^ menu down the bottom of the screen... trip back to late 70s [02:42] Heh, I've never even used CP/M before, though I've wanted to a few times in an emulator. [02:43] (It's even FOSS at this point, IIUC.) [02:47] if you used msdos; it was created based on CP/M without the polish notation PIP command (peripheral interchange program; used to copy files; eg. `pip c:=a:filename.txt` would copy a:filename,txt to c:) [02:48] Ugh... I even like reverse polish notation and that looks like a nightmare. [02:49] it was i guess the 'standard' at the time, unless you were lucky & had a much more expensive unix box [02:50] lol, now Linux is free and the thingy based on CP/M long ago is the pricey one. [02:51] :) [04:03] Hmm... while Wayfire will probably work, I kind of hope labwc works well or better. Wayfire is seriously powerful and uses 3D effects, fancy animations, etc. It looks, IMO, out of place in Lubuntu, where we keep things simple and lightweight. [04:03] labwc is designed to be Openbox-like and omits the tons of "fluff" that Wayfire appears to have. [09:52] [telegram] Maybe we should consider Mir too ?? Its super lightweight and Ubuntu Native.. (re @lubuntu_bot: (irc) Hmm... while Wayfire will probably work, I kind of hope labwc works well or better. Wayfire is seriously powerful and uses 3D effects, fancy animations, etc. It looks, IMO, out of place in Lubuntu, where we keep things simple and lightweight.) [09:53] [telegram] Mir is nowadays Wayland only, i mean its a set of libs that simplify writing a wayland compositor which is actually quite difficult [10:50] -queuebot:#lubuntu-devel- Builds: Lubuntu Desktop amd64 [Lunar Final] has been marked as ready [11:02] [telegram] It is on the exploration list. [12:49] [telegram] Nice (re @kc2bez: It is on the exploration list.) [14:07] Did some research into Mir, mainly looking at Miriway. I don't *think* it uses wlroots, which may be a problem. [14:10] [telegram] Cant say that it will cause a major problem or not ?? but alan has provided and done some testing of miriway with lxqt components, i did try with lxqt 1.2 on jammy but the panel was completely broken i mean appeared half on the screen, still its a good project that the devs should try alongside other options (re @lubuntu_bot: (irc) Did some research into Mir, mainly looking at Miriway. I don't *think* it uses w [14:19] [telegram] Did some research too as per my understanding wlroots/libweston and mir are different , they are alternatives to each other and maybe arent using each other ?? (re @lubuntu_bot: (irc) Did some research into Mir, mainly looking at Miriway. I don't *think* it uses wlroots, which may be a problem.) [14:19] [telegram] —> https://subdiff.org/blog/2021/wlroots-in-kwinft/ [14:28] From what I've researched, Wayland on its own is not suitable for LXQt - it omits too many features for LXQt to be usable with it. wlroots adds those needed features. So any Wayland compositor that supports only Wayland or Wayland + whatever isn't good enough, we need Wayland + wlroots at least, since that's what LXQt is working towards supporting. [14:29] I personally am actually not all that big of a fan of Wayland, but wlroots appears to be a pretty good compromise between the feature-loaded-and-messy X11 and the lean-clean-and-just-about-unusable Wayland :P [14:30] (to be fair I don't actually know how "lean" Wayland is but you get what I'm saying.) [14:45] [telegram] So basically very less chance for MIr ?? (re @lubuntu_bot: (irc) From what I've researched, Wayland on its own is not suitable for LXQt - it omits too many features for LXQt to be usable with it. wlroots adds those needed features. So any Wayland compositor that supports only Wayland or Wayland + whatever isn't good enough, we need Wayland + wlroots at least, since that's what LXQt is working towards supporting [14:45] [telegram] Mir can be enhanced by writing extensions ?? [14:46] [telegram] I had discussed this with alan once when seeking sway lock and sway idle to work with miriway [14:50] True, I believe Mir is unlikely to work. [14:50] Wayland support is probably going to be tricky enough on its own, so we sorta want to take the path of least resistance both for our own sakes and for the sake of our users. Currently that looks like it's going to be to package either Wayfire or labwc and use that as the compositor. [14:51] [telegram] Hmm Sad, yet good luck to lubuntu/lxqt devs for implementing wayland in lxqt (re @lubuntu_bot: (irc) True, I believe Mir is unlikely to work.) [14:52] [telegram] In LXQt they are already working on it [14:54] [telegram] I know and had been recently tracking them they seem to be picking wayfire (re @Roberalz: In LXQt they are already working on it) [17:57] We aren't set in stone on one implementation or another quite yet. We're looking for the fastest/most resource efficient one that works [18:02] If it's up to me, we may even have more than one option that can be switched between :D [18:02] For instance, I personally really want labwc since it's simpler and more lightweight than Wayfire AFAICT. But Wayfire also has a lot of nice stuff kind of like what picom might provide but better, IIUC. So having both and allowing the user to switch might be nice. === guiverc2 is now known as guiverc