[SOLVED] libdrm-2.4.52 exports wrong version?

[dachschaden]

But I best begin from the beginning.

I noticed that watching a video on YouTube in HD takes one processor core to render. Wondering what was going wrong here, I googled and tested the program vainfo:

Code: Select all

libva: VA-API version 0.32.0
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
libva error: /usr/lib64/va/drivers/i965_drv_video.so init failed
libva: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

Interdasting ... could it be that my chip is not supported?

Code: Select all

$ /usr/sbin/lspci -k | grep 'i915' -n2
5-00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
6-	Subsystem: ASUSTeK Computer Inc. Device 11cd
7:	Kernel driver in use: i915
8-00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
9-	Subsystem: Intel Corporation Device 2010

OK, I am running an Haswell chip ... these should be supported, at least according to this site: https://01.org/linuxgraphics/community/vaapi.

Code: Select all

$ emerge --ask libva-intel-driver
This action requires superuser access...
Would you like to add --pretend to options? [Yes/No] Yes

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] x11-libs/libva-intel-driver-1.0.17

Hm, the lib was installed, but ... it's a bit outdated? 1.3.0 is up-to-date ... eh, whatever. You are a coder, you can debug your system.
And this is what I did:

Code: Select all

if (IS_G4X(i965->intel.device_id))
        i965->codec_info = &g4x_hw_codec_info;
    else if (IS_IRONLAKE(i965->intel.device_id))
        i965->codec_info = &ironlake_hw_codec_info;
    else if (IS_GEN6(i965->intel.device_id))
        i965->codec_info = &gen6_hw_codec_info;
    else if (IS_GEN7(i965->intel.device_id))
        i965->codec_info = &gen7_hw_codec_info;
    else
        return VA_STATUS_ERROR_UNKNOWN;

This is where it fails. There is no Haswell support - so I checked 1.3.0, and this seems to have Haswell support:

Code: Select all

if (IS_HASWELL(i965->intel.device_id))

Well, why wouldn't I just install it manually?

Code: Select all

# ebuild libva-intel-driver-1.3.0.ebuild configure
[...]
checking pkg-config is at least version 0.9.0... yes
checking for DRM... yes
checking for GEN4ASM... no
configure: error: Package requirements (libdrm >= 2.4.45) were not met:

No package 'libdrm' found

Huh?

Code: Select all

* ERROR: x11-libs/libva-intel-driver-1.3.0::gentoo failed (configure phase):
 *   econf failed
 * 
 * Call stack:
 *          ebuild.sh, line   93:  Called src_configure

Code: Select all

checking for intel-gen4asm... no
checking for LIBVA_DEPS... no
configure: error: Package requirements (libva >= 0.35) were not met:

Requested 'libva >= 0.35' but version of libva is 0.32.0

Errr ... what the hell?

Code: Select all

# emerge --ask libdrm

 * IMPORTANT: 6 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.


These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] x11-libs/libdrm-2.4.52 

I must have missed that class in school in which they taught us that 2.4.45 is bigger than 2.4.52 ... or maybe it's just a leftover? Whatever, remerge it:

Code: Select all

[...]
libdrm 2.4.52 will be compiled with:

  libkms         no
  Intel API      yes
  vmwgfx API     no
  Radeon API     no
  Nouveau API    no
  OMAP API       no
  EXYNOS API     no
  Freedreno API  no
