ChanServ changed the topic of #kisslinux to: KISS Linux | https://k1sslinux.org | /msg zr for kisslinux/* cloaks | logs: https://k1sslinux.org/irc#2.0 | thing of the day: https://vid.puffyan.us/watch?v=HVzC6WZImGY
claudia_ has quit [Ping timeout: 252 seconds]
<riteo> So apparently GNU's sha1sum isn't flag-compatible with busybox's one... What can I do now?
<riteo> GNU's one allows only the big flag --status for some reason, while busybox allows only -s
progenyx has quit [Quit: progenyx]
<riteo> oh you know what? I think I can avoid it and be fine, nevermind
necromansy has quit [Ping timeout: 268 seconds]
mahmutov has quit [Ping timeout: 252 seconds]
m3g has quit [Ping timeout: 268 seconds]
zenomat has quit [Ping timeout: 244 seconds]
zenomat has joined #kisslinux
zenomat has joined #kisslinux
zenomat has quit [Changing host]
<testuser[m]1> Hi
<testuser[m]1> Yeah riteo i got that issue too
<testuser[m]1> How long ago did you try on adelie ?
<riteo> testuser[m]: I think it was Christmas
<riteo> anyways TLS seems like a very old thing on nvidia drivers AFAICT
<riteo> I looked around for some keywords and found very old mesa bug tickets talking about this
<testuser[m]1> Yea
<riteo> I have a strong feeling that adélie patched their musl package to allow dlopen on this configuration
<riteo> after all they made gcompat, they really care about compatibility
<riteo> the filenames of the patches tell me nothing though
soliwilos has quit [Remote host closed the connection]
<testuser[m]1> God why is shitlab so laggy
<riteo> very heavy statically generated pages I guess
<riteo> I have no idea
<riteo> as I said, there's no license file
<riteo> so I kinda want to avoid opening it
<testuser[m]1> Wouldn't changes to musl be under the same license as musl
<riteo> mhhh
<riteo> actually I think so
<riteo> explains a lot
<riteo> let's see
<riteo> mhhh, I actually have no idea what it's supposed to do lol
<riteo> but I read tls so I guess that's the patch
<riteo> I really have to study what it does more in depth
<testuser[m]1> Hmm alpine has the same patches too
<riteo> yeah they sharea lot of stuff
<riteo> even the package manager
<riteo> adélie is an interesting distro, it's like alpine but more desktop-y and standard compliant
<testuser[m]1> Oh
<testuser[m]1> Nicr
<riteo> I found them very based until recently
<riteo> they updated their website with polyfill and I lost all my respect towards them /s
<riteo> no ok that's mildly annoying but they still did good things
<riteo> oh
<testuser[m]1> You sure you didnt launch i3 with nouveau lol
<riteo> I looked everywhere and didn't find this obviously
<riteo> testuser[m]: I'm pretty sure
<riteo> I had to do the ld_preload trick
<riteo> and I messed up with gcompat and the nvidia installer a LOT
<riteo> I mean, I also did these things overnight, so everything's possible, I don't even remember myself what I fully did back them
<riteo> also I'm not really sure that patch's gonna do much
<riteo> I really think that we might have more luck reverting that commit, that behaviour isn't really done by much software, expecially the type of software that usually runs on KISS
<riteo> well, there's only one way to find out
<riteo> the modified package got installed on the usb, time to reboot there
<riteo> cya very soon!
riteo has quit [Quit: epic usb time]
kiss-riteo has joined #kisslinux
<kiss-riteo> it's me
<kiss-riteo> kiss-riteo
<testuser[m]1> Hi me
<kiss-riteo> as expected that patch did pretty much nothing
<kiss-riteo> how did I even boot that thing back then
<testuser[m]1> What'd the revert do
<kiss-riteo> oh no I didn't do that yet
Uks2 has quit [Ping timeout: 268 seconds]
<kiss-riteo> I just wanted to hope I wasn't actually drunk from sleep back then and accidentally turned on nouveau
Uks3 has joined #kisslinux
<kiss-riteo> welp, let's try reverting I guess
<kiss-riteo> testuser[m]1: did you use google to find that commit
<kiss-riteo> I can't find it anywere from ddg
<kiss-riteo> (also I don't know where the question mark is on american qwertys)
<testuser[m]1> No i just thought of running `find -name '*.c' -exec grep resolves {} +` by cloning the repo on my phone but i stumbled on their cgit search and used that
<testuser[m]1> I don't use gnugle
<kiss-riteo> oh I see
<kiss-riteo> is it me or are musl's git servers very slow?
<kiss-riteo> oh it failed
<kiss-riteo> welp, better reboot to arch, I won't be writing an URL by hand
kiss-riteo has quit [Quit: epic tty moment]
<testuser[m]1> Revert it by hand :v
riteo has joined #kisslinux
<riteo> it's time to diff
<riteo> the patch has been created
<riteo> time to reboot, again
riteo has quit [Quit: epic excessive reboots time]
kiss-riteo has joined #kisslinux
<kiss-riteo> time to build
<testuser[m]1> You can just add the patch to the package and `patch -p1 -R < patch` to revert it
<kiss-riteo> yes that's what I did
<testuser[m]1> Oh
<kiss-riteo> I'm building the package
<kiss-riteo> yes, the build is done
<kiss-riteo> YES
<kiss-riteo> IT WORKS
<kiss-riteo> I mean
<kiss-riteo> it doesn't start yet, but I'm back to some familiar missing symbols errors
<kiss-riteo> good old _IO_2_1_stdout_
<testuser[m]1> Yeah i got stuck on thay one
<kiss-riteo> I actually did some shatty patches for that time ago
<kiss-riteo> you know, the mysterious patches
<kiss-riteo> I'm tempted to blindly apply them and then writing them from scratch since I remember basically nothing
<kiss-riteo> blindly apply them to see what happens*
<testuser[m]1> Do it
<kiss-riteo> ok gimme a sec
<kiss-riteo> there actually quite a lot of them
<kiss-riteo> io-stdout, no-utmp, sched, wcstoul...
<kiss-riteo> I think I'll start with io-stdout.patch
<kiss-riteo> It doesn't compile
<kiss-riteo> I don't even think it's a patch thing
<testuser[m]1> What does it ssy
<kiss-riteo> it says that cc can't execute 'as'
<testuser[m]1> Lol
<testuser[m]1> Wtf
<kiss-riteo> and says that it can't find execvp
<kiss-riteo> if you give me a second I can write it by hand exactly
<testuser[m]1> It can't not find execvp, i think you lost your /usr/bin/as
<kiss-riteo> wait I think I know why
<kiss-riteo> I left LD_PRELOAD exported
<kiss-riteo> it messes up things a lot
<testuser[m]1> Yeah that's probably it
<kiss-riteo> yep it built
<kiss-riteo> it didn't do anything
<kiss-riteo> lemme look at the symbol list
<kiss-riteo> yep it implements it
<kiss-riteo> mhh this is familiar
<kiss-riteo> IIRC it doesn't find the symbol because xorg ran with musl, but with LD_PRELOAD it should work
<kiss-riteo> what did you do sleep drunk riteo? what?
<testuser[m]1> It only complains about IO_STDOUT thingy and 1-2 others, or other symbols too, without LD_PRELOAD ?
<kiss-riteo> ldd tells me so
<kiss-riteo> but with ld_preload it only complains about one symbol I don't recall
<kiss-riteo> the weird thing is that the xorg log still complains about io stdout
<kiss-riteo> aaaaaaaaaaaaaa what did I doooooooooooo
<kiss-riteo> wait maybe I recall
<kiss-riteo> I think I used ld.conf or something similarly named
<kiss-riteo> but isn't it the same of LD_PRELOAD?
<kiss-riteo> no ok it's a whole another thing
<kiss-riteo> I really should've backupped that usb you know
<kiss-riteo> maybe I just have to set it in the .profile
<kiss-riteo> it didn't do nothing
<kiss-riteo> s/nothing/anything/
<testuser[m]1> ld.so.comf just tells the elf interpreter WHERE to look for libraries
<kiss-riteo> yeah
<kiss-riteo> but ldd works fine, so I don't think that's the problem
<kiss-riteo> there was some specific thing I done to allow the module to link to gcompat but I can't remember it
<kiss-riteo> I was sure it was LD_PRELOAD
<kiss-riteo> I'm out of ideas for now and very tired
<testuser[m]1> Do patchelf --add-needed
<kiss-riteo> mh
<testuser[m]1> But i dont think it'll do anything since the lib is loaded anyway
<kiss-riteo> more than anything I feel like xorg loads the module in a funky way
<kiss-riteo> wait, should I do it on the module, xorg or both?
<testuser[m]1> Module
kiss-riteo has quit [Read error: Connection reset by peer]
kiss-riteo has joined #kisslinux
<kiss-riteo> IT WORKED
<kiss-riteo> I GOT STUCK ON A BLACK SCREEN BUT IT WORKED
<testuser[m]1> Nice
<kiss-riteo> I have seriously no idea how I got to this point months ago
<kiss-riteo> I always said that the craziest things happen only during the night
<kiss-riteo> you become a tech god as soon as you get tired enough
<kiss-riteo> obviously I broke it too because I completely shifted my timezone
<kiss-riteo> time to try i3
kiss-rit1o has joined #kisslinux
kiss-riteo has quit [Read error: Connection reset by peer]
<kiss-rit1o> I just found out why I got stuck
<kiss-rit1o> oh lol I'm rit1o
kiss-rit1o is now known as kiss-riteo
<testuser[m]1> Eudev?
<kiss-riteo> I don't think so
<kiss-riteo> I saw some broken i3 windows
<kiss-riteo> but
<kiss-riteo> it started technically
<kiss-riteo> after all I didn't import all the patches
<kiss-riteo> but for me that's more than enough proof to say that yes, it's possible to run nvidia's drivers on kiss linux
<kiss-riteo> all we had to do was revert a 3 year old commit disabling undefined behaviour, apply some shady patches to gcompat and patch libnvidia-glcore.so
<kiss-riteo> thanks a lot for finding that commit btw, otherwise I would've been stuck for like a whole week in an incredibly confused state
<kiss-riteo> enough nvidia for now, time to bundle up those few changes I made to minekiss and go to sleep
kiss-riteo has quit [Quit: epic arch linux moment]
riteo has joined #kisslinux
<riteo> aaaaaaa now my hands are stuck on the american layout
<riteo> s/on/to/
<riteo> yes, now minekiss validates all the assets in an instant and doesn't take like 2:35 minutes just to list all of them
<riteo> next step: adding all symbols to gcompat
<riteo> thinking about it, testuser[m]1 what if that freezing I saw was the corruption they were talking about in the commit?
<riteo> reading it again it talks about already existing threads though, and I didn't find garbage in my screen
<riteo> partially drawn stuff, yes, but not garbage, so I think we're good
<riteo> well, time to sleep, cya!
riteo has quit [Quit: epic nvidia moment]
schillingklaus has joined #kisslinux
<testuser[m]1> midfavila: the elinks fork seems to have some css rendering support btw, but colors are not configurable
<testuser[m]1> http://0x0.st/-9M6.xz
<schillingklaus> I set TERM to vt100 to make colours disappear in elinks
mahmutov has joined #kisslinux
<testuser[m]1> im fine with the colors but they fuck up on some sites :/ http://0x0.st/-9Ml.png
<testuser[m]1> oh wait you can configure the colors
Uks2 has joined #kisslinux
Uks3 has quit [Ping timeout: 268 seconds]
progenyx has joined #kisslinux
soliwilos has joined #kisslinux
mahmutov has quit [Ping timeout: 264 seconds]
progenyx has quit [Quit: progenyx]
progenyx has joined #kisslinux
progenyx has quit [Client Quit]
mmatongo has joined #kisslinux
<mmatongo> hi
mahmutov has joined #kisslinux
mmatongo has quit [Remote host closed the connection]
strajder has joined #kisslinux
<midfavila> testuser[m]1 how did you get elinks to compile?
progenyx has joined #kisslinux
<midfavila> i tried doing the usual procedure but it kept failing for me
schillingklaus has quit [Quit: schillingklaus]
necromansy has joined #kisslinux
<midfavila> " [GMSGFMT] po/bg.gmo fopen: No such file or directory"
<midfavila> to be clear, it does exist.
<midfavila> disabling nls worked around it
* midfavila shrugs
<midfavila> ...except now it's complaining about undefined references to "render_source_document_cxx"... this can wait for later
Uks2 has quit [Quit: Byee]
Uks2 has joined #kisslinux
<testuser[m]1> The tarball link i sent contains the build files
<testuser[m]1> Using those ?
<midfavila> Oh, no, I was using upstream
<midfavila> i'll give your files a shot
<testuser[m]1> It uses meson to avoid perl +autohell
<testuser[m]1> Cuz no configure script
<midfavila> oh, nice
<midfavila> yeah, it builds using your package and the latest release
<midfavila> Hey, ELinks is pretty decent with its CSS
<midfavila> it's able to render my site's navbar and text quite nicely
kimerus has joined #kisslinux
<kimerus> Guys
<kimerus> Anyone had a little extra ram in libudev-zero update?
<kimerus> I had to take a reinstall in eudev and remove it because libudev-zero had a problem and now is like i use eudev
<kimerus> Because the ram is the same
<testuser[m]1> Wat
<kimerus> So my ram after the update
<kimerus> Is about 130mb
<kimerus> Now is 150mb
<kimerus> Is like i use eudev
<kimerus> But i even use it
<testuser[m]1> You mean ram usage increased after libudev-zero update
<kimerus> Yeah
<kimerus> Normal or not?
<kimerus> And i had to do all the replacing-udev article because i get xorg errors
<kimerus> Maybe this part bugged the system
<testuser[m]1> Idk 20mb seems normal
<kimerus> For a update?
<testuser[m]1> It's probably something else you configured
<kimerus> Like what?
<kimerus> Because i don't know
<testuser[m]1> Extra services
<kimerus> Hmmm
<kimerus> No
<kimerus> Just run the same
<kimerus> Maybe the kernel update i did but i think is not
<kimerus> Is the same configs
claudia has joined #kisslinux
<claudia> yeah the libudev update introduced new so version. So everthing build against libudev.so has to be rebuild. https://github.com/illiliti/libudev-zero/commit/db72f8610d62a5e6884c6d8d86660d07e49455c4
<claudia> Or create a symlink from libudev.so to libudev.so.1
<kimerus> But it requeire much ram?
<kimerus> Because i did the rebuild
<kimerus> But i get 20mb more ram consumption
claudia has quit [Read error: Connection reset by peer]
claudia has joined #kisslinux
<claudia> kimerus: xorg, eiwd, crond, sxhkd xwallaper idles in about 80mb after startup.
<kimerus> All your system 80mb?
<claudia> yep
<claudia> going after htop
<kimerus> Wait
<kimerus> You mean after update you ger more 80mb or your system in total is 80mb?
<claudia> my system needs 80mb when I log in and start my windowmanager.
<claudia> *80mb ram
<kimerus> Shit
<kimerus> Amd or intel drivers?
<claudia> intel.
<kimerus> Imagined
<kimerus> But man
<kimerus> I don't know what happen
<kimerus> But i get more 20mb
<claudia> When you notice some problem, install old version do some mesurements.
<claudia> And when you think its libudev-zero related, open an issue on the libudev-zero repo.
<kimerus> My system is about 125mb or 130mb and know is about 150mb
<kimerus> Now*
<kimerus> Maybe i do a reinstall
<kimerus> To see if is not udev what bugged the system
<testuser[m]1> Bruh do you seriously care for 20mb ram
<kimerus> Yeah
<kimerus> I'am crazy with ram
<claudia> :D
<kimerus> Man is because
<kimerus> I use kiss for it
<testuser[m]1> Go for a static X config then, no udev
illiliti has joined #kisslinux
<kimerus> I get the same ram in gentoo ram with udev shit and glibc so why change if i get not in ram gain
<claudia> kimerus: a test with the prior libudev-zero version would gian some clarification.
<illiliti> kimerus: there is no extra ram usage in libudev-zero. i just did the measurements and didn't notice any differences between 0.4.8 and latest master
<kimerus> So yeah
<kimerus> Is a udev bug
<testuser[m]1> Wat
<testuser[m]1> You didnt switch to eudev right ?
<kimerus> Yeah
<kimerus> I mean
<kimerus> I did again the replacing-udev article
<kimerus> In kiss wiki
<testuser[m]1> First you switched back to eudev, then back to libudev-zero ?
<kimerus> Yeah
<kimerus> And now i get 20mb
<kimerus> More ram
<kimerus> My kiss revdepends eudev show nothing
<kimerus> So i think reinstall eudev and install libudev-zero give the system some bug
<claudia> kimerus: When you have libudev-zero installed and switch between versions, you can just do 'kiss-revdepends libudev-zero' and rebuild the packages from the output.
<claudia> No need the go the "replace udev" article again.
<kimerus> Yeah i see it after i did the dumb action
<kimerus> But now i get this 20mb extra ram
progenyx has quit [Quit: progenyx]
<claudia> This is empiric information.
<kimerus> I think ima just move to gentoo again, i need my steam back
progenyx has joined #kisslinux
soliwilos has quit [Quit: zzz]
claudia has quit [Ping timeout: 265 seconds]
<kimerus> testuser[m]1: your steam script works properly with non native linux games?
<testuser[m]1> How many times are you going to ask bruh, it works for me
an3223_ has quit [Quit: leaving]
<kimerus> Just for make sure
<kimerus> Still don't know why this not work in xorg
midfavila-laptop has joined #kisslinux
<kimerus> Maybe some dependencies fault
<kimerus> The problem is, you use wayland and i use xorg so is difficult do debug this way
<testuser[m]1> I used it on X
<testuser[m]1> Not anymore
an3223 has joined #kisslinux
soliwilos has joined #kisslinux
claudia has joined #kisslinux
illiliti has quit [Ping timeout: 258 seconds]
midfavila-laptop has quit [Ping timeout: 265 seconds]
claudia has quit [Ping timeout: 265 seconds]
midfavila-laptop has joined #kisslinux
micr0 has quit [Remote host closed the connection]
kimerus has quit [Remote host closed the connection]
progenyx has quit [Quit: progenyx]
progenyx has joined #kisslinux
micr0 has joined #kisslinux
micr0 has joined #kisslinux
micr0 has quit [Changing host]
micr0 has quit [Quit: micr0]
micr0 has joined #kisslinux
micr0 has joined #kisslinux
micr0 has quit [Changing host]
strajder has quit [Quit: leaving]
micr0 has quit [Ping timeout: 258 seconds]
micr0 has joined #kisslinux
micr0 has joined #kisslinux
micr0 has quit [Changing host]
Guest2571 has joined #kisslinux
andrei has joined #kisslinux
andrei is now known as Guest7639
Guest7639 is now known as Andrei_
<Andrei_> alright
<Andrei_> tech support time
<Andrei_> I've been trying to get Xorg working for hours but no avail
<Andrei_> it only works when change the ownership of /dev/dri/card0 to my user
<Andrei_> I'm using nouveau
<Andrei_> At first I though it was a kernel issue but I then recompiled my kernel with all the options enabled and the error still happened ;(
<soliwilos> I'm not using Xorg, but if your /dev/dri/card0 belongs to video or some such, is your user in that group?
<Andrei_> my user is in the video group
<Andrei_> :/
<Andrei_> soliwilos: /dev/dri/card0 does not belong to video for some reason
<Andrei_> it belongs to root
Guest2571 has quit [Quit: Client closed]
<soliwilos> I've got mine as root:video, that can be handled by your device manager.
<Andrei_> how would I configure that
<Andrei_> right now it's root:root
<Andrei_> I'm using eudev as the device manager
<soliwilos> Depends on which one, for mdevd/mdev it's /etc/mdev.conf
<Andrei_> ah alright
<Andrei_> weird that this is not in the wiki
claudia has joined #kisslinux
<Andrei_> since this seems like an important step
<claudia> Andrei_, have you read https://k1sslinux.org/faq#9.1 ?
<Andrei_> some of it
<claudia> like compiling the firmware into the kernel =y would prob do it.
<Andrei_> xlaudia: i thought firmware was only for propriatary drivers?
<Andrei_> i want to use nouveau
Andrei_ has quit [Quit: WeeChat 3.2]
Andrei_ has joined #kisslinux
<Andrei_> yep I'm very confused
<claudia> I have not bothered with novou before, but for people using amd cards, compiling the firmware into the kernel =y is recommended to avoid these permission problems.
<claudia> Going after gentoo wiki for nvidia this is recommended too.
Andrei_ has quit [Quit: WeeChat 3.2]
<claudia> have a look at the amd section as an example.
<claudia> In the linux firmware tree there is stuff for nvidia cards. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/nvidia
Andrei_ has joined #kisslinux
<claudia> Andrei_, check logs what I have written.
<Andrei_> i cant
<Andrei_> im on the tty
discolor has joined #kisslinux
<Andrei_> brb
<Andrei_> ah thanks
<Andrei_> i will install the firmware
<Andrei_> claudia: installing firmware did nothing
<Andrei_> the issue is with the device manager
<Andrei_> because a simple ls -l on /dev/dri/card0 clearly lists that it's owned by root:root
<Andrei_> instead of root:video
<Andrei_> and the Xorg.log says that it's a permission error
<Andrei_> weird thing is that even after chowning /dev/dri/card0 to root:video it still doesn't work for non root users
<claudia> Andrei_, then I am out of sight. sry.
<Andrei_> rip
<Andrei_> alright
<Andrei_> time to nag dilyn for help lol
<claudia> Did you specify firmware_dir and put the firmware to this dir?
<claudia> the usual questions (:
<Andrei_> I still don't understand how firmware would help this
<claudia> you are modprobing the firmware atm, right?
claudia has quit [Read error: Connection reset by peer]
<Andrei_> because 1) I'm using open source drivers not the propriatery ones 2) The Xorg.log states that it can't open it because of permission denied
claudia has joined #kisslinux
<Andrei_> wdym modprobing the firmware?
<Andrei_> I though I just had to move it to /usr/lib/firmware?
<claudia> Your current solution with building nuvououo is as module and this is not loaded at the right time.
<Andrei_> oh I modprobe it in /etc/inittab
<Andrei_> I don't think that's the issue
<claudia> When build into the kerenl =y the modules is availbe to the right time.
<claudia> Y, you move the firmware stuff to usr/lib/firmware, set novuou stuff to =y instead of =m and you have to specify the firmware in "config_extra_firmware"
<claudia> There is an example how to build an iwlwifi blob into the kernel https://k1sslinux.org/wiki/kernel/thinkpad
<Andrei_> wheres's config_extra_firmware?
<claudia> in your .config
<claudia> when its not there, just create it. Drivers which require extra firmware need this.
<Andrei_> and i just set it to where I copied the firmware to? So /usr/lib/firmware?
<Andrei_> claudia:
illiliti has joined #kisslinux
discolor1 has joined #kisslinux
discolor1 has quit [Client Quit]
claudia has quit [Read error: Connection reset by peer]
discolor has quit [Ping timeout: 252 seconds]
Andrei_ has quit [Quit: WeeChat 3.2]
Guest49 has joined #kisslinux
Guest49 has quit [Client Quit]
dante0012 has joined #kisslinux
dante0012 has quit [Client Quit]
micr0 has quit [Remote host closed the connection]
<dilyn> if you're modprobing nouveau then that is exactly the cause of your problems
micr0 has joined #kisslinux
micr0 has joined #kisslinux
micr0 has quit [Changing host]
<dilyn> download the firmware tarball, extract it to /usr/lib/firmware. find in /usr/lib/firmware your nvidia card's firmware.
<dilyn> enable CONFIG_EXTRA_FIRMWARE to point to /usr/lib/firmware and set the FIRMWARE_DIR to foo/bar.bin, where foo is whatever folder has your nvidia firmware, and bar.bin is the firmware blob
<dilyn> sorry that's backwards; CONFIG_EXTRA_FIRMWARE_DIR should point to /usr/lib/firmware, CONFIG_EXTRA_FIRMWARE points to the firmware blobs
micr0 has quit [Quit: micr0]
micr0 has joined #kisslinux
micr0 has joined #kisslinux
micr0 has quit [Changing host]
progenyx has quit [Quit: progenyx]
micr0_ has joined #kisslinux
micr0 has quit [Read error: Connection reset by peer]
ilko has joined #kisslinux
ilko has quit [Quit: Client closed]
micr0_ has quit [Quit: micr0_]