On Tue, Oct 28, 2008 at 03:32:44PM -0700, Garrett D'Amore wrote:
> What distributions actually "require" gcc to build? I can guess that
ON requires GCC to build, since the xVM gate does. It's also full of
code using obscure GCC features, as much of the code is Linux derived.
regards
john
Hitendra Zhangada writes:
> I totally agree with this but if ARC members do not review the
> fast-track material/proposal then that is of no fault of the project
> team or the case submitter.
I agree. The fine line that's being walked here is between punishing
that project's management team for n
Stefan Teleman writes:
> >>This FastTrack proposes the Integration of a more recent version
> >>of GNU binutils, which is compatible with Versions 4.3.x of the
> >>GNU Compiler Collection [ GCC ]. [2]
> >
> > This is not true: all recent versions up to and including GCC mainline (to
Hi Martina,
> > I don't see the point of installing those compat headers and library. To
> > my understanding, they are present only for those platforms that otherwise
> > lack libdbm and dbm.h/ndbm.h, which isn't true for Solaris. (They are only
> > installed by the non-default install-compat M
John Plocher wrote:
> In an attempt to be proactive and clarify what the ARC expects
> to happen in the rare situation where a case is submitted, but
> nobody actually reviews it, PSARC developed the following
> cross-ARC case approval process update.
>
> Since it started as a potential Sun-interna
Nicolas Williams wrote:
> On Tue, Oct 28, 2008 at 05:50:04PM -0400, Stefan Teleman wrote:
>>> What consequences and complexity?
>> Having all the Consolidations which currently use GCC 3.4.3 discover that
>> the GCC compiler they use no longer exists, and it has been replaced by a
>> newer comp
+1
On Oct 22, 2008, at 11:23 AM, John Plocher wrote:
> In an attempt to be proactive and clarify what the ARC expects
> to happen in the rare situation where a case is submitted, but
> nobody actually reviews it, PSARC developed the following
> cross-ARC case approval process update.
>
> Since i
John Plocher wrote:
>> This ARC Case [ and any subsequent, related ARC Cases ] does not [ do
>> not ]
>> address the existing GCC 3.4.3 and/or binutils 2.15. There have been
>> no change requests for either the upgrade, update, or removal of
>> either GCC 3.4.3, or binutils 2.15.
>>
>> Any ch
On Tue, Oct 28, 2008 at 03:04:28PM -0700, Bart Smaalders wrote:
> Note that Stefan's argument is this: changing binutils for the existing
> gcc is a compiler change, and would seem to warrant rather extensive
> testing of the affected consolidations. Is this a good idea?
We do change compilers f
On Tue, Oct 28, 2008 at 06:04:40PM -0400, Stefan Teleman wrote:
> >But you're replacing GCC [yet]. You're replacing binutils, and as far
> >as we all understand there's no reason why GCC 3.4.3 shouldn't work just
> >fine with the new binutils. Have you tested GCC 3.4.3 w/ the latest
> >binutils?
On Tue, Oct 28, 2008 at 05:50:04PM -0400, Stefan Teleman wrote:
> >What consequences and complexity?
>
> Having all the Consolidations which currently use GCC 3.4.3 discover that
> the GCC compiler they use no longer exists, and it has been replaced by a
> newer compiler, and this was done witho
Alan Coopersmith wrote:
> Garrett D'Amore wrote:
>
>> What distributions actually "require" gcc to build? I can guess that
>> SFW might because of free software projects that rely on GNUisms, but
>> hopefully none of the others do...
>>
>
> You mean consolidations? ON, X, JDS, SFW...
>
Garrett D'Amore wrote:
> What distributions actually "require" gcc to build? I can guess that
> SFW might because of free software projects that rely on GNUisms, but
> hopefully none of the others do...
You mean consolidations? ON, X, JDS, SFW...
--
-Alan Coopersmith- alan.co
I've added a set of slides (boomer-inception.pdf) and updated the spec
document (boomer.pdf) in the inception.materials directory.
gd78059 at sac{6}>ls -la
total 1144
drwxrwsr-x 2 gd78059 sac9 Oct 28 15:40 .
drwxrwsr-x 8 gd78059 sac 12 Oct 27 12:38 ..
-rw-r--r--
Nicolas Williams wrote:
> On Tue, Oct 28, 2008 at 06:04:40PM -0400, Stefan Teleman wrote:
>
>>> But you're replacing GCC [yet]. You're replacing binutils, and as far
>>> as we all understand there's no reason why GCC 3.4.3 shouldn't work just
>>> fine with the new binutils. Have you tested GCC
Rainer Orth wrote:
>> Please see my comment above.
>
> they only describe why you don't use binutils 2.18.
Well, yes. :-) 2.18 is broken on Solaris x86. 2.17 works just fine, passes all
the torture tests for binutils and GCC.
But, i see that binutils 2.19 was released yesterday, 10/27/2008.
Stefan Teleman wrote:
>
>
> John Plocher wrote:
>
>>> This ARC Case [ and any subsequent, related ARC Cases ] does not [ do
>>> not ]
>>> address the existing GCC 3.4.3 and/or binutils 2.15. There have been
>>> no change requests for either the upgrade, update, or removal of
>>> either GCC 3.
Stefan Teleman wrote:
>
> AFAIK, O/N does not compile with either GCC 4.3.1 or 4.3.2. I'll happily
> stand corrected if that is not the case.
>
You are correct. I happen to have the set of source code changes needed
to make ON compile with gcc 4.x, but I haven't integrated them into ON yet.
Stefan Teleman wrote:
> Exactly -- and i'd like to integrate a recent version of binutils
I completely agree.
> We already have
> a GCC (3.4.3) which uses binutils 2.15.
Which would not be harmed at all if you removed binutils 2.15 and
replaced it with something newer. The gas/binutils mainta
Right. I was on the call. I will work with Petr to resolve the missing
API issues, and we eagerly await the opinion as to how and where it
should be installed.
Tom Childers wrote:
> Brian,
>
> We discussed this case, and the junit case, in our OpenARC meeting this
> morning. We are extending
I am sponsoring the following case for Bill Holler. We believe that this
is a Self Review, but are willing to change it to a fasttrack if someone
desires. The added keywords are committed and the binding is Patch/Micro.
Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Copyrig
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081028/d10afbc3/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: Michael_Kearney.vcf
Type: text/x-vcard
Size: 347 bytes
Des
Michael Kearney wrote:
> 1.0 Project Information
> Eclipse is one of the most popular open source Java IDE.
text based next time please, not html. The tools that parse the
structured document don't render html first...
-John
extMessageID method and
>> NumMsgsPending. See specific changes above.
>> Unbundled Filesystem Layout Committed *New Interface.*
>>
>> Creates a new filesystem layout for the product when it is not
>> shipped with native packaging. See the Filesystem Layout
>> specification
>> <http://sac.sfbay/arc/LSARC/2008/648/specs/filelayout.html>
>>
>> Broker Log InfomationUncommitted Modified an existing
>> interface by adding new log messages (no format changes)
>> UMS Protocol Committed *New Interface.*
>>
>> Defines the protocol for the new ums service.See the UMS Protocol
>> Specification
>> <http://sac.sfbay/arc/LSARC/2008/648/specs/ums/protocol.html>
>>
>> UMS ConfigurationCommitted *New Interface.*
>>
>> Defines the configuration properties for the new ums service. See
>> the UMS Configuration Specification
>> <http://sac.sfbay/arc/LSARC/2008/648/specs/ums/config.html>
>>
>> imqums.war Committed *New Interface.*
>>
>> Defines the name of the war file used for deploying the new ums
>> service. See specific changes above.
>>
>> /bin/mqunistall[.bat] Committed *New Interface.*
>>
>> A new script file which is available only on the new openMQ
>> bundles that makes it easier for users to find the uninstaller.
>> See specific changes above.
>>
>>
>> *Imported Interfaces*
>> InterfaceClassification Comments
>> HKLM\SOFTWARE\Java Soft\Java Runtime Environment\CurrentVersion
>> Standard *New Interface*
>>
>> Location of the latest release of the JRE on a windows system.
>>
>> HKLM\SOFTWARE\Java Soft\Java Runtime
>> Environment\\JavaHome Standard*New Interface*
>>
>> Location of the java home for a release of the JRE on a windows
>> system.
>>
>>
>>
>>
>> References
>>
>> *Current Release*:
>>
>> Message Queue 4.3 feature functional specifications:
>>
>> * UMS protocol
>> <http://sac.sfbay/arc/LSARC/2008/648/specs/ums/protocol.html>
>> * UMS configuration specification
>> <http://sac.sfbay/arc/LSARC/2008/648/specs/ums/config.html>
>> * MQ Filesystem Layout and packaging specification for Robin
>> <http://sac.sfbay/arc/LSARC/2008/648/specs/filelayout.html>
>>
>>
>> *Previous Release*:
>>
>> Message Queue 4.2 (Harrier) LSARC case:
>> http://sac.sfbay.sun.com/arc/LSARC/2008/387
>>
>>
>>
>>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081028/9e5664e2/attachment.html>
Brian,
We discussed this case, and the junit case, in our OpenARC meeting
this morning. We are extending the timer on this fast-track to Friday:
1. we will be writing an opinion for the junit case, 2008/633, and the
content will impact the location of your deliverables. We are talking
abou
changes above.
>
> /bin/mqunistall[.bat]Committed New Interface.
> A new script file which is available only on the new openMQ bundles
> that makes it easier for users to find the uninstaller. See specific
> changes above.
>
>
> Imported Interfaces
> Interface Classification Comments
> HKLM\SOFTWARE\Java Soft\Java Runtime Environment\CurrentVersion
> Standard New Interface
> Location of the latest release of the JRE on a windows system.
>
> HKLM\SOFTWARE\Java Soft\Java Runtime Environment\\JavaHome
> Standard New Interface
> Location of the java home for a release of the JRE on a windows
> system.
>
>
>
> References
>
> Current Release:
>
> Message Queue 4.3 feature functional specifications:
>
> UMS protocol
> UMS configuration specification
> MQ Filesystem Layout and packaging specification for Robin
>
> Previous Release:
>
> Message Queue 4.2 (Harrier) LSARC case:
> http://sac.sfbay.sun.com/arc/LSARC/2008/387
>
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081028/2e3f4c7a/attachment.html>
Yes, it applies to all FOSS projects.
But it's very much a question of practical consequence for using FOSS.
What is "architectural" exactly?
AFAIK maintenance *is* an architectural question because it speaks
directly to:
- version or version(s) installed
- when and how versions are updated
-
My comments should not hold up this junit case.
...
I don't think we need to see any maven case--
I was just stating what is fairly common development practice which
makes installation of junit and many other libraries a moot issue: one
writes a maven build script (pom) and it automatically
Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
GDM system user home directory
1.2. Name of Document Author/Supplier:
Author: Darren Moffat
1.3 Date of This Docum
Sorry for the lateness of this reply.
We only use cachefs in the www cluster, to take load off the x4500s. Since it
is read-only data, to be served with Apache it is saving quite a lot of load
for the NFS servers.
There are some issues, the first access seems to be rather slow, but any
followi
30 matches
Mail list logo
