./mach package busted: package> make[6]: *** [package-langpack-en-US] Error 1
Categories
(Firefox Build System :: General, defect, P1)
Tracking
(firefox78 fixed)
Tracking | Status | |
---|---|---|
firefox78 | --- | fixed |
People
(Reporter: intermittent-bug-filer, Assigned: Pike)
References
(Regression)
Details
(Keywords: intermittent-failure, regression)
Attachments
(1 file, 2 obsolete files)
Filed by: mkmelin+mozilla [at] iki.fi
Parsed log: https://treeherder.mozilla.org/logviewer.html#?job_id=304375833&repo=comm-central
Full log: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/OFg0Sk88QGCm6QAEhV5Ldw/runs/0/artifacts/public/logs/live_backing.log
Something from https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=a58cc68b0c51645d34cbc7f8f8a30edae77ab396, potentially https://hg.mozilla.org/mozilla-central/rev/683ec8a0929d4b56d24eabd51c6c39207af4e41f (bug 1641131)
Updated•5 years ago
|
I believe this is cased by the check=in for bug 1641791.
(In reply to mac198442 from comment #1)
I believe this is cased by the check=in for bug 1641791.
I verified the above via backout.
Comment 3•5 years ago
|
||
./mach package is busted
FileNotFoundError: [Errno 2] No such file or directory: '/builds/worker/checkouts/gecko/comm/toolkit/locales/en-US/defines.inc'
I would guess the the earlier patch (bug 1641184) broke normal localization repacks since those went red 2020-05-29.
RuntimeError: File "chrome/calendar/calendar-alarms.properties" not found in z:/task_1590753440/workspace/obj-build/comm/mail/locales/merge-dir/ast\calendar
See https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=304375842&repo=comm-central&lineNumber=62006
Updated•5 years ago
|
Comment 4•5 years ago
|
||
For thunderbird it works if I (for https://hg.mozilla.org/mozilla-central/rev/dcd6c6877bba) make it
- $(call EXPAND_LOCALE_SRCDIR,toolkit/locales)/defines.inc \
+ $(call EXPAND_LOCALE_SRCDIR,../toolkit/locales)/defines.inc \
But that's obviously not correct.
Comment 6•5 years ago
|
||
Seem not, since that is an absolute value. If what I put there is something non-relative, things don't work.
So maybe $(call EXPAND_LOCALE_SRCDIR, $(topsrcdir)/toolkit/locales)/defines.inc \
(In reply to Magnus Melin [:mkmelin] from comment #6)
Seem not, since that is an absolute value. If what I put there is something non-relative, things don't work.
Well that is unfortunate. there must be a way to do this!
Comment 9•5 years ago
|
||
For reference, for comment 7, I get
FileNotFoundError: [Errno 2] No such file or directory: '/home/magnus/Code/tb/mozilla3/comm//home/magnus/Code/tb/mozilla3/toolkit/locales/en-US/defines.inc'
Comment 10•5 years ago
|
||
Ah so the fact that it begins whit a / does not make it treated as absolute.
Comment 11•5 years ago
|
||
So perhaps calling EXPAND_LOCALE_SRCDIR is the issue
How about
LOCALE_SRCDIR = $(call EXPAND_LOCALE_SRCDIR,../toolkit/locales)/defines.inc ...
Comment 12•5 years ago
|
||
(In reply to mac198442 from comment #11)
So perhaps calling EXPAND_LOCALE_SRCDIR is the issue
How about
LOCALE_SRCDIR = $(call EXPAND_LOCALE_SRCDIR,../toolkit/locales)/defines.inc ...
bad cut and paste
How about
LOCALE_SRCDIR = $(topsrcdir)/toolkit/locales)/defines.inc ...
Comment 13•5 years ago
|
||
Or perhaps a +=
Comment 14•5 years ago
|
||
If this idea can't be made to work I back to my original put the code back as it was and add a comment saying "The fallback here is required to build comm-central with Mozilla on top."
Comment 15•5 years ago
|
||
This works for me, but still not convinced it is the correct thing to do.
Comment 16•5 years ago
|
||
This seems the thing to do this should not impact the Firefox build at all. Works for me on SeaMonkey. I do not do Thunderbird builds.
Comment 17•5 years ago
|
||
surrounding the "$(call EXPAND_LOCALE_SRCDIR,../toolkit/locales)/defines.inc" with a $wildcard prevents the failure if it does not match anything.
Comment 18•5 years ago
|
||
With that it succeeds, but I don't know if it does the right thing.
Comment 19•5 years ago
|
||
Well it does not inclue the toolkit crap but then do we really want that or do we want the defines.inc file to be under our control and not hanged at the whim of the Firefox team. I might not do the right thing because we might need to define things in our defines.inc that we used to inherit, but I think that is probably what we wanted all along.
Assignee | ||
Comment 20•5 years ago
|
||
I have a fix for this locally. There are a few spots that I looked at in the last week that made no sense as is, so my fix is mostly comments.
Assignee | ||
Comment 21•5 years ago
|
||
This was regressed by bug 1641791, mostly for the lack of comments in at
least two places.
Comment 22•5 years ago
|
||
(In reply to Axel Hecht [:Pike] from comment #21)
Created attachment 9152968 [details]
Bug 1642092, find toolkit/locales/en-US/defines.inc for comm* builds, r=#buildThis was regressed by bug 1641791, mostly for the lack of comments in at
least two places.
That works for me. Thanks for the correct fix! I also like the comments. If there were proper comments in the first place this most likely would not have been broken in the first place.
Comment 24•5 years ago
|
||
Comment 25•5 years ago
|
||
bugherder |
Comment hidden (Intermittent Failures Robot) |
Description
•