open-vm-tools-devel — List for open-vm-tools developer discussions.

Re: [open-vm-tools-devel] Status of VMCI in open-vm-tools w.r.t workstation version

[Adar D. <ad...@vm...>]

> So I tried to use the latest copy of open-vm-tools to use with VMCI on
> workstation 6.0.2.  However, despite it building properly the module
> will not load.  It gives an error that I referred to yesterday that I
> have tracked down to this change in vmci_drv.c:
>
> vmci_drv.c from: VMwareTools-6.0.2-59824.tar.gz had this:
>
>     capabilities = inl(ioaddr + VMCI_CAPS_ADDR);
>
>     if ((capabilities & VMCI_CAPS_HYPERCALL) == 0) {
>        printk(KERN_ERR "VMCI device does not support hypercalls.\n");
>        goto release;
>     }
>     if ((capabilities & VMCI_CAPS_GUESTCALL) == 0) {
>        printk(KERN_ERR "VMCI device does not support guestcalls.\n");
>        goto release;
>     }
>
> where as vmci_drv.c in the current git has this to:
>
>     capabilities = inl(ioaddr + VMCI_CAPS_ADDR);
>
>     if ((capabilities & VMCI_CAPS_DATAGRAM) == 0) {
>        printk(KERN_ERR "VMCI device does not support datagrams.\n");
>        goto release;
>     }
>
> Under what version of workstation is this datagram capability present
> in
> the VMCI device?

Between WS6 and WS6.5 the vmci device was changed in a backwards-incompatible way. That is, the vmci device present in WS6.5 (and in any hardware version 7 VMs) is a different device than the experimental vmci device that shipped in WS6 (hardware version 6 VMs).

As such, the vmci driver in the open-vm-tools will only drive the VMCI device present in hardware version 7. So if you want to use it, you'll need to get your hands on WS6.5, which I believe is in either beta or RC at the moment. If you want to stay with WS6, the vmci driver in the open-vm-tools won't be of any use to you and you'll need to use the vmci module source that shipped with the WS6 Tools.

[open-vm-tools-devel] Status of VMCI in open-vm-tools w.r.t workstation version

[Cam M. <ca...@cs...>]

Hi,

So I tried to use the latest copy of open-vm-tools to use with VMCI on 
workstation 6.0.2.  However, despite it building properly the module 
will not load.  It gives an error that I referred to yesterday that I 
have tracked down to this change in vmci_drv.c:

vmci_drv.c from: VMwareTools-6.0.2-59824.tar.gz had this:

    capabilities = inl(ioaddr + VMCI_CAPS_ADDR);

    if ((capabilities & VMCI_CAPS_HYPERCALL) == 0) {
       printk(KERN_ERR "VMCI device does not support hypercalls.\n");
       goto release;
    }
    if ((capabilities & VMCI_CAPS_GUESTCALL) == 0) {
       printk(KERN_ERR "VMCI device does not support guestcalls.\n");
       goto release;
    }

where as vmci_drv.c in the current git has this to:

    capabilities = inl(ioaddr + VMCI_CAPS_ADDR);

    if ((capabilities & VMCI_CAPS_DATAGRAM) == 0) {
       printk(KERN_ERR "VMCI device does not support datagrams.\n");
       goto release;
    }

Under what version of workstation is this datagram capability present in 
the VMCI device?

Thanks,
Cam

[open-vm-tools-devel] [ open-vm-tools-Tracker-1960947 ] procps-devel and proc/sysinfo.h

[SourceForge.net <no...@so...>]

Tracker item #1960947, was opened at 2008-05-09 04:09
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1960947&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: misc
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Johnny Hughes (hughesjr)
Assigned to: Nobody/Anonymous (nobody)
Summary: procps-devel and proc/sysinfo.h

Initial Comment:
The procps package in several linux distributions does not contain the header file (proc/sysinfo.h) by default.

(CentOS, RHEL, Fedora, Mandriva, Ubuntu, and opensuse do not contain that header file by default ... it seems it is only in Debian by default)

The upstream "make install" also does not install that header.


----------------------------------------------------------------------

>Comment By: Adar Dembo (adembo)
Date: 2008-09-05 10:59

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Sorry for not providing an update earlier. Our intern Daniel was going to
take a look at this but got swamped with other tasks.

I think I'll go with the solution used in those dkms packages, though
there'll be a few ripples in configure.ac, so it may take me some time to
sort it out.

----------------------------------------------------------------------

Comment By: Denis Leroy (poolshark)
Date: 2008-09-05 03:11

Message:
Logged In: YES 
user_id=95186
Originator: NO

Any updates on this ?

It's important to understand that right now, the configure script will
fail by default on EVERY linux distribution but Debian. The use of procps
should be turned on explicitly by an option rather than the other way
round.


----------------------------------------------------------------------

Comment By: Denis Leroy (poolshark)
Date: 2008-05-12 23:15

Message:
Logged In: YES 
user_id=95186
Originator: NO

Ugh, I'd get flamed to a crisp if I did this in Fedora :-) It would also
be hard to convince the Fedora/RHEL maintainer to export the header files,
since this is a deviation from upstream.

I would recommend the solution I used for my dkms packages at

http://www.poolshark.org/dkms-open-vm-tools/dkms-open-vm-tools-0-1.2008.04.14.fc8.src.rpm

This one has a patch that add the few prototypes needed to compile the
code.


----------------------------------------------------------------------

Comment By: Johnny Hughes (hughesjr)
Date: 2008-05-12 14:09

Message:
Logged In: YES 
user_id=1166174
Originator: YES

Well ... I cheated :D

I just extracted the CentOS-5 procps source and tared up the /proc header
files and added them as a Source to my open-vm-tools SRPM, then I untared
them into open-vm-tools BUILD root (in lib/include/proc modified the path
in the configure file to look in the new place.

That is not a very good option, but it was the fastest/easiest.  I will
have to track the source manually and modify the headers if required.

The other option is to create a proper -devel file for procps .. which I
would do if CentOS was not a rebuild of RHEL sources.  Since it is, I am
kind of stuck with their procps RPM as defined.

----------------------------------------------------------------------

Comment By: ECL (sopwith)
Date: 2008-05-12 12:17

Message:
Logged In: YES 
user_id=18318
Originator: NO

Hey Johnny, do you have any suggestions for viable solutions? I think we
were looking at trying to remove the dependency on libprocps, but what
other options are there from your perspective?

----------------------------------------------------------------------

Comment By: Dmitriy (bryndin)
Date: 2008-05-09 11:55

Message:
Logged In: YES 
user_id=1494464
Originator: NO

In Mandriva case, /usr/include/procps is created instead of
/usr/include/proc.
creating a soft link solves the problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1960947&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-1960947 ] procps-devel and proc/sysinfo.h

[SourceForge.net <no...@so...>]

Tracker item #1960947, was opened at 2008-05-09 04:09
Message generated for change (Comment added) made by poolshark
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1960947&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: misc
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Johnny Hughes (hughesjr)
Assigned to: Nobody/Anonymous (nobody)
Summary: procps-devel and proc/sysinfo.h

Initial Comment:
The procps package in several linux distributions does not contain the header file (proc/sysinfo.h) by default.

(CentOS, RHEL, Fedora, Mandriva, Ubuntu, and opensuse do not contain that header file by default ... it seems it is only in Debian by default)

The upstream "make install" also does not install that header.


----------------------------------------------------------------------

Comment By: Denis Leroy (poolshark)
Date: 2008-09-05 03:11

Message:
Logged In: YES 
user_id=95186
Originator: NO

Any updates on this ?

It's important to understand that right now, the configure script will
fail by default on EVERY linux distribution but Debian. The use of procps
should be turned on explicitly by an option rather than the other way
round.


----------------------------------------------------------------------

Comment By: Denis Leroy (poolshark)
Date: 2008-05-12 23:15

Message:
Logged In: YES 
user_id=95186
Originator: NO

Ugh, I'd get flamed to a crisp if I did this in Fedora :-) It would also
be hard to convince the Fedora/RHEL maintainer to export the header files,
since this is a deviation from upstream.

I would recommend the solution I used for my dkms packages at

http://www.poolshark.org/dkms-open-vm-tools/dkms-open-vm-tools-0-1.2008.04.14.fc8.src.rpm

This one has a patch that add the few prototypes needed to compile the
code.


----------------------------------------------------------------------

Comment By: Johnny Hughes (hughesjr)
Date: 2008-05-12 14:09

Message:
Logged In: YES 
user_id=1166174
Originator: YES

Well ... I cheated :D

