78471 - Land NSPR 4.1 (or higher) on NSPRPUB_CLIENT_BRANCH

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect, P1)

Description

[Brian Ryner (not reading)]

We need the PR_ConnectContinue feature of NSPR 4.1 in order to avoid the
following sequence of steps in PSM:

- Put socket in blocking mode
- PR_Connect()
- Restore socket to original nonblocking state

This is not guaranteed to work on all platforms.

Comment 1

[Jon Granrose]

do we normally update the NSPR tag or is that wtc and his crew?

Also, what's the blocking bug and when it is targetted?

Comment 2

[cls]

I don't believe the NSPRPUB_CLIENT_BRANCH has been updated (aside from porting &
build fixes) since it has landed.  I checked back and I couldn't find a base tag
to go with the branch tag so "updating" may involve just jumping to the 4.1
release wholesale.

I'm not sure if there's a general blocking bug for this but the beos/psm bug
(bug 70217) would be a nice start. :)

Comment 3

[Wan-Teh Chang]

NSPR 4.1 release branch does not have many of the porting
and build fixes, in particular autoconf, so you can't just
jump to the NSPR 4.1 release wholesale.

Rather than merging the porting and build fixes onto the
NSPR 4.1 release branch, I suggest that Mozilla switch
to pulling static tags off of the trunk of NSPR.  The
trunk of NSPR has all the porting and build fixes except
the latest autoconf changes.  So you just need to land
the latest NSPR autoconf stuff on the trunk of NSPR.  Then
Mozilla will effectively skip NSPR 4.1 and directly update
to what will become NSPR 4.2.

The current NSPR trunk does not have any new functions.
However, it does have a few bug fixes that are not critical
enough to warrant going into NSPR 4.1.

Comment 4

[Wan-Teh Chang]

OK, I have merged the autoconf build system and additional
platform ports from NSPRPUB_CLIENT_BRANCH onto the trunk
of NSPR.  I have a new cvs tag, NSPRPUB_CLIENT_TAG,
ready for testing with the Mozilla client.  Note that
NSPRPUB_CLIENT_TAG is a static tag, currently generated
off of the trunk of NSPR.

NSPRPUB_CLIENT_TAG is what I call NSPR 4.2 Beta.  I am
quite confident that it works on all the major Unix platforms
and Windows.  It should also work on Mac but I haven't tested
it.

Comment 5

[cls]

I've used the branch on linux & win32 without any immediately observable
side-effects.  Can we get someone to test the new tag on the mac?  

Also, the tag will have to be converted to a branch when the actual "landing"
occurs.  The name doesn't matter much to me, NSPRPUB_4_2_BETA_BRANCH or
NSPRPUB_<date>_CLIENT_BRANCH is fine as well. 

Comment 6

[Wan-Teh Chang]

Steve Dagley has tested the new tag on the Mac, both
debug and optimized.

Comment 7

[J.J. Enser]

mac trunk verification & tinderbox scripts currently pull using:

> mozilla/nsprpub,        NSPRPUB_CLIENT_BRANCH

If this needs to change, update that line in mozilla/build/mac/build_scripts/
MozillaCheckoutList.txt

Comment 8

[cls]

Reassigning bug to wtc.

Comment 9

[Pete Collins (MDG)]

Is this going to land in 0.9.2?

Thanks

--pete

Comment 10

[Wan-Teh Chang]

This is unlikely to happen in mozilla0.9.2.
I am now targeting 0.9.3.  Until then, the
NSPRPUB_CLIENT_TAG is ready for testing.

Comment 11

[Wan-Teh Chang]

I just asked the release engineering team to help
me provide experimental mozilla0.9.2 builds with the
new NSPRPUB_CLIENT_TAG.

Comment 12

[Wan-Teh Chang]

Bug #74603 can be trivially fixed if PR_APPEND works.
PR_APPEND was implemented for non-Unix platforms in
NSPR 4.1.  So the landing of NSPR 4.2 Beta would help
bug #74603.

Comment 13

[Wan-Teh Chang]

Mozilla and Netscape test builds with NSPR 4.2 Beta for
Linux, Mac, and Windows are available.  The FTP URLs for
the test builds can be found at
http://komodo.mozilla.org/planning/branches.cgi.

I would appreciate it if you could try the test builds on
your platform and post a success or problem report here.
If you run into a problem, please open a bug report and
make this bug depend on it.

sdagley tested the Mac Netscape test build and it worked
for him.

Comment 14

[Wan-Teh Chang]

I just tested the Mac Mozilla test build on my iMac and
it worked fine.  I visited several HTTP, HTTPS, and FTP
sites without problems.  I didn't test Mail & News.

Comment 15

[Steve Freeland]

    I'm running 2001-08-07-14-NSPR42test/mozilla-i686-pc-linux-gnu.tar.gz and
don't notice any different behaviour from any other recent build I've tried
(0.9.3 and a  trunk nightly from the same date).
    I ran the browser buster for about 15 top-100 sites, about a dozen of my own
sites (one https://), and a quick run through mail and Composer (although I
don't actually use those regularly) and everything seems fine.

Comment 16

[Wan-Teh Chang]

Here is a review/assessment of regression bug list.

1. Test builds work on Linux, Mac, Solaris, and Windows.
   - Steve Dagley, Javier Delgadillo, and I tested the
     Mac test build.
   - I tested the Windows test build.
   - Steve Freeland and I tested the Linux test build.
   - I tested the Solaris test build (compiled with gcc 2.95.2).

2. The only problem is bug #94508, a build system problem.
   However, that problem only affects people who pass
   --cache-file=/dev/null to the toplevel configure on
   platforms with both gcc and OS vendor's compilers (for
   example, Solaris, HP-UX, AIX, and Tru64 Unix).  Few
   people specify the --cache-file=/dev/null configure option.
   Moreover, this problem has a simple workaround -- explicitly
   specify CC and CXX in the environment for the toplevel
   configure.  For example, in C shell you would say:
       env CC=gcc CXX=c++ ./configure <configure options...>
   Therefore, this minor build system problem should not block
   the NSPR 4.2 Beta landing.

I have met all the landing requirements and am ready to land.

Comment 17

[Wan-Teh Chang]

I did the deed today.  The tree did not open until 6PM.

To make sure that we learned something from today's NSPR
landing, I summarized the mistakes we made below.

1. Static tags can't be combined with date tags.

2. We should not simply nuke mozilla/nsprpub in an existing
   mozilla tree.  We should either nuke the whole mozilla
   tree or let client.mk update mozilla/nsprpub with the new
   tag.

   This is because a newly checked-out copy of
   mozilla/nsprpub/configure will have a time stamp equal
   to the time of the last cvs commit, which will be older
   than the toplevel config.status and will fool client.mk
   into thinking that it does not need to re-run the toplevel
   configure.  On the other hand, if an existing copy of
   mozilla/nsprpub/configure is cvs updated, it will have
   a time stamp equal to the current time.

   Note that this problem will bite us whether the new NSPR
   tag is a static tag or a branch tag.  So we still need
   to watch out for this problem when we update to a new NSPR
   branch tag in the future.

Are these correct?  Is there anything else we should watch out
for in the future?

Comment 18

[Jon Granrose]

verified.