Closed
Bug 625144
Opened 15 years ago
Closed 15 years ago
GECKO_PLATFORM_INI_PATH/FENNEC_APPLICATION_INI_PATH are wrong for Mac Desktop builds
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bhearsum, Assigned: bhearsum)
References
Details
Attachments
(1 file)
|
680 bytes,
patch
|
mozilla
:
review+
ted
:
review+
|
Details | Diff | Splinter Review |
I was attempting a Fennec Desktop repack on a Mac today and found that "make ident" failed because it couldn't find platform.ini. It appears to me that the non-libxul SDK paths are wrong for these files. Rather than:
GECKO_PLATFORM_INI_PATH="$(STAGEDIST)/../Resources/platform.ini"
FENNEC_APPLICATION_INI_PATH="$(STAGEDIST)/../Resources/application.ini"
They should be:
GECKO_PLATFORM_INI_PATH="$(STAGEDIST)/platform.ini"
FENNEC_APPLICATION_INI_PATH="$(STAGEDIST)/application.ini"
In the most recent nightly Desktop Mac en-US build there is no "Resources" directory.
I don't know if the libxul SDK path is still correct, but I don't think it's used
Patch is attached.
Attachment #503246 -
Flags: review?(ted.mielczarek)
Attachment #503246 -
Flags: review?(aki)
Comment 1•15 years ago
|
||
Comment on attachment 503246 [details] [diff] [review]
[checked in] fix ini paths for non-libxul SDK mac repacks
Having it work and not go to a non-existent directory sound good to me. r=me if Ted's ok with it.
Attachment #503246 -
Flags: review?(aki) → review+
Comment 2•15 years ago
|
||
This could be fallout from bug 557027.
Updated•15 years ago
|
Assignee: nobody → bhearsum
Comment 3•15 years ago
|
||
Comment on attachment 503246 [details] [diff] [review]
[checked in] fix ini paths for non-libxul SDK mac repacks
But I dunno, it's in a non-LIBXUL_SDK block, so maybe it just never worked.
Attachment #503246 -
Flags: review?(ted.mielczarek) → review+
| Assignee | ||
Comment 4•15 years ago
|
||
Drivers, the patch in this bug is a fix that makes it possible for us to have Desktop Mac l10n repacks, if we want. This codepath is not part of the en-US build, nor any repacks we currently have running. I tested it by hand and found no issues.
Status: NEW → ASSIGNED
blocking2.0: --- → ?
| Assignee | ||
Comment 5•15 years ago
|
||
I just realized that this is not a code path used by any infrastructure (currently), so I landed it.
Removing blocking2.0? request.
Status: ASSIGNED → RESOLVED
blocking2.0: ? → ---
Closed: 15 years ago
Resolution: --- → FIXED
| Assignee | ||
Comment 6•15 years ago
|
||
Comment on attachment 503246 [details] [diff] [review]
[checked in] fix ini paths for non-libxul SDK mac repacks
changeset: 2649:43c93d0f958d
Attachment #503246 -
Attachment description: fix ini paths for non-libxul SDK mac repacks → [checked in] fix ini paths for non-libxul SDK mac repacks
You need to log in
before you can comment on or make changes to this bug.
Description
•