[00:57] 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) [00:59] [telegram] bah, drop in the bucket [01:16] 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] but I'm fine with letting music stream all night off YouTube so I guess I must view Google's bandwidth as unlimited XD [01:19] [telegram] The lights are on, streaming or not. Might as well use them ;) [01:34] shoot, just deleted my snapshot instead of restoring it. [01:34] 🤪 [01:35] and I can't revert lubuntu-default-settings to 24.04.2 XD [01:35] sigh, alrighty, this is going to be fun to undo [01:36] (that one package was helping me get conffile prompts) [01:36] (which were the very things I was just testing / fixing) [01:36] [telegram] Dang [01:37] anyway, I'll just rebuild 24.04.2 from source, install it, tweak conffiles, then re-upgrade and be back up and running. [01:37] [telegram] That's the spirit. [01:38] 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] also lxqt-sudo is turning some newlines into CRLF combos :-/ [01:38] or something is at least [01:40] and also come to think of it it's putting things on stderr that shouldn't be there [01:41] I'm wondering if perhaps it needs patched to have a "raw" mode. [01:44] yeah, it looks like lxqt-sudo emulates a whole terminal [01:49] 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] Or maybe I just keep working around it. [01:53] 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] 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] arraybolt3: Externalize into its own script and use lxqt-sudo to call that? [03:04] Either way I'd be inclined to try pkexec as a temporary stop-gap. :) [03:06] Oh I already have externalized things into its own script. [03:06] The trouble is the app needs to talk to the script. [03:07] And lxqt-sudo is acting a bit more like a wall than a pipe :P [03:07] yeah, pkexec should work, but yuck [03:07] hmm, actually it doesn't look that bad now that I'm looking at it [03:10] 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] arraybolt3: You're falling into the same exact line of thought I had when launching Calamares. :) [03:11] "lxqt-sudo has LXQt in the name, why shouldn't we just push to use that?" [03:11] In reality, when you look at a code, it's just a Qt dialog for pkexec. [03:12] 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] 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] 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] Just... ugh, the theming will be off a bit :P [03:14] No, I'm totally with you there. I *wish* we could just use lxqt-sudo. [03:14] and the UI won't be quite as integrated [03:14] 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] I think that's a great idea, but I'll remind you yet again to not sink a week on this one. ;) [03:16] @arraybolt3, @wxl, @kc2bez: As of today, you now have upload access to these three, additional packages: qtilitools, sddm-conf, redshift-qt [03:16] heh, don't worry, I won't [03:16] arraybolt3: <3 [03:17] 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] I should be adding those to The List if they aren't there already [03:17] arraybolt3: I forget, did LoB only sponsor to Debian, or to Ubuntu for that one? [03:18] don't remember either [03:18] I'll take a peek at both, sec. [03:18] I know you uploaded it to Ubuntu [03:18] and I got it sponsored into Debian [03:18] Oh wait, did I? ;) [03:18] same with sddm-conf (that was all you), I did picom-conf [03:18] @teward001: Thomas: 1 Simon: 0 [03:18] (and hacked your sddm-conf packaging to do it (and got in trouble for your packaging a little bit)) [03:18] :P /s [03:19] hah :D [03:19] I make mistakes too, you know ;D [03:21] ok so I see the code in lxqt-sudo that shuttles info from the child app to the terminal again [03:22] [telegram] picom-conf is a fork of compton-conf right ? [03:22] (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] lynorian: yes [03:22] arraybolt3: It was incredibly common in bcron. ;P [03:22] yuck [03:34] https://tracker.debian.org/news/1491440/accepted-vim-2910-1-source-into-unstable/ [04:04] alright so I'm going back to pkexec :P I think buffering is messing me up [04:04] but as soon as lxqt-sudo is viable, we port [04:05] or as soon as I figure out how to fix it [04:11] +1 [04:12] We're probably going to get 1.4.2 of Featherpad tomorrow. [04:15] oooooh actually I got it to work with lxqt-sudo [04:15] 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] but otherwise it works [04:24] [telegram] https://lists.ubuntu.com/archives/ubuntu-release/2024-January/005862.html [04:24] [telegram] Niceeeee [04:51] meh, working close enough, going to test and see if this is sufficient [04:51] There's a slight bug I *could* fix... [04:51] sigh, yeah, I really could [04:51] anyway, this looks pretty hopeful [04:55] oof, yeah I really need to fix it :P [04:59] aaaAAAaaa these carriage returns make me want to scream and cry [05:00] (not really but wow they can be frustrating) [05:10] [telegram] felt that [05:12] 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] now I just need to **parse Ctrl+C** (?! yes, I actually have to parse for that) and we should be good :D [05:18] hrm, actually parsing Ctrl+C won't have expected results come to think of it [05:18] [telegram] https://github.com/lxqt/lxqt/discussions/2139#discussioncomment-7999545 [05:19] 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] 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. [05:20] [telegram] niceeeeee [05:21] [telegram] Downstream patch whatever matches Standard and LXQt won't accept (see lxqt-session if you need an example) [05:21] ...what? [05:21] talk to texans? [05:22] [telegram] Let me rephrase: if LXQt upstream won't accept it, and it's part of an established Standard, we should downstream patch it anyway [05:22] [telegram] (With some reasonable variance of course.) [05:22] ah, I get it [05:22] [telegram] Another example is in pcmanfm-qt re: trusted metadata :) [05:23] [telegram] If you install LXQt on any other distro and mark an executable as trusted, then switch to a different DE, that executable becomes untrusted [05:23] [telegram] LXQt is the only DE that does this and they reeeeefused to accept a patch making it consistent [05:23] [telegram] So we just did it downstream :P [05:24] I don't think I can fix the Ctrl+C behavior, but it's already buggy in the existing lxqt-sudo. [05:24] So my patch hasn't broken anything worse at least [05:24] [telegram] There we go, "no regressions" :P [05:24] 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] anyway, patch works, going to forward to upstream for consideration and maybe get you to review it before patching it in Lubuntu. [05:25] [telegram] Sounds great :) thanks for your help [05:31] 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] 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] figured better to conform rather than reform :P [05:33] plus I think devs like when you follow their coding style [06:44] [telegram] arraybolt3: ack thanks again :) [11:24] 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] ^ 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] (actually resolution is possibly different on this box; try/install appeared larger) [14:29] I think we do care. If it's only the background screen, I probably forgot to set the right image scaling mode. [15:29] 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] Whether it will be easy to fix or not is anyone's guess, but may as well find out. [15:43] ok, cannot reproduce on Jammy, trying Lunar. [15:45] Can't reproduce on Lunar, trying Mantic (this should be the one where it breaks I would hope) [15:45] Curious, can't reproduce on Mantic now. [15:45] so I guess the person from yesterday just had a random glitch...? [15:46] 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] oh they very much exist [15:47] but yeah, Cala sees both GPT and MBR disks on a BIOS VM. [15:47] My son's gateway machine refuses to dual-boot with grub, but is perfectly fine with rEFInd. [15:47] tsimonq2: gdisk doesn't exist anymore on Lunar out of the box. Bug or feature? [15:47] s/Lunar/Noble/ [15:48] gdisk = fdisk for GPT [15:48] 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] I forgot what, but yeah.... [15:49] s/specifically/explicitly [15:50] Had something to do with partition manager and one of its dependencies. I'm drawing a fog right now. [15:50] well, investigation over, if someone else comes and has the same problem we'll figure it out then. [15:50] Eickmeyer: np, we might not even want it. [15:50] arraybolt3: Nah, I'm talking about fdisk. [15:50] I only noticed since it caused a slight hiccup in my work that was a single install to fix [15:50] oh, we still have fdisk [15:50] just not gdisk [15:50] Oh, nevermind then. [15:51] 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] I usually use partitionmanager because graphical. [15:52] * arraybolt3 has turned into a CLI-addict who just wants SPEEEEEED [15:52] forget graphical if I can do the same job in two-thirds of the time with a text interface :P [15:54] 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] 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). [15:56] [telegram] 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] It's present in Jammy though... [15:56] hahaha [15:56] yeah g = gpt in gdisk :P [15:57] It would be a nice-to-have for me personally, but definitely not a need or even much of an obstruction. [16:06] [telegram] 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) [16:07] [matrix] yeah we use lximage-qt [16:07] [matrix] so no Gwenview for us :D [16:07] [telegram] Tooooootally not my point. [16:08] [matrix] oh, I misunderstood the joke :P [18:19] Looks like I finally have bidirectional communication working in lubuntu-update :D [18:25] \o/ [18:31] arraybolt3, @tsimonq2, you've both been summoned in #ubuntu-release. May God have mercy on your soul. 💀 [20:05] Looks like we may be writing Many Manpages soon... [20:06] either that or else removing overrides and living with the warnings [20:06] I've written them before and actually enjoy it, so I'm happy to do that. [20:06] but then of course we get to override maintainer-manual-page instead since upstream doesn't want them :P [20:34] conffile handling works [20:34] * arraybolt3 is happy about that [20:42] kc2bez: mind adding me to the lubuntu-wiki team? [20:43] currently it appears I can't write to it [20:49] 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] 💯💯💯💯 ^^^^^^^ [20:53] 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] *wasn't mentioned [21:08] 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] arraybolt3: You did win in one respect: you didn't back down and kept it respectful. Very positive sign. [21:09] (And in that case, both you and Steve won.) [21:12] +1 === arraybolt3 is now known as arraybolt3_tl [21:55] The reason Lubuntu doesn't use git-ubuntu (yet?) is because it captures all the orig stuff. [21:55] [matrix] Give that a whirl and let me know. [21:55] 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] I'm working with arraybolt3 on a "training wheels" patch pilot session in #ubuntu-devel right now. [21:56] [matrix] Nice === arraybolt3_tl is now known as arraybolt3 [22:54] arraybolt3: Fantastic job in there! Way to go student pilot! [22:55] Thanks :) [23:00] 💯💯 [23:01] arraybolt3 has just been on a roll today. :D [23:01] tsimonq2: btw did you ever upload Manuskript? [23:01] 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] (totally off topic for this room but who cares) [23:02] I think In Progress means you did, not sure. [23:02] actually that is what it means, so I need to poke the SRU team [23:03] I'm ... confused heh [23:03] That's not in the queue: [23:03] https://launchpad.net/ubuntu/jammy/+queue?queue_state=1&queue_text=manuskript [23:03] tsimonq2: ... [23:03] hrm [23:04] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2024-January/001342.html [23:04] tsimonq2: are you sure you uploaded it? :P [23:04] I'm checking my email now to see if there's an autoreject email. [23:04] I'm pretty sure I did... [23:05] 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] arraybolt3: Version Numbers Are Cheap [23:05] *shakes LP vigorously* [23:05] arraybolt3: You know *why* I got that message right? [23:05] yep [23:06] queue version numbers apparently count for some reason :P: [23:06] even a package rejection still burns a version number :-/ [23:06] arraybolt3: Protip: always make sure your uploads actually make it XD [23:06] heh, usually I get an email when they don't :P [23:07] (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] 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] MoinMoin syntax is meant to be botched ;P [23:09] [telegram] I use other words next to MoinMoin [23:09] It's like HTML is markup, MD is markdown, and MoinMoin is markno [23:10] [telegram] MoinMoin is NightNight [23:11] [telegram] Or at least it should be [23:11] 👍 [23:11] tsimonq2: thanks, I see the Manuskript upload worked this time [23:15] arraybolt3: Of course <3 [23:59] 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] 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?