[00:05] <arraybolt3[m]> Simon Quigley (Developer): OK, I just finished reading through the Calamares changelog, and made a list of everything I thought might be a trouble spot (something that could cause a significant change in the installed system). There's only one mandatory configuration change I saw, I marked it very clearly. https://pastebin.com/cEEXHqrn
[00:25] <arraybolt3[m]> Looking at our config, I think even the one trouble spot is unlikely to be a problem.
[00:35] <Eickmeyer[m]> Many of those seem like bugfixes to me, masquerading as new features.
[01:07] <arraybolt3[m]> Well I guess that's one way to do it, but it give me anxiety :P
[01:11] <tsimonq2> <arraybolt3[m]> "Simon Quigley (Developer): OK, I..." <- Okay, out of that list, eliminate the modules we don't actively use 
[01:12] <arraybolt3[m]> Uh... one moment, I'm in the middle of wrestling The Great Lintian Tantrum over here, I'll be on it in just a bit.
[01:14] <tsimonq2> Arraybolt vs Lintian Season 1 episode 15: The Linting
[01:15] <arraybolt3[m]> You should've seen the mess it spit out on my screen after the first build. Good grief.
[01:16] <arraybolt3[m]> (On the bright side, I'm getting to practice my rational-fu for some of the changes I'm making - I totally removed an entire patch from the patches directory and had a good reason for why. Hopefully it'll end up being something you like, rather than an epic boffo you have to tell me was wrong...)
[01:17] <tsimonq2> Very nice :)
[01:17] <arraybolt3[m]> While you're right here, can you tell me if these Lintian gripes are anything to worry about?
[01:17] <arraybolt3[m]> X: calamares: exit-in-shared-library usr/lib/x86_64-linux-gnu/libcalamares.so.3.2.60
[01:17] <arraybolt3[m]> X: calamares: exit-in-shared-library usr/lib/x86_64-linux-gnu/libcalamaresui.so.3.2.60
[01:36] <tsimonq2> What's that flag do?
[01:37] <arraybolt3[m]> I should've looked that up first.
[01:37]  * arraybolt3[m] is getting brainfried
[01:38] <arraybolt3[m]> The listed shared library calls the C library exit() or _exit() functions.
[01:38] <arraybolt3[m]> In the case of an error, the library should instead return an appropriate error code to the calling program which can then determine how to handle the error, including performing any required clean-up.
[01:38] <arraybolt3[m]> In most cases, removing the call should be discussed with upstream, particularly as it may produce an ABI change.
[01:39] <arraybolt3[m]> I don't think anything other than Calamares is going to use a library called "libcalamares" or "libcalamaresui", so I think I can just override it - Calamares must be designed to work this way (at least that's what would seem most logical to me).
[01:51] <arraybolt3[m]> OK, hopefully not-so-silly question: Currently we aren't installing src/modules/notesqml/examples/, which is causing a Lintian gripe. I see no reason to install these files, and believe I should override them, but at the same time, the Lintian page for this tag seems to suggest I make them install. Thoughts?
[02:08] <Eickmeyer[m]> <arraybolt3[m]> "OK, hopefully not-so-silly..." <- That's the wrong way to not install. It would be needed to be added to a debian/not-installed or debian/{package}.not-installed file.
[02:08] <arraybolt3[m]> Oh, OK, I didn't know that. Thank you!
[02:09] <Eickmeyer[m]> No prob. Little things like that are good to know when packaging. It's like the reverse of a .install file.
=== guiverc2 is now known as guiverc
[09:51] <arraybolt3[m]> https://bugs.launchpad.net/ubuntu/+source/calamares/+bug/1980180/comments/7 Good news on the Calamares SRU front!
[09:51] <ubot93> Launchpad bug 1980180 in calamares (Ubuntu Jammy) "[SRU] Calamares 3.2 Series for 22.04 LTS" [Medium, Triaged]
[09:52] <guiverc> :)
[10:26] <guiverc> @LeoK[m], should we create a duplicate (testing checklist) page for the 22.04.1 with -proposed calamares maybe...  & start crossing things off there..   (anyone with ideas etc is welcome to chime in too)  or maybe another field? is a better idea?  (though doc was already somewhat wide)
[10:32] <guiverc> one advantage of a seperate page is it won't get overwritten if anyone reads the SRU page when we've moved on to something else (if needed later b/c of bugs with jammy.2 or something..)
[10:54] <lubot> [telegram] <Leokolb> I think better to have another field so - to keep it simple - proposed will be heavy checking on manual partitioning etc . (re @lubuntu_bot: (irc) <guiverc> @LeoK[m], should we create a duplicate (testing checklist) page for the 22.04.1 with -proposed calamares maybe...  & start crossing things off there..   (anyone with ideas etc is welcome to chime in too)  or maybe another field? is a better idea?  (though doc was already somewhat 
[10:54] <lubot> [telegram] <Leokolb> Open to all ideas..
[10:54] <guiverc> :)  I personally prefer another field over two pages... less chance of errors I suspect
[10:55] <lubot> [telegram] <Leokolb> ah..we on same page! (re @lubuntu_bot: (irc) <guiverc> :)  I personally prefer another field over two pages... less chance of errors I suspect)
[10:55] <guiverc> :) LOL
[11:22] <arraybolt3[m]> Just finished the SRU packaging and did a quick test - installation was successful and the VM allowed me to use Firefox!
[11:22]  * arraybolt3[m] files pull request
[11:23] <arraybolt3[m]> https://github.com/lubuntu-team/calamares-packaging/pull/2
[11:23] <ubot93> Pull 2 in lubuntu-team/calamares-packaging "Calamares 3.2.60 SRU" [Open]
[11:23] <arraybolt3[m]> Simon Quigley (Developer): ^
[11:50] <lubot> [telegram] <Roberalz> What is the problem with lubuntu-update-notifier? (re @lubuntu_bot: (irc) <tsimonq2> lubuntu-update-notifier is one)
[18:10] <tsimonq2> arraybolt3 @arraybolt3:matrix.org: I'm going to prioritize this and get it uploaded today. Since you're the uploader and it makes rational sense, I would like you to be the one to ping the SRU vanguard in -release to ask them to accept it today.
[18:13] <tsimonq2> arraybolt3 @arraybolt3:matrix.org: After briefly reviewing your patch, I'm a -1 on the amount of changes being merged in. You should *only*, and I mean **only**, make changes necessary to update to the next upstream release. Also, that patch "fixing" our use of sudo has a major bug in Kinetic, and should **not** be SRUed. Please re-review the criteria for an SRU, taking into account the mantra of "small diffs tend to correlate to a smaller
[18:13] <tsimonq2> regression window." -1
[18:15] <tsimonq2> Also, instead of "SRU update," that entry should actually describe what the SRU does in one brief sentence
[22:39] <arraybolt3[m]> Simon Quigley (Developer): I made the number of changes I did only to satisfy Lintian. If I do not make that many changes, the build will not be Lintian-clean. Is that acceptable?
[22:40] <arraybolt3[m]> Or are some of the usual changes (like bumping Standards-Version) supposed to be dropped?
[22:42] <tsimonq2> arraybolt3[m]: Yes
[22:42] <arraybolt3[m]> Anyway, I'll start by undoing my "sudo fixing" patch, and maybe you can help me figure out the balance we need to make a good SRU.
[22:48] <arraybolt3[m]> Simon Quigley (Developer): Should I also drop all changes that made Lintian happy but weren't strictly necessary and the messages can be safely ignored?
[22:51] <tsimonq2> arraybolt3[m]: Correct
[22:52] <tsimonq2> In a bit I can explain why...
[22:59] <arraybolt3[m]> It just feels so wrong to leave broken stuff in the packaging for the sake of stability LOL. I fully understand why it works and why it's the way it should be done, and now that you're telling it to me, I agree, but it's counterintuitive :-P
[23:03] <arraybolt3[m]> Simon Quigley (Developer): I did leave the change where I removed the manpage that was in the packaging since there was already a manpage in Calamares, because I thought having two manpages in two different spots for the same program could be confusing. Should I revert that too for the sake of having fewer changes, even though that would mean potentially leaving or introducing a bug?
[23:04] <arraybolt3[m]> * a bug? Like, maybe it needs to have its own SRU?
[23:07] <arraybolt3[m]> <tsimonq2> "arraybolt3 @arraybolt3:matrix...." <- When you say this, do you mean that my change that undid the "use sudo rather than pkexec" was good, or bad?
[23:07] <arraybolt3[m]> I don't know if you mean my patch or the patch my patch clobbered.
[23:32] <arraybolt3[m]> Simon Quigley (Developer): Fixed and pushed, the sudo fixing patch I created was undone, the manpage fixing patch was left in place, and a ton of stuff was reverted. I did a quick test, and the package successfully installed Lubuntu 22.04 in a GNOME Boxes VM.
[23:48] <tsimonq2> <arraybolt3[m]> "Simon Quigley (Developer): Fixed..." <- Eew. Thanks tho
[23:49] <arraybolt3[m]> tsimonq2: I'm guessing something went wrong?
[23:50] <arraybolt3[m]> (Was I not supposed to use git revert?)
[23:50] <tsimonq2> arraybolt3[m]: Nope, GNOME Boxes :P
[23:50] <arraybolt3[m]> Ah. OK.
[23:50] <arraybolt3[m]> (You don't like GNOME Boxes? I'm surprised. What virt software do you use?)
[23:52] <tsimonq2> virt-manager
[23:52] <tsimonq2> Cockpit too
[23:52] <tsimonq2> (Please try Cockpit at least once lol)
[23:52] <arraybolt3[m]> virt-manager just takes SO MUCH TIME to make each VM. Thus why I got rid of it. I've never tried Cockpit though, I'll take a look.
[23:52] <arraybolt3[m]> (Like, the wizard is powerful, but there's way too many options - I like being able to just say, "Look, here's the ISO, now do it!")
[23:53] <tsimonq2> Cockpit is so nice. I didn't tell you that it's eventually supposed to be the successor to virt-manager
[23:53] <arraybolt3[m]> (And even that can be a bit long sometimes, so I made a script to let me make a VM with one command :P)
[23:55] <arraybolt3[m]> OK, I'll try Cockpit. A quick looks makes it seem like it's fast and powerful, so that might be fun.
[23:56] <tsimonq2> You can literally give it an ISO URL and it will totally make the VM for you
[23:56]  * tsimonq2 would recommend zsync though
[23:59] <kc2bez[m]> Quickemu is the bomb