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.
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
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. :)
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.
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.
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.
Steve Dagley has tested the new tag on the Mac, both debug and optimized.
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
Reassigning bug to wtc.
Assignee: cls → wtc
Is this going to land in 0.9.2? Thanks --pete
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.
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: mozilla0.9.2 → mozilla0.9.3
I just asked the release engineering team to help me provide experimental mozilla0.9.2 builds with the new NSPRPUB_CLIENT_TAG.
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.
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.
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.
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.
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.
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?
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.