Land NSPR 4.1 (or higher) on NSPRPUB_CLIENT_BRANCH

VERIFIED FIXED in mozilla0.9.4


18 years ago
14 years ago


(Reporter: bryner, Assigned: wtc)


(Blocks: 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




18 years ago
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

18 years ago
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?
Priority: -- → P3
Target Milestone: --- → mozilla0.9.2

Comment 2

18 years ago
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

18 years ago
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

18 years ago
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

Comment 5

18 years ago
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

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

Comment 7

18 years ago
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/

Comment 8

18 years ago
Reassigning bug to wtc.
Assignee: cls → wtc

Comment 9

18 years ago
Is this going to land in 0.9.2?




Comment 10

18 years ago
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.
Priority: P3 → P1
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 11

18 years ago
I just asked the release engineering team to help
me provide experimental mozilla0.9.2 builds with the


18 years ago
Blocks: 88341


18 years ago
Blocks: 70213


18 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4


18 years ago
Blocks: 84219

Comment 12

18 years ago
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.


18 years ago
Blocks: 74603

Comment 13

18 years ago
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

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

18 years ago
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

18 years ago
    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

18 years ago
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

18 years ago
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 update mozilla/nsprpub with the new

   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
   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?
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 18

18 years ago
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.