<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
<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