<awildthorp>
Hello. I'm trying to compile River on a Raspberry Pi 4. I seem to be hitting a segfault during compilation but I'm unfamiliar with the zig toolchain so I'm having a hard time digging much deeper. Has anyone else experienced this?
mon_aaraj has quit [Ping timeout: 250 seconds]
waleee has quit [Ping timeout: 250 seconds]
mon_aaraj has joined #river
roarc[m] has quit [Ping timeout: 268 seconds]
voroskoi[m] has quit [Ping timeout: 268 seconds]
waleee-cl has joined #river
<Evo2>
ifreund: I ran `zig libc` on my system. msvc_lib_dir, kernel32_lib_dir, and gcc_dir are all unset.
<Evo2>
include_dir and sys_include_dir are /usr/include.
<Evo2>
The only other setting is: crt_dir=/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu
waleee-cl has quit [Ping timeout: 240 seconds]
<Evo2>
It's not clear to me how to use that infomation to set the flags when building river.
voroskoi[m] has joined #river
<Evo2>
The crt_dir just resolves to /usr/lib/x86_64-linux-gnu
roarc[m] has joined #river
<Evo2>
Also I see that there is a bool option -Drelease. What does that do?
<awildthorp>
Not familiar with Zig but I've seen that mean more checking and minimization during compilation
<awildthorp>
E.g. stricter syntactic analysis and smaller binaries
<Evo2>
Ok, so longer compile time to optimize the binary. Makes sense.
<awildthorp>
+1
<awildthorp>
Optimize was the word I was looking for :P
<leon-p>
awildthorp: almost, zig has the same syntactical strictness for both debug and release builds
<awildthorp>
+1 Thanks
<Evo2>
Oops, sorry that -Drelease option is for building zig, not river. My bad.
elshize has quit [Ping timeout: 250 seconds]
<leon-p>
the main thing that changes for release builds is runtime safety measures, optimisation levels, whether debug symbols are included and similar.
elshize has joined #river
mon_aaraj has quit [Ping timeout: 240 seconds]
<leon-p>
also all calls to anything from std.debug will get removed when not in debug mode, like asserts and debug messages
<ghostbuster>
hmm is it possible that XKB_DEFAULT_OPTIONS="caps:ctrl_modifier" doesn't work for river commands?
<leon-p>
and since a developer has access to the release type at comptime, they could choose to change additional things based on it as well
<leon-p>
ghostbuster: all xkb optoins that work elsewhere should also work with river
mon_aaraj has joined #river
<ghostbuster>
hmm when i type caps + d in a terminal it exits, or caps + l in firefox it jumps to location, but caps + meta + # does not focus the tag (ctrl meta does, the actual ctrl key)
<leon-p>
ah, I see
<leon-p>
Hmm... maybe river does not correctly do the keymap lookup
<leon-p>
does it work in sway?
<ghostbuster>
not sure if i ever used ctrl as a modifier in sway
<ghostbuster>
i can check
<ghostbuster>
.. realized i can't check, because i uninstalled sway and manually upgraded wlroots lol
<leon-p>
hehe
<ghostbuster>
but i used sway itself to rebind caps
<leon-p>
that makes no difference, its all the same xkbcommon stuff under the hood
<leon-p>
anyway, I am off for today, it's late
<ghostbuster>
anyone else feel like confirming before i report a bug?
<ghostbuster>
must always remember PEBKAC is a possibility
<Evo2>
ifreund: Ok, I managed to get river to build without putting a RUNPATH in the binary. Thanks.
waleee-cl has joined #river
awildthorp has quit [Remote host closed the connection]
awildthorp has joined #river
mon_aaraj has quit [Ping timeout: 268 seconds]
mon_aaraj has joined #river
athorp96 has joined #river
awildthorp has quit [Ping timeout: 256 seconds]
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #river
waleee-cl has quit [Ping timeout: 250 seconds]
waleee-cl has joined #river
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #river
mon_aaraj has quit [Ping timeout: 268 seconds]
mon_aaraj has joined #river
waleee-cl has quit [Ping timeout: 250 seconds]
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #river
n8_ has joined #river
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #river
mon_aaraj has quit [Ping timeout: 268 seconds]
mon_aaraj has joined #river
athorp96 has quit [Ping timeout: 240 seconds]
Evo2 has quit [Remote host closed the connection]
n8_ is now known as n8r
n8r has quit [Quit: leaving]
n8_ has joined #river
n8_ has quit [Client Quit]
n8r has joined #river
awildthorp has joined #river
mon_aaraj has quit [Ping timeout: 268 seconds]
mon_aaraj has joined #river
n8r has quit [Ping timeout: 256 seconds]
Evo2 has joined #river
notzmv has quit [Ping timeout: 240 seconds]
norkki has quit [Read error: Connection reset by peer]
anb1 has quit [Ping timeout: 240 seconds]
Evo2_ has joined #river
Evo2_ has quit [Client Quit]
Evo2_ has joined #river
Evo2_ has quit [Client Quit]
Evo2 has quit [Quit: leaving]
Evo2 has joined #river
notzmv has joined #river
pkap has joined #river
anb1 has joined #river
<ifreund>
Evo2: glad you got it sorted out! sorry I wasn't very clear on the zig libc thing, the `--libc` argument of zig build expects a text file with those variables set
<ifreund>
you've probably figured that out by now though I assume
<ifreund>
leon-p: that's not quite accurate RE std.debug stuff getting removed in non-debug builds
<ifreund>
std.debug.print() for example will still be there
<ifreund>
std.debug.assert() will still panic in release-safe builds, but be UB in release-fast/release-small and give a hint to the optimizer
<leon-p>
ah, TIL
<ifreund>
(that's just how `unreachable` works in zig)
<leon-p>
yeah I think I forgot that debug.assert just wraps unreachable
<Evo2>
ifreund: It was clear enough after I did a little digging.
<ifreund>
cool :)
<ifreund>
Evo2: anything else blocking the debian package I can help with?
<Evo2>
I need to first try to get the zig package sorted before I try to get the river pacakge in.
<Evo2>
Note also that although I make a lot of Debian packages for myself I've not yet actually tried to get one into Debian.
<Evo2>
I've uploaded the packages to mentors.debian.net but not yet actually asked for anyone to review them.
mon_aaraj has quit [Ping timeout: 240 seconds]
<Evo2>
Given that this is Debian, I'm expecting things to move quite slowly. I'll be sure to let you know if (when) I have more questions.
mon_aaraj has joined #river
<ifreund>
yeah, slow movement is expected xD
mon_aaraj has quit [Ping timeout: 240 seconds]
mon_aaraj has joined #river
waleee-cl has joined #river
pkap has quit [Quit: Client closed]
norkki has joined #river
mon_aaraj has quit [Ping timeout: 240 seconds]
mon_aaraj has joined #river
<awildthorp>
leon-p I wonder if what you were running into was related to my problem as well, since I'm on raspbien
<leon-p>
awildthorp: I am missing context here, I run into a lot of things, which specifically are you talking about?
<awildthorp>
I'm trying to build on raspbien/raspberry-pi. During compilation Zig segfaults, giving only that it exit with code 11
<leon-p>
I don't think any problem I had to deal with is related to that, sorry :/
<awildthorp>
No worries. Do you happen to know how I would dig deeper? I'm not familiar with zig
<leon-p>
if the compiler zegfaults, then you'll probably have better luck asking on #zig
<awildthorp>
+1 Thanks
<ifreund>
awildthorp: how much RAM does your PI have?
<ifreund>
the current zig compiler uses unreasonable amounts of memory sadly
<ifreund>
a self hosted, far more efficient compiler is in progress and passing about half of the behavior tests, but it's able to compile river or other non trivial projects yet
<ifreund>
I don't think compiling river should take more than about a gigabyte though
<awildthorp>
ifreund: 2GB RAM
<ifreund>
is gdb able to give any kind of useful stack trace? I assume you're using one of the static zig tarballs from the webiste which I don't believe have debug symbols...
<awildthorp>
I cloned the repository actually. What flag would I provide for a stack trace?
<ifreund>
you managed to build zig from source with 2GB of RAM? I'm pretty sure the current compiler requires ~6-8 GB
<awildthorp>
Oh, I thought you were talking about the river tarballs. I installed zig via snap :P
<ifreund>
to get a stack trace you can run the command that segfaulted under gdb and then use the `bt` command
<novakane>
ifreund: looks like #501 works, fixes #500
mon_aaraj has quit [Ping timeout: 250 seconds]
mon_aaraj has joined #river
awildthorp has quit [Ping timeout: 256 seconds]
awildthorp has joined #river
mon_aaraj has quit [Ping timeout: 240 seconds]
pkap has joined #river
mon_aaraj has joined #river
mon_aaraj has quit [Ping timeout: 240 seconds]
mon_aaraj has joined #river
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #river
<ifreund>
novakane: thanks!
mon_aaraj has quit [Ping timeout: 250 seconds]
mon_aaraj has joined #river
<novakane>
ifreund: you had a bit of stroke writing the comment on the PR :P
<ifreund>
uh, whoops
<novakane>
sometimes I feel like github really doesn't like a lot of things from git
raiaq has quit [Write error: Connection reset by peer]
ifreund has quit [Write error: Broken pipe]
kindablue has quit [Remote host closed the connection]
anjan has quit [Remote host closed the connection]
leon-p has quit [Remote host closed the connection]
dnkl has quit [Remote host closed the connection]
andrea has quit [Remote host closed the connection]
psnszsn has quit [Remote host closed the connection]
coder_kalyan has quit [Remote host closed the connection]
kennylevinsen has quit [Remote host closed the connection]
novakane has quit [Remote host closed the connection]
ifreund has joined #river
anjan has joined #river
andrea has joined #river
kennylevinsen has joined #river
dnkl has joined #river
psnszsn has joined #river
kindablue has joined #river
raiaq has joined #river
novakane has joined #river
leon-p has joined #river
coder_kalyan has joined #river
<leon-p>
kina funny that people have thought about the session lock protocol now that it is merged...
<leon-p>
s/thought/thoughts/
<tiosgz`>
at least there isn't push for "quickly deciding on something", which in this case would be quite damaging i think
<tiosgz`>
or even for including anything related in this protocol
pkap has quit [Quit: Client closed]
<leon-p>
ifreund: btw, after our discussoin on the exact same topic, I already came up with a proposal for "that should happen over a separate protocol", if you like I can link it.
<leon-p>
it's a bit rough, but I can clean it up if there is interest
<ifreund>
leon-p: neat, looks pretty reasonable. I don't personally plan to push it forward though as I don't want anything displayed on my lock screen though :P
<leon-p>
I guess I'll just leave a comment. If people think it's the right direction I can pick it up seriously.
<tiosgz`>
+1 for the general "sensitive context" from me
<ifreund>
my recommendation would be only to work on it if you personally want to have it done
<leon-p>
I do like the functionality, I just don't know yet if it is the right approach
<ifreund>
I think it's a pretty good approach
<ifreund>
I wonder if the compositor might not want to augument it with some user-configureable whitelist though
<ifreund>
thing float-filter or csd-filter in river
mon_aaraj has quit [Ping timeout: 240 seconds]
<leon-p>
would require adding some sort of namespace. Currently it relies a bit on clients being reasonable and not requesting the interface if they don't need it.
mon_aaraj has joined #river
<ifreund>
hmm, does this even make sense for non layer shell clients
<ifreund>
maybe it should just be built into the next iteration of layer shell
<leon-p>
I did not want to bind it to the layershell, since there may be other widget shells at some point
<leon-p>
and hikari does have the concept of showing regular views on top of the lock screen, so I just "imported" the idea from there. Not sure how much sense it actually makes.
<leon-p>
Although I guess it is perfectly reasonable for a compositor to deny all such request for surfaces that are not widgets