[...]
libtool: install: /usr/bin/install -c .libs/libdrm.so.2.4.0 /var/tmp/portage/x11-libs/libdrm-2.4.52/image//usr/lib64/libdrm.so.2.4.0
libtool: install: (cd /var/tmp/portage/x11-libs/libdrm-2.4.52/image//usr/lib64 && { ln -s -f libdrm.so.2.4.0 libdrm.so.2 || { rm -f libdrm.so.2 && ln -s libdrm.so.2.4.0 libdrm.so.2; };[libtool: install: (cd /var/tmp/portage/x11-libs/libdrm-2.4.52/image//usr/lib64 && { ln -s -f libdrm.so.2.4.0 libdrm.so || { rm -f libdrm.so && ln -s libdrm.so.2.4.0 libdrm.so; }; })[
[...]
>>> Installing (1 of 1) x11-libs/libdrm-2.4.52

>>> Recording x11-libs/libdrm in "world" favorites file...
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

 * GNU info directory index is up-to-date.

Soooo, that should have done the trick, right?

Code: Select all

#ebuild libva-intel-driver-1.3.0.ebuild configure
[...]
configure: error: Package requirements (libdrm >= 2.4.45) were not met:

No package 'libdrm' found
[...]

So, is it just me, or did I find a bug?

[VoidMage]

Let's start with a trivial question: 'pkg-config libdrm --modversion' ?

Oh, and on a general note, putting too much directly into your world is not a good idea.

[dachschaden]

Code: Select all

$ pkg-config libdrm --modversion
2.4.52

I just have what is necessary. Everything that I do not need is excluded - I am against bloat in all forms.

[VoidMage]

So, the next question would be 'pkg-config --atleast-version=2.4.45 libdrm; echo $'.
Your config.log might be of interst too.

I just have what is necessary. Everything that I do not need is excluded - I am against bloat in all forms.

You forgot to add "right now" at the end of the first sentence - and that's my point. While in case of libdrm, it's unlikely to change, I was talking about the general case.

[dachschaden]

I don't know what you are expecting ... but:

Code: Select all

<prompt> pkg-config --atleast-version=2.4.45 libdrm; echo $
$
<prompt>

BTW:

Code: Select all

$ pkg-config --atleast-version=2.4.45 libdrm; echo $?
0

I guess that's rather what you meant, right?

Here you go: http://pastebin.com/uvqnhvRp

I am just pulling stuff directly that I want to debug. If my debugging works and the error is fixed, I file a bug and update as soon as there is a new version available.
Otherwise I strictly keep in the safe area of portage - because I am still a bloddy newbie with gentoo.

[VoidMage]

I'm dangerously close to saying "FTS".

Simple question: How many packages does 'emerge -1pv =x11-libs/libva-intel-driver-1.3.0' update ?

[dachschaden]

What does FTS mean? Sorry for asking, but with gentoo in addition it just occurs on google while mentioning "zeitgeist".

Code: Select all

$ emerge -1pv =x11-libs/libva-intel-driver-1.3.0

These are the packages that would be merged, in order:

Calculating dependencies... done!

The following keyword changes are necessary to proceed:
 (see "package.accept_keywords" in the portage(5) man page for more details)
# required by x11-libs/libva-intel-driver-1.3.0
# required by =x11-libs/libva-intel-driver-1.3.0 (argument)
=x11-libs/libdrm-2.4.54 ~amd64
# required by x11-libs/libva-intel-driver-1.3.0
# required by =x11-libs/libva-intel-driver-1.3.0 (argument)
=x11-libs/libva-1.3.1 ~amd64
# required by =x11-libs/libva-intel-driver-1.3.0 (argument)
=x11-libs/libva-intel-driver-1.3.0 ~amd64

emerge: there are no ebuilds to satisfy ">=x11-libs/libXfixes-5.0.1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]".
(dependency required by "x11-libs/libva-1.3.1" [ebuild])
(dependency required by "x11-libs/libva-intel-driver-1.3.0" [ebuild])
(dependency required by "=x11-libs/libva-intel-driver-1.3.0" [argument])

 * IMPORTANT: 6 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.

No, I haven't done anything rush yet (like adding keywords for portage).
No, I won't do so unless you explicitly tell me so.

EDIT: If that means anything to you: I am not using Gnome, but Xfce4.

[VoidMage]

What does FTS mean? Sorry for asking, but with gentoo in addition it just occurs on google while mentioning "zeitgeist".

Code: Select all

$ emerge -1pv =x11-libs/libva-intel-driver-1.3.0

These are the packages that would be merged, in order:

Calculating dependencies... done!

The following keyword changes are necessary to proceed:
 (see "package.accept_keywords" in the portage(5) man page for more details)
# required by x11-libs/libva-intel-driver-1.3.0
# required by =x11-libs/libva-intel-driver-1.3.0 (argument)
=x11-libs/libdrm-2.4.54 ~amd64
# required by x11-libs/libva-intel-driver-1.3.0
# required by =x11-libs/libva-intel-driver-1.3.0 (argument)
=x11-libs/libva-1.3.1 ~amd64
# required by =x11-libs/libva-intel-driver-1.3.0 (argument)
=x11-libs/libva-intel-driver-1.3.0 ~amd64

emerge: there are no ebuilds to satisfy ">=x11-libs/libXfixes-5.0.1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]".
(dependency required by "x11-libs/libva-1.3.1" [ebuild])
(dependency required by "x11-libs/libva-intel-driver-1.3.0" [ebuild])
(dependency required by "=x11-libs/libva-intel-driver-1.3.0" [argument])

 * IMPORTANT: 6 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.

google "slang FTS".
In this this context, it's about someone trying to parkour while barely being able to crawl.
While it often happens, that devs fail to bump requirements for the packages in their ebuilds and simply stabilize whole sets instead, if they do, they tend to have good reasons for it.
Here, for example, x11-libs/libva-1.3.1 is being requested by x11-libs/libva-intel-driver-1.3.0 ebuild.

Though it seems there's a bit of multilib noise at the end...
I wonder.. Did you for some reason set ABI_X86 globally ?
If not, what's the output of 'emerge -1pv =x11-libs/libva-intel-driver-1.3.0 libXfixes' ?

[dachschaden]

In this this context, it's about someone trying to parkour while barely being able to crawl.

So I did something wrong? Or is this just another example of my "excellent english skills"?

While it often happens, that devs fail to bump requirements for the packages in their ebuilds and simply stabilize whole sets instead, if they do, they tend to have good reasons for it.
Here, for example, x11-libs/libva-1.3.1 is being requested by x11-libs/libva-intel-driver-1.3.0 ebuild.

Though it seems there's a bit of multilib noise at the end...
I wonder.. Did you for some reason set ABI_X86 globally ?

Indeed:

Code: Select all

ABI_X86="64 32"

I remember I did this once because I had problems with glibc and zsnes (32 Bit application) back then.

If not, what's the output of 'emerge -1pv =x11-libs/libva-intel-driver-1.3.0 libXfixes' ?

I'll give you the output nonetheless:

Code: Select all

$ emerge -1pv =x11-libs/libva-intel-driver-1.3.0 libXfixes

These are the packages that would be merged, in order:

Calculating dependencies... done!

The following keyword changes are necessary to proceed:
 (see "package.accept_keywords" in the portage(5) man page for more details)
# required by x11-libs/libva-intel-driver-1.3.0
# required by =x11-libs/libva-intel-driver-1.3.0 (argument)
=x11-libs/libva-1.3.1 ~amd64
# required by x11-libs/libva-intel-driver-1.3.0
# required by =x11-libs/libva-intel-driver-1.3.0 (argument)
=x11-libs/libdrm-2.4.54 ~amd64
# required by =x11-libs/libva-intel-driver-1.3.0 (argument)
=x11-libs/libva-intel-driver-1.3.0 ~amd64

emerge: there are no ebuilds to satisfy ">=dev-libs/libpthread-stubs-0.3-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]".
(dependency required by "x11-libs/libdrm-2.4.54" [ebuild])
(dependency required by "x11-libs/libva-intel-driver-1.3.0" [ebuild])
(dependency required by "=x11-libs/libva-intel-driver-1.3.0" [argument])

 * IMPORTANT: 6 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.

[VoidMage]

While it often happens, that devs fail to bump requirements for the packages in their ebuilds and simply stabilize whole sets instead, if they do, they tend to have good reasons for it.
Here, for example, x11-libs/libva-1.3.1 is being requested by x11-libs/libva-intel-driver-1.3.0 ebuild.

Though it seems there's a bit of multilib noise at the end...
I wonder.. Did you for some reason set ABI_X86 globally ?

Indeed:

Code: Select all

ABI_X86="64 32"

I remember I did this once because I had problems with glibc and zsnes (32 Bit application) back then.

A bit earlier:

I just have what is necessary. Everything that I do not need is excluded - I am against bloat in all forms.

:facepalm: FFS...
(and I know what zsnes is - an emulator that's trying to be next Duke Nukem Forever)

You know, I could drive you step by step through the process of getting the list of all packages, that you'll going to need to add package.use.mask, I just don't feel like it, if there's obviously no need.
Setting that var globally seems a cute shortcut, but is actually more of a pain in the butt in the long run.

But if you want to have it your own way, just keep adding those packages emerge asks for, till the run completes successfully. It's quite obvious, which package should be added now, ne ?

[dachschaden]

I use 32 bit applications for other stuff as well, not only zsnes - that one just caused the problems.

So you're suggesting removing the flag and try it again or what?

But if you want to have it your own way, just keep adding those packages emerge asks for, till the run completes successfully. It's quite obvious, which package should be added now, ne ?

True, but ... based on your reaction I somehow screwed it up, huh?
I wanna be open here, I am still a newbie with Gentoo and Portage, and I don't want to break anything. I can execute commands and install stuff and debug it, but the deeper magic is still ... well, magic Your reaction suggests that you preferred an other solution - if you at least could tell me - or point me to the direction - where I am wrong that would be really appriciated.

[VoidMage]

I use 32bit stuff pretty much for wine only - for how little I use wine.

Not as much screwed up, as directly contradicted yourself. It's almost the same as if you set all your useflags in make.conf. Not that the big hammer won't work. :shrug:

Using 'ebuild <foo> (configure|compile|etc.) ' might be a useful debugging tool, but using it casually might create more trouble than it solves.

You already know, the algorithm - just keep adding the packages.
Though IMHO the list you'll end up with will be far longer than what you actually need.

Also, a correction: I've meant package.use.stable.mask above.

[dachschaden]

I use 32bit stuff pretty much for wine only - for how little I use wine.

Not as much screwed up, as directly contradicted yourself. It's almost the same as if you set all your useflags in make.conf. Not that the big hammer won't work.

Maybe you got me wrong - when I say "bloat", I mean "stuff that I don't use, but get's shipped nonetheless". Since I use that stuff, it's not really bloat.
Example: I don't use my nVidia card, so I don't need the nouveau driver. Thus, it's not compiled. I won't need the radeon driver as well -> I don't install it. Eh, whatever.

Using 'ebuild <foo> (configure|compile|etc.) ' might be a useful debugging tool, but using it casually might create more trouble than it solves.

You got other suggestions?

You already know, the algorithm - just keep adding the packages.
Though IMHO the list you'll end up with will be far longer than what you actually need.

Also, a correction: I've meant package.use.stable.mask above.

OK, I will do that.
BUT: can you tell me what the problem is here? Just to get this straight: I got the error that the libdrm version does not fit although it should fit, and right now I have no idea HOW this is supposed to fix my problem - although I am sure that it will solve it, I don't want a quick solution without understanding what is going on. As far as I understand adding the keyword disables the protection for packages in testing stage - is 1.3.0 for x86 stll in testing stage or what?

I wanna learn and someday contribute to others. How am I supposed to do that if I don't know what is going on on my own machine?

BTW, that help a bit, but I still cannot install it:

Code: Select all

emerge --ask =x11-libs/libva-intel-driver-1.3.0
This action requires superuser access...
Would you like to add --pretend to options? [Yes/No] Yes 

These are the packages that would be merged, in order:

Calculating dependencies... done!

emerge: there are no ebuilds to satisfy ">=dev-libs/libpthread-stubs-0.3-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?]".
(dependency required by "x11-libs/libdrm-2.4.54" [ebuild])
(dependency required by "x11-libs/libva-intel-driver-1.3.0" [ebuild])
(dependency required by "=x11-libs/libva-intel-driver-1.3.0" [argument])

Getting cocky, I just added =dev-libs/libpthread-stubs-0.3-r1 ~amd64 to package.accept_keywords. But then it requires =x11-libs/libpciaccess-0.13.1-r1 ~amd64. I guess if I added this, portage would want me to add =x11-libs/libXext-1.3.2 ~amd64 as well ... are you sure I should just continue here?

Sorry for asking, I just want to be sure.

[VoidMage]

That what I've meant by "keep adding" - keep adding, eventually, it should complete the run (due to package.use.stable.mask you'll likely add quite a bit more than you actually need, but meh).

[motaito]

@VoidMage
Sorry for bumping in like that but out of curiosity and for better understanding.

That what I've meant by "keep adding" - keep adding, eventually, it should complete the run (due to package.use.stable.mask you'll likely add quite a bit more than you actually need, but meh).

