You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mahout.apache.org by Grant Ingersoll <gs...@apache.org> on 2009/10/23 23:12:23 UTC

Re: TAR problems

Hey Benson,

Do you know how to turn this on the release profile?

I put in:
<plugin>
             <artifactId>maven-assembly-plugin</artifactId>
             <configuration>
               <descriptorRefs>
                 <descriptorRef>project</descriptorRef>
               </descriptorRefs>
               <tarLongFileMode>gnu</tarLongFileMode>
             </configuration>
             <executions>
               <execution>
                 <id>make-assembly</id>
                 <!-- this is used for inheritance merges -->
                 <phase>package</phase>
                 <!-- append to the packaging phase. -->
                 <goals>
                   <goal>single</goal>
                   <!-- goals == mojos -->
                 </goals>
                 <configuration>
                   <tarLongFileMode>gnu</tarLongFileMode>
                 </configuration>
               </execution>
             </executions>
           </plugin>

but I am still getting:
  Failed to create assembly: Error creating assembly archive project:  
Problem creating TAR: request to write '0' bytes exceeds size in  
header of '-1535663957' bytes


-Grant

On Jul 16, 2009, at 10:48 AM, Benson Margulies wrote:

> Do you have long mode turned on?
>
> On Thu, Jul 16, 2009 at 10:01 AM, Grant  
> Ingersoll<gs...@apache.org> wrote:
>> Anyone else seeing: Failed to create assembly: Error creating  
>> assembly
>> archive project: Problem creating TAR: request to write '0' bytes  
>> exceeds
>> size in header of '-1535663957' bytes
>>
>> when doing mvn install.  I know the problem has to do with TAR.   
>> I'm just
>> wondering if we should switch to JAR/Zip packaging only, instead of
>> tarballs.
>>



Re: TAR problems

Posted by Grant Ingersoll <gs...@apache.org>.
On Oct 24, 2009, at 2:25 PM, Sean Owen wrote:

