Closed Bug 359336 Opened 18 years ago Closed 17 years ago

should have an x86_64 Linux tinderbox with new gcc


(Webtools Graveyard :: Tinderbox, defect, P2)



(Not tracked)



(Reporter: dbaron, Assigned: bhearsum)




(2 files, 2 obsolete files)

We should have an x86_64 Linux tinderbox with a relatively new gcc so that we catch bugs with our visibility handling, and in particular with WRAP_SYSTEM_INCLUDES.  These bugs show up as linker errors on x86_64, but only as runtime problems on i386 (failure to run with SELinux enabled plus performance problems).  And it's nice to keep the WRAP_SYSTEM_INCLUDES option working since it has codesize and performance advantages.

It's also nice to keep x86_64 builds working, since a bunch of developers use x86_64 Linux.
You could use the refplatform for this, or FC6, or FC6 + gcc4.2
And when we have this, it would be useful for it to build both trunk and branches...
We'll need a DL360 (I think? Might be a 365?) with ESX 3.0 (not 2.5.x) to fulfill this request.

Adding server-ops.
*** Bug 360804 has been marked as a duplicate of this bug. ***
No plan to support this platform in the forseeable future, hence WONTFIX.
Closed: 17 years ago
Resolution: --- → WONTFIX
I don't see how "support" for the platform has to do with whether we have a tinderbox for it.

A significant number of developers who are on Linux use x86_64.

Having an x86_64 tinderbox would help catch problems that affect i386 as well, with more useful error messages, as described in comment 0.

I'm not sure what you mean by "support", but I don't think it affects whether we want a tinderbox.
Resolution: WONTFIX → ---
I know that preed was working on this once upon a time. Are the platform requirements for x86_64 documented anywhere aside from preed's head?
(In reply to comment #7)
> I know that preed was working on this once upon a time. Are the platform
> requirements for x86_64 documented anywhere aside from preed's head?

I never really had much in my head about it... I was just gonna take the 32-bit instructions ( and grab the CentOS 5 ISOs, and follow them until it broke. :-)
Do we have support for 64 bit VMs yet? I had a look through the VI client and couldn't find any way to create a 64 bit VM.
Assignee: build → bhearsum
sure - when you create new VMs, you have an option of installing RHEL 64 bit, and various other 64bit OS's.
Depends on: 418853
Okay, VM has been created. I'm not going to have time to do this until next or so. If someone else wants to finish this up, feel free.
Alright, I'm starting to get this going now.
Priority: P3 → P2
Pretty straightforward I think. I changed the shark scheduler to be 'nightly_scheduler' and added a 'depend_scheduler' -- no reason to have separate ones for different tasks, I think. The dep scheduler fires every 5 hours, and the BonsaiPoller fires on changes. I didn't remember what decision we made about this, but obviously I can switch this to, f.e., builds every 30 minutes.

They're set to report to MozillaExperimental for now, the dep and nightly builders have been forced to both report as "Linux 64-bit Dep Nightly". Since there's a lock around them they shouldn't ever collide. If we add more slaves we should watch out for this though.
Attachment #308424 - Flags: review?(rhelmer)
Comment on attachment 308424 [details] [diff] [review]
add linux 64 builds to the production-1.9 master.cfg

The scheduler stuff is too complicated; the goal so far has been to imitate Tinderbox and build as often as possible. It's actually because we depend on the side-effect of getting more Talos runs per checkin, which is obviously a bug.

Anyway, 1.9 branch is active enough I honestly think it'll keep just one builder busy most of the time. This may come up again when we go to add perf tests, if Talos still does not support separate revision/timestamp, but let's try it for now.
Attachment #308424 - Flags: review?(rhelmer) → review+
Might as well do this the right way (heh) to begin with. I removed the BonsaiPoller and bumped the Periodic scheduler to 5 minutes.

Checking in master.cfg;
/cvsroot/mozilla/tools/buildbot-configs/automation/production-1.9/master.cfg,v  <--  master.cfg
new revision: 1.18; previous revision: 1.17
Attachment #308424 - Attachment is obsolete: true
Attachment #308600 - Attachment is obsolete: true
it turns out that the nightly/release builders still use the cltbld key for CVS. linux64 uses stgbld, so i had to add a new cvsroot in the config to get it working.
Attachment #308617 - Flags: review?(rhelmer)
Alright, the first build just came out. The dep builds can be found here:
Nightly builds should go to the same place as regular Fx nightlies. (

No updates yet, but that should happen soon-ish. (See bug 422103)
For the record, this box is running GCC 4.2.3 and uses the same mozconfig that the 32-bit dep/nightly builds use.
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
Attachment #308617 - Flags: review?(rhelmer) → review+
Comment on attachment 308617 [details] [diff] [review]
[checked in] add a new cvsroot for linux64 builds

Checking in production-1.9/master.cfg;
/cvsroot/mozilla/tools/buildbot-configs/automation/production-1.9/master.cfg,v  <--  master.cfg
new revision: 1.20; previous revision: 1.19
Attachment #308617 - Attachment description: add a new cvsroot for linux64 builds → [checked in] add a new cvsroot for linux64 builds
Depends on: 422220
Component: Tinderbox Platforms → Tinderbox
Product: → Webtools
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.