[00:57] <arraybolt3> Hope Canonical has deep pockets when it comes to how much they can pay for bandwidth, this is going to be the third or fourth time tonight I've done a 400+ MB upgrade on my VM as part of testing (upgrades that I keep discarding by reverting a snapshot :P)
 bah, drop in the bucket
[01:16] <arraybolt3> I think I'm slightly compulsive when it comes to saving resources I think are limited. I try to not use too much data, too many SSD writes, too much drive space, etc.
[01:17] <arraybolt3> but I'm fine with letting music stream all night off YouTube so I guess I must view Google's bandwidth as unlimited XD
 The lights are on, streaming or not. Might as well use them ;)
[01:34] <arraybolt3> shoot, just deleted my snapshot instead of restoring it.
[01:34] <arraybolt3> 🤪
[01:35] <arraybolt3> and I can't revert lubuntu-default-settings to 24.04.2 XD
[01:35] <arraybolt3> sigh, alrighty, this is going to be fun to undo
[01:36] <arraybolt3> (that one package was helping me get conffile prompts)
[01:36] <arraybolt3> (which were the very things I was just testing / fixing)
 Dang
[01:37] <arraybolt3> anyway, I'll just rebuild 24.04.2 from source, install it, tweak conffiles, then re-upgrade and be back up and running.
 That's the spirit.
[01:38] <arraybolt3> but this gives me a good opportunity to take a break, I got tons done. Diff view works nicely, conffile prompt looks nice, only trouble is clicking "Done" doesn't actually then make things happen. Not sure why yet.
[01:38] <arraybolt3> also lxqt-sudo is turning some newlines into CRLF combos :-/
[01:38] <arraybolt3> or something is at least
[01:40] <arraybolt3> and also come to think of it it's putting things on stderr that shouldn't be there
[01:41] <arraybolt3> I'm wondering if perhaps it needs patched to have a "raw" mode.
[01:44] <arraybolt3> yeah, it looks like lxqt-sudo emulates a whole terminal
[01:49] <arraybolt3> yup, it's connecting the child process to a pty it looks like, thus the mayhem. That should be fixable I would hope.
[01:49] <arraybolt3> Or maybe I just keep working around it.
[01:53] <arraybolt3> I don't rightly understand most of what I'm looking at reading through the code... but I think I see why things still aren't quite working.
[03:03] <arraybolt3> https://github.com/lxqt/lxqt-sudo/issues/209
[03:03] -ubottu:#lubuntu-devel- Issue 209 in lxqt/lxqt-sudo "When running a terminal application via lxqt-sudo, all user input to the application is discarded" [Open]
[03:04] <tsimonq2> arraybolt3: Externalize into its own script and use lxqt-sudo to call that?
[03:04] <tsimonq2> Either way I'd be inclined to try pkexec as a temporary stop-gap. :)
[03:06] <arraybolt3> Oh I already have externalized things into its own script.
[03:06] <arraybolt3> The trouble is the app needs to talk to the script.
[03:07] <arraybolt3> And lxqt-sudo is acting a bit more like a wall than a pipe :P
[03:07] <arraybolt3> yeah, pkexec should work, but yuck
[03:07] <arraybolt3> hmm, actually it doesn't look that bad now that I'm looking at it
[03:10] <arraybolt3> From experience I know pkexec will work since I've used it for this very thing before, but I really want to use lxqt-sudo since it fits better. So I'm leaning towards the idea of writing a patch for lxqt-sudo.
[03:11] <tsimonq2> arraybolt3: You're falling into the same exact line of thought I had when launching Calamares. :)
[03:11] <tsimonq2> "lxqt-sudo has LXQt in the name, why shouldn't we just push to use that?"
[03:11] <tsimonq2> In reality, when you look at a code, it's just a Qt dialog for pkexec.
[03:12] <tsimonq2> It probably won't work for everything, and very unfortunately (given my own past experience), I don't expect much traction on your well-written issue.
[03:12] <tsimonq2> If you're looking to get something that Just Works and move on, you did the right thing by filing the issue, but I may just use pkexec instead this time. :)
[03:13] <arraybolt3> hmm, to me lxqt-sudo looked like it was its whole own thing that didn't use polkit at all, but yeah, it probably will be ignored.
[03:14] <arraybolt3> Just... ugh, the theming will be off a bit :P
[03:14] <tsimonq2> No, I'm totally with you there. I *wish* we could just use lxqt-sudo.
[03:14] <arraybolt3> and the UI won't be quite as integrated
[03:14] <arraybolt3> if I write the code to make things work myself, we can at least patch it ourselves, and maybe upstream will be more inclined to accept it.
[03:15] <tsimonq2> I think that's a great idea, but I'll remind you yet again to not sink a week on this one. ;)
[03:16] <tsimonq2> @arraybolt3, @wxl, @kc2bez: As of today, you now have upload access to these three, additional packages: qtilitools, sddm-conf, redshift-qt
[03:16] <arraybolt3> heh, don't worry, I won't
[03:16] <tsimonq2> arraybolt3: <3
[03:17] <arraybolt3> oh btw, we need someone to review picom-conf for us (still stuck in NEW), and we have to get sddm-conf and picom-conf into Debian (qtilitools made it in already).
[03:17] <arraybolt3> I should be adding those to The List if they aren't there already
[03:17] <tsimonq2> arraybolt3: I forget, did LoB only sponsor to Debian, or to Ubuntu for that one?
[03:18] <arraybolt3> don't remember either
[03:18] <tsimonq2> I'll take a peek at both, sec.
[03:18] <arraybolt3> I know you uploaded it to Ubuntu
[03:18] <arraybolt3> and I got it sponsored into Debian
[03:18] <tsimonq2> Oh wait, did I? ;)
[03:18] <arraybolt3> same with sddm-conf (that was all you), I did picom-conf
[03:18] <tsimonq2> @teward001: Thomas: 1 Simon: 0
[03:18] <arraybolt3> (and hacked your sddm-conf packaging to do it (and got in trouble for your packaging a little bit))
[03:18] <arraybolt3> :P /s
[03:19] <tsimonq2> hah :D
[03:19] <tsimonq2> I make mistakes too, you know ;D
[03:21] <arraybolt3> ok so I see the code in lxqt-sudo that shuttles info from the child app to the terminal again
 picom-conf is a fork of compton-conf right ?
