Hi, Wayne,
Sorry for the late response, I missed your email :$. I just fixed the
bug that keyboard layout setting does not take effect after re-login,
and it would be included in snv_102. Thank you very much for your
contributions!!!
Regards,
W. Wayne Liauh 写道:
>> Hi, Wayne,
>>
>> Thanks for
The error msg came, because options need to go last into the cmd line:
# LD_PRELOAD=/tmp/y/a.out conary update tuxpaint --resolve
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
# LD_PRELOAD=/tmp/y/a.out conary update --resove tuxpaint
usage: conary update [+][-][=][[flavor]]* *
Update or install software on the system
options:
Update Options:
--exact-flavors Only match troves whose flavors match exactly
--from-file=FROM-FILE
search
PROBLEM SOLVED - I managed to locate the thread of July 14 (Revised
instructions for updating..) in the [b]announce[/b] forum and everything
installed without a hitch. It would have been helpful if the upgrade script
incorporated an announcement for this type of thing.
--
This message posted fro
On Thu, Oct 23, 2008 at 12:25 AM, Mike Meyer <[EMAIL PROTECTED]> wrote:
> On Thu, 23 Oct 2008 00:16:03 +0200
> "Martin Bochnig" <[EMAIL PROTECTED]> wrote:
>
>> On Wed, Oct 22, 2008 at 11:40 PM, Martin Bochnig <[EMAIL PROTECTED]> wrote:
>> > On Wed, Oct 22, 2008 at 11:28 PM, Shawn Walker <[EMAIL PRO
On Wed, Oct 22, 2008 at 11:40 PM, Martin Bochnig <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 22, 2008 at 11:28 PM, Shawn Walker <[EMAIL PROTECTED]> wrote:
>
>> I would venture to guess that a significant majority of users will never
>> need to or want to recompile or alter the software as you suggest.
On Wed, Oct 22, 2008 at 11:28 PM, Shawn Walker <[EMAIL PROTECTED]> wrote:
> I would venture to guess that a significant majority of users will never
> need to or want to recompile or alter the software as you suggest.
>
> They're going to want a stable, tested version of the software, and that
> m
Mike Meyer wrote:
> On Wed, 22 Oct 2008 11:49:36 PDT "Richard L. Hamilton" <[EMAIL PROTECTED]>
> wrote:
>
>>> I'd much rather see a ports type implementation than
>>> an rpm
>>> implementation - particularly if it includes the
>>> sources.
>> Sources available? Darn right - some of the licenses r
On Wed, 22 Oct 2008 11:49:36 PDT "Richard L. Hamilton" <[EMAIL PROTECTED]>
wrote:
> > I'd much rather see a ports type implementation than
> > an rpm
> > implementation - particularly if it includes the
> > sources.
> Sources available? Darn right - some of the licenses require that, too.
Source
> I'd much rather see a ports type implementation than
> an rpm
> implementation - particularly if it includes the
> sources.
>
> fpsm
Sources available? Darn right - some of the licenses require that, too.
Build from source as the normal method of installation? That, I think is
too slow for mo
The most likely implementation will probably be what the pkgbuild folks
are providing, which is very much like rpmbuild.
Fredrich Maney wrote:
> I'd much rather see a ports type implementation than an rpm
> implementation - particularly if it includes the sources.
>
> fpsm
>
> On Mon, Oct 20, 2
Mike Meyer wrote:
> On Mon, 20 Oct 2008 23:16:41 +0100
> Calum Benson <[EMAIL PROTECTED]> wrote:
>
>> On 19 Oct 2008, at 13:11, Duncan Paterson wrote:
>>
>>> What are the chances that this will one day rival apt for selection,
>>> frequency of updates and speed.
>> It will happen a lot quicker o
I'd much rather see a ports type implementation than an rpm
implementation - particularly if it includes the sources.
fpsm
On Mon, Oct 20, 2008 at 6:24 PM, Mike Meyer <[EMAIL PROTECTED]> wrote:
> On Mon, 20 Oct 2008 23:16:41 +0100
> Calum Benson <[EMAIL PROTECTED]> wrote:
>
>>
>> On 19 Oct 2008,
On Mon, 20 Oct 2008 23:16:41 +0100
Calum Benson <[EMAIL PROTECTED]> wrote:
>
> On 19 Oct 2008, at 13:11, Duncan Paterson wrote:
>
> > What are the chances that this will one day rival apt for selection,
> > frequency of updates and speed.
>
> It will happen a lot quicker once we have reposito
On Wed, Oct 22, 2008 at 5:33 PM, Rob Johnston <[EMAIL PROTECTED]> wrote:
> This sort of information *may* be encoded in the SMBIOS records.
> Unfortunately, the quality and completeness of SMBIOS data varies quite
> a bit from vendor to vendor.
>
> You can dump the SMBIOS records for DIMMs (if pres
Thanks, I will check this tonight when I get home.
> This sort of information *may* be encoded in the
> SMBIOS records.
> Unfortunately, the quality and completeness of SMBIOS
> data varies quite
> a bit from vendor to vendor.
>
> You can dump the SMBIOS records for DIMMs (if
> present) with
This sort of information *may* be encoded in the SMBIOS records.
Unfortunately, the quality and completeness of SMBIOS data varies quite
a bit from vendor to vendor.
You can dump the SMBIOS records for DIMMs (if present) with the
following command:
% smbios -t SMB_TYPE_MEMDEVICE
rob
Mike DeM
What does prtdiag(1M) give you in verbose mode?
On 10/22/08, Martin Bochnig <[EMAIL PROTECTED]> wrote:
> On a SPARC's OBP prompt you could check that.
> On x86 the only way to check at which freq. your bus'es and mem are
> running is the BIOS.
> But it won't tell you which modules are inside.
>
>
On a SPARC's OBP prompt you could check that.
On x86 the only way to check at which freq. your bus'es and mem are
running is the BIOS.
But it won't tell you which modules are inside.
You have to open up your chassis, I would think.
You could boot into Windows and try SiSoft Sandra, although even i
On Tue, 2008-10-21 at 05:03 -0700, Richard L. Hamilton wrote:
> As to whether one really wants to spend more money that ends up in
> the hands of the Chinese military, that's another story...
Give us a break, we are discussing about "TECHNOLOGY"
MIPS is a great architecture, way to go!!!
It does *not* create any actual distro yet. All my scripts to prepare
a root proto dir and generate an iso are still on different hdds, but
not inside the distro bulk gate yet, I lost some time with getting the
most recent svn snapshot of conary to work again.
__
> That looks approximately like what I was thinking of.
> How generic is it? Can it build e.g. Indiana as well as your
It is _extremely_ generic.
However, it's not complete.
Right now all it does is fetching and building
on
sfw
fox-gate
conary
Next to be integrated are caiman, the distro-con
> On Wed, Oct 22, 2008 at 12:36 PM, Richard L. Hamilton
> <[EMAIL PROTECTED]> wrote:
> >>Perfect. Slight suggestion (I'm trying it out
> right now with an ON build for a >bugfix I've taken
> far too long to get taken care of) -- if DNS isn't
> going to be >used, could at least /etc/host entries
>
Is there any way to tell what speed memory is installed in a host.
I need to know if my DDR memory is pc3200 or pc2700
Thanks
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
> To checkout do:
> ssh://[EMAIL PROTECTED]/hg/generic_distro_bulk
> password is: "OpenSolarisIsGreat"
> (both for pull and push access!)
>
Correction, I forgot to add "hg clone" to it after I did the
copy&&paste, the correct command is of course:
To checkout do:
hg clone ssh://[EMAIL PROTECTE
On Wed, Oct 22, 2008 at 1:06 PM, Martin Bochnig <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 22, 2008 at 12:36 PM, Richard L. Hamilton <[EMAIL PROTECTED]>
> wrote:
>>>Perfect. Slight suggestion (I'm trying it out right now with an ON build
>>>for a >bugfix I've taken far too long to get taken care o
On Wed, Oct 22, 2008 at 12:36 PM, Richard L. Hamilton <[EMAIL PROTECTED]> wrote:
>>Perfect. Slight suggestion (I'm trying it out right now with an ON build for
>>a >bugfix I've taken far too long to get taken care of) -- if DNS isn't going
>>to be >used, could at least /etc/host entries be enter
>Perfect. Slight suggestion (I'm trying it out right now with an ON build for
>a >bugfix I've taken far too long to get taken care of) -- if DNS isn't going
>to be >used, could at least /etc/host entries be entered for certain
>opensolaris servers >(at least hg.opensolaris.org)? Since many proj
Thanks a lot!
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Hi Davide,
Dynamic Reconfiguration (DR) is a hardware+software feature of midrange
and high-end SPARC systems and so it is available on SPARC only.
With DR you can add or remove to a domain a physical board (4 CPUs with
memory) on E3800-E25Ks or even a single CPU (with memory) on a M-series
sy
Hi all! I'm a newbie of OpenSolaris world and I'm trying to understand how
resource allocation mechanism works. In particular I didn't understand what's
the difference between dynamic reconfiguration (DR) and dynamic resource pool
mechanism? Do they work only on SPARC architectures?
Thanks!
Best
[EMAIL PROTECTED] pisze:
>>If I'll upgrade the pool under my new BE, then I'm not able to boot
>>my laptop using old BE, because it doesn't support new version of ZFS.
>>Am I right?
>>
> If the old BE doesn't support the new ZFS version, then indeed you can't
> boot.
Hi,
Thanks a lot for the con
32 matches
Mail list logo