> Just to coordinate our efforts --
>
> I tried forcing DNS resolution of svn.apache.org to US servers. Same
> results. I eventually reach this error:
>
> svn: Path 'https://svn.apache.org/repos/asf/lucene/mahout/tags/ 
> mahout-0.2'
> does not exist in revision 829426
>
> and no amount of svn update or repeating release:prepare does the  
> trick.
>
>
> Grant, am I right in thinking you are getting past this part? if so,
> I'd judge it more important to figure out how you can move ahead so we
> can finally get a release out of this. (And then return to figuring
> out why it doesn't work here.)
>
>
> Looks like it is a question of enabling this
> <tarLongFileMode>gnu</tarLongFileMode> in the release profile.  One
> thing I don't see is where this whole release profile is defined --
> assume it's external, but where?


This is in the top level pom.xml under the <profile> section.  It is  
already defined there.

>
> As an aside, what in the process is creating a 2+GB tar file??
>
>
>
>
> On Sat, Oct 24, 2009 at 12:08 PM, Grant Ingersoll  
> <gs...@apache.org> wrote:
>> It looks like it is picking it up:
>>  Configuring mojo
>> 'org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-2:single'  
>> -->
>> [INFO] [DEBUG]   (s) appendAssemblyId = true
>> [INFO] [DEBUG]   (f) attach = true
>> [INFO] [DEBUG]   (s) basedir = .../projects/lucene/mahout/mahout- 
>> clean
>> [INFO] [DEBUG]   (s) descriptorRefs = [Ljava.lang.String;@1cf7cbd1
>> [INFO] [DEBUG]   (f) dryRun = false
>> [INFO] [DEBUG]   (s) finalName = mahout-0.2
>> [INFO] [DEBUG]   (f) ignoreDirFormatExtensions = false
>> [INFO] [DEBUG]   (s) ignoreMissingDescriptor = false
>> [INFO] [DEBUG]   (s) includeSite = false
>> [INFO] [DEBUG]   (s) localRepository = [local] ->
>> file:///Volumes/User/grantingersoll/.m2/repository
>> [INFO] [DEBUG]   (s) outputDirectory =
>> .../projects/lucene/mahout/mahout-clean/target
>> [INFO] [DEBUG]   (f) project = MavenProject:  
>> org.apache.mahout:mahout:0.2 @
>> .../projects/lucene/mahout/mahout-clean/pom.xml
>> [INFO] [DEBUG]   (s) reactorProjects = [MavenProject:
>> org.apache.mahout:mahout:0.2 @
>> .../projects/lucene/mahout/mahout-clean/pom.xml, MavenProject:
>> org.apache.mahout:mahout-parent:0.2 @
>> .../projects/lucene/mahout/mahout-clean/maven/pom.xml, MavenProject:
>> org.apache.mahout:mahout-core:0.2 @
>> .../projects/lucene/mahout/mahout-clean/core/pom.xml, MavenProject:
>> org.apache.mahout:mahout-taste-webapp:0.2 @
>> .../projects/lucene/mahout/mahout-clean/taste-web/pom.xml,  
>> MavenProject:
>> org.apache.mahout:mahout-utils:0.2 @
>> .../projects/lucene/mahout/mahout-clean/utils/pom.xml, MavenProject:
>> org.apache.mahout:mahout-examples:0.2 @
>> .../projects/lucene/mahout/mahout-clean/examples/pom.xml]
>> [INFO] [DEBUG]   (f) remoteRepositories = [[codehausSnapshots] ->
>> http://snapshots.maven.codehaus.org/maven2, [apacheSnapshots] ->
>> http://people.apache.org/maven-snapshot-repository/,  
>> [apache.snapshots] ->
>> http://repository.apache.org/snapshots, [central] ->
>> http://repo1.maven.org/maven2]
>> [INFO] [DEBUG]   (s) siteDirectory =
>> .../projects/lucene/mahout/mahout-clean/target/site
>> [INFO] [DEBUG]   (f) skipAssembly = false
>> [INFO] [DEBUG]   (s) tarLongFileMode = gnu
>> [INFO] [DEBUG]   (s) tempRoot =
>> .../projects/lucene/mahout/mahout-clean/target/archive-tmp
>> [INFO] [DEBUG]   (s) workDirectory =
>> .../projects/lucene/mahout/mahout-clean/target/assembly/work
>>
>> On Oct 23, 2009, at 8:54 PM, Benson Margulies wrote:
>>
>>> https://svn.apache.org/repos/asf/cxf/trunk/distribution/pom.xml
>>>
>>>
>>> It's not in a profile here, since we condition the entire  
>>> distribution
>>> module on a release profile. It should work just the same if the
>>> plugin spec is inside a profile.
>>>
>>> I note that ours has only config in the execution, none at top- 
>>> level.
>>>
>>> mvn -X might also be informative.
>>>
>>>
>>> On Fri, Oct 23, 2009 at 5:12 PM, Grant Ingersoll
>>> <gs...@apache.org>wrote:
>>>
>>>> Hey Benson,
>>>>
>>>> Do you know how to turn this on the release profile?
>>>>
>>>> I put in:
>>>> <plugin>
>>>>          <artifactId>maven-assembly-plugin</artifactId>
>>>>          <configuration>
>>>>            <descriptorRefs>
>>>>              <descriptorRef>project</descriptorRef>
>>>>            </descriptorRefs>
>>>>            <tarLongFileMode>gnu</tarLongFileMode>
>>>>          </configuration>
>>>>          <executions>
>>>>            <execution>
>>>>              <id>make-assembly</id>
>>>>              <!-- this is used for inheritance merges -->
>>>>              <phase>package</phase>
>>>>              <!-- append to the packaging phase. -->
>>>>              <goals>
>>>>                <goal>single</goal>
>>>>                <!-- goals == mojos -->
>>>>              </goals>
>>>>              <configuration>
>>>>                <tarLongFileMode>gnu</tarLongFileMode>
>>>>              </configuration>
>>>>            </execution>
>>>>          </executions>
>>>>        </plugin>
>>>>
>>>> but I am still getting:
>>>> Failed to create assembly: Error creating assembly archive project:
>>>> Problem creating TAR: request to write '0' bytes exceeds size in  
>>>> header
>>>> of
>>>> '-1535663957' bytes
>>>>
>>>>
>>>> -Grant
>>>>
>>>> On Jul 16, 2009, at 10:48 AM, Benson Margulies wrote:
>>>>
>>>> Do you have long mode turned on?
>>>>>
>>>>> On Thu, Jul 16, 2009 at 10:01 AM, Grant Ingersoll<gsingers@apache.org 
>>>>> >
>>>>> wrote:
>>>>>
>>>>>> Anyone else seeing: Failed to create assembly: Error creating  
>>>>>> assembly
>>>>>> archive project: Problem creating TAR: request to write '0' bytes
>>>>>> exceeds
>>>>>> size in header of '-1535663957' bytes
>>>>>>
>>>>>> when doing mvn install.  I know the problem has to do with  
>>>>>> TAR.  I'm
>>>>>> just
>>>>>> wondering if we should switch to JAR/Zip packaging only,  
>>>>>> instead of
>>>>>> tarballs.
>>>>>>
>>>>>>
>>>>
>>>>
>>
>> --------------------------
>> Grant Ingersoll
>> http://www.lucidimagination.com/
>>
>> Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids)  
>> using
>> Solr/Lucene:
>> http://www.lucidimagination.com/search
>>
>>

--------------------------
Grant Ingersoll
http://www.lucidimagination.com/

Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids)  
using Solr/Lucene:
http://www.lucidimagination.com/search


Re: TAR problems

Posted by Benson Margulies <bi...@gmail.com>.
It look like the 'remoteTagging' business from the symptoms reported.

On Mon, Oct 26, 2009 at 4:02 PM, Grant Ingersoll <gs...@apache.org>wrote:

> I think I see the problem
>
>
> On Oct 26, 2009, at 3:22 PM, Grant Ingersoll wrote:
>
>  Progress:
>> [INFO] [INFO] Mahout utilities ......................................
>> SUCCESS [15.683s]
>> [INFO] [INFO] Mahout examples .......................................
>> SUCCESS [52.623s]
>> [INFO] [INFO]
>> ------------------------------------------------------------------------
>> [INFO] [INFO]
>> ------------------------------------------------------------------------
>> [INFO] [INFO] BUILD SUCCESSFUL
>> [INFO] [INFO]
>> ------------------------------------------------------------------------
>> [INFO] [INFO] Total time: 8 minutes 28 seconds
>> [INFO] [INFO] Finished at: Mon Oct 26 13:52:29 EDT 2009
>> [INFO] [INFO] Final Memory: 115M/215M
>> [INFO] [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Checking in modified POMs...
>> [INFO] Executing: /bin/sh -c cd /private/tmp/trunk && svn --username
>> gsingers --non-interactive commit --file
>> /var/folders/3x/3xFVg3xW2RW7Yk+1YwUrt++++TI/-Tmp-/maven-scm-1640749809.commit
>> --targets
>> /var/folders/3x/3xFVg3xW2RW7Yk+1YwUrt++++TI/-Tmp-/maven-scm-3688595680751142028-targets
>> [INFO] Working directory: /private/tmp/trunk
>> [INFO] Tagging release with the label mahout-0.2...
>> [INFO] Executing: /bin/sh -c cd /private/tmp/trunk && svn --username
>> gsingers --non-interactive copy --file
>> /var/folders/3x/3xFVg3xW2RW7Yk+1YwUrt++++TI/-Tmp-/maven-scm-1845067920.commit
>> --revision 829879
>> https://svn.apache.org/repos/asf/lucene/mahout/tags/mahout-0.2
>> https://svn.apache.org/repos/asf/lucene/mahout/tags/mahout-0.2
>> [INFO] Working directory: /private/tmp/trunk
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] BUILD FAILURE
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Unable to tag SCM
>> Provider message:
>> The svn tag command failed.
>> Command output:
>> svn: Path 'https://svn.apache.org/repos/asf/lucene/mahout/tags/mahout-0.2'
>> does not exist in revision 829879
>>
>>
>>
>> Not sure why it can't create the tag, as the previous commit works.
>>  Something to do w/ that --revision flag I suspect.
>>
>> -Grant
>>
>> On Oct 26, 2009, at 1:52 PM, Benson Margulies wrote:
>>
>>  If you are stuck, and you want to give me a brevette promotion to
>>> committer,
>>> I'll make some time to try and cook this in the next few evenings.
>>>
>>> On Mon, Oct 26, 2009 at 12:32 PM, Grant Ingersoll <gsingers@apache.org
>>> >wrote:
>>>
>>>  What happens if you run with mvn -e -X
>>>>
>>>> Here's how I've been running:
>>>> mvn -Prelease,mahout_release release:prepare     // I've updated the
>>>> Wiki
>>>>
>>>> In my settings.xml, I have:
>>>> <profile>
>>>>   <id>mahout_release</id>
>>>>
>>>>   <properties>
>>>>     <gpg.passphrase>*****</gpg.passphrase>
>>>>     <deploy.altRepository>mahout.releases::default::scp://
>>>> people.apache.org/home/gsingers/public_html/staging-repo
>>>> /mahout</deploy.altRepository>
>>>>     <username>...</username>
>>>>     <user.name>...</user.name>
>>>>     <deploy.url>scp://people.apache.org/home/gsingers/public_html/
>>>> staging-repo/mahout</deploy.url>
>>>>   </properties>
>>>>  </profile>
>>>>
>>>>
>>>>
>>>> http://www.google.com/search?q=gpg%3A+signing+failed%3A+General+Error&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
>>>>  might
>>>> be of interest.
>>>>
>>>> Sean, can you summarize your errors on your local machine?  I don't want
>>>> to
>>>> rely on p.a.o for doing builds.
>>>>
>>>> Also, are you able to sign other files on your machine (foo.txt) using
>>>> GPG,
>>>> as in: gpg -s foo.txt
>>>>
>>>> What version of GPG do you have?
>>>>
>>>>
>>>>
>>>> On Oct 26, 2009, at 7:58 AM, Sean Owen wrote:
>>>>
>>>> Ah, I see how that works now. I was using the apache-release profile
>>>>
>>>>> but it also needed to be configured with <gpg.keyname> as well.
>>>>>
>>>>> (Actually I found I needed to run my own gpg-agent too -- "eval
>>>>> 'gpg-agent --daemon'" -- anyone think that sounds wrong? checking
>>>>> before I add it to the wiki.)
>>>>>
>>>>> I now get:
>>>>>
>>>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>>> [INFO] gpg: WARNING: "--no-use-agent" is an obsolete option - it has no
>>>>> effect
>>>>> [INFO] Warning: using insecure memory!
>>>>>
>>>>> You need a passphrase to unlock the secret key for
>>>>> user: "Sean Owen <sr...@apache.org>"
>>>>> 4096-bit RSA key, ID 021F6670, created 2009-10-16
>>>>>
>>>>> [INFO] gpg: cancelled by user
>>>>> [INFO] gpg: skipped "Sean Owen": General error
>>>>> [INFO] gpg: signing failed: General error
>>>>>
>>>>>
>>>>> Is that not the right keyname? that previously worked locally (where I
>>>>> had to supply the passphrase manually). I tried "Sean Owen" too with
>>>>> the same result.
>>>>>
>>>>> So our build instructions also talk about this mahout_release profile,
>>>>> which doesn't seem to be used? is that out of date?
>>>>>
>>>>>
>>>>> We seem to be stuck just in the release process in three different
>>>>> ways. Grant is stuck on long-mode and the release profile or
>>>>> something. I am both stuck on this gpg issue on people.apache.org, and
>>>>> on some possible svn.apache.org problem locally.
>>>>>
>>>>> I've done about a full day of head-banging on this and am ready to
>>>>> throw in the towel. If we are truly dead in the water with the release
>>>>> process... is there any kind soul to appeal to here?
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Oct 26, 2009 at 7:21 AM, Isabel Drost <is...@apache.org>
>>>>> wrote:
>>>>>
>>>>>  On Mon Sean Owen <sr...@gmail.com> wrote:
>>>>>>
>>>>>>  I don't know enough about GPG to know whether I should be seeing this
>>>>>>> at all (since my passphrase is already in settings.xml?) or how else
>>>>>>> this is supposed to work? does anyone see this?
>>>>>>>
>>>>>>>
>>>>>> You shouldn't be asked for the password if you set it in your
>>>>>> settings.xml and are using the profile you set it in for building.
>>>>>>
>>>>>> So, if your setting.xml says:
>>>>>>
>>>>>> <profiles>
>>>>>> <profile>
>>>>>> <id>apache-release</id>
>>>>>> <properties>
>>>>>>    <gpg.passphrase>*********</gpg.passphrase>
>>>>>> </properties>
>>>>>> </profile>
>>>>>> </profiles
>>>>>>
>>>>>> and you are building with mvn -Papache-release <goal> you shouldn't be
>>>>>> asked for the password.
>>>>>>
>>>>>> Isabel
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com/
>
> Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using
> Solr/Lucene:
> http://www.lucidimagination.com/search
>
>

Re: TAR problems

Posted by Sean Owen <sr...@gmail.com>.
That's great, since it likely means I can get past this point too. I
will abandon my experiment on p.a.o.

Sean

On Mon, Oct 26, 2009 at 9:00 PM, Grant Ingersoll <gs...@apache.org> wrote:
> Success.  Trying release:perform now.

Re: TAR problems

Posted by Grant Ingersoll <gs...@apache.org>.
Success.  Trying release:perform now.


On Oct 26, 2009, at 4:53 PM, Grant Ingersoll wrote:

>
> On Oct 26, 2009, at 4:44 PM, Grant Ingersoll wrote:
>
>>
>> On Oct 26, 2009, at 4:28 PM, Sean Owen wrote:
>>
>>> Good, since this is exactly where I am stuck. Do tell!
>>
>> I think it has to do w/ the <scm> tag in the pom.xml.  I just  
>> checked in a change and am trying it now.
>
> OK, pretty sure it is now due to the developerConnection setting:
> <scm>
>    <connection>scm:svn:https://svn.apache.org/repos/asf/lucene/ 
> mahout/trunk</connection>
>    <developerConnection>scm:svn:https://svn.apache.org/repos/asf/ 
> lucene/mahout/trunk</developerConnection>
>    <url>https://svn.apache.org/repos/asf/lucene/mahout/mahout</url>
>  </scm>
>
> That was set to mahout-0.2, which is what Maven uses as the source  
> for the copy command, which of course doesn't exist since that is  
> what we are trying to create.  I changed it to be what you see above  
> and am running now.
>
> Note, we can't both run release:prepare at the same time, so I can  
> take it for now and put up an RC, then you can do the same and then  
> we can vote on your artifacts.
>
> -Grant
>
>>
>>>
>>> What's the remoteTagging business, and is there any workaround other
>>> using US servers, which didn't seem to do it for me, from London.
>>>
>>> On Mon, Oct 26, 2009 at 8:02 PM, Grant Ingersoll <gsingers@apache.org 
>>> > wrote:
>>>> I think I see the problem
>>>>
>>
>
>



Re: TAR problems

Posted by Grant Ingersoll <gs...@apache.org>.
On Oct 26, 2009, at 4:44 PM, Grant Ingersoll wrote:

>
> On Oct 26, 2009, at 4:28 PM, Sean Owen wrote:
>
>> Good, since this is exactly where I am stuck. Do tell!
>
> I think it has to do w/ the <scm> tag in the pom.xml.  I just  
> checked in a change and am trying it now.

OK, pretty sure it is now due to the developerConnection setting:
<scm>
     <connection>scm:svn:https://svn.apache.org/repos/asf/lucene/ 
mahout/trunk</connection>
     <developerConnection>scm:svn:https://svn.apache.org/repos/asf/ 
lucene/mahout/trunk</developerConnection>
     <url>https://svn.apache.org/repos/asf/lucene/mahout/mahout</url>
   </scm>

That was set to mahout-0.2, which is what Maven uses as the source for  
the copy command, which of course doesn't exist since that is what we  
are trying to create.  I changed it to be what you see above and am  
running now.

Note, we can't both run release:prepare at the same time, so I can  
take it for now and put up an RC, then you can do the same and then we  
can vote on your artifacts.

-Grant

>
>>
>> What's the remoteTagging business, and is there any workaround other
>> using US servers, which didn't seem to do it for me, from London.
>>
>> On Mon, Oct 26, 2009 at 8:02 PM, Grant Ingersoll  
>> <gs...@apache.org> wrote:
>>> I think I see the problem
>>>
>



Re: TAR problems

Posted by Grant Ingersoll <gs...@apache.org>.
On Oct 26, 2009, at 4:28 PM, Sean Owen wrote:

> Good, since this is exactly where I am stuck. Do tell!

I think it has to do w/ the <scm> tag in the pom.xml.  I just checked  
in a change and am trying it now.

>
> What's the remoteTagging business, and is there any workaround other
> using US servers, which didn't seem to do it for me, from London.
>
> On Mon, Oct 26, 2009 at 8:02 PM, Grant Ingersoll  
> <gs...@apache.org> wrote:
>> I think I see the problem
>>


Re: TAR problems

Posted by Sean Owen <sr...@gmail.com>.
Good, since this is exactly where I am stuck. Do tell!

What's the remoteTagging business, and is there any workaround other
using US servers, which didn't seem to do it for me, from London.

On Mon, Oct 26, 2009 at 8:02 PM, Grant Ingersoll <gs...@apache.org> wrote:
> I think I see the problem
>

Re: TAR problems

Posted by Grant Ingersoll <gs...@apache.org>.
I think I see the problem

On Oct 26, 2009, at 3:22 PM, Grant Ingersoll wrote:

> Progress:
> [INFO] [INFO] Mahout  
> utilities ...................................... SUCCESS [15.683s]
> [INFO] [INFO] Mahout  
> examples ....................................... SUCCESS [52.623s]
> [INFO] [INFO]  
> ------------------------------------------------------------------------
> [INFO] [INFO]  
> ------------------------------------------------------------------------
> [INFO] [INFO] BUILD SUCCESSFUL
> [INFO] [INFO]  
> ------------------------------------------------------------------------
> [INFO] [INFO] Total time: 8 minutes 28 seconds
> [INFO] [INFO] Finished at: Mon Oct 26 13:52:29 EDT 2009
> [INFO] [INFO] Final Memory: 115M/215M
> [INFO] [INFO]  
> ------------------------------------------------------------------------
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd /private/tmp/trunk && svn --username  
> gsingers --non-interactive commit --file /var/folders/3x/ 
> 3xFVg3xW2RW7Yk+1YwUrt++++TI/-Tmp-/maven-scm-1640749809.commit -- 
> targets /var/folders/3x/3xFVg3xW2RW7Yk+1YwUrt++++TI/-Tmp-/maven- 
> scm-3688595680751142028-targets
> [INFO] Working directory: /private/tmp/trunk
> [INFO] Tagging release with the label mahout-0.2...
> [INFO] Executing: /bin/sh -c cd /private/tmp/trunk && svn --username  
> gsingers --non-interactive copy --file /var/folders/3x/3xFVg3xW2RW7Yk 
> +1YwUrt++++TI/-Tmp-/maven-scm-1845067920.commit --revision 829879 https://svn.apache.org/repos/asf/lucene/mahout/tags/mahout-0.2 
>  https://svn.apache.org/repos/asf/lucene/mahout/tags/mahout-0.2
> [INFO] Working directory: /private/tmp/trunk
> [INFO]  
> ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [INFO]  
> ------------------------------------------------------------------------
> [INFO] Unable to tag SCM
> Provider message:
> The svn tag command failed.
> Command output:
> svn: Path 'https://svn.apache.org/repos/asf/lucene/mahout/tags/ 
> mahout-0.2' does not exist in revision 829879
>
>
>
> Not sure why it can't create the tag, as the previous commit works.   
> Something to do w/ that --revision flag I suspect.
>
> -Grant
>
> On Oct 26, 2009, at 1:52 PM, Benson Margulies wrote:
>
>> If you are stuck, and you want to give me a brevette promotion to  
>> committer,
>> I'll make some time to try and cook this in the next few evenings.
>>
>> On Mon, Oct 26, 2009 at 12:32 PM, Grant Ingersoll <gsingers@apache.org 
>> >wrote:
>>
>>> What happens if you run with mvn -e -X
>>>
>>> Here's how I've been running:
>>> mvn -Prelease,mahout_release release:prepare     // I've updated  
>>> the Wiki
>>>
>>> In my settings.xml, I have:
>>> <profile>
>>>    <id>mahout_release</id>
>>>
>>>    <properties>
>>>      <gpg.passphrase>*****</gpg.passphrase>
>>>      <deploy.altRepository>mahout.releases::default::scp://
>>> people.apache.org/home/gsingers/public_html/staging-repo
>>> /mahout</deploy.altRepository>
>>>      <username>...</username>
>>>      <user.name>...</user.name>
>>>      <deploy.url>scp://people.apache.org/home/gsingers/public_html/
>>> staging-repo/mahout</deploy.url>
>>>    </properties>
>>>  </profile>
>>>
>>>
>>> http://www.google.com/search?q=gpg%3A+signing+failed%3A+General+Error&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a 
>>>  might
>>> be of interest.
>>>
>>> Sean, can you summarize your errors on your local machine?  I  
>>> don't want to
>>> rely on p.a.o for doing builds.
>>>
>>> Also, are you able to sign other files on your machine (foo.txt)  
>>> using GPG,
>>> as in: gpg -s foo.txt
>>>
>>> What version of GPG do you have?
>>>
>>>
>>>
>>> On Oct 26, 2009, at 7:58 AM, Sean Owen wrote:
>>>
>>> Ah, I see how that works now. I was using the apache-release profile
>>>> but it also needed to be configured with <gpg.keyname> as well.
>>>>
>>>> (Actually I found I needed to run my own gpg-agent too -- "eval
>>>> 'gpg-agent --daemon'" -- anyone think that sounds wrong? checking
>>>> before I add it to the wiki.)
>>>>
>>>> I now get:
>>>>
>>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>> [INFO] gpg: WARNING: "--no-use-agent" is an obsolete option - it  
>>>> has no
>>>> effect
>>>> [INFO] Warning: using insecure memory!
>>>>
>>>> You need a passphrase to unlock the secret key for
>>>> user: "Sean Owen <sr...@apache.org>"
>>>> 4096-bit RSA key, ID 021F6670, created 2009-10-16
>>>>
>>>> [INFO] gpg: cancelled by user
>>>> [INFO] gpg: skipped "Sean Owen": General error
>>>> [INFO] gpg: signing failed: General error
>>>>
>>>>
>>>> Is that not the right keyname? that previously worked locally  
>>>> (where I
>>>> had to supply the passphrase manually). I tried "Sean Owen" too  
>>>> with
>>>> the same result.
>>>>
>>>> So our build instructions also talk about this mahout_release  
>>>> profile,
>>>> which doesn't seem to be used? is that out of date?
>>>>
>>>>
>>>> We seem to be stuck just in the release process in three different
>>>> ways. Grant is stuck on long-mode and the release profile or
>>>> something. I am both stuck on this gpg issue on  
>>>> people.apache.org, and
>>>> on some possible svn.apache.org problem locally.
>>>>
>>>> I've done about a full day of head-banging on this and am ready to
>>>> throw in the towel. If we are truly dead in the water with the  
>>>> release
>>>> process... is there any kind soul to appeal to here?
>>>>
>>>>
>>>>
>>>> On Mon, Oct 26, 2009 at 7:21 AM, Isabel Drost <is...@apache.org>  
>>>> wrote:
>>>>
>>>>> On Mon Sean Owen <sr...@gmail.com> wrote:
>>>>>
>>>>>> I don't know enough about GPG to know whether I should be  
>>>>>> seeing this
>>>>>> at all (since my passphrase is already in settings.xml?) or how  
>>>>>> else
>>>>>> this is supposed to work? does anyone see this?
>>>>>>
>>>>>
>>>>> You shouldn't be asked for the password if you set it in your
>>>>> settings.xml and are using the profile you set it in for building.
>>>>>
>>>>> So, if your setting.xml says:
>>>>>
>>>>> <profiles>
>>>>> <profile>
>>>>> <id>apache-release</id>
>>>>> <properties>
>>>>>     <gpg.passphrase>*********</gpg.passphrase>
>>>>> </properties>
>>>>> </profile>
>>>>> </profiles
>>>>>
>>>>> and you are building with mvn -Papache-release <goal> you  
>>>>> shouldn't be
>>>>> asked for the password.
>>>>>
>>>>> Isabel
>>>>>
>>>>>
>>>
>
>

--------------------------
Grant Ingersoll
http://www.lucidimagination.com/

Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids)  
using Solr/Lucene:
http://www.lucidimagination.com/search


