Hi folks,
I have to temporarily withdraw my CR request for SUNWpmtools. I just
realized I posted a webrev from the old version of the workspace. I
need to locate the updated version and I'll submit a new webrev soon.
I apologize for the confusion.
Sincerely,
Pat
On 07/31/09 10:13, Bobbie wrote:
>
>
> -------- Original Message --------
> Subject: [sfwnv-discuss] HEADS UP: SFW build changes
> Date: Thu, 07 May 2009 18:06:41 -0500
> From: Norm Jacobs <Norm.Jacobs at Sun.COM>
> To: sfwnv-gate at sfwnv.sfbay.sun.com, sfwnv-discuss at opensolaris.org
>
>
> If you own a component in the SFW gate or plan on integrating one in the
> future, read on and read carefully...
>
> My recent integration of
>
> 6836557 sfw gate needs consistent metadata
>
> introduces some change to the SFW gate.
>
> * Each component now contains a METADATA file and that METADATA file
> should contain a consistent set of fields with consistent values.
> * The component builds will now validate that each component
> contains a METADATA file and that the file contains what appears
> to be valid data.
> * All components' Makefile.sfw now indirectly include
> $(SRC)/Makefile.targ, which defines sets of common rules. There
> are currently rules defined for
> o unpacking source for both 32 and 64 bit builds
> o patching source for both 32 and 64 bit builds
> o validating METADATA file contents
> o hooks for other actions
> * Two new top level targets have been introduced
> o 'meta-check' to validate the METADATA files across all of
> the components in the gate.
> o 'component-hook' to perform a supplied action across each
> component in the gate. (see example below)
>
> If you attempt to build a component and it doesn't contain a METADATA
> file or the validation tool determines it to be invalid in some way,
> your build will fail. You must correct any ERROR reported by the
> validation tool in order to proceed with your build.
>
> If you own a component in the gate...
>
> Please take the time to look at the METADATA file that currently
> exists and verify it's accuracy. If the file doesn't contain
> accurate information, please update it. A complete description of
> the METADATA file contents can be found at
> http://wikis.sun.com/display/SFWNotes/METADATA.
>
> If you have a workspace that is waiting to integrate into the gate...
>
> You must resync with the gate, add or update your METADATA file,
> rebuild your component, and resolve any issues that show up. If you
> don't, your integration will very likely break the gate.
>
> A note about the OWNER field...
>
> In the process of making these updates, I found the majority of the
> OWNER information in the existing METADATA files was way out of
> date. As a result, I have removed the OWNER field from the METADATA
> and will be placing it in a table on the gate website, possibly out
> on http://wikis.sun.com/display/SFWNotes/ as well. In the end, the
> decision to remove the OWNER came down to the fact that staffing
> changes shouldn't require a putback into the gate.
>
> Example of checking a component's METADATA:
>
> % cd {component-dir} ; make -f Makefile.sfw meta-check
>
> Example of checking all components' METADATA:
>
> % cd ${SRC}; make -f Makefile.sfw meta-check
>
> Example of invoking 'component-hook' support:
>
> % cd ${SRC} ; make COMPONENT_HOOK="cat METADATA" component-hook
>
> One more bit of information about some changes on the horizon...
>
> Over the next few weeks, I will be going through the various
> components and unifying their unpacking and patching methodology
> (hence some of the rules in $(SRC)/Makefile.targ). I will be
> updating all of the unpacking and packing rules in the gate to use
> the tools defined in Makefile.master and rules in Makefile.targ (at
> least where possible). I will also be converting all patching that
> I find to use unified context diffs that can be applied using "cd
> $(@D) ; gpatch -p1 <.../foo.patch" during the patching phase of a
> component build.
>
> If you are integrating any new components into the gate over the
> next few weeks, I would recommend that you take advantage of the
> existing unpacking and patching rules already in the gate and that
> any patches that you supply be unified context diffs that can be
> applied via "cd $(@D) ; gpatch -p1 <.../foo.patch"
>
> Unified Context Diffs can be generated using "diff -u" (see diff(1))
> Ex:
> % diff -u cups-1.4b2/backend/serial.c.orig
> cups-1.4b2/backend/serial.c >> Patches/00-backend-serial.c.patch
>
>
> -Norm
>
> _______________________________________________
> sfwnv-discuss mailing list
> sfwnv-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/sfwnv-discuss
--
Pat Bredenberg
Solaris Quality Engineering
Sun Microsystems, Inc. - Broomfield, CO
