00:05
<
ifreund >
leon-p: finally put up a PR for the riverctl river-options implementation though I have one more yak to shave before merging
00:05
<
ifreund >
let me know if you think the CLI interface does/doesn't make sense
00:06
<
ifreund >
we also have a small, zero-allocation arg parser thing now
00:08
g_w1 has joined #river
00:12
<
g_w1 >
should I not be using latest master?
00:12
<
ifreund >
g_w1: you're using wlroots master, you need wlroots 0.12.0
00:14
<
ifreund >
Idk how nixos works, but I removed that function from wlroots master
00:14
<
ifreund >
and it's definitely present on 0.12.0
00:15
<
g_w1 >
is there a way to check what version of wlroots is installed?
00:16
<
ifreund >
normally I'd say ask your package manager but if we aren't trusting it you could read the wlroots headers I guess
00:17
<
g_w1 >
oh nixos has 0.11.0, nvm. nixos master is different than 20.09
00:17
<
g_w1 >
i will just use the master shell and ill update the wiki if it works
00:18
<
ifreund >
oh lol, I read the symbol name wrong. Had a couple people report that building failed with the one that got removed on master
00:18
<
ifreund >
the layer surface one you hit is one I added in 0.12.0 :D
00:19
<
ifreund >
why the hell does nixos still have wlroots 0.11.0 though? I thought they were kinda up to date?
00:19
<
ifreund >
or maybe that's just the unstable channel
00:20
<
ifreund >
and yeah feel free to update that wiki page however you see fit :)
00:20
<
g_w1 >
its unstable, I could use it if I wanted, but im on 20.09
00:24
<
ifreund >
I guess the point of nix is that you can use unstable just for dev environments and stuff
00:25
<
ifreund >
heck, I used it for a bit to get llvm11 binaries before they were packaged for void
00:25
<
g_w1 >
ok nice it built thx
00:26
<
g_w1 >
yeah it was fairly easy to just download the wlroots.nix file
00:30
g_w1 has quit [Quit: Connection closed]
05:45
waleee-cl has quit [Quit: Connection closed for inactivity]
08:30
_whitelogger has joined #river
09:16
travankor has joined #river
11:38
travankor has quit [Remote host closed the connection]
11:38
trav80563 has joined #river
12:40
<
leon-p >
fwiw I also get the crash on exit on master, so it is not my code causing the issue.
12:44
<
ifreund >
leon-p: got a stacktrace for me?
12:45
<
ifreund >
piping stderr to a file can be helpful if it only happens on a tty
12:56
leon-p has quit [*.net *.split]
12:57
tsujp1 has quit [Ping timeout: 272 seconds]
12:59
leon-p has joined #river
13:00
tsujp1 has joined #river
13:04
<
leon-p >
actually seems like the debug code of std is crashing?
13:05
edrex has quit [Ping timeout: 240 seconds]
13:05
<
leon-p >
although I have no idea how `return_address - 1` could trigger an overflow.
13:07
ifreund_ has quit [Ping timeout: 258 seconds]
13:07
voroskoi has quit [Ping timeout: 244 seconds]
13:07
samhsmith[m] has quit [Ping timeout: 244 seconds]
13:10
<
leon-p >
ifreund: ^
13:15
trav80563 has quit [Ping timeout: 268 seconds]
13:36
<
ifreund >
leon-p: are you sure you're using wlroots 0.12.0?
13:38
<
ifreund >
there's also the fact that you seem to be using the logind wlroots backend while I use libseat
13:59
samhsmith[m] has joined #river
13:59
voroskoi has joined #river
13:59
ifreund_ has joined #river
14:01
edrex has joined #river
15:29
<
ifreund >
I think I need to put an actually secure screenlocker protocol on the TODO
15:35
<
ifreund >
or maybe what I really want is a screensaver protocol and have the locking part be handled by the compositor
15:56
<
ifreund >
leon-p: debug symbols for libwayland might also shed some more light, though I assume something didn't remove its display_destroy listener before it was de-allocated
15:57
<
ifreund >
valgrind would probably tell us what that thing was
16:56
<
leon-p >
screenlockers in wlroots land currently use layer shell, don't they?
16:57
<
leon-p >
But yeah, something dedicated would be nice
16:57
<
leon-p >
I think hikari is already doing locking server-side
16:59
waleee-cl has joined #river
17:05
<
ifreund >
indeed, hikari handles locking server side
17:05
<
ifreund >
river currently has the same support for "screenlockers" as sway does, which is just layer-shell and input-inhibit
17:07
<
ifreund >
I think server-side is the simplest secure option, though a dedicated protocol may be able to offer the same level of security
17:09
<
ifreund >
I think a screensaver protocol leaving the locking itself up to the compositor is the way I probably want to go though
17:09
<
ifreund >
but that can come much later, the sway approach is OK enough for now
21:12
leon-p has quit [Quit: leaving]
21:22
travankor has joined #river
23:30
travankor has quit [Ping timeout: 268 seconds]