<dok>
maybe the access should be done on the env variable only
<f_>
yeap
<dok>
but i think i would like to fail if the env variable is wrong
<dok>
and not fallback to Xwayback if the access fails
<dok>
what do you think ?
<f_>
dok: well it does fail if the env variable is wrong
<f_>
It doesn't fallback to Xwayback if the env variable is wrong
<dok>
i mean:
<dok>
if (xwayback_path != NULL && access(xwayback_path, X_OK) == -1)
<dok>
wayback_log && exit
<dok>
else
<dok>
xwayback_path = "Xwayback"
<f_>
Yeah that's what I was going to do
<dok>
cool
<dok>
i think this kind of thing is done twice
<f_>
The issue is I'd like to also handle Xwayback not found in PATH ...
<dok>
the second one is in Xwayback, i haven't looked much at it
<dok>
if Xwayback is not in PATH exec will fail
<f_>
yes, it will
<dok>
so maybe add strerror(errno) after the execlp error
<f_>
will do so later
<f_>
dok: do you want me to add reported-by
<dok>
nah it's okay
<dok>
> [16501.042362] wayback-composi[25420]: segfault at 8 ip 00007f1dcce71778 sp 00007ffd003fa748 error 6 in libwayland-server.so.0.24.0[7778,7f1dcce6f000+6000] likely on CPU 7 (core 3, socket 0)
<dok>
uh that's something else
<dok>
(that was before upgrading)
<f_>
hmmm
<f_>
remote:
<f_>
remote: To create a merge request for im-dumb, visit:
<f_>
dok: !60 should fix the issue you had earlier
<f_>
and it looks like Neal is silently monitoring the chat, thanks for the approve :D
ConanKudo[m]1 has joined #wayback
<ConanKudo[m]1>
and your build fails
<ConanKudo[m]1>
so unapproved
<f_>
and the unapprove :D
<ConanKudo[m]1>
missing include
<f_>
yep errno.h
<f_>
I hate errno tbh
<ConanKudo[m]1>
I hate C :)
<f_>
why return -1 and set errno when you can return -your_error_here
<f_>
ConanKudo[m]1 -- c:
<ConanKudo[m]1>
that too
<dok>
i like errno and C
<dok>
:]
<f_>
C is okay, but the errno variable thing? Just Whyâ„¢
<dok>
well... yeah maybe not the best design
<arraybolt3>
C isn't that bad
<f_>
ConanKudo[m]1: one moment before you merge it
<ConanKudo[m]1>
f_: because 4-bit and 8-bit computers didn't have register and memory for rich error handling
<f_>
arraybolt3: yeah it's not that bad but some of its design choices are not all that great in today's world
<arraybolt3>
possibly
<arraybolt3>
what I really hate is the standard library though, like "here do everything yourself"
<dok>
my wayback-session "fails" to launch if i have a `xset b off` (or any xset) in my .xinirc before exec dwm
<f_>
ConanKudo[m]1: there, now you can merge it if you like.
<f_>
huh wait
<f_>
I just updated my branch but the MR isn't updating
<f_>
You pushed to
<f_>
im-dumb
<f_>
at Ferass El Hafidi / wayback 48 seconds ago
<f_>
--- thank you gitlab, very helpful
<f_>
dok: Anyway, try again on latest git, it should work
HadiChokr[m]1 has joined #wayback
<HadiChokr[m]1>
arraybolt3: Its too easy and thats why you can segfault like a pro 😎
<f_>
well
<f_>
you can segfault whatever you like without needing to program in C
<dok>
f_: great !
<dok>
speaking of segfault...
<f_>
just kill -SIGSEGV your_pid_goes_here
<dok>
[18855.574854] wayback-composi[2146]: segfault at 8 ip 00007f09b9672778 sp 00007ffc7b23f248 error 6 in libwayland-server.so.0.24.0[7778,7f09b9670000+6000] likely on CPU 2 (core 1, socket 0)
<f_>
yeah, you told us already
<dok>
i think that's when i hit ctrl-alt-backspace
<f_>
interesting
<dok>
with a plain Xwayback
<f_>
I'll see if I can reproduce it
<dok>
no nothing
<f_>
in the meantime can you report it on gitlab?
<dok>
i need to create an account
<dok>
i'll
<f_>
if you can't that's fine
nemoto has quit [Remote host closed the connection]
<f_>
dok: I can reproduce it too
<dok>
cool
<dok>
i am creating the issue
<f_>
awesome!
<f_>
[Jul 14 14:55:07] kern kernel: wayback-composi[30644]: segfault at 8 ip 00007f0e7e6f4778 sp 00007ffde856c918 error 6 in libwayland-server.so.0.24.0[7778,7f0e7e6f2000+6000] likely on CPU 3 (core 3, socket 0)
<f_>
duh lol why does wmaker log to logbookd - [Jul 14 14:53:54] daemon wmaker[30548]: (real_main(main.c:773)): fatal: could not open display ":"
<dok>
uh
<f_>
Thread 3.1 "wayback-composi" received signal SIGSEGV, Segmentation fault.
<f_>
[Switching to LWP 31665]
<f_>
0x00007ffff7f46778 in wl_list_remove () from /lib/libwayland-server.so.0
<dok>
i tried debugging it but now my main Xserver has crashed, and i cannot restart it :/
<dok>
what's the best way to send small changes ?
dramforever[m]1 has joined #wayback
<dramforever[m]1>
you can apply for fork privilege
<dramforever[m]1>
they usually go through in uh... a few hours? half a day?
<f_>
in a few minutes
<dramforever[m]1>
well, if you're on freedesktop gitlab i mean, i thought you are but i may have confused you with someone else
<navi>
ConanKudo[m]1: question, could we consider rebasing the PRs instead of merge commits? merge commits kinda clutter the history, specially with small changes
<ConanKudo[m]1>
I prefer rebases, but Ariadne wants merges
<navi>
oh oki
<ConanKudo[m]1>
the compromise was semi-linear merges
<navi>
fair enough
<ConanKudo[m]1>
you still need to rebase, but merge commits are made to preserve the merge points
<navi>
yeye i know
<ConanKudo[m]1>
makes it easier to bisect (which is why I prefer rebase/ff merge) but shows the points of integration (with the merge commit)
<navi>
merge commits are just annoying when checking history, bisecting
<navi>
i honestly don't see PRs and point of integration, i see each individual commit as a change
<navi>
but that's unrelated
<f_>
I don't like merge commits either
<ConanKudo[m]1>
I'm not a fan either
<f_>
at postmarketOS what we do is we have a tool named mrhlpr which automatically adds `Part-of: merge_request_id_here` to commit messages
<ConanKudo[m]1>
regardless of my feelings on marge-bot and similar, we also can't use it if we want merge commits
<f_>
so we know which commits come from what MR but we still don't have merge commits
<f_>
FYI we don't use marge (yet)
<ConanKudo[m]1>
my personal opinion is that the merge points don't really matter that much
<navi>
on openrc, commits are supposed to be atomic, or close to, and link to Bugs they fix, if anything from the MR came up and caused a changed on the commits, the reason for the change should be noted on the commit message
<navi>
aka the PR itself is meaningless
<ConanKudo[m]1>
I actually don't like linking to bugs or MRs in commits, my preference is for fully freestanding commit messages
<navi>
that's all i care about with non-commit `Fixes:`
<ConanKudo[m]1>
yes
<ConanKudo[m]1>
or I'll do it in the MR
<ConanKudo[m]1>
* the MR description
<navi>
fair, less automated, but works
<ConanKudo[m]1>
usually since I go through MR flow, it's in the MR descriptions
norwoodites is now known as pinskia
<Ariadne>
i prefer fixes: uri, and i prefer to preserve all git history which squashes intentionally get rid of
<ConanKudo[m]1>
I despise squash merges
<f_>
squashes in MRs is fine but in master not so
<f_>
imo
<f_>
in master there should be no force push IMO
joast has joined #wayback
nemoto has joined #wayback
ThinkT510 has joined #wayback
whitequark[cis] has joined #wayback
<whitequark[cis]>
problem with preserving all git history is you end up with 15 commits which fix typos or add random irrelevant crap
<whitequark[cis]>
i find this very frustrating, though in the last few years i learned to just tell people to learn to rebase
<whitequark[cis]>
much less of a problem for wayback since an SWE background is expected
Saijin_Naib[m]1 has joined #wayback
<Saijin_Naib[m]1>
If I am testing wayback-session on an Alpine Linux x86_64 edge machine setup with setup-desktop xfce and lightdm stopped, is a failure to launch expected at this juncture, or should I file an issue?
<Ariadne>
it depends. how are you starting xfce?
<Saijin_Naib[m]1>
Normally, xfce is started via lightdm and the session file
<Saijin_Naib[m]1>
I verified that with lightdm stopped, startx and startxfce4 worked properly
<Ariadne>
those are starting x.org
<Saijin_Naib[m]1>
Then, I tried to invoke wayback-session without arguments
<Ariadne>
that won't do anything except launch your $HOME/.xinitrc file
<dramforever[m]1>
if just straight startx works you probably configured that?
<Saijin_Naib[m]1>
Not to my knowledge, no
<Ariadne>
you probably want: wayback-session dbus-run-session startxfce4
<Saijin_Naib[m]1>
Awesome, let me try that and report back what happens
<Saijin_Naib[m]1>
it'll be a moment
<Saijin_Naib[m]1>
It errors out saying that xwayback can not be found or is not executable
<Saijin_Naib[m]1>
doas?
<Saijin_Naib[m]1>
or is it better to put my user in group I might be missing currently?
<Saijin_Naib[m]1>
I'm in wheel,audio,video,input,netdev,abuild
<Saijin_Naib[m]1>
doas fails as well with the same error, either startxfce4 or startx, though both work outside of wayback
<Saijin_Naib[m]1>
I have wayback-20250713-r0 installed
<Saijin_Naib[m]1>
setup-xorg-base and setup-wayland-base were both run on this machine, so as far as I can tell currently, I should have everything I need for a wayland session with wayback
<f_>
21:57 <Ariadne> that won't do anything except launch your $HOME/.xinitrc file
<f_>
wayback-session also launches Xwayback
<Ariadne>
i understand that
<Ariadne>
i was talking in terms of user-visible side effects
<Saijin_Naib[m]1>
If I am too early to be testing with my knowledge level, let me know
<Saijin_Naib[m]1>
I'm not well-versed in all of this
<Saijin_Naib[m]1>
I just wanted to see if i could test a fairly "full" XFCE session and report my results, if it were helpful
<Ariadne>
i think the wayback package in alpine may be defective
<Ariadne>
(this is why i did not really want anyone to package it yet)
<Saijin_Naib[m]1>
Totally fair. Wait until a proper point release before further testing and reporting back then?
<Ariadne>
not sure. issue is that xwayback (the "X server") binary is not in the search path i guess.
<Ariadne>
seems like something to report to fossdd ;)
<Saijin_Naib[m]1>
stat /usr/bin/Xwayback succeeds, so it exists and is on-path
<Saijin_Naib[m]1>
backend.c:406,Failed to open xcb connection
<f_>
o.O
<Saijin_Naib[m]1>
Searching for a provides for that shows wayback?
<Saijin_Naib[m]1>
wayback-compositor.c:781, Failed to create wlr_backend
<Saijin_Naib[m]1>
I'm using i915 if that matters
<dramforever[m]1>
speaking of whether it's too early to report failure, would it help if i just dump the stack trace of kwin crashing to gitlab issues or is that not really actionable
<dramforever[m]1>
i'm running out of progress and leads to go on
Guest91 has joined #wayback
Guest91 has quit [Client Quit]
<f_|cat>
<Saijin_Naib[m]1> wayback-compositor.c:781, Failed to create wlr_backend
<f_|cat>
Hm. Can you paste all the logs to bpa.st?
dviola has quit [Ping timeout: 245 seconds]
<Saijin_Naib[m]1>
@funderscore:postmarketos.org is there a way to pass a verbose flag or a logfile or something? The console output is fairly terse
zdykstra has joined #wayback
<f_>
Saijin_Naib[m]1: compositor is set to verbose