ChanServ changed the topic of #kisslinux to: Unnofficial KISS Linux community channel | | post logs or else | song of the day
geekthattweaks has quit [Quit: Connection closed for inactivity]
<iceman[m]> <testuser[m]> "iceman:..." <- nice, he back
personifieddevil has quit [Ping timeout: 256 seconds]
personifieddevil has joined #kisslinux
ehawkvu has quit [Remote host closed the connection]
sad_plan has quit [Read error: Connection reset by peer]
shokara has quit [Remote host closed the connection]
shokara has joined #kisslinux
ehawkvu has joined #kisslinux
_whitelogger has joined #kisslinux
shokara has quit [Remote host closed the connection]
<sewn> testuser: is it possible to check for radeon drivers at mesa build time to check if user needs LLVM?
<sewn> error('The following drivers require LLVM: RadeonSI, SWR, Lavapipe. One of these is enabled, but LLVM is disabled.')
<sewn> only people with amd graphics drivers such as myself require llvm
<sewn> it can be checked with file /sys/module/amdgpu maybe
<testuser[m]> no
<testuser[m]> so bad
<sewn> why not
<testuser[m]> non deterministic
<sewn> you're gonna ask everyone to build llvm when they dont need it tho
<sewn> testuser[m]: wdym
<sewn> honestly im suprised muon can build mesa
stjohn has joined #kisslinux
stjohn is now known as dazzlepansy
<sewn> illiliti: why did muon build need MUON_STATIC compilation option to be removed? did it cause a build failure?
<illiliti> because it breaks discovery of packages that have pkg config file installed
<illiliti> by removing muon_static option, we tell muon/libpkgconf to use default pkg config path while keeping static build
<sewn> ah i see
dazzlepansy has quit [Quit: dazzlepansy]
<sewn> these packages do not use DESTDIR: baseinit baselayout busybox bzip2 certs kiss linux-headers pigz cbindgen efibootmgr firefox-privacy man-pages meson nodejs nss python-docutils python-mako python-markupsafe ttf-croscore
<sewn> only checked these by grepping DESTDIR
<sewn> do muon/meson build files use the build directory as 'output' or 'build'? which is preferred
<illiliti> the one you like more
<sewn> the one the maintainer of the package likes more*
yamchah2 has quit [Remote host closed the connection]
yamchah2 has joined #kisslinux
<xdream8[m]> When that muon pr will be merged?
<sewn> its literally freah
<sewn> fresh
<sewn> atleast give it like one kiss maintainer meeting
sad_plan has joined #kisslinux
<sad_plan> hi
<sad_plan> sewn: on sabotage, mesa is split into separate packages. one of which is for radeon/amd gpu. which obviously requires llvm which you mentioned. you could look at that. as iirc, they have a switch for it
<sewn> smart actually
<sad_plan> yep.
<sad_plan> not sure how the switch works, but it could be worth looking into in any case
<illiliti> split could be done with provides system
<sad_plan> sure
<sewn> provides system coming near you in never
<sewn> a provide system can be somewhat implemented by having simply different repositories
<sad_plan> lol. its been mentioned a couple times here, but its seems difficult to implement. i dunno
<sewn> it would require fake naming packages no?
<sewn> one can implement a provides system by just using different repositories
<sewn> another way I can put it is to add it to the 'depends' array as a 'replace' key and to have the end package name to be the replaced package
<sewn> how about that?
<sewn> or to have it be some file that's touched in the build file idk
<sad_plan> I was thinking more in line with using the manifest file, and just.. grepping it or w/e. not sure how practical that would be though
<sewn> I don't get what you mean
<sad_plan> say if a package specifically requires assert.h file, kiss would look for that file, and see what package provides said file, and then make sure said package is installed, if not, the build/install it
personifieddevil has quit [Read error: Connection reset by peer]
<sewn> that is significantly slow as let's say a package needs a giant library and its thousands of headers, it wouldn't be safe to check for one file as maybe one is missing, one would need to check for each file to see if they belong to a package, one by one.
<sewn> I think that would be very slow
<sewn> personally I don't see another way to implement it other than fake name packaging
<sad_plan> it would absolutely be slower than a snail
<sad_plan> which is why I said it wouldnt be practical
<sad_plan> in a situation like oasis, this makes somewhat sense, as its repo is very small, and only consists of smaller projects, so figuring out what headers and so on is needed is somwhat trivial
<sewn> I'm pretty sure even oasis doesn't need a provides system, as there isn't even any dependency management
<sad_plan> it doesnt, but itll only build w/e is needed, more or less. it does have a *system* for dependencies, its just in the buildfiles instead
<sad_plan> i.e. in a gen.lua file for i.e. velox, youd see that it includes files from different other packages. its specific to specific headers though, just.. headers from said package
<sad_plan> like velox would have included header files from fontconfig, libinput, and so on
<sewn> sad_plan: you forgot the fact that when defining the executable or library, the library itself is added as a source file, hence linking to it
<sewn> I think this is very impressive
<sad_plan> it was just a simple explenation, but yes, that would be correct.
<sad_plan> and yeah, Im also impressed by this