On 5/21/2010 9:05 PM, Alan Coopersmith wrote:
At Garrett's request I've reset the status of the case to
"waiting fast-track 05/28/2010".
Thanks. The rationale here is that meaty substance has already been
discussed/reviewed before. What's different is that we won't be
delivering GNU pl
At Garrett's request I've reset the status of the case to
"waiting fast-track 05/28/2010".
--
-Alan Coopersmith-alan.coopersm...@oracle.com
Oracle Solaris Platform Engineering: X Window System
___
opensolaris-arc mailing list
o
On May 21, 2010, at 2:55 PM, Joerg Schilling wrote:
> Don Cragun wrote:
>
>> http://www.opengroup.org/csq/view.mhtml?norationale=1&noreferences=1&RID=sun%2FSD1%2F7
>> specifies that the minimum value of LOGIN_NAME_MAX is 9 and the
>> maximum value of LOGIN_NAME_MAX is 9. So, making the changes
Don Cragun wrote:
> http://www.opengroup.org/csq/view.mhtml?norationale=1&noreferences=1&RID=sun%2FSD1%2F7
> specifies that the minimum value of LOGIN_NAME_MAX is 9 and the
> maximum value of LOGIN_NAME_MAX is 9. So, making the changes proposed
> in this case require one of the following:
> 1.
On May 21, 2010, at 16:30:01 +0100, darr...@opensolaris.org wrote:
> On 21/05/2010 16:19, James Carlson wrote:
>> The second is the standards group branding issue. The value 9 is baked
>> into the UNIX98 and UNIX03 reference materials, so changing it (at least
>> inside those conforming environme
In the original case, ibd.conf was classified as 'volatile' for Nevada (because
it's expected to be replaced by switching to Brussels).
That classification isn't appropriate for S10 if you intend to keep ibd.conf as
the only configuration interface (which I assume is the case).
So it's classif
Ok, so I would like to formally request that this case be restarted as a
regular EOF of the associated graph and spline utilities. If it is
approved, then I'll also deliver the GNU plotutils to /contrib, at the
time that I submit a request to remove the ancient portions from ON.
(I'll be goin
> From alan.coopersm...@oracle.com Fri May 21 10:57:07 2010
> Date: Fri, 21 May 2010 10:57:05 -0700
> From: Alan Coopersmith
> Subject: Re: Username length [PSARC/2010/184 FastTrack timeout
> 5/27/2010]
> To: James Carlson
> Cc: Nicolas Williams , psarc-...@sun.com,
> Don Cragun
In Nevada (snv_139), it was already replaced by Brussels.
But you are right, the team doesn't intend to backport the
Brussels stuff. So the .conf file becomes "committed" for S10.
-ted
James Gates wrote:
In the original case, ibd.conf was classified as 'volatile' for Nevada
(because it's expec
James Carlson wrote:
> Just for the sake of sanity, I'd like to see a rule limiting
> system-supplied names to 8 characters, at least for a while.
In the best Postelian tradition of "Be liberal in what you accept, and
conservative in what you send." and in the spirit of the many other
"not this ca
+1 even though not needed.
-- mark
On May 20, 2010, at 12:45 PM, John Forte wrote:
> I am sponsoring this closed approved automatic case for Janice Chang. It adds
> one SMF property to an already approved fasttrack (PSARC 2010/048). Binding
> is minor. PSARC 2010/048 was originally submitted
I am sponsoring this closed approved automatic case for Lukas Rovensky.
It Obsoletes Jakarta Tomcat 4 Interfaces In Solaris 10 and the release
binding is patch. If anyone thinks this doesn't qualify for self review,
then I'll convert it to a fasttrack.
Thanks,
-Suha
Template Version: @(#)onepag
On Fri, May 21, 2010 at 10:05:50AM -0700, Bart Smaalders wrote:
> On 20/05/2010 18:50, Roland Mainz wrote:
> > IMO this case should either allow the use of multibyte characters or
> > expcitly refer to bytes/ASCII characters (see below).
>
> Since there is no way of storing encoding information al
Folks,
Here is a minor amendment to an already approved case.
I am filing this as a "case note", but in case
anyone thinks this needs a real fasttrack, please
pipe up, and I will re-file it as such.
In PSARC/2009/593 IPoIB Connected Mode, the case said
S10 would default to Datagram Mode by not d
On 20/05/2010 18:50, Roland Mainz wrote:
> tools like Solaris's tools like "useradd" always restricted this to
> the ASCII character set while many sites allow (by using their own set
> of tools) non-ASCII usernames (e.g. German umlauts are commonly used
> on German university sites and some japan
On 05/21/10 09:19 AM, Garrett D'Amore wrote:
Does it make sense to use some special value (zero or -1) to mean
uninitialized? That way could at least preserve the type.
Or a missing property could mean uninitialized.
BTW, integer means you can have negative values. Counter are for only
posit
On Fri, May 21, 2010 at 05:07:54PM +0100, Darren J Moffat wrote:
> I don't see anywhere on limits.h(3HEAD) that says we won't change
> the value of LOGNAME_MAX it is the name that would be the Committed
> interface not the value of it.
>
> LOGNAME_MAX is listed in the "Other Invariant Values" sect
Darren J Moffat wrote:
> On 21/05/2010 16:58, joerg.schill...@fokus.fraunhofer.de wrote:
>>> LOGNAME_MAX is documented as a public committed interface in
>>> limits.h(3HEAD). How do you deal with that?
>>
>> LOGNAME_MAX is not part of the standard.
>>
>> As Solaris removed "utmp" and "wtmp" a long
Does it make sense to use some special value (zero or -1) to mean
uninitialized? That way could at least preserve the type.
-- Garrett
Felix Feng wrote:
>> I think this is a good change. But I'd like to see more sample values
>> for the valid values of these properties -- the type of astr
+1
-- Garrett
Darren J Moffat wrote:
>
>Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
>This information is Copyright (c) 2010, Oracle and/or its affiliates. All
>rights reserved.
>1. Introduction
>1.1. Project/Component Working Name:
>PKCS#11 URI parser for libcryptoutil
>
On 21/05/2010 16:58, joerg.schill...@fokus.fraunhofer.de wrote:
LOGNAME_MAX is documented as a public committed interface in
limits.h(3HEAD). How do you deal with that?
LOGNAME_MAX is not part of the standard.
As Solaris removed "utmp" and "wtmp" a long time ago, I would guess that
it can be
James Carlson wrote:
> Darren J Moffat wrote:
> > On 21/05/2010 16:19, James Carlson wrote:
> >> The second is the standards group branding issue. The value 9 is baked
> >> into the UNIX98 and UNIX03 reference materials, so changing it (at least
> >> inside those conforming environments) means e
On 21/05/2010 16:48, James Carlson wrote:
I'm certainly not saying "don't do it." In fact, I want to see it
happen. Nor am I trying to slow it down. I just want it done _right_.
Until such time as an ARC member derails it and asks for it to be voted
on it is being done right.
--
Darren J
Darren J Moffat wrote:
> On 21/05/2010 16:19, James Carlson wrote:
>> The second is the standards group branding issue. The value 9 is baked
>> into the UNIX98 and UNIX03 reference materials, so changing it (at least
>> inside those conforming environments) means either re-doing the branding
>> or
Just FYI:
I can confirm what Bill points out below. Solaris naming services does not
intentionally impose a limits on the length of username (or any other
variable
length strings like gecos etc.). NIS currently still has a 4k buffer
max, so
a NIS passwd entry total length has that upwards boun
Darren J Moffat wrote:
> On 21/05/2010 12:20, James Carlson wrote:
>> On 05/20/10 22:51, Don Cragun wrote:
>>> Since it is defined in the Solaris 10 limits.h(3HEAD) man page, a
>>> "Conforming POSIX Application Using Extensions" is free to use
>>> LOGNAME_MAX as defined in as long as it documents
On 21/05/2010 16:19, James Carlson wrote:
The second is the standards group branding issue. The value 9 is baked
into the UNIX98 and UNIX03 reference materials, so changing it (at least
inside those conforming environments) means either re-doing the branding
or ceasing to be "UNIX" in that sense
Darren J Moffat wrote:
> On 21/05/2010 12:15, James Carlson wrote:
>> On 05/21/10 04:18, Darren J Moffat wrote:
>>> On 20/05/2010 21:37, Don Cragun wrote:
I'm not disagreeing with the move to 32 bytes. I just believe that the
ARC needs to make it clear that doing so is a conscious decisi
> We need only one function for parsing the URI, all other helper
> functions are static. The function takes a string with the PKCS#11 URI
> and fills up a structure allocated by the caller.
>
> int pkcs11_parse_uri(const char *str, pkcs11_uri_t *uri);
> Interface Stability
> --
On 05/20/10 06:07 AM, sowmini.varad...@oracle.com wrote:
If all we want is to keep the origin clear, that can be done by simply
setting an address flag (IFF_FROM_GZ) on addresses added by ipmgmtd, and
using that to print output in show-addr. But we discussed some more complex
issues on the phone
On 05/19/10 10:51 AM, James Carlson wrote:
Moving forward we have a set of work in the area of networking
configuration that spans the range from how servers are typically
configured to the problems NWAM set out to solve. The reason to
structure things that way is exactly to avoid the problems y
On 21/05/2010 09:55, joerg.schill...@fokus.fraunhofer.de wrote:
I recommend to look into the Solaris sources and fix the parts that still
historically or by accident as in ./lib/libsec/common/acltext.c use a lower
limit.
Thanks Joerg, that was one I hadn't found yet in my testing since I
hadn'
On 21/05/2010 12:20, James Carlson wrote:
On 05/20/10 22:51, Don Cragun wrote:
Since it is defined in the Solaris 10 limits.h(3HEAD) man page, a
"Conforming POSIX Application Using Extensions" is free to use
LOGNAME_MAX as defined in as long as it documents that it
uses this macro (and __EXTENS
I think this is a good change. But I'd like to see more sample values
for the valid values of these properties -- the type of astring is a
bit .. hmm... non-specific. (And furthermore, perhaps some of the
values should actually take more specifically typed data, e.g. numbers
or booleans?
Hi
Frank Che wrote:
3. Modify existing /etc/default/kbd consumers, so that they operate on SMF
property instead of the file. The following consumer was found in ON gate
kbd(1) - usr/src/cmd/kbd/kbd.c
For this consumer, file /etc/default/kbd is only referred in this usage:
kbd -i [
On 05/20/10 16:57, Rainer Orth wrote:
Frank Che writes:
Exported Interfaces
===
NameCommitment Comments
---
keymap Committed keyboard configu
On 05/20/10 22:51, Don Cragun wrote:
> Since it is defined in the Solaris 10 limits.h(3HEAD) man page, a
> "Conforming POSIX Application Using Extensions" is free to use
> LOGNAME_MAX as defined in as long as it documents that it
> uses this macro (and __EXTENSIONS__ as defined on the standards(5)
On 21/05/2010 12:15, James Carlson wrote:
On 05/21/10 04:18, Darren J Moffat wrote:
On 20/05/2010 21:37, Don Cragun wrote:
I'm not disagreeing with the move to 32 bytes. I just believe that the
ARC needs to make it clear that doing so is a conscious decision to break
the ABIs and that it does
On 05/21/10 04:18, Darren J Moffat wrote:
> On 20/05/2010 21:37, Don Cragun wrote:
>> I'm not disagreeing with the move to 32 bytes. I just believe that the
>> ARC needs to make it clear that doing so is a conscious decision to break
>> the ABIs and that it does not set a precedent for other ABI b
Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is Copyright (c) 2010, Oracle and/or its affiliates. All
rights reserved.
1. Introduction
1.1. Project/Component Working Name:
PKCS#11 URI parser for libcryptoutil
1.2. Name of Document Author/Supplier:
On 21/05/2010 10:53, joerg.schill...@fokus.fraunhofer.de wrote:
Roland Mainz wrote:
I would give this case (if I could) a +1 with two minor changes:
1. "useradd" should clamp the string to 32bytes but _validate_ that
the input username doesn't get any multibyte characters cut-off in the
middle
Roland Mainz wrote:
> I would give this case (if I could) a +1 with two minor changes:
> 1. "useradd" should clamp the string to 32bytes but _validate_ that
> the input username doesn't get any multibyte characters cut-off in the
> middle.
As we are in the 21st century, we could even support lon
Darren J Moffat wrote:
> On 20/05/2010 21:37, Don Cragun wrote:
> > I'm not disagreeing with the move to 32 bytes. I just believe that the
> > ARC needs to make it clear that doing so is a conscious decision to break
> > the ABIs and that it does not set a precedent for other ABI breakage. If
>
Don Cragun wrote:
> According to the Solaris 10 limits.h(3HEAD) man page, LOGNAME_MAX is an
> invariant value defined in . It is described there as:
> "The maximum number of bytes supported in a user's login name."
>
> So it is perfectly legitimate for a Solaris 10 application to define
>
On 20/05/2010 18:50, Roland Mainz wrote:
Solaris currently documents a maximum username length of 8 characters
in passwd(4).
Erm... AFAIK this should be _bytes_, not characters. Characters would
be multibyte characters in this context with the small twist that
It is a effectively a 'char user
On 20/05/2010 22:06, I. Szczesniak wrote:
On Thu, May 20, 2010 at 9:18 PM, Don Cragun wrote:
The reason that LOGNAME_MAX was stuck at 8 in for so long
is that the System V ABIs and the SCDs require that value.
Solaris 10 has been breaking ABI requirements around the edges for a
few years. Si
On 20/05/2010 21:45, Nicolas Williams wrote:
On Thu, May 20, 2010 at 01:42:30PM -0700, Alan Coopersmith wrote:
Nicolas Williams wrote:
In any case, customers that require strict SysV ABI compliance (e.g.,
customers that have apps that use LOGNAME_MAX and/or L_cuserid and who
cannot or will not
On 20/05/2010 21:37, Don Cragun wrote:
I'm not disagreeing with the move to 32 bytes. I just believe that the
ARC needs to make it clear that doing so is a conscious decision to break
the ABIs and that it does not set a precedent for other ABI breakage. If
I remember correctly, an opinion needs
48 matches
Mail list logo
