<illiliti>
but this way allows to keep current repository layout without modifications
<illiliti>
i mean no "provides" file
<dilyn>
I've packaged many, many things. There is... still only one application that I've dealth with that cares about a provides file
<dilyn>
the rest care about a specific package
<dilyn>
I don't understand what the inconvenience is
<illiliti>
i don't care. i don't use "provides" functionality
<midfavila>
like I said,
<midfavila>
*not a big deal*
<midfavila>
it's just something that would be useful *sometimes*, in my *opinion*
<acheam>
provides is nice for using alternate implantations
<acheam>
for example: samurai provides ninja, byacc provides bison, etc
<dilyn>
that's just the alternatives system :P
<illiliti>
i think we need to decide which udev implementation to use(?)
<illiliti>
eudev is stable, easier to setup and use, supports everything
<illiliti>
libudev-zero is recently became stable, harder to understand for newbies, doesn't support everything
<illiliti>
eudev can be used with libudev-zero if compiled statically
<dilyn>
that's fair criticism of libudev-zero, but KISS isn't newbie friendly in general :v
<illiliti>
yeah
lieux has joined #kisslinux
<dilyn>
i'm not convinced that, had dylan originally had the choice between libudev-zero and eudev, he would've even included eudev
<illiliti>
libudev-zero does support everything in main repo, not sure about community
<dilyn>
almost everything, except apparenlty android-tools, tlp, and usbutils
<dilyn>
at least for things which explicitly demand eudev
<dilyn>
the problem I would have with relegating eudev to community && making libinput require libudev-zero is that it's so powerful and NOT "evil", it would just be less convenient than the current way
<acheam>
dilyn: no its not the alternatives system
* midfavila
sighs...
<acheam>
because I still want my byacc package to be called byacc
<midfavila>
there's a second chroot down to the second problem
<midfavila>
that being kiss overwriting perms...
<acheam>
but it needs to be called bison to resolve dependencies correctly
<dilyn>
that was mostly a joke
<dilyn>
a bad joke
<acheam>
ah okay
<dilyn>
wdym mid?
<midfavila>
jexactly what I said
<midfavila>
directories and files are having their groups and owners overwritten
<midfavila>
i'm done for now
<midfavila>
three days wasted on this
<illiliti>
android-tools are so bloated and overengineered. i can't believe we have it in community
<acheam>
testuser[m]1: defend yourself
<acheam>
ehr hes sleeping probably
<illiliti>
Additionally the following software is required at compile-time:
<illiliti>
A C and C++ compiler (either GCC >= 10.X or clang)
<illiliti>
The Go compiler
lieux has quit [Quit: Client closed]
<illiliti>
CMake
<illiliti>
Perl
<dilyn>
when you just finished your coding bootcamp and you want to flex how much you know
<testuser[m]1>
I guess you could yank the docs from arch's binary package or something into a package llvm-docs
sad_plan has joined #kisslinux
<testuser[m]1>
Other than the fact that pax isn't that commonly available, it's good
<acheam>
testuser[m]1: that feels like cheating :(
<acheam>
s/:\(/:\)/g
<testuser[m]1>
Better than your current approach
<testuser[m]1>
:p
<GalaxyNova>
also btw is `shift` posix?
<illiliti>
yes
<GalaxyNova>
phew :D
<illiliti>
it's a shell builtin
GalaxyNova has quit [Read error: Connection reset by peer]
<testuser[m]1>
What do you need the llvm docs for anyway acheam, not like you deal with llvm-* stuff directly
<acheam>
my llvm package has clang and stuff too
<testuser[m]1>
Is sphinx needed just for html docs or man pages too?
schillingklaus has quit [Remote host closed the connection]
Uks3 has joined #kisslinux
Uks2 has quit [Ping timeout: 258 seconds]
<acheam>
both
<acheam>
but I only generate manpages
jleightcap has quit [Ping timeout: 256 seconds]
jleightcap has joined #kisslinux
gtms has joined #kisslinux
schillingklaus has joined #kisslinux
micro_O has joined #kisslinux
micro_O has quit [Ping timeout: 258 seconds]
GalaxyNova has joined #kisslinux
Uks3 has quit [Quit: Byee]
Uks2 has joined #kisslinux
astronaut has quit [Remote host closed the connection]
micro_O has joined #kisslinux
micro_O has quit [Ping timeout: 252 seconds]
<sad_plan>
when building a package that has no deps at all, like openresolv, is there any reason to specify it being static, when going for a staticly linked system? I mean, does it make any difference when building if i export cflags -static, as opposed to not?
GalaxyNova has quit [Ping timeout: 256 seconds]
<testuser[m]1>
it still depends on libc
<testuser[m]1>
not automatically static
<testuser[m]1>
Also static should be in ldflags
<sad_plan>
so that would mean, in openresolv, its 'make LDFLAGS="$LDFLAGS -static"', correct?
<testuser[m]1>
Yeah
<sad_plan>
ok, cool.
<illiliti>
openresolv is written in posix shell. it's unaffected by static flag
<illiliti>
static flag will affect only programs that were written in compiled languages
<illiliti>
but actually it depends on language
<sad_plan>
I wasnt aware of openresolv being a shellscript. tbh I didnt check :p but yeah, I was sortof thought as much about static linking only was relevant for compiled langauges
<illiliti>
why do you need openresolv? just set your dns manually in /etc/resolv.conf and make it read only
<sad_plan>
I never really thought about it. I sortof just followed the guide, and it said its recommended to use openresolv. but since you mentioned it. im going to check that out momentarly
<illiliti>
openresolv is usually unneeded thing unless you have dhcp server that changes dns frequently
testuser[m] has quit [Quit: node-irc says goodbye]
rgybmc[m] has quit [Quit: node-irc says goodbye]
<illiliti>
personally, i use dnscrypt-proxy as a dns server
<illiliti>
because my isp does mitm on dns queries
<sad_plan>
I dont have a dhcp server, so I suppose I dont need it :p
<sad_plan>
ah thats a bummer. I always been curious about dnscrypt, but never really figured out how it works
<testuser[m]1>
You need dhcp unless static ip
<sad_plan>
isnt eiwd handling that on its own?
<sad_plan>
I could swear thats listed on the kiss website, and in wikis
<sad_plan>
aah, no now I see. to use eiwd's builtin resolv functions, I do need openresolv. if not, I would have to install dhcp as you stated
Uks2 has quit [Ping timeout: 256 seconds]
rgybmc[m] has joined #kisslinux
Uks2 has joined #kisslinux
<illiliti>
false. you don't need openresolv to use eiwd
<sad_plan>
so the post-install is wrong? it says you need it to use the builtin dns feature. is that no longer the case? or has that simply never been the case? :p
<illiliti>
> or has that simply never been the case
<illiliti>
this
<illiliti>
fyi, original iwd requires either systemd or openresolv
<illiliti>
i removed this nonsense in eiwd
<schillingklaus>
yeah, systemd is nonsense to be deleted wherever encountered. I do not know what openresolv is, though
schillingklaus has quit [Quit: schillingklaus]
<sad_plan>
aah, ok
<sad_plan>
what is this thread support that libelf requires? libelf fails for me all the time, when trying to build it staticly. cant find anything in dilyns repos either, about that issue in particular
<testuser[m]1>
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-musl/11.1.0/crtend.o: relocation R_X86_64_32 against `.ctors' can not be used when making a shared object; recompile with -fPIC
<testuser[m]1>
pass --disable-shared
<testuser[m]1>
you cant pass -static to build a shared library
<sad_plan>
that is true. perhaps I overlooked that when making the repo.
jleightcap has quit [Ping timeout: 240 seconds]
jleightcap has joined #kisslinux
Uks2 has quit [Quit: Byee]
Uks2 has joined #kisslinux
<sad_plan>
I have another question for you, which you perhaps could answer. I know that I cant for the life of me hope to compile everything staticly. so I was thinking about either not using -static flag in my cflags, or fork all those packages that I cant built staticly, and just sed away the -static flag on those packages. whats your thought on this? I currently require rust, because of firefox, and I know that staticly linking might not a
<sad_plan>
if I took away -static in my cflags, I would obviously had to specify that on every damn package that I want to build staticly though, aand now that I think of it, there might be more packages that I would end up building staticly anyway
<testuser[m]1>
set a kiss hook to disable static
<sad_plan>
aah, yeah that would be an idea. disable it for just those few packages that I dont want to build staticly
<testuser[m]1>
your depends file will be messed up with false dependencies anyways if you dont fork everything
<sad_plan>
how so? because the packages already exist, but said package cant locate them?
<testuser[m]1>
in normal repo foo needs libbar but you're static so it only needs libbar make
soliwilos has joined #kisslinux
smartin has joined #kisslinux
<sad_plan>
aah, I see. so all packages that already exist, staticly, just needs to add make to all of those libs essentially
<sad_plan>
for new packages that is
<sad_plan>
thats non-static
<sad_plan>
libelf still fails thought. Ive rebuilt whole core to be sure
<sad_plan>
same error
<testuser[m]1>
Weird
<testuser[m]1>
Check dilyn kiss-static repo
<testuser[m]1>
Nothing special there for libelf hmm
<testuser[m]1>
Do you mind sending the modified build file of yours
<sad_plan>
I dont belive I did anything in particular, but sure. buildscript comming up
<testuser[m]1>
Oh
<testuser[m]1>
You had to pass to configure script
<testuser[m]1>
Not to ldflags
<testuser[m]1>
Add --disable-shared in the build file args
<sad_plan>
for libelf I assume?
<testuser[m]1>
Yeah
<sad_plan>
hm, doesnt appear to work. still gives me same error. hold on, and ill push the change, and give you the link. maybe you notice something that I dont
<testuser[m]1>
hmm so its still trying the same thing
<testuser[m]1>
lemmme check the configure
<sad_plan>
cheers
<testuser[m]1>
oh it doesnt check static or shared configure options
<sad_plan>
so it just ignores if I pass static, and just assumes its shared?
<testuser[m]1>
it builds both
<testuser[m]1>
theres not really any need to fork libs, since if you build programs that need them with -static it'll use static lib instead of shared one
<testuser[m]1>
except the libs where static libs are explicitly disabled
<sad_plan>
strange. aah ok. but libelf is required to build the kernel it seems, so Im sortof depndent on it. I was trying without it, but for some reason I have yet to get it to work. Ill give you the details
<sad_plan>
gives me this error
<sad_plan>
error: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel
<cem>
illiliti: No, I'm using iwd and I don't have openresolv
<cem>
iwd can use dhcpcd
<illiliti>
cem: did you set EnableNetworkConfiguration=true in iwd.conf?
<illiliti>
dhcpcd is superfluous
<cem>
I don't have a configuration at all
sad_plan has quit [Quit: ]
<cem>
I just used void's patch to use dhcp by default
<dilyn>
well if you don't use AMDGPU and you don't mind using a worse unwinder... (:
<sad_plan>
i amd using amdgpu :( I dunno what the unwinder is anywah either :p
Uks2 has joined #kisslinux
<dilyn>
womp
<testuser[m]1>
you can just rm the .so files
<sad_plan>
what .so files?
<testuser[m]1>
the ones built by libelf
<testuser[m]1>
and just keep the static lib
<illiliti>
what is the state of kiss? seems like development slowly diverging(?)
claudia has joined #kisslinux
<sad_plan>
but libelf doesnt build for me..
<testuser[m]1>
It does
<testuser[m]1>
Just remove -static
<sad_plan>
ah ok. ill do it when I get back on my laptop. cheers
sad_plan has quit [Quit: Quit]
<dilyn>
pro tip: -static is a useless flag
<cem>
Why?
<dilyn>
because nobody really knows what it does, and some build systems just don't care about it
<dilyn>
like meson! it gives no fucks. It just finds the library, you don't get to choose
<cem>
Yeah, sadly true for quite a lot of software
<cem>
But I also kind of don't want to link anything on the X side statically
<dilyn>
hhhhmmmmm, why?
<cem>
The size
<dilyn>
I think linking X stuff statically is the ideal case tbh
<dilyn>
it should be smaller!
<cem>
slock statically linked 1.1M
<cem>
slock dynamically linked 52K
<dilyn>
what all does slock depend on?
<cem>
libX11 and that's it
<testuser[m]1>
lol glibc libx11 static is 10M
<testuser[m]1>
eww
<testuser[m]1>
oh this time it isnt glibc
<testuser[m]1>
its just fat
<dilyn>
well that' aint true cem; the whole dep chain for libX11 then is something like 9 packages
<cem>
Okay linking dynamically just a sec
<cem>
libXext and libXrandr
<cem>
I can ldd for the indirect dependencies as well
strajder has joined #kisslinux
<cem>
libc, X11, Xext, Xrandr, xcb, Xau, Xrender
<dilyn>
comparing static to nonstatic directly is always going to show the static version as being bigger; you have to talk about size differences holistically if you want gains
<dilyn>
that is to say, you no longer need a ton of dependencies, so you can include those size savings for slock
<dilyn>
but yeah, a static object on its own will probably be a bit bigger
<cem>
Kind of true, I guess
<dilyn>
my static KISS chroot tarball is 34MB (w/o a toolchain) and just over 100MB with, but a regular KISS chroot tarball is over 200 uncompressed
<dilyn>
so a lot of that space lives in /lib
<cem>
Well the total is 2.1M
<cem>
But, if you are going to have multiple X binaries, you're still better off linking them dynamically, no?
<cem>
5 dynamically linked slock binaries plus the libraries are smaller than 5 statically linked slock binaries
<dilyn>
I mean i think you're better off in general dynamically linking a lot of things xD
<cem>
You don't see that difference quite a lot on linking smaller software such as ones that use libcurl or libssl
<cem>
Things go from 100K to 200K, not from 52K to 1M
<cem>
That's why I don't get much excited on linking X programs statically
<cem>
Maybe I'm wrong to think that way idk
<cem>
Since storage is not a big issue anyway
<dilyn>
luckily people decided for us which way was better haha
<dilyn>
so now we just get to sit in shadowy corners of the internet and reee into the ether about how static is superior bla hoopla
micro_O has joined #kisslinux
micro_O has quit [Ping timeout: 240 seconds]
illiliti has quit [Quit: leaving]
claudia has quit [Ping timeout: 256 seconds]
micro_O has joined #kisslinux
micro_O has quit [Ping timeout: 272 seconds]
claudia has joined #kisslinux
<claudia>
acheam, you said you got distcc working. Could you share your build? and maybe say something if you created special users/group.
<testuser[m]1>
claudia duper tux kart is missinf dependency on glew
<testuser[m]1>
In kiss games
<claudia>
fixed. thanks
Uks2 has quit [Ping timeout: 268 seconds]
<claudia>
I changed removed glu and added glew, since glew depends on glu.
<msk_1411[m]>
is there a significant difference in functionality?
<msk_1411[m]>
he seems to just be using stuff like cp and mkdir instead
<dilyn>
you'd probably have to rely on -p a lot
<testuser[m]1>
<msk_1411[m] "is there a significant differenc"> Its more portable
midfavila has joined #kisslinux
<midfavila>
Anyone running into trouble with hummingbird init? My new image makes it to a tty and prompt, and I can do some stuff (edit files, display images on the framebuffer, make Internet connections over ethernet, etc) but the second I try to run X or any sort of daemon like iwd, I drop to a root prompt for a split second with the error "init failed", before being forced into a reboot
midfavila has quit [Read error: Connection reset by peer]
midfavila has joined #kisslinux
midfavila has quit [Read error: Connection reset by peer]
midfavila has joined #kisslinux
<acheam>
testing it, I see
<midfavila>
it's reproducible, then?
<midfavila>
fwiw shifting to shinit works for me
claudia02 has joined #kisslinux
<claudia02>
dilyn: I have seen you a few times using german words in an english conversation. Like your post on reddit, using the word "verboten".
<claudia02>
Is this something english speakers usually understand?
strajder has quit [Quit: leaving]
<dilyn>
depends on the audience xD
<omanom>
there's some generally well-known words
<dilyn>
but I think americans frequently comandeer words from other languages, either knowingly or not
<omanom>
verboten, achtung, wunderbar
<midfavila>
english speakers in general borrow words a lot
<dilyn>
ciao, gesundheit, hola
<claudia02>
y verboten is prob a pretty popular word.
<omanom>
plus with the number of movies / tv shows / books with WWII as a subject there tends to be some exposure
<claudia02>
gotcha. make sense.
<claudia02>
this always made me stumble
<dilyn>
us americans are a tricky folx
* midfavila
rolls their eyes
Uks3 has quit [Quit: Byee]
Uks2 has joined #kisslinux
<omanom>
from the US perspective, German immigrants were a large percentage of the settlers all across the country
<dilyn>
indeed!
mahmutov has joined #kisslinux
<midfavila>
hmm. and now I'm running into a second weird error... anyone ever have X fail to start with "Failed to set IOPL for I/O function (not implemented)"?
<omanom>
i have not, what's your full Xorg log?
<msk_1411[m]>
what are the permissions on xinit
<midfavila>
looks like it's something to do with the way that programs in protected and long mode on IA32 and amd64 chips access system IO... which makes some degree of sense, but I'm not sure why there'd be problems stemming from that. unless it's something to do with my workstation's slightly different ISA than my laptop's (Haswell-E compared to Haswell)
<msk_1411[m]>
* what are the permissions on your xinit executable
<midfavila>
fwiw I'm just trying to run X -configure, not xinitrc
<midfavila>
i don't use xinit
<midfavila>
as for the logs, will post after I've rebuilt the binary on my laptop - I want to make sure it's not some weirdness with ISA differences, omanom
<omanom>
gotcha, ok
<omanom>
gotcha, ok
<midfavila>
crusin' down the binary highway at a blazing 800mhz
<midfavila-laptop>
looks like something to do with stripping..?
<midfavila-laptop>
but checking the mentioned drivers with file says that they're not stripped, and I don't know when or how non-executables would have been stripped, besides
<midfavila-laptop>
i've made stupid mistakes, but nothing like that before
<omanom>
do you have xf86-video-intel built?
<midfavila-laptop>
Yeah. That's what's providing my intel video driver.
<midfavila-laptop>
I've already tried rebuilding it, but no dice. Gonna see if libpciaccess or libdrm are the culprit...
<omanom>
did you rebuild xorg-server too? weird issue, for sure
<midfavila-laptop>
Yep
<midfavila-laptop>
This latest image has been nothing but trouble
<midfavila-laptop>
randomly overwriting perms or files, hummingbird was acting funky, and now this
<midfavila-laptop>
hmm. seems like the symbol it's complaining about is normally provided by libfb.so
<midfavila-laptop>
which is available and hasn't been hit with any weird mutations...
<dilyn>
do anything strange with your graphics selections in the kernel?
<midfavila-laptop>
nothing at all. just bog standard, as per defconfig
<midfavila-laptop>
this occurs with my previous kernel, as well
<midfavila-laptop>
which wasn't giving me trouble on my last install
<midfavila-laptop>
it can't be a kernel error
<dilyn>
i mean, why not?
<cem>
what's wrong with shinit anyways :^)
<midfavila-laptop>
because if it was an error with my latest kernel, switching to the known-good kernel would fix it
<midfavila-laptop>
it does not, and has the same error, meaning it must be something else
<midfavila-laptop>
and there's nothing wrong with shinit, it was hummingbird that was giving me trouble. kept dropping to an emergency shell and forcing a reboot under certain seemingly-unrelated conditions
<midfavila-laptop>
but at least ALSA isn't giving me trouble lmfao
<midfavila-laptop>
the worst part about this error is that there's nothing useful about it on the net
<midfavila-laptop>
just some old posts about ARM debian from 2004 and some mint user whose suggestion was "turn it off and on again a few times"
<midfavila-laptop>
and some stuff about SELinux, which... I don't even have enabled in the kernel.
<cem>
Maybe because you are booting with "ro" option?
<midfavila-laptop>
init remounts root rw
<cem>
tru
<midfavila-laptop>
and i was booting with ro before, besides
<midfavila-laptop>
hmm.
<cem>
I had a similar issue with ro but that was a long time ago
<midfavila-laptop>
i don't even think this is an X error. it's gotta be one of the supporting libraries or programs...
<midfavila-laptop>
the framebuffer device is available and works, too...
<dilyn>
i mean it's literally a missing symbol error, in the driver (presumably) supplied by xf86-video-intel, and that missing symbol is in one of the xorg-server libs
<cem>
The problem is that I don't remember the details, it was on Void
<midfavila-laptop>
xf85EnableIOPorts: failed to set IOPL for I/O (Function not implemented)
<cem>
So maybe since I came late to this conversation that I don't exactly understand what's going on
<cem>
X fails on shinit, but not on hummingbird?
<midfavila-laptop>
no
<cem>
Sorry the vice versa
<midfavila-laptop>
X is a seperate issue
<cem>
Oh okay
an3223 has quit [Quit: leaving]
<midfavila-laptop>
i honestly have no clue what's going on with X. the missing symbol thing is obviously a problem, but if vesa doesn't run into that issue, but KMS and the Intel driver do, then it's clearly small-fry compared to this IOPL problem
<dilyn>
how are you starting X?
<dilyn>
it's either a symbol error or a permissions error, and if you rebuilt a bunch of things then it's probably perms
<midfavila>
X -configure, like I said
<midfavila>
and it's not permissions, I've already checked that.
<omanom>
on my kissbox its under /usr/share/X11 rather than /etc/X11
<midfavila>
X checks under /usr/share/X11 and /etc/X11
<midfavila>
...wait a second...
<midfavila>
...
<midfavila>
...could it... no, never mind.
<omanom>
lol you can't just say never mind, spit it out!
<midfavila>
i was going to say that it might have something to do with me fiddling with how the TTY handles the framebuffer, to increase available columns and spaces
<midfavila>
but that's still a kernel-level thing, and the known-good kernel (still encountering the same problem) had stock framebuffer settings
<midfavila>
so that can't be it either
<omanom>
i wouldn't think so, "fbPutImage: symbol not found" implies a framebuffer (fb) problem but your intel drivers built fine so...
<midfavila>
i'm not even concerned about that at this point
<midfavila>
the bigger issue imho is this IOPL failure
<midfavila>
like I mentioned earlier, the VESA drivers don't run into the symbol error, but they do still hit a brick wall with IOPL problems
<cem>
midfavila: Ugh, try setting setuid?
<omanom>
i dunno, the log fails to load all available drivers /prior/ to spitting out that IOPL issue. maybe im reading it wrong
<midfavila>
cem I'm running X as root rn
<cem>
Oh
<midfavila>
omanom yeah, but it only fails to load the KMS and intel drivers due to the missing symbol error, at which point it succeeds with the VESA driver
<omanom>
the log you provided doesn't show any VESA driver load that i see?
<cem>
which package owns /usr/lib/xorg/modules/drivers/modesetting_drv.so?
<midfavila>
i gave the VESA driver a shot after uploading the logs, omanom, but aside from that one change it's the same
<midfavila>
will check, cem
<omanom>
oh alright, ok
<midfavila-laptop>
xorg-server cem
<midfavila-laptop>
which is to be expected
<midfavila-laptop>
i'm just using the standard xorg repo
<cem>
Ah alright mine were static
mahmutov has quit [Ping timeout: 258 seconds]
mahmutov has joined #kisslinux
midfavila-laptop has quit [Remote host closed the connection]