Last Comment Bug 609878 - no longer generating en-US langpacks after bug 578393
: no longer generating en-US langpacks after bug 578393
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla2.0b9
Assigned To: Ben Hearsum (:bhearsum)
:
:
Mentors:
Depends on:
Blocks: 485860 574731 628795
  Show dependency treegraph
 
Reported: 2010-11-05 06:15 PDT by Ben Hearsum (:bhearsum)
Modified: 2011-02-01 09:21 PST (History)
4 users (show)
bugzillamozillaorg_serge_20140323: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
wanted
.14-fixed
.17-fixed


Attachments
[checked in] re-add $(LANGPACK) to the list of potential upload files (636 bytes, patch)
2010-12-10 12:49 PST, Ben Hearsum (:bhearsum)
khuey: review+
dbaron: approval2.0+
brandon: approval1.9.2.14+
brandon: approval1.9.1.17+
Details | Diff | Splinter Review

Description Ben Hearsum (:bhearsum) 2010-11-05 06:15:05 PDT

    
Comment 1 Ben Hearsum (:bhearsum) 2010-11-05 06:17:37 PDT
bug 578393 changed the upload logic a bit and ended up dropping the $(LANGPACK) upload line altogether. In this diff:
http://hg.mozilla.org/mozilla-central/rev/ab6d8c5a300a
there needs to be a $(LANGPACK) line in UPLOAD_FILES similar to the one being removed towards the end.
Comment 2 Ben Hearsum (:bhearsum) 2010-12-10 12:35:26 PST
I'm likely to be fixing this soon.
Comment 3 Ben Hearsum (:bhearsum) 2010-12-10 12:49:23 PST
Created attachment 496899 [details] [diff] [review]
[checked in] re-add $(LANGPACK) to the list of potential upload files
Comment 4 Ben Hearsum (:bhearsum) 2010-12-10 12:53:31 PST
I'd like to land this prior to beta 8 so we can finally do a release with en-US.xpi's. It's also blocking at least one q4 releng goal. I believe that it is very safe.
Comment 5 David Baron :dbaron: ⌚️UTC-7 2010-12-10 14:23:30 PST
I suspect that removal was a merging error, since
http://hg.mozilla.org/mozilla-central/rev/6a3204b41219
landed only a week or so before.
Comment 6 Ben Hearsum (:bhearsum) 2010-12-28 09:42:46 PST
Comment on attachment 496899 [details] [diff] [review]
[checked in] re-add $(LANGPACK) to the list of potential upload files

Landed this on the default branch of mozilla-central:
0ca6c4e19f46
Comment 7 Ben Hearsum (:bhearsum) 2010-12-28 10:37:08 PST
Seems to be working fine after landing.
Comment 8 Ben Hearsum (:bhearsum) 2010-12-29 13:59:43 PST
Drivers, I would like to take this patch on 1.9.1 and 1.9.2 as well, in order to keep the releng l10n repack code consistent across all branches. I've tested it, and believe it will cause no issues, and it has already landed without issue on trunk.
Comment 9 Brandon Sterne (:bsterne) 2010-12-30 09:48:34 PST
Comment on attachment 496899 [details] [diff] [review]
[checked in] re-add $(LANGPACK) to the list of potential upload files

a=bsterne for 1.9.2.14 and 1.9.1.17.
Comment 10 Ben Hearsum (:bhearsum) 2010-12-30 09:56:06 PST
Landed on 1.9.1 and 1.9.2.
Comment 11 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2010-12-30 12:06:10 PST
If this was the result of a mismerge why was it needed on the older branches?  Was the same mistake made there?
Comment 12 Daniel Veditz [:dveditz] 2011-01-03 10:29:45 PST
Marking branch fixed based on
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/702b35a5935a
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f4c422de6fce

But it'd be good to get an answer to khuey's question in comment 11
Comment 13 Ben Hearsum (:bhearsum) 2011-01-10 07:19:20 PST
tl;dr version: didn't need it on 1.9.1/1.9.2 before, now we do

The original bug that turned this on was bug 485860, which at the time, was only wanted for mozilla-central. The thing that prompted me to fix this regression will end up touching all active branches on which we have l10n, so I figured I may as well land on all of them now.
Comment 14 Ben Hearsum (:bhearsum) 2011-01-27 09:37:07 PST
We're still generating langpacks in the wrong place on 1.9.1 and 1.9.2, but I can't figure out why. They should end up dist/$platform/xpi, but they're still in "dist".

Note You need to log in before you can comment on or make changes to this bug.