Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED] libdrm-2.4.52 exports wrong version?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Multimedia
View previous topic :: View next topic  
Author Message
dachschaden
n00b
n00b


Joined: 07 Jun 2014
Posts: 65
Location: Germany

PostPosted: Sat Jun 28, 2014 5:36 pm    Post subject: [SOLVED] libdrm-2.4.52 exports wrong version? Reply with quote

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:

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:

$ /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:

$ 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:

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:

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


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

Code:

# 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:

* 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:

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:

# 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:

[...]
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:

#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?


Last edited by dachschaden on Sun Jul 20, 2014 12:51 am; edited 1 time in total
Back to top
View user's profile Send private message
VoidMage
Watchman
Watchman


Joined: 14 Oct 2006
Posts: 6196

PostPosted: Sun Jun 29, 2014 12:22 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
dachschaden
n00b
n00b


Joined: 07 Jun 2014
Posts: 65
Location: Germany

PostPosted: Sun Jun 29, 2014 12:34 am    Post subject: Reply with quote

Code:

$ 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. ;)
Back to top
View user's profile Send private message
VoidMage
Watchman
Watchman


Joined: 14 Oct 2006
Posts: 6196

PostPosted: Sun Jun 29, 2014 5:18 am    Post subject: Reply with quote

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

dachschaden wrote:
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.
Back to top
View user's profile Send private message
dachschaden
n00b
n00b


Joined: 07 Jun 2014
Posts: 65
Location: Germany

PostPosted: Sun Jun 29, 2014 9:22 am    Post subject: Reply with quote

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

Code:

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


BTW:

Code:

$ 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.
Back to top
View user's profile Send private message
VoidMage
Watchman
Watchman


Joined: 14 Oct 2006
Posts: 6196

PostPosted: Sun Jun 29, 2014 3:23 pm    Post subject: Reply with quote

I'm dangerously close to saying "FTS".

Simple question: How many packages does 'emerge -1pv =x11-libs/libva-intel-driver-1.3.0' update ?
Back to top
View user's profile Send private message
dachschaden
n00b
n00b


Joined: 07 Jun 2014
Posts: 65
Location: Germany

PostPosted: Sun Jun 29, 2014 3:30 pm    Post subject: Reply with quote

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

Code:

$ 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.
Back to top
View user's profile Send private message
VoidMage
Watchman
Watchman


Joined: 14 Oct 2006
Posts: 6196

PostPosted: Sun Jun 29, 2014 4:36 pm    Post subject: Reply with quote

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

Code:

$ 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' ?
Back to top
View user's profile Send private message
dachschaden
n00b
n00b


Joined: 07 Jun 2014
Posts: 65
Location: Germany

PostPosted: Sun Jun 29, 2014 5:04 pm    Post subject: Reply with quote

VoidMage wrote:
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"?

VoidMage wrote:

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:

ABI_X86="64 32"


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

VoidMage wrote:
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:

$ 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.
Back to top
View user's profile Send private message
VoidMage
Watchman
Watchman


Joined: 14 Oct 2006
Posts: 6196

PostPosted: Sun Jun 29, 2014 6:08 pm    Post subject: Reply with quote

dachschaden wrote:
VoidMage wrote:

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:

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:
dachschaden wrote:
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 ?
Back to top
View user's profile Send private message
dachschaden
n00b
n00b


Joined: 07 Jun 2014
Posts: 65
Location: Germany

PostPosted: Sun Jun 29, 2014 6:24 pm    Post subject: Reply with quote

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?

Quote:
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.
Back to top
View user's profile Send private message
VoidMage
Watchman
Watchman


Joined: 14 Oct 2006
Posts: 6196

PostPosted: Sun Jun 29, 2014 9:48 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
dachschaden
n00b
n00b


Joined: 07 Jun 2014
Posts: 65
Location: Germany

PostPosted: Sun Jun 29, 2014 10:16 pm    Post subject: Reply with quote

VoidMage wrote:
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.

VoidMage wrote:

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?

VoidMage wrote:

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:

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.
Back to top
View user's profile Send private message
VoidMage
Watchman
Watchman