Once you added all that you need and successfully installed the desired package. Could you then not just remove them again and do a

Code: Select all

emerge -avuND @world

to get rid of the unneeded packages again?

[dachschaden]

What about updates? I don't think portage will be smart enough that once in a while I want to update my system, will it?

[motaito]

I remember having read something like that but I could not find it again. If I remember correctly sometimes packages need to be present for a build script to run properly but can be removed after install. I guess it would depend on what needs updating. You might need to re-add some keywords or re-mask for updates. However, I am sure there are more qualified people on the forum to answer that. It just got me wondering if that would work so you don't have any unwanted bloat. If so you could simply comment out the parts you don't need. Portage is certainly smart enough to tell you again if you need it present for updates.

[VoidMage]

What about updates? I don't think portage will be smart enough that once in a while I want to update my system, will it?

Sorry, I don't get the context of this question.

[mmogilvi]

The combination ("mostly stable system", "amd_x86_32 widely enabled", and "emul-linux-x86-* packages installed") is not really supported, and is difficult to troubleshoot and get working. Blindly following emerge's recommendations tends to be worse than thinking about your preferred strategy and dependencies more globally first. This is due to how the dependencies and build scripts for the emul-linux packages are setup. Sometimes it works if the system package.use.stable.mask file is up to date to mask amd_x86_32 where appropriate, but sometimes it doesn't. My recommendation is to change at least one of the three conditions:

