Bugzilla Bug 112896

After upgrading to xorg 7.0.0_rc2 xine-lib would not compile because of missing
libXvMC, dooing a emerge -atv libXvMC solved the problem

Reproducible: Always
Steps to Reproduce:
1.Emerge xine
2.xine-libs fails cause of missing libXvMC
3.



Expected Results:  
prior to emegeing xine-lib, libXvMC should have been installed by the ebuild (
dependency)

AMD64, xorg 7.0.0_rc2

Post emerge info, libXvMC depends on the driver you selected.  

emerge --info
Portage 2.0.53_rc7 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r2,
2.6.11.11 x86_64)
=================================================================
System uname: 2.6.11.11 x86_64 AMD Athlon(tm) 64 Processor 2800+
Gentoo Base System version 1.12.0_pre10
dev-lang/python:     2.4.2
sys-apps/sandbox:    1.2.13
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.20-r1
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -fPIC"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib64/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-O2 -fPIC"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://mirror.gentoo.no/
http://pandemonium.tiscali.de/pub/gentoo/ http://ftp.rhnet.is/pub/gentoo/
http://ftp.du.se/pub/os/gentoo ftp://pandemonium.tiscali.de/pub/gentoo/"
LANG="dk"
LC_ALL="da_DK"
LINGUAS="dk"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 16bit 64bit 7zip X a52 aac aalib acpi alsa amarok apm auctex
audiofile avi bash-completion bcmath berkdb bitmap-fonts bl blas bluetooth
bonobo bootsplash bzip2 cap ccache cdda cddb cdio cdparanoia cdr cg chm cid
clamav cpudetection cracklib crypt css cups curl directfb djvu dpms dts dv dvd
dvdr dvdread dvi dynagraph editor edl eds emacs emacs-w3 emoticon emul-linux-x86
encode escreen evo exif expat fam fame fat fbcon fbdev fbsplash festival ffmpeg
firefox flac fmod foomaticdb fortran freetype gb gcj gcl gd gdbm ggi gif gimp
gimpprint ginac glut glx gmail gmailtimestamps gnokii gnome gphoto2 gpm grammar
graphviz gstreamer gtk gtk2 gtkhtml guile hal hddtemp hou id3 idn ieee1394
imagemagick imlib ipv6 java javascript joystick jpeg jpeg2k junit kde ladcca
lame lapack latex lcms leim libcaca libclamav libg++ libwww logitech-mouse lzo
lzw lzw-tiff mad maps mime mjpeg mng mod mozilla mozsvg mp3 mpeg mpeg2 mpeg4
mplayer musepack music musicbrainz mythtv ncurses net nls no-old-linux
nosendmail noweb nowin nptl nptlonly nsplugin nvidia offensive ogg oggvorbis
on-the-fly-crypt openal opengl pam pascal patented pcre pda pdf pdflib perl
player plotutils pmu png posix postgres ppds print python qt quicktime rar
readline real remix rhythmbox rtc sblive sdl sharedmem sms sou sounds speex
spell spreadsheet sql ssl stencil-buffer subtitles svg sysfs tcltk tcpd tetex
theora threads tiff transcode truetype truetype-fonts type1 type1-fonts udev
unicode usb userlocales utf8 v4l vcd videos visualization vmdbpostgres voice
vorbis wmf wv xanim xine xinerama xml xml2 xmms xpm xrandr xscreensaver xv xvid
xvmc yv12 zlib linguas_dk userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LDFLAGS, MAKEOPTS


uses nvidia-kernel

Deps of 1.1.1 are safe for xorg modular, if you're hot having virtual/x11 
installed. 
If you're using nvidia XvMC then it also requires nvidia-glx. 
 
Which version of xine-lib are you using? 
 

using xine-lib 1.1.1

Nvidia-glx is installed, and both nvidia-glx and nvidia-kernel was remerge after
succesfuld build og xorg 7.0.0_rc2

Sorry for beeing af noob but was does you mean? "Deps of 1.1.1 are safe for xorg
modular, if you're hot having virtual/x11 installed." 

xine-lib fails/failed just after uncompresion, libXvMC can not be found.

Mind pasting the output exactly? 

localhost ~ # emerge -atv xine-lib

These are the packages that I would merge, in reverse order:

