Closed Bug 956451 Opened 9 years ago Closed 8 years ago

Add configs for debug B2G Mac OS X desktop builds & enable on mozilla-central and mozilla-aurora


(Release Engineering :: General, defect)

Not set


(firefox30 fixed, firefox31 fixed, b2g-v1.4 fixed, b2g-v2.0 fixed)

Tracking Status
firefox30 --- fixed
firefox31 --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed


(Reporter: gkw, Assigned: sbruno)



(3 files, 1 obsolete file)

It will be good to have a debug version of:

created at:

(for example)

I believe this encompasses only Gaia and Gecko, so it's ok to be public.

It's basically the B2G Desktop version of

This will help speed up fuzzing efforts since B2G desktop should be much faster than the emulator builds.
Component: General → General Automation
Product: Firefox OS → Release Engineering
QA Contact: catlee
Summary: Create debug B2G desktop builds on tinderbox → Create debug B2G desktop builds
Assignee: nobody → sbruno
Hi Gary, I have two questions for you about this:

1. What branches do you want this build to be enabled for?
2. Are there any specific flags you want to enable in the corresponding "mozconfig" file?


Flags: needinfo?(gary)
For my purposes, at least for mozilla-aurora and mozilla-central, and if it's flags, then probably disable FTU and/or the lockscreen.

However, I'm not the most authoritative on this and other members of the QA / ateam use B2G Desktop for testing more often and I think they *might* be in a better position to advise on this.

Zac, thoughts? (if any, else please feel free to push the needinfo forward)
Flags: needinfo?(gary) → needinfo?(zcampbell)
Gary yes I can't really comment; we'd continue to focus on the user build.
Flags: needinfo?(zcampbell)
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 916111
This is still work in progress, I still need to properly test it on my staging environment.
I will submit the patches above for review as soon as I complete some tests in the staging environment.
Attachment #8363594 - Attachment is obsolete: true
Attachment #8382915 - Flags: review?(catlee)
Attachment #8363595 - Attachment description: mozconfig file to be used for the debug build - WIP → mozconfig file to be used for the debug build
Attachment #8363595 - Attachment filename: 956451_WIP_mozconfig_debug → 956451_mozconfig_debug
Attachment #8363595 - Attachment is patch: true
Attachment #8363595 - Flags: review?(catlee)
Hi catlee,

I discussed this with Aki in the past weeks, but he's not available these days so I am asking you for review.

I am going to also upload changes to add this new build to tbpl.


Comment on attachment 8382915 [details] [diff] [review]
b2g_config changes

Review of attachment 8382915 [details] [diff] [review]:

r+ with the unittest_platform fixed.

::: mozilla/
@@ +270,5 @@
>      },
> +    'macosx64_gecko-debug': {
> +        'product_name': 'b2g',
> +        'app_name': 'b2g',
> +        'unittest_platform': 'macosx64_gecko-opt',

I don't think this is right. Should be 'macosx64_gecko-debug'
Attachment #8382915 - Flags: review?(catlee) → review+
Attachment #8363595 - Attachment is patch: false
Attachment #8363595 - Flags: review?(catlee) → review+
Resolution: DUPLICATE → ---
Not sure as to the differences between this bug and bug 916111, but there are patches here so not leaving as a dupe.

Seems like best to morph this to be just about enabling B2G OS X desktop debug builds and bug 916111 being about the overall B2G debug story. Adjusting summary and marking blocking that bug - please adjust as appropriate.

Simone - re the email - for these jobs to appear on a debug row in TBPL, they just need to contain the string 'debug' somewhere in the build job name (and at such point where tests are being run too; the test job name) :-)
Blocks: 916111
No longer blocks: bld-lion-r5-087
Summary: Create debug B2G desktop builds → Add configs for debug B2G desktop builds & enable on mozilla-central and mozilla-aurora
Simone: what's the status here?
Flags: needinfo?(sbruno)
Hi Aki, I've been a bit slow on this :-(

I'll land today the mac-debug related changes, I am now working on the other debug builds (next will be the linux ones).
Flags: needinfo?(sbruno)
Just pushed the mac-debug related changes (including the mozconfig file to mozilla-central), the build should be enabled at next reconfig.
After pushing the patch to, the ci failed with the following message:

