02:14kisak: it looks like I need to bump wayland to 1.23.0 so that wayland-scanner is new enough to not throw `/home/kisak/packaging-build/wayland-protocols/1.38/test/wayland-protocols-1.38-n/stable/linux-dmabuf/linux-dmabuf-v1.xml:113: element event: validity error : No declaration for attribute deprecated-since of element event` in wayland-protocols 1.38, which is needed for mesa 24.3.0.
02:18kisak: I could look at disabling tests in the wayland-protocols build and call it good or would it be better to bump wayland 1.23 in the build environment? If I bump wayland, then is the new version a runtime dependency?
02:19kisak: (runtime dependency of mesa)
02:38kisak: Looks like I'll take the disabled test route for now and if there's other trouble later, then I'll bump wayland.
03:00oneforall2: hmm mesa how do I get it to build the internal direct-xheader?
03:00oneforall2: DirectX-Headers*
03:09oneforall2: mv I see I need to update mesa-subprojects.tar.lz
03:40oneforall2: I for5get where to get that
10:26mairacanal: hey, is pushing to drm-misc-next-fixes already open?
10:29ukleinek: ..ooOO(fixes is always open?)
10:33kj2: kisak: See issue #12126 . Tests were disabled with !32036
10:33mairacanal: ukleinek: afaik we should push to drm-misc-next-fixes on the merge window, not drm-misc-fixes
10:39ukleinek: mairacanal: ah. Don't know, but I would have expected that there is a single (always-open) fixes branch. Either it's a fix and then urgent, or it's not and can go to -next?!
10:53javierm: ukleinek: notice the difference between drm-misc-next-fixes and drm-misc-fixes
10:58javierm: https://drm.pages.freedesktop.org/maintainer-tools/repositories/drm-misc.html#drm-misc-next-fixes and https://drm.pages.freedesktop.org/maintainer-tools/repositories/drm-misc.html#drm-misc-fixes
11:38ukleinek: javierm: ah I see. This is needed because drm-misc isn't pulled directly into the mainline, right?
11:39mairacanal: tzimmermann, mripard, if you have some time, could you take a look at drm-misc-next-fixes permissions? i was able to push a patch to drm-misc-next, but, for drm-misc-next-fixes, GitLab returned that i didn't have permission to push code
11:39javierm: mairacanal: I believe that's on purpose because many people wrongly pushed to drm-misc-next-fixes stuff that wasn't meant for drm-misc-fixes
11:40javierm: and you should ask one of the drm-misc maintainers to push to that branch
11:40ukleinek: s/wasn't/was/ I guess
11:41javierm: ups, you are correct
11:42javierm: ukleinek: and yeah, drm-misc-next-fixes is because there's a small window between X-rc6 and (X+1)-rc1 that there are no drm-misc-next pulls anymore for X+1
11:42javierm: but drm-misc-fixes isn't pulled after -rc1, so drm-misc-next-fixes is for patches that were pulled up to -rc6 but need fixes for -rc7 or -rc8
11:43javierm: ukleinek: dunno if that explanation makes it more clear or more confusing after re-reading it :)
11:46mairacanal: javierm, thanks for the info! the last time I pushed to drm-misc-next-fixes was still in the git.freedesktop.org, i didn't know it changed in gitlab
11:47mairacanal: but maybe we should update the committer guidelines, i still see drm-misc-next-fixes in the flowchart (https://drm.pages.freedesktop.org/maintainer-tools/committer/committer-drm-misc.html#where-do-i-apply-my-patch)
11:50javierm: mairacanal: not an authoritative answer though, just my understanding :)
11:50javierm: and agree that if this is the case, we need to change the guidelines doc
19:32alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/67062464
19:32alyssa: ughhhhhhhhhhhhhh
19:32alyssa: src/compiler/spirv/meson.build:80:19: ERROR: Tried to tied to mix a host machine library ("vtn") with a build machine target "vtn_bindgen" This is not possible in a cross build.
19:32alyssa: *melts*
19:34alyssa:adds more meson
19:52kisak: karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/commit/cc37ecc7ba300122647d529e966e4c966b8cdc14 is disappointing and has voided support for rusticl/NVK on Ubuntu 24.04. I'm not going to fight your policy, but I can frown at unusable toolchain timing.
19:53karolherbst: kisak: 1.76 is a problem?
19:53karolherbst: how?
19:53kisak: 24.04 doesn't have it
19:53karolherbst: you need it to compile firefox
19:53karolherbst: so you either have it, or you have unsupported firefox shipped to users 🙃 and I know what's the worst situation here
19:54karolherbst: *worse
19:54kisak: https://packages.ubuntu.com/search?keywords=rustc&searchon=names
19:54karolherbst: how are you compiling firefox then
19:54karolherbst: current firefox ESR needs 1.76
19:54kisak: I'm not, I expect that Ubuntu's shoving it in their snap containers
19:54karolherbst: isn't there a rustc-mozilla package?
19:55karolherbst: ehh wait, it's a debian thing
19:57heat: fyi ubuntu's shipping firefox as a snap now
19:57karolherbst: well...
19:57heat: and the .deb package is fake :)
19:57karolherbst: nice :)
19:57karolherbst: sounds like I'll just ignore ubuntu then
19:58karolherbst: we bumped to 1.78 on main anyway, because it gives us other big benefits, though Firefox ESR is tested against 1.78 as well
20:00karolherbst: anyway.. ubuntu needs a better solution for this
20:01karolherbst: kisak: can't you... use the "rustc-1.76" package?
20:01kisak: first I've heard of it
20:01karolherbst: looks like every version up to rustc-1.80 is packaged as its own thing
20:02karolherbst: it's in the search results you linked to
20:02karolherbst: :D
20:02karolherbst: just at the bottom
20:02kisak: evaluating ...
20:02karolherbst: 1.78 is nice because it enables some asserts in release builds so we can catch more bugs in CI
20:03karolherbst: because we don't want to build rustc ourselves :D
20:03karolherbst: but yeah..
20:03karolherbst: if you can use the versioned rustc packages then that should be good enough I hope
20:08kisak: local built test says no. meson calls rustc and ignores the slotted version.
20:10kisak: so, in theory possible, but it's likely tjaalton would need to help adjust debian's packaging to use slotted rustc
20:11psykose: did you set RUSTC=rustc-1.80 or whatever?
20:14kisak: psykose: that passes configure phase ... so there's a chance
20:25kisak: local build testing with 24.04 came online literally yesterday. Now I'm glad it's up.
20:26tjaalton: I haven't tried backporting anything newer than 24.2.x, and it only requires a newer meson..
20:27tjaalton: so, don't know how hard/easy it is to build with a newer rustc
20:29kisak: tjaalton: my head-start backport notes for you would be directx-headers 1.614.1, wayland-protocols 1.38 which I needed to add `override_dh_auto_configure: dh_auto_configure -- -Dtests=false` to get it to lock in without bumping to wayland-scanner 1.23.
20:30alyssa: so nir_lower_io_to_temporaries is broken
20:30alyssa: this is not what I wanted to discover on Friday afternoon
20:31tjaalton: kisak: I don't need to worry about backports before 25.0.x is final ;)
20:31tjaalton: I mean after 24.2
20:33kisak: local build test passed.
20:33DemiMarie: rustc is a rolling release package now 🙂
21:14kisak: Looks like the build farm came back with green across the board. Thanks karolherbst, psykose for helping knock that back into alignment.
21:15karolherbst: cool!
21:16karolherbst: kisak: but yeah.. main is on 1.78 now, so you'd need to bump it for 25.0 again
21:16karolherbst: but that one also seems to be available, so it should be fine I hope
21:17kisak: nudging debian/control.in and an environment variable in debian/rules isn't excessively painful.