Re: TAR problems

Posted by Grant Ingersoll <gs...@apache.org>.
Progress:
[INFO] [INFO] Mahout utilities ......................................  
SUCCESS [15.683s]
[INFO] [INFO] Mahout examples .......................................  
SUCCESS [52.623s]
[INFO] [INFO]  
------------------------------------------------------------------------
[INFO] [INFO]  
------------------------------------------------------------------------
[INFO] [INFO] BUILD SUCCESSFUL
[INFO] [INFO]  
------------------------------------------------------------------------
[INFO] [INFO] Total time: 8 minutes 28 seconds
[INFO] [INFO] Finished at: Mon Oct 26 13:52:29 EDT 2009
[INFO] [INFO] Final Memory: 115M/215M
[INFO] [INFO]  
------------------------------------------------------------------------
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /private/tmp/trunk && svn --username  
gsingers --non-interactive commit --file /var/folders/3x/3xFVg3xW2RW7Yk 
+1YwUrt++++TI/-Tmp-/maven-scm-1640749809.commit --targets /var/folders/ 
3x/3xFVg3xW2RW7Yk+1YwUrt++++TI/-Tmp-/maven-scm-3688595680751142028- 
targets
[INFO] Working directory: /private/tmp/trunk
[INFO] Tagging release with the label mahout-0.2...
[INFO] Executing: /bin/sh -c cd /private/tmp/trunk && svn --username  
gsingers --non-interactive copy --file /var/folders/3x/3xFVg3xW2RW7Yk 
+1YwUrt++++TI/-Tmp-/maven-scm-1845067920.commit --revision 829879 https://svn.apache.org/repos/asf/lucene/mahout/tags/mahout-0.2 
  https://svn.apache.org/repos/asf/lucene/mahout/tags/mahout-0.2