Calculating dependencies ...done!
[ebuild   R   ] media-libs/xine-lib-1.1.1  +X +a52 +aac +aalib +alsa (-altivec)
-arts -cle266 +directfb +dts +dvd -dxr3 -esd +fbcon +flac +gnome -i8x0
+imagemagick +ipv6 +libcaca +mad +mng +nls +nvidia +opengl -oss -samba +sdl
+speex +theora +v4l +vcd (-vidix) +vorbis (-win32codecs) +xinerama +xv +xvmc 0 kB

Total size of downloads: 0 kB

Do you want me to merge these packages? [Yes/No] yes
>>> emerge (1 of 1) media-libs/xine-lib-1.1.1 to /
>>> md5 files   ;-) xine-lib-1.1.0-r7.ebuild
>>> md5 files   ;-) xine-lib-1.1.1.ebuild
>>> md5 files   ;-) xine-lib-1.1.0.ebuild
>>> md5 files   ;-) xine-lib-1.0.1-r4.ebuild
>>> md5 files   ;-) xine-lib-1.1.0-r5.ebuild
>>> md5 files   ;-) xine-lib-1_rc8-r2.ebuild
>>> md5 files   ;-) files/xine-lib-formatstring.patch
>>> md5 files   ;-) files/digest-xine-lib-1.1.0-r7
>>> md5 files   ;-) files/digest-xine-lib-1.1.0
>>> md5 files   ;-) files/digest-xine-lib-1.1.1
>>> md5 files   ;-) files/digest-xine-lib-1.0.1-r4
>>> md5 files   ;-) files/digest-xine-lib-1.1.0-r5
>>> md5 files   ;-) files/digest-xine-lib-1_rc8-r2
>>> md5 src_uri ;-) xine-lib-1.1.1.tar.gz
>>> md5 src_uri ;-) xine-lib-patches-17.tar.bz2
>>> Unpacking source...
>>> Unpacking xine-lib-1.1.1.tar.gz to /var/tmp/portage/xine-lib-1.1.1/work
>>> Unpacking xine-lib-patches-17.tar.bz2 to /var/tmp/portage/xine-lib-1.1.1/work
 * Applying various patches (bugfixes/updates) ...
 *   010_all_pic.patch ...                                                     
                                                                     [ ok ]
 *   020_all_fbsd-sdl.patch ...                                                
                                                                     [ ok ]
 *   030_all_vidix-gcc4.patch ...                                              
                                                                     [ ok ]
 * Done with patching
 * Running elibtoolize in: xine-lib-1.1.1
 *   Applying portage-1.5.10.patch ...
 *   Applying sed-1.5.6.patch ...
>>> Source unpacked.

!!! ERROR: media-libs/xine-lib-1.1.1 failed.
!!! Function src_compile, Line 162, Exitcode 0
!!! Unable to find libXvMC.so.
!!! If you need support, post the topmost build error, NOT this status message.

Are you sure it really does something? I think the only thing it could do is 
to add -g flags to CFLAGS/CXXFLAGS, but that's something you can do without 
having to change the ebuild on the user side... 
 

sorry was the wrong bug :| 

Can you post the output of equery f libXvMC ? 

 equery f libXvMC
[ Searching for packages matching libXvMC... ]

Seem like there's something bad with the || ( x11-libs/libXvMC virtual/x11 ) 
or you did something wrong. 
 
X11 Herd? 

Could i have anything to do with tha fact that xorg 7 series are modular
buildt,
and that libXvMC 0.99.1 is masked?

after dooing a emerge -atv libXvMC
jess@localhost ~ % sudo equery f libXvMC
Password:
[ Searching for packages matching libXvMC... ]
* Contents of x11-libs/libXvMC-0.99.1:
/usr
/usr/include
/usr/include/X11
/usr/include/X11/extensions
/usr/include/X11/extensions/XvMClib.h
/usr/lib64
/usr/lib64/libXvMC.a
/usr/lib64/libXvMC.la
/usr/lib64/libXvMC.so -> libXvMC.so.1.0.0
/usr/lib64/libXvMC.so.1 -> libXvMC.so.1.0.0
/usr/lib64/libXvMC.so.1.0.0
/usr/lib64/libXvMCW.a
/usr/lib64/libXvMCW.la
/usr/lib64/libXvMCW.so -> libXvMCW.so.1.0.0
/usr/lib64/libXvMCW.so.1 -> libXvMCW.so.1.0.0
/usr/lib64/libXvMCW.so.1.0.0
/usr/lib64/pkgconfig
/usr/lib64/pkgconfig/xvmc.pc

