Re: libpng 1.4.3 [PSARC/2010/313 Self Review]
All,
I am sponsoring this case for Laszlo (Laca) Peter from
the desktop group. I have made this an automatic approval
if anyone is concerned with that then I'll set a timer for
next week. Just let me know. The case directory contains
this proposal and a couple of documents from the community
describing the changes to the library.
This project delivers the latest version of libpng, version
1.4.3 into Solaris. It also updates the legacy 1.2.x and
1.0.y versions to the latest micro releases: 1.2.44 and 1.0.54.
Patch release binding is requested.
Thanks,
John
Title: libpng 1.4.3
Case: PSARC/2010/313
Submitter: Laszlo Peter
Owner: John Fischer
Timeout:Automatic
1.0 Introduction
1.1 Project/Component Working Name:
libpng 1.4.3 for Solaris
1.2 Purpose
This project delivers the latest version of libpng, version 1.4.3
into Solaris. It also updates the legacy 1.2.x and 1.0.y versions
to the latest micro releases: 1.2.44 and 1.0.54.
Patch release binding is requested.
2.0 Description
libpng is a widely used C library for working with Portable Network
Graphics images. It has multiple mostly API-compatible, but
ABI-incompatible branches. They are parallel installable, but one
is the default for development purposes. Currently libpng 1.2.x
is the default branch. This update makes the 1.4.x branch the
default one.
2.1 Security Issues Addressed
These libpng releases incorporate security fixes:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1205
An additional memory-leak bug, involving images with malformed
sCAL chunks, is also present; it could lead to an application
crash (denial of service) when viewing such images.
2.2 Additional Changes
The differences between the 1.4 and 1.2 branches are detailed in
libpng-ANNOUNCE-1.4.1.txt in the case directory.
A comprehensive list of changes from release to release is
in libpng-CHANGES.txt in the case directory.
3.0 Delivery
This project is targetting a Patch release of the Solaris OS.
Availability and file locations:
+--+---+
| Package name |File locations |
+--+---+
| SUNWpng | /usr/lib/libpng14.so.14 |
| | /usr/lib/{amd64,sparcv9}/libpng14.so.14 |
| IPS: | /usr/lib/libpng12.so.0|
| image/library/libpng | /usr/lib/{amd64,sparcv9}/libpng12.so.0|
| | /usr/lib/libpng10.so.0|
| | /usr/lib/{amd64,sparcv9}/libpng10.so.0|
+--+---+
| SUNWpng-devel| /usr/bin/libpng-config - libpng14-config |
| | /usr/bin/{amd64,sparcv9}/libpng-config|
| IPS: | /usr/bin/libpng1[024]-config |
| image/library/libpng | /usr/bin/{amd64,sparcv9}/libpng1[024]-config |
| | /usr/include/libpng - libpng14 |
| | /usr/include/libpng1[024] |
| | /usr/lib/pkgconfig/libpng.pc - libpng14.pc |
| | /usr/lib/pkgconfig/libpng1[024].pc|
| | /usr/lib/{amd64,sparcv9}/pkgconfig/libpng.pc |
| | - libpng14.pc|
| | /usr/lib/{amd64,sparcv9}/pkgconfig/ |
| | libpng1[024].pc |
+--+---+
4.0 Interface Classification
The project exports the following interfaces:
+---+
| Interfaces Exported |
+--++---+
| Interface Name | Classification | Comment |
+--++---+
| libpng14.so.14 | Committed | |
| libpng12.so.0| Obsolete Committed | LSARC/2003/085|
| libpng10.so.0| Obsolete Committed | LSARC/2003/085|
+--++---+
| SUNWpng | Committed | package names |
| SUNWpng-devel| Committed | |
| image/library/libpng | Committed
Re: Adobe Reader 9.x on S10 x86 [PSARC/2010/256 FastTrack timeout 07/14/2010]
On 07/ 3/10 07:54 AM, Alan Coopersmith wrote: John Fischer wrote: Will this also be delivered into the extra repository for OpenSolaris as was done in the SPARC case? The Acrobat reader has never been delivered into the extra repository for either platform, due to non-architectural reasons we are unable to discuss on the public lists. Alrighty then, +1. John ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233, FastTrack timeout, 06/30/2010]
Rich, Sounds good. You still have my +1. John On 07/ 1/10 08:39 AM, Rich Burridge wrote: What sort of announcement will be made in a Patch release of Solaris? Will this be release noted? Will the man pages be updated to include a warning? Other? It will be documented via a release note in a Patch release of Solaris. The P-Team and marketing will help craft the wording. It will also be announced to engineering in a flag day announcement Unless otherwise directed by either the C-Team or the P-Team, we are not planning to put a warning into the manual pages, because this functionality was only available on x86 and not SPARC, and because you typically had to set the SYSV3 environment variable to enable it. Other then that +1. Thanks. ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233, FastTrack timeout, 06/30/2010]
Rich, What sort of announcement will be made in a Patch release of Solaris? Will this be release noted? Will the man pages be updated to include a warning? Other? Other then that +1. John ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: System Configuration -- nodename and defaultdomain [PSARC/2010/223 FastTrack timeout 06/25/2010]
All, Still looking for a +1 on the updated proposal. Thanks, John ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: System Configuration -- nodename and defaultdomain [PSARC/2010/223 FastTrack timeout 06/25/2010]
All, After some off list email exchanges with Darrin I have updated the proposal to include a migration path to the new SMF service property. Diffs below as is the updated proposal. Thanks, John *** arc-proposal-v2.txtTue Jun 22 08:56:39 2010 --- arc-proposal-v3.txtFri Jun 25 11:28:55 2010 *** *** 28,34 1. Add the nodename property to the svc:/system/identity:node SMF service. The property definition (config/nodename) will be added in the SMF manifest. !Update the identity-node method to use the new property. 2. RBAC for nodename access to include solaris.smf.manage.nodename as the authorization and with a profile description of Node Name Management. --- 28,37 1. Add the nodename property to the svc:/system/identity:node SMF service. The property definition (config/nodename) will be added in the SMF manifest. !Update the identity-node method to use the new property. If the property !does not exist within the SMF service and /etc/nodename is present then !the identity-node method will migrate /etc/nodename into the SMF service !and remove the file. 2. RBAC for nodename access to include solaris.smf.manage.nodename as the authorization and with a profile description of Node Name Management. Background == Currently the nodename configuration is stored in the /etc/nodename file. During installation, the installer will prompt the user for the nodename and save the configuration into the /etc/nodename file. When the system boots up, if the system is standalone or the IP address is configured locally, the /etc/nodename file contains the system name. Users can modify the file /etc/nodename to change the hostname for a standalone system or if the IP address is configured locally. In such a case the change will take effect at next boot. Problem Statement = Update the svc:/system/identity:node SMF service which will take care of setting the nodename of the system installed by means of the Installer technologies. Furthermore, update various components that currently reference /etc/nodename to use the new mechanism, namely cvcd, setuname, metaset and nodename(4) for nodename. Requirement === The nodename will be configurable via SMF property of svc:/system/identity:node SMF service. Proposal 1. Add the nodename property to the svc:/system/identity:node SMF service. The property definition (config/nodename) will be added in the SMF manifest. Update the identity-node method to use the new property. If the property does not exist within the SMF service and /etc/nodename is present then the identity-node method will migrate /etc/nodename into the SMF service and remove the file. 2. RBAC for nodename access to include solaris.smf.manage.nodename as the authorization and with a profile description of Node Name Management. 3. Update the various Caiman installers to use the new property. 4. Obsolete file /etc/nodename. This file will no longer exist in the system 5. Modify existing /etc/nodename consumers, so that they operate on the SMF property instead of the file. The following consumers were found in the ON gate: cvcd setuname metaset Other consolidations will receive a flag day announcement and be given 2 builds prior to the removal of the nodename file. 6. Update appropriate man pages: nodename(4) metaset(1M) 7. Make appropriate announcements in a Patch release of Solaris and to internal development aliases. Interfaces == Exported Interfaces NameCommitment Comments --- svc:/system/identity:node Committed SMF service name config/nodename SMF property identity-domain SMF service method solaris.smf.manage.nodename Committed RBAC authorization property /etc/nodename Removed Obsolete in a Patch release Text Installer Uncommitted PSARC/2010/165 GUI Installer Uncommitted PSARC 2007/284, PSARC/2010/069 cvcdUncommitted virtual console daemon setunameRemoved change machine information utility, used for an old standard, Obsolete in a Patch release. metaset Committed configure disk sets utility
Re: System Configuration -- nodename and defaultdomain [PSARC/2010/223 FastTrack timeout 06/25/2010]
Still looking for a +1 on the new proposal. Thanks, John On 06/23/10 11:24 AM, John Fischer wrote: Darren, Right. This case could have the data in /etc files and migrate the information into SMF. There are several ways to deal with System Configuration: 1. simply use files 2. use files and migrate configuration into SMF from file 3. use SMF for configuration and have files as compatibility 4. use SMF only 5. other (there are always other ways of doing things) During the design phase discussion we did not see that large of a hit by using the SMF only method especially since nodename is only used for standalone or the IP address is configured locally. Thus in certain cases /etc/nodename is not a guarantee that the hostname is the same as what is in the file. Since this is the case scripts should really be using 'uname -n' to determine the hostname. When we couple the hit that the customer is taking in the upgrade migration from Solaris 10 it was decided that now was the time to make this sort of change. Thanks, John On 06/23/10 10:54 AM, Darren J Moffat wrote: On 23/06/2010 17:25, John Fischer wrote: I understand that this change will break some scripts that admins or developers have. However, as someone has already pointed out the decision to move this direction was made in the original greenline case. We are simply executing on one aspect of that strategy. You are but there are is also precedence in other cases where data has been moved from a file in /etc to SMF. In some of those other cases the approach was taken to load the data in the /etc file(s) into SMF. Could this case possibly do that type of thing ? On 06/22/10 02:29 PM, Peter Tribble wrote: On Sat, Jun 19, 2010 at 9:25 PM, James Carlsoncarls...@workingcode.com wrote: On 6/19/10 6:52 AM, Volker A. Brandt wrote: 3. Obsolete file /etc/nodename. This file will no longer exist in the system This will break 1000s of LOC of scripts. I am sure you have considered the consequences your customers will be facing, and have decided that your gain outweighs their loss... Really? I can't say I've ever seen a script that reads /etc/nodename in preference to using uname -n output, nor can I find any. Providing a pointer to one would probably help focus the discussion. I had several admin scripts that I wrote, nothing major. I would prefer to use `uname -n`, but after about the third time that I found a system thinking it was called --fqdn I started to mistrust uname -n, as it can be accidentally set to something other than the real name of the system by incautious admins or applications, and looked at /etc/nodename as a more reliable source of what the hostname was *supposed* to be. ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: System Configuration -- nodename and defaultdomain [PSARC/2010/223 FastTrack timeout 06/25/2010]
Octave, Again, if a SA is using /etc/nodename to determine the hostname via a script then they are using an inherently broken method to determine it. The reason being is that /etc/nodename only covers a standalone system or an IP address that is configured locally. /etc/nodename does not cover network booted (DHCP or RARP/bootparams) systems. Thanks, John On 06/24/10 09:33 AM, Octave Orgeron wrote: Hi, What would probably make sense is to maintain the config file method and have SMF load it. However, I'd also propose the to SMF the ability to dump such variables back to the standard configuration files. This could be a good compromise and also give SA's the ability to backup and restore the configuration of a server through SMF. Octave *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Virtualization Architect and Consultant Web: http://unixconsole.blogspot.com E-Mail: unixcons...@yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* - Original Message From: John Fischerjohn.fisc...@oracle.com To: psarc-...@sun.com Cc: Dave Minerdave.mi...@oracle.com Sent: Thu, June 24, 2010 10:18:07 AM Subject: Re: System Configuration -- nodename and defaultdomain [PSARC/2010/223 FastTrack timeout 06/25/2010] Still looking for a +1 on the new proposal. Thanks, John On 06/23/10 11:24 AM, John Fischer wrote: Darren, Right. This case could have the data in /etc files and migrate the information into SMF. There are several ways to deal with System Configuration: 1. simply use files 2. use files and migrate configuration into SMF from file 3. use SMF for configuration and have files as compatibility 4. use SMF only 5. other (there are always other ways of doing things) During the design phase discussion we did not see that large of a hit by using the SMF only method especially since nodename is only used for standalone or the IP address is configured locally. Thus in certain cases /etc/nodename is not a guarantee that the hostname is the same as what is in the file. Since this is the case scripts should really be using 'uname -n' to determine the hostname. When we couple the hit that the customer is taking in the upgrade migration from Solaris 10 it was decided that now was the time to make this sort of change. Thanks, John On 06/23/10 10:54 AM, Darren J Moffat wrote: On 23/06/2010 17:25, John Fischer wrote: I understand that this change will break some scripts that admins or developers have. However, as someone has already pointed out the decision to move this direction was made in the original greenline case. We are simply executing on one aspect of that strategy. You are but there are is also precedence in other cases where data has been moved from a file in /etc to SMF. In some of those other cases the approach was taken to load the data in the /etc file(s) into SMF. Could this case possibly do that type of thing ? On 06/22/10 02:29 PM, Peter Tribble wrote: On Sat, Jun 19, 2010 at 9:25 PM, James Carlsoncarls...@workingcode.com wrote: On 6/19/10 6:52 AM, Volker A. Brandt wrote: 3. Obsolete file /etc/nodename. This file will no longer exist in the system This will break 1000s of LOC of scripts. I am sure you have considered the consequences your customers will be facing, and have decided that your gain outweighs their loss... Really? I can't say I've ever seen a script that reads /etc/nodename in preference to using uname -n output, nor can I find any. Providing a pointer to one would probably help focus the discussion. I had several admin scripts that I wrote, nothing major. I would prefer to use `uname -n`, but after about the third time that I found a system thinking it was called --fqdn I started to mistrust uname -n, as it can be accidentally set to something other than the real name of the system by incautious admins or applications, and looked at /etc/nodename as a more reliable source of what the hostname was *supposed* to be. ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/165 - OpenSolaris Text Installer email vote...
All, We have another vote besides myself (Thank you Darren). I am still waiting on a vote on the case by COB on Wednesday, June 30th, 2010. The contracts are in process. The contract for the ncurses usage is signed and has been place in the ncurses (LSARC 2008/524) case directory. The libzoneinfo contract is an extension of an existing contract to use an additional interface (isvalid_tz()). I expect this to be signed as soon as the responsible manager returns from vacation. The importing manager (Dana Barsan) has already signed the contract. Thus I believe that there are no outstanding issues for the case. Thanks, John On 06/21/10 01:10 AM, Darren J Moffat wrote: I vote to approve (I wasn't present at the meeting but I have reviewed the materials and opinion). ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/165 - OpenSolaris Text Installer email vote...
Thanks!! On 06/23/10 09:54 AM, Sebastien Roy wrote: On 06/17/10 09:17 PM, John Fischer wrote: Please review these new materials and the draft opinion. Either provide feedback or vote on the case by COB Wednesday, June 30th, 2010. My vote is approve. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: System Configuration -- nodename and defaultdomain [PSARC/2010/223 FastTrack timeout 06/25/2010]
Darren, Right. This case could have the data in /etc files and migrate the information into SMF. There are several ways to deal with System Configuration: 1. simply use files 2. use files and migrate configuration into SMF from file 3. use SMF for configuration and have files as compatibility 4. use SMF only 5. other (there are always other ways of doing things) During the design phase discussion we did not see that large of a hit by using the SMF only method especially since nodename is only used for standalone or the IP address is configured locally. Thus in certain cases /etc/nodename is not a guarantee that the hostname is the same as what is in the file. Since this is the case scripts should really be using 'uname -n' to determine the hostname. When we couple the hit that the customer is taking in the upgrade migration from Solaris 10 it was decided that now was the time to make this sort of change. Thanks, John On 06/23/10 10:54 AM, Darren J Moffat wrote: On 23/06/2010 17:25, John Fischer wrote: I understand that this change will break some scripts that admins or developers have. However, as someone has already pointed out the decision to move this direction was made in the original greenline case. We are simply executing on one aspect of that strategy. You are but there are is also precedence in other cases where data has been moved from a file in /etc to SMF. In some of those other cases the approach was taken to load the data in the /etc file(s) into SMF. Could this case possibly do that type of thing ? On 06/22/10 02:29 PM, Peter Tribble wrote: On Sat, Jun 19, 2010 at 9:25 PM, James Carlsoncarls...@workingcode.com wrote: On 6/19/10 6:52 AM, Volker A. Brandt wrote: 3. Obsolete file /etc/nodename. This file will no longer exist in the system This will break 1000s of LOC of scripts. I am sure you have considered the consequences your customers will be facing, and have decided that your gain outweighs their loss... Really? I can't say I've ever seen a script that reads /etc/nodename in preference to using uname -n output, nor can I find any. Providing a pointer to one would probably help focus the discussion. I had several admin scripts that I wrote, nothing major. I would prefer to use `uname -n`, but after about the third time that I found a system thinking it was called --fqdn I started to mistrust uname -n, as it can be accidentally set to something other than the real name of the system by incautious admins or applications, and looked at /etc/nodename as a more reliable source of what the hostname was *supposed* to be. ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: System Configuration -- nodename and defaultdomain [PSARC/2010/223 FastTrack timeout 06/25/2010]
Richard, Kyle and Nico, After speaking with Doug Leavitt from the naming group within Oracle I am removing the defaultdomain portion of the project. The naming group at some point in the future will address defaultdomain system configuration. Updated materials are in the case directory and the proposal is below. The proposal is now only for node configuration to be an SMF property. Thanks, John Background == Currently the nodename configuration is stored in the /etc/nodename file. During installation, the installer will prompt the user for the nodename and save the configuration into the /etc/nodename file. When the system boots up, if the system is standalone or the IP address is configured locally, the /etc/nodename file contains the system name. Users can modify the file /etc/nodename to change the hostname for a standalone system or if the IP address is configured locally. In such a case the change will take effect at next boot. Problem Statement = Update the svc:/system/identity:node SMF service which will take care of setting the nodename of the system installed by means of the Installer technologies. Furthermore, update various components that currently reference /etc/nodename to use the new mechanism, namely cvcd, setuname, metaset and nodename(4) for nodename. Requirement === The nodename will be configurable via SMF property of svc:/system/identity:node SMF service. Proposal 1. Add the nodename property to the svc:/system/identity:node SMF service. The property definition (config/nodename) will be added in the SMF manifest. Update the identity-node method to use the new property. 2. RBAC for nodename access to include solaris.smf.manage.nodename as the authorization and with a profile description of Node Name Management. 3. Update the various Caiman installers to use the new property. 4. Obsolete file /etc/nodename. This file will no longer exist in the system 5. Modify existing /etc/nodename consumers, so that they operate on the SMF property instead of the file. The following consumers were found in the ON gate: cvcd setuname metaset Other consolidations will receive a flag day announcement and be given 2 builds prior to the removal of the nodename file. 6. Update appropriate man pages: nodename(4) metaset(1M) 7. Make appropriate announcements in a Patch release of Solaris and to internal development aliases. Interfaces == Exported Interfaces NameCommitment Comments --- svc:/system/identity:node Committed SMF service name config/nodename SMF property identity-domain SMF service method solaris.smf.manage.nodename Committed RBAC authorization property /etc/nodename Removed Obsolete in a Patch release Text Installer Uncommitted PSARC/2010/165 GUI Installer Uncommitted PSARC 2007/284, PSARC/2010/069 cvcdUncommitted virtual console daemon setunameRemoved change machine information utility, used for an old standard, Obsolete in a Patch release. metaset Committed configure disk sets utility man pages Uncommitted nodename(4) metaset(1M) Imported Interfaces NameCommitment Comments --- uname Uncommitted libscf Committed Service Configuration Facility Library Functions References == [1] Example of SMF profile configuring nodename property service_bundle type=profile name=default service name=system/identity version=1 type=service instance name=node enabled=true !-- The following property group is used at install time to configure the nodename for the system -- property_group name=config type=application propval name=nodename type=astring value=unknown/ /property_group /instance /service /service_bundle [2] Related SMF System Configuration cases PSARC 2010/183 Kernel Keyboard Configuration in SMF PSARC 2010/164 interfaces for basic install network configuration On 06/21/10 10:45 AM, John Fischer wrote: On 06/19/10 05:12 PM, Richard Elling wrote: On Jun 18, 2010, at 2:34 PM, John Fischer wrote: 5. Add the defaultdomain property to the svc:/system/identity:domain SMF service. The property definition (config/defaultdomain) will be added in the SMF manifest. Update the identity-domain
Re: System Configuration -- nodename and defaultdomain [PSARC/2010/223 FastTrack timeout 06/25/2010]
On 06/19/10 05:12 PM, Richard Elling wrote: On Jun 18, 2010, at 2:34 PM, John Fischer wrote: 5. Add the defaultdomain property to the svc:/system/identity:domain SMF service. The property definition (config/defaultdomain) will be added in the SMF manifest. Update the identity-domain method to use the new property. Since defaultdomain is already overloaded, would it not be preferable to set the NIS default domain in the nis/client service, LDAP defaultdomain in the ldap/client, etc.? In practice, I find very few sites where the NIS, LDAP, NFSv4, and DNS domains are the same and invariably I have to explain to the sysadmins why defaultdomain exists solely to increase their misery. -- richard Richard, I am checking with some other folks about this issue. As soon as I complete the discussion I'll summarize it for the committee. Thanks, John ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/165 - OpenSolaris Text Installer email vote...
PSARC members,
Updated opinion based upon feedback provided.
Case directory is updated.
Thanks,
John
?Oracle
Systems Architecture Committee
Oracle Proprietary/Need to Know
Subject: OpenSolaris Text Installer
Submitted by:Susan Sohn
File:
PSARC/2010/165/opinion.html
Date: TBD
Committee:John Fischer, TBD.
Product Approval Committee: N/A
1. Summary
The Text Installer is a mouseless, screen-oriented installer designed
for use
on SPARC and x86 systems that may not have graphics support such as many
server-class machines.
2. Decision Precedence Information
The project is approved as specified in reference [1].
The project may be delivered in a minor release of the ON Consolidation.
3. Interfaces
The project exports the following interfaces.
Interfaces Exported
Interface
Classification Comments
---
---
/usr/lib/text-install
UncommittedCLI
system/install/text-install
CommittedIPS package name
${root}/lib/python2.6/vendor-packages/\ Consolidation Python to C
bridge
osol_install/tgt.so
Private to Target
Instantiation and
Target Discovery
${root}/lib/python2.6/vendor-packages/\ Consolidation Python to C
bridge
osol_install/libzoneinfo.so
Private to /usr/lib/\
libzoneinfo.so
system/install-setup:default UncommittedSMF
Install service
The project imports the following interfaces.
Interfaces Imported
Interface Classification Comments
---
-
libzoneinfo.so.1 Contracted Private LSARC/2001/015
Python2.6 Uncommitted PSARC/2009/043
libdiskmgt.so.1 Consolidation LSARC/2004/743
Private
Distribution Constructor CommittedPSARC/2009/471
libncurses.soContracted Volatile LSARC/2008/524
menu.lst (grub)CommittedPSARC/2004/454
4. Opinion
This project had a successful inception review which did not have any major
concerns that could not be corrected by specification updates. Thus the
case
was approved by updating those specifications and taking an email vote. The
issues listed below reflect the substantial inception review issues.
4.1 Static IP and IPv6 Networking
The inception UI specifications discussed the longer term UI for setting
up the
various NICs. The project team stated that the current review was based
upon
allowing networking to be setup via NWAM or not established. Static and
IPv6
configurations will be reviewed in a future fast track and be based upon
the
interfaces for basic install network configuration case (PSARC/2010/164).
There will be documentation in the commitment materials explaining that the
Static IP and IPv6 Network section of the UI specification are not
covered by
this case (reference [2]). The committee was fine with the OpenSolaris Text
Installer not being dependent upon that case and following up with a
fast track.
4.2 text-install Command Installation Location
As specified the project installs text-installer into /usr/bin. When
questioned
about the usage of the command the project team stated that there are a
few edge
use cases where the end user might execute the command from a command
line. The
majority of uses would simply be to insert a disc and the text-installer
automatically starts on boot. The committee stated that perhaps a better
installation location might be /usr/lib. The project team has decided to
install
the text-installer into the /usr/lib directory. The committee was fine
with the
resolution of this issue.
4.3 Root and User Passwords Not Required
The committee noted that the root and user passwords are not required at
install
time. The project team stated that they were following current Best
Practices
with regards to installation technologies. The installation user is
warned that
the system will be installed in an unsafe manner. The committee was fine
with
the issue.
4.4
Re: PSARC/2010/165 - OpenSolaris Text Installer email vote...
PSARC members,
Updated opinion includes grub.lst taxonomy updated to Committed
and Primary Administrator Rights Profile discussion updated.
Thanks,
John
Oracle
Systems Architecture Committee
Oracle Proprietary/Need to Know
Subject: OpenSolaris Text Installer
Submitted by: Susan Sohn
File: PSARC/2010/165/opinion.html
Date: TBD
Committee: John Fischer, TBD.
Product Approval Committee: N/A
1. Summary
The Text Installer is a mouseless, screen-oriented installer designed
for use
on SPARC and x86 systems that may not have graphics support such as many
server-class machines.
2. Decision Precedence Information
The project is approved as specified in reference [1].
The project may be delivered in a minor release of the ON Consolidation.
3. Interfaces
The project exports the following interfaces.
Interfaces Exported
Interface Classification Comments
--- ---
/usr/lib/text-install Uncommitted CLI
system/install/text-install Committed IPS package name
${root}/lib/python2.6/vendor-packages/\ Consolidation Python to C bridge
osol_install/tgt.so Private to Target
Instantiation and
Target Discovery
${root}/lib/python2.6/vendor-packages/\ Consolidation Python to C bridge
osol_install/libzoneinfo.so Private to /usr/lib/\
libzoneinfo.so
system/install-setup:default Uncommitted SMF Install service
The project imports the following interfaces.
Interfaces Imported
Interface Classification Comments
--- ---
libzoneinfo.so.1 Contracted Private LSARC/2001/015
Python2.6 Uncommitted PSARC/2009/043
libdiskmgt.so.1 Consolidation LSARC/2004/743
Private
Distribution Constructor Committed PSARC/2009/471
libncurses.so Contracted Volatile LSARC/2008/524
menu.lst (grub) Committed PSARC/2004/454
4. Opinion
This project had a successful inception review which did not have any major
concerns that could not be corrected by specification updates. Thus the
case
was approved by updating those specifications and taking an email vote. The
issues listed below reflect the substantial inception review issues.
4.1 Static IP and IPv6 Networking
The inception UI specifications discussed the longer term UI for setting
up the
various NICs. The project team stated that the current review was based
upon
allowing networking to be setup via NWAM or not established. Static and
IPv6
configurations will be reviewed in a future fast track and be based upon
the
“interfaces for basic install network configuration” case (PSARC/2010/164).
There will be documentation in the commitment materials explaining that the
Static IP and IPv6 Network section of the UI specification are not
covered by
this case (reference [2]). The committee was fine with the OpenSolaris Text
Installer not being dependent upon that case and following up with a
fast track.
4.2 text-install Command Installation Location
As specified the project installs text-installer into /usr/bin. When
questioned
about the usage of the command the project team stated that there are a
few edge
use cases where the end user might execute the command from a command
line. The
majority of uses would simply be to insert a disc and the text-installer
automatically starts on boot. The committee stated that perhaps a better
installation location might be /usr/lib. The project team has decided to
install
the text-installer into the /usr/lib directory. The committee was fine
with the
resolution of this issue.
4.3 Root and User Passwords Not Required
The committee noted that the root and user passwords are not required at
install
time. The project team stated that they were following current Best
Practices
with regards to installation technologies. The installation user is
warned that
the system will be installed in an unsafe manner. The committee was fine
with
the issue.
4.4 User Installed as Primary Administrator
The initial user installed by the Caiman installers have been given the
Primary
Administrator Rights Profile. The committee pointed out that this Rights
Profile
is going away. The issue was discussed in the Solaris Modernization case
(PSARC/2010/067). In that case the project team agreed to modify the
installers
to:
1. remove the root password prompt
2. require an initial user login name and password
3. set the root password to the initial user password
4. the root is type=role
5. the initial user is granted the root role (type=normal;roles=root)
6. the initial user is put in /etc/sudoers -- presumable with all commands
7. the initial use is no longer granted the Primary Administrator Rights
Profile
8. the password hash algorithm is sha256
9. the root account password is installed as expired (passwd -f).
sp_lstchg == 0
username:password:lastchg:min:max:warn:inactive:expire:flag
sp_namp:sp_pwdp:sp_lstchg:sp_min:sp_max:sp_inact:ex_expire:sp_flag
The specification for this case will be modified to reflect
Re: PSARC/2010/165 - OpenSolaris Text Installer email vote...
PSARC members,
The opinion has been updated (section 4.4) based upon Darren's and Gary's
feedback. The directory versions are updated. Again, I am looking for a
vote
by COB Wednesday, June 30th, 2010.
Gary, I did not say anything new about the IPv6 and Static IP section. I
suspect
that the project team will be forth coming with the fast track well
prior to the
GA of the product.
Thanks,
John
Oracle
Systems Architecture Committee
Oracle Proprietary/Need to Know
Subject: OpenSolaris Text Installer
Submitted by: Susan Sohn
File: PSARC/2010/165/opinion.html
Date: TBD
Committee: John Fischer, TBD.
Product Approval Committee: N/A
1. Summary
The Text Installer is a mouseless, screen-oriented installer designed
for use
on SPARC and x86 systems that may not have graphics support such as many
server-class machines.
2. Decision Precedence Information
The project is approved as specified in reference [1].
The project may be delivered in a minor release of the ON Consolidation.
3. Interfaces
The project exports the following interfaces.
Interfaces Exported
Interface Classification Comments
--- ---
/usr/lib/text-install Uncommitted CLI
system/install/text-install Committed IPS package name
${root}/lib/python2.6/vendor-packages/\ Consolidation Python to C bridge
osol_install/tgt.so Private to Target
Instantiation and
Target Discovery
${root}/lib/python2.6/vendor-packages/\ Consolidation Python to C bridge
osol_install/libzoneinfo.so Private to /usr/lib/\
libzoneinfo.so
system/install-setup:default Uncommitted SMF Install service
The project imports the following interfaces.
Interfaces Imported
Interface Classification Comments
--- ---
libzoneinfo.so.1 Contracted Private LSARC/2001/015
Python2.6 Uncommitted PSARC/2009/043
libdiskmgt.so.1 Consolidation LSARC/2004/743
Private
Distribution Constructor Committed PSARC/2009/471
libncurses.so Contracted Volatile LSARC/2008/524
menu.lst (grub) Committed PSARC/2004/454
4. Opinion
This project had a successful inception review which did not have any major
concerns that could not be corrected by specification updates. Thus the
case
was approved by updating those specifications and taking an email vote. The
issues listed below reflect the substantial inception review issues.
4.1 Static IP and IPv6 Networking
The inception UI specifications discussed the longer term UI for setting
up the
various NICs. The project team stated that the current review was based
upon
allowing networking to be setup via NWAM or not established. Static and
IPv6
configurations will be reviewed in a future fast track and be based upon
the
“interfaces for basic install network configuration” case (PSARC/2010/164).
There will be documentation in the commitment materials explaining that the
Static IP and IPv6 Network section of the UI specification are not
covered by
this case (reference [2]). The committee was fine with the OpenSolaris Text
Installer not being dependent upon that case and following up with a
fast track.
4.2 text-install Command Installation Location
As specified the project installs text-installer into /usr/bin. When
questioned
about the usage of the command the project team stated that there are a
few edge
use cases where the end user might execute the command from a command
line. The
majority of uses would simply be to insert a disc and the text-installer
automatically starts on boot. The committee stated that perhaps a better
installation location might be /usr/lib. The project team has decided to
install
the text-installer into the /usr/lib directory. The committee was fine
with the
resolution of this issue.
4.3 Root and User Passwords Not Required
The committee noted that the root and user passwords are not required at
install
time. The project team stated that they were following current Best
Practices
with regards to installation technologies. The installation user is
warned that
the system will be installed in an unsafe manner. The committee was fine
with
the issue.
4.4 User Installed as Primary Administrator
The initial user installed by the Caiman installers have been given the
Primary
Administrator Rights Profile. The committee pointed out that this Rights
Profile
is going away according to the User, RBAC and Labeled Networking
Administration
case (PSARC/2009/652). Furthermore, the issue was discussed in the Solaris
Modernization case (PSARC/2010/067). In that case the project team
agreed to
modify the installers to:
1. remove the root password prompt
2. require an initial user login name and password
3. set the root password to the initial user password
4. make the root account a role
5. the initial user is granted the root role (type=normal;roles=root)
6. the initial user is put in /etc/sudoers -- presumable with all commands
7. the initial use is no longer granted
Re: Relaxed Type Requirements for SMF Profiles [PSARC/2010/222 Self Review]
Sean, This looks good (+1). My only question is about binding. The document states: Binding is Thanks, John On 06/17/10 05:24 PM, Liane Praza wrote: Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: Relaxed Type Requirements for SMF Profiles 1.2. Name of Document Author/Supplier: Author: Sean Wilcox 1.3 Date of This Document: 17 June, 2010 4. Technical Description Sean Wilcox 06/17/2010 1. Summary smf(5)/Greenline (PSARC 2002/547) provides the service_bundle(4) XML DTD. The required types for profiles can be relaxed in the property elements when those elements already exist in the repository via an imported manifest. 2. Details When a property group or property already has a type in the service/ instance, it can be taken from what is in the repository when applying a profile that would update that property group or property. Which means that the type should be implied for these elements. In order to keep the DTD validation for profiles that would like to use this relaxed requirement on elements, it is necessary to define the elements with implied types. Using Condidtional DTD Entities to create the different DTD elements within the DTD simplifies maintenance of the DTD for smf manifests and profiles given that there is so much shared data. With this method a profile writer that wants to take advantage of the relaxed elements and still be able to validate against the DTD with xml tools can simply add the following two elements to their profile : !ENTITY % profile INCLUDE !ENTITY % manifest IGNORE This will switch default values added to the DTD so that the relaxed elements will be used. 3. Interface Table service_bundle.dtd.1Committed Binding is 5. Additional Materials man page diffs : --- smf5.orig Fri Jun 4 10:01:54 2010 +++ smf5.newMon Jun 14 14:45:55 2010 @@ -439,11 +439,17 @@ Profiles can also contain configuration values for properties in services and instances. Tem- plate elements cannot be defined in a profile. + Profiles can use a relaxed set of elements from + the DTD described in service_bundle(4). To use + these the DOCTYPE entry should have the following + definitions added : +!ENTITY % profile INCLUDE +!ENTITY % manifest IGNORE Service bundles can be imported or exported from a reposi- tory using the svccfg(1M) command. See service_bundle(4) for a description of the service bundle file format with guide- lines for authoring service bundles. --- svccfg1m.orig Fri Jun 4 10:12:19 2010 +++ svccfg1m.newMon Jun 14 14:45:09 2010 @@ -161,11 +161,28 @@ modified in the SMF repository. Not-yet-existent proper- ties and property groups will be created. The type of the pre-existing property groups will not be changed by the profile. Existing properties (as distinguished from property groups) can have their type changed by the pro- - file. Nonexistent services and instances are ignored. + file. + +If the type attribute of a property or property group +is unspecified an attempt will be made to determine the +type from existing type settings or from the service +template. If a type cannot be determined a warning will +be presented and the service will be skipped so +inconsistent data will not be introduced into a service +and instance. Nonexistent services and instances are +ignored. + +In order to use the relaxed element definitions in a +profile the following definitions need to be added to +the DOCTYPE entry : + +!ENTITY % profile INCLUDE +!ENTITY % manifest IGNORE + Services and instances modified by the profile will be refreshed. If -n is specified, the profile is processed and no changes are applied to the SMF repository. Any syntax error found will be reported on stderr and an exit code of 1 will be returned. See smf(5) for a service_bundle.dtd.1 diffs : A series of service bundles may be composed via the xi:include tag. smf(5) tools enforce that all bundles be of the same type. -- + +!-- + These entities are used for the property, propval and property_group + elements, that require type attributes for manifest, while for profiles + the type attributes are only implied. +-- + +!ENTITY % profile IGNORE +!ENTITY % manifest INCLUDE + !ELEMENT xi:include (xi:fallback) !ATTLIST xi:include
Re: System Configuration -- nodename and defaultdomain [PSARC/2010/223 FastTrack timeout 06/25/2010]
Garrett, We discussed 'uname -S' and 'hostname' during the design phase. The consensus was those commands are not persistent across reboots today and this project does not change that behavior. system/identity:domain might be better named but that is really out of scope for the project. That to me seems like a case for the Networking team to come up with a new SMF service. Thanks, John On 06/18/10 03:06 PM, Garrett D'Amore wrote: Presumably uname -S and hostname will be modified to to update the SMF property as well as read it (likewise for domainname?) Also, what about sys-unconfig(1M)? (Or has that already been obsoleted elsewhere?) I wonder if system/identity:domain would better be named to reflect how this is used, which is really only with NIS, right? Perhaps this property ought to belong to the NIS service instead of as a system wide property. (The nodename property seems more general purpose, however.) - Garrett ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: System Configuration -- nodename and defaultdomain [PSARC/2010/223 FastTrack timeout 06/25/2010]
Andrew, When I looked at the source code I did not see sendmail needing changes. I just checked again and still do not believe any code changes are needed. Looking online I see that the $j refers to: confDOMAIN_NAME$j macro If defined, sets $j. This should only be done if your system cannot determine your local domain name, and then it should be set to $w.Foo.COM, where Foo.COM is your domain name. Thus the $j macro is used to set a domain name within sendmail by the system administrator when a domain name can not be determined by sendmail. This case will not change that behavior. sysidconfig tools are part of a future project which is starting up. The discussions are very early in the design phase. The purposed design by this project would be compatible with the current discussions. Thanks, John On 06/18/10 03:28 PM, Andrew Gabriel wrote: Garrett D'Amore wrote: Presumably uname -S and hostname will be modified to to update the SMF property as well as read it (likewise for domainname?) Also, what about sys-unconfig(1M)? (Or has that already been obsoleted elsewhere?) I wonder if system/identity:domain would better be named to reflect how this is used, which is really only with NIS, right? Perhaps this property ought to belong to the NIS service instead of as a system wide property. Isn't it picked up by sendmail.cf (et al) too ($j)? Also, what's happening about the auto-configuring of a zone using /etc/sysidcfg and the sysidconfig tools? They also manipulate domainname and nodename. ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
PSARC/2010/165 - OpenSolaris Text Installer email vote...
PSARC members,
The project team has provided updated materials which have been placed
under
the commitment.materials directory. There is now an ARC cover page
(ARC-CoverPage.html) which describes the changes between the inception and
commitment materials.
I have also added the attached draft opinion which is in the top level
directory.
There is also an HTML version of the draft opinion in the case directory.
Please review these new materials and the draft opinion. Either provide
feedback
or vote on the case by COB Wednesday, June 30th, 2010.
Thanks,
John
Oracle
Systems Architecture Committee
Oracle Proprietary/Need to Know
Subject:Â OpenSolaris Text Installer
Submitted by:Â Susan Sohn
File:Â PSARC/2010/165/opinion.html
Date:Â TBD
Committee:Â John Fischer, TBD.
Product Approval Committee:Â N/A
1. Summary
The Text Installer is a mouseless, screen-oriented installer designed for use
on SPARC and x86 systems that may not have graphics support such as many
server-class machines.
2. Decision Precedence Information
The project is approved as specified in reference [1].
The project may be delivered in a minor release of the ON Consolidation.
3. Interfaces
The project exports the following interfaces.
Interfaces Exported
Interface Classification Comments
--- ---
/usr/lib/text-install Uncommitted CLI
system/install/text-install Committed IPS package name
${root}/lib/python2.6/vendor-packages/\ Consolidation Python to C bridge
osol_install/tgt.so Private to Target
Instantiation and
Target Discovery
${root}/lib/python2.6/vendor-packages/\ Consolidation Python to C bridge
osol_install/libzoneinfo.so Private to /usr/lib/\
libzoneinfo.so
system/install-setup:defaultUncommitted SMF Install service
The project imports the following interfaces.
Interfaces Imported
Interface Classification Comments
--- ---
libzoneinfo.so.1Contracted Private LSARC/2001/015
Python2.6 Uncommitted PSARC/2009/043
libdiskmgt.so.1 Consolidation LSARC/2004/743
Private
Distribution ConstructorCommitted PSARC/2009/471
libncurses.so Contracted Volatile LSARC/2008/524
menu.lst (grub) EvolvingPSARC/2004/454
4. Opinion
This project had a successful inception review which did not have any major
concerns that could not be corrected by specification updates. Thus the case
was approved by updating those specifications and taking an email vote. The
issues listed below reflect the substantial inception review issues.
4.1 Static IP and IPv6 Networking
The inception UI specifications discussed the longer term UI for setting up the
various NICs. The project team stated that the current review was based upon
allowing networking to be setup via NWAM or not established. Static and IPv6
configurations will be reviewed in a future fast track and be based upon the
âinterfaces for basic install network configurationâ case (PSARC/2010/164).
There will be documentation in the commitment materials explaining that the
Static IP and IPv6 Network section of the UI specification are not covered by
this case (reference [2]). The committee was fine with the OpenSolaris Text
Installer not being dependent upon that case and following up with a fast track.
4.2 text-install Command Installation Location
As specified the project installs text-installer into /usr/bin. When questioned
about the usage of the command the project team stated that there are a few
edge
use cases where the end user might execute the command from a command line. The
majority of uses would simply be to insert a disc and the text-installer
automatically starts on boot. The committee stated that perhaps a better
installation location might be /usr/lib. The project team has decided to
install
the text-installer into the /usr/lib directory. The committee was fine with
the
resolution of this issue.
4.3 Root and User Passwords Not Required
The committee noted that the root and user passwords are not required at
install
time. The project team stated that they were following current Best Practices
with regards to installation technologies. The installation user is warned that
the system
Re: Lightning 1.0 [PSARC/2010/213 FastTrack timeout 06/16/2010]
Brian, Looks good -- +1 . I did not see the contracts in the sqlite cases. Are the contracts in process? Thanks, John On 06/14/10 12:22 PM, Brian Cameron wrote: PSARC: I have updated the case materials with a new one-pager that resolves the issues raised in review so far. Changes include: - local.sqlite is now Project Private - storage.sdb is now Obsolete Project Private. - mail/thunderbird is now listed in the Imported Interface table. - New style package names are now used. Attached please find a diff file which shows the changes from the previous version of the one-pager. Brian On 06/ 8/10 06:46 PM, John Fischer wrote: Brian, Should the local.sqlite be Project Private instead of Volatile? Also the packages should be part of the exported interface table as they show up in various places like Package Manager and pkg search. Please insure that the new IPS packages are included in the table. Should Thunderbird be listed in the Imported interface table? Are there interfaces being consumed by this project from the Thunderbird project? Perhaps not the entire thing but the actual interfaces consumed. Thanks, John On 06/ 8/10 02:47 PM, Brian Cameron wrote: This case is requesting a Minor release binding and will only deliver to OpenSolaris (Nevada). It has a timeout of 06/16/2010. Brian On 06/ 8/10 04:42 PM, Brian Cameron wrote: Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: Lightning 1.0 1.2. Name of Document Author/Supplier: Author: Brian Cameron 1.3 Date of This Document: 08 June, 2010 4. Technical Description Sun Proprietary/Confidential: Internal Use Only: Engineering Need-to-Know 1. Introduction 1.1. Project/Component Working Name: Lightning 1.0 1.2. Name of Document Author/Supplier: Author: Brian Lu Sponsor: Brian Cameron 2. Project Summary 2.1. Project Description: Lightning is an extension to tightly integrate calendar functionality into Thunderbird, a popular OpenSolaris mail client. It provides similar functionality as Evolution calendar, including scheduling, tasks, etc. 2.2. Risks and Assumptions: Risks may includes: - Product quality/stability. Since Lightning is still in the development stage (currently it is in 1.0b2 stage) and no official release is available yet, some new features may be added in the future. 4. Technical Description: 4.1. Details: The project will involve making sure that the Lightning builds and runs on Solaris, helping users manage their schedulings and tasks. Lightning 1.0 provides the following new features: - Seamless integration into the new Thunderbird 3.0 user interface - The different modes (calendar view, task view) are now displayed in tabs - You can now define multiple alarms for a single event - CalDAV support and interoperability with various CalDAV servers have been improved - WCAP 3.0 support has been improved Stability, performance and memory consumption have been improved. User's local calendars are stored at: $HOME/.thunderbird/user-profile-dir/calendar-data/local.sqlite Lightning 0.x settings can be migrated to Lightning 1.0 settings smoothly. After upgrading, Lightning 1.0 marks the old $HOME/.thunderbird/user-profile-dir/storage.sdb obsolete to prevent the user from using Lightning 0.x. If the user tries to use Lightning 0.x, following error message will be shown in a popup window and Lightning add-on is disabled in the thunderbird: The calendar data in your profile was updated by a newer version of Lightning, and continuing will probably cause the information to be lost or corrupted. Lightning will now be disabled and Thunderbird restarted That is to say, the user cannot use Lightning 0.x anymore after upgrading. If the user deletes $HOME/.thunderbird/user-profile-dir/storage.sdb manually, then Lightning 0.x will work again, but previous settings are unavailable. 4.5 Interfaces: Exported Interfaces Interface Stability Comments - --- -- $HOME/.thunderbird/user-profile-dir/calendar-data/local.sqlite Volatile local calendar settings $HOME/.thunderbird/user-profile-dir/storage.sdb Obsolete Volatile local calendar settings used in Lightning 0.x $HOME/.thunderbird/user-profile-dir/storage.sdb was not listed in the Exported Interfaces table of Lightning 0.3 ARC case (LSARC 2007/043) due to error. Imported Interfaces Interface Stability Comments --- SUNWsqlite3 Contracted Project sqlite3 db Private LSARC 2008/059 4.10. Packaging Delivery The project will be delivering the following packages to OpenSolaris: SUNWthunderbird-calendar 4.11. Security Impact: None. 4.12. Dependencies: Lightning 1.0 depends upon following packages: SUNWthunderbird SUNWpr SUNWsqlite3 5. Reference Documents: Lightning home page - http://wiki.mozilla.org/Lightning
Re: Lightning 1.0 [PSARC/2010/213 FastTrack timeout 06/16/2010]
On 06/14/10 12:46 PM, Nicolas Williams wrote: On Mon, Jun 14, 2010 at 12:37:50PM -0700, John Fischer wrote: Brian, Looks good -- +1 . I did not see the contracts in the sqlite cases. Are the contracts in process? SQLite3 is not contracted project private: it's mostly Uncommitted (see PSARC/2008/120 and subsequent cases). If it were Committed then you could use it safely. As it's Uncommitted, I think you could use it without a contract, though having a contract would be better. Nico Brian, Please update the document accordingly. John ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
PSARC/2010/165 - OpenSolaris Text Installer
PSARC, The OpenSolaris Text Installer case (2010/165) is scheduled for the next Open meeting, Wednesday June 16th, 2010. The Text Installer is a mouseless, screen-oriented text installer designed for use on SPARC and x86 systems that may not have graphics support. The case directory contains the following materials: PSARC Questionnaire - PSARC-questionnaire.txt Design Document ODT - designdocv2.0.8.odt Design Document PDF - designdocv2.0.8.pdf User Interface Design Document no/graphics - spec10-21.html User Interface Design Document w/graphics - UI/index.html It is related to the following other Caiman Install cases: PSARC/2007/039 - Caiman: New Solaris Installation Experience PSARC/2007/284 - Dwarf Caiman, New Solaris Install GUI PSARC/2010/069 - Solaris GUI Install Users Screen Modification PSARC/2009/471 - OpenSolaris Distribution Constructor Though it stands on its own. Please be sure to use the issues file as I will be using it during the discussion next week. Thanks, John ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Lightning 1.0 [PSARC/2010/213 FastTrack timeout 06/16/2010]
Brian, Should the local.sqlite be Project Private instead of Volatile? Also the packages should be part of the exported interface table as they show up in various places like Package Manager and pkg search. Please insure that the new IPS packages are included in the table. Should Thunderbird be listed in the Imported interface table? Are there interfaces being consumed by this project from the Thunderbird project? Perhaps not the entire thing but the actual interfaces consumed. Thanks, John On 06/ 8/10 02:47 PM, Brian Cameron wrote: This case is requesting a Minor release binding and will only deliver to OpenSolaris (Nevada). It has a timeout of 06/16/2010. Brian On 06/ 8/10 04:42 PM, Brian Cameron wrote: Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: Lightning 1.0 1.2. Name of Document Author/Supplier: Author: Brian Cameron 1.3 Date of This Document: 08 June, 2010 4. Technical Description Sun Proprietary/Confidential: Internal Use Only: Engineering Need-to-Know 1. Introduction 1.1. Project/Component Working Name: Lightning 1.0 1.2. Name of Document Author/Supplier: Author: Brian Lu Sponsor: Brian Cameron 2. Project Summary 2.1. Project Description: Lightning is an extension to tightly integrate calendar functionality into Thunderbird, a popular OpenSolaris mail client. It provides similar functionality as Evolution calendar, including scheduling, tasks, etc. 2.2. Risks and Assumptions: Risks may includes: - Product quality/stability. Since Lightning is still in the development stage (currently it is in 1.0b2 stage) and no official release is available yet, some new features may be added in the future. 4. Technical Description: 4.1. Details: The project will involve making sure that the Lightning builds and runs on Solaris, helping users manage their schedulings and tasks. Lightning 1.0 provides the following new features: - Seamless integration into the new Thunderbird 3.0 user interface - The different modes (calendar view, task view) are now displayed in tabs - You can now define multiple alarms for a single event - CalDAV support and interoperability with various CalDAV servers have been improved - WCAP 3.0 support has been improved Stability, performance and memory consumption have been improved. User's local calendars are stored at: $HOME/.thunderbird/user-profile-dir/calendar-data/local.sqlite Lightning 0.x settings can be migrated to Lightning 1.0 settings smoothly. After upgrading, Lightning 1.0 marks the old $HOME/.thunderbird/user-profile-dir/storage.sdb obsolete to prevent the user from using Lightning 0.x. If the user tries to use Lightning 0.x, following error message will be shown in a popup window and Lightning add-on is disabled in the thunderbird: The calendar data in your profile was updated by a newer version of Lightning, and continuing will probably cause the information to be lost or corrupted. Lightning will now be disabled and Thunderbird restarted That is to say, the user cannot use Lightning 0.x anymore after upgrading. If the user deletes $HOME/.thunderbird/user-profile-dir/storage.sdb manually, then Lightning 0.x will work again, but previous settings are unavailable. 4.5 Interfaces: Exported Interfaces Interface StabilityComments - --- -- $HOME/.thunderbird/user-profile-dir/calendar-data/local.sqlite Volatile local calendar settings $HOME/.thunderbird/user-profile-dir/storage.sdb Obsolete Volatilelocal calendar settings used in Lightning 0.x $HOME/.thunderbird/user-profile-dir/storage.sdb was not listed in the Exported Interfaces table of Lightning 0.3 ARC case (LSARC 2007/043) due to error. Imported Interfaces Interface StabilityComments --- SUNWsqlite3Contracted Project sqlite3 db Private LSARC 2008/059 4.10. Packaging Delivery The project will be delivering the following packages to OpenSolaris: SUNWthunderbird-calendar 4.11. Security Impact:
Re: PSARC/2010/138 - pkgbuild build engine
All, Laca has supplied the last need spec (see attached). I have placed it in the case directory as well. I believe this covers the last issue for the case. I will close the case out today COB unless I hear otherwise. Thanks, John On 05/12/10 05:46 AM, John Fischer wrote: All, I am extending the timer to Friday, May 14th, to allow Laca to complete his document on the spec files. I'll keep extending the timer until the document is done. He has shown me the document that he is producing and it will resolve this need spec. Therefore, when it is completed and available in the archives I will close the case as approved. Thanks, John On 05/ 7/10 11:00 AM, John Fischer wrote: Doug, Does the attached document satisfy this request for additional documentation? Laca, if not please provide what Doug is requesting. I will extend the timer for another few days to address the request. Thanks, John On 05/ 3/10 09:53 AM, Doug Leavitt wrote: In addition to the missing definitions for the Meta(*.*), SUNW*, and IPS* keys commonly deployed in pkgbuils spec files today, I also noticed that neither the proposal or the case materials make any reference to %include Solaris.inc or any of the include files Solaris.inc ifself includes and that are generally expected as part of current pkgbuild spec files, I believe that this ARC case needs to at least document and (hopefully) set some level of commitment to the well defined tag list. At a minimum this: http://hub.opensolaris.org/bin/view/Community+Group+sw-porters/specdesc needs to be included in the ARC materials. But, I'm sure better documentation than above should be provided. Say perhaps a man page or two? Doug. On 05/ 1/10 02:16 AM, Brian Cameron wrote: Albert: The spec file syntax is also conceptually an exported interface, and it needs a stability level. It would be nice if the spec file syntax were part of the materials (I'm guessing it's documented somewhere anyway). The basic syntax is the same as rpmbuild spec files, and pkgbuild includes a set of predefined macros and supports some additional tags (attributes/keywords): http://pkgbuild.sourceforge.net/man.php True, although pkgbuild does support some Solaris/OpenSolaris specific extensions, and it might be good to highlight those a bit more. For example, one thing I notice is that the new IPS_package_name and Meta(info.classification) keys cause syntax errors if you try to use an older version of pkgbuild. It would be nice if pkgbuild had better backwards compatibility support and provided some mechanism to allow people who just want to build SVR5 packages a way to tell pkgbuild to ignore keys that provide features that are not going to be used anyway. Brian The description of pkgbuild's spec files 1 Introduction pkgbuild uses build recipes called spec files to define what sources are used for building a component, how to set up the source tree, build the binaries and how to package them. The spec files used by pkgbuild are similar to RPM's spec files, but there are some differences. Because the resulting package formats (SVr4 and/or IPS) have different characteristics from RPM packages, pkgbuild uses additional spec file elements not used by RPM and there are also many elements of RPM spec files that are ignored by pkgbuild. This document describes the pkgbuild's spec file format with an emphasis on the differences from RPM spec files. A good general introduction to RPM spec files can be found in Chapter 13 of Maximum RPM by Edward C. Bailey. The book's ISBN is 0672311054 and is available as a PDF at http://www.redhat.com/docs/books/max-rpm/max-rpm.pdf or as HTML at http://www.rpm.org/max-rpm-snapshot/ch-rpm-inside.html 2 Overview of the format Spec files are plain text files. Lines starting with a # are comments. The percent character has a special meaning therefore it has to be escaped by another percent character, example: ./configure --default-zoom-level=50%% Tags define various attributes of the package, for example the name, the locations of sources, build-time and runtime dependencies. Lines that define tags start with the name of the tag followed by a colon followed by the value of the tag, for example: Name: pkgbuild Version: 1.3.102 The %package directive can be used to assign a name to a subset of files. A package usually corresponds to a separate SVr4 and/or IPS package. A number of shell script fragments (scriptlets) control the build process: %prep sets up the source tree from tarballs and/or patches and/or other source files. %build is used to create the binaries. %install places the binaries in a temporary package prototype area in the same layout at they will appear in the binary package. %check performs sanity testing. %clean is used to clean up the build directories after the build. Each scriptlet is executed separately, which means
Re: PSARC/2010/138 - pkgbuild build engine
All,
I have extended the timer to Friday, May 7th, 2010.
Thanks,
John
On 05/ 4/10 07:15 PM, Laszlo (Laca) Peter wrote:
On Tue, 2010-05-04 at 18:12 -0700, Alan Coopersmith wrote:
Laszlo (Laca) Peter wrote:
Like you say, the GNOME project provides common Makefiles in
gnome-common. GNU make does not come with useful standard
Makefiles AFAIK.
GNU Solaris make both come with makefile fragments included
by default to define useful standard rules like
.c.o:
$(CC) -c $@ $
See /usr/share/lib/make/make.rules for Solaris make - I believe
GNU make's are hardcoded in the gmake binary.
Whether something similar makes sense for pkgbuild, either now
or in a later case, is a different question.
I think the equivalent in pkgbuild would be the macros file
(which was adopted from rpmbuild's macros file) that lives in
$(libdir)/pkgbuild-$(version)/macros
It includes some standard macro definitions like:
%makeinstall \
make \\\
prefix=%{?buildroot:%{buildroot}}%{_prefix} \\\
exec_prefix=%{?buildroot:%{buildroot}}%{_exec_prefix} \\\
bindir=%{?buildroot:%{buildroot}}%{_bindir} \\\
sbindir=%{?buildroot:%{buildroot}}%{_sbindir} \\\
sysconfdir=%{?buildroot:%{buildroot}}%{_sysconfdir} \\\
datadir=%{?buildroot:%{buildroot}}%{_datadir} \\\
includedir=%{?buildroot:%{buildroot}}%{_includedir} \\\
libdir=%{?buildroot:%{buildroot}}%{_libdir} \\\
libexecdir=%{?buildroot:%{buildroot}}%{_libexecdir} \\\
localstatedir=%{?buildroot:%{buildroot}}%{_localstatedir} \\\
sharedstatedir=%{?buildroot:%{buildroot}}%{_sharedstatedir} \\\
mandir=%{?buildroot:%{buildroot}}%{_mandir} \\\
infodir=%{?buildroot:%{buildroot}}%{_infodir} \\\
install
%_prefix/usr
%_exec_prefix %{_prefix}
%_bindir%{_exec_prefix}/bin
%_sbindir %{_exec_prefix}/sbin
%_libexecdir%{_exec_prefix}/libexec
%_datadir %{_prefix}/share
%_sysconfdir%{_prefix}/etc
%_sharedstatedir%{_prefix}/com
%_localstatedir %{_prefix}/var
Laca
___
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
Re: PSARC/2010/149 - Removing bwm-ng from SFW
Having received the +1 and approval in PSARC meeting I am closing this case as approved. I will insure that these cases have a technology description moving forward. Thanks, John On 04/29/10 12:16 PM, Garrett D'Amore wrote: +1 on the case, and +1 on Darren's request. -- Garrett Darren J Moffatdarren.mof...@oracle.com wrote: On 29/04/2010 18:52, John Fischer wrote: All, I am sponsoring this case for Stefan Teleman of the SFW group. The case directory contains this proposal and the appendix material. I have set the timer for Thursday, May 6th, 2010. This case proposes the removal of bwm-ng from a Minor release of Solaris (i.e., Nevada). This component of SFW was only released in Nevada. A general comment for all cases of this type. Please can we have a short synopsis of what the component is so I don't have to go and lookup the ARC cases that introduced it to find out what it is. Which is what I've had to do with every one of these cases (other than acrea because I remembered commenting on that case when it came for review) so far. In this case the first paragraph of the project description from the original ARC case would have been perfect: bwm-ng is a small and simple console-based live network and disk io bandwidth monitor. It listens to network and disk io and displays current throughput -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Adobe - flash player plugin upgrade in Solaris [PSARC/2010/131 FastTrack timeout 04/22/2010]
Leon, Can you address Garrett's issue on the audio API changes within the OS? Once this is resolved then the case will be approved. Thanks, John On 04/15/10 12:26 PM, Garrett D'Amore wrote: On OpenSolaris/Solaris.Next, we have a new audio API (OSS), which is simpler, more performant, and quite possibly more reliable. Will the new flash player make use of the OSS API, or will it still use the legacy Sun audio interfaces? - Garrett On 04/15/10 12:05 PM, John Fischer wrote: Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: Adobe - flash player plugin upgrade in Solaris 1.2. Name of Document Author/Supplier: Author: Leon Sha 1.3 Date of This Document: 15 April, 2010 4. Technical Description 1.0 Introduction 1.1 Project/Component Working Name: Adobe - flash player plugin upgrade in solaris 1.2 Purpose This project will upgrade the Flash Player plugin in solaris to version 10.1. 1.3 Name of Document Author/Supplier: Leon Sha (leon@sun.com) 1.4 Email Aliases: 1.4.1 Responsible Manager: leo.bin...@sun.com 1.4.2 Responsible Engineer: leon@sun.com 1.4.3 Interest List: desktop-ct...@sun.com 2.0 Description Adobe Flash Player is the standard for delivering high-impact, rich Web content. Designs, animation, and application user interfaces are deployed immediately across all browsers and platforms, attracting and engaging users with a rich Web experience. 2.1 Installation Location As noted in section 2 of the opinion for LSARC/2002/745, the installation location for plugins wasbrowser installation location/plugins. For Solaris 10 the browser installation location is /usr/sfw/lib/mozilla. For OpenSolaris the browser installation location is /usr/lib/firefox. 3.0 Delivery The Flash Player plugin which is bundled with solaris will be upgraded to the latest version (version 10.1). This version is compatible with the previous version (version 10.0). The installation location will bebrowser installation location/plugins (see section 2.1). This release will be available as part of the SVr4 SUNWflash-player-plugin package. This project is targeting a patch release of Solaris 10. For opensolaris it will be in extras repositorie. https://pkg.sun.com/opensolaris/extra/ 4.0 Technical Description 4.1 New features compared with 10.0 * Introduces hardware-based H.264 video decoding to deliver smooth, high quality video with minimal overhead on supported systems. * The new global error handler enables developers to write a single handler to process all runtime errors that were not part of a try/catch statement. * New ActionScript globalization APIs allow Flash Player to use the values chosen in the operating system preferences to process text and lists and present information based on location context, without any knowledge of locale requirements. * Offers enhanced conformance to consistent browser usability guidelines, ensuring optimized user experiences and improved user control over privacy. * Abides by the host browser's private browsing mode, where local data and browsing activity are not persisted locally, providing a consistent private browsing mechanism for SWF and HTML content. * Prevents out-of-memory browser crashes by shutting down instances where a SWF attempts to allocate more memory than is available on the device. * Includes a number of media quality of service improvements and is ready to take advantage of upcoming Adobe media servers that will provide new ways to deliver rich media experiences and create new business models. * HTTP streaming enables delivery of video-on-demand and live streaming using standard HTTP servers, or from HTTP servers at CDNs, leveraging standard HTTP infrastructure and SWF-level playback components. * Stream reconnect allows an RTMP stream to continue to play through the buffer even if the connection is disrupted, thereby making media experiences more tolerant of short term network failures and enabling non-disruptive video playback. * Smart seek allows you to seek within the buffer and introduces a new back buffer so you can easily rewind or fast forward video without going back to the server, reducing the start time after a seek. * Buffered stream catch-up allows developers to set a target latency threshold that triggers slightly accelerated video playback to ensure that live video streaming stays in sync with real time over extended playback periods. * The Dynamic Streaming capability introduced
Re: Adobe - flash player plugin upgrade in Solaris [PSARC/2010/131 FastTrack timeout 04/22/2010]
all, This case was approved today at the PSARC meeting. Thanks, John ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Fwd: PSARC/2010/139 - Removing Areca Backup
All, This case received a +1 during the meeting and was approved. Thanks, John ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: [desktop-discuss] Time Slider Phase 2 (external backup) [PSARC/2010/129 OnePager]
+1 John On 04/13/10 03:53 PM, Brian Cameron wrote: Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: Time Slider Phase 2 (external backup) 1.2. Name of Document Author/Supplier: Author: Brian Cameron 1.3 Date of This Document: 13 April, 2010 4. Technical Description 1. Introduction 1.1. Project/Component Working Name: Time Slider Phase 2 (external backup) 1.2. Name of Document Author/Supplier: Author: Erwann Chenede, Niall Power 1.3 Date of This Document: Apr 8, 2010 4. Technical Description Time slider's primary purpose is to enable automatic ZFS snapshots to be taken for the user. This project's goal is to provide an external backup solution on top of Time Slider's local ZFS snapshot feature. Within the time slider setup dialog the user will only need to specify a path to an external filesystem where ZFS filesystem snapshots will be replicated using rsync and the filesystems the user wishes to replicate. This project makes the following high level changes : - auto-snapshot: Functional components responsible for scheduling, creation, deletion and backup of snapshots are to be replaced by a more modular scheduler provided by time slider. All interfaces are backward compatible or replaced. These interfaces are currently uncommitted. What remains of auto-snapshot are its SMF service instances which define automatic snapshot schedules. - time-slider: Replacement of the functional components removed from auto-snapshot via a snapshot daemon managed by the time-slider SMF service and introduction of a plugin mechanism to allow various types of time based backup strategies to be implemented. 4.1 Details: 4.1.1 Auto Snapshot : auto-snapshot as previously described in (LSARC 2008/571), consists of several SMF service instances (one per schedule: hourly, daily, weekly, monthly frequent by default). A SMF service method reads the configuration properties for a given schedule and creates a cron job that matches the schedule parameters for each instance. The cron job command is the auto-snapshot service method script invoked with arguments that cause it to execute in a snapshot creation operational mode. Additionally, the auto-snapshot SMF service provides a project private hook to allow execution of an administrator specified command immediately after creation of a scheduled snapshot set, which allows for a basic backup or replication mechanism. As an example for illustrative purposes only, an administrator could set the value of this property to: ssh host zfs receive -d poolB/received When a snapshot set is created the auto-snapshot service invokes /usr/sbin/zfs send [-iprevious]snapshot for each snapshot in the set and pipes the output to the administrator defined backup command which will receive the snapshot stream through standard input redirection. If it is the only existing snapshot matching the specified dataset and schedule, a full snapshot stream is created. Otherwise, if previous snapshots matching the dataset and schedule exist, an incremental difference stream between the previous and new snapshot is generated using the -i argument. In the above example, snapshot streams will be received and replicated on host under the target filesystem: poolB/received This feature is rather limited and has a number of drawbacks that make it unsuitable for further enhancement. The major issues with it are: - It can only send data in ZFS snapshot stream format and the mechanism to determine whether to send incremental or full snapshot streams is poor. It would incorrectly send a full stream instead of an incremental stream if all previous snapshots matching a given schedule and dataset were destroyed for example. Or worse, if the backup command feature was enabled some time after the containing auto-snapshot service was enabled and at least one snapshot event occurred, then it would incorrectly send an incremental stream instead of a full stream. In short, it has no way of knowing about relevant, previous events. - It can't operate asynchronously, it blocks when called and the auto-snapshot service waits until the backup command exits - If a backup can't be performed at the
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/subdir 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
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 stefan.tele...@oracle.com 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/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 stefan.tele...@oracle.com 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: 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
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: XCB (X Protocol C-Language Bindings) [PSARC/2010/109 FastTrack timeout 04/08/2010]
Stefan, I am good with most of the responses. I want to delve a little more into the first issue. Thanks, John On 04/ 2/10 08:43 AM, Stefan Teleman wrote: John Fischer wrote: Stefan, Thanks for being thorough as usual. I have truncated the fast track below for the issues/concerns that I would like to address in this email thread. 1. Interfaces Uncommitted vs. Volatile Why was Uncommitted chosen instead of Volatile? These interfaces sure seem to lend themselves to Volatile with stuff simply being removed at whim. Because Volatile would mandate contracts. The likeliest consumers of the XCB interfaces are Userland or Desktop applications [ GStreamer would be a prime candidate ]. Even Gtk and/or Cairo might decide in the near future to use XCB [ IIRC Cairo already looks for XCB if it is available ]. Not necessarily. Volatile can depend upon Volatile without a contract. In fact most of the Gnome stack is like that without contracts. If GStreamer or Cairo would have to sign contracts with XCB for every single micro release update, it would seriously hinder progress. Especially in case these updates do not actually break anything. That would be a compatible change and would not require a new contract. Actually, a contract can span multiple micro releases. The contract is simply a formal mechanism describing the relationship between the 2 interested parties when an interface is not stable enough to be consumed by one or additional communication is desired. Thus a contract could be used for a Committed interface. It would seem to me that since we know that the interfaces for this project are volatile within the community that we might require contracts for things that are higher then Volatile to consume the interfaces from this project. Also, XCB consumers [ application or library developers ] seem to have handled this implicit volatility quite well. They have accepted the fact that XCB can change unexpectedly, and they check for the version of XCB available at construction time, and adjust their software accordingly. So the open source community has accepted the volatility of these interfaces. What about future customers that are not so tightly tied into an open source community. How will they know that the interfaces might change from micro release to micro release of XCB on Solaris? Finally, the pitfalls with XCB's willingness to change only affect direct consumers of XCB. Application which use X11 won't be affected by these changes at all, since they will not see them [ in spite of the fact that X11 binds to XCB ]. Again, I am fine with the X11 applications issue. ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