[INFO] Working directory: /private/tmp/trunk
[INFO]  
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]  
------------------------------------------------------------------------
[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Path 'https://svn.apache.org/repos/asf/lucene/mahout/tags/ 
mahout-0.2' does not exist in revision 829879



Not sure why it can't create the tag, as the previous commit works.   
Something to do w/ that --revision flag I suspect.

-Grant

On Oct 26, 2009, at 1:52 PM, Benson Margulies wrote:

> If you are stuck, and you want to give me a brevette promotion to  
> committer,
> I'll make some time to try and cook this in the next few evenings.
>
> On Mon, Oct 26, 2009 at 12:32 PM, Grant Ingersoll  
> <gs...@apache.org>wrote:
>
>> What happens if you run with mvn -e -X
>>
>> Here's how I've been running:
>> mvn -Prelease,mahout_release release:prepare     // I've updated  
>> the Wiki
>>
>> In my settings.xml, I have:
>> <profile>
>>     <id>mahout_release</id>
>>
>>     <properties>
>>       <gpg.passphrase>*****</gpg.passphrase>
>>       <deploy.altRepository>mahout.releases::default::scp://
>> people.apache.org/home/gsingers/public_html/staging-repo
>> /mahout</deploy.altRepository>
>>       <username>...</username>
>>       <user.name>...</user.name>
>>       <deploy.url>scp://people.apache.org/home/gsingers/public_html/
>> staging-repo/mahout</deploy.url>
>>     </properties>
>>   </profile>
>>
>>
>> http://www.google.com/search?q=gpg%3A+signing+failed%3A+General+Error&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a 
>>  might
>> be of interest.
>>
>> Sean, can you summarize your errors on your local machine?  I don't  
>> want to
>> rely on p.a.o for doing builds.
>>
>> Also, are you able to sign other files on your machine (foo.txt)  
>> using GPG,
>> as in: gpg -s foo.txt
>>
>> What version of GPG do you have?
>>
>>
>>
>> On Oct 26, 2009, at 7:58 AM, Sean Owen wrote:
>>
>> Ah, I see how that works now. I was using the apache-release profile
>>> but it also needed to be configured with <gpg.keyname> as well.
>>>
>>> (Actually I found I needed to run my own gpg-agent too -- "eval
>>> 'gpg-agent --daemon'" -- anyone think that sounds wrong? checking
>>> before I add it to the wiki.)
>>>
>>> I now get:
>>>
>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>> [INFO] gpg: WARNING: "--no-use-agent" is an obsolete option - it  
>>> has no
>>> effect
>>> [INFO] Warning: using insecure memory!
>>>
>>> You need a passphrase to unlock the secret key for
>>> user: "Sean Owen <sr...@apache.org>"
>>> 4096-bit RSA key, ID 021F6670, created 2009-10-16
>>>
>>> [INFO] gpg: cancelled by user
>>> [INFO] gpg: skipped "Sean Owen": General error
>>> [INFO] gpg: signing failed: General error
>>>
>>>
>>> Is that not the right keyname? that previously worked locally  
>>> (where I
>>> had to supply the passphrase manually). I tried "Sean Owen" too with
>>> the same result.
>>>
>>> So our build instructions also talk about this mahout_release  
>>> profile,
>>> which doesn't seem to be used? is that out of date?
>>>
>>>
>>> We seem to be stuck just in the release process in three different
>>> ways. Grant is stuck on long-mode and the release profile or
>>> something. I am both stuck on this gpg issue on people.apache.org,  
>>> and
>>> on some possible svn.apache.org problem locally.
>>>
>>> I've done about a full day of head-banging on this and am ready to
>>> throw in the towel. If we are truly dead in the water with the  
>>> release
>>> process... is there any kind soul to appeal to here?
>>>
>>>
>>>
>>> On Mon, Oct 26, 2009 at 7:21 AM, Isabel Drost <is...@apache.org>  
>>> wrote:
>>>
>>>> On Mon Sean Owen <sr...@gmail.com> wrote:
>>>>
>>>>> I don't know enough about GPG to know whether I should be seeing  
>>>>> this
>>>>> at all (since my passphrase is already in settings.xml?) or how  
>>>>> else
>>>>> this is supposed to work? does anyone see this?
>>>>>
>>>>
>>>> You shouldn't be asked for the password if you set it in your
>>>> settings.xml and are using the profile you set it in for building.
>>>>
>>>> So, if your setting.xml says:
>>>>
>>>> <profiles>
>>>> <profile>
>>>>  <id>apache-release</id>
>>>>  <properties>
>>>>      <gpg.passphrase>*********</gpg.passphrase>
>>>>  </properties>
>>>> </profile>
>>>> </profiles
>>>>
>>>> and you are building with mvn -Papache-release <goal> you  
>>>> shouldn't be
>>>> asked for the password.
>>>>
>>>> Isabel
>>>>
>>>>
>>



Re: TAR problems

Posted by Benson Margulies <bi...@gmail.com>.
If you are stuck, and you want to give me a brevette promotion to committer,
I'll make some time to try and cook this in the next few evenings.

On Mon, Oct 26, 2009 at 12:32 PM, Grant Ingersoll <gs...@apache.org>wrote:

> What happens if you run with mvn -e -X
>
> Here's how I've been running:
>  mvn -Prelease,mahout_release release:prepare     // I've updated the Wiki
>
> In my settings.xml, I have:
> <profile>
>      <id>mahout_release</id>
>
>      <properties>
>        <gpg.passphrase>*****</gpg.passphrase>
>        <deploy.altRepository>mahout.releases::default::scp://
> people.apache.org/home/gsingers/public_html/staging-repo
> /mahout</deploy.altRepository>
>        <username>...</username>
>        <user.name>...</user.name>
>        <deploy.url>scp://people.apache.org/home/gsingers/public_html/
> staging-repo/mahout</deploy.url>
>      </properties>
>    </profile>
>
>
> http://www.google.com/search?q=gpg%3A+signing+failed%3A+General+Error&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a might
> be of interest.
>
> Sean, can you summarize your errors on your local machine?  I don't want to
> rely on p.a.o for doing builds.
>
> Also, are you able to sign other files on your machine (foo.txt) using GPG,
> as in: gpg -s foo.txt
>
> What version of GPG do you have?
>
>
>
> On Oct 26, 2009, at 7:58 AM, Sean Owen wrote:
>
>  Ah, I see how that works now. I was using the apache-release profile
>> but it also needed to be configured with <gpg.keyname> as well.
>>
>> (Actually I found I needed to run my own gpg-agent too -- "eval
>> 'gpg-agent --daemon'" -- anyone think that sounds wrong? checking
>> before I add it to the wiki.)
>>
>> I now get:
>>
>> [INFO] [INFO] [gpg:sign {execution: default}]
>> [INFO] gpg: WARNING: "--no-use-agent" is an obsolete option - it has no
>> effect
>> [INFO] Warning: using insecure memory!
>>
>> You need a passphrase to unlock the secret key for
>> user: "Sean Owen <sr...@apache.org>"
>> 4096-bit RSA key, ID 021F6670, created 2009-10-16
>>
>> [INFO] gpg: cancelled by user
>> [INFO] gpg: skipped "Sean Owen": General error
>> [INFO] gpg: signing failed: General error
>>
>>
>> Is that not the right keyname? that previously worked locally (where I
>> had to supply the passphrase manually). I tried "Sean Owen" too with
>> the same result.
>>
>> So our build instructions also talk about this mahout_release profile,
>> which doesn't seem to be used? is that out of date?
>>
>>
>> We seem to be stuck just in the release process in three different
>> ways. Grant is stuck on long-mode and the release profile or
>> something. I am both stuck on this gpg issue on people.apache.org, and
>> on some possible svn.apache.org problem locally.
>>
>> I've done about a full day of head-banging on this and am ready to
>> throw in the towel. If we are truly dead in the water with the release
>> process... is there any kind soul to appeal to here?
>>
>>
>>
>> On Mon, Oct 26, 2009 at 7:21 AM, Isabel Drost <is...@apache.org> wrote:
>>
>>> On Mon Sean Owen <sr...@gmail.com> wrote:
>>>
>>>> I don't know enough about GPG to know whether I should be seeing this
>>>> at all (since my passphrase is already in settings.xml?) or how else
>>>> this is supposed to work? does anyone see this?
>>>>
>>>
>>> You shouldn't be asked for the password if you set it in your
>>> settings.xml and are using the profile you set it in for building.
>>>
>>> So, if your setting.xml says:
>>>
>>> <profiles>
>>>  <profile>
>>>   <id>apache-release</id>
>>>   <properties>
>>>       <gpg.passphrase>*********</gpg.passphrase>
>>>   </properties>
>>>  </profile>
>>> </profiles
>>>
>>> and you are building with mvn -Papache-release <goal> you shouldn't be
>>> asked for the password.
>>>
>>> Isabel
>>>
>>>
>

Re: TAR problems

Posted by Grant Ingersoll <gs...@apache.org>.
What happens if you run with mvn -e -X

Here's how I've been running:
  mvn -Prelease,mahout_release release:prepare     // I've updated the  
Wiki

In my settings.xml, I have:
<profile>
       <id>mahout_release</id>
       <properties>
         <gpg.passphrase>*****</gpg.passphrase>
         <deploy.altRepository>mahout.releases::default::scp://people.apache.org/home/gsingers/public_html/staging-repo 
/mahout</deploy.altRepository>
         <username>...</username>
         <user.name>...</user.name>
         <deploy.url>scp://people.apache.org/home/gsingers/public_html/ 
staging-repo/mahout</deploy.url>
       </properties>
     </profile>

http://www.google.com/search?q=gpg%3A+signing+failed%3A+General+Error&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a 
  might be of interest.

Sean, can you summarize your errors on your local machine?  I don't  
want to rely on p.a.o for doing builds.

Also, are you able to sign other files on your machine (foo.txt) using  
GPG, as in: gpg -s foo.txt

What version of GPG do you have?


On Oct 26, 2009, at 7:58 AM, Sean Owen wrote:

> Ah, I see how that works now. I was using the apache-release profile
> but it also needed to be configured with <gpg.keyname> as well.
>
> (Actually I found I needed to run my own gpg-agent too -- "eval
> 'gpg-agent --daemon'" -- anyone think that sounds wrong? checking
> before I add it to the wiki.)
>
> I now get:
>
> [INFO] [INFO] [gpg:sign {execution: default}]
> [INFO] gpg: WARNING: "--no-use-agent" is an obsolete option - it has  
> no effect
> [INFO] Warning: using insecure memory!
>
> You need a passphrase to unlock the secret key for
> user: "Sean Owen <sr...@apache.org>"
> 4096-bit RSA key, ID 021F6670, created 2009-10-16
>
> [INFO] gpg: cancelled by user
> [INFO] gpg: skipped "Sean Owen": General error
> [INFO] gpg: signing failed: General error
>
>
> Is that not the right keyname? that previously worked locally (where I
> had to supply the passphrase manually). I tried "Sean Owen" too with
> the same result.
>
> So our build instructions also talk about this mahout_release profile,
> which doesn't seem to be used? is that out of date?
>
>
> We seem to be stuck just in the release process in three different
> ways. Grant is stuck on long-mode and the release profile or
> something. I am both stuck on this gpg issue on people.apache.org, and
> on some possible svn.apache.org problem locally.
>
> I've done about a full day of head-banging on this and am ready to
> throw in the towel. If we are truly dead in the water with the release
> process... is there any kind soul to appeal to here?
>
>
>
> On Mon, Oct 26, 2009 at 7:21 AM, Isabel Drost <is...@apache.org>  
> wrote:
>> On Mon Sean Owen <sr...@gmail.com> wrote:
>>> I don't know enough about GPG to know whether I should be seeing  
>>> this
>>> at all (since my passphrase is already in settings.xml?) or how else
>>> this is supposed to work? does anyone see this?
>>
>> You shouldn't be asked for the password if you set it in your
>> settings.xml and are using the profile you set it in for building.
>>
>> So, if your setting.xml says:
>>
>> <profiles>
>>  <profile>
>>    <id>apache-release</id>
>>    <properties>
>>        <gpg.passphrase>*********</gpg.passphrase>
>>    </properties>
>>  </profile>
>> </profiles
>>
>> and you are building with mvn -Papache-release <goal> you shouldn't  
>> be
>> asked for the password.
>>
>> Isabel
>>


Re: TAR problems

Posted by Benson Margulies <bi...@gmail.com>.
It's kind of hard to do release management without commit access. I've done
releases for two other Apache projects, but I think I've sent along all the
suggestions I can make from the sidelines.


On Mon, Oct 26, 2009 at 7:58 AM, Sean Owen <sr...@gmail.com> wrote:

> Ah, I see how that works now. I was using the apache-release profile
> but it also needed to be configured with <gpg.keyname> as well.
>
> (Actually I found I needed to run my own gpg-agent too -- "eval
> 'gpg-agent --daemon'" -- anyone think that sounds wrong? checking
> before I add it to the wiki.)
>
> I now get:
>
> [INFO] [INFO] [gpg:sign {execution: default}]
> [INFO] gpg: WARNING: "--no-use-agent" is an obsolete option - it has no
> effect
> [INFO] Warning: using insecure memory!
>
> You need a passphrase to unlock the secret key for
> user: "Sean Owen <sr...@apache.org>"
> 4096-bit RSA key, ID 021F6670, created 2009-10-16
>
> [INFO] gpg: cancelled by user
> [INFO] gpg: skipped "Sean Owen": General error
> [INFO] gpg: signing failed: General error
>
>
> Is that not the right keyname? that previously worked locally (where I
> had to supply the passphrase manually). I tried "Sean Owen" too with
> the same result.
>
> So our build instructions also talk about this mahout_release profile,
> which doesn't seem to be used? is that out of date?
>
>
> We seem to be stuck just in the release process in three different
> ways. Grant is stuck on long-mode and the release profile or
> something. I am both stuck on this gpg issue on people.apache.org, and
> on some possible svn.apache.org problem locally.
>
> I've done about a full day of head-banging on this and am ready to
> throw in the towel. If we are truly dead in the water with the release
> process... is there any kind soul to appeal to here?
>
>
>
> On Mon, Oct 26, 2009 at 7:21 AM, Isabel Drost <is...@apache.org> wrote:
> > On Mon Sean Owen <sr...@gmail.com> wrote:
> >> I don't know enough about GPG to know whether I should be seeing this
> >> at all (since my passphrase is already in settings.xml?) or how else
> >> this is supposed to work? does anyone see this?
> >
> > You shouldn't be asked for the password if you set it in your
> > settings.xml and are using the profile you set it in for building.
> >
> > So, if your setting.xml says:
> >
> > <profiles>
> >  <profile>
> >    <id>apache-release</id>
> >    <properties>
> >        <gpg.passphrase>*********</gpg.passphrase>
> >    </properties>
> >  </profile>
> > </profiles
> >
> > and you are building with mvn -Papache-release <goal> you shouldn't be
> > asked for the password.
> >
> > Isabel
> >
>

Re: TAR problems

Posted by Sean Owen <sr...@gmail.com>.
Ah I guess whatever notes I found on this problem were misleading,
sounds like you've shown it is a path length issue. Sounds like the
possible ways forward are...

- Can you just do release builds from /tmp or something like /mahout?
- Can we switch to .zip packaging? I don't particularly care about
tar.gz vs .zip
- Does a newer tar binary do the trick?

Meantime, I'm figuring out why gpg doesn't work out on p.a.o.

Benson if that was actually an offer to try to do a release here...
may well be worth taking you up on it if none of this is working.

On Mon, Oct 26, 2009 at 12:35 PM, Grant Ingersoll <gs...@apache.org> wrote:
> I get past the TAR problem when I check out into /tmp.  It really is just an
> issue w/ long names.  I'm on a Mac, Snow Leopard.  I don't know what to do
> about TAR.
>
> My tar is:
>  tar --version
> tar (GNU tar) 1.16.1
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software.  You may redistribute copies of it under the terms of
> the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
> There is NO WARRANTY, to the extent permitted by law.
>
> Written by John Gilmore and Jay Fenlason.
>
>
> I see there is a newer version, so I will try updating to that.
>
> -Grant
>
>
> On Oct 26, 2009, at 7:58 AM, Sean Owen wrote:
>
>> Ah, I see how that works now. I was using the apache-release profile
>> but it also needed to be configured with <gpg.keyname> as well.
>>
>> (Actually I found I needed to run my own gpg-agent too -- "eval
>> 'gpg-agent --daemon'" -- anyone think that sounds wrong? checking
>> before I add it to the wiki.)
>>
>> I now get:
>>
>> [INFO] [INFO] [gpg:sign {execution: default}]
>> [INFO] gpg: WARNING: "--no-use-agent" is an obsolete option - it has no
>> effect
>> [INFO] Warning: using insecure memory!
>>
>> You need a passphrase to unlock the secret key for
>> user: "Sean Owen <sr...@apache.org>"
>> 4096-bit RSA key, ID 021F6670, created 2009-10-16
>>
>> [INFO] gpg: cancelled by user
>> [INFO] gpg: skipped "Sean Owen": General error
>> [INFO] gpg: signing failed: General error
>>
>>
>> Is that not the right keyname? that previously worked locally (where I
>> had to supply the passphrase manually). I tried "Sean Owen" too with
>> the same result.
>>
>> So our build instructions also talk about this mahout_release profile,
>> which doesn't seem to be used? is that out of date?
>>
>>
>> We seem to be stuck just in the release process in three different
>> ways. Grant is stuck on long-mode and the release profile or
>> something. I am both stuck on this gpg issue on people.apache.org, and
>> on some possible svn.apache.org problem locally.
>>
>> I've done about a full day of head-banging on this and am ready to
>> throw in the towel. If we are truly dead in the water with the release
>> process... is there any kind soul to appeal to here?
>>
>>
>>
>> On Mon, Oct 26, 2009 at 7:21 AM, Isabel Drost <is...@apache.org> wrote:
>>>
>>> On Mon Sean Owen <sr...@gmail.com> wrote:
>>>>
>>>> I don't know enough about GPG to know whether I should be seeing this
>>>> at all (since my passphrase is already in settings.xml?) or how else
>>>> this is supposed to work? does anyone see this?
>>>
>>> You shouldn't be asked for the password if you set it in your
>>> settings.xml and are using the profile you set it in for building.
>>>
>>> So, if your setting.xml says:
>>>
>>> <profiles>
>>>  <profile>
>>>   <id>apache-release</id>
>>>   <properties>
>>>       <gpg.passphrase>*********</gpg.passphrase>
>>>   </properties>
>>>  </profile>
>>> </profiles
>>>
>>> and you are building with mvn -Papache-release <goal> you shouldn't be
>>> asked for the password.
>>>
>>> Isabel
>>>
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com/
>
> Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using
> Solr/Lucene:
> http://www.lucidimagination.com/search
>
>

Re: TAR problems

Posted by Grant Ingersoll <gs...@apache.org>.
I get past the TAR problem when I check out into /tmp.  It really is  
just an issue w/ long names.  I'm on a Mac, Snow Leopard.  I don't  
know what to do about TAR.

My tar is:
  tar --version
tar (GNU tar) 1.16.1
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software.  You may redistribute copies of it under the  
terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.


I see there is a newer version, so I will try updating to that.

-Grant


On Oct 26, 2009, at 7:58 AM, Sean Owen wrote:

> Ah, I see how that works now. I was using the apache-release profile
> but it also needed to be configured with <gpg.keyname> as well.
>
> (Actually I found I needed to run my own gpg-agent too -- "eval
> 'gpg-agent --daemon'" -- anyone think that sounds wrong? checking
> before I add it to the wiki.)
>
> I now get:
>
> [INFO] [INFO] [gpg:sign {execution: default}]
> [INFO] gpg: WARNING: "--no-use-agent" is an obsolete option - it has  
> no effect
> [INFO] Warning: using insecure memory!
>
> You need a passphrase to unlock the secret key for
> user: "Sean Owen <sr...@apache.org>"
> 4096-bit RSA key, ID 021F6670, created 2009-10-16
>
> [INFO] gpg: cancelled by user
> [INFO] gpg: skipped "Sean Owen": General error
> [INFO] gpg: signing failed: General error
>
>
> Is that not the right keyname? that previously worked locally (where I
> had to supply the passphrase manually). I tried "Sean Owen" too with
> the same result.
>
> So our build instructions also talk about this mahout_release profile,
> which doesn't seem to be used? is that out of date?
>
>
> We seem to be stuck just in the release process in three different
> ways. Grant is stuck on long-mode and the release profile or
> something. I am both stuck on this gpg issue on people.apache.org, and
> on some possible svn.apache.org problem locally.
>
> I've done about a full day of head-banging on this and am ready to
> throw in the towel. If we are truly dead in the water with the release
> process... is there any kind soul to appeal to here?
>
>
>
> On Mon, Oct 26, 2009 at 7:21 AM, Isabel Drost <is...@apache.org>  
> wrote:
>> On Mon Sean Owen <sr...@gmail.com> wrote:
>>> I don't know enough about GPG to know whether I should be seeing  
>>> this
>>> at all (since my passphrase is already in settings.xml?) or how else
>>> this is supposed to work? does anyone see this?
>>
>> You shouldn't be asked for the password if you set it in your
>> settings.xml and are using the profile you set it in for building.
>>
>> So, if your setting.xml says:
>>
>> <profiles>
>>  <profile>
>>    <id>apache-release</id>
>>    <properties>
>>        <gpg.passphrase>*********</gpg.passphrase>
>>    </properties>
>>  </profile>
>> </profiles
>>
>> and you are building with mvn -Papache-release <goal> you shouldn't  
>> be
>> asked for the password.
>>
>> Isabel
>>

--------------------------
Grant Ingersoll
http://www.lucidimagination.com/

Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids)  
using Solr/Lucene:
http://www.lucidimagination.com/search


