Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)
Stefano Mazzocchi wrote: Davanum Srinivas wrote: Stefano, i think i poked through all the jars in JDK 1.4 and did not find it...hence the question. Found it!!! The problem is in the XJavac task that Xerces2 uses to compile stuff (probably it's a left-over workaround from an ant bug on the javac task). Now, not only I can't find the sourcecode of that sucker http://cvs.apache.org/viewcvs.cgi/xml-xerces/java/tools/src/XJavac.java?view=markup http://cvs.apache.org/viewcvs.cgi/xml-xerces/java/tools/bin/xjavac.jar?rev=1.6&view=log - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: a few questions on our descriptors
Stefano Mazzocchi wrote: There are two places where you can put 1) inside 2) inside jakarta-slide.xml uses both. First of all, what is the rationale behind this? if a project depends on another project, why do we need to specify things further for ant? Think of elements inside of as macros. It expands to a element inside of and a element inside of . Gump has always needed elements. Some projects have required the same information (specifically jar paths) to be provided to ant as properties. As noted in the documentation[1], "that has become a common enough practice that it makes sense to introduce this element". Also, I don't understand the difference between: and why are they different? and, if so, why are their methods so similar? They are intentionally very similar. A inside of an definition has exactly the same meaning as a inside of an definition PLUS a element inside the project definition (minus the property attribute). - Sam Ruby [1] http://gump.apache.org/metadata/builder.html#depend - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unicode & Python interacting with File Systems
Adam Jack wrote:
1) Is "\xC3\xA9" a 'single' unicode character already? Is it being
considered as two by accident?
unicode("\xC3\xA9","utf-8") == u'\xe9'
http://www.unipad.org/unimap/index.php?page=detail¶m_char=00E9
- Sam Ruby
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: /usr nearly full
Leo Simons wrote: Hi gang, [EMAIL PROTECTED]:/usr/local/gump$ df -h FilesystemSize Used Avail Use% Mounted on /dev/sda1 7.4G 1.4G 5.7G 19% / tmpfs1011M 0 1011M 0% /dev/shm /dev/sda6 25G 2.1G 21G 9% /home /dev/sdb6 32G 26G 3.9G 87% /usr /usr/local/gump is kinda full, especially as it grows during gump runs (ie it was /dev/sdb6 32G 29G 1.1G 97% /usr a while ago). Something's gotta give. Or something has to move from /usr/local/gump to /home/gump. Some directories like /usr/local/gump/public/jars seem to only grow. A cron job such as the following would remove files that are older than a week: find /usr/local/gump/public/jars -ctime +6 | xargs -r rm - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: APR, httpd and gump
Stefan Bodewig wrote: On Thu, 16 Sep 2004, Graham Leggett <[EMAIL PROTECTED]> wrote: I know next to nothing about python, So we are in the same boat here 8-) The key thing seems to be the restriction where all scripts on unix have to end in ".sh" for some reason, platform independency, like I said. In reality I'm only aware of a single project that uses it, Ant to bootstrap itself. which typically they don't do. Is it possible to remove this restriction? Should be, but I'm not familiar enough with Python to try either. It is not that complicated. The current code looks like: # Add .sh or .bat as appropriate to platform scriptfullname=scriptxml.name if not os.name == 'dos' and not os.name == 'nt': scriptfullname += '.sh' else: scriptfullname += '.bat' One thing that would not be hard to add something like the following: if not os.path.exists(os.path.join(basedir, scriptfullname)): - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: rev 36230 - in gump/trunk: . bin cron log mysql python/gump python/gump/core python/gump/document python/gump/document/xdocs python/gump/java python/gump/model python/gump/mysql python/gump/notify python/gump/runner python/gump/shared python/gump/stats python/gump/stats/dbm python/gump/stats/mysql python/gump/utils test
[EMAIL PROTECTED] wrote: +def configureDB(): +conn = MySQLdb.Connect( +host='localhost', user='root', +passwd='', db='gump',compress=1, +cursorclass=MySQLdb.cursors.DictCursor) Why is user, passwd, and db hard coded in mysql/data.py? A more general question: does BrutusConfig[1] need to be updated to reflect any steps related to the setting up of mysql? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] a strategy for better gump action/reaction analysis
Stefano Mazzocchi wrote: Both projects compiled yesterday. We have artifacts from both in the archive. If you can do "cvs update -D", you don't need artifacts. I used to routinely be able to isolate the individual commit that caused a given failure by one by one rolling back projects, until the failure went away, and then doing a binomial search over the time range to isolate the individual commit. If A builds but B doesn't, there are two possibilies: 1) B broke itself 2) A broke B A breaking B doesn't imply fault. Counterexample: there were cases where log4j had deprecated an interface for literally YEARS (I'm not exagerating here), and when they removed it, builds broke. Nagging on deprecation warnings is difficult. When the deprecation is initially inserted into the development stream, there has been no release, and projects are typically (and rightfully) reluctant to step up to a daily build. Since we know that B-yesterda built against A-yesterday, than the result of the B-today against A-yesterday will tell us if it's 1) or 2) Ok, with two projects is easy, what about three? C -> B -> A worked yesterday, but today C is broken and B and A work. Who broke the build? First of all, is it safe to assume that since A is shielded by B and both B and A work, A has no influence on C? What matters is the jars that are used to build C. If A is visible at all, then it it relevant. It might not be directly involved at compile time, but it could be relevant at runtime. Furthermore, compile time often involves things like XSLT translations, so the distinction between compile time and runtime is not necessary pertinent. I remember a Xalan change that broke FOP's build for this reason. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RDF
Adam R. B. Jack wrote: I'm going to look into: http://rdflib.net/latest/ I've read some good things about it as an RDF parser and triple store. Other suggestions welcomed. Before you do, read this: http://www.xml.com/pub/a/2003/08/20/dive.html And Stefano's comments on N3: http://www.betaversion.org/~stefano/linotype/news/57/ You might also want to take a look at: http://jena.sourceforge.net/ - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: [jira] Commented: (INFRA-95) Please create a python@apache.org mailing list]
Why doesn't the gump PMC "sponsor" this mailing list? - Sam Ruby Original Message Subject: [jira] Commented: (INFRA-95) Please create a [EMAIL PROTECTED] mailing list Date: Thu, 22 Jul 2004 11:02:17 -0700 (PDT) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] The following comment has been added to this issue: Author: Adam Jack Created: Thu, 22 Jul 2004 11:02 AM Body: This request is suspended (and can be closed/deleted) since (per http://www.apache.org/dev/list-setup.html) it is an invalid request; since no PMC made it. - View this comment: http://issues.apache.org/jira/browse/INFRA-95?page=comments#action_36825 - View the issue: http://issues.apache.org/jira/browse/INFRA-95 Here is an overview of the issue: - Key: INFRA-95 Summary: Please create a [EMAIL PROTECTED] mailing list Type: Task Status: Unassigned Priority: Major Project: Infrastructure Components: Mailing Lists Assignee: Reporter: Adam Jack Created: Wed, 21 Jul 2004 8:25 AM Updated: Thu, 22 Jul 2004 11:02 AM Description: Based upon this thread, I'd like to request a [EMAIL PROTECTED] mailing list. http://issues.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=822734&to=822734&first=1&count=13 This intention for this list is for general Python discussion amongst Pythonically inclined (or simply Python using) ASF folk. This list is not part of a project, nor does it have (to date) a tighter focus than things related to Python. I am willing to be moderator (and I'll look for another volunteer down the road). I don't know where (if anywhere) this list ought be 'advertized', nor if I can do that myself (I doubt I have much Karma @ ASF, I only commit to Gump and Depot). Thanks in advance for any pointers. Please let me know (via comments on this issue) if this request is premature/misguided, and/or if I can/should do anything more prior to making this request. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDK 1.5
Adam R. B. Jack wrote: Yeah, there is something so rewarding about the 'thank you' one gets 99% of the time. Human feedback it is. Thanks. The other aspect I didn't mention is that you can proceed at whatever pace you want. Building with JDK 1.5 at the moment is a "nice to have". Identify one project a day or one a week or one a month as you have time. While you may see an occasional regression, overall progress tends to be cumulative. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fw: [CRIMSON] Crimson on JDK1.5
Adam R. B. Jack wrote: This seems (to me) the obvious outcome (although I had to ask). Can anybody help me with why XERCES depends upon CRIMSON? http://brutus.apache.org/gump/jdk15/xml-crimson/xml-crimson/details.html http://brutus.apache.org/gump/jdk15/xml-crimson/xml-xerces/details.html Is this an historical dependency? [Would that I had the resources to answer my own questions, but then, I'd still rather get human insights to enhance empirical.] Because I am evil? ;-) Ant requires an XML parser. Xerces 2 contained common code (or at least package names) with Xerces 1. The Xerces team routinely used Xerces 1 in their build environment in order to build Xerces 2. Every once in a while, and completely unbeknownst to the Xerces development team, Xerces 2 would become broken or incomplete, but they would not know it because some aspect of Xerces 1 would "bleed through" the build environment. Compiling with a non-Xerces compiler allowed such problems to be identified. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDOM
Adam R. B. Jack wrote: I sent e-mail to these folks a week (maybe less) ago, no response (so far): Who, precisely? I have found [EMAIL PROTECTED] to be responsive. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BSF
Adam R. B. Jack wrote: Anybody aware of the status of BSF? It got donated to the ASF: http://jakarta.apache.org/bsf/ - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDK 1.5
Adam R. B. Jack wrote: How do we get the word out about the JDK 1.5 Gump runs? http://brutus.apache.org/gump/jdk15/ Teams may not be shooting for JDK1.5 compliance right now, but if Gump could do the leg work for them, maybe they'd do minor tweaks if needed. I could see this help user, but I feel it has to start sooner, not later (so no releases go out w/ minor JDK1.5 nits if could be avoided). Ought we consider notifications? Other ideas? The way I did this in prior releases was to build it without notification, and then personally approach the projects which had failures. I kept a catalog of problems encountered which I dutifully submitted to Sun (who had made public claims about being 100% backwards compatible - bunk!). These problems were, of course, summarily ignored. My experience was that projects by and large were extremely appreciative of being given specific and human feedback, and I found the process to be very rewarding. Still, in the case of 1.4, there was a gap of six months to a year before everyone felt confortable with making it "official". - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to start with gumpy
Stefano Mazzocchi wrote: I want to start using gumpy for our project at MIT. Is there an howto to start? If you have never run Gump before, I strongly recommend that you first do a "normal" build with Apache projects before you try adding your own projects. A good place to start is http://wiki.apache.org/gump/BrutusConfig - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Was python a good idea?
Nicola Ken Barozzi wrote: Java: it's truly cross-platform and the Gump PMC members all know it quite well; easy to install * cons: dunno I've had a fetish for both complete reproducibility and for the overall build environment to be provably unable to effect the build environment. There were a number of cases where this has come in handy - I've been able to reproduce problems outside of Gump. The one notable exception: build.sysclasspath I'm particularly wary of class loader tricks, particularly when interacting with things like bootclasspath and compiling against Apache's version of Xalan. When these tricks work, they are unquestionably FM(*). When these tricks fail, they are also FM. - Sam Ruby (*) F'ing Magic. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump[y] internals re-design
Adam R. B. Jack wrote: (it is slow to load 600 projects) why? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Brutus new kernel
Thom May replaced the stock 386 kernel with a 686-smp one that recognizes both processesors, recognizes the Intel hyperthreading, and the full 2 gig of RAM. Rumor has it, that this should make things faster. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Brutus new schedule
Adam R. B. Jack wrote: 0 0,3,6,12,14,15,18,21 * * * cd /usr/local/gump/public/gump; /bin/bash gumpy.sh Is the 14 intentional? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cron on brutus
Adam R. B. Jack wrote: [EMAIL PROTECTED]:~$ crontab -l 30 3,9,12,15,21 * * * cd /usr/local/gump/public/gump; /bin/bash gumpy.sh > /home/gump/CRON_DID_THIS I keep trying to set values to catch the clock (i.e. I set 30 & 12 at 12:25) but I can't see a /home/gump/CRON_DID_THIS. I started this 'cos I don't see any fresh Gump run since I made the edit. Do I have a typo, or mistake? Am I missing something? When I've tried to do this in the past, I've always ended up doing something like the following: 30 3,9,12,15,21 * * * sh -c "cd /usr/local/gump/public/gump; /bin/bash gumpy.sh >/home/gump/CRON_DID_THIS 2>&1" I think it is because redirection is a shell function. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cron on brutus
Nick Chalko wrote: Can't send mail: sendmail process failed with error code 1 Any ideas what is wrong Um, perhaps that sendmail isn't installed on the machine: [EMAIL PROTECTED]:~$ sendmail -bash: sendmail: command not found - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTPD down on Brutus?
Adam R. B. Jack wrote: I can't seem to get to Brutus via HTTP: http://brutus.apache.org/gump/public/ nor can W3. From what I can tell, httpd was up and crashed, without leaving anything in the error log. I restarted httpd, and now I am doing a dist-upgrade to get the latest maintenance. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running Gump (public) on Hermes/Brutus N times a day.
Adam R. B. Jack wrote: Does anybody have a problem with me scheduling these two to run public Gump runs 4 times a day, each ? I'd set the cronjobs to run something like: brutus:0,6,12,18 hermes:3,9,15,21 Once we get the forrest run out of the picture (sometime, worst case, in next few weeks I hope) the runs oughtn't take more than an hour or so, so most of the 6 hours would be idle. Would folks want these niced? I don't see a need for "nice" on brutus. The purpose of that machine is to run Gump. If performance becomes a problem, we can ask for help to get the machine to take advantage of it's second CPU and additional memory. When hermes goes into production, we may lose it for Gump purposes. Meanwhile, nice there might be a good idea. Having gump first sniff to see if it is current running and quickly exit if so might be a good idea. Perhaps using some code like this: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65203 - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status blogging
Adam R. B. Jack wrote:
Beyond those two the next biggest hurdle is the markup that is produced.
If that is relatively straightforward (in other words, uses techniques
like CSS instead of things like spacer gifs and nested tables), then
building CGIs is downright trivial.
I know Leo has found some ways to build WWW applications in Python that he
is interested in. I would hope his efforts, and these, could share at some
level. Perhaps share a Python webapp framework (if one is picked), but there
is no real need for this to be the case since you are talking simple CGIs.
[When you say CGI I'm reading good old fashioned "common gateway interface",
right?] I guess sharing could just be a WWW server (with auth) and a simple
webapp space/look-and-feel.
Framework? We don't need to steenken framework. Take a peek at:
http://brutus.apache.org/gump/public/test.cgi?foo=bar
Anything you can do from python can be done via CGI. Anything.
Below is the source. Note output is declared as text/plain, but
text/html, or even application/atom+xml are possible.
I did say "downright trivial".
- Sam Ruby
-
#!/usr/bin/python
print "Content-Type: text/plain\r\n\r\n";
import cgi, os, sys
print sys.stdin.readline()
fs = cgi.FieldStorage()
print 'type\t',fs.type
print 'headers\t',fs.headers
print 'path\t',os.path.realpath('.')
print
for arg in fs.list:
print arg.name, arg.value
print
for (key,value) in os.environ.items():
print key, value.strip()
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: running gump (again)
robert burrell donkin wrote: i'm probably going to be (trying) to get gump up and running (again) on my mandrake box sometimes soonish but i though it best to enquire as to the current state of the code. Even though you will be running mandrake, it probably is worth taking a peek at the following: http://wiki.apache.org/gump/BrutusConfig - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PMC-VOTE] Bylaws
Stefan Bodewig wrote: On Tue, 13 Apr 2004, Sam Ruby <[EMAIL PROTECTED]> wrote: I'm uncomfortable with the two places where the bylaws talk about requiring unanimous votes. Both talk about the extremely rare case of removing a committer and/or PMC member. Particularly in the case of a rogue committer, swift action may be required. Would this become any better if we used any arbitrary majority number like 3/4 or 2/3? I don't think so. No. From a board perspective, the chair of the PMC is held accountable to such decisions. Exactly. Even if the bylaws don't spell this out, the chair would be able to act quickly on his/her own. Do you think we need to clarify the "superhuman powers" of the chair? Not necessarily. What concerns me is the explicit spelling out of bylaws that appear to define a process that not only is never expected to be executed, but would be counter productive if attempted. - Sam Ruby P.S. With or without any changes related to this comment, you have my +1 to proceed with these bylaws. Bylaws can always be amended. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: headless java question
Stefan Bodewig wrote: On Tue, 13 Apr 2004, Sam Ruby <[EMAIL PROTECTED]> wrote: Is there a small, standalone testcase for proper headless java operations? Not that I'd have one. A simple test would probably be something that just opens a java.awt.Frame and does nothing else. Found one: http://java.quest.com/support/search/JclServerChart/pr/jcl_serverchart_pr_1.html Simply removing the references go GifEncoder seems to do the trick. At the moment, the process seems to be to blindly installing what people tell me might work, and waiting for a run to complete. If you install Xvfb with all its dependencies you can be sure that everything for AWT is there as well. It may be too much, though. No, it is not enough. I also had to install libxt6 and libxtst6. Once done, java -Djava.awt.headless=true MyStandaloneExample ran without complaining. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PMC-VOTE] Bylaws
I'm uncomfortable with the two places where the bylaws talk about requiring unanimous votes. Both talk about the extremely rare case of removing a committer and/or PMC member. Particularly in the case of a rogue committer, swift action may be required. My concern is that unamimous does not scale to the current "all active committers who have been around long enough to establish a track record" approach to defining PMC membership. From a board perspective, the chair of the PMC is held accountable to such decisions. If such a chair were ever to run amuck, then the board would simply replace the chair. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status blogging
Leo Simons wrote: Stephen McConnell wrote: Adam R. B. Jack wrote: 4) The 'root cause/resolution' for outage X/Y (between too parties) was Z. Log it/Blog it... ++1 If this was available I would definitely use it to post details about what is going on relative to the projects I'm associated with. Furthermore - it would provide an extra hint that there is someone somewhere dealing with a problem as opposed to waiting n days for a change in status - which is something I would find really valuable in terms of projects I'm dependent on. you know, we do have one of the authorities on blogging and syndication right here as a resident gump meister. Someone who happens to know python rather well to boot. And someone who's itching to write code according to his blog... The hardest thing is authentication (something that the peas&carrots blog sidesteps nicely via CVS). Starting long running tasks is made possible by platforms that support fork (sorry Windows). Beyond those two the next biggest hurdle is the markup that is produced. If that is relatively straightforward (in other words, uses techniques like CSS instead of things like spacer gifs and nested tables), then building CGIs is downright trivial. If we can settle on an authentication mechanism, and agree to not worry about Windows initially, and get a clean CSS-based skin for gump pages, I can start picking off tasks from Adam's original list. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
headless java question (was: jira GUMP-45)
[EMAIL PROTECTED] wrote: 2004/03/29 02:02:19 ERROR - jorphan.test.AllTests: error adding test : java.lang.reflect.InvocationTargetException [snip] Caused by: java.lang.UnsatisfiedLinkError: /usr/local/j2sdk1.4.2_04/jre/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory Further details are in the JMeter test output, see: http://brutus.apache.org/gump/public/jakarta-jmeter/gump_work/build_jakarta-jmeter_jakarta-jmeter-test.html (long) Is there a small, standalone testcase for proper headless java operations? At the moment, the process seems to be to blindly installing what people tell me might work, and waiting for a run to complete. I could iterate faster with a testcase, and I presume that this would be a fairly trivial thing to recreate, but I don't know enough to create this myself. Any takers? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: gumpy.lock (was Re: Server Times (UTC) and Differences)
Adam R. B. Jack wrote: I'll enter a JIRA entry to look into a real locking mechanism, one where the OS cleans up upon process termination. [Probably something to do with lockf().] http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65203 - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: timeout
Adam R. B. Jack wrote:
BTW: Your request to have xdocs pages (for projects, etc.) built as the
come, really ought be doable w/o much change. Calling
ForrestDocumenter.documentModule or ForrestDocumenter.documentProject ought
have no dependencies. Either we write directly to the log directory
(possible) or we write to staging and sync. I don't quite know how to do
this to a staging area, and then sync ('cos there are N pages) but I'd like
to try, otherwise our site could accumulate a lot of flotsom and jetsom.
If you want to have a dig in, feel free. If this area is a little
'convoluted' and you'd like me to have a shot, no problem. I ought be get
there within the next week or so.
I'm travelling at the moment, and quite frankly until Gump gets back to
the point where I can experiment on a change with a edit/compile/debug
cycle measured in minutes instead of hours, all of my contributions will
be "in the margins". Furthermore, my knowledge of Forrest is nearly
approximately zero at the moment.
My brief forray into ForrestDocumenter lead me to the conclusion that a
good percentage of that code is really producing things like tables and
not particularly Forrest specific.
A way to manage the flotsam and jetsam is to write everything to a
directory whose name is based on today's date. "latest" can be a
symbolic link to the current date. At the beginning of the run can be
some code to create the directory if it doesn't exist (and updating the
symbolic link as required), and to delete all but the last "n"
directories that may exist.
Anyway, my suggestion is that if you can get something which
approximately works, I can help complete it. And we can clearly leave
the static forrest code in place until there is something worth
replacing it.
- Sam Ruby
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: timeout
Adam R. B. Jack wrote: It seems that pgrep doesn't exist on FreeBSD. The web site started to materialize once I manually killed the java step that was running. That I translated to some runaway ant script (we had one recently) and that is what caused me to bring up the whole 'timeout' thread. It didn't occur to me you were describing the Forrest run. :-) OK, lets get back to this issue. Nobody here seems to know why the forrest run takes so long, but it takes a significant fraction of the overall run. It also produces thousands of web pages, only a small fraction of which are likely to ever be looked at. And none of these pages are produced until the run is complete. A better approach would be to run forrest dynamically, i.e. produce (and possibly cache) the web page on demand. I'm not sure what that would take to make happen, but it seems to me that the best way to get from here to there is to try to do both. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: timeout
Adam R. B. Jack wrote: I've coding 'timeout' into Python Gump (allowing GumpEnvironment to detect it & register it, and allowing launcher.py:executeIntoResult to use it if found) as an optional dependency. [I've done this in the hope of helping Hermes, which (I assume) is still in an uncomfortable situation of having a rogue child.] I see no evidence of a rogue child. What leads you to this conclusion? Note: hermes was down for a number of hours yesterday due to an operator error. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AWT on Brutus
Christian Geisert wrote: Stefan Bodewig wrote: Hi, even with java.awt.headless=true some things that use AWT fail on brutus, for example jelly-tags-swing. The error looks like this java.lang.UnsatisfiedLinkError: /usr/local/j2sdk1.4.2_04/jre/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory On my old RedHat box, libXp is part of the XFree86-libs (for 4.2.x), no idea where you'd find it in a apt-get based system. I assume that [EMAIL PROTECTED]:~$ dpkg -S libXp.so libxp-dev: /usr/X11R6/lib/libXp.so libxp6: /usr/X11R6/lib/libXp.so.6.2 libxp6: /usr/X11R6/lib/libXp.so.6 Installed! - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: System Info
Adam R. B. Jack wrote: Folk, When both Stefano and Leo both misinterpret me, I realize I failed to communicate yet again. English truly ought not be counted as my first language (despite being born a Brit. ;-) You triggered off this: As I'm sure you are aware ... there is a strong feeling on this list that no Java pre-requisite ought exist, so Gump can be run in a 'clean' environment w/o worrying about CLASSPATHs and such. But didn't seem to register this, which was part of the same paragraph. (Might seem odd for a Java Builder, but Gump may do more/other than Java one day). That said, you seem to have cleverly worked around that. So long as Python Gump generates it, compiles it, and runs it -- I can't see folks objecting. where (1) I agree it is odd [I was being polite] for a Java Builder not to want Java, but then explained it and (2) I agree that this worked around any objection. Heck, I never even said they were my objections, I was just trying to summarize what I understood from prior threads/comments on this list. So, for the record (to try to clear up any miscommunication): - I agreed from the start that this was a nice to have. I said that 'ant --debug' might display it, but that I didn't know how to get it directly without writing Java. (Seems others don't either.) - I didn't think this list (from comments I've heard supporting Python Gump) wanted to have to configure/install/environment a Java compiler, but they are happy for Python to auto-discover and use one [clearly]. - I agreed that this solution is consistent with the purist (some might say bootstrap) approach, of starting with pure Python. - All in all, I agreed this was a good solution to the requirement, and fitting within what I understood as the philosophy. That all said, let's please clarify (because it came up again with C, I believe) and I don't want to be assuming that I understand the views of this community: - Do folks want a pure Python Gump, that one can download & run directly? [This solution investigates and locates tools in the environment and uses what it finds, even bootstrapping with those to build more of it's own tools.] - Or, are folks ok with Gump having other language components, and requiring a build prior to being able to run it. Any such build would need to be automated so we could deploy remote Gump agents. (Clearly this approach is achievable, traditional Gump did it, and clearly one could use ant in order to build Java, and perhaps C, etc.) I prefer the Python approach (even if I do get called a purist and not a pragmatist, this time. ;). That said, I could live with either. These questions are not straightfoward. At the moment, Gump has a nearly hard dependency on the CVS head version of a Java project which can't be built by gump. And the completely optional dependency on a completely stable and completely free of dependencies "C" program brings up this discussion. As does the adding of some code which will optionally provide version information for java in the case where java happens to be installed. We each apparently place different weights on different attributes. All other things being equal, yes I would prefer a pure Python solution. When things aren't equal, I would tend to yeild first on the language before yielding on bootstrappability. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indentation
Adam R. B. Jack wrote: In Python, indentation is syntactic, and crucial. I'd like some input on how we can all work on the source, without confusing each other... Sam's recent addition to forrest.py uses tabs, and what works & no doubt looks good to him, but looks wrong to me (see below). [I've been using pyEclipse inside Eclipse and I chose the option to to save tabs as spaces, 'cos I felt it disambiguated. I'm guessing I have tab set as 4 spaces somewhere, but I'm not sure. I'm game to change that to 8.] Sam hates tabs with a passion, so if there were any in there, it was because he was editing the files on a machine where he had neglected to set up vim properly. I'll try to be more careful in the future. My policy is to emulate the number of spaces that I see in the existing file when I make changes. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hermes status
Adam R. B. Jack wrote: I think we could add a check into GumpEnvironment to detect 'timeout' if available in the environment, and use it if present, and I think that would suit any purists (including me) that want Gump to function well out of the box, with the minimum of installation dependencies. Why not put 'timeout' in the box? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
System Info (was: Speed of brutus)
Adam R. B. Jack wrote:
And finally, a nit: I see useful information like the name of the java
command ("java") and the Operating System ("posix"), but I don't see the
values of System.getProperties which contains values such as:
java.vm.version=1.4.2_04-b05
java.vm.vendor=Sun Microsystems Inc.
os.arch=i386
os.name=Linux
Hmm. No, not directly. If a project repeatedly fails Gump automatically
turns on ant verbose and/or debug, and maybe this show those values. Is
there a way to list these things (above) without writing some Java?
What's wrong with writing some Java? ;-)
import commands, os, re
TMP_DIR = '/home/rubys/tmp'
JAVA_SOURCE = TMP_DIR + '/sysprop.java'
properties = [
'java.vendor',
'java.version',
'os.name',
'os.arch',
'os.version'
]
source=open(JAVA_SOURCE,'w')
source.write("""
public class sysprop {
public static void main(String [] args) {
for (int i=0; i
os.system('javac ' + JAVA_SOURCE)
os.unlink(JAVA_SOURCE)
cmd='java -cp ' + TMP_DIR + ' sysprop ' + ' '.join(properties)
properties = dict(re.findall('(.*?): (.*)', commands.getoutput(cmd)))
os.unlink(JAVA_SOURCE.replace('.java','.class'))
for (key,value) in properties.items():
print key, "=>", value
- Sam Ruby
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hermes status
Adam R. B. Jack wrote: Gosh I hate that bit of code: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=5728 All help & creative solutions appreciated: http://issues.apache.org/jira/browse/GUMP-35 The way this used to be done was to use a public domain program named timeout. I placed the source in brutus:/home/gump/timeout.tgz, and the compiled output and man page in /home/gump/bin. Timeout was used for all cvs updates and build commands. Including the cvs update of gump itself in the equivalent of gumpy. Here's how it was invoked: bash gen.sh -cp "/home/rubys/bin/timeout 1200" Where "cp" is the desired "command prefix". - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hermes status
It seems that pstat doesn't exist on FreeBSD. The web site started to materialize once I manually killed the java step that was running. We'll see what happens tonight. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hermes status
Sam Ruby wrote: A gump run has started on Hermes (FreeBSD). This one is configured for ... 2G RAM, Dual Processors, and mirrored RAID0. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Hermes status
A gump run has started on Hermes (FreeBSD). This one is configured for Those with the password for [EMAIL PROTECTED], the same password works, but the user is gumpuser on hermes (due to a conflict with the group name). http://hermes.apache.org/gump/public/ If the output appears comprable to what we are seeing on Brutus (Debian), then the plan will be to wipe Brutus and install FreeBSD on it (reducing the number of OSs the infrastructure team has to maintain). Meanwhile, for a while we will have two xSeries 345s to play with. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus config -> lsd config
Adam R. B. Jack wrote: I think we need to ensure we have a 'test' flavour [or test workspace perhaps] on every box, one that we expect folks to tinker with (when the main build isn't running). A test workspace would work [other than the fact it could mask 'updated'] because we'd only run it at odd times, and we'd not crap on the same output tree (like I often do testing.) Can I suggest a different approach? What I used to do with classic gump was to capture and datestamp the outputs of the "official" runs, keeping a fixed number live. This is a simple matter of copying a few directories at the end of the run. I've tinkered with this on and off, but not had a separate flag for 'official'. I think it needs to be introduced. (There are mutiple places where we check isFull() [i.e. 'all' projects not some] -- and we have the integrate script different (in what it does) than build or update or debug. There are even comments in the code about 'if official then nag and/or do rss/atom', but much has been removed since I like to test the whole path (quickly) on subsets of a profile.) This brings me onto configuration, see next... It appears to me that you are looking at Gump as as monolithic tool. I see it as a series of actions: Generate, Update, Make, Publish... My suggestion is that we should decompose Gump. There is no reason that everything needs to funnel through a single entry point. There are a number of discrete actions that users may wish to trigger. These actions may be triggered from the command line, a gui, a webapp, or a cron job. Focusing initially on the cron job, it needs to run a script. That script can be written entirely in Python (including reading the configuration, setting environment variables, etc). It can do more than what one typically does from the command line (e.g., copying of directories, nagging, etc). Key points: 1) when it does things typically done by "testing", it calls into the exact same code. 2) official, completed outputs are served from a different URL than incomplete or testing outputs. 3) official runs start by cleaning up the work area. This was done by rsync in "classic" gump. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus config -> lsd config
Adam R. B. Jack wrote: Are we happy with the gump config on brutus? Is that setup reasonably stable? Unless we decide to move to tomcat/forrest, I'd say so. How should that change things? What's the next step? Apparently running a forrest server on a different port is as easy as a executing a command. So I would think that the next step would be to get gump to produce xdocs during the run in addition to the static documents at the end of the run. Once this was done, forrest can be used to dynamically produce content from these xdocs. Does this sound about right? If there is anything I am not sure I like about the set-up is that we mirrored the /usr/local/gump from Moof, and I'm not sure if that directory is the best root one on all. I like things like /var/gump and /opt/gump/packages and things like that, and (maybe) /home/gump. But, so long as we can find choices (or a choice) that suits norms on these platforms, I don't really care. I already did a few symbolic links from /home/gump to strategic points in /usr/local/gump; we certainly can do a few more from /var and /opt. Oh yes, and I'm still not sure about .bash_profile including one flavours' local-env-py.sh. I didn't take Sam up on his posting (I forget when/werre) that said, don't expect these settings in cronjob. As such, we are still using gumpy (that works, but is ugly since it needs three more env variables & doesn't read the workspace to get the values) not gumpy.py. Why isn't gumpy simply: . local-env-py.sh python gump.py ? For that matter, the cron command can look something like this (omitting paths): bash -c "(. local-env-py.sh; python gump.py)" I think we need to ensure we have a 'test' flavour [or test workspace perhaps] on every box, one that we expect folks to tinker with (when the main build isn't running). A test workspace would work [other than the fact it could mask 'updated'] because we'd only run it at odd times, and we'd not crap on the same output tree (like I often do testing.) Can I suggest a different approach? What I used to do with classic gump was to capture and datestamp the outputs of the "official" runs, keeping a fixed number live. This is a simple matter of copying a few directories at the end of the run. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus config -> lsd config
Leo Simons wrote: Are we happy with the gump config on brutus? Is that setup reasonably stable? I'd like to mirror on lsd to the maximum extent possible. Since brutus is debian and lsd is fedora, the mirroring won't be complete, but we should get pretty far. Not that it is particularly hard, but if you give me an account, I would be willing to help set things up. The differences between debian and fedora primarily involve how you install of apache, cvs, python, and subversion. Oh, and java can be installed as an RPM. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki Editor? (was Re: [Gump Wiki] Updated: BrutusConfig)
Adam R. B. Jack wrote: I assume it is Sam improving/completing this content, but this isn't too helpful: Editor: 66.57.27.65 <> Anybody mind if I ask infrastructure@ (with subject [wiki]) to investigate? I assume attribution is of interest. This simply means that I hadn't bothered to create a user and login. I have now done so. Note: there is no real security in a wiki. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java 1.4.2p5 installed on hermes; a few other ports too
Aaron Bannert wrote: [EMAIL PROTECTED] /usr/local/jdk1.4.2/bin/java -version java version "1.4.2-p5" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-p5-aaron_30_mar_2004_16_59) Java HotSpot(TM) Client VM (build 1.4.2-p5-aaron_30_mar_2004_16_59, mixed mode) I haven't copied the accounts over, since I'm not sure how we want to do that, but I did create an account for Sam and myself, using our same UIDs from minotaur (same password as before, Sam). Thanks! Just to reiterate what my intentions are: the plan is to see if I can get gump up and running on this configuration in order to determine if Brutus should be wiped and have FreeBSD installed on it. Either way, gump will be removed from Hermes when Hermes goes into production. However, at the discretion of the infrastructure team, Gump can be left on Hermes until that point as a part of "burn in" process. Removing gump will involve removing the 'gump' user, and a /usr/local/gump directory. I've also installed a couple other packages: bash, zsh, screen, and wget. (and their dependencies) Can I also get you to install apache, python, and the svn client? -aaron P.S. The script I will be following can be found at: http://wiki.apache.org/gump/BrutusConfig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Two new pages...
Adam Jack wrote: BTW: I seem to have to press CTRL-RELOAD on Brutus or I don't see refreshed pages. I think we ought configure HTTPD to make this more interactive between browser/server, 'cos Gump pages change frequently. Can somebody easily change this and add the config change to the BrutusConfig wiki page? I don't see this behavior with Mozilla on WinXP. I checked the HTTP headers that were being returned, and there are no expired headers being added. I could be wrong, but as near as I can tell, the reason you need to press CTRL-RELOAD is because without doing this, the client is not sending any requests to the server. As the server is not getting the requests, there is not much that can be changed on the server side to fix this. For Mozilla, this behavior can be controlled by the preferences. From the menu bar, select Edit -> Preferences -> Advanced -> Cache. The section to look for is entited "Compare the page in the cache to the page on the network". "When the page is out of date" is a good answer here. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re:
Stefan Bodewig wrote: Could anybody with root access to brutus please add my authorized_keys2 file that can be found on minotaur or moof for me to brutus' ~bodewig/.ssh - assuming I already have an account on brutus, that is. At the moment, we are sharing an account (gump). I've send you details on how to login, after which point you can update the authorized_keys2 file yourself. Let me know if you would prefer a separate account... - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: /tmp full on jdom server?]
All better now. Original Message Subject: Re: /tmp full on jdom server? Date: Mon, 29 Mar 2004 13:08:50 -0800 From: Jason Hunter <[EMAIL PROTECTED]> To: Sam Ruby <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Thanks. Freed some space. Will look into the core cause. -jh- Sam Ruby wrote: http://brutus.apache.org/gump/public/jdom/index.html - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: run gump 4 times a day (Re: Speed of brutus)
Adam R. B. Jack wrote: Should we run gump every 6 hours on brutus? Some thoughts I've had... Since we have dedicated cycles, why not do it as soon as the last one stops? What about doing N with --optimise (only build what has changed) and the Nth+1 a full one? BTW: Have a separate 'check metadata' loop (that doesn't build just checks) might be nice for folks committing descriptor changes. I've not written the code (ok, I did, but I ripped it out -- it was inside the engine, not outside) but how about an external script that runs gumpy.py as above [which does CVS update of self in there]? My recommendation is that we first figure out how often we want to nag, and work backwards from that. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Speed of brutus
Antoine Lévy-Lambert wrote: Hi Adam, I have noticed that some cvs update failed due to /tmp being full. For instance jdom. http://brutus.apache.org/gump/public/jdom/index.html I'm pretty sure that "can't create temporary directory /tmp/cvs-serv" is an indication that there is a problem on the cvs server end. I'll send a note to Jason and Brett to see what's up... - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Generator vs Serializer
Adam R. B. Jack wrote: My first proposal was to run forrest dynamic for gump. This means that you don't have to change anything in the code right now *AND* you get immediate changes as soon as they are written on disk. I am game to explore alternatives, but this one really attracts me as a short term fix. Can anybody find time to help install this on moof and/or brutus and/or other? I'll give Gump a quick --xdocs option so that it leaves the xdocs it generates are the output [sync'ing/moving to the log directory, correct?], and not try to run Forrest inlined. If somebody can give me a "bill of materials" (preferably in the form of a list of URLs of installation instructions), I'll take care of this on Brutus. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Gump on FreeBSD?
Now that we have Gump running on Debian, I'd like to experiment with Gump on FreeBSD. Mostly what I need to have installed are the following: apache cvs java python subversion And for a user named gump to be created, as well as a directory named /usr/local/gump which is newown'ed to gump. And for an Apache alias to be set up as follows: Alias /gump/public /usr/local/gump/public/results More specifics on how exactly the Debian machine were set up can be found here: http://wiki.apache.org/gump/BrutusConfig - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Speed of brutus
I see from http://brutus.apache.org/gump/public/
Elapsed Time : 1 hour 56 mins 20 secs
Putting it mildly, this doesn't look half bad. I presume that this
includes the time of cvs/svn checkouts? Are the logs of the cvs/svn
checkouts captured? This sometimes is helpful when trying to track down
why a build that worked yesterday failed today.
Note that this is only with one CPU and less than one gig of RAM.
Looking at the build times, it looks to me like gump 2.0 tries to do
parallel builds whenever possible?
And finally, a nit: I see useful information like the name of the java
command ("java") and the Operating System ("posix"), but I don't see the
values of System.getProperties which contains values such as:
java.vm.version=1.4.2_04-b05
java.vm.vendor=Sun Microsystems Inc.
os.arch=i386
os.name=Linux
Are these available someplace?
- Sam Ruby
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump GUI development parallel to Gump Remote Agents (Sites)
Adam R. B. Jack wrote: I've not had chance to go over Leo's architecture notes in enough detail (at a quiet time) in order to respond to them completely. I keep wanting to find time. The first point that I'd like to address, when I do, is that I don't believe that Python Gump (I will start referring to it as Gump, implying it is just 2.0) reverted to a batch approach, per se. Maybe I am splitting hairs, but Gump can perform a 'run' of one or more projects, upon them alone or the dependency stack beneath them. Since Gump needs to behave in a certain (dependency) order when N>1, the N=1 case is a little bloated, but it is doable today. Perhaps I chose the wrong words to express what I was trying to convey. As usual, a picture is worth a thousand word. Take a look at the following urls. http://gump.covalent.net/log/cvs_index.html http://gump.covalent.net/log/index.html At the present time, it shows a run that started just after noon on Sunday, and completed at 9 am the following day. This happens to show a complete run. Check back in a few hours, and depending on when you check, you will find partial results, either on the checkout side or on the build side. I believe that this is a very valuable thing to have. Note that when you run classic Gump from the command line, much of this information goes to stdout instead. So, I say "build gump" and what I get is pretty much identical to what I would get if I were to type in "ant" from the proper subdirectory, and with all the right things in my CLASSPATH. This is also very valuable when inviting others into helping debug an integration problem. Simply give them a login on the machine, tell them to make whatever changes they like (it will get wiped out next cycle anyway), and then type "build " to see if it helps. I was able to identify exactly where breakages was introduced on projects I didn't know by repeatedly issuing "cvs update -D " and "build ", doing a binary search over time space until I had identified the exact commit that caused the problem. Yes, we could split the gui into a client and server and solve this (or simply rely on XWindows), but there is value in being able to do this from the command line. The reason I care about this distinction is that I feel we don't need a major re-work in order to satisfy targeted runs. I think this is most clearly seen if we bring the GUI, that Sam/Nicola worked on, out of mothballs. I'd love to see that done, 'cos I think it brings good issues to the surface. With the GUI I think we can allow a user to pick N projects, and can perform an update or a run, or whatever. A GUI is a nice thing to have, but not as a replacement for a command line interface. I also think a GUI is especially useful for resolving some of the concerns over documentation, and timeliness, and format. I think that a listener (being passed context with status) could be called whenever a project is built (or whatever) and could represent/display state as it proceeds. I've always respected the Gump GUI & liked what it brings to this mix, I've just never had enough cycles to maintain it as I fleshed out the more 'agent' way of doing things. For the GUI to really fly I believe we need some internals changes (separating all 'run' information into context objects and off the metadata model objects, so we can re-run without re-loading metadata) but I think this is worthwhile. So, my random thought is ... could we find folks to care about this use case, and bringing it to feature completeness as a parallel effort to the remote agents and their sites (via forrest or cheetah or both or ...) While I like the GUI and can invest some cycles there, I will remain fundamentally a command line person for 95% of my usage. So, my RT would be for us to flush out what would be required in order to implement a dynamic forrest approach. Let's specify the data formats of what is expected to be produced by python gump. My preference would be that this be semantically rich XML (i.e., lacking in presentation elements like spacer gifs and the like). If this can be XHTML with CSS, that might be nice (with the semantic information captured in class names). As to how we evolve from where we are to where this would take us, I would suggest that we simply continue to maintain in the current document.* classes, but start to augment the other classes to produce the specified data. Once this reaches a critical mass, a dynamic Forrest implementation could be initiated, and only after it gets to the point where it is deployable would the document.* classes get deprecated. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Downloading Maven to brutus
Adam R. B. Jack wrote: Thank you. I'll update the README and post it to the Gump Wiki for a clear record. I'll cut-n-paste your package install command line, please update it with these if needed. Hehe... I actually spent some time to update the Gump Wiki with a greatly expanded README (with specific URL references and commands) -- and all this was BEFORE I read the above email. http://wiki.apache.org/gump/BrutusConfig I left out Maven and Forrest, can you add these to the other prereqs section? Preferably with some specific commands and/or URLs. BTW: We've done moof (although it isn't complete) and now brutus. If we do a couple more, frm the documentation we generate for these, we ought hopefully have nailed the steps pretty well. Exactly. The next one to conquer is FreeBSD. And also remember, Brutus still can be wiped at any time. In fact, ideally I would like to plan on it being wiped periodically if possible. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Downloading Maven to brutus
Adam R. B. Jack wrote: use wget :) FYI: I've now installed both lynx and curl. Thanks, I tried it. Did I do something wrong? [EMAIL PROTECTED]:/usr/local/gump$ wget http://www.apache.org/dyn/closer.cgi/maven/binaries/maven-1.0-rc2.tar.gz Take a close look at that page. It is an HTML page telling you where you can download maven from, not the tar.gz file itself. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump docs solution, makes everyone happy (Re: Gump Thrashing/Spinning...)
Nicola Ken Barozzi wrote: Adam R. B. Jack wrote: I'll certainly guilty of being away for a while, but gump.document.forrest is not a small thing, and to my eyes, not entirely obvious. ... > Also, if we want both xdoc and html output we'd need to set of tempaltes (with code in) which isn't nice. Maybe my comment got lost... generate html and Forrest can skin that too. In other words, Forrest can skin an html site. So, if you make Cheetah output plain html you can see the site natively, or decide to have Forrest skin over it and publish it or use a live Forrest. I'm -1 on removing Forrest for output, as it takes away the same visual style of the site. That's darn near a circular definition. To demonstrate: what's wrong with the notion of switching the site to Anakia, which is stable, builds consistently with Gump, and powers www.apache.org, jakarta.apache.org, and a number of other sites? Now realize that I am *NOT* proposing Anakia. What I am proposing is that the ability to view a site as it is being produced is a very valuable thing to have, and an important consideration both for a machine which is a shared resource and for any hope of there ever being personal usage of gump. Beyond that, I would like to reiterate the point that there is value in keeping true to the original design where Gump bootstraps its own dependencies. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus.apache.org status
Adam R. B. Jack wrote: It's not all that scary. I've updated .bash_profile to contain the ... Not scared, just my *nix knowledge is not "borne again". ;-) following lines: export FORREST_HOME=/usr/local/gump/forrest export PATH=/usr/local/j2sdk1.4.2_04/bin:$PATH:$FORREST_HOME/bin I'll move the stuff at /usr/local/gump/public/gump/local-env-py-brutus.py in there, and try the hup command below, thanks. Note that the nohup command will benifit from you updating .bash_profile (presuming that you log off and back on), but cron will NOT. Thanks for that. I think the last root/admin task we need (which I'd forgotten earlier, sorry) is for the 'svn' client to be installed/available. Done. - Sam Ruby P.S. Capturing for posterity (don't worry if it doesn't make sense to you) apt-get install apache htdate cvs python subversion sudo vim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/profile gump.xml
[EMAIL PROTECTED] wrote: Apache Organization Brutus http://brutus.apache.org/gump/public http://gump.apache.org This answers the question I just asked... and even uses the same URL. :-) - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus.apache.org status
Adam R. B. Jack wrote: We really need somebody to place these local information into a .bashrc or .profile (or wherever) so FORREST_HOME is picked up by a python script. However, I'm not that guy -- I am too out of touch with such things. It's not all that scary. I've updated .bash_profile to contain the following lines: export FORREST_HOME=/usr/local/gump/forrest export PATH=/usr/local/j2sdk1.4.2_04/bin:$PATH:$FORREST_HOME/bin BTW: Don't take this as me being intransigent and not open to moving away from forrest, this is just for here and now. I personally think we need to make forrest work for us (I want SVGs) but I think we can remove it as a mandatory requirement for HTML sites. Pre-forrest, this was done via ant and batik: http://cvs.apache.org/viewcvs.cgi/gump/site/Attic/build.xml?rev=1.6&view=markup This was also done as a part of the gump run, so it was using the latest ant, batik, etc. Seemed only fair. Since I've not had much fun running gumpy.py in background (when I hang up, it dies) -- and because I need the forrest env variables I am adding this crontab entry: try: nohup python gumppy.py & Next steps (assuming this above all works) ought be to modify HTTPD configuration to point to the results in /usr/local/gump/public/results. Anybody game to take these on? What url do you want to map to that directory? For now, I've mapped http://brutus.apache.org/gump/public/ But this can be easily changed. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Generator vs Serializer
Adam R. B. Jack wrote: An alternate approach would be to completely flip this. Have the equivalent logic drive the acquisition of certain pieces of information, which can be processed as it is being received. Whilst most of the forrest documenter generates pages for single entities (for workspace/module/project/work) there are a significant number of statistics/xref pages that rely on all information being available. As such we'll need at least two phases. "classic" gump handles such statistics pages separately too. I'm not much into abstract architectural discussion. I tend to focus on tangible and measurable quanties that matter to real people. In this case, it is clear that Gump is expected to run for a long period of time, and I view not having ANY output until EVERYTHING is done as something less than ideal. The use case of having 'personal Gumps' (not just relying upon the remote servers) has not been greatly exercised. [In the main 'cos I don't have the resources to run it locally]. We are moving more and more towards that usage though, so I could see how this could start to become important to folks. I actually think there is considerable value in being able to view live results in the mult-hour run too, but it is fair to observe that classic gump "grew" in the other direction - being primarily used for my own personal builds which I ran multiple times a day, and an occasional complete resysnc, which I did every couple of weeks. For us to get to the point where others are interested in personal gumps, we need to make it easier to build profiles which use repositories for components that an individual is not interested in rebuilding for themselves. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RT] Generator vs Serializer
Adam R. B. Jack wrote: > > We have gump.document.text, and we could create gump.document.html > that use cheetah to write it. Stefano Mazzocchi wrote: +1 in removal of forrest and go plain XHTML + CSS. But please, let's use a velocity-like approach, not a DOM like approach! I may be reading too much into Stefano's words, but if so, the following is how I see things. At the moment, gump.document.* take a complete set of knowledge and produce a set of artifacts. The best analogy to Cocoon for this would be a serializer which terminates a pipeline. An alternate approach would be to completely flip this. Have the equivalent logic drive the acquisition of certain pieces of information, which can be processed as it is being received. The best analogy to Cocoon for this would be a generator which is at the beginning of a pipeline. Classic gump is closer to this model... after a brief generation phase, the execution of the resulting script triggers actions, the output of which is intermixed with some static and some generated output. I'm not much into abstract architectural discussion. I tend to focus on tangible and measurable quanties that matter to real people. In this case, it is clear that Gump is expected to run for a long period of time, and I view not having ANY output until EVERYTHING is done as something less than ideal. Producing output as the information becomes available can also dramatically reduce working set sizes. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Let each project run using the last successfull jar from each dependency
Martin Cooper wrote: On Sat, 27 Mar 2004, Nick Chalko wrote: Here is an idea to let gump build 100% every time. Keep the jars from the last success full build of each project. Then a project fails it will not stop the rest of the tree from building. I'm just a lurker here, but this seems to defeat the whole purpose of Gump. Gump's purpose in life is to let people know as soon as possible when changes in one place break things in other places. The change you are suggesting would at best delay the guilty party from being notified of the issues, and at worst result in everything building successfully every time. Of course, I may be misinterpreting you entirely... It is more subtle that that. What it would do is to enable a nearly perfect system to run better, but it could make a bad situation worse. Example: Xalan is a stable project with a stable set of interfaces. However, I have seen it fail to build. Due to Ant's depedency on Xalan, this pretty much wiped out the days's run. Unnecessarily. On the other side is projects that rarely build. If this is obscured by substituting in older jars, projects will be provided with misleading impression that One way to mitigate this would be to place an upper bound on how long old builds may be used. Three days old may be fine, but three weeks old is probably not. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump Thrashing/Spinning...
Nick Chalko wrote: Stefano Mazzocchi wrote: \ . Ok, I think that reducing complexity is critical for wider adoption. +1 in removal of forrest and go plain XHTML + CSS. But please, let's use a velocity-like approach, not a DOM like approach! I am not sure how removing forrest reduces complexity. It just means we have to maintaining the template / site code ourself. I'll certainly guilty of being away for a while, but gump.document.forrest is not a small thing, and to my eyes, not entirely obvious. A design point for the original gump is that output was viewable as it was produced. Is this the case for gumppy w/ forrest? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
brutus.apache.org status
Current status: A minimal network install of Debian testing [1] was made on one of the new IBM xSeries 345 machines. Being minimal, this kernel does not yet recognize the second CPU or second Gig, but my first focus is to get the box up and running. Once running, I plan to attempt to replicate this on other operating systems (in particular FreeBSD) for comparison purposes. Once we have had a chance to evaluate the alternatives, the plan is to settle down to a single machine, possibly with a completely different OS than what is currently installed on brutus, and that machine will be called brutus (it likely will be the same physical machine, but that's not important either). The key point is: don't get too comfortable, as things may change. - - - To date, I have installed the following via apt-get: sudo, apache, python, and cvs. In addition, I have installed Sun's j2sdk1.4.2_04. I created a user called 'gump' and sent the instructions on where to find the password to dims, leosimons, and ajack. Once this machine is fully set up, the plan is to make this a public resource for Apache committers with a desire to participate, but initially it makes sense to keep the list small to minimize stepping on one another's work. I've followed the /usr/local/gump directory structure pattern that I found in place on moof, though I did place packages on a separate hard drive, and created a convenient symbolic link to public from /home/gump. I also copied and updated the /usr/local/gump/README from Moof. I created the 'public' flavour, checked out GUMP, created a brutus.xml workspace, and tried to run the first tests. python gump/check.py failed as follows: File "/usr/local/gump/public/gump/python/gump/output/statsdb.py", line 181, in getFloat if self.db.has_key(key): val=self.db[key] File "/usr/lib/python2.3/bsddb/__init__.py", line 142, in has_key return self.db.has_key(key) TypeError: String or Integer object expected for key, unicode found An easy fix for this would be to add "key=str(key)" immediately before this line, and in other similar methods. It might be preferable to do this upstream (like when the string is read). I have not yet proceeded to step 8 which involves forrest. If the consensus is that we want to replace this with a Python solution, I can invest the time to make that happen. - Sam Ruby [1] http://www.debian.org/releases/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump Architecture
One thing that is possible to do in Python that would have been difficult to do in shell script is to parallelize some of the processing. In a daily build, there are three major components: cvs/svn update, copy/rsync, and build. My recommendation would be to not overdesign this (too many processes/threads is not a good thing for performance either), but perhaps having exactly three operating as a pipeline would be a good thing. Let's look at two extremes: 1) Fast network, slow CPU. In this case, after the first few cvs/svn updates, a period would occur where one component is building, a move/copy for a subsequent next component will be in progress, and a cvs/svn update for a third would be running. The net effect would be that the overall time would approximate the time of the builds, plus the small increment necessary to "prime the pump", and whatever penalty overlapping the I/O with the builds adds. 2) Slow network, fast CPU. Essentially the reverse of the above, whereby the overall time is the time of checkouts plus a small delta. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump Thrashing/Spinning...
Leo Simons wrote: We should probably use a template engine. I'm sure there's a python equivalent for something like velocity (or smarty). http://www.cheetahtemplate.org/ I use it in my weblogging software. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which gump on the new machines?
Adam Jack wrote: OK, it looks like there may be a new ASF hosted machine or two running gump in the next 24 or so hours. Which gump should be run on it? Which? As in traditioanl verse Python? I think concensus has been Python for a while. Just checking... We have a README in /usr/local/gump on moof, ought I post it here for folks? I can't get there this mo, and my eyebrowse search isn't bringing up when I posted it before. It has the steps involved. I see it on moof. I'm not too worried as I generally am a quick learner. ;-) I'm willing to take the lead in getting it up and running, or simply suggest it be turned over to somebody who wishes to volunteer. Once it is up and running, it is my intent that this be a public resource Gump participants. I will be online (from a hotel, after workout/dinner) tonight (PST time) and able to help. I do think we ought use the shared 'gump' account we've been discussing, that'd be good for a common place for the cronjob, etc. My guess is that real work won't start until tomorrow. A shared gump is OK with me. regards, Adam - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nagoya much slower again...
Noel J. Bergman wrote: Who's Gump in whose account? Sam's? Is anybody aware of the outputs, let alone using them? Sam, and ask him. :-) The outputs (in terms of reports indicating what worked and what did not) are directly linked to from gump.apache.org. Click on "Nagoya". In any case, I've commented this entry out of my crontab for now. Hopefully we will be seeing a new installation of Gump on separate hardware shortly. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Which gump on the new machines?
OK, it looks like there may be a new ASF hosted machine or two running gump in the next 24 or so hours. Which gump should be run on it? I'm willing to take the lead in getting it up and running, or simply suggest it be turned over to somebody who wishes to volunteer. Once it is up and running, it is my intent that this be a public resource Gump participants. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump nag mails (was Re: STANDARD_1_0_BRANCH doesn't build)
Stefan Bodewig wrote: Hi, Gump has been trying to tell you about the build problem for the past three weeks, but looking at the list archives, the nag mails have never been delivered to the list. Gump is configured to use Ted Husted's address to send the nag mails for any taglib failures. The only reason I can imagine that the mails are not going to the list is that Ted is no longer subscribed to the list (at least not using the specific address that Gump uses) and the moderator didn't moderate the Gump nag mails in. taglibs-dev has a backlog of 58 moderation requests pending. Ted Husted unsubscribed from taglibs-dev on 31 Mar 2003. taglibs-dev has one moderator defined: [EMAIL PROTECTED] As a temporary fix, I added [EMAIL PROTECTED] to the 'allow' list for this mailing list. - Sam Ruby Two questions: (1) Dear moderator, why didn't you accept/allow the nag messages? Are they unwanted by the taglibs community? If so, it would be easier to turn nagging off in Gump than to silently discard them. At least the Gump community wouldn't think you'd know about any problems. Since all taglibs committers (all Apache committers) are Gump committers as well, you can easily disable nagging yourself. (2) If nagging is wanted by the community, should Gump use a different sender address than Ted's? Any address would do as long as the mails get moderated in. Cheers Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] which OS for new gump machine?
Leo Simons wrote: The new IBM boxen arrived, and infrastructure@ will be installing them this week. There's been quite a bit of talk about which OS to run on the machine. From the looks of it, we're probably getting Red Hat Enterprise Linux v3 (RHEL3). This is a quick vote to be sure we're in agreement that's a sane choice. Please place your votes: [] Linux [] RHEL [] Debian [] FreeBSD (probably 5.2.x) My vote is for Debian. I initially switched to Debian for my own personal use when Red Hat end of lifed the non-Enterprise version of the OS, but I quickly fell in love with apt-get. If any help is needed administering this box, count me in. I have some prior experience in configuring Gump boxes, and would like to become reacquainted with the Python branch. ;-) - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
