[11:26] <jess44> is it easier to crack a password hash if youve got a salt?
[11:28] <jpds> !cracking | jess44
[11:28] <jpds> Ah, no ubottu here.
[11:28] <jess44> cool
[11:28] <jess44> ty
[11:29] <jess44> !cracking
[11:29] <jess44> ??
[11:29] <jess44> what do u mean?
[13:39] <jpds> 1


[09:05] <Riddell> bonjour
[09:41] <vila> Riddell: hello !
[09:57] <maxb> vila: Hello. Now that fixit.sh is merged, shall I translate my existing commands from the bugreport to use it?
[09:58] <vila> maxb: for extra clarity, it would be nice, but you don't have to
[09:58] <vila> maxb: did you have confirmation of the deployment ?
[09:58] <vila> err, off the lp side of things
[09:58] <vila> s/off/of/
[09:58] <maxb> Still waiting on that
[09:58] <vila> ok
[09:59] <maxb> it will be easy enough to translate the commands - I will just rewrite my version of the shell functions to ones which echo code in the new format
[09:59] <vila> maxb: I'll wait for your ping then
[09:59] <vila> :)
[10:00] <vila> maxb: oh, by the way, I did a launchpad-login on jubany and this seems to work
[10:00] <vila> maxb: just one more thing to keep an eye open for for a few days (in case this triggers something (not that I can think of any though))
[10:01] <vila> s/any/&thing/
[10:49] <jelmer> hah, hello for real
[11:44] <Riddell> jamesh: did you see my request about https://code.launchpad.net/~jr/bzr/bzr-gpgme/+merge/64859 ?
[15:25] <poolie> hi all
[15:25] <poolie> thanks for that riddell
[15:28] <Riddell> for the gpg stuff?  you're welcome :)
[15:28] <vila> hey poolie
[15:29] <poolie> hi vila
[15:32] <maxb> Riddell: One thing which occurred to me looking at your examples.... OK, 1 commit not valid..... which commit? :-)
[15:33] <vila> the invalid one ;-P
[15:34] <Riddell> maxb: you use -v to show you the invalid author and bzr log --signatures to find the commit
[15:35] <Riddell> I did think of having  bzr verify -vv  or something for very verbose which showed each commit but then why not just use bzr log
[15:37] <vila> Riddell: convenience
[15:37] <vila> why use 3 commands if one is enough ?
[15:39] <poolie> in the log perhaps it would be good to show the key id
[15:39] <poolie> vila, i was wondering if you could share your todo list or plan for babune
[15:39] <poolie> or summarize it, if the current one is too cryptic or detailed
[15:42] <vila> http://paste.ubuntu.com/630417/
[15:44] <poolie> thanks
[15:45] <poolie> that looks good
[15:45] <poolie> i think it would be good to get it off your own personal hardware, for a couple of reasons
[15:45] <vila> yes ! bug #688101 is almost dead ;)
[15:45] <poolie> hooray
[15:45] <poolie> one being so it's not down if you're away
[15:46] <vila> and it may be the last case where we have multiple conflicts for the same file...
[15:46] <poolie> also so we can run more builders
[15:46] <poolie> and, also, so other people can co-admin it
[15:46] <poolie> i'm setting up usertest again and it would be nice if that was actually driven by jenkins not cron
[15:46] <poolie> (perhaps)
[15:47] <poolie> oh, also i was remembering that thing at our recent sprint of "i have to wait until i get home to do this"
[15:47] <vila> sure, as long we keep the ability to admin it
[15:48] <vila> ha, that would be mostly addressed if the sources were public
[15:49] <Riddell> what is baboun?
[15:50] <poolie> i think probably our own machine, but on a server somewhere else
[15:50] <vila> Riddell: http://babune.ladeuil.net:24842/
[15:50] <poolie> Riddell: it re-tests bzr on other operating systems than that run by pqm
[16:00] <maxb> abentley: Hi, would you be able to offer some comments on bug 796748 when you have a moment?
[16:01] <abentley> maxb: what kind of comment are you looking for?
[16:02] <maxb> To start with, a quick sanity check - and maybe an explanation why treetransform is canonicalizing symlinked paths at all
[16:04] <abentley> maxb: paths are canonicalized so that you cannot get two trans_ids for the same path.
[16:05] <maxb> It makes sense to me to canonicalize /./, /../, // etc. - but I'm less convinced about expanding symlinks to their underlying path
[16:06] <abentley> maxb: symlinks themselves should not be transformed to the path they point at.  Files under those symlinks should.
[16:06] <maxb> Why should they?
[16:06] <abentley> maxb: otherwise, you wind up with two references to the same file, and that will break TT.
[16:07] <maxb> In that bug, I've found a situation where the current canonicalization gives the same trans_id to two paths which are actually distinct, and that breaks it too
[16:07] <abentley> maxb: Another way to fix it would be to forbid traversal through symlinks, and perhaps that's what I should have done.
[16:08] <maxb> That sounds like a practical option for fixing this
[16:09] <abentley> maxb: I don't think you've found a situation where the same trans_id has been given to two different paths.
[16:09] <maxb> No, I really have. I hacked in some print statements and observed it
[16:09] <abentley> maxb: A trans-id can only refer to one path in the source tree.
[16:10] <maxb> Well, it's *supposed* to, yes. But that got violated
[16:10] <abentley> maxb: It cannot, unless you change the source tree while the TT is active.
[16:10] <abentley> maxb: Which is against the rules.
[16:12] <abentley> maxb: Maybe "paths" is incorrect.  I don't think you've found a situation where the same trans_id has been given to two different files.
[16:13] <maxb> OK, that's partially true. There was one trans_id, assigned to two paths, which both led to the same file in the source tree
[16:13] <abentley> maxb: Right.
[16:13] <maxb> But, the intent was to drive the TT to remove the symlink involved, and put two distinct files at the two paths concerned
[16:14] <abentley> maxb: How are you driving it?
[16:14] <maxb> via "bzr import-dsc"
[16:15] <abentley> maxb: without looking at the code, it sounds like a bug in bzr import-dsc.
[16:16] <maxb> I'm not really convinced
[16:17] <maxb> If I have this tree:
[16:17] <maxb> lenny/
[16:17] <abentley> maxb: I'm not either.  But since I don't know what the code is trying to do, I don't know what the bug is.
[16:17] <maxb> lenny/some-file
[16:17] <maxb> squeeze -> lenny
[16:18] <maxb> Can you describe a valid way to drive TT to remove the squeeze symlink, create a squeeze directory, and a file squeeze/some-file ?
[16:18] <abentley> maxb: sure.  This will take a sec.
[16:19] <abentley> maxb: Now, what do you want to do about the original some-file?
[16:19] <maxb> for the sake of this example, let's say we want to update its text content, only
[16:20] <abentley> maxb: so you want to create a new some-file at squeeze/some-file, and update the contents of lenny/some-file?
[16:20] <maxb> yes
[16:24] <abentley> maxb: http://pastebin.ubuntu.com/630431/
[16:27] <maxb> abentley: OK.... is it considered technically invalid to attempt to create squeeze/some-file in a way involving a call to tt.trans_id_tree_path('squeeze/some-file'), before the squeeze directory is real on disk?
[16:27] <maxb> If so, import-dsc is running afoul of that
[16:27] <abentley> maxb: no.  You can do tree transform operations in any order.  That's part of the design.
[16:28] <maxb> Ah.
[16:28] <abentley> maxb: However, You cannot create squeeze/some-file at all using trans_id_tree_path.
[16:28] <maxb> Right... *that* is the violation going on here, then
[16:28] <abentley> maxb: Because in the tree, squeeze/some-file was lenny/some-file
[16:29] <abentley> maxb: Since you're replacing squeeze with a directory, squeeze/some-file must be a new file, or you must move lenny/some-file.
[16:30] <maxb> I'm unclear what you mean by "must be a new file"
[16:31] <maxb> Or why moving lenny/some-file should matter
[16:32] <abentley> maxb: by "must be a new file" I mean it must be a file with a new trans-id.
[16:33] <maxb> Well, quite. I want it to be. And it would be if trans_id_tree_path didn't follow symlinks
[16:35] <abentley> maxb: No, it would be an existing id in that case, too.  You'd just have two existing ids for trans_id_tree_path, one for squeeze/some-file and one for lenny/some-file.
[16:35] <maxb> hmm
[16:35] <abentley> maxb: I think you may not realize that trans_id_tree_path refers to paths in the source tree.
[16:36] <maxb> OK, so it sounds like import-dsc is being lazy in how it constructs the TT
[16:36] <abentley> maxb: and therefore nothing you do in the transform should change its output.
[16:37] <abentley> maxb: that seems possible.
[16:37] <maxb> Alright, this conversation has clarified that the code in import-dsc was written cutting some corners in how to properly drive TT, and needs an overhaul - thanks.
[16:39] <abentley> maxb: np.
[16:39] <maxb> (the same code is present in bzrtools, ftr)
[16:45] <abentley> maxb: Yes, I think I didn't anticipate the problems with replacing a symlink with a file.  Aside from that, using the tree paths seems fine.
[16:53] <abentley> maxb: have you filed a bug on import-dsc or bzrtools?
[16:54] <maxb> No, only the one on bzr, at present
[16:58] <abentley> maxb: what's the project for import-dsc?
[16:58] <maxb> builddeb
[16:59] <abentley> maxb: I've filed bug #800270
[20:01] <ccxCZ> is there bzr webinterface that can generate static files as on-push hook, that could be then simply served via webserver?
[20:02] <jelmer> ccxCZ, there was a bzr-html plugin that did that, though very rudimentary
[20:06] <ccxCZ> hmm, nicehtml is 404 and htmllog is just commit message log
[20:12] <jelmer> ccxCZ, what sort of information are you looking for?
[20:13] <ccxCZ> well, mostly what loggerhead does, altough it doesn't have to be so fancy-ajaxy
[20:16] <jelmer> I don't think there is anything like that (or even close to that).
[20:17] <jelmer> More than just dumping the current contents to disk would also require an insane amount of disk space for any project with a nontrivial amount of history or a non-trivial tree.
[20:17] <jelmer> loggerhead IIRC has one page per revision of each file (including markup), and then some
[20:25] <ccxCZ> hmm, when I do bzr log -n 0 -p on my projects it doesn't go over few megs
[20:25] <ccxCZ> I think it should be reasonably doable for smaller projects
[20:25] <jelmer> ccxCZ: That shows the diffs though, not the full file contents (like loggerhead)
[20:29] <ccxCZ> yes. I expect it would be significantly larger than that, but it gives some estimate
[23:53] <maxb> Hurrah, LP fix is deployed. vila / james_w / spiv : If you happen to be around, requeue_package.py --all-of-type bzr please?


 "Simon Quigley (Developer) Dan..." <- Does it install in an LXD container? :P