[03:22] <arraybolt3> (first time encountering PTYs, forks, and weird UNIX process juggling antics all in one application - I bet this is commonplace in lower-level Linux code)
[03:22] <arraybolt3> lynorian: yes
[03:22] <tsimonq2> arraybolt3: It was incredibly common in bcron. ;P
[03:22] <arraybolt3> yuck
[03:34] <tsimonq2> https://tracker.debian.org/news/1491440/accepted-vim-2910-1-source-into-unstable/
[04:04] <arraybolt3> alright so I'm going back to pkexec :P I think buffering is messing me up
[04:04] <arraybolt3> but as soon as lxqt-sudo is viable, we port
[04:05] <arraybolt3> or as soon as I figure out how to fix it
[04:11] <tsimonq2> +1
[04:12] <tsimonq2> We're probably going to get 1.4.2 of Featherpad tomorrow.
[04:15] <arraybolt3> oooooh actually I got it to work with lxqt-sudo
[04:15] <arraybolt3> it's a tad bit buggy since I'm not turning off echo on the pty before writing to the process, so you see what you type doubled
[04:15] <arraybolt3> but otherwise it works
 https://lists.ubuntu.com/archives/ubuntu-release/2024-January/005862.html
 Niceeeee
[04:51] <arraybolt3> meh, working close enough, going to test and see if this is sufficient
[04:51] <arraybolt3> There's a slight bug I *could* fix...
[04:51] <arraybolt3> sigh, yeah, I really could
[04:51] <arraybolt3> anyway, this looks pretty hopeful
[04:55] <arraybolt3> oof, yeah I really need to fix it :P
[04:59] <arraybolt3> aaaAAAaaa these carriage returns make me want to scream and cry
[05:00] <arraybolt3> (not really but wow they can be frustrating)
 felt that
[05:12] <arraybolt3> alright, seems to work finally. Only downside is that input line length is limited to 4095 chars because that's how pseudoterminals work apparently (even pkexec has this issue).
[05:12] <arraybolt3> now I just need to **parse Ctrl+C** (?! yes, I actually have to parse for that) and we should be good :D
[05:18] <arraybolt3> hrm, actually parsing Ctrl+C won't have expected results come to think of it
 https://github.com/lxqt/lxqt/discussions/2139#discussioncomment-7999545