1. [short term solution] Simplest: Disable amd_x86_32 globally, and only enable it narrowly in specific necessary packages that are not part of emul-linux packages (usually "leaf" packages like wine, steam, etc).

2. [long term solution] Uninstall emul-linux, and use native packages instead. This is not yet officially stabilized, requires a fair number of configuration changes, and not all packages can currently be installed at all under this option (they unconditionally (often wrongly) depend on emul-linux). But I think it is probably more future-proof than above. I describe how to do this in detail in http://forums.gentoo.org/viewtopic-p-75 ... 48#7509542 .

3. Globally enable ACCEPT_KEYWORDS="~amd64".

See also other solutions outlined in http://forums.gentoo.org/viewtopic-p-75 ... ml#7570012 as well as near the top of the "uninstall emul-linux" link about.

[dachschaden]

OK, that's it. I am quiting this bullshit. I have added all these keywords:

Code: Select all

x11-libs/libva-intel-driver-1.3.0 ~amd64
=x11-libs/libdrm-2.4.54 ~amd64
=x11-libs/libva-1.3.1 ~amd64
=dev-libs/libpthread-stubs-0.3-r1 ~amd64
=x11-libs/libXext-1.3.2 ~amd64
=x11-libs/libXfixes-5.0.1 ~amd64
=x11-libs/libX11-1.6.2 ~amd64
=x11-libs/libvdpau-0.7 ~amd64
=x11-proto/xextproto-7.2.1-r1 ~amd64
=x11-proto/fixesproto-5.0-r1 ~amd64
=x11-proto/kbproto-1.0.6-r1 ~amd64
=x11-proto/xf86bigfontproto-1.2.0-r1 ~amd64
=x11-proto/xproto-7.0.26 ~amd64
=x11-libs/libpciaccess-0.13.1-r1 ~amd64
=x11-libs/libva-vdpau-driver-0.7.4-r1 ~amd64
=x11-proto/inputproto-2.3.1 ~amd64
=x11-libs/libxcb-1.9.3-r1 ~amd64
=x11-libs/libXdmcp-1.1.1-r1 ~amd64
=virtual/opengl-7.0-r1 ~amd64
=x11-libs/libXdamage-1.1.4-r1 ~amd64
=x11-libs/libxshmfence-1.1 ~amd64
=x11-libs/libXau-1.0.7-r1 ~amd64
=media-libs/mesa-10.2.2 ~amd64
=x11-proto/xcb-proto-1.9-r1 ~amd64
=x11-libs/libXvMC-1.0.8 ~amd64
=x11-libs/libXxf86vm-1.1.3 ~amd64
=x11-proto/xf86vidmodeproto-2.3.1-r1 ~amd64
=sys-devel/llvm-3.4.2 ~amd64
=dev-libs/expat-2.1.0-r4 ~amd64
=x11-libs/libXv-1.0.10 ~amd64
sys-libs/ncurses:5= ~amd64
=x11-proto/damageproto-1.2.1-r1 ~amd64
virtual/libffi:0= ~amd64
=dev-libs/libffi-3.1-r3 ~amd64
=x11-proto/videoproto-2.3.1-r1 ~amd64
=virtual/udev-208-r2 ~amd64
=virtual/libgudev-208:0/0 ~amd64
=sys-fs/udev-214 ~amd64
=dev-libs/glib-2.40.0-r1 ~amd64
=sys-libs/zlib-1.2.8-r1 ~amd64
=virtual/libiconv-0-r1 ~amd64

