CVS of mozilla from Thursday Apr 22 Compiled on a debian-Linux system with a 2.0.36 kernel and gcc/gcs-1.1.1. I configured like this. setenv pre `cd ../../install;pwd` ../configure --prefix=$pre \ --with-gtk-prefix=$pre \ --with-glib-prefix=$pre \ --with-libIDL-prefix=$pre \ --with-nspr=$pre \ --with-pthreads \ --disable-md When I typed "make" I got the following errors. Can someone please check into this, I can not compile. ... make[4]: Leaving directory `/usr/local/project/mozilla/mozilla/linux/xpfe/compon ents/find/public' cd src; make libs /bin/sh: -c: line 1: syntax error near unexpected token `;' /bin/sh: -c: line 1: `for lib in ; do ar t ${lib} ; done;' /bin/sh: -c: line 1: syntax error near unexpected token `;' /bin/sh: -c: line 1: `for lib in ; do ar t ${lib} ; done;' /bin/sh: -c: line 1: syntax error near unexpected token `;' /bin/sh: -c: line 1: `for lib in ; do ar t ${lib} ; done;' make[4]: Entering directory `/usr/local/project/mozilla/mozilla/linux/xpfe/compo nents/find/src' rm -f libmozfind.a /bin/sh: -c: line 1: syntax error near unexpected token `;' /bin/sh: -c: line 1: `for lib in ; do ar x ${lib}; true; done' make[4]: *** [libmozfind.a] Error 2 make[4]: Leaving directory `/usr/local/project/mozilla/mozilla/linux/xpfe/compon ents/find/src' make[3]: *** [libs] Error 2 make[3]: Leaving directory `/usr/local/project/mozilla/mozilla/linux/xpfe/compon ents/find' make[2]: *** [libs] Error 2 make[2]: Leaving directory `/usr/local/project/mozilla/mozilla/linux/xpfe/compon ents' make[1]: *** [libs] Error 2 make[1]: Leaving directory `/usr/local/project/mozilla/mozilla/linux/xpfe' make: *** [libs] Error 2

This should be fixed now.

Verified.

(In reply to OrangeFactor Robot from comment #3) > 10 automation job failures were associated with this bug in the last 7 days. > > Repository breakdown: > * mozilla-inbound: 10 > > Platform breakdown: > * windows7-32: 3 > * linux64: 3 > * linux32: 2 > * osx-10-6: 1 > * android-2-3-armv7-api9: 1 > > For more details, see: > https://brasstacks.mozilla.com/orangefactor/ > ?display=Bug&bugid=5432&startday=2015-11-30&endday=2015-12-06&tree=all If it's in the last ten days, then it is a different bug. This particular bug was VERIFIED FIXED 15 years 9 months ago. That OrangeFactor Robot needs fixing. Who is its owner?

(In reply to Tony Mechelynck [:tonymec] from comment #4) > If it's in the last ten days, then it is a different bug. This particular > bug was VERIFIED FIXED 15 years 9 months ago. > > That OrangeFactor Robot needs fixing. Who is its owner? The bot doesn't need fixing per-se, it only reports what humans enter into it, which in this case appears to be someone entering "5432" since they had to enter something. Also it's worth noting that needinfos don't work on watch accounts (bug 179701). Cameron, looking at the raw data in elasticsearch (https://emorley.pastebin.mozilla.org/8854743), I can see these submissions were from you? Strangely the job_ids sent don't match stage or prod job_ids -- was this from a local instance? If so, I'm surprised since you'd need VPN permissions to access the ES cluster, which I don't think you have?

(In reply to Ed Morley (Away 15th Dec-4th Jan) [:emorley] from comment #5) > (In reply to Tony Mechelynck [:tonymec] from comment #4) > > If it's in the last ten days, then it is a different bug. This particular > > bug was VERIFIED FIXED 15 years 9 months ago. > > > > That OrangeFactor Robot needs fixing. Who is its owner? > > The bot doesn't need fixing per-se, it only reports what humans enter into > it, which in this case appears to be someone entering "5432" since they had > to enter something. Also it's worth noting that needinfos don't work on > watch accounts (bug 179701). […] Ah, sorry. I thought that that bug ID 5432 had come from the bot itself. After using Bugzilla autocomplete on "orangefactor" I found 3 accounts, so not knowing which one to select (but thinking the bot itself would be wrong) I selected one randomly and apparently didn't select the right one. Thank you for noticing.

It was the correct account, it's more that I just happened to see it because of the "CC as part of adding a request" (which is not enabled for all accounts) rather than because of the needinfo itself. A straight CC or else a bug filed in the component is less likely to be missed. But in this case it's all good since I did spot it :-)

P.S. Talking of watch accounts, the reason I noticed this change (comment #3) is that "SeaMonkey/Build Config" is one of the Components I'm watching. :-)

Wow, I must admit, I'm not sure what happened. At first I thought I'd been framed... :) But I HAVE been doing some experimenting with bugs wrt the autoclassifying locally. I didn't think it would send that information out to elastic search in any way though. 5432 is probably just a random number I typed in while testing. I'm not really sure what action is needed on this now, though.

(In reply to Cameron Dawson [:camd] from comment #9) > Wow, I must admit, I'm not sure what happened. At first I thought I'd been > framed... :) But I HAVE been doing some experimenting with bugs wrt the > autoclassifying locally. I didn't think it would send that information out > to elastic search in any way though. 5432 is probably just a random number > I typed in while testing. > > I'm not really sure what action is needed on this now, though. On this bug, nothing I guess. Just make sure the same thing doesn't happen again in the future. :-)