| Summary: | vmware-modules-1.0.0.17 provides a version mismatch against vmware-workstation-6.0.2 on amd64 | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Thomas Kuther <gimpel> |
| Component: | Core - Interface (emerge) | Assignee: | Gentoo VMWare Bug Squashers [disabled] <vmware+disabled> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | jakub |
| Priority: | High | ||
| Version: | 2.1 | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| URL: | http://forums.gentoo.org/viewtopic-t-626897.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | diff between vmware-modules-1.0.0.15-r1 and 1.0.0.17 ebuilds | ||
|
Description
Thomas Kuther
2007-12-05 17:43:48 UTC
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. |
