Closed Bug 744008 Opened 13 years ago Closed 12 years ago

Produce B2G builds for desktop operating systems.

Categories

(Release Engineering :: General, defect, P1)

Product:
Release Engineering
Component:
General
Type:
defect

Tracking

(blocking-basecamp:+)

Status:
VERIFIED FIXED
Project Flags:
blocking-basecamp +

People

(Reporter: vingtetun, Assigned: bhearsum)

References

Details

(Whiteboard: [b2g])

Attachments

(2 files, 1 obsolete file)

desktop build mozconfigs
5.06 KB, patch
cjones
: review+
jhford
: checked-in+
Details | Diff | Splinter Review
rename mozconfigs; adjust compiler
3.05 KB, patch
gal
: review+
bhearsum
: checked-in+
Details | Diff | Splinter Review
Similar to bug 719491 but building for desktop this time, this will let contributors play with B2G/Gaia on Windows/Mac/Linux/... without having to compile B2G on desktop themselves.
Vivien: are there instructions for how to do these builds on desktop, hopefully with configs?
Component: Release Engineering → Release Engineering: Automation (General)
Priority: -- → P3
QA Contact: release → catlee
Whiteboard: [b2g]
I did a mac-10.7 build with the following mozconfig: mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-b2g mk_add_options MOZ_MAKE_FLAGS="-j8" ac_add_options --enable-application=b2g ac_add_options --enable-debug-symbols ac_add_options --enable-profiling ac_add_options --with-ccache ac_add_options --enable-marionette export CXXFLAGS=-DMOZ_ENABLE_JS_DUMP and when I try to run the resulting b2g binary on the command line, I get a segfault: ~/mozilla/desktop-b2g/obj-b2g/dist $ DYLD_LIBRARY_PATH=lib/ gdb ./bin/b2g <snip> Reading symbols for shared libraries . done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000009 nsContainerFrame::SyncFrameViewProperties (aPresContext=0x10966b000, aFrame=0x109690c28, aStyleContext=0x0, aView=0x1, aFlags=0) at nsIView.h:116 116 { return reinterpret_cast<nsIViewManager*>(mViewManager); } Is this to be expected or am I doing something wrong?
This looks like a null pointer crash. What version of mozilla-central are you trying?
901dfde60183, i'll try updating
That rev should be fine AFAIK. You're probably seeing a new gecko bug. Please file! :)
(In reply to Chris Jones [:cjones] [:warhammer] from comment #5) > That rev should be fine AFAIK. You're probably seeing a new gecko bug. > Please file! :) bug 745070, but I wouldn't be surprised if I filed in the wrong component
(In reply to John Ford [:jhford] from comment #2) > I did a mac-10.7 build with the following mozconfig: > > mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-b2g > mk_add_options MOZ_MAKE_FLAGS="-j8" > ac_add_options --enable-application=b2g > ac_add_options --enable-debug-symbols > ac_add_options --enable-profiling > ac_add_options --with-ccache > ac_add_options --enable-marionette > export CXXFLAGS=-DMOZ_ENABLE_JS_DUMP > Let's add those options too: ac_add_options --enable-tests ac_add_options --enable-b2g-ril
(In reply to Chris Cooper [:coop] from comment #1) > Vivien: are there instructions for how to do these builds on desktop, > hopefully with configs? The usual configuration people use is the one at: https://wiki.mozilla.org/Gaia/Hacking
(In reply to Chris Cooper [:coop] from comment #1) > Vivien: are there instructions for how to do these builds on desktop, > hopefully with configs? :coop, bug 732467 discusses some issues with building on OS X; I worked through these on my machine and got a wrking build with the standard options from the wiki, *and* enabling clang as the compiler as the bug suggests: export CC=clang export CXX=clang++ Otherwise, I would get a segfault on start.
*bump*, coop - any feedback on this?
(In reply to Jeff Griffiths from comment #10) > *bump*, coop - any feedback on this? jhford seems to be doing the work here, so let's assign it to him.
Assignee: nobody → jhford
We would love to have these for b2g builds themselves, because xpcshell was recently stripped from the nightly xulrunner package and we need xpcshell to prebuild some DBs.
cc'ing Chris Lee and Dietrich. Guys, b2g desktop builds are a critical part of the tactics plan we're putting together specifically to supply web developers with the best tools and resources we can to build and test apps for b2g. What is blocking this? Does it need to be a higher priority?
(In reply to Jeff Griffiths from comment #13) > cc'ing Chris Lee and Dietrich. Guys, b2g desktop builds are a critical part > of the tactics plan we're putting together specifically to supply web > developers with the best tools and resources we can to build and test apps > for b2g. What is blocking this? Does it need to be a higher priority? jhford no longer works in releng, which might be part of the problem here. jhford: are you still planning on setting these up since you're on the b2g team now? You didn't hand this bug off when you moved over so I'm unsure.
I believe jhford is still working on this as he transitions over to the B2G team. He should be able to help address the issues we're running into now. If not, he should ping cjones for help. Thanks.
Yes, I am working on this. I can get patches together that I think would work, but I don't think I have access to test them beyond running ./setup-masters.py -t I've verified that I can build b2g desktop locally on Mac OS X, so depending on how my Try job goes for the other platforms, we might want a per-platform rollout.
Priority: P3 → P1
By submitting a try job that uses a B2G mozconfig in place of a Firefox one, I've been able to test whether B2G builds on the Releng build hosts. These builds are built with the same toolchain that desktop Firefox is built with, so should have the same runtime dependencies and compatibility. 32-bit Linux: Works 64-bit Linux: Works 64-bit Mac OS X 10.7: Builds, "make buildsymbols" doesn't. I am going to look into the mozconfig. 32-bit Windows: Fails to build while building b2g.exe because of redit.exe not being built. Filed 760138 to track fixing this. I am going to file a bug for the buildbot-configs changes needed, the mozconfigs to be checked into mozilla-central/b2g will be attached to this bug.
Summary: Add b2g-desktop to the list of builds → Produce B2G builds for desktop operating systems.
(In reply to John Ford [:jhford] from comment #17) ... > 64-bit Mac OS X 10.7: > Builds, "make buildsymbols" doesn't. I am going to look into the mozconfig. Which cc on 10.7 are you using? I could only get my builds to work with clang from XCode 4.2 - but I assume that is the standard Firefox toolchain?
(In reply to Jeff Griffiths from comment #18) > (In reply to John Ford [:jhford] from comment #17) > ... > > 64-bit Mac OS X 10.7: > > Builds, "make buildsymbols" doesn't. I am going to look into the mozconfig. > > Which cc on 10.7 are you using? I could only get my builds to work with > clang from XCode 4.2 - but I assume that is the standard Firefox toolchain? I also had some issues on 10.6 regarding the packaging, so I had to patch some files. I can attach the patch here if it's needed.
This is on the buildbot build machines. Those machines are using Xcode 4.1 and have real gcc-4.2 available. They build just fine, it's that the buildsymbols target isn't included in the objdir Makefile.
These mozconfigs build on the try server when put in as the browser/configs/mozconfigs/ equivalents. The Linux builds both fail l10n checks, which will be disabled in the buildbot patch. The mac patch was tested using a couple extra lines to force the objdir to be "obj-firefox/i386" to work around a couple issues with how buildbot picks the directory to run objdir makefile targets. Windows dies trying to build b2g.exe, but that's while trying to run redit.exe, which isn't being built. Bug 760138 tracks fixing the windows builds.
Attachment #629290 - Flags: review?(jones.chris.g)
Attachment #629290 - Flags: review?(jones.chris.g) → review+
I wonder if it make sense to add to the build: ac_add_options --enable-b2g-bt ac_add_options --enable-b2g-ril
(In reply to Vivien Nicolas (:vingtetun) from comment #23) > I wonder if it make sense to add to the build: > ac_add_options --enable-b2g-bt > ac_add_options --enable-b2g-ril Sure! Is it OK if we wait until these builds are green in production to do this?
(In reply to John Ford [:jhford] from comment #24) > (In reply to Vivien Nicolas (:vingtetun) from comment #23) > > I wonder if it make sense to add to the build: > > ac_add_options --enable-b2g-bt > > ac_add_options --enable-b2g-ril > > Sure! Is it OK if we wait until these builds are green in production to do > this? Sounds good to me :)
Nominating for k9o and basecamp - this is badly needed to be able to crowd source testing for b2g for contributors who want to help (we need all the help we can get for QA testing to get more testing).
blocking-basecamp: --- → ?
blocking-kilimanjaro: --- → ?
Can we include these desktop builds all in the same location where the daily QA builds live? See bug 763611 and bug 761868.
Depends on: 763611, 761868
(In reply to Tony Chung [:tchung] from comment #27) > Can we include these desktop builds all in the same location where the daily > QA builds live? See bug 763611 and bug 761868. As far as I know, those builds are not available for distribution outside mozilla due to licenses stuff on the binaries used to produce them. Desktop B2G is not tied to those binaries and can be freely distributed, so I would like this builds to be on a public reachable location.
These builds should end up on the public FTP, ASAP.
(In reply to Jeff Griffiths from comment #29) > These builds should end up on the public FTP, ASAP. Jeff, this is blocked on bug 760168 which is adding the b2g desktop platforms to the releng configurations.
(In reply to Hernán Rodriguez Colmeiro (:peregrino) from comment #28) > (In reply to Tony Chung [:tchung] from comment #27) > > Can we include these desktop builds all in the same location where the daily > > QA builds live? See bug 763611 and bug 761868. > > As far as I know, those builds are not available for distribution outside > mozilla due to licenses stuff on the binaries used to produce them. Desktop > B2G is not tied to those binaries and can be freely distributed, so I would > like this builds to be on a public reachable location. Correct, mozilla cannot distribute the device builds. But mozilla can distribute the manifest files that go with the device builds. And emulator builds are okay. I'm just proposing if we can do something like https://releases.mozilla.com/b2g/public, where the public FTP directory folders contains the following: - Daily Manifest file for device builds - Daily emulator builds (x86 and ARM) - Daily b2g Desktop builds
(In reply to Tony Chung [:tchung] from comment #31) ... > I'm just proposing if we can do something like > https://releases.mozilla.com/b2g/public, where the public FTP directory > folders contains the following: > - Daily Manifest file for device builds > - Daily emulator builds (x86 and ARM) > - Daily b2g Desktop builds That would indeed be splendid.
(In reply to Tony Chung [:tchung] from comment #31) > Correct, mozilla cannot distribute the device builds. But mozilla can > distribute the manifest files that go with the device builds. And emulator > builds are okay. > > I'm just proposing if we can do something like > https://releases.mozilla.com/b2g/public, where the public FTP directory > folders contains the following: > - Daily Manifest file for device builds > - Daily emulator builds (x86 and ARM) > - Daily b2g Desktop builds If that can be done, would be great to have. Will those B2G Desktop builds update like nightly does or that is an entire new issue that should be filed?
*bump* :jhford, what is the status of this? We would like to have publicly available desktop builds for people to be able test apps with at various hack days we are planning in Brazil and around the world, starting in early July. Is this possible?
(In reply to Jeff Griffiths from comment #34) > *bump* :jhford, what is the status of this? We would like to have publicly > available desktop builds for people to be able test apps with at various > hack days we are planning in Brazil and around the world, starting in early > July. Is this possible? Jeff, you should comment in the etherpad below that releng is tracking for build work. See #9 in particular. As far as i can read, there's not a compelling enough reason to proceed with desktop buids. https://etherpad.mozilla.org/b2g-builds
per irc, jhford is focusing on bug#769315 instead so reassigning.
Assignee: jhford → bhearsum
When testing the RelEng side of things over in bug 760168 I got the following error from the Windows build: e:/builds/moz2_slave/m-cen-w32-gecko-ntly/build/obj-firefox/config/nsinstall.exe -D ../../dist/bin/chrome/icons/default cp /e/builds/moz2_slave/m-cen-w32-gecko-ntly/build/b2g/app/b2g.ico ../../dist/bin/chrome/icons/default/b2g.ico e:/builds/moz2_slave/m-cen-w32-gecko-ntly/build/obj-firefox/dist/bin/redit.exe ../../dist/bin/b2g.exe /e/builds/moz2_slave/m-cen-w32-gecko-ntly/build/b2g/app/b2g.ico make[6]: Leaving directory `/e/builds/moz2_slave/m-cen-w32-gecko-ntly/build/obj-firefox/b2g/app' make[5]: Leaving directory `/e/builds/moz2_slave/m-cen-w32-gecko-ntly/build/obj-firefox/b2g' make[4]: Leaving directory `/e/builds/moz2_slave/m-cen-w32-gecko-ntly/build/obj-firefox' make[3]: Leaving directory `/e/builds/moz2_slave/m-cen-w32-gecko-ntly/build/obj-firefox' make[2]: Leaving directory `/e/builds/moz2_slave/m-cen-w32-gecko-ntly/build/obj-firefox' make[1]: Leaving directory `/e/builds/moz2_slave/m-cen-w32-gecko-ntly/build' make[6]: e:/builds/moz2_slave/m-cen-w32-gecko-ntly/build/obj-firefox/dist/bin/redit.exe: Command not found Anyone know how to fix this?
And this patch removes the old "linux32" mozconfig, which was actually for the gb_armv7a_gecko build.
Attachment #637916 - Flags: review?(jones.chris.g)
Same patch as before, except I've removed the $topsrcdir/build/unix/mozconfig.linux inheritance, because it sets a compiler that's not available on the slaves we'll be using to build the Linux desktop builds. Gal, for background: The original mozconfigs were created with different platform names that we ended up using. This patch's purpose is to rename them to make their names consistent with the ones we're using in bug 760168.
Attachment #637916 - Attachment is obsolete: true
Attachment #637916 - Flags: review?(jones.chris.g)
Attachment #638687 - Flags: review?(gal)
Attachment #638687 - Flags: review?(gal) → review+
It seems to me that this *blocks* bug 763611, not depends on it.
Blocks: 763611
No longer depends on: 763611
Depends on: 770624
Depends on: 770625
Depends on: 770628
Depends on: 771095
bugs 770625 and 771095 don't block this because they don't prevent us from producing builds. The former is a nice-to-have that may never get fixed and the latter is a build config issue that needs to be fixed before the Windows builds will run. Once bug 770990 is fixed we'll be creating and uploading builds for Linux, Mac and Windows and IMO be done here.
No longer depends on: 770625, 771095
Comment on attachment 638687 [details] [diff] [review] rename mozconfigs; adjust compiler This was checked in awhile ago.
Attachment #638687 - Flags: checked-in+
Linux, Mac and Windows builds are running, uploading, and working now.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Verified fixes.
Status: RESOLVED → VERIFIED
blocking-basecamp: ? → +
blocking-kilimanjaro: ? → ---
Product: mozilla.org → Release Engineering
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: