00:04 <ghostbuster> if wlr-randr doesn't detect my output, i assume that's something deeper in the graphics stack malfunctioning, right?

00:05 <ifreund> ghostbuster: indeed, that means river isn't aware of your output at all

00:05 <ifreund> so either wlroots or something lower down is at fault

00:06 <ghostbuster> i have had this issue on sway as well, but it's very intermittent

00:07 <ghostbuster> i think i found a bug report for it before, but now i've forgotten.. i usually subscribe to such things

01:19 <tleydxdy[m]> > <@shinyzenith:matrix.org> Absolutely agree with you on that one. That's why I use emacs even though it creates ~/.

01:19 <tleydxdy[m]> > It's simply a good text editor.

01:19 <tleydxdy[m]> not true for a while now, it does xdg based dir now afaik

01:23 <tleydxdy[m]> * since 27.1

03:15 <Shinyzenith[m]> <ifreund> "Shinyzenith: no luck setting..." <- I searched in artix wikis, no guides. I think I'll scour the gentoo wiki today and get back to you.

03:16 <Shinyzenith[m]> <tleydxdy[m]> "> <@shinyzenith:matrix.org..." <- I just use arch defaults so I probably missed the option. Will check.

05:10 <NickH> tleydxdy[m]: Nice! I just moved everything from my ~/.emacs.d/ to ~/.config/emacs/

12:15 <leon-p> Shinyzenith[m]: Does it only happen when you interact with it? Otherwise you could try to run river in valgrind over night an hope to get lucky.

12:23 <Shinyzenith[m]> <leon-p> "Shinyzenith: Does it only happen..." <- Happens when I try to close windows of chromium aka surface unmap

12:27 <leon-p> I wonder if testing could be automated

12:28 <Shinyzenith[m]> I can try but the crash is too inconsistent

12:31 <leon-p> If you are in de mood for tinkering, try this: Create a new river init script that just launches river, opens chrome, sleep for a minute, closes chrome, sleeps 10 seconds and exits. Now write another script that launches river in valgrind in a loop with that init and let it store the logs somewhere. Leave it running for some time and when you come back grep the logs for a crash

12:37 <Shinyzenith[m]> I was actually already in the process of writing that when power went out :P I'm really out of luck I assume

13:53 <tiosgz> <Shinyzenith[m]> "I searched in artix wikis, no..." <- not sure how exactly you'd go about enabling it globally, but you can enable it for a process tree

13:54 <tiosgz> instead of just `river`, run e.g. `prlimit -c104857600: river`

13:55 <tiosgz> (i also set /proc/sys/kernel/core_pattern to core.%e-%p.sig%s.time%t in my rc.local to get a more informative file name)

13:58 <leon-p> (or use a sane distribution that does not diable coredumps by default)

13:59 <ifreund> core dumps may contain sensitive information such as cryptographic secrets, disabling them by default isn't crazy

14:01 <leon-p> which is not a problem if your drive is encrypted

14:08 <ifreund> what distro does that by default though? :P

14:09 <leon-p> none, unfortunately

14:09 <leon-p> I never said I actually consider any distribution sane :D

14:09 <ifreund> ::D

14:12 <tiosgz> reminds me of river's readme: ...example init script with sane defaults...

14:14 <ifreund> yeah, should probably s/sane defaults//

14:15 <ifreund> Shinyzenith[m]: on my system there's a really nice checklist in the core(5) man page to debug why a core file isn't being produced

14:16 <ifreund> you can test your configuration by running a trivial program that does nothing but call abort() and make sure that produces a core dump

14:17 <nor[m]> > what distro does that by default though? :P

14:17 <nor[m]> I think Qubes does, might be wrong though xD

14:18 <tiosgz> great that manpage

18:21 <Shinyzenith[m]> <ifreund> "Shinyzenith: on my system there..." <- I'll keep trying and get back to you