Shawn Walker wrote:
Craig S. Bell wrote:
Let me play devil's advocate: If people have the option to continue
using the old package system (with it's action scripting
capabilities), then could that slow adoption of the new pkg format?
Or is that just the cost of providing compatibility?
I th
How does IPMITool logs the information in system event log(SEL)when the
system has some faults relating to power redundancy?
What is the search pattern to use if I want to redirect the "ipmitool SEL
list" command output to a file and determine whether the system has the
following hardware fault
> Dennis Clarke wrote:
>
>> Also, what rev is this ? I have been running this for a while and it
>> rocks :
>>
>> $ /opt/schily/bin/star --version
>> star: star 1.5a89 (i386-pc-solaris2.8)
>
> Why don't you use the recent version. Blastwave has a version 1.5 but it
> is
> really the 1.5.1 as I j
Craig S. Bell wrote:
Let me play devil's advocate: If people have the option to continue using the
old package system (with it's action scripting capabilities), then could that
slow adoption of the new pkg format? Or is that just the cost of providing
compatibility?
I think those users will
Craig S. Bell wrote:
> Alan, what will happen with old-style packages with dependencies on other
> SUNW* packages -- will there a way to artificially fulfill these? It seems
> like it will take some ongoing effort to continue supporting the SysV format.
IPS currently puts entries into the SVR4
Craig S. Bell wrote:
Alan, what will happen with old-style packages with dependencies on other SUNW*
packages -- will there a way to artificially fulfill these? It seems like it
will take some ongoing effort to continue supporting the SysV format.
IPS packages can provide what is called a "l
Alan, what will happen with old-style packages with dependencies on other SUNW*
packages -- will there a way to artificially fulfill these? It seems like it
will take some ongoing effort to continue supporting the SysV format.
Let me play devil's advocate: If people have the option to continue
Craig S. Bell wrote:
Shawn, thanks for explaining. I think that we'll get to where we need to be
for our enterprise build and recovery model. So much of what we do (especially
patching) is a big work-around, if you step back and take a look at it.
This amount of change naturally makes an ent
Shawn, thanks for explaining. I think that we'll get to where we need to be
for our enterprise build and recovery model. So much of what we do (especially
patching) is a big work-around, if you step back and take a look at it.
This amount of change naturally makes an entrenched sysadmin like m
Halton Huo wrote:
> I can not access http://wiki.genunix.org for several days, anybody know
> what happens?
See the notice in the first news item on http://www.genunix.org/
--
-Alan Coopersmith- alan.coopersm...@sun.com
Sun Microsystems, Inc. - X Window System Engineer
Halton Huo wrote:
I can not access http://wiki.genunix.org for several days, anybody know
what happens?
Yes, it is currently offline and the administrator will be working on it
as soon as possible.
--
Shawn Walker
___
opensolaris-discuss mailing li
I can not access http://wiki.genunix.org for several days, anybody know
what happens?
-Halton
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Craig S. Bell wrote:
Shawn, this sounds promising. Just to be clear, will I be able to analyze and apply arbitrary updates while offline, or only well-known releases?
As far as repository ISO images, at this point, I only know of the major
releases found in the /release repository being suppo
Shawn, this sounds promising. Just to be clear, will I be able to analyze and
apply arbitrary updates while offline, or only well-known releases?
For instance, we use pca's proxy feature to cache our patches. So long as I
have a reference xref handy, pca can do all of the needed analysis offl
On 17/12/2009 23:07, Joerg Schilling wrote:
ken mays wrote:
Ref: http://jucr.opensolaris.org/files/3117/7545/specs/star.spec
It is most unlikely that this will create a useful result.
well, it is a start.
I doubt there should be any big issues in making it build under the SJ.
Craig S. Bell wrote:
> I can't see vendors updating all of their software, though -- we still
> install S8-built commercial packages today, and they have actions. The
> vendor doesn't care to update them. Will they spend the effort for pkg?
> It's a potential barrier.
That's why pkgadd & com
Craig S. Bell wrote:
I need to keep one local cached repository of updates for installing on a
private network (no internet needed during updates). I'm not clear on whether
the pkg tools fully support proxies yet. IMHO this is necessary for enterprise
usage.
This should be true as of build
My thoughts on migrating to the new world of install and update:
wanboot and flash archives (or their equivalent) are very important for
managing our site. I have been assured that a flar equivalent is coming for the
new tools, but that's all I know so far. We live and die by flar, this
functi
there is a part of the spec file where you can specify which packages
are required to compile your package
it's called buildrequires. what else do you need? you can even use the
spec file you were given as an example.
what's wrong with just /usr/bin/star ?
nacho
On Thu, Dec 17, 2009 at 8:34 PM,
Joerg Schilling wrote:
> Ignacio Marambio Catán wrote:
>
>> perhaps you should integrate smake into jucr first and then have the
>> spec file for star BuildRequire it? and while you're at it, you can
>> place it in /usr where it should be?
>
> Well, smake compiles without the need for a "make" p
Ignacio Marambio Catán wrote:
> perhaps you should integrate smake into jucr first and then have the
> spec file for star BuildRequire it? and while you're at it, you can
> place it in /usr where it should be?
Well, smake compiles without the need for a "make" program as it first
creates a boos
On Thu, Dec 17, 2009 at 11:15 PM, Alan Coopersmith
wrote:
> Peter Tribble wrote:
>> But that problem arises not because SVR4 packaging supports scripting
>> but because it only does so badly. What's needed is:
>>
>> 1. For the packaging system to fully support scripting as a first-class
>> citizen
perhaps you should integrate smake into jucr first and then have the
spec file for star BuildRequire it? and while you're at it, you can
place it in /usr where it should be?
nacho
On Thu, Dec 17, 2009 at 8:07 PM, Joerg Schilling
wrote:
> ken mays wrote:
>
>> Ref: http://jucr.opensolaris.org/fil
On Thu, Dec 17, 2009 at 11:12 PM, Shawn Walker wrote:
> Peter Tribble wrote:
>>
>> IPS ought to do this right, and is pretty much there because it actually
>> does have the framework to do everything correctly, but claims that
>> scripting is forbidden and therefore doesn't provide the public hook
Peter Tribble wrote:
> But that problem arises not because SVR4 packaging supports scripting
> but because it only does so badly. What's needed is:
>
> 1. For the packaging system to fully support scripting as a first-class
> citizen. Which could include actually providing the most common
> functi
Dennis Clarke wrote:
>
> > Ref: http://jucr.opensolaris.org/files/3117/7545/specs/star.spec
> >
> > Well, congrats on getting it into the SourceJuicer system and I think it
> > is passing.
> >
> > Do we want star v1.5.1 version to review as the final spec??
>
> Also, can we get that in /usr ?
>
>
Peter Tribble wrote:
IPS ought to do this right, and is pretty much there because it actually
does have the framework to do everything correctly, but claims that
scripting is forbidden and therefore doesn't provide the public hooks,
again forcing every script writer into carrying the responsibili
On Thu, Dec 17, 2009 at 9:53 PM, John Plocher wrote:
>>> The better question is why someone is doing something
>>> so broken in the first place.
>>
>> There is nothing broken about being able to consistently and repeatably
>> create databases via packages.
>
> If you can do so in a way that relia
ken mays wrote:
> Ref: http://jucr.opensolaris.org/files/3117/7545/specs/star.spec
It is most unlikely that this will create a useful result.
Sun make does not support constructs like:
make CC=something or similar
as it does not forward command line macros to sub-makes.
If it did, the line:
> Ref: http://jucr.opensolaris.org/files/3117/7545/specs/star.spec
>
> Well, congrats on getting it into the SourceJuicer system and I think it
> is passing.
>
> Do we want star v1.5.1 version to review as the final spec??
Also, can we get that in /usr ?
I think /opt/schily/bin/star or even the
Ref: http://jucr.opensolaris.org/files/3117/7545/specs/star.spec
Well, congrats on getting it into the SourceJuicer system and I think it is
passing.
Do we want star v1.5.1 version to review as the final spec??
~Ken
--- On Thu, 12/17/09, Joerg Schilling
wrote:
> From: Joerg Schilling
> S
Joerg Schilling wrote:
Robert Milkowski wrote:
As someone else has already mentioned - Joerg why don't you try to get
it into /contrib repo via Source Juicer in the first place? IMHO this
would be the fastest way to get it into Open Solaris. It would probably
make it easier to get it promote
Robert Milkowski wrote:
> As someone else has already mentioned - Joerg why don't you try to get
> it into /contrib repo via Source Juicer in the first place? IMHO this
> would be the fastest way to get it into Open Solaris. It would probably
> make it easier to get it promoted later on to mai
>> The better question is why someone is doing something
>> so broken in the first place.
>
> There is nothing broken about being able to consistently and repeatably
> create databases via packages.
If you can do so in a way that reliably does so, then there is no problem.
Unfortunately, given
Hi,
As someone else has already mentioned - Joerg why don't you try to get
it into /contrib repo via Source Juicer in the first place? IMHO this
would be the fastest way to get it into Open Solaris. It would probably
make it easier to get it promoted later on to main repo if needed.
--
Rober
Hi,
As someone else has already mentioned - Joerg why don't you try to get
it into /contrib repo via Source Juicer in the first place? IMHO this
would be the fastest way to get it into Open Solaris. It would probably
make it easier to get it promoted later on to main repo if needed.
--
Rober
ken mays wrote:
> We don't. GNU tar is legacy. Your star is the answer, so let us get the
> latest star version into the package repository!
OK!
> > > True. I think star handles file sizes over 200
> > terabytes as well. Right?
> >
> > ??? How do you get to this number and why do you ask at
>
--- On Thu, 12/17/09, Joerg Schilling
wrote:
>
> > > I see absolutely no need for GNU tar. What
> features are
> > > unique to GNU tar that
> > > "require" GNU tar?
> >
> > Well GNU tar is just a tool so 'requirements' and a
> tool based on those requirements is not so much in equality.
> Mos
a b wrote:
"Never compromise", goes the wisdom at TOYOTA; lest any doubt that wisdom, they
are the undisputed ruler of the automotive industry, on this entire planet.
There is a lesson to be learned from that.
Actually see this week's Economist magazine (Dec 12th) - Toyota is not
the same for
I wouldn't argue that it's easier to maintain code in a dynamic high-
level language like Python rather a compiled relatively low-level
language like C. Some projects benefit from focus on elements of
programming like memory management and are thus better written in C,
but the problem that's
..
>> There is a lesson to be learned from that.
>>
>> And, what you ended up with, above, is a SALAD of half-C, half Python.
>> Perhaps you like curdled milk; I can't stand it.
>>
>> One of the first hardcore lessons I had been taught, when I was young and
>> starting my career as a sysadmi
Joseph Mocker wrote:
While I don't entirely agree with UNIX admin, I am sort of concerned
with the growing number of scripting environments that are now required
to make [Open]Solaris run.
First I realized that Perl was needed was when I discovered the kstat
was rewritten in Perl, which kind
So, instead of just replace 128a on (hd1,0) it crashes second,third primary
and extended partitions and any systems installed on this partitions. Build
124-128a kept everything alive, just replacing
OSOL disk
--
This message posted from opensolaris.org
_
ken mays wrote:
> > I see absolutely no need for GNU tar. What features are
> > unique to GNU tar that
> > "require" GNU tar?
>
> Well GNU tar is just a tool so 'requirements' and a tool based on those
> requirements is not so much in equality. Most FOSS developers utilizing
> build management
Alan Coopersmith wrote:
Please take your insults of the members of this community elsewhere.
They are not welcome here.
I've already issued a warning earlier today, that seems to have been
ignored.
If the OGB feels it is necessary to suspend the individuals who have
been making offensive r
> Please take your insults of the members of this community elsewhere.
> They are not welcome here.
It's not meant as an insult; I'm merely stating the current state of affairs.
But if you'd like me to leave, I've no problem with that. Bye.
> I would think that by keeping state somewhere, either via SMF properties
> or something else, you can record that you've "initialized" your package
> already and so in the SMF methods you would check the state before
> performing any action.
I was thinking the same thing. However, several q
a b wrote:
>> It seems that the type of engineer at Sun did change since the days of
> Bill Joy.
>
> It certainly appears so.
> And it also does not look like the change was for the better.
Please take your insults of the members of this community elsewhere.
They are not welcome here.
--
> As many recent studies have shown, interpreted languages can bring
> identical or acceptable performance levels for many operations when
> suitable algorithms are employed.
I believe that Wikipedia would term the above paragraph as "weasel words",
and put the applicable notice on the article.
> Most ISVs won't support short term releases of OpenSolaris, and that
> really isn't on our radar.
You told me everything I need to know, thank-you-very-much. Goodbye.
_
Windows Live: F
> You find optimizing Python with C as "Proof enough"? An unfortunate
> statement of ignorance (meant literally, not as an insult).
None taken; if I need to be educated, then educate me.
> The time from development to deployment with Python is generally very low and
> the code is also general
Hi Pradeep,
Please log a support call with your local Solution Centre for this. They
will be able to assist with troubleshooting your S10 install issues.
Regards,
Brian
Pradeep wrote:
Hi All,
I am installing solaris over pxe using jumpstart server ,
It went through initial tftbo
Why do you want/need to do this? What problem are you trying to solve here?
Regards,
Brian
Shreyas Bhatewara wrote:
Folks,
I am writing a device driver for current and past versions of (Open)Solaris
How can I check the version of the running kernel in the driver code ? I tried
using utsname
> It seems that the type of engineer at Sun did change since the days of Bill
> Joy.
It certainly appears so.
And it also does not look like the change was for the better.
_
Windows Live Ho
--- On Thu, 12/17/09, Joerg Schilling
wrote:
> From: Joerg Schilling
> Subject: Re: [osol-discuss] star [was: Some Why?-Questions]
> To: opensolaris-discuss@opensolaris.org, maybird1...@yahoo.com
> Date: Thursday, December 17, 2009, 6:28 AM
> ken mays
> wrote:
>
> > > Dennis Clarke wrote:
Hi All,
I am installing solaris over pxe using jumpstart server ,
It went through initial tftboot and after while loding module
it failed giving error
module$ /I86PC.Solaris_10-1/$ISADIR/x86.miniroot
loading module$ /I86PC.Solaris_10-1/$ISADIR/x86.miniroot
Error 25: Disk read erro
"Volker A. Brandt" wrote:
> I understand your frustration, as I have been feeling it myself.
>
> Yes, Sun has made two big mistakes: Implementing IPS in Python, and
> ditching scripting capability in the packages. I'm sure these seemed
> like good engineering decisions way back at the drawing b
This conversation seems to be taking a bit of a death spiral. Please
keep it polite, folks. We can, and will, take action if necessary.
--
Alan Burlison
--
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
ken mays wrote:
> > Dennis Clarke wrote:
> > As a voice from the community I see star as a
> > *need* and not just a want. It archive and extracts/packs just about
> > anything.
>
> It is a want. A 'need' if nothing else existed which didn't serve similar
> purposes.
> This goes back to the 'ne
Correct. the fix in http://cr.opensolaris.org/~vrthra/fcgid.conf/ sorted the
problem.
Chavdar Ivanov
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Joseph Mocker wrote:
> While I don't entirely agree with UNIX admin, I am sort of concerned
> with the growing number of scripting environments that are now required
> to make [Open]Solaris run.
>
> First I realized that Perl was needed was when I discovered the kstat
> was rewritten in Perl,
Hello, and thanks for your work on this issue!
I have a machine with one RTL8111C and three RTL8110SC interfaces, with these
mac_versions:
mac_ver 1006632960
mac_ver 402653184
mac_ver 402653184
hello
i am running a cluster with sol 10 and getting this issue,because of this some
of the Appln process is not coming up .
Resource: rac_framework phys-bill-1 OnlineOnline
Resource: rac_framework phys-bill-2 Start failed Degraded -
recon
It looks like there are several ways of sharing file systems and directories in
OpenSolaris. I've managed to share zfs file systems by setting the zfs
sharenfs property on, on one OpenSolaris system and also used sharemgr on
another OpenSolaris system (with the zfs sharenfs property off). Both
64 matches
Mail list logo
