<wael[m]>
you know what im going to try to make my own kiss fork for fun
<sad_plan>
statically linked hopefully? :p and with bearssl right? :p
claudia has quit [Quit: Leaving]
<wael[m]>
i was going to use libressl
<wael[m]>
i dont know whats the difference all i know is that in SLOC: libressl > bearssl 3x > openssl 13x
<wael[m]>
and probably not statically linked intentionally since literally the major programs are going to be required to not be statically linked for the thing im trying to target
<sad_plan>
bearssl is way less known, thus less support for it, and again then higher chances of you having to patch stuff if needed :p bearssl is really small though. oasis linux uses it
<wael[m]>
i dont want the hassle of patching things, so i guess sticking with libressl
<sad_plan>
rust needs a patch for that. a tiny one though
<wael[m]>
libressl? alright thanks for pointing that out
<sad_plan>
yes, rust needs a patch to build with libressl
<wael[m]>
if im correct it would be in your kiss-dumpsterfire repository riiiight?
<sad_plan>
the benefit of using libressl is that you can find alot of patches in openbsd's repo. they got a repo called ports.
<sad_plan>
yes
<sad_plan>
ive forked those things that needed due to openssl. like rust, nodejs ffmpeg etc
<wael[m]>
time to steal tons of build files
<wael[m]>
i mean fork
<sad_plan>
have at it
<wael[m]>
whats configure-hos, tooldir=/usr in binutils/build for?
<sad_plan>
thats just the way its setup from upstream, with the excepion of the LDFLAGS. Im assuing it has something todo with crosscompiling. tooldir is likely just to point it to your bins
<wael[m]>
well works without it so /shrug
<sad_plan>
yup
<wael[m]>
also i noticed that libressl is 3.4.3, while the latest is 3.5.3
<wael[m]>
is that intentional?
<sad_plan>
yes, 3.5.x is the unstable branch, and broke alot of stuff for me, so I chose to go with the stable branch instead
<wael[m]>
what did it break?
<sad_plan>
I dont recall at the top of my head. I couldve sworn I had it my commits but it seems it does not
<wael[m]>
i dont see how 3.5.x is unstable especially when the last update was in May
<sad_plan>
i think its on their github page. hold on, and ill find it
<sad_plan>
but yes, it seems 3.5.x is stable after all
<wael[m]>
alright ill continue using it
<sad_plan>
im not sure whats the deal here, but it seems that 3.5.2 is the correct version. iirc they had separate branches before anyhow
rohan has joined #kisslinux
<wael[m]>
about that distro, i think ill just be overlaying packages
<wael[m]>
ill start by trying to get libressl working
<sad_plan>
its simpler that way. theres also nothing stopping you from 'making your own distr', but instead of just start from scratch, and fork everything. fork stuff that you care about first, then move on from there. i.e. with libressl as you said, then perhaps move on to use toybox, and add patches, and changes to reflect toybox. and so on. just an example
rohan has quit [Ping timeout: 240 seconds]
<wael[m]>
in curl, was enable-symbol-hiding removed for libressl and enable-optimize for misc?
<sad_plan>
I dont recall actually. but Im assuming I just wanted less stuff, and more optimization or something
<wael[m]>
alright
<wael[m]>
also i know this is going to be answered with 'personal preference' but how are configure flags supposed to be structured? enable disable with without or disable enable without with im pretty confused
<wael[m]>
i want to make the build files consistent and not messy like what i saw when forking some packages
<sad_plan>
Ive set them up like upstream does basically. not that it matters, as the configure script will read them just the same regardless. I just put them where I see fit
<sad_plan>
you can also put them in one really long line if you want, but it just makes it less readable
<wael[m]>
each package with their own style?!
<sad_plan>
if you want that, thats up to you
<wael[m]>
hmm
<sad_plan>
nothing seems to have been broken by the recent libressl, so it seems was mistaken. thanks for noticing. else I would probably not have been updating it for a really long time :p
<wael[m]>
:D
<wael[m]>
also how come ffmpeg has openssl as a dependency when its not even listed in the dependency file
<sad_plan>
kiss checks if its links to libs that is owned by different packages, which it will then add those to the dep file. or something like that. Ive had packages list deps I didnt know of, and then checked it out
<sad_plan>
alot of times, packages has auto detection for different things. so if its not installed, itll automatically disable it. now if you install foo pkg, then rebuild foobar, now foobar will list foo as a dep, even though it didnt initally
<wael[m]>
i dont believe kiss can do that its too small for that
<sad_plan>
run kiss revdepends curl, then build libnghttp2, rebuild curl, rerun kiss revdepends curl, and tell me it doesnt :p
<wael[m]>
why is gnupg1 named gnupg1???
<wael[m]>
ive always wondered this since i saw kisslinux for the first time lol
<sad_plan>
because its version 1.x.x and not 2.x.x
<wael[m]>
whwhhwh ohhhhh yeah that wait why not specify it by the build file
<wael[m]>
i mean version file
<wael[m]>
and why 1.X.X? if there is a latest why not?
<sad_plan>
why? libnghttp2 isnt a dependency for curl inherently
<sad_plan>
its not, gnupg has 2.x.x as latest. gnupg2 is packaged iirc, if you should need/want it
<wael[m]>
no im just wondering why not just have a single latest package called 'gnupg'
<sad_plan>
I dunno, as I said, I dont know the reasons behind the splitting. but its the case for other stuff aswell, like libsoup
<sad_plan>
theres all kinds of reasons for splitting a package
<wael[m]>
there is literally no package that has a dependency of gnupg1
<phoebos>
gnupg1 is sufficiently different to gnupg2, in particular it has fewer dependencies so better suited to the main repo
<phoebos>
because gnupg1 isn't a library lol
<sad_plan>
^ there you have it
<phoebos>
the reason it's in the main repo is because dylan signed all his commits, so you could verify them (it's the first thing in the install guide)
<wael[m]>
but it seems it doesnt really search that much
<wael[m]>
ioraff: if you symlink things, why arent they listed as git submodules?
<wael[m]>
> ../../../repo
<wael[m]>
it seems its an outside repository nevermind
<ioraff>
it used to index every github repository with the kiss-repo tag, plus whatever was manually added. I assume the tag check was removed.
<ioraff>
right. maybe submodules would be a good idea.
<wael[m]>
personally i want to avoid using symlinks or submodules so i dont have a really dumb looking KISS_PATH
<wael[m]>
say, if for example i had package zlib fork which is at a higher priority set in KISS_PATH and it got updated in another repo, would it update?
<wael[m]>
KISS_PATH=repo/custom:repo/upstream
<wael[m]>
if custom packages got outdated but upstream had the same packages whilst being up to date would they update? or get ignored
ioraff has quit [Ping timeout: 245 seconds]
ioraff has joined #kisslinux
<ioraff>
they'd update if the version file is symlinked
<wael[m]>
so basically, no?
rohan has quit [Ping timeout: 252 seconds]
<ioraff>
correct
<wael[m]>
thanks
rohan has joined #kisslinux
<wael[m]>
it would have been real worrying if it was true
<ioraff>
only the package in the highest priority repo matters.
<wael[m]>
what the heck rust failed with your patch even though the build file explicitly says to ignore checksums i think?
<wael[m]>
let me check the build file in your repo
<wael[m]>
ohhhhhhh its only for curl-sys not open-ssl okay
<ioraff>
what's only for curl-sys?
<wael[m]>
checksum checking
<wael[m]>
the build file i copied had it disabled for curl-sys explicitly
<ioraff>
you need to disable it for libssh2-sys
<ioraff>
too
<wael[m]>
libxslt 1.1.35-1 => 1.1.34-1
<wael[m]>
python 3.10.6-1 => 3.10.5-1
<wael[m]>
why is kiss trying to downgrade?
<wael[m]>
oh yeah the python i installed is not in KISS_PATH nvm
<wael[m]>
ioraff: just adding it to the for loop your build file has :D
<ioraff>
isn't it already in the for loop?
<wael[m]>
yes.
ejjdhfjsu has quit [Ping timeout: 252 seconds]
ejjdhfjsu has joined #kisslinux
ioraff has quit [Quit: ioraff]
<wael[m]>
rust successfully compiled
<Ogromny>
hi
an3223 has quit [Remote host closed the connection]
an3223 has joined #kisslinux
fitrh has joined #kisslinux
soliwilos has quit [Remote host closed the connection]
soliwilos has joined #kisslinux
<wael[m]>
hi @Ogromny
<wael[m]>
anway mfw libressl Xorg can't open libcrypto.so.3
<wael[m]>
nvm had to recompile with libressl
ejjdhfjsu has quit [Remote host closed the connection]
an3223 has quit [Ping timeout: 268 seconds]
an3223 has joined #kisslinux
Guest10002 has joined #kisslinux
Guest10002 has quit [Client Quit]
Guest10002 has joined #kisslinux
Guest10002 has quit [Client Quit]
<phoebos>
i keep thinking about reviving kiss-find, it was useful
<phoebos>
i don't understand github actions though
<phoebos>
could just try to get admicos' version back
an3223 has quit [Ping timeout: 268 seconds]
fitrh has quit [Read error: Connection reset by peer]
fitrh_ has quit [Read error: Connection reset by peer]
fitrh has joined #kisslinux
<wael[m]>
wait using that i can find that someone has made mutlilib before on KISS
<wael[m]>
wow
<wael[m]>
however its just a kiss fork 'mkiss'
<Ogromny>
What do you think about writing a helper like `kiss find blabla`, and it'll return every git where blabla is found ?
<Ogromny>
A kiss-find but localy
<Ogromny>
Instead of doing a website where we can search package, why not creating a db.csv or whatever, and create a package `kiss-finder` who will be updated every x hours with the new db.csv ?
<phoebos>
Ogromny: that's what kiss-find is
<phoebos>
the website was a thing jedahan made
<Ogromny>
Yeah but why not create a package kiss-find who give you the helper kiss find ?
<phoebos>
if i get around to setting up gh actions, i'll put it in community
<wael[m]>
wooooooo
rohan has quit [Ping timeout: 268 seconds]
rohan has joined #kisslinux
an3223 has quit [Remote host closed the connection]
an3223 has joined #kisslinux
ioraff has joined #kisslinux
fitrh has quit [Quit: fitrh]
<wael[m]>
is it possible to build pulseaudio only for its libraries?
<illiliti>
apulse?
<wael[m]>
yep
<wael[m]>
i think i managed to do just that, pulseaudio tarball doesnt have pulseaudio in the file list
<ioraff>
if the program is linked against libpulse, wouldn't it need either pulseaudio running or to be running under apulse to function?
<wael[m]>
im running firefox with music playing right now under apulse without pulseaudio running
<wael[m]>
but if apulse isnt detected it tries to launch pulseaudio automatically
<wael[m]>
im not sure why it overrides alsa even though its compiled with support for it.
<ioraff>
it assume it gives priority to pulse since its alsa support is lackluster
<wael[m]>
thing is, it worked fine on a previous distro, alsa used but if pulseaudio daemon running it uses that
<ioraff>
so just don't run it under apulse?
<wael[m]>
firefox? it wont work without apulse even though alsa is compiled like i said
<ioraff>
did you compile it with support for both?
claudia has joined #kisslinux
<wael[m]>
for both yes
claudia has quit [Remote host closed the connection]
claudia has joined #kisslinux
<Ogromny>
ioraff: If you want just to have the libs of pulseaudio you can disable de "daemon" during the compilation, and I think you can also disable every tools of pulseaudio, I think like this you'll only get the lib and nothing else
<wael[m]>
> you can also disable every tools
<wael[m]>
with flag -Ddaemon=false some tools are still compiled, not sure how to disable them