<testuser[m]>
any idea why installing baselayout with KISS_ROOT set doesn't set correct perms for /tmp etc?
<Ogromny>
Hi
<Ogromny>
Do any of you use River ?
<Ogromny>
If yes, how did you compile it ? It requires libevdev, but on Kiss we use libudev-zero right ? It will fuck up the system if I install libevdev too ?
<Ogromny>
I have absolutely 0 knowledges on evdev/udev/libinput things
<testuser[m]>
evdev is unrealted to libudev-zero
<testuser[m]>
it needs libevdev, but that's currently bundled into libinput
<wael[m]>
does mako get split into another package in that PR?
<testuser[m]>
yea
<testuser[m]>
3 python packages
<wael[m]>
or does it remove the ability to build dependencies at build time and instead does them in package
<testuser[m]>
so bad
<wael[m]>
so bad indeed
<Ogromny>
Any of you use zig ?
<Ogromny>
Zig's working fine except when I try to link libc I got a segfault. GDB say absolutely nothing, it seems that there is only a _start function in the binary
<testuser[m]>
you're using the official binary?
<testuser[m]>
it happens with that for some reason
<Ogromny>
I built zig with the package from community
<Ogromny>
I tried with a master build of zig, same issue
<testuser[m]>
i mean i was trying iwth busybox tar outside of kiss
<phoebos>
ok
<testuser[m]>
yea busybox tar is shit
<testuser[m]>
λ ls -ld busy/tmp
<testuser[m]>
drwxrwxrwt 2 testuser testuser 40 Oct 3 18:58 gnoo/tmp
<testuser[m]>
drwxr-xr-t 2 testuser testuser 40 Oct 3 18:58 busy/tmp
<testuser[m]>
λ ls -ld gnoo/tmp
<testuser[m]>
btw how does `grep -q ":/var/db/kiss/installed/" "$_tmp_file" || safe=1` ever match ? my grep doesn't seem to do anything if i try `echo test | grep :t`
<testuser[m]>
: means line starting with substr i think
midfavila has joined #kisslinux
<testuser[m]>
maybe he meant to use ^
<testuser[m]>
OH
<testuser[m]>
its cuz when grepping on multiple files it appends : after filename
<testuser[m]>
ignore the partial matches i have to figure that out
<midfavila>
-E being slower would make sense considering it uses a more complex regex engine.
<testuser[m]>
116x diff
<illiliti>
which grep?
<testuser[m]>
busybox
<illiliti>
try gnu
midfavila has quit [Quit: Leaving.]
<testuser[m]>
hmmmm yea its 0s vs 0.06s
<testuser[m]>
ig ggrep does this sort of optimization by itself
<illiliti>
just use gnu grep
<illiliti>
no need to attempt to workaround busybox using -E and stuff like that
<illiliti>
iirc freebsd grep is also fast
<testuser[m]>
btw
<testuser[m]>
like wireguard-tools's wg-quick needs /usr/bin/ip set to iproute2
<testuser[m]>
what would be a good way to indicate that somewhere
<testuser[m]>
i mean like without swapping /usr/bin/ip
<testuser[m]>
prefixing all of iproute's binaries?
<illiliti>
post-install message
<testuser[m]>
but it seems hacky
<testuser[m]>
busybox so bad
<testuser[m]>
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
<testuser[m]>
ip: invalid argument '51820' to 'table'
<testuser[m]>
is this something missing inside busybox or an actual bug
<illiliti>
the ideal option would be to make it work with busybox
<illiliti>
probably busybox has no idea about table arg
<testuser[m]>
then thats probably out of scope for a KISS specific patch
<illiliti>
is upstream interested in busybox compatibility?
<illiliti>
but considering how they recklessly harcoded bash and shit, i guess no
<testuser[m]>
I meant more like adding the feature to busybox
<testuser[m]>
I don't think there's a "portable" alternative to that rule
ella-0_ has joined #kisslinux
<illiliti>
so you want to contribute a patch to busybox? do it then
<illiliti>
btw what about toybox
ella-0 has quit [Read error: Connection reset by peer]
<sad_plan>
toybox needs a patch for removing the bash make dep. unless we wanna put bash into the repo..
<sad_plan>
its also.. way less complete
<testuser[m]>
illiliti: can u read today's conversation about tar and sticky bits
<illiliti>
phoebos has sent a fix already and you merged, no?
<phoebos>
i'm still unsure about tar -p
<illiliti>
or fix depends on tar implementation?
midfavila has joined #kisslinux
<testuser[m]>
Its a partial fix
<testuser[m]>
sticky bit is preserved, but only as root with busybox tar
<testuser[m]>
stick bit is not preserved as regular user with busybox tar
<testuser[m]>
but it works in both cases with gtar
<phoebos>
^ only with tar -p
sereg has joined #kisslinux
<illiliti>
i doubt that we can do anything with this bug
<testuser[m]>
~~other than C rewrite~~
<midfavila>
speaking of bugs and C,
<midfavila>
could one you guys take a hot minute to do me a small favor?
<illiliti>
not with tar
<illiliti>
we could use pax
<midfavila>
i need someone to compile XMag with tcc, then attempt to magnify a section of the display and report back any errors
<illiliti>
also i doubt that current fix is good fix
<midfavila>
there seems to be a problem with tcc potentially generating incorrect output with programs that use Xt inheritance operations... whatever that means
<illiliti>
some systems don't support setting sticky bit on files
<illiliti>
this could be problematic
<testuser[m]>
phoebos: are there more cases that rwx needs to handle other than stick and rwx stuff already present? Eg if you were to do something like this, will it work?
<illiliti>
imho we should use chroot() rather than inventing our own using KISS_ROOT
<testuser[m]>
wdym
<illiliti>
i mean chroot() looks cleaner than prepending KISS_ROOT to everything
<illiliti>
chroot(KISS_ROOT)
<testuser[m]>
You mean in terms of post install files?
<testuser[m]>
How else would pkgs get installer
<testuser[m]>
if ur talking about KISS
<testuser[m]>
not the post* hooks
<testuser[m]>
And i think for hooks we should chroot cuz there can be many hooks like for adding users, which won't work without chrot
ioraff has joined #kisslinux
<illiliti>
i mean in general. if i haven't missed anything, chroot(KISS_ROOT) is a cleaner way
<illiliti>
but as you noted, how kiss would access ~/.cache/kiss/bin. does it need such access
ioraff has quit [Client Quit]
<illiliti>
re adding users, imo packages shouldn't modify anything in /etc
<illiliti>
they can only add new files and/or modify only their own files
<illiliti>
that's something we should enforce in sandbox
<testuser[m]>
illiliti: what about openssl certificate updaye
<illiliti>
it's ok cuz /etc/ssl/* is owned by openssl
<illiliti>
to be exact, openssl is a sole app that writes to /etc/ssl/*
<illiliti>
things get messy when apps start write to /etc/shells
<illiliti>
or /etc/passwd
<illiliti>
and on remove, they don't cleanup their shit
<sad_plan>
midfavila: I managed to build tinyx statically, if youre interested in doing so yourself
<midfavila>
that would be something I'd be interested in seeing, yeah
<sad_plan>
set XSERVERCFLAGS_CFLAGS to --static. maybe -static works for you, but for me it didnt seem to work.
<sad_plan>
you may also have to add some libs to XSERVERLIBS_LIBS aswell. I had to add libz, freetype and harfbuzz and libpng. I also set *.a aswell to begin with. dunno if it made any difference tbh.
<midfavila>
could you package the changes and send me a copy?
<midfavila>
thanks, I'll fiddle with it next time I'm looking at tinyx
<midfavila>
for now I've put any X-related stuff off to the side
<sad_plan>
youre welcome :D
<sad_plan>
alot of other stuff to figure out first?
<midfavila>
no, stuff that I'm not capable of figuring out right now
<midfavila>
tinycc doesn't generate executables that use motif or athena properly
<midfavila>
that's not something I can fix
<midfavila>
xwx
<sad_plan>
well I cant help you there unfortunatly.
<sad_plan>
do you have to use those though?
<sad_plan>
I mean, if I cant use tool x, then sometimes I look for tool y or z instead, that might fit the bill
<midfavila>
do i have to use athena/motif, or do i have to use tcc?
<sad_plan>
athena/motif
<midfavila>
technically no to the former, yes for the latter
<midfavila>
i could just use programs that exclusively use xlib directly
<midfavila>
but that's a horrible idea
<midfavila>
motif and athena are the only toolkits that my system can build
<midfavila>
so
<sad_plan>
but they dont generate executables, so dont build properly now do they? but whats wrong with using xlibs tools?
<sad_plan>
I mostly like tools that depend purly on xlibs, as theyre likely simpler to build statically..
<midfavila>
the code is valid and some athena programs work as they should
<sad_plan>
some are anyway, not everyone
<midfavila>
this is a problem in tcc that needs to be resolved
<sad_plan>
hm, ok
<midfavila>
anyway, while i can appreciate that mindset, going toolkit-less isn't viable for larger-scale projects, I think
<sad_plan>
im not saying you should drop something you initially need, but if some other tool can accomplish what you want, why not give that a try? I get that some tools might not be easily replacable though.
<sad_plan>
also dont waste too much time on 1 issue. if you cant figure it out, do something else for some time, then come back to it afterwards
<sad_plan>
I do that all the time. makes troublesome issues.. abit less troublesome imo
<wael[m]>
illiliti: why does mdev still have to run as a service when baseinit specifies mdev to kernel via /proc/sys/kernel/hotplug
<illiliti>
because mdev need to listen to uevents
<illiliti>
/proc/sys/kernel/hotplug is an old way for that
<illiliti>
it can fork bomb system
<illiliti>
because it fork/execs mdev for each uevent
<illiliti>
testuser[m]: mirror to github doesn't seem to work?
<testuser[m]>
illiliti: I forgot to sync it
<testuser[m]>
Codeberg interval is disabled
<testuser[m]>
So i have to click the mirror. Button manually
<illiliti>
got it
<testuser[m]>
I'd set up a cron job but the endpoint for triggering push mirror is only going to be available in the next gitea version
<testuser[m]>
It's present in latest git
rohan has quit [Ping timeout: 252 seconds]
rohan has joined #kisslinux
<testuser[m]>
Synced all repos
<phoebos>
why does codeberg add so many crap tags to merge commit message