18:53 austriancoder: do you include ci exception update in a git commit or do you put it into a separate commit?
18:54 mareko: both
19:01 austriancoder:is working on an MR where each commit fixes something and would need a ci exceptions update..
21:48 jljusten: Am I seeing it right that Mesa cd4581e393a ("venus: migrate to build with venus-protocol subproject") adds a meson wrap for an external dependency which is, uh, not packaged for any distro, and from what I can see not really amenable to being packaged. ?
22:09 karolherbst: jljusten: what do you mean by "not really amenable"?
22:13 jljusten: karolherbst: I doubt it's much of a gap, but ninja install didn't install anything.
22:21 jljusten: I thought for, say, libdrm, in the past we had an informal goal to have a couple big distros having made the new version available before depending on the new release in Mesa. Is "have a wrap" the bar now?
22:34 karolherbst: well at least for development purposes the wraps are doing the job until it gets packaged
23:21 jljusten: Yeah it helps, but there are consumers of the Mesa main branch that would like to build in a sandbox environment.
23:21 karolherbst: sure, but that's kinda the experience people sign-up for when building straight from main
23:24 jljusten: I was going to work on packaging venus-protocol, and it appears no one even considered such a thing before adding it as an external dependency.
23:25 dwfreed: meson has a "download all the subprojects (including wraps)" command to run with network access before running the actual build without network
23:27 jljusten: Is it not reasonable to expect that an external dependency of Mesa would be installable as an external dependency on the system before making it an external dependency of Mesa?
23:33 karolherbst: well sometimes those things are unintentional, probably best to file an issue to explain the pain points
23:35 karolherbst: but it's just header files anyway unless I missed something
23:35 karolherbst: so you could probably have a trivial script that just installs those files somewhere
23:38 karolherbst: but yeah it should probably allow you to install it and add a *.pc file or something
23:42 jljusten: I still think having a goal to have one or two major distros packaging the new external dependency is worth while.
23:43 dwfreed: not really
23:44 dwfreed: distros aren't going to package something until it's needed, if it's only needed for mesa and friends, and mesa and friends can't use it until it's packaged in distros, you have a catch-22
23:44 karolherbst: I mean.. it's the main branch.. the next release is due in November. I'm sure we'll all manage to get it working by then
23:44 jljusten: Well, you are potentially pushing the effort of resolving such issues from the dev that wants to push for the new external dependency onto whoever wants to build the project without wraps.
23:45 karolherbst: the dep already existed
23:45 karolherbst: it was just vendored in tree
23:45 karolherbst: the same work has to be done regardless...
23:46 karolherbst: like I don't even disagree that the dependencies project should be fixed
23:46 karolherbst: and that it should be easier to install, etc..
23:47 karolherbst: but it's the main branch, mistakes happen
23:47 karolherbst: you caught it, great, now we can resolve the problems
23:49 jljusten: Well, that's where the goal to have it packaged first comes in. Even to have attempted to have it packaged...
23:53 dwfreed: Nobody's going to be packaging something that's only new in the main branch
23:56 karolherbst: it's not like the fix is even difficult... could just make the mesa package download the archive, place it as a subprojects like the other things, and that should be good?
23:56 karolherbst: like it's okay if you just want to vent here, but I honestly don't see the big issue here
23:56 karolherbst: it's not like it's a massive dep that's a pita to build
23:58 karolherbst: but you are also free to review MRs that touch dependency stuff and help us catch those issues earlier