359336 - should have an x86_64 Linux tinderbox with new gcc

Status: RESOLVED FIXED

(Webtools Graveyard :: Tinderbox, defect, P2)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 1

[Benjamin Smedberg]

You could use the refplatform for this, or FC6, or FC6 + gcc4.2

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

And when we have this, it would be useful for it to build both trunk and branches...

Comment 3

[J. Paul Reed [:preed]]

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.

Comment 4

[J. Paul Reed [:preed]]

*** Bug 360804 has been marked as a duplicate of this bug. ***

Comment 5

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

No plan to support this platform in the forseeable future, hence WONTFIX.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 7

[Chris Cooper [:coop] (he/him)]

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?

Comment 8

[J. Paul Reed [:preed]]

(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 (
http://wiki.mozilla.org/ReferencePlatforms/Linux-CentOS-5.0) and grab the CentOS 5 ISOs, and follow them until it broke. :-)

Comment 10

[[e-mail] (:bhearsum)]

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.

Comment 11

[Justin Fitzhugh]

sure - when you create new VMs, you have an option of installing RHEL 64 bit, and various other 64bit OS's.

Comment 12

[[e-mail] (:bhearsum)]

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.

Comment 13

[[e-mail] (:bhearsum)]

Alright, I'm starting to get this going now.

Comment 14

[[e-mail] (:bhearsum)]

Attachment: add linux 64 builds to the production-1.9 master.cfg

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.

Comment 15

[Robert Helmer [: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.

Comment 16

[[e-mail] (:bhearsum)]

Attachment: [checked in] patch as landed (remove bonsaipoller, un-bitrot)

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
done

Comment 17

[[e-mail] (:bhearsum)]

Attachment: [checked in] the _real_ patch

Comment 18

[[e-mail] (:bhearsum)]

Attachment: [checked in] add a new cvsroot for linux64 builds

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.

Comment 19

[[e-mail] (:bhearsum)]

Alright, the first build just came out. The dep builds can be found here: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/firefox-linux64/
Nightly builds should go to the same place as regular Fx nightlies. (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/)

No updates yet, but that should happen soon-ish. (See bug 422103)

Comment 20

[[e-mail] (:bhearsum)]

For the record, this box is running GCC 4.2.3 and uses the same mozconfig that the 32-bit dep/nightly builds use.

Comment 21

[[e-mail] (:bhearsum)]

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
done