I just extracted the CentOS-5 procps source and tared up the /proc header
files and added them as a Source to my open-vm-tools SRPM, then I untared
them into open-vm-tools BUILD root (in lib/include/proc modified the path
in the configure file to look in the new place.

That is not a very good option, but it was the fastest/easiest.  I will
have to track the source manually and modify the headers if required.

The other option is to create a proper -devel file for procps .. which I
would do if CentOS was not a rebuild of RHEL sources.  Since it is, I am
kind of stuck with their procps RPM as defined.

----------------------------------------------------------------------

Comment By: ECL (sopwith)
Date: 2008-05-12 12:17

Message:
Logged In: YES 
user_id=18318
Originator: NO

Hey Johnny, do you have any suggestions for viable solutions? I think we
were looking at trying to remove the dependency on libprocps, but what
other options are there from your perspective?

----------------------------------------------------------------------

Comment By: Dmitriy (bryndin)
Date: 2008-05-09 11:55

Message:
Logged In: YES 
user_id=1494464
Originator: NO

In Mandriva case, /usr/include/procps is created instead of
/usr/include/proc.
creating a soft link solves the problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1960947&group_id=204462

[open-vm-tools-devel] Getting "Failed opening default VMCI device with error 2"

[Cam M. <ca...@cs...>]

Hi,

Rather sporadically I am getting an error from VMCI.  It was working 
previously.

cam@hardy:~/VMCI$ ./sharedMemApp -s
Failed opening default VMCI device with error 2.
Failed to init VMCI library.

/dev/vmci exists but strace shows the following error:
open("/dev/vmci", O_RDWR|O_LARGEFILE)   = -1 ENODEV (No such device)

Here is the output from dmesg referring to VMCI.

[713259.760719] VMCI: Major device number is: 253
[713259.762032] Probing for vmci/PCI.
[713259.762094] ACPI: PCI Interrupt 0000:02:03.0[A] -> GSI 17 (level, 
low) -> IRQ 18
[713259.762174] Found vmci/PCI at 0x20c0, irq 18.
[713259.762200] VMCI device does not support datagrams.
[713259.762248] ACPI: PCI interrupt for device 0000:02:03.0 disabled
[713259.768547] vmci: probe of 0000:02:03.0 failed with error -16
[713270.412047] Opening vmci device
[713270.412392] Received open on uninitialized vmci device.
[713277.483196] Opening vmci device
[713277.483568] Received open on uninitialized vmci device.

It seems the probe is failing.  I am running Ubuntu with 2.6.24-16.  Is 
it known what combination open-vm-tools version and kernel that work 
well together?

Thanks,
Cam

[open-vm-tools-devel] [ open-vm-tools-Tracker-1925183 ] building on openSUSE fails

[SourceForge.net <no...@so...>]

Tracker item #1925183, was opened at 2008-03-25 06:50
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1925183&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libraries
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: building on openSUSE fails

Initial Comment:
Building open-vm-tools on openSUSE up to 10.3 fails for some reasons.

./configure passes correctly, but make afterwards fails with:

 gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"2008.03.19-82724\" "-DPACKAGE_STRING=\"open-vm-tools 2008.03.19-82724\"" -DPACKAGE_BUGREPORT=\"ope...@li...\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"2008.03.19-82724\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DNO_DNET=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LSEEK=1 -I. -Wall -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -DVMX86_TOOLS -I
 /usr/src/packages/BUILD/open-vm-tools-2008.03.19-82724/lib/include -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -DGLIBC_VERSION_22 -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -DUSING_AUTOCONF=1 -MT str.lo -MD -MP -MF .deps/str.Tpo -c ../str.c -fPIC -DPIC -o .libs/str.o
../str.c:46: error: expected declaration specifiers or '...' before numeric constant
../str.c:46: error: expected ')' before '!=' token
make[3]: *** [str.lo] Error 1
make[3]: Leaving directory `/usr/src/packages/BUILD/open-vm-tools-2008.03.19-82724/lib/string/shared'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/packages/BUILD/open-vm-tools-2008.03.19-82724/lib/string'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/packages/BUILD/open-vm-tools-2008.03.19-82724/lib'
make: *** [all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.60982 (%build)


line 46 in str.c is
#ifndef _WIN32
extern int vasprintf(char **ptr, const char *f, va_list arg);
>> extern int vswprintf(wchar_t *wcs, size_t maxlen, const wchar_t *format, va_list args);
#endif

If there's anything else I can provide, please let me know. 

----------------------------------------------------------------------

>Comment By: Adar Dembo (adembo)
Date: 2008-09-03 12:32

Message:
Logged In: YES 
user_id=1867590
Originator: NO

The patch was committed, though Ryan took a different approach in the
final patch than in the patch he posted in this bug report. Here's his
changeset description (we use Perforce internally):

Avoid clashing w/ glibc's vswprintf macro when _FORTIFY_SOURCE is used.

When compiling with _FORTIFY_SOURCE > 0, glibc header files define
vswprintf as a macro which makes use of a buffer overflow wrapper.
This clashes with our str.c where, in the non-Windows case, we declare
`extern int vswprintf...'

This change attempts to fix this by not declaring vswprintf on platforms
where it's known to already exist (glibc >= 2.2, FreeBSD >= 5.0, all
supported versions of Solaris.)

This addresses Open VM Tools / Sourceforge Tracker no. 1925183.



Does the modified patch not address the problem? If so, could you reopen
this bug report?

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-09-03 12:22

Message:
Logged In: YES 
user_id=263934
Originator: YES

The patch apparently is still not included in the current code release
(2008-09-03).

I still have it in my build system, thus I can deploy the packages... but
I think it would be good to bring that patch in the official source tree as
well?

----------------------------------------------------------------------

Comment By: ECL (sopwith)
Date: 2008-06-27 18:03

Message:
Logged In: YES 
user_id=18318
Originator: NO

Fixed according to Dominique.

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-05-06 23:23

Message:
Logged In: YES 
user_id=263934
Originator: YES

I can confirm: for the SUSE / openSUSE Build System, this patch solved the
compile errors.

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-05-06 21:36

Message:
Logged In: YES 
user_id=263934
Originator: YES

Ryan,

thank you very much. I added the patch and built (so far only one for
testing) run and it seems to pass. I submitted it to the build system to
get all packages built.

I'll be able to tell later today if this worked entirely.

THANK YOU

----------------------------------------------------------------------

Comment By: Ryan Beasley (rbeasley)
Date: 2008-05-06 13:38

Message:
Logged In: YES 
user_id=2047681
Originator: NO

Hi, Dominique & Justin.

Attached is a patch which I think will solve this problem for you.

Please let us know if you need additional instructions, or if you
encounter further problems.

  - Ryan
File Added: ovt_lib_string_str_c.patch

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-05-06 03:48

Message:
Logged In: YES 
user_id=263934
Originator: YES

just as info: with open-vm-tools 2008.05.02, the error is still happening.

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-03-25 07:08

Message:
Logged In: YES 
user_id=263934
Originator: YES

File Added: config.log

----------------------------------------------------------------------

Comment By: Justin M. Forbes (jmforbes)
Date: 2008-03-25 07:05

Message:
Logged In: YES 
user_id=1399676
Originator: NO

We are seeing the same at rPath on both rPL1 and rPL2.  rPL2 is using
glibc from RHEL 5 sources.  I have not had time to debug just yet.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1925183&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2071988 ] Module vmci does not compile

[SourceForge.net <no...@so...>]

Tracker item #2071988, was opened at 2008-08-24 11:22
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071988&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Module vmci does not compile

Initial Comment:
Im trying to spin up new rpms for open-vm-tools (opensuse).

The configure uses --without-kernel-modules (as the build actually happens in a controlled virtual environment, not running the target kernel).

the modules themself are after built using
  #make modules
  for module in %{vm_modules}; do
    pushd modules/linux/$module
    make -C /usr/src/linux-obj/%{_target_cpu}/$flavor modules M=$PWD VM_CCVER=$(gcc -dumpversion) SRCROOT=$PWD
    popd
  done

vm_modules contains a list of modules to be built: "vmblock vmhgfs ... vmci"

this works (and did for long time now) for all modules, but on vmci it fails with the following errors:

+ for module in vmblock vmhgfs vmmemctl vmsync vmxnet vsock vmci
+ pushd modules/linux/vmci
/usr/src/packages/BUILD/obj/debug/modules/linux/vmci /usr/src/packages/BUILD/obj/debug /usr/src/packages/BUILD
++ gcc -dumpversion
+ make -C /usr/src/linux-obj/i586/debug modules M=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci VM_CCVER=4.3 SRCROOT=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci
make: Entering directory `/usr/src/linux-2.6.27-rc3-2-obj/i386/debug'
make -C ../../../linux-2.6.27-rc3-2 O=/usr/src/linux-2.6.27-rc3-2-obj/i386/debug/. modules
Using standalone build system.
/usr/src/packages/BUILD/obj/debug/modules/linux/vmci/autoconf/geninclude.c:19:28: error: linux/autoconf.h: No such file or directory
/usr/src/linux-2.6.27-rc3-2/scripts/Makefile.build:46: *** CFLAGS was changed in "/usr/src/packages/BUILD/obj/debug/modules/linux/vmci/Makefile". Fix it to use EXTRA_CFLAGS.  Stop.
make[2]: *** [_module_/usr/src/packages/BUILD/obj/debug/modules/linux/vmci] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
make: Leaving directory `/usr/src/linux-2.6.27-rc3-2-obj/i386/debug'
error: Bad exit status from /var/tmp/rpm-tmp.23557 (%build)

I would anticipate if somebody could have a look into this. Most likely a small thing which I miss. The Makefile seems to be an exact copy of the one from vmxnet, except to the drivers name... so I really miss something.

