On Fri, 8 Jul 2005, Adam Jack [EMAIL PROTECTED] wrote:
Ought we simple disable CVS metadata updates by default,
Yes.
enabling SVN by default. With svn:external I believe we
automatically pick up the ability to have one SVN update get both
code and metadata, so disabling CVS update ought be
On Mon, 11 Jul 2005, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
How about granting our GSoC friends commit access so that they can
show us what they are doing?
Related, if not completely on-topic. Justin's CLA has not yet been
recorded.
Until we get there, Justin could provide patches - we
Hi,
I am one of the developers of the Kaffe.org VM. I would like to know if
there is any chance to get back an automatic gump run on
vmgump.apache.org. That was pretty useful to test GNU Classpath Kaffe
in interaction with the rest of the other java projects and to detect
bugs.
Thanks a lot for
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-test has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-test has an issue affecting its community integration.
This issue
Guilhem Lavaux wrote:
Hi,
Hi Guilhem!
I am one of the developers of the Kaffe.org VM. I would like to know if
there is any chance to get back an automatic gump run on
vmgump.apache.org.
Not really :/. That machine is low on disk space so we can't run any
more profiles there. We do have a
On Mon, 11 Jul 2005, Guilhem Lavaux [EMAIL PROTECTED] wrote:
I would like to know if there is any chance to get back an automatic
gump run on vmgump.apache.org.
There is not that much left to add to what Leo said.
If you had the choice of Solaris or MacOS X, which one would you
prefer as a
Dear Gumpmeisters,
The following 11 notifys should have been sent
*** G U M P
[EMAIL PROTECTED]: Module jakarta-commons-sandbox success, but with warnings.
[EMAIL PROTECTED]: Project nant (in module nant) failed
[EMAIL
Dear Gumpmeisters,
The following 11 notifys should have been sent
*** G U M P
[EMAIL PROTECTED]: Module jakarta-commons-sandbox success, but with warnings.
[EMAIL PROTECTED]: Project nant (in module nant) failed
[EMAIL
Hi,
If Mac OS X means Powerpc, I would prefer Solaris. Mac OS X supports is
still uncertain with the JIT (though we are working on it).
Solaris/sparc/x86 should work at 99%. The remaining percent being due to
some unimplemented feature like Network card interface detection.
Thanks !
Guilhem
On Mon, 11 Jul 2005, Guilhem Lavaux [EMAIL PROTECTED] wrote:
If Mac OS X means Powerpc,
It does.
I would prefer Solaris.
Solaris x86 is the only option here.
Cheers
Stefan
-
To unsubscribe, e-mail: [EMAIL
So, ehm,
I've had to learn a lot about process management in the last two days,
most importantly that java is *really* bad at doing it properly. If you
open
pygump/python/gump/plugins/java/builder.py
and edit the AntBuilderPlugin to have no_cleanup=False instead of
no_cleanup=True, then do a
Need to run each build against a fresh CVS/SVN tree
-
Key: GUMP-146
URL: http://issues.apache.org/jira/browse/GUMP-146
Project: Gump
Type: New Feature
Components: Python-based Gump
Versions: Gump3-alpha-5
[ http://issues.apache.org/jira/browse/GUMP-146?page=all ]
Leo Simons reassigned GUMP-146:
---
Assign To: Adam Jack
Need to run each build against a fresh CVS/SVN tree
-
Key: GUMP-146
Yay! :-)
This is awesome! Having some 'live' data is exactly what we need to make
this move forward fast. Thank you.
You have *no* idea how hard that was (well, actually, I guess at least
adam does :-)).
Actually, I suspect we all have an idea about how much it takes, and all
you've put in.
Stefan Bodewig wrote:
On Mon, 11 Jul 2005, Leo Simons [EMAIL PROTECTED] wrote:
I suspect that using any JVM for which Ant's Execute takes a
different approach (ie not using Runtime.exec) makes the problem
go away.
Hmm, have you run your tests with the equivalent of exec's
vmlauncher=false?
On Mon, 11 Jul 2005, Leo Simons [EMAIL PROTECTED] wrote:
Stefan Bodewig wrote:
On Mon, 11 Jul 2005, Leo Simons [EMAIL PROTECTED] wrote:
I suspect that using any JVM for which Ant's Execute takes a
different approach (ie not using Runtime.exec) makes the problem
go away.
Hmm, have you run
Stefan Bodewig wrote:
I have now. It doesn't help. But it does give a new bit of info --
the /bin/sh process created by the ShellLauncher stalls as well,
Likely some thread waiting for the process to read or the process
waiting for Ant to write something. There have been some process
Gang,
...
00:05:35 INFO Processing LocalRepository:
DEFAULT_GUMP_LOCAL_REPOSITORY
00:05:35 INFO Processing LocalModule: gump3-packages
00:05:35 INFO Processing Project: jdk
00:05:35 INFO Processing Project: jaxp
00:05:35 INFO Processing
Leo Simons wrote:
Gang,
...
00:05:35 INFO Processing LocalRepository:
DEFAULT_GUMP_LOCAL_REPOSITORY
00:05:35 INFO Processing LocalModule: gump3-packages
00:05:35 INFO Processing Project: jdk
00:05:35 INFO Processing Project: jaxp
00:05:35 INFO
20 matches
Mail list logo
