package open-vm-dkms 2011.03.28-387002-0ubuntu2 fails to build against 2.6.39 kernels, due to missing linux/smp_lock.h

I think I might have a fix to this. I requires and upgrade to the newest version (for May 2011). In the next few postings (Including this one) I will post the following:

-Upstream changelog
-Full package diff (from the one in Oneiric to mine)
-Diff for debian folder

After this, I will give info about what I posted, and the plan.

One notable change in the newer packaging is that the GUI (open-vm-toolbox) has been removed. I've commented out the lines in debian/rules to relate to the toolbox (which caused problems in the previous builds over the course of the past week). These commented lines will be removed this is all done, it's just a place holder.

I've uploaded a bzr branch (a working one, not the one we'll (or I'll) upload): https://code.launchpad.net/~n-muench/+junk/open-vm-tools-prep

I've also reopened my Virtual Test PPA (without the shared folders mount command): https://launchpad.net/~n-muench/+archive/virtual-test

I've done all can, so I need you guys to help me finish it up.

The Plan:
-I want to turn open-vm-toolbox into a transitional package for Oneiric. I'm not sure how you properly create a transitional package

Notes (I've tried it, but open-vm-toolbox doesn't install, everything else upgrades successfully):
-I can compile the kernel modules successfully (meaning I get no error, even with the issues with open-vm-toolbox in it's current form)
-Auto Screen Resize doesn't work properly after the upgrade (might be an issue with open-vm-toolbox). xrandr doesn't work to resize, even if your root.

Nate, your efforts are much appreciated and I'll be following them with great interest. While I still use the proprietary VMWare Tools [8.4.6 Build 385536] on my Ubuntu 11.04 guest [kernel 2.6.39-3], they seem to be quite broken on Debian Sid [kernel 2.6.39-1].

I was quite sure they would still build on the rc7 kernel for which Debian Unstable obliged me to create my own kbuild infrastructure (quite educational for a novice).

Since the Debian version, even in Unstable, is quite ancient [8.4.2-261024-1], I am becoming quite desperate.

Desperate enough to perhaps install an Ubuntu package on Debian ;-)

Cheers.

Don't use the ones in Debian unstable because they're using a kernel that requires a module (vmmemctl) in the Tools. The newer kernels (like the ones in Natty/Oneiric) have said module in the kernel.

Also as of right now, the Stable Tools (and the unstable ones currently in the repo) don't support the 2.6.39. Although, I guess Oneiric is going with the 3.0 Kernel (I just check the packages Launchpad page). So what I'm suggesting might be irrelevant.

As I said I've tried compiling the May 2011 release modules of open-vm-tools, and even with the issues with the open-vm-toolbox, I got all the modules SUCCESSFULLY compiled.

I have an update with the 3.0-0.1 packaging in Oneiric Repo.

-Modules successfully compiles (I used the packaging in my Virtual Test PPA)
-Auto Screen resolution works after a second reboot (once after compiling modules, and once more)

Has anyone made any process on packaging that has open-vm-toolbox as a transitional package?

I don't know if it's because I'm inpatient, or not, but I think I'm going to give this a try. I just got to make a small revision to the code (I got to uncomment a couple of lines). This will be done to the packaging, not the branch (not now, at least).

The revision (aka the uncommenting of lines) is so I have some sort of packaging (for open-vm-toolbox) to look at. So I can see what remains in the code after the removal of the GUI Toolbox.

This is the plan:
-Stuff that goes into the open-vm-toolbox package will go into the open-vm-tools package. At least the stuff that isn't commented out.
-All package dependencies for open-vm-toolbox will added to the open-vm-tools dependencies.
-Any other packages that require open-vm-toolbox, will point to the open-vm-tools package.

I should have almost finished product in a couple of days, for everyone to try. Will it work, I don't know? As a minimum, I would like open-vm-toolbox (transitional or not) to successfully install/update without any issues.

I'm done, I have attached the diff (full folder, patches not applied). I got a successful install/update, so I pushed it to the repo. The only issue is the Num lock does automatically turn on at boot.

I'm pushing the code shortly.

Nate, I believe you are on the right track.

I know this is not the type of feedback you need (or want) in this venue. After all, my virtual platform is Debian Sid, not Oneiric; and my kernel is 2.6.39-2, not 3.0-rc<x>. But the underlying problems seem to be from the same causes.

And I know all the dire warnings about installing Ubuntu binaries on Debian, or the reverse. But one of the reasons I virtualize non-production environments is so that I *can* screw them up ;-)

But the great news is that DKMS *finally* doesn't croak:

# dpkg -i *.deb

Selecting previously deselected package open-vm-dkms.

(Reading database ... 332857 files and directories currently installed.)
Unpacking open-vm-dkms (from open-vm-dkms_2011.05.27-420096-0~ppa9_all.deb) ...
dpkg: warning: downgrading open-vm-source from 1:8.4.2-261024-1 to 2011.05.27-420096-0~ppa9.
Preparing to replace open-vm-source 1:8.4.2-261024-1 (using open-vm-source_2011.05.27-420096-0~ppa9_all.deb) ...
Unpacking replacement open-vm-source ...
dpkg: warning: downgrading open-vm-toolbox from 1:8.4.2-261024-1 to 2011.05.27-420096-0~ppa9.
Preparing to replace open-vm-toolbox 1:8.4.2-261024-1 (using open-vm-toolbox_2011.05.27-420096-0~ppa9_amd64.deb) ...
Unpacking replacement open-vm-toolbox ...
dpkg: warning: downgrading open-vm-tools from 1:8.4.2-261024-1 to 2011.05.27-420096-0~ppa9.
Preparing to replace open-vm-tools 1:8.4.2-261024-1 (using open-vm-tools_2011.05.27-420096-0~ppa9_amd64.deb) ...
Stopping open-vm guest daemon: vmtoolsd.
Removing open-vm-tools modules: vmhgfs
WARNING: All config files need .conf: /etc/modprobe.d/options, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/ndiswrapper, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/blacklist-firewire, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/blacklist-extra, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/blacklist-amd76-edac, it will be ignored in a future release.
 vmmemctl
WARNING: All config files need .conf: /etc/modprobe.d/options, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/ndiswrapper, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/blacklist-firewire, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/blacklist-extra, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/blacklist-amd76-edac, it will be ignored in a future release.
FATAL: Module vmmemctl not found.
 vmsync
WARNING: All config files need .conf: /etc/modprobe.d/options, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/ndiswrapper, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/blacklist-firewire, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/blacklist-extra, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/blacklist-a...

If your virtual system is Debian sid, WHY ARE YOU COMMENTING HERE? This is an Ubuntu Oneiric bug report. If you have a issue with Debian, tell them about it.

Your bug report can be found here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629980

I'm going to upload refreshed diffs/patches of my work as it is now.

First, notes:
* Everything is working fine, except the Num Lock won't turn on after logging in.
* I've uploaded new packaging to my Virtual Test repo. When it succeeds, I'm going to push Natty Package. For a trial Natty-to-Oneiric upgrade of the package with Natty.
* I want to push this (the Proposal) to the main repo by (or after the release of) Alpha 3 (which will be the July packaging). This assumes nothing major changes (like the Toolbox (GUI) getting removed) for the June and July releases.
* This will allow me to do a clean install of my open-vm-tools packaging in Alpha 2. And the afore mentioned test to see if the new packaging upgrades successfully with Natty

Second, the refreshed package diffs (Part 1). These were done with my working repo and the packaging in the Oneiric (not the Oneiric branch). The Patches we're not applied.

These patches are very important, so pay attention.

Currently the Oneiric branch is very out of date/sync (understatement). Apparently some idiot (I know that's tasteless) never updated the branch with the packaging for Natty/Oneiric. The branch is only up to date with packaging for Maverick, which was uploaded by me.

The following patches were done by using the branch downloaded from Oneiric (which lacks the Natty/Oneiric code) and my working branch. When I do the branch proposal, the patch (enclosed with this comment/post), will be used to add my packaging as well as including the changes made for Natty (and the current Oneiric packaging).

I'd be happy to update the branches for Natty, so they're up to date.

I think that response was beneath you. PLEASE DO NOT USE ALL CAPS TO SHOUT AT ME. Don't worry, I won't bother you again.

I need some help. I'm attempting to update the package on my Ubuntu Natty (32-Bit) virtual machine, for a test Natty (2011.03.28-387002-0ubuntu1.1) to Oneiric (My packaging) update.

When I get the updated packages, open-vm-tools isn't checked. I removed open-vm-toolbox and/or update the other packages, open-vm-tools breaks.

I have my new packaging installed on my Oneiric VM, although I won't have a proper test until Alpha 2 comes out in 2 weeks.

Can someone (IS EVAN (Broder) OR ANYONE ELSE OUT THERE?) tell me if I'm doing this right?

My PPA (with the packaging): https://launchpad.net/~n-muench/+archive/virtual-test
My Working Branch: https://code.launchpad.net/~n-muench/+junk/open-vm-tools-prep

Both are synced, no differences between the PPA or the branch.

If you want me to refresh the diffs (which are out of date), I'd be happy to do that.

And I'm sorry for yelling at you.

Nate, I wish I was more than a newcomer; I'd gladly help you, since I am getting obsessed to an unhealthy and unnatural degree with making VMware work from am end-user perspective. I realize this is sick ;-)

If I weren't so frustrated that the Debian "package maintainers" seem to be indifferent, absent, clueless, or just paralyzed, I wouldn't have reached out to my Ubuntu brothers. Debian has had grave bug reports for at least four months on their totally obsolete, supposedly "latest" version of Tools and hasn't even classified any of them. Much less uploaded a new package to unstable or experimental.

So I was reaching out to you in desperation; I had you pegged as someone actively working to get a solution I could steal.

So while I'm sorry for treading on your ppa, I *have* successfully installed ppa9 in a "semi-Oneiric" Natty (basically a 3.0.1 kernel with as much of the internals and build infrasturucture upgraded as I can without breaking my desktop, which is fragile because, of course, VMware doesn't support direct-rendering in linux guests). DMKS built all modules without any problems whatsoever.

