Assuming N6PR3's installer is open source (I install Mozilla Linux nighlies from tarballs). If I ran the graphical installer as user, and told it to install in /usr/local/packages/netscape-n6pr3, it died shortly after unpacking the xpis (IIRC, after libplc4.so or somthing). /usr/local is drwxr-xr-x 0:0, but /usr/local/packages is 0:0 and symlink to /mnt/packages, which is drwxr-xr-x and owned by the installing user. netscape-n6pr3 has the same permissions. Dunno, if it's the smylink or the permissions causing the trouble. If the former, please removing it from meta bug 42184.

reassigning to Samir.

How rampant would this be if the symlink was the issue? Trying to guage whther we should invesitigate this now or work on it for the next release.

sgehani, symlinks in the install path are *very* common.

OK, I'll take your word on this. This warrants expedient investigation. Grace, Can you help by isolating whether the issue is higher dirs not being writable (I highly doubt) or whether having a symlink in the path is the issue? If both work exclusively then try the combination to see if that is the unique situation in which this crash occurs. Thanks. Ben, Would it be possible for you to attach a stack trace of the crash if the installer dumped a core. If it didn't and if you have a debug build swap in the debug mozilla-installer-bin in your optimized installer folder with the one from your mozilla/xpinstall/wizard/unix/src2 directory and run in gdb. Thanks for any help.

I forgot to notice: Installing in /tmp/inst/ worked fine. /tmp is a smylink, owned by 0:0. The target, /mnt/tmp/tmp/, was drwxrwxrwt, owned by myuser. /mnt/tmp/ is drwxr-xr-x, owned by 0:0. /tmp/inst/ was drwxr-xr-x, owned by myuser. So, it is *not* just the symlink. Adjusting SUMMARY. Samir, the installer didn't dump a core, and I don't have a debug build (unless mozilla.org distributes DEBUG binaries - my own build is non-debug).

CC'ing David since I vaguely recollect him mentioning some such behavior. Since it's not the symlink problem I'm not too worried.

Grace, Can you try and reproduce the higer dirs not having write perms problem? Since I seem to be hearing that the symlink factor is not what is causing this bug we need not investigate/try to reproduce that aspect. Thanks.

I cannot reproduce this using directory structure similar to one noted (no symlink) t1/t2/t3 with t1 and t3 having 755 permissions and t2 having 555. I successfully install into t3. I am not familiar with the 0:0 notation- so I maybe missing something. Is this the same as bug 46558?

gbush, 0:0 is short for root:root, i.e. owned by root, group root. IIRC, I've seen bug 46558 before, but it mentions no crash.

Moz 0.9 tasks

Using the initially posted setup I could not reproduce this bug.

I saw pretty wierd crashes GTK and stuff when I ran the Mozilla Linux stub installer recently. Maybe I used mozilla-installer-bin, not mozilla-installer? I fail with a download error, when using the latter. When setting ftp_proxy and FTP_PROXY, it just exists before downloading. Different bug? Guess so. Anyway, cannot verify or reject closure.

We don't support proxies yet in the linux installer. Once we do we'll expose the settings in the UI. Very soon. Could you try verifying using the "blob" instead of the "stub" installer? The blob is the one that has the "sea" suffix in place of the "installer" suffix in the name. For example: <ftp://ftp.mozilla.org/pub/mozilla/nightly/2001-03-14-08-Mtrunk/mozilla-i686-pc-linux-gnu-sea.tar.gz> The blob contains all the zippies (.xpis) already so it doesn't try to download. Thanks for your time. Grace, Please verify when you have time. Thanks.

Yes, it works now. VRFY.