05:45 <tiosgz> __toor__: i've tried that recently, don't recall if i got at least rivertile and riverctl to link statically. i also stumbled on a zig bug that didn't let libs other than libc to be static with the seemingly correct approach

05:47 <tiosgz> iirc i eventually needed something like thing.addObjectFile(.{.cwd_relative="/path/to/libsomething.a"}), although .{.linkage=.static} in b.addExecutable() or thing.addSystemLibrary2("something", .{.preferred_link_mode=.static}) also seemed correct

05:48 <tiosgz> (all that regarding build.zig of course)

05:48 <tiosgz> and i needed to specify libffi cos apparently libwayland doesn't pull it in with static linkage

08:06 <Nickli> does this scratchpad configuration seem correct? https://bpa.st/5I7EW

09:47 <__toor__> well, right now I could not even compile with the latest "stable" of zig, river pair :)

09:53 <__toor__> ifreund: do you have a maintainance release for compiling with the latest zig planned?

09:53 <ifreund> __toor__: huh? river compiles with the latest zig release

09:53 <ifreund> if you're talking about supporting zig's master branch, no

09:54 <__toor__> no the latest release of zig ofc

09:54 <__toor__> i could not get the latest of river to compile with the latest zig

09:54 <ifreund> well I'm inclined to blame your LFS install tbh

09:54 <ifreund> feel free to share the compile error though

09:55 <__toor__> I blame it all the time -- but its 100% better to blame something I can control reasonable than to blame archlinux guys ;-)

09:55 <__toor__> Let me have another look at it!

09:56 <ifreund> one could also use a distro other than arch that doesn't break things as often :D

10:03 <__toor__> I stand corrected. I upgraded river to the latest and now it compile with zig just fine. Zig 0.13.0

10:04 <__toor__> https://imgur.com/a/xUYRWS4

14:24 <The_Buhs> ifreund> one could also use a distro other than arch that doesn't break things as often :D

14:24 <The_Buhs> Gentoo is like 90% of the configurability of LFS, but also doesn't break particularly often (haven't had any issues in the 2 and a bit years I've been on it unless I've been messing with things), and you can easily allow unstable packages if you really want bleeding edge for a few things (or your whole system). 🤷 __toor__

14:27 <leon-p> do other peoples arch installes really break that often? I had like two issues after upgrade in ~5 years and both times the fix was so trivial I can't even remember it. What kind of unholy setups do people use that are so fragile?

14:29 <The_Buhs> leon-p honestly no clue I've just heard about it lots lol. I don't think I had any major issues on Arch when I ran it, either

14:29 <ifreund> as long as pacman allows you to break things with partial upgrades I will smirk at arch linux :P

14:29 <The_Buhs> That's fair

14:29 <The_Buhs> That's why portage is love, portage is life

14:30 <ifreund> I hear 2 things about portage: 1. it's incredibly flexible 2. it's slow as hell

14:30 <ifreund> I quite like apk personally

14:35 <leon-p> I mean you have to go out of your way to do partial upgrades, f.e. by explicitly holding back packages. If that breaks something, it's user error IMO

14:36 <leon-p> although I might switch to alpine eventually; there is currently an effort to get systemd going on alpine, if that lands I might jump over

14:36 <Nickli> alpine is pretty neat

14:37 <leon-p> it updates fast and that is like half of what I care about. I am not a fan of split packages though

14:38 <leon-p> also they have some of my things packaged. It would be kinda funny to install my own tools via apk :)

17:06 <gbrlsnchs> ifreund: portage is not as fast as a binary package manager, but it's pretty fast for what it does (specially resolving compilation dependencies)

17:06 <gbrlsnchs> I still have to explore it as a binary package manager though at some point

17:06 <gbrlsnchs> I had great experiences with apk as well

17:07 <gbrlsnchs> btw ifreund, how is your experience with chimera linux going? compared to void and specially alpine

17:47 <vimproved> ifreund: yep both of those are true about portage

17:47 <vimproved> by far the most powerful package manager out there

17:47 <vimproved> but also it takes like a minute for dependency resolution on a full system upgrade sometimes

