[02:59] <arraybolt3[m]> OK, I looked at the docs for `germinate`, and I understand what I'm looking at enough to be able to add qtxdg-tools to the seed. The problem is, I don't know how to properly test the changes I would make. I assume what I should do is:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/b5cc18cd47dd85fa2c184e0044bc1009478db4ba>)
[02:59] <arraybolt3[m]>  * OK, I looked at the docs for `germinate`, and I understand what I'm looking at enough to be able to add qtxdg-tools to the seed. The problem is, I don't know how to properly test the changes I would make. I assume what I should do is:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/02c4fa58dd130b4d471df529eae2ce973e6a9221>)
[03:00] <tsimonq2> That is the best, safest way to do it, I would agree with that much 
[03:01] <arraybolt3[m]> Nice. I have to go afk again, but now we have a plan of attack. Thank you!
[03:45] <arraybolt3[m]> Simon Quigley: OK, this is the diff of the two germinate runs. It looks right to me, can I run it by you to make sure that it looks right to you too? https://termbin.com/dcvqb
[03:46] <arraybolt3[m]> (I just got all the seed files together, ran germinate with germinate -S file:///home/arraybolt3/Projects/ubuntu/lubuntu-seed -d lunar -s lubuntu -a amd64 -c main,universe,restricted,multiverse, put all the tons of output in one folder, added qtxdg-tools to the seed, ran it again, moved all that output to a second folder, then did diff -r -u run1 run2 on it.)
[03:47] <arraybolt3[m]> Also, the modification I made was:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/3a659fa603b50dc0252e910f623171457a372904>)
[03:47] <arraybolt3[m]> (I didn't put the comment in though :P)
[03:48] <arraybolt3[m]>  * (I just got all the seed files together, ran germinate with germinate -S file:///home/arraybolt3/Projects/ubuntu/lubuntu-seed -d lunar -s lubuntu -a amd64 -c main,universe,restricted,multiverse, put all the tons of output in one folder, added qtxdg-tools to the seed, ran germinate again, moved all that output to a second folder, then did diff -r -u run1 run2 on it.)
[04:29] <tsimonq2> The seed output looks correct. Remember to push a commit to the actual seed repo and use ./update for lubuntu-meta :)
[04:31] <arraybolt3[m]> Nice. (Forgot that I would need to update lubuntu-meta, thank you for the reminder!)
[04:36] <arraybolt3[m]> Simon Quigley: Last time we updated the seed and lubuntu-meta, I know the seed was on LP, but I *think* that lubuntu-meta is in Gitea and then uploaded to LP, right? Or did I forget where in LP I'm supposed to find lubuntu-meta?
[04:38] <arraybolt3[m]> (yikes, looks like we never uploaded it last time after updating it!)
[04:39] <arraybolt3[m]> (I guess that means it probably isn't in LP, then.)
[04:44] <tsimonq2> seed = only in LP under ~lubuntu-dev
[04:44] <tsimonq2> Metapackage should be updated in GiTea then uploaded as normal 
[04:45] <arraybolt3[m]> OK, that's what I thought. (brain isn't working super-good right now, thanks for your help!)
[04:45] <arraybolt3[m]> One last thing - we didn't upload our last changes. Should I upload, update, and upload again, or just update and upload?
[04:45] <arraybolt3[m]> (I'm pretty sure that just updating and uploading is fine, but since this is new, I'd like to double-check these things.)
[04:51] <arraybolt3[m]> Actually, if I just add the new changes to the version we didn't upload yet, that will let us upload everything in one go.
 "OK, that's what I thought. (..." <- Ditto - been a long weekend and the week is just now starting!
 "One last thing - we didn't..." <- One upload is likely best, two would be redundant, no?
[04:56] <tsimonq2> Builder + publisher resources etc. (I mean, it's not like the first one will migrate before the second one is uploaded)
[04:57] <arraybolt3[m]> True. But an upload should only bump a package one version, right? That's where I was getting hung up - it didn't occur to me (until the last message) that I could just add more changes to the not-yet-uploaded version. But I can, which makes everything work right.
[05:28] <tsimonq2> Version numbers are cheap ;)
[05:30] <tsimonq2> (That took me time to learn; if you upload a version and it FTBFS, which will eventually happen to you, there's no way to remove a package from proposed and re-upload a version that has the same version)
 "[matrix] <kc2bez> Also, sorry..." <- Oh that sounds fun, /me looks
[15:50] <arraybolt3[m]> Dan Simmons, Simon Quigley: Asking for peer review on the latest changes to the meta, whenever you guys have time. I could just upload this and probably would if it was only qtxdg-tools that changed, but that update script also changed a debootstrap version number it looks like, so I'm a bit worried. Here's the diff (this includes all of the changes from last time, as well as the changes I made just now).
[15:50] <arraybolt3[m]> https://git.lubuntu.me/Lubuntu/lubuntu-meta/compare/ubuntu/22.10.3...ubuntu/lunar
[16:26] <Eickmeyer[m]> How's the updater looking these days?
 "How's the updater looking..." <- Better, the bug itself is fixed, we're still working on the workaround script. I intended on doing that today.
[16:48] <arraybolt3[m]> It will need a change made to the updater itself to make this stuff work, though. I'd say we're about halfway or more done.
[16:53] <Eickmeyer[m]> arraybolt3[m]: OK, keep me posted so I can unblock the sddm fix.
[16:53] <Eickmeyer[m]> Just bear in mind, though, that you're no longer racing sddm but unknown fixes that could cause the same problem.
[16:54] <arraybolt3[m]> Yes. I am well aware. There's just lots of other stuff that needs juggled, and I'm trying to help keep anything from falling through the cracks.
[16:55] <arraybolt3[m]> My main focus is going to be the fix for the updater today, hopefully we'll have something we can upload by tonight.
[16:55] <arraybolt3[m]> (And then we'll have to explain to the SRU team why allowing a patch that forcibly stops the update in some situations is a good idea, which may be... interesting :P)
[16:59] <Eickmeyer[m]> The core of the uphill battle is explaining why you're not simply using update-manager, which already provides the functionality. I mean, I get it, but there's a lot of nearsightedness going on, which comes down to a lack of maintenance of Qt frontends for certain tools, which comes down to another core problem that nobody is really talking about.
[17:04] <Eickmeyer[m]> I guess what I'm saying is, you don't have to explain why the tool exists, but you'll have to explain why a new feature needs to exist since it's causing a major usability issue. *But* they are coming at it from the perspective of "why does this even exist if this already does the job?"
[17:04] <Eickmeyer[m]> It's hard to remove bias.
[17:07] <arraybolt3[m]> It should be easy enough to explain. The new feature is needed because this tool is what's in use currently, and there's no way to swap out the tool and fix the bug at this point. The bug requires something to restart the updater in order to fix it, and the only updater that should accept something that hacky should be lubuntu-update-notifier. We fully intend to rewrite lubuntu-update-notifier to use update-manager, and there's
[17:07] <arraybolt3[m]> currently no Qt frontend for it that's good enough for Lubuntu so it will require us to rewrite it from scratch.
[17:07] <arraybolt3[m]> Replacing lubuntu-update-notifier with something else won't work here (and it would be too complex for an SRU anyway).
[17:08] <Eickmeyer[m]> I like that a lot. Not that my blessing is anything here, but that would convince the hell out of me. :)
[17:08] <arraybolt3[m]> Sounds good. /me buries my head back into the Debian Policy Manual to figure out what on earth I'm doing with a postinst script
[17:09] <Eickmeyer[m]> Hehe, think of a postinst script just like any other sh script with a few quirks.
[17:10] <arraybolt3[m]> That's what it looks like. I like some of the stuff like idempotency, that seems like a very good requirement for them to make.
[17:11] <arraybolt3[m]> (Obviously you know what it looks like, you've been doing this for way longer :P)
[17:11] <arraybolt3[m]> Thank you!
[17:11] <Eickmeyer[m]> No prob. Glad I can poke my head in and help.
[18:24] <arraybolt3[m]> Hey, I got autopkgtest to pass!
[18:25]  * arraybolt3[m] sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/d8c53972e4ac6e3f0867b976d9c8c599ac20a0ba
[18:26] <arraybolt3[m]> It doesn't like that I'm using killall, which I guess is reasonable. I may want to instead parse ps, extract the exact processes to kill, and kill those.
[18:26] <arraybolt3[m]> (I'm not worried about lubuntu-upgrader having a duplicate, but I can see that it's within the realm of possibility that something called "aptd" other than the "aptd" I'm targeting might exist.)
[18:27] <arraybolt3[m]> (Maybe I'll leave killall for lubuntu-upgrader for the sake of ease and simplicity, and use ps parsing to attack aptd.)
[18:34] <arraybolt3[m]> `killall -e "python3 /usr/sbin/aptd"` Nevermind, if *that* aptd isn't right where it should be, then something is dreadfully wrong. So that's safe to "killall" after all.
[18:46] <arraybolt3[m]> Hmm. So, it turns out killall matches process name, not full command line. Crud.
[18:47] <arraybolt3[m]> So I could probably nuke all python3 processes on the system, but not "/usr/bin/python3 /usr/sbin/aptd".
[18:47] <arraybolt3[m]> (And I get the distinct feeling that "killall /usr/bin/python3" won't get through SRU review...)
[18:48] <arraybolt3[m]> (warning, don't ever run the above command, for those who read the log)
[18:55] <arraybolt3[m]>  * (warning, don't EVER run the above command, for those who read the log, it may end up causing you to lose unsaved work or make your system otherwise behave wrong)
[20:03] <arraybolt3[m]> pkill looks like it might work.
[20:05] <arraybolt3[m]> pgrep looks handy too, that might reduce the complexity of some of the grep mess.
[21:28] <arraybolt3> The new lubuntu-meta successfully migrated to -release, shall I send the email asking for qtxdg-tools to be added to the Lubuntu packageset?
[21:31] <tsimonq2> +1
[21:39] <arraybolt3> Hmm, so I botched the email address. Sweet.
[21:39] <arraybolt3> Is it devel-permissions@ubuntu.com or devel-permissions@lists.ubuntu.com?
[21:40] <tsimonq2> It's the latter
[21:40] <Eickmeyer[m]> 🪜
[21:41] <arraybolt3[m]> Alright, email sent successfully this time.
[21:41] <arraybolt3[m]> (cc'd it to the Lubuntu council and to Simon.)