Joined: 14 Oct 2006
Posts: 6196

PostPosted: Mon Jun 30, 2014 1:17 am    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
motaito
Tux's lil' helper
Tux's lil' helper


Joined: 28 May 2014
Posts: 102

PostPosted: Mon Jun 30, 2014 12:25 pm    Post subject: Reply with quote

@VoidMage
Sorry for bumping in like that but out of curiosity and for better understanding.
Quote:
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:
emerge -avuND @world
to get rid of the unneeded packages again?
Back to top
View user's profile Send private message
dachschaden
n00b
n00b


Joined: 07 Jun 2014
Posts: 65
Location: Germany

PostPosted: Mon Jun 30, 2014 4:19 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
motaito
Tux's lil' helper
Tux's lil' helper


Joined: 28 May 2014
Posts: 102

PostPosted: Mon Jun 30, 2014 4:41 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
VoidMage
Watchman
Watchman


Joined: 14 Oct 2006
Posts: 6196

PostPosted: Mon Jun 30, 2014 9:10 pm    Post subject: Reply with quote

dachschaden wrote:
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.
Back to top
View user's profile Send private message
mmogilvi
n00b
n00b


Joined: 13 May 2011
Posts: 62

PostPosted: Tue Jul 01, 2014 3:52 am    Post subject: Reply with quote

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 https://forums.gentoo.org/viewtopic-p-7509542.html?sid=c5b44664c998872c1c014477e22c3048#7509542 .

3. Globally enable ACCEPT_KEYWORDS="~amd64".

See also other solutions outlined in https://forums.gentoo.org/viewtopic-p-7570012-highlight-.html#7570012 as well as near the top of the "uninstall emul-linux" link about.
Back to top
View user's profile Send private message
dachschaden
n00b
n00b


Joined: 07 Jun 2014
Posts: 65
Location: Germany

PostPosted: Thu Jul 03, 2014 10:20 am    Post subject: Reply with quote

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

Code:

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:

!!! 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.

VoidMage wrote:
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?

mmogilvi wrote:
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.

mmogilvi wrote:
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 https://forums.gentoo.org/viewtopic-p-7509542.html?sid=c5b44664c998872c1c014477e22c3048#7509542 .


Sounds better, I might give it a try.

mmogilvi wrote:
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?

mmogilvi wrote:
See also other solutions outlined in https://forums.gentoo.org/viewtopic-p-7570012-highlight-.html#7570012 as well as near the top of the "uninstall emul-linux" link about.


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


mmogilvi wrote:
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?
Back to top
View user's profile Send private message
VoidMage
Watchman
Watchman


Joined: 14 Oct 2006
Posts: 6196

PostPosted: Thu Jul 03, 2014 11:14 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
mmogilvi
n00b
n00b


Joined: 13 May 2011
Posts: 62

PostPosted: Fri Jul 04, 2014 5:17 am    Post subject: Reply with quote

@dachschaden:

That list of ~amd64 packages seems MUCH longer than it should need to be. As described in https://forums.gentoo.org/viewtopic-p-7509542.html?sid=c5b44664c998872c1c014477e22c3048#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.

dachschaden wrote:
mmogilvi wrote:
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?

dachschaden wrote:
mmogilvi wrote:
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:

motaito, NOT mmogilvi wrote:
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?
Back to top
View user's profile Send private message
mmogilvi
n00b
n00b


Joined: 13 May 2011
Posts: 62

PostPosted: Fri Jul 04, 2014 6:18 am    Post subject: Reply with quote

VoidMage wrote:
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:
/etc/portage/profile/use.mask:
-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 https://forums.gentoo.org/viewtopic-p-7509542.html?sid=c5b44664c998872c1c014477e22c3048#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.
Back to top
View user's profile Send private message
dachschaden
n00b
n00b


Joined: 07 Jun 2014
Posts: 65
Location: Germany

PostPosted: Sun Jul 20, 2014 12:51 am    Post subject: Reply with quote

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:

# 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.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Multimedia All times are GMT
Page 1 of 1

 
Jump to:  
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