Closed Bug 233863 Opened 20 years ago Closed 16 years ago
Recommended patches for Mozilla on Solaris need updating
User-Agent: Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.6) Gecko/20040209 Firefox/0.8 I've noticed a problem when a compiled Mozilla 1.6 on Solaris can crash on Solaris machines even if they have the recommended Solaris patches in 'Installation Instructions for Mozilla Ports' page at http://www.mozilla.org/releases/mozilla1.6/installation-ports.html I am compiling Mozilla on Solaris 8 with the latest recommended patch cluster and the following addtional patches... 108434-14 108435-14 108773-18 109147-27 111697-04 111721-04 The machines the build crashes have at least the minimum patch revisions on the Mozilla web page but they don't seem to be enough. I have a suspicion that patch 111721-04 (Solaris 8) and 111722-04 (Solaris 9) for Math Library could be the culprit as they include support for new data types for which Solaris machines without that patch would'nt be able to support. I can't exactly say which patch is definitly causing the problem as when Mozilla started to crash for me i had it fully deployed in my department, and i updated the patch revisions for Solaris 8 and 9 to their latest versions and sent them out to all machines to stop people screaming at me I think the web page detailing the Solaris recommended patches will have to be updated and possibly the list of patches in the patch checker in Bug ID: 230598 which has just been checked into the 1.7 branch. This problem came up in the discussion for Bug ID: 230598 and Roland Mainz (email@example.com) asked if he could be assigned this bug as he is the person who did the list of recommended patches for Solaris and will look into this patch problem. Reproducible: Always Steps to Reproduce: 1. Compile Mozilla on Solaris machine with latest C++, linker and math libraries. 2. Try running Mozilla on a Solaris machine without those patches. 3. Actual Results: Mozilla began to crash frequently Expected Results: Mozilla should'nt crash
Assignee: nobody → roland.mainz
OS: SunOS → Solaris
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.7final
The patch updates the patch lists in the patch checker per user feedback and own investigations, adds support for Solaris/x86 and fixes a nit caused by the changes in the "pluggable shell script framework" API.
Attachment #144627 - Flags: review?(bsmedberg) → review?(leaf)
Comment on attachment 144627 [details] [diff] [review] Step 1 - update the patch checker (patch for 2004-03-24-trunk) a=mkaply
Attachment #144627 - Flags: approval1.7? → approval1.7+
Patch checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Hi Roland, I've tested those patches you have recommended on Solaris 8 & 9 for SPARC (i hav'nt had a Solaris 7 system for a long time) and Solaris 9 for X86. The patches you have recommended work with fine with Mozilla, Firefox, and Thunderbird. I've have asked my users to check as many of their applications as possible to see if the combinations of patches cause any unforseen problems with other applications. Thanks for the effort you have put in testing the combinations of patches, it must have been an awful job testing that many patches. Mick.
Reopening... step 2 is to update the WWW docs...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Will you find to update the WWW docs the time before 1.7 is released? Looks a lot more professional if they're in sync with the patch checker.
I'd like to complain about one thing. For SPARC/Solaris8, this patch requires 109704-03 (or later). My system only has 109704-02, so I get a complaint. However, patch 109704 is not freely available from Sun. Their web server lists it as only available to people with Sun Support contracts. I don't think we should warn people about problems they can't necessarily solve.
Chris P. Ross wrote: > I'd like to complain about one thing. For SPARC/Solaris8, this patch requires > 109704-03 (or later). My system only has 109704-02, so I get a complaint. > However, patch 109704 is not freely available from Sun. Their web server > lists it as only available to people with Sun Support contracts. > I don't think we should warn people about problems they can't necessarily > solve. Erm... http://sunsolve6.sun.com/search/document.do?assetkey=109704 is available for the public. Which problem do you have with that ?!
That is available to me, I agree. But, without that URL, it wasn't. If I go to www.sun.com, click "downloads" then click "patches & updates" then click "solaris[..]", then "Patch portal". I then enter "109704" (or "109704-03") into the patch number text-box, and click search, I get a page reporting that it's only available to people with contracts. What did you do to get to that URL in the first place?
The CVS log for revision 1.3 of moz_patch_checker.dtksh refers to bug 233683 instead of this one; i.e. two digits were flipped.
I'd like to complain about: "113902-03" [6_title]="SunOS 5.9: Asian UTF-8 iconv modules enhancement "114276-02" [7_title]="SunOS 5.9: Extended Arabic support in UTF-8" "114641-02" [8_title]="SunOS 5.9: Japanese iconv for UTF-8 patch" These seem to be patches to packages containing the Asian iconv modules for UTF-8, and Arabic fonts, none of which we use. The patch checker shouldn't ask for patches for language support when the underlying language support is not present or used.
firstname.lastname@example.org wrote: > The patch checker shouldn't ask for patches for language > support when the underlying language support is not present or used. The script really can't predict any future behaviour of the users. Really, we don't have a way to read tea leaves from within dtksh. The intention behind the patch checker was to avoid that people (which means: the "average" user in the _world_, not only within the US. This includes customers within the EU, Japan, Middle-East etc.) start filing bogus bugs because they hit (already fixed, incl. patches available) OS bugs (that goal has been reached, the number of bogus bug reports has dropped significantly :) ... we had enougth trouble with that in the past. If you don't want the patch checker then either hit simply "Continue" or take a look at http://lxr.mozilla.org/mozilla/source/xpfe/bootstrap/init.d/S02solaris_patchchecker.sh#19 - there is a way to turn this OFF via a "secret" way.
Ken Takusagawa wrote: > The CVS log for revision 1.3 of moz_patch_checker.dtksh refers > to bug 233683 instead of this one; i.e. two digits were flipped Ouch... sorry... ;-(
(In reply to comment #13) > The script really can't predict any future behaviour of the users. Really, we > don't have a way to read tea leaves from within dtksh. Sure, but if the packages aren't installed then the patches shouldn't be checked. You can't patchadd a patch for which none of the packages are installed. Ken, is that what you are concerned about?
Greg Onufer wrote: > (In reply to comment #13) > > The script really can't predict any future behaviour of the users. Really, > > we > > > don't have a way to read tea leaves from within dtksh. > > Sure, but if the packages aren't installed then the patches shouldn't be > checked. You can't patchadd a patch for which none of the packages are > installed. Erm, how do you think should this be solved ? The names of the packages to be patched are variable between the single patch _revisions_ - it would mean that I have to track all revisions of a patch and the packages patched by the specific patch revision. That will be a nightmare.
(In reply to comment #15) > You can't patchadd a patch for which none of the packages are installed. > > Ken, is that what you are concerned about? Yes.
moz_patch_checker.dtksh has been removed on the trunk by bug 380786. Since this bug was reopened (from FIXED) for reasons of the www docs not being in sync, and the www docs are now moot, I am restoring the state to FIXED. (The script still exists on the Mozilla 1.8 branch, but unless someone brings (new) resources to bear on a 1.8-only issue, there is no point in keeping this bug or its friends open. If you have resources to bring to bear, it is probably more appropriate to re-open one of the other bugs related to the script, or to log an entirely new one.)
Status: REOPENED → RESOLVED
Closed: 20 years ago → 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.