[05:19] <arraybolt3> I think lxqt-sudo's architecture is wrong - the fact that it's still running and shuttling data between a process just seems wrong and it's inhibiting part of how the terminal works (by, oh, disabling Ctrl+C somehow).
[05:20] <arraybolt3> Usually I'd hit Ctrl+C and *instantly* the process will get a SIGINT and it's over. Whereas here I don't know I have a Ctrl+C until the user types it and presses Enter, which is just wrong.
 niceeeeee
 Downstream patch whatever matches Standard and LXQt won't accept (see lxqt-session if you need an example)
[05:21] <arraybolt3> ...what?
[05:21] <arraybolt3> talk to texans?
 Let me rephrase: if LXQt upstream won't accept it, and it's part of an established Standard, we should downstream patch it anyway
 (With some reasonable variance of course.)
[05:22] <arraybolt3> ah, I get it
 Another example is in pcmanfm-qt re: trusted metadata :)
 If you install LXQt on any other distro and mark an executable as trusted, then switch to a different DE, that executable becomes untrusted
 LXQt is the only DE that does this and they reeeeefused to accept a patch making it consistent
 So we just did it downstream :P
[05:24] <arraybolt3> I don't think I can fix the Ctrl+C behavior, but it's already buggy in the existing lxqt-sudo.
[05:24] <arraybolt3> So my patch hasn't broken anything worse at least
 There we go, "no regressions" :P
[05:24] <arraybolt3> probably lxqt-sudo would need fully rewritten to fix whatever's wrong with interrupt handling, given the fact that data shuttling is *deeply* ingrained into its code.
[05:25] <arraybolt3> anyway, patch works, going to forward to upstream for consideration and maybe get you to review it before patching it in Lubuntu.
 Sounds great :) thanks for your help
[05:31] <arraybolt3> https://github.com/lxqt/lxqt-sudo/pull/210
[05:31] -ubottu:#lubuntu-devel- Pull 210 in lxqt/lxqt-sudo "lxqt-sudo: allow bidirectional communication with launched process" [Open]
[05:33] <arraybolt3> tsimonq2: when you go to review it, please overlook my coding style, I tried to match the style of the code around me, thus the weird braces, awful way of specifying if/else blocks, and use of snake_case.
[05:33] <arraybolt3> figured better to conform rather than reform :P
[05:33] <arraybolt3> plus I think devs like when you follow their coding style
 arraybolt3: ack thanks again :)
