tipc Ver 1.7.6 [LSARC/2009/239 FastTrack timeout 04/20/2009]
This case was approved at LSARC last week. -- mark
RADIUS PAM module (pam_radius_auth) [PSARC/2008/269 FastTrack timeout 04/28/2008]
Darren: What is the status of this module? Has it made it into OpenSolaris? Will it be available in a Solaris 10 Update? Thank you, -- prasad -- This message posted from opensolaris.org
[Fwd: Re: Drools [LSARC/2008/748 FastTrack timeout 05/05/2009]]
Charles, Looking at the below interface table, drools-ant-4.7.jar makes sense as a project private jar file. But drools-analytics-4.7.jar is marked project private but then all the API's are marked uncommitted. That is a conflict. drools-analytics-4.7.jarProject Private jar file location: /usr/share/lib/java * AnalyticsData uncommitted interface * AnalysisResultuncommitted interface * Cause uncommitted interface * RangeCheckCause uncommitted interface * Possibility uncommitted interface drools-ant-4.7.jar Project Private jar file location: /usr/share/lib/java Thanks, Margot Charles Binford wrote: Resend, this time including LSARC-ext. cb Subject: Re: Drools [LSARC/2008/748 FastTrack timeout 05/05/2009] From: Charles Binford Charles.Binford at Sun.COM Date: Tue, 19 May 2009 09:56:30 -0500 To: Margot Miller Margot.Miller at Sun.COM To: Margot Miller Margot.Miller at Sun.COM CC: Richard.Matthews at Sun.COM, Mark Carlson Mark.Carlson at Sun.COM, Holly Vergara Holly.Costanza at Sun.COM Our commitment level is project private. I've attached updated files and diffs so it is easy to tell what changed. cb Margot Miller wrote: What is your commitment level for your jar files? Can any project outside yours use them? If not, then they should be project private. And then the answer is no for the first question and the rest are skipped. The focus of these questions is on what you are exporting, not importing. So if you are not publicly exporting anything, than mark it no and skip the rest. Does that make sense? thanks Margot Rick Matthews wrote: Mark and Margot, I'm a bit confused by these questions. Its likely because of lack of context. I'll provide further detail (to be verified by Charles) to hopefully steer us toward the correct answers. ++ ++3.1.2 Share and Sharable ++ Does the module include any components that are used or shared by ++ other projects? ++ [ ] Yes ++ [x] No This project consumes jar files from other FOSS cases, both within the context of Drools, and outside of that context (done by a different project team). This project does not export anything other than the Drools business rules engine. So, no components are exported for sharing. ++ ++ If yes are these components packaged to be shared with the other FOSS? ++ [x] Yes ++ [ ] No - ARC review required ++ [ ] N/A Based on the no above, this question should be skipped. If the shared imported components are the ones in question, than the yes answer stands. ++ ++ Are these components already in the Solaris WOS? ++ [ ] Yes ++ [x] No - continue with next section (section 3.2) Again, if the imported components are the ones in question, some are in Solaris already, others are in progress as result of this case and other fast tracks. ++ ++ If yes are these newer versions being delivered? ++ [ ] Yes ++ [ ] No - ARC review required ++ ++ If yes are the newer versions replacing the existing versions? ++ [ ] Yes ++ [ ] No - ARC review required ++
commons-collections [LSARC/2009/296 FastTrack timeout 05/15/2009]
The JDK needs to be in the imported interface table. And I suppose there is no problem with it running on whatever JDK is on the system? I don't think you need to put the javadocs in the interface table. Just a notation that javadocs are being delivered would be good. In any case, Project Private doesn't seem right for documentation. /usr/share/lib/java/javadoc/commons-collections Project Private Commons-Collections javadoc [2] Thanks Margot James Walker wrote: I'm sponsoring this familiarity case for James Wan. The requested release binding is minor. The man page has been posted in the materials directory and the javadoc tarball will be added. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: commons-collections 1.2. Name of Document Author/Supplier: Author: James Wan 1.3 Date of This Document: 08 May, 2009 4. Technical Description Summary === The Java Collections Framework was a major addition in JDK 1.2. It added many powerful data structures that accelerate development of most significant Java applications. Since that time it has become the recognised standard for collection handling in Java. Commons-Collections seek to build upon the JDK classes by providing new interfaces, implementations and utilities. Commons-Collections has many features, including: * Bag interface for collections that have a number of copies of each object * Buffer interface for collections that have a well defined removal order, like FIFOs * BidiMap interface for maps that can be looked up from value to key as well and key to value * MapIterator interface to provide simple and quick iteration over maps * Type checking decorators to ensure that only instances of a certain type can be added * Transforming decorators that alter each object as it is added to the collection * Composite collections that make multiple collections look like one * Ordered maps and sets that retain the order elements are added in, including an LRU based map * Identity map that compares objects based on their identity (==) instead of the equals method * Reference map that allows keys and/or values to be garbage collected under close control * Many comparator implementations * Many iterator implementations * Adapter classes from array and enumerations to collections * Utilities to test or create typical set-theory properties of collections such as union, intersection, and closure Commons-Collections 3.2.1 will be integrated into the SFW consolidation as part of this proposal, and will be installed as SUNWcommons-collections. The Commons-Collections package will contain commonly used versions of Commons-Collections. The file name will be used to manage multiple versions, for example: --- /usr/share/lib/java/commons-collections.jar link to most recent version /usr/share/lib/java/commons-collections-3.2.1.jar /usr/share/lib/java/commons-collections-3.1.1.jar --- This project requests a minor release binding. The Commons-Collections man page is included in the case materials directory. Dependencies SUNWjunit Interfaces == Exported Interfaces Classification Comment --- -- - SUNWcommons-collections Uncommitted Commons-Collections Package /usr/share/lib/java/commons-collections-3.2.1.jar Uncommitted Commons-Collections Classes /usr/share/lib/java/commons-collections.jar Uncommitted Symbolic Link org.apache.commons.collections Bag BidiMap BoundedCollection BoundedMap Buffer Closure Factory IterableMap KeyValue MapIterator MultiMap OrderedBidiMap OrderedIterator OrderedMap OrderedMapIterator Predicate PriorityQueue ResettableIterator ResettableListIterator SortedBag SortedBidiMap Transformer Unmodifiable org.apache.commons.collections.collection CompositeCollection.CollectionMutator org.apache.commons.collections.functors PredicateDecorator org.apache.commons.collections.map CompositeMap.MapMutator
jar file man pages - was Re: trove-2.0.4 [LSARC/2009/262 FastTrack timeout 05/05/2009]
Let's keep in mind that we are trying to document (in an easily accessible place) the interface classification of the OpenSolaris instance (not the Java interface across platforms). Given that we need to do this without massive patches to the upstream code, and that Java projects should use whatever native mechanism exists to document the classification across platforms, the OpenSolaris man page seems to be the best place. -- mark Rick Matthews wrote: I agree in principle with Jim's points. In particular, 1. Provides users stability and availability (taxonomy) information about jar file packages on Solaris/OpenSolaris not available anywhere else. If ARCs are going to require this information, it should be documented somewhere that a user can find it a normal operating environment. Currently, I'd have to agree this is man pages. I think a further point of this discussion is a need for ARCs to adopt a consistent means of doing so, and stick to it. In several of the cited cases with man pages, the man pages were produced as part of the Fast Track process. In the case of LSARC/2009/262, it was questioned why we would have man pages for jar/java release vehicles. That is inconsistent, which is why I believe Jim raised the issue. Toward that end, issues continue to be raised with jar/java FOSS projects. There doesn't seem to be a checklist of items needed for a FOSS jar project (and of course, many checklists are incomplete). As I recall, the following issues resulted from FOSS cases delivering jar s: 1) How to deliver javadocs to OpenSolaris (mostly due to web site volume issues) 2) Man pages for stability and taxonomy 3) What portions need to have declared stability, etc. (like package name) 4) What JDK version(s)? 5) Versioning of jar files Mark Martin brought up number 5 quite awhile ago. There was no further action taken. The jar files really seem to parallel C libraries, and should have a best practice for versioning similar to (or maybe expanded) Library and Shared Object Requirements. IMHO, man page declaration of stability and taxonomy works. Let's keep that until there is a suitable better way. Lloyd's method of documenting is a good start, but we can't hope to force external communities to use such a method, except by general acceptance. We could make it a best practice for non-FOSS jar deliverables that are being ARCed. This assumes Lloyd's proposal is sound, which I don't feel qualified to have opinion. I think the ARCs need to look into these issues (as is being done), and reasonable methods/ practices be established, and then those be consistently applied. -- Rick On 05/13/09 13:30, Jim Walker wrote: For LSARC, PSARC and the opinion writer(s) to consider Michael Kearney wrote: 1. Lloyd, I like the idea of your annotation but have a couple of concerns. - Would teams be expected to update third party, open source jar files with the annotation? - Would the ARC provide the common @Taxonomy annotation Java code? I have concerns too. In general, we will not be able to change FOSS code upstream like this. We normally try to do as little modification as possible (ie. just enough to get it to run well on Solaris/OpenSolaris). This is another reason why short man pages are being tacked on. Is it possible to tack on a page to the javadoc? I don't want to see big javadoc patches in the SFW consolidation that document detailed taxonomy information that we have to carry forever because they will never be accepted into the upstream community. Why would a FOSS project creating jar files even care about our taxonomy rules? 2. What if the man page simple documented the stability at the granularity of the jar file and nothing else. Perhaps the man page could generically reference the Javadoc? Not every jar file in /usr/share/lib/java has a man page, but that is the current practice, for the ones that do: $ man asm $ man mvel $ man janino $ man jettison $ man joda-time $ man jaxen-core $ man junit $ man ant (needs a more direct reference to javadoc) ... As I see it, having jar file man pages... 1. Provides users stability and availability (taxonomy) information about jar file packages on Solaris/OpenSolaris not available anywhere else. 2. Is pretty painless for project teams to produce and support. 3. Man pages do no harm, and I think users are already getting use to having them. Some information is better than no information. 4. Until there is a better way, man pages should be required for any new jar file submissions into Solaris/OpenSolaris. I thought this was already true. 5. Man pages are used by most Solaris/OpenSolaris packages. 6. I appreciate where Java developers are coming from, but not standard practice for Java developers to look for man pages alone, doesn't seem enough reason to stop man pages being delivered with jar file packages.
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Claire Li wrote: I see. Your biggest concern is that 'beansh' would be different from the upstream. But I think there are some reasons to support 'beansh'. 1. My opinion is to use both 'beanshell' and 'beansh', not 'beansh' only. 'beanshell' is for the potential name change in upstream, and beansh is use for short. 2. As far as I know, shell commands use 'sh' as the suffix of the command name, not 'shell'. Maybe that is another naming rule. A convention perhaps, but not a rule. 3. I don't think they will use other names, at least in a short term. Patrick Niemeyer /said I had never heard that AIX was calling Bourne Shell bsh. I always thought Bourne shell was simply 'sh'. / That's true for systems where /bin/sh is *not* ksh. Anyway, I don't care that much one way or the other -- I'd discourage arbitrary difference from the upstream, but whatever the project team wants to do is fine with me. -- Garrett Claire / /Garrett D'Amore wrote: Claire Li wrote: Hi Garrett, Please see my in-line comments. Regards, Claire Garrett D'Amore wrote: Claire Li wrote: Hi ARC team: In view of the naming conflict of bsh, I've contact beanshell author Patrick Niemeyer on this issue. He suggested resorting to name the command 'beanshell'. However, I would like to have both 'beanshell' and 'beansh' proposed by Jorg, since 'beansh' is more concise, and conciseness is what a command name needs. Conciseness *might* be useful, but IMO adding beansh doesn't make that much sense if: 1) the command is primarily executed from the gui The GUI of BeanShell is started by the command. 2) the command is infrequently manually type Everytime you want to start BeanShell, you need to type the command. So I think it's frequently manually typed. Ok. 3) the upstream won't adopt the same change, so the change would create arbitrary divergence from the upstream As far as I know, the upstream use 'bsh' as the command name. And so does the Linux platforms such as Ubuntu and Fedora. If we want to avoid the potential naming conflict, it seems we have to diverse from the upstream. My point was that, if the recommendation was to use beanshell from upstream, then it is likely that this name will be available on other platforms as well (perhaps in addition to bsh). The key thing here is that for some platforms *in addition* to OpenSolaris, the bsh conflict will exist. I remain unconvinced that saving 3 characters in the command name is worth the risk of even *further* divergence from the upstream community. That said, I don't think I'll stand in the way of the alias if the team wants to have it anyway. - Garrett My biggest concern of the three is #3. I think it would be wise to stick with just what the upstream community advises. (If however you get consensus from the upstream that beansh is a useful alias and will be used on other platforms as well, then I'm happy to support that option as well.) - Garrett Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: beanshell 1.2. Name of Document Author/Supplier: Author: Claire Li 1.3 Date of This Document: 18 May, 2009 2. Project Summary 2.1 Project Description This project introduces the package of BeanShell 2.0b4 into the SFW consolidation. A minor release binding is requested. 4. Technical Description: BeanShell[1] is a small, free, embeddable Java source interpreter with object scripting language features, written in Java. BeanShell dynamically executes standard Java syntax and extends it with common scripting conveniences such as loose types, commands, and method closures like those in Perl and JavaScript. You can use BeanShell interactively for Java experimentation and debugging as well as to extend your applications in new ways. Scripting Java lends itself to a wide variety of applications including rapid prototyping, user scripting extension, rules engines, configuration, testing, dynamic deployment, embedded systems, and even Java education. BeanShell is small and embeddable, so you can call BeanShell from your Java applications to execute Java code dynamically at run-time or to provide extensibility in your applications. Alternatively, you can use standalone BeanShell scripts to manipulate Java applications; working with Java objects and APIs dynamically. Since BeanShell is written in Java and runs in the same VM as your application, you can freely pass references to live objects into scripts and return them as results. In short, BeanShell is dynamically interpreted Java, plus a scripting language and flexible environment all rolled into one clean package. Command name Notes
jar file man pages - was Re: trove-2.0.4 [LSARC/2009/262 FastTrack timeout 05/05/2009]
Mark A. Carlson wrote: Let's keep in mind that we are trying to document (in an easily accessible place) the interface classification of the OpenSolaris instance (not the Java interface across platforms). Given that we need to do this without massive patches to the upstream code, and that Java projects should use whatever native mechanism exists to document the classification across platforms, the OpenSolaris man page seems to be the best place. I remain unconvinced that we (OpenSolaris) should even be concerned about stability of Java APIs upon OpenSolaris. (With the possible exception of APIs that are designed specifically to *support* OpenSolaris itself.) Do other members see value in having another layer of commitment and review beyond whatever is already done as part of the Java community? - Garrett -- mark Rick Matthews wrote: I agree in principle with Jim's points. In particular, 1. Provides users stability and availability (taxonomy) information about jar file packages on Solaris/OpenSolaris not available anywhere else. If ARCs are going to require this information, it should be documented somewhere that a user can find it a normal operating environment. Currently, I'd have to agree this is man pages. I think a further point of this discussion is a need for ARCs to adopt a consistent means of doing so, and stick to it. In several of the cited cases with man pages, the man pages were produced as part of the Fast Track process. In the case of LSARC/2009/262, it was questioned why we would have man pages for jar/java release vehicles. That is inconsistent, which is why I believe Jim raised the issue. Toward that end, issues continue to be raised with jar/java FOSS projects. There doesn't seem to be a checklist of items needed for a FOSS jar project (and of course, many checklists are incomplete). As I recall, the following issues resulted from FOSS cases delivering jar s: 1) How to deliver javadocs to OpenSolaris (mostly due to web site volume issues) 2) Man pages for stability and taxonomy 3) What portions need to have declared stability, etc. (like package name) 4) What JDK version(s)? 5) Versioning of jar files Mark Martin brought up number 5 quite awhile ago. There was no further action taken. The jar files really seem to parallel C libraries, and should have a best practice for versioning similar to (or maybe expanded) Library and Shared Object Requirements. IMHO, man page declaration of stability and taxonomy works. Let's keep that until there is a suitable better way. Lloyd's method of documenting is a good start, but we can't hope to force external communities to use such a method, except by general acceptance. We could make it a best practice for non-FOSS jar deliverables that are being ARCed. This assumes Lloyd's proposal is sound, which I don't feel qualified to have opinion. I think the ARCs need to look into these issues (as is being done), and reasonable methods/ practices be established, and then those be consistently applied. -- Rick On 05/13/09 13:30, Jim Walker wrote: For LSARC, PSARC and the opinion writer(s) to consider Michael Kearney wrote: 1. Lloyd, I like the idea of your annotation but have a couple of concerns. - Would teams be expected to update third party, open source jar files with the annotation? - Would the ARC provide the common @Taxonomy annotation Java code? I have concerns too. In general, we will not be able to change FOSS code upstream like this. We normally try to do as little modification as possible (ie. just enough to get it to run well on Solaris/OpenSolaris). This is another reason why short man pages are being tacked on. Is it possible to tack on a page to the javadoc? I don't want to see big javadoc patches in the SFW consolidation that document detailed taxonomy information that we have to carry forever because they will never be accepted into the upstream community. Why would a FOSS project creating jar files even care about our taxonomy rules? 2. What if the man page simple documented the stability at the granularity of the jar file and nothing else. Perhaps the man page could generically reference the Javadoc? Not every jar file in /usr/share/lib/java has a man page, but that is the current practice, for the ones that do: $ man asm $ man mvel $ man janino $ man jettison $ man joda-time $ man jaxen-core $ man junit $ man ant (needs a more direct reference to javadoc) ... As I see it, having jar file man pages... 1. Provides users stability and availability (taxonomy) information about jar file packages on Solaris/OpenSolaris not available anywhere else. 2. Is pretty painless for project teams to produce and support. 3. Man pages do no harm, and I think users are already getting use to having them. Some information is better than no information. 4. Until there is a
jar file man pages - was Re: trove-2.0.4 [LSARC/2009/262 FastTrack timeout 05/05/2009]
Garrett D'Amore wrote: Mark A. Carlson wrote: Let's keep in mind that we are trying to document (in an easily accessible place) the interface classification of the OpenSolaris instance (not the Java interface across platforms). Given that we need to do this without massive patches to the upstream code, and that Java projects should use whatever native mechanism exists to document the classification across platforms, the OpenSolaris man page seems to be the best place. I remain unconvinced that we (OpenSolaris) should even be concerned about stability of Java APIs upon OpenSolaris. (With the possible exception of APIs that are designed specifically to *support* OpenSolaris itself.) Do other members see value in having another layer of commitment and review beyond whatever is already done as part of the Java community? I think the only real review that is relevant is where it is installed and how it is packaged. If it provides a service how that service is started. This is not really any different to what we allow for code written in other languages. For example the real documentation (including stability levels) for libcurl is html docs under /usr/share/ That is what came from upstream. Personally I find even the addition of some of the ATTRIBUTES section information more than is really necessary in some cases - like when it is blindinly obvious this isn't OpenSolaris/Sun developed components. However given there is a good working system for adding it and it does provide value I'm happy to see it continue. If there is no man page for something and its docs come in a different format then IMO we should leave those docs alone. -- Darren J Moffat
logilab-common [LSARC/2009/298 FastTrack timeout 05/18/2009]
All issues have been addressed and the timeout period has been reached and I have updated the proposal.txt file to indicate python 2.6 will be used. Marking this case closed approved. Cheers, Jim
logilab-astng [LSARC/2009/299 FastTrack timeout 05/18/2009]
+1 has been received. All issues have been addressed and the timeout period has been reached and I have updated the proposal.txt file to indicate python 2.6 will be used. Marking this case closed approved. Cheers, Jim
[Fwd: Re: Drools [LSARC/2008/748 FastTrack timeout 05/05/2009]]
An embedded and charset-unspecified text was scrubbed... Name: drools-arc-interfaces.2009-05-19a.txt URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090519/54452282/attachment.txt
commons-collections [LSARC/2009/296 FastTrack timeout 05/15/2009]
margot wrote: The JDK needs to be in the imported interface table. And I suppose there is no problem with it running on whatever JDK is on the system? I don't think you need to put the javadocs in the interface table. Just a notation that javadocs are being delivered would be good. In any case, Project Private doesn't seem right for documentation. /usr/share/lib/java/javadoc/commons-collectionsProject PrivateCommons-Collections javadoc [2] I agree. I'll make the changes. Cheers, Jim
jar file man pages - was Re: trove-2.0.4 [LSARC/2009/262 FastTrack timeout 05/05/2009]
Garrett D'Amore writes: Mark A. Carlson wrote: Let's keep in mind that we are trying to document (in an easily accessible place) the interface classification of the OpenSolaris instance (not the Java interface across platforms). Given that we need to do this without massive patches to the upstream code, and that Java projects should use whatever native mechanism exists to document the classification across platforms, the OpenSolaris man page seems to be the best place. I remain unconvinced that we (OpenSolaris) should even be concerned about stability of Java APIs upon OpenSolaris. (With the possible exception of APIs that are designed specifically to *support* OpenSolaris itself.) Do other members see value in having another layer of commitment and review beyond whatever is already done as part of the Java community? It's not another layer of review. It's architectural review as required by the process. No matter how important a project team may be, we simply do not defer to project teams to do all architectural review on our behalf. There's only one ARC, and the system is designed that way on purpose. So, JCP may do whatever reviews it desires in its own way (as may other quasi-ARC-like bodies, such as CLARC and Sun Ray ARC), but to be shipped as a Sun product -- including but not limited to being part of the OpenSolaris distribution -- it's necessary that the engineering work goes through architectural review. In this case, I think we *are* concerned about advertising the right stability level for these interfaces, because that's an inherent part of software design, and not just some artifice that comes out of the ARC. If there's some local definition of stability levels and reference documentation, and these are well understood by users, then that's great. It doesn't matter to me much that it's not identical to our taxonomy or to man pages. We may as well use what's natural (and in fact require its use in all reviewed projects) so that users will understand it better. However, I do not agree that this means that we take a pass on it. If that's what we're planning to do (or if it's what you're suggesting here), then either (a) Java needs to create a SAC-sponsored process to play nice with the rest of us or (b) we need a much bigger rule (from the CTO's office) giving Java a get-out-of-ARC-free card. I don't think we can or should do that on our own. -- James Carlson, Solaris Networking james.d.carlson at sun.com Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
jar file man pages - was Re: trove-2.0.4 [LSARC/2009/262 FastTrack timeout 05/05/2009]
James Carlson wrote: Garrett D'Amore writes: Mark A. Carlson wrote: Let's keep in mind that we are trying to document (in an easily accessible place) the interface classification of the OpenSolaris instance (not the Java interface across platforms). Given that we need to do this without massive patches to the upstream code, and that Java projects should use whatever native mechanism exists to document the classification across platforms, the OpenSolaris man page seems to be the best place. I remain unconvinced that we (OpenSolaris) should even be concerned about stability of Java APIs upon OpenSolaris. (With the possible exception of APIs that are designed specifically to *support* OpenSolaris itself.) Do other members see value in having another layer of commitment and review beyond whatever is already done as part of the Java community? It's not another layer of review. It's architectural review as required by the process. No matter how important a project team may be, we simply do not defer to project teams to do all architectural review on our behalf. There's only one ARC, and the system is designed that way on purpose. This sounds like a self-serving statement to me. I've always believed (and maybe I've misunderstood) that ARC review is designed to ensure that the bits that we deliver are properly reviewed -- to prevent total anarchy, and to ensure that the right people are looking at the project. What I'm failing to understand is how PSARC (or LSARC) review of Java APIs is at all meaningful. The right parties to involve in those conversations are *not* (at least today) the members of the ARCs. In fact, I propose that the current ARCs are woefully inadequate to understanding the delivery concerns for software that it is intended to be used in environments that are not Unix-ish. Furthermore, what sense does it make to deny a Java API, or even issue TCRs against such an API, when the API comes from upstream (and the upstream might well be Sun itself!), and is concerned with portability and such. I'm opposed to the idea of process for its own sake -- the process needs to add something or its just a waste everyone's time. I think reviewing of Java APIs (and assigning stability levels to such) on any kind of fine grained scale qualifies as such a waste. What *does* make sense for review, IMO, is: 1) delivery of major new revisions or features, such as Java 1.6 or whatever. 2) location of deliverables (what directory are libraries and commands located in) 3) stability of *major* components. (I.e. Java 1.6 is assigned a Committed binding on Solaris or somesuch) Anything more than that, including trying to provide man pages for individual APIs, is utter nonsense, IMO. So, JCP may do whatever reviews it desires in its own way (as may other quasi-ARC-like bodies, such as CLARC and Sun Ray ARC), but to be shipped as a Sun product -- including but not limited to being part of the OpenSolaris distribution -- it's necessary that the engineering work goes through architectural review. I view Java as a bit special, because it has an entire runtime environment that is totally disconnected from the rest of the platform. Trying to review a whole different platform in that context makes little or no sense, except in the broadest terms of Java is available, and the version number is X with Commitment Level Y. Here are the directories...') In this case, I think we *are* concerned about advertising the right stability level for these interfaces, because that's an inherent part of software design, and not just some artifice that comes out of the ARC. But its totally redundant, except that in this case the folks reviewing the API are probably completely inadequate to the task of performing the review. For example, how many ARC members are familiar with the issues faced by software intended to be deployed on cell phones. Or Win32? Or even Linux, for that matter? What about the considerations for software deployed in the browser? Or the sandbox restrictions of Java? Like it or not, our specialty is Solaris. The further afield we get from that, the more inadequate our ability to meaningfully review it. At some point we either have to degenerate into a pointless rubber stamp, or (worse) a potentially harmful (because we lack adequate context) barrier to progress. If there's some local definition of stability levels and reference documentation, and these are well understood by users, then that's great. It doesn't matter to me much that it's not identical to our taxonomy or to man pages. We may as well use what's natural (and in fact require its use in all reviewed projects) so that users will understand it better. However, I do not agree that this means that we take a pass on it. If that's what we're planning to do (or if it's what you're suggesting here), then
PSARC 2008/769 - Multiple disk sector size support
Just to clarify. This case 2008/769 is phase I of multiple phase. Larry
jar file man pages - was Re: trove-2.0.4 [LSARC/2009/262 FastTrack timeout 05/05/2009]
I agree in principle with Jim's points. In particular, 1. Provides users stability and availability (taxonomy) information about jar file packages on Solaris/OpenSolaris not available anywhere else. If ARCs are going to require this information, it should be documented somewhere that a user can find it a normal operating environment. Currently, I'd have to agree this is man pages. I think a further point of this discussion is a need for ARCs to adopt a consistent means of doing so, and stick to it. In several of the cited cases with man pages, the man pages were produced as part of the Fast Track process. In the case of LSARC/2009/262, it was questioned why we would have man pages for jar/java release vehicles. That is inconsistent, which is why I believe Jim raised the issue. Toward that end, issues continue to be raised with jar/java FOSS projects. There doesn't seem to be a checklist of items needed for a FOSS jar project (and of course, many checklists are incomplete). As I recall, the following issues resulted from FOSS cases delivering jar s: 1) How to deliver javadocs to OpenSolaris (mostly due to web site volume issues) 2) Man pages for stability and taxonomy 3) What portions need to have declared stability, etc. (like package name) 4) What JDK version(s)? 5) Versioning of jar files Mark Martin brought up number 5 quite awhile ago. There was no further action taken. The jar files really seem to parallel C libraries, and should have a best practice for versioning similar to (or maybe expanded) Library and Shared Object Requirements. IMHO, man page declaration of stability and taxonomy works. Let's keep that until there is a suitable better way. Lloyd's method of documenting is a good start, but we can't hope to force external communities to use such a method, except by general acceptance. We could make it a best practice for non-FOSS jar deliverables that are being ARCed. This assumes Lloyd's proposal is sound, which I don't feel qualified to have opinion. I think the ARCs need to look into these issues (as is being done), and reasonable methods/ practices be established, and then those be consistently applied. -- Rick On 05/13/09 13:30, Jim Walker wrote: For LSARC, PSARC and the opinion writer(s) to consider Michael Kearney wrote: 1. Lloyd, I like the idea of your annotation but have a couple of concerns. - Would teams be expected to update third party, open source jar files with the annotation? - Would the ARC provide the common @Taxonomy annotation Java code? I have concerns too. In general, we will not be able to change FOSS code upstream like this. We normally try to do as little modification as possible (ie. just enough to get it to run well on Solaris/OpenSolaris). This is another reason why short man pages are being tacked on. Is it possible to tack on a page to the javadoc? I don't want to see big javadoc patches in the SFW consolidation that document detailed taxonomy information that we have to carry forever because they will never be accepted into the upstream community. Why would a FOSS project creating jar files even care about our taxonomy rules? 2. What if the man page simple documented the stability at the granularity of the jar file and nothing else. Perhaps the man page could generically reference the Javadoc? Not every jar file in /usr/share/lib/java has a man page, but that is the current practice, for the ones that do: $ man asm $ man mvel $ man janino $ man jettison $ man joda-time $ man jaxen-core $ man junit $ man ant (needs a more direct reference to javadoc) ... As I see it, having jar file man pages... 1. Provides users stability and availability (taxonomy) information about jar file packages on Solaris/OpenSolaris not available anywhere else. 2. Is pretty painless for project teams to produce and support. 3. Man pages do no harm, and I think users are already getting use to having them. Some information is better than no information. 4. Until there is a better way, man pages should be required for any new jar file submissions into Solaris/OpenSolaris. I thought this was already true. 5. Man pages are used by most Solaris/OpenSolaris packages. 6. I appreciate where Java developers are coming from, but not standard practice for Java developers to look for man pages alone, doesn't seem enough reason to stop man pages being delivered with jar file packages. We can't control how jar files are delivered or documented on windows or other environments, but we can on Solaris/OpenSolaris. BTW. ccing Norm (sfw c-team lead) since one of the requirements to integrate into sfw is a man page. Cheers, Jim -- - Rick Matthews email: Rick.Matthews at sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road
jar file man pages - was Re: trove-2.0.4 [LSARC/2009/262 FastTrack timeout 05/05/2009]
Could we not add something like a stability file to the META-INF directory in a JAR file then provide something (like extension in IDE, or CLI) to extract it? I was going to suggest adding it to the manifest, but it would seem to be more strict about the format of the file - while the directory META-INF would be more flexible. Just my 2?, Darren. On 19/05/2009 16:53, Michael Kearney wrote: I wouldn't want to see the Sun jar files have the @Taxonomy annotation and a completely different (or non-existent) method, such as a man page for FOSS jar files. I'd like to see a single, consistent method and I think that's a short and simple man page. -Michael Norm Jacobs wrote: Jim Walker wrote: For LSARC, PSARC and the opinion writer(s) to consider Michael Kearney wrote: 1. Lloyd, I like the idea of your annotation but have a couple of concerns. - Would teams be expected to update third party, open source jar files with the annotation? - Would the ARC provide the common @Taxonomy annotation Java code? NO, NO, NO. We don't want to be in the business of patching this bit of Sun lore into source and or documentation delivered by existing open source projects. Largely, the projects are not going to be interested in this type of change. This should be handled by a separate mechanism that falls outside of that arena, perhap by the taxonomy(1) command. I have concerns too. In general, we will not be able to change FOSS code upstream like this. We normally try to do as little modification as possible (ie. just enough to get it to run well on Solaris/OpenSolaris). This is another reason why short man pages are being tacked on. Is it possible to tack on a page to the javadoc? Simply put, If we can leave the upstream bits alone, we should. If we have to make changes to make it build, install, or function properly then coordinate those changes with the upstream community. For SFW, it's ok to deliver them as a patch initially, but the expectation is that the next update will obsolete the patch unless there is a really compelling reason to deviate from the upstream. This doesn't mean that you can't include support for SMF, RBAC, ... It just means that we want something that doesn't require new patches at each update and ultimately, no patching at all would be preferred. So again, leave the open source bits (docs in this case) alone unless there is a really compelling reason to deviate. I don't want to see big javadoc patches in the SFW consolidation that document detailed taxonomy information that we have to carry forever because they will never be accepted into the upstream community. Why would a FOSS project creating jar files even care about our taxonomy rules? They won't. 2. What if the man page simple documented the stability at the granularity of the jar file and nothing else. Perhaps the man page could generically reference the Javadoc? Not every jar file in /usr/share/lib/java has a man page, but that is the current practice, for the ones that do: $ man asm $ man mvel $ man janino $ man jettison $ man joda-time $ man jaxen-core $ man junit $ man ant (needs a more direct reference to javadoc) ... As I see it, having jar file man pages... 1. Provides users stability and availability (taxonomy) information about jar file packages on Solaris/OpenSolaris not available anywhere else. 2. Is pretty painless for project teams to produce and support. 3. Man pages do no harm, and I think users are already getting use to having them. Some information is better than no information. 4. Until there is a better way, man pages should be required for any new jar file submissions into Solaris/OpenSolaris. I thought this was already true. 5. Man pages are used by most Solaris/OpenSolaris packages. 6. I appreciate where Java developers are coming from, but not standard practice for Java developers to look for man pages alone, doesn't seem enough reason to stop man pages being delivered with jar file packages. We can't control how jar files are delivered or documented on windows or other environments, but we can on Solaris/OpenSolaris. BTW. ccing Norm (sfw c-team lead) since one of the requirements to integrate into sfw is a man page. The requirement has really been to provide documentation. We have not forced folks to deliver man pages when the software they were delivering had it's own documentation. If it comes with texinfo, javadoc, html, ... then we have let them deliver that documentation and not required a man page for everything. If software was lacking documentation, we have asked for documentation that describes it, usually a man page. The intent is to provide the documentation that is expected by the users of the software. -Norm -- http://www.sun.com * Michael Kearney * Staff Software Engineer *Sun Microsystems, Inc.* MS UBRM05-390, 500 Eldorado Blvd Broomfield, CO
zfs snapshot holds [PSARC/2009/297 FastTrack timeout 05/20/2009]
+1 -- - Rick Matthews email: Rick.Matthews at sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USAmain: +1(651) 554-1500 -
2009/228 ls enhancements
Hi Jason, Please find comments in-line below... Cheers, Don On Mon, 18 May 2009 21:21:53 -0500 Jason King wrote: To accompany my earlier message, I've attached the updated man page changes for the case materials. These do not reflect any change in behavior or architecture, merely making the initial manpage changes submitted with the case agree with the results of the case discussion. Thanks for sending the update. There are still a few more changes that need to be made. A brief summary of the changes from the original ls.txt: 1. --color invocation is changed to show correct usage of --color[=WHEN]. 2. Values for --block-size are elaborated (based on pervious message). 3. LS_COLOR is fixed to the correct LS_COLORS. 4. LS_COLORS and TERM added to the environment variable section. LS_COLORS use was already detailed in the color output section, just not listed under environment variables. TERM was an implicit dependency due to the use of terminfo, it was added to make the dependency explicit. -- next part -- User Commands ls(1) NAME ls - list contents of directory SYNOPSIS | /usr/bin/ls [-aabccdeeffghhikllmnopqrrsstuuwv...@] [-/ c | v] [-% atime | crtime | ctime | mtime | all] [file]... You have added the new short options, but these SYNOPSIS lines give no indication that new long options have been added that don't have short option equivalents. I think the last line above needs to be changed to: |[-/ c | v] [-% atime | crtime | ctime | mtime | all] |[--block-size size] [--color[=when]] [--file-type] [--si] |[--time-style style] [file]... | /usr/xpg4/bin/ls [-aabccdeeffghhikllmnopqrrsstuuwv...@] [-/ c | v] [-% atime | crtime | ctime | mtime | all] [file]... The same change needs to be applied to the line above. | /usr/xpg6/bin/ls [-aabccdeeffghhikllmnopqrrsstuuwv...@] [-/ c | v] [-% atime | crtime | ctime | mtime | all] [file]... The same change needs to be applied to the line above. DESCRIPTION ... ... ... OPTIONS ... ... ... | -U Output is unsorted. This overrides the -t and |-s setting. I assume you mean -S rather than -s (-s doesn't affect sorting). Do you really mean that -U overrides the other options, or does the last -S, -t, or -U option on the command line determine the behavior. (Either way is OK, I just want to be sure that the man page correctly documents the behavior.) For some options, the behavior of mutually exclusive options depends on which version of ls you invoke.) This last sentence probably also needs to be moved to the discussion on mutually exclusive options below... ... ... ... |--file-type | Display a suffix after a file depending on it's type, similar | to the -F option, except * is not appended to executable files. See notes below about mutually exclusive options. | |--si | Display human scaled sizes similar to the -h option, except | powers of 10 instead of powers of 2 are used. See notes below about mutually exclusive options. | |--time-style style | Display times using the specified style. This does not effect | the times displayed for extended attributes (-%). | Possible values for style are: | full-iso: Equivalent to -E | long-iso: Display in -MM-DD HH:MM for all files | iso: Display older files using -MM-DD and newer files | with MM-DD HH:MM | locale: Use the default locale format for old and new files. | This is the default. | +FORMAT: Use a custom format. Values are the same as described | in strftime(3c). If a newline appears in the string, | the first line is used for older files and the | second line is used for newer files, otherwise the | given format is used for all files. /usr/bin/ls -FMarks directories with a trailing slash (/), doors with a trailing greater-than sign (), executable files with a trailing asterisk (*), FIFOs with a trailing vertical bar (|), symbolic links with a trailing at sign (@), and AF_UNIX address family sockets with a trailing equals sign (=). Follows sym- links named as operands. Note that -F always follows symlinks for /usr/bin/ls and /usr/xpg4/bin/ls, but /usr/xpg6/bin/ls does not follow symlinks unless -H or -L is also present. What does --file-type do? A new paragraph should be added here to talk about the interactions between -S, -t, and -U. What happens if both --file-type and -F are given on the command line? Does the last one specified win, or does one override
OpenSolaris ARC Minutes - 05/19/2009
SYSTEM ARCHITECTURE COUNCIL Layered Software ARC - 05-19-2009 MEETING MINUTES Send CORRECTIONS, additions, deletions to lsarc-coord at sun.com. Minutes are archived in /shared/sac/Minutes/LSARC. ATTENDEES: Chair Margot Miller Yes Members (8 active members) Mark CarlsonYes Lloyd Chambers Yes Aniruddh Dikhit No Danek Duvall(on sabbatical) John FischerYes Ed Hunter Out Chris Kasso no Arieh Markel(on sabbatical) Jyri Virkki no Interns Brian Cameron Yes James Gates no Irene Huang no Matthias HuetschYes Michael Kearney Yes Linda Schneider no Rahul Shah no Krishna Tallapaneni no David Tong no James WalkerYes Mark Martin Yes (external) Coordinator Asa Romberger (PM) Yes Guest Norm Jacobs Jeff Chi Rick Matthews John Childers Charles Binford Not all attendees names are captured. Please send email to Asa.Romberger at Sun.com, if you attended the meeting and your name was not captured. == AGENDA 20 min Open ARC Business 60 min Discussion on man pages for jar files, taxonomy 15 min Open: LSARC/2009/262: trove-2.0.4 20 min Closed ARC Business == Case Anchors: br A HREF=#case1trove-2.0.4 (2009/262)/A br == ARC Business Fast-tracks: Case (Timeout) Exposure Title 2008/748 (05/15/09) open Drools approved 2009/239 (05/08/09) open tipc Ver 1.7.6 approved 2009/250 (05/15/09) open Firefox 3.0.x on S10 approved pending email notification of issue 2009/258 (05/08/09) open pywbem Ver 0.7 approved 2009/262 (05/05/09) open trove-2.0.4 extend to 5/22 pending vote on jar filed 2009/277 (05/10/09) open libosip2 extend to 5/22 pending vote on jar filed 2009/278 (05/11/09) open qdox-1.9 extend to 5/22 pending vote on jar filed 2009/280 (05/11/09) open jrexx-1.1.1 approved 2009/296 (05/15/09) open commons-collections extend timer to 05/22/2009 2009/298 (05/18/09) open logilab-common approved 2009/299 (05/18/09) open logilab-astng approved 2009/302 (05/21/09) open aalib approved Opinions Other stuff --- Jar file documentation with respect to interface stability Margot Miller Lloyd Chambers to write majority opinion - no man page Mark Carlson to write minority opinion - optional man page Next Meeting -- 05/26/2009 20 min Open ARC Business 20 min Closed ARC Business 60 min AVAILABLE 60 min AVAILABLE
Time Stamp Option for xxstat Commands Phase II [PSARC/2009/307 Self Review]
On Mon, May 18, 2009 at 4:12 PM, Chad Mynhier cmynhier at gmail.com wrote: On Mon, May 18, 2009 at 6:56 AM, James Carlson james.d.carlson at sun.com wrote: Sherry Moore writes: ? ? ? - netstat(1M) Kais Belgaied writes: will there be more follow-ons to 2009/105 for the remaining of xxstat commands? netstat, dladm show-link -s -i, flowadm show-flow -s -i, etc? ?^^^ It looks like at least one of those is being addressed. I think the rest would be addressed if the project team updated Sowmini's CR 6782154 work, which is a common output formatter for networking commands. Yes, as James pointed out, netstat was already included. ?I could certainly add dladm and flowadm to this list. Just to be clear, I'm adding these two (dladm show-link -s -i and flowadm show-flow -s -i) to the list of commands covered by this case. I've been told that there's no need to update the one-pager itself and that this email thread is sufficient documentation. Chad
LSARC/2009/250 - Firefox 3.0.x on Solaris 10
Margot: What was the resolution to Brian Cameron's GSteamer needing GLib 2.12 or newer? It looks like this project is integrating version 2.14.4. Can GStreamer use that? If so, should the interface stability be consolidation private? Or, has it been determined that all these libraries are truly private? Just to reiterate what I said in the meeting. GLib 2.14.4 (or any version 2.12 or later) would be fine for backporting GStreamer 0.10 to Solaris 10. It still is not clear if backporting GStreamer 0.10 is something that will be done, but if the decision is made to do so, then it would obviously make things easier if this GLib 2.14.4 library could be used. It would be good to clarify what the interface stability level of these GNOME base libraries will be. If they are private, will it be possible to get a contract to use them for GStreamer 0.10 if needed? Brian ---+--+-+ |/usr/lib/gnome-private/glib-2.0 | Project private | Project private glib libraries | |/usr/lib/gnome-private/libglib*.so| | version 2.14.4 Thanks Margot On 05/13/09 10:00, John Fischer wrote: All, Actually, I have set the timer for Friday, May 15th, 2009, COB PST. Thanks, John John Fischer wrote: All, Attached please find the updated proposal. I have reset the timer for Wednesday May 20th, 2009. Thanks, John John Fischer wrote: All, I am putting this case into need spec status to allow the project team to produce a new specification that addresses the sharing of the Gnome libraries and installation locations. Once this is done I will restart the timer appropriately. Thanks, John Abhijit Nath wrote: Alan/John, Yes, it is a mistake. We'll shift all the private libraries/ Firefox 3.0.x libraries in /opt/firefox3. You are also correct about the LD_LIBRARY_PATH. We'll modify the one pager and incorporate LD_LIBRARY_PATH_32 and LD_LIBRARY_PATH_64. Some other frameworks' up-prive (eg GStreamer) also need upgraded gnome libraries( Refer Brian's mail). So we are in a process to check the feasibility of keeping all the upgraded libraires in a common place. We'll revert back asap. Thanks, Abhijit On 04/22/09 04:40, John Fischer wrote: Alan, I totally missed the /opt/firefox and /opt/sfw issue. Thanks for catching that one. I'll let the project team address these issues. Thanks, John Alan Coopersmith wrote: John Fischer wrote: This project proposes to back port Firefox 3.0.x from Nevada to a Solaris 10 Update release which is a Patch release of Solaris. Is it integrating into the update release or shipping as a separate web download running on top of the update release? (/opt would be wrong for the integrated case, right for the unbundled case). Is this intended to replace or supplement Firefox 2.x? The one-pager references both /opt/firefox3 /opt/sfw/lib/firefox/ - can we assume /opt/firefox3 is correct since /opt/sfw is reserved for the Solaris Companion CD? All the plugins are spawned by firefox-bin. So, LD_LIBRARY_PATH environment variable will be set to /opt/sfw/lib in run-mozilla.sh This also seems incorrect - should this refer to the /opt/firefox3/lib directory or are you importing/depending on libraries from the Companion CD? (Also, in the unavoidable cases in which you must use LD_LIBRARY_PATH-type variables, you should always use LD_LIBRARY_PATH_32 or LD_LIBRARY_PATH_64 to avoid breaking programs of the other wordsize.) Are the library upgrades incompatible? Is there no way they can be shipped as updates to the existing public libraries in /usr/lib ? For the brand new libraries, like cairo dbus, is there any architectural reason they must be private, or is this just a resource issue around supporting them? ___ opensolaris-arc mailing list opensolaris-arc at opensolaris.org ___ opensolaris-arc mailing list opensolaris-arc at opensolaris.org ___ opensolaris-arc mailing list opensolaris-arc at opensolaris.org
Time Stamp Option for xxstat Commands Phase II [PSARC/2009/307 Self Review]
Just to be clear, I'm adding these two (dladm show-link -s -i and flowadm show-flow -s -i) to the list of commands covered by this case. I've been told that there's no need to update the one-pager itself and that this email thread is sufficient documentation. On second thought, how about you send me an updated one with the added commands, I will copy it to the materials directory for your ARC case. Once I have copied the file (and send you the link to the file), you can respond the mail stating that you will add those two commands, and the case file has been updated and can be found where. Sherry -- Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
LSARC/2009/250 - Firefox 3.0.x on Solaris 10
Brian, In talking with Parthasarathi and Abhijit they understand the desire by Java to have GStreamer in Solaris 10. However, they do not want to end up pulling in a bunch of support issues by making them a public interface. With that said I am sure that they would be willing to sign a contract when Java comes to the committee to us the interface. Thanks, John Brian Cameron wrote: Margot: What was the resolution to Brian Cameron's GSteamer needing GLib 2.12 or newer? It looks like this project is integrating version 2.14.4. Can GStreamer use that? If so, should the interface stability be consolidation private? Or, has it been determined that all these libraries are truly private? Just to reiterate what I said in the meeting. GLib 2.14.4 (or any version 2.12 or later) would be fine for backporting GStreamer 0.10 to Solaris 10. It still is not clear if backporting GStreamer 0.10 is something that will be done, but if the decision is made to do so, then it would obviously make things easier if this GLib 2.14.4 library could be used. It would be good to clarify what the interface stability level of these GNOME base libraries will be. If they are private, will it be possible to get a contract to use them for GStreamer 0.10 if needed? Brian ---+--+-+ |/usr/lib/gnome-private/glib-2.0 | Project private | Project private glib libraries | |/usr/lib/gnome-private/libglib*.so| | version 2.14.4 Thanks Margot On 05/13/09 10:00, John Fischer wrote: All, Actually, I have set the timer for Friday, May 15th, 2009, COB PST. Thanks, John John Fischer wrote: All, Attached please find the updated proposal. I have reset the timer for Wednesday May 20th, 2009. Thanks, John John Fischer wrote: All, I am putting this case into need spec status to allow the project team to produce a new specification that addresses the sharing of the Gnome libraries and installation locations. Once this is done I will restart the timer appropriately. Thanks, John Abhijit Nath wrote: Alan/John, Yes, it is a mistake. We'll shift all the private libraries/ Firefox 3.0.x libraries in /opt/firefox3. You are also correct about the LD_LIBRARY_PATH. We'll modify the one pager and incorporate LD_LIBRARY_PATH_32 and LD_LIBRARY_PATH_64. Some other frameworks' up-prive (eg GStreamer) also need upgraded gnome libraries( Refer Brian's mail). So we are in a process to check the feasibility of keeping all the upgraded libraires in a common place. We'll revert back asap. Thanks, Abhijit On 04/22/09 04:40, John Fischer wrote: Alan, I totally missed the /opt/firefox and /opt/sfw issue. Thanks for catching that one. I'll let the project team address these issues. Thanks, John Alan Coopersmith wrote: John Fischer wrote: This project proposes to back port Firefox 3.0.x from Nevada to a Solaris 10 Update release which is a Patch release of Solaris. Is it integrating into the update release or shipping as a separate web download running on top of the update release? (/opt would be wrong for the integrated case, right for the unbundled case). Is this intended to replace or supplement Firefox 2.x? The one-pager references both /opt/firefox3 /opt/sfw/lib/firefox/ - can we assume /opt/firefox3 is correct since /opt/sfw is reserved for the Solaris Companion CD? All the plugins are spawned by firefox-bin. So, LD_LIBRARY_PATH environment variable will be set to /opt/sfw/lib in run-mozilla.sh This also seems incorrect - should this refer to the /opt/firefox3/lib directory or are you importing/depending on libraries from the Companion CD? (Also, in the unavoidable cases in which you must use LD_LIBRARY_PATH-type variables, you should always use LD_LIBRARY_PATH_32 or LD_LIBRARY_PATH_64 to avoid breaking programs of the other wordsize.) Are the library upgrades incompatible? Is there no way they can be shipped as updates to the existing public libraries in /usr/lib ? For the brand new libraries, like cairo dbus, is there any architectural reason they must be private, or is this just a resource issue around supporting them? ___ opensolaris-arc mailing list opensolaris-arc at opensolaris.org ___ opensolaris-arc mailing list opensolaris-arc at opensolaris.org ___ opensolaris-arc mailing list opensolaris-arc at opensolaris.org
Time Stamp Option for xxstat Commands Phase II [PSARC/2009/307 Self Review]
On Tue, May 19, 2009 at 4:10 PM, Sherry Moore sherry.moore at sun.com wrote: Just to be clear, I'm adding these two (dladm show-link -s -i and flowadm show-flow -s -i) to the list of commands covered by this case. ?I've been told that there's no need to update the one-pager itself and that this email thread is sufficient documentation. On second thought, how about you send me an updated one with the added commands, I will copy it to the materials directory for your ARC case. Once I have copied the file (and send you the link to the file), you can respond the mail stating that you will add those two commands, and the case file has been updated and can be found where. Okay, the case file has been updated with these two commands. It can be found here: http://arc.opensolaris.org/caselog/PSARC/2009/307/materials/case.final.txt Chad
trove-2.0.4 [LSARC/2009/262] - Draft Minority Opinion
During the case discussion today, I took the AI to help Michael Kearney draft a minority opinion. There may be other minority opinions, but if this looks close to something you would sign on to, I am open to small changes. -- mark 5. Minority Opinion Background It is not typical for programmers working with non C/C++/Assembler files, such as Java Jar files, to determine the Exported Interface stability level using the man command. Java programmers depend on Javadoc, Python programmers depend on pydoc and so forth to document interfaces and the stability would best be indicated there. Approval of OpenSolaris projects have been inconsistent in preferring man pages or native documentation. This opinion seeks to clarify the issue and define a policy for all such cases going forward. Best Practice Case A - Sun Developed Components 1) Sun project team developing a Jar file shall document the ARC interface classification in the native documentation. (i.e. Javadocs) Case B - Components imported from external OSS Communities 1) The OSS Community documents the interface classification in their native documentation a) OpenSolaris project team agrees with the classification and supports it - Javadoc or other native documentation required (unchanged) - No man page shall be allowed b) OpenSolaris project team disagrees with the classification - Javadoc or native documentation required, but project team must change the OSS documentation to match the project team's classification - No man page shall be allowed 2) OSS Community does not document interface classification in their native documentation a) OpenSolaris project team is strongly encouraged to update the native documentation to reflect the OpenSolaris project team classification. - Changed Javadoc or other native documentation required - No man page shall be allowed b) OpenSolaris project team cannot support deltas to the native documentation - Unchanged Javadoc or other native documentation required - A man page shall be provided
libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009]
This case was approved at the LSARC meeting today. The project team plans to update the libosip man page to indicate that libsip is the current preferred sip library on Solaris/OpenSolaris. Cheers, Jim
aalib [LSARC/2009/302 FastTrack timeout 05/21/2009]
The case was approved at todays LSARC meeting. The following files have been moved to the demo directory and the aalib-config man page has been added to the case materials. /usr/demo/aalib/aafire /usr/demo/aalib/aainfo /usr/demo/aalib/aasavefont /usr/demo/aalib/aatest Cheers, Jim
2009/228 ls enhancements
This should be the final update of the manpage changes (*crossing
fingers*), reflecting the points that Don Cragun brought up. I don't
believe they don't effect the vote (as they're just disambiguating the
interaction of options), but as always speak up if you feel otherwise.
Summary:
1. Added long options with no short equivalents to synopsis
2. Clarified behavior of --file-type with ls, xpg4 ls, and xpg6 ls
wrt -H or -L options (matches -F behavior minus marking of executables
for each).
3. Clarified interaction of -S, -t, and -U options (last one wins).
4. Clarified interaction of -h and --si options (last one wins).
5. Added new flags to list of non-standard options in attributes section.
-- next part --
User Commands ls(1)
NAME
ls - list contents of directory
SYNOPSIS
| /usr/bin/ls [-aabccdeeffghhikllmnopqrrsstuuwv...@]
| [-/ c | v] [-% atime | crtime | ctime | mtime | all]
| [--block-size size] [--color[=when]] [--file-type] [--si]
| [--time-style style] [file]...
| /usr/xpg4/bin/ls [-aabccdeeffghhikllmnopqrrsstuuwv...@]
| [-/ c | v] [-% atime | crtime | ctime | mtime | all]
| [--block-size size] [--color[=when]] [--file-type] [--si]
| [--time-style style] [file]...
| /usr/xpg6/bin/ls [-aabccdeeffghhikllmnopqrrsstuuwv...@]
| [-/ c | v] [-% atime | crtime | ctime | mtime | all]
| [--block-size size] [--color[=when]] [--file-type] [--si]
| [--time-style style] [file]...
DESCRIPTION
For each file that is a directory, ls lists the contents of
the directory. For each file that is an ordinary file, ls
repeats its name and any other information requested. The
output is sorted alphabetically by default. When no argument
is given, the current directory (.) is listed. When several
arguments are given, the arguments are first sorted
appropriately, but file arguments appear before directories
and their contents.
There are three major listing formats. The default format
for output directed to a terminal is multi-column with
entries sorted down the columns. The -1 option allows single
column output and -m enables stream output format. In order
to determine output formats for the -C, -x, and -m options,
ls uses an environment variable, COLUMNS, to determine the
number of character positions available on one output line.
If this variable is not set, the terminfo(4) database is
used to determine the number of columns, based on the
environment variable, TERM. If this information cannot be
|obtained, 80 columns are assumed. If the -w option is used,
|the argument will override any other column width.
The mode printed when the -e, -E, -g, -l, -n, -o, -v, -V, or
-@ option is in effect consists of eleven characters. The
first character can be one of the following:
d The entry is a directory.
D The entry is a door.
l The entry is a symbolic link.
SunOS 5.11 Last change: 25 Mar 20081
User Commands ls(1)
b The entry is a block special file.
c The entry is a character special file.
p The entry is a FIFO (or named pipe) special file.
P The entry is an event port.
s The entry is an AF_UNIX address family socket.
- The entry is an ordinary file.
The next 9 characters are interpreted as three sets of three
bits each. The first set refers to the owner's permissions;
the next to permissions of others in the user-group of the
file; and the last to all others. Within each set, the three
characters indicate permission to read, to write, and to
execute the file as a program, respectively. For a direc-
tory, execute permission is interpreted to mean permission
to search the directory for a specified file. The character
after permissions is an ACL or extended attributes indica-
tor. This character is an @ if extended attributes are asso-
ciated with the file and the -@ option is in effect. Other-
wise, this character is a plus sign (+) character if a non-
trivial ACL is associated with the file or a space character
if not.
If -/ and/or -% are in effect, then the extended system
attributes are printed when filesystem supports extended
system attributes. The display looks as follows:
$ls -/ c file
-rw-r--r-- 1 root root 0 May 10 14:17 file
{AHRSadim-u}
$ls -/ v file
-rw-r--r-- 1 root root 0 May 10 14:17 file
{archive,hidden,readonly,system,appendonly\
nodump,immutable, av_modified,\
Draft of trove-2.0.4 LSARC/2009/262
Hey All, Here is the draft opinion. Please review/comment. Thanks Margot ** sun microsystems Systems Architecture Committee _ Subject: trove-2.0.4 Submitted by: Vivek Titamare File: LSARC/2009/262/opinion.txt Date: May, 2009 Committee: Margot Hackett Miller, Lloyd Chambers Minority: Mark Carlson Product Approval Committee: Solaris PAC solaris-pac-opinion at sun.com 1. Summary This project is one of the Linux familiarity cases; this one provides a library to do fast regular and primitive collections for Java. 2. Decision Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a minor release of Solaris. 3. Interfaces Exported Interfaces: __ | Interfaces Exported | | __ | __ __|| |Interface | Classification | Comments| |___ __|_|_| | trove.jar | Uncommitted | | |SUNWtrove | Uncommitted | | |___|_|| Imported Interfaces: __ | Interfaces Exported | | |___|__ __|| |Interface | Classification | Comments | |___ __|_|| | | SUNWj5dev | Committed | Java Development kit | | SUNWj5rt | Committed | Java Runtime library | | SUNWj6dev | Committed | Java Development kit | | SUNWj6rt | Committed | Java Runtime library | |___|_|| 4. Opinion During review, the only real issue raised was whether this team should provide a man page in addition to the javadocs. The man page would basically give a brief description of the jar file, pointer to the javadocs, and state the interface stability of the jar file. Discussion ensued whether it makes sense to ship a man page with a jar file. Solaris developers expect man pages, but do Java developers? Is it worth the extra work to provide a man page and would Java developers even look for a man page. It was noted that this is not standard practice as most Java developers look for java documentation via javadocs, not via man. However, others stated that having a minimal man page for a java jar file would allow the interface classification to be visible to the end user and a few other ARC cases have already shipped man pages for jar files. There was discussion over the granularity of the jar file and does it make sense to have an interface stability for the overall jar. Currently, java has Public, Package, and Protected. Does that convey enough of the stability of the jar and its methods to the developer? With all the FOSS that is being delivered into Solaris, projects are delivering in their native, natural form. This includes man pages, texinfo, html, and javadoc. So the problem isn't just with javadocs and jar files. There is quite a bit of FOSS out there with no interface stability in the external Sun documentation. This is not a problem for Sun project teams as they can always look at the interface tables in the ARC tables to determine stability level. Asking all java project teams to ship a man page in addition to javadocs doesn?t seem like the right solution and having some teams ship a man page and others not, does not provide consistency. There needs to more discussion to determine if it is critical that the ARC stability level be communicated to the Solaris end user for all the FOSS software that is being delivered. If so, a comprehensive solution needs to be formulated, whether it is a CLI, a man page, annotation embedded in the Javadocs (which will work for Sun products but you cant force that upstream). Up until now, most projects have not shipped man pages with jar files. This doesn?t seem to have been written down anywhere. With this case, we would like to make it explicit to not deliver man pages with jar files. This is setting precedent. 5. Minority Opinion(s) Mark Carlson providing text 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required Do not ship man pages with Java jar files 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory LSARC/2009/262 1) Project Proposal file: LSARC/2009/262 Copyright 2009 Sun Microsystems
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
This case appears to have come to resolution, and the timeout has been reached. The package will provide the following command and link for beanshell: /usr/bin/beanshellUncommitted Command /usr/bin/beansh Uncommitted Symbolic link And the project team will monitor the application usage and upstream community to see if other command names should be used in the future. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
I'm marking this case closed approved. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
Configurable Boot Archive Updates [2009/312 05/26/2009]
I am sponsoring this fast-track on behalf of Gangadhar Mylapuram, with a timeout set to May 26, 2009. Patch/micro-release binding is requested. == 1. Introduction 1.1. Project/Component Working Name: Configurable Boot-archive Updates with uadmin(2) 1.2. Name of Document Author/Supplier: Author: Gangadhar Mylapuram 1.3. Date of This Document: 04/27/2009 1.3.1. Date this project was conceived: 04/06/2009 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. Solaris PAC 1.4.2. PSARC 1.4.3. Chris Armes 1.4.4. Solaris Sustaining 1.5. Email Aliases: 1.5.1. Responsible Manager: Narayana.Kadoor at sun.com 1.5.2. Responsible Engineer: Gangadhar.M at sun.com 1.5.3. Marketing Manager: 1.5.4. Interest List: Todd.Miller at sun.com, Robert.Dipietro at Sun.COM 2. Project Summary 2.1. Project Description: Provides a new attribute in Boot configuration service to permit boot-archive updates during uadmin(2) operations. Patch/micro-release binding requested. 3. Business Summary 3.1. Problem Area: Some customers require the use of uadmin(2) to reboot which can result in boot archive inconsistency on reboot since uadmin(2) does not update the boot archive, Other applications such as clustering require that uadmin(2) NOT update the archive, so always updating the archive cannot be made the default. 3.2. Market/Requester: Lucent Technologies 4. Technical Description: 4.1. Details: Introduce a new property, 'uadmin_boot_archive_sync', to config group in svc:/system/boot-config:default service. The default value of this property is config/uadmin_boot_archive_sync boolean false uadmin(2) system call will respect this property setting when determining whether to update boot-archive before rebooting. Customer may set this value to true if they want to reboot/halt/shutdown the system using uadmin interface and ensure that the boot archive remains in sync. 4.2. Bug/RFE Number(s): 6795430 newboot needs a fully supported way to automatically recover when boot archive is out of date 4.6. Doc Impact: Some additions required to Basic Administration guide, uadmin (2) and uadmin(1M) man pages to describe the new property introduced and how to make use of this property to update the boot-archive. 4.6.1 Man page of uadmin(2) and uadmin(1M) Shutting down or rebooting or halting the system by means of uadmin does not update the boot archive by default. To update the boot archive during these operations, set the uadmin_boot_archive_sync property of boot-config service to true. # svccfg -s svc:/system/boot-config:default setprop \ config/uadmin_boot_archive_sync=true 4.8 Interfaces: svc:/system/boot-config committed per PSARC/2008/760 config/uadmin_boot_archive_sync committed boolean property 4.12. Dependencies: PSARC/2008/760 Boot configuration Service. Solaris 10 doesn't have this project integrated. This project introduces the boot-config service (but not fast reboot itself) portion of PSARC/2008/760. 5. Reference Documents: CR 6795430 http://monaco.sfbay/detail.jsf?cr=6795430 PSARC/2008/760 http://sac.sfbay/PSARC/2008/760/ 6. Resources and Schedule: Prototype is ready 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
2009/310 Disk IO PM Enhancement 1999/388 2005/250 2008/465
On 05/19/09 06:23 PM, Edward Pilatowicz wrote: On Tue, May 19, 2009 at 10:37:45AM -0700, Terry Whatley wrote: 4.3.4 disk power attribute driver properties sd(7D) will export a set of driver properties to indicate a disk's power attributes. See Table-2. Table-1 Disk Power Attribute Properties (array properties are indexed by power state in order of ascending power levels) Prop NameProp Type| Prop Description pm-resource-type String| resource-spindle-disk for the | spindle disks pm-perf Integer array | array of average R/W | performance percentages pm-pwr-saving Integer array| array of average power saving in | units of 0.1watt pm-latency Integer array| array of time to first data in units | of 100ms exporting performance statistics via device properties seems weird to me. is there a precedent for this? why isn't this information being exported via kstats? do we really want to train users to start using prtconf -v to get performance data? ed I think these are not performance statistics. I believe that these are static arrays that are specific for a device type (most likely Sun disks only), that correlate specific power level with performance and power savings. These properties, I believe, are to be used by a storage power manager to decide at what power level disk should run at given time. Jane Chu may correct me here... -Pawel
