[00:00] <arraybolt3> the other day I learned there actually was an X10 at some point (or something older than X11)
[00:01] <arraybolt3> seriously though, I like X11 pretty well and there are several DEs out there that may never migrate past it (IceWM for instance). Hopefully someone will pick up X.Org once Red Hat drops it.
[00:15] <arraybolt3> Time to install sbuild into my RISC-V VM and then build everything needed to get libfm-qt14's symbols :-) :-/
[00:16]  * arraybolt3 signs the petition to get Canonical to buy a room full of RISC-V hardware builders to accelerate build times
[00:39] <tsimonq2> hahahahaha
[00:39] <tsimonq2> arraybolt3: so fun fact for you re: RISC-V that I learned
[00:40] <tsimonq2> a) ~ubuntu-dev can ask for that to be enabled for PPAs, might be core dev, idk, I can ask for it on a ~lubuntu-dev PPA once you're back
[00:40] <tsimonq2> b) they're working diligently on the whole "moar builders" thing
[00:41] <arraybolt3> Nice!
[01:31] <teward> i'm not reversing Simon's decision
[01:32] <teward> but I am stepping on him 'cause he's not team lead and can't make single-handed decisions
[01:32] <teward> *literally sits on Simon and squishes him*
[01:32] <arraybolt3> teward: why on earth does your nick start with an @ sign from my perspective
[01:32] <teward> tsimonq2: they're very picky about RISC-V though, it requires Core Dev access, anyone without core dev might not have access, Teams included
[01:32] <teward> arraybolt3: because i'm chanopped
[01:32] <arraybolt3> ah
[01:33] <teward> because as soon as Canonical pokes a few DNS records I have to alter the topics
[01:33] <teward> then i deop :p
[01:33] <teward> tsimonq2: i'm not sure lubuntu-dev qualifies, I'd have to ask internally via my contacts @ Canonical
[01:33] <teward> (for the PPA)
[01:33] <teward> anywho, i need sleep so.
[01:33] <teward> *offline*
[01:36] <tsimonq2> teward: Risk/reward etc. etc. I took the risk and I'm willing to pay for it :)
[01:36]  * tsimonq2 sends teward a gallon of coffee
[01:36] <arraybolt3> Well tell Canonical that people down here need MOAR RISC-V POWA
[01:36] <tsimonq2> LMFAO
[01:36] <arraybolt3> Either that or else they need to buy us some servers
[01:36]  * arraybolt3 pretends like I can tell Mark what to do
[01:37] <arraybolt3> at any rate, libfm-qt for RISC-V now building.
[01:38] <arraybolt3> er, almost now building, I forgot to run uscan
[01:50] <arraybolt3> oh my word I hate apt-cacher-ng
[01:52] <arraybolt3> once again it worked for a while before suddenly and catastrophically failing and resulting in a failed build
[01:52] <arraybolt3> it seems like back in the day it mostly worked but needed a restart every so often to get it working again. But on Jammy it just dies without fail.
[01:53] <arraybolt3> er, with fail I guess XD
[01:54] <arraybolt3> which reminds me, I should get my LXD container up-to-date
[01:54] <arraybolt3> ?! My LXC container has been running without an apt update for the last six months
[01:54] <arraybolt3> Me thinks I'd be better off deleting it and starting from scratch...
[01:54] <arraybolt3> Didn't realize those turned on automatically upon bootup.
[02:00] <arraybolt3> tsimonq2: How do I create an LXD container with the development release again?
[02:01] <arraybolt3> I can look up how to make an LXD container but specifying 24.04 as the version failed :P
[02:01] <arraybolt3> maybe I just start with 23.10 and upgrade?
 I think you can specify devel.
 https://images.linuxcontainers.org/
 Looks like there is a noble image.
[02:21] <arraybolt3> ah that's a different image server than the default one, thanks
[02:21] <arraybolt3> hmm, I'm not sure if I want to use linuxcontainers.org though since Canonical kinda took control of LXD/LXC and now linuxcontainers.org is running their own separate fork, Incus.
[02:22] <arraybolt3> specifying "devel" worked, thanks!
[02:23] <arraybolt3> ah, lxc is still linuxcontainers, lxd turned into Incus there and remains lxd in Canonical's realm
[02:33] <arraybolt3> aaaaand... ubuntu:devel gave me a Mantic container.
[02:33]  * arraybolt3 does a do-release-upgrade
[02:43] <arraybolt3> https://termbin.com/1cew somehow lxqt-menu-data is being recognized as a 64-bit only package and resulting in libfm-qt being unable to build on armhf
[02:44] <arraybolt3> https://launchpad.net/~arraybolt3/+archive/ubuntu/lxqt-dev-noble/+build/26965532
[02:45]  * arraybolt3 wonders if this is an upstream bug? I mean the package is reconigzed as being for all architectures
 Uhhhh it's an arch-all package dude :)
[02:52] <arraybolt3> yeah I know
[02:52] <arraybolt3> but CMake has other ideas
 le sigh
 k I'll iterate on it after the binary acceptance, I asked RAOF in passing if he could help