[11:24] <guiverc> booted lubuntu noble on device with two different resolution displays (3:4 & 16:10), wallpaper on larger display (16.10) is tiled & it doesn't look 'great'... do we care?
[11:42] <guiverc> ^ is petty.. booted another box that shares same displays & the 16:10 display has image full screen; try/install on smaller 4:3 as with other box; yet no tiled (1 full & 3 partial tiles showing on 16:10...)  ..  live system is fully functional, you only boot to install (or use live) rarely so i see little point worrying about this (that only shows on some boxes anyway given here)
[11:44] <guiverc> (actually resolution is possibly different on this box; try/install appeared larger)
[14:29] <arraybolt3> I think we do care. If it's only the background screen, I probably forgot to set the right image scaling mode.
[15:29] <arraybolt3> Main focus for me today will be debugging Cala drive detection failures on Jammy and later when working with mixed-partition-table systems (some disks MBR, some disks GPT). It appears from the support session yesterday that Cala omits GPT drives from the list of installable drives when on a BIOS system.
[15:29] <arraybolt3> Whether it will be easy to fix or not is anyone's guess, but may as well find out.
[15:43] <arraybolt3> ok, cannot reproduce on Jammy, trying Lunar.
[15:45] <arraybolt3> Can't reproduce on Lunar, trying Mantic (this should be the one where it breaks I would hope)
[15:45] <arraybolt3> Curious, can't reproduce on Mantic now.
[15:45] <arraybolt3> so I guess the person from yesterday just had a random glitch...?
[15:46] <Eickmeyer> It was probably machine specific. Different manufacturers have different EFI implementations, and they just fell into a "non-standard" one, if such a thing exists.
[15:46] <arraybolt3> oh they very much exist
[15:47] <arraybolt3> but yeah, Cala sees both GPT and MBR disks on a BIOS VM.
[15:47] <Eickmeyer> My son's gateway machine refuses to dual-boot with grub, but is perfectly fine with rEFInd.
[15:47] <arraybolt3> tsimonq2: gdisk doesn't exist anymore on Lunar out of the box. Bug or feature?
[15:47] <arraybolt3> s/Lunar/Noble/
[15:48] <arraybolt3> gdisk = fdisk for GPT
[15:48] <Eickmeyer> Oh shoot, forgot to warn you all about that. Might need to be specifically seeded now, it was dropped as a depends or recommends for something.
[15:49] <Eickmeyer> I forgot what, but yeah....
[15:49] <Eickmeyer> s/specifically/explicitly
[15:50] <Eickmeyer> Had something to do with partition manager and one of its dependencies. I'm drawing a fog right now.
[15:50] <arraybolt3> well, investigation over, if someone else comes and has the same problem we'll figure it out then.
[15:50] <arraybolt3> Eickmeyer: np, we might not even want it.
[15:50] <Eickmeyer> arraybolt3: Nah, I'm talking about fdisk.
[15:50] <arraybolt3> I only noticed since it caused a slight hiccup in my work that was a single install to fix
[15:50] <arraybolt3> oh, we still have fdisk
[15:50] <arraybolt3> just not gdisk
[15:50] <Eickmeyer> Oh, nevermind then.
[15:51] <arraybolt3> there's probably still something like parted on the ISO (probably I should check), but I just prefer the fdisk-like user interface. I've used parted a few times and it was just too cumbersome.
[15:52] <Eickmeyer> I usually use partitionmanager because graphical.
[15:52]  * arraybolt3 has turned into a CLI-addict who just wants SPEEEEEED
[15:52] <arraybolt3> forget graphical if I can do the same job in two-thirds of the time with a text interface :P
[15:54] <Eickmeyer> I err on the side of accuracy, and if I can get everything visual and not have to visualize it in my brain first, then I'd much rather be accurate.
[15:55] <arraybolt3> Valid point. My brain usually thinks in words, not in pictures, so for me I can generally think of what I'm going for in a text-based way almost faster than partitionmanager can scan my drives (which sometimes can just be downright horribly slow).
 arraybolt3: I seem to recall the rationale being "it has a G in it so remove it" when we were switching to LXQt :P
[15:56] <arraybolt3> It's present in Jammy though...
[15:56] <arraybolt3> hahaha
[15:56] <arraybolt3> yeah g = gpt in gdisk :P
[15:57] <arraybolt3> It would be a nice-to-have for me personally, but definitely not a need or even much of an obstruction.
 gwenview. 💀 (re @tsimonq2: arraybolt3: I seem to recall the rationale being "it has a G in it so remove it" when we were switching to LXQt :P)
 Tooooootally not my point.
