13:48mareko: DavidHeidelberg: that would never happen, Mesa is tightly dependent on libdrm, they both advance in lockstep, when the libdrm version is bumped, 99% of the time we need to bump the Mesa->libdrm requirement the same day
13:50mareko: DavidHeidelberg: it's never a good idea to use libdrm from the distro with mesa/main
13:52mareko: DavidHeidelberg: libdrm changes are mostly made when Mesa needs them, and when Mesa needs them, it needs them immediately
13:53mareko: DavidHeidelberg: the gitlab-ci change doesn't work for all jobs, and I'm out of ideas
13:55mareko: DavidHeidelberg: the other project that is problematic to use from the distro is llvm
13:56mareko: debian having too old LLVM has been a problem in the past to the point that we considered removing the jobs from the CI because it was too much pain in the ass
14:02mareko: llvm could be installed from the llvm.org apt source
14:10mareko: DavidHeidelberg: Merry Christmas, how to fix the libdrm issue in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26643 ?
15:28mareko: DavidHeidelberg: sorry if some of my comments were harsh
15:38eric_engestrom: FWIW, at the time I said that it was a mistake to remove the "build libdrm locally" code in favour of installing from debian repos just because debian had just updated its libdrm; I said that we were going to have to revert all that code sooner or later... looks like we have reached that point 🤷
15:39karolherbst: mareko: looks like virglrender needs libdrm, and if you force remove it, it can't find it anymore
15:39karolherbst: or if you don't install it
15:40karolherbst: but it's kinda weird, because I don't see it being removed in that `debian/x86_64_test-base` job
15:44karolherbst: mareko: +1 to using llvms deb repos
15:44karolherbst: and we should just use those going forward
16:10DavidHeidelberg: eric_engestrom: or we could just install recent libdrm package..
16:13DavidHeidelberg: mareko: can I propose just doing "wget $pkg && dpkg -i $pkg && rm $pkg" please?
16:13DavidHeidelberg: I can give you the commit / sent the MR
16:48eric_engestrom: DavidHeidelberg: sure, but even if we maintain our own packages, this is still quite the burden for driver devs, and really pointless for something tiny like libdrm
16:48eric_engestrom: for deqp it's a good idea, but not for libdrm
16:49DavidHeidelberg: hmm, I see it's not bumped yet and I don't have deb-ci-repo ready yet; for the ugly stuff, I would just override the libdrm and kept the package installed
18:19karolherbst: or we just built it and install it system wide. Do we have any dependencies installed actually needing libdrm?
18:19karolherbst: there is no point using packages if it's just annoying us
18:19karolherbst: which with libdrm is the case, so we should just build it ourselves _forever_
18:20karolherbst: and using debian's package was a mistake imho
18:20karolherbst: which we shouldn't repeat
18:21karolherbst: and if debian makes this a pain for us, maybe using debian was a mistake...
18:23karolherbst: and I think pinning the libdrm version in CI also gives us the advantage, that libdrm bumps are actually done correctly (in some sense). There is this "depending on the config we use a certain version" but at least disitributions go with the highest one there anyway
18:24karolherbst: and then _if_ we wnated to replicate that via a deb rep, we'd have to keep all versions we care about (from all stable branches) and CI needs to install the specific version we need. Building libdrm inside CI kinda sounds like the easier and better solution here...
18:25karolherbst: also.. other package managers have the option to mark a package as installed even though it isn't. Couldn't find if apt supports, some others do.
18:26karolherbst: (the idea here is, that you compile and install system wide, and then tell the package manager it's already taken care of and it can just assume it's there)
19:16robclark: DavidHeidelberg: it is useful to be able to build libdrm from a libdrm MR sometimes.. not for marge pipeline necessarily, but in other cases