phoebos changed the topic of #kisslinux to: Unofficial KISS Linux community channel | https://kisscommunity.bvnf.space | post logs or else | song of the day https://yewtu.be/watch?v=S81bNIK4MaE
dilyn has quit [Quit: Client closed]
phinxy has quit [Ping timeout: 265 seconds]
dilyn has joined #kisslinux
<midfavila> whoa hey im old now
<midfavila> time for that hip replacement
<dilyn> imagine growing up in this channel
<sewn> happy birthday midfavila
<sewn> dilyn: me
<sewn> that's me
<sewn> I'm gonna be growing up and dying here
<dilyn> bit rude innit
<dilyn> unzip ain't in extra/ >=| and not marked as a dep
<phoebos> busybox has an unzip :(
fultilt has quit [Quit: Leaving]
phinxy has joined #kisslinux
<midfavila> sewn once ur here ur here forever
<midfavila> even dilyn has recognised that
<midfavila> he can't live without us
<midfavila> :3
<sewn> i dont know how to feel about that last statement
<sewn> is anyone interested in seeing muon be the default meson implementation
<sewn> converting kiss-community to use muon without meson seems like a hassle becuase in community its all meson
<midfavila> i would 100% push for muon
<midfavila> but it doesn't need to be like
<midfavila> a 100% perfect immediate switch-over
<midfavila> can just say that new commits for build scripts should use muon 's all
<sewn> why shouldnt it be a immediate switch-over
<sewn> why have both
<midfavila> because that's a lot of effort all at once
<sewn> unless za people are ok with zat obviously
<midfavila> better to just change over as updates are done
<midfavila> i mean if ur special interest is rewriting meson commands to use muon 100% go for it, all the power to you, but like
<midfavila> my hobby is micromanaging my kiss repo and not even i care enough to do that all at once
<midfavila> shit that reminds me i need to check on gcc from yesterday
<midfavila> now *that* would be a birthday gift, if it actually built
<midfavila> almost did
<midfavila> for some reason it can't find zlib
<sewn> if you ever need a system to build stuff quickly i can volunteer lol
<dilyn> phoebos: busybox shmizzybox!
<midfavila> sewn its less speed and more gcc being a pain in my ass
<sewn> just making sur
<midfavila> the rockpro64 is honestly an okay build machine
<midfavila> i mean it doesnt hold a candle to my workstation
<midfavila> but it's respectable
<midfavila> man shortbread with jam slaps
<sewn> never eating gourmet spicy shin ramyun again
riteo has joined #kisslinux
<dilyn> why did mesa make us do all this stupid shit with python packages. and wtf is gpep. Yet Another PIP?
<dilyn> and wtf
<dilyn> ModuleNotFoundError: No module named 'setuptools.command.bdist_wheel'
<midfavila> and that's why i don't use python
<dilyn> well I would like to use mesa for now before committing to velox :v
<midfavila> use tinyx
<midfavila> :3
<midfavila> im pretty sure it doesnt need mesa
<dilyn> never
<dilyn> ModuleNotFoundError: No module named 'more_itertools'
<dilyn> *where the fuck are my dependencies*
<midfavila> those are optional
<midfavila> install from pip before pip is deprecated
<dilyn> absolutely NOT
<midfavila> nup you gotta
<midfavila> :3c
<midfavila> you *will* fight with pip to get basic shit working
<midfavila> you *will* have twenty different package managers
<midfavila> you will *not* have a simple and cohesive computing experience
<midfavila> you *will* buy new hardware every six months to continue to use chrome
<dilyn> i've specifically packaged incus so that for scenarios where that is true I can create an environment I don't give a shit about to do it in
* midfavila snickers
<sewn> the chocolate bar?
<dilyn> kekw
<dilyn> i'm at a mile of loss rn. do I have to package moreitertools? am I being trolled by repo/ rn?
<sewn> whatru on about
fultilt has joined #kisslinux
<dilyn> wrangling the python dependencies for mesa. python-yaml seems to require python-more-itertools but that isn't packaged. so how are people building mesa
<dilyn> was mid being frfr when he said pip > = |
<midfavila> (guys he doesn't know i'm fucking him :3c)
<midfavila> (i've brainbroken dilyn)
<midfavila> no python is just garbo
<dilyn> don't fuck me
<midfavila> fucking with
<midfavila> god
<midfavila> i need more coffee
* midfavila facedesks
<midfavila> dying now
<sewn> so youre saying you wouldn't?
<midfavila> im only interested in computers
<midfavila> sorry bby
<sewn> says the goat
<midfavila> i need wool so i dont die when its -56C outside and the bus system fails and i have to stand there for hours on end
<sewn> dilyn: are you using mesa from repo/
<sewn> it jut works
<midfavila> It Just Works:tm:
<midfavila> lmao oh my god
<midfavila> i was joking
<midfavila> but you *DO* need to pip it
<midfavila> holy shit that's incredible LMFAO
<dilyn> I'm basically using all of extra from repo/
<dilyn> no you can package more-itertools
<dilyn> i just did, now python-yaml builds just fine
<midfavila> i mean yeah you can
<midfavila> you don't *need* need to
<dilyn> the day I use pip is the day you put me down because I'm obviously an imposter
<midfavila> gonna eat ur brain then
<midfavila> absorb your knowledge
<midfavila> or the imposter's
<midfavila> good enough im sure
<riteo> oof yeah LLVM is required for AMDGPU afaik
<dilyn> it is
<dilyn> but I'm using llvm instead of gcc ;)
<dilyn> I guess mesa uses the .pc which I don't have
<riteo> oof
<riteo> packageconfig my hated
<riteo> is packageconfig seriously the best solution we found for dependency discovery
<riteo> like, why is this problem so hard
<midfavila> portability in general is hard
<midfavila> it's why i program to spec and throw everything else in the garbage
<riteo> I mean isn't posix meant to make portability easy
<riteo> it's in the name
<dilyn> i mean how else would you discover the insane bullshit some folx do...
<dilyn> okay, my issue was a pc issue. now I think I'm hitting a muon issue :v
<riteo> uhhh isn't it supposed to be included from somewhere
<riteo> and isn't that somewhere standard
<dilyn> it can be as standard as we want but some people still use lib lib32 lib64 libx32 and libexec
<dilyn> so how do you decide if it's in /usr/lib or /usr/lib/<triplet> or /usr/lib64/<triplet>?
<riteo> I see
<dilyn> and by "some people" I do mean ubuntu :V :V :V
<riteo> lmao
<riteo> is everything still not linked together?
<riteo> like, what's the point?
<dilyn> they didn't usr-merge until recently and when they did they had to put files in / indicating that usr had been merged lmfao
<riteo> why
<dilyn> a billion reasons
<dilyn> you can't break twenty years of practice willy nilly, as it turns out...
<riteo> isn't the whole point of linking everything together to make things as seamless and compatible as possible
<dilyn> jesus I just checked my /usr/sbin and I have so much shit in there...
<riteo> if it still breaks shit at this point people might have as well stuck onto one options
<dilyn> well yes that is certainly the point of it in part
<midfavila> yeah but ldd depends on paths to link things in at runtime
<dilyn> but you try to update 90,000 packages to deal with that
<midfavila> if you just smack everything in a single directory then it won't find its depends
<midfavila> and yeah
<midfavila> economics of scale makes that simple change a massive problem
<riteo> I see
<dilyn> it was a discussion for *years* leading up to it haha
<dilyn> I think you can see it on the debian ml archive...
dilyn has quit [Quit: Client closed]
dilyn has joined #kisslinux
<sewn> dilyn
<sewn> are you using muon
<dilyn> tryna
<sewn> have you seen my pr
<sewn> all packages in repo built with muon just needs some upstream PRS and issues to be addressed
<sewn> I hate the fact you've gone this long and i didn't notice you're trying to muon
<dilyn> I only just started on the muon enterprise haha
<dilyn> will take a look
<dilyn> next I need to find the resolution to this undef STN_UNDEF error (but that's an elftoolchain thing, not a muon thing...)
<dilyn> ope, no. got a new different error...
<dilyn>  73 | @va_driver_init@
<midfavila> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
<midfavila> i'm going to scream
<midfavila> i finally
<midfavila> FINALLY
<midfavila> got the stage one bootstrap toolchain building
<midfavila> only for it to immediately fail because the skarnet toolchain doesn't support modules
<dilyn> :v
<dilyn> trolled hard
<midfavila> and that means i need to restart the entire build
<midfavila> because god forbid i change a single fucking character in the entire build environment mid-build
<midfavila> i literally want to kms rn oh my god
<midfavila> i've been doing this for months
<midfavila> aaaaaaaaaaaa
<dilyn> why can't you just use crosstools-ng? :P
<midfavila> because im not building a cross toolchain
<midfavila> im building a native toolchain using a cross toolchain
<dilyn> but you can build a cross toolchain to then build a native toolchain with crosstools-ng, can you not
<midfavila> in theory. in practice i tried using it and musl-cross-make and mussel, but they produced toolchains that were out of date or had other issues that i didn't find a way to work around.
<midfavila> mussel broke, cross-make built out of date tools, and... i can't recall what issue i had with crosstools, but it gave me shit too
dilyn has quit [Quit: Client closed]
dilyn has joined #kisslinux
krjst has quit [Ping timeout: 252 seconds]
krjst has joined #kisslinux
<dilyn> sewn what gpu(s) are you building for when you tested this mesa package? intel?
sadplan is now known as sad_plan
<sad_plan> hi
<sad_plan> hi dilyn. nice to see you back again
<dilyn> o/ :D
<sad_plan> sewn: also re static: yes, I do have a static kiss repo, which was somewhat based on dilyns work on his kiss-static repo. but I fell short when I couldnt build everything I wanted statically linked.
<sad_plan> re toybox aswell: I also tried to switch to toybox, but was dissatisfied with it completeness. or rather lack there of. aswell as its dependency on bash..
<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
<midfavila> i know it's not really a segment in today's market but i really wish i could get a no-frills 2D "display adapter" card
<sad_plan> midfavila: no, you can use velox with libdrm only, no mesa
<dilyn> plus mesa just didn't work (so I tried velox)
<midfavila> idc about velox
<midfavila> i use a real graphics server
<midfavila> smdh
<sad_plan> midfavila: I knew you would say that :p
<midfavila> wayland will literally never be suitable for my needs.
<midfavila> by definition.
<sad_plan> dilyn: shouldve just used oasis. doesnt fall appart for me :p
<midfavila> anyway it looks like nouveau hard depends on mesa which isn't surprising
<midfavila> alas
<dilyn> i strongly considered using oasis
<sad_plan> midfavila: care to elaborate?
<dilyn> oasis doesn't support even nouveau, probably for the same reason?
<sad_plan> dilyn: maybe you can find some inspiration in my fork; https://github.com/hovercats/oakiss
<sad_plan> dilyn: false
<midfavila> my entire UX is built around X's facilities
<midfavila> that wayland by design has no analogue to
<sad_plan> it doesnt support amdgpu
<midfavila> like for example Xt
<midfavila> i explicitly do not want gtk or qt or similar
<midfavila> or any of their facilities
<dilyn> don't tempt me lad lmfaooo I can't become this distracted
<sad_plan> midfavila: sure, thats gonna be an issue
<dilyn> oh do I have the GPU problems backwards
<midfavila> i want a simple, no-frills, lightweight UI library in C.
<sad_plan> dilyn: sure you can, have a peak now already
<midfavila> i don't need or want scalable fonts, vector fonts, theming, etc etc
<midfavila> athena is sufficient
<midfavila> also there are no good compositors imho
<midfavila> if fvwm ever gets ported to support wayland and a library that's similar to athena gets written to target wayland i would consider switching
<midfavila> but even then that ignores the slow adoption among non-linux unices
<sad_plan> midfavila: I also have somewhat of an issue with the lack of compositors on wayland, but im pretty sure I culd get by at the end of the day anyway
<dilyn> just be like everyone else on unixporn and use hyprland
<sad_plan> not niche enough :p
<dilyn> hikari is always there to catch us when we fall :)
<sad_plan> yeah, hikari seems somewhat nice. its one of those Ive been wanting to try, but I was mad about some font issues with foot, or getting st to work properly
<sad_plan> for some reason, mcfs fork of st, will segfault in sway or hikari
<dilyn> very strange
<midfavila> i dont want to just "get by"
<midfavila> i want to actually enjoy using my computer again
<midfavila> :\
<sad_plan> yes. very strange indeed. on sway I could not launch it if specified in the config, it doesnt work at all. I could launch it in from foot in sway, or if I put it into background on hikari.
<sad_plan> midfavila: I get that
<sad_plan> dilyn: I havent really investigated much past that.
<sad_plan> his dmenu fork also just never launched at all, giving me no output either which was really wierd
* sad_plan shrugs
<dilyn> well sewn in the meantime I've installed libva to skip the need for your second patch lmfaoo
<dilyn> lmk
<sad_plan> got my new case today though. so now I can finally assemble my new desktop tomorrow :D
<sad_plan> midfavila: how do you intend for pm to use ncompress? ncompress doesnt have any library