|
|
flag day: lint, third-party licenses, closed code, crypto
Date: Thu, 03 May 2007 16:22:43 -0700
From: Mike Kupfer <mike.kupfer at sun dot com>
To: on-all at eng dot sun dot com, onnv-gate at onnv dot sfbay dot sun dot com
Subject: flag day: lint, third-party licenses, closed code, crypto
My putback for
6467531 nightly(1) needs option to generate OpenSolaris delivery
6455242 nightly should be able to preserve all proto areas from a
single build.
is a flag day for people in any of the following categories:
* you run nightly with -l (lint) but not -D (debug build)
* you work with open-source code that has a third-party license
* you work with confidential code (usr/closed)
* you work with crypto
This is also a heads-up message if you want to
* generate BFU archives, closed binaries, or sources to post on
opensolaris.org.
* maintain separate proto areas for debug and non-debug builds
--- Flag day details ---
A. nightly -l
With this putback, nightly(1) will not run lint if you specify only a
non-debug build. Be sure to include -D in your NIGHTLY_OPTIONS.
(Note that -D is already recommended practice.)
B. Third-party Licenses
Many open-source projects include a third-party license that requires
binary distributions to include a copy of the license. Until now, the
OpenSolaris engineering team has been handling this for onnv snapshots
on opensolaris.org. This putback enhances the build infrastructure to
gather the third-party license files, but project teams will have some
new responsibilities.
1. How it Works
usr/src/tools/opensolaris/license-list is a new configuration
file. It contains a list of all the third-party license files
that must be delivered when we post binaries (BFU archives, closed
binaries, etc.) on opensolaris.org. Most of these license files
are static files (checked in with SCCS). A few are extracted
during the build from other files.
Each license file has a corresponding "description" file (e.g.,
LICENSE.descrip). This file contains the one-line description
that identifies the software covered by the license. Near the end
of the build, the license files are combined with the
"description" files into an aggregate THIRDPARTYLICENSE file
(e.g., THIRDPARTYLICENSE.BFU-ARCHIVES). Each binary tarball that
we post on opensolaris.org has one of these aggregate files.
2. Team Responsibilities
When you update code that already has a third-party license,
please review the license text for changes (e.g., new copyright
years). If there are changes, make sure they are propagated as
needed. In a few cases, you will have nothing to do, because the
build just drops in the license file that we get from upstream.
In most cases, you will need to copy the changes to the static
third-party license file that lives in the source directory. In
the cases where the license text is dynamically extracted, you can
do a "make install" and then review the generated license file, to
make sure that the extraction code is still working.
If you add new code that has a third-party license, please review
the license terms and the associated inbound OSR. If the license
or the OSR instructions require that binaries include a copy of
the license text, decide how you want to produce the license file,
then add the license file to
usr/src/tools/opensolaris/license-list. Be sure to include
copyright statements if the license requires them. And don't
forget to create the description (.descrip) file that goes with
the license file.
If you delete code that has a third-party license, please be sure
to remove the license file from
usr/src/tools/opensolaris/license-list.
If you add entries to (or delete entries from)
usr/src/tools/opensolaris/license-list, you can run nightly with
the 'O' (upper-case oh) option to test your changes. (Add 'O' to
NIGHTLY_OPTIONS in your environment file.)
C. Confidential Code
As you may know, we post a "closed binaries" tarball on
opensolaris.org, which external developers use when building ON. This
tarball does not contain everything that is built from usr/closed.
For example, some drivers have a license that prevents us from posting
the binary on opensolaris.org, so we exclude them from the tarball.
We also exclude some cryptographic data files (e.g., some
certificates).
If you are introducing something into usr/closed and it should not
show up in the closed binaries tarball, you must add the appropriate
file(s) to the exclusion list in usr/src/tools/scripts/bindrop.sh.
D. Crypto
There are two things that the crypto folks need to deal with.
First, if you work with anything in usr/closed, please review the
previous section ("Confidential Code").
Second, the closed binaries tarball contains crypto implementation
modules that have been signed by Sun Release Engineering (RE). If you
add a new crypto file that must be signed to work, please add it to
the appropriate list in usr/src/tools/scripts/bindrop.sh. Note that
there are two lists: one for packages that are part of a standard
netinstall, and one for Encryption Kit packages.
--- Heads-up Details ---
A. Multiple Proto Areas
As you probably know, the ON build generates both debug and non-debug
kernel modules. These modules share the same path in the proto area,
which requires serializing the debug and non-debug builds.
With this putback, you can set MULTI_PROTO to "yes" in your
environment file. nightly(1) and bldenv(1) will then use
root_$MACH-nd as the proto area for non-debug builds.
B. OpenSolaris Deliverables
Suppose your project wants to post BFU archives on opensolaris.org for
people to try out, or you want to post source and closed binaries so
that people can build and play with your stuff. Until now, putting
together these tarballs has been a manual process. With this putback,
you can now just add 'O' (upper case oh) to your NIGHTLY_OPTIONS.
nightly(1) will generate these tarballs and put them in $CODEMGR_WS:
SUNWonbld.$MACH.tar.bz2
on-bfu-nightly-open-nd.$MACH.tar.bz2 (non-debug builds)
on-bfu-nightly-open.$MACH.tar.bz2 (debug builds)
on-closed-bins-nd.$MACH.tar.bz2 (non-debug builds)
on-closed-bins.$MACH.tar.bz2 (debug builds)
on-src.tar.bz2
The tarballs are ready to post, though you might want to rename them
to include a date or build identifier. To make things simpler for
your users, just post the tarballs that are specific to your project.
For example, if you haven't made any changes in usr/src/tools, you
don't need to post a new SUNWonbld tarball.
The 'O' option always sets MULTI_PROTO to yes (see the preceding
section for details.) Also, be aware that bldenv will take 'O' to
mean that you want to do an open-only build.
--- Questions? Concerns? ---
If you have any questions or concerns, please contact
tonic-team at sun dot com.
|