Closed Bug 607392 Opened 14 years ago Closed 10 years ago

split tagging into en-US and other

Categories

(Release Engineering :: Release Automation, defect, P4)

All
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: massimo)

References

Details

(Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2066] )

Attachments

(5 files, 21 obsolete files)

7.09 KB, patch
rail
: review+
massimo
: checked-in+
Details | Diff | Splinter Review
14.53 KB, patch
rail
: review+
massimo
: checked-in+
Details | Diff | Splinter Review
5.87 KB, patch
rail
: review+
massimo
: checked-in+
Details | Diff | Splinter Review
671 bytes, patch
rail
: review+
massimo
: checked-in+
Details | Diff | Splinter Review
3.76 KB, patch
rail
: review+
massimo
: checked-in+
Details | Diff | Splinter Review
There's no technical reason why we need to block the start of non-l10n builds/source packages on l10n repositories being tagged. We should parallelize en-US and l10n tagging, and start en-US builds, source packages, and xulrunner builds as soon as en-US tagging finishes.
bug 708656 is adding a builder that runs prior to tagging. I think it will be easier to do this once it lands.
The bulk of this work is in tag-release.py. There's a couple ways we can approach it: 1) Add --tag-sourceRepo, --tag-l10n, --tag-other flags to the script, and make the associated blocks conditional on those flags. 2) Pass in a list of repositories as arguments, and check all repos against that list, skipping those that don't exist. I'm not sure which is better, etiher is probably OK.
Assignee: nobody → bugspam.Callek
Attached patch [tools] v1 (obsolete) — Splinter Review
This is the attempt at doing the tagging script change, still have the necessary buildbotcustom change to do.
Attachment #592974 - Flags: review?(bhearsum)
Comment on attachment 592974 [details] [diff] [review] [tools] v1 Review of attachment 592974 [details] [diff] [review]: ----------------------------------------------------------------- Looks good to me. This can probably land right away ,considering it defaults to the old behaviour.
Attachment #592974 - Flags: review?(bhearsum) → review+
Attached patch [buildbotcustom] v1 (obsolete) — Splinter Review
This should do it, I don't have a Firefox buildmaster test setup anywhere yet to verify that it doesn't cause any problems (even with checkconfig) though.
Attachment #594332 - Flags: review?(bhearsum)
Comment on attachment 594332 [details] [diff] [review] [buildbotcustom] v1 Review of attachment 594332 [details] [diff] [review]: ----------------------------------------------------------------- All the builder/scheduler changes look OK to me, but this code is fresh in Rail's mind so I'd like him to double check it. r- because of the small issue noted below. ::: process/release.py @@ +390,3 @@ > scriptRepo=tools_repo, > scriptName='scripts/release/tagging.sh', > + extra_args=("--tag-source",), This won't quite do it...these extra args are passed to tagging.sh, not tag-release.py. You'll need to find some way to pass them through.
Attachment #594332 - Flags: review?(bhearsum) → review-
Attached patch [tools] Part 2, use EXTRA_DATA (obsolete) — Splinter Review
I realized we have extra_data as an option to ScriptFactory, and this looks perfect for our use here.
Attachment #594814 - Flags: review?(bhearsum)
Attached patch [buildbotcustom] v2 (obsolete) — Splinter Review
This should adjust it as requested. Rail, ben wanted you to do a final review of it since this stuff is fresh in your mind.
Attachment #594332 - Attachment is obsolete: true
Attachment #594818 - Flags: review?(rail)
Attachment #594818 - Flags: feedback?(bhearsum)
Comment on attachment 594818 [details] [diff] [review] [buildbotcustom] v2 This is not a real review for now. Can you add a check if we really want to tag l10n repos? For example Fennec 11.0b1 was en-US only, so there will be no need to tag nor run repacks. Something like "if releaseConfig['l10nPlatforms']".
(In reply to Rail Aliiev [:rail] from comment #11) > Comment on attachment 594818 [details] [diff] [review] > [buildbotcustom] v2 > > This is not a real review for now. Can you add a check if we really want to > tag l10n repos? For example Fennec 11.0b1 was en-US only, so there will be > no need to tag nor run repacks. Something like "if > releaseConfig['l10nPlatforms']". The tag_l10n also does the tagging of "other" repos. I think the optional "don't do l10n repacks/tag l10n" should be a different bug. If you disagree I can try and fold that here, but I'd rather keep the logic separate to different bug.
Sounds good in this case. Fennec handles fine en-US only releases (with {} in the l10n json file). Not sure if en-US only Firefox should be a blocker here (another bug?). I'll review the patch in in a couple of days. Thanks for the patch, btw. It should reduce end-to-end time of the release procedure for another 10-20 minutes!
(In reply to Justin Wood (:Callek) from comment #12) > (In reply to Rail Aliiev [:rail] from comment #11) > > Comment on attachment 594818 [details] [diff] [review] > > [buildbotcustom] v2 > > > > This is not a real review for now. Can you add a check if we really want to > > tag l10n repos? For example Fennec 11.0b1 was en-US only, so there will be > > no need to tag nor run repacks. Something like "if > > releaseConfig['l10nPlatforms']". > > The tag_l10n also does the tagging of "other" repos. I think the optional > "don't do l10n repacks/tag l10n" should be a different bug. If you disagree > I can try and fold that here, but I'd rather keep the logic separate to > different bug. I think it makes sense to handle the tagging portion of this here. It should just modify which flags you pass in extra_data, no?
Attachment #594814 - Flags: review?(bhearsum) → review+
Comment on attachment 594818 [details] [diff] [review] [buildbotcustom] v2 Review of attachment 594818 [details] [diff] [review]: ----------------------------------------------------------------- ::: process/release.py @@ +1500,5 @@ > + repack_upstream = [ > + builderPrefix('%s_build' % platform), > + builderPrefix('%s_tag_l10n' % releaseConfig['productName']), > + ] > + repack_scheduler = AggregatingScheduler( Hmmm, if you're switching to AggregatingScheduler here you should remove the Trigger steps from the en-US builds, too. Even though its based on Triggerable, AggregatingScheduler functions like the Dependent Scheduler in terms of how builds are actually triggered. When you trigger() an AggergatingScheduler you actually reset its state, which would probably be bad here! Rail, any other gotchas to watch out for?
Comment on attachment 594818 [details] [diff] [review] [buildbotcustom] v2 > Hmmm, if you're switching to AggregatingScheduler here you should remove the > Trigger steps from the en-US builds, too. Even though its based on > Triggerable, AggregatingScheduler functions like the Dependent Scheduler in > terms of how builds are actually triggered. When you trigger() an > AggergatingScheduler you actually reset its state, which would probably be > bad here! +1 > Rail, any other gotchas to watch out for? I think that --tag-other should be done as a part of source tagging. Mobile builds would fail since they require tagged mozharness.
Attachment #594818 - Flags: review?(rail) → review-
Attachment #594818 - Attachment is obsolete: true
Attachment #594818 - Flags: feedback?(bhearsum)
Attached patch [buildbotcustom] v3 (obsolete) — Splinter Review
This should address all review comments: * Don't do tagging unless we have l10nPlatforms (instead do a Dummy* for tagging) * Do --tag-other in the source tagging. (Added a comment why) * Removed the Trigger directive from the Build.
Attachment #595163 - Flags: review?(rail)
Comment on attachment 595163 [details] [diff] [review] [buildbotcustom] v3 Review of attachment 595163 [details] [diff] [review]: ----------------------------------------------------------------- Yay! Thanks a lot for the patch. There are just 2 nits. Otherwise it looks fine and passes test_masters.sh. Let's land it once we're done with the 10.0.1 release. ::: process/release.py @@ +419,5 @@ > + scriptRepo=tools_repo, > + scriptName='scripts/release/tagging.sh', > + extra_data={"tag_args": "--tag-l10n"}, > + ) > + Please remove trailing spaces from this line. @@ +609,4 @@ > unittestBranch=unittestBranch, > clobberURL=branchConfig['base_clobber_url'], > triggerBuilds=True, > + triggeredSchedulers=None, You can drop this parameter completely since it's None by default.
Attachment #595163 - Flags: review?(rail) → review+
Attachment #594814 - Flags: checked-in+
Attachment #595163 - Flags: checked-in+
Just pushed these, and had to do a followup for c#19 nits that I forgot to qref.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Didn't work as expected for 11.0b3. Tagging ran twice for all repos. Since tagging.sh runs without "set -x" it's harder to debug it. Some additional information: * download_extra step worked, what indicates that extra_data was passed * there is no data.json file on the slave
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I suspect clobberer, adding "-s data.json" to our boilerplate script wrappers should help here...
Yes, I blame clobberer: rel-m-beta-firefox-tag-source:Clobbering... Skipping scripts Removing buildbot-configs/ Skipping last-clobber Skipping buildprops.json Removing mozilla-beta/ Removing data.json
I currently suspect this bug for breaking linux repacks (script_repo_revision not set anymore.)
(In reply to Aki Sasaki [:aki] from comment #24) > I currently suspect this bug for breaking linux repacks > (script_repo_revision not set anymore.) s,linux,all, script_repo_revision isn't set and branch is incorrect.
Not having the branch set also breaks clobberer: Checking clobber URL: http://build.mozilla.org/clobberer/index.php?master=http%3A%2F%2Fbuildbot-master08.build.sjc1.mozilla.com%3A8001%2F&slave=mv-moz2-linux-ix-slave02&builddir=rel-m-beta-lnx-rpk-2&branch=None&buildername=release-mozilla-beta-linux_repack_2%2F6 ... rel-m-beta-lnx-rpk-2:Our last clobber date: 2012-02-14 20:52:40 rel-m-beta-lnx-rpk-2:Server clobber date: 2012-01-27 16:05:40 vs Checking clobber URL: http://build.mozilla.org/clobberer/index.php?master=http%3A%2F%2Fbuildbot-master08.build.sjc1.mozilla.com%3A8001%2F&slave=mv-moz2-linux-ix-slave10&builddir=rel-m-beta-lnx-bld&branch=mozilla-beta&buildername=release-mozilla-beta-linux_build ... rel-m-beta-lnx-bld:Our last clobber date: 2012-02-14 10:26:49 rel-m-beta-lnx-bld:Server clobber date: 2012-02-14 20:52:40 rel-m-beta-lnx-bld:Server is forcing a clobber, initiated by asasaki@mozilla.com
Attached patch [buildbotcustom] fix bustage (obsolete) — Splinter Review
Not sure which one of you needs to look, but this *should* fix my bustage here. I did not test since I have no staging area to use
Attachment #597368 - Flags: review?(rail)
Attachment #597368 - Flags: review?(aki)
Attached patch [buildbotcustom] fix bustage (obsolete) — Splinter Review
(this time without typo)
Attachment #597368 - Attachment is obsolete: true
Attachment #597369 - Flags: review?(rail)
Attachment #597369 - Flags: review?(aki)
Attachment #597368 - Flags: review?(rail)
Attachment #597368 - Flags: review?(aki)
Comment on attachment 597369 [details] [diff] [review] [buildbotcustom] fix bustage branch is a required parameter. On IRC we agreed to backout the patches and land them when they are ready and tested.
Attachment #597369 - Flags: review?(rail)
Attachment #597369 - Flags: review?(aki)
Attachment #597369 - Flags: review-
Attachment #595163 - Flags: checked-in+ → checked-in-
Attachment #594814 - Flags: checked-in+ → checked-in-
Attached patch [buildbotcustom] v3 (obsolete) — Splinter Review
This replaces all previous patches on this bug, and [hopefully] corrects all issues. This is applied on top of bug #727489 and uses that design as branch=
Attachment #595161 - Attachment is obsolete: true
Attachment #595163 - Attachment is obsolete: true
Attachment #597369 - Attachment is obsolete: true
Attachment #598711 - Flags: review?(rail)
Attached patch [tools] v3 (obsolete) — Splinter Review
This patch incorporates all previous patches in this bug, and does the following: * Fixes -z to -n * makes the use of EXTRA_DATA add to clobberer excludes * set -ex instead of set -e
Attachment #592974 - Attachment is obsolete: true
Attachment #594814 - Attachment is obsolete: true
Attachment #598713 - Flags: review?(rail)
Attached patch [buildbotcustom] v3.1 (obsolete) — Splinter Review
(add in nits from previous review here)
Attachment #598711 - Attachment is obsolete: true
Attachment #598714 - Flags: review?(rail)
Attachment #598711 - Flags: review?(rail)
Attached patch [buildbotcustom] v3.2 (obsolete) — Splinter Review
I got to get better at saving and qref-ing before attaching lately.
Attachment #598714 - Attachment is obsolete: true
Attachment #598881 - Flags: review?(rail)
Attachment #598714 - Flags: review?(rail)
Comment on attachment 598713 [details] [diff] [review] [tools] v3 Review of attachment 598713 [details] [diff] [review]: ----------------------------------------------------------------- ::: scripts/release/tag-release.py @@ +183,4 @@ > if err: > sys.exit(1) > + > + # Non-fatal warnings only after this point Please remove trailing spaces above. @@ +214,5 @@ > + help="Tag the source repo(s).") > + parser.add_option("--tag-l10n", dest="tag_l10n", > + help="Tag the L10n repo(s).") > + parser.add_option("--tag-other", dest="tag_other", > + help="Tag the other repo(s).") The options above expect argumets, if you try to run the script using command line you get: tag-release.py: error: --tag-l10n option requires an argument You need to use action="store_false/true" here. "tag-release.py ... --tag-source --tag-other" works, but it doesn't tag "other" repos, since optparse interprets --tag-other as an argument of --tag-source.
Attachment #598713 - Flags: review?(rail) → review-
Attached patch [tools] v4 (obsolete) — Splinter Review
Attachment #598713 - Attachment is obsolete: true
Attachment #599148 - Flags: review?(rail)
Callek, could you also update mozilla/release_templates to reflect the changes in the builder names? Please, also remove trailing spaces from the tools patch. I'm running a staging release right now. Tagging worked fine. Waiting for other builders to be triggered properly (l10n).
Mass move of bugs to Release Automation component.
Component: Release Engineering → Release Engineering: Automation (Release Automation)
Flags: checked-in-
No longer blocks: hg-automation
Attachment #598881 - Flags: review?(rail)
Comment on attachment 599148 [details] [diff] [review] [tools] v4 r+ if you remove trailing spaces from the patch.
Attachment #599148 - Flags: review?(rail) → review+
I'll be happy to review unbitrotten builbotcustom and buildbot-configs patches with template changes. ;)
Sorry it got lost in my queue.
Attachment #611360 - Flags: review?(rail)
This was re-created by hand based on the previous diff here, since I couldn't quickly remember how to rebase properly since my local repo was also newer enough to make the last copy of the patch fail to apply. A re-run of staging release is probably worth it
Attachment #598881 - Attachment is obsolete: true
Attachment #611361 - Flags: review?(rail)
Last patch was old though had review, just re-requesting for the trio
Attachment #599148 - Attachment is obsolete: true
Attachment #611362 - Flags: review?(rail)
Attachment #611362 - Flags: review?(rail) → review+
Testing the patches in staging...
Attachment #611361 - Flags: review?(rail) → review+
Interdiff: https://gist.github.com/2284520 * We still need tag_change, it used by http://hg.mozilla.org/build/buildbotcustom/file/309e0a7cddbd/process/release.py#l1818, then hardcoded here http://hg.mozilla.org/build/buildbotcustom/file/309e0a7cddbd/process/release.py#l219 * No need for *_tag_{source,l10n}_change templates, *_change templates are used only by ChangeNotifier, which uses hardcoded "tag" prefix. Ship it once you r+ this one!
Attachment #611360 - Attachment is obsolete: true
Attachment #611473 - Flags: review?(bugspam.Callek)
Attachment #611360 - Flags: review?(rail)
Comment on attachment 611473 [details] [diff] [review] [buildbot-configs] v2 - Updates templates r+ for the changes, but f- since this didn't preserve the hg rename/copies I explicitly did in my patch. If you don't beat me to it I'll land in my unpaid time later today though.
Attachment #611473 - Flags: review?(bugspam.Callek)
Attachment #611473 - Flags: review+
Attachment #611473 - Flags: feedback-
(In reply to Justin Wood (:Callek) from comment #48) > Comment on attachment 611473 [details] [diff] [review] > [buildbot-configs] v2 - Updates templates > > r+ for the changes, but f- since this didn't preserve the hg rename/copies I > explicitly did in my patch. Ouch... I use git to generate the patches, which doesn't handle explicit file renames... The current patch should be fine. > If you don't beat me to it I'll land in my unpaid time later today though. Sure thing, no rush.
Attachment #611473 - Attachment is obsolete: true
Attachment #611525 - Flags: review?(bugspam.Callek)
Comment on attachment 611361 [details] [diff] [review] [buildbotcustom] v4 - Unbitrotted http://hg.mozilla.org/build/buildbotcustom/rev/cdda75585a84 <-- Pushed with rail as author instead of me, not sure how that happened, but not worth the backout and reland imo.
Attachment #611361 - Flags: checked-in+
Attachment #611525 - Flags: review?(bugspam.Callek) → review+
Comment on attachment 611362 [details] [diff] [review] [tools] v4.1 - Updated (no trailing whitespace) http://hg.mozilla.org/build/tools/rev/bf37aabfd936
Attachment #611362 - Flags: checked-in+
Sending a mail to release@ for a heads up, and this is now fixed.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Made it to production today.
I believe this broke Fennec l10n tagging.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Aki Sasaki [:aki] from comment #55) > I believe this broke Fennec l10n tagging. Could you elaborate on this?
Blocks: 749542
Since there are no l10nPlatforms (single locale) but we require l10n tagging for multilocale, we can't go by len(l10nPlatforms) as the only check for whether to tag. Testing on staging.
Attachment #619138 - Attachment is obsolete: true
Comment on attachment 619157 [details] [diff] [review] (untested) fix fennec split tagging, with typo fix This patch gets the Fennec l10n tag builder to be a non-Dummy builder, but I'm hitting issues where the Fennec l10n mozilla-beta tag builder is trying to tag mozilla-beta over and over (instead of noticing there are no locales to tag, and skipping). I'm leaning towards backing out split tagging to fix for now.
Attachment #611361 - Flags: checked-in+ → checked-in-
Attachment #611362 - Flags: checked-in+ → checked-in-
There are a few gotchas here in terms of mobile: * The locales are specified in a json changeset file, not the l10n-changesets text file. ** This means that get_l10n_repositories() is not necessarily an accurate list for Fennec; get_locales_from_json() would be correct. ** This bug existed before your work * Multilocale is currently enabled, even though l10nPlatforms isn't. I tried to account for this in https://bugzilla.mozilla.org/attachment.cgi?id=619157 . * However, I hit issues while trying to tag Fennec after applying this patch (see comment 59). So that patch does create an l10n tagging builder instead of a dummy builder, but the builder seems to be doing the wrong thing. ** This may be a side effect of an empty json changeset file on beta?
I know this isn't actively being worked on, but if/when it gets done please make sure to update the Tag section of the documentation to talk about it: https://wiki.mozilla.org/Release:Release_Automation_on_Mercurial:Tagging_through_Signing#Tag
(In reply to Aki Sasaki [:aki] from comment #57) > Since there are no l10nPlatforms (single locale) but we require l10n tagging > for multilocale, we can't go by len(l10nPlatforms) as the only check for > whether to tag. Now that: 1) android native, with single locale repacks, is on mozilla-release, (l10nPlatforms is not empty), and 2) we don't have to support linux-android multilocale (no single locale repacks) on esr10, we may be able to land this again without breaking mobile.
Product: mozilla.org → Release Engineering
I haven't worked on this in a while now. But could further reduce end-to-end time for release jobs if someone wanted to prioritize it.
Assignee: bugspam.Callek → nobody
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2057]
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2057] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2066]
Assignee: nobody → mgervasini
Ported Callek's patch to current version of buildbotcustom and updated tag_l10n_factory to use mock.
Attachment #611361 - Attachment is obsolete: true
Attachment #619157 - Attachment is obsolete: true
Attachment #8532606 - Flags: review?(rail)
Comment on attachment 8532606 [details] [diff] [review] [buildbotcustom] Split tagging into en-US and other.patch Review of attachment 8532606 [details] [diff] [review]: ----------------------------------------------------------------- In overall it looks good, just some minor changes. ::: process/release.py @@ +68,4 @@ > mozharness_repo_path = releaseConfig.get('mozharness_repo_path', > branchConfig['mozharness_repo_path']) > mozharness_repo = '%s%s' % (branchConfig['hgurl'], mozharness_repo_path) > + with_l10n = False This line is redundant. @@ +423,4 @@ > ) > > builders.append({ > + 'name': builderPrefix('%s_tag_source' % releaseConfig['productName']), This requires template file name changes. Can you rename the templates as well? @@ +457,5 @@ > + extra_data={"tag_args": "--tag-l10n"}, > + ) > + > + builders.append({ > + 'name': builderPrefix('%s_tag_l10n' % releaseConfig['productName']), This requires an extra template. @@ +464,5 @@ > + 'builddir': builderPrefix('%s_tag_l10n' % releaseConfig['productName']), > + 'slavebuilddir': normalizeName( > + builderPrefix('%s_tag_l10n' % releaseConfig['productName'])), > + 'factory': tag_l10n_factory, > + 'nextSlave': _nextSlave_skip_spot, nextSlave will be going away with bug 1106922, the same for the source tagging.
Attachment #8532606 - Flags: review?(rail) → review-
Added new templates for Thunderbird
Attachment #8532673 - Flags: review?(rail)
Updated with changes requested in comment #68. Tools patch following soon.
Attachment #8532606 - Attachment is obsolete: true
Attachment #8532675 - Flags: review?(rail)
Attachment #611525 - Attachment is obsolete: true
Updated tagging scripts in tools.
Attachment #611362 - Attachment is obsolete: true
Attachment #8532677 - Flags: review?(rail)
BTW, there are 3 dangling symlinks: $ find -L . -type l ./mozilla/release_templates/fennec_ready_for_release ./mozilla/release_templates/firefox_ready_for_release ./mozilla/release_templates/thunderbird_ready_for_release All of them point to ready_for_release, which doesn't exist. Can you fix them too.
Attachment #8532677 - Flags: review?(rail) → review+
Attachment #8532673 - Flags: review?(rail) → review+
(In reply to Rail Aliiev [:rail] from comment #72) > BTW, there are 3 dangling symlinks: > > $ find -L . -type l > ./mozilla/release_templates/fennec_ready_for_release > ./mozilla/release_templates/firefox_ready_for_release > ./mozilla/release_templates/thunderbird_ready_for_release > > All of them point to ready_for_release, which doesn't exist. Can you fix > them too. Actually never mind, I'll forward this to the original bug.
Attachment #8532675 - Flags: review?(rail) → review+
Attachment #8532673 - Flags: checked-in+
Attachment #8532675 - Flags: checked-in+
Attachment #8532677 - Flags: checked-in+
Temporary fix for: ValueError: Cannot shorten "release-mozilla-release-34.1-firefox_tag_source" to maximum length (30). Got to: rel-m-rel-34.1-firefox_tag_source
Attachment #8533782 - Flags: review?(rail)
Attachment #8533782 - Flags: review?(rail) → review+
Attachment #8533782 - Flags: checked-in+
This patch worked fine for Fennec 35.0b4. On Firefox 35.0b4, instead, all repacks failed because there 'buildid' and 'script_repo_revision' were not set. I am creating a new patch to add the missing properties
I've talked with catlee about this issue. It's not easy to get the buildid in the Aggregating scheduler and propagate it to the down stream builders. A more sane approach would be fix the create-release-repacks.py script to figure out the buildid by itself. I am going to backout, for a while, the changes made in buildbotcustom/buildbot-configs/tools and fix the create-release-repacks.py script.
Attachment #8532673 - Flags: checked-in+ → checked-in-
Attachment #8532675 - Flags: checked-in+ → checked-in-
Attachment #8533782 - Flags: checked-in+ → checked-in-
Attachment #8532677 - Flags: checked-in+ → checked-in-
create-release-repacks.py now uses getBuildID() to find the right buildid. There is no need to get this parameter from the builders.
Attachment #8538542 - Flags: review?(rail)
Attachment #8538542 - Flags: review?(rail) → review+
Attachment #8538542 - Flags: checked-in+
Attachment #8532675 - Flags: checked-in- → checked-in+
Attachment #8532673 - Flags: checked-in- → checked-in+
Attachment #8533782 - Flags: checked-in- → checked-in+
Attachment #8532677 - Flags: checked-in- → checked-in+
The buildid patch from comment #80, has worked fine (Firefox 35.0b5). I have re-landed all the backed out patches.
Firefox and Fennec 35.0b6 build 1 completed without any tagging/repacks problems.
Status: REOPENED → RESOLVED
Closed: 13 years ago10 years ago
Resolution: --- → FIXED
\o/
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: