[00:08] Alright, prepping for symbols update. [00:14] https://git.lubuntu.me/Lubuntu/lubuntu-tools/raw/branch/main/lxqt-builddep-graph/dependency-map.png [00:14] What. In the world. [00:14] That's current [00:14] :P [00:15] And I have another one that also puts the KDE Frameworks we depend on in the mix too :P [00:15] (Same dir) [00:15] Oh grief. I liked the layered way better. [00:15] (I get why this is useful, but...) [00:15] Easier to read but simplified :) [00:16] And that's just build deps lol [00:36] OK, I may be a bit, sbuild setup again. [00:40] No worries - I'm about to step away for a few hours, just waiting on Britney :) [00:41] In the mean time I'm uploading to a PPA so woot [00:45] Perfect, here come the build failures. [00:55] Heh :) === arraybolt3_ is now known as arraybolt3 [02:06] !ping [02:06] pong! [02:06] Alright, IRC bouncer functional! \o/ [02:08] * arraybolt3[m] 's brain is about to explode with the number of keyboard shortcuts I'm having to use :P [02:11] And the riscv build has now been started! [02:22] i386 build also kicked off. And all the PPA builds finished, so symbols file update, here we come! [02:24] Shoot. Stuff in Debian hasn't pushed through yet... sigh, alright now I have to do a local package set up which is going to take a while. [02:26] OR... wait a minute, perhaps the power of the PPA can be used here! [02:27] Except... then I'd be pulling Ubuntu packages into a Debian schroot. Wow. This is getting confusing. [02:30] "Shoot. Stuff in Debian hasn't..." <- Why are you avoiding this, if I may ask? It's pretty darn easy [02:31] I'm not avoiding it anymore. The problem is that Barry's scripts have a bunch of his own stuff hardcoded in and it was a hassle to figure out how to fix them last tine I fiddled with them, plus apt-cacher-ng adds a layer of complexity, and then the speed of RISC-V emulation makes the whole thing like wading through molasses :P [02:31] (Though I'm going to have to use local packages if I'm doing RISC-V, since the PPA won't have RISC-V packages in it.) [02:33] This should hopefully only take time and eternity once, then it should be easy from then on. [02:34] Also, Simon Quigley: That build dependency graph is about to come in mighty handy, since it means I only have to figure out liblxqt's deps to RISC-V build before I can build liblxqt, rather than having to build the whole stack up to there! \o/ [02:51] Pffft. Nevermind, Stage 0 and 1 are both one package each, so technically I am going to be building the whole stack up to that point :P [02:56] "I'm not avoiding it anymore. The..." <- Protip for next time, script it. Either using your Ansible flavor of choice, or straight bash. Figure out a container solution to iterate (hint: `lxc launch ubuntu-daily:devel --ephemeral` then `lxc shell ridiculous-name` / `lxc exec ridiculous-name -- echo "Hello world."` then powering off the container from the inside automatically destroys it) and make sure it can do it from [02:56] scratch [02:56] It will take you twice or three times as long to do initially, but you're going to save so much time if you ever need to re-deploy [02:57] I really need to do that. That's a good idea. [02:57] "Pffft. Nevermind, Stage 0 and..." <- Meh, you just won't have to build as much depending on the package :) [02:57] Some way to do a similar thing for moving files in and out of VMs would be handy too - tar + cat + netcat works, but it's a bit tedious. [02:58] Or I just need to make a shared folder LOL [02:58] Off the top of my head, sshfs would probably do the trick as long as you make sure your VM IP is static [02:58] You could set up a cronjob with rsync and just a shared pool [02:59] I always use VMs with usermode NICs so... [02:59] Or if you want to go overkill, SMB server on the host :P [02:59] I think QEMU has a way to share a directory from the host to the guest though. [03:00] arraybolt3[m]: Maybe, but permissions are definitely going to be a hassle unless you have a fine-tuned set of options in QEMU [03:00] I dunno about pure QEMU, but virt-manager loves to `chown` the ISO files it works with :P [03:01] I think QEMU can share a dir as a FAT32 drive, which pretty much clobbers all permissions issues. [03:01] tsimonq2: Ouch, never had that happen before. Then again I usually use a user session in virt-manager. [03:02] arraybolt3[m]: You could run into some pretty noticeable performance issues once you get into package builds (if there's a stage with high IO), that's a risk worth looking into [03:03] That's a good point. It's just for file transfer though, not the main drive for the package build to happen on. [03:03] Just something so I can just "cp -R /dir /shareddir/" rather than "tar cfv package.tar dir && cat package.tar | nc -l 127.0.0.1 7897" then on VM "nc 127.0.0.1 7897 > package.tar". [03:05] sshfs :) [03:05] I'd remove QEMU as an abstraction entirely [03:05] I dunno, whatever ends up floating your boat, but I wouldn't rely on QEMU to handle this for you :) less layers that could break... [03:07] That's a good point. It's yet another thing to learn though. [03:10] As always ;) [03:11] Hey, though, eventually I'll have a bunch of it learned and it will get easy! [04:45] OK I think I'm finally managing to build liblxqt on the last two arches for updating the symbols. Sheesh. RISC-V's slowness is a bit much. [04:46] Err... right I have to start the python http server for this to work... [04:50] arraybolt3[m]: Append & at the end for it to run in the background, looks cool when you run sbuild in the same terminal ;P [04:51] +1, especially since I only have but a single terminal to work with in the emulator (well I could add tmux on top but in an emulator? ...) [04:55] * arraybolt3[m] finally got the i386 symbols, woohoo! [04:55] And RISC-V is running for real (I hope) this time. [05:34] Wow. If it's not one thing it's another. Now that the Python server is finally working, apt-cacher-ng is now throwing an absolute fit. [05:34] I think I'm just going to disable it entirely for now and just run the build without it so that this finally works so I can finish this tonight. [06:29] Finally. Alright, it got past dependency resolution and installation and has been actually compiling for a while now, so there's an end in sight! liblxqt is almost done! [18:43] Oh. My gosh. I have been shown git-gui by an LXQt team member. I am SO HAPPY. [18:45] Git-gui is actually part of git, nothing extra is needed. [18:50] [telegram] provided you have a suitable src:git that ships it on your system :P [18:51] [telegram] but yes git-gui can be useful [18:51] I had to install it with apt, but it works really well. It's like, rather than having to make commits as I go, now I can just go, and then turn it all into commits after the fact. [19:48] Learned a new trick for doing copyright files fast. `for i in $(ls); do vim $i; done` Boom, no more having to open every single file manually. Grep through to find hidden data, then :q out and it opens the next one automatically. [20:01] "Learned a new trick for doing..." <- Even more concise would be `for i in *` [20:01] Oh, that makes sense. [20:01] Similarly, `for i in *-packaging/` [20:02] "Wow. If it's not one thing it'..." <- Standing issue for me too, it doesn't Just DTRT :/ [20:04] Eh, got it working finally. But, I discovered that I misunderstood Andrew (again...) and now have to redo some work - thankfully Yao Wei noticed what was happening or at least saw I was a bit lost and helped me figure out some of the logic behind their decisions and how to easily fix things to make them match what they wanted. [20:04] Thus how I learned git gui :D [20:04] arraybolt3[m]: I'm very happy for that [20:04] arraybolt3[m]: Very nice :D [20:11] Anyway once I finally get my legs underneath me this should start to go faster, then maybe we can try and tackle LXQt 1.2... though do you think it's too late in Debian's cycle to try that if we manage 1.1 on time? [20:14] I hate when people tell me this, but it's one of the few cases I'll say it: one step at a time [20:14] Debian is slow because it's really important for them to do things right on all arches. There's a 7 day aging window regardless [20:15] So, the point at which LXQt 1.1 fully migrates, that's when we should consider doing 1.2 [20:15] Makes sense. [20:16] Grr... I hate dealing with image files. People can hide copyright information inside svg and even bitmap files. [20:16] Thank goodness for exiftool. [20:17] And Vim. Vim for SVG, exiftool for pretty much everything else. [20:18] That's also exactly why I wanted to do Ubuntu-first this time. This is a unique cycle in which Debian freezes before Ubuntu does. This means 23.04 will be incredibly stable, to the best of both project's abilities [20:18] I'll let you fill in the pieces on this one: what happens when Debian unfreezes and every maintainer gets to upload brand new upstream versions all at once, and Ubuntu autosync is turned on? That will be 23.10 [20:19] I think that's probably called an experimental nightmare + Britney meltdown. [20:19] So 23.04 is going to be very stable, and 23.10 is going to be one of those interesting computer-crashing artifacts if we're not careful, I think. [20:20] Simon Quigley: Uh... is CC-BY-**NC**-SA allowed in Debian? [20:20] Because lxqt-themes has some files under that license. [20:21] I think that needs DFSG-patched out. [20:22] arraybolt3[m]: Best answer to get you moving: check the Debian FTP Masters page on the license [20:22] Best answer to gain skills: Read the entire fulltext license and the entire DFSG, then compare and contrast the two [20:22] I've had to do the latter under pressure... not a fun scenario [20:24] > <@tsimonq2:linuxdelta.com> Best answer to get you moving: check the Debian FTP Masters page on the license [20:24] > Best answer to gain skills: Read the entire fulltext license and the entire DFSG, then compare and contrast the two [20:24] Took the first route since we're in a time crunch, will do the second when we get breathing room. So... now for the fun question, how do I patch stuff out of a package? [20:24] Is this just a matter of some quilt-foo, or...? [20:25] https://wiki.debian.org/DFSGLicenses#Creative_Commons_Attribution-NonCommercial-ShareAlike_.28CC_BY-NC-SA.29 [20:26] arraybolt3[m]: I had to re-ask this question the other day WRT Qt development... [20:26] If it's legal to distribute in source form but not binary form, it's a line in debian/rules [20:26] If it's illegal to distribute at all, debian/copyright has the ability to exclude files [20:26] (The problematic files are in lxqt-themes/wallpapers. I guess upstream must not have known to exiftool check stuff before putting it in their package.) [20:26] arraybolt3[m]: Time to file a bug ;) [20:27] It's illegal to distribute at all if they're being used for commercial use. And we are actively out of compliance right now for failing to add attribution (unless the EXIF data in the images counts as attribution). [20:27] (At least I think that's how it works.) [20:27] Sigh. Wow. Alright. That breaks lxqt-themes/themes/silver, too. Darn. [20:28] This is a great scenario for a "stranded on an island with a copy of the Debian archive" test heh [20:28] This is uncharted territory for me, but maybe you should consider putting that binary specifically into contrib or non-free [20:28] lxqt-themes? 😬 [20:28] I guess I could separate out just that file and put it in its own package. [20:28] One source package can have binaries in multiple suites [20:29] Huh. TIL! [20:29] They do this all the time for promoting binaries to Main when they don't want to support some of the Deb packages [20:30] Maybe I can ask you to do the heavy lifting on the "interfacing with Debian" side since I have *no clue* what I'm doing here and am not sure how well a newbie will be received saying "Hey guys there's a Big Problem right --> here <--, we need to fix it!". [20:31] When it comes to actual problem-solving and application of solutions, sure [20:31] I'm also 100% sure if you wrote a well-thought-out argument to the debian-legal mailing list, you'd get some great answers [20:31] Oh, that's a good point. Forgot about them. [20:31] Just make sure you re-read the copyright considerations page in debian-policy before doing so ;) [20:32] Sounds good. [20:32] Alright. Switching gears, I have the MR in Salsa marked as a draft to keep anyone from merging it in prematurely. I guess I'll finish building my copyright chart, then delve into this mess and see what happens. [20:33] Simon Quigley: Could you link to that page, i'm not sure which one you mean. [20:33] Sweet, feel free to CC tsimonq2@debian.org :) [20:34] arraybolt3[m]: https://www.debian.org/doc/debian-policy/ch-archive.html#copyright-considerations [20:34] Ah, in the policy manual. Thanks! [20:34] No worries :) [20:40] Another thing I should check is where LXQt got the problematic files from. Perhaps the notice in the EXIF data is a mistake and the website or wherever that they got the files from explains differently. I mean I find that unlikely, but it's possible, I guess. [20:41] Like maybe the guy's camera is set to automatically put that as the license (can cameras do that?), or maybe he marked them all as CC-BY-NC-SA and then changed his mind later and forgot to clean up the EXIF data. [20:44] Hah, there's a website link in the EXIF stuff. Nice. [20:45] Nope. It's purposeful, so says his website. Alright, back to where I was before. [21:03] Simon Quigley: Should I send a copy of this to you *first*, before sending it to the Debian Legal team? (I'm still writing it, actually I just started really writing something and just want to make sure I don't cause any trouble.) [21:03] arraybolt3[m]: Sure :) [21:04] lxqt-notificationd (1.1.0-0ubuntu1 to 1.2.0-0ubuntu1) [21:04] Migration status for lxqt-notificationd (1.1.0-0ubuntu1 to 1.2.0-0ubuntu1): Waiting for test results, another package or too young (no action required now - check later) [21:04] Issues preventing migration: [21:04] ...(truncated) [21:08] And from my estimation, not this Britney run :/ [21:09] "Guys, I think we hit the limitations of using SQLite" :P [21:10] laughs in CloudFlare R2 [21:10] The thing that's making Britney runs take forever is that it's constantly querying the database for current results and not just taking a single "point in time" snapshot to work with :/ [21:13] Oh... look what I just found. [21:13] Simon Quigley: I think the reason that these files made it into LXQt at all... is because *an LXQt developer took them.* [21:14] Simon Quigley: According to lxqt-themes/wallpapers/License, the Beam.png photo (the first one I noticed with this problem) is by stefonarch (one of the developers). The file specifically says the license is CC BY-SA 3.0. [21:15] If you go to the site that is linked in the EXIF data, it takes you to a blog of a person who seems to like Linux and does farming. [21:15] If you look at the exif data for the file, it tells you it's CC-BY-NC-SA-2.0, and it says the name of the owner is "stef binde". [21:15] sigh :/ so maybe he formed an agreement with the author? [21:15] And if you look at stefonarch's data on GitHub, it says he's an organic farmer. [21:16] hahahahahahahahahahaha... wait a minute... [21:16] Not "took them" as in repossessed... okay, wow [21:16] So he's on the LXQt team, it's his photo to license as he wishes. And while on his blog he licenses them as CC-BY-NC-SA, for LXQt, he licenses them as CC-BY-SA. [21:16] Like he has a camera and shot the photo. [21:16] That is extremely fortunate, because he's also still an active contributor :) [21:16] Very nice catch [21:17] Deep sigh of relief. [21:17] now the GPL vs LGPL stuff on the other hand... XD [21:17] So he did, in fact, just forget to change the EXIF data. [21:17] I'd file a bug in lxqt-themes and tag his GitHub user explicitly [21:17] 👍️ [21:18] Here's the thing... that's all good, he just needs to write that down somewhere :P [21:18] He did. lxqt-themes/wallpapers/License. [21:18] * arraybolt3[m] sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/1d4a5e24c3fc0bee988ae4df2c8cd1b1996bd708 [21:19] Very nice. Then no issue besides the EXIF data :) [21:19] Exactly. Welp, not exactly the hidden copyright info I was hoping to find, but I guess a win nonetheless! [21:19] * arraybolt3[m] proceeds to file a bug [21:40] Simon Quigley:... (full message at ) [21:41] * Simon Quigley:... (full message at ) [21:42] Ship it :) [21:43] Done https://github.com/lxqt/lxqt-themes/issues/91 [21:43] -ubot93:#lubuntu-devel- Issue 91 in lxqt/lxqt-themes "EXIF data in stefonarch's photos contains conflicting licensing information" [Open] [21:43] ER... crud botched the title, it's only some of the photos that have problems. [21:43] Blah, and you can't edit titles. [21:44] Oh nice, GitHub is having a bad day for editing the text body, too. Welp, guess it is what it is. [21:44] (Oh no wait here it goes, must be my glitchy Chrome.) [21:46] LOL and now I found the GitHub edit button for the title. 🤦 Why can't they put buttons where you look for them. [21:46] Or why can't I look for them in the places where they are. [21:47] Welcome to Microsoft. [21:47] Valid point :P [21:47] You should see the various admin centers in M365. [21:48] Just the idea of plural admin centers is a bit distressing... [21:48] $dayjob pays the bills at least. [21:52] I wish "enterprise software" meant "solid, well-built, unbreakable, and efficient to use" rather than "hacked together, unreliable, crashy, unstable, and exorbitantly expensive". [21:52] I guess that's what Ubuntu is trying to fix though. [21:53] Absolutely. [21:58] I have a tentative OpenQA instance set up, but I'll be stepping away for a bit [21:58] I won't have as much time this upcoming week as I usually would, so it's a matter of "what is the most urgent item on the list?" [21:59] Oh nice! [21:59] Ideally, we'd get OpenQA up and running so everyone can start adding tests to it [21:59] It's on the sandbox right now in its own container and I have nginx reverse proxying set up on the host [21:59] I just need to configure postgres and figure out where the packaged OpenQA configs hide :/ [22:00] Anyway... if you need me, feel free to ping [22:00] Otherwise, this week my activity will be limited to firefighting