00:00jljusten: It should be the person pushing for the external dep to deal with ensuring it can be packaged somewhere. Not them pushing any and all issues out to be investigated and resolved by distro packagers and the like.
00:01jljusten: I do find it frustrating if the conclusion of the wrap system is that we can now shift this burden elsewhere.
00:02jljusten: But, I guess that is the case.
00:09karolherbst: I think it's unreasonable to expect from upstream maintainers, who are probably also very busy, to package a dependency in every distribution. If you just want them to pick any, they could have picked I dunno.. fedora and then you'd have the same issue, probably.
00:10karolherbst: really.. this shouldn't take more than 2 or 3 lines in the packaging to fix
00:40Venemo: MrCooper: FYI - I looked into the bug report that you linked recently. I haven't received any reply from the bug reporter but judging by the details posted on the bugzilla, I believe this was the same crash that I fixed recently regarding VGA connectors. As a side note, this was working fine when we changed to amdgpu by default in Linux 6.19 but was regressed by a refactor commit that AMD landed in Linux 7.0, details here: https://bugzilla.
00:40Venemo: redhat.com/show_bug.cgi?id=2510053#c14
00:48jljusten: karolherbst: It's not about making them doing the packaging work. It's about them doing the work to make sure it should go smoothly for packaging before adding the dep.
00:49karolherbst: jljusten: that's already possible... just add the dep as an additional tarball to the mesa package, unpack it as a subporject and it should just work, no?
00:51jljusten: I guess "pre-wrap" we'd want to say, it's in a couple big distros. Maybe now it should just be, "you were able ninja install the dep and build without the wrap".
00:59karolherbst: sure, but sounds like more work for 0 benefits atm, so could just do the trivial ting and move on and wait until it can be installed and then it doesn't matter, because nothing else uses it (probably)
01:02dwfreed: "meson subprojects download" will download all subproject sources so that "meson setup" does not need a network connection
01:04karolherbst: yeah.. but packaging usually wants to checksum archives and such
01:05karolherbst: and also not rely on random URLs
01:15llyyr: jljusten: karolherbst https://gitlab.freedesktop.org/virgl/venus-protocol/-/merge_requests/122
01:26dwfreed: karolherbst: sure, but one can do that locally and then include the results in their packaging
14:57tacokoneko: hello, is there someone here who cross-compiles mesa from 64-bit x86 GNU/Linux to 64-bit ARM GNU/Linux and it works?
17:29Ristovski: tacokoneko: I haven't done it, but I assume it should Just Work(tm) with a proper meson cross file
17:29Ristovski: https://docs.mesa3d.org/meson.html#cross-compilation-and-32-bit-builds
17:37tacokoneko: Ristovski: I see, I have been trying to do that but I'm having this problem https://pastebin.com/raw/W0zR3m7B
18:57pendingchaos: tacokoneko: I think the problem is that meson is trying to build a x86-64 vtn_bindgen2 with arm .a files
18:57pendingchaos: I had a similar problem with cross-compilation with a x86-64 build and x86 host and fixed it by setting "needs_exe_wrapper = false" in the cross file
18:57pendingchaos: I doubt that would work for arm though, so maybe one possible solution would be to set an exe wrapper: https://mesonbuild.com/Cross-compilation.html#binaries
18:58pendingchaos: I think you should also be able to instead do -Dmesa-clc=system and supply the mesa_clc/vtn_bindgen2 from a x86-64 build somehow?
19:08tacokoneko: I see, thanks, I will try to make -Dmesa-clc=system work in case that helps
19:09tacokoneko: unfortunately, for my use case i'm actually not allowed to use an exe wrapper that involves running the target binary,
19:09tacokoneko: only to make reimplementation or temporary executables that run on the build machine, like the llvm-config in my document