[22:09] guiverc @Leokolb: https://calamares.io/calamares-3.2.59-is-out/ should be in Kinetic shortly, here's the package link: https://launchpad.net/ubuntu/+source/calamares/3.2.59-0ubuntu1 [22:09] Please test once it lands, should only be bugfixes [22:52] That tweet was me, by the way. If it's a popular thing, I'll personally do the backporting as needed. [22:56] kc2bez: liblzqt pushed [22:56] woah hi keyboard [22:56] liblxqt [22:57] thanks tsimonq2 [23:06] of course :) [23:14] tsimonq2: Will be waiting for it to hit. [23:14] Sounds good! [23:14] :) & thanks arraybolt3 [23:14] Hey, so we should really think of a streamlined way for developers to request testing. Does everyone watch Discourse? [23:14] Just checked, appears to already be in Proposed, and I *just* zsync'd the ISO. [23:14] Yeah, I watch Discourse. [23:15] guiverc @Leokolb: If you guys watch Discourse, let's streamline all the testing I'm about to ask for there ;) [23:15] I do, and think it's an appropriate place tsimonq2 [23:17] Also, I finished that quick VM testing script I was talking about the other day. It's similar to QuickEmu (the tool kc2bez uses), but more targeted toward testing, and allows you to make a VM with the disk stored entirely in RAM if you have 32GB of RAM or more. It's working for me so far. I put it on my GitHub, ArrayBolt3/vm-isotest, if anyone's interested. [23:18] Thoughts on here vs a dedicated QA Discourse feed? https://discourse.lubuntu.me/c/development/7 [23:18] arraybolt3: Nice. I'm stuck in my ways but that's 'cause I've been doing this for a few years now... :) [23:18] I dunno what a dedicated QA Discourse feed is... [23:19] Is it just a post where stuff is announced about "this needs testing"? [23:19] okay so in Discourse there's categories [23:19] maybe make it a page in development; the 'to test' can be the first 'wiki' post (points removed as completed; added) with comments made after that ... maybe -- we can adjust if it's not suitable [23:19] I said feed but really meant that :) [23:19] but yea [23:19] Do we want to do one post that we just edit over time or do we want to do one post per testing issue? [23:20] Oh, so there's also tags [23:20] so [23:20] we can do like [23:20] NEEDSTESTING [23:20] perfect [23:20] My vote is for one post edited over time, that way we don't make too much noise in the Development section, which is usually rather quiet. [23:20] That way if something really blows up, someone can put it there and grab everyone's attention, rather than it potentially getting lost in the noise. [23:20] it'll be very long if the post is used for everything... so we can 'adjust' as needed & experience gained [23:20] Okay cool, so I'll create a post. [23:21] Sec, I'll link it. [23:21] I'll look later.. and I'll see it [23:21] Can we just remove stuff once it passes testing? We can reply to the post when we've done the testing and what hardware we used and then delete the replies when no longer needed. Just a thought. [23:22] (Or move the replies to an archive as needed - that could get sorta cumbersome.) [23:22] what I was meaning is like our tracking pages; eg. https://discourse.lubuntu.me/t/lubuntu-jammy-jellyfish-22-04-issue-tracker/3101 for 22.04 - the top 'wiki' page kept shrinking as I removed posts... (I maybe should use strikeout so readers see progress..) [23:24] Yeah but replies could start getting very lengthy, and I don't know how Discourse will handle multiple simultaneous edits to the same wiki post. Maybe we need a separate IRC channel for just recording our progress, and have the wiki post just be the "this is what needs done" area. [23:24] #lubuntu-testing is unused. [23:25] what I've suggested i find easy enough; in browser 'HOME' jumps me to top (wiki page) & END jumps me to latest post (can be a delay yes if loads of posts on thread) [23:27] Oh OK. And I guess we can always make a new wiki post if one post seems to be getting a little long in the scroll-bar size. [23:27] or just create one per cycle as with the issue tracking pages... [23:28] * guiverc we can implment new pages earlier too, as required.. we can set our own rules ! [23:28] (And you're right - END takes me straight to the end. Didn't know that trick. Weird, I can make 200+ line Bash scripts for quick testing and help debug boot failures, but I don't know how to use important features of my browser?!) [23:29] we're all still learning..... (I just wish I didn't forget so much of what I learnt!) [23:30] I'm happy to report that the new version of Calamares no longer has the problem with the greyed out Next button when you select No Swap! (At least in a German install - I'm also testing for the LibreOffice localization bug.) [23:31] :) & Yippee arraybolt3 tsimonq2 , thanks for testing! [23:32] https://discourse.lubuntu.me/t/qa-needs-testing-issue-tracker-updated-over-time/3376 [23:33] arraybolt3: ohhhh yeah? [23:33] When did that fix happen? [23:33] Dunno. I've been testing the daily ISO, and it's been happening, but I just grabbed the Proposed one that you uploaded, and now it's fixed. I'll test without the Proposed to see if it still happens there. [23:36] Should I report the fix on the ISO QA tracker, or should I leave it off since I grabbed the Proposed repository? [23:37] !itsawiki [23:37] It's a wiki, *you* can edit it [23:37] arraybolt3, my opinion: if it's fixed by a proposed package; it doesn't yet belong on iso.qa.ubuntu.com; just reported on the launchpad bug itself [23:38] We can make Discourse posts a wiki page too so you minimize the replies [23:38] guiverc: :+1: ('cause finding the thumbs up emoji in my selector is harder, but typing this was harder yet still, so here: 👍) [23:38] fyi: I do report tests on iso.qa.ubuntu.com if using testing proposed; but don't report NEW BUGS if they occur because of proposed packages... but do NTOE them in the comments! [23:39] ^ assumes it's the latest ISO being used; not an old one [23:39] "liblxqt" <- Ta [23:40] guiverc: Should I note a fixed bug in the comments, too? [23:41] For sure... you put everything in comments you feel belongs there.. the real important place though in my opinion being the lp.bug.report where you can provide a link to the iso.qa.ubuntu.com page where your comments can be found (if helpful to readers in the future) [23:42] Ah, good idea. [23:47] (This might be silly, but is it OK that I'm doing a lot of testing that results in downloading quite a bit of data from Ubuntu's servers? I don't want to drive an Internet bill through the roof because I had to pull all the Proposed updates multiple times for testing one package in multiple scenarios.) [23:48] https://github.com/lubuntu-team/qtxdg-tools-packaging [23:48] [telegram] every download & test you perform on Lubuntu helps test the base system which is identical with other flavors & main Ubuntu itself. Your testing is helping all of Ubuntu; don't worry about data usage... [23:48] (And one more thing - how should I edit the Wiki to note my test results? Or should I reply and not edit? Or do I take a wild guess and just try not to mess anything up? (Please don't tell me to do that last one...)) [23:49] tsimonq2: Link gives me a 404 not found. [23:49] [telegram] put any results not on the WIKI at the top; but on a reply/comment later in the thread.. Let the person who asked for testing (Simon/tsimonq2) remove it from the wiki when they're happy [23:49] oh wtf [23:50] [telegram] ^ is referring to the tracking docs on discourse [23:51] * tsimonq2 was referring to the GH repo which is now public [23:51] I can see it Simon Quigley [23:51] OK now it's working. [23:55] tsimonq2: Not to be impatient, but since you're posting a lot of stuff about LXQt, is there anything I can do on my end to help (compiling, testing, etc)? [23:55] Not at the moment. [23:55] I'll let ya know.