| View previous topic :: View next topic |
| Author |
Message |
Tout
n00b
Joined: 18 Jul 2020
Posts: 41
|
 Posted: Tue Jul 23, 2024 5:24 pm Post subject: [RESOLVED] Help needed reading portage output llvm_slot |
 |
|
Hi,
So updating my system. Running into the following:
| Code: |
!!! The ebuild selected to satisfy "media-libs/mesa[wayland,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?]" has unmet requirements.
- media-libs/mesa-24.1.3::gentoo USE="X llvm lm-sensors (opengl) proprietary-codecs vaapi vdpau vulkan wayland zstd -d3d9 -debug -opencl -osmesa (-selinux) -test -unwind -valgrind -vulkan-overlay -xa" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse2" LLVM_SLOT="-15 -16 -17 (-18)" VIDEO_CARDS="-d3d12 (-freedreno) -intel -lavapipe (-lima) -nouveau (-nvk) (-panfrost) -r300 -r600 -radeon -radeonsi (-v3d) (-vc4) -virgl (-vivante) -vmware -zink"
The following REQUIRED_USE flag constraints are unsatisfied:
llvm? ( exactly-one-of ( llvm_slot_15 llvm_slot_16 llvm_slot_17 llvm_slot_18 ) )
The above constraints are a subset of the following complete expression:
d3d9? ( any-of ( video_cards_freedreno video_cards_intel video_cards_nouveau video_cards_panfrost video_cards_r300 video_cards_r600 video_cards_radeonsi video_cards_vmware video_cards_zink ) ) llvm? ( exactly-one-of ( llvm_slot_15 llvm_slot_16 llvm_slot_17 llvm_slot_18 ) ) vulkan-overlay? ( vulkan ) video_cards_lavapipe? ( llvm vulkan ) video_cards_radeon? ( x86? ( llvm ) amd64? ( llvm ) ) video_cards_r300? ( x86? ( llvm ) amd64? ( llvm ) ) video_cards_zink? ( vulkan opengl ) video_cards_nvk? ( vulkan video_cards_nouveau ) vdpau? ( X ) xa? ( X )
(dependency required by "x11-libs/gtk+-3.24.41::gentoo" [installed])
(dependency required by "app-crypt/gcr-3.41.1-r2::gentoo[gtk]" [installed])
(dependency required by "gnome-base/gnome-keyring-42.1-r2::gentoo" [installed])
(dependency required by "sys-auth/pambase-20240128::gentoo[gnome-keyring]" [installed])
(dependency required by "sys-libs/pam-1.6.1::gentoo" [installed])
(dependency required by "sys-libs/libcap-2.70::gentoo[pam]" [installed])
(dependency required by "sys-auth/elogind-246.10-r4::gentoo" [installed])
(dependency required by "sys-auth/polkit-124-r1::gentoo[-systemd]" [installed]) |
What I understand is that the combination of my use flags has to point to exactly one llvm slot. And currently it is not. Is that a correct thought?
I scanned through my use flags and found one:
>=sys-devel/llvm-16.0.5 abi_x86_32
I removed that, but that did not make for a solution.
edit4: I think I ruled out that one. Since I am having >llvm16 on my system and need the abi_x86_32 for steam, I keep that line in
Can you point me in the good direction?
Thanks
edit 3: equery list llvm:
* Searching for llvm ...
[IP-] [ ] sys-devel/llvm-17.0.6:17/17
edit2: does LLVM_SLOT="-15 -16 -17 (-18 )" mean: negative use flag 15,16,17,18. So actually exclude them?
Last edited by Tout on Tue Jul 23, 2024 6:17 pm; edited 2 times in total |
|
| Back to top |
|
 |