[18:19] <arraybolt3> Looks like I finally have bidirectional communication working in lubuntu-update :D
[18:25] <Eickmeyer> \o/
[18:31] <Eickmeyer> arraybolt3, @tsimonq2, you've both been summoned in #ubuntu-release. May God have mercy on your soul. 💀
[20:05] <arraybolt3> Looks like we may be writing Many Manpages soon...
[20:06] <arraybolt3> either that or else removing overrides and living with the warnings
[20:06] <arraybolt3> I've written them before and actually enjoy it, so I'm happy to do that.
[20:06] <arraybolt3> but then of course we get to override maintainer-manual-page instead since upstream doesn't want them :P
[20:34] <arraybolt3> conffile handling works
[20:34]  * arraybolt3 is happy about that
[20:42] <arraybolt3> kc2bez: mind adding me to the lubuntu-wiki team?
[20:43] <arraybolt3> currently it appears I can't write to it
[20:49] <Eickmeyer> arraybolt3: Can I just compliment you on how much you ABSOLUTELY KICKED BUTT in #ubuntu-release? Not many people can do what you just did.
[20:51] <tsimonq2> 💯💯💯💯 ^^^^^^^
[20:53] <Eickmeyer> Another point that wasn't as part of the Debian policy regarding manpages: TL;DR: If the documentation exists elsewhere, if a manpage doesn't exist, the warning can be overridden *as long as* the override is commented with where the documentation is located, whether it be a URL or another location in the fhs.
[20:53] <Eickmeyer> *wasn't mentioned
[21:08] <arraybolt3> Eickmeyer, tsimonq2: Thanks! I'm more happy that I didn't win but came to a compromise instead since that will improve our packaging.
[21:09] <tsimonq2> arraybolt3: You did win in one respect: you didn't back down and kept it respectful. Very positive sign.
[21:09] <tsimonq2> (And in that case, both you and Steve won.)
[21:12] <arraybolt3> +1
[21:55] <tsimonq2> The reason Lubuntu doesn't use git-ubuntu (yet?) is because it captures all the orig stuff.
[21:55] <tsimonq2> Makes it much easier to clone and work with when you don't have the orig in it. That's my personal opinion. :P
[21:56] <tsimonq2> I'm working with arraybolt3 on a "training wheels" patch pilot session in #ubuntu-devel right now.
[22:54] <Eickmeyer> arraybolt3: Fantastic job in there! Way to go student pilot!
[22:55] <arraybolt3> Thanks :)
[23:00] <tsimonq2> 💯💯
[23:01] <tsimonq2> arraybolt3 has just been on a roll today. :D
[23:01] <arraybolt3> tsimonq2: btw did you ever upload Manuskript?
[23:01] <arraybolt3> https://bugs.launchpad.net/ubuntu/+source/manuskript/+bug/1989203
[23:01] -ubottu:#lubuntu-devel- Launchpad bug 1989203 in manuskript (Ubuntu Jammy) "Manuskript crashes on start" [High, In Progress]
[23:01] <arraybolt3> (totally off topic for this room but who cares)
[23:02] <arraybolt3> I think In Progress means you did, not sure.
[23:02] <arraybolt3> actually that is what it means, so I need to poke the SRU team
[23:03] <tsimonq2> I'm ... confused heh
[23:03] <tsimonq2> That's not in the queue:
[23:03] <tsimonq2> https://launchpad.net/ubuntu/jammy/+queue?queue_state=1&queue_text=manuskript
[23:03] <arraybolt3> tsimonq2: ...
[23:03] <arraybolt3> hrm
[23:04] <tsimonq2> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2024-January/001342.html
[23:04] <arraybolt3> tsimonq2: are you sure you uploaded it? :P
[23:04] <tsimonq2> I'm checking my email now to see if there's an autoreject email.
[23:04] <tsimonq2> I'm pretty sure I did...
[23:05] <tsimonq2> File manuskript_0.12.0-1ubuntu0.22.04.1.debian.tar.xz already exists in Primary Archive for Ubuntu, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors.
[23:05] <tsimonq2> arraybolt3: Version Numbers Are Cheap
[23:05] <arraybolt3> *shakes LP vigorously*
[23:05] <tsimonq2> arraybolt3: You know *why* I got that message right?
[23:05] <arraybolt3> yep
[23:06] <tsimonq2> queue version numbers apparently count for some reason :P:
[23:06] <arraybolt3> even a package rejection still burns a version number :-/
[23:06] <tsimonq2> arraybolt3: Protip: always make sure your uploads actually make it XD
[23:06] <arraybolt3> heh, usually I get an email when they don't :P
[23:07] <arraybolt3> (correction - package rejection doesn't burn a version number, package upload-accept-into-proposed-test-failed-verification-removed-from-proposed burns a version number.)
[23:08] <tsimonq2> arraybolt3: Minor nitpick: don't say that you're backporting the changes, focus more on what the changes are and have backports as a secondary item (read: tone)
[23:08]  * arraybolt3 botches MoinMoin syntax
[23:08] <tsimonq2> MoinMoin syntax is meant to be botched ;P
 I use other words next to MoinMoin
[23:09] <arraybolt3> It's like HTML is markup, MD is markdown, and MoinMoin is markno
 MoinMoin is NightNight
 Or at least it should be
[23:11] <arraybolt3> 👍
[23:11] <arraybolt3> tsimonq2: thanks, I see the Manuskript upload worked this time
[23:15] <tsimonq2> arraybolt3: Of course <3
[23:59] <arraybolt3> hmm, just dawned on me that OEM setup in Lubuntu means we will need to write an OEM wizard, complete with first-time setup acrobatics.
[23:59] <arraybolt3> I'm thinking perhaps exiting OEM mode doesn't mean the wizard creates a new user and deletes the old one, but rather it renames the OEM user to something else, resets the password, and then BOOM that's the user's new account?