Volatile, externally controlled, that's the price of admission on this one, ok.
That they provide it at all is better than that they don't, and adding it so the
end user doesn''t have to hunt for it and/or has a similar experience as on
other
platforms, may be desirable. (I trust it's redistribut
Bart Smaalders wrote:
> Garrett D'Amore wrote:
>>> Since each action can contain arbitrary attributes, the customer's
>>> signature action can contain whatever data he wants; the packaging
>>> system happily ignores that which it doesn't know about so he can
>>> add new attributes to his signature
Bart Smaalders writes:
> James Carlson wrote:
>
> > We're setting ourselves up for yet more reasons (besides the usual
> > "resources" one) to deliver stale software if that issue and related
> > legal problems aren't solved.
> >
>
> By this argument we should stop shipping any new gnu software.
Ali Bahrami writes:
> Emacs is a pretty mature package (well over 20 years old), and is
> not evolving so fast that old copies are worthless. The value of
That's not what I was questioning. The part that I was questioning
was whether it was a good thing to be delivering things that we know
we can
On Fri, Aug 01, 2008 at 02:06:44PM -0700, Garrett D'Amore wrote:
> However, the case gets more interesting once gtk or athena based
> versions are available. Then choice could indeed play a role, and
> environment variables or some other per-user tunable would be nice. (I
> suppose just running
I am sponsoring this case for John Martin of the x86 driver team.
It requests a patch release binding as it only adds a new package
and does not modify existing interfaces.
The timer is set for next Friday, August 8, 2008.
-Alan Coopersmith- alan.coopersmith at sun.com
Ali Bahrami wrote:
> GNU emacs is usually referred to as 'emacs', while Xemacs is 'xemacs'.
> My assumption is that the Xemacs packages would therefore be
> SUNWxemacs-*.
>
OK - I'm happy.
-John
On Fri, Aug 01, 2008 at 04:57:49PM -0400, James Carlson wrote:
> If they all do get frozen, then that stinks, and it makes hash of the
> whole rationale for trying to ship them in the first place.
Maybe they only get frozen until Legal figures out a way forward. That
seems like a likely result to
John Plocher writes:
> Ali Bahrami wrote:
> > Note that there are two emacs variants in wide use, GNU emacs,
> > and Xemacs. This case is for GNU emacs only.
>
>
> > SUNWemacs
> > SUNWemacs-el
> > SUNWemacs-x
> > SUNWemacs-nox
>
>
> Given that there will probably also be a c
On Fri, Aug 01, 2008 at 01:21:40PM -0700, Garrett D'Amore wrote:
> On a separate note, its unclear to me whether SUNWemacs-nox is a sound
> approach for Solaris.
>
> It presents potential difficulties, as there is no precedent (that I'm
> aware of) for having the same binary program (/usr/bin/em
Gary Winiger writes:
> Dependencies
>
> SUNWgccruntimeGCC Runtime libraries
Why the dependency on SUNWgccruntime? Is SWIG being built with g++? If
so, this means that all C++ users of SWIG would be forced to use g++ as
well due the incompatible ABIs vs. Sun Studio CC.
Jyri Virkki wrote:
> Ali Bahrami wrote:
>> actual emacs binary available. The user has a choice of emacs binaries,
>> and is free not to install the ones that are not of value.
>
> Actually I did have one comment which I forgot in the joy of just
> seeing this case come in ;-)
>
> "Install" is a
As it happens, I have prototype versions of these emacs
packages available to those within Sun:
# pkgadd -d /net/rtld.central/local/emacs-pkg/`uname -p` \
SUNWemacs SUNWemacs-nox SUNWemacs-x SUNWemacs-el
These should install on recent Nevada, or OpenSolaris.
Feel free
James Carlson wrote:
> Ali Bahrami writes:
>> Emacs is a pretty mature package (well over 20 years old), and is
>> not evolving so fast that old copies are worthless. The value of
>
> That's not what I was questioning. The part that I was questioning
> was whether it was a good thing to be delive
I'll reply inline...
Garrett D'Amore wrote:
> On a separate note, its unclear to me whether SUNWemacs-nox is a sound
> approach for Solaris.
>
> It presents potential difficulties, as there is no precedent (that I'm
> aware of) for having the same binary program (/usr/bin/emacs)
> distributed
James Carlson wrote:
> Bart Smaalders writes:
>> James Carlson wrote:
>>
>>> We're setting ourselves up for yet more reasons (besides the usual
>>> "resources" one) to deliver stale software if that issue and related
>>> legal problems aren't solved.
>>>
>> By this argument we should stop shipping
James Carlson wrote:
>
> A deeper question is the value of integrating something that we know
> from the outset will be essentially a frozen snapshot dust collector
> due to Sun's internal legal issues. Wouldn't it be better to have
> someone outside of Sun who isn't afraid of GPLv3 do the work?
>
Jyri Virkki wrote:
> Ali Bahrami wrote:
>
>> actual emacs binary available. The user has a choice of emacs binaries,
>> and is free not to install the ones that are not of value.
>>
>
> Actually I did have one comment which I forgot in the joy of just
> seeing this case come in ;-)
>
> "Ins
John Plocher wrote:
> Ali Bahrami wrote:
>> Note that there are two emacs variants in wide use, GNU emacs,
>> and Xemacs. This case is for GNU emacs only.
>
>
>> SUNWemacs
>> SUNWemacs-el
>> SUNWemacs-x
>> SUNWemacs-nox
>
>
> Given that there will probably also be a call for
Ali Bahrami wrote:
>
> actual emacs binary available. The user has a choice of emacs binaries,
> and is free not to install the ones that are not of value.
Actually I did have one comment which I forgot in the joy of just
seeing this case come in ;-)
"Install" is a system-wide action (ignoring us
Sorry if I misunderstood what the case was delivering.
Still not sure exactly why we're doing a no-x version from a business
perspective (and I think JCarlson's issue is a business one as well),
but architecturally I see no further issues.
-- Garrett
Bart Smaalders wrote:
> Garrett D'Amore
James Carlson wrote:
> We're setting ourselves up for yet more reasons (besides the usual
> "resources" one) to deliver stale software if that issue and related
> legal problems aren't solved.
>
By this argument we should stop shipping any new gnu software.
What is your intent?
- Bart
--
Ba
Garrett D'Amore wrote:
> On a separate note, its unclear to me whether SUNWemacs-nox is a sound
> approach for Solaris.
>
> It presents potential difficulties, as there is no precedent (that I'm
> aware of) for having the same binary program (/usr/bin/emacs)
> distributed by different packages.
Ali Bahrami wrote:
>
> GNU emacs is usually referred to as 'emacs', while Xemacs is 'xemacs'.
> My assumption is that the Xemacs packages would therefore be
> SUNWxemacs-*.
>
> I agree that it's subtle, but this is the way those commands are commonly
> named, and I was following that pattern.
I d
I am sponsoring the following fast track for myself - timeout 8/8/2008.
The binding is Minor. Most interfaces are uncommitted (exceptions
are detailed below).
---
This case proposes to integrate the GNU emacs text editor
into the
On a separate note, its unclear to me whether SUNWemacs-nox is a sound
approach for Solaris.
It presents potential difficulties, as there is no precedent (that I'm
aware of) for having the same binary program (/usr/bin/emacs)
distributed by different packages. It potentially raises challenges
On Fri, 2008-08-01 at 12:36 -0700, John Plocher wrote:
> Ali Bahrami wrote:
> > Note that there are two emacs variants in wide use, GNU emacs,
> > and Xemacs. This case is for GNU emacs only.
>
>
> > SUNWemacs
> > SUNWemacs-el
> > SUNWemacs-x
> > SUNWemacs-nox
>
>
> Given th
Ali Bahrami wrote:
> Note that there are two emacs variants in wide use, GNU emacs,
> and Xemacs. This case is for GNU emacs only.
> SUNWemacs
> SUNWemacs-el
> SUNWemacs-x
> SUNWemacs-nox
Given that there will probably also be a call for having Xemacs,
wouldn't it be better
On Fri, 01 Aug 2008 10:57:20 +0200, Darren J Moffat
wrote:
> I think this case needs a formal opinion. I'm derailing it an will
> happily provide the opinion text (as either majority or minority).
>
> Do other ARC members wish to vote now or when they see a draft opinion ?
I'd hope and expect
scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080801/6d8913c9/attachment.html>
While I agree with you in principle, we should be building all of
Solaris with Studio, there are cases where using Studio is not really
worth the effort. There are several open source components out there
that seem to make heavy use of GCC extensions or what I more "lovingly"
like to think of
Darren Reed ??:
> Will irssi be linking with SSL from OpenSSL?
Yes.
> If so, does the irssi team have a contract for OpenSSL?
I think so, and I am contacting the Irssi team for the confirmation,
will get back to you on this once I get reply...
>
> Darren
>
Frank Batschulat (Home) wrote:
> On Fri, 01 Aug 2008 10:57:20 +0200, Darren J Moffat Sun.COM> wrote:
>
>> I think this case needs a formal opinion. I'm derailing it an will
>> happily provide the opinion text (as either majority or minority).
>>
>> Do other ARC members wish to vote now or when t
Garrett D'Amore wrote:
>> Since each action can contain arbitrary attributes, the customer's
>> signature action can contain whatever data he wants; the packaging
>> system happily ignores that which it doesn't know about so he can
>> add new attributes to his signature ad nauseam.
>>
>> This would
Bart Smaalders wrote:
> Stephen Hahn wrote:
>
>> I am having difficulty formulating a use case where nested or multiply
>> signed packages are needed, and in which the consumer makes different
>> decisions when distinct subsets of the signing entities cannot be
>> independently verified.
Daniel Hain wrote:
> I've been informed that the project team has an Aug 6 deadline for
> providing EOF materials to Marketing and Docs, pending resolution of
> this case (timeout on 8/4). I would like to summarize where I think we
> are so that the project team can address any issues between
This appears to be incorrect. On one of the web instruction pages
telling us how to port these packages there is a test script. This test
scripts output said that there was a dependency for SUNWgccruntime
however I've checked the swig exe and the Makefiles and swig is being
built with Sun Studi
Darren J Moffat wrote:
> Frank Batschulat (Home) wrote:
>> On Fri, 01 Aug 2008 10:57:20 +0200, Darren J Moffat
>> wrote:
>>
>>> I think this case needs a formal opinion. I'm derailing it an will
>>> happily provide the opinion text (as either majority or minority).
>>>
>>> Do other ARC members w
Agreed. All software in the OS should be compiled with Sun Studio. The GNU
stuff should just be there to help developers port things. Not to mention how
poorly g++ performance is on Solaris, let alone SPARC.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Octave J. Orgeron
Solaris Systems E
39 matches
Mail list logo
