Created attachment 369668 [details] build.log This failure only happens on a fresh install of x11-libs/libva-1.1.1-r1. If libva-1.1.1 or any of the older versions in portage are already installed, the build of libva-1.1.1-r1 succeeds. Steps to reproduce: 1. emerge -C libva 2. emerge -1 =libva-1.1.1-r1
For some additional info, libva-1.1.1 does build successfully, so it would appear to be related to the multilib changes in 1.1.1-r1. BUT 1.2.1-r1 which also has the new multilib stuff also builds successfully.
After emerging of =libva-1.0.15 manually, it sucessfuly updates to 1.1.1-r1
i have the problem too (and yes, it is also a fresh install) The workaround of emerging =libva-1.0.15 first doesn't work here. i got a loop pb it seems : sudo emerge -qvta --keep-going =libva-1.0.15 -1 [ebuild N ] x11-libs/libva-1.0.15 USE="opengl vdpau" VIDEO_CARDS="intel -dummy -fglrx -nvidia" [ebuild N ] x11-libs/libva-vdpau-driver-0.7.4-r1 USE="opengl -debug" ABI_X86="(64) -32 (-x32)" [ebuild N ] x11-libs/libva-intel-driver-1.0.20-r1 USE="X drm wayland" ABI_X86="(64) -32 (-x32)" [ebuild N ] x11-libs/libva-1.1.1-r1 USE="X drm opengl vdpau wayland -egl" ABI_X86="(64) -32 (-x32)" VIDEO_CARDS="intel -dummy -fglrx -nvidia" !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: x11-libs/libva:0 (x11-libs/libva-1.1.1-r1::gentoo, ebuild scheduled for merge) pulled in by >=x11-libs/libva-1.1.0[X,opengl?,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (x11-libs/libva-vdpau-driver-0.7.4-r1::gentoo, ebuild scheduled for merge) (and 1 more with the same problem) (x11-libs/libva-1.0.15::gentoo, ebuild scheduled for merge) pulled in by =libva-1.0.15
I got the problem on another computer which is far from being freshly installed. Exactly the same problem / error message. The error message is : ---------------------------------------------------------------- x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I/var/tmp/portage/x11-libs/libva-1.1.1-r1/work/libva-1.1.1/test/v4l_h264/encode -I../../.. -march=native -pipe -O2 -c -o avcenc.o /var/tmp/portage/x11-libs/libva-1.1.1-r1/work/libva-1.1.1/test/v4l_h264/encode/avcenc.cpp /var/tmp/portage/x11-libs/libva-1.1.1-r1/work/libva-1.1.1/test/v4l_h264/encode/avcenc.cpp:35:23: fatal error: va/va_x11.h: No such file or directory #include <va/va_x11.h> ---------------------------------------------------------------- which makes me think that the error is due to tests being compiled and expecting libva to be somehow installed somewhere. My first idea was to disable tests, but there's not the usual USE=test stuff there. The workaround "emerge -1 =libva-1.0.15" doesn't work here neither (unresolved loop). ---------------------------------------------------------------- [ebuild N ] x11-libs/libva-1.0.15 USE="opengl vdpau" VIDEO_CARDS="-dummy -fglrx -intel -nvidia" [ebuild N ] x11-libs/libva-vdpau-driver-0.7.4-r1 USE="opengl -debug" ABI_X86="(64) -32 (-x32)" [ebuild N ] x11-libs/libva-1.1.1-r1 USE="X drm opengl vdpau wayland -egl" ABI_X86="(64) -32 (-x32)" VIDEO_CARDS="-dummy -fglrx -intel -nvidia" ---------------------------------------------------------------- I tried this just in case, but got the same problem: USE="-wayland -vdpau -opengl" emerge -1 libva The one that worked, though, is this : USE="-vdpau" emerge -1 =libva-1.0.15 which is a mix between the reported working workaround, and USE=-vdpau to break my loop problem.
simply using --nodeps when downgrading to libva-1.0.15 solves the circular dependencies problem, the build was still successful in my case. I could then updrade libva and the respective driver (intel in my case) without problems.
I get some other failures too, when trying 1.1.1-r1; might be time to stabilize something newer, then throw old incompatible versions out of the Portage tree.
this seems fixed with libva 1.3.1+
