Build|SeaMonkey|Mac Debug Clbr|success Build|SeaMonkey|Mac Opt Clbr|success Build|SeaMonkey|Mac Opt Depend|success Build|SeaMonkey|Win32 VC6.0Clobber|success Build|SeaMonkey|Win32 VC6.0Depend|success Build|SeaMonkey|shrike Linux Clobber|success Build|SeaMonkey|shrike Linux Depend|testfailed Build|SeaMonkey|speedracer SunOS/sparc 5.6 Depend|success Build|SeaMonkey-Ports|bab71-131 FreeBSD/i386 3.2-RELEASE Clobber mozilla-bin|success Build|SeaMonkey-Ports|medusa Linux/arm 2.2.13 Depend|busted Build|SeaMonkey-Ports|salerno HP-UX B.10.20 Clobber|busted Build|SeaMonkey-Ports|siena HP-UX B.11.00 Clobber|testfailed Build|SeaMonkey-Ports|torino AIX 4.3 Clobber|busted Build|MozillaTest|bezilla BeOS Clobber mozilla-bin|testfailed -- State|SeaMonkey|SeaMonkey|open Build|SeaMonkey|Mac Debug Clbr|success Build|SeaMonkey|Mac Opt Clbr|success Build|SeaMonkey|Mac Opt Depend|success Build|SeaMonkey|Win32 VC6.0Clobber|success Build|SeaMonkey|Win32 VC6.0Depend|success Build|SeaMonkey|shrike Linux Clobber|testfailed Build|SeaMonkey|shrike Linux Depend|testfailed Build|SeaMonkey|speedracer SunOS/sparc 5.6 Depend|success State|SeaMonkey-Ports|SeaMonkey|open Build|SeaMonkey-Ports|bab71-131 FreeBSD/i386 3.2-RELEASE Clobber mozilla-bin|success Build|SeaMonkey-Ports|medusa Linux/arm 2.2.13 Depend|busted Build|SeaMonkey-Ports|salerno HP-UX B.10.20 Clobber|busted Build|SeaMonkey-Ports|siena HP-UX B.11.00 Clobber|testfailed Build|SeaMonkey-Ports|torino AIX 4.3 Clobber|busted State|MozillaTest|SeaMonkey|open Build|MozillaTest|bezilla BeOS Clobber mozilla-bin|testfailed -- There are in this case 3 addt'l lines (State|<Tree>|<SourcePath??I-should-read-field-descript>|<State>)

The two URIs timeless is referring to are: http://tinderbox.mozilla.org/showbuilds.cgi?quickparse=1&tree=SeaMonkey,SeaMon key-Ports,MozillaTest http://tinderbox.mozilla.org/showbuilds.cgi?quickparse=1&tree=Grendel,SeaMonke y,SeaMonkey-Ports,MozillaTest Basically, including "Grendel" in the input (or any unknown tree) screws up the output of quickparse. This is unfortunate, as the IRC bots cannot easily tell if a tree is valid or not.

slamm no longer owns tinderbox and is no longer at netscape. Reassigning to mcafee till a more permenant owner is found so these bugs won't be ownerless.

Unsetting target milestone so we can delete the old (inappropriate) Mozilla target milestones from Webtools.

I checked in a workaround for mozbot (although the current mozbot hasn't pulled it)

I need a little more clue as to what to do here. Is the workaround working Ok?

I don't get this bug, it's been a year, marking won't fix.

http://tinderbox.mozilla.org/showbuilds.cgi?&quickparse=1&tree=SeaMonkey,Foo http://tinderbox.mozilla.org/showbuilds.cgi?&quickparse=1&tree=Foo,SeaMonkey here's a much simpler problem, the second url causes no output. I'm having a slight problem reproducing the original results...

ok I see that latest problem, I can go look at that. reopening

off 098 radar

Exit tb_loadquickparseinfo() early if the tree directory doesn't exist or the build file cannot be read.

Checking in webtools/tinderbox/tbglobals.pl; /cvsroot/mozilla/webtools/tinderbox/tbglobals.pl,v <-- tbglobals.pl new revision: 1.