AssertionError: <buildbotcustom.scheduler.SpecificNightly-props instance at 0xa921d88> uses unknown builder b2g_mozilla-aurora_macosx64_gecko-debug nightly

This extra patch should fix the problem - catlee, can you confirm this is the right direction? Thanks!
Attachment #8399578 - Flags: review?(catlee)
Attachment #8399578 - Flags: review?(catlee) → review+
This was landed on m-c yesterday and the bug wasn't ever marked as such. Please don't forget to do so in the future.

Also, this is now burning on Aurora due to the patch not landing there yet. I've gone ahead and landed it there as well to hopefully fix the bustage.
Flags: needinfo?(sbruno)
Thanks Ryan - you are absolutely right... Thanks for landing the aurora part!
Flags: needinfo?(sbruno)
Attachment #8363595 - Flags: checked-in+
Attachment #8382915 - Flags: checked-in+
Attachment #8399578 - Flags: checked-in+
Relevant changesets:
Summary: Add configs for debug B2G desktop builds & enable on mozilla-central and mozilla-aurora → Add configs for debug B2G Mac OS X desktop builds & enable on mozilla-central and mozilla-aurora
Closed: 9 years ago8 years ago
Resolution: --- → FIXED
Hidden for not meeting visibility standards. They can be unhidden once they're running on all trunk branches.
Resolution: FIXED → ---
Guys, what is the minimal set of branches this should be enabled on in order to comply with the Visibility Rules? I am not able to induce an answer just examining the branches listed in other jobs.
Flags: needinfo?(catlee)
Flags: needinfo?(aki)
"all the trees that merge into it": I think that means m-c, m-i, b-i, fx-team, try.
Flags: needinfo?(aki)
Flags: needinfo?(catlee)
"As a rough guide, mozilla-central based trees include mozilla-inbound, fx-team, services-central, ionmonkey, graphics as well as many of the other project/disposable repositories." And don't forget item 5, runs on Try.

There is no minimal set because sheriffs and developers, who wrote that document, very much don't want the minimal set. As a mental experiment, pick your favorite developer that you don't want to disappoint (I usually pick bz), and imagine him working on a twig, a twig that you are desperately trying to not run this job on, for 18 months. He merges his 18 months worth of work to mozilla-central, and burns this build, because you gave him a defective twig which didn't meet the implied promise of "this will tell me what will happen when I merge to m-c."

Now what? If your answer is "well, we hide this build, and work on fixing it" then where to run this is easy: you are not *trying* to create a visible job here, so just run it on whatever branches gkw wants to download builds for, leave it hidden, and make him responsible for filing bugs when it breaks, the same level of support that most of the JS shell builds have.

If instead you are trying to create a build for which any bustage-causing checkin must be immediately backed out, then your answer is in the Visibility_Policy, "and release engineering will enable it in the default config from which all trunk trees inherit (unless the various tree owners have explicitly opted out)." Though since that's aimed at the requester rather than the requestee, it doesn't mention that along with putting it in the default set and removing it just from release branches where you don't want it yet until it follows the trains, you also need to look at twigs with locked platforms, and add it to the ones which would have chosen it if it had existed at the time: Pine, which runs every b2g job, should certainly not be the only twig which does not run a b2g build.
Gary, in the light of Philor's explanation (thanks Philor!), should we keep this enabled (and hidden) on just m-c and aurora (as it currently is), or just enable it on all trunk trees?
Flags: needinfo?(gary)
(In reply to Simone Bruno [:simone] from comment #24)
> Gary, in the light of Philor's explanation (thanks Philor!), should we keep
> this enabled (and hidden) on just m-c and aurora (as it currently is), or
> just enable it on all trunk trees?

I'd go with enabling it on all trunk trees, having it enabled but hidden will not be of much use.
Flags: needinfo?(gary) → needinfo?(sbruno)
> having it enabled but hidden will not be of much use.

(especially since no one will likely immediately spot this going orange/red after a patch landing.)
Thanks Gary! I'll submit a patch for that then.
Flags: needinfo?(sbruno)
Bug cleanup - For simplicity, I will track progress about this on bug Bug 916111; this is a subset of 916111, in this sense I am marking this as a duplicate.
Closed: 8 years ago8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 916111
No longer blocks: 916111
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.