I would like only to observe that distro package maintainers have to look thought the eyes of the recipient to ensure that end-users will have a good experience. This is what I mean:

* Even if shared folders are always enabled in the host, the guest will not auto-mount them. Timing issues in loading the necessary modules makes using fstab problematic.

* Drag and Drop operations from the *host* to *guest* will fail because the open-vm-tools initialization does not seem to provide the necessary environment, and once created, that environment is volatile, since VMwareDnD has to be created in \tmp.

After doing some reading, I've modified the startup section of my /etc/init.d/open-vm-tools as follows (I make no claim about knowing what I'm doing, or that it is sufficiently general):

log_daemon_msg "mounting hgfs shares"
  mount -t vmhgfs .host:/ /mnt/hgfs
  log_end_msg 0
if [ ! -d /tmp/VMwareDnD ]
  then
   log_daemon_msg "making a directory on the guest to store files for DnD"
   mkdir /tmp/VMwareDnD
   chmod 1777 /tmp/VMwareDnD
   log_end_msg 0
fi
log_daemon_msg "mounting vmblock for DnD"
mount -t vmblock none /proc/fs/vmblock/mountPoint
log_end_msg 0

Source: http://sourceforge.net/apps/mediawiki/open-vm-tools/index.php?title=Packaging

I actually have Shared folders enabled in the open-vm-tools package (for Natty and (for the moment) Maverick) in my Programs PPA (it's one of 3 or 4 programs (this one, Calibre, tinyxml, and I think libpodofo) that I made changes to). It works nicely. And what you did is from a page that was last edited 2 years ago, so DnD might not exist, just like vmmemctl.

Also this project, to turn toolbox into a transitional package (or get rid of it all together, depending on what Evan or anyone else who has better knowledge about what I'm doing), is the biggest thing I've ever done (and I'm enjoying). And I look forward to merging it to the existing branch, and mark it as a proposal (anything short, would make me think I got screwed (aka you submitting the proposal, even though I put a lot of time into getting this to work)).

Before now, all I did was take someone else's work, and propose it for merging (which is currently in Maverick's Main Repo for the open-vm-tools package).

Thanks Nate for working on this. I am bumping this back to "In Progress" as a fix hasn't yet been merged or uploaded. I have marked it as a bug which should be resolved by Alpha 2, so it is being tracked.

@dj.palindrome, Thanks also for your confirmations; it is appreciated.

I'm refreshing the patches. This is the final product, at least until next week (when June packages is released). And assuming that that release is only bug fixes and no changes, I'll upload that (assuming it works). Every new version (under these conditions), until the freeze for Oneiric.

Notes:
-The Replaces and Breaks fields in open-vm-tools don't have version requirements (which might be wise because Debian is watching this bug report)
-When updating (with open-vm-toolbox installed), you'll get a distribution update.

When Alpha 2 comes out, I'm going to do an install of my packages (which build with m-a) and what's currently in Oneiric's Repos (which don't build with m-a). This will allow me to see where everything is, and make final changes to debian/rules before I delete the commented out lines, and create the proposal.

Thanks in advance for putting up with the observations of a clueless outsider ;-)

* The transitional-package approach, which I think is what you used for open-vm-toolbox in ppa15, worked nicely.

* The conflicting-package approach, which I think is what you are using for open-vm-toolbox in ppa19, achieves the same result, although with benign errors that can be ignored. This is probably just due to the way I had to install (using dpkg rather than apt or Synaptic).

* The most important thing, that DKMS actually works, has been true since the earliest ppa's and continues. GOD BLESS YOU!!

* Anything I said about initialization scripts or mounting is completely inappropriate and beyond the scope of this bug report and its resolution. I just didn't know who else would be listening to me ;-)

* I couldn't agree more that it is confusing to read documentation about vmmemctl and vmware-user that even *I* suspect are just no longer true. But I think the point about DnD is still valid because I've played with it. In other words, the observations are uninformed by knowledge, but empirical. I still suspect something is rotten in Denmark because a force-reload of my modified open-vm-tools script frequently fails (mount: mount point /proc/fs/vmblock/mountPoint does not exist). Loading vmblock is *supposed* to create /proc/fs/vmblock (it does) and two nodes therein (dev and mountPoint). The former it always does; the latter, not always.

As of right now, it looks like I'll be pushing the May release next weekend (which is when I plan on making the proposal). But a lot can change until Thursday.

Like I said, I plan on pushing each new release (assuming only bug fixes & cleanups) until the freeze.

For the first new release, I plan on removing some redundant manpages (I know of 3 that need to be removed: vmmemctl, vmxnet3 (both now in the kernel itself), and vmware-toolbox (removed from the package, the CLI version is still there). I think vmware-user should be renamed vmtoolsd, I need someone to confirm this. I will file a bug on this (ETA: Mid July), just so we know/confirm what needs to be removed/updated, in regards to the manpages, before I push the July release (?), in time for Alpha 3.

If there is more than just bug fixes and cleanups in the June/July release, I'll just push a second revision (to the May release), containing the changes to the manpages.

The June release was released a couple of hours ago, with cleanups and bug fixes. This should be noted in the changelog:
* A few enhancements to Unity: XFCE support, better interaction with "the other" (Ubuntu's) Unity and compositing window managers, better X error handling, and a few bug fixes.

I'm going to push the June release shortly to my Virtual Test PPA (or build it within the VM using pbuilder, and if built successful, I'll then push it to the repo). If all goes according to plan (aka builds and installs successfully), I'll push it to the working Repo, and maybe refresh the diffs.

Build failure, we'll be going with the May Release, unless someone can help fix the problem before Thursday (also, I encountered this issue when building (the package) on my Linux From Scratch VM)

I've attached the last few lines of my build (which includes the failure).

Ignore my last comment, that's pbuilder for you. It's currently building in my Virtual Test Repo.

I think the problem is with OpenSSL (or GCC). I Google pathlen, and the first result is relating with OpenSSL. All I know is the June release successfully builds with Natty (in my regular PPA), but fails with Oneiric.

So as it stands, this weekend, I push create the proposal for the May version. And unless someone has a fix for this problem, the May version is what Oneiric will have when released in October.

I pushed the old version (the one I'm going to push in a couple days) to my Regular PPA. If it builds successfully, we're in good shape. If it fails, well, we might have to hold off until Alpha 3, so EVAN (Broder) OR SOMEONE MORE FAMILIAR can get me a patch to fix the issue with GCC 4.6.x.

I guess we can't expect stuff like this. I should've pushed it last week, but just wanted until after Alpha 2 was released and install my packaging in a clean environment.

And, we have a failure, because of this:
fileStandAlone.c:223:17: error: variable 'pathLen' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

The Package (for the June version) successfully build in a Natty environment. The Virtual Test PPA still has the binaries for the May version (for Oneiric and Natty). So you may use those until we (this is a team effort now) can get something out that actually builds successfully with Oneiric because I will not submit something that fails to build.

I think this is going to be held off until Alpha 3. And because we have something that works (as it successfully built, works with the transitional Toolbox package), I can just create the proposal when we got that patch, and I got a successful build on my Repo.

I look a little look into a fix (via Google). But based on the other solutions, I've decided to wait because I might do more harm that good, and I have no clue on how to go any further with this kind of patch. I would like a patch by the weekend or this fix will unfortunately delayed until Alpha 3.

So, this will be the last comment until I get my answer (patch).

@Nate, thanks for your work on this so far. I didn't quite understand your last comment - are you looking for assistance, or are you doing ok?

Thanks.

I am looking for assistance.

Because apparently, the problem I'm having is a common one with GCC 4.6.x. This is the only thing preventing the package from being 100% ready for proposal.

I installed Alpha 2 and installed open-vm-tools package that built successfully (from May), before this all went to hell (thanks GCC 4.6).

It look good, I just need that patch for the issues with GCC 4.6 and I can push the June packaging. After I do a test build on my Virtual Test PPA, to make sure everything is good before I cleanup (remove my commented out lines) and create the proposal.

@Nate,

is lp:~n-muench/+junk/open-vm-tools-prep still the tree I should be looking at?

Yep

I think I'm kind of glad I waited to push it, if I hadn't, the next person to push this packaging (probably me) would have the problem with GCC 4.6.x.

Just a quick note, the tree is still for the May Release. The actual proposal (the plan, at least) will be for the June release (after I/we test it) because of the improvements for Unity.

The GCC patch for May will work for June, so just get me a patch for May, and we'll work from there.

I'm going to update my tree shortly. Just to incorporate the changes in 2011.03.28-387002-0ubuntu4, so that things don't become unfixed when I push my proposal.

I just making changes in the debian/manpages folder, and the changelog.

I just want to note that someone has opened a bug about the build failures with the newest packaging.

Said bug is #807903 and I've added a line to the changelog. There is no patch name because I don't know what's it going to called.

@Serge, over the last couple of days, I've only made changes to the debian folder (merging 2011.03.28-387002-0ubuntu4, and the GCC line in the changelog)

@Nate

(ignore my last email, obviously it is all about those errors)

I'll hold off and see your proposed fix. I suspect though that the thing to do is engage upstream in getting all those errors fixed. Some of them are obvious, but with others we need to at least look a the function whose result is being assigned to the otherwise-unused variable, and make sure we don't depend on any side effects in that fn.

Anyway, I think you're saying you ahve this about licked, so I'll wait until you either post your patch proposal, or tell me I misunderstood and I should proceed.

I may have a patch, I found it on the bug tracker on their sourceforge page. It's for the stable 8.4.2 version, but I think I can adapt it for my purpose.

Although when I push it to my Virtual Test Repo, I'm probably going to have to use my Natty machine because my Oneiric Virtual Machine is on the fritz (damn GDM), and I got no GUI.

So, Stand by.

Done, I'm going to add the file to Oneiric via the Natty Live CD.

The first file is my adapted patch (Based on June Release).
The second is the original patch (from 8.4.2 bug report)

Just pushed to my Virtual Test PPA. This doesn't have 2011.03.28-387002-0ubuntu4 because as I said, I can't access the GUI on my Oneiric Alpha 2 VM because of the GDM freezing up. And I can't create pbuilder environment (apparently debootstrap is being a pain in the ass), so we'll have to wait 5 hours to see if the patch works. I'm saying there is a 40% that it'll work.

If Successful, I'm going to copy the source to my regular PPA and rebuild for Natty, just because.

The Original Bug Report: http://sourceforge.net/tracker/?func=detail&aid=3354213&group_id=204462&atid=989708

The report was closed for being "out of date." And it was kind of was, but I adapted it (sans one section that said it was only for 8.4.2, which is why I say 40%). And the patch was made for Fedora 15, which has GCC 4.6.0.

We have another failure, but we made it further.

hgfsChannelGuestBd.c:596:19: error: variable 'packetOut' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

File is located:
/lib/hgfsServerManagerGuest/hgfsChannelGuestBd.c

@Nate,

are you using your ppa to compile each time? Which irc channel can I find you on to chat? I'm serue on #ubuntu-devel on freenode.

I'm using my Virtual Test (https://launchpad.net/~n-muench/+archive/virtual-test/+packages) mainly because, as I said, I'm currently having issues creating pbuilder environment in the Oneiric Alpha 2 VM (1st time I've had issues).

I'll come to #ubuntu-devel shortly

I did a little compiling on my LFS system, and I think I found our problem points.

Below is everything we need to fix before the package will build successfully (I think). First line is folders. The last section is similar to one that's already fixed, but I'm not going to take any chances.

lib/hgfsServerManagerGuest
hgfsChannelGuestBd.c:596:19: error: variable 'packetOut' set but not used

lib/misc
vthreadBase.c:965:23: error: variable 'key' set but not used
vthreadBase.c:961:9: error variable 'result' set but not used

lib/rpcIn
rpcin.c:569:17: error: variable 'current' set but not used
rpcin.c:568:9: error: variable 'resched' set but not used

lib/slashProc
net.c:857:11: error: variable 'nmatched' set but not used

So there we go, 4 files that need to be patched and we can hopefully get a successful build against GCC 4.6.1.

We got a successful build, I've attached the patch.

Also, Someone double check my work. I want to be sure that it's 100% safe, because I did it with base knowledge. So some parts might be wrong (I'm concerned about vixTools and the posixAttributeSpecified fix).

Tomorrow, I'll probably update the branch to June (since this is what the patch is based on).

Now that we got a package that builds successfully, I'm going to layout the plan.

-Later today: Update the branch to June release (including adding the new patch attached in the comment above)
-By Sunday: Input on anything that needs to changed in the patch. Stuff that may cause issues, and can be improved upon.
-Monday or Tuesday: Create the proposal, and commit it. As I said before, if approved, I want the main branch updated (if possible, Oneiric's branch still shows my work for Maverick's release)

As I said before, I plan on pushing the July and August releases (if no major changes). The August release will (as of now) have the vmmemctl, vmxnet3, and the vmware-toolbox (NOT vmware-toolbox-cmd) manpages removed since those components no longer exist. The former 2 are now in the kernel itself.

So I have an idea, how about when i push the forthcoming releases, any issues with my patch can be fixed with that released.

I've lost auto screen resize and host/guest copy-and-paste. They worked before the upgrade. So, the plan is now thrown out. The following files (in the patch) need to be double checked if I did it right. I WILL NOT GO ANY FURTHER WITHOUT ANY HELP. I've done 95%, the remaining 5% in your court.

-lib/hgfsServerManagerGuest/hgfsChannelGuestBd.c
-lib/misc/vthreadBase.c
-lib/rpcIn/rpcin.c
-lib/slashProc/net.c
-services/plugins/vix/vixTools.c

I will however push the June release into the open-vm-tools-prep, since the patch is based on it.

Once more, as soon as I get confirmation that the 5 lines stated above look good, no proposal will be created.

I just want to note that, a couple of hours ago, I pushed the patched May release (listed as the June release) to see if it was the June release or the Patch (hell even the new kernel update) was the issues.

So the final analysis is it's the patch. I think I screwed up, somewhere, and it't up to you (I mean it this time, I've done all I can), with your better knowledge of this kind of stuff.

Thanks for all your work on this, Nate. I'm out the rest of this week, but will look at this on Monday.

---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

@Serge

Am I correct to assume that you will now create the proposal (aka push it)? Or am I still on for creating the Proposal?

Confirmed: Packaged broke with GCC 4.6.1-1ubuntu1. I found this in the Debian changelog (for 4.6.1-1):
* Stop passing -Wno-error=unused-but-set-parameter and
  -Wno-error=unused-but-set-variable if -Werror is present.
  This was a temporary workaround introduced in 4.6.0~rc1-2. Closes: #615157.

Just wanted to point this out.

@Nate,

I've updated your packaging a bit, with the resulting debs in

http://people.canonical.com/~serge/open-vm-tools_2011.06.27-amd64-debs.tgz

and the source at

lp:~serge-hallyn/ubuntu/oneiric/open-vm-tools/open-vm-tools-june/

Unfortunately I do not have vmware workstation available for testing. Could you try it out?

I've pushed it to my Virtual Test Repo, I'll try it in a couple of hours, after I install updates (so I have a snapshot to fall back on if I have issues).

@Serge, am I correct to assume (based on the changelog) that I will be creating the proposal.

@Nate

no, don't worry about it - I will push it (once confirmed that it works), but since you did most of the work I will keep your name on the changelog.

I got results
host-guest Copy-and-Paste: Still not working.
Auto Screen Resize: Doesn't work

@Serge
I thought when you said you'd look at it, I thought you meant the patch. My original configuration works 100% fine (I've confirmed this with May), the patch is where work is needed. The reason everything is breaking is because OF THE PATCH.

THE PATCH IS WHERE WORK NEEDS TO BE DONE ON, NOT THE PACKAGING.

I suggest we wait a couple of weeks until the new version for July is released, which might have some compatibility with GCC 4.6.x.

Attached is the patch (from GCC 4.6.0), that was removed beginning with GCC 4.6.1-1. The removal of this patch caused the problems we are currently having.

Lastly, I've opened a bug report over on SourceForge, to see whether they'll do anything:
https://sourceforge.net/tracker/?func=detail&aid=3370770&group_id=204462&atid=989708

Quoting Nate Muench (<email address hidden>):
> I got results
> host-guest Copy-and-Paste: Still not working.
> Auto Screen Resize: Doesn't work
>
> @Serge
> I thought when you said you'd look at it, I thought you meant the patch.

I thought you said earlier that you were confident in the patch and wanted help with the packaging :)

> My original configuration works 100% fine (I've confirmed this with May), the patch is where work is needed. The reason everything is breaking is because OF THE PATCH.

Can you confirm that compiling the June release, with your packaging, compiled with older gcc (maybe built under natty), also works? The git tree has seen a lot of churn. Commits like 8bb81e03780f936a4d3f04def07e3d467bf30c01 (which admittedly was end of april) are very suspect as they change how open-vm-tools are used.

> THE PATCH IS WHERE WORK NEEDS TO BE DONE ON, NOT THE PACKAGING.

The patch may break things, but your bzr tree (as fetched today) was not in fact building for me.

Thanks for the feedback. Sounds like I'll need to find a version of vmware I can use for really testing, and per your advice I'll start by looking more closely at the patch.

-serge

I suggest we wait to see what how they respond to my bug report over on SourceForge.

Quoting Nate Muench (<email address hidden>):
> I suggest we wait to see what how they respond to my bug report over on
> SourceForge.

Agreed, that seems sensible. They know the code best :)

thanks,
-serge

(Removing myself as assignee to make sure noone feels they shouldn't feel free to jump in. I'll re-take it after gauging sf response)

I'm sure you've already seen today's drop in SF [2011.07.19-450511] which supposedly fixes the gcc compilation issues, so I won't torture you gentlemen further.

I see new code related to FUSE blocking filesystems which they don't talk about, probably because it's coming from upstream, and VMware corporate has tied their hands.

I don't know who I feel sorrier for, you or them.

I know about it because a) I reported the bug about it on SourceForge, b) I pushed the updated packaging to my Virtual Test PPA and my branch about an hour ago.

