See http://tinderbox.mozilla.org/showbuilds.cgi?tree=Sunbird-Mozilla1.8&hours=24 The following tinderboxen seem to have a problem: Linux lt18-linux-tbox Dep Lt-Release Linux lt18-linux-tbox Dep Sb-Release WINNT 5.2 solaria Dep Lt-Release WINNT 5.2 solaria Dep Sb-Release
Trunk tinderboxen for win and linux too. Branch and trunk L10n as well.
Amending bug summary according to comment #1.
Summary: Problems with Sunbird-Mozilla1.8 tinderboxen for Linux & Windows → Problems with Sunbird tinderboxen for Linux & Windows
Cc'ing ause as Calendar build/tinderbox expert.
The community ESX server died yesterday and had to be restarted. I noticed the SeaMonkey VMs not reacting and got IT to respond fast to reboot the server, but ause has to start up the tinderboxen again. Over to ause as he has the login to do start those.
Assignee: server-ops → ause
tinderboxes restarted. waiting to see the first successful build
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Yes, all green, and "D" links are visible on the tinderbox page; but only the Windows nightlies have been pushed to the lates-mozilla1.8 directory (I haven't checked the latest-trunk); the Linux nightlies, though more than one hour old, haven't.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
After checking in some more detail, the missing builds on latest-* are the following: - latest-mozilla1.8 (Linux) for Sunbird and Lightning - latest-mozilla1.8-l10n (Windows) for Sunbird (Lightning apparently doesn't have localized builds) All trunk nightlies are on latest-trunk.
argl! due to restarting the tinderboxes, some builds shared their to-date directory with the solaris builds. these are delivered with a different userid so chmod failed. upload-packages.sh finally is created that it stops after the first error, thus before copying to latest-*. the problem should be gone tomorrow but the root cause isn't that easy to fix :(
Well, I've downloaded today's nightly from the dated directory, let's wait until tomorrow's nightly before we VERIFY this bug. I suppose a followup bug should be filed so such a failed chmod won't happen in the future, even if Solaris and Mozilla builds happen too close in time to each other again.
New nightlies have been produced, so I'm marking this bug FIXED. Now what about filing another bug about not preventing nightlies from bring pushed to latest-* if a date-time collision happens again, before you forget how it happened?
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago → 10 years ago
Resolution: --- → FIXED
Component: Server Operations: RelEng → RelOps
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.