Thank you

----------------------------------------------------------------------

>Comment By: Adar Dembo (adembo)
Date: 2008-09-03 12:25

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Glad to hear you were able to resolve the problem.

As for your patch, I'm surprised you need it at all. Couldn't you just
overload HEADER_DIR on the command line? That's what I do when I want to
build against the mainline git repo: "make
HEADER_DIR=/usr/src/git/linux-2.6/include"


----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-09-03 12:20

Message:
Logged In: YES 
user_id=263934
Originator: YES

Found it...

Forgot that I have a patch for every single module Makefile in my
buildsystem. Had to add those new modules to the patch as well, and
everything is fine now.

I don't think the patch will get upstream, but for reference I attach it
hereto.

Feel free to use it or to dismiss this bug report.
Dominique
File Added: open-vm-tools-2008.09.03-kver.patch

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-08-25 01:12

Message:
Logged In: YES 
user_id=263934
Originator: YES

even having vmci built as the first (or only) module does not change
anything.

The problem seems to appear starting with kernel 2.6.25 (as I see the
module failing on openSUSE 11.0 and openSUSE_Factory).

Still, surprisingly, all other modules (except the newly added ones vmci
and vsock) 'know' that they are built in the kernel tree build system...
the new ones report to be built standalone.

To reproduce (take a kernel 2.6.27-rc3):
./configure --without-kernel-modules
cd modules/linux/vmci
make -C /usr/src/linux-obj/i586/debug modules
M=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci VM_CCVER=4.3
SRCROOT=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci

(with adjusted paths of course).

and in my case, this always reports using standalone build system, which
in fact is not true... this way, it should recognize the kernel 2.6 build
system.

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-08-25 00:29

Message:
Logged In: YES 
user_id=263934
Originator: YES

I'm not using the GIT tree. For the RPMs, I always use the officially
released tarballs (so in tis case 2008-08-08).

- File permissions are as in the tarball... will have to check further
wether there is a problem or not
- Environment: the script goes through a FOR loop, compiling all the
different modules. I can try to adjust the order of them, in case this
should matter. But this would be weird.

The kernel tree is sane (all modules are built against this tree, of the
entire distribution... and the problem does not only happen in one version
of the distro... so assuming that all the trees are broken sounds rude
against the distro maintainers (I know you did not mean it like that... )

So I'll change the order of the modules, having vsock and vmci before the
others... let's see what happens... I'll report back later today).

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-24 23:40

Message:
Logged In: YES 
user_id=1867590
Originator: NO

I really don't know what the problem might be. As you said, the Makefiles
are virtually identical: the only difference being the name of the driver.

Could you do some basic sanity checks:
- Make sure you haven't modified files in git, and that git's view of the
source is healthy (assuming you're using git).
- Make sure the file permissions are correct.
- Make sure you haven't set any environment variables that might affect
things.
- Make sure your kernel tree is sane.

When exactly did this start? With 2008.08.08? Or some time later?

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-08-24 11:35

Message:
Logged In: YES 
user_id=263934
Originator: YES

compared to the compilation of vmxnet, the following line is different:

vmxnet: Using 2.6.x kernel build system.    

vmci (and also vsock): Using standalone build system.

Maybe it helps.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071988&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-1925183 ] building on openSUSE fails

[SourceForge.net <no...@so...>]

Tracker item #1925183, was opened at 2008-03-25 14:50
Message generated for change (Comment added) made by dimstar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1925183&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libraries
Group: None
>Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: building on openSUSE fails

Initial Comment:
Building open-vm-tools on openSUSE up to 10.3 fails for some reasons.

./configure passes correctly, but make afterwards fails with:

 gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"2008.03.19-82724\" "-DPACKAGE_STRING=\"open-vm-tools 2008.03.19-82724\"" -DPACKAGE_BUGREPORT=\"ope...@li...\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"2008.03.19-82724\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DNO_DNET=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LSEEK=1 -I. -Wall -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -DVMX86_TOOLS -I
 /usr/src/packages/BUILD/open-vm-tools-2008.03.19-82724/lib/include -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -DGLIBC_VERSION_22 -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -DUSING_AUTOCONF=1 -MT str.lo -MD -MP -MF .deps/str.Tpo -c ../str.c -fPIC -DPIC -o .libs/str.o
