Following on from bug 739598, if no USE flags are set, attempting to build mesa will fail with a complaint of "building dri drivers require at least one windowing system or classic osmesa". I haven't tested any further, at the time of writing. Perhaps it needs something along the lines of "^^ ( X osmesa wayland )".
Why are you running into these cases?
The reason was explained in the previous bug. I don't even use mesa, but need it to satisfy a Python wheel as a simple technicality (link-time requirement for unused functionality). I don't _need_ to build it with no flags, as such. I was determining, again, whether it was possible. Besides, I don't see how it is material. For the choice of selected USE flags to lead to an error raised by the build system rather than portage is a QA issue, is it not?
To clarify, this can be reproduced with USE="-*" emerge =mesa-20.2.4.
I've taken a closer look at how the build system works and began trying to figure out a solution. So far, I'd say I'm about half way there. As far as REQUIRED_USE is concerned, a potential solution may end up looking something like this: || ( X classic egl gbm osmesa ) classic? ( !osmesa? ( || ( X egl gbm ) ) ) osmesa? ( !classic? ( || ( X egl gbm ) ) ) For an explanation as to why, I shall attach my current notes. In particular, note that the combination of "classic" and "osmesa" is one that is ostensibly supported. However, as things stand, one cannot specify either alone - or neither - while also specifying none of X, egl and gbm. To do so leads to the error reported in the opening comment. Specifying USE="-* classic osmesa" reveals a new QA issue, which is that the build system bails out with: Build-time dependency wayland-scanner found: NO (tried pkgconfig and cmake) This issue is easy to explain. The ebuild specifies -Dplatforms conditionally, but shouldn't. The reason is that, if it is missing outright, it will be inferred as being "x11,wayland", which is a violation of the intent of their respective USE flags. Fixing that reveals yet another previously unseen QA issue. The build actually succeeds but produces files that can conflict with media-libs/libglvnd (the details are in the notes). So, the constraints either need to be tightened up further or may even need to express a package block. That's all, so far.
Created attachment 678049 [details] bug-759139-diagnosis-notes.txt
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3a4de1a00cc1f5de3feb0956bccf7b5cd908f921 commit 3a4de1a00cc1f5de3feb0956bccf7b5cd908f921 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2021-01-15 00:56:41 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2021-01-15 01:34:27 +0000 media-libs/mesa: Always specify -Dplatforms=... Otherwise it will default to -Dplatforms=auto, which includes Wayland. Many thanks to Jan Burgmeier for debugging the issue and providing the fix. Closes: https://bugs.gentoo.org/759139 Closes: https://bugs.gentoo.org/759319 Signed-off-by: Matt Turner <mattst88@gentoo.org> media-libs/mesa/mesa-20.2.4.ebuild | 2 +- media-libs/mesa/mesa-20.2.6.ebuild | 2 +- media-libs/mesa/mesa-20.3.2.ebuild | 2 +- media-libs/mesa/mesa-9999.ebuild | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-)
I was the one that debugged the issue. I specifically explained in comment 4 that "the ebuild specifies -Dplatforms conditionally, but shouldn't". That aside, neither of the other two QA issues I have mentioned in the same comment have been commented on or addressed. For that reason, I am re-opening.
I am sorry that I missed that. My apologies.
(In reply to Matt Turner from comment #8) > I am sorry that I missed that. My apologies. No problem. I'll attach a build.log soon.
Just to recap, I opened this bug initially on account of one observed QA issue, along with a misguided notion of how it might be fixed. Subsequently, I endeavoured to better understand how the build system works. In the course of doing so, I was able to suggest a way of augmenting REQUIRED_USE in a way that might properly address the issue. At the same time, I encountered two further QA issues. I explained all of these in comment 4, and in even greater detail in the attached "diagnosis" notes. Further, I did not want to split these three issues into separate bugs at the time, owing to their finnicky and potentially inter-connected nature. As someone who initially knew nothing of mesa's build system, it was a challenge for to get that far. In any case, the three issues were as follows. 1) REQUIRED_USE insufficiently strict, allowing for combinations raising an error of "at least one windowing system or classic osmesa" being required. Reproducers:- USE="-*" emerge =mesa-20.2.4::gentoo USE="classic" emerge =mesa-20.2.4::gentoo USE="osmesa" emerge =mesa-20.2.4::gentoo 2) USE choices raising an error of "Build-time dependency wayland-scanner found: NO". Now fixed by commit 3a4de1a. 3) USE choices resulting in file conflicts between media-libs/mesa and media-libs/libglvnd. Reproducer:- emerge libglvnd && USE="-* classic osmesa" emerge =mesa-20.2.4::gentoo So, #1 and #3 still apply, with it being more obvious as to how to address #1. As alluded to previously, I'm not sure whether it's worth tolerating the flag combination that triggers #3. My hope is that somebody better versed in how mesa is used in the real world can make that decision. Anyway, build logs for both remaining issues are coming.
Apologies but the reproducers for #1 should have written as follows. USE="-*" emerge =mesa-20.2.4::gentoo USE="-* classic" emerge =mesa-20.2.4::gentoo And the reproducers for #3 as follows. emerge libglvnd && USE="-* classic osmesa" emerge =mesa-20.2.4::gentoo emerge libglvnd && USE="-* osmesa" emerge =mesa-20.2.4::gentoo
Created attachment 682972 [details] build.log for sub-issue #1
Created attachment 682975 [details] build.log for sub-issue #3 (xz compressed)
You're operating now on the 3 issues that you bundled all into this, like file collision and required use. Please open separated bugs about them, as to clearly state what is the problem. This bug no longer serves it's initial purpose about building with USE=-*.
(In reply to Piotr Karbowski from comment #14) > You're operating now on the 3 issues that you bundled all into this, like > file collision and required use. Please open separated bugs about them, as > to clearly state what is the problem. This bug no longer serves it's initial > purpose about building with USE=-*. Please don't close bugs if you haven't bothered to read or understand them. The bug was opened for what I later referred to as "sub-issue 1". This issue _still_ applies and was _not_ rectified by Matt's recent commit. Go try building the stable version with USE="-*" now and see what happens. I'll wait. Then go and read from the top and tell me with a straight face that the originally reported bug is RESOLVED. This is the second time now that the bug has been erroneously closed. Please stop. It's almost as if there is a greater degree of energy being invested into making me go away rather than to read a single, solitary word that I've written. Indeed, I had to begin by effectively defending my position that this is a legitimate QA bug to begin with. I spent hours root-causing the original issue, including the others that I subsequently discovered. I made the effort to convey my findings in great detail, making what I think is a sensible suggestion to fix the original subject of this bug, as well as a demonstrably correct suggestion for the other (sub-issue 2). I have no expectation of bugs being addressed, frankly, but I feel that the least anyone could do if they are going to comment is to read and understand the prior commentary. At this point, only sub-issue 3 is eligible for being spun off as a separate bug. Of course, I'd have to edit, copy and paste some of what I've posted here, including the attachments. If you hadn't thundered in like a bull in a china shop and tried to shut this one down, I might actually be amenable to doing that. Now, I am not. Opening a new bug just to swim against the tide is not an enticing proposition to me. At this point, I would very much like for the originally reported bug to be addressed, if possible. Rest assured, I shall then be on my way and shall elect not to file any bugs against this package in the future.
(In reply to Kerin Millar from comment #11) > Apologies but the reproducers for #1 should have written as follows. > > USE="-*" emerge =mesa-20.2.4::gentoo > USE="-* classic" emerge =mesa-20.2.4::gentoo > > And the reproducers for #3 as follows. > > emerge libglvnd && USE="-* classic osmesa" emerge =mesa-20.2.4::gentoo > emerge libglvnd && USE="-* osmesa" emerge =mesa-20.2.4::gentoo Thank you. I got wrapped up in all the info before. This is great. I'll take a look.
I've removed gbm, egl USE flags. IUSE=classic/gallium are also now gone now that the classic drivers have been removed upstream. I'm not sure if there's anything more to do here, but I don't want to incorrectly close the bug early again. :)
(In reply to Matt Turner from comment #17) > I've removed gbm, egl USE flags. IUSE=classic/gallium are also now gone now > that the classic drivers have been removed upstream. Interesting. > > I'm not sure if there's anything more to do here, but I don't want to > incorrectly close the bug early again. :) Is mesa-21.3.1 representative of these changes? I gave that version a quick spin with USE="-*". It fails, albeit for different reasons that were originally cited by my report. Hence, there remains at least one QA issue that would imply an amendment to REQUIRED_USE. That's as far as I've checked because I lack the motivation to proper re-assess the package at this juncture. Unless that changes, I have no further stake in this bug.
mesa-22.0.0_rc1 builds with USE=-*.
(In reply to Matt Turner from comment #19) > mesa-22.0.0_rc1 builds with USE=-*. Thanks.
