Public GLDv3 Interfaces [PSARC/2009/638 FastTrack timeout 11/26/2009]
The following minor case updates and corrections have been made: - man page update and cleanup - add MC_PROPERTIES mac_callback flag - rename MAC_HCK_* mac_hcksum flags to HCK_* - add LSO_TX_BASIC_TCP_IPV4 flag to interface table - add MC_* flags to interface table The case materials have been updated at: http://arc.opensolaris.org/caselog/PSARC/2009/638/ The differences are located in the /diffs directories in the *.diff2 files. http://arc.opensolaris.org/caselog/PSARC/2009/638/diffs/proposal.diff2 http://arc.opensolaris.org/caselog/PSARC/2009/638/materials/diffs/mac_provider.diff2 http://arc.opensolaris.org/caselog/PSARC/2009/638/materials/man/diffs/README.diff2 http://arc.opensolaris.org/caselog/PSARC/2009/638/materials/man/diffs/mac-9e.diff2 http://arc.opensolaris.org/caselog/PSARC/2009/638/materials/man/diffs/mac-9f.diff2 http://arc.opensolaris.org/caselog/PSARC/2009/638/materials/man/diffs/mac_callbacks-9s.diff2 http://arc.opensolaris.org/caselog/PSARC/2009/638/materials/man/diffs/mac_hcksum_get-9f.diff2 http://arc.opensolaris.org/caselog/PSARC/2009/638/materials/man/diffs/mac_lso_get-9f.diff2 http://arc.opensolaris.org/caselog/PSARC/2009/638/materials/man/diffs/mac_prop_info_set_perm-9f.diff2 Cheers, Jim
Public GLDv3 Interfaces [PSARC/2009/638 FastTrack timeout 11/26/2009]
This case has been marked closed approved. Cheers, Jim
Public GLDv3 Interfaces [PSARC/2009/638 FastTrack timeout 11/26/2009]
(cleaned up version) The case materials have been updated (diff files showing the changes are included). This case has received three +1s and the timeout has expired. I plan to mark this case closed approved at the end of the day. Cheers, Jim
Public GLDv3 Interfaces [PSARC/2009/638 FastTrack timeout 11/26/2009]
The case materials have been updated (diff files showing the changes have been included). This case has received three +1s and the timeout has expired. I plan mark this case closed approved at the end of the day. Cheers, Jim
libstatgrab [PSARC/2009/583 FastTrack timeout 11/01/2009]
Thanks Mike. Since this was the remaining item to be addressed, and the timeout has been reached, I'm going to mark this case closed approved. Cheers, Jim Michael Corcoran wrote: Here are the anoninfo and cpu_vminfo stats being used. anoninfo.ani_max; anoninfo.ani_resv; cpu_vminfo.pgpgin; cpu_vminfo.pgpgout; Can someone knowledgeable give an idea of their reliability? >>> >>> I ran these by a few VM people and we all agree that these should be >>> relatively stable. >> >> Thank you, that makes me happier. Are any of them willing to have >> their names listed here? > First there's my name, then Blake Jones and Stan Studzinski. > > --Mike
libstatgrab [PSARC/2009/583 FastTrack timeout 11/01/2009]
Garrett D'Amore wrote: > Jim Walker wrote: >> Garrett D'Amore wrote: >>> Can you add *which* kstats are being used? Individual kstats are >>> normally not documented, and some of them are more volatile than >>> others. If this case is going to use kstats, then I think we need to >>> document which ones are used in case someone decides to change them >>> in the future. >> >> Appendix A. in the proposal file has been updated to include the >> individual kstat information. >> >> Cheers, >> Jim > > Thanks. The stats you're using look reasonable to me, but I'd like to > hear from someone more familiar with the VM subsystem -- the anoninfo > and cpu_vminfo stats might be unreliable... Here are the anoninfo and cpu_vminfo stats being used. anoninfo.ani_max; anoninfo.ani_resv; cpu_vminfo.pgpgin; cpu_vminfo.pgpgout; Can someone knowledgeable give an idea of their reliability? Currently, we are assuming they are as reliable as any other stat. I would like to wrap up this case. Here's the full proposal: http://arc.opensolaris.org/caselog/PSARC/2009/583/proposal.txt Cheers, Jim
libstatgrab [PSARC/2009/583 FastTrack timeout 11/01/2009]
Garrett D'Amore wrote: > Can you add *which* kstats are being used? Individual kstats are > normally not documented, and some of them are more volatile than > others. If this case is going to use kstats, then I think we need to > document which ones are used in case someone decides to change them in > the future. Appendix A. in the proposal file has been updated to include the individual kstat information. Cheers, Jim
libstatgrab [PSARC/2009/583 FastTrack timeout 11/01/2009]
Garrett D'Amore wrote: > Darren J Moffat wrote: >>> libstatgrab works with root and non-root privileges. If root privileges >>> are given, then libstatgrab returns more information. The sg_init() >>> function performs all the one-time initialization including operations >>> that use setuid/setgid privileges if root privilege is used. Afterwards, >>> sg_drop_privileges() is used to discard setuid/setgid privileges. The >>> following code is common in commands using libstatgrab: >> >> How does this fit with OpenSolaris given we don't actually use a uid==0 is >> all powerful model anymore ? setuid root does still work they way it used >> to but we try not to document things that away any more; instead say which >> privileges are required. >> >> What operations that libstatgrab does, on OpenSolaris, require privilege >> and what privileges are they ? [ not that root is NOT a privilege it is a >> userid that by default happens to have all privileges ]. >> >> kstats don't need privileges to view them anyway, so I'm not sure what >> operations that libstatgrab provides would need any privilege. >> > I think it was using root privilege to access some portions of the device > tree. (Accessing the information from the prom requires root, IIRC.) Correct. Historically it was related to the device tree. > This should be reevaluated, because it shouldn't be needed. The project team has reevaluated the need for root privileges. Root privileges are not needed, and user and root statgrab runs with a diff file are included in the materials directory to show this. ../materials/statgrab.root.out ../materials/statgrab.user.out ../materials/statgrab.user.root.diff This has also been noted in the proposal.txt file. Cheers, Jim
libstatgrab [PSARC/2009/583 FastTrack timeout 11/01/2009]
Garrett D'Amore wrote: > Mostly I like this, having reviewed the documentation on the website as > well. > > A few things I'd like to see in this case before I assert +1: > >1) a list of the actual interfaces (routines) provided... you'll need > to provide man pages for them anyway, so this shouldn't be too onerous > ... along with commitment levels for each (probably all Uncommitted) > >2) a list of interfaces being *imported*, along with the stability > for each, for any non-public interfaces. (I suspect that it uses > several such interfaces, although I've not checked the code. Some of > the details may be challenging to collect.) > >3) for Network interfaces, I'd like to know how it collects the > details -- does it use libdlpi? Does it use kstats? libdladm? Will > it show up vnics and other crossbow kinds of pseudo-interfaces? The project team has updated the proposal.txt file with the requested information. http://sac.sfbay/arc/PSARC/2009/583/proposal.txt http://arc.opensolaris.org/caselog/PSARC/2009/583/proposal.txt (may not be pushed yet) In addition, output from another statgrab run is provided that shows crossbow vnic information. kstats is used. http://sac.sfbay/arc/PSARC/2009/583/materials/statgrab.vnic.txt net.vnic0.collisions = 0 net.vnic0.duplex = unknown net.vnic0.ierrors = 0 net.vnic0.interface_name = vnic0 net.vnic0.ipackets = 0 net.vnic0.oerrors = 0 net.vnic0.opackets = 31 net.vnic0.rx = 0 net.vnic0.speed = 0 net.vnic0.systime = 1256701191 net.vnic0.tx = 2152 net.vnic0.up = true Cheers, Jim
libstatgrab [PSARC/2009/583 FastTrack timeout 11/01/2009]
Robs wrote: > If someone would help me offline with this, I'd really appreciate it. Rob, I can help you. It's a reasonable request. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
[2009/467] Solaris ATCA IPMI Driver
An updated 20questions doc has been posted for this case, which is being reviewed at the PSARC meeting tomorrow. Cheers, Jim
ettcp [PSARC/2009/508 FastTrack timeout 09/29/2009]
This case was approved at todays PSARC meeting. Cheers, Jim
ettcp [PSARC/2009/508 FastTrack timeout 09/29/2009]
Rick Matthews wrote: > As documented in the man page, are suck(1), blow(1), speedto(1) and > speedfrom(1) required? > Or are they just mis-applied to the man page. They are associated utilities that utilize ettcp. The project team has reviewed them and decided they will not be delivered. The man page can be updated to not reference them. Cheers, Jim
Where is the meta-architecture to support FOSS?
Garrett D'Amore wrote: > I believe it is perfectly reasonable to allow users to push their favorite > bits into /contrib, skip the ARC review, and allow the community to support > those packages on a caveat emptor basis. The rest of the stuff, we should > continue reviewing, using the same faculties that we have heretofore been > using -- intelligent review by human engineers. I contend that the existing > process works for these cases. I'm in general agreement with this. Case by case review gives us the best chance at providing or at least documenting interface stability while allowing us to evolve, and hopefully get better, as new innovations are made. I don't believe in special cases, especially since non-Sun initiated cases could become the majority over time as OpenSolaris becomes more dominate due to both its Sun and non-Sun derived technologies. Like several have said, and J?rg Schilling summarizes nicely: "The most obvious solution for this problem is to establish more collaboration with the community." In order to better match reality, we need to connect more with key "external" open source projects, and continue to do whatever we can to bring the community into the architecture review process, including actively recruiting more "external" ARC members from key open technology areas. Ultimately I think diversity provides the most strength and stability over time. Cheers, Jim
pmtools [PSARC/2009/458 FastTrack timeout 09/01/2009]
Scott Rotondo wrote: >> >> USAGE >> PRIV_FILE_DAC_READ privileges are necessary to use this >> utility to access /dev/xsvc. >> > > Nit: That's a single privilege. "The PRIV_FILE_DAC_READ privilege is > necessary ..." Thanks. Updated. USAGE The PRIV_FILE_DAC_READ privilege is necessary to use this utility to access /dev/xsvc. Cheers, Jim
pmtools [PSARC/2009/458 FastTrack timeout 09/01/2009]
The timeout for this case has expired and all issues have been addressed, including changing the package name to SUNWacpidump and using the following text in the man pages: USAGE PRIV_FILE_DAC_READ privileges are necessary to use this utility to access /dev/xsvc. The proposal.txt file and man pages in the case directory have been updated. I'm marking this case closed approved. Cheers, Jim
Where is the ARChitecture? (Re: FOSS to /contrib -- a bikeshed paint argument)
Nicolas Williams wrote: > On Tue, Sep 01, 2009 at 10:46:55AM -0700, Garrett D'Amore wrote: >>> >>> - /contrib is a not good place for Sun projects to integrate into -- >>> aim for /dev & /release if you can; >> Why? I think /contrib is perfectly reasonable for projects that just >> want to enable something, and don't want to make support guarantees. We >> have no other way to deliver 'caveat emptor' bits that I can see. If >> /contrib works for the rest of the community, why not also Sun? I agree. > Precisely because there's no commitment to keep anything in /contrib > working. That's fine for: a) random third parties, b) as a stepping > stone to /dev and /release (e.g., for alpha and beta testing purposes). I think that generalization limits us. The contrib repo is a community driven place to put OpenSolaris software packages and serves multiple needs. Some packages are well maintained some aren't. Some packages may be destine for /dev and /release, and some may live in /contrib indefinitely. /contrib gives us a lot of options that we can leverage. >>> - What is the architectural status of /contrib? IMO: none. /contrib >>> is for third party contributions that are not yet ready to integrate >>> into /dev & /release; It's more than that. Many /contrib packages have no interest in moving to /dev or /release nor can Sun support an infinite number of packages. Also, /contrib packages can take advise from ARC and meet most if not all the Solaris architecture rules, and the community can decide how closely ARC rules are followed. The /contrib repo in conjunction with the Source Juicer and Package Factory is primarily a mechanism to quickly increase the software content of OpenSolaris to better satisfy the needs of OpenSolaris end users and developers. Beyond this we have a lot of room to grow and the ARC teams can provide a lot of guidance. >> I'd really like to have something like "External", which would mean that >> Sun (or the Solaris org) makes no guarantees about interface stability, >> we just follow the upstream. Caveat emptor sort of thing. > > Yes, I agree with this. We need an adjective that indicates that > something is of third party origin and that advertised interface > stability is advisory only, not necessarily reliable. Yes. A clearer tie with reality would be good. >>> We might even need to deliver more than two versions of some FOSS. >> This way generally lies madness. There are some specific counter >> examples were it has worked out (multiple perl versions for example), >> but doing this generally for shared libraries will cause huge kinds of >> problems. We need to have this flexibility on a case by case basis. We need to keep our options open, so we can continue to evolve. Some parts of the architecture need to be static and some parts can bend and evolve into new taxonomies. There are too many approaches to open source code and code releases to blindly apply one set of architectural constraints to all packages. > We will have these choices when the upstream community breaks > compatibility: > > a) don't update; > b) warn, update and break compatibility and oh well; > c) deliver multiple versions, risk DLL hell; > d) fund an effort to restore backwards compatibility and contribute the >fixes back upstream; > e) fund an effort to restore backwards compatibility and fork; ... >>> The practically inescapable conclusion is that we should just allow out >>> of cycle backwards incompatible changes (after some teeth gnashing, >>> perhaps), >> This has already happened for specific cases. I think its OK but it >> needs to be an exception and such cases carefully reviewed for impact. Right. Review allows us to engage with the specific case and consider the bigger picture and see what fits and what doesn't, and do our best to meet the needs of current and future users and developers. Cheers, Jim
pmtools [PSARC/2009/458 FastTrack timeout 09/01/2009]
Terry (Sarito) Whatley wrote: > Is it really necessary to use the "pmtools" name? None of the commands seem > to use this name. There are many other things that might eventually be > included in a collection of "pm tools", including some we already have > (powertop comes to mind), and some that we will want for SPARC as well. It > seems a shame to burn the name for such a small specific thing, when it is > really an ACPI-specific set of commands. The only place pmtools shows up on > the referenced url is in the name of the tar file ... Some unix distros use pmtools some use acpidump as the package name. http://packages.gentoo.org/package/sys-power/pmtools http://www.opencsw.org/packages.php/acpidump http://packages.ubuntu.com/dapper/acpidump ccing Aubrey Li, the upstream maintainer, who Pat was been working with. Pat, Aubrey, Do you have input in terms of which package name to use? Cheers, Jim
idzebra [PSARC/2009/424 FastTrack timeout 08/14/2009]
The timeout for this case has been reached and all issues have been resolved. I'm marking this case closed approved. Cheers, Jim
2009/424 [idzebra]
Garrett D'Amore wrote: > > My preference is that if the utility would only ever be run by an > administrator to debug a service, or to start up something manually that > should have been started by SMF, then /usr/lib is probably better. If > it is a reasonable thing that administrators might need to run this > command manually, then /usr/sbin or /usr/bin. Thanks to everyone providing input on this. When I get some time (ha) I may take a stab at improving the target directory mapping information. Based on this input. The project team will locate zebrasrv in /usr/bin. Cheers, Jim
2009/424 [idzebra]
Garrett D'Amore wrote: > I think that it makes sense to at least *try* to move zebrasrv out of > /usr/bin. /usr/lib seems the right place for it. Since zebrasrv has good command definition and /usr/bin is the familiar location (ie. I'm not seeing /usr/lib being used anywhere else). I think /usr/bin is the best place for now. Cheers, Jim
idzebra [PSARC/2009/424 FastTrack timeout 08/14/2009]
Darren J Moffat wrote: > > It is a little unfortunate that we already have usr/sbin/zebra that is > nothing to do with this. However I don't beleive any changes to this case > are required as a result of that since there is not path name conflicts even > though there are similar ones /usr/sbin/zebra vs /usr/bin/zebrasrv. Right. We considered this. There aren't any namespace conflicts with the current zebra package and the names used in this case are still the "familiar" ones. Cheers, Jim
[desktop-discuss] Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009]
>>4.5. Interfaces: >> >> Exported Interface >> >>Interface Classification Comments >>- -- -- >>SUNWraptorUncommitted Package name >>SUNWraptor-devel Uncommitted Package name >>/usr/bin/rapper Volatileparser utility >>/usr/bin/raptor-configVolatileconfig utility >>/usr/lib/libraptor.so.1 Volatilelibrary >>/usr/share/man/man1/rapper.1 Volatileman page >>/usr/share/man/man1/raptor-config.1 >> Volatileman page >>/usr/share/man/man3/libraptor.3 Volatileman page >>/usr/lib/pkgconfig/raptor.pc Volatilepc file >>/usr/include/raptor.h VolatileHeader file >>/usr/share/gtk-doc/html/raptorVolatilehelp file Some comments: 1. Man pages aren't interfaces and shouldn't be included here. 2. Documentation isn't an interface and shouldn't be include here. 3. Individual include files don't need to be specified. 4. Package classifications should match interface classifications. 5. Library symlink should be provided. Here's what I end up with: Interface Classification Comments - -- -- SUNWraptorVolatilePackage name SUNWraptor-devel VolatilePackage name /usr/bin/rapper Volatileparser utility /usr/bin/raptor-configVolatileconfig utility /usr/lib/libraptor.so Volatilelibrary symlink /usr/lib/libraptor.so.1 Volatilelibrary /usr/lib/pkgconfig/raptor.pc Volatilepc file /usr/include/ VolatileHeader files Also, it would be good for the desktop community to evaluate the current strategy of only delivering 64bit libraries as needed. It's normally easier for engineers to produce both archs at the time of initial putback then later, and we are seeing more and more interest in community members wanting to produce 64bit ready desktops. Because of this, "as needed" strategy it creates a barrier. If you are concerned about space, you could include the 64bit libraries only in the devel packages for now. Cheers, Jim
WebKit 1.1.x [LSARC/2009/409 FastTrack timeout 08/04/2009]
Alfred Peng wrote: > > As for the header files, I just compare the new pkgmap with the old one. > They contain the same set of files. On the other hand, the "Exported > Interface" /usr/include/webkit-1.0 was declared to be Volatile in the > previously arc. I think it's not necessary to list the file changes in > that folder. Please correct me if I'm wrong. That's fine. You don't need to list the header files for diffs. I just wanted to make sure ../webkit-1.0* was still being used. Thanks for the detail on the versioning. It is non-standard :) Cheers, Jim
WebKit 1.1.x [LSARC/2009/409 FastTrack timeout 08/04/2009]
John Fischer wrote:
> Jim,
>
> The OSD (formerly JDS) group will have both a regular end user package
> and a developer package. The developer package will typically contain
> things relating to header files, package configuration scripts and
> sometimes developer documentation. Other packages that you will see
> with the OSD group will be root (and used to have doc) packages.
Thanks John.
This brings up another point. This case is a delta case for
LSARC/2008/782.
http://arc.opensolaris.org/caselog/LSARC/2008/782/mail
What version of WebKit will be included in the package(s)?
It looks like 1.1.11 is the current version.
Are there any header file changes, so the header file directory
should at least be listed?
Is this directory going to continue to be used?
/usr/include/webkit-1.0
Are these files going to continue to be used?
/usr/lib/pkgconfig/webkit-1.0.pc
/usr/lib/${MACH64}/pkgconfig/webkit-1.0.pc
libwebkit-1.0* is being used in the library naming instead of
libwebkit-1.1* why?
Cheers,
Jim
WebKit 1.1.x [LSARC/2009/409 FastTrack timeout 08/04/2009]
Brian Cameron wrote: > 4.8. Packaging & Delivery: > > The project will be delivering the following packages: > SUNWwebkit > SUNWwebkit-devel What's the difference between the two packages if any? Cheers, Jim BTW. You may want to update 1.4.4. OPG is not a BU anymore.
fakeroot [PSARC/2009/406 FastTrack timeout 07/28/2009]
This case was approved at todays PSARC meeting. Cheers, Jim
fakeroot [PSARC/2009/406 FastTrack timeout 07/28/2009]
Garrett D'Amore wrote: > > The other thing is that one could imagine giving folks their own zones > (sparse root probably!) to do this, which would allow root to be used > "safely". We provide development zones in the test farm for this purpose. It's been available for some time now, and we plan to expand this using crossbow. Cheers, Jim
fakeroot [PSARC/2009/406 FastTrack timeout 07/28/2009]
Garrett D'Amore wrote: > I don't understand the point of this. Why is this kind of emulation > helpful? Is this just to create honeypot? Or am I missing something. You may want to look at this more slowly. > Some additional information is also missing ... what privileges does the > faked run under? Who inserts the LD_PRELOAD into the environment? Is > this done using fakeroot(1) to execute the program? User. Yes. > It would be nice to have man pages handy without having to download the > source code to extract them. The man pages are posted in the materials directory. > Also, some of your exported interfaces are not declared with stability > levels. What exported interfaces are you referencing? The 'Faked' functions are not exported. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
yaz [PSARC/2009/368 FastTrack timeout 06/30/2009]
I updated this case to include a pointer to the gnutls LSARC/2008/341 yaz contract in the materials directory. Cheers, Jim
yaz [PSARC/2009/368 FastTrack timeout 06/30/2009]
This case received a +1 and all comments have been addressed and the timeout has expired. I'm marking this case closed approved. Cheers, Jim
Pipe Viewer (pv) [PSARC/2009/350 FastTrack timeout 06/18/2009]
During pkgrti approval Alan Steinberg requested that the Pipe Viewer package name be changed from SUNWpv to SUNWpipe-viewer so it would be more descriptive for the user. Huajian from the project team agreed with this change. I updated the proposal.txt file in the case directory to show this change. This email documents this change, which I think is under the threshold of needing a review. Cheers, Jim
disktype [PSARC/2009/356 FastTrack timeout 06/21/2009]
After reviewing this case with the project team, I'm marking this case closed withdrawn until they are in a better position to address the issues discussed during the arc review and have the resources needed to complete the project. Cheers, Jim
nfswatch [PSARC/2009/295 FastTrack timeout 05/14/2009]
After reviewing this case with the project team, I'm marking this case closed withdrawn until they are in a better position to address the issues discussed during the arc review and have the resources needed to complete the project. Cheers, Jim
sysbench [PSARC/2009/351 FastTrack timeout 06/18/2009]
All comments for this case have been addressed and the timeout has been reached. I'm marking this case closed approved. Cheers, Jim
sysbench [PSARC/2009/351 FastTrack timeout 06/18/2009]
Mark Martin wrote: 4.0 Interfaces 4.1 Exported Interfaces Interface NameClassificationComments --- --- SUNWsysbenchUncommittedPackage /usr/benchmarks/sysbench/sysbench Uncommitted Executable binary file >>> >>> PSARC 2007/448 set the precedent that this should probably be >>> /usr/benchmarks/sysbench/bin/sysbench I would like to go with the above like filebench PSARC/2007/448. It was first and discussed extensively. Peter, If this is ok with you and there are no other comments, I would like to close this case. >> Understood, and I'll make the change. I had been distracted by PSARC >> 2008/461 (bonnie++) which did not use the bin directory. Should I >> also add a symlink in /usr/bin as in 2007/461? bonnie++ and some recent benchmarks probably should be looked at again. I may be able to take a look in a few weeks. Cheers, Jim
libtool [PSARC/2007/557 Self Review]
As part of the update to guile to provide 64-bit libraries, libtool, a guile dependency, also needed to provide 64-bit libraries. libtool64.txt has been added to the case directory to document this change. This is planned to be updated as part of the guile integration into the SFW consolidation. Cheers, Jim --- 64-bit Interface Additions == Exported Interfaces Classification Comment --- -- -- SUNWlibtool Uncommitted Package /usr/lib/64/libltdl.so Uncommitted symbolic link /usr/lib/64/libltdl.so.3Uncommitted symbolic link /usr/lib/64/libltdl.so.3.1.4Uncommitted 64-bit library 64 = amd64 | sparcv9 Reference Documents === Bug: 6832880 libtool need to provide 64bit library
Opinion for review -- 2008/772 Command Assistant
Jim Walker wrote: > Mark Martin wrote: >> Please find attached (and text inline) the draft opinion for 2008/772 >> Command Assistant. Commentary, concerns, criticisms, and corrections >> wanted. Please. >> _ >> >> Project Private: >> /usr/lib/commandassistant/CommnadAssistant.jar >> /usr/lib/commandassistant/lib/jaxb-api.jar >> /usr/lib/commandassistant/lib/sjsxp.jar >> /usr/lib/commandassistant/lib/jsr173_api.jar >> /usr/lib/commandassistant/lib/jaxws-api.jar >> /usr/lib/commandassistant/lib/jsr250-api.jar >> /usr/lib/commandassistant/lib/FastInfoset.jar >> /usr/lib/commandassistant/lib/jaxb-xjc.jar >> /usr/lib/commandassistant/lib/streambuffer.jar >> /usr/lib/commandassistant/lib/jaxws-rt.jar >> /usr/lib/commandassistant/lib/http.jar >> /usr/lib/commandassistant/lib/saaj-api.jar >> /usr/lib/commandassistant/lib/jsr181-api.jar >> /usr/lib/commandassistant/lib/jaxws-tools.jar >> /usr/lib/commandassistant/lib/saaj-impl.jar >> /usr/lib/commandassistant/lib/stax-ex.jar >> /usr/lib/commandassistant/lib/jaxb-impl.jar >> /usr/lib/commandassistant/lib/activation.jar >> Also, does this account for the fact that most if not all of these are separate FOSS projects with various licensing? I think it is better to port these separately then combine them like Drools LSARC/2008/748 did. Cheers, Jim
autogen and guile [PSARC/2008/315 Self Review]
The project team is updating guile to include 64-bit versions of the libraries to meet ARC 64-bit library standards. proposal64bit.txt has been added to the case directory. autogen and guile are planning to be integrated into the SFW consolidation. I think this can be handled as a self review. Cheers, Jim --- 64-bit Interface Additions == Exported Interfaces Classificat Comment --- --- -- SUNWguile Uncommitted Package /usr/lib/64/libguile.so Uncommitted symbol link /usr/lib/64/libguile.so.17Uncommitted symbol link /usr/lib/64/libguile.so.17.1.2Uncommitted 64-bit library /usr/lib/64/libguilereadline-v-17.so Uncommitted symbol link /usr/lib/64/libguilereadline-v-17.so.17 Uncommitted symbol link /usr/lib/64/libguilereadline-v-17.so.17.0.3 Uncommitted 64-bit library /usr/lib/64/libguile-srfi-srfi-1-v-3.so Uncommitted symbol link /usr/lib/64/libguile-srfi-srfi-1-v-3.so.3 Uncommitted symbol link /usr/lib/64/libguile-srfi-srfi-1-v-3.so.3.0.1 Uncommitted 64-bit library /usr/lib/64/libguile-srfi-srfi-4-v-3.so Uncommitted symbol link /usr/lib/64/libguile-srfi-srfi-4-v-3.so.3 Uncommitted symbol link /usr/lib/64/libguile-srfi-srfi-4-v-3.so.3.0.1 Uncommitted 64-bit library /usr/lib/64/libguile-srfi-srfi-13-14-v-3.so Uncommitted symbol link /usr/lib/64/libguile-srfi-srfi-13-14-v-3.so.3 Uncommitted symbol link /usr/lib/64/libguile-srfi-srfi-13-14-v-3.so.3.0.1 Uncommitted 64-bit library /usr/lib/64/libguile-srfi-srfi-60-v-2.so Uncommitted symbol link /usr/lib/64/libguile-srfi-srfi-60-v-2.so.2Uncommitted symbol link /usr/lib/64/libguile-srfi-srfi-60-v-2.so.2.0.2Uncommitted 64-bit library 64 = amd64 | sparcv9 Reference Documents === [1] http://www.gnu.org/software/autogen/ [2] http://www.gnu.org/software/guile/ RFE ID# 6672584 for autogen RFE ID# 6672583 for guile
Opinion for review -- 2008/772 Command Assistant
Mark Martin wrote: > Please find attached (and text inline) the draft opinion for 2008/772 > Command Assistant. Commentary, concerns, criticisms, and corrections > wanted. Please. > _ > > Project Private: > /usr/lib/commandassistant/CommnadAssistant.jar > /usr/lib/commandassistant/lib/jaxb-api.jar > /usr/lib/commandassistant/lib/sjsxp.jar > /usr/lib/commandassistant/lib/jsr173_api.jar > /usr/lib/commandassistant/lib/jaxws-api.jar > /usr/lib/commandassistant/lib/jsr250-api.jar > /usr/lib/commandassistant/lib/FastInfoset.jar > /usr/lib/commandassistant/lib/jaxb-xjc.jar > /usr/lib/commandassistant/lib/streambuffer.jar > /usr/lib/commandassistant/lib/jaxws-rt.jar > /usr/lib/commandassistant/lib/http.jar > /usr/lib/commandassistant/lib/saaj-api.jar > /usr/lib/commandassistant/lib/jsr181-api.jar > /usr/lib/commandassistant/lib/jaxws-tools.jar > /usr/lib/commandassistant/lib/saaj-impl.jar > /usr/lib/commandassistant/lib/stax-ex.jar > /usr/lib/commandassistant/lib/jaxb-impl.jar > /usr/lib/commandassistant/lib/activation.jar > I cases where jar files are useful beyond Command Assistant why don't they get moved to /usr/share/lib/java for other applications to use? Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
jedit [PSARC/2009/357 FastTrack timeout 06/13/2009]
This case was approved at todays PSARC meeting. Cheers, Jim
Pipe Viewer (pv) [PSARC/2009/350 FastTrack timeout 06/18/2009]
This case was approved at todays PSARC meeting. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
sysbench [PSARC/2009/351 FastTrack timeout 06/18/2009]
Kais Belgaied wrote: > +1 , a quick question though: the release binding is minor, is there > a dependency on future minor release features that are not available > yet as patches to the current minor release of Solaris? No. But can you rephrase, since the question seems too general. Cheers, Jim
sysbench [PSARC/2009/351 FastTrack timeout 06/18/2009]
Mark Martin wrote: > > Minor nit -- you mention it's a "familiarity case", which seems > reasonable, yet 2.3 says "no". > Fixed. Cheers, Jim
disktype [PSARC/2009/356 FastTrack timeout 06/21/2009]
Garrett D'Amore wrote: >> >> I think that was too quick :) The i-team might well agree to patch >> disktype to use libfstyp as a source of information... I've asked for >> that, now let's give them a chance to tell us if they're willing to do >> that :) >> > > Please go back and reread my last statement. If they use libfstyp, then > yes, I'll rescind the derailment. (Or if they figure out another way > to support ZFS.) Without ZFS support, the derailment stands, and I'll > actually vote to deny this case if it comes up for a vote as currently > specified. The project team was already planning to extend disktype to support zfs and work is in progress, but they also saw utility in making disktype available prior to the changes. I'll get them to provide more details on where they are at including incorporating the suggestions by Nico. Cheers, Jim
Pipe Viewer (pv) [PSARC/2009/350 FastTrack timeout 06/18/2009]
Sebastien Roy wrote: > I wonder how many other "/usr/bin/pv" commands there are... Here's one > that's part of the "waon" project, included with Ubuntu: > > http://www.kichiki.com/WAON/pv.html > > There is even an unresolved bug filed against Ubuntu flagging this exact > conflict of /usr/bin/pv being in two different packages > (https://bugs.launchpad.net/ubuntu/+source/waon/+bug/326717). Sigh... > > In any case, the next "pv" will have to deal with it, so +1. Since pipe viewer is intended to be used in command piping, it's probably best to keep it short. Plus it was "first" as Joerg likes to say :) Cheers, Jim
Pipe Viewer (pv) [PSARC/2009/350 FastTrack timeout 06/18/2009]
Currently, the project team is using the man page directly from the tarball and tacking on the available and stability information at the end. However, they will look into your suggestions and work with the upstream community to improve the man page and or package functionality. Cheers, Jim Don Cragun wrote: > On Thu, 11 Jun 2009 20:41:50 -0700 (PDT) James Walker wrote: >> I'm sponsoring this familiarity case for Huajian Luo. The requested >> release binding is minor. The man page has been posted in the >> materials directory. >> > > I find the pv(1) man page a little confusing... > 1. What does: > "pv will copy each supplied FILE in turn to standard output >means standard input)," > at the start of the 3rd paragraph of the description mean? Is the > intent something like: > "pv will copy each supplied FILE in turn to standard output (- >means standard input),"? > > 2. The 2nd paragraph of the description says: > "To use it, insert it in a pipeline between two processes," > but several of the examples show it as the first process in a > pipeline. Are the examples wrong, or is the description wrong? > > 3. The examples use several utilities that I haven't seen added to > Solaris yet. Is this case going to provide them as well? I noted > dialog (which is also in the See Also list), gpg, mcrypt, and nc; > but there may be others. If this case isn't going to provide them, > shouldn't we have an updated man page that doesn't refer to them? > > 4. The DISPLAY SWITCHES section of the OPTIONS sections starts with: > "If no display switches are specified, pv behaves as if -p, -t, >-e, had been given (i.e. everything is switched on)." > but there are other display switches in addition to -e, -p, and -t. > Is the output with no display switches equivalent to: > pv -e -p -t > or to?: > pv -b -e -p -r -t > > 5. Shouldn't -n and -q be listed in the OUTPUT MODIFIERS list instead > of the DISPLAY SWITCHES list? If not, add -n and -q to the last > command line in #4 above. (Except, see #6 below.) > > 6. Aren't -n and -q mutually exclusive? What happens if both are given > on the command line? > > - Don > >
rtorrent & libtorrent [PSARC/2009/336 FastTrack timeout 06/10/2009]
All issues have been addressed and the timeout has been reached. I'm marking this case closed approved. Cheers, Jim
bvi [PSARC/2009/326 FastTrack timeout 06/04/2009]
All issues have been addressed and the timeout has expired. I'm marking this case closed approved. Cheers, Jim
rtorrent & libtorrent [PSARC/2009/336 FastTrack timeout 06/10/2009]
James Walker wrote: > I'm sponsoring this familiarity case for Alex Zhang. The requested > release binding is minor. The man pages have been posted in the > materials directory. The OpenSSL contract link will be posted after > it is approved. I added the approved openssl contract link to the materials directory. Cheers, Jim
pylint [PSARC/2009/325 FastTrack timeout 06/04/2009]
This case was approved during the PSARC meeting. Cheers, Jim
pylint [PSARC/2009/325 FastTrack timeout 06/04/2009]
Sebastien Roy wrote: > Hi Erik, > > On Fri, 2009-05-29 at 11:05 -0700, Erik Lafever wrote: >> Sebastien Roy wrote: >>> It looks like this project makes no backward incompatible changes to any >>> existing software. As such, Minor binding seems unnecessarily >>> restrictive. Why not Patch? > > Any thoughts on this? I updated the proposal.txt file as discussed and changed the requested binding to patch to give us more options. I'll review the logilab library cases too. I recommend this case be approved at the PSARC meeting today. I won't be able to attend. Cheers, Jim
pylint [PSARC/2009/325 FastTrack timeout 06/04/2009]
Shawn Walker wrote: > From what I can tell, there seems to be a random naming pattern to > packages where some of them get named SUNWpyhon-something, others > SUNWPython-something, and yet others SUNWsomething. > > Is there an established practice yet? For now, we will use SUNWpylint until directed otherwise. I don't know of a standard Python naming practice yet. Cheers, Jim
commons-collections [LSARC/2009/296 FastTrack timeout 05/15/2009]
All issues have been addressed, and the timeout has been reached. I'm marking this case case closed approved. Cheers, Jim
Update Perl to version 5.10.x [PSARC/2009/315 FastTrack timeout 06/02/2009]
I. Szczesniak wrote: >> >> > Unlike previous releases, 5.10.x will not integrate in to O/N, but >> > will instead move to SFW. >> >> I'll be glad to see it go (eventually) for the improvement in build >> time, > > Is this the only justification? Bits delivered via SFW commonly have > substandard quality and are very poorly integrated. I fear that > putting a critical system component such as perl into SFW will affect > the quality of Opensolaris as whole piece. I disagree. In general, the SFW pkgs are very high quality. Also, there are many critical system components in SFW already, like gcc, mercurial, zip, rsync, php, p7zip ... Cheers, Jim
Update Perl to version 5.10.x [PSARC/2009/315 FastTrack timeout 06/02/2009]
Garrett D'Amore wrote: > > Not architectural in nature, but I wonder if Perl itself is "meaty" > enough to justify delivering in its own consolidation. It takes a while > to build. But then I have no insight into the release engineering > issues associated having multiple consolidations, and I only work in the > ON consolidation. Anything that shortens build times is a good thing, > though. (Will moving to the SFW consolidation make it more trouble for > people working in that consolidation, though?) > Maybe, but consolidations should have dedicated resources including a tech lead, gatekeeper and PM and cteam members to review changes and integrations and make sure quality standards are met. SFW does all this. I don't recommend one or two person consolidations. If you don't have the staffing to maintain your own consolidation, established ones should be used. Plus, the SFW team is working toward more scalable builds, so developers don't have to build every pkg to integrate. Cheers, Jim
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
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
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
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
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
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
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]
Bobbie wrote: > After seeing the feedback on logilab-common, I will retarget > logilab-astng to python 2.6 > Can I get a +1 from a member on this one? Thanks, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
ejabberd [LSARC/2008/218 closed superceded by PSARC/2008/340]
Housekeeping... I'm closing the orphaned ejabberd LSARC/2008/218 case which was superceded by PSARC/2008/340 which was approved. Cheers, Jim
aalib [LSARC/2009/302 FastTrack timeout 05/21/2009]
Li Fan wrote: > > For those example programs in /usr/demo/aalib, do they must include > source code with them? Where should these source code be placed? > What source code? I didn't see any in your or other aalib packages. If it is not normally delivered, I wouldn't deliver it. But /usr/demo/ and doc locations are not a concern for ARC reviewers anyway. I can help you organize this if needed. Cheers, Jim
aalib [LSARC/2009/302 FastTrack timeout 05/21/2009]
John Fischer wrote: > Fan, > > The files within bin all seem (with the exception aaconfig-lib) > to be example programs for aalib. In fact the man page for aafire > states: > > aafire, aainfo, aasavefont, aatest - aalib example programs > > So I am not sure why they are being included on Solaris with this > project. Or at least I am not sure why they are being include in > /usr/bin. Perhaps /usr/demo/aalib would be more appropriate. If > they are included in /usr/bin I would also expect the man page to > be delivered with an Attributes section. These also do not seem > like they should be Uncommitted but Volatile at best. If these > are in /usr/demo then they are "Not an Interface". Also if you > go the /usr/demo route you might consider including the source > code for these demos along with the binary. > > aaconfig-lib is a utility that makes sense to have in /usr/bin > for developers as it informs them of useful information. It > should also have a man page with an Attributes section. I agree. /usr/demo is better and Li Fan can add an aaconfig-lib manpage. Li Fan and I discussed this but he want to try for the more "familiar" location. Li Fan, Can you confirm these changes are ok with you? Cheers, Jim
libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009]
James Carlson wrote: > Jim Walker writes: >> James Carlson wrote: >>> I urge the project team to consider bringing in at least one >>> application that makes use of this library. Libraries without >>> consumers are, in my opinion, just baggage. And in this case, given >>> that the library also represents functional duplication, it doesn't >>> provide much of an offsetting gain. >>> >> We are looking into this already. >> >> I plan to submit the libexosip2 case after this one which is >> required by many of the osip2 apps. > > We already went through that ... libexosip2 isn't an application, > either. I'm suggesting that having a library as the top level > deliverable isn't necessarily an interesting thing. I understand. We should have a candidate osip2 / exosip2 app soon. The initial app that was driving this case got lost somewhere? I'm still searching the email ;) Maybe these were on the FOSS 500 list. The libraries themselves seemed useful enough to warrant porting on their own. But it is better let the consumer apps drive things more. Cheers, Jim
libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009]
James Carlson wrote: > >>> Are these being delivered by this or by some other project? And do >>> any of them work with the existing libsip? >>> >> These application will not be delivered by this case and I'm not sure if >> someone is working on porting them. None of them works with libsip. > > I urge the project team to consider bringing in at least one > application that makes use of this library. Libraries without > consumers are, in my opinion, just baggage. And in this case, given > that the library also represents functional duplication, it doesn't > provide much of an offsetting gain. > We are looking into this already. I plan to submit the libexosip2 case after this one which is required by many of the osip2 apps. Cheers, Jim
jar file man pages - was Re: trove-2.0.4 [LSARC/2009/262 FastTrack timeout 05/05/2009]
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
snort [PSARC/2009/256 FastTrack timeout 05/04/2009]
This case has come to resolution and the timeout extension of 05/08/2009 has been reached, and it has received a +1. I'm marking it closed approved. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
nfswatch [PSARC/2009/295 FastTrack timeout 05/14/2009]
Sebastien Roy wrote: > On Fri, 2009-05-08 at 01:15 -0700, Garrett D'Amore wrote: >> Even though this is a "Linux familiarity case", I believe that these >> shortcomings are severe enough to warrant derailment. > > FWIW, I agree with your assessment of the problems with this tool. I'll > note that I'm available to help the project team understand the DLPI > related proplems and what can be done to address them. Thanks. As many of you know Helen is a strong member of the NFS team and has good connections with the pkg owner, so I think there is opportunity to improve the current short comings. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
snort [PSARC/2009/256 FastTrack timeout 05/04/2009]
I'm extending the timeout on this case to 5/8/2009. Cheers, Jim
please prune duplicate email addresses
Procedural Note. Before you press send button please remember to prune addresses that are already on the arc email alias. If you are sending case related email and you have more addresses than 1) the arc alias, 2) project team address and 3) the person you are responding to, you probably should do more pruning (ie. if you know someone is on the alias take them off, if you don't, leave the explicit address). We need to avoid bombarding each other with extra emails. Thanks, Jim
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
I'm marking this case status as waiting needs spec. The project team will check with the beanshell community to see how they have handled namespace issues in the past and we will review the findings via email and hopefully resolve at the next PSARC meeting on 05/13/2009. Cheers, Jim
awstats [PSARC/2009/158 FastTrack timeout 03/13/2009]
Note. awstats version 6.9 will be ported instead of version 6.7. There are no interface changes. I will keep the state at closed approved. Cheers, Jim
iozone [PSARC/2009/257 FastTrack timeout 05/04/2009]
This case was approved at todays PSARC meeting. The project team will look at pointing to filebench in the man page. Cheers, Jim
iozone [PSARC/2009/257 FastTrack timeout 05/04/2009]
Phil, I understand your concerns, that's why we ran it by Brendan, who ran it by SAE. As you point out there are issues with iozone in general, and with Solaris. filebench is clearly a much better benchmarking framework. But, it is still a commonly used open source benchmark, and if we don't port it someone else will and we may be in a better position to promote some change upstream. Cheers, Jim Phil Harman wrote: > I have a number of concerns: > > 1) it should be called cachezone, not I/O zone > > Most of the examples in the short Iozone paper do not actually show I/O > performance, but get side-tracked on the various caches in the system. > > 2) it produces hard to understand data, which leads to meaningless > conclusions > > It does nothing useful to explore the size of the filesystem cache, and > can only draw a line between cached and not-cached performance, with it > being especially hard to produce data for non-cached filesystem I/O. > > 3) it is a support call generator > > I had one prestigious customer that was claiming 1GB/sec through a 4Mbps > HBA. I've seen a number of other examples where I have had to make up > for a poor undertanding of that the benchmark does, and why its data > isn't that helpful. And what about the cases where decisions are made on > unchallenged data? > > 3) it is not very Solaris savvy > > Most databases use O_DSYNC (not O_SYNC), but there is not O_DSYNC option > > 4) is it pro VxFS to the exclusion of UFS and others > > It hasVX_DIRECT support, but no notion of directio(3C) > > 5) the options are seemingly random, but not easily extensible > > 6) there is very little control over the workload mix > > 7) we already have filebench > > and so on. > > Phil > > > > James Walker wrote: >> I'm sponsoring this familiarity case for Ivan Shi. The requested >> release binding is minor. The man page has been posted in the >> materials directory. >> >> 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: >> iozone >> 1.2. Name of Document Author/Supplier: >> Author: Ivan Shi >> 1.3 Date of This Document: >> 27 April, 2009 >> 4. Technical Description >> Summary >> === >>Iozone[1] is a filesystem benchmark tool. The benchmark generates >> andmeasures a variety of file operations. It is useful for >> performing a >>broad filesystem analysis of a computer platform. >> >>Iozone3_321 will be integrated into the SFW consolidation as part of >>this proposal, and will be installed as SUNWiozone. >> >>This project requests a minor release binding. >> >> >> Dependencies >> >> >>None >> >> >> Interfaces >> == >> >>Exported InterfacesClassificationComment >>------- >>SUNWiozoneUncommittedPackage >>/usr/benchmarks/iozoneUncommittedCommand >> >>Imported Interfaces >>--- None >> Reference Documents >> === >>[1] http://www.iozone.org/ >> >>RFE ID# 6831877 >> >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >>6.4.1. Consolidation C-team Name: >> SFW >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> >> >
slib [LSARC/2008/211 closed superceded by PSARC/2008/316]
Housekeeping... I'm closing the orphaned slib LSARC/2008/211 case which was superceded by PSARC/2008/316 which was approved. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
mrtg [PSARC/2009/120 FastTrack timeout 04/22/2009]
The update was approved. I'm marking this case closed approved again. Cheers, Jim
mrtg [PSARC/2009/120 FastTrack timeout 04/22/2009]
Can a member give this a +1 so I can close it? Thanks, Jim Jim Walker wrote: > I'm reopening this case for comments to allow the addition of the > following two Project Private directories: > > /usr/lib/mrtg2/ Project Private Perl scripts > /usr/share/mrtg2/ Project Private Icon and Image files > > Since I don't think these changes are controversial and don't > effect public interfaces, I don't think a separate case is required. > The proposal.txt file in the case directory has been updated. > > I plan to reclose the case on 4/22/2009 unless there are issues. > > Cheers, > Jim
mrtg [PSARC/2009/120 FastTrack timeout 04/22/2009]
I'm reopening this case for comments to allow the addition of the following two Project Private directories: /usr/lib/mrtg2/ Project Private Perl scripts /usr/share/mrtg2/ Project Private Icon and Image files Since I don't think these changes are controversial and don't effect public interfaces, I don't think a separate case is required. The proposal.txt file in the case directory has been updated. I plan to reclose the case on 4/22/2009 unless there are issues. Cheers, Jim +++ 2.0 Project Summary 2.1 Project Description MRTG - The Multi Router Traffic Grapher, is a popular tool to monitor network traffic and other system status. ... Here is the complete interface description: 4.0 Interfaces 4.1 Exported Interfaces Interface Name Classification Comments -- --- - SUNWmrtgUncommittedPackage /usr/bin/mrtg UncommittedPerl script /usr/bin/mrtg-traffic-sum UncommittedPerl script /usr/bin/cfgmaker UncommittedPerl script /usr/bin/indexmaker UncommittedPerl script /usr/bin/rateup UncommittedExecutable binary file /usr/lib/mrtg2/ Project Private Perl scripts /usr/share/mrtg2/ Project Private Icon and Image files 4.2 Imported Interfaces Interface Name Classification Comments -- -- -- SUNWgd2Uncommitted Graphics Draw Package SUNWpngVolatilePNG Package SUNWzlib Committed Zip Package SUNWzlibr Committed Zip Package (Root) SUNWlibms Committed Math Package SUNWlibmsr Committed Math Package (Root) Appendix A - References [1] http://oss.oetiker.ch/mrtg/ OSR ID# 10872 RFE ID# 6790397
hal-cups-utils [PSARC/2009/240 FastTrack timeout 04/21/2009]
This case was approved at this weeks PSARC meeting. Cheers, Jim
hal-cups-utils [PSARC/2009/240 FastTrack timeout 04/21/2009]
Norm Jacobs wrote: > Danek Duvall wrote: >> On Tue, Apr 14, 2009 at 02:19:34AM -0700, James Walker wrote: >> >> >>> /usr/lib/cups/backend/halVolatileCUPS backend >>> /usr/lib/hal/hal_lpadmin VolatileHAL hot-plug >>> action >>> >> >> Aren't these really Private? >> >> Danek >> > Yes, they probably should be. Nobody interacts with them directly. > It's all HAL and CUPS backend magic. I updated the proposal.txt file indicating that the above interfaces are project private. Cheers, Jim
libxmlrpc-c [LSARC/2009/218 FastTrack timeout 04/09/2009]
All issues for this case have been addressed and it has received two +1s and the timeout has expired. And, I have added a pointer to the OpenSSL contract-33 file in the materials directory documenting the approvals. And, I have updated the version number to the correct version 1.06.32 in the proposal.txt file (no interface changes from version 1.06.31). I'm marking this case closed approved. Cheers, Jim
tipc Ver 1.7.6 [LSARC/2009/239 FastTrack timeout 04/20/2009]
Mark Carlson wrote: > > Exported InterfaceClassificationComments >=== > == > /opt/SUNWtipc/lib/libtipcsocket.so UncommittedLibrary > symbolic link Since it would be in a bundled product /opt isn't valid: http://opensolaris.org/os/community/arc/policies/install-locations/ ... Isn't this (below) an exported interface? Can you keep all the exported interfaces together above and be explicit about what binary files are being installed? > The binary file would go in "usr/lib/" Cheers, Jim
libxmlrpc-c [LSARC/2009/218 FastTrack timeout 04/09/2009]
Margot Miller wrote: > +1 > > Just curious- the man page mentions tools and libraries for XML-RPC. > Will there be a tools case for this? The exported interfaces in proposal.txt have been updated to include the following tools and C++ libraries: /usr/bin/xmlrpc Uncommitted Command /usr/bin/xmlrpc-c-config Uncommitted Shell script /usr/lib/libxmlrpc++.so.3.06 Uncommitted library /usr/lib/libxmlrpc_server++.so.3.06 Uncommitted library /usr/lib/libxmlrpc_server_abyss++.so.3.06Uncommitted library /usr/lib/libxmlrpc_client++.so.3.06 Uncommitted library /usr/lib/libxmlrpc_cpp.so.3.06 /usr/lib/libxmlrpc++.so.3Uncommitted sym link /usr/lib/libxmlrpc++.so Uncommitted sym link /usr/lib/libxmlrpc_client++.so.3 Uncommitted sym link /usr/lib/libxmlrpc_client++.so Uncommitted sym link /usr/lib/libxmlrpc_cpp.so.3 Uncommitted sym link /usr/lib/libxmlrpc_cpp.soUncommitted sym link /usr/lib/libxmlrpc_server++.so.3 Uncommitted sym link /usr/lib/libxmlrpc_server++.so Uncommitted sym link /usr/lib/libxmlrpc_server_abyss++.so.3 Uncommitted sym link /usr/lib/libxmlrpc_server_abyss++.so Uncommitted sym link And, a xmlrpc.1 manpage has been added to the materials directory, and the libxmlrpc-c.3lib manpage has been updated to include information on the xmlrpc-c-config compile/link helper script. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
libxmlrpc-c [LSARC/2009/218 FastTrack timeout 04/09/2009]
Margot Miller wrote: > +1 > > Just curious- the man page mentions tools and libraries for XML-RPC. > Will there be a tools case for this? Good catch. The example xmlrpc command needs to be added. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
libxmlrpc-c [LSARC/2009/218 FastTrack timeout 04/09/2009]
John Fischer wrote:
> The interface table lists the 64-bit libraries as installing into
> /usr/lib/64/... Does the project actually intend to install these
> libraries into this 64 directory or do you actually mean ${ISAINFO}?
>
> Assuming the later (${ISAINFO}), I +1 this case.
$ISAINFO. /usr/lib/sparcv9 and /usr/lib/amd64 target directories are used
for the 64-bit libraries. "/usr/lib/64" is shorthand.
Cheers,
Jim
--
Jim Walker, http://blogs.sun.com/jwalker
Sun Microsystems, Broomfield, Colorado
bwm-ng [PSARC/2009/160 FastTrack timeout 03/13/2009]
This case received two +1s and the timeout has expired. I am marking the case closed approved. Cheers, Jim
aget [PSARC/2009/159 FastTrack timeout 03/13/2009]
This case received a +1 and the timeout has expired. I am marking this case closed approved. Cheers, Jim
awstats [PSARC/2009/158 FastTrack timeout 03/13/2009]
This case received a +1 and the timeout has expired. I am marking it closed approved. Cheers, Jim (back from vacation)
epydoc [PSARC/2009/149 FastTrack timeout 03/10/2009]
The timeout has been reached for the case with a +1 and comments have been addressed. I'm marking this case closed approved. Cheers, Jim
libconfuse [LSARC/2009/151 FastTrack timeout 03/11/2009]
This case was approved at todays LSARC meeting. Cheers, Jim
bwm-ng [PSARC/2009/160 FastTrack timeout 03/13/2009]
James Carlson wrote: >>> bwm-ng is compile such that it is not dependent on libstatgrab. >> Assuming that change mean that the application lacks any of its >> "normal" functionality, I'll give this +1. > > I meant "doesn't lack," obviously. :-/ Right. It does fine using only kstat. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
clisp [PSARC/2009/141 FastTrack timeout 03/05/2009]
This case was approved at todays PSARC meeting. Cheers, Jim
clisp [PSARC/2009/141 FastTrack timeout 03/05/2009]
Rick Matthews wrote: > Are we supporting a particular version of clisp? The community appears > to be very active. The project team will be delivering the current clisp version 2.47. I'll update the checklist. Cheers, Jim
epydoc [PSARC/2009/149 FastTrack timeout 03/10/2009]
James Carlson wrote: > James Walker writes: >> I'm sponsoring this familiarity case for Jeffrey Huang. The requested >> release binding is minor. The man pages have been posted in the >> materials directory. > [...] >> Does the module include any components that are used or shared by >> other projects? >> [ ] Yes >> [*] No > > Actually, I think that's *all* it contains. Other projects run epydoc > to generate documentation from the marked-up source. > >> Are there any network protocols used by this project? >> [*] Yes >> [ ] No - continue with the next section (section 3.5) > > Really? What "network protocols" are here? (HTML and PDF aren't > really network protocols ...) > >> 3.5 Networking >> Do the components access the network? >> [*] Yes >> [ ] No - continue with the next section (section 3.6) > > In what way? > > I'll give this a +1, even though I think the answers to the checklist > are not quite accurate. I know the underlying sourceforge project > better. :-/ I'll update the checklist. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009]
James Carlson wrote: > What's the point? > > tcpdump is enough like snoop that it seems to me that there's not a > great reason to do this. Instead, it'd be much nicer to see wireshark > integrated (which includes a command line tool that's more powerful > than either tcpdump *or* snoop), and also have snoop yanked from the > product. > > The time spent here could be better spent elsewhere. > >> /usr/bin/tcpdump Uncommitted Executable binary file > > If this just _has to_ be integrated, I think it belongs in /usr/sbin, > just like snoop. It's administrative in nature. tcpdump is on the top 25 miss list, so I guess someone wants it. The project team will reconsider the target directory and it back to you. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
mrtg [PSARC/2009/120 FastTrack timeout 02/27/2009]
Lizhong Li wrote: >> James Carlson wrote: >> >> Should probably say something about where passwords are stored, just >> for completeness. >> > Generally command 'cfgmaker' is used to introduce a config file for > 'mrtg' like this: > # cfgmaker public at 192.168.1.100 > mrtg.cfg > So the 'community' password is stored in the file mrtg.cfg , it's owned > by root and could be saved in any location. The clients from web can't > see this file since they can just access the files allowed by apache. I added this information to a Notes section in the proposal.txt file, and marked this case closed approved. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