and not only does portage want me to add even more keywords, also the messages get more and more disturbing:

Code: Select all

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

sys-fs/udev:0

  (sys-fs/udev-214::gentoo, ebuild scheduled for merge) pulled in by
    >=sys-fs/udev-208-r1:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,gudev,introspection?,static-libs?] required by (virtual/libgudev-208::gentoo, ebuild scheduled for merge)

  (sys-fs/udev-212-r1::gentoo, installed) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

sys-libs/zlib:0

  (sys-libs/zlib-1.2.8-r1::gentoo, installed) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (sys-libs/zlib-1.2.8-r1::gentoo, ebuild scheduled for merge) pulled in by
    >=sys-libs/zlib-1.2.8-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?] required by (dev-libs/glib-2.40.0-r1::gentoo, ebuild scheduled for merge)


!!! Enabling --newuse and --update might solve this conflict.
!!! If not, it might help emerge to give a more specific suggestion.


emerge: there are no ebuilds to satisfy ">=virtual/libudev-208:0/1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,static-libs?]".
(dependency required by "virtual/udev-208-r2" [ebuild])
(dependency required by "media-libs/mesa-10.2.2[dri3,-gbm]" [ebuild])
(dependency required by "virtual/opengl-7.0-r1" [ebuild])
(dependency required by "x11-libs/libva-vdpau-driver-0.7.4-r1[opengl]" [ebuild])
(dependency required by "x11-libs/libva-1.3.1[-video_cards_nvidia,vdpau]" [ebuild])
(dependency required by "x11-libs/libva-intel-driver-1.3.0" [ebuild])
(dependency required by "=x11-libs/libva-intel-driver-1.3.0" [argument])