Re: TAR problems

Posted by Sean Owen <sr...@gmail.com>.
Ah, I see how that works now. I was using the apache-release profile
but it also needed to be configured with <gpg.keyname> as well.

(Actually I found I needed to run my own gpg-agent too -- "eval
'gpg-agent --daemon'" -- anyone think that sounds wrong? checking
before I add it to the wiki.)

I now get:

[INFO] [INFO] [gpg:sign {execution: default}]
[INFO] gpg: WARNING: "--no-use-agent" is an obsolete option - it has no effect
[INFO] Warning: using insecure memory!

You need a passphrase to unlock the secret key for
user: "Sean Owen <sr...@apache.org>"
4096-bit RSA key, ID 021F6670, created 2009-10-16

[INFO] gpg: cancelled by user
[INFO] gpg: skipped "Sean Owen": General error
[INFO] gpg: signing failed: General error


Is that not the right keyname? that previously worked locally (where I
had to supply the passphrase manually). I tried "Sean Owen" too with
the same result.

So our build instructions also talk about this mahout_release profile,
which doesn't seem to be used? is that out of date?


We seem to be stuck just in the release process in three different
ways. Grant is stuck on long-mode and the release profile or
something. I am both stuck on this gpg issue on people.apache.org, and
on some possible svn.apache.org problem locally.

