ChanServ changed the topic of #kisslinux to: Unnofficial KISS Linux community channel | https://kisscommunity.bvnf.space | post logs or else | song of the day https://vid.puffyan.us/H7PvgY65OxA
rohan has quit [Ping timeout: 264 seconds]
rohan has joined #kisslinux
rohan has quit [Ping timeout: 264 seconds]
rohan has joined #kisslinux
<testuser[m]1> rust
<testuser[m]1> illiliti: ok
<ioraff> ha
<testuser[m]1> Hi
<ioraff> hi
<noocsharp> testuser[m]1: i would consider starting kiss-ng from nkiss because a lot of the functionality is already in place
<noocsharp> but i am biased of course
<virutalmachineus> rust kiss!!!
<virutalmachineus> is for security reasons?
<testuser[m]1> noocsharp i prefer to do from scratch cuz I can learn more
ioraff has quit [Quit: ioraff]
geekthattweaks has joined #kisslinux
ioraff has joined #kisslinux
Torr has quit [Quit: leaving]
<noocsharp> fair
<noocsharp> virutalmachineus: he's joking about rust
<rohan> hey guys
<rohan> mesa build is broken for some reason
<virutalmachineus> <noocsharp> "virutalmachineuser: he's..." <- what? we all know testuser loves rust. he's just joking.
<rohan> heres the log
<virutalmachineus> mesa is broken again
<virutalmachineus> that thing is hot mess
<ioraff> sorry. on it
<illiliti> i suppose you just need to null vulkan-drivers option
<illiliti> -Dvulkan-drivers='[]'
<illiliti> rohan: you have amd gpu right?
<rohan> yeah
<ioraff> we could null it by default
<wael[m]> aren't vulkan drivers important
<ioraff> for games
<wael[m]> well, you would still need vulkan headers and loader which don't exist in the kiss repos so
<ioraff> indeed
<wael[m]> it is errroring because of missing glslang, which is opengl thing
<ioraff> yes, but it only tries to find it if vulkan is enabled
<illiliti> so disable vulkan
<illiliti> we don't use or need it anyway
<illiliti> -Dvulkan-drivers='[]'
<wael[m]> true
<illiliti> muon equivalent: -Dvulkan-drivers=
<illiliti> if anyone need it
<ioraff> pushed
<illiliti> thanks
<wael[m]> is there a way to quickly make a patch for a package without having to git init, git add, git commit, git diff in the source dir?
<wael[m]> also in muon, there is no i18n so i cannot build pulseaudio for that
<wael[m]> eg. i18n = import('i18n')
<ioraff> well, you only run git init once. git diff is optional, and you can combine add and commit into commit -a if all the changes in the tree belong to one commit
<wael[m]> i didnt know that was possible
<wael[m]> `/usr/lib/libGLdispatch.so -> libGLdispatch.so.0.0.0c_1248`
<wael[m]> why did muon do this
<wael[m]> `/usr/lib/libEGL.so.1 -> libEGL.so.1.1.0?C?D?Q??D?D?P`
<wael[m]> wtf
<illiliti> lattis merged this patch
<illiliti> update muon
<wael[m]> in what commit/version?
<wael[m]> 5 hours ago ok
<wael[m]> yep seems good
<wael[m]> illiliti: sway is failing to build because of glib? https://termbin.com/6ivz
<illiliti> rebuild glib
<wael[m]> with muon?
<illiliti> yes
<illiliti> rebuild everything you build with muon
<illiliti> i guess you have corrupted symlinks
<illiliti> somewhere
<wael[m]> well, i am converting grepo's current meson packages to muon, and sway relies on glib, but the glib muon hasnt been merged in the primary repos so i have to wait for that sorta
<illiliti> sway doesn
<illiliti> 't need glib
<wael[m]> so why is it failing to build whar
<illiliti> because pango need it
<wael[m]> yeah i think i will wait for the muon pr to get merged
<wael[m]> in the meanwhile ill try to get all the muon packages in the pr and test the ones that my system needs
<wael[m]> btw, what about mesa? is it still failing to build with muon?
<illiliti> it builds fine if your gpu don't need llvm
<wael[m]> ..nvidia
<ioraff> amd does too
<illiliti> i'll work on mesa once i fix all regressions and get freetype-harfbuzz to work
<wael[m]> freetype muon works? harfbuzz doesnt?
<illiliti> they are merged into one package
<wael[m]> I know, I was asking if harfbuzz muon doesn't work
<wael[m]> for me freetype muon builds
<illiliti> hm
<ioraff> btw -Dvulkan-drivers= doesn't work
<illiliti> for me second build of freetype is broken
<illiliti> maybe my system is dirty
<illiliti> ioraff: will look into it
<wael[m]> the freetype muon I've tested is a 32-bit package, which harfbuzz never builds in so..
curious-antelope has joined #kisslinux
curious-antelope has left #kisslinux [#kisslinux]
ioraff has quit [Remote host closed the connection]
<wael[m]> about muon missing i18n required for pulseaudio to build, i have attempted to disable it entirely (po) but now im getting missing glib.h error, which is handeled by po
<wael[m]> weird
<illiliti> nuke it
<wael[m]> got it sir
<wael[m]> as in remove it
<illiliti> send error log
<wael[m]> nuking glib fixed it
<wael[m]> also, when a feature is used as a boolean (eg. glib=false) muon seems to crash
<wael[m]> now last package is at-spi2 which requires meson GNOME bindings and whatnot
<wael[m]> probably isnt important, ignoring
<illiliti> exit with 1 without output?
<wael[m]> yep
<wael[m]> 'Terminated' is all kiss gives me
<illiliti> i've reported it already
<wael[m]> yay cool
<illiliti> btw
<illiliti> consider sending muon.patch to upstream
<illiliti> it's their bug
<wael[m]> wdym
geekthattweaks has quit [Quit: Connection closed for inactivity]
<wael[m]> booleans are required to not be in quotes, as specified in manuals
<wael[m]> pulseaudio has this already, just those 3 for some reason
<illiliti> booleans must not be in quotes
<wael[m]> OHHHHHHHHHH i see what you mean yeah ur right
<wael[m]> on it
<wael[m]> 5 months ago wtf
<illiliti> yep, gtk is slow to ship fixes
<illiliti> i bet pulseaudio is slower
<wael[m]> lets find out
<wael[m]> i will be copying the gtk pr's title and description since idk what to write
<illiliti> fine
<wael[m]> and for mangohud as well lol
<illiliti> mangohud?
<illiliti> link?
<wael[m]> oh yeah i forgot i dropped it
<wael[m]> its pretty useless nvm
<illiliti> ok
<wael[m]> https://github.com/flightlessmango/MangoHud here is the link anyway
<wael[m]> its just a overlay for games, i barely even use it anyway, as my gpu already has one built in
<wael[m]> ~~opens a pr for mangohud anyway~~
Beni has joined #kisslinux
Beni has quit [Client Quit]
smudge-the-cat has joined #kisslinux
smudge-the-cat has left #kisslinux [#kisslinux]
<wael[m]> now libglvnd with 32-bit support is failing to build, ...with assembler errors https://termbin.com/tf8b
<wael[m]> other lib32 packages work with muon so hmm
<illiliti> no idea what's wrong
<wael[m]> it is required for lib32 mesa, which is still meson, so i guess i can ignore it and keep meson until mesa gets fixed
<wael[m]> normal libglvnd with muon works however
<illiliti> wait, can meson build 32 libglvnd?
<wael[m]> yep
<illiliti> so it is muon bug, ok ...
<wael[m]> how is it muon bug if 32 libdrm works
<wael[m]> hmm
<illiliti> idk
<illiliti> need to investigate
<testuser[m]1> What does muon even have to do with 32
<illiliti> maybe it doesn't work well with multilib
<wael[m]> probably
<testuser[m]1> But all it cares about is value of $CC right
<illiliti> nope
<illiliti> there might be a problem with lib32/lib64 split
<illiliti> muon resolves libs using libpkgconf instead of passing -l<lib> to CC
<illiliti> considering that muon doesn't support cross-compilation, i think that multilib is not supported too
chomwitt has joined #kisslinux
<phoebos> can someone on musl do `nm /lib/libc.a | grep backtrace`
<phoebos> oh dw
<phoebos> execinfo.h isn't owned by musl
an3223_ has quit [Ping timeout: 258 seconds]
an3223_ has joined #kisslinux
<testuser[m]1> ioraff: why is nproc changed to grep core id in rust
rohan has quit [Ping timeout: 264 seconds]
rohan has joined #kisslinux
rohan has quit [Ping timeout: 268 seconds]
rohan has joined #kisslinux
rohan has quit [Ping timeout: 265 seconds]
rohan has joined #kisslinux
rohan has quit [Ping timeout: 260 seconds]
rohan has joined #kisslinux
phinxy has quit [Ping timeout: 252 seconds]
rohan has quit [Ping timeout: 252 seconds]
rohan has joined #kisslinux
rohan has quit [Ping timeout: 244 seconds]
rohan has joined #kisslinux
phinxy has joined #kisslinux
rohan has quit [Ping timeout: 252 seconds]
rohan has joined #kisslinux
rohan has quit [Ping timeout: 265 seconds]
ioraff has joined #kisslinux
dilyn has quit [Quit: Connection closed]
<ioraff> testuser[m]1: nproc isn't posix
ella-0_ has joined #kisslinux
ella-0 has quit [Ping timeout: 265 seconds]
ella-0 has joined #kisslinux
ella-0_ has quit [Read error: Connection reset by peer]
<testuser[m]1> ioraff: how posix is core id in cpuinfo
<testuser[m]1> android doesn't seem to have it
<ioraff> good point
<testuser[m]1> linux 4.4
<testuser[m]1> Not that you'd run kiss on android
<testuser[m]1> But i was just checking
<testuser[m]1> Also with sed -i and install removal
<testuser[m]1> Tons of makefiles and build scripts would still be making use of them
<testuser[m]1> I'm sure about install, not sure how common sed -i is
<ioraff> the file of course isn't posix, but we still avoid requiring a non-posix utility. I suppose I could add '|| printf 1'.
<ioraff> and yes, that's a potential issue. at least we're trying not to contribute to it
<testuser[m]1> ioraff: grep || nproc || 1?
<ioraff> why both grep and nproc?
<testuser[m]1> If the file isnt present
<testuser[m]1> nproc doesn't rely on proc
<ioraff> it's still unportable under the hood
<testuser[m]1> But no harm in checking if it exists and possibly getting correct core count rather than 1
phinxy has quit [Quit: WeeChat 3.5-dev]
phinxy has joined #kisslinux
midfavila has quit [Quit: Leaving.]
midfavila has joined #kisslinux
rohan has joined #kisslinux
rohan has quit [Ping timeout: 265 seconds]
rohan has joined #kisslinux
rohan has quit [Ping timeout: 265 seconds]
rohan has joined #kisslinux
chomwitt has quit [Ping timeout: 264 seconds]
rohan has quit [Ping timeout: 265 seconds]
rohan has joined #kisslinux