And when the build is successful (and I've tested it out), I'll create the proposal.

There still appears to be issues with the packaging. I've filed another bug on SourceForge (https://sourceforge.net/tracker/?func=detail&aid=3373006&group_id=204462&atid=989708)

I am about to push new packaging that adds "-Wno-unused-but-set-variable" to the CFLAGS (in debian/rules). This comes at the suggestion of one of the developers over at SF. This hopes to solve issues with GCC 4.6.x.

Finally, after a month of issues (mainly with GCC), we finally have a package that works 100%. It's not ready to be pushed yet, there are a couple of things I need to do with it yet.

I'm in the process of creating the proposal, will be out within moments. I'm going forward with my plan to get rid of the obsolete manpages.

@Serge, Just make changes to my changelog (if needed). Don't touch the debian/rules file because as it stands right now EVERYTHING (and I mean everything) WORKS. Shared Folders, host/guest copy-and-paste, and auto-screen resize all work (for once). If someone opens a bug (the operative word being IF), we'll deal with it.

@Nate

thanks. Your bzr trees (both of the ones linked) again do not build, because of some missing files. I've pulled your source package from your ppa into lp:~serge-hallyn/ubuntu/oneiric/open-vm-tools/nmuench-jul25.1 , and that does build fine. Please give it a quick look/diff to make sure I pulled the right thing, and then I'll ask someone to sponsor.

How does it not build? My branch and the packaging (in my PPA) are exactly the same (excluding some changes in changelog and the removal of my commented out lines in debian/rules).

@Serge I want a build log, please.

Quoting Nate Muench (<email address hidden>):
> How does it not build? My branch and the packaging (in my PPA) are
> exactly the same (excluding some changes in changelog and the removal of
> my commented out lines in debian/rules).

No they are not. Please re-fetch the bzr tree and do a diff. There are
missing files.

# dget https://launchpad.net/~n-muench/+archive/virtual-test/+files/open-vm-tools_2011.07.19-450511-0%7Eppa3.dsc
# bzr branch lp:~n-muench/ubuntu/oneiric/open-vm-tools/open-vm-tools.fix-july
# rm -rf open-vm-tools.fix-july/.bzr
# dpkg-source -x open-vm-tools_2011.07.19-450511-0%7Eppa3.dsc
# diff -Nrup open-vm-tools-2011.07.19-450511 open-vm-tools.fix-july | diffstat
    debian/changelog | 9
    debian/rules | 22
    docs/api/services/main.doxy | 55 --
    lib/file/fileStandAlone.c | 767 -------------------------------
    lib/file/fileTemp.c | 370 --------------
    lib/file/fileTempPosix.c | 576 -----------------------
    lib/include/vmware/tools/log.h | 184 -------
    modules/linux/shared/compat_log2.h | 60 --
    services/plugins/dndcp/copyPasteCompat.c | 171 ------
    services/plugins/unity/toolsPlugin.cpp | 206 --------
    10 files changed, 3 insertions(+), 2417 deletions(-)

> @Serge I want a build log, please.

# cd open-vm-tools.fix-july
# fakeroot debian/rules build > ~/failbuild 2>&1

(log attached) Notice it fails because it is missing lib/file/fileStandAlone.c
which is not in your bzr tree.

Never mind on the build log. I'm going to push my proposed branch (zero changes, except root folder name, the changelog, and removal of .bzr folder) to my regular PPA (no orig.tar.gz or diff.gz). And we'll see who's right, see you in around 4 hours (when the amd64 build suppose to be done).

@Nate, It seems probable that your bzr tree has missing files, in that they haven't been added to bzr. $ bzr status , should probably confirm this. If you are debuild -S -sa, to push to your PPA then the files will be present in the package you upload the PPA.

If you use "bzr bd -S" to produce a source package, then you'll probably find the files are missing.

Additionally, I'd ask that you please ensure that you keep this polite. I asked Serge to help get your changes into Ubuntu, and he is clearly trying his best to help - but the files do indeed seem missing. There is no need to see "who is right", he is helping.

If we can this resolved now, we can probably get it in Oneiric before your PPA is finished.

Thanks.

@Dave,

The source coming from

 dget https://launchpad.net/~n-muench/+archive/virtual-test/+files/open-vm-tools_2011.07.19-450511-0%7Eppa3.dsc

looks good to me, builds great, and is tested by Nate. Do you mind sponsoring it? :) Changelog just needs the version changed to not reflect ppa.

