Re: [osol-discuss] Do we even need a reference OpenSolaris binary distro
Francois Saint-Jacques [EMAIL PROTECTED] wrote: Beforing getting in the package management/installation stuff, I think we need to solve a big problem here: ON build. The current build process is really monolithic and unfriendly for new commers. What is all that 'nightly' and 'bldenv' stuff? Have you considered seperating in packages and give the freedom to build what ever you want (kernel, libc, base utils) like GNU tools? By following this method, you give more freedom to external distribution. This is the wrong way to go. ON is not even complete. Why do you believe are flagdays needed? This is a result of inconsistences in ON because it is incomplete, you need a build machine that is very similar to the just crerated ON release. This is not Linux but UNIX and if you like to compare, look at *BSD. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: What's the best TERM setting when working remotely from a Linux system?
UNIX admin wrote: You like the tab feature of GNOME terminal? It's a shame that GNOME terminal is slow and buggy. Odd, it appears to be neither on my systems. The problem is actutely exhibited when huge amounts of output ser sent to the terminal at very high speeds. The thing starts croaking and choking, it is ultra annoying. xterm, being the oldskool piece of code, has no such problems. It's a speed demon. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: What's the best TERM setting when working remotely from a Linux system?
UNIX admin wrote: You like the tab feature of GNOME terminal? It's a shame that GNOME terminal is slow and buggy. Odd, it appears to be neither on my systems. The problem is actutely exhibited when huge amounts of output ser sent to the terminal at very hig h speeds. The thing starts croaking and choking, it is ultra annoying. xterm, being the oldskool piece of code, has no such problems. It's a speed demon. And at those times it pretends to be fast it just doesn't show all the output. Particularly annoying is trying to run GNOME terminal remotely; even over 8Mbit ADSL it is *slow*. Xterm doesn't even blink. It's abysmal code. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: SXCE Build 65 available
And since you ENVISION Solaris to be an enterprise OS and Sun should pay its engineers to focus things more IMPORTANT, why do you have gripes with garbled date format string in JDS running in zh_CN locale? Ivan. Sorry I didn't mean to ignore your question. There is a long story. To make it short, Honolulu city councilman Rod Tam, who chairs the business committee, and I have been running a project (both on pro bono basis) to try to establish Hawaii as a Linux-related business/culture center serving the Asia-Pacific region. We believe the unique multi-cultural feature of Hawaii, our geographic location, as well as the Chinese American ethnicity of both of us, should give us an advantage. As part of our effort we have set up a Linux demo in case any foreign (mainly from China) dignatory shows an interest. It turned out that no one (zero) from China is interested in Linux (I promise I will get to this subject at a later time). Last year, I began putting together an OpenSolaris demo. As I mentioned in a separate post, I seemed to be able to attract their attention. I have also tried to do a show and tell whenever I am in China and/or Taiwan. Garbled date format string in JDS running in zh_CN locale of course has no effect on how jobs get done. But for the purpose of doing demonstrations, it will prohibitively put our city ( Sun) in shame. It is unimportant from an engineer's point of view, but critically important from ours. Silly as it sounds, that's the way life is. As of Build 65, this garbled date format string problem in Chinese locales has been solved. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: What's the best TERM setting when working remotely from a Linux system?
UNIX admin wrote: UNIX admin wrote: You like the tab feature of GNOME terminal? It's a shame that GNOME terminal is slow and buggy. Odd, it appears to be neither on my systems. The problem is actutely exhibited when huge amounts of output ser sent to the terminal at very high speeds. The thing starts croaking and choking, it is ultra annoying. Ah, well that's why I don't see the problem, I don't send huge amounts of data to a terminal at high speed! Ian ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Do we even need a reference OpenSolaris binary distro
Francois Saint-Jacques wrote: On Tue, Jun 05, 2007 at 09:35:33AM -0400, Brian Gupta wrote: One of the goals of Indiana is also to be able to boot and install from a mini cd rom image, that pulls things from the network. I have been thinking that the best option would be to include templates in the installation procedure that could pull down different packages sets depending on what kind of distro you want. e.g - Indiana, minimum, Reference. What do you guys thing? -Brian On 6/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Beforing getting in the package management/installation stuff, I think we need to solve a big problem here: ON build. The current build process is really monolithic and unfriendly for new commers. What is all that 'nightly' and 'bldenv' stuff? Have you considered seperating in packages and give the freedom to build what ever you want (kernel, libc, base utils) like GNU tools? By following this method, you give more freedom to external distribution. It is possible to do partial builds even today. nightly will build the whole thing. bldenv will start a new shell with the environment vars setup properly. Now in this shell you can only build libc by doing: cd usr/src/lib/libc; make Build kernel via: cd usr/src/uts; make The thing that is missing is a make menuconfig like stuff that can allow one to build a reduced set of kernel components or a reduced features kernel. Currently all kernel components are built. Regards, Moinak. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Do we even need a reference OpenSolaris binary distro
Moinak Ghosh writes: The thing that is missing is a make menuconfig like stuff that can allow one to build a reduced set of kernel components or a reduced features kernel. Currently all kernel components are built. Ugh. Please, let's not go the way of the sort of #ifdef madness that tragically afflicts other platforms. Modularity in the the Solaris kernel is achieved by creating separate loadable modules. So long as you understand what those modules do and how they relate to each other, you can build and change subsets of them to alter your system as you choose. I don't agree that 'make menuconfig' would be a good thing. It's a maintenance and testing nightmare. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Do we even need a reference OpenSolaris binary distro
On Wed, Jun 06, 2007 at 08:08:16AM +0200, Joerg Schilling wrote: Francois Saint-Jacques [EMAIL PROTECTED] wrote: Beforing getting in the package management/installation stuff, I think we need to solve a big problem here: ON build. The current build process is really monolithic and unfriendly for new commers. What is all that 'nightly' and 'bldenv' stuff? Have you considered seperating in packages and give the freedom to build what ever you want (kernel, libc, base utils) like GNU tools? By following this method, you give more freedom to external distribution. This is the wrong way to go. ON is not even complete. Why do you believe are flagdays needed? This is a result of inconsistences in ON because it is incomplete, you need a build machine that is very similar to the just crerated ON release. This is not Linux but UNIX and if you like to compare, look at *BSD. Reposting due to bad from: I've runned OpenBSD and FreeBSD for many years, I know the difference between the base system and ports/packages. My point is: neither OpenBSD, FreeBSD, NetBSD provides a decent way to upgrade the core system AND packages at the same time. I love *BSD, but I'm not running it on production server simply because you can't upgrade it quickly. On the other site, if the packaging system is also aware of the base system and packages. That's all I request :) PS: It seems I didn't read the build process correctly. Ordinary SVR4 packages can be built from the files installed into the proto area (see section 4.4.1). This is done automatically by the main makefile's all and pkg_all targets (see usr/src/Makefile) as part of a successful build. So if we could build something around 'pkgbootstrap' which could build a working system only from packages, that would be a good step. -- Francois Saint-Jacques http://www.networkdump.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Unable To Install DBI::mysql on Solaris 10
Thanks for your replies
I am still having trouble with this. Here is what I have done
Downloaded and installed perl / mysql / gcc / make and associated support
packages from sunfreeware.com.
These all install into /usr/local
I have set up ${PATH} as follows :-
[b] /usr/local/bin:/usr/local/mysql/bin/:/usr/sbin:/usr/bin:/usr/ccs/bin[/b]
And ${LD_LIBRARY_PATH} as :-
[b]/usr/local/mysql/lib/mysql/:/usr/local/lib[/b]
I can make the DBD:mysql with no errors but all tests fail!
When using force directive to instal DBD:mysql and executing a test script I
get a Segmentation Fault (core) when it atempts to connect to the database.
Bellow is some output from make test with a debug of 12 set :-
export DBI_TRACE=12
[b]# make test[/b]
PERL_DL_NONLAZY=1 /usr/local/bin/perl -MExtUtils::Command::MM -e
test_harness(0, 'blib/lib', 'blib/arch') t/*.t
t/00base.DBI 1.56-nothread default trace level set to 0x0/12
(pid 561) at DBI.pm line 271 via 00base.t line 28
install_method DBI::db::get_info, flags 0x2a00,
usage: min 2, max 2, '$info_type'
install_method DBI::db::take_imp_data, flags 0x1,
usage: min 1, max 1, ''
install_method DBI::db::disconnect , flags 0x10c00,
usage: min 1, max 1, ''
install_method DBI::db::selectrow_array, flags 0x2000,
usage: min 2, max 0, '$statement [, \%attr [, @bind_params ] ]'
install_method DBI::db::tables , flags 0x2200,
usage: min 1, max 6, '$catalog, $schema, $table, $type [, \%attr ]'
install_method DBI::db::quote_identifier, flags 0x0430,
usage: min 2, max 6, '$name [, ...] [, \%attr ]'
install_method DBI::db::clone ,
usage: min 1, max 2, '[\%attr]'
install_method DBI::db::quote , flags 0x0430,
usage: min 2, max 3, '$string [, $data_type ]'
install_method DBI::db::type_info , flags 0x2200,
usage: min 1, max 2, '$data_type'
install_method DBI::db::statistics_info, flags 0xaa00,
usage: min 6, max 7, '$catalog, $schema, $table, $unique_only, $quick, [,
\%attr ]'
install_method DBI::db::selectrow_arrayref, flags 0x2000,
usage: min 2, max 0, '$statement [, \%attr [, @bind_params ] ]'
install_method DBI::db::begin_work , flags 0x0400,
usage: min 1, max 2, '[ \%attr ]'
install_method DBI::db::last_insert_id, flags 0x2800,
usage: min 5, max 6, '$catalog, $schema, $table_name, $field_name [, \%attr
]'
install_method DBI::db::foreign_key_info, flags 0xaa00,
usage: min 7, max 8, '$pk_catalog, $pk_schema, $pk_table, $fk_catalog,
$fk_schema, $fk_table [, \%attr ]'
install_method DBI::db::primary_key , flags 0x2200,
usage: min 4, max 5, '$catalog, $schema, $table [, \%attr ]'
install_method DBI::db::commit , flags 0x0c80,
usage: min 1, max 1, ''
install_method DBI::db::ping, flags 0x0404,
usage: min 1, max 1, ''
install_method DBI::db::selectall_arrayref, flags 0x2000,
usage: min 2, max 0, '$statement [, \%attr [, @bind_params ] ]'
install_method DBI::db::type_info_all, flags 0x2a00,
usage: min 1, max 1, ''
install_method DBI::db::do , flags 0x3200,
usage: min 2, max 0, '$statement [, \%attr [, @bind_params ] ]'
install_method DBI::db::selectcol_arrayref, flags 0x2000,
usage: min 2, max 0, '$statement [, \%attr [, @bind_params ] ]'
install_method DBI::db::prepare_cached, flags 0xa200,
usage: min 2, max 4, '$statement [, \%attr [, $if_active ] ]'
install_method DBI::db::rows, flags 0x0004
install_method DBI::db::rollback, flags 0x0c80,
usage: min 1, max 1, ''
install_method DBI::db::column_info , flags 0xaa00,
usage: min 5, max 6, '$catalog, $schema, $table, $column [, \%attr ]'
install_method DBI::db::table_info , flags 0xaa00,
usage: min 1, max 6, '$catalog, $schema, $table, $type [, \%attr ]'
install_method DBI::db::primary_key_info, flags 0xaa00,
usage: min 4, max 5, '$catalog, $schema, $table [, \%attr ]'
install_method DBI::db::prepare , flags 0xa200,
usage: min 2, max 3, '$statement [, \%attr]'
install_method DBI::db::preparse
install_method DBI::db::connected , flags 0x0004,
usage: min 1, max 0, ''
install_method DBI::db::data_sources, flags 0x0200,
usage: min 1, max 2, '[\%attr]'
install_method DBI::db::selectall_hashref, flags 0x2000,
usage: min 3, max 0, '$statement, $keyfield [, \%attr [, @bind_params ] ]'
install_method DBI::db::selectrow_hashref, flags 0x2000,
usage: min 2, max 0, '$statement [, \%attr [, @bind_params ] ]'
install_method DBI::dr::default_user,
usage: min 3, max 4, '$user, $pass [, \%attr]'
install_method DBI::dr::data_sources, flags 0x0800,
usage: min 1, max 2, '[\%attr]'
install_method DBI::dr::disconnect_all, flags 0x0800,
usage: min 1, max 1, ''
install_method DBI::dr::connect_cached, flags 0x8000, H 3,
usage: min 1, max 5, '[$db [,$user [,$passwd [,\%attr'
install_method DBI::dr::connect , flags 0x8000, H 3,
usage: min 1, max 5, '[$db [,$user [,$passwd [,\%attr'
install_method DBI::st::more_results,
usage: min
Re: [osol-discuss] Do we even need a reference OpenSolaris binary distro
James Carlson wrote: Moinak Ghosh writes: The thing that is missing is a make menuconfig like stuff that can allow one to build a reduced set of kernel components or a reduced features kernel. Currently all kernel components are built. Ugh. Please, let's not go the way of the sort of #ifdef madness that tragically afflicts other platforms. Modularity in the the Solaris kernel is achieved by creating separate loadable modules. So long as you understand what those modules do and how they relate to each other, you can build and change subsets of them to alter your system as you choose. I don't agree that 'make menuconfig' would be a good thing. It's a maintenance and testing nightmare. Okay. But to have OpenSolaris on appliances and constrained platforms it will require the ability to build a kernel with a reduced set of features. Leaving out individual modules can be done but only till a point. Regards, Moinak. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Unable To Install DBI::mysql on Solaris 10
[b]Update :--[/b]
I thought I'd try to statically link the DBD::mysql module.
Not sure if this is the correct way to do this but heres what happened :-
[b]# perl Makefile.pl[/b]
Edited Makefile and changed LINKTYPE from dynamic to static
[b]#make
# make test_static[/b]
rm -f blib/arch/auto/DBD/mysql/mysql.so
LD_RUN_PATH=/usr/local/lib:/usr/lib:/usr/local/ssl/lib /usr/local/bin/perl
myld gcc -G -L/usr/local/lib dbdimp.o mysql.o -o
blib/arch/auto/DBD/mysql/mysql.so \
-L/usr/local/lib -R/usr/local/lib -R/usr/lib -L/usr/lib
-R/usr/openwin/lib -L/usr/openwin/lib -L/usr/local/ssl/lib -R/usr/local/ssl/lib
-L/usr/X11R6/lib -R/usr/X11R6/lib -L/usr/local/mysql/lib/mysql -lmysqlclient
-lz -lposix4 -lresolv -lgen -lsocket -lnsl -lm -L/usr/local/ssl/lib -lssl
-lcrypto \
chmod 755 blib/arch/auto/DBD/mysql/mysql.so
make -f Makefile.aperl perl
make[1]: Entering directory `/.cpan/build/DBD-mysql-4.004-GwLB5D'
make[1]: `perl' is up to date.
make[1]: Leaving directory `/.cpan/build/DBD-mysql-4.004-GwLB5D'
PERL_DL_NONLAZY=1 ./perl -MExtUtils::Command::MM -e test_harness(0,
'blib/lib', 'blib/arch') t/*.t
t/00base.ok
t/10connect..ok
t/20createdrop...ok
t/30insertfetch..ok
t/35limitok
t/35prepare..ok
t/40bindparamok
t/40bindparam2...ok
t/40blobsok
t/40catalog..ok
16/77 skipped: various reasons
t/40listfields...ok
t/40nullsok
t/40numrows..ok
t/41bindparamok
t/41blobs_prepareok
t/42bindparamok
t/50chopblanks...ok
t/50commit...ok
14/30 skipped: various reasons
t/60leaksskipped
all skipped: $ENV{SLOW_TESTS} is not set
t/70takeimp..skipped
all skipped: test feature not implemented
t/75supported_sqlok
t/80procsok
t/insertid...ok
t/multi_statementok
t/param_values...ok
t/prepare_noerrorok
t/texecute...ok
t/utf8...ok
All tests successful, 2 tests and 30 subtests skipped.
Files=28, Tests=578, 4 wallclock secs ( 2.19 cusr + 0.40 csys = 2.59 CPU)
So what the hell is going wrong?
I guess it points to dynamic libraries being the issue so if so is this a
Solaris 10 issue?
Any help appreciated !!
SRG
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Do we even need a reference OpenSolaris binary distro
Francois Saint-Jacques wrote: On Tue, Jun 05, 2007 at 07:09:06PM -0700, [EMAIL PROTECTED] wrote: ... If I want to build just a specific kernel module, I cd to usr/src/uts/intel/ip (for example, to build just ip) and type make all in that directory. Similarly I can do a make in various other directories for libraries, binaries, etc. However it isn't safe to build just in one place until after you've done a complete build as there may be dependencies, etc. At least one short cut required if you wan to try building just a small part is to do a make install_h in usr/src. Being able to do make in usr/src and have that invoke nightly or whatever would be nice. My point is: neither OpenBSD, FreeBSD, NetBSD provides a decent way to upgrade the core system AND packages at the same time. I love *BSD, but I'm not running it on production server simply because you can't upgrade it quickly. On the other site, if the packaging system is also aware of the base system and packages. That's all I request :) The point is you're not meant to upgrade both at the same time. And I thought that was the flexibility being sought :) Through various compatibility options, you are meant to be able to upgrade the kernel and base OS independant of the packages/ports. For ports/packages, updating the relevant tree is required, along with a make deinstall; make install, to do an upgrade. Darren ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Do we even need a reference OpenSolaris binary distro
Joerg Schilling wrote: Francois Saint-Jacques [EMAIL PROTECTED] wrote: Beforing getting in the package management/installation stuff, I think we need to solve a big problem here: ON build. The current build process is really monolithic and unfriendly for new commers. What is all that 'nightly' and 'bldenv' stuff? Have you considered seperating in packages and give the freedom to build what ever you want (kernel, libc, base utils) like GNU tools? By following this method, you give more freedom to external distribution. This is the wrong way to go. ON is not even complete. Why do you believe are flagdays needed? This is a result of inconsistences in ON because it is incomplete, you need a build machine that is very similar to the just crerated ON release. This is not Linux but UNIX and if you like to compare, look at *BSD. *BSD have flag days for similar reasons to Solaris - when you change (for example) the major number of libc, chances are things will care about this. Darren ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Do we even need a reference OpenSolaris binary distro
On Wed, 2007-06-06 at 16:36 +0530, Moinak Ghosh wrote: Francois Saint-Jacques wrote: On Tue, Jun 05, 2007 at 09:35:33AM -0400, Brian Gupta wrote: One of the goals of Indiana is also to be able to boot and install from a mini cd rom image, that pulls things from the network. I have been thinking that the best option would be to include templates in the installation procedure that could pull down different packages sets depending on what kind of distro you want. e.g - Indiana, minimum, Reference. What do you guys thing? -Brian On 6/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Beforing getting in the package management/installation stuff, I think we need to solve a big problem here: ON build. The current build process is really monolithic and unfriendly for new commers. What is all that 'nightly' and 'bldenv' stuff? Have you considered seperating in packages and give the freedom to build what ever you want (kernel, libc, base utils) like GNU tools? By following this method, you give more freedom to external distribution. It is possible to do partial builds even today. nightly will build the whole thing. bldenv will start a new shell with the environment vars setup properly. Now in this shell you can only build libc by doing: cd usr/src/lib/libc; make Build kernel via: cd usr/src/uts; make The thing that is missing is a make menuconfig like stuff that can allow one to build a reduced set of kernel components or a reduced features kernel. Please don't do that... Usually feature like this heavily depends on macros within the kernel and changes its structuring. As the result Linux kernels suffers from beign incompatible even within the same minor release just because vendors jumping on this feature and building their variants with modified .config files. As far as Embedded OpenSolaris is concerned (if any), in my opinion it should just single option in bld-env which strips down existing components and produces reduced fat proto. Currently all kernel components are built. Regards, Moinak. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Unable To Install DBI::mysql on Solaris 10
So what the hell is going wrong? PEBKAC problem? (:-) I guess it points to dynamic libraries being the issue so if so is this a Solaris 10 issue? Having compiled tons and tons of software on Solaris, I seriously doubt it's a Solaris 10 issue. What I can tell you is that compiling, linking and packaging correctly is not only a science, it's an art. I'd say your compiling environment is not set up properly. If it were me I could probably figure out what the issue is, but as it is it's hard to figure out what is going wrong in your environment (at least for me, I'm a hands on guy). Anyways, what I can see are a few things I would never do: - /usr/local/bin: NEVER (it's against System V, and it won't work for sparse zones anyway) - sunfreeware.com / Steve Christensen: the good Mr. Christensen can't build a proper, System V compliant and clean package to save his life: NEVER Pity the tremendous amount of time he invested in it. Some people just don't have what it takes. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Unable To Install DBI::mysql on Solaris 10
I am still having trouble with this. Here is what I
have done
Downloaded and installed perl / mysql / gcc / make
Do yourself a favor, get Sun Studio compilers. They're gratis, generate up to
80% faster code, support Solaris (i86pc and sparc) and Linux, and have
optimization capabilities GCC can't even touch.
And ${LD_LIBRARY_PATH} as :-
[b]/usr/local/mysql/lib/mysql/:/usr/local/lib[/b]
OK, as soon as you have to resort to setting LD_LIBRARY_PATH, you know you've
got trouble.
Setting LD_LIBRARY_PATH is a major hack, and what it means is that the stuff
hasn't been linked properly to begin with.
Instead of setting LD_LIBRARY_PATH, you'll have to set -R/path/to/lib along
with -L/path/to/lib in CFLAGS and CXXFLAGS variables.
If that doesn't work, then the build system is a brain dead hack. If that's the
case, you've basically have two options:
a) try to fix the build system
b) ditch the whole thing, it's a hack, and such things are usually not worth
one's time.
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Do we even need a reference OpenSolaris binary distro
*BSD have flag days for similar reasons to Solaris - when you change (for example) the major number of libc, chances are things will care about this. We do not have such flag days in Solaris. We only have build environment flag days because ON is not self-contained. The flag days are typically of the form: - As of today - you should be using compiler X - you should have libz version = A - you should have libxml version = B - you should have Java version = C - you should have GNOME version = D Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] change all permissions
Hello! Where is a posting for a newbies? I'm sorry! Please anybode say me howto I got to replase all of perm in my Nexenta? in /dev /devices and others!? Only need it! Any is possible modes?... This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: change all permissions
Hello! Where is a posting for a newbies? I'm sorry! Please anybode say me howto I got to replase all of perm in my Nexenta? in /dev /devices and others!? Only need it! Any is possible modes?... You should not modify permissions of files in /dev/ and /devices/. What is it that you actually want to do? And more OpenSolaris don't working with SerialATA! It's problem! Why? SATA is actuality now ago! Solaris does work with SATA. I've built quite a few servers of my own with SATA in them and installed Solaris on them and it just worked. Not only did SATA work, SATA-II drives on Solaris are speed demons. I managed to peak them out at ~75MB/s, and considering Solaris was running in PATA emulation mode, that's some impressive I/O Solaris was pushing out of SATA-II drives. Do you have a non-onboard SATA controller in your system? But more I have IDE and SATA is starting as RAID mode stripping as separately! It's possible with nForce4 chipset! Any one volume of disks may be created as stripping array! ;) There is no need for that if you are running Solaris: ZFS has made all of that hardware RAID stuff obsolete. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: change all permissions
Thanks! I don't know about this link! Cool! This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: isainfo on PPC
Workaround: Use isainfo -k, I usually do this, i.e. here: You have to consider that to be truly clean, a package must be a pure relocatable package. What does that mean? For example, it means that ISA one is installing from is not the same as the target ISA. Consider the scenario where the AutoClient or Diskless client server is a 32-bit i86pc Solaris system, and the target system the package is being installed on is a 64-bit sparc system: you perform pkgadd -R/export/client7879/ ABCDblabla which says to install the package ABCDblabla under a different root (/export/client7879/) `isainfo -k` will return i386 in the postinstall phase, but the target system is a 64-bit sparc platform system. The whole thing will fall on the nose and create a wrong directory structure, /export/client7879/opt/abcd/lib/64 - amd64 instead of /export/client7879/opt/abcd/lib/64 - sparcv9, which would have been the correct thing to do. There must be another way. That's why I wrote earlier: creating clean and correct packages is an art. There are so many factors to consider. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: change all permissions
You should configure all your disks to be visible as individual drives - no RAID, then you stand a chance of Solaris seeing the drives. I think troubles with sata don't with raid... raid work correctly but it's only different theme... I have work with nonstandart raid mode ;) I'ts possible with nForce chip! I create raid set for only one HDD!! Without HDD+HDD! I'st possible! I don't know how its realy work... With it no any problems, all of systems correctly starts on This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: isainfo on PPC
THere is none and even the uname(1) fields are
unreliable if
you compare different platforms.
Yes, that is a problem I ran into seven years ago when I was trying to design a
central NFS server that would store software for different operating systems
and different architectures (IRIX, IRIX64, HP-UX 10.20 hppa, HP-UX 11.x ia64
and hppa, Solaris 7 / 8 i86pc and sparc...)
Basically there was no way to reconcile and consistently use `uname` to
configure the AutoMounter maps to cover all the OSes on all platforms and all
revisions correctly.
This is something that makes it hard to write a
platform independent
makefilesystem like the Schily makefiles.
I came up with a solution, although I must write that I'm not particularly
proud of it:
Arch=`pkgparam ${PKGINST} -v ARCH`
the above extracts the target system ARCH and derives a predetermined mapping
value (sparc - sparcv9, i386 - amd64, ppc - ppc64) using a `case $Arch in
...` statement.
If someone sees any problems with this approach, or knows or can think of a
better way, now's the time to come forth.
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
[osol-discuss] Re: change all permissions
What is it that you actually want to do? Permissions must be cheinged[i]![/i] :) What reason don't accessed by root? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: change all permissions
I think troubles with sata don't with raid... raid work correctly but it's only different theme... It completely irrelevant whether the hardware RAID works correctly or not. The reason why Solaris doesn't see the SATA drives is because the SATA driver for that RAID is not available. Whether that's just the case for Nexenta or Solaris is general I don't know, but the point is, the kernel doesn't have a driver which would talk to that HW RAID subsystem. That's why you don't see any of your SATA drives. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: change all permissions
What is it that you actually want to do? Permissions must be cheinged[i]![/i] :) What reason don't accessed by root? I wish full access to my system! I still don't understand. Which permissions must be changed? Have you somehow damaged the system, or do you mean you want to log in as root and can't? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: change all permissions
The nForce4 is not hardware RAID. The RAID is performed in software by the controller's BIOS, then by a driver loaded into the operating system once booted. Cheers Andrew. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] b65 and multibooting
I ran into an issue with trying to install b65 onto a previously partitioned disk on an IBM stinkpad. The disk had three partitions: Solaris2 (b64a), Linux (Ubuntu 7) and Linux swap. I installed Ubuntu first, letting it overwrite the MBR with its GRUB and then proceeded to boot the b65 DVD. When I got to the point in the installer (GUI/Custom/Fresh install) where it asks me for disk information, the installer complained that there was in error in reading the disk table (or something like that) and it said that I needed to use the entire disk for Solaris, trashing the other partitions (I clicked on the Back button before committing that). Why? I've never seen this type of behavior before from Solaris. It has always respected other operating systems on my machines, including a Sun Ultra 20 where I run three OSs: Solaris 10, Windows XP 64 and RedHat 4. I retried using the upgrade install option and that seems to be working (still working on the as of right now). Although, it never asked me for disk information, so I'm hoping that it didn't trash the Linux partitions. It's not a big deal if it did, except I don't want to get into an infinite installation loop. I'll know in a bit if that is the case or not. Anybody have any ideas? thanks, -john ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal: Open Sound System
Dev Mazumdar wrote: The rumors are true, we're planning on open sourcing Open Sound +1! Adding icing to this cake is that Dev has been actively working with several of us getting things ready for an OpenSolaris ARC review of OSS as part of their initial code contribution! Of course, this means that we in the ARC community are going to have to figure out the logistics of making this happen - the OGB discussion about ARC reviews seems timely indeed! Welcome aboard Dev!!! -John ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Perl 6 on snv_55b x86
Interestingly, I saw someone have the exact same error messages while trying to link Oracle on a reasonably recent Nevada build (might want to check in database-discuss for details). Don't know if there is a connection, but just seems a bit odd. On 6/5/07, Rod Evans [EMAIL PROTECTED] wrote: Stefan Parvu wrote: ld: fatal: symbol `s44W_info' in file /export/home/sparvu/ghc/lib/ghc- 6.6.1/libHSCabal.a(Utils__90.o): \ section [1] .text: size 1042: symbol (address 0x400, size 20) lies outside of containing section ... Anyone any ideas ? Is this a GNU ld / Sun ld issue ? The error is from Sun ld(1). We check to insure a symbol is really encapsulated by a backing section. In the above, the symbol s44W_info is associated to section .text. The .text section is size 1042 (0x412), but the symbol claims to start at 0x400, and is size 20 (0x14). In other words, the symbol extends past the end of the enclosed section. The elements within libHSCabal.a look a little suspicious. I'd to and discover how the objects within libHSCabal.a were built. If you were to elfdump(1) the archive object, I think you'll discover the same error. -- Rod ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Do we even need a reference OpenSolaris binary distro
On Tue, Jun 05, 2007 at 07:09:06PM -0700, [EMAIL PROTECTED] wrote: As monolithic as it may be, when you're building an entire platform, something of that nature is required to deliver it all. While it may be an unfamiliar task to Linux folks, it isn't to those from the BSD world. Similar commands exist for FreeBSD - make buildworld - and NetBSD make build - that build the entire operating system, kernel, commands, man pages, etc. However unlike Solaris, on both of those BSD platforms there is no extra special bits required. I've runned OpenBSD and FreeBSD for many years, I know the difference between the base system and ports/packages. If I want to build just a specific kernel module, I cd to usr/src/uts/intel/ip (for example, to build just ip) and type make all in that directory. Similarly I can do a make in various other directories for libraries, binaries, etc. However it isn't safe to build just in one place until after you've done a complete build as there may be dependencies, etc. At least one short cut required if you wan to try building just a small part is to do a make install_h in usr/src. Being able to do make in usr/src and have that invoke nightly or whatever would be nice. My point is: neither OpenBSD, FreeBSD, NetBSD provides a decent way to upgrade the core system AND packages at the same time. I love *BSD, but I'm not running it on production server simply because you can't upgrade it quickly. On the other site, if the packaging system is also aware of the base system and packages. That's all I request :) PS: It seems I didn't read the build process correctly. Ordinary SVR4 packages can be built from the files installed into the proto area (see section 4.4.1). This is done automatically by the main makefile's all and pkg_all targets (see usr/src/Makefile) as part of a successful build. -- Francois Saint-Jacques http://www.networkdump.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Perl 6 on snv_55b x86
Hi, The error is from Sun ld(1). We check to insure a symbol is really encapsulated by a backing section. right. Im wonder to try this in S10, not in Nevada to see the results. In the above, the symbol s44W_info is associated to section .text. The .text section is size 1042 (0x412), but the symbol claims to start at 0x400, and is size 20 (0x14). In other words, the symbol extends past the end of the enclosed section. The elements within libHSCabal.a look a little suspicious. I'd to and discover how the objects within libHSCabal.a were built. If you were to elfdump(1) the archive object, I think you'll discover the same error. the result after elfdump: http://www.nbl.fi/~nbl97/elfdump.libHSCabal.a.out.gz Any ideas what can I do ? Im wonder if I could instruct pugs to use gnu ld and see if that skips this error. So this is a problem how ghc was built in Solaris, right ? I will keep posted the maintainer of Haskell compiler for Solaris x86/sparc about it. thanks for help, Stefan ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Perl 6 on snv_55b x86
Jason King wrote: Interestingly, I saw someone have the exact same error messages while trying to link Oracle on a reasonably recent Nevada build (might want to check in database-discuss for details). Don't know if there is a connection, but just seems a bit odd. cheers, I will check the database-discuss group thanks, stefan ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Project Proposal: Open Sound System
Awesome news! I've really enjoyed the ease with which OpenSound works on my boxes. Thanks 4Front! -- richard This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: b65 and multibooting
I ran into an issue with trying to install b65 onto a previously partitioned disk on an IBM stinkpad. The disk had three partitions: Solaris2 (b64a), Linux (Ubuntu 7) and Linux swap. I installed Ubuntu first, letting it overwrite the MBR with its GRUB and then proceeded to boot the b65 DVD. snip We are multiple-booting SX65 with SuSE, WinXP, CentOS, Ubuntu 6.10, Fedora, RH, as well as with other version(s) of Solaris, never had, and never expected to have, any problem. The only exception is with Ubuntu 7.04. In fact, we are also having problems dual-booting Feisty with other Linux distros. We don't know what the problems are, or where we screwed up. You probably should go over to Ubuntu part of the world to search for a solution, or simply choose another Linux distro or move back to 6.10. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
