[00:02]  * arraybolt3[m] fiddles with a Rubik's cube while waiting for this thing to update
[00:03] <arraybolt3[m]> (And I'm going to assign it all eight threads that I have rather than just four, to try to speed things along.)
[00:06] <arraybolt3[m]> Alright that's going to take a while, /me starts packaging while I wait for this thing to update
=== arraybolt3_ is now known as arraybolt3
[00:53] <arraybolt3[m]> teward: No need to answer, this is just to satisfy my curiosity, but did the watch file hack I shared end up being useful?
[00:54] <tsimonq2> arraybolt3[m]: Well, the ones Andrew uploaded did not work at all with the upstream tarball signatures
[00:55] <tsimonq2> So, every package in that list I just replaced with your template watch file and it works fine :P
[00:55] <arraybolt3[m]> \o/
[00:55] <tsimonq2> I remember from the d-devel discussion that the only limitation of that approach is GitHub API calls
[00:55] <tsimonq2> As in, rate limiting
[00:55] <tsimonq2> GitHub will figure out soon enough that Debian exists >:P
[00:56] <arraybolt3[m]> Ohhhh... for automated mass builds.
[00:56] <tsimonq2> Yeah :)
[00:56] <arraybolt3[m]> See my thought was "no one's ever going to trigger so many builds so fast that they're going to hit a rate limit." But... one fast-moving PPA or build server sure will!
[00:56] <tsimonq2> We don't nearly have that usecase, so I think we'll be okay. Once we start getting this in CI though, I think I'll have to implement a hard limit in code so we don't get ourselves blocked
[00:57] <arraybolt3[m]> And then what happens when they go into Launchpad or similar?
[00:57] <arraybolt3[m]> Is there a way to prevent flooding the API there?
[00:57] <tsimonq2> Well, a copy of the tarball is uploaded with the source. It doesn't grab it every time. Technically you could upload a package with a non-functional watch file :P
[00:57] <arraybolt3[m]> tsimonq2: GitHub has made very foolish decisions in the past that drove people nuts and they didn't end up caring a whole lot. See the brownouts for Ubuntu 18.04 GitHub Actions during deprecation.
[00:58] <arraybolt3[m]> tsimonq2: Oh I see. So it's not a problem there I guess?
[00:58] <tsimonq2> However, the Debian package tracker polls at shrug some frequency to ensure those watch files still work, and to check for new upstream versions
[00:58] <arraybolt3[m]> arraybolt3[m]: (To be fair they did seem to stop doing that for a while, but then it looks like they started again...)
[00:59] <tsimonq2> Yeah, that's what happens when Microsoft acquires a company, it seems :P
[00:59] <arraybolt3[m]> Maybe we'll just need to host the repos ourselves on a different Git server and then plug that into the watch file.
[00:59] <tsimonq2> Anyway, I need to step away for a good hour or two, but I'm seeing green checks down the board for both Backports Staging and the choo choo train
[00:59] <arraybolt3[m]> OK. See you later, and thanks!
[01:51] <teward> arraybolt3: yep for my needs.  i didnt share it wider yet
[01:51] <teward> i was at a coworker's retirement party sorry
[03:49] <tsimonq2> lynorian: Push mirror now set up for GiTea -> GitHub, enjoy :)
[03:50] <arraybolt3[m]> Does that mean I should run the setup-gitea script?
[03:50] <lubot> [telegram] <tsimonq2> @lynorian ^^^
[03:50] <tsimonq2> arraybolt3: Where was that again? :P
[03:50] <arraybolt3[m]> Lemme post it...
[03:52]  * arraybolt3[m] sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/17087ecef280e8abbd60d4577a625d71748bb59f
[03:52] <tsimonq2> arraybolt3: Hey, do you have access to create a repository under the Lubuntu namespace in GiTea?
[03:52] <arraybolt3[m]> I do. Someone (dunno who) gave me admin access.
[03:52] <tsimonq2> Please create a scripts repo and collect all your useful scripts there :P
[03:53] <arraybolt3[m]> (Which I treat with caution - not sure why but...)
[03:53] <lubot> [telegram] <lynorian> Sadly is the lunar iso still not yet up
[03:53] <arraybolt3[m]> (As in, not sure why I got given admin access.)
[03:53] <arraybolt3[m]> tsimonq2: 👍️
[03:54] <tsimonq2> @lynorian: Soon... very soon :)
[03:54] <tsimonq2> arraybolt3[m]: "Oops, someone gave Aaron powers, we better revoke them before he completely wrecks the site" -Nobody, ever :)
[03:55] <arraybolt3[m]> tsimonq2: ROFL
[03:57] <arraybolt3[m]> Simon Quigley: https://git.lubuntu.me/Lubuntu/lubuntu-tools (This is where the script is going to be in a bit here)
[04:01] <tsimonq2> Sounds good, thanks!
[04:16] <arraybolt3[m]> Simon Quigley: Alright, repo pushed.
[04:22] <tsimonq2> <3 the README
[04:23] <arraybolt3[m]> Except for the bit where I botched the Markdown...
[04:23] <tsimonq2> ¯\_(ツ)_/¯ you'll fix it in the next commit right? :P
[04:24] <tsimonq2> also, very brave of you to simply put a comment on line 29 :P
[04:24] <arraybolt3[m]> tsimonq2: Should be fixed already.
[04:25] <tsimonq2> if we wanted this script to be "safe," you'd do some detection to make sure git is found in the current $PATH and throw a print statement with the current directory path + prompt for a y/N - depends on how overkill you want to go :P
[04:26] <arraybolt3[m]> That's a good point. And I guess our internal tooling should be ready for in the event more people come on board.
[04:27] <tsimonq2> also: https://stackoverflow.com/questions/287871/how-do-i-print-colored-text-to-the-terminal
[04:27] <tsimonq2> :P
[04:27] <arraybolt3[m]> Anyway the comment on line 29 is only for if you're modifying the script - if you're only using it, it doesn't exactly matter.
[04:27] <arraybolt3[m]> tsimonq2: Someone noticed my giant line of exclamation points. :P
[04:29] <tsimonq2> `subprocess.run(["git", "branch", newBranch])` - perhaps consider `git checkout -b newBranch`
[04:29] <arraybolt3[m]> tsimonq2: I literally did that once and then changed it because I thought calling the function "gitbranch" and then using `git checkout -b` was a bit misleading.
[04:30] <arraybolt3[m]> I figured better to have the code be truthful and obvious even if it meant it was a bit less efficient.
[04:30] <arraybolt3[m]> (I mean, c'mon, it's Python. If you're writing something in Python, you've already mostly thrown efficiency out the window...)
[04:32] <tsimonq2> it can also get out of hand quickly if you're simply running subprocess.run and not capturing the output... simple pseudocode may look something like:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/00cdb674b18a8e49ff417c125e79ddb38dbd45e8>)
[04:33] <arraybolt3[m]> Hmm, that's a good point.
[04:33] <arraybolt3[m]> You'll notice I do capture and use the output in the `gitcurrentbranch()` function, but the others don't really need it (though perhaps doing error checking by checking the current branch is a bit kludgy and is definitely less efficient).
[04:34] <tsimonq2> ohhhhhh, yeah
[04:34] <arraybolt3[m]> `git checkout -b` will succeed even if the branch already exists, and just behave the same as `git checkout`, right?
[04:35] <tsimonq2> tbh, this is kind of what GitPython is meant to do, a purely Pythonic way of representing a Git repo :P
[04:35] <tsimonq2> I understand it's deprecated but it accomplishes exactly this minus the complexity of having to learn it all :P
[04:35] <tsimonq2> that being said, if you want to use this as a Python learning exercise, by all means ;)
[04:36] <tsimonq2> arraybolt3[m]: That's something to look into, I don't remember off the top of my head :)
[04:36] <arraybolt3[m]> I'd have to test it, the docs are ambiguous.
[04:38] <arraybolt3[m]> tsimonq2: That, and also:
[04:38] <arraybolt3[m]> 1. Avoiding deprecated things is pretty much always good, unless you particularly like having things come back to bite you later. Maybe it won't bite for way later, maybe it won't bite at all, but why risk it?
[04:38] <arraybolt3[m]> 2. GitPython requires the use of pip to install it, and not everything that you can install with pip is safe. Typo-squatting supply chain attacks are possible, and that's something we do **not** want to happen to us.
[04:38] <arraybolt3[m]> 3. This isn't that much difficult to implement - in fact, for me, it's a bit easier.
[04:38] <arraybolt3[m]> And 4, this is a tiny bit more portable - someone who is avoiding GitPython for reasons will still be able to use this.
[04:39] <tsimonq2> `apt show python3-git` would disagree with #2 :P
[04:40] <arraybolt3[m]> tsimonq2: Oh. Didn't know that it was available in Apt. That does fix that point nicely.
[04:40] <tsimonq2> not against the other points :)
[04:40] <tsimonq2> arraybolt3[m]: `apt list | grep python | grep git` got me there
[04:41] <arraybolt3[m]> Oh that's clever.
[04:41] <RikMills> morning. can't sleep :/
[04:41] <arraybolt3[m]> There's also `apt-cache search git-python`
[04:41] <tsimonq2> Hey Rik :)
[04:41] <arraybolt3[m]> RikMills: o/
[04:41]  * RikMills risks a caffeine overdoes
[04:42] <RikMills> *overdose
[04:42] <arraybolt3[m]> Extra-bold + french vanilla + clover honey = yay
[04:43] <RikMills> I bet
[04:43] <tsimonq2> RikMills: Godspeed, literally and metaphorically :P
[04:43] <arraybolt3[m]> *french vanilla creamer, I mean - leave out the creamer and that's sad :(
[04:44]  * tsimonq2 continues to chug through LXQt 1.2.0
[04:44] <tsimonq2> RikMills: sorry in advance for tangling your transition :)
[04:45] <RikMills> which one?
[04:45] <tsimonq2> probably doesn't directly conflict with KDE PIM, but Britney likes to group random things together sometimes...
[04:47] <RikMills> There is usually a reason. just can be hard to fathom sometimes
[04:47] <RikMills> bileto copy to archive still seems broken :/
[04:48] <arraybolt3[m]> Speaking of that, I'm just finishing up a copyright file, and then I get the supreme privilege of throwing the whole mess at Launchpad and my RISC-V slomulator.
[04:57] <tsimonq2> RikMills: wait really? that's about to be a fun task for me :P
[04:58] <RikMills> Lucaz was looking into it. he needs/needed to be granted some extra permissions by IS to properly debug he said
[05:00] <RikMills> https://irclogs.ubuntu.com/2022/11/16/%23ubuntu-release.html#t09:05
[05:01] <RikMills> doing a manual copy would presumably dump stuff into binnew
[05:07] <tsimonq2> sounds like fun...
[05:11] <arraybolt3[m]> Alright, RISC-V sbuild schroot is now building. Also, even this system is running RISC-V slowly :P
[05:13] <RikMills> great. m-o-m stopped updating AGAIN
[05:13]  * arraybolt3[m] sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/3f94af9bd3b2c625d6e69c87554601d03aefb1e7
[05:15] <arraybolt3[m]> Maybe debootstrap is trying to pull from the wrong URL? It should be trying to pull from http://deb.debian.org/debian-ports.
[05:23] <RikMills> tsimonq2: is wxl still about? he just expired from kubuntu-members
[05:27] <arraybolt3> !ping
[05:27] <ubot93> pong!
[05:28] <arraybolt3[m]> Network issues.
=== arraybolt3_ is now known as arraybolt3
[05:33] <tsimonq2> <arraybolt3[m]> "Maybe debootstrap is trying to..." <- Ports.debian.org ? Hm
[05:36] <arraybolt3[m]> Whew! Got it, I think! First the URL needed to be changed, then that needed a different GPG key, which had to also be specifically pointed to (thankfully the keyring was installable as an apt package so I didn't have to blindly trust a key).
[05:37] <tsimonq2> RikMills: wxl> no, very unfortunately :/
[05:37] <tsimonq2> RikMills: MoM> we really need to do something better here :(
[05:38] <arraybolt3[m]> Oh lovely, I just flushed my username, password, and API key from that setup-gitea script on accident. :/
[05:39] <arraybolt3[m]> OK, I still have a copy of it. Yay.
[06:17] <arraybolt3[m]> Building libqtxdg for RISC-V, finally.
=== blaze1 is now known as blaze
[16:58] <lubot> [telegram] <Leokolb> Daily Lunar build fails again..
[17:14] <arraybolt3[m]> > <@tsimonq2:linuxdelta.com> You have two options, essentially:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/8cdff85a9c35b74970761ea27aec5e531f0619ac>)
[17:14] <arraybolt3[m]> I even extracted just the symbols diffs from the logs, and it did the same thing.
[17:19] <arraybolt3[m]> Thankfully the symbols diff was very small and symbol so applying it by hand was a piece of cake.
[17:26] <arraybolt3[m]> At any rate, last step is to set up an i386 VM and try to build in it, and then I'm done with libqtxdg and can tackle the next symbol-laden mess.
[17:27] <arraybolt3[m]> s/symbol/simple/
[17:45] <arraybolt3[m]> Simon Quigley: You gonna be around soon-ish? I'm prepping to throw a symbols file at Andrew momentarily and am wondering what course of action you would suggest for minimum friction in so doing.
[17:49] <tsimonq2> > <@arraybolt3:matrix.org> ```... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/c4c0c037816ee749870b67f02429cdcf92b901bc>)
[17:50] <arraybolt3[m]> Which file, the main symbols file itself?
[17:50] <tsimonq2> Yeah
[17:51] <arraybolt3[m]> Ah. And what would that comment look like? #SymbolsHelper-Confirmed ?
[17:51] <tsimonq2> Yes, or similar :)
[17:51] <arraybolt3[m]> Nice.
[17:52] <arraybolt3[m]> Also, for the sake of making sure that things go smoothly, which one of the three would you like me to do:
[17:52] <arraybolt3[m]> 1: Do the best job I can at prepping the symbols file (using Launchpad and both RISC-V and i386 VMs), then send it to Andrew and hope for the best.
[17:52] <arraybolt3[m]> 2: Throw the packaging at you so you can use the porterboxes on it.
[17:52] <arraybolt3[m]> 3: Try to set up my own emulated build farm myself so I can make sure every single architecture is right.
[17:53] <tsimonq2> 1
[17:54] <tsimonq2> Although given Launchpad publisher speed I've been >< THIS close to setting up a local LP and hammering at that issue until I figure it out 
[17:54] <arraybolt3[m]> For me all the builds failed and I only needed the buildlogs anyway so :P
[17:55] <tsimonq2> XD
[17:57] <tsimonq2> I'm gonna go get a workout in, I can review sometime after 1 if that's what you would prefer :)
[17:57] <arraybolt3[m]> Thanks!
[17:57] <tsimonq2> Of course :)
[18:26] <arraybolt3[m]> i386 passing, RISC-V build in progress and files uploaded to PPA. If this passes, then we're done!
[19:59] <arraybolt3[m]> Alright, everything passes, time to wrap up!
[20:03] <arraybolt3[m]> MR submitted. Woot!
[21:45] <arraybolt3[m]> liblxqt mostly done, just have to do copyright and symbols now.
[21:47] <arraybolt3[m]> Actually I see there's some work that Simon's done for me that I need to upstream.
[21:49] <arraybolt3[m]> Alright that was easy.
[21:58] <arraybolt3[m]> Random licensing question - is it legal to include a GPL-2+ source code file in a repo that is LGPL-2.1+? Or does that make it so that the whole repo is actually GPL-2+? I'm pretty sure the latter is true, which causes some... problems... with liblxqt.
[22:09] <arraybolt3[m]> Simon Quigley: liblxqt has a serious licensing problem>
[22:09] <arraybolt3[m]> It's licensed under LGPL-2.1+... but it includes a file that is GPL-2+, which makes the whole thing GPL-2+. I think that's problematic.
[22:28] <tsimonq2> <arraybolt3[m]> "It's licensed under LGPL-2.1+......" <- Which specific file?
[22:28] <arraybolt3[m]> lxqtbacklight.cpp and lxqtbacklight.h so far.
[22:29] <tsimonq2> <arraybolt3[m]> "Random licensing question - is..." <- Time for me to re-read the longtexts... :)
[22:29] <arraybolt3[m]> I asked in ubuntu-devel, juliank seems to think that the latter is true, and I'm pretty sure from my reading that that's how it works.
[22:46] <tsimonq2> arraybolt3: https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
[22:47] <tsimonq2> Here's what I'll tell you on this one...
[22:48] <tsimonq2> Yes, it is an issue for upstream, specifically because zero proprietary works can be based on liblxqt, at all. With wing-menu having no licensing, it adds an additional argument for not shipping it
[22:49] <tsimonq2> I think back to the reason Qt is dual-licensed... for open source projects, it is okay to use Qt, as long as they maintain compatibility. That's what allows KDE and LXQt to exist
[22:49] <tsimonq2> That being said, if you start developing proprietary software on top of Qt, it's not permissible to do so without paying a fee to the Qt Company
[22:51] <tsimonq2> The same is the case here. In Debian and Ubuntu, we only ship software that is free (not gratis. free) and separate other software into restricted and multiverse, depending on the Canonical support (contrib and non-free for Debian)
[22:52] <tsimonq2> I don't think this presents a problem for us in shipping it. As long as each file is explicitly marked as what it's licensed upstream, there should not be an issue with shipping it. I would defer to vorlon for a final opinion on that, although he is a pretty popular guy these days :)
[22:52] <tsimonq2> That being said, I would immediately file an upstream bug letting them know that any GPL-2 licensed code makes the entire project GPL-2
[22:53] <arraybolt3[m]> The problem I'm seeing is with making the copyright file - do I state that it's licensed under GPL-2+ (since it is), or just stick with what upstream says, inaccurate though it may be?
[22:53] <tsimonq2> Explicitly note the upstream files that are GPL-2 vs LGPL-2 respectively, I
[22:53] <tsimonq2> * respectively, I'd say
[22:53] <arraybolt3[m]> OK, will do.
[22:55] <tsimonq2> Another route, if this really bugs you, would be to email debian-legal@lists.debian.org before going upstream
[22:55] <tsimonq2> As per https://www.debian.org/doc/debian-policy/ch-archive.html#copyright-considerations :)
[22:59] <arraybolt3[m]> OK, I have to go afk, like, right now, and probably won't be back until tomorrow night. Thank you so much for everything!
[22:59] <arraybolt3[m]> 👋
[23:07] <tsimonq2> Cya, good luck :)
[23:40] <tsimonq2> Good news: it's likely LXQt 1.2 will be ready to test for Backports Staging tonight, and will also land in the proposed pocket of Lunar