[02:53] <arraybolt3> # check that the installed version has the same 32/64bit-ness as the one which is currently searching:
[02:53] <arraybolt3> in one of the installed files from lxqt-menu-data
[02:53] <arraybolt3> why
[02:53] <arraybolt3> bet it's a bug in the write_basic_package_version_file call
[02:54] <arraybolt3> er, in how LXQt is calling it I mean
[02:54] <arraybolt3> yep, they forgot to specify "ARCH_INDEPENDENT"
[02:54] <arraybolt3> so *technically* this is an arch: any package XD though really we can patch it into an arch: all package
[02:55] <arraybolt3> so I'mma try specifying that and if it works, then another upstream LXQt bug will follow shortly thereafter.
 https://github.com/lxqt/lxqt-menu-data/issues/17#issuecomment-1794728518
[12:41] -ubottu:#lubuntu-devel- Issue 17 in lxqt/lxqt-menu-data "cmake file provided doesn't allows to satisfy requirement of lxqt-menu-data" [Open]
 OH
 By the way
[16:35] <arraybolt3> yeah?
 vorlon acked the current Calamares menu we're working on, because it doesn't preseed them on the ISO, it preseeds them on the installed system, so I was right about it bring not applicable
[16:35] <arraybolt3> \o/
 That's my general understanding after the conversation, I could be missing some finer points filled in by sleep ;)
 So on that front now, a few things...
 I think it FTBFS on !amd64, which boooo
 Also, when you use the new standalone script to pre-seed the snaps in the chroot, it regresses those snaps to having those long startup times
 That being said, the snapd team told me it's the compression algorithm
[16:39] <arraybolt3> to be clear, doing things this way results in the snap always launching slowly, or only the first time?
 Only the first time, like Firefox
[16:39] <arraybolt3> (I'm remembering a thing with Firefox where it had a delay on first boot before it showed up but then that only happened once and only on the ISO)
[16:39] <arraybolt3> ah ok
[16:39] <arraybolt3> I *think* that's livable?
 Basically, pre-seeding a snap is literally just downloading its .snap and .assert file, putting them in the correct directory, then hand-crafting a YAML file that snapd reads on first boot
 On first boot, snapd does manually install it, which takes some time to run in the background
 Changing the compression algorithm to be consistent with the existing approach would be ideal, but the snapd team told me there's a resource tradeoff
 So we should closely compare and contrast those two compression levels and determine what is best for *our* user base
 If you look at the cala settings source on Gitea, I have all that implemented already :)
[16:42] <arraybolt3> hah nice
 Which btw - a second set of eyes eventually wouldn't hurt, 'cause I'd like to make that QML view "transparent" to match the others
[16:43] <arraybolt3> kk, I'm relatively handy with QML.
[16:43] <arraybolt3> (Never did get around to fighting with lxqt-menu-data last night, got too tired and had work to do elsewhere, so I'm fighting with it this morning.)
 No worries, I did see your followup on GH tho, thanks for that :)
[16:44] <arraybolt3> Sure thing
[16:46] <arraybolt3> sheesh, am I the only one who's Downloads folder is a catastrophe :P I've got old source code, fonts, programs that need to be run through Wine, logo design, wallpapers, operating systems, deb packages... all mashed together
 My entire ~ is about 75 GB of random assorted mess
[16:48] <arraybolt3> I try to keep my stuff relatively well-organized but sometimes it gets messy
[16:50] <arraybolt3> Mine is at 257G...
[16:50] <arraybolt3> but I have a lot of VMs
 ah right
 That'll do er
 @Roberalz I heard some feedback that we have some very good translations coverage in all parts of the UI, so let me pass on those congratulations to the Global Team for helping drive translations :))
 @Roberalz If you notice anything that generally isn't translated into any language, let me know, let's fix it :)
 I have to look, with the last fix you made everything was solved.  These days I have been translating into Spanish, Basque and Galician. (re @tsimonq2: @Roberalz If you notice anything that generally isn't translated into any language, let me know, let's fix it :))
 I met a group of Latvians who run Lubuntu too, and they say the translations are great :D
 Keep me posted :)
 Ok
[16:57] <arraybolt3> I can help translate things into English!
[16:57]  * arraybolt3 runs
[16:57] <arraybolt3> actually probably not even that, since English is my only language :P
 "I'm sorry but I can't read this, I only read FREEDOM English, not British English"
 /me runs
[16:58] <arraybolt3> lol
[16:58] <arraybolt3> ok, so technically I know enough to translate between British English and Mangled... er... American English.
 (I had some Europeans just dying laughing with how jokingly over-American I was :D)
[16:58] <arraybolt3> (seriously though, why couldn't we just have one form of English, why do we need all the alternate spellings like colour vs. color)
 "Why would I call them French Fries, they're Freedom Fries" lmaoo
 meh it's cultural, accents make spelling different maybe
[18:07] <arraybolt3> Alright, time to see if this works.
[18:09] <arraybolt3> grr... it's grabbing the lxqt-menu-data that isn't in the PPA!
[18:10] <arraybolt3> I think
[18:11] <arraybolt3> alright, version number bump
[18:11] <arraybolt3> and now we wait for the PPA to build AGAIN
[22:04] <arraybolt3> tsimonq2 and whoever else is doing packaging on lxqt-menu-data: Heads up, I just pushed a fix for https://github.com/lxqt/lxqt-menu-data/issues/17 into the lxqt-menu-data packaging in Git. Please make sure to do a `git pull` before working on that package again so that you get the fix in.
[22:04] -ubottu:#lubuntu-devel- Issue 17 in lxqt/lxqt-menu-data "cmake file provided doesn't allows to satisfy requirement of lxqt-menu-data" [Open]
[22:04] <arraybolt3> (and yes, I did verify that the fix works first)