[00:18] Man, I just have to say, I'm really thankful that you taught me how to use git rebase -i. That command has saved my bacon so many times during this process. [00:34] It just saved mine too, fwiw ;) [00:34] Worth noting once: I had to patch lxqt-build-tools because header files moved quite a bit in the Kinetic glib2.0, apparently [00:35] (So, reverting a patch that fixed it in Kinetic+ but doesn't work in <= Jammy) [00:35] Oy, is that something I'll need to keep in mind for Debian? [00:36] Nope, not unless you intend on backporting to Debian Stable ;) ) [00:36] * Nope, not unless you intend on backporting to Debian Stable ;) [00:36] Oh good grief no. [00:36] Me and you both XD [00:36] Anyway... [00:37] Lunar is chugging along pretty well. I just confirmed the first two levels have zero symbols issues, and should work as-is [00:37] I'll be working on the next level "all at once," so standby and we'll get to see those symbols too. :) [00:37] Alrighty! [00:37] * arraybolt3[m] audits copyright file for lximage-qt [01:04] arraybolt3: Good learning tool for you, what do you make of this? W: qtxdg-tools: wrong-name-for-upstream-changelog [usr/share/doc/qtxdg-tools/CHANGELOG] [01:18] [telegram] fun fact [01:18] [telegram] backports went kersplat 'screw you' with the lxqt stack in staging [01:23] no it didn't [01:24] I manually cleared out the PPA [01:24] unless you're saying systems who still have backports staging enabled [01:24] when the announcement EXPLICITLY says not to do that :P [01:26] Brief status update: stage 3 is now in the choo choo [01:26] If any part of the stack will need manual intervention, this part will [01:27] As for Jammy... turns out I didn't get that patch right. For this third upload, I'll be doing some manual iteration, but it will likely be shortly after I throw LXQt 1.2 at Lunar [01:27] -- Found gio-unix-2.0, version 2.72.1... (full message at ) [01:27] that's a direct bug with lxqt-build-tools :P [01:28] anyway, time to get Twitter hyped and /me breaks for 5-10 [01:48] * arraybolt3[m] has returned [01:49] Perfect, just about to actually take my break :P [01:50] "arraybolt3: Good learning tool..." <- Odd, I'm not sure what to make of that actually. Isn't the build process supposed to zip the changelog and install it? Is it just a wrong filename in upstream? [01:52] arraybolt3[m]: *Supposed to*, yes :) [01:53] Hmm... guess that's something I'll look deeper into in the near future. [01:57] arraybolt3: One of the tasks on my list, for the next day or two, would be to sort through *ahem* The List [01:59] I mention this because it would be good to update The List if anyone else has items, before I actually categorize it [01:59] I've been trying to keep it somewhat in shape based on what I know. https://notes.lubuntu.me/huOk59_iRSaAMZDl_my8bw?view [01:59] Thank you very much for that :) [02:02] Anyway, I generally move stuff around based on what I see going on, or if it's only something I'm doing I might move it, but feel free to change/overhaul/delete and create it anew/etc. the whole thing. I'll avoid messing up anything you've put in there as "this is what we're doing now". [02:03] Sounds good! Already looks very well-organized, so I'll also hunt through Phab at some point [02:13] OK, /me needs food, also $PERSONAL_LIFE has entered the room and pulled arraybolt3 out of the chat for a bit, but I think I'll be right back. [02:25] tsimonq2 no i'm talking about the FTBFS notifications that went over email (RE: backports-staging) [02:31] teward: Oh, you mean the one I'm actively working on? :P [02:31] https://launchpadlibrarian.net/634031038/buildlog_ubuntu-jammy-armhf.libqtxdg_3.10.0-0ubuntu1~ppa1_BUILDING.txt.gz this one that asploded at 8:17PM UTC-5 (my time) [02:31] so if you're working on that, then yes [02:31] I think this lxqt-build-tools update will do it [02:31] yeah [02:31] that [02:32] in the meantime, seems as if all arches are now built and published for stage 3, for Lunar [02:33] er, and by stage 3, I meant stage 2, because it starts with 0 lol >_< [03:29] FINALLY, libqtxdg is building in Backports Staging 🎉 [03:52] Alright, copyright file audit complete. One more down! [04:03] * arraybolt3[m] sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/73901b41ff994124dedee14e9548d944418e7aeb [04:03] There is no cmake-data build dependency in the file. One assumes this is a dependency of a dependency. [04:03] * arraybolt3[m] tries using Experimental as an additional repo and using the aptitude-based resolver [04:06] Sigh. Nevermind, looks like I see it. lxqt-build-tools not being merged into Debian yet is now messing me up. That means I need a local PPA setup... and that is non-trivial at this point in time. [04:06] Right about now is when I wish Debian used Launchpad. [04:12] > <@arraybolt3:matrix.org> ```... (full message at ) [04:12] "Sigh. Nevermind, looks like..." <- Or... OR [04:12] https://wiki.ubuntu.com/SimpleSbuild [04:12] "Local packages" [04:29] As I go to bed here, a few items to report: [04:29] - Per https://github.com/lxqt/lxqt/wiki/Building-from-source#generalbuild-order we're up to stage III in both Backports Staging and the choo choo train, except libfm-qt failed hard on symbols. I'll be addressing that first thing tomorrow. [04:29] - The Lubuntu droplet has been re-created, so if anything is now down, I blame teward for giving me the green light ;P no, but seriously, we'll have OpenQA up by tomorrow EOD hopefully, and I'm thinking we can start the QA Team on configs, assuming they can be easily-exported. More investigation work tomorrow [04:30] https://bileto.ubuntu.com/#/ticket/4951 <-- I'll manually kick the Bileto end of that, to get it to pay attention to all the new, shiny packages [04:30] https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4951/+packages is the relevant PPA, https://launchpad.net/~lubuntu-dev/+archive/ubuntu/backports-staging/+packages of course is Backports Staging [04:30] And on that note, o/ [04:35] ""Local packages"" <- That's what I meant by a local PPA setup. [04:36] "And on that note, o/" <- 👋 [04:36] "Sigh. Nevermind, looks like..." <- I actually think I might be wrong here, /me looks [04:37] Yeah, I'm wrong, 0.11.0 is in the repos. So... throws hands up in air [04:37] Hopefully it's something b0rked in Debian's guts and it will fix itself eventually. [14:23] [telegram] arraybolt3 what were you trying to build [14:23] [telegram] i have an unstable and experimental sbuild chroot i can toss at testinf [17:06] ISO failure today still related to snaps... so still waiting [17:09] [telegram] *blames simon for the failures* [17:19] @teward001: I was trying to build LXImage-Qt, but with my own updates applied. I was building it in a sid chroot. [17:20] [telegram] ah [17:20] [telegram] then we wait on Debian [17:20] [telegram] 'cause they fubar'd [17:20] [telegram] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023787 [17:20] -ubot93:#lubuntu-devel- Debian bug 1023787 in release.debian.org "transition: liblxqt" [Normal, Open] [17:21] * arraybolt3[m] shoves sbuild back into action [17:21] [telegram] there's some chaos there in Debian land they have to fix probably before things'll build cleanly again [17:21] And it works this time! \o/ [17:22] Nice when bugs disappear overnight, literally. [17:22] [telegram] heh [17:22] I mean i guess I could get Lintian output without doing a full source code build but this is more thorough I think. [17:23] [telegram] actually reading that link [17:23] [telegram] @tsimonq2 you dun goofed which led to the rest of the LXQt Debian team fubaring things [17:23] [telegram] *smacks Simon* [17:24] @teward001: I thought it was that Simon had one idea of how to package and Andrew had another idea, thus leading to the same situation as when you try to follow two sets of instructions to fix the same problem at the same time. [17:25] [telegram] potentially, but it is made out that it was both Simon and Andrew's fault (re @lubuntu_bot: (irc) @teward001: I thought it was that Simon had one idea of how to package and Andrew had another idea, thus leading to the same situation as when you try to follow two sets of instructions to fix the same problem at the same time.) [17:25] [telegram] because SImon said after June he'd upload the new stack [17:25] [telegram] and then Andrew uploaded new liblxqt and lxqt-session but not the rest of the stack [17:25] [telegram] so it's a collision of BS on all sides. [17:26] @teward001: Well the fact that Andrew started literally undoing some of our work didn't help (*points to libfm-qt from last cycle*) [17:26] [telegram] *yawns* [17:26] [telegram] keep in mind Debian vs. Ubuntu cycles are different so there is that [17:26] [telegram] but i get to yell at Simon regardless [17:27] We only ever uploaded stuff to Experimental, it *should* have stayed there (or at worst gotten shoved to a different branch) until the job was done, IMO. [17:28] But whatever. At this point what really matters is that it gets fixed somehow, blame isn't a team mindset. (Frustration however...) [17:28] [telegram] Simon is blamed for everything so 😔 [17:29] * arraybolt3 shoves @teward001 into a swimming-pool-sized milkshake [17:30] [telegram] This is base firmly in precedent here :P (re @teward001: Simon is blamed for everything so :P) [17:35] [telegram] though it's quite accurate to blame him in many cases xD (re @RikMills: This is based firmly in precedent here :P) [17:35] And to be fair, --> I, arraybolt3 <-- did a significant amount of the mangling things. I get that debian/experimental was supposed to be a safety net, but some of the mistakes I made were truly horrible, as I am now learning firsthand as I fix them. [17:35] [telegram] matterbridge being fubar earlier was because i noticed i have a failing drive or two in my RAID array [17:36] [telegram] hehe, welcome to the hell i instituted with NGINX packaging - (re @lubuntu_bot: (irc) And to be fair, --> I, arraybolt3 <-- did a significant amount of the mangling things. I get that debian/experimental was supposed to be a safety net, but some of the mistakes I made were truly horrible, as I am now learning firsthand as I fix them.) [17:36] [telegram] when we first migrate a package out of nginx source tarball for dynamic or third party modules, we do so in Experimental [17:36] [telegram] make sure it works [17:36] [telegram] then make the change in Unstable [17:36] [telegram] it slows testing, etc. down but makes sure we don't torch testing [17:36] :P Well, I have things I need to do in $PERSONAL_LIFE, but I have another MR in Debian, so we're making progress! [17:36] [telegram] heheheh [17:37] [telegram] as for 'progress' I am still moving and taking over packages that pique my interest xD [17:37] [telegram] pastebinit (thank you krytarik for contribs!) from Simon, and rlwrap and a few others [17:37] That's what good MOTU's and higher do, right? [17:37] [telegram] I'm ITSing some obscure but useful stuff [17:37] [telegram] i mean in Debian not Ubuntu (re @lubuntu_bot: (irc) That's what good MOTU's and higher do, right?) [17:37] * arraybolt3 goes afk, be back soon-ish [17:37] [telegram] technically yes, but MOTU/Triage for Ubuntu -> Debian ends once you upstream the Debian bug or send to actual upstream typically [17:38] [telegram] *shoves arraybolt3 into the slime pit* [18:02] [telegram] As part of my role, I have to personally take on some risk with conviction. It's only "par for the course" that I'm blamed when things go wrong (re @teward001: though it's quite accurate to blame him in many cases xD) [18:02] [telegram] I take it on voluntarily instead of letting it blindside me [18:03] [telegram] At the end of the day, my key signed your uploads. My name goes on the release announcement. I have to be able to answer for some of this (re @lubuntu_bot: (irc) And to be fair, --> I, arraybolt3 <-- did a significant amount of the mangling things. I get that debian/experimental was supposed to be a safety net, but some of the mistakes I made were truly horrible, as I am now learning firsthand as I fix them.) [18:05] [telegram] Ditto me and Kubuntu [18:06] [telegram] *burps* [18:06] [telegram] ahhhh... lunch. [18:08] [telegram] evening beer o'clock here I think [18:20] [telegram] Just got back from the gym 😈 [18:21] [telegram] good you can pay for my coffee now. *usurps $20 of your money for his coffee* (re @tsimonq2: Just got back from the gym 😈) [18:22] hah [18:34] * genii sips [18:35] Meanwhile, my younger brother has a literal box full of energy drinks that I'll be taking from XD [18:35] He estimates about 200 in there [18:38] [telegram] *hisses and rushes with a spear until the caffeine is shared* (re @lubuntu_bot: (irc) sips) [18:52] hehe [18:53] * genii slides teward[m] a fresh mug of the good stuff [21:49] Okay, finally heh... I'll be addressing symbols in Jammy libfm-qt, then on to continuing the stack [22:08] Looks like that's passing on amd64, waiting on builders to verify that non-standard arches are also working [22:14] obconf-qt and libsysstat are the two I'm skipping right now [22:15] I have a feeling Britney won't like that, but I guess we'll have to see :P [22:25] Simon Quigley: When you get a minute, can you give me a quick refresher course on symbols? I get the feeling it will probably come time to manage them sooner rather than later. [22:26] (Speaking of which... I need to set up RISC-V and i386 environments. orchestra plays epic battle music) [22:27] [telegram] It shouldn't be too grumpy about obconf (re @lubuntu_bot: (irc) obconf-qt and libsysstat are the two I'm skipping right now) [22:29] (Actually i386 shouldn't be too much of a bear, since I can just do "mk-sbuild --target i386 sid" and it should just work, I believe.) [22:32] ``` [22:32] chroot:sid-amd64-i386 [22:32] ``` [22:32] Why sbuild. Just why. [22:38] I mean I get why (i386 running on amd64), but that's just... confusing/ [22:38] s///./ [22:45] ...and now it's downloading amd64 libraries when I try to build with it. Lovely. [22:46] Alright, so I guess I am going to be setting up an i386 VM after all! [22:57] "Simon Quigley: When you get a..." <- Symbols exist to keep track of all the functions a specific `.so` file exposes, to identify non-backwards-compatible changes to what it exposes [22:57] No I know what they do, I don't remember how to update them. [22:57] > <@arraybolt3:matrix.org> ```... (full message at ) [22:57] There was some pkgkde-symbolshelper thingy involved, and some other tool I think, but memory does not serve me well here. [22:58] arraybolt3[m]: You have two options, essentially: [22:58] - Apply the diff by hand, from all architectures, cross-referencing the various architectures in symbols. [22:58] - `pkgkde-symbolshelper batchpatch -v UPSTREAM_VERSION /path/to/logs/for/all/arches/*.txt` [22:58] Oh right, that makes sense. And what's the man page that has info about the file format? [22:59] * arraybolt3[m] has to go afk again, I am so sorry [23:03] arraybolt3[m]: Not sure what you're referring to, you can just feed it a raw build log [23:03] > * <@arraybolt3:matrix.org> has to go afk again, I am so sorry [23:03] No worries, I'm just cranking this out :) [23:08] Holy publishing speed, Batman [23:22] Yeah, I'm guessing the Launchpad publisher is going to be slow given the amount of builds in the queue and such. I can see qtermwidget failed, likely due to symbols, just not why heh [23:37] "Not sure what you're referring..." <- Right but last time I had to do some symbol modding by hand, and I remember there was something that had docs about the file format. [23:37] (Stuff for how to exclude an arch from a certain symbol and the like. [23:37] ) [23:37] arraybolt3[m]: Oh, symbols file format [23:37] Yeah, that depends on the case [23:37] Generally speaking, if you look at a package like libfm-qt, that's a great example [23:38] All symbols themselves start the line with a space, then any filters in parentheses, followed by @Base, followed by a space, then the upstream version number [23:41] ...but I don't remember the filters format :P [23:43] Found the docs! https://manpages.debian.org/bullseye/dpkg-dev/deb-src-symbols.5.en.html [23:50] Sorry, without a specific example it can be hard to say [23:50] I'm glad you found the right docs :) [23:51] I: lxqt-about: desktop-entry-lacks-keywords-entry [usr/share/applications/lxqt-about.desktop] - should be dealt with upstream, Eventually [23:52] I: lximage-qt: desktop-entry-lacks-keywords-entry [usr/share/applications/lximage-qt.desktop] ditto [23:54] "Yeah, I'm guessing the Launchpad..." <- I guessed it was likely due to symbols, I was wrong [23:54] It was actually just Launchpad being flaky [23:54] Interesting :) [23:55] Alright, time to see how this laptop handles RISC-V64. My desktop was painfully slow with it, but this should be faster.