But struts-taglib doesn't depend on Anakia, so why can Anakia
contribute anything to struts-taglib?
I see:
struts-taglib - jakarta-cactus-framework-12 - checkstyle -
anakia - jakarta-velocity...
OK, but struts-taglib doesn't inherit anything from
It must be possible. I know os.system() or one of the other calls returns
a
process id, so using that we should at least be able to kill all the
processes we spawn directly.
Yup, tried that. Trouble is grandchildren below, not children.
BTW: What is odd is that I no longer see use of
What would you enjoy most? :-D
Getting insights into a worldview outside of my head, and learning from/with
others. :-)
/I/ would love to see you helping out with Gump3.
I'll give it a shot.
I don't quite share your views that Gump needs to be so componentized, but
(1) I don't object to
I saw them in a few places (for example many CLASSPATHs seem to
include bootstrap-ant and ant) but never found the time to complain
until it finally started to cause problems, sorry.
You know, I was suspicious about that, but never quite registered the
severity of the problem.
Ok, so please
I agree w/ that. I'd love to rip out the complex code we have there, and
do
it right. I think the solution lies w/ Process Groups.
I've exercised a test program (I stored it in python/misc/pgrp.py for want
of a better place) that appears to do what we want here. As such, for
'posix'==os.name,
Gentlemen,
Thanks for your input. I recently (an hour ago, after a year+ of fighting
this using finding ineffective solutions) implemented spawning along the
lines of:
1) fork, getting forkPID for the child process.
2) [child]: setpgrp [become a group leader], run child
2) Work on using process groups to kill stalled offspring.
Not sure where stdout is going right now. Output files are empty. I'll
investigate this, and the state of the other tweak, when I next get time @ a
computer.
regards
Adam
You know, we should really investigate using popen...
http://docs.python.org/lib/module-popen2.html
The main reason this is all a mess, and I'm not using the nice/simple posix
functions is I couldn't find a portable (to windows) mechanism to pass
environment (e.g. CLASSPATH) in a thread safe
Stefan
Thanks for your continued patience and assistance, I really appreciate it.
Meaning, do I (except for inherit=jars) not recurse into the
sub-dependency project to get more dependencies?
You recurse for inherit=all and inherit=runtime, you don't for no
inherit attribute or
Is there a way to avoid the dependancy on mysql in gump?
Yeah, it is an optional dependency. Ought cope gracefully if the Python
MySQL driver isn't there, and/or if the workspace doesn't give DB details.
That said, what are you seeing?
regards,
Adam
I then ran into the next problem though: The next thing gump tries to do
is svn update itself. Problem is this machine cannot see the net
(another long annoying story) and so this step fails. Is it possible to
stop gump from trying a self update?
Try exporting the environment variable
The mailserver (hermes) has been flaky since we did the colo move. Some
bits
of brutus may be required to fix it, which means we may have more
downtime.
Sorry :/
Are there any backups/snapshots of Brutus (configurations, installs,
whatever) that we can/should take in case we end up loosing
I propose we start requiring Python 2.4 for Gump3.
Stefan's concerns outstanding, I'm ok with this.
Motivation:
1) the subprocess module described in PEP 324 finally properly solves
running processes within python using a decent interface. It's new in
python
2.4. Needless to say, we run a
On Wed, 30 Mar 2005, Stefan Bodewig [EMAIL PROTECTED] wrote:
On 30 Mar 2005, [EMAIL PROTECTED] wrote:
'MySQL server has gone away'
I've upgraded MySQL on brutus as part of an overall upgrade today, I
didn't see any messages about problems during the upgrade. This was
around 5:30
Hmm, shouldn't the Kaffe run have picked it up as well (the sync
changes)?
Only since I did the migration of TRUNK to LIVE.
Hmm, for some reason java_cup is fine for Kaffe and the run claims it
had been fine for 17 runs.
Oddly TEST seemed to be working also, back when PUBLIC wasn't. I don't
* why does Gump use /usr/bin/java instead of $JAVA_HOME/bin/java at all?
Why? Likely 'cos way back when I wrote this, I didn't know that (cross
platforms) this was a standard location. As such , I kinda relied upon the
path.
self.javaCommand = 'java'
That said, we do have the ability to
Why? Likely 'cos way back when I wrote this, I didn't know that
(cross platforms) this was a standard location.
It isn't, but I thought it was Gump's standard location. After all we
are setting JAVA_HOME in each of our workspaces.
Maybe for Ant's boot, I vaguely recall something like
Dear Sir/Madam,
I was taking a quick look into why this build [1] for XSDLIB [2] started
failing on Apache Gump [3]. (It is a project with a lot of dependees, see
[4]) It seems that this class (amongst, perhaps others) is not being built,
or not being placed on the classpath.
[EMAIL PROTECTED]
So why does Gump think there is a problem here ?
It is something to do with the tests failing. Does Dumpster open some ports
and try to connect to it? [Or, is it all in memory?]
http://brutus.apache.org/gump/public/dumbster/dumbster/gump_work/build_dumbster_dumbster.html
test:
[junit]
Quick Q: how do you find the location to make small changes like this when
you fire up your development environment, and how do you test to make sure
its the only thing to change?
In this case, I guess I believed I knew it, based on prior knowledge of the
code, i.e that all things to do with
This came to the Gump mailing list, but says it is going to itself. Is this
something we need to configure on our wiki? [My e-mail tool didn't put this
into my Gump list for this reason.]
regards
Adam
- Original Message -
From: Apache Wiki [EMAIL PROTECTED]
To: Apache Wiki [EMAIL
http://wiki.apache.org/gump/GumpThree
And let me know where it breaks?
I'm new to Cygwin, so probably failed to install things exactly as you
specified (a problem for later stages, I suspect), however, I can't seem to
get past the mysql step.
$ bash gump test
gump: line 1:
For those reading along, Adam and I find out on ICQ that his bin
subdirectory was in some way wrong containing entirely different cruft.
Hence, he was missing PrintPath and testrunner.py
Yeah, I think I must've used an old old SVN client that (due to some change
in the repository)
Yup, it was this commit, I fell into this circular loop trap -- Jaxen -
XOM - Jaxen. I guess that is something to fix (in either Gump2 or Gump3).
[It is funny how you never give the commits mail list much attention, until
it is so helpful as to tell you the only possible cause that occurred on
Peter wrote:
I discovered in last night's local Gump run that XML Commons has been
updated to require JAXP 1.3, which I didn't have installed locally (just
the
java-xml-pack as suggested by xml-commons.xml). Brutus doesn't seem to
run
at all since Wednesday, but I think it's going to get
On 06-04-2005 17:25, Adam Jack [EMAIL PROTECTED] wrote:
1) External PlugIns
I'd really like to hear design/implementation ideas about
discovery/life-cycle of plug-ins to Gump3.
My initial idea number one: don't design ahead of need.
I hear ya, but we've heard the need for this
This is to be expected - and this is why we had to play with xml-apis
and bootclasspath and build.sysclasspath in order to get everything
built under JDK 1.5 or Kaffe (which contain JAXP 1.3 in their version
of the classlib already).
We probably should add an xml-apis-12 project (either the
I'm not wanting us
to design a generic mechanism, just solve our problem, but is the
approach
the right one? Why are these three walks better than (say) putting
Updates/Builders/Databasers(DynaGumper) in sequence inside one mutlicast
plugin?
Do you think we could do without multiple
with the new xml-apis as well...
http://brutus.apache.org/gump/public/dom4j/dom4j/index.html
regards,
Maarten
Stefan Bodewig wrote:
On Sun, 10 Apr 2005, Adam R. B. Jack [EMAIL PROTECTED] wrote:
Looking at the run I've set off some things are not happy, e.g
XALAN
Aruna wrote:
I'm in need of the rhino jar.
Can you pls send it to me.
I don't know the current version of the jar I've been using, but its
reporting error in optimizer and regexp packages.
I would be of great help if you could mail me the latest jar.
Jars built/used by Gump are not suitable
I'm tempted to do a radical remodelling of our metadata structure to
remove
this kind of ambiguity, even going as far as having conventions like
project-name-is-file-name be gently enforced.
We are rebuilding Gump from the bottom up, so why not do the same with the
metadata? I'm game for it.
I just committed some updates to the gump3 branch that on my machine,
allow me to run on cygwin+winxp+python2.4-win32. Could some people try and
follow
Some cygwin testing:
$ bash gump webgump
hostname: invalid option -- s
Try `hostname --help' for more information.
./bin/debug: line 24:
(I hope the links all work, you never really know with jira ;)
At least for me they didn't 8-)
Nor I. I'll poke around when attempting to use JIRA stops giving me 502
Proxy Error status.
regards,
Adam
-
To unsubscribe,
Propchange: gump/branches/Gump3/
('svn:ignore' removed)
I tried setting svn:ignore on my Gump.wpr file, and couldn't since it isn't
under version control. As such, I tried setting it, for this file, for the
directory -- which seems right, but almost seemed to be ignoring the
I dunno. Could be. Could you be a little more specific about what you're
seeing and when what pauses? On every 'run' invocation the 'gump' shell
scripts removes *.pyc then recompiles and re-imports, that's part of the
delay.
It seems like the program runs, and only once done I see output.
self.rssFile=self.run.getOptions().getResolver().getFile(self.workspace,'rss
','.xml',1)
File C:\gump\python\gump\actor\document\text\resolver.py, line 64,
in getFile
raise RuntimeError, 'Not Implemented on ' + self.__class__.__name__
+ ': getFile.'
RuntimeError: Not Implemented on
C:\gump\pythonpython ..\bin\build.py -w ..\metadata\workspace.xml all
Oops, staring me in the face I didn't see it. Those direct commands
(update/build/etc.) attempt to do a quick semi-interactive text based run,
hence the code path that causes the problem. :(
I don't have time to look into
I'm still finding it hard to make progress, 'cos I can't see log output.
This (captured below) is all I see, and either there is a problem with
logging on (Cygwin) or the Mutliplexer isn't dispatching, or something. Do
we need to ask for non-buffered log files, or do some flushing prior to
exit,
Leo wrote:
* pygump/python/gump/plugins/builder.py: commenting out this existence
test makes the associated testcase fail under posix. Error log:
Sorry, I should've run/fixed the test case. I suspect that failure to find a
script file is not more severe an error than failure to execute one, or
Change config.py; configure the logging package by hand (I think that's
called basicConfig()) instead of using a config file, and make it output
everything to the screen. We can fix it later, and there's no test to look
for the existence of log files so you're not breaking anything ;)
Ok,
If you think of a Project as a node, a Dependency as a vertex, then you
can
have an array of DependencyInfo as multiple vertex colorings. Was my
thinking.
I sorta got it, but I guess I was thinking based upon existing Gump
metadata/documentation. I had no metadata sample for Ant, so built it
In fact, I'd much prefer the xml to be:
[...]
Or rather:
project name=a
depend project=b
output type=jar id=basic runtime=true/
output type=jar id=extension1 runtime=true/
output type=native-lib id=fancy-feature optional=true/
/depend
/project
I'd go
OTOH, debug statements have also worked reasonably for ages. Simplest
thing,
simplest thing ;)
Yup, I'm there for now, however I was thinking about communication between
two separate developers of plugins, perhaps the latter not being able to
hack debug statements into the former. Still, right
Could it be that the new Kill prcess group stuff is killing too many
processes, taking the main Gump process down with it?
I don't think it is the new stuff, per-se, but the fact that some old
slipped in with the new. The old killed the Gump process 'cos it was
running within a standalone
The problem must have been some apt-get installation that added a
symlink to gij into /usr/bin/java. Obviously Gump still doesn't use
$JAVA_HOME.
Much as my read of the code would hope to differ, my read of the log say
that Gump (despite efforts) isn't defaulting to $JAVA_HOME/bin/java, but
thanks adam. i was looking into the code myself when i saw ur email :)
will wait for ur patch (both trunk and live...right?)
Nice to have company in there dims. :-)
Let's do a test run, see if things are working (if we can be certain) and
then do a release.
I've been wondering whether its a smart idea to change a whole lot of this
now. I think the Normalizer code and friends shows we can keep the model
the
same for now yet develop most of our code the way we see fit. The new
model
will fall out, and we'll immediately know what the transformation
: Davanum Srinivas [EMAIL PROTECTED]
To: Adam R. B. Jack [EMAIL PROTECTED]
Cc: Gump code and data general@gump.apache.org
Sent: Tuesday, April 26, 2005 1:56 PM
Subject: Re: Has the Kaffe Gump run died?
no luck :( kaffe run still dies.
-- dims
On 4/26/05, Adam R. B. Jack [EMAIL PROTECTED] wrote
Hey Leo, thanks for taking a peek @ this...
Looking at the code, I see no 'setpgid', which is disturbing (to say the
least).
Well, there is a setpgrp. That's setpgid(0,0), or something.
Sorry, typo, I meant : os.setpgrp().
The logic of this kill means the forked child needs to place
Thanks Leo/Stefan.
With WingIDE not adding files/directories when SVN brings them down anew,
and with me having manually add things w/ SVN, refactoring is a pain. I was
putting them into the plugin/builder.py file until I re-read the JIRA entry
on what was requested of me. I quickly moved things,
I fixed it. Please try to run ./gump test before every commit, and
make sure it completes without errors.
I will. (Further, I'll even add some test sooner or later, not just dilute
the code to test ratio. Promise. :-)
Since I'm trying to grab precious minutes of time here and there, the
I guess this has to be expected - and it will extend beyond Xerces and
to Xalan sooner or later as well.
Makes me wonder if we want a disclaimer (general message) ability that
get's sent out w/ each Gump notification. i.e. Caution : Work in progress
on migration to JAXP 1.3.
Since I'll be
Lemme know what you think!
I love the concept. Unfortunately, on Cygwin, I see this below. I get pretty
much the same whatever Gump command I try.
Adam
$ bash gump kill
1152 [main] bash 3292 fork_parent: child 4012 died waiting for longjmp
before
initialization
gump: fork: No such file or
Is there a way to increase this timeout, or remove it altogether?
I see this in the code:
TIMEOUT=60*60 # 60 minutes (in seconds)
if os.environ.has_key('GUMP_TIMEOUT'):
TIMEOUT = string.atoi(os.environ['GUMP_TIMEOUT'])
Setting to 0 will (I believe) remove it.
Brutus will be going down somewhere today or tomorrow. It will be wiped to
start hosting Apache's SVN install.
For somebody trying to play catch-up, where are the alternative places to
run a Gump instance? I'd like to be able tinker with a Gump3 on some *nix
type platform, and I could perhaps
DON'T KILL THE LOGS!
Would that they'd be logs. We never had space (or haven't optimized
sufficiently) to keep the build logs. Gump's (internal) logs aren't worth a
lot, but exist, if wanted. I hope we give good consideration to 'Net
history (and access for external services, e.g. google)
I suspect we have a circular dependency in the metadata (that isn't
detected) but I don't have time to investigate tonight/tomorrow morning.
Since there were only two metadata changes today, it ought be easy to undo.
regards
Adam
- Original Message -
From: [EMAIL PROTECTED]
To:
I think in these (early days, maybe through-out the life of Gump3) the
toughest part is the property messaging protocol(s). Basically Gump3
internals are based upon trust respect between plugins -- like a good
OSS
project :-) -- but it doesn't (yet) have the internal equivalents of
Adam, I had discussions like this for years and years over in avalon land.
Enuf said! ;-)
I was thinking of the update build document[to DB] chain (say) for
ant. Once done, are all the details of the build, that documentation
used,
still needed?
Once done, don't we just exit the gump
On Sun, 22 May 2005, Adam R. B. Jack [EMAIL PROTECTED] wrote:
Does it make sense to move public (with nagging) to JDK 1.5?
Not yet, IMHO.
Ok. I just didn't want us to give up on all the Gump flavours w/o having
asked the question.
Given that we can't support all configurations
Is there an option within gump that sets the time gump is willing to wait
for the build to finish?
Graham
Did you not notice this response to your previous mail, or did it not help?
http://marc.theaimsgroup.com/?l=gumpm=111620403011709w=2
regards
Adam
1) Removed Homedir, since home isn't an output.
Yes it is! Just think JAVA_HOME, ANT_HOME, JIKES_HOME, etc. A lot of
native
code projects find each other via a prefix directory. Step out of the
confines of the java world :-)
I'm not thinking Java, I'm thinking Gump.[1] What you are
1) Added to the tsws1.xml workspace:
Which is? That info should not be in the commit but rather in the xml
comments for the workspace.
It is a hostname I've used for a couple of years. It is just like
giraffe.xml, I assume, although I suspected that was some new Python module
(like cheetah
Could we get back to this thread above (using http://tinyurl.com/4qt9a to
get to the attachment) and see where we want to take it? I see that Gump3
has a schema that does not include some of the additions mentioned in the
thread.
Also, I'm trying to flesh out DynaGumper (the Gump3 DB plugin) and
I've enabled public on vmgump [1] to (1) do an official build each day and
(2) deliver notifications via e-mail when it does. With Brutus gone, it
seems time.
I just burned more time than I wanted spend tracking down why vmgump was not
sending notification e-mails. It logged that the
So what's the latest situation on vmgump? are the results published
yet? (jdk1.4?)
http://vmgump.apache.org/gump/public/
regards
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
I suspect Leo is either (1) swamped or (2) practicing I'm only one Gumper,
not the oracle, so figuring it out as a group is best or (3) both. As such,
I say go for it, and we'll try to compress disk requirements to fit. I
suspect we'll fit two (just) and I'm game for the second to be Kaffe.
[We
It seems we have a bunch of these.
-
svn: Working copy 'muse' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
details)
-
Ought we consider an 'svn cleanup' before each 'svn
I think it comes down to relaying. Brutus was allowed to, VmGump not. I've
entered this:
http://issues.apache.org/jira/browse/INFRA-365
regards
Adam
- Original Message -
From: sebb [EMAIL PROTECTED]
To: Gump code and data general@gump.apache.org
Sent: Wednesday, June 01, 2005 5:44
I hope the next public build on vmgump will be a full one, not an
Axis-only one, so that we can crawl back to normal operations.
Sorry about that, I was trying to debug why mail wasn't going out (yesterday
morning) and just selected an AXIS one 'cos I knew a nag ought go. I ran a
full build
Sorry about that, I was trying to debug why mail wasn't going out
(yesterday
morning) and just selected an AXIS one 'cos I knew a nag ought go. I ran a
full build right afterwards, but for some inexplicable reason it hung,
hence
no more Gump builds. I've killed that, and hope the next run
I'm not going to be of much help until Sunday. I've set up accounts on
captainfantastic, all that remains to be done is to copy
.ssh/authorized_keys into the right homedirs (which are under /Users on
the
mac). Ie along the lines of:
scp -r minotaur.apache.org:~bodewig/.ssh \
On 06-06-2005 01:22, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
1) added -b --do-builds (defaults to FALSE, like --do-updates, for
initial
devel)
Do you think we should have a stage abstraction or something like that,
ie, will there be many more --do-blah-blah? If so, we might want to
On Mon, 6 Jun 2005, Bill Barker [EMAIL PROTECTED] wrote:
According to http://vmgump.apache.org/gump/public/index.html, Gump
hasn't run since Midnite last Friday. Is is down for a reason?
There was a hanging Gump instance from June 5th, I've killed that and
asserted that no lock files
Me too. I can't think of a good reason why it ought hang, and I couldn't
find a cause when I last saw a hang (just before). I fear this might be
happening every time.
Ok, the what-is-becoming usual, i.e. circular dependency in the metadata
(dom4j/jaxen, I believe). Clearly given the
. Adam, could you give
some pointers (filenames and linenumbers) where you think the insertion
point for a cyclic dependency checker should be in gump3?
I think Gump3 has some such code in there already.
What I think is missing is an (equally supported) use case of check
metadata that is as
Gak, damn. Bad to worse. Working on it...
Adam
- Original Message -
From: Stefan Bodewig [EMAIL PROTECTED]
To: general@gump.apache.org
Sent: Tuesday, June 07, 2005 2:57 PM
Subject: Re: Gump runs stopped?
On Tue, 7 Jun 2005, Adam R. B. Jack [EMAIL PROTECTED] wrote:
In short
Ok, I believe I have rolled back the last update of LIVE from TRUNK. I
didn't remove the work from TRUNK 'cos I'd like to test it/fix it. Please
let me know if you see anything wrong w/ these SVN steps. (I did a merge w/
last but one release, then re-commit.)
BTW: Gump nagging is off for a short
340736 3% /tmp
/dev/sda5 4807056683168 3879704 15% /usr
/dev/sda6 2885780596924 2142268 22% /var
/dev/sda9 21520948 11041700 9386028 55% /x1
Gone fishing^H^H^H^H^H^Hcamping...
regards
Adam
- Original Message -
From: Adam R. B
This will require us to remove the checked out source trees. I'll do
so once the current run has come past the three directories.
I had to manually kill a bunch of processes and remove lock files
since the 6pm run didn't kill all childs, or so it seemed. There have
been five lock files
Actually, the workspace is in Gump3/metadata (not Gump3/fixture/metadata).
Once SVN is back up I'll commit my improved fix.
Where is the correct place for the workspace? I'd like to get VmGump
building it, and us growing it (with properties, etc.) on an as needed
basis. I'm game to either build
Sorry, can you be more explicit? What sort of locks?
BTW: We can limit the number of background threads (to none, if needed) for
updates by editing the workspace definition.
regards
Adam
- Original Message -
From: Stefan Bodewig [EMAIL PROTECTED]
To: general@gump.apache.org
Sent:
: Monday, June 20, 2005 8:46 AM
Subject: Re: Killed Gump, removed locks
On Mon, 20 Jun 2005, Adam R. B. Jack [EMAIL PROTECTED] wrote:
Sorry, can you be more explicit? What sort of locks?
gump.lock was present, and belonged to the Gump instance from Sunday
noon.
Inside of workspace/cvs
I also use it as you use it, a sanity check that it ran (and these days --
on vmgump -- didn't stall.)
That said, I also often eyeball it for candidates that I can go bug. When
Gump is stable, sending notifications as needed, it annoys me if ASF
projects don't accept notification. I also go and
Does anyone ever do anything with the content of these messages?
Yes, I look for module failures and even worse for module success but
with warnings. The later usually means stuff has been moved in svn,
we are now unable to check it out, but Gump doesn't consider it a
failure.
Want
The commit itself made me itch to spend more time on Python, the exact
same code-change in three different files.
Yeah, bad copy-n-paste on my part (ok, 1 of the 2 copies). The more I look
at Gump2 these days, the more I feel I need to spend time on Gump3 see if
I can do Python right these
Adam Jack wrote:
I've been tinkering with an IRC plug-in for Gump3 that allows it to interact
with an IRC channel.
Whoah! Cool! Is this up and working on any of our servers atm? Can we
fix up a cronjob somewhere to enable this?
I'm not able to get my SSH tunnel to work right now (since the
bash gump run [EMAIL PROTECTED]/#asfgump
Ok, that needs quoting, i.e.
--irc='[EMAIL PROTECTED]/#asfgump'
which is what I just added to gump3 on VmGump. If we find it too chatty we
could move it to #asfgumprun or something like that.
Which remind me. Folks who want to, ought add this
Justin, welcome! It's a pleasure to have you on board.
Yup, welcome congratulations. :-)
I would suggest you to start from Gump 3, which is a little cleaner and
less complex and has a more modular architecture.
What do others think?
Gump2 has an integration with Maven, albeit at the
Thomas,
Adam you talked about implementing it with python, it will take me a lot
of time since i haven't used python before so I rather do it in Java.
But if you whant it in python fine I'll take the time and sit to to
learn python. Final result will take abit longer with python thats all.
I
Stefano,
I would like to know who is working on what, who is the mentor and what
their plans are.
When I sent the list of the two to the Gump PMC list, I failed to recall
that the URLs were protected. You e-mail is a timely reminder to 'speak' to
those who got accepted, and those who did not.
Mind filing this via JIRA, so we don't forget it [like I have]?
regards,
Adam
- Original Message -
From: Bill Barker [EMAIL PROTECTED]
To: general@gump.apache.org
Sent: Tuesday, June 28, 2005 8:14 PM
Subject: JMX Remoting
Tomcat now requires JMX Remoting to build. I've changed the
]
http://www.ibiblio.org/pub/packages/solaris/sparc/html/GNUmake.3.78.1.html
- Original Message -
From: Adam R. B. Jack [EMAIL PROTECTED]
To: Apache Gump general@gump.apache.org
Sent: Thursday, June 30, 2005 3:18 PM
Subject: Re: gump.zones.apache.org
With a little more help from Leo
Thomas et al,
We need to pick a technology to use to display the contents of a database
via a webapp. We are in the fortunate position of having more technologies
available to use than we could wave a stick at. Clearly we could do the job
with all of them. Let's explore them and come to a
They have a web interface to the current build state here:
http://spikesource.com/spikewatch/
Just thought people might be interested...
To me, it looks pretty laughable compared to gump... what am I missing?
Perhaps the charts and/or historical data? Some seems to be there just
What in addition to this do I need to configure to get gump to send
emails?
I'd add a nag/ to the workspace to get success/failure e-mails, and run
with --official (to get the nightly reminders.)
http://gump.apache.org/metadata/workspace.html#nag
I'd also add an administrator to the
Unable to mail failure report : [u'192.168.1.24', 25, '',
u'[EMAIL PROTECTED]']
This needs a better error message, please add a JIRA entry. This is 'cos
there was no 'administrator' setting in the workspace (hence the empty
third entry, the 'to'.)
regards
Adam
so I figured we'd need to get Thomas some more data. Rather than invent
it by hand, I figured I'd fix up the dynagumper plugin to work properly.
See
Cool, that is what I've been trying to do with Gump3 on VmGump:
Oh, and you're now greeted with 100s of lines of error messages if you
don't
I'm halfway torn between throwing history away and simply importing
CVS HEAD manually and doing a trunk-only conversion. Well, not really
true, I'd probably prefer keeping the history, but could live without
it. What's your preference?
+1 for keep the history.
The second question is,
The following annotations (debug/informational/warning/error
messages) were provided:
-ERROR- Unhandled Property: --enable-libxml2 on: Configure
on Project:monaco-xml-configure
It seems that gump is not happy with the --enable-libxml2 option to
configure, although it does work.
501 - 600 of 610 matches
Mail list logo