17:48 <vimproved> thankfully i am a patient person

17:49 <vimproved> part of that is due to the increased complexity introduced to dependency graphs by use flags and the variety of configurations it has to consider

17:49 <vimproved> part of it is python

17:50 <vimproved> the part of portage i like the most though is that it enforces a lot of good packaging practices

17:51 <vimproved> very robust qa checks, network sandbox, etc

17:51 <vimproved> which means it catches a lot of upstream bugs

18:59 <The_Buhs> Really the only time I notice how slow portage is is when I do `emerge -puDU @world` and want to see what I need to update

20:00 <ifreund> gbrlsnchs: I'm still very happy with chimera. Compared to void all the core tech is far better in my opinion

20:01 <ifreund> compared to alpine, it's probably less of a major enhancement. I definitely prefer dinit to openrc though and think chimera generally is better setup to robustly support desktop use-cases ootb or with minimal effort

20:02 <ifreund> rolling release is also nice, though I don't think it's much difference in practice to alpine edge

20:03 <ifreund> currently my tastes are chimera for any kind of desktop/laptop usage and FreeBSD for any kind of server usage

20:03 <gbrlsnchs> nice, that makes sense

20:03 <ifreund> vimproved: is portage any stricter about build sandboxing than e.g. chimera's cports?

20:04 <ifreund> gbrlsnchs: oh, I forgot about cports with regards to the comparison to alpine. cports is far better than alpines packaging system

20:05 <gbrlsnchs> I confess I enjoy Gentoo a lot because I can customize it to the core but sometimes it's tiresome

20:06 <gbrlsnchs> and because I enjoy minimalism a lot, Chimera was next in my list in case I got tired of Gentoo

20:06 <vimproved> ifreund: not sure, it definitely has more QA checks

20:07 <ifreund> I find myself increasingly trying to avoid the need for customization, there are other things I'd rather spend my time on

20:07 <gbrlsnchs> I might try chimera on my StarLite 5

20:07 <ifreund> though I do seem to have written my own wayland compositor, I do like having things behave the way I want them to :D

20:08 <gbrlsnchs> ifreund: yeah, I totally agree... of course it varies from person to person, but for me it feels like customizing it too much is cool once, specially for learning

20:08 <gbrlsnchs> then it gets on your way 😛

20:23 <vimproved> ifreund: i find customization fun but i have to go about it in a systematic way

20:24 <vimproved> like i wrote my own dotfile management tool bc i wasn't happy with anything else https://codeberg.org/vimproved/blahajdotsl

20:25 <vimproved> and i manage all my gentoo machines with ansible

20:25 <ifreund> I too wrote my own dotfile management tool: https://codeberg.org/ifreund/dotfiles/src/branch/chimera/install.sh

20:26 <ifreund> (blahajdotsl is a 404 for me by the way... private repo?)

20:27 <vimproved> mistyped an l lol

20:28 <vimproved> https://codeberg.org/vimproved/blahajdots

20:33 <ifreund> vimproved: now if only if everything would cooperate to make that theme switching frame-perfect

20:33 <vimproved> lol

20:34 <ifreund> (I unironically want frame-perfect switching between solarized light and solarized dark in my future personal rwm protocol wm/de)

20:35 <gbrlsnchs> let us know if you ever achieve that ifreund!! 😄

20:36 <ifreund> I've got to finish the hard part first (the rwm protocol PR) before I get to have fun with stuff like that :D

20:36 <ifreund> been a bit busy with the new job this month

20:40 <gbrlsnchs> but how do you intend to handle theme switching on external software? (foot, for example)

20:40 <gbrlsnchs> I mean, in order for it to be frame perfect

20:41 <ifreund> no idea, luckily I don't have to cross that bridge yet :D

20:43 <gbrlsnchs> haha gotcha, food for thought then

23:09 <Guest44> I was looking through the archives about running river headless and I think I have found a new issue? I launch river with environment variable WLR_BACKENDS=headless. Once river starts, I get the following error message: error(output): output commit failed for HEADLESS-1. Has anyone seen this before?