142107 - Installer fails

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P1)

Description

[Tracy Walker [:tracy]]

seen with today's linux branch builds.

-attempt to install the build

it fails after a series of -621 errors.

leaf tells me sean su is looking into it. I assigned it to him.

Comment 1

[Grace Bush]

a few duplicates in bugscape

Comment 2

[Tracy Walker [:tracy]]

this happens to mozilla too.  

Comment 3

[Myk Melez [:myk] [@mykmelez]]

Attachment: screen shot

Here's what it looks like when it fails for me.  When I tell the installer to
install into a specific directory, it installs a series of files with
consecutive integers appended to the name of the directory in which I wanted
the files to be installed.  In other words, if I specify that mozilla should be
installed in the directory "/home/myk/foo/bar" I get the following files:

/home/myk/foo/bar-1
/home/myk/foo/bar-2
etc.

This goes up to about 323 before it craps out with the error message in the
screen shot.

Comment 4

[Sean Su]

reassigning to Samir since he's taking a look at it right now ;).  Thanks Samir.

Comment 5

[Samir Gehani]

Can't repro in the browser (successfully installed inspector.xpi) which means we
are probably trying to exercise code from  a dll that is not packaged in
xpcom.xpi.  Next step is to investigate using a debug installer.

Comment 6

[Samir Gehani]

Attachment: Move libuconv.so to xpcom.xpi since we now need it at install-time.

Comment 7

[Samir Gehani]

ssu, please r.
alecf, please sr.

Comment 8

[Sean Su]

Comment on attachment 82348 [details] [diff] [review]
Move libuconv.so to xpcom.xpi since we now need it at install-time.

r=ssu

Comment 9

[Daniel Veditz [:dveditz]]

libuconv?! It was alecf's removal of the uconv depndency in bug 
100676 that caused bug 125106 in the first place!

Comment 10

[Daniel Veditz [:dveditz]]

Comment on attachment 82348 [details] [diff] [review]
Move libuconv.so to xpcom.xpi since we now need it at install-time.

sr=dveditz

Comment 11

[Jaime Rodriguez, Jr.]

i am confused. wasn' the linux install issue resolved by the backout of bug
125106, by leaf?

Comment 12

[Alec Flett]

Wow, yeah this seems really lame. I mean, xpi packaging is really beyond the
scope of my modularity work, but it seems pretty lame that we need uconv here.

Comment 13

[Samir Gehani]

Regarding comment 11: yes, the linux install issue is resolved for now.  But
when we land the patch for bug 125106 again then we should land this patch as well.

Regarding comment 13: I'll try to debug XPInstall more to find the offending
code to hopefully truly break the dependency on uconv.  Failing teh arrival of
such a patch in a ``timely'' manner, we can ship beta with the current patch
(attachment 82348 [details] [diff] [review]).

Comment 14

[Asa Dotzler [:asa]]

Comment on attachment 82348 [details] [diff] [review]
Move libuconv.so to xpcom.xpi since we now need it at install-time.

a=asa (on behalf of drivers) for checkin to the 1.0 branch.

Comment 15

[Samir Gehani]

Attachment: Better patch that truly breaks the dependency on uconv.

Comment 16

[Samir Gehani]

Attachment: Same as last patch but with fixed comments.

Comment 17

[Syd Logan]

Is the failure return the only effect of the uncov lib not being there? And what
possible areas would break based on handling the error in the way you do? We can
be pretty sure that by making uconv available to the linux installer we will
work without regressions (even if the installer size is 3x, I prefer no
regressions).

Comment 18

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on ADT's behalf) approval for checkin to the 1.0 brnach. Pls check
this in asap, then add the fixed1.0.0 keyword.

Comment 19

[Samir Gehani]

Syd,
Regarding comment 17 I agree we should take my first patch (attachment 82348 [details] [diff] [review])
for beta (and maybe even for RTM).  After I check my patch into the branch Dan
(or install folks deemed appropriate) can run with the newer patch I have
attached.  I think we haven't covered all our bases cause I found other
AppendUnicode() calls whose rv was not being checked.  Both patches fix the
linux installer problem though and install ``working'' builds.

Comment 20

[Alec Flett]

Comment on attachment 82514 [details] [diff] [review]
Same as last patch but with fixed comments.

interesting approach, but be forwarned this will probably change in some way
once darin lands his nsIFile/utf8 patch... that doesn't land until later
though. 

Come to think of it, I'm not sure this will actually fix the problem on
non-ASCII systems though. "Lossy" is the key word - dan has switched the
installer over to using native paths where appropriate, and I think all you're
doing here is munging the native path into some ugly ascii string.

I actually think that darin's UTF8/nsIFile patch may fix THIS bug, when it does
finally land on the branch.

Comment 21

[Samir Gehani]

Alec,
I was porting Dan's approach (see nsInstallFolder.cpp rev 1.197.2.2) from
nsInstallFolder.cpp to nsInstallFile.cpp.  Since we are checking in the first
patch we can leave this to Dan post-beta when hopefully Darin's checkin fixes this.

Comment 22

[Doug Turner (:dougt)]

I landed 82348 on the BRANCH.

Comment 23

[Jaime Rodriguez, Jr.]

Marking as fixed1.0.0, since Dougt landed attachment 82348 [details] [diff] [review] on the branch.

Comment 24

[Peter Trudelle]

Shouldn't this be resolved as fixed, since it was apparently only a problem on
the branch?

Comment 25

[Samir Gehani]

Thanks Doug!

Comment 26

[Tracy Walker [:tracy]]

verified fixed with linux commercial build 2002-05-07-08-1.0.0

Comment 27

[Grace Bush]

adding verified1.0.0 keyword ( tested on branch too)