This issue is due to portage handling of virtuals, so moving to portage devs.  
 
Seems like xorg-x11-7*, although not providing virtual/x11, is registered as 
provider, filling the virtual/x11 requirement and then disregarding the rest 
of the deps. 
 

$ cat /mnt/archive/gentoo/rsync/profiles/base/virtuals | grep /x11 
virtual/x11                                     x11-base/xorg-x11 
 

Throwing this back as there's absolutely nothing that can be done from portage 
side. You can either use <x11-base/xorg-x11-7 in place of virtual/x11 or throw 
this X11's way to become an early adopter of GLEP 37. The only thing 
preventing GLEP 37 from going final is that portage does not do --deep by 
default meaning that a user will be able to unmerge a provider while the 
"virtual" package is still installed. 

Moving to X11, I did what spyderous told to for modular xorg.. it's their game 
to find a solution. 
 

(In reply to comment #16)
> Throwing this back as there's absolutely nothing that can be done from portage 
> side.

Why is it impossible for portage to respect the PROVIDES flag? That is how I was
told it worked when I asked about it in #gentoo-portage. Finding differently now
is rather annoying, to say the least.

Portage starts of with the list of virtuals defined in the profiles and the
user's configuration. It then adjusts it with packages that are installed and
packages to be installed as they are added to the dependency graph. Portage does
not do any sanity checks on the virtuals that profiles or the user have manually
specified.

(In reply to comment #19)
> Portage does
> not do any sanity checks on the virtuals that profiles or the user have manually
> specified.

Could that be changed?

Not in a hurry... Internally, virtuals are expanded into || ( foo bar ) 
constructs. At the time that the || ( foo bar ) bit is processed, the fact 
that it was once a virtual is long forgotten. A fair bit will need to be 
refactored and installed packages will have to be taken into account when 
working dependencies (which I'm currently working on). A quick estimate would 
be something in the order of 2 months for a capable portage to hit ~arch. 

OK, thanks for the info Jason! Guess we'll have to start telling people to use
<=xorg-6.99 instead.

(In reply to comment #16)
> this X11's way to become an early adopter of GLEP 37. The only thing 
> preventing GLEP 37 from going final is that portage does not do --deep by 
> default meaning that a user will be able to unmerge a provider while the 
> "virtual" package is still installed. 

Any updates here, portage guys?

I've yet to brush off the GLEP yet, but there's nothing that needs to be done 
portage side for dummy packages with a category of virtual to work. I don't 
think there's any sort of policy that disagrees with adoption of what the GLEP 
proposes either. The GLEP itself is more about getting rid of current style 
virtuals. Was there something specific you were waiting on? 

(In reply to comment #24)
> Was there something specific you were waiting on? 

It sounded like --deep by default was a requirement for this to work properly.
Is that the case in current portage, or is that not a requirement?

It's preferred but not exactly required. Without it, a user is able to merge  
virtual/x11 (bringing in xorg-x11), unmerge xorg-x11 and then be able to merge  
qt (for example) without emerge bringing xorg-x11 back in. This is of course 
already possible with non-virtuals but is a much less common action. However, 
as xorg-x11 is the only current virtual/x11 provider (?) it should be uncommon 
anyway. 
 
Perhaps adding --deep to revdep-rebuild would be a good idea for the 
short-term...  

(In reply to comment #26) 
> However, as xorg-x11 is the only current virtual/x11 provider (?) it should be 
> uncommon anyway. 

Not quite -- macos/darwin users have the (mythical?) x11-base/apple-xfree set as
their default, which comes from their package.provided.

RDEPEND="macos? ( x11-base/apple-xfree ) !macos? ( || 
( <=x11-base/xorg-x11-6.99 x11-libs/libXvMC ) )" 
 
What I meant was that a user is unlikely to unmerge xorg-x11 with the 
intention to replace it with something else, forget to do so and then try and 
merge something that requires x11. 

Created an attachment (id=73851) [details]
virtual/x11/x11-0.1.ebuild

I'm trying to get all this straight in my head. Basically what this will mean
is that when we commit a virtual/x11-0.1, we can remove the virtual/x11 line
from all the virtuals files, and the PROVIDES line from all virtual/x11
providers, right?

Here's a draft, untested ebuild -- how's it look?

(In reply to comment #29)
> I'm trying to get all this straight in my head. Basically what this will mean
> is that when we commit a virtual/x11-0.1, we can remove the virtual/x11 line
> from all the virtuals files, and the PROVIDES line from all virtual/x11
> providers, right?

Along these lines, which type of virtual will be preferred if both exist?

Could someone from the portage team please look at my proposed ebuild and let
me
know whether it will work?

Thanks!

I'd give it a version to match what the virtual is based on (X11R6) but the 
actual content is pretty much right. We should really look at adjusting the 
default src_* functions as I'm pretty sure they're just a hold over from very 
old practices and that it's been policy to explicitly define them for a very 
long time... That's an issue apart from this one though. 

Excellent. I'll test this over the next few days, then add it.

Answers to my other questions in comment #29 and comment #30 would also be nice.

If a "real" virtual is defined anywhere it will mask the ebuild. So while  
virtual/x11 exists in the profiles, it will always be used. If it's removed  
from the profiles but left in the ebuild, the installed version's PROVIDE will  
only mask the package after it has been installed. User overrides will always  
take preference.  
  
Given this, it might be safest to leave the PROVIDE in the xorg-x11 ebuilds  
until virtual/x11 comes to represent multiple packages if ever. Leaving it in  
would work around the issue I mentioned in comment #26. 

(In reply to comment #32)
> I'd give it a version to match what the virtual is based on (X11R6) but the 
> actual content is pretty much right. We should really look at adjusting the 
> default src_* functions as I'm pretty sure they're just a hold over from very 
> old practices and that it's been policy to explicitly define them for a very 
> long time... That's an issue apart from this one though. 

Actually I looked at them and they look fine. I just made an assumption from a
while ago.

(In reply to comment #32)
> I'd give it a version to match what the virtual is based on (X11R6) but the 
> actual content is pretty much right.

I just committed it, but was unable to add the macos section because repoman
whined, since the actual app doesn't exist (just in package.provided on macos).
Looks like virtual/x11 will have to stay in profiles for macos until something
gets figured out for that.

Once I know this doesn't break the tree, I'll remove the virtual in base/.

*** Bug 114990 has been marked as a duplicate of this bug. ***

RepoMan scours the neighborhood...

  digest.assumed                 2
   digest-xorg-x11-6.8.99.15-r4::xorg-x11-6.8.99.15-files-0.1.1.tar.bz2
   digest-xorg-x11-6.8.99.15-r4::xorg-x11-6.8.99.15-patches-0.1.6.tar.bz2
  virtual.exists                 3
   x11-base/xorg-x11/xorg-x11-6.8.99.15-r4.ebuild: virtual/x11
   x11-base/xorg-x11/xorg-x11-6.8.2-r4.ebuild: virtual/x11
   x11-base/xorg-x11/xorg-x11-6.8.2-r6.ebuild: virtual/x11

Genone asked me to mention this issue here.  That virtual.exists message is
fatal, not a warning, btw.

Ya, it's pretty annoying.  I just delete the virtual/x11 ebuild from my CVS
checkout whenever I need to do xorg-x11 work.  I'm assuming this problem will go
away once Donnie yoinks the original virtual this weekend.

(In reply to comment #39)
> Ya, it's pretty annoying.  I just delete the virtual/x11 ebuild from my CVS
> checkout whenever I need to do xorg-x11 work.  I'm assuming this problem will go
> away once Donnie yoinks the original virtual this weekend.

I don't think it will, according to the error description, because what it's
checking for is PROVIDE and a package that exists. The PROVIDE will stay in the
xorg-x11 ebuilds, as recommended in comment #34.

(In reply to comment #34)
> Given this, it might be safest to leave the PROVIDE in the xorg-x11 ebuilds  
> until virtual/x11 comes to represent multiple packages if ever. Leaving it in  
> would work around the issue I mentioned in comment #26. 

This causes some repoman errors.

"virtual.exists":"PROVIDE contains existing package names"
"virtual.versioned":"PROVIDE contains virtuals with versions"

I moved them into qawarnings in my local copy. Perhaps you could do the same, if
this is the approach you prefer?

Yep, have done so already until a better solution can be found. 

Should be fixed now, using the new-style virtual.