Menu
▾
▴
open-vm-tools-devel — List for open-vm-tools developer discussions.
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(30) |
Oct
(50) |
Nov
(42) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(36) |
Feb
(13) |
Mar
(74) |
Apr
(17) |
May
(62) |
Jun
(53) |
Jul
(32) |
Aug
(58) |
Sep
(44) |
Oct
(21) |
Nov
(35) |
Dec
(53) |
| 2009 |
Jan
(43) |
Feb
(58) |
Mar
(14) |
Apr
(16) |
May
(61) |
Jun
(49) |
Jul
(11) |
Aug
(22) |
Sep
(37) |
Oct
(12) |
Nov
(23) |
Dec
(10) |
| 2010 |
Jan
(21) |
Feb
(13) |
Mar
(5) |
Apr
(18) |
May
(14) |
Jun
(10) |
Jul
(1) |
Aug
|
Sep
(13) |
Oct
(8) |
Nov
(11) |
Dec
(14) |
| 2011 |
Jan
(13) |
Feb
(19) |
Mar
(16) |
Apr
(10) |
May
(22) |
Jun
(4) |
Jul
(63) |
Aug
(14) |
Sep
(10) |
Oct
(12) |
Nov
(10) |
Dec
(43) |
| 2012 |
Jan
(3) |
Feb
(4) |
Mar
(35) |
Apr
(1) |
May
(32) |
Jun
(8) |
Jul
(10) |
Aug
(6) |
Sep
(3) |
Oct
(25) |
Nov
(14) |
Dec
(4) |
| 2013 |
Jan
(12) |
Feb
(6) |
Mar
(15) |
Apr
(24) |
May
(9) |
Jun
(2) |
Jul
|
Aug
(4) |
Sep
|
Oct
(8) |
Nov
(3) |
Dec
|
| 2014 |
Jan
(5) |
Feb
|
Mar
(4) |
Apr
(2) |
May
(4) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2015 |
Jan
|
Feb
(5) |
Mar
|
Apr
(1) |
May
(3) |
Jun
(1) |
Jul
(2) |
Aug
(5) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Denis L. <de...@po...> - 2008-10-31 09:17:25
|
Marcelo Vanzin wrote: > So it seems to imply that what controls the license version and that other > versions are allowed is the copyright header in each source file; I checked and > all sources seem to say "no later version", so unless I'm misinterpreting the > LGPL text, I don't think there's an issue. Marcelo, yes that makes sense, and the source code therefore is LGPL 2.1 (no later version). Thanks for the clarification. -denis |
|
From: SourceForge.net <no...@so...> - 2008-10-30 11:20:37
|
Tracker item #2209565, was opened at 2008-10-30 12:20 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=2209565&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: vmware vmxnet fail after hibernate/resume Initial Comment: * Bug copied from bugzilla.novell.com / reported by openSUSE user * * Clarification: Factory means a transient state of openSUSE 11.1 development * * Due to a feature freeze, there is still version 2008.09.03 in the repositories * * Any help woukd be appreciated in this case * * Original bug address: https://bugzilla.novell.com/show_bug.cgi?id=439046 * after hibernate/resume, the VM`s nic is unusable, forwarding no packets anymore. "modprobe -r vmxnet" hangs for a short time and gives: vmxnet_close: Pending tx = 4 vmxnet_close: Failed to finish all pending tx. Is the related vmxnet device disabled? This virtual machine may be in an inconsistent state. Adapter not morphed. read magic: 0x00002934 vmxnet 0000:02:01.0: PCI INT A disabled after reload of that module (modprobe vmxnet) all is fine again. dmesg on reload: VMware vmxnet virtual NIC driver vmxnet 0000:02:01.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 Found vmxnet/PCI at 0x2024, irq 19. features: numRxBuffers = 100, numRxBuffers2 = 1 eth0: no IPv6 routers present - latest factory - 2.6.27.1-2-pae - vmware-kmp-pae-2008.09.03_2.6.27.1_2.1-5.17 - vmware ws 6.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2209565&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2008-10-28 22:54:44
|
Tracker item #2205584, was opened at 2008-10-28 22:12 Message generated for change (Comment added) made by aer0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2205584&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: vmware-user Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam (aer0) Assigned to: Nobody/Anonymous (nobody) Summary: unable to initialize blocking driver Initial Comment: Ubuntu 8.1 After installing, tried to invoke vmware-user. For the unable to initialize error message. Mouse is locked in vm session, but resolution resizing seems to work. ---------------------------------------------------------------------- Comment By: Adam (aer0) Date: 2008-10-28 22:54 Message: Here is a stack trace from the invocation as root. It works for about 1s before crashing: adam@cdl2:~$ vmware-user failed to initialize blocking driver. Error in the RPC recieve loop: RpcIn: Unable to send Another instance of VMwareUser may be running. //its not... *** glibc detected *** vmware-user: free(): invalid pointer: 0x0966f3a0 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb74573f4] /lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb7459456] /usr/lib/libglib-2.0.so.0(g_free+0x36)[0xb770bc06] vmware-user[0x804e26b] vmware-user[0x804e368] vmware-user[0x805641d] vmware-user[0x8058ef6] vmware-user[0x80575e9] /usr/lib/libglib-2.0.so.0[0xb7703e26] /usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1e8)[0xb77036f8] /usr/lib/libglib-2.0.so.0[0xb7706da3] /usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1d2)[0xb77072c2] /usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xb9)[0xb7c573a9] vmware-user[0x8057375] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb73fe685] vmware-user[0x804d211] ======= Memory map: ======== 08048000-080a6000 r-xp 00000000 08:01 820888 /usr/local/bin/vmware-user 080a6000-080a7000 r--p 0005d000 08:01 820888 /usr/local/bin/vmware-user 080a7000-080a8000 rw-p 0005e000 08:01 820888 /usr/local/bin/vmware-user 080a8000-08136000 rw-p 080a8000 00:00 0 09661000-096a4000 rw-p 09661000 00:00 0 [heap] b70f1000-b70fe000 r-xp 00000000 08:01 33050 /lib/libgcc_s.so.1 b70fe000-b70ff000 r--p 0000c000 08:01 33050 /lib/libgcc_s.so.1 b70ff000-b7100000 rw-p 0000d000 08:01 33050 /lib/libgcc_s.so.1 b7100000-b7121000 rw-p b7100000 00:00 0 b7121000-b7200000 ---p b7121000 00:00 0 b7203000-b720d000 r-xp 00000000 08:01 50397 /lib/tls/i686/cmov/libnss_files-2.8.90.so b720d000-b720e000 r--p 00009000 08:01 50397 /lib/tls/i686/cmov/libnss_files-2.8.90.so b720e000-b720f000 rw-p 0000a000 08:01 50397 /lib/tls/i686/cmov/libnss_files-2.8.90.so b720f000-b7218000 r-xp 00000000 08:01 50401 /lib/tls/i686/cmov/libnss_nis-2.8.90.so b7218000-b7219000 r--p 00008000 08:01 50401 /lib/tls/i686/cmov/libnss_nis-2.8.90.so b7219000-b721a000 rw-p 00009000 08:01 50401 /lib/tls/i686/cmov/libnss_nis-2.8.90.so b721a000-b7221000 r-xp 00000000 08:01 50393 /lib/tls/i686/cmov/libnss_compat-2.8.90.so b7221000-b7222000 r--p 00006000 08:01 50393 /lib/tls/i686/cmov/libnss_compat-2.8.90.so b7222000-b7223000 rw-p 00007000 08:01 50393 /lib/tls/i686/cmov/libnss_compat-2.8.90.so b7234000-b7315000 r--p 00000000 08:01 771203 /usr/lib/locale/en_US.utf8/LC_COLLATE b7315000-b7354000 r--p 00000000 08:01 771204 /usr/lib/locale/en_US.utf8/LC_CTYPE b7354000-b7357000 rw-p b7354000 00:00 0 b7357000-b7358000 r-xp 00000000 08:01 748141 /usr/lib/libxcb-xlib.so.0.0.0 b7358000-b7359000 r--p 00000000 08:01 748141 /usr/lib/libxcb-xlib.so.0.0.0 b7359000-b735a000 rw-p 00001000 08:01 748141 /usr/lib/libxcb-xlib.so.0.0.0 b735a000-b7382000 r-xp 00000000 08:01 32880 /lib/libpcre.so.3.12.1 b7382000-b7383000 r--p 00027000 08:01 32880 /lib/libpcre.so.3.12.1 b7383000-b7384000 rw-p 00028000 08:01 32880 /lib/libpcre.so.3.12.1 b7384000-b7399000 r-xp 00000000 08:01 50391 /lib/tls/i686/cmov/libnsl-2.8.90.so b7399000-b739a000 r--p 00014000 08:01 50391 /lib/tls/i686/cmov/libnsl-2.8.90.so b739a000-b739b000 rw-p 00015000 08:01 50391 /lib/tls/i686/cmov/libnsl-2.8.90.so b739b000-b739d000 rw-p b739b000 00:00 0 b739d000-b73c1000 r-xp 00000000 08:01 747214 /usr/lib/libexpat.so.1.5.2 b73c1000-b73c3000 r--p 00023000 08:01 747214 /usr/lib/libexpat.so.1.5.2 b73c3000-b73c4000 rw-p 00025000 08:01 747214 /usr/lib/libexpat.so.1.5.2 b73c4000-b73c5000 rw-p b73c4000 00:00 0 b73c5000-b73c9000 r-xp 00000000 08:01 746986 /usr/lib/libXdmcp.so.6.0.0 b73c9000-b73ca000 rw-p 00003000 08:01 746986 /usr/lib/libXdmcp.so.6.0.0 b73ca000-b73cc000 r-xp 00000000 08:01 746975 /usr/lib/libXau.so.6.0.0 b73cc000-b73cd000 rw-p 00001000 08:01 746975 /usr/lib/libXau.so.6.0.0 b73cd000-b73e5000 r-xp 00000000 08:01 32892 /lib/libselinux.so.1 b73e5000-b73e6000 r--p 00017000 08:01 32892 /lib/libselinux.so.1 b73e6000-b73e7000 rw-p 00018000 08:01 32892 /lib/libselinux.so.1 b73e7000-b73e8000 rw-p b73e7000 00:00 0 b73e8000-b7540000 r-xp 00000000 08:01 50380 /lib/tl [1]+ Aborted sudo vmware-user ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2205584&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2008-10-28 22:12:43
|
Tracker item #2205584, was opened at 2008-10-28 22:12 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=2205584&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: vmware-user Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam (aer0) Assigned to: Nobody/Anonymous (nobody) Summary: unable to initialize blocking driver Initial Comment: Ubuntu 8.1 After installing, tried to invoke vmware-user. For the unable to initialize error message. Mouse is locked in vm session, but resolution resizing seems to work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2205584&group_id=204462 |
|
From: Marcelo V. <mv...@vm...> - 2008-10-28 18:32:40
|
Hi Denis, Denis Leroy wrote: > There are a number of copies of COPYING containing the LGPLv2+ (i.e. "or > any later version"), while the source code mentions LGPLv2 (i.e. "no > later version")... Could you clarify a little bit more what's your concern? I took a look at the LGPL text, and the license itself (i.e., the text in the COPYING file) doesn't seem to dictate one way or another. These are the two paragraphs I'm basing my interpretation on: "0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". " (From term 13:) "Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation." So it seems to imply that what controls the license version and that other versions are allowed is the copyright header in each source file; I checked and all sources seem to say "no later version", so unless I'm misinterpreting the LGPL text, I don't think there's an issue. Also, this is the only version of the LGPL available at the GNU website - I don't see a different version with the "no later version" clause replacing the "any later version" wording above, so that case seems to be implied by term 13. -- - Marcelo |
|
From: Adar D. <ad...@vm...> - 2008-10-26 20:45:13
|
> What license are the tools (not the kernel modules) written with ? > > There are a number of copies of COPYING containing the LGPLv2+ (i.e. "or > any later version"), while the source code mentions LGPLv2 (i.e. "no > later version")... Our intent was for LGPLv2 adhering bits to be "no later version". Looking at the code now, I see what you mean (I think most of the COPYING files refer to "any later version" while most of the snippets embedded in individual source files refer to "no later version"). This is something we'll need to correct; could you please file a bug so we can better track the issue? |
|
From: Denis L. <de...@po...> - 2008-10-26 17:27:20
|
What license are the tools (not the kernel modules) written with ? There are a number of copies of COPYING containing the LGPLv2+ (i.e. "or any later version"), while the source code mentions LGPLv2 (i.e. "no later version")... -denis |
|
From: Dominique L. <Dom...@TM...> - 2008-10-22 08:07:38
|
On Wed, 2008-10-22 at 09:59 +0200, Dominique Leuenberger wrote:
> So a little bit better... just yet: /etc/init.d/vmware start fails on
> loading all of the modules. It seems not to be happy with this setup
> yet.
Just a follow up on this:
I had to modify the script /etc/init.d/vmware;
the change was like this:
vmwareLoadModule() {
/sbin/insmod -s -f "/lib/modules/`uname
-r`/kernel/drivers/misc/$1.ko" || exit 1
return 0
}
The line with insmod did not contain kernel/drivers/misc, but only misc.
Thus it failed. With this change now applied, vmware seems to start up
finally and machines seem to boot including network access.
Why not simply use "/sbin/modprobe $1" There? This would take care of it
all in my opinion.
Wohoo ;)
Dominique
|
|
From: Dominique L. <Dom...@TM...> - 2008-10-22 07:59:54
|
On Tue, 2008-10-21 at 09:51 -0700, Aaron Rolett wrote:
> Dominique,
> The vsock module warning messages have always been there (its
> been on our list of things to cleanup for awhile). They appear because
> the vsock build has no knowledge of the vmci module build even though
> vsock depends on vmci symbols. I believe that the kernel module loader
> changed sometime before 2.6.27 to prevent modules with unknown symbols
> from loading if the kernel was built with CONFIG_MODVERSIONS. This is
> something I was going to look into internally but haven't had a chance
> to test out yet.
> The reporters have seen the following from dmesg:
> home/user/vmxnet3h/hosted08/bora# insmod build/obj-x64/ws/modules/
> local/2.6.27-4-generic/vsock/vsock.ko
> insmod: error inserting 'build/obj-x64/ws/modules/local/2.6.27-4-
> generic/vsock/vsock.ko': -1 Unknown symbol in module
>
> A quick test to see if this is the problem would be to:
> 1. Build the vmci module
> 2. Copy Module.symvers from vmci => vsock
> 3. Build vsock
> 4. Try loading the module.
>
Thank you very much for your help. I tried this.
Built all the modules, before compiling vsock, I copied the
Modules.symvers from vmci-only to vsock-only, and as suggested by you,
vsock compiled correctly like this.
As suggested by you, I can now load all the modules (vmblock, vmmon,
vmnet, vmci and vsock).
So a little bit better... just yet: /etc/init.d/vmware start fails on
loading all of the modules. It seems not to be happy with this setup
yet.
When loading the modules manually, I don't have a /dev/vmnet0 does not
get created (was probably normally done by the vmware init script.. will
have to look into this).
> All of that being said, ws shouldn't be segfaulting on startup (it
> should be able to load and run fine without the vsock module ... you
> just will not be able to use vmci sockets).
>
Indeed, this should not happen... I'm performing my tests on openSUSE
11.1beta3; openSUSE 11.1 is scheduled to be released before x-mas... and
I hope it's in everybody's interest to snatch this out before the
release... After all that's what for beta releases are.
> A couple of questions:
> 1. Which process specifically is dying? vmware / vmware-vmx something
> else?
When not having the modules loaded / compiled and I start vmware, I get
this on the console:
dle3ams@3120-2914:~/Desktop/RPMs/var/cache/vmware> vmware
Logging to /tmp/vmware-dle3ams/setup-11031.log
modinfo: could not find module vmmon
modinfo: could not find module vmnet
modinfo: could not find module vmblock
modinfo: could not find module vmci
modinfo: could not find module vsock
modinfo: could not find module vmmon
modinfo: could not find module vmnet
modinfo: could not find module vmblock
modinfo: could not find module vmci
modinfo: could not find module vsock
/usr/lib/vmware/bin/launcher.sh: line 231: 11031 Segmentation fault
"$binary" "$@"
The content of the mentioned log file is:
dle3ams@3120-2914:~/Desktop/RPMs/var/cache/vmware>
cat /tmp/vmware-dle3ams/setup-11031.log
Oct 22 09:50:06.868: app| Log for VMware Workstation pid=11031
version=6.5.0 build=build-118166 option=Release
Oct 22 09:50:06.868: app| Host codepage=UTF-8 encoding=UTF-8
Oct 22 09:50:06.868: app| Logging to /tmp/vmware-dle3ams/setup-11031.log
on dmesg I get the following output:
vmware-modconfi[10656]: segfault at 0 ip 00007f54bd915347 sp
00007fffccbde380 error 4 in libc-2.8.90.so[7f54bd896000+152000]
A coredump is attached to this mail)
> 2. Can you get us a core dump from the segfault?
Of course.. attached
> 3. Can you upload the relevant logs. On my machine they live in /tmp/
> vmware-${USER} and <VM Directory>/vmware.log
Attached (the one from tmp)... the one from the VMwares itself is not
very interesting, as vm gui does not even come up.
> 4. Any other relevant debugging information you can think of.
>
Well, as said, I'm performing my tests on openSUSE 11.1, beta3, x86_64
setup. Not being a complete noob in the linux area I hope I can be of
further assistance to you in finding out what goes wrong and testing
possible solutions. In very best case, the problem is not caused by
vmware ;)
> Aaron
Dominique
|
|
From: Denis L. <de...@po...> - 2008-10-21 22:17:28
|
Dominique Leuenberger wrote: > Hi, > > I know this is not the right list, but the problem might come up later > in the open-vm-tools as well. > > I'm trying to make a VMware Workstation 6.5 start on a 2.6.27 kernel. For the record, I have no problem here with Workstation 6.5 (build 118166) on Fedora 10 (kernel 2.6.27.3). All modules compile. |
|
From: Aaron R. <ar...@vm...> - 2008-10-21 16:51:42
|
Dominique,
The vsock module warning messages have always been there (its
been on our list of things to cleanup for awhile). They appear because
the vsock build has no knowledge of the vmci module build even though
vsock depends on vmci symbols. I believe that the kernel module loader
changed sometime before 2.6.27 to prevent modules with unknown symbols
from loading if the kernel was built with CONFIG_MODVERSIONS. This is
something I was going to look into internally but haven't had a chance
to test out yet.
The reporters have seen the following from dmesg:
home/user/vmxnet3h/hosted08/bora# insmod build/obj-x64/ws/modules/
local/2.6.27-4-generic/vsock/vsock.ko
insmod: error inserting 'build/obj-x64/ws/modules/local/2.6.27-4-
generic/vsock/vsock.ko': -1 Unknown symbol in module
A quick test to see if this is the problem would be to:
1. Build the vmci module
2. Copy Module.symvers from vmci => vsock
3. Build vsock
4. Try loading the module.
All of that being said, ws shouldn't be segfaulting on startup (it
should be able to load and run fine without the vsock module ... you
just will not be able to use vmci sockets).
A couple of questions:
1. Which process specifically is dying? vmware / vmware-vmx something
else?
2. Can you get us a core dump from the segfault?
3. Can you upload the relevant logs. On my machine they live in /tmp/
vmware-${USER} and <VM Directory>/vmware.log
4. Any other relevant debugging information you can think of.
Aaron
On Oct 21, 2008, at 6:34 AM, Dominique Leuenberger wrote:
> Hi,
>
> I know this is not the right list, but the problem might come up later
> in the open-vm-tools as well.
>
> I'm trying to make a VMware Workstation 6.5 start on a 2.6.27 kernel.
>
> Starting vmware itself gives a segfault, as the modules are not there
> and apparently compiling them seems more difficult than expected.
>
> So I went to /usr/lib/vmware/modules/sources nd untared all the
> archives.
>
> changing to every directory and executing make compiles them (except
> one.. for parallel port if I'm not mistaken, which sounds rather
> unimportant) and vsock.ko
>
> vsock fails with the following warnings:
> WARNING:
> "VMCIDatagram_CreateHnd" [/usr/lib/vmware/modules/source/vsock-only/
> vsock.ko] undefined!
> WARNING:
> "VMCIDatagram_DestroyHnd" [/usr/lib/vmware/modules/source/vsock-only/
> vsock.ko] undefined!
> WARNING:
> "VMCI_GetContextID" [/usr/lib/vmware/modules/source/vsock-only/
> vsock.ko]
> undefined!
> WARNING:
> "VMCIDatagram_Send" [/usr/lib/vmware/modules/source/vsock-only/
> vsock.ko]
> undefined!
>
> Needless to say, that modprobing this module does not work; all the
> others work.
>
> What would be the correct way to tackle this?
>
> Dominique
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> open-vm-tools-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel
|
|
From: Dominique L. <Dom...@TM...> - 2008-10-21 13:34:54
|
Hi, I know this is not the right list, but the problem might come up later in the open-vm-tools as well. I'm trying to make a VMware Workstation 6.5 start on a 2.6.27 kernel. Starting vmware itself gives a segfault, as the modules are not there and apparently compiling them seems more difficult than expected. So I went to /usr/lib/vmware/modules/sources nd untared all the archives. changing to every directory and executing make compiles them (except one.. for parallel port if I'm not mistaken, which sounds rather unimportant) and vsock.ko vsock fails with the following warnings: WARNING: "VMCIDatagram_CreateHnd" [/usr/lib/vmware/modules/source/vsock-only/vsock.ko] undefined! WARNING: "VMCIDatagram_DestroyHnd" [/usr/lib/vmware/modules/source/vsock-only/vsock.ko] undefined! WARNING: "VMCI_GetContextID" [/usr/lib/vmware/modules/source/vsock-only/vsock.ko] undefined! WARNING: "VMCIDatagram_Send" [/usr/lib/vmware/modules/source/vsock-only/vsock.ko] undefined! Needless to say, that modprobing this module does not work; all the others work. What would be the correct way to tackle this? Dominique |
|
From: SourceForge.net <no...@so...> - 2008-10-15 08:49:29
|
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: Closed Resolution: Fixed 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-10-15 01:45 Message: Verified. Thank you! ---------------------------------------------------------------------- Comment By: Adar Dembo (adembo) Date: 2008-09-12 18:50 Message: Alright, I committed a patch to git that should fix this problem. Could you guys check it out and let me know if it doesn't work for you? Otherwise, it'll be in the next code refresh and at that point I'll close this bug. ---------------------------------------------------------------------- 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 |
|
From: Adar D. <ad...@vm...> - 2008-10-14 22:05:34
|
> > Back in the June 20th code refresh we changed how vmware-guestd relays > versioning information to the host. Now, one can now set a key/value pair > in tools.conf which will cause the open-vm-tools to "opt-out" of VMware's > Tools upgrading infrastructure. At the time I don't think we advertised > this change loudly, but we should have: ALL OPEN-VM-TOOLS PACKAGES SHOULD > MAKE USE OF THIS MECHANISM. I've added a paragraph describing the key/value > pair to the open-vm-tools packaging wiki (in the vmware-guestd section). > More details follow. > > > > What is the key/value pair that should be set to do this? disable-tools-version = TRUE |
|
From: Sean D. <se...@du...> - 2008-10-14 19:40:50
|
Adar Dembo wrote: > Back in the June 20th code refresh we changed how vmware-guestd relays versioning information to the host. Now, one can now set a key/value pair in tools.conf which will cause the open-vm-tools to "opt-out" of VMware's Tools upgrading infrastructure. At the time I don't think we advertised this change loudly, but we should have: ALL OPEN-VM-TOOLS PACKAGES SHOULD MAKE USE OF THIS MECHANISM. I've added a paragraph describing the key/value pair to the open-vm-tools packaging wiki (in the vmware-guestd section). More details follow. > What is the key/value pair that should be set to do this? Thanks, Sean |
|
From: Adar D. <ad...@vm...> - 2008-10-13 23:16:38
|
Back in the June 20th code refresh we changed how vmware-guestd relays versioning information to the host. Now, one can now set a key/value pair in tools.conf which will cause the open-vm-tools to "opt-out" of VMware's Tools upgrading infrastructure. At the time I don't think we advertised this change loudly, but we should have: ALL OPEN-VM-TOOLS PACKAGES SHOULD MAKE USE OF THIS MECHANISM. I've added a paragraph describing the key/value pair to the open-vm-tools packaging wiki (in the vmware-guestd section). More details follow. The VMware Tools have an "internal version" which is broadcast by vmware-guestd to the VMX, which in turn, broadcasts it to our hosted UIs and to clients of the VI SDK. This version is bumped prior to every product release, and generally represents the "newness" of a particular Tools release. Clients outside the VMX will use this version to determine whether the Tools are to be upgraded, using either the VMware Tools auto-upgrading mechanism or the traditional manual upgrading mechanism (where the user must mount an ISO image in the guest, extract the Tools from it, and run a script). Unfortunately, these clients don't understand open-vm-tools or distro packages, and so they won't know to make use of tools like yum or apt to a) check for the availability of new open-vm-tools, and b) upgrade existing open-vm-tools. Until we address these shortcomings, we need a way to disable VMware-induced Tools upgrades, and so we cooked up this "opt-out" switch in vmware-guestd to do just that. It's very simple: instead of broadcasting the actual Tools internal version, vmware-guestd instead broadcasts the largest internal version possible. In newer VMware products this value has been special cased to represent open-vm-tools that clients should ignore, and in older products it'll appear to be the newest possible Tools, which will fool clients into thinking the Tools are up-to-date. |
|
From: SourceForge.net <no...@so...> - 2008-10-13 07:41:51
|
Tracker item #1925183, was opened at 2008-03-25 06:50 Message generated for change (Settings changed) 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: Closed >Resolution: Fixed 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-10-13 00:41 Message: Haven't heard back from Dominique, so will assume this isn't a problem. ---------------------------------------------------------------------- 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 |
|
From: SourceForge.net <no...@so...> - 2008-10-13 07:41:48
|
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-10-13 00:41 Message: Haven't heard back from Dominique, so will assume this isn't a problem. ---------------------------------------------------------------------- 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 |
|
From: SourceForge.net <no...@so...> - 2008-10-13 07:40:22
|
Tracker item #1960947, was opened at 2008-05-09 04:09 Message generated for change (Settings changed) 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: Closed >Resolution: Fixed 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-12 18:50 Message: Alright, I committed a patch to git that should fix this problem. Could you guys check it out and let me know if it doesn't work for you? Otherwise, it'll be in the next code refresh and at that point I'll close this bug. ---------------------------------------------------------------------- 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 |
|
From: SourceForge.net <no...@so...> - 2008-10-07 00:01:40
|
Tracker item #1865635, was opened at 2008-01-06 23:00 Message generated for change (Comment added) made by eatnumber1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1865635&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: 3 Private: No Submitted By: Russell Harmon (eatnumber1) Assigned to: ECL (sopwith) Summary: FEATURE: Add the ability to include in the kernel. Initial Comment: It would be VERY nice if a makefile and instructions were included for including open-vm-tools as part of the kernel. I help maintain a small kernel patchset and would like to include open-vm-tools in it. I will write an example Makefile if I get the time. ---------------------------------------------------------------------- >Comment By: Russell Harmon (eatnumber1) Date: 2008-10-06 19:57 Message: It needs the Makefile to follow the conventions outlined at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kbuild/makefiles.txt;h=7a7753321a263f62c2a00c9d0e348716e701ac2c;hb=HEAD (or Documentation/kbuild/makefiles.txt in the tree), and you need to create a kbuild file defining what shows up in menuconfig (see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kbuild/kconfig-language.txt;h=c412c245848f9116fb05361bb78e5189b43cfd51;hb=HEAD or Documentation/kbuild/kconfig-language.txt in the tree). ---------------------------------------------------------------------- Comment By: Dmitriy (bryndin) Date: 2008-05-09 14:56 Message: Logged In: YES user_id=1494464 Originator: NO I'm using it as dkms modules. ---------------------------------------------------------------------- Comment By: ECL (sopwith) Date: 2008-02-08 16:54 Message: Logged In: YES user_id=18318 Originator: NO Hey Russell - any progress with that example Makefile? I know the kernel modules already include a Makefile that ties in with the 2.6 kernel build system. While I'm totally ignorant about the kernel build system, what happens if you just 'mv open-vm-tools-2008.01.23*/modules/linux/vmhgfs /usr/src/linux/fs/vmhgfs' and fix up the top-level Makefiles to match? Are there any other technical tasks involved in integrating the modules into a kernel tree? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1865635&group_id=204462 |
|
From: Adar D. <ad...@vm...> - 2008-09-27 20:29:12
|
> Also: In short what does "unity" provide? > Or what does "--disable-unity" leave out? I can answer this one. Unity is essentially "rootless mode" for a VM. Meaning, the guest desktop is hidden, and all guest windows appear on the host desktop. We've actually never tested Unity on FreeBSD guests so I'm not sure how well it'll work once you get it compiling, but in any case you'll also need to be running your guest under Fusion or Workstation 6.5. Here's a Youtube video previewing Unity for Fusion 1.0: http://www.youtube.com/watch?v=JIApJMzGzDQ |
|
From: Ernest G. W. I. <ern...@gm...> - 2008-09-27 13:50:58
|
Ryan, Thank you for looking into this. I look forward to having a version that is built-in to FreeBSD 7 that works from ports. I hate to see FreeBSD 7 get left behind and appreciate your efforts to patch and correct these items. Will you respond to this email thread in the future to let me know when and how to test again? Also: In short what does "unity" provide? Or what does "--disable-unity" leave out? Have a great trip and hope to hear from you soon! Thank you, Ernie Wilson http://www.N3NCY.com -----Original Message----- From: Ryan Beasley [mailto:rbe...@vm...] Sent: Friday, September 26, 2008 9:05 PM To: Ern...@gm...; DIscussions relating to development of the open-vm-tools project Cc: Adar Dembo Subject: Re: [open-vm-tools-devel] FreeBSD 7.0 building Ernest G. Wilson II wrote: > Adar, > > I see libXss here: > [root@FreeBSD ~]# find / | grep -i "libXss" > /usr/compat/linux/usr/X11R6/lib/libXss.so.1 > /usr/compat/linux/usr/X11R6/lib/libXss.so.1.0 Hi, Ernie, The libXss library isn't part of libX11, but rather from x11/libXScrnSaver. The paths you're referring to above are part of the Linux binary compatibility packages. I.e., they only apply if you're running a Linux binary X server. Regardless, the Unity codebase requires some modification to even build on FreeBSD, so for the time being you should stick to using "--disable-unity" when running ./configure. > In file included from deployPkgLog.c:26: > /usr/src/open-vm-tools-2008.09.03-114782/lib/include/file.h:49:38: error: > syslimits.h: No such file or directory I just want to let you know that I'm looking into this. We have a few instances where <syslimits.h> is referenced instead of <sys/syslimits.h>. There are a few other things getting in the way of building the open-vm-tools, unmodified, against FreeBSD 7.0. Unfortunately I'm going out of town soon and have some other things to gnaw on first, but I'm going to try to get these issues taken care of "soon", and will also look into patching up the FreeBSD port (emulators/open-vm-tools), sending modifications over to the current port maintainer. I won't feel -too- bad if anyone beats me to the punch, though. ;) -- Ryan Beasley <rbe...@vm...> |
|
From: Ryan B. <rbe...@vm...> - 2008-09-27 01:05:28
|
Ernest G. Wilson II wrote: > Adar, > > I see libXss here: > [root@FreeBSD ~]# find / | grep -i "libXss" > /usr/compat/linux/usr/X11R6/lib/libXss.so.1 > /usr/compat/linux/usr/X11R6/lib/libXss.so.1.0 Hi, Ernie, The libXss library isn't part of libX11, but rather from x11/libXScrnSaver. The paths you're referring to above are part of the Linux binary compatibility packages. I.e., they only apply if you're running a Linux binary X server. Regardless, the Unity codebase requires some modification to even build on FreeBSD, so for the time being you should stick to using "--disable-unity" when running ./configure. > In file included from deployPkgLog.c:26: > /usr/src/open-vm-tools-2008.09.03-114782/lib/include/file.h:49:38: error: > syslimits.h: No such file or directory I just want to let you know that I'm looking into this. We have a few instances where <syslimits.h> is referenced instead of <sys/syslimits.h>. There are a few other things getting in the way of building the open-vm-tools, unmodified, against FreeBSD 7.0. Unfortunately I'm going out of town soon and have some other things to gnaw on first, but I'm going to try to get these issues taken care of "soon", and will also look into patching up the FreeBSD port (emulators/open-vm-tools), sending modifications over to the current port maintainer. I won't feel -too- bad if anyone beats me to the punch, though. ;) -- Ryan Beasley <rbe...@vm...> |
|
From: Ernest G. W. I. <ern...@gm...> - 2008-09-26 21:53:05
|
Adar, I see libXss here: [root@FreeBSD ~]# find / | grep -i "libXss" /usr/compat/linux/usr/X11R6/lib/libXss.so.1 /usr/compat/linux/usr/X11R6/lib/libXss.so.1.0 And here is the failing output from "make" [root@FreeBSD /usr/src/open-vm-tools-2008.09.03-114782]# make Making all in lib Making all in guestRpc Making all in auth Making all in backdoor Making all in shared Making all in conf Making all in dict Making all in deployPkg gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"2008.09.03-114782\" -DPACKAGE_STRING=\"open-vm-tools\ 2008.09.03-114782\" -DPACKAGE_BUGREPORT=\"ope...@li...\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"2008.09.03-114782\" -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 -DLT_OBJDIR=\".libs/\" -DHAVE_DLOPEN=1 -DNO_PROCPS=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -I. -DUSING_AUTOCONF=1 -I/usr/local/include -I/usr/local/include -DUSE_ICU -DHAVE_ICU_38 -DVMX86_TOOLS -DNO_CORE_ICU -I/usr/src/open-vm-tools-2008.09.03-114782/lib/include -g -O2 -Wall -Werror -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -MT deployPkgLog.o -MD -MP -MF .deps/deployPkgLog.Tpo -c -o deployPkgLog.o deployPkgLog.c In file included from deployPkgLog.c:26: /usr/src/open-vm-tools-2008.09.03-114782/lib/include/file.h:49:38: error: syslimits.h: No such file or directory *** Error code 1 Stop in /usr/src/open-vm-tools-2008.09.03-114782/lib/deployPkg. *** Error code 1 Stop in /usr/src/open-vm-tools-2008.09.03-114782/lib. *** Error code 1 Stop in /usr/src/open-vm-tools-2008.09.03-114782. Thank you for looking into this. Ernie -----Original Message----- From: Adar Dembo [mailto:ad...@vm...] Sent: Friday, September 26, 2008 4:24 AM To: Ern...@gm...; DIscussions relating to development of the open-vm-tools project Subject: RE: [open-vm-tools-devel] FreeBSD 7.0 building > I am trying to compile: > open-vm-tools-2008.09.03-114782 > on FreeBSD 7 Thanks for trying out the open-vm-tools! It's too bad you're having difficulties compiling; let's take a closer look and see what's going on. > First I get an error during configure stating: > configure: error: libXss not found. Please configure without Unity > (using > --disable-unity) or install the libXss devel package > > Even though I do have libXss installed via FreeBSD ports: > cd /usr/ports/x11/libX11 > make install clean > > So I am forced to configure like this: > ./configure --disable-unity So where did 'make install' put libXss? Could you provide the config.log file that configure generated? > So I get through configure and try to make and get: > /usr/src/open-vm-tools-2008.09.03-114782/lib/include/file.h:49:38: > error: > syslimits.h: No such file or directory > > But I do have syslimits.h in two places: > /usr/include/sys/syslimits.h > /usr/src/sys/sys/syslimits.h > > Any idea why file.h can't find my syslimits.h? Could you provide the full line of make's output which details how the file including file.h was compiled? |
|
From: Adar D. <ad...@vm...> - 2008-09-26 08:45:05
|
> I am trying to compile: > open-vm-tools-2008.09.03-114782 > on FreeBSD 7 Thanks for trying out the open-vm-tools! It's too bad you're having difficulties compiling; let's take a closer look and see what's going on. > First I get an error during configure stating: > configure: error: libXss not found. Please configure without Unity > (using > --disable-unity) or install the libXss devel package > > Even though I do have libXss installed via FreeBSD ports: > cd /usr/ports/x11/libX11 > make install clean > > So I am forced to configure like this: > ./configure --disable-unity So where did 'make install' put libXss? Could you provide the config.log file that configure generated? > So I get through configure and try to make and get: > /usr/src/open-vm-tools-2008.09.03-114782/lib/include/file.h:49:38: > error: > syslimits.h: No such file or directory > > But I do have syslimits.h in two places: > /usr/include/sys/syslimits.h > /usr/src/sys/sys/syslimits.h > > Any idea why file.h can't find my syslimits.h? Could you provide the full line of make's output which details how the file including file.h was compiled? |
58 messages has been excluded from this view by a project administrator.