Yeah, right. As if I am going to continue here. I am not experienced enough to fix any problems that could arise from this, and I prefer a stable system over one that does support VDPAU - that is, if it booted up, it would support VDPAU.

Sorry, I don't get the context of this question.

Well ... imagine that I was insane enough to just blindly add all these testing packages and it would finally work.As far as I am concerned, there can be only one lib at the same time.OK, that is not entirely true, since I can have mutliple libXXX.so.X.Y.Z files, but even then I can have only one libXXX.so symlink. The question is: will portage apply updates on base of the just enabled packages or of the default (in my case, those without haswell support) packages? Will portage remove the packages that support haswell if, we say, we passed the 1.4 stable border?

1. [short term solution] Simplest: Disable amd_x86_32 globally, and only enable it narrowly in specific necessary packages that are not part of emul-linux packages (usually "leaf" packages like wine, steam, etc).

I thought about that, but that's not really short - at least I think so. :/ Often software tends to include a rattail of other dependencies, like glibc, proper X support, ncurses, alsa, you name it. I basically had the same problem as I have now.

2. [long term solution] Uninstall emul-linux, and use native packages instead. This is not yet officially stabilized, requires a fair number of configuration changes, and not all packages can currently be installed at all under this option (they unconditionally (often wrongly) depend on emul-linux). But I think it is probably more future-proof than above. I describe how to do this in detail in http://forums.gentoo.org/viewtopic-p-75 ... 48#7509542 .

Sounds better, I might give it a try.

3. Globally enable ACCEPT_KEYWORDS="~amd64".