I've done about a full day of head-banging on this and am ready to
throw in the towel. If we are truly dead in the water with the release
process... is there any kind soul to appeal to here?



On Mon, Oct 26, 2009 at 7:21 AM, Isabel Drost <is...@apache.org> wrote:
> On Mon Sean Owen <sr...@gmail.com> wrote:
>> I don't know enough about GPG to know whether I should be seeing this
>> at all (since my passphrase is already in settings.xml?) or how else
>> this is supposed to work? does anyone see this?
>
> You shouldn't be asked for the password if you set it in your
> settings.xml and are using the profile you set it in for building.
>
> So, if your setting.xml says:
>
> <profiles>
>  <profile>
>    <id>apache-release</id>
>    <properties>
>        <gpg.passphrase>*********</gpg.passphrase>
>    </properties>
>  </profile>
> </profiles
>
> and you are building with mvn -Papache-release <goal> you shouldn't be
> asked for the password.
>
> Isabel
>

Re: TAR problems

Posted by Isabel Drost <is...@apache.org>.
On Mon Sean Owen <sr...@gmail.com> wrote:
> I don't know enough about GPG to know whether I should be seeing this
> at all (since my passphrase is already in settings.xml?) or how else
> this is supposed to work? does anyone see this?

You shouldn't be asked for the password if you set it in your
settings.xml and are using the profile you set it in for building.

So, if your setting.xml says:

<profiles>
  <profile>
    <id>apache-release</id>
    <properties>
        <gpg.passphrase>*********</gpg.passphrase>
    </properties>
  </profile>
</profiles

and you are building with mvn -Papache-release <goal> you shouldn't be
asked for the password.

Isabel

Re: TAR problems

Posted by Sean Owen <sr...@gmail.com>.
Just tried this now. It's a good idea.

I ran into some weird build failures that only showed up on this
machine. I somehow resolved it with a few changes including updating
the version of xstream.

I'm stuck on GPG again. I get to the part where I must put in my
passphrase. On my laptop I'm presented with a GUI dialog and it works.
I don't think the same mechanism is working over ssh... assume it's
waiting on command line input but I don't have access to its input
stream?

I don't know enough about GPG to know whether I should be seeing this
at all (since my passphrase is already in settings.xml?) or how else
this is supposed to work? does anyone see this?

[INFO] gpg: WARNING: "--no-use-agent" is an obsolete option - it has no effect
[INFO] Warning: using insecure memory!

You need a passphrase to unlock the secret key for
user: "Sean Owen <sr...@apache.org>"
4096-bit RSA key, ID 021F6670, created 2009-10-16


On Sun, Oct 25, 2009 at 8:15 PM, Grant Ingersoll <gs...@apache.org> wrote:
> BTW, Sean, have you tried building on people.a.o?  You should have an
> account there and it is located in the US.
>
> -Grant
>
> On Oct 25, 2009, at 9:29 AM, Sean Owen wrote:
>
>> My understanding of the error is that tar only works with file sizes under
>> 2GB (max signed 32 bit int) unless long mode us on.
>>
>> If that is right and long mode is problematic then I am musing about what
>> on
>> earth is so big!
>>
>> Which tar is it?
>>
>> Can we just use zip packaging?
>>
>> I am seeking any way forward now.
>>
>> Sean
>>
>> On Oct 25, 2009 1:10 PM, "Grant Ingersoll" <gs...@apache.org> wrote:
>>
>> On Oct 24, 2009, at 7:40 PM, Sean Owen wrote: > What, the 'why is tar
>> processing 2GB' question? ye...
>> Where do you see that?
>>
>>> On Sat, Oct 24, 2009 at 10:51 PM, Benson Margulies > <
>>
>> bimargulies@gmail.com> wrote: >> >> That ...
>
>

Re: TAR problems

Posted by Grant Ingersoll <gs...@apache.org>.
BTW, Sean, have you tried building on people.a.o?  You should have an  
account there and it is located in the US.

-Grant

On Oct 25, 2009, at 9:29 AM, Sean Owen wrote:

> My understanding of the error is that tar only works with file sizes  
> under
> 2GB (max signed 32 bit int) unless long mode us on.
>
> If that is right and long mode is problematic then I am musing about  
> what on
> earth is so big!
>
> Which tar is it?
>
> Can we just use zip packaging?
>
> I am seeking any way forward now.
>
> Sean
>
> On Oct 25, 2009 1:10 PM, "Grant Ingersoll" <gs...@apache.org>  
> wrote:
>
> On Oct 24, 2009, at 7:40 PM, Sean Owen wrote: > What, the 'why is tar
> processing 2GB' question? ye...
> Where do you see that?
>
>> On Sat, Oct 24, 2009 at 10:51 PM, Benson Margulies > <
> bimargulies@gmail.com> wrote: >> >> That ...


Re: TAR problems

Posted by Sean Owen <sr...@gmail.com>.
My understanding of the error is that tar only works with file sizes under
2GB (max signed 32 bit int) unless long mode us on.

If that is right and long mode is problematic then I am musing about what on
earth is so big!

Which tar is it?

Can we just use zip packaging?

I am seeking any way forward now.

Sean

On Oct 25, 2009 1:10 PM, "Grant Ingersoll" <gs...@apache.org> wrote:

On Oct 24, 2009, at 7:40 PM, Sean Owen wrote: > What, the 'why is tar
processing 2GB' question? ye...
Where do you see that?

> On Sat, Oct 24, 2009 at 10:51 PM, Benson Margulies > <
bimargulies@gmail.com> wrote: >> >> That ...

Re: TAR problems

Posted by Grant Ingersoll <gs...@apache.org>.
On Oct 24, 2009, at 7:40 PM, Sean Owen wrote:

> What, the 'why is tar processing 2GB' question? yeah good one. Grant
> which step exactly is doing this? maybe we can work around this
> another way.
>

Where do you see that?


> On Sat, Oct 24, 2009 at 10:51 PM, Benson Margulies
> <bi...@gmail.com> wrote:
>> That might be the most important question.



Re: TAR problems

Posted by Sean Owen <sr...@gmail.com>.
What, the 'why is tar processing 2GB' question? yeah good one. Grant
which step exactly is doing this? maybe we can work around this
another way.

On Sat, Oct 24, 2009 at 10:51 PM, Benson Margulies
<bi...@gmail.com> wrote:
> That might be the most important question.

Re: TAR problems

Posted by Benson Margulies <bi...@gmail.com>.
That might be the most important question.

On Sat, Oct 24, 2009 at 2:25 PM, Sean Owen <sr...@gmail.com> wrote:

> Just to coordinate our efforts --
>
> I tried forcing DNS resolution of svn.apache.org to US servers. Same
> results. I eventually reach this error:
>
> svn: Path 'https://svn.apache.org/repos/asf/lucene/mahout/tags/mahout-0.2'
> does not exist in revision 829426
>
> and no amount of svn update or repeating release:prepare does the trick.
>
>
> Grant, am I right in thinking you are getting past this part? if so,
> I'd judge it more important to figure out how you can move ahead so we
> can finally get a release out of this. (And then return to figuring
> out why it doesn't work here.)
>
>
> Looks like it is a question of enabling this
> <tarLongFileMode>gnu</tarLongFileMode> in the release profile.  One
> thing I don't see is where this whole release profile is defined --
> assume it's external, but where?
>
> As an aside, what in the process is creating a 2+GB tar file??
>
>
>
>
> On Sat, Oct 24, 2009 at 12:08 PM, Grant Ingersoll <gs...@apache.org>
> wrote:
> > It looks like it is picking it up:
> >  Configuring mojo
> > 'org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-2:single' -->
> > [INFO] [DEBUG]   (s) appendAssemblyId = true
> > [INFO] [DEBUG]   (f) attach = true
> > [INFO] [DEBUG]   (s) basedir = .../projects/lucene/mahout/mahout-clean
> > [INFO] [DEBUG]   (s) descriptorRefs = [Ljava.lang.String;@1cf7cbd1
> > [INFO] [DEBUG]   (f) dryRun = false
> > [INFO] [DEBUG]   (s) finalName = mahout-0.2
> > [INFO] [DEBUG]   (f) ignoreDirFormatExtensions = false
> > [INFO] [DEBUG]   (s) ignoreMissingDescriptor = false
> > [INFO] [DEBUG]   (s) includeSite = false
> > [INFO] [DEBUG]   (s) localRepository = [local] ->
> > file:///Volumes/User/grantingersoll/.m2/repository
> > [INFO] [DEBUG]   (s) outputDirectory =
> > .../projects/lucene/mahout/mahout-clean/target
> > [INFO] [DEBUG]   (f) project = MavenProject: org.apache.mahout:mahout:0.2
> @
> > .../projects/lucene/mahout/mahout-clean/pom.xml
> > [INFO] [DEBUG]   (s) reactorProjects = [MavenProject:
> > org.apache.mahout:mahout:0.2 @
> > .../projects/lucene/mahout/mahout-clean/pom.xml, MavenProject:
> > org.apache.mahout:mahout-parent:0.2 @
> > .../projects/lucene/mahout/mahout-clean/maven/pom.xml, MavenProject:
> > org.apache.mahout:mahout-core:0.2 @
> > .../projects/lucene/mahout/mahout-clean/core/pom.xml, MavenProject:
> > org.apache.mahout:mahout-taste-webapp:0.2 @
> > .../projects/lucene/mahout/mahout-clean/taste-web/pom.xml, MavenProject:
> > org.apache.mahout:mahout-utils:0.2 @
> > .../projects/lucene/mahout/mahout-clean/utils/pom.xml, MavenProject:
> > org.apache.mahout:mahout-examples:0.2 @
> > .../projects/lucene/mahout/mahout-clean/examples/pom.xml]
> > [INFO] [DEBUG]   (f) remoteRepositories = [[codehausSnapshots] ->
> > http://snapshots.maven.codehaus.org/maven2, [apacheSnapshots] ->
> > http://people.apache.org/maven-snapshot-repository/, [apache.snapshots]
> ->
> > http://repository.apache.org/snapshots, [central] ->
> > http://repo1.maven.org/maven2]
> > [INFO] [DEBUG]   (s) siteDirectory =
> > .../projects/lucene/mahout/mahout-clean/target/site
> > [INFO] [DEBUG]   (f) skipAssembly = false
> > [INFO] [DEBUG]   (s) tarLongFileMode = gnu
> > [INFO] [DEBUG]   (s) tempRoot =
> > .../projects/lucene/mahout/mahout-clean/target/archive-tmp
> > [INFO] [DEBUG]   (s) workDirectory =
> > .../projects/lucene/mahout/mahout-clean/target/assembly/work
> >
> > On Oct 23, 2009, at 8:54 PM, Benson Margulies wrote:
> >
> >> https://svn.apache.org/repos/asf/cxf/trunk/distribution/pom.xml
> >>
> >>
> >> It's not in a profile here, since we condition the entire distribution
> >> module on a release profile. It should work just the same if the
> >> plugin spec is inside a profile.
> >>
> >> I note that ours has only config in the execution, none at top-level.
> >>
> >> mvn -X might also be informative.
> >>
> >>
> >> On Fri, Oct 23, 2009 at 5:12 PM, Grant Ingersoll
> >> <gs...@apache.org>wrote:
> >>
> >>> Hey Benson,
> >>>
> >>> Do you know how to turn this on the release profile?
> >>>
> >>> I put in:
> >>> <plugin>
> >>>          <artifactId>maven-assembly-plugin</artifactId>
> >>>          <configuration>
> >>>            <descriptorRefs>
> >>>              <descriptorRef>project</descriptorRef>
> >>>            </descriptorRefs>
> >>>            <tarLongFileMode>gnu</tarLongFileMode>
> >>>          </configuration>
> >>>          <executions>
> >>>            <execution>
> >>>              <id>make-assembly</id>
> >>>              <!-- this is used for inheritance merges -->
> >>>              <phase>package</phase>
> >>>              <!-- append to the packaging phase. -->
> >>>              <goals>
> >>>                <goal>single</goal>
> >>>                <!-- goals == mojos -->
> >>>              </goals>
> >>>              <configuration>
> >>>                <tarLongFileMode>gnu</tarLongFileMode>
> >>>              </configuration>
> >>>            </execution>
> >>>          </executions>
> >>>        </plugin>
> >>>
> >>> but I am still getting:
> >>> Failed to create assembly: Error creating assembly archive project:
> >>> Problem creating TAR: request to write '0' bytes exceeds size in header
> >>> of
> >>> '-1535663957' bytes
> >>>
> >>>
> >>> -Grant
> >>>
> >>> On Jul 16, 2009, at 10:48 AM, Benson Margulies wrote:
> >>>
> >>> Do you have long mode turned on?
> >>>>
> >>>> On Thu, Jul 16, 2009 at 10:01 AM, Grant Ingersoll<gsingers@apache.org
> >
> >>>> wrote:
> >>>>
> >>>>> Anyone else seeing: Failed to create assembly: Error creating
> assembly
> >>>>> archive project: Problem creating TAR: request to write '0' bytes
> >>>>> exceeds
> >>>>> size in header of '-1535663957' bytes
> >>>>>
> >>>>> when doing mvn install.  I know the problem has to do with TAR.  I'm
> >>>>> just
> >>>>> wondering if we should switch to JAR/Zip packaging only, instead of
> >>>>> tarballs.
> >>>>>
> >>>>>
> >>>
> >>>
> >
> > --------------------------
> > Grant Ingersoll
> > http://www.lucidimagination.com/
> >
> > Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using
> > Solr/Lucene:
> > http://www.lucidimagination.com/search
> >
> >
>

Re: TAR problems

Posted by Sean Owen <sr...@gmail.com>.
Just to coordinate our efforts --

I tried forcing DNS resolution of svn.apache.org to US servers. Same
results. I eventually reach this error:

svn: Path 'https://svn.apache.org/repos/asf/lucene/mahout/tags/mahout-0.2'
does not exist in revision 829426

and no amount of svn update or repeating release:prepare does the trick.


Grant, am I right in thinking you are getting past this part? if so,
I'd judge it more important to figure out how you can move ahead so we
can finally get a release out of this. (And then return to figuring
out why it doesn't work here.)


Looks like it is a question of enabling this
<tarLongFileMode>gnu</tarLongFileMode> in the release profile.  One
thing I don't see is where this whole release profile is defined --
assume it's external, but where?

As an aside, what in the process is creating a 2+GB tar file??




On Sat, Oct 24, 2009 at 12:08 PM, Grant Ingersoll <gs...@apache.org> wrote:
> It looks like it is picking it up:
>  Configuring mojo
> 'org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-2:single' -->
> [INFO] [DEBUG]   (s) appendAssemblyId = true
> [INFO] [DEBUG]   (f) attach = true
> [INFO] [DEBUG]   (s) basedir = .../projects/lucene/mahout/mahout-clean
> [INFO] [DEBUG]   (s) descriptorRefs = [Ljava.lang.String;@1cf7cbd1
> [INFO] [DEBUG]   (f) dryRun = false
> [INFO] [DEBUG]   (s) finalName = mahout-0.2
> [INFO] [DEBUG]   (f) ignoreDirFormatExtensions = false
> [INFO] [DEBUG]   (s) ignoreMissingDescriptor = false
> [INFO] [DEBUG]   (s) includeSite = false
> [INFO] [DEBUG]   (s) localRepository = [local] ->
> file:///Volumes/User/grantingersoll/.m2/repository
> [INFO] [DEBUG]   (s) outputDirectory =
> .../projects/lucene/mahout/mahout-clean/target
> [INFO] [DEBUG]   (f) project = MavenProject: org.apache.mahout:mahout:0.2 @
> .../projects/lucene/mahout/mahout-clean/pom.xml
> [INFO] [DEBUG]   (s) reactorProjects = [MavenProject:
> org.apache.mahout:mahout:0.2 @
> .../projects/lucene/mahout/mahout-clean/pom.xml, MavenProject:
> org.apache.mahout:mahout-parent:0.2 @
> .../projects/lucene/mahout/mahout-clean/maven/pom.xml, MavenProject:
> org.apache.mahout:mahout-core:0.2 @
> .../projects/lucene/mahout/mahout-clean/core/pom.xml, MavenProject:
> org.apache.mahout:mahout-taste-webapp:0.2 @
> .../projects/lucene/mahout/mahout-clean/taste-web/pom.xml, MavenProject:
> org.apache.mahout:mahout-utils:0.2 @
> .../projects/lucene/mahout/mahout-clean/utils/pom.xml, MavenProject:
> org.apache.mahout:mahout-examples:0.2 @
> .../projects/lucene/mahout/mahout-clean/examples/pom.xml]
> [INFO] [DEBUG]   (f) remoteRepositories = [[codehausSnapshots] ->
> http://snapshots.maven.codehaus.org/maven2, [apacheSnapshots] ->
> http://people.apache.org/maven-snapshot-repository/, [apache.snapshots] ->
> http://repository.apache.org/snapshots, [central] ->
> http://repo1.maven.org/maven2]
> [INFO] [DEBUG]   (s) siteDirectory =
> .../projects/lucene/mahout/mahout-clean/target/site
> [INFO] [DEBUG]   (f) skipAssembly = false
> [INFO] [DEBUG]   (s) tarLongFileMode = gnu
> [INFO] [DEBUG]   (s) tempRoot =
> .../projects/lucene/mahout/mahout-clean/target/archive-tmp
> [INFO] [DEBUG]   (s) workDirectory =
> .../projects/lucene/mahout/mahout-clean/target/assembly/work
>
> On Oct 23, 2009, at 8:54 PM, Benson Margulies wrote:
>
>> https://svn.apache.org/repos/asf/cxf/trunk/distribution/pom.xml
>>
>>
>> It's not in a profile here, since we condition the entire distribution
>> module on a release profile. It should work just the same if the
>> plugin spec is inside a profile.
>>
>> I note that ours has only config in the execution, none at top-level.
>>
>> mvn -X might also be informative.
>>
>>
>> On Fri, Oct 23, 2009 at 5:12 PM, Grant Ingersoll
>> <gs...@apache.org>wrote:
>>
>>> Hey Benson,
>>>
>>> Do you know how to turn this on the release profile?
>>>
>>> I put in:
>>> <plugin>
>>>          <artifactId>maven-assembly-plugin</artifactId>
>>>          <configuration>
>>>            <descriptorRefs>
>>>              <descriptorRef>project</descriptorRef>
>>>            </descriptorRefs>
>>>            <tarLongFileMode>gnu</tarLongFileMode>
>>>          </configuration>
>>>          <executions>
>>>            <execution>
>>>              <id>make-assembly</id>
>>>              <!-- this is used for inheritance merges -->
>>>              <phase>package</phase>
>>>              <!-- append to the packaging phase. -->
>>>              <goals>
>>>                <goal>single</goal>
>>>                <!-- goals == mojos -->
>>>              </goals>
>>>              <configuration>
>>>                <tarLongFileMode>gnu</tarLongFileMode>
>>>              </configuration>
>>>            </execution>
>>>          </executions>
>>>        </plugin>
>>>
>>> but I am still getting:
>>> Failed to create assembly: Error creating assembly archive project:
>>> Problem creating TAR: request to write '0' bytes exceeds size in header
>>> of
>>> '-1535663957' bytes
>>>
>>>
>>> -Grant
>>>
>>> On Jul 16, 2009, at 10:48 AM, Benson Margulies wrote:
>>>
>>> Do you have long mode turned on?
>>>>
>>>> On Thu, Jul 16, 2009 at 10:01 AM, Grant Ingersoll<gs...@apache.org>
>>>> wrote:
>>>>
>>>>> Anyone else seeing: Failed to create assembly: Error creating assembly
>>>>> archive project: Problem creating TAR: request to write '0' bytes
>>>>> exceeds
>>>>> size in header of '-1535663957' bytes
>>>>>
>>>>> when doing mvn install.  I know the problem has to do with TAR.  I'm
>>>>> just
>>>>> wondering if we should switch to JAR/Zip packaging only, instead of
>>>>> tarballs.
>>>>>
>>>>>
>>>
>>>
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com/
>
> Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using
> Solr/Lucene:
> http://www.lucidimagination.com/search
>
>

Re: TAR problems

Posted by Grant Ingersoll <gs...@apache.org>.
It looks like it is picking it up:
  Configuring mojo 'org.apache.maven.plugins:maven-assembly-plugin:2.2- 
beta-2:single' -->
[INFO] [DEBUG]   (s) appendAssemblyId = true
[INFO] [DEBUG]   (f) attach = true
[INFO] [DEBUG]   (s) basedir = .../projects/lucene/mahout/mahout-clean
[INFO] [DEBUG]   (s) descriptorRefs = [Ljava.lang.String;@1cf7cbd1
[INFO] [DEBUG]   (f) dryRun = false
[INFO] [DEBUG]   (s) finalName = mahout-0.2
[INFO] [DEBUG]   (f) ignoreDirFormatExtensions = false
[INFO] [DEBUG]   (s) ignoreMissingDescriptor = false
[INFO] [DEBUG]   (s) includeSite = false
[INFO] [DEBUG]   (s) localRepository = [local] -> file:///Volumes/User/grantingersoll/.m2/repository
[INFO] [DEBUG]   (s) outputDirectory = .../projects/lucene/mahout/ 
mahout-clean/target
[INFO] [DEBUG]   (f) project = MavenProject: org.apache.mahout:mahout: 
0.2 @ .../projects/lucene/mahout/mahout-clean/pom.xml
[INFO] [DEBUG]   (s) reactorProjects = [MavenProject:  
org.apache.mahout:mahout:0.2 @ .../projects/lucene/mahout/mahout-clean/ 
pom.xml, MavenProject: org.apache.mahout:mahout-parent:0.2 @ .../ 
projects/lucene/mahout/mahout-clean/maven/pom.xml, MavenProject:  
org.apache.mahout:mahout-core:0.2 @ .../projects/lucene/mahout/mahout- 
clean/core/pom.xml, MavenProject: org.apache.mahout:mahout-taste- 
webapp:0.2 @ .../projects/lucene/mahout/mahout-clean/taste-web/ 
pom.xml, MavenProject: org.apache.mahout:mahout-utils:0.2 @ .../ 
projects/lucene/mahout/mahout-clean/utils/pom.xml, MavenProject:  
org.apache.mahout:mahout-examples:0.2 @ .../projects/lucene/mahout/ 
mahout-clean/examples/pom.xml]
[INFO] [DEBUG]   (f) remoteRepositories = [[codehausSnapshots] -> http://snapshots.maven.codehaus.org/maven2 
, [apacheSnapshots] -> http://people.apache.org/maven-snapshot-repository/ 
, [apache.snapshots] -> http://repository.apache.org/snapshots,  
[central] -> http://repo1.maven.org/maven2]
[INFO] [DEBUG]   (s) siteDirectory = .../projects/lucene/mahout/mahout- 
clean/target/site
[INFO] [DEBUG]   (f) skipAssembly = false
[INFO] [DEBUG]   (s) tarLongFileMode = gnu
[INFO] [DEBUG]   (s) tempRoot = .../projects/lucene/mahout/mahout- 
clean/target/archive-tmp
[INFO] [DEBUG]   (s) workDirectory = .../projects/lucene/mahout/mahout- 
clean/target/assembly/work

On Oct 23, 2009, at 8:54 PM, Benson Margulies wrote:

> https://svn.apache.org/repos/asf/cxf/trunk/distribution/pom.xml
>
>
> It's not in a profile here, since we condition the entire distribution
> module on a release profile. It should work just the same if the
> plugin spec is inside a profile.
>
> I note that ours has only config in the execution, none at top-level.
>
> mvn -X might also be informative.
>
>
> On Fri, Oct 23, 2009 at 5:12 PM, Grant Ingersoll  
> <gs...@apache.org>wrote:
>
>> Hey Benson,
>>
>> Do you know how to turn this on the release profile?
>>
>> I put in:
>> <plugin>
>>           <artifactId>maven-assembly-plugin</artifactId>
>>           <configuration>
>>             <descriptorRefs>
>>               <descriptorRef>project</descriptorRef>
>>             </descriptorRefs>
>>             <tarLongFileMode>gnu</tarLongFileMode>
>>           </configuration>
>>           <executions>
>>             <execution>
>>               <id>make-assembly</id>
>>               <!-- this is used for inheritance merges -->
>>               <phase>package</phase>
>>               <!-- append to the packaging phase. -->
>>               <goals>
>>                 <goal>single</goal>
>>                 <!-- goals == mojos -->
>>               </goals>
>>               <configuration>
>>                 <tarLongFileMode>gnu</tarLongFileMode>
>>               </configuration>
>>             </execution>
>>           </executions>
>>         </plugin>
>>
>> but I am still getting:
>> Failed to create assembly: Error creating assembly archive project:
>> Problem creating TAR: request to write '0' bytes exceeds size in  
>> header of
>> '-1535663957' bytes
>>
>>
>> -Grant
>>
>> On Jul 16, 2009, at 10:48 AM, Benson Margulies wrote:
>>
>> Do you have long mode turned on?
>>>
>>> On Thu, Jul 16, 2009 at 10:01 AM, Grant Ingersoll<gsingers@apache.org 
>>> >
>>> wrote:
>>>
>>>> Anyone else seeing: Failed to create assembly: Error creating  
>>>> assembly
>>>> archive project: Problem creating TAR: request to write '0' bytes  
>>>> exceeds
>>>> size in header of '-1535663957' bytes
>>>>
>>>> when doing mvn install.  I know the problem has to do with TAR.   
>>>> I'm just
>>>> wondering if we should switch to JAR/Zip packaging only, instead of
>>>> tarballs.
>>>>
>>>>
>>
>>

--------------------------
Grant Ingersoll
http://www.lucidimagination.com/

Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids)  
using Solr/Lucene:
http://www.lucidimagination.com/search


Re: TAR problems

Posted by Benson Margulies <bi...@gmail.com>.
https://svn.apache.org/repos/asf/cxf/trunk/distribution/pom.xml


It's not in a profile here, since we condition the entire distribution
module on a release profile. It should work just the same if the
plugin spec is inside a profile.

I note that ours has only config in the execution, none at top-level.

mvn -X might also be informative.


On Fri, Oct 23, 2009 at 5:12 PM, Grant Ingersoll <gs...@apache.org>wrote:

> Hey Benson,
>
> Do you know how to turn this on the release profile?
>
> I put in:
> <plugin>
>            <artifactId>maven-assembly-plugin</artifactId>
>            <configuration>
>              <descriptorRefs>
>                <descriptorRef>project</descriptorRef>
>              </descriptorRefs>
>              <tarLongFileMode>gnu</tarLongFileMode>
>            </configuration>
>            <executions>
>              <execution>
>                <id>make-assembly</id>
>                <!-- this is used for inheritance merges -->
>                <phase>package</phase>
>                <!-- append to the packaging phase. -->
>                <goals>
>                  <goal>single</goal>
>                  <!-- goals == mojos -->
>                </goals>
>                <configuration>
>                  <tarLongFileMode>gnu</tarLongFileMode>
>                </configuration>
>              </execution>
>            </executions>
>          </plugin>
>
> but I am still getting:
>  Failed to create assembly: Error creating assembly archive project:
> Problem creating TAR: request to write '0' bytes exceeds size in header of
> '-1535663957' bytes
>
>
> -Grant
>
> On Jul 16, 2009, at 10:48 AM, Benson Margulies wrote:
>
>  Do you have long mode turned on?
>>
>> On Thu, Jul 16, 2009 at 10:01 AM, Grant Ingersoll<gs...@apache.org>
>> wrote:
>>
>>> Anyone else seeing: Failed to create assembly: Error creating assembly
>>> archive project: Problem creating TAR: request to write '0' bytes exceeds
>>> size in header of '-1535663957' bytes
>>>
>>> when doing mvn install.  I know the problem has to do with TAR.  I'm just
>>> wondering if we should switch to JAR/Zip packaging only, instead of
>>> tarballs.
>>>
>>>
>
>