dmoulding
n00b
Joined: 03 Jun 2014
Posts: 28
|
| Posted: Tue Jul 23, 2024 5:46 pm Post subject: |
|
|
I just ran into the same thing. I could be wrong, but this looks like a bug in the portage tree to me. If so, I'm guessing it will quickly get sorted out.
I note that the mesa I've currently got installed shows that I've got llvm_slot_17 set. I've never had to explicitly specify an LLVM_SLOT before, so I think that must mean something had been setting it with a default (maybe something in the profile?). And I'm guessing some recent update has unset that default, probably by mistake, leading to this error.
| Code: | $ equery uses mesa
[ Legend : U - final flag setting for installation]
[ : I - package is installed with flag ]
[ Colors : set, unset ]
* Found these USE flags for media-libs/mesa-24.1.3:
U I
+ + X : Add support for X11
+ + abi_x86_32 : 32-bit (x86) libraries
+ + cpu_flags_x86_sse2 : Use the SSE2 instruction set
- - d3d9 : Enable Direct 3D9 API through Nine state tracker.
Can be used together with patched wine.
- - debug : Enable extra debug codepaths, like asserts and
extra output. If you want to get meaningful
backtraces see https://wiki.gentoo.org/wiki/Project
:Quality_Assurance/Backtraces
+ + llvm : Enable LLVM backend for Gallium3D.
- - llvm_slot_15 : Use LLVM 15.
- - llvm_slot_16 : Use LLVM 16.
- + llvm_slot_17 : Use LLVM 17.
- - lm-sensors : Enable Gallium HUD lm-sensors support.
- - opencl : Enable the Rusticl Gallium OpenCL state tracker.
- - osmesa : Build the Mesa library for off-screen rendering.
+ + proprietary-codecs : Enable codecs for patent-encumbered audio and video
formats.
- - test : Enable dependencies and/or preparations necessary
to run tests (usually controlled by FEATURES=test
but can be toggled independently)
- - unwind : Add support for call stack unwinding and function
name resolution
+ + vaapi : Enable Video Acceleration API for hardware decoding
- - valgrind : Enable annotations for accuracy. May slow down
runtime slightly. Safe to use even if not currently
using dev-debug/valgrind
+ + vdpau : Enable the VDPAU acceleration interface for the
Gallium3D Video Layer.
- - video_cards_d3d12 : VIDEO_CARDS seeting to build driver for Microsoft
WSL video cards
- - video_cards_intel : VIDEO_CARDS setting to build driver for Intel video
cards
- - video_cards_lavapipe : VIDEO_CARDS setting to build Vulkan software
rasterizer using LLVMpipe
+ + video_cards_nouveau : VIDEO_CARDS setting to build reverse-engineered
driver for nvidia cards
- - video_cards_r300 : VIDEO_CARDS setting to build only r300, r400 and
r500 based chips code for radeon
- - video_cards_r600 : VIDEO_CARDS setting to build only r600, r700,
Evergreen and Northern Islands based chips code for
radeon
- - video_cards_radeon : VIDEO_CARDS setting to build driver for ATI radeon
video cards
- - video_cards_radeonsi : VIDEO_CARDS setting to build only Southern Islands
based chips code for radeon
- - video_cards_virgl : VIDEO_CARDS setting to build driver for virgil
(virtual 3D GPU)
- - video_cards_vmware : VIDEO_CARDS setting to build driver for vmware
video cards
- - video_cards_zink : VIDEO_CARDS setting to build Zink
OpenGL-over-Vulkan Gallium driver
- - vulkan : Add support for 3D graphics and computing via the
Vulkan cross-platform API
- - vulkan-overlay : Build vulkan-overlay-layer which displays Frames
Per Second and other statistics
+ + wayland : Enable support for dev-libs/wayland
+ + xa : Enable the XA (X Acceleration) API for Gallium3D.
+ + zstd : Enable support for ZSTD compression
|
|
|
| Back to top |
|
|
Tout
n00b
Joined: 18 Jul 2020
Posts: 41
|
| Posted: Tue Jul 23, 2024 5:50 pm Post subject: |
|
|
Aah! Thank you. Yes maybe it is good to wait for a bit.
I also did not manually add a llvm_slot either as far as I can remember.
Edit: what I do notice is that when you see this in color it seems that
- - llvm_slot_15 : Use LLVM 15.
- - llvm_slot_16 : Use LLVM 16.
- + llvm_slot_17 : Use LLVM 17.
are blue, so unset as per the legend of equery uses mesa
[ Legend : U - final flag setting for installation]
[ : I - package is installed with flag ]
[ Colors : set, unset ] |
|
| Back to top |
|
|
bstaletic
Guru
Joined: 05 Apr 2014
Posts: 313
|
| Posted: Tue Jul 23, 2024 6:01 pm Post subject: |
|
|
I think we have just picked a terrible time to sync the portage tree.
LLVM_SLOT 18 is being stabilized. |
|
| Back to top |
|
|
Tout
n00b
Joined: 18 Jul 2020
Posts: 41
|
| Posted: Tue Jul 23, 2024 6:04 pm Post subject: |
|
|
| bstaletic wrote: | I think we have just picked a terrible time to sync the portage tree.
LLVM_SLOT 18 is being stabilized. |
Ah, that could explain a lot  Thanks for sharing.
A terrible time to sync, makes a good time to learn for me  As I learned a few things already looking at this  |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 131
|
| Posted: Wed Jul 24, 2024 4:17 am Post subject: |
|
|
There is an eclass that handles choosing LLVM_SLOT for packages. It automatically defines IUSE for individual ebuilds, with *default enabling* of the highest LLVM version which is stabilized..
... as defined by the eclass variable _LLVM_NEWEST_STABLE.
In combination with this, if llvm 18 isn't stable, the portage tree considers it an invalid lint to have the *stable* option to select it -- so there's a use.stable.mask entry basically saying "we're not quite ready yet"
When the eclass bumps to llvm 18, you end up with IUSE="llvm_slot_17 +llvm_slot_18". If one also forgets to clean up the old mask, that means that simultaneously, 17 is no longer default-enabled, but 18 is masked and force disabled.
There was a 4 hour period in which that happened. I'm sure you've all synced again by now though. |
|
| Back to top |
|
|
Tout
n00b
Joined: 18 Jul 2020
Posts: 41
|
| Posted: Wed Jul 24, 2024 4:28 am Post subject: |
|
|
| Thank you for explaining and clarifying! |
|
| Back to top |
|
|
sMueggli
Guru
Joined: 03 Sep 2022
Posts: 431
|
| Posted: Wed Jul 24, 2024 7:58 am Post subject: |
|
|
| eschwartz wrote: | | In combination with this, if llvm 18 isn't stable, the portage tree considers it an invalid lint to have the *stable* option to select it -- so there's a use.stable.mask entry basically saying "we're not quite ready yet" |
Just out of curiosity: If a developer is stabilising llvm slot 18 prior to update the eclass, does that produce an error? |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 131
|
| Posted: Wed Jul 24, 2024 4:00 pm Post subject: |
|
|
| sMueggli wrote: | | eschwartz wrote: | | In combination with this, if llvm 18 isn't stable, the portage tree considers it an invalid lint to have the *stable* option to select it -- so there's a use.stable.mask entry basically saying "we're not quite ready yet" |
Just out of curiosity: If a developer is stabilising llvm slot 18 prior to update the eclass, does that produce an error? |
There are four different components here:
- LLVM itself needs to be packaged, so that people on ~arch can install llvm:18 and maybe clang:18
- eclasses which offer USE flags to select between different llvm slots as a dependency, need to be updated to offer a USE flag on ~arch for that slot
- LLVM itself needs to be stabilized, so that people on arch (not ~arch) can install llvm:18 and maybe clang:18
- now that llvm:18 has become stabilized and available for arch (not ~arch), the eclass should start offering the USE flag for arch (not ~arch)
So the issue is that it makes perfect sense to use.stable.mask the USE=llvm_slot_18 option at step 2.
And at step 3, there is no error -- you can install llvm 18 just fine, you just cannot yet have other packages depend on it. But maybe you have installed multiple slots of llvm, and at the moment the only thing you need llvm 18 for is as a dependency of clang 18 -- since clang doesn't use the LLVM_SLOT use_expand as it itself is slotted in tandem with llvm, it's fine to simply stabilize both packages at the same time without touching the USE flag used elsewhere.
Step 4 requires, basically, doing two things in one commit, because the eclass has to be consistent with use.stable.mask. |
|
| Back to top |
|
|
sMueggli
Guru
Joined: 03 Sep 2022
Posts: 431
|
| Posted: Wed Jul 24, 2024 4:11 pm Post subject: |
|
|
| @eschwartz thanks a lot for the explanation and the time to explain it. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