../str.c:46: error: expected declaration specifiers or '...' before numeric constant
../str.c:46: error: expected ')' before '!=' token
make[3]: *** [str.lo] Error 1
make[3]: Leaving directory `/usr/src/packages/BUILD/open-vm-tools-2008.03.19-82724/lib/string/shared'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/packages/BUILD/open-vm-tools-2008.03.19-82724/lib/string'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/packages/BUILD/open-vm-tools-2008.03.19-82724/lib'
make: *** [all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.60982 (%build)


line 46 in str.c is
#ifndef _WIN32
extern int vasprintf(char **ptr, const char *f, va_list arg);
>> extern int vswprintf(wchar_t *wcs, size_t maxlen, const wchar_t *format, va_list args);
#endif

If there's anything else I can provide, please let me know. 

----------------------------------------------------------------------

>Comment By: Dominique Leuenberger (dimstar)
Date: 2008-09-03 21:22

Message:
Logged In: YES 
user_id=263934
Originator: YES

The patch apparently is still not included in the current code release
(2008-09-03).

I still have it in my build system, thus I can deploy the packages... but
I think it would be good to bring that patch in the official source tree as
well?

----------------------------------------------------------------------

Comment By: ECL (sopwith)
Date: 2008-06-28 03:03

Message:
Logged In: YES 
user_id=18318
Originator: NO

Fixed according to Dominique.

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-05-07 08:23

Message:
Logged In: YES 
user_id=263934
Originator: YES

I can confirm: for the SUSE / openSUSE Build System, this patch solved the
compile errors.

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-05-07 06:36

Message:
Logged In: YES 
user_id=263934
Originator: YES

Ryan,

thank you very much. I added the patch and built (so far only one for
testing) run and it seems to pass. I submitted it to the build system to
get all packages built.

I'll be able to tell later today if this worked entirely.

THANK YOU

----------------------------------------------------------------------

Comment By: Ryan Beasley (rbeasley)
Date: 2008-05-06 22:38

Message:
Logged In: YES 
user_id=2047681
Originator: NO

Hi, Dominique & Justin.

Attached is a patch which I think will solve this problem for you.

Please let us know if you need additional instructions, or if you
encounter further problems.

  - Ryan
File Added: ovt_lib_string_str_c.patch

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-05-06 12:48

Message:
Logged In: YES 
user_id=263934
Originator: YES

just as info: with open-vm-tools 2008.05.02, the error is still happening.

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-03-25 15:08

Message:
Logged In: YES 
user_id=263934
Originator: YES

File Added: config.log

----------------------------------------------------------------------

Comment By: Justin M. Forbes (jmforbes)
Date: 2008-03-25 15:05

Message:
Logged In: YES 
user_id=1399676
Originator: NO

We are seeing the same at rPath on both rPL1 and rPL2.  rPL2 is using
glibc from RHEL 5 sources.  I have not had time to debug just yet.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1925183&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2071988 ] Module vmci does not compile

[SourceForge.net <no...@so...>]

Tracker item #2071988, was opened at 2008-08-24 20:22
Message generated for change (Comment added) made by dimstar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071988&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Module vmci does not compile

Initial Comment:
Im trying to spin up new rpms for open-vm-tools (opensuse).

The configure uses --without-kernel-modules (as the build actually happens in a controlled virtual environment, not running the target kernel).

the modules themself are after built using
  #make modules
  for module in %{vm_modules}; do
    pushd modules/linux/$module
    make -C /usr/src/linux-obj/%{_target_cpu}/$flavor modules M=$PWD VM_CCVER=$(gcc -dumpversion) SRCROOT=$PWD
    popd
  done

vm_modules contains a list of modules to be built: "vmblock vmhgfs ... vmci"

this works (and did for long time now) for all modules, but on vmci it fails with the following errors:

+ for module in vmblock vmhgfs vmmemctl vmsync vmxnet vsock vmci
+ pushd modules/linux/vmci
/usr/src/packages/BUILD/obj/debug/modules/linux/vmci /usr/src/packages/BUILD/obj/debug /usr/src/packages/BUILD
++ gcc -dumpversion
+ make -C /usr/src/linux-obj/i586/debug modules M=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci VM_CCVER=4.3 SRCROOT=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci
make: Entering directory `/usr/src/linux-2.6.27-rc3-2-obj/i386/debug'
make -C ../../../linux-2.6.27-rc3-2 O=/usr/src/linux-2.6.27-rc3-2-obj/i386/debug/. modules
Using standalone build system.
/usr/src/packages/BUILD/obj/debug/modules/linux/vmci/autoconf/geninclude.c:19:28: error: linux/autoconf.h: No such file or directory
/usr/src/linux-2.6.27-rc3-2/scripts/Makefile.build:46: *** CFLAGS was changed in "/usr/src/packages/BUILD/obj/debug/modules/linux/vmci/Makefile". Fix it to use EXTRA_CFLAGS.  Stop.
make[2]: *** [_module_/usr/src/packages/BUILD/obj/debug/modules/linux/vmci] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
make: Leaving directory `/usr/src/linux-2.6.27-rc3-2-obj/i386/debug'
error: Bad exit status from /var/tmp/rpm-tmp.23557 (%build)

I would anticipate if somebody could have a look into this. Most likely a small thing which I miss. The Makefile seems to be an exact copy of the one from vmxnet, except to the drivers name... so I really miss something.

Thank you

----------------------------------------------------------------------

>Comment By: Dominique Leuenberger (dimstar)
Date: 2008-09-03 21:20

Message:
Logged In: YES 
user_id=263934
Originator: YES

Found it...

Forgot that I have a patch for every single module Makefile in my
buildsystem. Had to add those new modules to the patch as well, and
everything is fine now.

I don't think the patch will get upstream, but for reference I attach it
hereto.

Feel free to use it or to dismiss this bug report.
Dominique
File Added: open-vm-tools-2008.09.03-kver.patch

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-08-25 10:12

Message:
Logged In: YES 
user_id=263934
Originator: YES

even having vmci built as the first (or only) module does not change
anything.

The problem seems to appear starting with kernel 2.6.25 (as I see the
module failing on openSUSE 11.0 and openSUSE_Factory).

Still, surprisingly, all other modules (except the newly added ones vmci
and vsock) 'know' that they are built in the kernel tree build system...
the new ones report to be built standalone.

To reproduce (take a kernel 2.6.27-rc3):
./configure --without-kernel-modules
cd modules/linux/vmci
make -C /usr/src/linux-obj/i586/debug modules
M=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci VM_CCVER=4.3
SRCROOT=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci

(with adjusted paths of course).

and in my case, this always reports using standalone build system, which
in fact is not true... this way, it should recognize the kernel 2.6 build
system.

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-08-25 09:29

Message:
Logged In: YES 
user_id=263934
Originator: YES

I'm not using the GIT tree. For the RPMs, I always use the officially
released tarballs (so in tis case 2008-08-08).

- File permissions are as in the tarball... will have to check further
wether there is a problem or not
- Environment: the script goes through a FOR loop, compiling all the
different modules. I can try to adjust the order of them, in case this
should matter. But this would be weird.

The kernel tree is sane (all modules are built against this tree, of the
entire distribution... and the problem does not only happen in one version
of the distro... so assuming that all the trees are broken sounds rude
against the distro maintainers (I know you did not mean it like that... )

So I'll change the order of the modules, having vsock and vmci before the
others... let's see what happens... I'll report back later today).

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-25 08:40

Message:
Logged In: YES 
user_id=1867590
Originator: NO

I really don't know what the problem might be. As you said, the Makefiles
are virtually identical: the only difference being the name of the driver.

Could you do some basic sanity checks:
- Make sure you haven't modified files in git, and that git's view of the
source is healthy (assuming you're using git).
- Make sure the file permissions are correct.
- Make sure you haven't set any environment variables that might affect
things.
- Make sure your kernel tree is sane.

When exactly did this start? With 2008.08.08? Or some time later?

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-08-24 20:35

Message:
Logged In: YES 
user_id=263934
Originator: YES

compared to the compilation of vmxnet, the following line is different:

vmxnet: Using 2.6.x kernel build system.    

vmci (and also vsock): Using standalone build system.

Maybe it helps.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071988&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2046262 ] open-vm-tools-2008.08.08-109361 fails to configure

[SourceForge.net <no...@so...>]

Tracker item #2046262, was opened at 2008-08-11 03:45
Message generated for change (Settings changed) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2046262&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Timo Gurr (tgurr)
Assigned to: Nobody/Anonymous (nobody)
Summary: open-vm-tools-2008.08.08-109361 fails to configure

Initial Comment:
When performing ./configure it bails out with following error message:

checking for GCC flag -Wno-pointer-sign... yes
checking for GCC flag -Wno-unused-value... yes
checking for GCC flag -fno-strict-aliasing... yes
checking for GCC flag -Wno-unknown-pragmas... yes
checking for GCC flag -Wno-uninitialized... yes
configure: error: conditional "am__fastdepCXX" was never defined.
Usually this means the macro was only invoked conditionally.

Using:
gcc-4.3.1
automake-1.10.1

Attached patch fixes the issue for me.

----------------------------------------------------------------------

Comment By: Timo Gurr (tgurr)
Date: 2008-08-13 03:01

Message:
Logged In: YES 
user_id=1687320
Originator: YES

Worked perfectly, just had to create the missing m4 directory. Thanks for
looking into this, greatly appreciated!

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-13 00:03

Message:
Logged In: YES 
user_id=1867590
Originator: NO

File Added: configure.ac.patch

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-13 00:02

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Alright, I've spent a while looking at this and I think I have it figured
out. The reason this problem manifests itself only when you run autoreconf
is because you probably have libtool-2.2 installed in your system.
Internally we build the configure script using libtool-1.5.22, and when I
changed our build to use libtool-2.2, I also saw the same errors.

So I've gone ahead and done three things:
- I've upgraded our internal compile test infrastructure to use
libtool-2.2 instead of libtool-1.5.22, because it fixes a few other issues
and is more cutting edge. This necessitated a few other changes to
configure.ac (which you'll see in the patch I'm uploading).
- I've also made the AC_PROG_CXX check unconditional as you did in your
patch. I looked at how autoconf implements the AC_PROG_CXX macro and saw
that unlike AC_PROG_CC, it does _not_ throw an error if the compiler isn't
found. So it should be safe to have everyone use AC_PROG_CXX, even if they
aren't using libicu.
- To make sure that we actually do have a C++ compiler, I added a call to
AC_CHECK_TOOL on CXX in the case where we're using libicu.

Here's the patch; you'll need to use autoreconf because I'm too lazy to
generate diffs on configure and all the Makefile.in files. Let me know if
it solves the problem.
File Added: Makefile.am.patch

----------------------------------------------------------------------

Comment By: Timo Gurr (tgurr)
Date: 2008-08-12 02:34

Message:
Logged In: YES 
user_id=1687320
Originator: YES

Tarball, because the file was too big to attach in plain/text.
File Added: configure.fail.tar.bz2

----------------------------------------------------------------------

Comment By: Timo Gurr (tgurr)
Date: 2008-08-12 02:29

Message:
Logged In: YES 
user_id=1687320
Originator: YES

File Added: build.log

----------------------------------------------------------------------

Comment By: Timo Gurr (tgurr)
Date: 2008-08-12 02:28

Message:
Logged In: YES 
user_id=1687320
Originator: YES

Attached is my config.log. After reading your comment I also found out
that if I don't force the rebuild of the of the autotools scripts it works
like in your case, I'm also attaching my full build.log and configure.fail
(the autoconf 2.62 regenerated configure script).
File Added: config.log

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-11 12:38

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Hmm, I don't think that patch is correct. If you look further into
configure.ac you'll see that AC_PROG_CXX is already invoked in the case
where icu is enabled. If icu is disabled (which it is in your case) we
shouldn't need the C++ compiler/linker, and so we shouldn't require it for
all open-vm-tools builds. That's why it's surprising to see this failure. 

When I run your ./configure line locally (after removing my /usr/bin/g++
symlink) I don't see this problem. Could you share your config.log file? Is
anyone else experiencing this bug?

----------------------------------------------------------------------

Comment By: Timo Gurr (tgurr)
Date: 2008-08-11 04:01

Message:
Logged In: YES 
user_id=1687320
Originator: YES

Forgot the most important, following ./configure parameters were given:

./configure --prefix=/usr --host=x86_64-pc-linux-gnu
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--sysconfdir=/etc --localstatedir=/var/lib --without-kernel-modules
--without-icu --without-x --disable-multimon --libdir=/usr/lib64
--build=x86_64-pc-linux-gnu

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2046262&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2048423 ] Build fails on Fedora 9 and Ubuntu Intrepid Ibex

[SourceForge.net <no...@so...>]

Tracker item #2048423, was opened at 2008-08-12 12:35
Message generated for change (Settings changed) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2048423&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nathan Charles (travalas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build fails on Fedora 9 and Ubuntu Intrepid Ibex

Initial Comment:
configure options:  --without-unity (because uri is backlevel i think)



gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"2008.08.08-109361\" -DPACKAGE_STRING=\"open-vm-tools\ 2008.08.08-109361\" -DPACKAGE_BUGREPORT=\"ope...@li...\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"2008.08.08-109361\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LSEEK=1 -I.   -DUSING_AUTOCONF=1  -D_REENTRANT -I/usr/include -DUSE_ICU -DHAVE_ICU_38 -DVMX86_TOOLS -DNO_CORE_ICU -I/home/nathan/open-vm-tools-2008.08.08-109361/lib/include -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -I/usr/local/include -I/usr/include -I../../include -g -O2 -Wall -Werror -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -MT guestInfoPosix.o -MD -MP -MF .deps/guestInfoPosix.Tpo -c -o guestInfoPosix.o guestInfoPosix.c
cc1: warnings being treated as errors
guestInfoPosix.c: In function ReadInterfaceDetails:
guestInfoPosix.c:203: error: format not a string literal and no format arguments
make[2]: *** [guestInfoPosix.o] Error 1
make[2]: Leaving directory `/home/nathan/open-vm-tools-2008.08.08-109361/lib/guestInfo'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/nathan/open-vm-tools-2008.08.08-109361/lib'
make: *** [all-recursive] Error 1



