Closed
Bug 143132
Opened 22 years ago
Closed 22 years ago
Installation failed when installing under some locales on RH Linux
Categories
(Core :: Internationalization, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: ruixu, Assigned: shanjian)
References
Details
(Keywords: intl, Whiteboard: [m5+])
Attachments
(1 file, 2 obsolete files)
4.39 KB,
patch
|
shanjian
:
review+
mscott
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
Build: 2002-05-08-10-1.0.0 OS: JA RH 7.1 and RH 7.2 This is separated for bug 142850. When installing under locale ja_JP.SJIS and zh_TW.Big5 on JA RH 7.1 and RH 7.2, got the following error and the installation failed. Warning: MOZILLA_FIVE_HOME not set. ./netscape-installer: line 45: 1583 segmentation fault. ./netscape-installer-bin $@
Summary: Installation failed when installing under some locales → Installation failed when installing under some locales on RH Linux
Assignee | ||
Comment 1•22 years ago
|
||
On RH7.2, nl_langinfo(CODESET) returns ANSI_X3.4-1968, which is an alias of us-ascii. I believe this cause the problem, but don't know why yet. We should handle such situation gracefully.
Assignee | ||
Comment 3•22 years ago
|
||
The problem is because we add the dependency on libuconv to do some charset conversion. Part of the code is try to identify platform charset, which need to search some property file. This function relys on necko module. I don't know at this point why nsURLProperties::nsURLProperties could not return gracefully. I guess it might not be a good option to add necko and probably some other modules to xpcom.xpi. We don't know if that will end there. I am suggesting 2 options here: 1, Set LANG in mozilla-installer to be en_US, and set it back when script exit. We will have problem in localized installation. This not a good option. 2, Remove the dependency on libuconv. It seems that we only do the conversion for path, and it is not really necessary to be able to handle native character in path. If we allow user use native path, they will have problem accessing it in other locale. People rarely do that and this is an acceptable option. I am working on a patch use option 2.
Assignee | ||
Comment 4•22 years ago
|
||
This patch removed the dependency on libuconv for unix.
Comment 5•22 years ago
|
||
Can we get r=/sr= on this?
Assignee | ||
Comment 6•22 years ago
|
||
Almost same as above, add some comment and remove warning for unix. It also move those conversion routine back to browser xpi, since we don't need it in xpcom.xpi anymore.
Attachment #82884 -
Attachment is obsolete: true
Assignee | ||
Comment 7•22 years ago
|
||
Being greedy, I move the other conversion related file to browser.xpi. This patch is final, I don't see any more improvement possible.
Assignee | ||
Updated•22 years ago
|
Attachment #82890 -
Attachment is obsolete: true
Ok, so, my question is this. We have seen random flakiness on Linux en-US systems, some people install OK, others crash. It implies someone is not respecting a failure code or checking a NULL pointer or something like that. This dependency breaking might be more easily triggering on some people's Linux machines, but is there a chance that by not breaking the dependency on Mac and Windows that we will cause some number of people to run into the crash on those platforms too? Or is there something specific about this code that requires we only need to break the dependency for Linux.
Assignee | ||
Comment 9•22 years ago
|
||
I will try to answer your question. On windows ( and probably mac), the character query and conversion is performed using system API. Since unix does not have this kind of unicode support buildin, we have to use our own implementation. Our unicode conversion module has dependency on something else, necko for example. It is a problem not be able to handle it gracefully when necko module is not there, and that's something we need to find out in future. But to add necko to xpcom.xpi sounds like a risky option, since necko may have dependency on something else and I certainly do want to see another stopper bug. When do we need the conversion? For file/foler path. As what I said in comment #3, that is not really necessary. So the dependency on unicode conversion can be removed.
Status: NEW → ASSIGNED
Assignee | ||
Comment 10•22 years ago
|
||
I just called syd over the phone, and explained the code to him. He gave r=syd.
Assignee | ||
Updated•22 years ago
|
Attachment #82891 -
Flags: review+
Updated•22 years ago
|
Whiteboard: [adt1] [ETA 05/09]
Updated•22 years ago
|
Attachment #82891 -
Flags: superreview+
Comment 11•22 years ago
|
||
Comment on attachment 82891 [details] [diff] [review] final patch sr=mscott
Comment 12•22 years ago
|
||
adding adt1.0.0+. Please check this into the branch after getting drivers approval.
Keywords: adt1.0.0+
Whiteboard: [adt1] [ETA 05/09] → [m5+]
Comment 13•22 years ago
|
||
Comment on attachment 82891 [details] [diff] [review] final patch a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #82891 -
Flags: approval+
Assignee | ||
Comment 14•22 years ago
|
||
fix checked in to branch.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 15•22 years ago
|
||
marking as fixed1.0.0, since shanjian says fix was checked into the branch.
Keywords: fixed1.0.0
Comment 16•22 years ago
|
||
Shanjian, could you make sure this gets testing on japanese rh system tomorrow so we can make sure there is no problem? Thank you.
Reporter | ||
Comment 17•22 years ago
|
||
I will test it on Japanese RH 7.1 and RH 7.2 with supported locales, and will spot check with some non-supported locales.
Comment 18•22 years ago
|
||
*** Bug 143160 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 19•22 years ago
|
||
I tried to install under the following locales so far, it is not reproducible with 1.0 branch build 2002-05-09 on JA RH Linux 7.1. ja_JP.eucJP zh_CN.GB2312 ko_KR.euckr korean.euc ja_JP.SJIS zh_TW.Big5 ja_JP C en en_US I will try the rest areas on RH 7.2.
Comment 20•22 years ago
|
||
file bug 143283 for uconv depend on necko issue. not a short term need. but file as a long term issue.
Reporter | ||
Comment 21•22 years ago
|
||
Tested the following rest areas, this bug is not reproducible with 1.0 branch build 2002-05-09. 1. On JA RH Linux 7.1: ja_JP.eucJPutf8, japanese, japanese.euc, japanese.sjis zh_CN, zh_CN.gbk, zh_CN.gb18030, zh_CN.utf8 zh_TW, zh_TW.euctw, zh_TW.utf8, zh_HK, zh_HK.utf8 ko_KR, ko_KR.utf8, korean 2. On RH Linux 7.2: ja_JP, ja_JP.eucJP, ja_JP.eucJPutf8, ja_JP.SJIS, japanese, japanese.euc, japanese.sjis zh_CN, zh_CN.GB2312, zh_CN.gbk, zh_CN.utf8 zh_TW, zh_TW.Big5, zh_TW.euctw, zh_HK, zh_HK.utf8 ko_KR, ko_KR.euckr, ko_KR.utf8, korean, korean.euc C, en, en_US, en_HK
Keywords: fixed1.0.0 → verified1.0.0
You need to log in
before you can comment on or make changes to this bug.
Description
•