Philip Brown wrote:
On Thu, Jul 13, 2006 at 05:19:08PM -0400, James Carlson wrote:
The original reason for /usr/sfw was to prevent users from wandering
into External (extremely volatile; not necessarily compatible from
patch to patch) software. But with GNOME integrating into /usr/bin as
Extern
On Fri, Jul 14, 2006 at 01:01:20PM -0400, James Carlson wrote:
> Dennis Clarke writes:
> > The software package at Blastwave ( built by you ) is built on Solaris 8
> > such that we can rest assured that it runs as expected for users with
> > Solaris 8 and 9 and 10 and Nevada. If the package doe
On Thu, Jul 13, 2006 at 05:19:08PM -0400, James Carlson wrote:
>
> The original reason for /usr/sfw was to prevent users from wandering
> into External (extremely volatile; not necessarily compatible from
> patch to patch) software. But with GNOME integrating into /usr/bin as
> External and with
Dennis Clarke writes:
> > It does run with compatibility.
>
> Is that a flaw or some sort of a weakness in the software?
It might be, depending on your perspective.
> Is a binary that is compiled on Solaris 8 with Sun ONE Studio 8 any more or
> less able to run on a Solaris 10 server?
Nope. It
> Dennis Clarke writes:
>> > This is an old version that does not yet know about fine grained privs
>> > and as Blastwave does primarily supports Solaris 8 we need to decide how
>> > to support cdrecord on Blastwave in future.
>> >
>>
>> ** WRONG **
>
> Really?
Yes Really. :-P
Blastwave does
Dennis Clarke writes:
> > This is an old version that does not yet know about fine grained privs
> > and as Blastwave does primarily supports Solaris 8 we need to decide how
> > to support cdrecord on Blastwave in future.
> >
>
> ** WRONG **
Really?
> The software package at Blastwave ( buil
> James Carlson <[EMAIL PROTECTED]> wrote:
>> Joerg Schilling writes:
>
>> I also looked in the current blastwave version (identified as
>> "cdrtools-2.01b38,REV=2004.8.26-SunOS5.8"), and the same appears to be
>> true; there's no class-action invocation that would add this exec_attr
>> entry.
>
>
James Carlson <[EMAIL PROTECTED]> wrote:
> Joerg Schilling writes:
> > For cdrtools it is a bit more complex.
> >
> > If you like to run cdrecord, you need to prepare files from the ON
> > consolidation (e.g. /etc/security/exec_attr). Otherwise the current
> > rootless installation will not work
Joerg Schilling writes:
> For cdrtools it is a bit more complex.
>
> If you like to run cdrecord, you need to prepare files from the ON
> consolidation (e.g. /etc/security/exec_attr). Otherwise the current
> rootless installation will not work.
>
> We need to find out why this does not seem to w
James Carlson <[EMAIL PROTECTED]> wrote:
> Dennis Clarke writes:
> > look at that .. the SFW stuff goes into /bin and not /usr/sfw/bin
>
> Yes. We're trying to get rid of the /usr/sfw/bin botch as best we
> can, or at least not allow it to grow.
For cdrtools it is a bit more complex.
If you lik
Dennis Clarke writes:
>
> > Dennis Clarke writes:
> >> look at that .. the SFW stuff goes into /bin and not /usr/sfw/bin
> >
> > Yes. We're trying to get rid of the /usr/sfw/bin botch as best we
> > can, or at least not allow it to grow.
> >
>
> why not /opt/sfw ?
Unbundled things go in /opt.
> Dennis Clarke writes:
>> look at that .. the SFW stuff goes into /bin and not /usr/sfw/bin
>
> Yes. We're trying to get rid of the /usr/sfw/bin botch as best we
> can, or at least not allow it to grow.
>
why not /opt/sfw ?
> The original reason for /usr/sfw was to prevent users from wandering
Dennis Clarke writes:
> look at that .. the SFW stuff goes into /bin and not /usr/sfw/bin
Yes. We're trying to get rid of the /usr/sfw/bin botch as best we
can, or at least not allow it to grow.
The original reason for /usr/sfw was to prevent users from wandering
into External (extremely volatil
> Dennis Clarke wrote:
>>> "Dennis Clarke" <[EMAIL PROTECTED]> wrote:
>>>
What would it take to get the code from cdrecord fed directly upstream
into
the snv tree such that the cdrecord in Solaris Nevada is up to date ?
>>> From what I did see until now, it seems that the cdrto
Dennis Clarke wrote:
"Dennis Clarke" <[EMAIL PROTECTED]> wrote:
What would it take to get the code from cdrecord fed directly upstream
into
the snv tree such that the cdrecord in Solaris Nevada is up to date ?
From what I did see until now, it seems that the cdrtools sources have not
been
int
> "Dennis Clarke" <[EMAIL PROTECTED]> wrote:
>
>>
>>
>> What would it take to get the code from cdrecord fed directly upstream
>> into
>> the snv tree such that the cdrecord in Solaris Nevada is up to date ?
>
> From what I did see until now, it seems that the cdrtools sources have not
> been
> in
"Dennis Clarke" <[EMAIL PROTECTED]> wrote:
>
>
> What would it take to get the code from cdrecord fed directly upstream into
> the snv tree such that the cdrecord in Solaris Nevada is up to date ?
>From what I did see until now, it seems that the cdrtools sources have not been
integrated into the
"Phi N. Tran" <[EMAIL PROTECTED]> wrote:
> cdrecord 2.01.01.a10 will be in snv 44. Since a11 just came out yesterday,
> it'll take a couple of builds to get it in since the cdrecord releases come
> out
> pretty fast sometimes.
This is no problem. The main source change was to supress a warning
cdrecord 2.01.01.a10 will be in snv 44. Since a11 just came out yesterday,
it'll take a couple of builds to get it in since the cdrecord releases come out
pretty fast sometimes.
Phi
This message posted from opensolaris.org
___
opensolaris-discuss m
19 matches
Mail list logo
