Closed Bug 182506 Opened 22 years ago Closed 22 years ago

MOZILLA_1_2_RELEASE is missing some checkins from MOZILLA_1_2_BRANCH

Categories

(SeaMonkey :: Build Config, defect)

Product:
SeaMonkey
Component:
Build Config
Version:
Other Branch
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: malcolm-bmo, Assigned: leaf)

References

Details

Attachments

(1 file)

cvs diff: 1.2 release against tip of 1.2 branch (SeaMonkeyAll only)
36.55 KB, text/plain
Details
Fixes for at least the following bugs were made into MOZILLA_1_2_BRANCH, but have 'disappeared' from MOZILLA_1_2_RELEASE. That is, these bugs were thought to have been fixed in 1.2, but the 1.2 release tag does not include the fixed versions, though the 1.2 branch tip does. Bug 178722: calling Array.sort() on an empty array returns undefined instead of an empty array [venkman fix only] Bug 124556: Crashing on random pages in 8-bit StaticGray class X11 server [nsImageGTK::DrawCompositedGeneral] [bug is critical, crash] Bug 180339: Can't send message if receiver contain Chinese character Bug 167663: [OS X]window disappears when clicking the maximize button (green +) [checkin similar to third attachment, but not identical] Bug 173195: Changes in the Mozilla/Netscape Installer to run Palm Conduit Installer Were the mozilla.org binaries made against MOZILLA_1_2_RELEASE?
Version: Trunk → Other Branch
All the changes between MOZILLA_1_2_RELEASE and the tip of MOZILLA_1_2_BRANCH.
More details (for that bug only) are available at bug 124556 comment 16 and later.
Interesting to note that none of the bugs mentioned appear on the "make Mozilla 1.2 not suck" bug dependency list http://bugzilla.mozilla.org/show_bug.cgi?id=174647 Bug #167663 was removed from the dependency list on 11/20. The others don't appear to have ever been on the dependency list.
Not all the checkins for 1.2final appeared on the '1.2 not suck' list. Bug 167663 was removed from the list because a more complete fix was expected on the trunk. See bug 167663 comment 108.
Apropos missing stuff: bug 182550 - Talkback is missing on 1.2 release, Linux (not explicitly mentioned in the diff)
For the record, I'd think this probably doesn't affect the release builds, since the (major-platform, anyway) release builds are done from the branch before the release is tagged (and then tested to see if they're working correctly before they're considered the release). (Or has someone tested that it does?)
I have pulled MOZILLA_1_2_BRANCH from CVS yesterday as I have documented at ftp://depot.mcom.com/pub/pioch/mozilla-1.2/ (README file) The source code obtained is in the tarball mozilla-1.2-branch.source.tar.bz2 at the URL above. recursive diff with the MOZILLA_1_2_RELEASE as posted on ftp.mozilla.org gives me about the same as attachment 107704 [details] on this bug I checked the source code manually; bug 124556 is correctly fixed, and bug 167493 is correctly backed out, i.e. the TagList starts with an "8" instead of a "9", cf attachment 98435 [details] [diff] [review] I've produced a build on Solaris8 (my 4th in 3 days I think :-) and the result is another mozilla-1.2.sparc-sun-solaris2.8.tar.bz2 posted above. This build passes basic QA for me :-) ie it doesn't crash due to patch for 124556 missing, and I cannot reproduce parser bugs due to bug 167493 tracked in bug 182500 for instance bug 182498 is fixed and attachment 107701 [details] displays the anchor/link correctly, as expected. Do we need anything else to ship this as 1.2.1 ?
I'd like to publically thank (or as publically as I can on bugzilla) those who worked hard to determine the problem with 1.2, and to endico and asa for the Official Mozilla statement on the problem and for pulling access to 1.2. This quick reaction is yet another example of customer service that one would never see from Microsoft and its IE product. And just think, MS staff are paid to provide service, while Mozilla people aren't (well, some are, but the vast majority aren't). Also nice to see all the compliments posted at Mozillazine.
dbaron points out that the user agent is getting revved on the 1.2 branch... so you might need to rebuild your solaris build. (also, the binaries are produced just before the tag is made... but it's possible the tree used for tagging was a few revisions behind). The 1.2.1 tag/source will not have this issue.
Assignee: seawood → leaf
Ok the original 1.2 release tag is fixed (not including the dbaron fix). Fixing source tarfiles now while we wait for 1.2.1 builds to test.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 182550 has been marked as a duplicate of this bug. ***
Urk, dont you people want to reconsider in future just changing tarballs ?
We'd like to get the tags, source tarfiles, and binaries to match up. The binaries had the code, there was no way to re-release those. Tag and source tar files have been fixed. updated tarfiles posted 2002/12/1
Just pulled MOZILLA_1_2_1_RELEASE from cvs -- tarball now available off ftp://depot.mcom.com/pub/pioch/mozilla-1.2.1/ Looks ok so far, only changes with the MOZILLA_1_2_BRANCH source tarball posted above are: -1.2 +1.2.1 -MOZILLA_VERSION='1.2' +MOZILLA_VERSION='1.2.1' -MOZILLA_VERSION='1.2' +MOZILLA_VERSION='1.2.1' - <string>0.9.7+, <C2><A9> 1998-2002 The Mozilla Organization</string> + <string>1.2.1, <C2><A9> 1998-2002 The Mozilla Organization</string> - <string>0.9.7+</string> + <string>1.2.1</string> - <string>1.2, <C2><A9> 1998-2002 The Mozilla Organization</string> + <string>1.2.1, <C2><A9> 1998-2002 The Mozilla Organization</string> - <string>1.2, <C2><A9>1998-2002 The Mozilla Organization</string> + <string>1.2.1, <C2><A9>1998-2002 The Mozilla Organization</string> - <string>1.2</string> + <string>1.2.1</string> - <string>1.2</string> + <string>1.2.1</string> -#define VERSION_MINOR 0x20 // revision & fi x in BCD +#define VERSION_MINOR 0x21 // revision & fi x in BCD -#define VERSION_STRING "1.2" +#define VERSION_STRING "1.2.1" -Version=1.2.0r.0 +Version=1.2.1r.0 - 0x20, + 0x21, - "1.2", // short version string - "Mozilla 1.2 Installer" // long version string + "1.2.1", // short version string + "Mozilla 1.2.1 Installer" // long version string Checking source code manually: bug 124556 is correctly fixed per attachment 106427 [details] [diff] [review], and bug 167493 is correctly backed out, i.e. the TagList starts with an "8" instead of a "9", per attachment 98435 [details] [diff] [review] ... Building now...
Followup on comment 14 above, doing QA the same way as comment 7: Build of MOZILLA_1_2_1_RELEASE doesn't crash due to patch for bug 124556 missing, and I cannot reproduce parser bugs due to bug 167493 tracked in bug 182500 for instance bug 182498 is fixed and attachment 107701 [details] displays the anchor/link correctly, as expected. However, my Solaris build displays in HELP | ABOUT: Mozilla 1.2 Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2) Gecko/20021203 In other words, the ABOUT section or User-Agent doesn't display the fact it's version 1.2.1 on Unix (unlike the Win32 version, which displays it correctly). Can anyone verify that other Unix builds have the same problem ? (Linux, anyone ?) In other words, what I built now on Solaris looks indistinguishible from the build of the tip of MOZILLA_1_2_BRANCH from comment 7 I'm fairly sure I didn't screwup mixing the sources: a quick glance at mozilla/configure states MOZILLA_VERSION='1.2.1'
Nicolas: I see the correct version number in about: - using the Linux .tar.gz package.
It has been a long day and I almost thought I was going nuts, and despite the fact that I cannot pull MOZILLA_1_2_1_RELEASE from CVS right now as cvs-mirror.mozilla.org is hosed -- it doesn't even respond to "cvs login"... I started mozilla on a non-existing profile, selected HELP | ABOUT then quit. Here are the generated contents of $HOME/.mozilla/default/xxx.slt/prefs.js : # Mozilla User Preferences // This is a generated file! user_pref("browser.startup.homepage_override.mstone", "rv:1.2"); user_pref("prefs.converted-to-utf8", true); user_pref("timebomb.first_launch_time", "1038948651011347"); I'd be curious to find out what the "override mstone" above is for :-) Also, every time I delete it and start mozilla, it gets added back... could that be the culprit for making a 1.2.1 version look like a 1.2 in the HELP | ABOUT MOZILLA page (and possibly, the User-Agent ?)
Nicolas: Do you still get the worng User Agent if you visit one or two different pages before going to "Help > About Mozilla"? This looks to get only set for the startup override homepage (The first page that is shown for a given profile with that version).
I'm also seeing rv:1.2 on the RedHat 8 xft-enabled RPM builds.
The RedHat 8 xft build has been contributed (not built by mozilla.org) like the Solaris build I am doing. Could it be that every contributed build, issued from a cvs checkout of the MOZILLA_1_2_1_RELEASE as per the official instructions, displays a rv:1.2, whereas the "official" mozilla.org builds display rv:1.2.1 for instance because they were not make according to the "official instructions" but the builds were made against the tip of the MOZILLA_1_2_BRANCH ?
PS: that would mean that MOZILLA_1_2_1_RELEASE is still missing some checkins from the MOZILLA_1_2_BRANCH !
Found it... the above is true, MOZILLA_1_2_1_RELEASE still doesn't correspond to the tip of MOZILLA_1_2_BRANCH and is missing some checkins, specifically attachment 107815 [details] [diff] [review] of bug 182812 is correctly checked in MOZILLA_1_2_BRANCH but partially into MOZILLA_1_2_1_RELEASE Details of what's different between MOZILLA_1_2_BRANCH and MOZILLA_1_2_1_RELEASE : --- MOZILLA_1_2_1_RELEASE/mozilla/modules/libpref/src/init/all.js Wed Nov 13 17:07:23 2002 +++ MOZILLA_1_2_BRANCH/mozilla/modules/libpref/src/init/all.js Sat Nov 30 11:59:48 2002 @@ -47,7 +47,7 @@ pref("keyword.enabled", false); pref("general.useragent.locale", "chrome://navigator/locale/navigator.properties"); pref("general.useragent.contentlocale", "chrome://navigator-region/locale/region.properties"); -pref("general.useragent.misc", "rv:1.2"); +pref("general.useragent.misc", "rv:1.2.1"); pref("general.startup.browser", true); pref("general.startup.mail", false); In other words, MOZILLA_1_2_1_RELEASE has pref("general.useragent.misc", "rv:1.2"); while MOZILLA_1_2_BRANCH has pref("general.useragent.misc", "rv:1.2.1"); So are the _RELEASE tags hopelessly hosed ? It looks like the only way for contributors to produce correct builds is once again to checkout via CVS the tip of the _BRANCH (which is what mozilla.org is doing, and that explains why only the official mozilla.org builds display the correct version, rv:1.2.1 !!!)
mozilla-source-1.2.1.tar.bz2 available at ftp://ftp.mozilla.org/pub/mozilla/releases/mozilla1.2.1/src/ contains the wrong User-Agent rv: and needs to be pulled. It matches MOZILLA_1_2_1_RELEASE/mozilla/modules/libpref/src/init/all.js with pref("general.useragent.misc", "rv:1.2"); (the "src" directory and contributed builds are the only things that were built against MOZILLA_1_2_1_RELEASE apparently)
The correct source code tarball of what should be MOZILLA_1_2_1_RELEASE is now posted at ftp://depot.mcom.com/pub/pioch/mozilla-1.2.1/ (file mozilla-1.2_BRANCH.src.tar.bz2) The included file mozilla/modules/libpref/src/init/all.js has the correct pref("general.useragent.misc", "rv:1.2.1");
Building this sources (my 7th build!) produces a Solaris8 distribution of Mozilla 1.2.1 that passes finally my stringent QA process (comment 15 above) Updated README and binary distribution posted on ftp://depot.mcom.com/pub/pioch/mozilla-1.2.1/ until Dawn pushes them on ftp.mozilla.org All contributed builds on ftp.mozilla.org and src/ distributions are currently invalid and will display rv:1.2.1 instead of rv:1.2 Hopefully this should be the end of this saga...
The above should read: ...and will display rv:1.2 instead of rv:1.2.1 Maybe people triaging bugs reported on rv:1.2 should be made aware that the User-Agent string is not reliable for this revision of the Mozilla client.
verified per final comments
Status: RESOLVED → VERIFIED
err... not really, if you read the last comments the MOZILLA_1_2_1_RELEASE tag was just missing the rv: patch to increase version to 1.2.1 and nobody ever confirmed this was fixed... is it?
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: