Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 336963

Summary:	create.product action fails with: The action chmod failed - launcher.svn-base does not exist
Product:	z_Archived	Reporter:	Matthew Webber <matthew>
Component:	Buckminster	Assignee:	buckminster.core-inbox <buckminster.core-inbox>
Status:	NEW ---	QA Contact:
Severity:	major
Priority:	P3	CC:	bernard.sarter, eiswind, gunnar, josh.hester, matthew, richardfearn, thomas, vroldanbet
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Matthew Webber

2011-02-11 11:27:22 EST

Build Identifier: 

Original problem description: http://www.eclipse.org/forums/index.php?t=msg&th=162306&S=f2718ea92cfddb6ad2facf25d57bf9d4#msg_513258.

Buckminster is used to create a standard p2 site for all platforms, and then the director is called to install the feature as a product for a particular paltform. This is all standard (as per http://www.ralfebert.de/blog/eclipsercp/rcp_builds/).

This means the following buckminster commands are executed:
perform -Dtarget.os=* -Dtarget.ws=* -Dtarget.arch=* -Dqualifier.replacement.*=generator:lastRevision -Dcbi.include.source=false uk.ac.diamond.sda.site#site.p2

perform -Dtarget.os=linux -Dtarget.ws=gtk -Dtarget.arch=x86 -Diu=uk.ac.diamond.scisoft uk.ac.diamond.sda.site#create.product.zip

The create.product.zip fails as follows:
[ant] An error occurred while installing the items
[ant]  session context was:(profile=SciSoft, phase=org.eclipse.equinox.internal.p2.engine.phases.Install, operand=null --> [R]uk.ac.diamond.scisoft.product.executable.gtk.linux.x86 1.0.0, action=org.eclipse.equinox.internal.p2.touchpoint.natives.actions.ChmodAction).
[ant]  The action chmod failed - file /tmp/uk.ac.diamond.sda.site/scisoft/uk.ac.diamond.sda.site_1.0.0-eclipse.feature/scisoft.gtk.linux.x86/launcher.svn-base does not exist

WHat appears to happen is that the target platform, target/features/org.eclipse.equinox.executable_3.4.1.R36x_v20100823-7M7K7JF90dnJ-WLf3cf4yi/bin/gtk/linux/x86/ is copied to ${buckminster.output.root}/uk.ac.diamond.sda.site_1.0.0-eclipse.feature/scisoft.gtk.linux.x86.

The original report encountered the problem when running create.product from the Eclipse IDE. I got the problem running Buckminster headless.
However, the target platform was originally checked out from a subversion repository, so it contains a .svn/ sub-directory. I'm guessing that the .svn/ sub-directory was not copied to the buckminster.output.root, but that the list of files built for the chmod operation does not realise that hidden files were skipped.




Reproducible: Always

Comment 1 Thomas Hallgren

2011-02-15 08:34:15 EST

I'm not able to reproduce this. I haven't tried explicitly with the executable feature but I did try with the buckminster.pde.test project. The root files are copied correctly. .svn is excluded correctly. No chmod is produced in the p2 metadata for the things below the .svn folder.

What version of Eclipse is used?

Comment 2 Matthew Webber

2011-02-15 12:10:03 EST

(In reply to comment #1)
> I'm not able to reproduce this. I haven't tried explicitly with the executable
> feature but I did try with the buckminster.pde.test project. The root files are
> copied correctly. .svn is excluded correctly. No chmod is produced in the p2
> metadata for the things below the .svn folder.
> 
> What version of Eclipse is used?

This is with Eclipse 3.6 headless Buckminster. It should be the latest version, I donwloaded it on 31/Jan/2011.

I note that the original mention of this problem (on the forums, not in bugzilla) was in the IDE - that message was a while ago, so I'm guessing 3.5.

I'll re-check everything and see if I can see any special features of my install that might be a factor. I should mention up front that my target platform defintion specifies mutiple directories, and the eclipse part of the target is not the first mentioned.

Comment 3 Matthew Webber

2011-02-16 05:51:03 EST

(In reply to comment #1)
> I'm not able to reproduce this. I haven't tried explicitly with the executable
> feature but I did try with the buckminster.pde.test project. The root files are
> copied correctly. .svn is excluded correctly. No chmod is produced in the p2
> metadata for the things below the .svn folder.
> 
> What version of Eclipse is used?

I have confirmed that the problem also happens in the Eclipse IDE - this is Eclipse 3.6.1 with org.eclipse.buckminster.core.feature at 1.3.1.r11660.

I run the build on Linux. If I build for win32, there are no problems. If I then look in ${buckminster.output.root}/uk.ac.diamond.sda.site_1.0.0-eclipse.feature/, I see 4 subdirectories - scisoft.win32.win32.x86, site, site.pw, temp.

Looking in scisoft.win32.win32.x86, I see that it does have a subdirectory called .svn, which I'm guessing should not be there.

Building for linux, the euqivalent directory ${buckminster.output.root}/uk.ac.diamond.sda.site_1.0.0-eclipse.feature/scisoft.gtk.linux.x86 does *NOT* have a .svn subdirctory (which is wha I would expect), but of course that's what is causing the chmod to trip up.

I'm not sure what is the best way for me to help you diagnose this. I could provide you with a zipped up workspace to repeoduce the problem with, but it's fairly large (just under 1GB, though I could possibly trim it a bit).

Comment 4 Matthew Webber

2011-02-22 08:18:02 EST

I am currently circumventing the problem by moving the .svn directory elsewhere before the #create.product.zip action, and then moving it back afterwards.

Comment 5 Victor Roldan Betancort

2011-03-24 13:27:12 EDT

Hey guys, any news on this? It appears you are you having problems to reproduce it. 

It seems not trivial to create a test-case for this, so the only recommendation I can give is to share your delta-pack folder (which is included in your target platform) on SVN. I do check out the sources using Hudson SVN plugin, not Buckminster SVN feature...

Dont hesitate asking for more information!

Comment 6 Thomas Kratz

2011-05-05 04:29:10 EDT

I see the same trouble with my build.

Comment 7 Gunnar Wagenknecht

2011-07-28 08:18:45 EDT

Same problem here when invoking Buckminster via Hudson plug-in on a Linux Hudson machine (Buckminster and Java is configured to be installed automatically).

Comment 8 Bernard Sarter

2011-09-22 10:54:17 EDT

(In reply to comment #7)
> Same problem here when invoking Buckminster via Hudson plug-in on a Linux
> Hudson machine (Buckminster and Java is configured to be installed
> automatically).

Same problem too, with Buckminster 3.7 and Jenkins (with latest svn plugin 1.32) on a Windows PC; The proposed workaround is Ok.

Comment 9 Josh Hester

2011-11-03 09:39:37 EDT

Is there any target date on this?

Comment 10 Bernard Sarter

2011-12-13 09:01:05 EST

(In reply to comment #9)
> Is there any target date on this?


I don't know, but I guess that as soon as Jenkins SVN plugin will be compatible with SVN 1.7 (early 2012 ?), the problem will no longer be an issue, since all those .svn folders should no longer exist with the new SVN check-out design ...

Comment 11 Bernard Sarter

2012-05-14 05:42:28 EDT

With Jenkins 1.463 and Subversion plugin 1.40 (first version supporting the new SVN 1.7 working copy format) this bug is no longer visible ... because local .svn files are no longer existing.