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 wrote:
> Success. Â Trying release:perform now.
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 tag in the pom
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 tag in the pom.xml. I just
checked in a change and am trying it now.
OK, pretty sure it is now due to t
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 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,
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 wrote:
> I think I see the problem
>
It look like the 'remoteTagging' business from the symptoms reported.
On Mon, Oct 26, 2009 at 4:02 PM, Grant Ingersoll wrote:
> I think I see the problem
>
>
> On Oct 26, 2009, at 3:22 PM, Grant Ingersoll wrote:
>
> Progress:
>> [INFO] [INFO] Mahout utilities
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]
---
Progress:
[INFO] [INFO] Mahout utilities ..
SUCCESS [15.683s]
[INFO] [INFO] Mahout examples ...
SUCCESS [52.623s]
[INFO] [INFO]
[INFO] [INFO]
---
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 wrote:
> What happens if you run with mvn -e -X
>
> Here's how I've been running:
> mvn -Prelease,maho
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:
mahout_release
*
mahout.releases::default::scp://people.apache.org/home/gsingers/public
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 abo
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 r
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 wrote:
> Ah, I see how that works now. I was using the ap
Ah, I see how that works now. I was using the apache-release profile
but it also needed to be configured with 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
On Mon Sean Owen 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 a
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 presen
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 o
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 forwa
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
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
wrote:
That might be
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
wrote:
> That might be the most important question.
That might be the most important question.
On Sat, 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/luce
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 rel
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)
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-
Hey Benson,
Do you know how to turn this on the release profile?
I put in:
maven-assembly-plugin
project
gnu
make-assembly
No, I see that option now. To some extent, the problem has been
pushed off to release time now thanks to your patch for MAHOUT-144.
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 wrote:
Anyone else
Do you have long mode turned on?
On Thu, Jul 16, 2009 at 10:01 AM, Grant Ingersoll 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
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 J
29 matches
Mail list logo