LSARC/2009/518 - Package creation for SQLAlchemy
hi,
Thanks John For your support in the procedure. One more question i
wanted to ask you is now i am porting to python 2.6 but you told python
3.0 also but build machines are not having python 3.0 what to do in this
case.?
Thanks.
Regards,
Shweta
John Fischer wrote:
All,
This project was approved today at LSARC.
Thanks,
John
Mark Martin wrote:
On Fri, Sep 25, 2009 at 6:45 PM, John Fischer John.Fischer at sun.com
wrote:
3.4. Interfaces:
Exported Interface
SUNWsqlalchemy python library will be ported to /usr/lib/python2.6
as well as /usr/lib/python3.0
Interface ClassificationComments
--------
SUNWsqlalchemy UncommitedPackage Name
/usr/lib/python2.6/vendor-packages/ UncommitedDirectory For
sqlalchemy
sqlalchemy library
/usr/lib/python2.6/vendor-packages/ UncommitedDirectory for
SQLAlchemy.egg-info sqlalchemy
library
/usr/lib/python2.6/vendor-packages/ UncommitedObject
relational
mapping
sqlalchemy/orm library
directory.
/usr/lib/python2.6/vendor-packages/ Uncommited
sqlalchemy/ext
/usr/lib/python2.6/vendor-packages/ Uncommited
sqlalchemy/engine
/usr/lib/python2.6/vendor-packages/ Uncommited
sqlalchemy/sql
/usr/lib/python2.6/vendor-packages/ UncommitedDirectory for
different
sqlalchemy/databasesdatabase
support by
sqlalchemy
/usr/lib/python2.6/vendor-packages/Uncommited Directory for
sqlalchemy
sqlalchemy/SQLAlchemy.egg-info
And all above mentioned directories will have python libray files .
(Probably) minor nit -- If you've gone through the trouble of listing
the python2.6 dirs, you may want to list the python3.0 dirs. Or maybe
s/python2.6/${PYTHON} and briefly define ${PYTHON} below... -- much
like we do with ${MACH64}.
Having said that, this case looks fine to me (and I'm glad to see it!)
+1
LSARC/2009/518 - Package creation for SQLAlchemy
hi,
Thanks for reviewing the same .
Regards,
Shweta
Mark Martin wrote:
On Fri, Sep 25, 2009 at 6:45 PM, John Fischer John.Fischer at sun.com wrote:
3.4. Interfaces:
Exported Interface
SUNWsqlalchemy python library will be ported to /usr/lib/python2.6
as well as /usr/lib/python3.0
Interface ClassificationComments
--------
SUNWsqlalchemy UncommitedPackage Name
/usr/lib/python2.6/vendor-packages/ UncommitedDirectory For
sqlalchemy
sqlalchemy library
/usr/lib/python2.6/vendor-packages/ UncommitedDirectory for
SQLAlchemy.egg-info sqlalchemy library
/usr/lib/python2.6/vendor-packages/ UncommitedObject relational
mapping
sqlalchemy/orm library directory.
/usr/lib/python2.6/vendor-packages/ Uncommited
sqlalchemy/ext
/usr/lib/python2.6/vendor-packages/ Uncommited
sqlalchemy/engine
/usr/lib/python2.6/vendor-packages/ Uncommited
sqlalchemy/sql
/usr/lib/python2.6/vendor-packages/ UncommitedDirectory for
different
sqlalchemy/databasesdatabase support by
sqlalchemy
/usr/lib/python2.6/vendor-packages/Uncommited Directory for
sqlalchemy
sqlalchemy/SQLAlchemy.egg-info
And all above mentioned directories will have python libray files .
(Probably) minor nit -- If you've gone through the trouble of listing
the python2.6 dirs, you may want to list the python3.0 dirs. Or maybe
s/python2.6/${PYTHON} and briefly define ${PYTHON} below... -- much
like we do with ${MACH64}.
Having said that, this case looks fine to me (and I'm glad to see it!)
+1
CUPS as the default print service [PSARC/2009/514 FastTrack timeout 10/02/2009]
Venky wrote: Sorry about the delay. Was a long weekend here. Consolidating all queries below. Replies inline. Careful with the quoting; I didn't write half of what you've attributed to me. :-/ On Fri, Sep 25, 2009 at 01:15:42PM -0400, James Carlson wrote: I am sponsoring the following fast-track for Venky TV. The case requests Micro binding and the timeout is 10/02/2009. [...] Targeted release: OpenSolaris 2010.02 Requested binding: Minor You should probably pick a release binding. (For what it's worth, Micro is effectively the same as Minor if you don't also include Patch and if the PAC isn't planning a 10.1 release. But knowing whether you intended to included Patch/Micro release binding, and therefore a potential S10 back-port, would be useful.) We do not intend to backport this to S10. OK ... so Minor sounds about right, and Micro is possibly a typo. -- James Carlson 42.703N 71.076W carlsonj at workingcode.com
CUPS as the default print service [PSARC/2009/514 FastTrack timeout 10/02/2009]
James Carlson wrote: Venky wrote: Sorry about the delay. Was a long weekend here. Consolidating all queries below. Replies inline. Careful with the quoting; I didn't write half of what you've attributed to me. :-/ On Fri, Sep 25, 2009 at 01:15:42PM -0400, James Carlson wrote: I am sponsoring the following fast-track for Venky TV. The case requests Micro binding and the timeout is 10/02/2009. [...] Targeted release: OpenSolaris 2010.02 Requested binding: Minor You should probably pick a release binding. (For what it's worth, Micro is effectively the same as Minor if you don't also include Patch and if the PAC isn't planning a 10.1 release. But knowing whether you intended to included Patch/Micro release binding, and therefore a potential S10 back-port, would be useful.) We do not intend to backport this to S10. OK ... so Minor sounds about right, and Micro is possibly a typo. Argh! It is a typo :-( Thanks for catching that.
IRM Framework Extension(s) [PSARC/2009/505 FastTrack timeout 09/28/2009]
On Mon, 2009-09-21 at 16:45 -0700, Garrett D'Amore - sun microsystems wrote: 1.1. Project/Component Working Name: IRM Framework Extension(s) +1 -Seb
ettcp [PSARC/2009/508 FastTrack timeout 09/29/2009]
On Tue, 2009-09-22 at 11:04 -0700, James Walker wrote: I'm sponsoring this familiarity case for Robin Luo. The requested release binding is minor. The man page has been posted in the materials directory. I don't understand why ettcp exists. It's presumably simply ttcp + extra features. Why aren't these features folded into ttcp instead? Anyway, I can't say that I care enough about the answer to not give this case a +1, so +1. -Seb
audioemu10k device driver [PSARC/2009/519 FastTrack timeout 10/02/2009]
On Sat, 2009-09-26 at 00:06 -0700, Garrett D'Amore - sun microsystems wrote: 1.1. Project/Component Working Name: audioemu10k device driver +1 -Seb
iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009]
On Thu, 2009-09-17 at 03:54 -0700, Fuyuki Hasegawa wrote:
Integrating ibus does not mean to obsolete iiimf or scim, but we would
put them in maintenance state.
What is maintenance state? If you mean that they will remain
supported but that ibus is the preferred method, then making them
Obsolete in the ARC sense would seem like the right thing to do. Is
that what you intend? See
http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/.
4.1.2 Switching between iBus, SCIM and IIIMF
iBus services are started by gnome-session(1). User could
simply enable
or disable the service via gnome-session-properties(1). With
the help of
startup scripts shipped with iiimf and scim, user could set
GTK_IM_MODULE
environment variable in $HOME/.profile to select iBus, IIIMF or
SCIM.
Is the GTK_IM_MODULE variable an interface exported by this case, or was
it part of a previous case?
We plan to change default IM framework from iiimf to ibus in Solaris
Next.
So this case does not change the default IM framework. A future case
will do that. Is that accurate?
4.5. Interfaces:
INTERFACE NAME STABILITYNOTE
---
/usr/bin/ibus-daemon Uncommitted message bus daemon
/usr/bin/ibus-setupUncommitted setup launcher
/usr/libexec/ibus-x11 Uncommitted ibus XIM fontend/agend
/usr/libexec/ibus-gconfUncommitted config backend by gconf-python
/usr/libexec/ibus-ui-gtk Uncommitted panel GUI by pygtk
/usr/lib/libibus.soUncommitted ibus C binding SDK library
/usr/include/ibus-1.0/*Uncommitted ibus C binding header files
/usr/share/gtk-doc/html/ Uncommitted ibus developor documents
ibus/*
/usr/lib/python2.6/Uncommitted ibus Python binding
site-packages/ibus/*
/usr/lib/gtk-2.0/2.10.0/ Uncommitted ibus gtk-im-module
immodules/im-ibus*.so
/usr/lib/{amd64,sparcv9}/ Uncommitted 64bits version of ibus
gtk-2.0/2.10.0/immodules/ gtk-im-module
im-ibus*.so
/usr/share/ibus/setup/*Uncommitted ibus-setup modules
/usr/share/ibus/ui/gtk/* Uncommitted panel GUI by pygtk
/usr/share/ibus/ Uncommitted ibus components registry
components/*like ibus-gconf, ibus-ui-gtk
and IMEs
/usr/libexec/ Uncommitted IME launcher
ibus-engine-IME_NAME
/usr/libexec/ Uncommitted IME setup launcher
ibus-setup-IME_NAME
/usr/share/ibus-IME_NAME Uncommitted IME modules
*IME_NAME is among [anthy, chewing, hangul, m17n, pinyin, table]
/usr/share/ibus-table/*Uncommitted ibus-table engine and
code-tables
I suspect that many of the above are not actually interfaces at all, but
rather internal components of the implementation. No user or
application should be using most of these things directly, so
Uncommitted seems inappropriate. Can you clarify which interfaces you
expect users and applications to interact with directly and give those
appropriate stabilities. Everything else should probably be some kind
of private or not an interface at all.
4.12. Dependencies:
We need python2.6 to be the default in OpenSolaris.
What is the specific case dependency?
-Seb
LSARC/2009/518 - Package creation for SQLAlchemy
Shweta,
You need to have both python 2.6 and python 3.0 packages ready. At some
point in time python 2.6 will disappear. So keep an eye out for python
3.0 to appear within the Solaris / Open Solaris WOS. This project has
a dependency on it but can deliver the python 2.6 packages at any point
in time. Once the python 3.0 packages appear then the project needs to
port to it and make another delivery. You do not need to return for
approval for that new delivery because you are already approved.
Thanks,
John
shweta phabba wrote:
hi,
Thanks John For your support in the procedure. One more question i
wanted to ask you is now i am porting to python 2.6 but you told python
3.0 also but build machines are not having python 3.0 what to do in this
case.?
Thanks.
Regards,
Shweta
John Fischer wrote:
All,
This project was approved today at LSARC.
Thanks,
John
Mark Martin wrote:
On Fri, Sep 25, 2009 at 6:45 PM, John Fischer John.Fischer at sun.com
wrote:
3.4. Interfaces:
Exported Interface
SUNWsqlalchemy python library will be ported to /usr/lib/python2.6
as well as /usr/lib/python3.0
Interface ClassificationComments
--------
SUNWsqlalchemy UncommitedPackage Name
/usr/lib/python2.6/vendor-packages/ UncommitedDirectory For
sqlalchemy
sqlalchemy library
/usr/lib/python2.6/vendor-packages/ UncommitedDirectory for
SQLAlchemy.egg-info sqlalchemy
library
/usr/lib/python2.6/vendor-packages/ UncommitedObject
relational
mapping
sqlalchemy/orm library
directory.
/usr/lib/python2.6/vendor-packages/ Uncommited
sqlalchemy/ext
/usr/lib/python2.6/vendor-packages/ Uncommited
sqlalchemy/engine
/usr/lib/python2.6/vendor-packages/ Uncommited
sqlalchemy/sql
/usr/lib/python2.6/vendor-packages/ UncommitedDirectory for
different
sqlalchemy/databasesdatabase
support by
sqlalchemy
/usr/lib/python2.6/vendor-packages/Uncommited Directory for
sqlalchemy
sqlalchemy/SQLAlchemy.egg-info
And all above mentioned directories will have python libray files .
(Probably) minor nit -- If you've gone through the trouble of listing
the python2.6 dirs, you may want to list the python3.0 dirs. Or maybe
s/python2.6/${PYTHON} and briefly define ${PYTHON} below... -- much
like we do with ${MACH64}.
Having said that, this case looks fine to me (and I'm glad to see it!)
+1
CUPS as the default print service [PSARC/2009/514 FastTrack timeout 10/02/2009]
Hi, Norm Jacobs p??e v ?t 29. 09. 2009 v 13:51 -0500: Garrett D'Amore wrote: [...] 2) Are there any plans to enhance CUPS to distributed network printer configuration via NIS? Or is there a replacement for this service already present? (I guess this is what Bonjour is intended for?) There are no plans for NIS. CUPS supports LDAP, DNS-SD, SLP, and CUPS Browse protocols for print queue advertisement/discovery. Since CUPS is the de facto standard print service on *nix these days, it's interoperable with other systems. Our name service support support isn't. NIS is not Solaris specific feature and fully supported naming service with no EOL plans. Why should admins mantain another naming just for printing? [...] Best regards, Milan
CUPS as the default print service [PSARC/2009/514 FastTrack timeout 10/02/2009]
Milan Jurik wrote: Hi, Norm Jacobs p??e v ?t 29. 09. 2009 v 13:51 -0500: Garrett D'Amore wrote: [...] 2) Are there any plans to enhance CUPS to distributed network printer configuration via NIS? Or is there a replacement for this service already present? (I guess this is what Bonjour is intended for?) There are no plans for NIS. CUPS supports LDAP, DNS-SD, SLP, and CUPS Browse protocols for print queue advertisement/discovery. Since CUPS is the de facto standard print service on *nix these days, it's interoperable with other systems. Our name service support support isn't. NIS is not Solaris specific feature and fully supported naming service with no EOL plans. Why should admins mantain another naming just for printing? NIS is not Solaris specific, but our printers.conf.byname NIS map is. The name service support in CUPS is more dynamic and actually requires less admin work than NIS does for printing under Solaris. -Norm
zpool split [PSARC/2009/511 FastTrack timeout 10/31/2009]
This case was approved in today's meeting. -tim
CUPS as the default print service [PSARC/2009/514 FastTrack timeout 10/02/2009]
This case was approved at the PSARC meeting 30-Sep-2009. Thanks pete
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
CUPS as the default print service [PSARC/2009/514 FastTrack timeout 10/02/2009]
Norm Jacobs wrote: Milan Jurik wrote: NIS is not Solaris specific feature and fully supported naming service with no EOL plans. Why should admins mantain another naming just for printing? NIS is not Solaris specific, but our printers.conf.byname NIS map is. The name service support in CUPS is more dynamic and actually requires less admin work than NIS does for printing under Solaris. Architecturally, though, if it went through the name service switch rather than linking directly with the protocol-specific libraries, it should work fine with NIS, LDAP, or any other NSS-supported feature. -- James Carlson 42.703N 71.076W carlsonj at workingcode.com
ettcp [PSARC/2009/508 FastTrack timeout 09/29/2009]
This case was approved at todays PSARC meeting. Cheers, Jim
ZFS received properties [PSARC/2009/510 FastTrack timeout 09/30/2009]
This case was approved at today's meeting. --matt
Changes to IPsec ESP to support Combined mode ciphers [PSARC/2009/513 FastTrack timeout 09/29/2009]
This case timed out yesterday and has a +1 from a member. Marking this case approved. Regards, -Krishna
PSARC/2009/306 Brussels II - ipadm and libipadm approved
PSARC members voted to approve this case during today's Commitment review. Members voting to approve the case were: Sebastien Roy Glenn Skinner Kais Belgaied Mark Carlson Other members were not participating. The spec will be updated to reflect the change of the netstart path, which will be in /lib as opposed to /sbin as originally specified. -Seb
ettcp [PSARC/2009/508 FastTrack timeout 09/29/2009]
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. -- Rick On 09/22/09 13:04, James Walker wrote: I'm sponsoring this familiarity case for Robin Luo. 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: ettcp 1.2. Name of Document Author/Supplier: Author: Robin Luo 1.3 Date of This Document: 22 September, 2009 4. Technical Description Summary === ettcp[1] is a tool for measuring network throughput. It supports both TCP and UDP protocols and allows the tuning of various parameters, such as message buffer size, the time to run. It can transmit data from stdin. Unlike other tools which might be used for this purpose (such as FTP clients), ettcp does not read or write data from or to a disk while operating, which helps ensure more accurate results. ettcp 1.0 will be integrated into the SFW consolidation as part of this proposal, and will be installed as SUNWettcp. This project requests a minor release binding. Dependencies None Interfaces == Exported Interfaces Classification Comment --- -- -- SUNWettcp Uncommitted Package name /usr/bin/ettcpUncommitted Command Imported Interfaces Classification Comment --- -- -- None Reference Documents === [1] http://sourceforge.net/projects/ettcp/ OSR ID# 12282 RFE ID# 685293 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 -- - 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 -
Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009]
Casper.Dik at Sun.COM wrote: Of course, if other folks think that the original proposal is a proper heavy weight mechanism, please let them speak up. attached new spec. It will no longer use the software driver, but will use a regular file under /var/run. -Nakano -- next part -- An embedded and charset-unspecified text was scrubbed... Name: fast_track-new3.txt URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090930/3c6f99a2/attachment.txt
CUPS as the default print service [PSARC/2009/514 FastTrack timeout 10/02/2009]
On Wed, Sep 30, 2009 at 01:15:32PM -0400, James Carlson wrote:
Norm Jacobs wrote:
Milan Jurik wrote:
NIS is not Solaris specific feature and fully supported naming service
with no EOL plans. Why should admins mantain another naming just for
printing?
NIS is not Solaris specific, but our printers.conf.byname NIS map is.
The name service support in CUPS is more dynamic and actually
requires less admin work than NIS does for printing under Solaris.
Architecturally, though, if it went through the name service switch
rather than linking directly with the protocol-specific libraries, it
should work fine with NIS, LDAP, or any other NSS-supported feature.
Architecturally it couldn't really, since the relevant name service
switch interfaces are not, so far as I can tell from a cursory look,
Public.
In fact, there are two private-looking implementations of
getprinterbyname() in ONNV, like this one from
$SRC/lib/print/libprint/common/nss_printer.c:
int
getprinterbyname(char *name, char *linebuf, int linelen, char *ns)
{
nss_XbyY_args_t arg;
nss_status_tres;
private_ns = ns;
NSS_XbyY_INIT(arg, linebuf, linebuf, linelen, str2printer);
arg.key.name = name;
res = nss_search(db_root, _nss_initf_printers,
NSS_DBOP_PRINTERS_BYNAME, arg);
(void) NSS_XbyY_FINI(arg);
private_ns = NULL;
return (arg.status = res);
}
There's another, similar one in $SRC/lib/print/libpapi-dynamic/common/nss.c.
And that's not enough, since one then has to parse the result (see the
two _cvt_nss_entry_to_printer() implementations in the same two
libraries).
Of course, CUPS could get a contract to use those low-level name service
switch interfaces. Or we could make a Public getprinterbyname(). The
former seems more likely at the moment; anyways, I recommend it.
Nico
--
CUPS as the default print service [PSARC/2009/514 FastTrack timeout 10/02/2009]
Hi,
Nicolas Williams p??e v st 30. 09. 2009 v 12:40 -0500:
On Wed, Sep 30, 2009 at 01:15:32PM -0400, James Carlson wrote:
Norm Jacobs wrote:
Milan Jurik wrote:
NIS is not Solaris specific feature and fully supported naming service
with no EOL plans. Why should admins mantain another naming just for
printing?
NIS is not Solaris specific, but our printers.conf.byname NIS map is.
The name service support in CUPS is more dynamic and actually
requires less admin work than NIS does for printing under Solaris.
Architecturally, though, if it went through the name service switch
rather than linking directly with the protocol-specific libraries, it
should work fine with NIS, LDAP, or any other NSS-supported feature.
Architecturally it couldn't really, since the relevant name service
switch interfaces are not, so far as I can tell from a cursory look,
Public.
In fact, there are two private-looking implementations of
getprinterbyname() in ONNV, like this one from
$SRC/lib/print/libprint/common/nss_printer.c:
int
getprinterbyname(char *name, char *linebuf, int linelen, char *ns)
{
nss_XbyY_args_t arg;
nss_status_tres;
private_ns = ns;
NSS_XbyY_INIT(arg, linebuf, linebuf, linelen, str2printer);
arg.key.name = name;
res = nss_search(db_root, _nss_initf_printers,
NSS_DBOP_PRINTERS_BYNAME, arg);
(void) NSS_XbyY_FINI(arg);
private_ns = NULL;
return (arg.status = res);
}
There's another, similar one in $SRC/lib/print/libpapi-dynamic/common/nss.c.
And that's not enough, since one then has to parse the result (see the
two _cvt_nss_entry_to_printer() implementations in the same two
libraries).
Of course, CUPS could get a contract to use those low-level name service
switch interfaces. Or we could make a Public getprinterbyname(). The
former seems more likely at the moment; anyways, I recommend it.
Yes, getprinterbyname() is private interface and lp is the only
consumer. The question is how lp on other platforms is consuming NIS
maps for printing because websearch reveals that printers in NIS maps
is not Solaris only thing (but not on Linux probably).
Still it is unclear how CUPS will take care or not (for now not) about
printers in nsswitch. I am not saying it is proper solution to use
that interface but it should be evaluated before disbanding lp in the
next phases.
NIS2LDAP is not option for those who are using NIS servers (NIS2LDAP is
wrapper around LDAP server).
Best regards,
Milan
CUPS as the default print service [PSARC/2009/514 FastTrack timeout 10/02/2009]
On Wed, 2009-09-30 at 20:11 +0200, Milan Jurik wrote: Yes, getprinterbyname() is private interface and lp is the only consumer. The question is how lp on other platforms is consuming NIS maps for printing because websearch reveals that printers in NIS maps is not Solaris only thing (but not on Linux probably). Still it is unclear how CUPS will take care or not (for now not) about printers in nsswitch. I am not saying it is proper solution to use that interface but it should be evaluated before disbanding lp in the next phases. Not this case seems appropriate to me. CUPS uses a perfectly modern desktop printer configuration tool that has a discovery feature that displays local printers (i.e. those that I'd actually want to print to) that use modern protocols. This is in contrast to NIS which has an incompatible notion of scope (NIS domain) that results in applications having access to potentially hundreds of printers I'd never want to print to. I'd rather see the printers NIS map Obsoleted rather than extended (and focus more on service discovery rather than directory-based solutions), but that's just my personal opinion. Anyway, not this case. NIS2LDAP is not option for those who are using NIS servers (NIS2LDAP is wrapper around LDAP server). -Seb
CUPS as the default print service
Sebastien Roy wrote: On Wed, 2009-09-30 at 20:11 +0200, Milan Jurik wrote: Yes, getprinterbyname() is private interface and lp is the only consumer. The question is how lp on other platforms is consuming NIS maps for printing because websearch reveals that printers in NIS maps is not Solaris only thing (but not on Linux probably). Still it is unclear how CUPS will take care or not (for now not) about printers in nsswitch. I am not saying it is proper solution to use that interface but it should be evaluated before disbanding lp in the next phases. Not this case seems appropriate to me. CUPS uses a perfectly modern desktop printer configuration tool that has a discovery feature that displays local printers (i.e. those that I'd actually want to print to) that use modern protocols. This is in contrast to NIS which has an incompatible notion of scope (NIS domain) that results in applications having access to potentially hundreds of printers I'd never want to print to. I'd rather see the printers NIS map Obsoleted rather than extended (and focus more on service discovery rather than directory-based solutions), but that's just my personal opinion. Anyway, not this case. [ I've removed the case number. Because it's *not* this case as already noted.] I think this question, directory vs. discovery, is a fairly important one. Certainly discovery based services are often easier for end-users, but the question is, what other discovery services do we use for things *besides* printers. Sites that administer all of their configuration in a directory (NIS or LDAP or whatever) probably want to keep doing that. Changing the administrative *paradigm* might be upsetting for some sites. Additionally, sites might have very good reasons enforce a directory based approach. For example, you don't want someone adding a queue that appears to be the private printer for the HR department, but really just duplicates a copy of everything printed, and then forwards the job to the real HR printer... While directory based approaches might not completely prevent this vector, they are probably a very good start at ensuring that non-tech-savvy users don't misprint to unauthorized devices. - Garrett
OpenSolaris ARC Minutes - 09/30/2009
SYSTEM ARCHITECTURE COUNCIL Platform Software ARC - PSARC Regular Meeting time: Wednesdays 10:00-1:00pm in MPK17-3507. 09-30-2009 MEETING MINUTES Send CORRECTIONS, additions, deletions to psarc-coord at sun.com. Minutes are archived in sac.Eng:/sac/export/sac/Minutes/PSARC. Co-Chair(s): Sebantien Roy: Yes Tim Marsland: no ATTENDEES - Members: (6 active members) Kais Belgaied: Yes Mark Carlson: Yes Richard Matthews: no Darren Moffat: no (on sabbatical) Garrett D'Amore:no Glenn Skinner: Yes Bill Sommerfeld:no (on sabbatical) Gary Winiger: Yes (on sabbatical) STAFF - Asa Romberger (PM): Yes ATTENDEES - Interns: Frank Che no James Falkner: no (on sabbatical) Daniel Hain:no Michael Haines: no Alan Hargreaves:no Phil Harman:no Wyllys Ingersoll: no Darren Reed:no Dean Roehrich no Ienup Sung: no Phi Tranno Brian Utterback:no James WalkerYes Suhasini PeddadaYes Calum MackayYes Mark Martin Yes (external) Don Cragun Yes (external) Guests: -- GUESTS -- Girish Moodalbail Vasumathi Sundaram Sowmini Varadhan Mark Musante David Chieu Pete Dennis Prasad Singamsetty Tim Haley Not all names are captured. Please send email to Asa.Romberger at Sun.com, if you attended the meeting and your name is missing from the list. --- MEETING SUMMARY: AGENDA 09/30/2009 10:00-10:10 Open ARC Business (use open dial in above) 10:10-10:55 Commitment: Brussels II - ipadm and libipadm (2009/306) Submitter: Girish Moodalbail Owner: Sebastien Roy Exposure: open --- Case Anchors: br A HREF=#case1Brussels II - ipadm and libipadm (2009/306)/A br === Fast Tracks: Case (Timeout) Exposure Title 2009/499 (09/24/09) open iBus integration extend to 10/7/2009 2009/501 (09/25/09) open Dynamic Ring Grouping on NICs approved 2009/503 (09/28/09) open usr/lib links for OpenSSL approved 2009/505 (09/28/09) open IRM Framework Extension(s) approved 2009/507 (09/29/09) open FIPS Capable OpenSSL approved 2009/508 (09/29/09) open ettcp approved 2009/510 (09/30/09) open ZFS received properties approved 2009/511 (10/31/09) open zpool split approved 2009/513 (09/29/09) open Changes to IPsec ESP to support Combined mode ciphers approved 2009/514 (10/02/09) open CUPS as the default print service approved 2009/515 (10/02/09) open fragmentation controls for ping and tracerouteapproved 2009/516 (10/02/09) open Timezone cache renewal let it run 2009/519 (10/02/09) open audioemu10k device driver approved Next Meeting: = 10/07/2009 10:00-10:10 Open ARC Business (use open dial in above) 10:10-10:55 Inception: Solaris ATCA IPMI Driver (2009/467) Submitter: Kevin Song Owner: Garrett D'Amore Intern: Jim Walker Exposure: open --- --- 2009/306 Name: Brussels II - ipadm and libipadm Submitter: Girish Moodalbail Owner: Sebastien Roy Status: inception held 06/03/2009 Exposure: open SUMMARY === There are two problems with Administrative utilities for networking that are addressed by this project: (i) As documented in CR 6215036, the ndd(1m) tool lacks Stable interfaces and a well-defined mechanism for applying settings persistently across reboot. This project will introduce a tool, ipadm(1m) that will allow system administrators to
CUPS as the default print service [PSARC/2009/514 FastTrack timeout 10/02/2009]
On Wed, Sep 30, 2009 at 11:29 AM, Sebastien Roy Sebastien.Roy at sun.com wrote: ?I'd rather see the printers NIS map Obsoleted +1 Anyway, not this case. +1 !!! -John
iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009]
On Thu, 2009-09-17 at 03:54 -0700, Fuyuki Hasegawa wrote: I'm submitting this fast-track for myself (IM group), scheduled to timeout at 09/24/2009. FYI, I requested more time on this case during today's PSARC meeting as it had yet to receive a +1 from an ARC member. I've posted some questions based on my review. Please extend the timer for another few days to accommodate for for the resolution of those issues (which are all relatively minor). -Seb
CUPS as the default print service
Garrett D'Amore wrote: Sebastien Roy wrote: Not this case seems appropriate to me. CUPS uses a perfectly modern desktop printer configuration tool that has a discovery feature that displays local printers (i.e. those that I'd actually want to print to) that use modern protocols. This is in contrast to NIS which has an incompatible notion of scope (NIS domain) that results in applications having access to potentially hundreds of printers I'd never want to print to. I'd rather see the printers NIS map Obsoleted rather than extended (and focus more on service discovery rather than directory-based solutions), but that's just my personal opinion. Anyway, not this case. [ I've removed the case number. Because it's *not* this case as already noted.] I think this question, directory vs. discovery, is a fairly important one. Certainly discovery based services are often easier for end-users, but the question is, what other discovery services do we use for things *besides* printers. Sites that administer all of their configuration in a directory (NIS or LDAP or whatever) probably want to keep doing that. Changing the administrative *paradigm* might be upsetting for some sites. That's an important point -- this used to work, and it's now not going to work, at least by default, and without much of an EOF. Getting back to Sebastien's point, I agree that the way NIS is managed inside Sun with gargantuan printer lists is really annoying and a user-hostile answer. That doesn't mean it has to be managed that way _everywhere_ or that you even have to put up with it. You can modify your /etc/nsswitch.conf if you want to opt out of the local lookup scheme, or even substitute your own priority order there. As for Nico's point about the accessor functions being private, I don't get it. The point I was making was about the high level issue of using the switch versus binding directly with the underlying libraries. The switch provides administrative control over which mechanism is used, and that's a good thing. If the impediment really is that getprinterby* is private, well, then for pity's sake, let's correct that nit. I'm not sure that having every application effectively growing its own embedded equivalent of a name service switch is really the right long term direction. Though it certainly seems to be the way some applications are going. -- James Carlson 42.703N 71.076W carlsonj at workingcode.com
CUPS as the default print service
On Wed, Sep 30, 2009 at 04:00:14PM -0400, James Carlson wrote: Garrett D'Amore wrote: I think this question, directory vs. discovery, is a fairly important one. Certainly discovery based services are often easier for end-users, but the question is, what other discovery services do we use for things *besides* printers. Sites that administer all of their configuration in a directory (NIS or LDAP or whatever) probably want to keep doing that. Changing the administrative *paradigm* might be upsetting for some sites. That's an important point -- this used to work, and it's now not going to work, at least by default, and without much of an EOF. Getting back to Sebastien's point, I agree that the way NIS is managed inside Sun with gargantuan printer lists is really annoying and a user-hostile answer. That doesn't mean it has to be managed that way _everywhere_ or that you even have to put up with it. You can modify your /etc/nsswitch.conf if you want to opt out of the local lookup scheme, or even substitute your own priority order there. Agreed. As for Nico's point about the accessor functions being private, I don't get it. The point I was making was about the high level issue of using the switch versus binding directly with the underlying libraries. The switch provides administrative control over which mechanism is used, and that's a good thing. If the impediment really is that getprinterby* is private, well, then for pity's sake, let's correct that nit. You wrote: Architecturally, though, ... Interface stability attributes and contracts are a crucial aspect of architecture. The relevant interfaces in this case are not Public, therefore CUPS would need a contract (or perhaps just to reside in ON). The relevant interfaces really should not be Public. We really need a public getprinterbyname(); the private implementations of it in lib/print _probably_ won't do. Which brings us to: it's not likely that we'll develop a public getprinterbyname() any time soon, which means that CUPS, if it uses the nsswitch at all, should do so via the same low-level interfaces used by lib/print. My reply was not intended as a nit, since it's clearly feasible to have a contract for CUPS to use the relevant interfaces. My reply was intended to be informational (since the i-team might well choose to get such a contract, and develop and send a patch upstream for using those interfaces). I'm not sure that having every application effectively growing its own embedded equivalent of a name service switch is really the right long term direction. Though it certainly seems to be the way some applications are going. I am sure that having every application effectively growing its own ... name service switch is NOT the right approach. I agree that several applications (e.g., automounter, lp, sendmail, I think, and maybe one or two others) access the nsswitch via private, low-level APIs, or implement a name service switch themselves outright. I agree that that is not a good thing. I agree that we should correct that, but I doubt that we will any time soon. Nico --
qlge - QLogic PCIe converged NIC driver [PSARC/2009/525 FastTrack timeout 10/07/2009]
I'm sponsoring this on behalf of Sukumar. It probably qualifies for automatic approval, but as this is the first converged NIC driver, I felt it better to give others a chance to respond. This case is seeking Patch binding. -- 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: qlge - QLogic PCIe converged NIC driver 1.2. Name of Document Author/Supplier: Author: Sukumar Swaminathan 1.3 Date of This Document: 30 September, 2009 4. Technical Description This qlge driver will support Qlogic PCIe Converged Network Adapter. The driver and adapter will support 10GB interface only. 10GBASE-SR and 10GBASE-CX4 PHY layers will be supported. Model numbers for initial Qlogic adapers are QLE8152, QLE8142 and QLE8140. Source code for this qlge driver will be coming from Qlogic. This driver will be open sourced in Nevada and will also go into s10u9. Patch binding is needed for s10u9 support. Driver will be integrated into ON Consolidation. This is a gldv3 based driver. This will support core gldv3 functions on both SPARC and x86 platforms. Brussels and LSO offload Features will be supported in Nevada only. HW checksum offload and Jumbo frames Features will be supported in both Nevada and S10. Driver source will be open. This case should be run as Open case. 6871527 FCoE, qlge driver - Add NIC side of support for new Qlogic FCoE adapter, Europa 6880020 qlge NIC driver from Qlogic need new man page qlge(7d) Sukumar. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
oce - Emulex PCIe converged NIC driver [PSARC/2009/526 FastTrack timeout 10/07/2009]
This is another case that maybe could be handled as a self-review, but because there is no precedent for converged devices yet, I felt it best to leave this a fast track. The case is seeking patch binding. 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: oce - Emulex PCIe converged NIC driver 1.2. Name of Document Author/Supplier: Author: Sukumar Swaminathan 1.3 Date of This Document: 30 September, 2009 4. Technical Description This oce driver will support Emulex PCIe Converged Network Adapter. The driver and adapter will support 10GB interface only. 10GBASE-SR and IEEE 802.3aq-2006 PHY layers will be supported. Model numbers for initial Emulex adapers are OCe10102-N and OCe10102-F. Source code for this oce driver will be coming from Emulex. This driver will be open sourced in Nevada and will also go into s10u9. Patch binding is needed for s10u9 support. Driver will be integrated into ON Consolidation. This is a gldv3 based driver. This will support core gldv3 functions on both SPARC and x86 platforms. Brussels and Quiesce Features will be supported in Nevada only. HW checksum offload, LSO offload, and Jumbo frames Features will be supported in both Nevada and S10. Driver source will be open. This case should be run as Open case. 6870995 FCoE, oce driver - Add NIC side of support for new Emulex FCoE adapter, Europa 6880011 oce NIC driver from Emulex need new man page oce(7d) 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
qlge - QLogic PCIe converged NIC driver [PSARC/2009/525 FastTrack timeout 10/07/2009]
Garrett D'Amore - sun microsystems gd78059 at sac.sfbay.sun.com writes: I'm sponsoring this on behalf of Sukumar. It probably qualifies for automatic approval, but as this is the first converged NIC driver, I felt it better to give others a chance to respond. While it's probably me being dense, if this is worthy of a fasttrack because it's a converged NIC driver, it seems worth defining what that actually means in the case materials. -- Rich
