Closed Bug 1642092 Opened 4 years ago Closed 4 years ago

./mach package busted: package> make[6]: *** [package-langpack-en-US] Error 1

Categories

(Firefox Build System :: General, defect, P1)

Product:
Firefox Build System
Component:
General
Type:
defect

Tracking

(firefox78 fixed)

Status:
RESOLVED FIXED
Milestone:
mozilla78
Tracking Flags:
Tracking Status
firefox78 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: Pike)

References

(Regression)

Details

(Keywords: intermittent-failure, regression)

Attachments

(1 file, 2 obsolete files)

Bug 1642092, find toolkit/locales/en-US/defines.inc for comm* builds, r=#build
47 bytes, text/x-phabricator-request
Details | Review
Severity: normal → S1
Priority: P5 → P1

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.

./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

Flags: needinfo?(l10n)
Regressed by: 1641791
Summary: CI busted 2020-05-30: Intermittent package> make[6]: *** [package-langpack-en-US] Error 1 → ./mach package busted: package> make[6]: *** [package-langpack-en-US] Error 1
Has Regression Range: --- → yes
Keywords: regression

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.

Is there a way to use TOPSRCDIR here?

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!

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'

Ah so the fact that it begins whit a / does not make it treated as absolute.

So perhaps calling EXPAND_LOCALE_SRCDIR is the issue

How about
LOCALE_SRCDIR = $(call EXPAND_LOCALE_SRCDIR,../toolkit/locales)/defines.inc ...

(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 ...

Or perhaps a +=

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."

Attached patch Patch that works for Me (obsolete) — — Splinter Review

This works for me, but still not convinced it is the correct thing to do.

Attached file Better patch (obsolete) —

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.

Attachment #9152957 - Attachment is obsolete: true

surrounding the "$(call EXPAND_LOCALE_SRCDIR,../toolkit/locales)/defines.inc" with a $wildcard prevents the failure if it does not match anything.

With that it succeeds, but I don't know if it does the right thing.

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.

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: nobody → l10n
Component: Build Config → General
Flags: needinfo?(l10n)
Product: Thunderbird → Firefox Build System

This was regressed by bug 1641791, mostly for the lack of comments in at
least two places.

(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=#build

This 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.

Attachment #9152959 - Attachment is obsolete: true
Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/integration/autoland/rev/96d034123ad9
find toolkit/locales/en-US/defines.inc for comm* builds, r=nalexander

https://hg.mozilla.org/mozilla-central/rev/96d034123ad9

Status: NEW → RESOLVED
Closed: 4 years ago
status-firefox78: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: