158683 - NSS libraries don't conform to Solaris versioning conventions

Status: RESOLVED FIXED

(NSS :: Libraries, defect)

Description

[Kirk Erickson]

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).

Comment 1

[Kirk Erickson]

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.

Comment 2

[Kirk Erickson]

Attachment: solarispkg target DIFFS and README

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.

Comment 3

[Kirk Erickson]

Attachment: newfiles tar archive (pkg/solaris infastructure files)

This is newfiles.tar, which is the second ingredient
for the recipe in the previous attachment.

Comment 4

[Danek Duvall]

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

Comment 5

[Kirk Erickson]

Attachment: newfiles tar archive (pkg/solaris infastructure files)

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

Comment 6

[Kirk Erickson]

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

[Nelson Bolyard (seldom reads bugmail)]

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

[Danek Duvall]

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.

Comment 9

[Kirk Erickson]

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

[Wan-Teh Chang]

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

[Danek Duvall]

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

[Wan-Teh Chang]

Attachment: wtc's proposed patch

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.)

Comment 13

[Kirk Erickson]

Checked in wtc's patch (id=96377).
Thanks Wan-Teh!

Comment 14

[Danek Duvall]

Attachment: more packaging fixes

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

[Wan-Teh Chang]

Comment on attachment 96396 [details] [diff] [review]
more packaging fixes

r=wtc.

Comment 16

[Kirk Erickson]

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

[Danek Duvall]

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.

Comment 18

[Kirk Erickson]

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

Comment 19

[Kirk Erickson]

Attachment: tools patch

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.

Comment 20

[Kirk Erickson]

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

Comment 21

[Kirk Erickson]

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

[Sonja Mirtitsch]

don't check anything in until the tree is tagged, we had to RTM the 32 bit
version for apps server

Comment 23

[Kirk Erickson]

Attachment: SUNWtlsx.tar (64-bit package directory)

New directory:
./mozilla/security/nss/pkg/solaris/SUNWtlsx

A matching patch proposal is the next attachment.

Comment 24

[Kirk Erickson]

Attachment: SUNWtlsx.DIFFS (64-bit packaging patch)

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

[Danek Duvall]

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

[Sonja Mirtitsch]

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

[Wan-Teh Chang]

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).

Comment 28

[Kirk Erickson]

Attachment: SUNWtlsx.tar (64-bit package directory)

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.

Comment 29

[Kirk Erickson]

Attachment: SUNWtlsx.DIFFS (64-bit packaging patch)

Comment 30

[Kirk Erickson]

Attachment: Copyright changes from Danek

Tested building packages, checked this in.

Comment 31

[Kirk Erickson]

Attachment: solarispkg target to mozilla/security/nss/Makefile

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.

Comment 32

[Kirk Erickson]

Added Bob to the CC list.
Bob - I've attached the proposed patch for review.

Comment 33

[Kirk Erickson]

Attachment: depend/copyright changes to pkg/solaris

pkg/solaris specific changes
(pkgdepend/copyright updates)

Comment 34

[Kirk Erickson]

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.

Comment 35

[Kirk Erickson]

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.

Comment 36

[Kirk Erickson]

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).