Errrr ... what would be the result? Still having ABI_X86 set to "64 32" ... could it be that portage will then try to compile for both 64 and 32 bit, but will actually prefer the 64 bit packages?

See also other solutions outlined in http://forums.gentoo.org/viewtopic-p-75 ... ml#7570012 as well as near the top of the "uninstall emul-linux" link about.

Portage is certainly smart enough to tell you again if you need it present for updates.

I wouldn't really trust emerge's recommended 32-bit changes without considering them carefully. It often doesn't seem to handle the complex mess of 32-bit dependencies, "||" (OR) alternative dependencies, etc in an intelligent manner.

Why the sudden change of heart?

[VoidMage]

Till multilib herd deems abi_x86_32 stable enough to drop most of package.use.stable.mask, you'll have a quite large file undoing that mask - which (BTW) is most likely reason for those "there are no ebuilds to satisfy" messages with long abi_x86_32 string (I'm nearly certain it's the case for virtual/udev).

I've got about 200 entries for wine alone (and I don't even have all potential options set, like many of gstreamer plugins).

Other than that, it's just the average dangers of mixing - like, for example, if the gap between stable and unstable is getting big, maintainer may chose to drop some of the older unstable, forcing you to update your keywords file with a more recent version.

You most likely don't want to go to pure ~amd64.

[mmogilvi]

@dachschaden:

That list of ~amd64 packages seems MUCH longer than it should need to be. As described in http://forums.gentoo.org/viewtopic-p-75 ... 48#7509542 , I currently only need 4 unstable packages to install basic wine without emul-linux. Plus a few optional ~amd64 packages for each additional wine USE flag you want to enable (except for gstreamer, which needs more than a few).

A large list like that is a symptom of running into a major strategic-level dependency problem, such as trying to install emul-linux with amd_x86_32 enabled on a system that isn't keyworded ~amd64 globally. Or trying to mix-and-match packages with and without amd_x86_32 when those packages are part of an installed emul-linux. Neither of these is really supported at all.

"Enabling --newuse and --update might solve this conflict": I usually try "emerge -uDNva world" after making configuration file changes. Not sure how well it works without the "uDN" flags.

1. [short term solution] Simplest: Disable amd_x86_32 globally, and only enable it narrowly in specific necessary packages that are not part of emul-linux packages (usually "leaf" packages like wine, steam, etc).

I thought about that, but that's not really short - at least I think so. :/ Often software tends to include a rattail of other dependencies, like glibc, proper X support, ncurses, alsa, you name it. I basically had the same problem as I have now.

Most such dependencies should be satisfied by emul-linux. For anything not in emul-linux, you should be able to enable amd_x86_32 without problems. Or maybe steam or other 32-bit software requires a bunch more unstable packages? I don't have any experience with steam. Perhaps if I saw emerge's output from an attempt to update to such a configuration, I might see something to try?

3. Globally enable ACCEPT_KEYWORDS="~amd64".

Errrr ... what would be the result? Still having ABI_X86 set to "64 32" ... could it be that portage will then try to compile for both 64 and 32 bit, but will actually prefer the 64 bit packages?

This is how you switch to an unstable/"testing" system. I've never done this. Theoretically new weird bugs are more likely here, in both 32 bit and 64 bit subsystems, although these days I've heard it usually works well. I've also heard that going back to a stable system from an unstable one can be difficult.

~amd64 by itself doesn't directly effect 32 bit/64 bit compilation. That's what AMD_X86 is for. But indirectly, several packages still only have native 32-bit USE flag (amd_x86_32) available in unstable (~amd64) versions of the package.

----

You misread; this sentence was written by motaito, not me:

Portage is certainly smart enough to tell you again if you need it present for updates.

I would agree that portage will notice any problems, but its recommendations for resolving them often seem to ignore strategic concerns like the emul-linux cases I mentioned above. Hence my own recommendation to consider them carefully (neither trust them blindly, nor ignore them completely).

-----

I just re-read your initial messages, since I was initially just responding to the 32-bit stuff.

It looks like things were fine (except for vdpau) until you tried to update your video driver, and then dependencies kind of exploded?

