Re: Fwd: PSARC/2010/139 - Removing Areca Backup
On 04/21/10 16:18, Nicolas Williams wrote: On Wed, Apr 21, 2010 at 03:56:25PM -0700, Hugh McIntyre wrote: Norm Jacobs wrote: Now, from a more practical standpoint, it is a place where people can build and deliver software not in the product, but may be useful as an add-on to the product. I.e. kind of like the original /opt/sfw? If any "unbundled" (not in /release, or /extra) code is to be deliverable into /usr (as opposed to /opt), then we may get into registry issues. (Well, IPS' exclude dependencies could be used to manage conflicts, to some degree, but perhaps only if repos can figure these out automatically, and since we're talking about multiple repos, I think implementing that would get complicated.) Nico We obsolete the package in SFW, and the contrib package has an optional dependency on the obsolete version in SFW. - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaald...@oracle.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Fwd: PSARC/2010/139 - Removing Areca Backup
On Wed, Apr 21, 2010 at 03:56:25PM -0700, Hugh McIntyre wrote: > Norm Jacobs wrote: > >Now, from a more practical standpoint, it is a place where people > >can build and deliver software not in the product, but may be > >useful as an add-on to the product. > > I.e. kind of like the original /opt/sfw? If any "unbundled" (not in /release, or /extra) code is to be deliverable into /usr (as opposed to /opt), then we may get into registry issues. (Well, IPS' exclude dependencies could be used to manage conflicts, to some degree, but perhaps only if repos can figure these out automatically, and since we're talking about multiple repos, I think implementing that would get complicated.) Nico -- ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Fwd: PSARC/2010/139 - Removing Areca Backup
Norm Jacobs wrote: On 04/21/10 02:40 PM, Sebastien Roy wrote: I think there is perhaps general confusion about the relationship between the /contrib repository and the product. Yes, they did bring up the /contrib repository and they do intend on making it available there, but the reality is that /contrib doesn't contain pieces of Solaris architecture and should not. /contrib is not part of the product and you can't layer anything that is part of the product on it. From an architectural standpoint, it doesn't exist. I guess part of the question might be: does the project team plan to move this to /contrib once and then abandon it? Or is the team (or some unspecified "contrib team") signing up to keep the version in /contrib up to date with security and other updates, at least to the extent that SFW was historically kept up to date by the SFW team? Now, from a more practical standpoint, it is a place where people can build and deliver software not in the product, but may be useful as an add-on to the product. I.e. kind of like the original /opt/sfw? Hugh. ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Fwd: PSARC/2010/139 - Removing Areca Backup
On 04/21/10 02:40 PM, Sebastien Roy wrote: On 04/21/10 03:07 PM, Norm Jacobs wrote: On 04/21/10 12:37 PM, Sebastien Roy wrote: On 04/21/10 01:19 PM, Bart Smaalders wrote: It seems that someone actually needs to own and maintain contrib for this plan to go forward; right now contrib is not well maintained, and maintainers are not responsive to bugs. Indeed. This case is obviously not unique; there are a significant number of cases coming through the process with the shared goal of vacating the SFW consolidation of software that the project team has identified as being better suited for the /contrib repository. Perhaps it would be productive to have a discussion about this greater goal and the type of infrastructure that is needed to accomplish it. An umbrella case would be a good medium to have such a discussion. -Seb While I agree that the /contrib repository is in need of some care and feeding, it doesn't contain software that is part of the Solaris architecture. As a result, this isn't really the right forum for a discussion of /contrib. Call me confused, but the project team initially brought it up by including this in the case materials: 2.Technical Issues 2.1.Availability through OpenSolaris /contrib repository The OpenSolaris /contrib repository [1] is a more appropriate mechanism for delivering Areca Backup to interested consumers. A separate and independent project will provide Areca Backup availability through the OpenSolaris /contrib repository. I think there is perhaps general confusion about the relationship between the /contrib repository and the product. Yes, they did bring up the /contrib repository and they do intend on making it available there, but the reality is that /contrib doesn't contain pieces of Solaris architecture and should not. /contrib is not part of the product and you can't layer anything that is part of the product on it. From an architectural standpoint, it doesn't exist. Now, from a more practical standpoint, it is a place where people can build and deliver software not in the product, but may be useful as an add-on to the product. Regardless of the /contrib issue, there seems to be some overarching driver for these cases, and I'm suggesting that communicating the overall goal and plan to accomplish it separate would save every individual case from having the same kind of discussion, and would give greater context to these cases. The goal of this case and similar cases is to remove software from the Solaris WOS that should not have been integrated into the WOS in the first place. If you disagree and believe that the software fits a significant architectural need, then you should say so, so that we might better apply the resources available. You should be looking at each of these cases on the merit of it's architectural significance to Solaris. The intention of this case and similiar cases is to remove interfaces from the Solaris architecture that don't address a specific architectural need or where it might make sense to address a user requirement outside of the Solaris architecture. The fact that they are being added to /contrib should have little or no bearing on any recommendation you make. Perhaps that's true, but my general point is that this is something that could have been discussed in an umbrella case in order to facilitate the formulation and review of each of these piece-meal removal cases. There may be an umbrella case to be had, though it's likely to involve more than just an architectural discussion. -Norm ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC 2010/095 More ksh93 builtins
Sebastien, the goal is to have only one implementation at the end
(lets call it SUNWposix-core), one which is a maintained, modern, very
fast, conforms to POSIX, SUS, passes UNIX branding requirements (some
people have voiced concerns about this, I can say as current project
lead in charge that this is nothing to worry about as we indent to
pass all tests and requirements required by the UNIX brand),
implements commonly used BSD and GNU features and supports a wide
range of systems from very small 16 MB ARM embedded machines scaling
up to very large servers with 16 TB or more.
Olga
On Wed, Apr 21, 2010 at 4:52 PM, Sebastien Roy wrote:
> On 03/31/10 12:19 PM, Garrett D'Amore wrote:
>>
>> The project team has decided to change the proposal to remove the
>> contentious builtins for /usr/gnu. Instead, only /usr/bin and
>> /usr/xpg4,xpg6 utilities are being provided as builtins. As these
>> utilities will hopefully one day be converted to use the same underlying
>> libcmd interface, this should not be contentious.
>>
>> I'm restarting the timeout for one week from today (timeout expires
>> April 7). The revised spec follows.
>
> Given that this case is building upon pre-existing built-in architecture, I
> don't have any issues specific to this case that should hold it up. +1
>
> That said, I think one thread of substance from the lengthy discussion this
> case spawned relates to the duplicity of code between the commands and their
> built-in equivalents. This is more a commentary of the implementation of
> built-ins in general, and not of the specific built-ins introduced by this
> case. Having architecture introduced to allow a shared implementation (as
> Garrett hopes will be the case with libcmd above) would be a good thing.
>
> -Seb
>
>
--
, __ ,
{ \/`o;-Olga Kryzhanovska -;o`\/ }
.'-/`-/ olga.kryzhanov...@gmail.com \-`\-'.
`'-..-| / Solaris/BSD//C/C++ programmer \ |-..-'`
/\/\ /\/\
`--` `--`
___
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
This case was approved in today's meeting. -tim ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Fwd: PSARC/2010/139 - Removing Areca Backup
On 4/21/2010 3:07 PM, Norm Jacobs wrote: You should be looking at each of these cases on the merit of it's architectural significance to Solaris. The intention of this case and similiar cases is to remove interfaces from the Solaris architecture that don't address a specific architectural need or where it might make sense to address a user requirement outside of the Solaris architecture. The fact that they are being added to /contrib should have little or no bearing on any recommendation you make. Was there a recent decision made regarding the "familiarity cases" of the last few years? I thought the idea of adding a lot of the FOSS code to Solaris, either core or sfw or contrib, was a goal in of it's self. Even if it wasn't required to solve a specific architectural problem. (sudo v rbac being one example.) ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Fwd: PSARC/2010/139 - Removing Areca Backup
On 04/21/10 03:07 PM, Norm Jacobs wrote: On 04/21/10 12:37 PM, Sebastien Roy wrote: On 04/21/10 01:19 PM, Bart Smaalders wrote: It seems that someone actually needs to own and maintain contrib for this plan to go forward; right now contrib is not well maintained, and maintainers are not responsive to bugs. Indeed. This case is obviously not unique; there are a significant number of cases coming through the process with the shared goal of vacating the SFW consolidation of software that the project team has identified as being better suited for the /contrib repository. Perhaps it would be productive to have a discussion about this greater goal and the type of infrastructure that is needed to accomplish it. An umbrella case would be a good medium to have such a discussion. -Seb While I agree that the /contrib repository is in need of some care and feeding, it doesn't contain software that is part of the Solaris architecture. As a result, this isn't really the right forum for a discussion of /contrib. Call me confused, but the project team initially brought it up by including this in the case materials: 2. Technical Issues 2.1.Availability through OpenSolaris /contrib repository The OpenSolaris /contrib repository [1] is a more appropriate mechanism for delivering Areca Backup to interested consumers. A separate and independent project will provide Areca Backup availability through the OpenSolaris /contrib repository. I think there is perhaps general confusion about the relationship between the /contrib repository and the product. Regardless of the /contrib issue, there seems to be some overarching driver for these cases, and I'm suggesting that communicating the overall goal and plan to accomplish it separate would save every individual case from having the same kind of discussion, and would give greater context to these cases. You should be looking at each of these cases on the merit of it's architectural significance to Solaris. The intention of this case and similiar cases is to remove interfaces from the Solaris architecture that don't address a specific architectural need or where it might make sense to address a user requirement outside of the Solaris architecture. The fact that they are being added to /contrib should have little or no bearing on any recommendation you make. Perhaps that's true, but my general point is that this is something that could have been discussed in an umbrella case in order to facilitate the formulation and review of each of these piece-meal removal cases. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Fwd: PSARC/2010/139 - Removing Areca Backup
On 04/21/10 02:17 PM, Torrey McMahon wrote: On 4/21/2010 3:07 PM, Norm Jacobs wrote: You should be looking at each of these cases on the merit of it's architectural significance to Solaris. The intention of this case and similiar cases is to remove interfaces from the Solaris architecture that don't address a specific architectural need or where it might make sense to address a user requirement outside of the Solaris architecture. The fact that they are being added to /contrib should have little or no bearing on any recommendation you make. Was there a recent decision made regarding the "familiarity cases" of the last few years? I thought the idea of adding a lot of the FOSS code to Solaris, either core or sfw or contrib, was a goal in of it's self. Even if it wasn't required to solve a specific architectural problem. (sudo v rbac being one example.) The initial intention of the familiarity cases was lost in the fervor early on. Simply being an open source package should not have been sufficient cause to integrate in the WOS. Within the SFW consolidation, we are trying to rectify that by evaluating the SFW consolidation contents and identifying which components seem to make sense to retain in the WOS for architectural or other reasons and which make more sense to remove from the WOS. -Norm ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Fwd: PSARC/2010/139 - Removing Areca Backup
On 04/21/10 12:37 PM, Sebastien Roy wrote: On 04/21/10 01:19 PM, Bart Smaalders wrote: On 04/21/10 09:14, John Fischer wrote: 2.1. Availability through OpenSolaris /contrib repository The OpenSolaris /contrib repository [1] is a more appropriate mechanism for delivering Areca Backup to interested consumers. A separate and independent project will provide Areca Backup availability through the OpenSolaris /contrib repository. It seems that someone actually needs to own and maintain contrib for this plan to go forward; right now contrib is not well maintained, and maintainers are not responsive to bugs. Indeed. This case is obviously not unique; there are a significant number of cases coming through the process with the shared goal of vacating the SFW consolidation of software that the project team has identified as being better suited for the /contrib repository. Perhaps it would be productive to have a discussion about this greater goal and the type of infrastructure that is needed to accomplish it. An umbrella case would be a good medium to have such a discussion. -Seb While I agree that the /contrib repository is in need of some care and feeding, it doesn't contain software that is part of the Solaris architecture. As a result, this isn't really the right forum for a discussion of /contrib. You should be looking at each of these cases on the merit of it's architectural significance to Solaris. The intention of this case and similiar cases is to remove interfaces from the Solaris architecture that don't address a specific architectural need or where it might make sense to address a user requirement outside of the Solaris architecture. The fact that they are being added to /contrib should have little or no bearing on any recommendation you make. -Norm ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
OpenSolaris ARC Minutes - 04/21/2010
SYSTEM ARCHITECTURE COUNCIL Platform Software ARC - PSARC Regular Meeting time: Wednesdays 10:00-1:00pm in MPK17-3507. 04-21-2010 MEETING MINUTES Send CORRECTIONS, additions, deletions to psarc-co...@sun.com. Minutes are archived in sac.Eng:/sac/export/sac/Minutes/PSARC. Co-Chair(s): Sebastien Roy Yes ATTENDEES - Members: (8 active members) Aniruddh Dikhit no Arieh Markel(on sabbatical) Chris Kasso (on sabbatical) Danek Duvall(on sabbatical) Darren Moffat (on sabbatical) Garrett D'Amore no Gary WinigerYes (on sabbatical) John FischerYes (on sabbatical) Jyri Virkki no Margot Miller Yes Mark CarlsonYes Michael Kearney Yes Richard Matthewsno Bill Sommerfeld (on sabbatical) Glenn Skinner no (external) Mark Martin no (external) STAFF - Asa Romberger (PM) Yes ATTENDEES - Interns: Alan Hargreaves no Brian Cameron Yes Brian Utterback no Calum Mackayno Daniel Hain Yes Darren Reed no David Tong no Frank Che no Ienup Sung no James Falkner (on sabbatical) James Gates no James Walkerno Jeff Caino Krishna Tallapaneni no Matthias Huetschno Phi Tranno Rahul Shah no Suhasini Peddadano Wyllys Ingersollno Don Cragun Yes (external) Guests: Sowmini Varadhan -- GUESTS -- Not all names are captured. Please send email to asa.romber...@sun.com, if you attended the meeting and your name is missing from the list. --- MEETING SUMMARY: AGENDA 04/21/2010 10 minutes Open ARC Business (use open dial in above) 10 minutes Closed ARC Business (use closed dial in above) --- Case Anchors: === Fast Tracks: Fast-tracks: Case (Timeout) Exposure Title 2010/084 (03/17/10) open Perl Crypt bindings for OpenSSL approved 2010/095 (04/14/10) open More ksh93 builtins approved 2010/106 (04/14/10) open DTrace TCP and UDP providers extend to 4/28 2010/107 (04/07/10) open Removal of Drools Interfaces approved 2010/116 (04/14/10) open GDM Integration With audioctl approved 2010/121 (04/21/10) open zpool status/list interval and count approved 2010/126 (04/19/10) open Temporary ZFS mounts approved 2010/127 (04/19/10) open ipadm hostmodel property extend to 4/28 2010/129 (04/21/10) open Time Slider Phase 2 (external backup) extend to 4/28 2010/131 (04/22/10) open Adobe - flash player plugin upgrade in Solarislet it run 2010/135 (04/27/10) open Kerberos Diagnostic Enhancements (umbrella case) let it run 2010/136 (04/29/10) open NetBeans 6.9 let it run Next Meeting: = 04/28/2010 10 minutes Open ARC Business (use open dial in above) 45 minutes SER removal (2010/110) Submitter: Lukas Rovensky Owner: Peter Dennis Exposure: open 10 minutes Closed ARC Business (use closed dial in above) ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Fwd: PSARC/2010/139 - Removing Areca Backup
On 04/21/10 01:19 PM, Bart Smaalders wrote: On 04/21/10 09:14, John Fischer wrote: 2.1. Availability through OpenSolaris /contrib repository The OpenSolaris /contrib repository [1] is a more appropriate mechanism for delivering Areca Backup to interested consumers. A separate and independent project will provide Areca Backup availability through the OpenSolaris /contrib repository. It seems that someone actually needs to own and maintain contrib for this plan to go forward; right now contrib is not well maintained, and maintainers are not responsive to bugs. Indeed. This case is obviously not unique; there are a significant number of cases coming through the process with the shared goal of vacating the SFW consolidation of software that the project team has identified as being better suited for the /contrib repository. Perhaps it would be productive to have a discussion about this greater goal and the type of infrastructure that is needed to accomplish it. An umbrella case would be a good medium to have such a discussion. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: SNAP BE Management [PSARC/2010/059 opinion for review by 04/23/2010]
On 04/21/10 01:27 PM, Jim Walker wrote: (reminder - I extended this until Friday) Here is the opinion for PSARC/2010/059 SNAP BE Management. http://arc.opensolaris.org/caselog/PSARC/2010/059/opinion_draft.txt I request a commitment email vote. Suggestion: Perhaps a subject line starting with "NEED VOTE" would draw more attention. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
SNAP BE Management [PSARC/2010/059 opinion for review by 04/23/2010]
(reminder - I extended this until Friday) Here is the opinion for PSARC/2010/059 SNAP BE Management. http://arc.opensolaris.org/caselog/PSARC/2010/059/opinion_draft.txt I request a commitment email vote. Cheers, Jim ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Fwd: PSARC/2010/139 - Removing Areca Backup
On 04/21/10 09:14, John Fischer wrote: 2.1.Availability through OpenSolaris /contrib repository The OpenSolaris /contrib repository [1] is a more appropriate mechanism for delivering Areca Backup to interested consumers. A separate and independent project will provide Areca Backup availability through the OpenSolaris /contrib repository. It seems that someone actually needs to own and maintain contrib for this plan to go forward; right now contrib is not well maintained, and maintainers are not responsive to bugs. - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaald...@oracle.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/140 - removing conflict
All, The timeout is set for April 28th, 2010 and not April 21st, 2010. Thanks, John On 04/21/10 09:12 AM, John Fischer wrote: All, I am sponsoring this case for Stefan Teleman of the SFW group. I have set the timeout for Wednesday, April 21st, 2010. The case directory contains this proposal. This case proposes the removal of conflict from a Minor release of Solaris (i.e., Nevada). This component of SFW was only released in Nevada. Thanks, John ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Fwd: PSARC/2010/139 - Removing Areca Backup
All, I must be having a bad morning. The timeout is set for April 28th, 2010 and not April 21st, 2010. Thanks, John On 04/21/10 09:14 AM, John Fischer wrote: All, I am sponsoring this case for Stefan Teleman of the SFW group. I have set the timeout for Wednesday, April 21st, 2010. The case directory contains this proposal. This case proposes the removal of Areca Backup from a Minor release of Solaris (i.e., Nevada). This component of SFW was only released in Nevada. Thanks, John ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/140 - removing conflict
On Wed, Apr 21, 2010 at 09:12:03AM -0700, John Fischer wrote: > 2.Technical Issues > > 2.1.Availability through OpenSolaris /contrib repository > > The OpenSolaris /contrib repository [1] is a more appropriate > mechanism for delivering Conflict to interested consumers. > > A separate and independent project will provide Conflict > availability through the OpenSolaris /contrib repository. Is /contrib really the right home for this? conflict(1) is really useful, given the multiple, conflicting versions of tar(1), ls(1), etcetera that we ship in Solaris. A move to /contrib might be OK, but you're not even promising integration into /contrib... Nico -- ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Fwd: PSARC/2010/139 - Removing Areca Backup
All, I am sponsoring this case for Stefan Teleman of the SFW group. I have set the timeout for Wednesday, April 21st, 2010. The case directory contains this proposal. This case proposes the removal of Areca Backup from a Minor release of Solaris (i.e., Nevada). This component of SFW was only released in Nevada. Thanks, John Right-sizing the SFW Consolidation : Removing Areca Backup from SFW Stefan Teleman 19 April 2010 1. Summary and Motivation As part of the ongoing SFW Consolidation right-sizing project, this Case announces the removal of Areca Backup Version 6.0.7 from the SFW Consolidation. Areca Backup was introduced in Nevada by LSARC/2008/681 [0]. This Case relies on LSARC/2008/681 as its Reference ARC Case. All technical considerations pertaining to Areca Backup have been addressed by LSARC/2008/681. Areca Backup has never been distributed with Solaris: it was only integrated and available in Nevada. This Case seeks Micro/Patch release binding. 2. Technical Issues 2.1.Availability through OpenSolaris /contrib repository The OpenSolaris /contrib repository [1] is a more appropriate mechanism for delivering Areca Backup to interested consumers. A separate and independent project will provide Areca Backup availability through the OpenSolaris /contrib repository. 2.2.Objects subject to removal: /usr/bin/areca /usr/share/areca/areca.sh /usr/share/areca/check_version.sh /usr/share/areca/readme.txt /usr/share/areca/bin/decrypt.sh /usr/share/areca/bin/dezip.sh /usr/share/areca/bin/run_gui.sh /usr/share/areca/bin/run_tui.sh /usr/share/areca/lib/activation.jar /usr/share/areca/lib/areca.jar /usr/share/areca/lib/commons-net-1.4.1.jar /usr/share/areca/lib/jakarta-oro-2.0.8.jar /usr/share/areca/lib/local_policy.jar /usr/share/areca/lib/mail.jar /usr/share/areca/doc/index.html /usr/share/areca/help/advanced_encryption_howto.txt /usr/share/areca/help/help.txt /usr/share/areca/icons /usr/share/areca/config/Main.xml /usr/share/areca/config/fwk.properties /usr/share/areca/plugins /usr/share/areca/license/license.txt /usr/share/areca/translations 3. Interfaces 3.1.Interfaces subject to removal: Exported Interface Classification Interface Type == == == SUNWareca Uncommitted Package name /usr/bin/areca Uncommitted Command 4. References [0] LSARC/2008/681 [1] http://pkg.opensolaris.org/contrib/ ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
PSARC/2010/140 - removing conflict
All, I am sponsoring this case for Stefan Teleman of the SFW group. I have set the timeout for Wednesday, April 21st, 2010. The case directory contains this proposal. This case proposes the removal of conflict from a Minor release of Solaris (i.e., Nevada). This component of SFW was only released in Nevada. Thanks, John Right-sizing the SFW Consolidation : Removing Conflict from SFW Stefan Teleman 19 April 2010 1. Summary and Motivation As part of the ongoing SFW Consolidation right-sizing project, this Case announces the removal of Conflict Version 6.0 from the SFW Consolidation. Conflict was introduced in Nevada by PSARC/2009/003 [0]. This Case relies on PSARC/2009/003 as its Reference ARC Case. All technical considerations pertaining to Conflict have been addressed by PSARC/2009/003. Conflict has never been distributed with Solaris: it was only integrated and available in Nevada. This Case seeks Micro/Patch release binding. 2. Technical Issues 2.1.Availability through OpenSolaris /contrib repository The OpenSolaris /contrib repository [1] is a more appropriate mechanism for delivering Conflict to interested consumers. A separate and independent project will provide Conflict availability through the OpenSolaris /contrib repository. 2.2.Objects subject to removal: /usr/bin/conflict /usr/share/man/man1/conflict.1 3. Interfaces 3.1.Interfaces subject to removal: Exported Interface Classification Interface Type == == == SUNWconflictUncommitted Package name /usr/bin/conflict Uncommitted Command 4. References [0] PSARC/2009/003 [1] http://pkg.opensolaris.org/contrib/ ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/139 - Removing Conflict
All, Please disregard this email on removing conflict as I got the wrong case number. I will send out the corrected case number shortly. Sorry, John On 04/21/10 09:06 AM, John Fischer wrote: All, I am sponsoring this case for Stefan Teleman of the SFW group. I have set the timeout for Wednesday, April 21st, 2010. The case directory contains this proposal. This case proposes the removal of conflict from a Minor release of Solaris (i.e., Nevada). This component of SFW was only released in Nevada. Thanks, John ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
PSARC/2010/139 - Removing Conflict
All, I am sponsoring this case for Stefan Teleman of the SFW group. I have set the timeout for Wednesday, April 21st, 2010. The case directory contains this proposal. This case proposes the removal of conflict from a Minor release of Solaris (i.e., Nevada). This component of SFW was only released in Nevada. Thanks, John Right-sizing the SFW Consolidation : Removing Conflict from SFW Stefan Teleman 19 April 2010 1. Summary and Motivation As part of the ongoing SFW Consolidation right-sizing project, this Case announces the removal of Conflict Version 6.0 from the SFW Consolidation. Conflict was introduced in Nevada by PSARC/2009/003 [0]. This Case relies on PSARC/2009/003 as its Reference ARC Case. All technical considerations pertaining to Conflict have been addressed by PSARC/2009/003. Conflict has never been distributed with Solaris: it was only integrated and available in Nevada. This Case seeks Micro/Patch release binding. 2. Technical Issues 2.1.Availability through OpenSolaris /contrib repository The OpenSolaris /contrib repository [1] is a more appropriate mechanism for delivering Conflict to interested consumers. A separate and independent project will provide Conflict availability through the OpenSolaris /contrib repository. 2.2.Objects subject to removal: /usr/bin/conflict /usr/share/man/man1/conflict.1 3. Interfaces 3.1.Interfaces subject to removal: Exported Interface Classification Interface Type == == == SUNWconflictUncommitted Package name /usr/bin/conflict Uncommitted Command 4. References [0] PSARC/2009/003 [1] http://pkg.opensolaris.org/contrib/ ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
PSARC/2010/138 - pkgbuild build engine
All, I am sponsoring this case for Laszlo (Laca) Peter of the desktop group. I have set the timeout for Wednesday, April 21st, 2010. The case directory contains this proposal. This case proposes to integrate pkgbuild into a Minor release of Solaris. pkgbuild is the build engine developed by the desktop release engineering team to build the desktop components. It is similar to rpmbuild for linux. Thanks, John Title: pkgbuild build engine Case: PSARC/2010/138 Submitter: Laszlo (Laca) Peter Owner: John Fischer Timeout:04/28/2010 1.0 Introduction 1.1 Project/Component Working Name: pkgbuild build engine 1.2 Purpose This project delivers the pkgbuild build engine into OpenSolaris. Minor release binding is requested. 2.0 Summary Description pkgbuild is a build engine developed by the Desktop Release Engineering team. It has been used for building the Desktop components of Solaris/ OpenSolaris since 2004. It is also used for building the OpenSolaris /contrib package repository. 2.1 Detailed Description The original purpose of pkgbuild was to facilitate delivering identical code using very similar build procedures on an RPM-based Linux system (JDS) and on Solaris. For this reason, the input of pkgbuild is a spec file[1] similar to RPM's. pkgbuild also has the same CLI and the same output format as rpmbuild, making it familiar to developers who have a background in Linux/RPM packaging. A complete pkgbuild build of a component consists of the following steps (corresponding spec file sections in parentheses): o set up source tree (%prep section) - unpack sources - apply source changes/patches o configure and compile the sources (%build) o install the binaries to a temporary proto area (%install) o generate package prototypes / manifests and create / publish packages All of the above steps are identical to rpmbuild's behaviour, the difference is the end result, which is a source RPM and one or more binary RPMs in the case of rpmbuild, and a source package and one or more binary packages (SVr4 and/or IPS) in the case of pkgbuild. The spec file includes all metainformation required for the above steps, including the location of the sources (a URL), patch names, build-time and runtime dependencies, IPS tags, attributes, actions. pkgbuild builds a single component at a time. It looks for sources (source bundles, individual files, patches and copyright files) in %_topdir/SOURCES. (%_topdir is macro that defines the location of the root of the build area). Additional spec files that may be used included using %include or %use statements must be located in %_topdir/SPECS. The build is performed in a subdirectory under the %_topdir/BUILD directory. Dynamically created SVr4 prototype, pkginfo, depend files, package scripts (e.g. CAS or postinstall) and IPS manifest files are created under %_topdir/PKGMAPS. SVr4 packages are created in %_topdir/PKGS and SVr4 "source packages" under %_topdir/SPKGS. Source packages include all files required for reproducing the build (specs, sources bundles, patches, etc). pkgbuild can automatically rebuild source packages using pkgbuild --rebuild /path/to/source_package IPS packages are published in the repository specified by the PKGBUILD_IPS_SERVER environment variable, or the local repository, if running (as determined using smf commands). Source IPS packages are published in $PKGBUILD_SRC_IPS_SERVER or PKGBUILD_IPS_SERVER or the local IPS repository. At this time, pkgbuild is not able to automatically rebuild IPS source packages, however, it is possible to install the source package (will get installed under /usr/share/src) and then rebuild the package using pkgbuild --rebuild /usr/share/src/ A higher level build script, pkgtool is provided for various convenience functions: o download sources o locate previously downloaded sources and copy them to where pkgbuild expects them o build/install a number of spec files in the order determined by the dependency information in the given spec files o collect log files o send emails about build failures o compile build reports The spec files used by pkgbuild and RPM are not fully compatible because pkgbuild needs to accommodate for the differences. These differences are documented on the pkgbuild web site[2]. Full spec file documentation is not provided, because there is already a wealth of information available for rpm spec files. spectool is a command line utility intended for parsing spec files and querying information from that for the purpose of scripting or embedding the pkgbuild utilities in larger systems.
Re: PSARC 2010/095 More ksh93 builtins
On 03/31/10 12:19 PM, Garrett D'Amore wrote: The project team has decided to change the proposal to remove the contentious builtins for /usr/gnu. Instead, only /usr/bin and /usr/xpg4,xpg6 utilities are being provided as builtins. As these utilities will hopefully one day be converted to use the same underlying libcmd interface, this should not be contentious. I'm restarting the timeout for one week from today (timeout expires April 7). The revised spec follows. Given that this case is building upon pre-existing built-in architecture, I don't have any issues specific to this case that should hold it up. +1 That said, I think one thread of substance from the lengthy discussion this case spawned relates to the duplicity of code between the commands and their built-in equivalents. This is more a commentary of the implementation of built-ins in general, and not of the specific built-ins introduced by this case. Having architecture introduced to allow a shared implementation (as Garrett hopes will be the case with libcmd above) would be a good thing. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
SER removal [PSARC/2010/110]
Updated proposal has been put into the case and is included below. This case has been scheduled for the PSARC meeting of 28-April-2010. Thanks pete 1. Introduction 1.1 Project/Component Working Name: SER removal 1.2 Name of Document Author/Supplier: Author: Lukas Rovensky 1.3 Date of This Document: 19 March, 2010 1.4 The requested release taxonomy: Patch binding for the announcement and marking as Obsolete. Minor binding for the removal. 1.5 Introduction This FastTrack will EOF the Sip Express Router (SER) and its web based interface -- SERWeb -- from Solaris Next and obsolete SER and SERWeb in Solaris 10. On November 4th 2008 a new SIP Router project was announced and joined by SER developers, [1]. This also means that SER itself is no longer developed in favour of the SIP Router, [2]. Since SER is no longer developed product it shall be removed from Solaris Next. Should a similar product be required then the SIP Router (Kamailio) may be a good candidate. Note, that attributes(5) documents an exceptio, which can apply to this case: 4. An interface specification which isn't controlled by Sun has been changed incompatibly and the vast majority of interface consumers expect the newer interface. 1.6 Previous Relevant ARC cases LSARC/2004/324 - sfw/SIP Proxy Server (actually still in waiting state), [3] 1.7 SIP Status In Solaris, RFC 3261 SER itself provides functionality, which implements SIP protocol, RFC 3261, [8]. There are currently also two libraries in Solaris, which implement the SIP protocol (RFC 3261, [8]) and can be eventually used for implementation of SIP routing: * libsip (also in S10, since U4), PSARC 2006/402, [4], CR 6461142, [5] This library is developed by Oracle and it is available both in Solaris 10 and OpenSolaris / Solaris Next. As per the responsible engineer, there is at least one customer, who had built its application using libsip. * libosip2, LSARC 2009/277, [6], CR 6826484, [7] This is an open sourse library, [9]. There are no further plans with this library as per the responsible engineer. 1.8 Input From Marketing, Usage of SER Marketing was informed about the intention to remove SER from Solaris Next. They do not seem to have any real data, which would support or deny this action. Their current position is as the following: "Right now, I agree with the general position that SER seems like an unsupported offering and we should drop it, however we do need to assess if we should and who should pick up SIP router." The I-team also tried to approach OS Ambassadors (sig...@sun.com) to get more info about SER usage but no one provided any data. The I-team also looked at IPS download statistics maintained by Stephen Hahn and by end of February 2010 SER reached 24813 downloads as part of OpenSolaris. 2. Documentation Obsoleting SER and SERWeb in Solaris 10 will be announced in release notes for Solaris 10. Interface Stability in SER man page (ser(8)) in Solaris 10 will be set to "Obsolete, External". 3. Packaging and Delivery SUNWserr, SUNWseru and SUNWserweb packages will be removed from OpenSolaris. This does mean that the renamed packages will no longer be delivered (service:network:sip:ser and service:network:sip:ser:administration). 4. Interfaces All the interfaces described below will be obsoleted in Solaris 10 and removed from OpenSolars / SNV. The following files and directories (including all their content) will be removed from OpenSolaris / SNV: /usr/sfw/sbin/ser /usr/sfw/sbin/serctl /usr/sfw/lib/ser/ /usr/sfw/share/doc/ser/ /etc/sfw/ser/ /usr/sfw/share/serweb/ 5. References [1] http://sip-router.org/2008/11/04/the-sip-router-project-launched/ [2] http://sip-router.org/ [3] http://sac.sfbay/LSARC/2004/324/ [4] http://sac.sfbay/PSARC/2006/402/ http://arc.opensolaris.org/caselog/PSARC/2006/402/ [5] http://monaco.sfbay/detail.jsf?cr=6461142-2145051 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6461142 [6] http://sac.sfbay/LSARC/2009/277/ http://arc.opensolaris.org/caselog/LSARC/2009/277/ [7] http://monaco.sfbay/detail.jsf?cr=6826484 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6826484 [8] http://www.ietf.org/rfc/rfc3261.txt [9] http://www.gnu.org/software/osip/ 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: sfw 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
