Closed Bug 83331 Opened 23 years ago Closed 23 years ago

xptLink fails during Mac packaging

Categories

(SeaMonkey :: Passwords & Permissions, defect)

PowerPC
Mac System 8.5
defect
Not set
major

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 76095
mozilla0.9.1

People

(Reporter: jj.enser, Assigned: morse)

References

Details

(Whiteboard: no eta)

xptLink returns the following error when executed as part of the mac packaging 
automation:

> Linking .xpt files...
> [browser]
> ERROR: found duplicate definitions of interface nsIPasswordManager with iids
> 
173562f0-2173-11d5-a54c-0010a401eb10 and 110c808c-1dd2-11b2-8de5-814d4485c444
> # Error: xpt_link failed.  Exiting...

This causes all .xpt files under Components to be packaged as individual files 
instead of being merged into browser.xpt, mail.xpt, etc.
this should be assigned to the password manager people to fix the duplicate
interface definition.  setting component and reassigning to default component owner.
Assignee: jj → morse
Component: Build Config → Password Manager
QA Contact: granrose → tpreston
Target Milestone: --- → mozilla0.9.1
This looks like a side effect of bug 76095. creating dependency.
Depends on: 76095
This is more than a side=effect, it's a dup of that bug.  Because once that bug 
is fixed, this one is automatically fixed.

*** This bug has been marked as a duplicate of 76095 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
I will have to disagree. I looked at 76095 before adding the dependency and 
understood that the latter is addressing compiler issue while this one is about 
packaging.

appropriate mac installer packaging will not happen until 76095 is resolved. 
That's a dependency.
In addition, packages-mac might need to be updated depending on what the 
resolution is in 76095. If so, a patch to packages-mac should be submitted here.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
why is this happening only now i.e. why did this not happen with previous 
builds? the two password manager idl files existed for a long time. is there any 
workaround? 
Keywords: nsbeta1
Whiteboard: no eta
This is not happening only now. xpt files merge have been broken since April 5th 
and no one reported it until now
why is this a beta/m0.9.1 stopper - does it prevent the build from working? or 
is it that we have some extra files on your hard drive?
it doesn't prevent the build from working, but as Granrose stated in 76095, it 
affects performance (startup time at least) because of the large number of xpt 
files to load. It also affect smartupdate since the xpt file list will be 
completely different between 6.0x and 6.1. 
If this gets files later (after b1), then the smartupdate process will become 
even more complicated to handle all the different cases. (ssu can probably tell 
us more about this)

Let's fix 76095 and with some luck, this bug will automagically get fixed with 
it.
ccing greggl so he can get the appropriate smartupdate people involved if necessary.

*** This bug has been marked as a duplicate of 76095 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → DUPLICATE
Verified Duplicate
Status: RESOLVED → VERIFIED
verified with 2001-06-05-09-trunk builds. No more warnings during xptlink.pl

Will verify again with tomorrow's 0.9.1 BRANCH builds (kicked off at 3am before 
Samir's fix to 76095 went in).
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.