Closed
Bug 460263
Opened 15 years ago
Closed 15 years ago
postflight on macosx fails when building thunderbird with preinstalled lightning
Categories
(Calendar :: Build Config, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
1.0b1
People
(Reporter: ause, Assigned: ause)
Details
Attachments
(1 file, 1 obsolete file)
the unify step breaks because the install.rdf of lightning contain different platform entries.
Flags: tb-integration?
Comment 2•15 years ago
|
||
seems like something we want, since there's a patch - you should request review from a module owner or peer for the module this file is in.
Flags: tb-integration? → tb-integration+
Comment on attachment 343385 [details] [diff] [review] merge lightning install.rdf before running unify i will come up with another patch as this one will break builds without --enable-calendar
Attachment #343385 -
Attachment is obsolete: true
requires moving merge-installrdf.py in the same commit
Attachment #343537 -
Flags: review?
Attachment #343537 -
Flags: review? → review?(gozer)
Comment 5•15 years ago
|
||
(In reply to comment #4) > Created an attachment (id=343537) [details] > the new version also includes the suggested move of merge-installrdf.py from > calendar/lightning/build to build > > requires moving merge-installrdf.py in the same commit Given you're in hg (and with git patches turned on), you can do hg rename yourself to move the file, and then it will show up in hg diff (or hg qdiff if you're using mq as well), you can attach a patch, and if it isn't you pushing it, then as long as the person uses hg import or hg qimport to get it into their repository it will work fine.
Updated•15 years ago
|
Attachment #343537 -
Flags: review?(gozer) → review?(gozer)
Updated•15 years ago
|
Assignee: nobody → ause
Status: NEW → ASSIGNED
Comment 6•15 years ago
|
||
Is there any way this logic could somehow be kept inside calendar/lightninig/build/*.mk instead of inserting itself into build/* ? Or possibly better/different, generalize the approach to correctly unify all install.rdf's generated during universal builds (not being lightninig specific), as this is a generic problem with building universal extensions with arch-specific bits.
(In reply to comment #6) > Is there any way this logic could somehow be kept inside > calendar/lightninig/build/*.mk instead of inserting itself into build/* ? i don't think that makes sense as the inserted actions are required for tb packing, not for creating a lightning.xpi. > > Or possibly better/different, generalize the approach to correctly unify all > install.rdf's generated during universal builds (not being lightninig > specific), as this is a generic problem with building universal extensions with > arch-specific bits. sure, the applied patch is just a workaround for the current problem until unify learns how to merge install.rdf. if you like i can try to create for unify. but as this is hosted in another repository and i doubt that we want to duplicate it, this seemed to be the most promising way to get integrated builds for the moment.
Comment 8•15 years ago
|
||
(In reply to comment #7) > (In reply to comment #6) > > Is there any way this logic could somehow be kept inside > > calendar/lightninig/build/*.mk instead of inserting itself into build/* ? > i don't think that makes sense as the inserted actions are required for tb > packing, not for creating a lightning.xpi. Yes, but what I was trying to say is that it's definitely a workaround for lightning. And under universal builds, any module like lightning would end up requiring this exact same workaround. > > > > Or possibly better/different, generalize the approach to correctly unify all > > install.rdf's generated during universal builds (not being lightninig > > specific), as this is a generic problem with building universal extensions with > > arch-specific bits. > sure, the applied patch is just a workaround for the current problem until > unify learns how to merge install.rdf. Okay, if this was an intended workaround from the start, and teaching unify how to merge install.rdf's, then I am okay with it. r=gozer
Updated•15 years ago
|
Attachment #343537 -
Flags: review?(gozer) → review+
Updated•15 years ago
|
Keywords: checkin-needed
Attachment #343537 -
Attachment description: the new version also includes the suggested move of merge-installrdf.py from calendar/lightning/build to build → [checked in] the new version also includes the suggested move of merge-installrdf.py from calendar/lightning/build to build
i submitted Bug 461515 to enhance unify, not sure who to bother with that.
No longer blocks: 401779
Updated•15 years ago
|
Keywords: checkin-needed
Comment 10•15 years ago
|
||
ause: Can this bug be marked FIXED?
Assignee | ||
Comment 11•15 years ago
|
||
afaik, preinstalled lightning is still disabled by build configuration. so i'd like to wait until it's active.
Assignee | ||
Comment 12•15 years ago
|
||
DISABLE_LIGHTNING_INSTALL is gone now, lightning boxes build thunderbird with preinstalled lightning without error
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Updated•15 years ago
|
Status: RESOLVED → VERIFIED
Updated•14 years ago
|
Target Milestone: 1.0 → 1.0b1
You need to log in
before you can comment on or make changes to this bug.
Description
•