jaeger changed the topic of #crux-devel to: CRUX (https://crux.nu/) development channel | Logs: https://libera.irclog.whitequark.org/crux-devel/
guest724 has joined #crux-devel
guest724 has quit [Quit: @]
groovy3shoes has joined #crux-devel
groovy2shoes has quit [*.net *.split]
groovy3shoes has quit [Ping timeout: 248 seconds]
groovy2shoes has joined #crux-devel
jue has joined #crux-devel
jue has joined #crux-devel
jue has quit [Changing host]
<jue> beerman: done ;)
<beerman> jue cheers
<beerman> do you still have a usecase for our old mozjs?
<jue> no, not really
<beerman> ok
<jue> just dropped mozjs
<beerman> Neat
<jue> I bet there will be others than me that will complain ;)
<beerman> Yeah, certainly.
<beerman> Maybe it's time to start working on updating the toolchain. I'll try to look into that this weekend
<beerman> I still don't see why we avoid libbsd in core, but if we don't need to import it I'm fine either way
<jue> because we like to avoid unneeded dependencies ;)
<beerman> i mean, it clearly looks like it is or was intended to be
<jue> even arch has libbsd in extra and not in core, but well i don't have a strong opinion here, if we want libbsd in core that's fine for me, but only at CRUX release boundaries
<beerman> arch hasn't updated yet and we will need to wait for that to happen to see how they decide on handling. Don't get me wrong, I don't have any strong feelings either way but it has potential to solve a few knots.
<beerman> 1. currently, because a lot of software prefers libbsd around, Matt made our port install in some location that other software needs to specify to include it - i think thats fine enough but could be avoided
<beerman> 2. i have encountered software (namely one game I like to play and bought via gog) which demands libbsd around (...yeah..)
<beerman> so there are cases where including it could be a good thing. all i'd like is some discussion around the topic. that lib exists and it is in demand. shadows solution to just yank two of the three functions is kind of weird imo, but sure, either way we will need to wait with the shadow update until we jump onto the newer glibc
<jue> sure
<jaeger> I also don't have a strong feeling about libbsd. If it were something massive it might bother me more
<beerman> i mean, it kind of is massive in its own way, right? a broken libbsd in core has potential to foobar the system into a state where it needs to be recovered
<jaeger> I was thinking massive in size in this case. Yeah, there's always a risk with something that gets eager-linked into a bunch of other stuff. That's never going to be really appealing.
<jaeger> Eventually everything will probably require rust and I'll just cry in the corner.
<jue> :)
<beerman> oof, well.. rust still has a lot of potential. its the foundation that seems to stink it seems
<beerman> lets hope for the best with rust, at least i do, i still like rust
<jaeger> I don't have anything against rust itself... but its cultlike followers freak me out and it takes a LONG time to build
<beerman> yeah well, at least its not a pain to get the source packages like it was with java back in the day :D
<beerman> that hurt me much more imo
<beerman> and while i am back here trying to revive my electron port: that is so much worse, trust me
<jaeger> heh
<beerman> if i can't figure out a way to make it build from tarballs instead of having to git clone all of electrons codebase as well as chromiums... i'll trash the port and never look back
<beerman> the git clones alone took over an hour, and lets not speak about the resources you are pulling with every rebuild/update... headache material times 10
<jaeger> oof
<beerman> rust is like a purring kitten compared to that
<beerman> so any way, wrt libbsd: its basically two rather small libs we'd need to import to core. i don't really care about the numbers, but for the up- and downsides of the import. Downside is that I have no idea how robust it is. Upsides: a lot of things like it so much, they take it when its around. I am fine with either decision we make, but I'll leave that up to you two
<jaeger> Lots of things eager linking to it could also be a downside... if it breaks for some reason
<beerman> jaeger: just a sidenote on electron - tarballs are missing files (probably git subprojects internally) from electron, and they want you to use googles depot_tools to pull the sources. i wanted to see if i can take the files from the tarballs and just sync whats missing - it's going at it for the past 30 minutes now pulling stuff...
<beerman> what it pulls is a mystery :D
jue has quit [Ping timeout: 246 seconds]
<beerman> farkuhar btw, sorry, I pretty much forgot about your report about libetonyek a while ago. you proposed a following http://ix.io/4ByX but you seem to have worked around it for now? is that correct?
<farkuhar> beerman: no worries, I forgot about it myself when I first adopted boost. It was only on Monday that I remembered and pushed the patched version of boost (1.83) to contrib. After that change I can build libetonyek without having boost-1.80 installed.
<beerman> sounds great, thanks, i think i can retire that one then
<farkuhar> cheers to everyone who's working on toolchain updates, and the proposed move of libbsd to core. Looks like we might be approaching one of those "CRUX release boundaries" that jue mentioned.
darfo has quit [Remote host closed the connection]
darfo has joined #crux-devel
farkuhar has left #crux-devel [#crux-devel]