There is a problem with run 'brutus-public' (26012005_180001), location :
http://brutus.apache.org/gump/public
The log ought be at:
http://brutus.apache.org/gump/public/gump_log.txt
There is a problem with run 'brutus-test' (26012005_120001), location :
http://brutus.apache.org/gump/test
The log ought be at:
http://brutus.apache.org/gump/test/gump_log.txt
--
There is a problem with run 'brutus-kaffe' (26012005_090002), location :
http://brutus.apache.org/gump/kaffe
The log ought be at:
http://brutus.apache.org/gump/kaffe/gump_log.txt
---
Should all be trivial changes
Cheers
Stefan
--- gump.xml.orig Wed Jan 26 17:43:16 2005
+++ gump.xmlWed Jan 26 17:47:09 2005
@@ -1340,7 +1340,7 @@
Delivery context library
-
+
@@ -1369,7 +1369,7 @@
Chaperon is a project that he
Dear Gumpmeisters,
The following 7 notifys should have been sent
*** G U M P
[EMAIL PROTECTED]: Project asm (in module asm) failed
[EMAIL PROTECTED]: Project derby (in module db-derby) failed
[EMAIL PROTECTED]: Project logging-lo
Stefan Bodewig wrote:
On Wed, 26 Jan 2005, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
Another way to do it is to blast those directories entirely and have
gump repopulate them from the start, it should be able to do it.
Yes, I know. But given the incredible speed of sourceforge's CVS
right now
On Wed, 26 Jan 2005, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> Another way to do it is to blast those directories entirely and have
> gump repopulate them from the start, it should be able to do it.
Yes, I know. But given the incredible speed of sourceforge's CVS
right now I was willing to
Stefan Bodewig wrote:
On Wed, 26 Jan 2005, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
I'll go through the list of modules sometime later today and purge
unneeded stuff from our workspaces
Just finished. We had some now obsolete copies of cocoon-2.1,
cocoon-lenya and some other modules that have b
I've manually started a new public build at about 4am PST. This right
now fights a Kaffe build for the CPU and will collide with the JDK 1.5
build later, but I had to ensure that it works now - and the next JDK
1.4 build is too far away for me.
Stefan
On Wed, 26 Jan 2005, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> I'll go through the list of modules sometime later today and purge
> unneeded stuff from our workspaces
Just finished. We had some now obsolete copies of cocoon-2.1,
cocoon-lenya and some other modules that have been filled with ja
Hi all,
When I upgraded brutus apt-get installed sablevm as /usr/bin/java,
which I didn't realize until I saw the build failures.
I've removed the symlink to java, javac and javadoc in /usr/bin and
hope the next builds are going to work.
Stefan
--
On Wed, 26 Jan 2005, Andrew McIntyre <[EMAIL PROTECTED]> wrote:
> On Jan 25, 2005, at 2:04 AM, Stefan Bodewig wrote:
>
>> Ideally we'd build everything except the JDBC 2.0 stuff using
>> Gump's default. And build the JDBC 2.0 stuff with JDK 1.3's rt.jar
>> on the bootclasspath.
>
> The easiest w
On Wed, 26 Jan 2005, Samuel Andrew McIntyre
<[EMAIL PROTECTED]> wrote:
> resending with the current account. *sigh*
I've just "allowed" your other address to post as well.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
resending with the current account. *sigh*
On Jan 25, 2005, at 2:04 AM, Stefan Bodewig wrote:
Ideally we'd build everything except the JDBC 2.0 stuff using Gump's
default. And build the JDBC 2.0 stuff with JDK 1.3's rt.jar on the
bootclasspath.
The easiest way to achieve this would be to set the p
On Jan 25, 2005, at 2:04 AM, Stefan Bodewig wrote:
Ideally we'd build everything except the JDBC 2.0 stuff using Gump's
default. And build the JDBC 2.0 stuff with JDK 1.3's rt.jar on the
bootclasspath.
The easiest way to achieve this would be to set the property j13lib to
the location of the JDK
15 matches
Mail list logo