This bug was fixed in the package open-vm-tools - 2011.07.19-450511-0ubuntu1

---------------
open-vm-tools (2011.07.19-450511-0ubuntu1) oneiric; urgency=low

  * Merge latest upstream git tag. Fixes Building on Oneiric
    (LP: #776103, LP: #807903)

  * The Toolbox (GUI) has been removed.
  * Changes in debian folder:
    - Contents of open-vm-toolbox.lintian-overrides have been moved to
      open-vm-tools.lintian-overrides.
    - The contents of open-vm-toolbox.manpages (excluding the first line,
      which relates to the Toolbox) have been moved to open-vm-tools.manpages.
  * Changes in debian/control:
    - Convert open-vm-toolbox into a transitional package.
    - All dependencies for toolbox have been moved to open-vm-tools package.
    - Changed architecture for open-vm-toolbox package to all.
    - Added Replaces and Breaks fields to open-vm-tools.
  * Changes in debian/rules:
    - Commented out references to the Toolbox (GUI), that no longer exist
      in the package itself.
    - Remaining references changed from open-vm-toolbox to open-vm-tools.
    - Added -Wno-unused-but-set-variable to CFLAGS to suppress remaining
      issues with GCC 4.6.0 or later.
  * Files removed in debian/manpages:
    - vmmemctl.9 (Component no longer in package)
    - vmware-toolbox.1 (Component removed in this release)
    - vmxnet3.9 (vmxnet3 is now included in kernel itself)
 -- Nate Muench <email address hidden> Fri, 22 Jul 2011 16:41:03 -0500

@Dave, @Serge. I integrated my packaging into the branch via a diff patch (much easier than doing it manually). I used the following command to create the diff "diff -Naurp --exclude=.bzr <the existing branch> <my packaging>".

What would be the correct options to make a more accurate patch (so everything is added)?

I will create a new proposal, with a better diff (created with the proper options).

I'm sorry.

Never mind.

We finally got packaging. And I did 99% of the work, which I didn't expect, but I feel better and smarter because of the work I did on this (main the removal of the Toolbox GUI).

Now, I'm going to work on some packages that need to be transitioned to dh_python2 (thanks Ubuntu Developer Week).

@Nate

It's no problem, Daviey has pushed your package based on the ppa contents.

Once you have a working .dsc, the easiest way to import that into a bzr tree is using

   bzr import-dsc

Otherwise, any time after hand-applying a patch, you can do

   bzr status

to see a list of both which files are modified, and which are unknown, i.e.:

# serge@sergelap:~/bzr/principia-tools$ bzr status
unknown:
  cd
  foo

Unknown source files can then be added by doing

   bzr add cd foo

before committing.

Lastly, for the next full upstream release merge 'bzr merge-upstream' might be the easiest thing to do, but I've not used it myself. 'bzr help merge-upstream' shows its usage.

Thanks.

Dave forgot to remove my commented out lines in debian/rules.

I might fix that when I push the next release (if there is time left)

@Nate, Gah - thanks.

If you want to raise a new bug documenting the debian/rules issues, we'll treat it as a separate bug.

Thanks.

@Nate -

I hate to rain on your parade here, as it looks like it was quite a struggle to get everything working right for this package (and certainly, thanks a lot for your efforts).

The introduction of X11 dependencies into what is ostensibly a CLI package is not a good thing for those of us who have server systems which should not have X11.

Please review bug #604998, and bug #391224 which put that situation in place (as well as Debian bug 561639, where that change was immediately rejected) - a --no-install-recommends workaround worked, except for those of us who wanted to automate the install with something like puppet.

This change, to merge the X11 support components into the CLI tools package, has taken that situation from bad to worse, and has rendered this package completely unusable on systems that must not have X11 - I'm surprised that this change moved forward after bug #604998 was confirmed. Please think of the servers!