groovy2shoes has quit [Remote host closed the connection]
groovy2shoes has joined #crux-devel
ivandi has joined #crux-devel
ivandi has quit [Client Quit]
ivandi has joined #crux-devel
fishe has quit [Quit: Connection closed for inactivity]
<Romster>
libbsd that abomination links to everything
<beerman>
it could also be a core port /shrug
<beerman>
or we drop scrot
<beerman>
which would also be nice
<Romster>
then what should i be using?
<Romster>
non-wayland still
<beerman>
¯\_(ツ)_/¯
<beerman>
don't you have a mobile?
<Romster>
that's helpful
<Romster>
...
<beerman>
well
<beerman>
i actually tried to spark a discussion about it
<beerman>
but alas, nobody participated
<beerman>
not even you, Danny
<beerman>
so, how much help can i offer?
<beerman>
about it = libbsd
<Romster>
wait scrot worked outout libbsd unless someone bumped it...
<Romster>
reason why i did not want to bumop scrot it worked fine withot libbsd
<Romster>
without
<Romster>
meh
<Romster>
whatever i'll just move it to my person repo
<Romster>
personal even
<beerman>
you are a port messy
<beerman>
learn to say goodbye to old stuff and let it go
<Romster>
if i ahd a bloody replacment i would
<beerman>
the replacement is run wayland
<Romster>
meh gonna go make dinner, got fuck all work done today
<beerman>
also there is replacements that work on X11
<Romster>
and amek it all work on my system with nvidia
<beerman>
nvidia supposedly just works for over half a year now
<beerman>
¯\_(ツ)_/¯
<Romster>
with steam and all that?
<Romster>
how much breakage do i have to endure to get back to where i am now currently at
<beerman>
i dunno
<beerman>
fuck i avoid nvidia for years now
<beerman>
not too much, but its still work, thats granted
<beerman>
you know, you can install both and see how they run individually right?
<beerman>
thats x11/wayland
<Romster>
true i tried and i coulnd't get my compositor to work but i didn't try that hard to
<beerman>
"my compositor" is which compositor exactly?
<beerman>
anyway, i might say again: i don't use x11 anymore at all. steam works as much as all other things work. I don't see a point in defaulting to x11 anymore at all.
SiFuh has quit [Read error: Connection reset by peer]
SiFuh has joined #crux-devel
jue has joined #crux-devel
jue has joined #crux-devel
jue has quit [Changing host]
<farkuhar>
is libbsd really an abomination that links to everything? Running 'prt-get dependent --all libbsd' only returns contrib/bumblebee. Maybe everyone is keeping the ports that depend on libbsd in their personal repos.
<farkuhar>
as for non-wayland screenshot utilities, I recently stumbled upon a link to a file created by xwd, the venerable window dump utility bundled with Xorg. You don't see that filetype uploaded very much these days, because the format isn't as widely supported as jpeg and png.
<farkuhar>
in the case of xorg-xwd it seems that nobody was too fond of it to create a port, but there is maim (in groovy2shoes' repository) if you want a viable alternative to scrot.
<beerman>
yes, libbsd will break your core ports
<beerman>
if you install that, then rebuild all your installed packages, then remove it, it will be a shitty situation if you have no boot iso at hand
<farkuhar>
couldn't we avoid breaking core ports by installing libbsd with namespaced headers (rather than overlay mode)? Or was overlay mode chosen to make migration easier, in case libbsd eventually became a core port itself?
<braewoods>
beerman: libbsd is that invasive?
<braewoods>
I thought it was just a supplement to libc.
<beerman>
braewoods: it is, and my point of discussion was if we should just include it in core and be done with it, as this seems like what most distros do
<braewoods>
also worth noting the invasiveness is contained by careful build processes
<braewoods>
Something not really practical for source based.
<braewoods>
I would think libbsd should require patching for the few ports that need it. It shouldn't link against everything.
<braewoods>
serious question. why would libbsd link against everything? I can't see anything here that would cause it to inject itself into every build.
<braewoods>
unless it's something in a header?
<braewoods>
seems it has to be explicitly requested
<braewoods>
from pkgconfig or so?
<beerman>
I dunno the specifics, but among broken ports was libarchive which cripples rebuilding without a chroot env where you can sideload good versions
<beerman>
jaeger: does repology pick up on 3.7 according to the data inside the json we send them or do we need to ask for an update?
<jaeger>
We need to make a pull request to get the new data
<darfo>
at compile time lots of software use libbsd if it is present and don't allow that to be turned off without patches. So libbsd show up as a dependency but the longer it is on a system the more ports find it during build and link it.
<darfo>
after my troubles with it is swore: no libbsd on my linux systems ever again
<darfo>
I swore the above. And a swore a lot.
<beerman>
alright
<jaeger>
I was planning to try to test the repology stuff locally and make a PR this week, but it should look exactly the same with the version changed, I think
<jaeger>
About to find out if my laptop survived the upgrade :)
<farkuhar>
echoing braewoods' serious question, why are ports detecting the presence of libbsd and linking to it without being told to do so? Shouldn't we be able to disable the auto-detection at compile time, by installing libbsd into a subdirectory that's not in the default CFLAGS include path?
<jaeger>
I can't speak for others but I have zero attachment to libbsd, only made it a port because something else (I think opendkim/libmilter) needed it
<jaeger>
If it can be reconfigured like that and still work, fine by me
<braewoods>
the real question is why this one library is causing so much trouble.
<jaeger>
bad behavior? Like icu
<braewoods>
if I had an environment where the issue could be reproduced I could take a look.
<braewoods>
there has to be *something*. the compiler doesn't magically decide to start grabbing random libraries and linking it against everything that doesn't even need it.
<jaeger>
yeah, it would be autotools or something, I'd guess
<jaeger>
Unless libbsd somehow replaces libs/symbols... if it replaced libs on disk we'd see footprint problems, but I'm just guessing, haven't looked into it
<braewoods>
i looked at the ARCH's package list. It's just headers, pkgconfig files, and libraries.
<braewoods>
I'm guessing something to do with build systems. But why would autotools look for libbsd if it wasn't requested?
<jaeger>
No idea
<braewoods>
beerman: think you can setup an environment where I can investigate?
<braewoods>
it would give some idea if other options for dealing with it exist.
<braewoods>
can use containers on the server if ya need to
<beerman>
braewoods: i think i can do that, no worries
<jaeger>
It looks like opendkim and bumblebee are the only things that depend on libbsd, I wonder if it's even worth keeping
<jaeger>
I'll look into putting it in some subfolder, since those are probably ports that only I care about
<jaeger>
as a side note, reading that github issue, please don't lump us all together as "crux maintainers" - you've given them the impression that we as a group are antogonistic towards libbsd, which at least in my case isn't true. I don't care one way or the other about libbsd, it was simply required by something else I used
<jaeger>
s/antogonistic/antagonistic/
<beerman>
wasn't really my intention at all
<beerman>
i know that romster didn't want to update and depend on libbsd actually ;)
<beerman>
at least wanted
<jaeger>
Since I don't think we've really done anything like it before, where would be a preferred path to install libbsd rather than the usual areas? Something like /usr/libbsd?
<SiFuh>
/usr/lib/libbsd/
<SiFuh>
Probably still show up though so /usr/libbsd might be the better option
<SiFuh>
How about /opt/lib/ ?
<jaeger>
I usually keep packages known to the system package database out of opt... but this is a weird exception anyway, so it's an option, I guess
<SiFuh>
Same, and binary packages as well
<SiFuh>
I use opt for binary packages as well*
<beerman>
jaeger: how about a general approach, if we are ever to be hit with yet another lib which is deemed to be handled differently we are prepared. /usr/optional/$name for example, that way, the parent directory can hold any other case as well
<beerman>
and if you ask me, i am still up to just make it a core port if thats what libarchive and possibly others prefer to use
<beerman>
whats the big deal
<jaeger>
I don't have a strong preference. If folks prefer it in core, that's fine
<beerman>
its not folks for me, its the software we choose to have in core
<jaeger>
by folks I mean "the people here talking about this"
<darfo>
the problem i had with libbsd is not it but the autotools (configure) scripts that find it then link it and the don't have an option to prevent that short of patching configure.in or removing libbsd before every build
<darfo>
it gets linked in with important programs then when it changes I couldn't even use pkgmk/prt-get.
<SiFuh>
darfo: I had used libbsd for my sndio and some things broke during updates so I scraped libbsd and my sndio port
<darfo>
usually a software like that is only updated on a new release of CRUX
<darfo>
same here @SiFuh. had a lot of fun updating all the ports that had linked it a compile time.
<darfo>
arch shows libbsd required by 15 ports. not entirely true because one of them is samba which crux builds just fine without libbsd.
<darfo>
AUR shows it is required by 105 of its ports. wonder how many actually require it or only because it has insinuated into the toolchain to build those port?
<darfo>
omg, useflags. I left Gentoo for CRUX to get away from those.
<SiFuh>
:-P
SiFuh has quit [Ping timeout: 264 seconds]
<beerman>
jaeger: fair enough, anyway, I don't have a strong point towards one or the other either, its just that I dropped libbsd when I found out how invasive that is, and since that, tried avoiding it like the pest
<beerman>
and in the same sense, its fair to talk about making it a core port
<farkuhar>
beerman: thanks for pointing us to the scrot github issue, it's a fascinating glimpse into the history of this "automagic dependency" problem.
<jaeger>
What other ports do you guys remember that hard require libbsd? Sounds like bumblebee (which I'm not even sure if anyone's using besides me, very specific to laptops with intel/nvidia gpu switching) and scrot at least but are there others? opendkim needs it but I realized that's not in the official ports trees
<beerman>
like i said, i prominently remember it breaking bsdtar/libarchive
<jaeger>
right, I mean which ports actually won't build without it?
<beerman>
oh, i dunno
<jaeger>
did a recursive grep through the portdb's working directory, I see 12 depends lines listing libbsd, not many
<jaeger>
Mostly for my own curiosity
<jaeger>
Romster: do you plan to revive rust-bin for 3.7? No pressure, also just a curiosity question
<beerman>
i probably could answer that
<beerman>
I don't expect a comeback for rust-bin as his words were "i don't care for rust-bin"
<beerman>
if we were to make a rust-bin port, it would make much more sense to use rustup, the official tool to grab a rust binary distribution
<beerman>
at least imo
<jaeger>
Fair enough. No need for it on my account, just had it installed on an older system. Will replace it with rust
<beerman>
yeah i mean, the past port was neglected for so long i had to drop it
SiFuh has joined #crux-devel
<stenur>
yeah. acpid developer included the one libbsd thing he used after i mailed him. libbsd not here.
<stenur>
btw. libarchive SMP. and our /etc/rc random is a mess, we need my entropy saver, or take that from donending, .. or include newest busybox in core and link some to that!!
<beerman>
forgot to actually add the patch (which is one of the changes to the Pkgfile I made for gbm some time ago)
<jaeger>
oops
<beerman>
I didnt, I am just tired
<beerman>
just copy the actual patch over from the gbm port
<jaeger>
ok
<beerman>
i have started a rebuild inside my container and will push the changes as soon as that finishes, I don't expect any problems. kodi is one of the ports i rebuild more frequently to check if it still holds up, as it can be a bit flaky. But by now I only really use the gbm port, as it shows
<jaeger>
It's building again, that's a slow box so will take a while
<SiFuh>
They usually still work if there is an empty line below
<beerman>
😴
<SiFuh>
That's a sleeping face
<SiFuh>
Best part about being on the ignore list, is I don't get yelled out or abused :-P
<beerman>
CORE_PLATFORM_NAME *X11;WAYLAND;GBM <- we could probably make one port while we maintaint three in total, dunno how practicle that would be
<farkuhar>
looks like switching from autotools to cmake prevented the libarchive build from linking against libbsd. I just ran 'prt-get update -fr libarchive' on a system with libbsd installed, and ldd /usr/bin/bsdtar does not report any linking to files owned by libbsd.
<farkuhar>
so it's definitely an autotools problem, as darfo reported.
<beerman>
and here I was almost thinking cmake was as evil as so many people love to cry about
<stenur>
i never had libbsd here
<stenur>
_never_
<beerman>
farkuhar: anyway, thanks for testing it out. I still think we should consider it for core, it wouldn't hurt either way and only hurts the "i love as few packages as humanely possible"-egos
<stenur>
Ah wait! It was blue-alsa!
<stenur>
July 2021. He used libbsd for timespecsub(), but then luckily included that manually after i wrote "performs a rather trivial calculation, and which is unchanged since at least 1997 (looking at the OpenBSD version here)".
<stenur>
Needs it optionally for a program i do not build though
groovy2shoes has quit [Remote host closed the connection]
groovy2shoes has joined #crux-devel
<jaeger>
Hrmm, that did get kodi-wayland to build but I just get a black window with some gray decorations (borders, buttons) when I run it
<beerman>
i'll give it a shot tomorrow and let you know how it goes, can try with Haswell-ULT
<beerman>
is there any chance that you used clang & lld for the build? the Pkgfile makes those adjustments to be able to build with LTO
<jaeger>
Not intentionally
<beerman>
yeah I left an extra env flag in there to prevent it
<jaeger>
yeah, clang isn't even installed
<beerman>
so if you didn't set it you should be fine
<jaeger>
ok
<beerman>
it enables the LTO build
<jaeger>
I'm not sure if this is a wayland issue or old hardware or what
<jaeger>
It's definitely not a modern intel gpu
<jaeger>
but sway does seem to work without issues
<jaeger>
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev 02) for reference
<Romster>
farkuhar, use finddeps on all the core ports and others after you've recompiled them with libbsd on your system, or alternatively remove libbsd and see what is broken. (be sure to have a recovery plan, wget wont work curl wont work libarchive wont work fun times)
<beerman>
mine is fairly old and powerless by design as well :D no problems so far
<jaeger>
hrmm, ok
<beerman>
i'll just add my container package
<beerman>
yeah same behaviour over here, i'll need to se why that is
<jaeger>
ok. Glad it's not just my system, at least
<beerman>
the menu works, according to the sound it makes but its just a black window
<jaeger>
yeah, and opening other windows still works behind it, etc... just can't see anything useful in its window
<beerman>
i'll look into it tomorrow and let you know what I found, it used to work just fine
<beerman>
sway just prevented fullscreen mode, so to speak, but thats something you should be able to configure with sways for_window option
<Romster>
i had a bad expieance with libbsd, no hard feelings but it really broke my pc when i removed it, can't remember why i removed it though. honestly not sure why libbsd is a thing. bsd does changes that are not libc or musl included.
<Romster>
lots of ports bundle there own libbsd but it'll use the system one than there bundled one if found on the system
<Romster>
at first i didn't like cmake but it's better now than it used to be
<stenur>
last year i grepped the ports tree, and there was only one port which needed it
<stenur>
really
<stenur>
other than that i do not care; but 'am happy bluealsa maintainer included that simple macro
<Romster>
i guess install it in it's own prefix and not put it's libbsd.pc in the searchable paths
<jaeger>
Hrmm... at some point I need to try to discover why it takes a while to start firefox on my laptop
<Romster>
move usr/lib/pkgconfig/libbsd.*pc in usr/lib/libbsd/pkgconfig/libbsd.*pc
<Romster>
perhaps
<Romster>
not tested that
<Romster>
libbsd.la coudl be nuked probably.
<Romster>
the bin or the source build i made?
<Romster>
browser-vacuum cleans out old crud of the firefox database