I would like to see the information emerge includes when using the "-v" flag whenever you try something. Show what's happening with package use flags, show what old versions were previously installed, etc. (Also, it looks like some of the output was edited down a little too much; some more of the context might have been useful.) Some of the questions below have obvious answers if -v information is available.

Was amd_x86_32 unmasked? Is it unmasked now? I don't think you've keyworded ~amd64 globally, but I'm not sure.

When was the last time you did a successful world update (emerge -uDNva world)?

It is hard to be sure, but one possibility is that portage is keeping really old (before amd_x86_32 support) packages installed to avoid conflicts caused by amd_x86_32 dependencies interacting with emul-linux. If so, I would expect lots of these kinds of ballooning problems until the underlying strategic conflicts are understood and reconfigured.

Perhaps go back to the working (non-vdpau) config and do a world update. Then pick a supported strategy for emul-linux, amd_x86_32, and ~amd64, and do another world update. Then see if you still have issues with an obsolete video driver, or if the updates just took care of it...

-----

I just tested that if I start with my no-emul-linux config from my link above (with only the 4 required unstable packages plus the two optional pkgconfig's), add USE=video_cards_intel, and keyword ~amd64 in appropriate versions of only 3 more packages (x11-libs/libva, x11-libs/libva-intel-driver, and x11-libs/libva-vdpau-driver), then "emerge -pv libva-intel-driver" doesn't complain about anything else (for version 1.3.0). Of course I'm not inclined to actually install that, considering I don't have an intel card.

Perhaps trying to install it manually instead of keywording ~amd64 for that package (and tracking down the other two dependencies) is what diverted you down the wrong path? (Trying to install packages with ebuild instead of emerge just sounds really risky. Despite occasionally writing my own ebuild's, I've never tried it, and am not inclined to either.)

But maybe there is some more serious dependency issue when emul-linux is installed?

[mmogilvi]

Till multilib herd deems abi_x86_32 stable enough to drop most of package.use.stable.mask, you'll have a quite large file undoing that mask - which (BTW) is most likely reason for those "there are no ebuilds to satisfy" messages with long abi_x86_32 string (I'm nearly certain it's the case for virtual/udev).

I've got about 200 entries for wine alone (and I don't even have all potential options set, like many of gstreamer plugins).

Just to clarify, unmasking ~amd64 is different from unmasking abi_x86_32, and unmasking abi_x86_32 itself is a one-liner:

Code: Select all

-abi_x86_32

There is no reason to be more selective with unmasking abi_x86_32, although you might possibly want to be a little more selective about which packages actually have abi_x86_32 enabled. (All those packages mask it on stable only for the purpose of avoiding the emul-linux dependency limitation/hell described below. Without the emul-linux dependency issues, abi_x86_32 seems very stable as long as the package isn't still masked ~amd64.)

And if you can eliminate emul-linux (if no other packages require it), you can currently install a minimal wine with only four ~amd64 packages, or wine with all USE flags except gstreamer with only about 2 dozen ~amd64 packages. See http://forums.gentoo.org/viewtopic-p-75 ... 48#7509542 for details.

However, I can easily believe that the combination "need emul-linux", "want system as stable as possible", and "enable amd_x86_32 widely" will require a lot of ~amd64 unmasked/keyworded packages. This is because emul-linux forces all its native-32 package dependencies to have the same amd_x86_32 setting as emul-linux, and no attempt has been made to include a version of emul-linux that only depends on stable native packages when amd_x86_32 is enabled. Older, no-native-multilib versions of packages won't satisfy dependencies when emul-linux is installed with amd_x86_32, even if nothing actually uses the many rarer libraries.

[dachschaden]

OK, I just tossed all recommendations that you guys suggested away, because ... seriously? Just to enable VDPAU? Gotta be kidding me.
Also, with the latest update, they seemed to have fixed the initial problem. 1.3.0 is now supported for my box:

Code: Select all

# vainfo 
libva info: VA-API version 0.35.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_35
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.35 (libva 1.3.1)
vainfo: Driver version: Intel i965 driver - 1.3.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Simple            :	VAEntrypointEncSlice
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc
      VAProfileJPEGBaseline           :	VAEntrypointVLD

So I cannot actually complain.
Thanks for your posts though, I really appreciate the effort you guys made.