[00:35] <tsimonq2> Upgrade, rather
 "OK, now it's done." <- Sweet thanks :)
 "(I just removed the "-Wl,--as-..." <- Cool
[00:59] <tsimonq2> arraybolt3 @arraybolt3:matrix.org: alright I'm around, are you?
[01:09] <arraybolt3[m]> I'm here.
[01:09] <arraybolt3[m]> Simon Quigley (Developer): Ping
[01:10] <arraybolt3[m]> Simon Quigley (Developer): I'll install LXD in my VM now.
[01:10] <arraybolt3[m]> (Sorry, was off cleaning up a mess, hope 10 minutes wasn't too late.)
[01:17] <tsimonq2> All good
[01:18] <tsimonq2> arraybolt3 @arraybolt3:matrix.org: I'll review Featherpad in the next few hours
[01:18] <tsimonq2> In the meantime if you feel up to it we could make some backports progress :)
[01:36] <arraybolt3[m]> Sounds good. I have to go afk for a bit, but I'll be right back.
[01:48] <arraybolt3[m]> Simon Quigley (Developer): OK, I'm back. Ready for backporting.
[01:53] <arraybolt3[m]> Si
[01:53] <arraybolt3[m]> Si
[01:53] <arraybolt3[m]> Come on, twice?
[01:54] <arraybolt3[m]> Simon Quigley (Developer): OK, I have a question. I see that some of the packages earlier in the build are used as build dependencies later in the build. How do I get those into the sbuild chroot?
[01:57] <arraybolt3[m]> Is there some way for me to make a locally hosted PPA or something? That way I don't have to wait for Launchpad's painfully slow build servers.
[01:58] <arraybolt3[m]> Ah, I see you pointed me to the docs already. Figuring stuff out!
 "Simon Quigley (Developer): OK, I..." <- Using the extra deps flag or that local PPA
[02:06] <arraybolt3[m]> Yeah, just got the local PPA setup rigged.
 "Ah, I see you pointed me to..." <- Yeah the Ubuntu ones have it :)
[02:06] <tsimonq2> arraybolt3[m]: Sweeeet
[02:06] <arraybolt3[m]> Wow am I glad that I did FeatherPad first, this is going to be a breeze (I hope) now. Thank you so much for teaching me all of this!
[02:06] <tsimonq2> arraybolt3[m]: Of course :) we got you
[02:07] <tsimonq2> And thank you for your contributions+
[02:07] <tsimonq2> s/+/!/
[02:07] <tsimonq2> You're catching on really quick man, I gotta give you that
[02:07] <arraybolt3[m]> Man, I feel like I'm stumbling through like a dizzy beaver. Glad you guys are happy!
[02:08] <kc2bez[m]> I think you are getting the hang of things pretty quick too.
[02:09] <tsimonq2> I've seen much much worse my friend :)
[02:09] <arraybolt3[m]> OK, maybe I'm missing something, but how bad is it if the newest release in lxqt-tools-packaging is ubuntu/hiruste?
[02:09] <tsimonq2> arraybolt3[m]: Not too bad, we synced it with Debian
[02:10] <arraybolt3[m]> OK. So rather than going backwards from Kinetic to Jammy, I just go forwards?
[02:10] <tsimonq2> Yeah. Do you know how to sync with the archive?
[02:10] <arraybolt3[m]> I'm guessing not, since I don't know what you just said.
[02:11] <arraybolt3[m]> I know how to git clone, and I know how to edit the changelog, which I think is what uscan reads.
[02:11] <tsimonq2> pull-lp-source PKGNAME version is your friend. Pull the same package version from the archive using that, that is cloned with the packaging Git repo
[02:11] <tsimonq2> Then also download the latest version with pull-lp-source
[02:11] <tsimonq2> Then use debdiff between the two
[02:11] <tsimonq2> And apply that debdiff to the packaging
[02:11] <tsimonq2> You follow?
[02:11] <arraybolt3[m]> I'm just going to try to absorb that, then make sure I know what you mean.
[02:12] <arraybolt3[m]> So, do I add a new changelog entry for LXQt 1.1.0, since the version in GitHub is 0.8.0?
[02:12] <arraybolt3[m]> Then I uscan, then use pull-lp-source, then debdiff, then apply debdiff?
[02:12] <tsimonq2> I would just sync with the archive first :)
[02:12] <tsimonq2> arraybolt3[m]: Same process wrong stage
[02:13] <tsimonq2> You're pulling two packages from the archive to debdiff
[02:13] <arraybolt3[m]> OK, tell me where I stopped tracking. LXQt is at 1.1.0, that's what we want backported. The repo is at 0.8.0. So if I pull the same package version from both launchpad and uscan, I'm going to get LXQt 0.8.0 for Jammy, which is the opposite of what we want.
[02:13] <arraybolt3[m]> Am I pulling the old one from GitHub and the new one from LaunchPad?
[02:14] <tsimonq2> You're pulling everything from Launchpad. Use the packaging repo to see what version is in there, pull it specifically, pull the newest one, and debdiff. If it makes a difference you want a diff that you can apply to the packaging repo
[02:15] <arraybolt3[m]> Ah, I get it. Thank you!
[02:16] <tsimonq2> Also hold on
[02:16] <arraybolt3[m]> To what? :p
[02:17] <tsimonq2> arraybolt3 @arraybolt3:matrix.org: before you get too far... we're farther down the build steps
[02:17] <tsimonq2> Check that PPA - we're up to... III? I can relink you if needed
[02:17] <arraybolt3[m]> Oh OK. So don't start with lxqt-build-tools.
[02:17] <tsimonq2> arraybolt3[m]: Deez... nevermind XD
[02:18] <arraybolt3[m]> OK, the PPA is to stage II.
[02:18] <arraybolt3[m]> So I need to start with III.
[02:18] <tsimonq2> arraybolt3[m]: https://github.com/lxqt/lxqt/wiki/Building-from-source#Compiling
[02:18] <tsimonq2> https://launchpad.net/~lubuntu-dev/+archive/ubuntu/backports-staging
[02:18] <tsimonq2> Yeah
[02:19] <arraybolt3[m]> Nice, I think I got it. Also, one last thing. Once I start actually using a for-real PPA, how to I link one PPA to another for pulling build deps?
[02:19] <arraybolt3[m]> s/to/do
[02:20] <arraybolt3[m]> (This is probably way too early for me to need to ask that, so it can wait if you have other things to do.)
[02:25] <arraybolt3[m]> Simon Quigley (Developer): I noticed you asked that I add a new changelog entry using the same scheme as you did in the past. Can you link me to an example? I don't see anything in particular about the changelog entry directly beneath my new one that's all that different from a usual changelog entry.
 "Nice, I think I got it. Also..." <- You create your own on Launchpad :)
[02:26] <tsimonq2> arraybolt3[m]: dch (with no args) - or check the changelog entry for the packages in the PPA
[02:27] <arraybolt3[m]> 🤦♂Why didn't I think to check the PPA packages...
[02:27] <tsimonq2> ```
[02:27] <tsimonq2> libqtxdg (3.9.1-0ubuntu1~ppa1) jammy; urgency=medium * Backport to Jammy. -- Simon Quigley <email address hidden> Sun, 12 Jun 2022 12:39:13 -0400
[02:27] <tsimonq2> ```
[02:27] <tsimonq2> arraybolt3[m]: All good
[02:27] <arraybolt3[m]> Yep, found it.
[02:28] <tsimonq2> All I ask for is consistency :) (even if that means consistently going against my changelog norm ;))
[02:28] <tsimonq2> (Just be technically sound with your argument and I usually never have a problem)
[02:29] <arraybolt3[m]> Nah, why go against the old system? I mean, "Backport to Jammy", why else put anything there if that's all I'm doing?
[02:29] <tsimonq2> Precisely :)
[02:29] <arraybolt3[m]> (Unless Google Translate turns it into "backlash the peanut butter and jam")
[02:29] <tsimonq2> Bahahahahaha
[02:31]  * tsimonq2 was a bad packager and didn't do a full Lintian check on this stack...
[02:31] <tsimonq2> So you may find a few gems.
[02:31] <arraybolt3[m]> Simon Quigley (Developer): Hey, do I need to make a Jammy development VM for this, or is making a Jammy chroot in sbuild enough?
[02:31] <tsimonq2> arraybolt3[m]: I'd say the latter will suffice
[02:34] <tsimonq2> Well... unless you want to check that the entire stack upgrades and works. Later on though
[02:35] <tsimonq2> Starting with liblxqt?
[02:37] <arraybolt3[m]> Simon Quigley (Developer): I figure I can do that last part after the PPA is uploaded.
[02:37] <arraybolt3[m]> Simon Quigley (Developer): Yep, starting with liblxqt.
[02:47] <arraybolt3[m]> > * <@tsimonq2:linuxdelta.com> was a bad packager and didn't do a full Lintian check on this stack...
[02:47] <arraybolt3[m]> Hey, it's your policy. As long as my system works reliably, and doesn't crash, lock up, or catch fire, I'm happy. (Though I will take a good look at Lintian stuff.)
[02:49] <tsimonq2> Reviewing your featherpad diff now, comments incoming
[02:50] <tsimonq2> My sponsors would make me be more verbose here, for future reference...
[02:50] <tsimonq2> +  * Bumped standards-version.
[02:50] <tsimonq2> They would say:
[02:50] <tsimonq2> a) Did you have to make any changes? If not, explicitly say so.
[02:50] <tsimonq2> b) The specific version you bumped to should be right in the entry
[02:51] <tsimonq2> This is your first major upload like this so I'll let it slide
[02:51] <arraybolt3[m]> Why? I can fix it.
[02:51] <arraybolt3[m]> (As in, why let it slide.)
[02:51] <tsimonq2> arraybolt3[m]: Go for it
[02:51] <tsimonq2> +  * Run wrap-and-sort.
[02:51] <tsimonq2> +  * Overrode missing man page warnings.
[02:51] <tsimonq2> Watch your tenses :)
[02:51] <arraybolt3[m]> Ah, "run" in commit, "ran" in changelog. Got those confused.
[02:52] <tsimonq2> +featherpad: no-manual-page *
[02:52] <tsimonq2> I would not do a wildcard here, I would explicitly specify it per-binary
[02:52] <arraybolt3[m]> Oh, good point.
[02:53] <tsimonq2> https://github.com/tsujan/FeatherPad/releases/download/V1.3.0/FeatherPad-1.3.0.tar.xz.asc
[02:53] <tsimonq2> Please check the GPG key via the watch file/uscan
[02:53] <tsimonq2> Besides that... I think you're good to go
[02:53] <tsimonq2> All normal LXQt packages already do this so feel free to use those as an example
[02:54] <arraybolt3[m]> OK, easy enough.
[02:55] <arraybolt3[m]> I can figure this out myself, but it would be mighty convenient if you could link wherever tsujan stashes his public key.
[02:55] <tsimonq2> Hmm... I'd first check if it's the same upstream signing key as LXQt
[02:55] <tsimonq2> May just be able to copy it over from another package
[02:55]  * tsimonq2 is unsure on that one
[02:57] <tsimonq2> guiverc, Leo K: Can either of you reproduce this? (Fresh PopOS install then try to install Lubuntu alongside it, doesn't give the option... same as other distros?) https://twitter.com/XanisCorp/status/1539368917461778440
[03:01] <arraybolt3[m]> Simon Quigley (Developer): Got this error trying to include the LXQt PPA in sbuild: https://pastebin.com/63EXAwEi
[03:01] <arraybolt3[m]> Do I just change it to http rather than https?
[03:02] <tsimonq2> affirmative
[03:02] <tsimonq2> Unfortunately Launchpad has not switched yet.
[03:02] <arraybolt3[m]> I need to start trying ideas rather than asking every time something throws a fit...
[03:03] <tsimonq2> It's not mandatory but you'll get your answers quicker that way ;)
 actually simon https IS enabled for PPAs.  that proxy they are using wherever in theit config is forbidding outgoing via HTTPS (so proxy doesnt support https)
[03:04] <tsimonq2> Since when?
[03:04] <tsimonq2> That's gotta be NEW new
 https://askubuntu.com/questions/1293702/ppa-launchpad-net-does-not-support-https/1391683#1391683
[03:04] <tsimonq2> wait wtf I guess so
 at least february but wit additional urls
[03:04] <arraybolt3[m]> Crud, now this is happening when it tries to pull the ppa packages: "503  Connection closed, check DlMaxRetries [IP: <IP_ADDRESS> 3142]"
 fyi you have been out of the loop so long yoh miss things.  ;)
[03:05] <arraybolt3[m]> https://pastebin.com/SJhLELGJ
 arraybolt: what is 3142 on <IP_ADDRESS>?  apt-cacher?
[03:06] <arraybolt3[m]> teward001: How do I check?
 because you might need to remove thay from the equation for things to pull direct from apt.
 1 moment gotta switch to computer
[03:06] <arraybolt3[m]> Pulling packages directly from the repo works, but not from the ppa in sbuild.
 again
[03:08] <tsimonq2> It's 2022... CTFO :P
[03:08] <tsimonq2> So where's the main archive at with this?
 your sbuild env is using some proxy
 simon: different logistical headache
[03:08] <tsimonq2> Yeah, just restart the systemd service
 its called TLS Certificates
 :P
[03:08] <arraybolt3[m]> Yeah, I've got apt-cacher on, but MAN it makes things so much better. I'm not sure if taking apt-cacher out of the loop is an option.
[03:08] <tsimonq2> Every once in a while it freezes
[03:08] <arraybolt3[m]> Simon Quigley (Developer): I'll try the restart.
[03:08] <tsimonq2> arraybolt3[m]: Agreed
[03:08] <tsimonq2> Just status the service, force kill the process it's running if it doesn't restart, then manually start it
[03:08] <arraybolt3[m]> Especially not on my ~4Mbps connection.
[03:08] <tsimonq2> PITA but it works
[03:08] <arraybolt3[m]> Will do.
 i mean i have insane net speed so its irrelevant for me
 but i also do a ton of sid builds where stuff changes super fast
 sometjmes too fast for cacher
 but to each their own :P
[03:09] <arraybolt3[m]> Yay, the restart fixed it!
[03:09] <tsimonq2> I mean, it's never been too fast for cacher for me, not building often enough :P
[03:09] <arraybolt3[m]> lubot: Must be nice.
[03:10] <tsimonq2> I mean, FWIW I have gigabit down and it still makes it exponentially faster...
[03:10] <arraybolt3[m]> But this is more than livable, and besides, apt-cacher keeps the load on Ubuntu servers lighter. Why waste Canonical's money if I don't have to?
 *shrugs* to each their own
 and i think you meant teward not lubot ;)
