ifreund changed the topic of #river to: river - a dynamic tiling wayland compositor || https://github.com/riverwm/river || channel logs: https://libera.irclog.whitequark.org/river/
monaaraj has quit [Ping timeout: 256 seconds]
monaaraj has joined #river
kindablue has left #river [#river]
kindablue has joined #river
anb1 has joined #river
Grawp has quit [Quit: Client closed]
pkap has quit [Quit: Client closed]
<ifreund> alebastr: yep, it targets the native cpu/os/abi by default
<ifreund> not totally sure if I agree with that default or not yet tbh
<alebastr> hm. zig build --help states that -Dcpu is a project specific option. is it inherited from std.build and there are alternative builder implementations that won't support the option?
<ifreund> alebastr: if you use std.build.standardTargetOptions() in your build.zig it will expose the -Dtarget and -Dcpu options
<ifreund> which every build.zig I've seen does in practice
<alebastr> which means it's relatively safe to move -Dcpu to our rpm macros for zig. good.
<ifreund> alebastr: I'd consider a zig project using the zig build system that would be packaged for a linux distro not supporting -Dcpu or -Dtarget a bug with that zig project
<ifreund> alebastr: the void linux build sytle I wrote for the zig build system may be interesting to you: https://github.com/void-linux/void-packages/blob/master/common/build-style/zig-build.sh
<alebastr> ifreund: so -Drelease-safe is also global. do I need to specify target if we never cross-compile? I'd guess that zig is able to detect the current target
<ifreund> alebastr: indeed, it will detect the native target just fine, Evo2 discovered that zig currently puts some unnecessary runpaths in the resulting binary when using the native target though
<ifreund> I'll be taking a look at that and the related possible regression tomorrow
<alebastr> oh. so that doesn't happen if the target is explicitly specified? Not a big issue for me as we can always recommend to chrpath the binaries, but would be nice to avoid that.
<alebastr> and I assume that -Dcpu is being passed to llvm and will share possible values with clang's -mcpu, right?
<ifreund> yeah, I'll get it fixed upstream at some point, won't be the first upstream zig fix to come out of try to package river
<ifreund> alebastr: nope, it's not passed directly to llvm
<ifreund> the possible values can be seen with `zig targets`
<ifreund> (warning, there are tons of cpu options, jq is recommended)
<ifreund> you probably just want "baseline" though when packaging unless targeting arm
<alebastr> well, here's my hope to extract the cpu baseline from our gcc optflags and pass it to the compiler directly. time to write an awkward conditional for all arches we support
<alebastr> smh I doubt baseline will be an exact equivalent to '-mcpu=k8 -mtune=generic'
<ifreund> it pretty much does that for all the arches void supports, which is a fair number
<ifreund> zig doesn't support -mtune yet, maybe eventually
<ifreund> does it even have a significant affect in practice? would certainly be interested if anyone knows of good benchmarks
<alebastr> unlikely if your cpu baseline is too old. -mtune is not a magic, it just uses the same old set of instructions maybe slightly differently
<ifreund> yep, I'm aware what it does. I'm looking for anything that would be a strong reason for zig to support it
<ifreund> it's not clear that it would be worth doing
steef[m] has joined #river
steef[m] is now known as steef
<steef> hello!
<steef> I just installed river on Arch using the AUR and wlroots from community-staging
<steef> (so my setup may be a bit unstable)
<steef> I have an issue where xwayland windows from multiple tags seem to "overlap" each other (taking input)
<steef> I'm not sure how to describe it best, but the situation is e.g. the following:
<steef> I have one Xwayland client that e.g. takes the whole screen on tag 2
<steef> I also have a small Xwayland client that takes a part of the screen on tag 1
<steef> I am on tag 2
<steef> I click on the Xwayland client on tag 2: the right window gets the input
<steef> I click on the Xwayland client on tag 2, inside the dimensions of the window on tag 1: window of tag 1 takes the input
<steef> So e.g. while I am clicking inside one window on tag x, the input actually goes to a window on tag y
<steef> Is this a known issue? I've searched on GH but I'm not sure how to describe this
<steef> sometimes it even gets to the point where I can see tooltips from the "underlying window" on the other tag
<steef> Looking through the irc logs it seem that norkki had the same issue
<steef> norkki: are you also using wlroots from arch community-staging?
<ifreund> steef: that xwayland issue has been fixed on master branch but not yet included in a release
<ifreund> using the wlroots-git AUR package would also work fine, just check out the 0.15.0 git tag
<steef> ifreund: ah, thank you! master branch works perfectly :)
snakedye has quit [Ping timeout: 256 seconds]
<alebastr> ifreund: "in cross-compilation mode, which Zig enters when you explicitly specify the target, no search paths are populated since we don't know where to expect them."
<alebastr> that's from Jakub's comment for one of ziglang/zig issues
<steef> ah yeah I should have done that
waleee has quit [Ping timeout: 256 seconds]
monaaraj has quit [Ping timeout: 240 seconds]
monaaraj has joined #river
notzmv has quit [Ping timeout: 240 seconds]
monaaraj has quit [Ping timeout: 240 seconds]
monaaraj has joined #river
notzmv has joined #river
monaaraj has quit [Ping timeout: 240 seconds]
monaaraj has joined #river
snakedye has joined #river
noopdecoder has joined #river
noopdecoder has quit [Quit: noopdecoder]
Misthios has quit [Quit: Misthios]
Misthios has joined #river
Misthios has quit [Client Quit]
Misthios has joined #river
Misthios has quit [Client Quit]
Misthios has joined #river
Misthios has quit [Client Quit]
monaaraj has quit [Ping timeout: 240 seconds]
Misthios has joined #river
monaaraj has joined #river
Misthios has quit [Client Quit]
Misthios has joined #river
Misthios has quit [Client Quit]
Misthios has joined #river
monaaraj has quit [Ping timeout: 256 seconds]
<norkki> steef: I'm building wlroots and river from source
monaaraj has joined #river
<steef> thank you. Turned out that the overlapping thing didn't have to do with that, sorry for the ping
monaaraj has quit [Ping timeout: 240 seconds]
steef has quit [Quit: Reconnecting]
monaaraj has joined #river
steef has joined #river
monaaraj has quit [Ping timeout: 256 seconds]
monaaraj has joined #river
<chipps_> ifreund: how can I use wlroots-git with 0.15.0 git tag from the aur?
chipps__ has quit [Quit: WeeChat 3.4]
<ifreund> chipps_: cd into the git repository cloned by the PKGBUILD and do `git checkout 0.15.0`
<chipps_> oh thanks. Didn't know it's just a branch
<ifreund> 0.15.0 is a tag, but `git checkout` works on any ref not just branchs
<steef> You can also specify it in the source url in the PKGBUILD (see Using VCS sources in man PKGBUILD)
waleee has joined #river
<chipps_> steef: I'm trying to specify it in the source url in the pkgbuild, so I just did source=("...#tag=0.15.0"). Now it's stalled at the cloning stage
<chipps_> am I doing something wrong here?
monaaraj has quit [Ping timeout: 256 seconds]
monaaraj has joined #river
Ollie[m] has quit [Quit: You have been kicked for being idle]
<steef> chipps_: Hmm, I don't think so, but I have the same
<steef> I think it might be the dots in the tag name, I tried looking into makepkg source but I don't quickly see where it goes wrong
<ifreund> I can't really help, I use void these days. Probably better off asking in #archlinux
monaaraj has quit [Ping timeout: 256 seconds]
<steef> chipps_: after removing the already cloned git repository from a previous makepkg run it works for me
monaaraj has joined #river
monaaraj has quit [Ping timeout: 256 seconds]
monaaraj has joined #river
monaaraj has quit [Ping timeout: 240 seconds]
monaaraj has joined #river
noopdecoder has joined #river
<norkki> why do programs using SDL ignore caps:espace?
<norkki> escape acts as escape and caps lock does nothing
<leon-p> norkki: probably because SDL uses the key events directly, without "translating" them using a keymap.
<leon-p> SDL does a lot of weird things, so this is really not surprising, unfortunately
<norkki> so there's no fix for this?
<leon-p> if there is one, you'll probably have a better chance of finding it by searching online than asking here, I am afraid
<norkki> I'll try searching for one
<ifreund> yeah, if SDL really isn't using an xkbcommon keymap that's an SDL bug sorry
monaaraj has quit [Ping timeout: 240 seconds]
monaaraj has joined #river
<ifreund> norkki: looks like this one's already been fixed though: https://github.com/libsdl-org/SDL/issues/3471
<norkki> just noticed that myself
<norkki> maybe the programs I'm using are using an older version of SDL since the merge is quite new
pkap has joined #river
monaaraj has quit [Ping timeout: 256 seconds]
monaaraj has joined #river
notzmv has quit [Read error: Connection reset by peer]
notzmv has joined #river
noopdecoder has quit [Quit: noopdecoder]
notzmv has quit [Ping timeout: 268 seconds]
monaaraj has quit [Ping timeout: 256 seconds]
monaaraj has joined #river
monaaraj has quit [Ping timeout: 240 seconds]
monaaraj has joined #river