<anabelae[m]>
Replying in a matrix thread to see how it relays over to IRC. However, I will also mention the word in meson build, never seen it before.
<f_>
anabelae[m]: it just gets sent as a regular reply-to
<f_>
just like on non-element matrix clients
<f_>
anyway, logoff! Have fun and please don't abuse the bot lol
<Consolatis[m]1>
it only reads title and weburl from the json response
arraybolt3 has quit [Quit: Konversation terminated!]
arraybolt3 has joined #wayback
orowith2os[m] has joined #wayback
<orowith2os[m]>
<Consolatis[m]1> that one doesn't seem more like a *very* early skeleton without support for even xdg-shell
<orowith2os[m]>
I'm trying - I'd appreciate any help I can get.
<orowith2os[m]>
My project also has a slightly different goal in trying to offload most of the work to SDL itself, instead of using X11 directly. When I get a Mac, it should open up some more stuff to play around with.
<anabelae[m]>
XWayback binary in build expects wayback to be installed system-wide?
<dramforever[m]1>
<anabelae[m]> XWayback binary in build expects wayback to be installed system-wide?
pinskia has quit [Read error: Connection reset by peer]
<dramforever[m]1>
currently wayback-session expects to find Xwayback in $PATH, or you can set XWAYBACK_PATH
<navi>
Xwayback (for now) expects wayback-compositor to be in libexec
<navi>
but there's an environment variable to override that
<dramforever[m]1>
oh i meant in the not installed case
pinskia has joined #wayback
<dramforever[m]1>
ahhh
<dramforever[m]1>
yeah Xwayback wants wayback-compositor... that's the other dependency yes
<anabelae[m]>
Alright, another question, hope you don't mind. It builds well with system installed devel dependencies. However when I tried building with a wlroots-0.19 subproject, it yields this error: `/usr/local/libexec/wayback-compositor: error while loading shared libraries: libwlroots-0.19.so: cannot open shared object file: No such file or directory`
<anabelae[m]>
I replaced the wlroots dependency in meson.build with
<anabelae[m]>
(And moved it below xwayland, because it creates a target and it's not possible to declare arguments after that).
<dramforever[m]1>
yeah so, dynamic linking is just kinda like that
<dramforever[m]1>
one convenient-ish way you can hack that is with LD_LIBRARY_PATH pointing to where well, that .so file is
<dramforever[m]1>
note that this overrides subprocess's global libraries with ones in that directory but hopefully nothing else under wayback-session is using wlroots
<dramforever[m]1>
all subprocesses, as long they inherit this environment variable
<Consolatis[m]1>
anabelae:matrix.org: I also build with wlroots as subproject but I just left it as dependency and it seems to work fine. I did have to move the xwayland global arg to the top though
<Consolatis[m]1>
no LD_LIBRARY_PATH or anything, afair meson will build it statically
<whitequark[cis]>
would this be solved with RPATH?
<anabelae[m]>
<Consolatis[m]1> anabelae:matrix.org: I also build with wlroots as subproject but I just left it as dependency and it seems to work fine. I did have to move the xwayland global arg to the top though
<anabelae[m]>
Are you sure you don't have wlroots-0.19 installed system-wide?
<Consolatis[m]1>
yes, very sure
<thomas_adam>
whitequark[cis]: Yes it would.
<dramforever[m]1>
if wlroots is statically linked then that would make sense
<dramforever[m]1>
i don't know how on earth meson works though
<anabelae[m]>
Setting LD_LIBRARY_PATH to a directory containing the .so works. Hm, well I will try playing with it for a bit. Thanks
<dramforever[m]1>
if you can get meson to build and link wlroots as a static library that would be much easier to handle
<thomas_adam>
You can: static_library -- however, is that really useful?
<Consolatis[m]1>
AFAIR meson by default links subprojects statically
<Consolatis[m]1>
well, dependencies found via .wrap files at least
<thomas_adam>
I mean, either you go all-in, and adopt as a subproject wlroots to suit the needs of wayback, or you don't -- apparentlu, there's some contention in doing the former.
<navi>
meson's non-installed libraries have rpath set (on platforms that support them)
<navi>
if that's failing, there's something wrong with the build files
<Consolatis[m]1>
hm.. you are right, sorry. I just checked ldd build/wayback-compositor/wayback-compositor actually links to libwlroots-0.19.so from the build directory
<Consolatis[m]1>
so its not statically built but meson automatically makes linking work
<dramforever[m]1>
if you're debugging something it helps to just play around with an editable wlroots, i think
<dramforever[m]1>
Consolatis[m]1: if you're feeling like checking try a `readelf -d` on wayback-compositor?
<dramforever[m]1>
if taht works then TIL meson makes that work (but only sometimes?)
<navi>
to build wlroots statically, `meson configure build -Dwlroots-19:library_type=static
<navi>
(iirc)
<Consolatis[m]1>
for me wlroots-019.so shows up as (NEEDED) on readelf -d. I confused it with statically linked because that is how it works in labwc but I missed a 'default_library=static' in its default_options for the wlroots dependency. So I assumed it was a meson default.
<navi>
i usually pass static manually on the cmdline when i want to
<navi>
meson is shared by default
<anabelae[m]>
<navi> to build wlroots statically, `meson configure build -Dwlroots-19:library_type=static
<anabelae[m]>
This doesn't work for me unfortunately. The only thing that worked so far is setting the `LD_LIBRARY_PATH` var.
<navi>
i typoed that btw
<navi>
it's meant to be wlroots-0.19
<navi>
but, meson install (for me) did install the wlroots .so to /usr/local
<navi>
so, i think /usr/local/lib64 is outside your distro's default search path for some reason
<anabelae[m]>
No yeah I corrected it to wlroots-0.19 after trying what you originally wrote, it still didn't work : / Unsure if it's the combination with
<anabelae[m]>
Meh. I'll just keep in mind to set the env var
<dramforever[m]1>
it's just for development anyway
<dramforever[m]1>
i think it's fine
<navi>
oh
<navi>
`subproject('wlroots')`
<navi>
-Dwlroots-0.19 is overriding the setting for the `wlroots-0.19 subproject
<dramforever[m]1>
oh
f_|cat has quit [Quit: Idle timeout reached: 172800s]
<anabelae[m]>
From which environment do you start wayback from to develop
<axtlos>
what do you mean?
<axtlos>
like what desktop is used for testing?
<anabelae[m]>
I meant to ask whether or not you run it as a session compositor, or a system one from the tty (with it having to create drm devices and such)
<axtlos>
oh, both
<axtlos>
idk about the others but I always test changes as a session compositor, and once im ready to commit i test it from the tty
<axtlos>
just have to make sure that the DISPLAY envvar is set to the right to the right display
<anabelae[m]>
Happens here execv(xwayland_path, xwayland_argv);, but that isn't very helpful is it
<axtlos>
what command do you run
<f_>
Consolatis[m]1: Oh. Should not be hard to get working
<anabelae[m]>
Oh, right. I was omitting -displayfd. I was looking at older versions of wayback earlier today in which the :display could be directly written as the first argument (e.g wayback 0) without the flag. Might be worth calling usage when the required arguments are not specified?
<ConanKudo[m]1>
if someone tries to game this bot somehow, I'll disable the webhook
<ConanKudo[m]1>
but it looks like it works
<f_>
ConanKudo[m]1: lol that won't happen hopefully
<f_>
We can make it less verbose if it turns out to be too verbose later on, that being said
<f_>
but: plz don't use the bot to spam the channel, I don't want to get into trouble. ty
<Consolatis[m]1>
I think there are much easier options for that
<f_>
yeah run efknockr on the channel (please don't :p)
<f_>
I just added a comment to an issue and it does not seem to show up in here
<f_>
awesome, so it's not too verbose (IMO) after all
<f_>
Thanks ConanKudo[m]1 ! :)
<Consolatis[m]1>
usually those notifications bots only react to the toplevel event, e.g. comments opened / closed / re-opened and mrs opened / closed / merged / re-opened
<Consolatis[m]1>
s/comments/issue/
<f_>
yeah right
<Consolatis[m]1>
this specific bot also sends some commits when a MR has been merged, that might be something to adjust eventually
<f_>
hmmm yeah
<f_>
We'll see how this goes
<f_>
but I'm calling it a night for now. Good night ^^
<anabelae[m]>
night!
Lord_Nightmare has quit [Killed (ozone (No Spam))]
Lord_Nightmare has joined #wayback
Wayback has quit [Ping timeout: 244 seconds]
Wayback has joined #wayback
<anabelae[m]>
<axtlos> what command do you run
<anabelae[m]>
To this - what's the difference between running with x_display and displayfd? When I run without filling in displayfd, I get the mentioned lock file issues, but if I do, then wayback runs well
<anabelae[m]>
The only difference I see is that `xwayback->X_display` does not get filled and there are minor base argument differences