|
Replies:
11
-
Last Post:
Sep 16, 2006 3:23 AM
by: bochnig
|
|
|
|
|
|
|
on-closed bits suggestion
Posted:
Aug 22, 2006 10:09 AM
|
|
[No Body]
|
|
|
Posts:
1,156
From:
US
Registered:
3/9/05
|
|
|
|
Re: on-closed bits suggestion
Posted:
Aug 22, 2006 10:09 AM
in response to: Guest
|
|
Rich Teer wrote:
> On Wed, 23 Aug 2006, Alan Hargreaves wrote:
>
>> Oh if only it were that simple. Unfortunately it's not. I've got code working
>> for producing the bits, I need to keep testing each time a code drop happens
>> (and I really need to test sparc properly), but other than that it's ready for
>> code review.
>
> Given that (presumably) the Solaris bits are shipped in non-debug mode,
> can you please give us some more details as to why building the open
> bits in non-debug mode causes so much grief? I take it that it's not
> as simple as just changing an option in a Makefile...
>
> Curiously,
>
Bonnie - are there any redistribution/licensing issues with building and
distributing non-debug closed-binaries?
cheers,
steve
--
stephen lau // stevel at sun dot com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
308
From:
US
Registered:
4/26/05
|
|
|
|
Re: on-closed bits suggestion
Posted:
Aug 22, 2006 11:12 AM
in response to: stevel
|
|
Stephen Lau wrote On 08/22/06 11:09,:
> Rich Teer wrote:
>
>>On Wed, 23 Aug 2006, Alan Hargreaves wrote:
>>
>>
>>>Oh if only it were that simple. Unfortunately it's not. I've got code working
>>>for producing the bits, I need to keep testing each time a code drop happens
>>>(and I really need to test sparc properly), but other than that it's ready for
>>>code review.
>>
>>Given that (presumably) the Solaris bits are shipped in non-debug mode,
>>can you please give us some more details as to why building the open
>>bits in non-debug mode causes so much grief? I take it that it's not
>>as simple as just changing an option in a Makefile...
>>
>>Curiously,
>>
>
>
> Bonnie - are there any redistribution/licensing issues with building and
> distributing non-debug closed-binaries?
No. Licensing a non-debug version of the ON closed-binaries should be
the same as for the debug version.
Thanks.
Bonnie
>
> cheers,
> steve
>
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
206
From:
AU
Registered:
6/13/05
|
|
|
|
Re: on-closed bits suggestion
Posted:
Sep 12, 2006 12:25 AM
in response to: bjc
|
|
Bonnie, does this mean that if I create a non-debug set of closed
binaries and the file list in the tarball matches what Steve creates for
the debug version, that there should be no issue with me making them
available?
alan.
Bonnie Corwin wrote:
> Stephen Lau wrote On 08/22/06 11:09,:
>> Rich Teer wrote:
>>
>>> On Wed, 23 Aug 2006, Alan Hargreaves wrote:
>>>
>>>
>>>> Oh if only it were that simple. Unfortunately it's not. I've got code working
>>>> for producing the bits, I need to keep testing each time a code drop happens
>>>> (and I really need to test sparc properly), but other than that it's ready for
>>>> code review.
>>> Given that (presumably) the Solaris bits are shipped in non-debug mode,
>>> can you please give us some more details as to why building the open
>>> bits in non-debug mode causes so much grief? I take it that it's not
>>> as simple as just changing an option in a Makefile...
>>>
>>> Curiously,
>>>
>>
>> Bonnie - are there any redistribution/licensing issues with building and
>> distributing non-debug closed-binaries?
>
> No. Licensing a non-debug version of the ON closed-binaries should be
> the same as for the debug version.
>
> Thanks.
>
> Bonnie
>
>
>> cheers,
>> steve
>>
>
> _______________________________________________
> opensolaris-code mailing list
> opensolaris-code at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
--
Alan Hargreaves - http://blogs.sun.com/tpenta
Staff Engineer (Kernel/VOSJEC/Performance)
Systems Technical Service Center
Sun Microsystems
I went in the World's Greatest shave for Leukaemia. See
http://blogs.sun.com/roller/page/tpenta?entry=hair_yesterday_gone_today
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
308
From:
US
Registered:
4/26/05
|
|
|
|
Re: on-closed bits suggestion
Posted:
Sep 12, 2006 7:59 AM
in response to: alanh
|
|
Hi Alan,
Yes, if the contents of your tarball match the contents of the debug
version, it can be distributed using the OpenSolaris Binary License.
There are posting instructions at:
http://opensolaris.org/os/projects/posting_instr
that include naming conventions and information about the OBL - you need
to include three files related to the license in the tarball.
Thanks.
Bonnie
Alan Hargreaves wrote On 09/12/06 01:25,:
> Bonnie, does this mean that if I create a non-debug set of closed
> binaries and the file list in the tarball matches what Steve creates for
> the debug version, that there should be no issue with me making them
> available?
>
> alan.
>
> Bonnie Corwin wrote:
>
>>Stephen Lau wrote On 08/22/06 11:09,:
>>
>>>Rich Teer wrote:
>>>
>>>
>>>>On Wed, 23 Aug 2006, Alan Hargreaves wrote:
>>>>
>>>>
>>>>
>>>>>Oh if only it were that simple. Unfortunately it's not. I've got code working
>>>>>for producing the bits, I need to keep testing each time a code drop happens
>>>>>(and I really need to test sparc properly), but other than that it's ready for
>>>>>code review.
>>>>
>>>>Given that (presumably) the Solaris bits are shipped in non-debug mode,
>>>>can you please give us some more details as to why building the open
>>>>bits in non-debug mode causes so much grief? I take it that it's not
>>>>as simple as just changing an option in a Makefile...
>>>>
>>>>Curiously,
>>>>
>>>
>>>Bonnie - are there any redistribution/licensing issues with building and
>>>distributing non-debug closed-binaries?
>>
>>No. Licensing a non-debug version of the ON closed-binaries should be
>>the same as for the debug version.
>>
>>Thanks.
>>
>>Bonnie
>>
>>
>>
>>>cheers,
>>>steve
>>>
>>
>>_______________________________________________
>>opensolaris-code mailing list
>>opensolaris-code at opensolaris dot org
>>http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>
>
>
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
206
From:
AU
Registered:
6/13/05
|
|
|
|
Re: on-closed bits suggestion
Posted:
Sep 12, 2006 7:00 PM
in response to: bjc
|
|
Cool. I guess that puts the onus on me to generate something.
Hmmmmm, Stev's latest drop is from thsi mornings clone and contains teh
brandZ bits. That sounds like a good place to start.
alan.
Bonnie Corwin wrote:
> Hi Alan,
>
> Yes, if the contents of your tarball match the contents of the debug
> version, it can be distributed using the OpenSolaris Binary License.
>
> There are posting instructions at:
>
> http://opensolaris.org/os/projects/posting_instr
>
> that include naming conventions and information about the OBL - you need
> to include three files related to the license in the tarball.
>
> Thanks.
>
> Bonnie
>
> Alan Hargreaves wrote On 09/12/06 01:25,:
>> Bonnie, does this mean that if I create a non-debug set of closed
>> binaries and the file list in the tarball matches what Steve creates for
>> the debug version, that there should be no issue with me making them
>> available?
>>
>> alan.
>>
>> Bonnie Corwin wrote:
>>
>>> Stephen Lau wrote On 08/22/06 11:09,:
>>>
>>>> Rich Teer wrote:
>>>>
>>>>
>>>>> On Wed, 23 Aug 2006, Alan Hargreaves wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Oh if only it were that simple. Unfortunately it's not. I've got code working
>>>>>> for producing the bits, I need to keep testing each time a code drop happens
>>>>>> (and I really need to test sparc properly), but other than that it's ready for
>>>>>> code review.
>>>>> Given that (presumably) the Solaris bits are shipped in non-debug mode,
>>>>> can you please give us some more details as to why building the open
>>>>> bits in non-debug mode causes so much grief? I take it that it's not
>>>>> as simple as just changing an option in a Makefile...
>>>>>
>>>>> Curiously,
>>>>>
>>>> Bonnie - are there any redistribution/licensing issues with building and
>>>> distributing non-debug closed-binaries?
>>> No. Licensing a non-debug version of the ON closed-binaries should be
>>> the same as for the debug version.
>>>
>>> Thanks.
>>>
>>> Bonnie
>>>
>>>
>>>
>>>> cheers,
>>>> steve
>>>>
>>> _______________________________________________
>>> opensolaris-code mailing list
>>> opensolaris-code at opensolaris dot org
>>> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>>
>>
>
> _______________________________________________
> opensolaris-code mailing list
> opensolaris-code at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
--
Alan Hargreaves - http://blogs.sun.com/tpenta
Staff Engineer (Kernel/VOSJEC/Performance)
Systems Technical Service Center
Sun Microsystems
I went in the World's Greatest shave for Leukaemia. See
http://blogs.sun.com/roller/page/tpenta?entry=hair_yesterday_gone_today
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
8
From:
Registered:
8/21/06
|
|
|
|
Re: on-closed bits suggestion
Posted:
Sep 12, 2006 9:09 PM
in response to: alanh
To: OpenSolaris » code
|
|
Sounds like a wonderful plan. Can't wait to see the binaries :) The debug factor, in all simplicity, is the only thing keeping me from keeping a home-build ON in my system -- I need the speed of a non-debug. Wonderful system though.
-Mike
|
|
|
|
|
Posts:
206
From:
AU
Registered:
6/13/05
|
|
|
|
Re: Re: on-closed bits suggestion
Posted:
Sep 14, 2006 2:16 AM
in response to: mthayes
|
|
Folks interested in playing with non-debug bits may find the following
url "interesting".
http://blogs.sun.com/tpenta/entry/non_debug_opensolaris_build_49
alan.
Michael Hayes wrote:
> Sounds like a wonderful plan. Can't wait to see the binaries :) The debug factor, in all simplicity, is the only thing keeping me from keeping a home-build ON in my system -- I need the speed of a non-debug. Wonderful system though.
>
> -Mike
>
--
Alan Hargreaves - http://blogs.sun.com/tpenta
Staff Engineer (Kernel/VOSJEC/Performance)
Systems Technical Service Center
Sun Microsystems
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
976
From:
Registered:
6/14/05
|
|
|
|
Re: [osol-discuss] Re: Re: on-closed bits suggestion
Posted:
Sep 16, 2006 3:23 AM
in response to: alanh
|
|
Alan Hargreaves wrote:
> Folks interested in playing with non-debug bits may find the following
> url "interesting".
>
> http://blogs.sun.com/tpenta/entry/non_debug_opensolaris_build_49
>
> alan.
_very_ interesting.
(As always when you work on this.)
+1
martin
>
> Michael Hayes wrote:
>
>> Sounds like a wonderful plan. Can't wait to see the binaries :) The
>> debug factor, in all simplicity, is the only thing keeping me from
>> keeping a home-build ON in my system -- I need the speed of a
>> non-debug. Wonderful system though.
>>
>> -Mike
>>
>
>
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
1,156
From:
US
Registered:
3/9/05
|
|
|
|
Re: on-closed bits suggestion
Posted:
Aug 22, 2006 10:33 AM
in response to: Guest
|
|
Rich Teer wrote:
> On Wed, 23 Aug 2006, Alan Hargreaves wrote:
>
>> Oh if only it were that simple. Unfortunately it's not. I've got code working
>> for producing the bits, I need to keep testing each time a code drop happens
>> (and I really need to test sparc properly), but other than that it's ready for
>> code review.
>
> Given that (presumably) the Solaris bits are shipped in non-debug mode,
> can you please give us some more details as to why building the open
> bits in non-debug mode causes so much grief? I take it that it's not
> as simple as just changing an option in a Makefile...
It's not so much grief as it is time-consuming. Here's the process my
scripts do for delivering the nightly builds each week:
1. Bringover from /ws/onnv-gate
2. Build a full (open+closed) build
3. Move the proto area out of the way
4. Setup the minimal required closed binaries (libc_i18n & libdisasm on
sparc)
5. Build an open-only build
6. Build closed-binaries tarball (consists of the following substeps)
6a. Make a copy of the full proto area we saved in step 3
6b. Delete anything that is also in the open-only proto area
6c. Delete anything we don't have the rights to redistribute
6d. Pull in the RE-signed crypto bits
7. Using the newly created closed-bins, fire off one more open-only
build to build the BFU archives (so that the BFU archives contain
the closed-bins)
8. Create the SUNWonbld package
9. Create the BFU archives tarball
10. Create the source tarball (removing all the SCCS history)
11. Generate changelogs
12. Create the squelched source (consists of the following substeps):
12a. Bringover a child of usr/src
12b. Squelch the history for every file
12c. Upload to cvs.opensolaris.org
13. Build the Mercurial bundles
Steps 1-9 are done twice, once for SPARC, and once for x86.
Essentially, they would have to be done two more times - for non-debug
on both platforms.
cheers,
steve
--
stephen lau // stevel at sun dot com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
1,098
From:
CA
Registered:
4/27/05
|
|
|
|
Re: on-closed bits suggestion
Posted:
Aug 22, 2006 10:43 AM
in response to: stevel
|
|
On Tue, 22 Aug 2006, Stephen Lau wrote:
> It's not so much grief as it is time-consuming. Here's the process my scripts
> do for delivering the nightly builds each week:
[...]
> Steps 1-9 are done twice, once for SPARC, and once for x86. Essentially, they
> would have to be done two more times - for non-debug on both platforms.
Ah, I see! Thanks for the clarification.
--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
8
From:
Registered:
8/21/06
|
|
|
|
Re: on-closed bits suggestion
Posted:
Aug 27, 2006 4:26 PM
in response to: stevel
|
|
> Rich Teer wrote:
> > On Wed, 23 Aug 2006, Alan Hargreaves wrote:
> >
> >> Oh if only it were that simple. Unfortunately it's
> not. I've got code working
> >> for producing the bits, I need to keep testing
> each time a code drop happens
> >> (and I really need to test sparc properly), but
> other than that it's ready for
> >> code review.
> >
> > Given that (presumably) the Solaris bits are
> shipped in non-debug mode,
> > can you please give us some more details as to why
> building the open
> > bits in non-debug mode causes so much grief? I
> take it that it's not
> > as simple as just changing an option in a
> Makefile...
>
> It's not so much grief as it is time-consuming.
> Here's the process my
> cripts do for delivering the nightly builds each
> week:
>
> 1. Bringover from /ws/onnv-gate
> 2. Build a full (open+closed) build
> 3. Move the proto area out of the way
> 4. Setup the minimal required closed binaries
> (libc_i18n & libdisasm on
> sparc)
> 5. Build an open-only build
> 6. Build closed-binaries tarball (consists of the
> following substeps)
> 6a. Make a copy of the full proto area we saved in
> n step 3
> 6b. Delete anything that is also in the open-only
> y proto area
> 6c. Delete anything we don't have the rights to
> o redistribute
> 6d. Pull in the RE-signed crypto bits
> 7. Using the newly created closed-bins, fire off one
> more open-only
> build to build the BFU archives (so that the BFU
> archives contain
> the closed-bins)
> reate the SUNWonbld package
> 9. Create the BFU archives tarball
> 10. Create the source tarball (removing all the SCCS
> history)
> 11. Generate changelogs
> 12. Create the squelched source (consists of the
> following substeps):
> 12a. Bringover a child of usr/src
> 12b. Squelch the history for every file
> 12c. Upload to cvs.opensolaris.org
> 13. Build the Mercurial bundles
>
> Steps 1-9 are done twice, once for SPARC, and once
> for x86.
> Essentially, they would have to be done two more
> times - for non-debug
> on both platforms.
>
> cheers,
> steve
>
>
> --
> stephen lau // stevel at sun dot com | 650.786.0845 |
> http://whacked.net
> opensolaris // solaris kernel development
> _______________________________________________
> opensolaris-code mailing list
> opensolaris-code at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/opensolar
> is-code
>
as for the time-consuming part and given the number of servers that i can imagine would be involved with building solaris and OS, couldn't you partition just one server out to build the debug bits as is done currently, and dedicate another to do non-debug, then have them upload to the same mirror under (slightly) different names? it would be time consuming to initially set the second server up, but in the end would be a lot less time consuming than actually making one machine build both types of bits, since the closed bits would only be built once per architecture on each machine. this would also be easier on the admin, since he or she could login to both machines at once, issue commands to them, and not have to worry about sitting around for one build to complete.
|
|
|
|
|
