It seems the ebuild/eclass for vmware-modules does not care about any-any updates. Tested with vmware-modules-1.0.0.17 for vmware-workstation-6.0.2.59824 Reproducible: Always Steps to Reproduce: 1. edit vmware.eclass to pick a newer any-any 2. redigest vmware-workstation-6.0.2.xxx.ebuild 3. emerge vmware-modules Actual Results: any-any update is ignored completely. The tarball isn't checked or unpacked. ---------------------------------------------------------- >>> Emerging (1 of 1) app-emulation/vmware-modules-1.0.0.17 to / * VMware-player-2.0.2-59824.x86_64.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking VMware-player-2.0.2-59824.x86_64.tar.gz ;-) ... [ ok ] * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found kernel object directory: * /lib/modules/2.6.24-rc4-zen0/build * Found sources for kernel version: * 2.6.24-rc4-zen0 >>> Unpacking source... >>> Unpacking VMware-player-2.0.2-59824.x86_64.tar.gz to /var/tmp/portage/app-emulation/vmware-modules-1.0.0.17/work >>> Unpacking ./vmware-player-distrib/lib/modules/source//vmmon.tar to /var/tmp/portage/app-emulation/vmware-modules-1.0.0.17/work * Applying various patches (bugfixes/updates) ... * 000_all_makefile-include-directory.patch ... [ ok ] * 020_all_epoll-def-warnings.patch ... [ ok ] * Done with patching * Converting vmmon-only/Makefile to use M= instead of SUBDIRS= ... [ ok ] >>> Unpacking ./vmware-player-distrib/lib/modules/source//vmnet.tar to /var/tmp/portage/app-emulation/vmware-modules-1.0.0.17/work * Applying various patches (bugfixes/updates) ... * 000_all_makefile-include-directory.patch ... [ ok ] * 020_all_epoll-def-warnings.patch ... [ ok ] * Done with patching * Converting vmnet-only/Makefile to use M= instead of SUBDIRS= ... [ ok ] >>> Unpacking ./vmware-player-distrib/lib/modules/source//vmblock.tar to /var/tmp/portage/app-emulation/vmware-modules-1.0.0.17/work * Applying various patches (bugfixes/updates) ... * 000_all_makefile-include-directory.patch ... [ ok ] * 020_all_epoll-def-warnings.patch ... [ ok ] * Done with patching * Converting vmblock-only/Makefile to use M= instead of SUBDIRS= ... [ ok ] >>> Source unpacked. >>> Compiling source in /var/tmp/portage/app-emulation/vmware-modules-1.0.0.17/work ... ------------------------------------------------------------------ Expected Results: Any-any patches should be unpacked and applied, like e.g. for vmware-workstation: -------------------------------------- * checking VMware-workstation-6.0.2-59824.x86_64.tar.gz ;-) ... [ ok ] * checking vmware-any-any-update115.tar.gz ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking VMware-workstation-6.0.2-59824.x86_64.tar.gz to /var/tmp/portage/app-emulation/vmware-workstation-6.0.2.59824/work >>> Unpacking vmware-any-any-update115.tar.gz to /var/tmp/portage/app-emulation/vmware-workstation-6.0.2.59824/work --------------------------------------------------- emerge --info: Portage 2.1.4_rc7 (default-linux/amd64/2007.0/desktop, gcc-4.2.2, glibc-2.7-r0, 2.6.24-rc4-zen0 x86_64) ================================================================= System uname: 2.6.24-rc4-zen0 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ Timestamp of tree: Wed, 05 Dec 2007 11:30:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.3 dev-lang/python: 2.5.1-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 2.0.0_rc6 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r2 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -msse3 -fno-ident -fweb -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=athlon64 -msse3 -fno-ident -fweb -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="candy ccache collision-protect distlocks metadata-transfer parallel-fetch prelink sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS=" http://gentoo.intergenia.de ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo" LANG="de_DE.UTF-8" LC_ALL="de_DE.utf8" LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed" LINGUAS="en de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/enlightenment /usr/portage/local/layman/xeffects /usr/portage/local/layman/java-overlay /usr/portage/local/layman/webapps-experimental /usr/portage/local/layman/gechi /usr/portage/local/layman/gentoo-gis /usr/portage/local/layman/java-gcj-overlay /usr/portage/local/layman/gentoo-china /usr/portage/local/layman/kde /usr/portage/local/layman/mozilla /usr/local/overlays/gimpel /home/tom/cvs/proaudio/trunk/overlays/proaudio /home/tom/cvs/proaudio/trunk/overlays/proaudio-dev" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowex X acl acpi alsa amd64 apache2 berkdb bitmap-fonts branding cairo cdr cli cracklib crypt cups dbus dri dvd dvdr dvdread eds emboss encode evo fam fbcon firefox gdbm gif gpm gstreamer gtk hal iconv isdnlog jack jpeg kdeenablefinal kdehiddenvisibility libnotify mad midi mikmod mmx mmxext mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp pam pcre pdf perl pic png pppd pthreads python qt3 qt3support qt4 quicktime readline reflection sdl session shadow spell spl sse sse2 ssl ssse3 startup-notification svg tcpd threads tiff truetype truetype-fonts type1-fonts unicode userlocales vorbis xcb xml xorg xv zlib" ALSA_CARDS="ice1712 ice1724" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="worker" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en de" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
To sum it up, these were the steps I had to do manually to get vmware workstation 6.0.2 running fine on 2.6.24-rc4 Additionally I had to use the module sources that come with vmware-workstation, because the ones installed by the vmware-modules ebuild from VMware-Player caused a version mismatch for vmnet when starting vmware "expected 171.0, got 161.0" ------------------------------- # fist apply update to installed vmware workstation (module sources) cd /tmp tar xvf /usr/portage/distfiles/vmware-any-any-update115a.tar.gz cd vmware-any-any-update115a ./runme.pl # run ebuild manually ebuild /usr/portage/app-emulation/vmware-modules/vmware-modules-1.0.0.17.ebuild unpack cd /var/tmp/portage/app-emulation/vmware-modules-1.0.0.17/work rm -rf vm*-only # do NOT use outdated vmware player modules, use the ones that come with workstation # otherwhise we get a version mismatch for i in /opt/vmware/workstation/lib/modules/source/*.tar; do tar xvf $i; done # compile and install ebuild /usr/portage/app-emulation/vmware-modules/vmware-modules-1.0.0.17.ebuild compile ebuild /usr/portage/app-emulation/vmware-modules/vmware-modules-1.0.0.17.ebuild merge -----------------------------------
Whatever the problem is here, it probably be fixed by making some slight tweaks to the ebuild/eclasses. The main difference between portage-2.1.4 and earlier versions is that global scope code in the ebuild/eclasses is only executed one time instead of once per phase. Any ebuilds/eclasses that assume that they will be sourced more than once need to be fixed. Looking at the vmware-modules ebuild, it's unclear to me if or how the ANY_ANY variable relates to it. I see that vmware.eclass references ANY_ANY in it's src_unpack, but vmware-modules should be using vmware-mod_src_unpack() and I don't see any ANY_ANY references there.
Created attachment 137860 [details, diff] diff between vmware-modules-1.0.0.15-r1 and 1.0.0.17 ebuilds The 1.0.0.15-r1 ebuild does not define a SRC_URI, so it inherits the SRC_URI that's defined by vmware-mod.eclass (and contains ANY_ANY references). The 1.0.0.17 ebuild defines SRC_URI, which overrides the SRC_URI that's inherited from vmware-mod.eclass. Because of this, the SRC_URI containing the ANY_ANY references is overwritten.
For the record, The vmware-workstation/player/server packages don't actually *need* the any_any package (they were only using it for the init script, which was actually causing some problems with the more recent packages). I'm removing it's use from the vmware overlay in the very latest version of player/workstation/server (so if you're using the overlay, that's why). It's also entirely possible that the recent changes in portage 2.4 are causing issues (there's a big red warning saying they're being overridden when using the vmware overlay, I haven't had a chance to investigate the issue yet). As to the vmware-modules mismatch issue, 6.0.2 should work fine with vmware-player-2.0.2's modules (which should be 1.0.0.17). Please also note that the 2.6.24-rc kernels are not supported by the latest versions of workstation or player, because the any-any people haven't caught up with those version numbers yet (older modules that end in -r1 are built from the any-any sources as of 115 are now compatible with 2.6.24-rc{2,3,4}). I hope this clears up some of the confusion, if there's a still a bug left at the end of all this, let me know what is it and I'll be happy to help investigate it with the portage team... 5:)
(In reply to comment #4) > For the record, > > The vmware-workstation/player/server packages don't actually *need* the any_any > package (they were only using it for the init script, which was actually > causing some problems with the more recent packages). I'm removing it's use > from the vmware overlay in the very latest version of player/workstation/server > (so if you're using the overlay, that's why). > I don't use the vmware overlay, and none of the other overlays I have in the emerge --info output above has a vmware.eclass or vmware-mod.eclass > As to the vmware-modules mismatch issue, 6.0.2 should work fine with > vmware-player-2.0.2's modules (which should be 1.0.0.17). It didn't for me. Maybe because I removed the unpacked module sources from player and used the ones from the any-any update tarball. That was wrong it seems, but I didn't look into how exactly that runme.pl works. So let's forget about that in this bug report. I know that 2.6.24-rc's are unsupported, but after the any-any-upadte115(a) came out I wanted to get my workstation running again and stumbled over this issue: the vmware-modules ebuild doesn't care about the updates. That's a bug.
Fair enough, you might like to try out the vmware overlay, as it gets updated more frequently than the main tree (and is, in fact, already using any-any-update115, although I'll check again for 115a). 115 did not yet support vmware-workstation-6.0.2 (due to a version mismatch, etc) and therefore the vmware-modules-1.0.0.17 ebuild will *not* make use of the any-any-patch because it isn't interoperable with that product yet. For that reason we build direct from the vmware-player sources, which should be compatible with vmware-workstation of the same version (they are for x86, since I'm using them as we speak). Unfortunately the any-any-updates are not produced by vmware and are not always compatible with the latest vmware products. As soon as they become compatible, it will be reflected in the vmware overlay, and a few weeks later added to the main tree. Please ensure you understand the workings of the module system we've established before reporting assertions as bugs. The ebuilds are functioning exactly as intended. The real bug appears to be that the vmware-modules-1.0.0.17 provide a version mismatch against vmware-workstation-6.0.2 on amd64. I'll double check to ensure that there are no discrepancies between the vmware-workstation-6.0.{1,2} and vmware-player-2.0.{1,2} modules for amd64, but please don't go rolling your own modules. I'll report my results back here.
Just as a side note, there's also no sign of a vmware-any-any-update115a on the standard distribution sites. There's only vmware-any-any-update115.
(In reply to comment #6) > Fair enough, you might like to try out the vmware overlay, as it gets updated > more frequently than the main tree (and is, in fact, already using > any-any-update115, although I'll check again for 115a). Tried that too of course, but didn't help for my "unstable" 2.6.24-rc kernel. > 115 did not yet support vmware-workstation-6.0.2 (due to a version mismatch, > etc) and therefore the vmware-modules-1.0.0.17 ebuild will *not* make use of > the any-any-patch because it isn't interoperable with that product yet. For > that reason we build direct from the vmware-player sources, which should be > compatible with vmware-workstation of the same version (they are for x86, since > I'm using them as we speak). Thanks, that makes it a lot clearer now why it didn't pick the any-any patch at all. > Please ensure you understand the workings of the module system we've > established before reporting assertions as bugs. The ebuilds are functioning > exactly as intended. The real bug appears to be that the > vmware-modules-1.0.0.17 provide a version mismatch against > vmware-workstation-6.0.2 on amd64. I'm not sure. As said I removed the module sources from vmware-player in $WORKDIR, and unpacked the ones from any-any-115(a), and those caused the mismatch. I will test the regular modules on 2.6.23 and amd64 this evening. (In reply to comment #6) > Just as a side note, there's also no sign of a vmware-any-any-update115a on the > standard distribution sites. There's only vmware-any-any-update115. True, 115a is somewhere from the vmware forums. It seems to solve a lockup after some minutes which I had with 115, 115a is running since tonight w/o problems so far. Again: I didn't know that vmware-modules-1.0.0.17 isn't supposed to apply any updates at all, and thought this must be a bug. Wrong thinking. Thanks for your explanation, and sorry for that noise.
No problem, I've also checked the amd64 versions of vmware-workstation-6.0.2 and vmware-player-2.0.2 (and, in fact, 6.0.1 and 2.0.1 as well). The source code for the modules is identical, so everything should work as intended, but probably not with the 2.6.24 kernel. Since there's no real bug here, I'm going to mark this as invalid.
