Please backport open-vm-source (and -tools) from intrepid/debian sources

[Jan Ivar Beddari]

The packages open-vm-tools and open-vm-source was pulled from Hardy because "it was not production-ready software".

However, this leaves a situation where you have to maintain vmware tools manually. This is not desireable or something that anyone wants to do manually over time. You will need to roll your own source packages to go with module assistant if you want to solve this by yourself on a larger scale.

Right now for running virtual servers on VMware ESX or VMware Server it is better to go with Debian Etch which has an actively maintained backport, rather than Hardy. We'd love to move to Hardy if this was sloved.

Using whats already there for Debian (and now also recently for Interpid) it should be possible to put together a backport.

[Alexander Frolushkin (hokum)]

This package could be very usefull for anyone, using VMWARE virtualization products.
For users needed to have vmware-tools this howto may help http://peterc.org/2008/62-how-to-install-vmware-tools-on-ubuntu-hardy-804-under-vmware-fusion.html

[Michael Casadevall (mcasadevall)]

open-vm-source depends on debhelper 7 which isn't available in Hardy. Source level porting will be required for this backport so I'm marking it incomplete until which time such backporting can be done.

[J. Zimmerman (john.zimm)]

Does anyone know if a backport is going to be planned anytime soon.

A graceful vmware tools installation is critical for installing Hardy on ESX. I would think this is a high priority especially with JeOS targeting virtual environments and Hardy being an LTS release.

[Lowell Alleman (lowell-alleman)]

I am also quite interested in getting a backport of this package. I wrote up a question on the "open-vm-tools" package, outlining my own reasons for this request, before realizing how to properly request a backport... which is when I found the request has already been made:
   https://answers.launchpad.net/ubuntu/+source/open-vm-tools/+question/51827

I have only minimal debian package building experience, but is there something that I could do to push the process along? Does anybody know the level of complexity thats involved? Is it simply a matter of figuring out how to take current source package and getting it to build against 8.04 (with debhelper 6) and then submitting a patch? Or is this a really complicated process that would take a large amount of effort for someone who isn't a debian package builder by trade?

If anyone has some links to point me in the right direction (backporting packaging how-to or a debhelper upgrade/downgrade steps...) I would be willing to give this a try.

[Lowell Alleman (lowell-alleman)]

I was able to get the open-vm-tools package to build on hardy. I grabbed the latest source release open-vm-tools_2008.10.10-123053-2 (from jaunty). All that I had to change was the debhelper compatibility level to 6 in a couple of places and remove dh_lintian from the rules file. (See attached patch). I was able to get all the packages to build. I tested that the kernel module could be compiled with module-assistant, and the modules seem to be working properly on my test VM.

As I mentioned before, I have minimal packaging experience so help me out with anything I missed. I am hoping that some one with more experience can take this information and turn it into something more official.

Let me know if there is anything else I can do to help this process along.

- Lowell

[Lowell Alleman (lowell-alleman)]

If anyone is interested, I made a backported copy of these packages available on my PPA. You can find the appropriate apt/source.list entries here: https://launchpad.net/~lowell-alleman/+archive

I don't think it's possible to distribute kernel modules with PPA, I could be wrong.... So after installing open-vm-source, you'll have to run the following to build/install the kernel level modules:
    module-assistant prepare open-vm
    module-assistant auto-install open-vm

[Kristian Domke (kristian-neither-nor)]

May be simply a "metoo", but with one question:

As far as I can see, the patch seem to be simple enough. What speaks against using it for ubuntu-backports? (I have not tested it yet, but...)

Kristian

[Rouben (rouben)]

FYI, VMware does provide packages and even apt repositories with precompiled versions of both kernel modules and VMware Tools for Ubuntu 8.04 and 8.04.1 for ESX version 3.5:

http://www.vmware.com/download/packages.html

[J. Zimmerman (john.zimm)]

I was not aware of that before. The date on the page states the middle of
December. How long has this been available?

On Mon, Dec 22, 2008 at 11:38 PM, Rouben <email address hidden> wrote:

> FYI, VMware does provide packages and even apt repositories with
> precompiled versions of both kernel modules and VMware Tools for Ubuntu
> 8.04 and 8.04.1 for ESX version 3.5:
>
> http://www.vmware.com/download/packages.html
>
> --
> Please backport open-vm-source (and -tools) from intrepid/debian sources
> https://bugs.launchpad.net/bugs/252663
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Hardy Heron Backports: Incomplete
>
> Bug description:
> The packages open-vm-tools and open-vm-source was pulled from Hardy because
> "it was not production-ready software".
>
> However, this leaves a situation where you have to maintain vmware tools
> manually. This is not desireable or something that anyone wants to do
> manually over time. You will need to roll your own source packages to go
> with module assistant if you want to solve this by yourself on a larger
> scale.
>
> Right now for running virtual servers on VMware ESX or VMware Server it is
> better to go with Debian Etch which has an actively maintained backport,
> rather than Hardy. We'd love to move to Hardy if this was sloved.
>
> Using whats already there for Debian (and now also recently for Interpid)
> it should be possible to put together a backport.
>

[Kristian Domke (kristian-neither-nor)]

The modules are not uptodate. If you want to use them, you have to use kernel 2.6.24-16-generic, not 2.6.24-22. So it is still preferrable to have the open vm tools in the ubuntu repositories.

[Jared (jared-thanhandjared)]

I too (three?four?) would like to see this backport made available. 804 was chosen on a number of production servers because of the LTS nature.

These servers only have ssh access which makes installing vmtools problematic (to the extend that some dont even have it installed, which makes the blade owners unhappy)

Please can this backport be approved and moved along.

[Matt Arnold (mattarnold5)]

Wouldn't it just be simpler to backport dh7 to Hardy, rather then converting open-vm-* to a lower dh version? Or are backports builds not allowed to pull in build-deps from *-backports suites? For a little before i did the hardy to intrepid upgrade I was building debhelper from sid with no source changes.

[erlguta (gonzalomarcote)]

I have the same problem. It is 2009 06-11 and still no news about this important (and simple to do) backport.
Nothing has been done yet...

[Greek Ordono (grexk)]

I maintain latest backport of open-vm-tools in https://launchpad.net/~grexk/+archive/ppa.

[Giles Westwood (giles-westwood)]

Quick note to help anyone installing this, I managed to get the open-vm-tools packages to install fine, tx Greek!

However the kernel modules didn't compile. There are various bug reports for various versions of the code. So I grabbed the latest package from Debian:-

http://packages.debian.org/sid/all/open-vm-source/download

and it compiled and loaded fine, you will need debhelper 7 from hardy backports though.

[Evan Broder (broder)]

It looks like this bug requests a backport from Ubuntu 8.10 (Intrepid
Ibex). However, as Intrepid is no longer supported, such a backport is
no longer possible.

This bug is being set to "Won't Fix". If you would still like to move
forward with this backport request, please re-open the bug and adjust
it to request a backport from a current release.

(This change is being made by an automated bot run by Evan Broder, who
is now subscribed to the bug; if you think the change was made in
error, please feel free to re-open the bug)