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