01:02luc: MrCooper: https://pastebin.com/KjcuUX36 such an error seems like a bit obscure regarding what happened here for an end user. how about just validate ->getSwapInterval() before calling it? https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/glx/glx_pbuffer.c#L289
01:06luc: the same seems to happen in EXT_buffer_age support https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/glx/glx_pbuffer.c#L281
05:47tjaalton: I'm new to the rust nonsense, so when meson is trying to find {syn,paste}.pc for nvk, and the -dev packages don't even ship those, what should I do to enable nvk?
05:48alice: subprojects/thing.wrap defines a patch that adds a meson.build to those
05:49alice: if you don't build with --wrap-mode nofallback/nodownload it's automatic
05:50tjaalton: well I can't download
05:50tjaalton: during pkg build
05:50tjaalton: have to use readily available packages
05:50alice: there's usually a pre-build step where you can, and a sources= list
05:51alice: the other option is to manually download all the declarared tarballs the .wrap files declare
05:51tjaalton: no I can't, not for the official debian pacakges
05:51alice: and put them in a folder
05:51alice: and then you can pass MESON_PACKAGE_CACHE_DIR= to the folder that has the .tar.gz's of them
05:52alice: but if you're expecting to use the debian /usr syn then you can't i guess
05:52tjaalton: I'm not going to vendor these
05:52tjaalton: sigh
05:52alice: the way meson consumes the rlibs is by having a meson.build for them (that is inside mesa, declared as a patch)
05:54alice: (the only reason it looks like it looks for a .pc is because that's what meson does for dependency() )
06:01tjaalton: ahah, I see the fedora mesa pkg does some tricks..
06:04clee: tjaalton: aha, I see you're here too :)
06:05tjaalton: oh hai
06:05tjaalton: yeah almost threw the towel in..
06:05clee: I did manage to get it to build and work locally but I just hit it with a large hammer and enabled --wrap-mode=default, probably completely unsuitable for debian packaging
06:06tjaalton: though I'm about to leave on PTO in 6h, and back after three weeks.. so I might not be able to squeeze this in before I leave
06:06clee: no rush
06:06clee: enjoy the vacation!
06:06tjaalton: ta
08:51sima: airlied, I did a backmerge for drm-next because one of the pulls had newer baseline, otherwise nothing special last week
08:51sima: maybe double check I didn't miss any pulls, I guess everyone sent theirs before merge window so there was a bit more than usual
09:47MrCooper: sima: keep in mind drivers/gpu/drm/amd/amdgpu/dce_v*.c is non-DC code, DC never enables vblank_disable_immediate since f64e6e0b6afe ('Revert "drm/amdgpu/display: set vblank_disable_immediate for DC"')
09:47sima: MrCooper, oops, I got mislead by the classic
09:48sima: but yeah sounds like a proper fix is needed instead of more artisan duct tape
09:49sima: MrCooper, are you replying with that commit or should I?
09:49sima: or hwentlan_ ^^
09:51MrCooper: feel free
10:10sima: done
14:56mripard: mlankhorst, tzimmermann: ping for https://oftc.irclog.whitequark.org/dri-devel/2024-07-08#33332906 ?
15:00Calandracas: alyssa, for cross compiling asahi_clc, is it reasonable to simply build it for the host machine, and rely on exe_wrapper being set in the meson cross file?
15:01Calandracas: I've been able to cross compile it with a simple one line patch, if this is a reasonable approach, I'll create a MR
15:18Calandracas: nvm, I didn't see that it was changed to `native : not meson.can_run_host_binaries()` which accomplishes the same thing
16:52alyssa: Calandracas_: Yes, that should probably work
16:53Calandracas: it already works. all that I needed to do was provide the exe_wrapper :P
16:54alyssa: cool
16:54Calandracas: meson.can_run_host_binaries() evalutates to `true` only when exe_wrapper is set
16:55Calandracas: although I would still argue that it should be removed. the check doesn't accomplish anything useful, and only (imo) causes confusion
16:55Calandracas: if host binaries can't be run, the build will fail
16:56Calandracas: if that line is removed, then error message provided by meson is much more helpful
16:59Calandracas: karolherbst, would you recommend distributions ship your SPIRV-Tools patch?
17:04alyssa: ok
18:55alimj: Hi. I wonder if Freedesktop's Plymouth development questions could be asked here.
18:55alimj: My question is on this function: https://gitlab.freedesktop.org/plymouth/plymouth/-/blob/main/src/libply-splash-core/ply-terminal.c?ref_type=heads#L912-920
18:55alimj: I do not understand the logic here. State is not set to any value and it appears that LED_CAP is undefined
18:56alimj: I am exploring the possibility to implement Plymouth.GetNumlockState function. This is useful for laptops with smaller keyboards which have LUKS encryption.
19:07llyyr: what do you mean? the led state is stored in the state variable
19:07llyyr: did you link the wrong rev or something
19:26alimj: llyyr: Oh I missed the & reference before the state variable. I have been too long away from C. What about the LED_CAP constant? I did not find it anywhere in the header files or anywhere else.
19:27llyyr: it comes from ioctl headers, check "man ioctl_kd"
19:27alimj: llyyr: Thank you very much for the info
19:28llyyr: also this isn't the right channel for this I believe
19:28llyyr: it's #plymouth on libera
19:29alimj: llyyr: Thanks again. You are a saviour. What is this channel BTW? For general Freedesktop development?
19:29llyyr: Mesa and the linux graphics stack in general
19:30alimj: Oh. I see. Thanks again. I will remember this for the future
22:27gfxstrand: tjaalton: RE https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075858f
22:27gfxstrand: tjaalton: Is there anything I can do to help?
22:28gfxstrand: There's an environment variable you can set which tells meson to look elsewhere for crates
22:29gfxstrand: Looks like MESON_PACKAGE_CACHE_DIR is the thing to use
22:32gfxstrand: On Fedora, if I set MESON_PACKAGE_CACHE_DIR=/usr/share/cargo/registry/, everything builds from locally installed tarballs
22:32gfxstrand: Well, I guess not tarballs
22:32gfxstrand: fedora untars them
22:56clee: gfxstrand: I think they're officially on vacation by now
22:56clee: maybe we can trick daniels into doing it instead :D
23:16HdkR: `should include NVK driver on amd64` Shouldn't it exist on more than amd64?
23:19alice: yea but the report is specific to what the user wanted
23:20HdkR: Makes sense. Hopefully the package maintainer extrapolates that request to NVK being built for all arches :P