Closed Bug 224340 Opened 22 years ago Closed 22 years ago

v1.6a is missing PSM module: SSL protocols like HttpS, Pop3/Ssl, ... are unavailable

Categories

(SeaMonkey :: Build Config, defect)

Product:
SeaMonkey
Component:
Build Config
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: hhschwab, Assigned: leaf)

References

(
URL
)

Details

(Keywords: regression)

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031030 Build ID: 2003103019 Using Mozilla Mailclient, I can´t access my account at myrealbox.com Same account accessed via browser gives an Alert: you must install PSM ... Same with another account accesses with an https:\\ URL, I get the alert before anything is loaded. reproducable: always Did a clean install, after download installed into a new directory, created a new profile, didn´t config at all, or load extensions, surfed a bit, ok. Then I switched to my default profile and tried to access my webmail, got the alert. Closed 1.6a release, started 1.6a trunk with same default profile, and could access my mail. Closed 1.6a trunk, started 1.6a release with its own new untouched profile, tried to access my webmail by pasting the https: URL into the location bar, and got same alert. When I started the mail client, I got the message I´m currently offline, though DUN was up, and I was asked to allow going online. I accepted, and could access my POP3-account (non-secure). My secure IMAP-account was spinning, I aborted about a minute later, didn´t want to wait for an alert. Install log didn´t differ between Trunk and Release, on a quick view. At least I didn´t see a message about corrupt or missing files. Didn´t compare 1:1 if all files were mentioned in both logs. Raising severity to critical, as this is a release, and maybe couldbe fixed, as the lacking of https: makes the thing unusable.
You don't need to write books as comment :-) The PSM installed warning from Necko and missing SSL Tabs in the preferences is enough information to be sure that that PSM is missing. I can confirm this on win2k and this file : http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6a/mozilla-win32-1.6a-installer.exe
Severity: critical → blocker
1.5b configure switches (about:buildconfig): --without-system-jpg --without-system-zlib --with-extensions=all --enable-optimize --disable-debug --disable-tests --enable-crypto 1.6a : --disable-debug --enable-optimize --disable-tests
1.5 configure arguments agree with the 1.5b arguments.
This error appears to occur on submission to an encrypted (https) page. An alert appears informing you of the missing PSM module and instructing you to reinstall it. My installation was on Windows XP.
*** Bug 224386 has been marked as a duplicate of this bug. ***
Time to "remove" the v1.6a ! Then release a v1.6a.1 ? At least, add a warning on the v1.6a release note !! [Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031025] (nightly) (W98SE) If I remember well, this bug did not yet exist in v20031025(04)... (The change may have happened along the one causing bug 224370 !?) [Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007] (W98SE) Works fine, confirming comment 3: (K) regression.
Flags: blocking1.6b?
Keywords: regression
Summary: Mozilla 1.6a is missing PSM module, can´t access my mail via HTTPS → v1.6a is missing PSM module: SSL protocols like HttpS, Pop3/Ssl, ... are unavailable
no need for another point release, since the source hasn't changed. I've done a respin and staged bits, using the configuration options that were used for 1.5. The bits are starting to hit ftp... if someone with an existing 1.6a install can test installing the bits from today (november 1), to see if mozilla's installer will even perform another installation over the top. If not, i'm sure uninstalling and reinstalling will work. (too bad crypto doesn't have its own xpi anymore!)
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 224372 has been marked as a duplicate of this bug. ***
Flags: blocking1.6b?
The new build has been apperently build without BUILD_OFFICIAL flag and therefore shows Build ID: 0000000000. However this time it has the PSM. I wonder about this total screw-up: Why weren't any nightly builds available on October 29 and 30? The latter should be used as the release after testing it for a day or two. Was this because of the ugly license scattered with with black rectangles that was added in the last minute? A real shame for us all :-(
*** Bug 224402 has been marked as a duplicate of this bug. ***
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031030] (BuildId=0...0, bug 224340#c9) (W98SE) Re comment 7: New build works fine after uninstal+reinstal. (I did not try the "over-instal".) Re comment 9: License format issue: see bug 224370. (No explanation so far on how theses two bugs came in...)
the source may not have changed, but most mozilla users don't care about that - what they see changing is the build, and that has changed. By now a bunch of people have downloaded 1.6a, found it's broken, and gone back to 1.5. If we want them to test 1.6a, we need to tell them that the version on the FTP now isn't the broken one they already tried. Are we just living with the lack of buildID?
Delivering as soon as possible a new build with PSM included was very good :-) Resolving the bug without in-depth explanation seems premature :-( "At least, add a warning on the v1.6a release note !!" stands in all cases... (<http://www.mozilla.org/releases/mozilla1.6a/README.html>)
Full explanation: we're still working through transition issues. Builds used to be produced by a set of machines running very old and well-tested automation on the netscape campus. New automation is being written to produce builds now, and the 1.6a release coincided with a failure of a legacy system, so the first 1.6a windows builds were produced in an ad-hoc fashion, which resulted in some missed configuration options (human error). The lack of buildid in the new bits is also due to human error, in that my haste to produce builds with PSM led me to forget to set an environment variable to produce official builds. As far as i know, the lack of buildid is the only effect of this. I don't have time to produce another set of builds with the OFFICIAL bit set, as i am going offline until thursday of next week. I'm not sure what the best way to announce "bits with psm", but updating a revision number for a build machine configuration issue is not appropriate. An announcement on the releases page or news item might work. I don't have time at the present to produce a well worded announcement. If anyone would like to add criticism to the bug, feel free to do so, and i will read it and respond where appropriate thursday. One thing for sure, though, Beta will not have any of these issues.
Leaf: I want to say "Thank you" for your Mozilla work and also for the fast fix ! A build without PSM is bad but you fixed that very fast. The missing build ID is trivial and doesn't affect anything except the Build ID in the title. Continue your great work and we will be all happy !
Leaf - thanks very much for the explanation and also for the prompt respin (on a Saturday too). A note somewhere on the releases page or something would be fine, and I don't think the missing buildID is a significant problem - this is an alpha, after all.
Status: RESOLVED → VERIFIED
I think i can squeeze in an "official" build before i have to leave. I'll get a note on the release notes and a brief news item.
New official build is staged (i believe that the license.txt file is correctly line-ended now as well). I will post a small news item and send mail to npm.builds. Sorry for the invonvenience.
The new (2003110115) build has the build ID number back (and thanks to that it can be called by it, obviously). The license bug is solved too. You can install the 2003110115 (third try) directly over the 0000000000 (second try) build with even GRE being replaced thanks to the different build IDs. I cannot check how it upgrades from the first try build as I already deleted it. Thanks for fixing the problems during the weekend!
*** Bug 224512 has been marked as a duplicate of this bug. ***
Just for test I installed BuildID 2003110115 right on top of first release Build ID: 2003103019 and had no problems, still using it. But seeing now, it gives the wrong UA: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031030
Re comment 21: In fact, the UA did not change between the 3 builds ("same sources"): only the BuildId ("new binaries"). Your test is 100% successful :-)
just deinstalled and reinstalled into a fresh directory, also deleted zonealarm entries. ZA asked me to allow Mozilla 2003103019 as server, and the about: page shows Build ID 2003110115 in the title bar, and Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031030 in the content. That makes it difficult to decide which build is in use, have a look at bug 224589 Browser crashes when logging on to secure web page via pop-up dialog
Re comment 23: As I understand it: "Gecko/20031030" is the date of the Gecko engine only (which was included in/with this Mozilla build)... "rv:1.6a" is the only information about which Mozilla "milestone" (not build) it is... (no BuildId in the User-Agent string.) "Build ID 2003110115" is the true information to identify a build. Now, here is what is odd about the third v1.6a build: *mozilla.exe identifies itself as "1.6a: 2003103019", as ZA reports, where we would(!) expect "2003110115". *the Gecko directory is named "GRE\1.6a_2003110115" where we might(?) expect "20031030xx". That said, I believe that you were very right to report it, in case there is something to fix there for the future; and that, for the v1.6a release, we'll now live with it: unlike the BID=0...0 of the second build which was kind of a "blocker".
Additional Re comment 23: (for the record) Bug 224589 is unrelated to the current one. While looking at it, I wondered about bug 222849 comment 13, "Build ID 2003110115 (no Talkback packaged)", but that's bug 218898, unrelated to this one too.
Re: Comment 24 "Gecko/20031030" is the date of the Gecko engine only (which was included in/with this Mozilla build)..." No, it is simply the date you put in a file (namely mozilla/layout/build/gbdate.h) which you want the UA string to show...
*** Bug 224745 has been marked as a duplicate of this bug. ***
*** Bug 224776 has been marked as a duplicate of this bug. ***
Re comment 26: See bug 150351 comment 17: {(<http://mozilla.org/build/revised-user-agent-strings.html>) GeckoVersion: [...] For official Mozilla builds, this will correspond to the date portion of the BuildID. [...] } You're right: actually, since the third build is an official one (as the second was for that matter), it should have had the "20031101" date too.
The problem (or is it a feature?) is that if gbdate.h exists, the script gbdate.pl will not update it. Therefore it is important to remember to delete it before an official build is done.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.