----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-17 21:32

Message:
Logged In: YES 
user_id=1867590
Originator: NO

I answered my own question: it is the only problem. The patch I wrote is
very similar to yours, but it also frees ctmp if Posix_RealPath succeeds
and if the second chdir fails. I've committed it to the git repository.
File Added: appUtilX11_new.patch

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-17 20:40

Message:
Logged In: YES 
user_id=1867590
Originator: NO

You're right; I didn't try building with Unity enabled because the
uriparser in Intrepid is still too old. Was this the only problem?

I'll build uriparser from source, do a full build of open-vm-tools on
Intrepid with Unity, and post something comprehensive.

----------------------------------------------------------------------

Comment By: Nathan Charles (travalas)
Date: 2008-08-15 19:36

Message:
Logged In: YES 
user_id=2178601
Originator: YES

I think if you build with unity you also need to do something like in
appUtilX11.patch
File Added: appUtilX11.patch

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-15 16:04

Message:
Logged In: YES 
user_id=1867590
Originator: NO

I made a mistake in intrepid.patch. Here's another patch that you should
apply on top to get the correct runtime behavior (the original patch
compiles successfully).

Both patches were committed to the git repository.
File Added: intrepid2.patch

----------------------------------------------------------------------

Comment By: Nathan Charles (travalas)
Date: 2008-08-15 09:47

Message:
Logged In: YES 
user_id=2178601
Originator: YES

Yep looks good. Thanks!

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-14 22:25

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Here, give these patches a shot. If it works, I'll put it in the next code
refresh.
File Added: intrepid.patch

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-14 19:41

Message:
Logged In: YES 
user_id=1867590
Originator: NO

For what it's worth, I built an Intrepid VM, ran through the open-vm-tools
compilation, and fixed all the errors. I'll post the patches later.

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-13 11:35

Message:
Logged In: YES 
user_id=1867590
Originator: NO

It seems sane to me. Posix_Printf is intended to wrap the standard printf
function such that you can pass a set of UTF-8 encoded formatted arguments
into it (the ConstUnicode type is intended to represent UTF-8 encoded
strings), and it will firstly convert those arguments to a single string
encoded in the process's current encoding and secondly call the regular
printf on it.

The problem appears to be that printf is being called directly on a
string, which can actually lead to formatting string vulnerabilities (and
it appears that the compiler is sensitive to such vulnerabilities now). The
fix would be to change the printf(outCurr) call to printf("%s", outCurr).

As I said in an earlier comment, I'm going to hold off generating a patch
for this so that I can do something more comprehensive for Intrepid. If you
feel up to the task, feel free to patch these problems and I'll commit your
patches, provided you can sign the open-vm-tools contribution agreement.

----------------------------------------------------------------------

Comment By: Nathan Charles (travalas)
Date: 2008-08-13 07:12

Message:
Logged In: YES 
user_id=2178601
Originator: YES

Yes I am using the git repository.  

I applied that patch, but it still blows up.

cc1: warnings being treated as errors
../posixPosix.c: In function 'Posix_Printf':
../posixPosix.c:2984: error: format not a string literal and no format
arguments

I'm trying to get better at C and I was curious is that Posix_Printf
function really doing what it says it's doing?  BTW Thanks for your help in
this!


----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-13 00:27

Message:
Logged In: YES 
user_id=1867590
Originator: NO

You're using the git repository, right?

Some of our modules ship our real includeCheck.h file while others simply
touch an empty version of that file at build-time (there's no good reason
for this inconsistency). Looks like vsock is the latter, and although
includeCheck.h exists in the tarball I uploaded to SF, when I patched the
git repository it dropped the file, presumably because it was empty.

I recreated the empty file, and it seems to have worked this time.

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-13 00:09

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Alright, here's the patch for guestInfoPerfMonLinux.c.

If there's another such issue (and I imagine there is, if the compiler
flags on Intrepid now warn about not checking certain return values), I'll
stop generating one-off patches, build an Intrepid VM, get the
open-vm-tools building in it, and publish something more comprehensive.
File Added: guestInfoPerfMonLinux.c.patch

----------------------------------------------------------------------

Comment By: Nathan Charles (travalas)
Date: 2008-08-12 19:33

Message:
Logged In: YES 
user_id=2178601
Originator: YES

on Fedora 9 
it borks with 
  CC [M] 
/home/nathan/code/open-vm-tools/modules/linux/vsock/linux/af_vsock.o
In file included from
/home/nathan/code/open-vm-tools/modules/linux/vsock/linux/af_vsock.c:95:
/home/nathan/code/open-vm-tools/modules/linux/vsock/./include/driver-config.h:33:26:
error: includeCheck.h: No such file or directory

copying lib/include/includeCheck.h does let it build


----------------------------------------------------------------------

Comment By: Nathan Charles (travalas)
Date: 2008-08-12 18:57

Message:
Logged In: YES 
user_id=2178601
Originator: YES

looks like that causes it to blow up in a different way on ubuntu, 
haven't tried it on fedora 9 yet.

