3.51 KB, patch
|Details | Diff | Splinter Review|
413 bytes, patch
|Details | Diff | Splinter Review|
2.14 KB, patch
|Details | Diff | Splinter Review|
We should have 64-bit desktop builds, since that's by far our biggest development platform for B2G applications. For numbers, see https://bugzilla.mozilla.org/show_bug.cgi?id=776845#c6 I have written a version of patches that I think should work. I don't have access to the mirrors that you use, so I can't actually test things. The main thing that I don't know is whether the 64-bit copy of the Fedora 16 mirror is maintained, and updated at the same level as the 32-bit one, and whether the releng packages have been built for 64-bit. A follow up bug for setting this repository might be a good idea.
This patch adds the linux64_gecko platform to b2g_config.py. I have tested that I was able to build using this package list on a vanilla up to date copy of the Fedora 16 mirrors but with the standard fedora 16 toolchain instead of the releng one. This passes ./setup-masters.py -t -R build as well, requires a small buildbotcustom patch
Attachment #674002 - Flags: review?(bhearsum)
this patch adds the linux64_gecko platform to the list of acceptable platforms
Attachment #674003 - Flags: review?
Attachment #674003 - Flags: review? → review?(bhearsum)
This patch adds a mock configuration to the mock build slaves for the 64bit repositories. I am not sure whether the 64bit copies of Fedora 16 are still being maintained or whether the custom releng package repo has been built for Fedora 16 64-bit.
Ben, if you aren't the person to review these patches, please feel free to reassign
I explicitly didn't do these as part of the original set-up because 64-bit Linux users can run 32-bit builds. I don't care either way, but someone needs to make the call that we're willing to spend the resources on them. CC'ing Catlee/Joduinn for that.
17:11 < catlee> bhearsum: meh 17:11 < catlee> may as well
Comment on attachment 674007 [details] [diff] [review] puppet v1 I'm not the right person to review this patch...I don't know who to suggest.
Attachment #674003 - Flags: review?(bhearsum) → review+
Comment on attachment 674002 [details] [diff] [review] buildbot-configs v1 Review of attachment 674002 [details] [diff] [review]: ----------------------------------------------------------------- r=me with the following two things fixed on check-in. And of course, these can't land until the mock configs get updated. ::: mozilla/b2g_config.py @@ +226,5 @@ > + 'builds_before_reboot': b2g_localconfig.BUILDS_BEFORE_REBOOT, > + 'build_space': 6, > + 'upload_symbols': False, > + 'packageTests': True, > + 'enable_codesighs': False, This flag is about to die in bug 803736, just leave it out please. @@ +232,5 @@ > + 'platform_objdir': OBJDIR, > + 'unittest_masters': , > + 'stage_product': 'b2g', > + 'stage_platform': 'linux64_gecko', > + 'update_platform': 'Linux_x86-gcc3', This is unused AFAIK, but please update to Linux_x86_64-gcc3 for correctness.
Attachment #674002 - Flags: review?(bhearsum) → review+
64-bit users can theoretically run the 32-bit version with the appropriate 32-bit compatibility libs, but those are cumbersome to install on Fedora (easier on Ubuntu), and there may be some other issues (at least one person reported that 32-bit B2G Desktop was having trouble finding its own libs on 64-bit Fedora, although this may be unrelated to the bit depth of the binary). B2G Desktop is key to getting app developers to build apps for Firefox OS, so it's important that it be simple to install and use. I understand that this is extra effort, and as one of its advocates, I don't take it lightly, but in this case it's worth the effort for the better experience the build will provide to developers on 64-bit Linux systems.
Comment on attachment 674007 [details] [diff] [review] puppet v1 >diff --git a/modules/mockbuild/files/mozilla-f16-i386.cfg b/modules/mockbuild/files/mozilla-f16-x86_64.cfg >+++ b/modules/mockbuild/files/mozilla-f16-x86_64.cfg >-[releng-fedora16-i386] >+[releng-fedora16-x86_64] > name=releng-fedora16-i386 >-baseurl=http://repos/repos/yum/releng/public/Fedora/16/i386 >+baseurl=http://repos/repos/yum/releng/public/Fedora/16/x86_64 While all the other x86_64 repo's exist, this one doesn't. r- for that alone. Everything else looks good on a glance though. http://puppetagain.pub.build.mozilla.org/data/repos/yum/releng/public/Fedora/16/
Attachment #674007 - Flags: review-
Ok. I don't know who currently is responsible for setting up that repository, but given that it's an empty one, I don't think we need to block on it. Dustin, are you still heading up the puppetagain project from the relops/it side? What do we need to get the http://repos/repos/yum/releng/public/Fedora/16/x86_64 repository set up?
File a bug. Depending on how big it is, we may need to get space on the servers expanded first (and, ugh, we're going to need to put F15 i386 and x86_64 on there too.. need moar gigz)
it's an empty repository if the internal version matches the one that I can see on .pub.build.mozila.org, so it should be very small
filed bug 804380 for ensuring the needed repositories are set up.
Comment on attachment 674036 [details] [diff] [review] puppet v2 r+ pending the repo's getting set up properly. I see you filed a dep bug and have feedback against dustin here, so once resolved on that front this can land.
Attachment #674036 - Flags: review?(bugspam.Callek) → review+
repos are ready
Attachment #674036 - Flags: feedback?(dustin) → feedback+
Comment on attachment 674003 [details] [diff] [review] buildbotcustom v1 http://hg.mozilla.org/build/buildbotcustom/rev/2c7bcfd1a1cb
Attachment #674003 - Flags: checked-in+
Attachment #674007 - Attachment is obsolete: true
Comment on attachment 674036 [details] [diff] [review] puppet v2 http://hg.mozilla.org/build/puppet/rev/c7dcff48b737
Attachment #674036 - Flags: checked-in+
Comment on attachment 674002 [details] [diff] [review] buildbot-configs v1 http://hg.mozilla.org/build/buildbot-configs/rev/b0b5e299d559
Attachment #674002 - Flags: checked-in+
This is live.
Builds haven't shown up on ftpmo yet, presumably because of this error in the build logs: checking whether the C compiler (/tools/gcc-4.5-0moz3/bin/gcc ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. - https://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2012-10-29-03-05-57-mozilla-central/mozilla-central-linux64_gecko-nightly-bm35-build1-build3.txt.gz - https://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2012-10-29-03-06-02-mozilla-aurora/mozilla-aurora-linux64_gecko-nightly-bm25-build1-build0.txt.gz
Yes, that's why. A fix to the mozconfigs landed earlier today.
(In reply to John Ford [:jhford] from comment #23) > Yes, that's why. A fix to the mozconfigs landed earlier today. https://bugzilla.mozilla.org/show_bug.cgi?id=806548
The central build succeeded! The aurora build is still failing with that same error, however: https://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2012-10-30-03-06-42-mozilla-aurora/mozilla-aurora-linux64_gecko-nightly-bm35-build1-build4.txt.gz
That's great! The remaining work is tracked in bug 806548, closing this bug as the automation is working.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.