[03:12] <arraybolt3[m]> teward001: Oh, that's Matrix's reply feature at work. Thus why you should use Matrix. Hit me with the dead fish.
 (unrelated my normal computer is busy being disk imaged because I'm possibly going to install 22.04 tomorrow and need a restorable disk image heh for my 20.04 system.)
 *forgoes the fish, and replaces it with a cruise missile*
[03:12]  * arraybolt3[m] secretly places degausser underneath teward's backup drive
 does that actually work on SSDs?
 :P
[03:13] <arraybolt3[m]> Works on firmware, at least, from what I've read.
[03:13] <arraybolt3[m]> So I'd imagine it would work.
 *shrugs* well if you want to die then use the degausser.  by the time you're 'done' degaussing the drive, you'd be shot as an intruder in my home :P
[03:13] <arraybolt3[m]> (OK, I wouldn't actually do that, but you wouldn't hit me with a cruise missile either.)
 (truth)
[03:14]  * arraybolt3[m] immediately turns on VPN to mask IP from teward
[03:15]  * tsimonq2 brings the SWAT team to put degausser on all of teward's drives
 lol
 SWATting someone is illegal now
 actually a federal crime if you did that
[03:15]  * arraybolt3[m] leaves planet earth before this devolves into nuclear war
 WAR hue.
 aaaaaaaaanyways
 oh lookit, new 512GB SSD from work they let me keep
 also simon
 why is it everyone is trying to breach your account on the WP 😐
[03:16] <tsimonq2> what now
[03:16] <tsimonq2> idk just fix it lol
[03:16] <tsimonq2> idc
 it's already been fixed lol
[03:17] <tsimonq2> good lol
 they're trying to bruteforce
 they haven't succeeded.
 :P
 thank you modern Ubuntu, PHP, and all the addons I have installed :P
[03:18] <arraybolt3[m]> Good luck bruteforcing my passwords, I use Chrome's password manager. 💪
 *points at his password manager* i know the feeling :P
[03:18] <arraybolt3[m]> (Plus the strong passwords I remember are, well, strong, and the one LUKS-ing my GPG key drive is at somewhere around 90 bits of entropy)
[03:19] <arraybolt3[m]> (Caluclated in my head, didn't upload it anywhere)
 *whistles nonchalantly as he pokes away at the git server*
[03:19] <arraybolt3[m]> teward001: That reminds me, how close are we to using Gitea rather than Phabricator?
 well if we want to start pure Git before I get CI with drone or other integrations set up, soon.
 if we want CI integration of some sort, then it'll take a bit for me to get Drone.IO set up
 setting up automirror to GH I think is easier though, so we could use GH Actions/CI if we wanted to, but meh
[03:20] <arraybolt3[m]> Humorous snippet of what Lintian's feeding me: "liblxqt-l10n: extended-description-is-probably-too-short"
[03:20] <arraybolt3[m]> Wow. Really?
 arraybolt3: what's the status level of that though
[03:20] <arraybolt3[m]> I
 Informational lintians can be ignored
 for the most part
 in terms of package policy.
 it's Warnings (W) and Errors (E) that you need to not ignore unless you KNOW it's a false positive
 (case in point the known Lintian bug on Debian's builders where it erroneously flags debug symbols as "unable to determine compiler binary" which they know about)
 (and which I lintian override because it's a known FP, and I explain it in the overrides file as "This is a debug symbol - it won't have the proper elf header.  See biug ...")
[03:22] <tsimonq2> Now that one, I'd wildcard
 (which is apparently OK and something Bage even told me I can do if I have an annoyingly evil lintian tester.)
[03:22] <arraybolt3[m]> Simon Quigley (Developer): Quick question, just noticed this Lintian warning and want to know if my idea is correct.
[03:22] <arraybolt3[m]> W: liblxqt source: upstream-metadata-field-unknown Repository-Browser
 tsimonq2: Oh, I definitely do that for elf-error now.
[03:23] <tsimonq2> well what's the hint mean?
[03:23] <tsimonq2> I dunno off the top of my head
 https://lintian.debian.org/tags/upstream-metadata-field-unknown
 > The named field in the upstream metadata provided with this package is not part of the DEP-12 specification.
 > Please use only recognized field names.
[03:23] <arraybolt3[m]> There's two lines in the debian/upstream/metadata file, Repository and Repository-Browser, both point to "https://github.com/lxqt/liblxqt"
[03:23] <arraybolt3[m]> Can I just remove the "Repository-Browser" field?
 i would, and keep it as a packaging delta
 my opinion :P
[03:24] <arraybolt3[m]> I don't know what a packaging delta is.
 it LOOKS though like this exists in a ton of locations
 in Debian, (d/upstream/metadata) this might be something they let pass, but IDK
 so this is known DEP12 metadata - https://wiki.debian.org/UpstreamMetadata
 not entirely sure if this is fully functional or drafted out, last update to that page was October
 bluh I need the Lubuntu branding >.<
 *goes to steal it from Launchpad.net)
 literally just a difference in the packaging we will have between Upstream and what is actually in the repos (re @lubuntu_bot: (irc) <arraybolt3[m]> I don't know what a packaging delta is.)
 you can see any number of such deltas in packages that don't autosync in ubuntu anymore because of introduced changes (deltas) to the packging
 either from individual patches or otherwise)
[03:45] <arraybolt3[m]> Simon Quigley (Developer): OK, one slight problem. That GPG verification file you gave me is for a tar.xz file, but the file uscan downloads is for tar.gz
[03:45] <arraybolt3[m]> Simon Quigley (Developer): For Featherpad.
[03:46] <tsimonq2> Oh, I see
[03:46] <tsimonq2> https://github.com/tsujan/FeatherPad/releases/tag/V1.3.0
[03:46] <tsimonq2> Four URLs
[03:47] <arraybolt3[m]> So... the source code doesn't have a GPG checking file?
 yes it does
 uscan is probably pulling the wrong url
[03:48] <arraybolt3[m]> Oh, the source is in the xz (just found that out).
 it's pulling the source code tar.gz not the versioned tar.xz
[03:49] <arraybolt3[m]> Guess I can fix that in the watch file.
 which means the d/watch file isn't properly configured
 yes
[03:49] <tsimonq2> yes
[03:50] <tsimonq2> https://launchpad.net/ubuntu/+source/calamares/3.3.0~git20220620-0ubuntu1
[03:51] <arraybolt3[m]> Simon Quigley (Developer): I changed the ".gz" parts of the watch file to ".gz", and it's not working (exact error below), despite the fact that the .tar.gz and .tar.xz files have identical names, except for the extension.
 arraybolt: can you give me the d/watch file content itself?  You might need to change the URL syntax it's using to pull data
[03:52] <arraybolt3[m]> uscan warn: In debian/watch no matching hrefs for version 1.3.0 in watch line
[03:52] <arraybolt3[m]> teward001: Working on it.
[03:53] <arraybolt3[m]> https://termbin.com/xemm
[03:53] <arraybolt3[m]> Oh, I see why, and I bet I can fix it.
[03:57] <arraybolt3[m]> Shoot, in order to get uscan to automatically download this for me, it looks like I'll have to hardcode the V1.3.0 part, since it's part of the URL... any ideas? teward001, Simon Quigley (Developer)
 give me a few minutes to stab something
 *loads his VM while his laptop is out of commission*
 i'm going to attempt to emulate the uscan behavior locally, see if I can get the regex to work right
[04:00] <arraybolt3[m]> Crud, it's worse than I thought. Since GitHub displays the release in one page, but then puts the files at a different URL, and THAT url gives a 404 error if it doesn't have the filename hardcoded in, I can't get uscan to pull the xz file at all.
[04:01] <arraybolt3[m]> I'd need some way to put a regex in the URL and tell uscan to just go straight for the file and don't try to load the web page behind it.
[04:01] <arraybolt3[m]> I think I'm just going to sidestep uscan entirely and do it manually.
 you have zero patience don't you
[04:02] <arraybolt3[m]> Well I've been working on this for days and am tired of holding you guys up when you or Simon probably could have had this bashed out in an hour or two. I'd be happy to be patient if you'd prefer.
 i would because i'm doing some things right now here
[04:02] <arraybolt3[m]> 👍
[04:03] <tsimonq2> It's all good - we'll help you get this figured out :)
[04:04] <arraybolt3[m]> Also, how exactly would I go about creating a packaging delta? I know how to make a Quilt patch.
[04:05] <arraybolt3[m]> Or does "keep it as a packaging delta" mean "just change it, I don't care that it's not in upstream"?
 got it
 you can't make a quilt patch for anything under debian/*
 this is a change that when you merge with upstream you make sure you don't include upstream's changes without revising things yourself and reviewing merge conflicts
 1 moment
 https://termbin.com/b3pu
 arraybolt: uses the releases tag instead because the URL for the release format is under releases not tags
 i didn't test the asc but the uscan verbose shows this works
 detects the .tar.xz proper
 i don't think this uscan is configured to pull the asc though
[04:10] <arraybolt3[m]> I can check the ASC myself, thank you for the watch file!
 well i have the code though :P
[04:11] <arraybolt3[m]> uscan warn: In debian/watch no matching hrefs for version 1.3.0 in watch line
[04:11] <arraybolt3[m]> https://github.com/tsujan/featherpad/releases .*/V?(\d\S+).tar.xz
[04:11] <arraybolt3[m]> That's with the new file...
 oh i think i derped 1 moment
 wait a minute
 show me the *exact* content of the file as you used it
 because what i have works fine on 20.04 and 22.04 and my Unstable test machine
 (all VMs)
 but yours not working means something's screwy on *your* uscan
 here's how you can test your regex by the way
 https://regex101.com/r/gG9W5o/1
[04:13] <arraybolt3[m]> The problem I'm seeing is that the releases page you linked to has the links to the needed files, but the files themselves are at different URLs.
 i also pulled the URL(s) manually to test with
 here's my uscan debug output
 well one thing is
 i had to 'fudge' the info
 where's your source package branch
 the git?
 having the full packaging source tree here would help me test further
 because when i tell the system the proper version, etc. to test with it works fine
[04:15] <arraybolt3[m]> My output from uscan: https://pastebin.com/UD1n9z9e
 i want the source packaging branch
 not your output
[04:15] <arraybolt3[m]> I'll push the repo and send the link.
[04:15] <arraybolt3[m]> (Sorry, thought that would be helpful...)
[04:16] <arraybolt3[m]> Hey, quick question, how do I revert all uncommitted changes with Git? I keep making a "waste" commit and then hard resetting back, which doesn't seem like the right way.
 git reset —hard $COMMIT (or $HEAD~1 if you are only one commit ahead of your last push)
 see here's what i see in your code:
 s/code/output
[04:18] <arraybolt3[m]> I just pushed all my local changes, so you may want to refresh the page.
[04:18] <arraybolt3[m]> https://github.com/ArrayBolt3/featherpad-packaging
 i wonder...
[04:19] <tsimonq2> @teward001: An error occurred while sending mail. The mail server responded:  SendAsDenied<EMAIL_ADDRESS>not allowed to send as<EMAIL_ADDRESS>
 *does more tests*
[04:19] <tsimonq2> ugh Outlook settings?
 @tsimonq2 not fixable.  you need to use an external SMTP server for sending from an alias
 MS365 and Microsoft limitations
 many are angry at it
[04:20] <tsimonq2> @teward001: So as my email admin, where's the SMTP server I can use? :P
 it's why i use a separate SMTP server for @ubuntu.com messages and why Debain and Ubuntu both need to fix an app-password-like SMTP solution in
 simon: you still owe me for this year's email
 i'm also not debugging email at midnight :P
[04:21] <tsimonq2> uh no I don't? thought I paid you
[04:21] <tsimonq2> anyway
 so regarding featherpad
 i wonder if this is a uscan issue
[04:21] <tsimonq2> :P
 because.......................
 this works on 2.20.2ubuntu2 uscan
 *does more evil*
[04:22] <arraybolt3[m]> My uscan is 2.22.1ubuntu2
 i know
 that's 22.04 and i'm redoing the test
 (can only have one VM on at a time on this POS computer)
[04:22]  * arraybolt3[m] sudo apt update && sudo apt full-upgrade
 hence my saying " I wonder if..." :P
 standby while i get my 22.04 updated
[04:24] <arraybolt3[m]> OK. My VM is on Kinetic FWIW.
 i always test this initially on the LTSes
 one thing at a time
[04:24] <tsimonq2> When everything propagates: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013334
 since i can't spin a kinetic VM easy right now (ERR: No LXD)
 2.22.1ubuntu1 is what's in Kinetic
 erm, Jammy
 let me see the changelogs
[04:25] <arraybolt3[m]> Simon Quigley (Developer): Nice!
[04:26] <arraybolt3[m]> They're in my GitHub, I'll link.
 not your changelogs
[04:26] <arraybolt3[m]> If you mean the FeatherPad packaging changelogs.
 the uscan changelogs
[04:26] <arraybolt3[m]> Oh. Never mind...
 your devscripts is out of date by thew ay
[04:27] <arraybolt3[m]> (I just realized you're using an older uscan than me, not newer)
 kinetic is 2.22.2ubuntu1
 yes, that's why i'm doing individaul tests here to see ife this is a uscan regression
[04:28] <arraybolt3[m]> lubot: Oy, I'm so used to KDE's nice and timely "update me" notifications that I figured LXQt would do the same. Guess not, updating now.
 2.22.1ubuntu2 was a simple rebuild against kinetic
 but it's at 2.22.2ubuntu1 now which included some changes
 so run an update on your build env and install the latest devscripts first
[04:29] <arraybolt3[m]> Updating now.
 2.22.1ubuntu1 from Jammy works fine with the test
 wait a minute
 no that's right
[04:30] <arraybolt3[m]> Should I stop the update?
 *yawns*
 i'm tired and misreading, no don't stop the update
[04:30] <arraybolt3[m]> 👍
 if you use Kinetic as your build env/testing you should always update your packages before doing ANYTHING dev related
[04:31] <arraybolt3[m]> Makes sense, will do from now on.
 https://termbin.com/xwfe is the uscan verbose output in the Jammy version of uscan
[04:31] <tsimonq2> teward: Are you a DM yet? you are right?
 yes, DM.  not DD (re @lubuntu_bot: (irc) <tsimonq2> teward: Are you a DM yet? you are right?)
 one of the things i brought up internally with Council on your thread lately
 about how Debian is picky about contributors
[04:32] <tsimonq2> Okay, so when we update the LXQt stack, assuming they're cool with it I'll just give you DM access to those packages
 works for me
 i don't think anyone'll object as a comaintainer
[04:33] <tsimonq2> Speaking of internal threads, I'm flattered Dan still thinks I'm a MOTU. I wish I was still such a young buck. :P
 well dan's not DMB so :P
 he don't know access levels
 everyone knows my access though :P
[04:33] <tsimonq2> Right, I meant to file that bug for the sake of "hey let's help update" and less "hey let's completely take over"
[04:35]  * guiverc thinks MOTU is a far better title than Core-Dev... Any Sci-fi fan would agree I'm sure
[04:35] <tsimonq2> I BCCed the council on that bug btw in case you guys want to start an internal thread
 "Developer Membership Board Member" is above coredev heheheh
[04:35] <tsimonq2> guiverc: Technically I'm inherently a MOTU still :P
 heh
[04:35] <arraybolt3[m]> guiverc: LOL agreed.
[04:36]  * arraybolt3[m] hopes one day I can get even as high as Lubuntu member, and feels kinda weird being part of a group of people who are four or more levels above me
 well to be fair
 i didn't contribute to Lubuntu first ;)
[04:36]  * tsimonq2 strokes my beard - one day you will be...
 what simon said
 eventually you'll get here
[04:37] <tsimonq2> I mean keep this up and I give it less than a month before I advocate you out of sheer dedication :P
[04:37] <tsimonq2> and impulse
[04:37] <tsimonq2> but mostly dedication :P
 tbh give it a month and I'll just *give* you Lubuntu Member status, because your contributions don't go unnoticed by myself or Dan or others.
 i don't think the Council will object.
 *sips the mountain dew*
[04:37] <arraybolt3[m]> tsimonq2: I wouldn't go too fast, you're still having to teach me basic terms...
 well it'll take you some time to get used to packaging,d evel, etc.
[04:38] <tsimonq2> arraybolt3[m]: You would be surprised how far you've *already* come
 but in the interim Lubuntu Member is an easier hurdle :)
[04:38] <arraybolt3[m]> I'm like, "Oh, yeah, I'll help backport LXQt! Hey, what's syncing the archive mean?"
[04:38] <tsimonq2> I'm not saying developer I'm saying member ;P
 ^^ that
[04:38] <tsimonq2> XD
 developer requires more work
 uploader (in ubuntu) requires even *more* work than that
 and in Debain even more work :P
[04:38] <tsimonq2> For developer we will be sure to roast you thoroughly :P
[04:39]  * tsimonq2 high-fives teward on that one
[04:39] <arraybolt3[m]> tsimonq2: I know. But you've been throwing around worrisome terms like "upload access" and I'd like to not botch everything
[04:39] <tsimonq2> arraybolt3[m]: meh upload access is far off
[04:39] <tsimonq2> don't get worried
[04:39] <arraybolt3[m]> Oh OK good.
[04:39] <tsimonq2> we'll both know when you're ready
 and by 'thoroughly' he means inside, outside, forwards, backwards, upside down, left, right, forwards and backwards in time.
 :P
 yeah you're far off from upload access
 and we're not pushing that :P
 but Lubuntu Member has a lower bar than developer access
 / title
[04:40] <arraybolt3[m]> teward001: You missed spinning in circles.
[04:40] <tsimonq2> not until you've reached a point where we're not even reviewing your diffs anymore ;)
[04:41] <arraybolt3[m]> tsimonq2: That's a long way off, since I think I'd probably get a stomach cramp if someone said they *didn't* review my diff ATM.
[04:41] <tsimonq2> Like I said, you'll know and so will we
[04:41] <tsimonq2> It's a gut feeling
[04:42] <arraybolt3[m]> OK, VM updated, now let's try to fight with this thing again.
 if it just works this time, blame the kinetic rebuild fubaring something
 because my regex-fu and Regex101 all suggest it should Just Work
 (so does the one minor revision earlier, 2.22.1, in Jammy)
[04:45] <arraybolt3[m]> Still getting the same uscan error with the latest devscripts.
 hmmmmmm
[04:46] <tsimonq2> case-sensitivity?
 i'd say if yuo have another package to poke at poke at it and leave the featherpad stuff for the day/evening
 that could be truth
 because that's a capital V I have in ther
 not a v
 and i thought that
[04:46] <arraybolt3[m]> I'm just copypasting what teward gave me in the termbin.
 which was a capital V
 simon if you want to test the watch file yourself let me know
[04:47] <tsimonq2> check your cases and run uscan in verbose mode
[04:47] <tsimonq2> -vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
[04:47] <tsimonq2> :P
 i'm going to do an even more chaotic test - uscan in Debian
[04:47] <arraybolt3[m]> I do have LXQt to poke at, so I can do that. I've pushed everything with FeatherPad, the only thing that needs done is the GPG verify.
[04:47] <tsimonq2> ah yes wouldn't be teward without a lick of chaos
 tsimonq2: well if it doesn't work in Debain Unstable but works in Testing or Stable, then I can go to Debian and say "Um, I think something went fubar"
 but i need my laptop for that.
[04:48] <arraybolt3[m]> tsimonq2: What's funny is, "-vv" gives me copious amounts of output, but copypasting this line gives me no verbose output.
[04:48] <tsimonq2> arraybolt3[m]: (And to be fair, that can be punted if you want a few days to really bang your head against it.)
[04:48] <tsimonq2> :P
[04:48] <tsimonq2> arraybolt3[m]: it's meant somewhat sarcastically since -vvvvv sometimes does something; the more `v`s the more verbosity
[04:49] <arraybolt3[m]> Right, I knew that, it was just funny that you can actually do too many Vs.
[04:49] <tsimonq2> :P
 (approx 2h50m to completion of the backup of the laptop but I'll be asleep by then.  1.82GB per minute, but xz compression on the clonezilla image, so not super fast but fast unzip and good compression)
[04:51] <arraybolt3[m]> teward001: The uscan output you gave me is pointing to the .tar.gz files, not the .tar.xz files.
 hmm you're right let me poke more
 i think i made a faux pas
[04:52] <arraybolt3[m]> (?:(?:https://github.com)?/tsujan/featherpad/)?.*/V?(\d\S+).tar.gz
[04:52] <arraybolt3[m]> (Don't you just love how Matrix eats regexes...)
 works with my changes
[04:54] <arraybolt3[m]> Well, I'll work with LXQt until we figure out what's gone wrong. Thanks for all your guy's help!
 https://termbin.com/1hhj watchfile
 https://termbin.com/waqy uscan output with debug and no-download
 (aka "dry run")
 again, the Jammy verison of the package
 becuase Kinetic won't be available until my laptop is done backing up
 full disk imnages on a 1TB disk are not quick
[04:56] <arraybolt3[m]> Still the same error.
[04:56] <arraybolt3[m]> Applied new watch file.
 i'll poke it in Kinetic and Debian Unstable tomorrow
 well, after I sleep anyways
 and potentially go to war against uscan
 because this *sounds* like a regression in uscan
 now, plot twist, if it works for me in a brand new kinetic VM or LXD container, i'm going to tell you to rebuild your VM from scratch :P
[05:01] <arraybolt3[m]> Well, I doubt that's going to happen, since my Kinetic VM isn't highly modded (just a default install with a bucket of dev tools and a relatively straightforward sbuild setup.)
[05:25] <arraybolt3[m]> Simon Quigley (Developer): Just so I don't mess anything up, the debian/watch file autoverifies the GPG key for the LXQt stuff, right? I believe this is right because of my Lintian output (gives me a warning about GPG on FeatherPad, but not on liblxqt)
[05:25] <tsimonq2> I'm not sure which key is used for featherpad
 right now, none
[05:26] <tsimonq2> You may have to grab it and manually export it in a way that debuild likes
 ther'es no signing key defined in the package
[05:26] <tsimonq2> lubot: uh yeah there's one upstream though
[05:26] <tsimonq2> there's an asc file
 it's not hard to get that signing key - hint: i just redid that for Debian's nginx lately
[05:26] <tsimonq2> probably determine the public key from that?
 and then add that in the package
 @tsimonq2  Debian and uscan likes having the signing key locally in the package
 for keyring storage to know "this is trusted" vs. "this is not trusted"
 it'll verify the keys off that keyring
 it took me like an hour to figure that out for nginx last month
[05:27] <arraybolt3[m]> I think you misunderstood me, I wanted to know if the LXQt stuff auto-verified itself, or if I needed to do that part manually.
 that way if the key changes lintian and uscan yell/warn
 arraybolt3: check the debian/watch file.  see if it's got gpg configuration options in there
[05:27] <arraybolt3[m]> Ah, OK.
 if it does then uscan etc. do that verification on download
 if it doesn't, then it's not configured for signature verification
[05:28] <arraybolt3[m]> Including getting the signing key from the keyserver?
 no, that's still a manual step I believe
 i don't think uscan is capable of pulling right from the keyserver
[05:28] <arraybolt3[m]> Crud.
 i can double check that while i'm in the system
 but it's why the signing key is kept for NGINX
 see here - https://salsa.debian.org/nginx-team/nginx/-/tree/master/debian/upstream
 this is the signing keys that we pulled direct from upstream
 there's two because we've observed both
 (the .asc is the keyring)
 and d/watch for nginx - https://salsa.debian.org/nginx-team/nginx/-/blob/master/debian/watch
 fortunately ours is easier because we don't have to search a page for a specific regex, we know a specific tarformat we need
 s/ours/NGINX's/
 but let me see the code more
 based on the debian/watch documentation...
 it can't do the auto pull
 you include the signing key in the package yourself
 https://wiki.debian.org/debian/watch#Cryptographic_signature_verification
 so for this case, we'd have to add the config for sigurl mangling.  i'll test that AFTER I make sure we don't have a uscan regression (for featherpad)
 if we know the key to pull from the keyring and key servers, then we add that to the proper location in the packaging
 and uscan automatically checks the signature (.asc file) against the known pgp keys
 probably a good idea in this case
 because if the signing key is breached there's no way to validate it's actually from who you expect
[05:34] <arraybolt3[m]> How do I find the public key for LXQt?
 Simon should know how to get it, if they sign their releases
 though it could already be in the packaging in Debian
 (I haven't checked the LXQt branches in Debian)
 Simon: ^^ lxqt signing keys
 if they even use them.
[05:36] <tsimonq2> try checking against the existing LXQt signing key in e.g. libfm-qt
[05:36] <arraybolt3[m]> I figured out how to get gpg to tell me the key that matches the ASC file, but then how do I know that's the legitimate key?
 in reality: you don't unless they publish the key(s) they use
 and if they don't, then you have to say "If you trust the current release's signature, then use that key"
 i don't see a specific signing key defined on their site,.
 (I did not check their Github repos for documentation, etc.)
[05:39] <tsimonq2> Debian has historically been tight enough with upstream where we could trust that it is The Key. No idea if it's the same key with Featherpad
 ^^
[05:40] <arraybolt3[m]> Simon Quigley (Developer): I'm trying to get the LXQt key.
[05:40] <tsimonq2> Qool
[05:40] <arraybolt3[m]> So I can just trust the key in the .asc file?
[05:40] <tsimonq2> yes
[05:41] <tsimonq2> guiverc: You using Matrix now? :)
[05:42]  * guiverc smiles
 i'm likely going to set up a matrix server myself soon.  probably on our infra as another container heh.
 we'll see what happens after i sleep.
 i'm headed off for that now, good night.  (01:45 here)
[05:45] <arraybolt3[m]> teward001: 👋
[05:47] <arraybolt3[m]> Should I turn off piuparts in my .sbuildrc? It always fails and I don't think we care.
[05:48] <arraybolt3[m]> Also, just finally finished liblxqt, complete with a full Lintian cleanup! 🌮
[05:48] <arraybolt3[m]> Err... 🎉
[05:55] <arraybolt3[m]> Simon Quigley (Developer): Do I need to upload the packages in the LXQt backports PPA to my own LXQt PPA?
[05:55] <arraybolt3[m]> Or is there a way to link the PPAs so that mine pulls build deps from yours?
[05:58] <arraybolt3[m]> Nevermind, figured out how to link PPAs.
 "Should I turn off piuparts in my..." <- I don't mind
 "Also, just finally finished..." <- Very nice!
 "Simon Quigley (Developer): Do..." <- Yeah, just push your changes to your own Git repo
[06:04] <tsimonq2> I'll pull em down and get er uploaded to backports-staging
[06:05] <arraybolt3[m]> tsimonq2: Oh, I was getting ready to upload liblxqt to my own PPA, and needed the stuff in your PPA as build deps. I found a setting in Launchpad to allow me to "chain" PPAs like that, are you saying I shouldn't use that?
[06:05] <tsimonq2> Yeah you certainly can if you're waiting on me
[06:05] <tsimonq2> But right now feel free to just create that PR and we can push it through
[06:06] <tsimonq2> Unless I have to manually create that branch...
[06:06] <arraybolt3[m]> Oh OK.
[06:10] <tsimonq2> arraybolt3: ok so let's talk about versioning really quick...
[06:10] <arraybolt3[m]> Accidentally made the PR trying to push my code, but hey, it all appears to work!
[06:10] <tsimonq2> Think of the scenario where a Jammy user wants to upgrade to Kinetic once it's out but they have backports enabled for Jammy
[06:10] <tsimonq2> I see you have 1.1.0-0ubuntu3~ppa1
[06:10] <tsimonq2> I mean, that would usually be fine, except you can't upgrade from that to the Kinetic version
[06:10] <arraybolt3[m]> I did the ~ppa1 because that's what your stuff in the backports-staging repo was using.
[06:10] <tsimonq2> I would go with 1.1.0-0ubuntu2~ppa1
[06:11] <tsimonq2> 1.1.0-0ubuntu3~ppa1 > 1.1.0-0ubuntu2
[06:11] <arraybolt3[m]> Oh, I get it. I was going with whatever dch gave me.
[06:11] <tsimonq2> 1.1.0-0ubuntu3 > 1.1.0-0ubuntu3~ppa1
[06:11] <tsimonq2> yeah it's all good
[06:11] <arraybolt3[m]> OK, I'll check the version numbers a bit better from now on.
[06:11] <tsimonq2> lmk once that's pushed and I'll land this thing
[06:11] <tsimonq2> all good
[06:12] <tsimonq2> here let me get you some recommended reading...
[06:12] <arraybolt3[m]> Pushed it.
[06:13] <tsimonq2> eparation#Packaging
[06:13] <tsimonq2> https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging
[06:13] <tsimonq2> Update the packaging
[06:13] <tsimonq2> bullet point 2
[06:13] <tsimonq2> anyway
[06:13] <arraybolt3[m]> Oh no, I have to reboot my VM because a qemu update just came through on my host... sigh
[06:13] <tsimonq2> cool looking again
[06:15] <arraybolt3[m]> I'm going to reboot my whole system for security's sake, but I'll still be here on my Chromebook, just will be out of commission for a few minutes.
[06:16] <tsimonq2> All good.
[06:17] <tsimonq2> arraybolt3: Check the PPA, it's there now :)
[06:17] <arraybolt3[m]> Will check it in just a bit.
[06:19] <arraybolt3[m]> Ooh, shiny! I see it!
[06:20] <arraybolt3[m]> Hey, I see I'm putting a bunch of details in the changelog, since that's what the packaging guide for a new upstream release told me to do. Should I stop adding all that clutter and just put "Backport to Jammy."?
[06:24]  * arraybolt3[m] cracks knucles
[06:24] <arraybolt3[m]> Now I get to do the archive sync thingy. Moving onto libsysstat, it needs help. Here's hoping I do this right.
[06:24] <tsimonq2> Nah, keep it, it's good
[06:24] <tsimonq2> Cool
[06:35] <arraybolt3[m]> (BTW, I'm downloading Pop!_OS so I can test that Lubuntu might-be-a-bug you pointed out earlier.)
[06:35] <arraybolt3[m]> (The bit about installing Pop!_OS and Lubuntu side-by-side)
[06:38] <arraybolt3[m]> OK, so I pull-lp-source'd both the package versions of libsysstat, then debdiffed the .dsc files, but now how do I apply this diff? (I could try to figure this one out, but I'm worried it might look like it worked when it didn't, so I want to make sure.)
[06:38] <tsimonq2> What precise versions are in your packaging and the dsc files?
[06:39] <tsimonq2> The earlier versioned dsc must match the packaging version exactly to get a correct diff
[06:39] <arraybolt3[m]> The one in the packaging is 0.4.4-1ubuntu1.
[06:40] <arraybolt3[m]> The one I'm trying to update to is 0.4.6-1.
[06:40] <arraybolt3[m]> (Also, the one in the dsc is also 0.4.4-1ubuntu1.)
[06:40] <tsimonq2> Perfect.
[06:41] <tsimonq2> Another hack is to just run `debuild -S -d -sa` with the packaging repo and use that dsc ;)
[06:41] <tsimonq2> options options options
[06:41] <tsimonq2> I like a pristine dsc just in case I accidentally made some packaging changes
[06:41] <tsimonq2> but I can be pedantic lol
[06:42] <arraybolt3[m]> That's a good trick to know. I have the debdiff file, but I have no clue how to actually apply it to my packaging data now.
[06:42] <arraybolt3[m]> I think it's probably going to be done with `patch` but I'm not sure.
[06:43] <tsimonq2> patch -p1 ../debdiff.patch
[06:44] <arraybolt3[m]> (Also just learned about debdiff-apply, I wonder what that does... but I'll just use patch.)
[06:46] <arraybolt3[m]> Simon Quigley (Developer): On my VM, that command just hangs.
[06:47] <arraybolt3[m]> Does it just take a while but not use much CPU?
[06:53] <arraybolt3[m]> Ah, I figured it out. It's `patch -p1 <../debdiff.patch`.
[07:04] <arraybolt3[m]> Just got the following interesting Lintian output: "I: libsysstat-qt5-0: hardening-no-fortify-functions [usr/lib/x86_64-linux-gnu/libsysstat-qt5.so.0.4.6]" I know that I can't manually edit a .so file, but I don't know how to get rid of this message the right way other than edit the file it says, and I don't know what it's telling me.
[07:05] <tsimonq2> That one is okay
[07:25] <tsimonq2> arraybolt3: Need anything before I crash?
[07:25] <arraybolt3[m]> Maybe one last PPA upload, other than that, no. I'm almost done with this thing.
[07:26] <tsimonq2> Cool. I'll still be around. Just ping when you're ready
[07:39] <arraybolt3[m]> Simon Quigley (Developer): Pull request made for libsysstat-packaging.
[07:41] <arraybolt3[m]> Shoot, I forgot wrap-and-sort.
[07:41] <arraybolt3[m]> One moment...
[07:42] <arraybolt3[m]> Simon Quigley (Developer): OK, now it's actually done.
[07:43] <tsimonq2> I say take off the ubuntu1
[07:43] <tsimonq2> That's just a gut feeling
[07:43] <arraybolt3[m]> I tried that, but it resulted in sbuild failures.
[07:44] <arraybolt3[m]> I guess I can uscan again after doing that. I'll try it.
[07:44] <tsimonq2> See the other LXQt packages, it's a two line change in d/control
[07:44] <tsimonq2> So 0.4.6-1~ppa1
[07:44] <tsimonq2> You shouldn't have to tweak the maintainers at that point
[07:45] <arraybolt3[m]> OK, version changed, and uscan takes it. Should I bother with another sbuild, or just push it?
[07:47] <tsimonq2> nah just push it
[07:48] <arraybolt3[m]> I also noticed that I needed to bump standards-version, so I did that. I probably forgot to do that on liblxqt, since I trained myself to ignore the Lintian output related to standards-version since it kept throwing itself at me incorrectly before. Oops. Got it right on this one.
[07:48] <arraybolt3[m]> Simon Quigley (Developer): Pushed.
[07:49] <tsimonq2> please bump the build dependency
[07:49] <arraybolt3[m]> Actually, liblxqt was already on the newest version, so yay!
[07:49] <tsimonq2> the version
[07:50] <arraybolt3[m]> I don't know what I'm missing, where do I bump what?
[07:51] <arraybolt3[m]> I changed the version in the changelog, but I don't know what I'm supposed to change other than that.
[07:51] <arraybolt3[m]> Simon Quigley (Developer): me is confused
[07:51] <tsimonq2> lxqt-build-tools
[07:51] <tsimonq2> we should depend on the newest version
[07:51] <RikMills> morning
[07:51]  * RikMills thinks tsimonq2 must be on the redbull again
[07:51] <arraybolt3[m]> Ah, OK
[07:52] <tsimonq2> Hey Rik what's up? :)
[07:52] <tsimonq2> bahahahahaha
[07:52] <tsimonq2> RikMills: I discovered 5 hour energy for the first time the other day... if only you could have witnessed me chugging two in the span of three or four hours :P
[07:53] <RikMills> never heard of that, but I can imagine!
[07:54] <arraybolt3[m]> Simon Quigley (Developer): Pushed, tell me if I got the version right, also added us to the Copyright file, another thing I forgot for liblxqt, but remembered here.
[07:55] <arraybolt3[m]> RikMills: Good morning, how's it going?
[07:55] <arraybolt3[m]> We're in here bashing our brains on LXQt.
[07:58] <tsimonq2> arraybolt3[m]: Pushed and uploaded. Nice work and great determination :)
[07:58] <arraybolt3[m]> Thanks! I'll hopefully fix the copyright file for liblxqt, and keep plugging away at it tomorrow. Thank you for everything!
 i couldn't sleep soooooooo
 arraybolt: fresh Kinetic LXD container - https://pastebin.ubuntu.com/p/zTjZnvkvY8/
 that's your watch file yes?
 not mine
[08:02] <arraybolt3[m]> teward001: Looks like mine.
 this is with *my* watch file, in a *freshly created and updated* LXD container of Kinetic from the daily images system.  https://pastebin.ubuntu.com/p/fmMBTNMdTS/
 and it works
 so whatever is going on in your environment is unique to *your* environment
[08:04]  * arraybolt3[m] telepathically vigorously shakes desktop screen
 nuke your VM, clean it from scratch, and start it over.
[08:04] <arraybolt3[m]> teward001: Alright, that's just odd. I'll build a new VM tomorrow.
[08:05] <arraybolt3[m]> teward001: If it fails in a new VM, I'm going to be seriously confused.
 and just to prove the thing works fine, i have a debian unstable (sid) container here too, from linuxcontainers.org's images.  fully updated and fully installed devscripts, etc.  and it works too.  https://pastebin.ubuntu.com/p/tRY9FcK37Y/
[08:06] <arraybolt3[m]> teward001: You are using "uscan --download-current-version", right?
 i'm doing dry-run and it works fine
 in unstable it works
[08:07] <arraybolt3[m]> teward001: For my sanity's sake, try it with --download-current-version and see if it borks.
 *that* doesn't work in kinetic
 but let me try something
 oh wait
 you know what you did
[08:07] <arraybolt3[m]> It doesn't work? That's the command I've been using.
 i think you've broken something
 bah git trees
 hang on
[08:09] <arraybolt3[m]> I'm just so baffled how I could have possibly broken something, I didn't do anything weird to my setup. (Come to think of it, I did Ctrl+C out of an sbuild once, but that shouldn't have broken uscan, and sbuild's still working just fine.)
 so
 download-current-version is for the 'currently packaged version'
 but that's... not exactly what you want
 i say this because
 i don't think the url patterns match
 let me run extra debug mode
[08:09] <arraybolt3[m]> And that would influence .tar.gz vs .tar.xz, of the same version?
[08:10] <arraybolt3[m]> I mean, the files are named the exact same thing but one changed to .xz IIRC.
[08:11] <arraybolt3[m]> (Actually, I've Ctrl+C'd out of sbuilds a few times, but again, that shouldn't have been the problem.)
 again this isn't an sbuild problem
[08:11] <arraybolt3[m]> Right.
[08:11] <arraybolt3[m]> I'm just trying to figure out what I could have broken.
[08:14] <arraybolt3[m]> Lemme try a dry run on my existing VM and see what happens.
 see normally i just use --download if there's no special 'newer' version that we're packaging
 and it sounds to me like --download might be what you want (default behavior) since this is the latest release
 and there's no others
 and i know that --download works
 i'm going to go beat myself to sleep and then ask for someone to help me prod this one around, because i don't think this is normal behavior for uscan
[08:17] <arraybolt3[m]> teward001: Can you shoot me your watch file again?
 hmm https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891047 i think is relevant
 or at least it looks like a similar bug
 let me poke Debian
 arraybolt: give me a moment
 oh here we go more bugs
 i think this is a uscan bug but i'm going to ask Debian to poke it
[08:23] <arraybolt3[m]> OK, even more interesting results. I extracted your watch file from the logs from a working run, and managed to download the .xz file this time (using uscan --download), however it also threw this all over my terminal: https://pastebin.com/C3Jb73ZY
 yeah i noticed that one as well
 that's a different issue i think, part of the problem being that it wants to extract it a certain way and the underlying directories don't exist for your environment
 i'm going to dig into that later
 potentially
 but this is turning into a cluster so
 i've sent this all to #debian-devel with some tweaks so it looks like I'm working on a debian package attempt rather than an *ubuntu package, but also because this source behavior looks odd in Debian
 we'll see what happens.
 i'mma go beat myself into sleep now.
[08:30] <arraybolt3[m]> teward001: I hear chamomile tea works a lot better than bruises.
[08:31] <arraybolt3[m]> teward001: Not sure if you're the one who said you hate tea, but FWIW, there it is.
 and this explains why it breaks in --download-current-version - "it cannot find a matching *version*, because the found versions are in a form of "1.3.0/FeatherPad-1.3.0""
 i wonder if we can use a mangle to fix that
 huzzah i figured it out
 i'm just tired
[08:39] <arraybolt3[m]> I love programming. We use mangles to fix things, name our software after what they aren't, and use hacks to keep things secure. Wonder what we'll flip upside down next.
[08:40] <arraybolt3[m]> s/they aren't/it isn't
 this didn't need a mangle
 it needed a different regex match
 which i'll hand you in a minute
 but i'll also need you to create a file in the packaging
 because i solved the pgp part too i think
 https://paste.debian.net/1244837/  the updated watch file
 https://paste.debian.net/hidden/af597b29/  <— what to put in debian/upstream/signing-key.asc
 put both bits together and your uscan --download-current-version should work without issue
 for featherpad
[08:46] <arraybolt3[m]> Fantastic, thank you. I'll pull those two files before they vanish, and then try to apply them tomorrow (my desktop is on the other side of the room from me ATM and I really don't want to get up and try again right now.)
 thanks to wRAR in debian-devel on OFTC for helping me realize that "I Am An Idiot" when tired
 (those two are set for 90d expiry)
[08:47] <arraybolt3[m]> Oh, nice, thank you! I missed the difference between 6 and 9 in the month (my screen is small and I'm tired)
 no worries
 now, whether this actually properly BUILDS is another test
 if we're lucky it will work without issue :P
 i'm going to take a melatonin dose and go zonk out.
[08:49] <arraybolt3[m]> OK. Thank you so much, and see you tomorrow (or whenever)!
 arraybolt3: one you get that in the packaging, run that in a full sbuild env and make sure that it properly pulls the stuff in, and extracts and such.
 barring any chaos it should "just work"
[08:55] <teward> tsimonq2: required work for you.  lubuntu-team/pastebinit.  updated for issues reported downstream, thanks to Unit193's merge request.  Thanks to you adding me to lubuntu-team, merged.  Needs a Debian upload and a version string bump.
[08:55] <teward> that's your job and that's an easy one.
[08:55] <teward> i'm offlining for sleep now.
[17:56] <arraybolt3[m]> teward001: The watch file and signing key work! Thank you so much!
[18:02] <arraybolt3[m]> teward001: Also, the sbuild worked just fine, I removed my old FeatherPad installation and installed the newly built package, and it also appears to be working. \o/
[18:14] <tsimonq2> Good morning/afternoon :)
[18:14] <arraybolt3[m]> Simon Quigley (Developer): Good morning to you, how's it going today?
[18:15] <arraybolt3[m]> (I guess it's actually good afternoon here, but whatever.)
[18:15] <arraybolt3[m]> Hey, I finished up with FeatherPad just a bit ago, would you like me to open another GitHub PR, or do you just want the diff?
[18:16] <arraybolt3[m]> Dan Simmons: Good whatever it is in your part of the world (morning/evening/afternoon/etc)!
[18:16] <kc2bez[m]> 👋
[18:17] <kc2bez[m]> Quarter after 2 in the afternoon here.
[18:17] <arraybolt3[m]> Dan Simmons: Nice, so we're all in close enough to the same spot in the world to work at the same time.
[18:17] <arraybolt3[m]> 1:17 in my neck of the woods.
[18:17] <arraybolt3[m]> PM, not AM.
[18:19] <arraybolt3[m]> I guess while things are just getting going, I'll get everything updated and then maybe try and merge the LibreOffice localization bug patch. Since it will probably need SRU'd since it was made in response to a Jammy bug report, is there anything in particular I need to be doing differently with that patch?
[18:19] <tsimonq2> arraybolt3[m]: Pretty good :D just got some good news, unfortunately not one I can share but I'm happy and that's all that matters :)
[18:20] <kc2bez[m]> arraybolt3[m]: We should make sure the change is in Kinetic first.
[18:21] <kc2bez[m]> And has been verified to work.
 "Hey, I finished up with FeatherP..." <- Simon Quigley (Developer): Just in case it got missed in the backlog.
 "Hey, I finished up with FeatherP..." <- I forget, we didn't already merge/upload this right? Updating the PR may be okay
[18:21] <arraybolt3[m]> I believe you manually command-line merged it or something.
[18:22] <arraybolt3[m]> Yeah, I'll make a new PR.
[18:22] <tsimonq2> No that was libsysstat right?
[18:22] <tsimonq2> I dunno :)
[18:22] <arraybolt3[m]> Me neither. :)
[18:22] <arraybolt3[m]> Well, I can see in the PR I'm just about to open, it wants to try and merge a lot of commits, so I'm guessing it probably wasn't merged all the way in yet.
[18:24] <arraybolt3[m]> tsimonq2: Which reminds me, I have to fix the liblxqt copyright file and send that, plus I somehow mangled GitHub on that one. If I just trash my liblxqt fork, make a new one, then upload to it in a way that actually works and makes sense, will that still work for re-creating the PPA package?
[18:27] <arraybolt3[m]> https://github.com/lubuntu-team/featherpad-packaging/pull/1
[18:28] <tsimonq2> arraybolt3[m]: Should
[18:29] <tsimonq2> Merged, will upload shortly
[18:36] <arraybolt3[m]> https://github.com/lubuntu-team/liblxqt-packaging/pull/3 Careful with this one, I'm not sure what GitHub's doing here (looks like it's going to merge from my backports branch straight into Kinetic?), but this is ready.
[19:51] <tsimonq2> New Calamares snapshot landed in the daily today. Changes included are here: https://github.com/calamares/calamares/compare/2f3fb4...d9b456
 "https://github.com/lubuntu-team..." <- Done and uploaded to the PPA
[20:00] <arraybolt3[m]> Nice. I'll try to test that today.
[20:06] <tsimonq2> https://launchpad.net/ubuntu/+source/featherpad/1.3.0-0ubuntu1
[20:06] <tsimonq2> Congrats :)
[20:13] <tsimonq2> arraybolt3: Do you plan on making Backports progress today or should I jump in for a few later?
[20:15] <tsimonq2> Looks like some greetd fixes have been uploaded since the reroll of the tar. Doesn't apply to us but if someone brings it up lmk.
[20:17] <arraybolt3[m]> Yes, I do want to do more Backports today. I probably won't be active for an hour or two, but I will be doing it hopefully after that. I can test and backport at the same time.
[20:20] <arraybolt3[m]> Also, I'm making sure to clean up Lintian stuff for every build, so we can probably take our backports and then re-forward-port (?) them to Kinetic to get hopefully Lintian-clean builds.
[20:40]  * tsimonq2 goes afk for a bit
[20:41] <tsimonq2> Any questions ping - otherwise Dan and Thomas have upload access to this PPA
[20:41] <kc2bez[m]> Take care Simon Quigley (Developer)
[22:14] <arraybolt3[m]> Started to backport qtxdg-tools.
 "Started to backport qtxdg-tools." <- Great job arraybolt3 @arraybolt3:matrix.org: