Closed
Bug 158683
Opened 22 years ago
Closed 22 years ago
NSS libraries don't conform to Solaris versioning conventions
Categories
(NSS :: Libraries, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: kirk.erickson, Assigned: kirk.erickson)
Details
Attachments
(10 files, 3 obsolete files)
752 bytes,
patch
|
Details | Diff | Splinter Review | |
20.00 KB,
application/octet-stream
|
Details | |
2.41 KB,
patch
|
Details | Diff | Splinter Review | |
3.98 KB,
patch
|
wtc
:
review+
|
Details | Diff | Splinter Review |
1.94 KB,
patch
|
Details | Diff | Splinter Review | |
20.00 KB,
application/octet-stream
|
Details | |
986 bytes,
patch
|
Details | Diff | Splinter Review | |
4.79 KB,
patch
|
Details | Diff | Splinter Review | |
642 bytes,
patch
|
Details | Diff | Splinter Review | |
2.89 KB,
patch
|
Details | Diff | Splinter Review |
Directory Server was bundled in Solaris 9 with NSS library.
To avoid a mess on Solaris, NSS needs to adapt to the Library
Versioning conventions of Solaris. Application Server will
needs to be bundled within a couple months, and utilizes a
different version (NSS 3.3.2 and NSPR 4.1.2).
To comply we need to define what functions are public, and
define interfaces, and use library names that reflect the
major version (ex. libnss.so.3).
NSS is already following the conventions in terms of creating
a map files by massaging a list of public function lists:
./mozilla/security/nss/lib/nss/nss.def
./mozilla/security/nss/lib/smime/smime.def
./mozilla/security/nss/lib/softoken/softokn.def
./mozilla/security/nss/lib/ssl/ssl.def
which are massaged by a script in coreconf by way of Makefiles.
For example, mozilla/security/nss/lib/nss/Makefile:
grep -v ';-' nss.def | sed -e 's,;+,,' -e 's; DATA ;;' -e 's,;;,,' -e 's,;.*,;,'
> SunOS5.8_OPT.OBJ/nss.def
which is used in the link:
ld -G -h libnss3.so -M SunOS5.8_OPT.OBJ/nss.def ...
Sun has evolved to using higher level "spec" files that house additional
information, including function prototypes. But the map files should
suffice.
The work to resolve this bug then boils down to the library naming
convention. Wan-Teh proposed shifting from
libnss3.so
to
libnss.so.3
and pointed to mozilla/security/coreconf/ruleset.mk as the best
place to change the name:
Index: ruleset.mk
===================================================================
RCS file: /cvsroot/mozilla/security/coreconf/ruleset.mk,v
retrieving revision 1.15
diff -u -r1.15 ruleset.mk
--- ruleset.mk 21 Feb 2002 21:23:14 -0000 1.15
+++ ruleset.mk 22 Jul 2002 17:13:37 -0000
@@ -117,7 +117,7 @@
LIBRARY = $(OBJDIR)/$(LIB_PREFIX)$(LIBRARY_NAME).$(LIB_SUFFIX)
endif
ifndef SHARED_LIBRARY
- SHARED_LIBRARY =
$(OBJDIR)/$(DLL_PREFIX)$(LIBRARY_NAME)$(LIBRARY_VERSION)$(JDK_DEBUG_SUFFIX).$(DLL_SUFFIX)
+ SHARED_LIBRARY =
$(OBJDIR)/$(DLL_PREFIX)$(LIBRARY_NAME)$(JDK_DEBUG_SUFFIX).$(DLL_SUFFIX).$(LIBRARY_VERSION)
endif
endif
This would be the best from my perspective too, but its pervasive and
we need to inform those effected and deal with the ripples it creates.
Its pervasive since the change is not specific to Solaris, but effects
all platforms.
We could create a link as part of the build so existing linker
command lines with -lnss3 still work:
libnss3.so -> libnss.so.3
As part of the packaging step, an additional link is created
to select the version to engage after installation:
libnss.so -> libnss.so.3
I plan to follow Wan-Teh suggestion. The remaining issue is that
OpenSSL is distributed with Solaris too, and libssl.so is taken.
Its also clear that libsmime.so is likely popular.
In view of Sun's convention to invent a new name when upward
binary compatibility is broken, I propose we simplify life
and use the "3" as we have.
libnss3.so -> libnss3.so.3
would be like saying our name is not nss, but nss3.
When Stan is introduced, the name would change to nss4 and
so forth. Following the same convention with the subordinate
libs means we won't conflict with the existing libssl.so:
libssl3.so -> libssl3.so.3
libsmime3.so -> libsmime3.so.3
libsoftoken3.so -> libsoftoken3.so.3
libfreebl3.so -> libfreebl3.so
So my proposal is to apply the following patch:
Index: ruleset.mk
===================================================================
RCS file: /cvsroot/mozilla/security/coreconf/ruleset.mk,v
retrieving revision 1.15
diff -u -r1.15 ruleset.mk
--- ruleset.mk 21 Feb 2002 21:23:14 -0000 1.15
+++ ruleset.mk 22 Jul 2002 17:30:03 -0000
@@ -117,7 +117,7 @@
LIBRARY = $(OBJDIR)/$(LIB_PREFIX)$(LIBRARY_NAME).$(LIB_SUFFIX)
endif
ifndef SHARED_LIBRARY
- SHARED_LIBRARY =
$(OBJDIR)/$(DLL_PREFIX)$(LIBRARY_NAME)$(LIBRARY_VERSION)$(JDK_DEBUG_SUFFIX).$(DLL_SUFFIX)
+ SHARED_LIBRARY =
$(OBJDIR)/$(DLL_PREFIX)$(LIBRARY_NAME)$(LIBRARY_VERSION)$(JDK_DEBUG_SUFFIX).$(DLL_SUFFIX).$(LIBRARY_VERSION)
endif
endif
This approach would also mean everyone links in the same old manner
(with -l nss3).
Assignee | ||
Comment 1•22 years ago
|
||
Are the map files for Solaris incomplete? The following email from Danek indicates our Solaris map files need fixing: Ok, I finally did take a look at it, and after scratching my head a bit, I ran it past Jarrett. The versioning isn't hierarchical like it should be, and none of the private (but still exported) symbols are marked as such. Jarrett suggested something like this: SUNW_1.3 { # NSS 3.3. release global: CERT_CheckCertUsage; CERT_FindCertIssuer; PK11_GetModule; SECKEY_CreateDHPrivateKey; SECKEY_GetPublicKeyType; SECMOD_AddNewModule; }; SUNW_1.2; SUNW_1.2 { # NSS 3.2.1 release global: CERT_AddRDN; CERT_CreateRDN; CERT_CreateAVA; CERT_CreateName; }; SUNW_1.1; SUNW_1.1 { # NSS 3.2 release global: ATOB_AsciiToData; BTOA_ConvertItemToAscii; ... }; SUNWprivate { global: # The following symbols are exported only to make libsmime3.so work. # __CERT_ClosePermCertDB; __CERT_DecodeDERCertificate; __CERT_TraversePermCertsForNickname; __CERT_TraversePermCertsForSubject; __PBE_CreateContext; __PBE_DestroyContext; __PBE_GenerateBits; ATOB_ConvertAsciiToItem; CERT_AddCertToListTail; ... # The following symbols are exported only to make libssl3.so work. # __CERT_NewTempCertificate; __PK11_CreateContextByRawKey; __PK11_GetKeyData; __nss_InitLock; CERT_CertChainFromCert; CERT_DestroyCertificateList; CERT_DupCertList; ... # The following symbols are exported only to make JSS work. # CERT_DisableOCSPChecking; CERT_DisableOCSPDefaultResponder; CERT_EnableOCSPDefaultResponder; CERT_GetCertTimes; CERT_ImportCAChainTrusted; ... # Data objects # # Don't export these symbols on Windows because they don't work right. # CERT_CrlTemplate; CERT_SignedDataTemplate; CERT_CertificateTemplate; CERT_Certific ... local: *; }; I asked if we could retain the NSS_* names and numbers, and he said that would work fine. He also noted that the library probably should have had its minor version bumped at 3.2.1, where it got new symbols (and hence his SUNW_ renumbering), but it's in the past and shouldn't make a difference.
Assignee | ||
Comment 2•22 years ago
|
||
Here's a recipe for creating Solaris packages for NSS 3.3.2. The ingredients are: /u/kirke/nss/158683/DIFFS (this attachment) /u/kirke/nss/158683/newfiles.tar (next attachment) Create a workarea and build in the normal manner. cd <workarea> patch </u/kirke/nss/158683/DIFFS tar xvf /u/kirke/nss/158683/newfiles.tar cd mozilla/security/nss gmake solarispkg That will generate: mozilla/dist/SunOS5.6_OPT.OBJ/pkgarchive/SUNWnss3 Copy to: /share/builds/mccrel3/nss/NSS_3_3_2_RTM/package/SunOS5.6_OPT.OBJ This will migrate to /share/builds/integration and evenutally /share/builds/components.
Assignee | ||
Comment 3•22 years ago
|
||
This is newfiles.tar, which is the second ingredient for the recipe in the previous attachment.
Comment 4•22 years ago
|
||
The following files in the tar are generated files, and should not be committed: mozilla/security/nss/pkg/solaris/SUNWnss3/pkgdepend mozilla/security/nss/pkg/solaris/SUNWnss3/pkginfo mozilla/security/nss/pkg/solaris/awk_pkginfo mozilla/security/nss/pkg/solaris/bld_awk_pkginfo
Assignee | ||
Comment 5•22 years ago
|
||
Removed the following: mozilla/security/nss/pkg/solaris/SUNWnss3/pkgdepend mozilla/security/nss/pkg/solaris/SUNWnss3/pkginfo mozilla/security/nss/pkg/solaris/awk_pkginfo mozilla/security/nss/pkg/solaris/bld_awk_pkginfo
Assignee | ||
Updated•22 years ago
|
Attachment #94189 -
Attachment is obsolete: true
Assignee | ||
Comment 6•22 years ago
|
||
Added Wan-Teh to the cc list. We need feedback regarding the map file changes Danek proposed (see Comment #1). Also, we need to discuss the use of: libfreebl_hybrid_3.so libfreebl_pure32_3.so The correct way to do this according to the Solaris folks is to let the linker load rather than doing it ourselves. If the information is passed to the linker through the packaging and installation infastructure, we may need to deal with issues related to having 2 release mechanisms. We need a solution that doesn't break the "unpackaged Solaris" distribution. Wan-Teh, this is similiar to the libultrasparc4.so "filter library" in NSPR. Perhaps we could spend some time before or after the meeting today to agree on a path. If you have questions Danek is listening, and we can query the Solaris linker pros...
Comment 7•22 years ago
|
||
Regarding comment #6 above, and the remark that the use of Solaris's "auxiliary filter" feature is the "correct" way to load these platform dependenty libraries: Is there any sense in which the present code is incorrect? In what way is the use of auxiliary filter DSOs superior to the method now used in NSS? Is the use of platform-dependent loader facilities a desirable end in itself? Here's a bit of history about the freebl DSOs. Prior to early 2000, export control regulations for crypto software precluded the use of shared libraries for crypto code. So, both the "pure32" (a.k.a. v8) and "hybrid" (a.k.a. v8+) versions of the code were linked into each program, and the code determined at run time which set of code to use. Some special hackery was necessary to be able to load a program with v8+ code on a v8 CPU, but that's just what we did. This architectural approach (link in two sets of code into the executable, choose the right one at run time) was used on Solaris/sparc and HP-UX/PA-Risc. We also intended to use it on AIX, which also runs on both 32 and 64 bit PPC CPUs, but that work was never done. Later, when the export regulations changed and we were permitted to use shared libraries for this code, we already had the code in place to choose the right set of code at run time. It was a relatively small change to have that code load a DSO in addition to what it was already doing (setting a pointer to a table of function pointers). Changing the code to use the auxilliary filter feature would have been considerably more work, and would have made the approach on Solaris be quite different than the approach for HPUX, resulting in considerably more #ifdef'ed code, I think. My only concern with switching to use auxiliary filter DSOs at this point is the effect on the maintainability of the code. If there is significant performance benefit, then perhaps the additional ifdeffing in the code is not too high a price to pay.
Comment 8•22 years ago
|
||
From a technical standpoint, there's probably little difference. It sounds like your code does pretty much what the Solaris dynamic linker does, though maybe they have different minor features. Still, though, both get the job done. The argument from Solaris-land, though, would be thus: 1. You're duplicating technology that already exists on the system. Duplicate functionality is generally frowned upon, especially if, as in this case, the Solaris version is older, better tested, and documented such that people can understand what's going on. 2. Since you're not a part of core Solaris, you have to worry about making sure your method of choosing which library to load matches the information Solaris gives you. If ISALIST changes, you have to scurry to keep up. Why not let ld.so do all that work for you? 3. You're putting libraries into a location where it appears it's fine to link directly against them. Solaris puts its filtees into separate directories to make it obvious that those paths aren't public. As it is, it's not clear to me that the implementation of isHybrid() is correct. And the comment talking about -R $ORIGIN on Solaris indicates that you're going through some uncomfortable machinations (copying code) to get this to work. Again, why not let the dynamic linker do it for you? I understand the cross-platform issue is a driver here as well. But you already have code #ifdef'ed out the wazoo, so simply #ifdefing all the wrapper functions out when compiling on Solaris won't be a big deal, and won't be a maintenance issue, because they simply won't exist on Solaris.
Assignee | ||
Comment 9•22 years ago
|
||
Added subdirectory for new package name: mozilla/security/nss/pkg/solaris/SUNWtls Removed subdirectory for old package name: mozilla/security/nss/pkg/solaris/SUNWnss3 Edited mozilla/security/nss/pkg/solaris/common_files/pkgdepend to use the new package name for NSPR (SUNWpr). Also edited the package prototype: "i pkgdepend" became "i depend=pkgdepend"
Comment 10•22 years ago
|
||
Re: SUNWtls NSS is more than just TLS. Is this because SUNWnss is already taken? How about SUNWns3? Alternatively, is it possible to avoid this conflict by using something other than SUNW as the vendor (e.g., MOZnss or OPENnss)?
Comment 11•22 years ago
|
||
Yes, SUNWtls was chosen because SUNWnss was already taken. I'd strongly hesitate from putting the version number in the package name, as it broadcasts an inability to manage major changes. This might not be the case, but the ARC would probably shoot that down. Using a different prefix might work (I think MOZ would actually be fine), but ... because we're doing something different on this branch than on the trunk (and the main release branches) I think it makes sense to put the Sun stamp on it. If and when we start delivering packages that result from an unadulterated mozilla tree, we could consider renaming the package.
Comment 12•22 years ago
|
||
1. I moved the 'solarispkg' makefile target from coreconf/rules.mk to nss/Makefile because this target is specific to NSS. (coreconf is used by other products too.) 2. The 'VERSION' in pkginfo.tmpl should say '3.3.2' instead of '4.1.2'. 3. I deleted the commented-out libultrasparc4.so from prototype_sparc. (That is an NSPR file.)
Assignee | ||
Comment 13•22 years ago
|
||
Checked in wtc's patch (id=96377). Thanks Wan-Teh!
Comment 14•22 years ago
|
||
This updates the packaging setup to be a bit more like the NSPR packages. We now pull the NSS version from a makefile (though we should be a bit more dynamic yet; the hardcoding is now just in Makefile.com). Also, get rid of all of the appserver crud I forgot to remove in the first place. Fix the location of the proto area, and make PROTO a variable, not a target.
Comment 15•22 years ago
|
||
Comment on attachment 96396 [details] [diff] [review] more packaging fixes r=wtc.
Attachment #96396 -
Flags: review+
Assignee | ||
Comment 16•22 years ago
|
||
Danek, my attempts to test with your patch choke on me. kirke@kentuckyderby[70] gmake solarispkg Making Solaris packages. gmake -C pkg/solaris publish gmake[1]: Entering directory `/export/kirke/workarea-nss332pkg/mozilla/security/nss/pkg/solaris' /usr/bin/ln -s ../../../../../../dist/SunOS5.8_OPT.OBJ/lib ROOT/usr/lib/mps; ln: cannot create ROOT/usr/lib/mps: File exists gmake[1]: *** [ROOT/usr/lib/mps] Error 2 gmake[1]: Leaving directory `/export/kirke/workarea-nss332pkg/mozilla/security/nss/pkg/solaris' gmake: *** [solarispkg] Error 2 kirke@kentuckyderby[71] There were no complaints from 'patch' installing it. I've cleaned and clobbered the living daylights out of my tree. When I remove ROOT, things come not found. rm -rf pkg/solaris/ROOT gmake solarispkg Making Solaris packages. gmake -C pkg/solaris publish gmake[1]: Entering directory `/export/kirke/workarea-nss332pkg/mozilla/security/nss/pkg/solaris' mkdir -p ROOT mkdir -p ROOT/usr mkdir -p ROOT/usr/lib /usr/bin/ln -s ../../../../../../dist/SunOS5.8_OPT.OBJ/lib ROOT/usr/lib/mps; cd SUNWtls; gmake publish gmake[2]: Entering directory `/export/kirke/workarea-nss332pkg/mozilla/security/nss/pkg/solaris/SUNWtls' pkgmk -f prototype_sparc -d ../../../../../dist/SunOS5.8_OPT.OBJ/pkgarchive -r ../ROOT -o SUNWtls ## Building pkgmap from package prototype file. ERROR in /export/kirke/workarea-nss332pkg/mozilla/security/nss/pkg/solaris/SUNWtls/prototype_com: no object for <usr/lib/mps/libnss3.so> found in root directory no object for <usr/lib/mps/libsmime3.so> found in root directory no object for <usr/lib/mps/libssl3.so> found in root directory no object for <usr/lib/mps/libfreebl_hybrid_3.so> found in root directory no object for <usr/lib/mps/libfreebl_pure32_3.so> found in root directory pkgmk: ERROR: unable to build pkgmap from prototype file ## Packaging was not successful. gmake[2]: *** [pkg] Error 1 gmake[2]: Leaving directory `/export/kirke/workarea-nss332pkg/mozilla/security/nss/pkg/solaris/SUNWtls' gmake[1]: *** [publish] Error 2 gmake[1]: Leaving directory `/export/kirke/workarea-nss332pkg/mozilla/security/nss/pkg/solaris' gmake: *** [solarispkg] Error 2 kirke@kentuckyderby[29] kirk
Comment 17•22 years ago
|
||
Try changing the $(ROOT)/lib/mps rule to have one more ../ in it. I'm just guessing, but I figure moving the proto area down one more level means that the link was one level too shallow. If it's not that, it should be easy to fix. But I'm pretty much gone for a week now. If you can't get it to work, revert the changes to the Makefile.
Assignee | ||
Comment 18•22 years ago
|
||
Checked in Danek's patch with the following modification:
> $(LN) -s ../../$(DIST)/lib $@;
52d45
< + $(LN) -s ../../../$(DIST)/lib $@;
to mozilla/security/nss/pkg/solaris/Makefile
Assignee | ||
Comment 19•22 years ago
|
||
This adds the tools excepting dbck, listed at: http://www.mozilla.org/projects/security/pki/nss/tools/ The tools are targeted too /usr/bin/mps. Danek and now Michael are leaning toward installing too /usr/lib/mps, the directory where the libraries are installed. To go to /usr/lib/mps with the tools, we need to start copying, rather than using symlinks. Since there are separate lib and bin subdirectories subordinate to dist: kirke@kentuckyderby[318] pwd /export/kirke/workarea-nss332pkg/mozilla/security/nss/pkg/solaris kirke@kentuckyderby[319] l ./ROOT/usr/lib/mps lrwxrwxrwx 1 kirke staff 46 Aug 29 10:47 ./ROOT/usr/lib/mps -> ../../../../../../../dist/SunOS5.8_OPT.OBJ/lib/ kirke@kentuckyderby[320] l ./ROOT/usr/bin/mps lrwxrwxrwx 1 kirke staff 46 Aug 29 11:07 ./ROOT/usr/bin/mps -> ../../../../../../../dist/SunOS5.8_OPT.OBJ/bin/ kirke@kentuckyderby[321] I'm placing this patch here in case the ARC and powers that be decide on /usr/bin/mps, as Michael and the AppServer team wanted initially.
Assignee | ||
Comment 20•22 years ago
|
||
I just checked in a change to add libnssckbi.so. Index: mozilla/security/nss/pkg/solaris/SUNWtls/prototype_com =================================================================== RCS file: /cvsroot/mozilla/security/nss/pkg/solaris/SUNWtls/Attic/prototype_com,v retrieving revision 1.1.2.2 diff -b -u -r1.1.2.2 prototype_com --- mozilla/security/nss/pkg/solaris/SUNWtls/prototype_com 22 Aug 2002 21:52:33 -0000 1.1.2.2 +++ mozilla/security/nss/pkg/solaris/SUNWtls/prototype_com 30 Aug 2002 21:45:37 -0000 @@ -30,3 +30,4 @@ f none usr/lib/mps/libssl3.so 755 root bin f none usr/lib/mps/libfreebl_hybrid_3.so 755 root bin f none usr/lib/mps/libfreebl_pure32_3.so 755 root bin +f none usr/lib/mps/libnssckbi.so 755 root bin
Assignee | ||
Comment 21•22 years ago
|
||
Problems with 64-bit package. First, shouldn't it be called SUNWtlsx? Second, we're picking up 32-bit libraries in the 64-bit package; nss/pkg/solaris/Makefile, unlike nsprpub/pkg/solaris/Makefile makes no provisions for USE_64. Danek, should the NSS tree be using the same mps/sparcv9 convention as NSPR? (include pkg/solaris/SUNWtlsx sister directory?) I'll create a patch and tarball for this.
Comment 22•22 years ago
|
||
don't check anything in until the tree is tagged, we had to RTM the 32 bit version for apps server
Assignee | ||
Comment 23•22 years ago
|
||
New directory: ./mozilla/security/nss/pkg/solaris/SUNWtlsx A matching patch proposal is the next attachment.
Assignee | ||
Comment 24•22 years ago
|
||
I needed to remove these: usr/lib/mps/libfreebl_hybrid_3.so usr/lib/mps/libfreebl_pure32_3.so Because they were not appearing in the 64-bit OJBDIR. + find . -xdev -name *free* ./mozilla/security/nss/lib/freebl/SunOS5.8_64_OPT.OBJ/libfreebl.a ./mozilla/dist/SunOS5.8_64_OPT.OBJ/lib/libfreebl.a This may have been a pilot error. Sonja, are you setting USE_HYBRID=1 in your 4.2.1 build?
Comment 25•22 years ago
|
||
A small nit with the new package -- you have the DESC field in pkginfo.tmpl with the space in the wrong place around the parens. It looks like the patch will be problematic. The last hunk gives you a rule without a target if USE_64 isn't defined. I think you want to put $(ROOT)/usr/lib/mps in the else clause as the target. Otherwise, it's straightforward; it looks fine.
Comment 26•22 years ago
|
||
not on 4.1.2, I assume you mean NSS? I grept for USE_HYBRID in the build logs, found it on all 32 bit builds, but it is not from my init files, the build itself seems to set this. see freebl/Makefile libs::
Comment 27•22 years ago
|
||
libfreebl_hybrid_3.so and libfreebl_pure32_3.so are not part of the 64-bit Solaris version of NSS. They are not part of the Solaris Intel version of NSS either. They only exist in the 32-bit Solaris SPARC version of NSS (3.2 or higher).
Assignee | ||
Comment 28•22 years ago
|
||
Thanks Danek. I fixed the misplaced blank in pkgingo.tmpl, and fixed the 32-bit target in solaris/Makefile earlier :-) I added the new files, and checked in the patch. Sonja, you can turn the crank now.
Assignee | ||
Updated•22 years ago
|
Attachment #98026 -
Attachment is obsolete: true
Assignee | ||
Comment 29•22 years ago
|
||
Attachment #98029 -
Attachment is obsolete: true
Assignee | ||
Comment 30•22 years ago
|
||
Tested building packages, checked this in.
Assignee | ||
Comment 31•22 years ago
|
||
This is the only change to the preexisting NSS tree. A new directory is associated with this patch: ./mozilla/security/nss/pkg which contains a single subdirectory called 'solaris'. These changes were tested with NSS_3_3_2_RTM. I verified that I can build solaris packages with the same change at the tip. I 'll proceed with checkin after someone reviews.
Assignee | ||
Comment 32•22 years ago
|
||
Added Bob to the CC list. Bob - I've attached the proposed patch for review.
Status: NEW → ASSIGNED
Assignee | ||
Comment 33•22 years ago
|
||
pkg/solaris specific changes (pkgdepend/copyright updates)
Assignee | ||
Comment 34•22 years ago
|
||
I checked in attachment (id=104088), the pkg/solaris specific changes to fixup copyright and depend files and structure. I will be comparing and updating pkg/solaris on the NSS_3_6_BRANCH and the TIP.
Assignee | ||
Comment 35•22 years ago
|
||
I've checked in my changes to NSS_3_3_2_SUN_PKG_BRANCH, and tested building ALL solaris packages. Sonja - we're ready for official builds. Michael said we need to come up with a Solaris patch for 3.3.2, since it already released. The next step will be to come up with a patch based on your build. Michael will inform us of how this is done. I've also integrated all the changes that occured on the NSS_3_3_2_SUN_PKG_BRANCH since we integrated the packaging changes at the NSS TIP. Since that time, the 3.6 branch was created. So I checked these into NSS_3_6_BRANCH, and the TIP: x86 support (separate prototype_sparc, prototype_i386) single updated copyright on common_files no pkgdepend in common_files I've also verified the changes by building all packages in all three trees: NSS_3_3_2_SUN_PKG_BRANCH NSS_3_6_BRANCH TIP Wan-Teh - I'm done with my part of the 3.6.1 release. After we exercise the packages and come up with a solaris patch for 3.3.2 that works I'll mark this fixed.
Assignee | ||
Comment 36•22 years ago
|
||
Work on NSS_3_3_2_SUN_PKG_BRANCH for which this bug was opened is complete. http://bugzilla.mozilla.org/show_bug.cgi?id=184523 was created to track NSS 3.3.3 (NSS_3_3_BRANCH).
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•