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
message was scrubbed...
From: David Korn d...@research.att.com
Subject: Re: [ksh93-integration-discuss] 2008/344 [ksh93 Integration Update
1
Amendments 1]
Date: Thu, 29 May 2008 17:17:01 -0400
Size: 5333
URL:
http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080530
I don't think qemu, even if though there is an opensolaris.org hosted
project to ensure it runs on OpenSolaris, should hold up removal of this
driver.
Think about it this way, given all the OpenSolaris on metal and all the
other whole machine virtualisation solutions that are available how
Ben Taylor wrote:
On Fri, May 30, 2008 at 7:21 AM, Darren J Moffat Darren.Moffat at sun.com
wrote:
I don't think qemu, even if though there is an opensolaris.org hosted
project to ensure it runs on OpenSolaris, should hold up removal of this
driver.
Think about it this way, given all
Roland Mainz roland.mainz at nrubsig.org wrote:
Did you thing about the fact that ksh93 is _really_ big and that people who
like to use OpenSolaris in embedded environments probably cannot use ksh93
for
this reason?
Erm... the issue is the other way around - the use of builtin
Roland Mainz roland.mainz at nrubsig.org wrote:
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
On Fri, May 30, 2008 at 7:21 AM, Darren J Moffat Darren.Moffat at sun.com
wrote:
I don't think qemu, even if though there is an opensolaris.org hosted
project to ensure it runs on OpenSolaris, should hold up removal of this
driver.
Think about it this way, given all the OpenSolaris on metal
Joerg Schilling wrote:
You would need to prove this on an embedded system. I am not convinced at all.
Interesing discussion - But not as part of this case.
A future appliance/embedded OpenSolaris project is free (nay, almost
expected) to make its own choices as to which utilities it will use.
Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Switch SPARC GNU coreutils+bash from 32 to 64bit
1.2. Name of Document Author/Supplier:
Author: Roland Mainz
Darren Reed wrote:
Liane Praza wrote:
...
2.5 Manifest updates
As part of the initial integration of the Templates project, we will
provide a set of updated manifests, including updated manifests to
describe the global and restarter generic properties.
The svc:/system/svc/global
+ import [-V] file
...
+ If the -V option is specified, manifests which violate
+ the defined templates will fail to import. In interactive
+ invocations of svccfg, -V is the default behaviour.
So, no way to import a manifest interactively without this option?
(I
Nicolas Williams wrote:
+ import [-V] file
...
+ If the -V option is specified, manifests which violate
+ the defined templates will fail to import. In interactive
+ invocations of svccfg, -V is the default behaviour.
So, no way to import a manifest
John Plocher wrote:
Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Switch SPARC GNU coreutils+bash from 32 to 64bit
1.2. Name of Document Author/Supplier:
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.
Roland has identified several utilities that would benefit from
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 ocean scope creep.
Sometimes
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
versions may or may not be ready
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
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
Joseph Kowalski wrote:
To be more constructive, maybe we should look at the CLIP
case. On the surface, its not relevant, but perhaps we should
remember the strong advice (er, requirement) in that case of
When in Rome, do as the Romans.
Since we are moving all the inhabitants of the
John Plocher wrote:
Joseph Kowalski wrote:
To be more constructive, maybe we should look at the CLIP
case. On the surface, its not relevant, but perhaps we should
remember the strong advice (er, requirement) in that case of
When in Rome, do as the Romans.
Since we are moving all the
John Plocher writes:
Joseph Kowalski wrote:
To be more constructive, maybe we should look at the CLIP
case. On the surface, its not relevant, but perhaps we should
remember the strong advice (er, requirement) in that case of
When in Rome, do as the Romans.
Since we are moving
I'm sponsoring this open exposure fast-track for Jingjing Duan and
myself. The timer is set to 06/06/2008.
Background
Zebra Routing Suite (PSARC 2004/448) originally added Zebra to
Solaris, delivering through SFW and /usr/sfw. This was then
replaced by Quagga (a Zebra branch) with
Mostly deleted. Most of Roland's concern is his scheduling. Sorry, I
don't care.
Desiring to work on something this weekend, is not one of the reasons for
using self-review.
Other observations follow:
Roland Mainz wrote:
Why do you want that I want to do _all_ utilities in one piece ? It's
Liane Praza wrote:
Darren Reed wrote:
Liane Praza wrote:
...
2.5 Manifest updates
As part of the initial integration of the Templates project, we will
provide a set of updated manifests, including updated manifests to
describe the global and restarter generic properties.
The
Darren Reed wrote:
Liane Praza wrote:
Darren Reed wrote:
Liane Praza wrote:
...
2.5 Manifest updates
As part of the initial integration of the Templates project, we will
provide a set of updated manifests, including updated manifests to
describe the global and restarter generic
Joseph Kowalski wrote:
As other posts have suggested, we need to decide what the appropriate group
of utilities to do as subprojects is appropriate.
I disagree that we == PSARC for that case. Give guidance, yes, but
it is not PSARC's job to make the final decision.
My Rome is all versions of
Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
zpool autoexpand property
1.2. Name of Document Author/Supplier:
Author: George Wilson
1.3 Date of This
We are requesting a patch binding.
Matthew Ahrens wrote:
Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
zpool autoexpand property
1.2. Name of Document
John Plocher wrote:
Joseph Kowalski wrote:
As other posts have suggested, we need to decide what the appropriate
group
of utilities to do as subprojects is appropriate.
I disagree that we == PSARC for that case. Give guidance, yes, but
it is not PSARC's job to make the final decision.
Matthew Ahrens wrote:
[SNIP]
D. MANPAGE DIFFS
The following text will be added under the Properties section:
autoexpand=on | off
Controls automatic pool expansion when the underlying LUN is
grown. If set to on, the pool will be resized according to the
size of
Torrey McMahon wrote:
Matthew Ahrens wrote:
[SNIP]
D. MANPAGE DIFFS
The following text will be added under the Properties section:
autoexpand=on | off
Controls automatic pool expansion when the underlying LUN is
grown. If set to on, the pool will be resized according to
Liane Praza wrote:
Darren Reed wrote:
Liane Praza wrote:
Darren Reed wrote:
Liane Praza wrote:
...
2.5 Manifest updates
As part of the initial integration of the Templates project, we will
provide a set of updated manifests, including updated manifests to
describe the global and
Matthew Ahrens wrote:
Torrey McMahon wrote:
Matthew Ahrens wrote:
[SNIP]
D. MANPAGE DIFFS
The following text will be added under the Properties section:
autoexpand=on | off
Controls automatic pool expansion when the underlying LUN is
grown. If set to on, the pool will
___
opensolaris-arc mailing list
opensolaris-arc at opensolaris.org
-- next part --
An HTML attachment was scrubbed...
URL:
http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080530/a5a6feb0/attachment.html
On Fri, May 30, 2008 at 05:37:14PM -0400, Sebastien Roy wrote:
On Fri, 2008-05-30 at 17:05 -0400, James Carlson wrote:
IS-IS uses ISO datagrams, and thus requires raw network access.
Because we're delivering the source upstream to quagga.net, which
compiles on many older Sun
37 matches
Mail list logo