cc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\"
-DPACKAGE_VERSION=\"2008.08.08-109361\" -DPACKAGE_STRING=\"open-vm-tools\
2008.08.08-109361\"
-DPACKAGE_BUGREPORT=\"ope...@li...\"
-DPACKAGE=\"open-vm-tools\" -DVERSION=\"2008.08.08-109361\"
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_ECVT=1
-DHAVE_FCVT=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1
-DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1
-DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1
-DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LSEEK=1 -I.  
-DUSING_AUTOCONF=1  -D_REENTRANT -I/usr/include -DUSE_ICU -DHAVE_ICU_38
-DVMX86_TOOLS -DNO_CORE_ICU -I/home/nathan/code/open-vm-tools/lib/include
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500
-D_BSD_SOURCE -D_SVID_SOURCE -I/usr/local/include -I/usr/include
-I../../include -g -O2 -Wall -Werror -Wno-pointer-sign -Wno-unused-value
-fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -MT
guestInfoPerfMonLinux.o -MD -MP -MF .deps/guestInfoPerfMonLinux.Tpo -c -o
guestInfoPerfMonLinux.o guestInfoPerfMonLinux.c
cc1: warnings being treated as errors
guestInfoPerfMonLinux.c: In function GuestInfoMonitorReadMeminfo:
guestInfoPerfMonLinux.c:183: error: ignoring return value of fscanf,
declared with attribute warn_unused_result
make[2]: *** [guestInfoPerfMonLinux.o] Error 1
make[2]: Leaving directory
`/home/nathan/code/open-vm-tools/lib/guestInfo'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/nathan/code/open-vm-tools/lib'
make: *** [all-recursive] Error 1

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-12 18:14

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Whoops, looks like I accidentally changed the summary back.

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-12 18:13

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Doesn't look like this is a regression; that call to Str_Sprintf has been
there for some time.

In any case, does this patch fix the problem for you?

File Added: a.diff

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2048423&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2071170 ] asm/semaphore.h no longer exists in kernel tree

[SourceForge.net <no...@so...>]

Tracker item #2071170, was opened at 2008-08-24 02:24
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071170&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: kernel modules
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: asm/semaphore.h no longer exists in kernel tree

Initial Comment:
Hello,

Due to some changes in the kernel tree, asm/semaphore.h does no longer exist.

This currently stops from compiling open-vm-tools (module vmhgfs)

When I find some time, I'll try to prepare a patch (it would be a simple one, as it most likely only has to be changed to linux/semaphore.h, but the complexity will be not breaking the old kernel compatibility.. like always :) )

If you happen to already have a fix for this, please let me know.. so we do not double-invest time on it.

(last version I tested was open-vm-tools 2008-08-08 against kernel 2.6.27-rc3)

----------------------------------------------------------------------

>Comment By: Adar Dembo (adembo)
Date: 2008-09-03 01:55

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Resolved in latest code refresh.

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-08-24 11:03

Message:
Logged In: YES 
user_id=263934
Originator: YES

Thank you very much Adar, this patch did the job and also did not break
compilation on the older platforms.
I added it to the spec file for the moment and will remove it again with
the next refresh.


----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-24 03:48

Message:
Logged In: YES 
user_id=1867590
Originator: NO

I'm not able to attach the patch to this bug report for some reason. I've
added it to the "Development Snapshots" section of the download area.
Here's a direct link:
http://downloads.sourceforge.net/open-vm-tools/open-vm-tools-2008.08.08-2.6.27.kernels.patch

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-24 03:41

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Having some problems uploading the file; hopefully compressing it will
help.

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-24 03:39

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Yeah, don't bother putting together a patch, we've already got something
in-tree. Try this out; it'll be in the next code refresh.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071170&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2064471 ] FEATURE:control vm recording by toolbox

[SourceForge.net <no...@so...>]

Tracker item #2064471, was opened at 2008-08-21 03:41
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: toolbox
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ven (ven9)
Assigned to: Nobody/Anonymous (nobody)
Summary: FEATURE:control vm recording by toolbox

Initial Comment:
A patch that affects both vmware-toolbox and vmware-toolbox-cmd, adding start/stop recording functionalities for them. It adds a new GuestApp routine, through vmware backdoor, to do it, a new panel for toolbox and a new command for toolbox-cmd as UI.
This patch is based on 2008.08.08 release. I have already posted a version in devel mailing list, now I submit to tracker for simpler tracking.
Thanks to Adar's review. More comments are welcomed.

----------------------------------------------------------------------

>Comment By: Adar Dembo (adembo)
Date: 2008-09-03 00:02

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Looks good, just two more requests out of me:
- "proccess" --> "process" in GuestApp_ControlRecord.
- I'm attaching statelogger_backdoor_def.h which contains a very
rudimentary record of this backdoor protocol. Could you incorporate it into
your patch, using its macros where appropriate?
File Added: statelogger_backdoor_def.h

----------------------------------------------------------------------

Comment By: ven (ven9)
Date: 2008-09-01 02:58

Message:
Logged In: YES 
user_id=2082796
Originator: YES

Any comments?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2064471 ] FEATURE:control vm recording by toolbox

[SourceForge.net <no...@so...>]

Tracker item #2064471, was opened at 2008-08-21 18:41
Message generated for change (Comment added) made by ven9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: toolbox
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ven (ven9)
Assigned to: Nobody/Anonymous (nobody)
Summary: FEATURE:control vm recording by toolbox

Initial Comment:
A patch that affects both vmware-toolbox and vmware-toolbox-cmd, adding start/stop recording functionalities for them. It adds a new GuestApp routine, through vmware backdoor, to do it, a new panel for toolbox and a new command for toolbox-cmd as UI.
This patch is based on 2008.08.08 release. I have already posted a version in devel mailing list, now I submit to tracker for simpler tracking.
Thanks to Adar's review. More comments are welcomed.

----------------------------------------------------------------------

>Comment By: ven (ven9)
Date: 2008-09-01 17:58

Message:
Logged In: YES 
user_id=2082796
Originator: YES

Any comments?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2071988 ] Module vmci does not compile

[SourceForge.net <no...@so...>]

Tracker item #2071988, was opened at 2008-08-24 20:22
Message generated for change (Comment added) made by dimstar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071988&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Module vmci does not compile

Initial Comment:
Im trying to spin up new rpms for open-vm-tools (opensuse).

The configure uses --without-kernel-modules (as the build actually happens in a controlled virtual environment, not running the target kernel).

the modules themself are after built using
  #make modules
  for module in %{vm_modules}; do
    pushd modules/linux/$module
    make -C /usr/src/linux-obj/%{_target_cpu}/$flavor modules M=$PWD VM_CCVER=$(gcc -dumpversion) SRCROOT=$PWD
    popd
  done

vm_modules contains a list of modules to be built: "vmblock vmhgfs ... vmci"

this works (and did for long time now) for all modules, but on vmci it fails with the following errors:

+ for module in vmblock vmhgfs vmmemctl vmsync vmxnet vsock vmci
+ pushd modules/linux/vmci
/usr/src/packages/BUILD/obj/debug/modules/linux/vmci /usr/src/packages/BUILD/obj/debug /usr/src/packages/BUILD
++ gcc -dumpversion
+ make -C /usr/src/linux-obj/i586/debug modules M=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci VM_CCVER=4.3 SRCROOT=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci
make: Entering directory `/usr/src/linux-2.6.27-rc3-2-obj/i386/debug'
make -C ../../../linux-2.6.27-rc3-2 O=/usr/src/linux-2.6.27-rc3-2-obj/i386/debug/. modules
Using standalone build system.
/usr/src/packages/BUILD/obj/debug/modules/linux/vmci/autoconf/geninclude.c:19:28: error: linux/autoconf.h: No such file or directory
/usr/src/linux-2.6.27-rc3-2/scripts/Makefile.build:46: *** CFLAGS was changed in "/usr/src/packages/BUILD/obj/debug/modules/linux/vmci/Makefile". Fix it to use EXTRA_CFLAGS.  Stop.
make[2]: *** [_module_/usr/src/packages/BUILD/obj/debug/modules/linux/vmci] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
make: Leaving directory `/usr/src/linux-2.6.27-rc3-2-obj/i386/debug'
error: Bad exit status from /var/tmp/rpm-tmp.23557 (%build)

I would anticipate if somebody could have a look into this. Most likely a small thing which I miss. The Makefile seems to be an exact copy of the one from vmxnet, except to the drivers name... so I really miss something.

Thank you

----------------------------------------------------------------------

>Comment By: Dominique Leuenberger (dimstar)
Date: 2008-08-25 10:12

Message:
Logged In: YES 
user_id=263934
Originator: YES

even having vmci built as the first (or only) module does not change
anything.

The problem seems to appear starting with kernel 2.6.25 (as I see the
module failing on openSUSE 11.0 and openSUSE_Factory).

Still, surprisingly, all other modules (except the newly added ones vmci
and vsock) 'know' that they are built in the kernel tree build system...
the new ones report to be built standalone.

To reproduce (take a kernel 2.6.27-rc3):
./configure --without-kernel-modules
cd modules/linux/vmci
make -C /usr/src/linux-obj/i586/debug modules
M=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci VM_CCVER=4.3
SRCROOT=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci

(with adjusted paths of course).

and in my case, this always reports using standalone build system, which
in fact is not true... this way, it should recognize the kernel 2.6 build
system.

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-08-25 09:29

Message:
Logged In: YES 
user_id=263934
Originator: YES

I'm not using the GIT tree. For the RPMs, I always use the officially
released tarballs (so in tis case 2008-08-08).

- File permissions are as in the tarball... will have to check further
wether there is a problem or not
- Environment: the script goes through a FOR loop, compiling all the
different modules. I can try to adjust the order of them, in case this
should matter. But this would be weird.

The kernel tree is sane (all modules are built against this tree, of the
entire distribution... and the problem does not only happen in one version
of the distro... so assuming that all the trees are broken sounds rude
against the distro maintainers (I know you did not mean it like that... )

So I'll change the order of the modules, having vsock and vmci before the
others... let's see what happens... I'll report back later today).

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-25 08:40

Message:
Logged In: YES 
user_id=1867590
Originator: NO

I really don't know what the problem might be. As you said, the Makefiles
are virtually identical: the only difference being the name of the driver.

Could you do some basic sanity checks:
- Make sure you haven't modified files in git, and that git's view of the
source is healthy (assuming you're using git).
- Make sure the file permissions are correct.
- Make sure you haven't set any environment variables that might affect
things.
- Make sure your kernel tree is sane.

When exactly did this start? With 2008.08.08? Or some time later?

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-08-24 20:35

Message:
Logged In: YES 
user_id=263934
Originator: YES

compared to the compilation of vmxnet, the following line is different:

vmxnet: Using 2.6.x kernel build system.    

vmci (and also vsock): Using standalone build system.

Maybe it helps.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071988&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2071988 ] Module vmci does not compile

[SourceForge.net <no...@so...>]

Tracker item #2071988, was opened at 2008-08-24 20:22
Message generated for change (Comment added) made by dimstar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071988&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Module vmci does not compile

Initial Comment:
Im trying to spin up new rpms for open-vm-tools (opensuse).

The configure uses --without-kernel-modules (as the build actually happens in a controlled virtual environment, not running the target kernel).

the modules themself are after built using
  #make modules
  for module in %{vm_modules}; do
    pushd modules/linux/$module
    make -C /usr/src/linux-obj/%{_target_cpu}/$flavor modules M=$PWD VM_CCVER=$(gcc -dumpversion) SRCROOT=$PWD
    popd
  done

vm_modules contains a list of modules to be built: "vmblock vmhgfs ... vmci"

this works (and did for long time now) for all modules, but on vmci it fails with the following errors:

+ for module in vmblock vmhgfs vmmemctl vmsync vmxnet vsock vmci
+ pushd modules/linux/vmci
/usr/src/packages/BUILD/obj/debug/modules/linux/vmci /usr/src/packages/BUILD/obj/debug /usr/src/packages/BUILD
++ gcc -dumpversion
+ make -C /usr/src/linux-obj/i586/debug modules M=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci VM_CCVER=4.3 SRCROOT=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci
make: Entering directory `/usr/src/linux-2.6.27-rc3-2-obj/i386/debug'
make -C ../../../linux-2.6.27-rc3-2 O=/usr/src/linux-2.6.27-rc3-2-obj/i386/debug/. modules
Using standalone build system.
/usr/src/packages/BUILD/obj/debug/modules/linux/vmci/autoconf/geninclude.c:19:28: error: linux/autoconf.h: No such file or directory
/usr/src/linux-2.6.27-rc3-2/scripts/Makefile.build:46: *** CFLAGS was changed in "/usr/src/packages/BUILD/obj/debug/modules/linux/vmci/Makefile". Fix it to use EXTRA_CFLAGS.  Stop.
make[2]: *** [_module_/usr/src/packages/BUILD/obj/debug/modules/linux/vmci] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
make: Leaving directory `/usr/src/linux-2.6.27-rc3-2-obj/i386/debug'
error: Bad exit status from /var/tmp/rpm-tmp.23557 (%build)

I would anticipate if somebody could have a look into this. Most likely a small thing which I miss. The Makefile seems to be an exact copy of the one from vmxnet, except to the drivers name... so I really miss something.

Thank you

----------------------------------------------------------------------

>Comment By: Dominique Leuenberger (dimstar)
Date: 2008-08-25 09:29

Message:
Logged In: YES 
user_id=263934
Originator: YES

I'm not using the GIT tree. For the RPMs, I always use the officially
released tarballs (so in tis case 2008-08-08).

- File permissions are as in the tarball... will have to check further
wether there is a problem or not
- Environment: the script goes through a FOR loop, compiling all the
different modules. I can try to adjust the order of them, in case this
should matter. But this would be weird.

The kernel tree is sane (all modules are built against this tree, of the
entire distribution... and the problem does not only happen in one version
of the distro... so assuming that all the trees are broken sounds rude
against the distro maintainers (I know you did not mean it like that... )

So I'll change the order of the modules, having vsock and vmci before the
others... let's see what happens... I'll report back later today).

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-25 08:40

Message:
Logged In: YES 
user_id=1867590
Originator: NO

I really don't know what the problem might be. As you said, the Makefiles
are virtually identical: the only difference being the name of the driver.

Could you do some basic sanity checks:
- Make sure you haven't modified files in git, and that git's view of the
source is healthy (assuming you're using git).
- Make sure the file permissions are correct.
- Make sure you haven't set any environment variables that might affect
things.
- Make sure your kernel tree is sane.

When exactly did this start? With 2008.08.08? Or some time later?

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-08-24 20:35

Message:
Logged In: YES 
user_id=263934
Originator: YES

compared to the compilation of vmxnet, the following line is different:

vmxnet: Using 2.6.x kernel build system.    

vmci (and also vsock): Using standalone build system.

Maybe it helps.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071988&group_id=204462

[open-vm-tools-devel] A question on text transfer of copy and paste

[Yiwen Z. <zha...@gm...>]

    I used to think that the copy and paste feature makes the clipboard
buffer shared between host and guest. However, the source code and
experiment shows a different result.
    The code in vmware-user indicates that when I select some text in guest
os, it is instantly copied and sent to host os. My experiment confirms that.
The clipboard of host os (WinXP for me) is overwritten. However, before I
explicitily copy anything in guest, the clipboard of guest os remains
before.
    A detailed scenario is:
    1. I have a host and 2 guest a and b installed vmtools;
    2. Copy text A in host, so both a and b hold A in their clipboard;
    3. Select text B in guest a, then host holds B but a and b hold A;
    4. Copy B in guest a, then all hold B.
    My question is:
    1. When texts are sent to host, host's clipboard is refreshed, but
guest's is not. Why?
    2. Step 3 above seems to increase cost and inconsistency. What is the
purpose of such design?  I assume hooking another event is not much more
complicated.
    Thanks,

Yiwen

[open-vm-tools-devel] [ open-vm-tools-Tracker-2071988 ] Module vmci does not compile

[SourceForge.net <no...@so...>]

Tracker item #2071988, was opened at 2008-08-24 11:22
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071988&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Module vmci does not compile

Initial Comment:
Iäm trying to spin up new rpms for open-vm-tools (opensuse).

The configure uses --without-kernel-modules (as the build actually happens in a controlled virtual environment, not running the target kernel).

the modules themself are after built using
  #make modules
  for module in %{vm_modules}; do
    pushd modules/linux/$module
    make -C /usr/src/linux-obj/%{_target_cpu}/$flavor modules M=$PWD VM_CCVER=$(gcc -dumpversion) SRCROOT=$PWD
    popd
  done

vm_modules contains a list of modules to be built: "vmblock vmhgfs ... vmci"

this works (and did for long time now) for all modules, but on vmci it fails with the following errors:

+ for module in vmblock vmhgfs vmmemctl vmsync vmxnet vsock vmci
+ pushd modules/linux/vmci
/usr/src/packages/BUILD/obj/debug/modules/linux/vmci /usr/src/packages/BUILD/obj/debug /usr/src/packages/BUILD
++ gcc -dumpversion
+ make -C /usr/src/linux-obj/i586/debug modules M=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci VM_CCVER=4.3 SRCROOT=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci
make: Entering directory `/usr/src/linux-2.6.27-rc3-2-obj/i386/debug'
make -C ../../../linux-2.6.27-rc3-2 O=/usr/src/linux-2.6.27-rc3-2-obj/i386/debug/. modules
Using standalone build system.
/usr/src/packages/BUILD/obj/debug/modules/linux/vmci/autoconf/geninclude.c:19:28: error: linux/autoconf.h: No such file or directory
/usr/src/linux-2.6.27-rc3-2/scripts/Makefile.build:46: *** CFLAGS was changed in "/usr/src/packages/BUILD/obj/debug/modules/linux/vmci/Makefile". Fix it to use EXTRA_CFLAGS.  Stop.
make[2]: *** [_module_/usr/src/packages/BUILD/obj/debug/modules/linux/vmci] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
make: Leaving directory `/usr/src/linux-2.6.27-rc3-2-obj/i386/debug'
error: Bad exit status from /var/tmp/rpm-tmp.23557 (%build)

I would anticipate if somebody could have a look into this. Most likely a small thing which I miss. The Makefile seems to be an exact copy of the one from vmxnet, except to the drivers name... so I really miss something.

Thank you

----------------------------------------------------------------------

>Comment By: Adar Dembo (adembo)
Date: 2008-08-24 23:40

Message:
Logged In: YES 
user_id=1867590
Originator: NO

I really don't know what the problem might be. As you said, the Makefiles
are virtually identical: the only difference being the name of the driver.

Could you do some basic sanity checks:
- Make sure you haven't modified files in git, and that git's view of the
source is healthy (assuming you're using git).
- Make sure the file permissions are correct.
- Make sure you haven't set any environment variables that might affect
things.
- Make sure your kernel tree is sane.

When exactly did this start? With 2008.08.08? Or some time later?

----------------------------------------------------------------------

Comment By: Dominique Leuenberger (dimstar)
Date: 2008-08-24 11:35

Message:
Logged In: YES 
user_id=263934
Originator: YES

compared to the compilation of vmxnet, the following line is different:

vmxnet: Using 2.6.x kernel build system.    

vmci (and also vsock): Using standalone build system.

Maybe it helps.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071988&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2071988 ] Module vmci does not compile

[SourceForge.net <no...@so...>]

Tracker item #2071988, was opened at 2008-08-24 20:22
Message generated for change (Comment added) made by dimstar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071988&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Module vmci does not compile

Initial Comment:
Im trying to spin up new rpms for open-vm-tools (opensuse).

The configure uses --without-kernel-modules (as the build actually happens in a controlled virtual environment, not running the target kernel).

the modules themself are after built using
  #make modules
  for module in %{vm_modules}; do
    pushd modules/linux/$module
    make -C /usr/src/linux-obj/%{_target_cpu}/$flavor modules M=$PWD VM_CCVER=$(gcc -dumpversion) SRCROOT=$PWD
    popd
  done

vm_modules contains a list of modules to be built: "vmblock vmhgfs ... vmci"

this works (and did for long time now) for all modules, but on vmci it fails with the following errors:

+ for module in vmblock vmhgfs vmmemctl vmsync vmxnet vsock vmci
+ pushd modules/linux/vmci
/usr/src/packages/BUILD/obj/debug/modules/linux/vmci /usr/src/packages/BUILD/obj/debug /usr/src/packages/BUILD
++ gcc -dumpversion
+ make -C /usr/src/linux-obj/i586/debug modules M=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci VM_CCVER=4.3 SRCROOT=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci
make: Entering directory `/usr/src/linux-2.6.27-rc3-2-obj/i386/debug'
make -C ../../../linux-2.6.27-rc3-2 O=/usr/src/linux-2.6.27-rc3-2-obj/i386/debug/. modules
Using standalone build system.
/usr/src/packages/BUILD/obj/debug/modules/linux/vmci/autoconf/geninclude.c:19:28: error: linux/autoconf.h: No such file or directory
/usr/src/linux-2.6.27-rc3-2/scripts/Makefile.build:46: *** CFLAGS was changed in "/usr/src/packages/BUILD/obj/debug/modules/linux/vmci/Makefile". Fix it to use EXTRA_CFLAGS.  Stop.
make[2]: *** [_module_/usr/src/packages/BUILD/obj/debug/modules/linux/vmci] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
make: Leaving directory `/usr/src/linux-2.6.27-rc3-2-obj/i386/debug'
error: Bad exit status from /var/tmp/rpm-tmp.23557 (%build)

I would anticipate if somebody could have a look into this. Most likely a small thing which I miss. The Makefile seems to be an exact copy of the one from vmxnet, except to the drivers name... so I really miss something.

Thank you

----------------------------------------------------------------------

>Comment By: Dominique Leuenberger (dimstar)
Date: 2008-08-24 20:35

Message:
Logged In: YES 
user_id=263934
Originator: YES

compared to the compilation of vmxnet, the following line is different:

vmxnet: Using 2.6.x kernel build system.    

vmci (and also vsock): Using standalone build system.

Maybe it helps.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071988&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2071988 ] Module vmci does not compile

[SourceForge.net <no...@so...>]

Tracker item #2071988, was opened at 2008-08-24 20:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071988&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Module vmci does not compile

Initial Comment:
Im trying to spin up new rpms for open-vm-tools (opensuse).

The configure uses --without-kernel-modules (as the build actually happens in a controlled virtual environment, not running the target kernel).

the modules themself are after built using
  #make modules
  for module in %{vm_modules}; do
    pushd modules/linux/$module
    make -C /usr/src/linux-obj/%{_target_cpu}/$flavor modules M=$PWD VM_CCVER=$(gcc -dumpversion) SRCROOT=$PWD
    popd
  done

vm_modules contains a list of modules to be built: "vmblock vmhgfs ... vmci"

this works (and did for long time now) for all modules, but on vmci it fails with the following errors:

+ for module in vmblock vmhgfs vmmemctl vmsync vmxnet vsock vmci
+ pushd modules/linux/vmci
/usr/src/packages/BUILD/obj/debug/modules/linux/vmci /usr/src/packages/BUILD/obj/debug /usr/src/packages/BUILD
++ gcc -dumpversion
+ make -C /usr/src/linux-obj/i586/debug modules M=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci VM_CCVER=4.3 SRCROOT=/usr/src/packages/BUILD/obj/debug/modules/linux/vmci
make: Entering directory `/usr/src/linux-2.6.27-rc3-2-obj/i386/debug'
make -C ../../../linux-2.6.27-rc3-2 O=/usr/src/linux-2.6.27-rc3-2-obj/i386/debug/. modules
Using standalone build system.
/usr/src/packages/BUILD/obj/debug/modules/linux/vmci/autoconf/geninclude.c:19:28: error: linux/autoconf.h: No such file or directory
/usr/src/linux-2.6.27-rc3-2/scripts/Makefile.build:46: *** CFLAGS was changed in "/usr/src/packages/BUILD/obj/debug/modules/linux/vmci/Makefile". Fix it to use EXTRA_CFLAGS.  Stop.
make[2]: *** [_module_/usr/src/packages/BUILD/obj/debug/modules/linux/vmci] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
make: Leaving directory `/usr/src/linux-2.6.27-rc3-2-obj/i386/debug'
error: Bad exit status from /var/tmp/rpm-tmp.23557 (%build)

I would anticipate if somebody could have a look into this. Most likely a small thing which I miss. The Makefile seems to be an exact copy of the one from vmxnet, except to the drivers name... so I really miss something.

Thank you

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071988&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2071170 ] asm/semaphore.h no longer exists in kernel tree

[SourceForge.net <no...@so...>]

Tracker item #2071170, was opened at 2008-08-24 11:24
Message generated for change (Comment added) made by dimstar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071170&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: kernel modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: asm/semaphore.h no longer exists in kernel tree

Initial Comment:
Hello,

Due to some changes in the kernel tree, asm/semaphore.h does no longer exist.

This currently stops from compiling open-vm-tools (module vmhgfs)

When I find some time, I'll try to prepare a patch (it would be a simple one, as it most likely only has to be changed to linux/semaphore.h, but the complexity will be not breaking the old kernel compatibility.. like always :) )

If you happen to already have a fix for this, please let me know.. so we do not double-invest time on it.

(last version I tested was open-vm-tools 2008-08-08 against kernel 2.6.27-rc3)

----------------------------------------------------------------------

>Comment By: Dominique Leuenberger (dimstar)
Date: 2008-08-24 20:03

Message:
Logged In: YES 
user_id=263934
Originator: YES

Thank you very much Adar, this patch did the job and also did not break
compilation on the older platforms.
I added it to the spec file for the moment and will remove it again with
the next refresh.


----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-24 12:48

Message:
Logged In: YES 
user_id=1867590
Originator: NO

I'm not able to attach the patch to this bug report for some reason. I've
added it to the "Development Snapshots" section of the download area.
Here's a direct link:
http://downloads.sourceforge.net/open-vm-tools/open-vm-tools-2008.08.08-2.6.27.kernels.patch

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-24 12:41

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Having some problems uploading the file; hopefully compressing it will
help.

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-24 12:39

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Yeah, don't bother putting together a patch, we've already got something
in-tree. Try this out; it'll be in the next code refresh.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071170&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2071170 ] asm/semaphore.h no longer exists in kernel tree

[SourceForge.net <no...@so...>]

Tracker item #2071170, was opened at 2008-08-24 02:24
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071170&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: kernel modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: asm/semaphore.h no longer exists in kernel tree

Initial Comment:
Hello,

Due to some changes in the kernel tree, asm/semaphore.h does no longer exist.

This currently stops from compiling open-vm-tools (module vmhgfs)

When I find some time, I'll try to prepare a patch (it would be a simple one, as it most likely only has to be changed to linux/semaphore.h, but the complexity will be not breaking the old kernel compatibility.. like always :) )

If you happen to already have a fix for this, please let me know.. so we do not double-invest time on it.

(last version I tested was open-vm-tools 2008-08-08 against kernel 2.6.27-rc3)

----------------------------------------------------------------------

>Comment By: Adar Dembo (adembo)
Date: 2008-08-24 03:48

Message:
Logged In: YES 
user_id=1867590
Originator: NO

I'm not able to attach the patch to this bug report for some reason. I've
added it to the "Development Snapshots" section of the download area.
Here's a direct link:
http://downloads.sourceforge.net/open-vm-tools/open-vm-tools-2008.08.08-2.6.27.kernels.patch

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-24 03:41

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Having some problems uploading the file; hopefully compressing it will
help.

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-24 03:39

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Yeah, don't bother putting together a patch, we've already got something
in-tree. Try this out; it'll be in the next code refresh.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071170&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2071170 ] asm/semaphore.h no longer exists in kernel tree

[SourceForge.net <no...@so...>]

Tracker item #2071170, was opened at 2008-08-24 02:24
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071170&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: kernel modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: asm/semaphore.h no longer exists in kernel tree

Initial Comment:
Hello,

Due to some changes in the kernel tree, asm/semaphore.h does no longer exist.

This currently stops from compiling open-vm-tools (module vmhgfs)

When I find some time, I'll try to prepare a patch (it would be a simple one, as it most likely only has to be changed to linux/semaphore.h, but the complexity will be not breaking the old kernel compatibility.. like always :) )

If you happen to already have a fix for this, please let me know.. so we do not double-invest time on it.

(last version I tested was open-vm-tools 2008-08-08 against kernel 2.6.27-rc3)

----------------------------------------------------------------------

>Comment By: Adar Dembo (adembo)
Date: 2008-08-24 03:41

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Having some problems uploading the file; hopefully compressing it will
help.

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-08-24 03:39

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Yeah, don't bother putting together a patch, we've already got something
in-tree. Try this out; it'll be in the next code refresh.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071170&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2071170 ] asm/semaphore.h no longer exists in kernel tree

[SourceForge.net <no...@so...>]

Tracker item #2071170, was opened at 2008-08-24 02:24
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071170&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: kernel modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: asm/semaphore.h no longer exists in kernel tree

Initial Comment:
Hello,

Due to some changes in the kernel tree, asm/semaphore.h does no longer exist.

This currently stops from compiling open-vm-tools (module vmhgfs)

When I find some time, I'll try to prepare a patch (it would be a simple one, as it most likely only has to be changed to linux/semaphore.h, but the complexity will be not breaking the old kernel compatibility.. like always :) )

If you happen to already have a fix for this, please let me know.. so we do not double-invest time on it.

(last version I tested was open-vm-tools 2008-08-08 against kernel 2.6.27-rc3)

----------------------------------------------------------------------

>Comment By: Adar Dembo (adembo)
Date: 2008-08-24 03:39

Message:
Logged In: YES 
user_id=1867590
Originator: NO

Yeah, don't bother putting together a patch, we've already got something
in-tree. Try this out; it'll be in the next code refresh.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071170&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2071170 ] asm/semaphore.h no longer exists in kernel tree

[SourceForge.net <no...@so...>]

Tracker item #2071170, was opened at 2008-08-24 11:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071170&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: kernel modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: asm/semaphore.h no longer exists in kernel tree

Initial Comment:
Hello,

Due to some changes in the kernel tree, asm/semaphore.h does no longer exist.

This currently stops from compiling open-vm-tools (module vmhgfs)

When I find some time, I'll try to prepare a patch (it would be a simple one, as it most likely only has to be changed to linux/semaphore.h, but the complexity will be not breaking the old kernel compatibility.. like always :) )

If you happen to already have a fix for this, please let me know.. so we do not double-invest time on it.

(last version I tested was open-vm-tools 2008-08-08 against kernel 2.6.27-rc3)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2071170&group_id=204462