Christof Pintaske writes:
A user can add to the repository by submitting the document to the
opensolaris documentation community and notifying us. The number of
submissions in that community is so low that I don't see that any
further automation is justified (so far we haven't seen any
I'm filing this on my own behalf. While the proposal is for EOF of a
closed source bit (sdtaudiocontrol), I think its fair for the
discussion to be in the open, so the case is left open. The timeout
is set for Feb 16, 2009. Thanks.
Template Version: @(#)sac_nextcase %I% %G% SMI
This
Garrett,
This project appears to be deprecating the sdtaudiocontrol
application in a Patch release of Solaris and removing it in
a Minor release of Solaris. Correct? If so then the interface
is Obsolete Uncommitted. What about the SADA mixer framework?
Are you doing the same for it as well?
James Carlson wrote:
George Vasick writes:
Thanks for your many comments and helpful feedback. Attached, please
find a revised proposal. It contains major changes to the previous
proposal as follows:
This looks pretty nice except for one bit that seems a little
unfortunate:
John Fischer wrote:
Garrett,
This project appears to be deprecating the sdtaudiocontrol
application in a Patch release of Solaris and removing it in
a Minor release of Solaris. Correct? If so then the interface
is Obsolete Uncommitted. What about the SADA mixer framework?
Are you doing
I. Szczesniak wrote:
On 2/4/09, Roland Mainz roland.mainz at nrubsig.org wrote:
2. The next ARC case may contain a few more non-filesystem utilties
(e.g. join, head, tail, tee, mkfifo) from libcmd and (as a
seperare ARC case) cover the remaining closed-source commands defined by
POSIX
+1
On Mon, 2009-02-09 at 08:46, Garrett D'Amore wrote:
John Fischer wrote:
Garrett,
This project appears to be deprecating the sdtaudiocontrol
application in a Patch release of Solaris and removing it in
a Minor release of Solaris. Correct? If so then the interface
is Obsolete
...I've asked around
whether it is possible to deliver the contents of one ARC case with
multiple putbacks but the answers were a bit fuzzy
Speaking not as an ARC member, but rather as a CRT Advocate and former
Tech Lead:
Standard expectation is that a single ARC case will be integrated as
Mark J. Nelson wrote:
...I've asked around
whether it is possible to deliver the contents of one ARC case with
multiple putbacks but the answers were a bit fuzzy
Speaking not as an ARC member, but rather as a CRT Advocate and former
Tech Lead:
Standard expectation is that a single ARC
Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
antlr runtime
1.2. Name of Document Author/Supplier:
Author: Vivek Titarmare
1.3 Date of This Document:
Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Unified ps(1)
1.2. Name of Document Author/Supplier:
Author: Casper Dik
1.3 Date of This Document:
09
First off, I really like what this case is trying to do. But I do have
a possible concern: /usr/ucb/ps could have been used with a leading
-. E.g. /usr/ucb/ps -aux and /usr/ucb/ps aux both return the same thing.
I'd humbly suggest that if getexecname returns /usr/ucb/ps then the
legacy UCB
Garrett D'Amore writes:
First off, I really like what this case is trying to do. But I do have
a possible concern: /usr/ucb/ps could have been used with a leading
-. E.g. /usr/ucb/ps -aux and /usr/ucb/ps aux both return the same thing.
I'd humbly suggest that if getexecname returns
Vivek,
The FOSS check list states that there are libraries being delivered
with this project. However, the libraries are not included in the
Exported Interface tables. Is this information incorrect in the
FOSS check list or is there missing information within the interface
table?
Thanks,
John
I am sponsoring this fast-track for Vivek Titarmare. The
timeout is set at Feb 18. The case directory contains the supplied
materials.
This fast-track is a portion of the Drools case LSARC 2008/748, which
is a dependency of ADM - PSARC 2007/210.
Template Version: @(#)sac_nextcase %I% %G% SMI
I am sponsoring this fast-track for Vivek Titarmare. The
timeout is set at Feb 18. The case directory contains the supplied
materials.
This fast-track is a portion of the Drools case LSARC 2008/748, which
is a dependency of ADM - PSARC 2007/210.
Template Version: @(#)sac_nextcase %I% %G% SMI
I am sponsoring this fast-track for Vivek Titarmare. The
timeout is set at Feb 18. The case directory contains the supplied
materials.
This fast-track is a portion of the Drools case LSARC 2008/748, which
is a dependency of ADM - PSARC 2007/210.
Template Version: @(#)sac_nextcase %I% %G% SMI
This case, having resolved all outstanding issues, is being marked
closed approved.
-- mark
This case, having received the requisite +1, is being marked closed
approved.
-- mark
This case, having resolved all outstanding issues, is being marked
closed approved.
-- mark
This case, having received the requisite +1, is being marked closed
approved.
-- mark
All,
The discussion having converged and the timeout being reached I
am closing this case as approved.
Thanks,
John
First off, I really like what this case is trying to do. But I do have
a possible concern: /usr/ucb/ps could have been used with a leading
-. E.g. /usr/ucb/ps -aux and /usr/ucb/ps aux both return the same thing.
I'd humbly suggest that if getexecname returns /usr/ucb/ps then the
legacy
Hmm... maybe I didn't understand. As long as /usr/ucb/ps behaves as
/usr/ucb/ps whenever any valid syntax that was accepted by it today is
given, then I'm ok with it. (And understanding that - is a valid part
of the syntax. :-)
Indeed. And yes, ps -xuag works as you expect when you
Garrett D'Amore wrote:
That said, I do sort of think that the rule you have, while workable, is
more confusing and violates the principle of least surprise.(I.e.
you added a switch by accident which suddenly changed the meaning of
other options in a totally unexpected fashion.)
This
Scott Rotondo wrote:
Garrett D'Amore wrote:
That said, I do sort of think that the rule you have, while workable,
is more confusing and violates the principle of least surprise.
(I.e. you added a switch by accident which suddenly changed the
meaning of other options in a totally
Scott Rotondo writes:
Garrett D'Amore wrote:
That said, I do sort of think that the rule you have, while workable, is
more confusing and violates the principle of least surprise.(I.e.
you added a switch by accident which suddenly changed the meaning of
other options in a totally
Depending on the presence of - isn't novel. Other OSes have done
this before. Inspecting the options in a presumed-BSD-ish list and
reverting to SVR4 behavior if an unexpected option is seen _is_ new,
and it's what caused both Garrett and me to say something.
I understand. Clearly, I wanted
Rick,
Can you take a little more time putting these
fasttracks together? There are a lot of people
on this alias.
Section 2.1 and 4 are dups. Pick one. Don't repeat.
It may be better to just send out the FOSS checklist.
What about man pages?
Cheers,
Jim
Richard Jr Matthews wrote:
2.
Ceri Davies writes:
On Mon, Feb 09, 2009 at 10:36:35PM +0100, Casper.Dik at sun.com wrote:
This kind of precludes adding any new options to /usr/ucb/ps, ever. I
don't believe that this is a particularly bad thing, just want to be
crystal clear that this is what we want to do.
As
+1 to the change along with Garrett's suggestion, which I understand
to be in priority order:
/usr/ucb/ps - only BSD flags, regardless of -
- present - only USL flags
no - - only BSD flags
+1 I can then stop having to remember which ps path I have to type
Gary..
+1.
-- Garrett
Alan Coopersmith wrote:
I am sponsoring this case on behalf of the recently combined X server
and SPARC graphics teams. It has been split out from the larger
PSARC 2009/072 case into this separate fasttrack.
The timeout is set for Tuesday, Feb. 17, due to the US
(While at this point there is nothing fundamentally different between
a rights profile as assigned to users and a policy profile as
specified as argument here they are conceptually different: the first
assigns all rights and auths it contains, while the latter is used to
check for
Actually, this case does raise one question (which doesn't impact my +1
below) -- we've already shipped some OpenSolaris releases.
It isn't clear to me what the EOF rules would be for things that shipped
in OpenSolaris releases should be ... although I don't think this
particular driver has
This driver is SPARC only. The only OpenSolaris release shipped for SPARC
is a early developer preview that shipped last week - no supported version
of OpenSolaris has shipped on SPARC, and the version that shipped has no
X support for these graphics cards since they only have Xsun support and
I suspected as much. Thanks for the clarification.
I expect we'll want an answer to the question I've asked in the future,
but it isn't needed for this case.
-- Garrett
Alan Coopersmith wrote:
This driver is SPARC only. The only OpenSolaris release shipped for SPARC
is a early
This case is now approved.
The only change to the initial proposal is that the default value of the
eject_button SMF property for rmvolmgr will now be boolean true,
rather than false, as discussed earlier.
-Artem
The solaris.login authorizations are granted to all accounts via
Basic Solaris User, so the behaviour of the system remains the same
in default configurations.
Since we do not want customers modifying Sun delivered Rights
Profiles, IMO it would be better to add a new
This case has timed out and is thereby approved.
-jg
The timer on this fast-track has expired with no further
comment, so this case is now approved.
-jg
40 matches
Mail list logo
