Rich.Brown at sun.com wrote:
[snip]
== Introduction/Background ==
Zero-copy (copy avoidance) is essentially buffer sharing
among multiple modules that pass data between the modules.
This proposal avoids the data copy in the READ/WRITE path
of filesystems, by providing a mechanism to
Mahesh Siddheshwar wrote:
Roland Mainz wrote:
[snip]
How do you handle sparse files, e.g. files with one or more holes ?
Sparse files are not handled any differently in VOP_READ/VOP_WRITE calls
when using the zero-copy interface. Modules that want to seek/skip holes
can use
Garrett D'Amore wrote:
Bruce Rothermal wrote:
This package is needed for a $Supported code project we are working on
in HPC. Since we are already porting this for our project we are
directed to make the package available to all and also so it is
available via the IPS package server on
Don Cragun wrote:
On Fri, 21 Aug 2009 00:00:53 -0700, Hugh McIntyre wrote:
Joerg Schilling wrote:
int futimens(int fd, const struct timespec times[2]);
int utimensat(int fd, const char *path,
const struct timespec times[2], int flag);
In order
Garrett D'Amore wrote:
Don Cragun wrote:
On Fri, 21 Aug 2009 00:00:53 -0700, Hugh McIntyre wrote:
Joerg Schilling wrote:
int futimens(int fd, const struct timespec times[2]);
int utimensat(int fd, const char *path,
const struct timespec times[2], int flag);
John Fischer wrote:
PSARC,
I am sponsoring this project for Bruce Rothermal who will be integrating
this project via the SFW consolidation. I have set the timer for Friday,
August 28th. The case directory contains this proposal, FOSS check list,
and appropriate man pages.
This
Alan Coopersmith wrote:
Roland Mainz wrote:
... what's the general procedure to make a project private API
consolidation private ?
File an ARC fasttrack (or maybe even a self-review case if simple
enough) declaring the list of interfaces and their new stability
level.
Examples:
PSARC
Garrett D'Amore wrote:
Dave Plauger wrote:
Ivek Szczesniak wrote:
The stdio implementation in libc is among the slowest stdio
versions out there. If you want to archive better performance you
should use the stdio implementation in libast or use mmap(2).
This is an interesting
Garrett D'Amore wrote:
Roland Mainz wrote:
Garrett D'Amore wrote:
Dave Plauger wrote:
Ivek Szczesniak wrote:
The stdio implementation in libc is among the slowest stdio
versions out there. If you want to archive better performance you
should use the stdio implementation in libast
of Document Author/Supplier:
Author: Garrett D'Amore
1.3 Date of This Document:
10 August, 2009
4. Technical Description
I am sponsoring this fast track for Roland Mainz. The case times out in one
week (8/19/2009), and minor binding is requested.
[snip]
3. Interface table
Garrett D'Amore wrote:
Peter Cudhea wrote:
It would be useful to take a definitive stand on whether or not
operations on two adjacent bool values are atomic with respect to one
another. E.g. back in the days of the DEC Alpha, there existed no
instructions that could modify the value of
Garrett D'Amore wrote:
Roland Mainz wrote:
Alan Coopersmith wrote:
[snip]
What I still try to offer is the truce of letting us work in _peace_
on the idea of having one master DocBook/XML manual page file from which
both the normal manpages and the getopts strings are generated from
Roland Mainz wrote:
Garrett D'Amore wrote:
Roland Mainz wrote:
Alan Coopersmith wrote:
[snip]
What I still try to offer is the truce of letting us work in _peace_
on the idea of having one master DocBook/XML manual page file from which
both the normal manpages and the getopts
Garrett D'Amore wrote:
Roland Mainz wrote:
Garrett D'Amore wrote:
Alan Coopersmith wrote:
Garrett D'Amore wrote:
[snip]
There's yet another concern, which is that I've found that man command
and command --man do not generate the same document. So we know
introduce a problem were
Garrett D'Amore wrote:
Alan Coopersmith wrote:
Garrett D'Amore wrote:
1) The commands increase the size of the text segment. Not only does
it add new parsing requirements (you have to at least have enough code
to handle --man, for example), but you also have the text of the man
pages
John Sonnenschein wrote:
On 25-Jul-09, at 4:59 PM, James Carlson wrote:
John Sonnenschein wrote:
I've got a question about this...
Whose responsibility is it to update the man pages and --man
command then? The people whose jobs it is to update man pages, or
the people whose jobs it is
:
Author: Roland Mainz
1.3 Date of This Document:
24 July, 2009
4. Technical Description
[snip]
My main concern here is the integration of manual page functionality
into the commands themselves. I see both benefits and costs. The
benefit is that the documentation is more
Garrett D'Amore wrote:
Alan Coopersmith wrote:
Garrett D'Amore wrote:
Personally, I think --man, --html and --nroff and such is a dangerous
precedent to set. I'd rather not have them, and instead rely on the
man command to provide this functionality.
Isn't it a bit late to raise such
Nicolas Williams wrote:
On Mon, Jun 15, 2009 at 01:40:21PM -0700, Rich Burridge wrote:
Between 6.7 and 7.4, the following new commands were introduced:
Erm... where can I find the full ARC case ? Somehow I never got the
email for this... ;-(
/usr/gnu/bin/
Casper.Dik at sun.com wrote:
On Tue, Jun 16, 2009 at 09:55:30AM +0200, Casper.Dik at Sun.COM wrote:
/usr/bin already has an mktemp. How does it differ from the GNU
version? Ah, there's an option conflict, sadly (-u is --dry-run in
GNU, but unsafe operation in Solaris).
Solaris'
Glenn Fowler wrote:
On Tue, 16 Jun 2009 20:24:39 +0200 Roland Mainz wrote:
Casper.Dik at sun.com wrote:
On Tue, Jun 16, 2009 at 09:55:30AM +0200, Casper.Dik at Sun.COM wrote:
/usr/bin already has an mktemp. How does it differ from the GNU
version? Ah, there's an option conflict
Nicolas Williams wrote:
On Thu, Jun 04, 2009 at 01:36:14PM -0700, Apostolos Syropoulos wrote:
Indeed, I agree. But in my opinion there is no need for a UK at euro locale.
For example, if country X has trade relations with India then should we
introduce a locale for this country with support
Casper.Dik at sun.com wrote:
I think it would be helpful to see a few worked examples that show how
system_noshell() and its variants make things simpler than using
posix_spawn().
Date: Fri, 29 May 2009 10:41:30 -0700
From: Sumanth Naropanth Sumanth.Naropanth at sun.com
John.Zolnowsky at sun.com wrote:
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:
system_noshell
1.2. Name of Document Author/Supplier:
Author: Sumanth
Rich Burridge wrote:
I'm sponsoring the following fast track for John Sonnenschein.
The requested release binding is Minor. The fast track times out
on 06/02/2009.
1. Introduction
1.1. Project/Component Working Name:
PSARC/2009/315 Update Perl to version
Don Cragun wrote:
Casper Dik wrote:
... ... ...
Recent publications of the Open Group Technical Standards,
including
[IEEE P1003.1 Draft 5.1, 15 May 2008] has confirmed that this
interface
shall be named 'faccessat' and shall have the following prototype:
Alan Coopersmith wrote:
I am sponsoring this fasttrack for the X engineering team and have set
the timeout to one week from today, Thursday, May 14.
Since the interfaces being removed have been reviewed and imported in
cases reviewed both at PSARC LSARC, both ARC's are cc'ed, though the
Joerg Schilling wrote:
Roland Mainz roland.mainz at nrubsig.org wrote:
Is it possible to make this interface Uncommited until the IEEE
P1003.1 Draft has been made an official standard (e.g. what would you do
if somehow the Draft changes the prototype or functionality in a subtle
way - add
James Carlson wrote:
Glenn Fowler writes:
[snip]
a bonus is that ksh93 uses optget() to implement getopts
so shell scripts are not second class citizens w.r.t. long options
and since the options desc ription is one 0-terminated string
instead of a C-data-struct the description can be
hi!
I'd like to request to open the following ARC cases for publish access:
PSARC 1993/685 PowerPC_ABI
PSARC 1994/188 Solaris Kernel for PowerPC
PSARC 1994/196 PowerPC Header Files
PSARC 1994/197 PowerPC Commands
PSARC 1994/302 PowerPC_Booting
PSARC 1995/077 processor_info(2) binding for
Garrett D'Amore wrote:
Roland Mainz wrote:
Garrett D'Amore wrote:
I've posted a draft opinion filename opinion-draft.txt (and also .ms)
in the case directory for review. Its attached to this message as
well. Thanks.
[snip]
3. Interfaces
The project exports the following
Garrett D'Amore wrote:
I've posted a draft opinion filename opinion-draft.txt (and also .ms)
in the case directory for review. Its attached to this message as
well. Thanks.
[snip]
3. Interfaces
The project exports the following interfaces.
James Carlson wrote:
Garrett D'Amore - sun microsystems writes:
I'm sponsoring this fast-track request on behalf of Roland Mainz and the
ksh93-integration project. It consists of more commands being converted
to use internal ksh93 builtins.
Not an ARC issue, but please do make sure
I. Szczesniak wrote:
As the case is specified it gets my +1 but I still have some minor questions:
On 4/21/09, Garrett D'Amore - sun microsystems
gd78059 at sac.sfbay.sun.com wrote:
I'm sponsoring this fast-track request on behalf of Roland Mainz and the
ksh93-integration project
Don Cragun wrote:
From: Garrett D'Amore gdamore at sun.com
I. Szczesniak wrote:
... ... ...
Could you elaborate the difference between Committed and Committed
Obsolete?
Committed Obsolete means we can't remove it, but you're still
discouraged from using it in new code. That's
Nicolas Williams wrote:
On Wed, Apr 22, 2009 at 11:16:09AM -0700, Don Cragun wrote:
The standard does not currently specify a way to count (multi-byte)
characters even though this means tail output may start or end in the
middle of a multi-byte character when using the -c option.
How...
Artem Kachitchkine wrote:
We seem to be doing a good job coming up with names that we definitely
shouldn't use :-) I still hope Rishi can put forth a new name for these
handy objects. (Naming is hard -- but important.)
We just need to break out of the confines of the English language.
Roger A. Faulkner wrote:
I am sponsoring this automatic case for myself.
1. Introduction
This case adds a new posix_spawn() support function to the C library:
int posix_spawn_file_actions_addclosefrom_np(
posix_spawn_file_actions_t *file_actions,
int
James Carlson wrote:
Casper Dik writes:
char *stpcpy(char *restrict s1, const char *restrict s2);
char *stpncpy(char *restrict s1, const char *restrict s2, size_t n);
wchar_t *wcpcpy(wchar_t restrict *ws1, const wchar_t *restrict ws2);
wchar_t *wcpncpy(wchar_t restrict *ws1,
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
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
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
Casper.Dik at Sun.COM wrote:
It's fine to make use of the ksh builtin support for various
commands, but
can we please learn from the problems that occurred when we
changed sleep
to be a builtin recently (e.g. 6793120) and instead create trivial
wrapper
*programs* that
Scott Rotondo wrote:
John Plocher wrote:
Peter Tribble wrote:
I know that I'm certainly not happy about ripping out Solaris commands and
replacing them with external commands.
Since Sun's management seems to have RIF'd the entire team that used
to maintain those old Solaris commands,
James Carlson wrote:
Roland Mainz writes:
2. Restricted shell scripts (e.g. rsh, rksh, pfrksh [2] etc.) need
a way to output data (e.g. counterpart to read) and therefore print
was never bound to a PATH element since the korn shell exists. Otherwise
you have shell scripts which can't
James Carlson wrote:
Alan Hargreaves writes:
Unlike other built-in commands named in PSARC/2006/550, the print
built-in in ksh93 will _not_ be bound to the /usr/bin/ pathname to
ensure backwards-compatiblity to existing ksh93 scripts (for example
scripts running in restricted shell mode
Peter Tribble wrote:
On Mon, Feb 2, 2009 at 1:28 AM, Alan Hargreaves
ah89892 at sac.sfbay.sun.com wrote:
I'm sponsoring this fast-track request on behalf of the
ksh93-integration project.
Please note that this is an *open* case.
Template Version: @(#)sac_nextcase %I% %G% SMI
This
Peter Memishian wrote:
It's fine to make use of the ksh builtin support for various commands, but
can we please learn from the problems that occurred when we changed sleep
to be a builtin recently (e.g. 6793120) and instead create trivial wrapper
*programs* that access the builtin
Dale Ghent wrote:
On Feb 4, 2009, at 12:32 AM, Peter Memishian wrote:
It's fine to make use of the ksh builtin support for various
commands, but
can we please learn from the problems that occurred when we
changed sleep
to be a builtin recently (e.g. 6793120) and instead create trivial
Peter Memishian wrote:
It's fine to make use of the ksh builtin support for various
commands, but
can we please learn from the problems that occurred when we
changed sleep
to be a builtin recently (e.g. 6793120) and instead create trivial
wrapper
*programs* that access
Peter Memishian wrote:
It's fine to make use of the ksh builtin support for various commands,
but
can we please learn from the problems that occurred when we changed sleep
to be a builtin recently (e.g. 6793120) and instead create trivial
wrapper
*programs* that access the
Peter Memishian wrote:
So there is a unique pid for each program and thus it can still be
pkill'd?
If you start the command as seperate child job (e.g. $ sleep 12345 #)
it will always have a seperate pid. But that was not the problem which
caused CR #6793120 - the process name
Garrett D'Amore - sun microsystems wrote:
[snip]
PROPOSAL
Add inlines for i386/amd64 and sparcv9 for the following types of prefetch:
void prefetch_read_many(void *)
This requests data be loaded into a cache for repeated reading. (This
equates to a 't0' prefetch on x86 CPUs).
void
Alan Coopersmith wrote:
[snip]
What shell is used for these scripts? If it's /bin/sh, have you verified
they
work with both classic Solaris /bin/sh and ksh93 (which OpenSolaris uses as
/bin/sh)?
Actually it would help a lot if projects would test their scripts
against
Steve Nash wrote:
Alan Coopersmith wrote:
[snip]
* changes the default $PATH and $LD_LIBRARY_PATH for all users
How does it change the default $PATH?
How does it set $LD_LIBRARY_PATH without breaking other software?
We modify the /etc/{bashrc,csh.cshrc} to change the default
James Carlson wrote:
I am sponsoring this fast-track request for Vasumathi Sundaram. The
timer is set to 01/02/2009 in light of the coming holidays. Please
speak up if you need more time than that.
In an offline discussion, the project team went to lengths to find any
sendfilev users,
George Vasick wrote:
Danek Duvall wrote:
On Thu, Dec 18, 2008 at 10:35:36AM +1000, James C. McPherson wrote:
You seem to be conflicting with
6674032 Introduce GCC 4.3.x in Nevada
6674042 Introduce MPFR (Multiple Precision Floating-Point Rounding
Library) in Nevada
6674044
George Vasick wrote:
Rainer Orth wrote:
Raj Prakash Raj.Prakash at sun.com writes:
[snip]
2. Project Summary
2.1. Project Description:
The project will provide the current releases of the GNU Compiler
Collection (GCC) and the GNU Binutils for OpenSolaris. The primary
Roger A. Faulkner wrote:
I am sponsoring this automatic case for myself.
1. Introduction
This case adds two new functions to the C library, asprintf()
and vasprintf() as follows:
int asprintf(char **ret, const char *format, ...);
int vasprintf(char **ret, const
Nicolas Williams wrote:
On Fri, Dec 19, 2008 at 11:39:01AM -0800, George Vasick wrote:
We consulted the submitter, Craig Mohrman. The case is stalled in Sun
legal. Craig agrees with the concept in our proposal of using
/usr/compilers/... for this and future versions of compilers allowing
Nicolas Williams wrote:
On Fri, Dec 19, 2008 at 09:14:37PM +0100, Roland Mainz wrote:
Will this even work if another library is used for |malloc()||free()|
calls (IMO it should work but I am not sure about the case when an
application is linked via -B direct) ?
Yes, it will: malloc
Garrett D'Amore wrote:
-- Garrett
Don Cragun wrote:
I am sponsoring this case for Roland Mainz (an OpenSolaris contributor)
and April Chin (acting as sponsor for this work).
I believe it qualifies for closed approved automatic status. If a
PSARC member disagrees, let me
Yong Young Sun wrote:
[snip]
2. Project Summary
2.1. Project Description:
Add the following South East Asia locales support to current
OpenSolaris.
Malaysian: ms_MY.UTF-8
Indonesian: id_ID.UTF-8
Vietnamese: vi_VN.UTF-8
Are there any plans to
Yong Sun wrote:
This project is targeting to Indiana 2008.11 release, UTF-8 locales have
higher priority than legacy locales,
Right (except stuff like zh_CN.GB18030 which still should be preferred
over the UTF-8 variant since the matching goverment requires it (and is
very picky about it)) ...
Darren J Moffat wrote:
Roland Mainz wrote:
- There is one well-known[1] port of Solaris which runs on 64bit only
hardware - the problem with under review is that the work is _not_
[1]=The name is not public... yet.
So well known that I don't know what it is and its name isn't public
James Carlson wrote:
[sorry, this one was stuckforgotten in my Drafts/-folder]
Garrett D'Amore writes:
Have the upstream providers given thought to dealing with changes like
this and their impact on already-deployed scripts? (Maybe there aren't
any that we care about yet, since our ksh93
Garrett D'Amore wrote:
Nicolas Williams wrote:
On Thu, Jun 12, 2008 at 08:34:33PM -0700, Garrett D'Amore wrote:
[snip]
The question isn't about discouraging scripting, but rather, how far do
we want to go to enable people to use a shell script to perform
something that they really probably
Alan Coopersmith wrote:
I'm sponsoring this fast-track request on behalf of the
ksh93-integration project.
Please note that this is an *open* case.
[snip]
As discussed in today's ARC phone call...
... attached is the updated text for onepager.txt and
manpage.diff.txt and the diff from the
of Document Author/Supplier:
Author: Roland Mainz
1.3 Date of This Document:
30 May, 2008
4. Technical Description
gisburn: Does it require an ARC case if we switch the GNU coreutils
from 32bit to 64bit on SPARC only (no changes in interfaces
Joseph Kowalski wrote:
John Plocher wrote:
Joseph Kowalski wrote:
Sorry, I want a fast-track.
What are the architectural (as opposed to C-Team, Design or RE)
issues?
1) I believe this is an incomplete project.
This sounds to me like go boil the ocean scope creep.
Sometimes
James Carlson wrote:
Joseph Kowalski writes:
John Plocher wrote:
Joseph Kowalski wrote:
Sorry, I want a fast-track.
What are the architectural (as opposed to C-Team, Design or RE) issues?
1) I believe this is an incomplete project.
This sounds to me like go boil the
Alan Coopersmith wrote:
Joseph Kowalski wrote:
I don't see why /usr/gnu/bin/awk should get preference over /usr/bin/awk
just because its in gnucore.
How about because it's already known to be 64-bit clean since the GNU
utilities run on platforms that are 64-bit only, while the Solaris
Garrett D'Amore wrote:
John Plocher wrote:
I think it is time for an updated spec/issue roll up.
Here is where I think things stand - please correct any
misunderstandings:
[snip]
2) Relationship of t-, t, t+ versioning scheme and C-Team
integration rules.
Commentary:
Garrett D'Amore wrote:
This case was approved yesterday.
Erm... did you check whether this driver may be needed by software
emulators ? For example the only sound driver which AFAIK works in Bochs
with Solaris as guest is sbpro (see
Garrett D'Amore wrote:
Roland Mainz wrote:
Garrett D'Amore wrote:
This case was approved yesterday.
Erm... did you check whether this driver may be needed by software
emulators ? For example the only sound driver which AFAIK works in Bochs
with Solaris as guest is sbpro (see
http
Joseph Kowalski wrote:
Garrett D'Amore wrote:
I've seen mail from David Korn (not CC'd to PSARC, unfortunately)
which I think cleared this up unambiguously. Check the no box, and
lets move forward. :-)
Can we forward this to PSARC (actually the case, so it is captured)?
Then we can
Glenn Skinner wrote:
Glenn Skinner wrote:
Glenn Skinner wrote:
[snip
If the project team wishes to retain the existing stability
classification, that's their prerogative; they'll have chosen to
assume the risk of violating the stability classification's guarantees
(and presumably will
Garrett D'Amore wrote:
Roland Mainz wrote:
Joseph Kowalski wrote:
Garrett D'Amore wrote:
[snip]
Erm... I'm just answering the ARC emails out of sync and I'm simply not
fast enought to answer all emails ASAP (around seven emails are already
in the drafts folder but I'm a slow email
Alan Coopersmith wrote:
Roland Mainz wrote:
Alan Coopersmith wrote:
Garrett D'Amore wrote:
Are you using (populating) anything in /usr/shell as part of this case?
If not, you might consider running that as a separate fast track.
Without that portion, this case is pretty much
Alan Coopersmith wrote:
Garrett D'Amore wrote:
It may be helpful for persons observing this, as well as the project
team, to understand that Solaris integrations always need to conform to
a release ready rule. That is, we don't integrate software that
aren't comfortable including in a
Glenn Skinner wrote:
[snip]
## Part 1.1: Update of ksh93
The 1.1 portion of this project is the update of ksh93 from
ast-ksh.2007-12-15 to ast-ksh-2008-05-22 which marks the update
from ksh93 version 's+' to version 't-' (AST/ksh93 uses the
(latin) alphabet for its version number, e.g.
John Plocher wrote:
I. Szczesniak wrote:
It was always good practice to avoid C language keywords in shell
scripts. Quoting the Opensolaris programming style guide:
Do not use function names which are reserved keywords (or function
names) in C/C++/JAVA or the POSIX shell standard (to
Joerg Schilling wrote:
Roland Mainz roland.mainz at nrubsig.org wrote:
ksh93 scripts written for one platform can run on Solaris, too (and
ksh93 scripts written for Solaris may be able to run on other platforms
like Linux or Win32/SFU/Cygwin, too). In a similar manner we want to
Knowing
Joseph Kowalski wrote:
Garrett D'Amore wrote:
Are you using (populating) anything in /usr/shell as part of this case?
I think you mean /usr/lib/shell.
/usr/lib/shell/ is the correct location since we expect that
ISA-specific modules show-up there...
Bye,
Roland
--
__ . . __
(o.\
Darren J Moffat wrote:
Alan Coopersmith wrote:
### Part 2: Project-private location for shell function library
/usr/lib/shell/ is reserved as project private location, mainly to
build a (platform/architecture-specific) library of dynamically
loadable shell functions in a similar form as
Joseph Kowalski wrote:
Roland Mainz wrote:
The java packages are in /usr/share/lib/ and /usr/share/lib/java/
I doubt the JAVA packages there have any ISA-specific code inside.
First, package is a reserved word in the Java Language. Need to be
careful here
A wad which exports
Glenn Skinner wrote:
Glenn Skinner wrote:
Date: Tue, 27 May 2008 16:19:44 -0700 (PDT)
From: Alan Coopersmith Alan.Coopersmith at sun.com
Subject: ksh93 Integration Update 1 Amendments 1 [PSARC/2008/344
FastTrack timeout 06/03/2008]
...
Joseph Kowalski wrote:
Glenn Skinner wrote:
[snip]
## Part 1.1: Update of ksh93
The 1.1 portion of this project is the update of ksh93 from
ast-ksh.2007-12-15 to ast-ksh-2008-05-22 which marks the update
from ksh93 version 's+' to version 't-' (AST/ksh93 uses the
Nicolas Williams wrote:
On Wed, May 28, 2008 at 09:33:10PM +0200, Roland Mainz wrote:
Huh? This share is supposed to be shared? If that was the case is should
be /usr/gnu/... and /usr/share/gnu/...
Well... it's still better having the GNU stuff seperate... we're still
suffering from
Joseph Kowalski wrote:
Garrett D'Amore wrote:
Frankly, the effort to create a new case (fast track or otherwise) is
so small, that I'd just spin off the /usr/lib/shell part into a
separate fast track. If you would like a sponsor for it, write up a
quick draft -- you can probably just
Garrett D'Amore wrote:
Joseph Kowalski wrote:
Garrett D'Amore wrote:
[snip]
I've not heard from any other ARC members that they feel strongly
about this. That doesn't mean they don't; we often just let the
poster of the initial request continue to discuss.
However, this is starting
Garrett D'Amore wrote:
Joseph Kowalski wrote:
Is this one of those FOSS cases we are supposed to not get too deep into
polishing the edges?
I don't think so. ksh93 is more intrinsically becoming a core
component, that we build our system upon. It has a non-External
commitment.
Joseph Kowalski wrote:
Roland Mainz wrote:
If not, you might consider running that as a separate fast track.
Why ? The directory is explcitly marked as project private for now.
AFAIK we don't have to notify ARC about further activities there until
we start making ARC contracts or open
Magne M?hre wrote:
Template Version: @(#)onepager.txt 1.31 07/08/08 SMI
This information is Copyright 2007 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Integrate PROJ4
[snip]
4. Technical Description:
4.1. Details:
PROJ is a
Nicolas Williams wrote:
On Fri, Apr 11, 2008 at 10:38:23AM +0200, Joerg Schilling wrote:
Garrett D'Amore gdamore at sun.com wrote:
[snip]
Cleanly written scripts (e.g. autoconf) do not depend on the non-portable
extensions.
But the world isn't perfect, and including GNU sed doesn't cost
Joerg Schilling wrote:
Garrett D'Amore gdamore at sun.com wrote:
Sorry, I just saw the answers to question #1 in section 4.2. (I.e. no.)
The ON sed sources are still non-free, so it we need to think about a free
replacement.
That's already on my ToDo list...
Bye,
Roland
--
__
Alan Coopersmith wrote:
Eric Sultan wrote:
I'm sponsoring this case for Charmaine Lee. This project delivers an
xorg,conf file required to support Sun SPARC graphics devices.
[snip]
I'm on vacation this week, so not following all my e-mail closely, but
I don't see any justification for why
Roland Mainz wrote:
Alan Coopersmith wrote:
Eric Sultan wrote:
I'm sponsoring this case for Charmaine Lee. This project delivers an
xorg,conf file required to support Sun SPARC graphics devices.
[snip]
I'm on vacation this week, so not following all my e-mail closely, but
I don't see
Eunice Moon wrote:
Roland Mainz wrote:
Dan Hain wrote:
I am sponsoring the following case on behalf of Eunice Moon
as a fast-track with timeout set to 04/14/2008.
The project requests minor binding.
Libvirt for LDoms (Logical Domains) support
Michael Corcoran wrote:
On Mon, 2008-03-31 at 13:37 +0200, Roland Mainz wrote:
Rod Evans wrote:
I'm sponsoring the following case for Mike Corcoran. Time out 04/07/08.
The case introduces a new system call, mmapfd(2). This call is primarily
targeted for use by ld.so.1(1
1 - 100 of 224 matches
Mail list logo
