> > > > > ./lib/libast/common/features/*
> > > > > ./lib/libcmd/common/features/*
> > > > > ./lib/libdll/common/features/*
> > > > > ./lib/libshell/common/features/*
> > >
> > > These are feature probes (e.g. for "iffe"&co.), they're used to
> > > generate the matching platform-specific
Peter Memishian wrote:
>
> > Let's ignore the ATT Makefiles for a while. Are there other files
> > you'd like to see removed? A list based on Roland's annotated list
> > would be nice.
>
> Eliminating the ones that he called out as Documentation or tests, and
> reordering/compressing things a
Richard Lowe wrote:
> John Plocher wrote:
> > Keith M Wesolowski wrote:
[snip]
> > In much the same way that we generate C sources via rpcgen, the
> > ksh93 build process could [diff/patch, rename, exclude, etc] the
> > files found in the baseline tree to create the OpenSolaris-specific
> > source
Mike Kupfer wrote:
>
> > "Roland" == Roland Mainz <[EMAIL PROTECTED]> writes:
>
> Roland> For example: If we remove the "feature probes" (which build the
> Roland> majority of the "possibly (maybe) unused files"-list) - how can
> Roland> I refresh the generated file "in place" and create a pa
On 3/8/07, Joerg Schilling <[EMAIL PROTECTED]> wrote:
Richard Lowe <[EMAIL PROTECTED]> wrote:
> > In much the same way that we generate C sources via rpcgen, the
> > ksh93 build process could [diff/patch, rename, exclude, etc] the
> > files found in the baseline tree to create the OpenSolaris-sp
On 3/8/07, John Plocher <[EMAIL PROTECTED]> wrote:
Richard Lowe wrote:
> No
So, since it seems likely that the ksh93 project will need/desire
to keep this stuff around, where is it expected to live? As I read
Roland's comments (and, I admit I probably am confused), it seems like
he is desperat
Thanks for all the opinions, folks. I'll file the RFE and RTI today.
___
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
Garrett D'Amore wrote:
[EMAIL PROTECTED] wrote:
Alexander Kolbasov wrote:
psrinfo -vp currently outputs processor IDs in 'digested' form:
The physical processor has 1 virtual processor (0)
x86 (AuthenticAMD family 15 model 37 step 1 clock 2210 MHz)
AMD Opteron(tm) Processor 84
Boyd Adamson wrote:
> On 3/8/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
>> Now, NetBSD is a totally different beast. They provide a lot of
>> backwards compatibility, and generally any incompatible change that
>> might cause breakage is heavily frowned upon. There have been
>> exceptions, but
[EMAIL PROTECTED] wrote:
>> Alexander Kolbasov wrote:
>>
psrinfo -vp currently outputs processor IDs in 'digested' form:
The physical processor has 1 virtual processor (0)
x86 (AuthenticAMD family 15 model 37 step 1 clock 2210 MHz)
AMD Opteron(tm) Processor
> Let's ignore the ATT Makefiles for a while. Are there other files
> you'd like to see removed? A list based on Roland's annotated list
> would be nice.
Eliminating the ones that he called out as Documentation or tests, and
reordering/compressing things a bit for clarity:
> > > ./lib/libsh
On 3/8/07, Peter Memishian <[EMAIL PROTECTED]> wrote:
> > > The one reason I can think of to keep them is that they provide some
> > > clues about how ksh93 is built using the ATT toolset. So, for example,
> > > if we run into problems, they provide a comparison point. And if the
> > >
> > What do you mean with "diffs" in this case ?
>
> I meant the difference between one ATT Makefile and another.
Sorry, that was poorly stated -- I meant "one revision of a given ATT
Makefile and another revision of it".
--
meem
___
opensolaris-
> > > The one reason I can think of to keep them is that they provide some
> > > clues about how ksh93 is built using the ATT toolset. So, for example,
> > > if we run into problems, they provide a comparison point. And if the
> > > upstream version changes, the diffs for the ATT makefil
"I. Szczesniak" <[EMAIL PROTECTED]> wrote:
> On 3/8/07, Joerg Schilling <[EMAIL PROTECTED]> wrote:
> > "I. Szczesniak" <[EMAIL PROTECTED]> wrote:
> >
> > > > > This is not analogous to rpcgen, this is patching a fairly large
> > > > > component
> > > > > into the ON world *at build time*. Such t
On 3/8/07, Joerg Schilling <[EMAIL PROTECTED]> wrote:
"I. Szczesniak" <[EMAIL PROTECTED]> wrote:
> > > This is not analogous to rpcgen, this is patching a fairly large component
> > > into the ON world *at build time*. Such that we don't actually have the
> > > sources we build in the tree at a
"I. Szczesniak" <[EMAIL PROTECTED]> wrote:
> > > This is not analogous to rpcgen, this is patching a fairly large component
> > > into the ON world *at build time*. Such that we don't actually have the
> > > sources we build in the tree at all, but instead have the original sources
> > > and a co
"Richard L. Hamilton" <[EMAIL PROTECTED]> wrote:
> I gather BusyBox is intended for use in embedded distributions only,
> not "normal" ones constrained by backwards compatibility. In those
> situations, it would replace a bunch of commands.
>
> I would imagine the idea would be to reimplement it
Dan Mick writes:
> Does anyone think that either 1) this is a bad idea, or 2) that ARC is
> interested in this output format change,
I think it's a good idea, and it looks to me like the sort of change
that would reasonably fly beneath the ARC's radar.
> or 3) that anyone else has an
> opinion as
Richard Lowe <[EMAIL PROTECTED]> wrote:
> > In much the same way that we generate C sources via rpcgen, the
> > ksh93 build process could [diff/patch, rename, exclude, etc] the
> > files found in the baseline tree to create the OpenSolaris-specific
> > source tree. And then build that tree.
>
> N
Richard Lowe wrote:
> No
So, since it seems likely that the ksh93 project will need/desire
to keep this stuff around, where is it expected to live? As I read
Roland's comments (and, I admit I probably am confused), it seems like
he is desperately trying to keep the original ATT code (makefiles..
John Plocher wrote:
Keith M Wesolowski wrote:
On Thu, Mar 08, 2007 at 04:03:19AM +0100, Roland Mainz wrote:
Grumpf...
Am I correct in thinking that your concerns around removing these
files are entirely a result of a belief that the structure of the code
should be optimised for bulk upgrades fr
John Plocher wrote:
Keith M Wesolowski wrote:
On Thu, Mar 08, 2007 at 04:03:19AM +0100, Roland Mainz wrote:
Grumpf...
Am I correct in thinking that your concerns around removing these
files are entirely a result of a belief that the structure of the code
should be optimised for bulk upgrades fr
On 3/8/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
Now, NetBSD is a totally different beast. They provide a lot of
backwards compatibility, and generally any incompatible change that
might cause breakage is heavily frowned upon. There have been
exceptions, but they are few and far between.
>Alexander Kolbasov wrote:
>>> psrinfo -vp currently outputs processor IDs in 'digested' form:
>>>
>>> The physical processor has 1 virtual processor (0)
>>>x86 (AuthenticAMD family 15 model 37 step 1 clock 2210 MHz)
>>> AMD Opteron(tm) Processor 848
>>
>> Note that psrinfo doesn't d
If you want everyone to get a POSIX shell:
* give everyone /usr/xpg4/bin/sh as their shell
* put
PATH=`getconf CS_PATH`;export PATH
in /etc/profile
* put that same PATH value (expanded) in /etc/default/init
I think that would probably do it...maybe I missed something.
AFAIK, all POSIX requires is
The Board has asked that the polling system being used to conduct the
upcoming Board election first be tested in a meaningful way, by
asking the Community's Core Contributors to prioritize potential
Board initiatives for the coming year. This test poll opened at
00:00 PST March 8 a
27 matches
Mail list logo
