#kisslinux

Unofficial KISS Linux community channel | https://kisscommunity.bvnf.space | post logs or else | song of the day https://yewtu.be/watch?v=S81bNIK4MaE
Earlier messages
<sad_plan>dilyn: do you still intend on using toybox? :p
<dilyn>I'm currently using it yes :v
<dilyn>need to update the old patch I have from e5ten to work on HEAD tho
<dilyn>I think around here is my last commit of a largely static system (llvm based but you know, inspiration) https://github.com/dilyn-corner/KISS-me/tree/0756695c277b88afd56dd0dfef070d98279121e6
<sad_plan>figured as much. so no toysh yet I suppose :p
<sad_plan>yeah, a fully static system is nice. Im there now, mostly, its just the pesky browser part that keeps bugging me
<dilyn>I refuse to use toysh on principle just to spite landley lmfao
<sad_plan>lol, so landley have actually finally implemented toysh now?
<dilyn>it's hard to find when I dropped static for my wyverkiss fork... I have a whole chroot that's been laying around for years tho
<dilyn>if he has I won't have noticed
<dilyn>but nobody apparently builds any pending toys anyways...
<sad_plan>hm, so project is kinda at a standstill?
<dilyn>i don't think so, it's just not obvious to me what parts they're taking seriously and currently working on
<sad_plan>hm, I see
<dilyn>AAAAAAAAAAAAAAAAAHHHHH ld: error: duplicate symbol: handle_table_remove
<dilyn>*this* is why you don't use static libraries smdh
<sad_plan>thats a new one for me. but sure, static linking can be a real bitch at times
<sad_plan>luckily, I use oasis as my core, so dont have to mess around with non-reproducable builds. atleast not for a lareger part of my system :D
<dilyn>:P
<dilyn>idk how the problem is happening *now*. someone fucked up a meson.build somewhere and decided to link something somewhere...
<sad_plan>just use ag and youll find the cuplrit in a jiffy
<dilyn>well the culprit is actually muon only building libdrm with static libraries...
<dilyn>oh cus that's its default lmfaooo
<sad_plan>then the issue is local, because I do use muon to build libdrm, with static libraries only
<sad_plan>yes, muon seems to be more picky like that
<sad_plan>ive had several packages all of a sudden lack one or the other because I didnt pay attention
<dilyn>are you  building radeonsi?
<sad_plan>no, not building any gpu specific ones actually
<sad_plan>I use tinyx atm, so theres really no benefit
<dilyn>then that would be why you haven't seen it ;)
<dilyn>add -Dgallium-drivers=radeonsi for your mesa build and you'll probably hit it...
<sad_plan>nope, libdrm still builds with no issues if I enabled radeon C:
<sad_plan>mesa is another story.
<sad_plan>havent been able to build mesa with muon to begin with really
<dilyn>oh, if you reset to this commit and revert it you can get a close approx to a static system -> https://github.com/dilyn-corner/KISS-me/commit/4dc67cc7f374b9d42b3a80ccc46e789d7290552c
<dilyn>no libdrm builds fine it's a link issue with mesa; if you enable radeonsi in the mesa build it'll complain about a duplicate symbol in libdrm
<sad_plan>I only build swrast because it was the only one I could build without requiring llvm, but if I try with muon, itll complain regardless. which is somewhat ironic iirc, because swrast supposedly requires llvm
<dilyn>largely, mesa and libdrm can't be static anyways :(
<sad_plan>Ive built only static libs for libdrm for a while now, and no issues. but probably perhaps because I use swrat and not radeonsi
<sad_plan>driver that is, my laptop uses amdgpu/radeon
<sad_plan>then checkout your repo there, and go from there, so you can enjoy a fully static system :D
<dilyn>it was so fsck'd :v
<midfavila>i wonder if nouveau can be compiled without mesa
<midfavila>for just 2d
<midfavila>since i dont think nouveau can do 3d anyway can it?
<dilyn>tthis might be the last commit that was static and "functional" d62f00779473fd12112da32f796b19d0b0bb79fd
<sad_plan>stop lying dilyn. it was great
<midfavila>no nouveau does need mesa
<midfavila>a shame
<dilyn>it silently fell apart after a while lmfao
Later messages