During the last week, additions were made to NSPR/NSS CVS. However, bonsai.mozilla.org claims that there were none. Example files: mozilla/nsprpub/pr/src/io/prprf.c mozilla/security/nss/cmd/lib/secutil.c Brian suggested this could have been accidentally disconnected by a recent data center move?
I also noticed that http://lxr.mozilla.org/ is now not responding, although the new name http://mxr.mozilla.org/ works.
FWIW, I'm not sure anyone watches this component; this bug probably wants to move to Server Ops somewhere. (I don't see another bug on the Bonsai issue, but Bugzilla noticed the issue, too, in bug 754798.)
This is now fixed. However.... I had 15 emails get "lost" in the process of fixing it. They bounced and got mailed to the committers. There was 1 that went to wtc and 14 that went to mkanat. If you guys could forward those to me I can manually inject them into bonsai. This is only the permanent bounce ones. Looking at the logs you probably got some earlier that said "THIS IS A WARNING MESSAGE ONLY" at the top. I *don't* need those. I only need the ones that say "----- The following addresses had permanent fatal errors -----" in them. Thanks!
Assignee: nobody → justdave
Component: Tinderbox Configuration → Server Operations: Developer Services
QA Contact: tinderbox-config → shyam
oh, for the record, the reason it was failing was that the new bonsai server is behind a zeus VIP, and bonsai never had an MX record. As such, mail was trying to deliver directly to its A record in DNS, and the load balancer of course doesn't accept mail. I put the direct address for the bonsai server on the back end into the routing table on the cvs server, then immediately backed it out when I saw it starting to bounce... turns out the new bonsai server didn't know it was allowed to handle mail for the bonsai domains, so it was throwing "Relaying denied". Added the bonsai domains to its "I own these domains" list, then put the transport map change back in place on the cvs server, the rest of the messages that had been queued up delivered successfully.
Thanks for working on this issue. Regarding NSS, I confirm that Bonsai queries for recent changes work again. However, until recently, on the NSS tinderbox site, we also got entries in the guilty column. This is still broken. If you knew of a simple fix, it would be helpful and appreciated, thanks. http://tinderbox.mozilla.org/showbuilds.cgi?tree=NSS
Since the emails are correctly making it to the bonsai server now, I'm suspecting that's a problem with Tinderbox... my guess is the local pathnames to the installs may have changed and tinderbox can't find bonsai's data... since that data comes right out of bonsai in real time... /me goes to poke.
(In reply to Dave Miller [:justdave] from comment #6) > Since the emails are correctly making it to the bonsai server now, I'm > suspecting that's a problem with Tinderbox... my guess is the local > pathnames to the installs may have changed and tinderbox can't find bonsai's > data... since that data comes right out of bonsai in real time... /me > goes to poke. Better yet, someone rewrote the thing to pull the data from bonsai's database instead of grabbing the files off the disk, so that bonsai and tinderbox wouldn't have to be on the same physical box anymore. I had no clue there was database config in tinderbox. :) Changed it to point at the new database server, and I see commits listed in the guilty column now.
Dave, thanks a lot for your efforts! I think the Bonsai issue is fixed.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Component: Server Operations: Developer Services → General
Product: mozilla.org → Developer Services
You need to log in before you can comment on or make changes to this bug.