Re: [osol-discuss] Re: Boot CD problem
Eric Schrock wrote: Just to note that a large number of these problems relating to krtld either missing or panicking are due to bad media/hardware. You may want to investigate re-burning/re-downloading the CD images, or trying the CDs in different machines to see if the problem still happens there. - Eric initially i also thought that the media was bad so i re-burned the cd but the problem persisted on the dell laptop (latitude c800). i used the cd's to install on another machine and installation completed successfully - so i guess the media is fine ? strange problem... i also downloaded/burned solaris express 6/05 and tried installing on the dell latitude c800 - same problem :( greetings, Stoyan On Tue, Jun 28, 2005 at 01:31:02PM -0700, Derek Crudgington wrote: I'm having this same problem and I disabled USB in the BIOS and it still is the same error. I can't even get into kernel debug mode to see what is going on. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- Eric Schrock, Solaris Kernel Development. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] OpenSolaris distributions and package managment
First question is specificly to Sun's opensolaris distribution... Will it continue to be in the format of downloadable iso's with the standard release cycle or variation thereof? If yes, does this mean that a regular download of 4 ISO's are on the cards? If no, are there any internal work being done to devise a package management system to keep your desktop up to date with the latest happenings? (rpm-like for example so that 100MB's of updates could get you to a new release as opposed to 4x600MB ) I've read reports on a "gentoo-ish portage ie sortage ?" being developed for Open Solaris. This would imply that I can keep my Open Solaris up to date with patches and new program/utility fixes via a management system (like my gentoo pc). This would probably be a "gentoo open solaris" distribution ... any news? The iso download (for patches and application updates) are bandwith consuming and not friendly to countries where the DSL are not comparable with the US/EU. I would love to hear opinions on package management for opensolaris, specificly the Sun release. Cheers. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris distributions and package managment
Louwtjie Burger wrote: First question is specificly to Sun's opensolaris distribution... Will it continue to be in the format of downloadable iso's with the standard release cycle or variation thereof? This is a bit confusing, but there is no ISO distribution of OpenSolaris. You are probably thinking of the Solaris Express Community Release which comes as four ISOs. That's not OpenSolaris. The only Sun provided distribution of OpenSolaris comes only as source code (and a bunch of binaries that are still closed source). You need to Solaris Express Community Release to compile OpenSolaris. While they have some things in common, Solaris Express still is not OpenSolaris. The only OpenSolaris based binary distribution currently is Schillix. The main FAQ sort of answers this (though it and the download page should probably be a lot more explicit on this point): http://www.opensolaris.org/os/about/faq/general_faq/ -- James Lick -- 黎建溥 -- [EMAIL PROTECTED] -- http://jameslick.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: OpenSolaris distributions and package managment
Sorry James, I'll try again :) You need the Express ISO's to deploy the opensolaris source, yes. My question is, looking down the line in 3-6 months (or 12), will there be any opensolaris distro's (directly from Sun)? Will they continue with Express as the representative of the open work ...? Will Sun consider any other form of distributing Express, apart from the regular iso's ? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris distributions and package managment
On Wed, Jun 29, 2005 at 05:33:46PM +0800, James Lick wrote: > The only Sun > provided distribution of OpenSolaris comes only as source code (and a > bunch of binaries that are still closed source). You need to Solaris Not so. There is a binary "distribution" in the form of BFU archives. These archives are sufficient to install and boot a basic OpenSolaris system without the need for any underlying OS (other than needing to boot some version of Solaris to extract the BFU's). Scott ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris distributions and package managment
James Lick <[EMAIL PROTECTED]> said >>> >>>This is a bit confusing, but there is no ISO distribution of >>>OpenSolaris. Sure there is. Solaris Express and the Community Release. >>>You are probably thinking of the Solaris Express Community >>>Release which comes as four ISOs. That's not OpenSolaris. No. It's OpenSolaris and a whole lot more. Fedora, RHEL, and SuSE aren't Linux, but it would be hard to claim that they aren't Linux distributions. >>>The only Sun >>>provided distribution of OpenSolaris comes only as source code (and a >>>bunch of binaries that are still closed source). Not so. Solaris Express, and the Community release, are binary distributions based on OpenSolaris. Solaris 10 fails to qualify only as an accident in timing. And Sun provide prebuilt binary archives you can bfu. >>>You need to Solaris >>>Express Community Release to compile OpenSolaris. While they have some >>>things in common, Solaris Express still is not OpenSolaris. The only >>>OpenSolaris based binary distribution currently is Schillix. And Schillix (amazing achievement) doesn't equal OpenSolaris either. Yes, it's a binary distribution based on OpenSolaris, but it contains additional components that aren't contained in OpenSolaris. (And isn't available on Sparc either, unfortunately.) >>>The main >>>FAQ sort of answers this (though it and the download page should >>>probably be a lot more explicit on this point): >>> >>>http://www.opensolaris.org/os/about/faq/general_faq/ Actually, the faq ought to clarify that Solaris Express is a binary distribution of the OpenSolaris source and a whole lot more. For most users, far and away the easiest and safest way to run OpenSolaris binaries is to live a week or two behind the source and run Solaris Express Community Release. Building your own kernel and using the likes of bfu isn't really appropriate for most users. There is a sense of satisfaction in doing so (I know, I do it occasionally just to prove that I can), but it isn't really justifiable unless you're doing hardcore development on the innards of the kernel or building your own distribution. -Peter Tribble MRC Rosalind Franklin Centre for Genomics Research http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris distributions and package managment
On Wed, 29 Jun 2005, Peter C. Tribble wrote: James Lick <[EMAIL PROTECTED]> said This is a bit confusing, but there is no ISO distribution of OpenSolaris. Sure there is. Solaris Express and the Community Release. Btw, b17 seem to be available for downloads. Just downloaded it and I am now getting my courage to install it :-) Dragan -- Dragan Cvetkovic, To be or not to be is true. G. BooleNo it isn't. L. E. J. Brouwer ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris distributions and package managment
Hi, Others have already clarified most of this. Any package management solution that an opensolaris distribution uses will be up to that distro. I've written a little on keeping a binary distribution up to date on http://blogs.sun.com/roller/page/albertw?entry=updaing_software_in_the_open as has Eric Boutilier http://blogs.sun.com/roller/page/eric_boutilier/20050609#on_jun_6_on_comp Louwtjie Burger wrote: I would love to hear opinions on package management for opensolaris, specificly the Sun release. Well the 'Sun Release' part has been answered by others, but feel free to add thoughts on package management for distros to Eric's or my blogs. Cheers, ~Al ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] b17 copying behaviour?
On Wed, 29 Jun 2005, Dragan Cvetkovic wrote: Btw, b17 seem to be available for downloads. Just downloaded it and I am now getting my courage to install it :-) Btw, I am noticing very strange behaviour here: I am copying the image files to the install server in the usual way: 1. unzip CD1 on nv16 x86 machine, lofi mount it and export via NFS to the install server (Solaris 10 SPARC machine) 2. On the install server go to Solaris_11/Tools directory and start ./setup_install_server /export/home/jumpstart/se_nv17_i386/ and then it takes ages to copy. The funny thing is that if I truss the process, cpio works much much faster. For example: after starting truss -afe -o /dev/null -p 2079, it managed to copy some 10MB of data in one minute or so, but after killing truss, it takes 5 minutes to copy 2MB of data. What is going on here? How can I find that out? Thanks and bye, Dragan -- Dragan Cvetkovic, To be or not to be is true. G. BooleNo it isn't. L. E. J. Brouwer ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] b17 copying behaviour?
On Wed, 29 Jun 2005, Dragan Cvetkovic wrote: > after starting truss -afe -o /dev/null -p 2079, it managed to copy some > 10MB of data in one minute or so, but after killing truss, it takes 5 > minutes to copy 2MB of data. > > What is going on here? How can I find that out? This sounds like a job DTrace! [FX: sounds of feverish typing] :-) -- Rich Teer, SCNA, SCSA, OpenSolaris CAB member President, Rite Online Inc. Voice: +1 (250) 979-1638 URL: http://www.rite-group.com/rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: OpenSolaris distributions and package managment
Regarding to package mangement, pleasealso see this thead. http://opensolaris.org/jive/thread.jspa?threadID=804&tstart=0 You have choice of using Local (PMS) Package Management System or Hyper PMS. LPMS candidate for opensolaris are Portage and pkg-get. But if you want to avoid yourself to be locked in by a perticular OS(even opensoalris), you can go with Hyper PMS approach. Both LPMS and HPMS have pros and cons. tj This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] TCP SNOOP
Please let me know if you have any feedback for http://blogs.sun.com/roller/comments/raviswam/Weblog/tcp_snoop_using_dtrace This script snoops traffic at tcp level, the traffic being snooped can be filtered using the wrapper shell script provided. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
Not directed at TJ yang, rather at those whom read this thread: On 6/29/05, TJ Yang <[EMAIL PROTECTED]> wrote: > Regarding to package mangement, pleasealso see this thead. > http://opensolaris.org/jive/thread.jspa?threadID=804&tstart=0 > > You have choice of using Local (PMS) Package Management System > or Hyper PMS. LPMS candidate for opensolaris are Portage and pkg-get. Of course OpenPKG ( http://www.openpkg.org ) also serves as a viable package management system. > But if you want to avoid yourself to be locked in by a perticular OS(even > opensoalris), you can go with Hyper PMS approach. Both LPMS and HPMS have > pros and cons. OpenPKG is also cross-platform and won't lock you into a particular OS. -- Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] what do you like about using opensolaris?
Darren J Moffat <[EMAIL PROTECTED]> wrote: > On Mon, 2005-06-27 at 07:07, Joerg Schilling wrote: > > What is the difference between a general dumping ground /usr/gnu and > > /usr/sps? > > The same as the difference between /usr/sfw and /usr/xpg? today. > > /usr/xpg? is only for the things that differ between Solaris (as it > has traditionally been and needs to be due to the binary compatibility > requirements). > > /usr/sfw became a dumping ground for all things we didn't want to > put in /usr/bin. > > /usr/gnu would be like /usr/xpg/, ie just those things from the > GNU core utils, eg ls,tar,cp,mv etc. That have a clash with already > existing things in Solaris's /usr/bin. For example /usr/gnu/bin > wouldn't have star or mozilla nor would it have any of the GNOME > stuff. OK, this is an argument. But then /usr/gnu would bot contain much more than /usr/schily > My understanding of /usr/sps is that it is basically /usr/sfw, > it has all the same advantages and disadvantages that it has. Or > am I missing something and /usr/sps is different in semantics > than /usr/sfw ? As I cannot create binaries that definitely have the same behavior then the related Sun suppiled binaries, I decided to chose a different install path. 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] pthread_attr_getstack broken?
Hi Solaris developers, a little bit out of topic. But I hope to get some competent reply from this list. I'm trying to run the C# environment mono under Solaris10/x86 and have problems with the pthreads implementation. I can't state if the procedure 'pthread_attr_getstack' dosn't work, or if there are prerequisites missing. The returned values for stack address and stack size are both zero. The following lines are from the source mini-x86.c. The g_assert statement is in line 4729: > r = pthread_attr_getstack( &attr, (void**)&staddr, &stsize ); > printf( "\n r, staddr, stsize: %d %x %x\n", r, staddr, stsize); > > g_assert (staddr); Gmake aborts als follows: > gmake[7]: Leaving directory `/home/src/mono/118/mcs/jay' > gmake[6]: Leaving directory `/home/src/mono/118/mcs/jay' > gmake[6]: Entering directory `/home/src/mono/118/mcs/mcs' > gmake all-local > gmake[7]: Entering directory `/home/src/mono/118/mcs/mcs' > MONO_PATH="../class/lib/basic: $MONO_PATH" /home/src/mono/118/runtime/mono-wrapper ../class/lib/basic/mcs.exe -d:NET_1_1 -d:ONLY_1_1 -debug /target:exe /out:mcs.exe cs-parser.cs @mcs.exe.sources > > r, staddr, stsize: 0 0 0 > > ** ERROR **: file mini-x86.c: line 4729 (setup_stack): assertion failed: (staddr) > aborting... Can any one confirm that pthread_attr_getstack doesn't work yet or tell me what I have to do to make it work? -- Guenter ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: OpenSolaris distributions and package managment
Thanks guys ... and Albert. Your blog sums it up really well, ... "hometown swamped with tourists". :) This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: pthread_attr_getstack broken?
See http://docs.sun.com/app/docs/doc/816-5137/6mba5vpja?a=view - a staddr of NULL and a stsize of zero means the system defaults are being used. Also, make sure the pthread_attr_t object has been initialized properly with pthread_attr_init() before it is passed to any of the other pthread_attr_XXX() functions, and also make sure it is cleaned up after use with pthread_attr_destroy() This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: router creation using OpenSolaris
Joerg wrote: > Do you like to build something like a DSL router box > using OpenSolaris? Hm - but I am interested in changing my DLS woody-router to a schillix/OpenSolaris or a FreeBSD one. Is it possible, at the current devlopment stage, to setup a small router (firewall, NAT, [DHCP, squid, DNS]) with schillix? Thanks, T. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Help: Schillix 0.1 booted without GUI
Xirui <[EMAIL PROTECTED]> wrote: > Hmm... > > The second one sounds easier. :-) How long will it take? I can't tell. The next release will definitely not have a GUI. I am not sure about the release after the next one ;-) 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] bite-size bugs
there was a short discussion last night about bite-size bugs in the OpenSolaris User Group. I took a look, and many of these bugs already have proposed fixes. Why not just apply the fixes and get on with more interesting problems? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] bite-size bugs
On Wed, Jun 29, 2005 at 11:11:45AM -0700, Brian Y Wong wrote: > there was a short discussion last night about bite-size bugs in the > OpenSolaris User Group. I took a look, and many of these bugs already have > proposed fixes. Why not just apply the fixes and get on with more > interesting problems? The cost of making a change to Solaris is never free. Every bug, no matter how small, requires testing, codereview, and RTI approval. The amount of effort may only take a few hours (depending on the complexity of the testing needed), but it's decidedly non-zero. If we had infinite resources, then we would just go off and fix these bugs. But sadly, that is not the case. Hence the hope that community members can chip away at these easy bugs as a way of getting started. - Eric -- Eric Schrock, Solaris Kernel Development. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pthread_attr_getstack broken?
Guenter Feldmann wrote:
Hi Solaris developers,
a little bit out of topic. But I hope to get some competent reply from
this list.
I'm trying to run the C# environment mono under Solaris10/x86 and have
problems with the pthreads implementation. I can't state if the procedure
'pthread_attr_getstack' dosn't work, or if there are prerequisites
missing. The returned values for stack address and stack size are both
zero. The following lines are from the source mini-x86.c. The g_assert
statement is in line 4729:
r = pthread_attr_getstack( &attr, (void**)&staddr, &stsize );
printf( "\n r, staddr, stsize: %d %x %x\n", r, staddr, stsize);
g_assert (staddr);
Gmake aborts als follows:
gmake[7]: Leaving directory `/home/src/mono/118/mcs/jay'
gmake[6]: Leaving directory `/home/src/mono/118/mcs/jay'
gmake[6]: Entering directory `/home/src/mono/118/mcs/mcs'
gmake all-local
gmake[7]: Entering directory `/home/src/mono/118/mcs/mcs'
MONO_PATH="../class/lib/basic:
$MONO_PATH" /home/src/mono/118/runtime/mono-wrapper ../class/lib/basic/mcs.exe
-d:NET_1_1 -d:ONLY_1_1 -debug /target:exe /out:mcs.exe cs-parser.cs
@mcs.exe.sources
r, staddr, stsize: 0 0 0
** ERROR **: file mini-x86.c: line 4729 (setup_stack): assertion failed:
(staddr)
aborting...
Can any one confirm that pthread_attr_getstack doesn't work yet or tell
me what I have to do to make it work?
-- Guenter
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
From the man page:
The pthread_attr_getstack() and pthread_attr_setstack()
functions, respectively, get and set the thread creation
stack attributes stackaddr and stacksize in the attr object.
The stack attributes specify the area of storage to be used
for the created thread's stack. The base (lowest addressable
byte) of the storage is stackaddr, and the size of the
storage is stacksize bytes. The stacksize argument must be
at least {PTHREAD_STACK_MIN}. The stackaddr argument must be
aligned appropriately to be used as a stack; for example,
pthread_attr_setstack() might fail with EINVAL if (stackaddr
& 0x7) is not 0. All pages within the stack described by
stackaddr and stacksize are both readable and writable by
the thread.
What does pthread_attr_setstack return?
Here's the source:
http://cvs.opensolaris.org/source/xref/usr/src/lib/libc/port/threads/pthr_attr.c#380
- Bart
--
Bart Smaalders Solaris Kernel Solaris Software
[EMAIL PROTECTED] (650) 786-5335 MS UMPK17-301
http://blogs.sun.com/barts
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] bite-size bugs
On Jun 29, 2005, at 8:24 PM, Eric Schrock wrote: On Wed, Jun 29, 2005 at 11:11:45AM -0700, Brian Y Wong wrote: there was a short discussion last night about bite-size bugs in the OpenSolaris User Group. I took a look, and many of these bugs already have proposed fixes. Why not just apply the fixes and get on with more interesting problems? The cost of making a change to Solaris is never free. Every bug, no matter how small, requires testing, codereview, and RTI approval. The amount of effort may only take a few hours (depending on the complexity of the testing needed), but it's decidedly non-zero. If we had infinite resources, then we would just go off and fix these bugs. But sadly, that is not the case. Hence the hope that community members can chip away at these easy bugs as a way of getting started. And how will the community test those fixes in a proper way? Are the special test tools needed (yeah, I know they exist) or will 'continuous use' count as testing? Well, I'm not on the 'test list', maybe I should subscribe to that one too. J^2 You're newer too old to rock'n'roll, if you're too young to die ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] bite-size bugs
On Wed, Jun 29, 2005 at 08:48:16PM +0200, Jasse Jansson wrote: > > And how will the community test those fixes in a proper way? > > Are the special test tools needed (yeah, I know they exist) > or will 'continuous use' count as testing? > > Well, I'm not on the 'test list', maybe I should subscribe to that > one too. > The testing will be based on the scope and content of the bug. For a simple fix to a utility, it may be sufficient to simply roll your own handmade regression tests. For more complicated changes, such as those to libraries, kernel, or system interfaces, your sponsor will help you get the testing resources that you need. For the near future, this will likely involve you providing BFU archives and having your sponsor submit them to various test runs. If you're interested in how we plan to make testing more accesible, or have suggestions about what needs to be done, you should definitely subscribe to the test discussion list. - Eric -- Eric Schrock, Solaris Kernel Development. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Proposal: OpenSolaris User Group Community
Hey, guys. I'm getting a lot of calls regarding user groups, and some user groups are already starting to crop up out there -- Brazil, UK, USA, Australia, and I hear the Canadians are interested. There's also been some interest at universities, too, so this could get pretty big. Special thanks to Alan Duboff, Alan Hargreaves, Ulf Andreasson, and Simon Phipps (and I'm *sure* I'm missing some guys here, so I apologize) for initiating the groups that are already up and running. Sun doesn't have a lot of resources to support these activities directly, so why don't we leverage what they do have and create a user group community on opensolaris.org? It would be a way for the entire community to contribute ideas, connections, and resources to help focus the effort. Sun can participate in the community, of course, but it will be a community gig from the start. How about this to get going: * We open a user group community on the opensolaris site. * Sun engineering and marketing are the community leaders initially, but we'd be looking for community leaders to help share the responsibility real quick. * The user group community site will have links, descriptions, and contact info for all the user groups currently out there, and it will grow regularly and rapidly. * The user group community has its own lists, announcements, news, and blog feeds. * The page can also have initial resources for starting a user group, such as presentations that can be customized for local areas, etc. We need some feedback on what these resources would be and who could provide them ...) * Through Sun employees, we can help establish contacts for potential speakers -- sometimes this is brain dead easy; other times extremely difficult. * Speakers can also come from the community as we figure out where everyone lives and where they travel to. * Sun marketing can help provide some swag for inaugural user group meetings. * Community members may be able to provide meeting facilities, and in some instances Sun may be able to as well. We may also be able to leverage existing conference venues to meet. * Sun will announce the formation of new user groups on the main announce page, but all subsequent user group announcements would take place within the user group community itself. The purpose of this is to simply help drive traffic to the user group community initially. * Sun will encourage other groups at the company to get involved on the OpenSolaris User Group community site and in the field. * Anything else? Community leaders (initially): * Jim Grisanzio * Eric Boutilier * Sara Dornsife What do you think? Doable? Interested? If so, we'll get this set up and see what happens. Jim ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal: OpenSolaris User Group Community
Hi Jim, one suggestion: Let the User Groups be User Groups. The Community Leaders you mentioned should be mentors to the Users that step up to the responsibility to lead/manage groups. Set some requirements and empower the local guys to do their thing within the context of your guidance. We had some experience with this and can provide more feedback if you want. Examples: http://pegasos.jinak.cz/ (Czech) http://www.pegasos.org/ (Swedish) http://www.pegasos.hu/ (Hungary) http://www.pegasosforum.de/ (Germany) http://www.pegasos.pl/ (Poland) http://pegasos.vkt.lt/ (Lithuania) etc... R&B On Jun 29, 2005, at 2:17 PM, Jim Grisanzio wrote: Hey, guys. I'm getting a lot of calls regarding user groups, and some user groups are already starting to crop up out there -- Brazil, UK, USA, Australia, and I hear the Canadians are interested. There's also been some interest at universities, too, so this could get pretty big. Special thanks to Alan Duboff, Alan Hargreaves, Ulf Andreasson, and Simon Phipps (and I'm *sure* I'm missing some guys here, so I apologize) for initiating the groups that are already up and running. Sun doesn't have a lot of resources to support these activities directly, so why don't we leverage what they do have and create a user group community on opensolaris.org? It would be a way for the entire community to contribute ideas, connections, and resources to help focus the effort. Sun can participate in the community, of course, but it will be a community gig from the start. How about this to get going: * We open a user group community on the opensolaris site. * Sun engineering and marketing are the community leaders initially, but we'd be looking for community leaders to help share the responsibility real quick. * The user group community site will have links, descriptions, and contact info for all the user groups currently out there, and it will grow regularly and rapidly. * The user group community has its own lists, announcements, news, and blog feeds. * The page can also have initial resources for starting a user group, such as presentations that can be customized for local areas, etc. We need some feedback on what these resources would be and who could provide them ...) * Through Sun employees, we can help establish contacts for potential speakers -- sometimes this is brain dead easy; other times extremely difficult. * Speakers can also come from the community as we figure out where everyone lives and where they travel to. * Sun marketing can help provide some swag for inaugural user group meetings. * Community members may be able to provide meeting facilities, and in some instances Sun may be able to as well. We may also be able to leverage existing conference venues to meet. * Sun will announce the formation of new user groups on the main announce page, but all subsequent user group announcements would take place within the user group community itself. The purpose of this is to simply help drive traffic to the user group community initially. * Sun will encourage other groups at the company to get involved on the OpenSolaris User Group community site and in the field. * Anything else? Community leaders (initially): * Jim Grisanzio * Eric Boutilier * Sara Dornsife What do you think? Doable? Interested? If so, we'll get this set up and see what happens. Jim ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
Tending to be a bit of a reductionist, I can't help but throw out what I think is the #1 foundational question here. What's the best package architecture (database) standard for OpenSolaris? The canonicial choices, listed alphabetically, are: * deb * pkgsrc (implemented by pkgsrc system) * portage * rpm (implemented by the openpkg system) * solaris packaging (implemented by Sun, Blastwave, and Sunfreeware) * tww (implemented by tww system) Let me know if I've missed any; but before you do, note that this list is intended to be limited to package architecture types (i.e. package file-format/database architectures). My 2 cents: - A big strike against deb and portage (for Solaris/OpenSolaris) is that no work's been done yet. - A big strike against Solaris packaging is it's not open-source yet. - A big point in favor of Solaris packaging is compatibiltiy with commercial Solaris and Solaris Express. Of the other three others -- rpm, pkgsrc, and tww... Thoughts? Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Getting the source...
Hey, > > Okay, I know JDS hasn't been released as part of the OpenSolaris > project. However, as a Solaris user, I obviously have the right to > obtain certain parts of it because of the license they're under, such > as Metacity, etc. Where can I get the source tarballs from? Or whom do > I contact so I can get them? > > For the older GNOME 2.0, the packages told you where to get the source > when you installed, but JDS doesn't. I couldn't find them anywhere, so > I asked the engineering team, who pointed me to: > > http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=8&PartDetailId=JDS3_SLRS10_SOURCE-G-F&TransactionId=try And I'll be the first from the engineering team to say that does indeed suck heavily - apologies. We're definitely going to be better at this in the future, especially as we start creating a desktop community around JDS. I'm just cutting through some amount of red tape at the moment, but hopefully we'll see some desktop action on opensolaris.org *real soon*. In the meantime, if you can comment on potential things that a desktop community should be doing, please do - I have a few ideas myself, but I'm just wondering if they're off base compared to the expectations that people have. Glynn ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On 6/29/05, Eric Boutilier <[EMAIL PROTECTED]> wrote: > My 2 cents: > > - A big strike against deb and portage (for Solaris/OpenSolaris) is > that no work's been done yet. > > - A big strike against Solaris packaging is it's not open-source yet. > > - A big point in favor of Solaris packaging is compatibiltiy with > commercial Solaris and Solaris Express. > > Of the other three others -- rpm, pkgsrc, and tww... Thoughts? As far as I can tell from reading the documentation, TWW is a high level package management system that can't work on it's own, as it relies on the underlying operating system to have a native packaging system. Think of it as an abstract packging system layer above whatever the native one is. So, it doesn't really work for a native packaging system. That leaves OpenPKG RPM, and pkgsrc. Most of the *nix folk will probably lean more toward pkgsrc. But, as someone that's implemented an entire software deployment system based on OpenPKG, I'm heavily biased towards it. Especially since there is a rich set of portable packages already available and Solaris is an officially supported platform for the OpenPKG project. -- Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Getting the source...
On Jun 29, 2005, at 1:04 AM, Glynn Foster wrote: Hey, Okay, I know JDS hasn't been released as part of the OpenSolaris project. However, as a Solaris user, I obviously have the right to obtain certain parts of it because of the license they're under, such as Metacity, etc. Where can I get the source tarballs from? Or whom do I contact so I can get them? For the older GNOME 2.0, the packages told you where to get the source when you installed, but JDS doesn't. I couldn't find them anywhere, so I asked the engineering team, who pointed me to: http://javashoplm.sun.com/ECom/docs/Welcome.jsp? StoreId=8&PartDetailId=JDS3_SLRS10_SOURCE-G-F&TransactionId=try And I'll be the first from the engineering team to say that does indeed suck heavily - apologies. We're definitely going to be better at this in the future, especially as we start creating a desktop community around JDS. I'm just cutting through some amount of red tape at the moment, but hopefully we'll see some desktop action on opensolaris.org *real soon*. In the meantime, if you can comment on potential things that a desktop community should be doing, please do What about nagging the package community to make sure that packages/programs that is user/desktop oriented (gimp, openoffice and such) gets added to the start menu automatically ;o) J^2 You're newer too old to rock'n'roll, if you're too young to die ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On Wed, 2005-06-29 at 15:43, Eric Boutilier wrote: > - A big strike against deb and portage (for Solaris/OpenSolaris) is > that no work's been done yet. > > - A big strike against Solaris packaging is it's not open-source yet. > > - A big point in favor of Solaris packaging is compatibiltiy with > commercial Solaris and Solaris Express. > > Of the other three others -- rpm, pkgsrc, and tww... Thoughts? pkgsrc can be made to use solaris packaging via "gensolpkg" but it's not well integrated with the build makefiles. I owe the gensolpkg maintainer some patches to bring it up to speed with the recent increase in package name lengths. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal: OpenSolaris User Group Community
Raquel Velasco and Bill Buck wrote: Hi Jim, one suggestion: Let the User Groups be User Groups. The Community Leaders you mentioned should be mentors to the Users that step up to the responsibility to lead/manage groups. Set some requirements and empower the local guys to do their thing within the context of your guidance. We had some experience with this and can provide more feedback if you want. Examples: http://pegasos.jinak.cz/ (Czech) http://www.pegasos.org/ (Swedish) http://www.pegasos.hu/ (Hungary) http://www.pegasosforum.de/ (Germany) http://www.pegasos.pl/ (Poland) http://pegasos.vkt.lt/ (Lithuania) etc... R&B Thanks. I agree. I'll look at these links to see what you guys have done. The user groups community I'm proposing is simply a place for us all to meet, collaborate, pool resources, and make connections. It's just a community of communities. The individual user groups leaders will have to step up and lead or nothing will get done aside from building out a web site page. I'd like to see the OpenSolaris User Group Community become not only a place to network and quantify what's already out there but also a place to help new people get started so the entire Solaris user community has more leverage points and grows faster. Jim On Jun 29, 2005, at 2:17 PM, Jim Grisanzio wrote: Hey, guys. I'm getting a lot of calls regarding user groups, and some user groups are already starting to crop up out there -- Brazil, UK, USA, Australia, and I hear the Canadians are interested. There's also been some interest at universities, too, so this could get pretty big. Special thanks to Alan Duboff, Alan Hargreaves, Ulf Andreasson, and Simon Phipps (and I'm *sure* I'm missing some guys here, so I apologize) for initiating the groups that are already up and running. Sun doesn't have a lot of resources to support these activities directly, so why don't we leverage what they do have and create a user group community on opensolaris.org? It would be a way for the entire community to contribute ideas, connections, and resources to help focus the effort. Sun can participate in the community, of course, but it will be a community gig from the start. How about this to get going: * We open a user group community on the opensolaris site. * Sun engineering and marketing are the community leaders initially, but we'd be looking for community leaders to help share the responsibility real quick. * The user group community site will have links, descriptions, and contact info for all the user groups currently out there, and it will grow regularly and rapidly. * The user group community has its own lists, announcements, news, and blog feeds. * The page can also have initial resources for starting a user group, such as presentations that can be customized for local areas, etc. We need some feedback on what these resources would be and who could provide them ...) * Through Sun employees, we can help establish contacts for potential speakers -- sometimes this is brain dead easy; other times extremely difficult. * Speakers can also come from the community as we figure out where everyone lives and where they travel to. * Sun marketing can help provide some swag for inaugural user group meetings. * Community members may be able to provide meeting facilities, and in some instances Sun may be able to as well. We may also be able to leverage existing conference venues to meet. * Sun will announce the formation of new user groups on the main announce page, but all subsequent user group announcements would take place within the user group community itself. The purpose of this is to simply help drive traffic to the user group community initially. * Sun will encourage other groups at the company to get involved on the OpenSolaris User Group community site and in the field. * Anything else? Community leaders (initially): * Jim Grisanzio * Eric Boutilier * Sara Dornsife What do you think? Doable? Interested? If so, we'll get this set up and see what happens. Jim ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On Wed, 29 Jun 2005, Eric Boutilier wrote: > My 2 cents: > > - A big strike against deb and portage (for Solaris/OpenSolaris) is > that no work's been done yet. > > - A big strike against Solaris packaging is it's not open-source yet. > > - A big point in favor of Solaris packaging is compatibiltiy with > commercial Solaris and Solaris Express. > > Of the other three others -- rpm, pkgsrc, and tww... Thoughts? tww isn't really an option. It's a metapackage system that rides on top of your native packaging, and not really a package system as such (more apt than dpkg, in Debian terms) Also, keep in mind the big difference between something like rpm and SysV package format -- rpm manages not just the packaging, but also the building. That's not necessarily a bad thing but it makes adopting it more work since you have to base your build architecture around it. later, chris ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On Wed, Jun 29, 2005 at 02:43:27PM -0500, Eric Boutilier wrote: > Tending to be a bit of a reductionist, I can't help but throw out what > I think is the #1 foundational question here. > > What's the best package architecture (database) standard for > OpenSolaris? The canonicial choices, listed alphabetically, are: Are you talking about how binaries built from ON and other Solaris consolidations are delivered, or about a hypothetical community-led third-party application repository like portage, pkgsrc, and blastwave provide today? Certainly unification in those latter areas would be very helpful for users of OpenSolaris distributions. The packaging structure for Solaris isn't going to change, though it might be possible to add support for one or more additional packaging methods that other distributions could use. That seems like a tough sell, though - properly maintaining one set of packaging data is enough work already, and nothing stops a distribution from discarding usr/src/pkgdefs in favour of its own solution. Making the svr4 packaging tools available in source form is a high priority; assuming it's possible - a likely proposition - is there any reason that standard can't continue to be used for distribution of binary packages and tracking of dependencies among them? Some of the other formats you describe aren't packaging formats so much as build infrastructure - and if that build infrastructure could be used to produce svr4 packages, you would be able to take advantage of the packages installed on the system in your dependency calculations. Really, it seems like there are multiple questions here; to name a few: - How do distributions package the OpenSolaris components? How is this affected by the fact that Solaris is constrained to continue using the same package format? - Could the disparate community-led third-party software provisioning efforts be unified, and how? - What kind of infrastructure would be used in building such third-party software? - What kind of binary package formats should be produced, if any? - If new packages are added in existing consolidations, how should they be named? Where is the registry that prevents conflicts? - How do you prevent the situation in which multiple packages could satisfy a dependency but they have different names? Conversely, how would you prevent the existence of incompatible packages with the same names? -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!" ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal: OpenSolaris User Group Community
Jim, one thing we did in the beginning was provide a template for a website and offer hosting that linked to a common repository of resources (software, FAQs, etc.). In some cases all they did was translate the site into their native language. Here are a couple more examples of the older sites still in use: http://www.pegasos.org.ru/ (Russia) http://pegasos.amiga-klub.si/ (Slovenia) http://www.pegasos-italia.com/ (Italy) It really does help get the word out. We also supported/hosted sites around operating systems we supported. These are for MorphOS: http://developer.morphosppc.com/ http://www.morphzone.org http://www.morphos-news.de And, finally around the CPU architecture itself: http://www.ppczone.org Different strokes for different folks but all basically supporting the community and the platform with different angles all funneling into the same pot. You could draw all user groups in initially like this and then farm them out as they take legs: http://www.morphzone.org/modules/newbb_plus/ Scroll down and look how we have it broken down into languages. Again, this helps often significantly because everyone does not speak English. Or, this... http://www.ppczone.org/forums/ Scroll down and see how we break it up by functional interest and operating system - even OpenSolaris has a Forum! :-) The point is to leverage the interest of the Users/Developers. You could have a CDDL Forum, a Zone Forum, etc. Anyway, we would be happy to provide the sources for any of the sites if they could be useful as a template for any of your User Groups. PPCZone and MorphZone in particular can be modified relatively easily with the right compliment of graphic support. All the sites are well tuned and tested. R&B On Jun 29, 2005, at 3:53 PM, Jim Grisanzio wrote: Raquel Velasco and Bill Buck wrote: Hi Jim, one suggestion: Let the User Groups be User Groups. The Community Leaders you mentioned should be mentors to the Users that step up to the responsibility to lead/manage groups. Set some requirements and empower the local guys to do their thing within the context of your guidance. We had some experience with this and can provide more feedback if you want. Examples: http://pegasos.jinak.cz/ (Czech) http://www.pegasos.org/ (Swedish) http://www.pegasos.hu/ (Hungary) http://www.pegasosforum.de/ (Germany) http://www.pegasos.pl/ (Poland) http://pegasos.vkt.lt/ (Lithuania) etc... R&B Thanks. I agree. I'll look at these links to see what you guys have done. The user groups community I'm proposing is simply a place for us all to meet, collaborate, pool resources, and make connections. It's just a community of communities. The individual user groups leaders will have to step up and lead or nothing will get done aside from building out a web site page. I'd like to see the OpenSolaris User Group Community become not only a place to network and quantify what's already out there but also a place to help new people get started so the entire Solaris user community has more leverage points and grows faster. Jim On Jun 29, 2005, at 2:17 PM, Jim Grisanzio wrote: Hey, guys. I'm getting a lot of calls regarding user groups, and some user groups are already starting to crop up out there -- Brazil, UK, USA, Australia, and I hear the Canadians are interested. There's also been some interest at universities, too, so this could get pretty big. Special thanks to Alan Duboff, Alan Hargreaves, Ulf Andreasson, and Simon Phipps (and I'm *sure* I'm missing some guys here, so I apologize) for initiating the groups that are already up and running. Sun doesn't have a lot of resources to support these activities directly, so why don't we leverage what they do have and create a user group community on opensolaris.org? It would be a way for the entire community to contribute ideas, connections, and resources to help focus the effort. Sun can participate in the community, of course, but it will be a community gig from the start. How about this to get going: * We open a user group community on the opensolaris site. * Sun engineering and marketing are the community leaders initially, but we'd be looking for community leaders to help share the responsibility real quick. * The user group community site will have links, descriptions, and contact info for all the user groups currently out there, and it will grow regularly and rapidly. * The user group community has its own lists, announcements, news, and blog feeds. * The page can also have initial resources for starting a user group, such as presentations that can be customized for local areas, etc. We need some feedback on what these resources would be and who could provide them ...) * Through Sun employees, we can help establish contacts for potential speakers -- sometimes this is brain dead easy; other time
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
Previously Shawn Walker wrote: > As far as I can tell from reading the documentation, TWW is a high > level package management system that can't work on it's own, as it > relies on the underlying operating system to have a native packaging > system. Think of it as an abstract packging system layer above whatever > the native one is. So, it doesn't really work for a native packaging > system... > ... Thanks Shawn. tww should be deleted because it's not a back-end package database architecture. So the canonical list actually is this: * deb * pkgsrc (implemented by pkgsrc system) * portage * rpm (implemented by the openpkg system) * solaris packaging (implemented by Sun, Blastwave, and Sunfreeware) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On Wed, 2005-06-29 at 12:43, Eric Boutilier wrote: > Tending to be a bit of a reductionist, I can't help but throw out what > I think is the #1 foundational question here. > > What's the best package architecture (database) standard for > OpenSolaris? The canonicial choices, listed alphabetically, are: Are we talking about adding packaging to the source currently on OpenSolaris.org and by implication the packaging system for the Solaris product based on OpenSolaris or are we talking about packaging systems for future/current distributions ? Just like with Linux I kind of expected that each distribution that is based on OpenSolaris would do what suites them. In fact I'd really like to see OpenSolaris distributions that use rpm or deb as their defaults - if for no other reason than to prove it can be done but - because this will help us all work out what really is best. It would be very interesting to see rpm used the way it is used to build Fedora, ie use the build and package system rather than just the package system. However that requires significant re whack of the ON consolidation build system I expect. -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] bite-size bugs
Nice lead in Eric :) To signup on the opensolaris testing-discuss list you just send an email to: [EMAIL PROTECTED] Then reply to the confirmation message. The testing community page outlines some of the initiatives we are working on: http://www.opensolaris.org/os/community/opensolaris_test_qe/ We started putting some test links at: http://www.opensolaris.org/os/community/opensolaris_test_qe/testlinks/ After you join the discussion, send your test needs and ideas to: [EMAIL PROTECTED] Jim OpenSolaris Test Lead Eric Schrock wrote: On Wed, Jun 29, 2005 at 08:48:16PM +0200, Jasse Jansson wrote: And how will the community test those fixes in a proper way? Are the special test tools needed (yeah, I know they exist) or will 'continuous use' count as testing? Well, I'm not on the 'test list', maybe I should subscribe to that one too. The testing will be based on the scope and content of the bug. For a simple fix to a utility, it may be sufficient to simply roll your own handmade regression tests. For more complicated changes, such as those to libraries, kernel, or system interfaces, your sponsor will help you get the testing resources that you need. For the near future, this will likely involve you providing BFU archives and having your sponsor submit them to various test runs. If you're interested in how we plan to make testing more accesible, or have suggestions about what needs to be done, you should definitely subscribe to the test discussion list. - Eric -- Eric Schrock, Solaris Kernel Development. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
> ... > But, as someone that's implemented an entire software deployment system > based on OpenPKG, I'm heavily biased towards it. Especially since there > is a rich set of portable packages already available and Solaris is an > officially supported platform for the OpenPKG project... Just wanted to point out that you're talking about the merits of the OpenPKG system and team, not necessarily their choice to use RPM as the backend architecture. So my instincts (such as they are) tell me that comparing the pros/cons of the pkgsrc backend architecture with that of the rpm backend architecture, would effectively result in a tie. Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On Wed, 29 Jun 2005, Chris Ricker wrote: > ... > > Also, keep in mind the big difference between something like rpm and SysV > package format -- rpm manages not just the packaging, but also the > building... Chris, Sorry but could you elaborate a bit more -- especially in terms of contrasting this aspect of rpm infrastructure with Solaris' (SysV)... Thanks. Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
These questions to me frame the entire set of problems for any existing packaging system that tries to integrate with a native one or when you have a 3rd party providing the packages instead of the original project. On 6/29/05, Keith M Wesolowski <[EMAIL PROTECTED]> wrote: > - If new packages are added in existing consolidations, how should > they be named? Where is the registry that prevents conflicts? Having a central package registry where definitive names could be defined that all packagers should use regardless of which system they're packaging for would be a nice start to helping solve dependency, package replacement, or package upgrade issues. > - How do you prevent the situation in which multiple packages could > satisfy a dependency but they have different names? Conversely, how > would you prevent the existence of incompatible packages with the same > names? This seems to be an age old problem that no one has yet solved. After having spent years working with different packaging systems and reading various philosophies posted by others I don't think there is a golden bullet solution to this problem. As long as humans are the ones packaging software, each one of them will tend to do things differently, because obviously their own way is better ;) For example, some RPM based Distributions have progname, progname-devel, and progname-debug for almost every program. Where the first is the program, the second is development headers and devel specific libraries or tools, and the third is debug information that can be additionally installed when so desired. Yet other distributions only have progname, and bundle development headers, debug info and everything into one item. Then of course comes the naming conventions as you mentioned, they love to prefix all of their packages with special initials, and use a different versioning scheme than others so that even when you're using the same package format the system goes crazy trying to figure out what to do when you attempt upgrades. Then of course some people will never conform to a universal set of rules, they have their own packages, their own directory structure, and to heck with complying with any type of rules. -- Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On 6/29/05, Eric Boutilier <[EMAIL PROTECTED]> wrote: > > ... > > But, as someone that's implemented an entire software deployment system > > based on OpenPKG, I'm heavily biased towards it. Especially since there > > is a rich set of portable packages already available and Solaris is an > > officially supported platform for the OpenPKG project... > > Just wanted to point out that you're talking about the merits of the > OpenPKG system and team, not necessarily their choice to use RPM as the > backend architecture. > > So my instincts (such as they are) tell me that comparing the pros/cons > of the pkgsrc backend architecture with that of the rpm backend > architecture, would effectively result in a tie. I wish I could agree, but I can't. I've worked with a lot of different source based packaging systems, including Gentoo's, Grimoire (Sorcerer Linux..can't remember exactly), FreeBSD ports and others. RPM is a great system for providing easily rebuildable packages that generate binary packages. Personally, I have yet to find a source package system that supports easy rebuilding of source packages into a binary one using the same naming conventions and package specification files other than RPM. Every other system I've seen tends to seperate the two to a certain extent and makes it a real pain to manage both. I'm not saying that pkgsrc doesn't have that capability as I haven't worked with it. But, RPM is pretty dang convenient from my developer, system administrator and user perspective. -- Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On Wed, 29 Jun 2005, Keith M Wesolowski wrote: > On Wed, Jun 29, 2005 at 02:43:27PM -0500, Eric Boutilier wrote: > > Are you talking about how binaries built from ON and other Solaris > consolidations are delivered... No. > or about a hypothetical community-led > third-party application repository like portage, pkgsrc, and blastwave > provide today? Sort of. I'm talking about what I see as the foundational question for rapid adoption of community-led implementations (e.g. SchilliX). So maybe this is a better way of framing things: By talking about the relative pros/cons of the 5 canonical package backend architectures -- deb, pkgsrc, portage, rpm, and solaris/SVR4 -- we can derive the answer to the following question: What's the best binary packaging system for doing a first-of-its-kind (prototype if you will) SchilliX-based distro? -Eric P.S. By the way, one of the main reasons I'm pushing this is purely self-serving. The reason being, I'm eager to personally start working on a SchilliX/OpenSolaris distro, but I want ensure that I do it in a direction that has a promising future. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On Wed, 29 Jun 2005, Eric Boutilier wrote: > On Wed, 29 Jun 2005, Chris Ricker wrote: > > ... > > > > Also, keep in mind the big difference between something like rpm and SysV > > package format -- rpm manages not just the packaging, but also the > > building... > > Chris, > > Sorry but could you elaborate a bit more -- especially in terms of > contrasting this aspect of rpm infrastructure with Solaris' (SysV)... With Solaris, you build your wad of binaries (or whatever you're bundling) to package any which way you can ;-). Once you've got a hopefully working set of stuff, you go through the pkg creation process - which basically consists of listing the files you've created and some of the metadata about them (permissions, ownership, etc.) (prototype(4)), and then archiving all that (pkgmk(1)). Essentially, the pkg creation is just a glorified version of tarball creation. With rpm (dpkg is very similar; the two are basically feature-complete in comparison to each other, but rpm has the added bonus of being ported already and used by some large Sun customers) the packaging process starts with creation of a spec file. This contains the same sort of info as a prototype file (files to archive and their metadata), but it also uses a shell-script syntax to list the source archives and patches to use, and then defines the build process that produces the stuff that's being packaged from that source. You run an rpmbuild command against this spec file, and it compiles the source using the build commands listed inside the spec file. After the compile finishes, the rpmbuild produces a src.rpm which contains the original source code, any patches which were applied to it, and a copy of the spec file used for building it-- all anyone else needs to reproduce your build and produce their own binary rpms. The rpmbuild also produces a binary rpm which contains basically the same stuff as a Solaris-style package -- the compiled binaries and their permissions, plus any pre / post install / uninstall scripts. If you cheat, you can get a SysV like packaging process using rpm (compile your stuff outside of rpm, tar it up, use that tarball as your "source" for the rpm, and for the compile section of the spec file just untar it). If you're doing that, though, you might as well just do Solaris pkgs instead. The real major feature (and also the real major drawback, from a packager's perspective if you're trying to package something painfully complex ;-) of rpm over SysV is that it provides the src.rpm which should give you pristine source, any patches used by the packager, and documentation of how it is to be compiled to give you the binary package. Really using that would require reworking the whole build, bfu, etc. process though later, chris ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On 6/29/05, Chris Ricker <[EMAIL PROTECTED]> wrote: > Wow! I couldn't have put it better than that. Nicely done! -- Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
|> - How do you prevent the situation in which multiple packages could |> satisfy a dependency but they have different names? Conversely, how |> would you prevent the existence of incompatible packages with the same |> names? Fink under MacOS X seems to have a solution for this. For example in cases where X11 support can come either from Apple's X11 supplied with the OS or X.org / Xfree86 externally. The solution is to have both the specific package (with a unique name) as well as a virtual package such as "x11". Then each of the specific packages tells Fink that it implements the "x11" virtual package, and any packages that depend on X11 record the dependency on the virtual package, not the specific variant installed. Hugh. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On Wed, 29 Jun 2005, Darren J Moffat wrote: > On Wed, 2005-06-29 at 12:43, Eric Boutilier wrote: > > Tending to be a bit of a reductionist, I can't help but throw out what > > I think is the #1 foundational question here. > > > > What's the best package architecture (database) standard for > > OpenSolaris? The canonicial choices, listed alphabetically, are: > > Are we talking about adding packaging to the source > currently on OpenSolaris.org and by implication the packaging system > for the Solaris product based on OpenSolaris or are we talking about > packaging systems for future/current distributions ? The latter. > Just like with Linux I kind of expected that each distribution > that is based on OpenSolaris would do what suites them. So "them" is this commuity here, and the "distribution" is SchilliX. So in that context, "What suites us?" is the issue I'm raising. > In fact > I'd really like to see OpenSolaris distributions that use > rpm or deb as their defaults - if for no other reason than to > prove it can be done but - because this will help us all > work out what really is best. Just a point of clarification re: rpm vs. deb: A Solaris implementation of an rpm binary package system/repository has been done (the OpenPKG project), whereas nobody has done a Solaris implementation of deb yet. > It would be very interesting to see rpm used the way it is > used to build Fedora, ie use the build and package system rather > than just the package system. However that requires significant > re whack of the ON consolidation build system I expect. Along these lines, there are two auto-build systems for Solaris now: SPS and pkgsrc; and strong interest in doing Gentoo/Portage (e-builds, etc.) for Solaris too. Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On Wed, 29 Jun 2005, Bill Sommerfeld wrote: > On Wed, 2005-06-29 at 15:43, Eric Boutilier wrote: > > - A big strike against deb and portage (for Solaris/OpenSolaris) is > > that no work's been done yet. > > > > - A big strike against Solaris packaging is it's not open-source yet. > > > > - A big point in favor of Solaris packaging is compatibiltiy with > > commercial Solaris and Solaris Express. > > > > Of the other three others -- rpm, pkgsrc, and tww... Thoughts? > > pkgsrc can be made to use solaris packaging via "gensolpkg" but it's not > well integrated with the build makefiles. > > I owe the gensolpkg maintainer some patches to bring it up to speed with > the recent increase in package name lengths. So in terms relative merits of backend architectures, because the pkgsrc team doesn't (I presume) support the deb, rpm, or portage formats, the existence of "gensolpkg" sounds like a point in favor of the Solaris packaging architecture (SVR4). ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] b17 copying behaviour?
On Wed, 29 Jun 2005, Rich Teer wrote: On Wed, 29 Jun 2005, Dragan Cvetkovic wrote: after starting truss -afe -o /dev/null -p 2079, it managed to copy some 10MB of data in one minute or so, but after killing truss, it takes 5 minutes to copy 2MB of data. What is going on here? How can I find that out? This sounds like a job DTrace! [FX: sounds of feverish typing] :-) Yes, I know I should use them, and I wish I know how to do it. Therefore dtrace-discuss cc-ed :-) To recapitulate and simplify a bit: I want to copy via NFS a large file (Solaris Express b17 first iso, some 300MB). My NFS server is a x86 machine running onnv16, my NFS client is a SPARC machine (SunBlade 100) running Solaris 10 GA and up to date with patches. They are all on the local network and e.g. ftp shows the transfer speed of some 8-9MB/s. However, if I use cp to do the same, it goes extremelly slowly: 1 or 2MB per minute or even less! When I truss nfsd on the server, I see that it does a lot of sleeping, when I trace cp on the client, it does a lot of write() + mmap() of 8MB chunks and some idling in between. I have tried experimenting with switching off NFS4 and some other stuff (as I am not completely sure that our NFS4 setup is completely OK), but didn't help. Where is the cp source, btw? Another example of slow transfer: copying these 4 isos to our install server (using setup_install_server + add_to_install_server) took the whole day (some 5 to 6 hours!)! How do I start debugging this problem? Hints are more than welcome. Thanks and bye, Dragan -- Dragan Cvetkovic, To be or not to be is true. G. BooleNo it isn't. L. E. J. Brouwer ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Source Browser for Mozilla/Firefox
I wrote an engine interface for Mozilla/Firefox search. Nab it in my blog: http://cuddletech.com/blog/ benr. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] b17 copying behaviour?
On 6/30/05, Dragan Cvetkovic <[EMAIL PROTECTED]> wrote: > On Wed, 29 Jun 2005, Rich Teer wrote: > > > On Wed, 29 Jun 2005, Dragan Cvetkovic wrote: > > > >> after starting truss -afe -o /dev/null -p 2079, it managed to copy some > >> 10MB of data in one minute or so, but after killing truss, it takes 5 > >> minutes to copy 2MB of data. > >> > >> What is going on here? How can I find that out? > > > > > > This sounds like a job DTrace! [FX: sounds of feverish typing] > > > > > > :-) > > > > Yes, I know I should use them, and I wish I know how to do it. Therefore > dtrace-discuss cc-ed :-) > > To recapitulate and simplify a bit: I want to copy via NFS a large file > (Solaris Express b17 first iso, some 300MB). My NFS server is a x86 machine > running onnv16, my NFS client is a SPARC machine (SunBlade 100) running > Solaris 10 GA and up to date with patches. They are all on the local > network and e.g. ftp shows the transfer speed of some 8-9MB/s. However, if > I use cp to do the same, it goes extremelly slowly: 1 or 2MB per minute or > even less! > > When I truss nfsd on the server, I see that it does a lot of sleeping, when > I trace cp on the client, it does a lot of write() + mmap() of 8MB chunks > and some idling in between. I have tried experimenting with switching off > NFS4 and some other stuff (as I am not completely sure that our NFS4 setup > is completely OK), but didn't help. > > Where is the cp source, btw? > > Another example of slow transfer: copying these 4 isos to our install > server (using setup_install_server + add_to_install_server) took the whole > day (some 5 to 6 hours!)! > Those symptoms immediately make me think duplex mismatch. -- Alex Kiernan ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: OpenSolaris distributions and package managment
> - A big strike against deb and portage (for > Solaris/OpenSolaris) is > that no work's been done yet. you assume too much...:) work on portage for opensolaris has been slow. there are battles to be fought with gentoo people for full support. And there is of course lot of work to get it going smoothly. I am currently testing it in its zone (what a freaking relief in the thought that I won't kill my system as often as I would without zones). should have some patches for gentoo folks and an update for you folks here soon (its vacation time here..:)). portage is a beautiful system with over 100K packages ready to build with full dep tracking and flexibility of being able to create and install binary packages. I am going to add few more to that list for opensolaris. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Booting my built kernel gives "cannot mount root path"
After an apparently successful compile of the kernel using Studio 10 on my X86 platform, I used Install to create the tar file and then untarred it to create /platform/i86pc/kernel.tarkus (yes, after the EL&P album) Booting from this kernel panics the box... from the kernel debugger, ::msgbuf shows the message: "cannot mount root path" amoung the panic lines. Any suggestions as to what would cause this? -- Raymond Scott This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
I feel like it's time to mention my baby: pkgbuild (pkgbuild.sf.net), which is an rpmbuild replacement that produces Solaris SVr4 packages. This is what we use for building JDS/Solaris (all GNOME, Mozilla, Evolution, APOC). We have rpm spec files [with a few enhancements], patches and community tarballs and simply use pkgbuild -ba file.spec to build the binaries and create Solaris packages. In fact the same spec files are used for building JDS on Linux and Solaris. The JDS sources you can download from the Sun download centre (mentioned in another thread) are actually pkgbuild source packages. You can rebuild them using pkgbuild --rebuild /path/to/src-pkg Laca On Wed, 2005-06-29 at 18:28, Chris Ricker wrote: > On Wed, 29 Jun 2005, Eric Boutilier wrote: > > > On Wed, 29 Jun 2005, Chris Ricker wrote: > > > ... > > > > > > Also, keep in mind the big difference between something like rpm and SysV > > > package format -- rpm manages not just the packaging, but also the > > > building... > > > > Chris, > > > > Sorry but could you elaborate a bit more -- especially in terms of > > contrasting this aspect of rpm infrastructure with Solaris' (SysV)... > > With Solaris, you build your wad of binaries (or whatever you're bundling) > to package any which way you can ;-). Once you've got a hopefully working > set of stuff, you go through the pkg creation process - which basically > consists of listing the files you've created and some of the metadata > about them (permissions, ownership, etc.) (prototype(4)), and then > archiving all that (pkgmk(1)). Essentially, the pkg creation is just a > glorified version of tarball creation. > > With rpm (dpkg is very similar; the two are basically feature-complete in > comparison to each other, but rpm has the added bonus of being ported > already and used by some large Sun customers) the packaging process starts > with creation of a spec file. This contains the same sort of info as a > prototype file (files to archive and their metadata), but it also uses a > shell-script syntax to list the source archives and patches to use, and > then defines the build process that produces the stuff that's being > packaged from that source. You run an rpmbuild command against this spec > file, and it compiles the source using the build commands listed inside > the spec file. After the compile finishes, the rpmbuild produces a src.rpm > which contains the original source code, any patches which were applied to > it, and a copy of the spec file used for building it-- all anyone else > needs to reproduce your build and produce their own binary rpms. The > rpmbuild also produces a binary rpm which contains basically the same > stuff as a Solaris-style package -- the compiled binaries and their > permissions, plus any pre / post install / uninstall scripts. > > If you cheat, you can get a SysV like packaging process using rpm (compile > your stuff outside of rpm, tar it up, use that tarball as your "source" > for the rpm, and for the compile section of the spec file just untar it). > If you're doing that, though, you might as well just do Solaris pkgs > instead. The real major feature (and also the real major drawback, from a > packager's perspective if you're trying to package something painfully > complex ;-) of rpm over SysV is that it provides the src.rpm which should > give you pristine source, any patches used by the packager, and > documentation of how it is to be compiled to give you the binary package. > > Really using that would require reworking the whole build, bfu, etc. > process though > > later, > chris > ___ > opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] b17 copying behaviour?
On Thu, 30 Jun 2005, Alex Kiernan wrote: On 6/30/05, Dragan Cvetkovic <[EMAIL PROTECTED]> wrote: To recapitulate and simplify a bit: I want to copy via NFS a large file (Solaris Express b17 first iso, some 300MB). My NFS server is a x86 machine running onnv16, my NFS client is a SPARC machine (SunBlade 100) running Solaris 10 GA and up to date with patches. They are all on the local network and e.g. ftp shows the transfer speed of some 8-9MB/s. However, if I use cp to do the same, it goes extremelly slowly: 1 or 2MB per minute or even less! Those symptoms immediately make me think duplex mismatch. I thought so as well, but the ftp transfer confuses me (sca is the NFS client, lokrum is the NFS server): lokrum% ftp sca Connected to sca. 220 sca FTP server ready. Name (sca:dragan): 331 Password required for dragan. Password: 230 User dragan logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd /var/tmp 250 CWD command successful. ftp> bin 200 Type set to I. ftp> put sol-nv-b17-x86-v3-iso.zip 200 PORT command successful. 150 Opening BINARY mode data connection for sol-nv-b17-x86-v3-iso.zip. 226 Transfer complete. local: sol-nv-b17-x86-v3-iso.zip remote: sol-nv-b17-x86-v3-iso.zip 615586788 bytes sent in 60 seconds (10051.06 Kbytes/s) ftp> quit So, it's almost 10MB/s for the ftp between the same two machines. How can I check "duplex mismatch"? Bye, Dragan -- Dragan Cvetkovic, To be or not to be is true. G. BooleNo it isn't. L. E. J. Brouwer ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] b17 copying behaviour?
On 6/30/05, Dragan Cvetkovic <[EMAIL PROTECTED]> wrote: > On Thu, 30 Jun 2005, Alex Kiernan wrote: > > > On 6/30/05, Dragan Cvetkovic <[EMAIL PROTECTED]> wrote: > >> > >> To recapitulate and simplify a bit: I want to copy via NFS a large file > >> (Solaris Express b17 first iso, some 300MB). My NFS server is a x86 machine > >> running onnv16, my NFS client is a SPARC machine (SunBlade 100) running > >> Solaris 10 GA and up to date with patches. They are all on the local > >> network and e.g. ftp shows the transfer speed of some 8-9MB/s. However, if > >> I use cp to do the same, it goes extremelly slowly: 1 or 2MB per minute or > >> even less! > >> > > > Those symptoms immediately make me think duplex mismatch. > > I thought so as well, but the ftp transfer confuses me (sca is the NFS > client, lokrum is the NFS server): > > lokrum% ftp sca > Connected to sca. > 220 sca FTP server ready. > Name (sca:dragan): > 331 Password required for dragan. > Password: > 230 User dragan logged in. > Remote system type is UNIX. > Using binary mode to transfer files. > ftp> cd /var/tmp > 250 CWD command successful. > ftp> bin > 200 Type set to I. > ftp> put sol-nv-b17-x86-v3-iso.zip > 200 PORT command successful. > 150 Opening BINARY mode data connection for sol-nv-b17-x86-v3-iso.zip. > 226 Transfer complete. > local: sol-nv-b17-x86-v3-iso.zip remote: sol-nv-b17-x86-v3-iso.zip > 615586788 bytes sent in 60 seconds (10051.06 Kbytes/s) > ftp> quit > > So, it's almost 10MB/s for the ftp between the same two machines. How can > I check "duplex mismatch"? > > Bye, Dragan > kstat -n at each end would where I'd start, but I think whether you get meaningful duplex from it depends on what your NICs actually are. >From memory late collisions are another good indicator. -- Alex Kiernan ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] b17 copying behaviour?
On Thu, 30 Jun 2005, Alex Kiernan wrote: On 6/30/05, Dragan Cvetkovic <[EMAIL PROTECTED]> wrote: On Thu, 30 Jun 2005, Alex Kiernan wrote: Those symptoms immediately make me think duplex mismatch. I thought so as well, but the ftp transfer confuses me (sca is the NFS client, lokrum is the NFS server): [snip] 615586788 bytes sent in 60 seconds (10051.06 Kbytes/s) So, it's almost 10MB/s for the ftp between the same two machines. How can I check "duplex mismatch"? kstat -n at each end would where I'd start, but I think whether you get meaningful duplex from it depends on what your NICs actually are. From memory late collisions are another good indicator. OK, on the NFS server I see the following: $ kstat -n elxl0 module: elxlinstance: 0 name: elxl0 class:net [snip] carrier_errors 456984 [snip] $ kstat -n elxl0 | grep coll collisions 0 ex_collisions 0 first_collisions0 multi_collisions0 tx_late_collisions 0 on the client $ kstat -n eri0 module: eri instance: 0 name: eri0class:net [snip] ifspeed 1 [snip] $ kstat -n eri0 | grep coll collisions 0 excessive_coll 0 first_coll 0 late_coll 0 so there are no collisions, but quite a few carrier_error on the server. Hm. Dragan -- Dragan Cvetkovic, To be or not to be is true. G. BooleNo it isn't. L. E. J. Brouwer ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
Chris -- First, let me echo Shawn... +1 on your explanation. So one more big question... On Wed, 29 Jun 2005, Chris Ricker wrote: > ... > > With Solaris, you build your wad of binaries (or whatever you're bundling) > to package any which way you can ;-). Once you've got a hopefully working > set of stuff, you go through the pkg creation process - which basically > consists of listing the files you've created and some of the metadata > about them (permissions, ownership, etc.) (prototype(4)), and then > archiving all that (pkgmk(1)). Essentially, the pkg creation is just a > glorified version of tarball creation. > > With rpm (dpkg is very similar; the two are basically feature-complete in > comparison to each other, but rpm has the added bonus of being ported > already and used by some large Sun customers) the packaging process starts > with creation of a spec file. This contains the same sort of info as a > prototype file (files to archive and their metadata), but it also uses a > shell-script syntax to list the source archives and patches to use, and > then defines the build process that produces the stuff that's being > packaged from that source. You run an rpmbuild command against this spec > file, and it compiles the source using the build commands listed inside > the spec file. After the compile finishes, the rpmbuild produces a src.rpm > which contains the original source code, any patches which were applied to > it, and a copy of the spec file used for building it-- all anyone else > needs to reproduce your build and produce their own binary rpms. The > rpmbuild also produces a binary rpm which contains basically the same > stuff as a Solaris-style package -- the compiled binaries and their > permissions, plus any pre / post install / uninstall scripts. This suggest that the Solaris-specific build knowledge that every OpenPKG package maintainer had to acquire in order to deliver Solaris packages to the OpenPKG system has been captured and made available for re-use in Solaris-specific src.rpms on their site... Is that true? (I'm assuming that this falls into that notorious category called "If it sounds too good to be true, then it probably is". But hey, unless I'm dreaming, my beloved White Sox have reached 50+ wins before July, so apparently anything is possible! :) ) Eric > > If you cheat, you can get a SysV like packaging process using rpm (compile > your stuff outside of rpm, tar it up, use that tarball as your "source" > for the rpm, and for the compile section of the spec file just untar it). > If you're doing that, though, you might as well just do Solaris pkgs > instead. The real major feature (and also the real major drawback, from a > packager's perspective if you're trying to package something painfully > complex ;-) of rpm over SysV is that it provides the src.rpm which should > give you pristine source, any patches used by the packager, and > documentation of how it is to be compiled to give you the binary package. > > Really using that would require reworking the whole build, bfu, etc. > process though > > later, > chris > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On Wed, 29 Jun 2005, Laszlo Peter wrote: > I feel like it's time to mention my baby: pkgbuild > (pkgbuild.sf.net), which is an rpmbuild replacement that > produces Solaris SVr4 packages. This is what we use for > building JDS/Solaris (all GNOME, Mozilla, Evolution, APOC). > We have rpm spec files [with a few enhancements], patches > and community tarballs and simply use > pkgbuild -ba file.spec > to build the binaries and create Solaris packages. > In fact the same spec files are used for building JDS > on Linux and Solaris. > > The JDS sources you can download from the Sun download centre > (mentioned in another thread) are actually pkgbuild source > packages. You can rebuild them using > pkgbuild --rebuild /path/to/src-pkg > > Laca ! This is all starting to get really interesting... ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [dtrace-discuss] Re: [osol-discuss] b17 copying behaviour?
On Thu, 30 Jun 2005, Gavin Maltby wrote: Hi Dragan, Hi Gavin, On 06/30/05 00:00, Dragan Cvetkovic wrote: [cut] Where is the cp source, btw? usr/src/cmd/mv - cp and mv have common source. Ah, that explains it. Another example of slow transfer: copying these 4 isos to our install server (using setup_install_server + add_to_install_server) took the whole day (some 5 to 6 hours!)! How do I start debugging this problem? Hints are more than welcome. There was a fix around a year ago to cp performance - 5015406. Basically all the fancy mmap and VM advice that our copy was doing had so much VM overhead that a brute-force "read buffer, write buffer" approach was faster! So that should have eliminated the traditional cp performance problems. Before diving into cp/mv source try some copies using dd in both direction - nfs client to server and server to client - using a few block sizes. That could eliminate or confirm cp as a suspect - my guess is it will eliminate it. OK. See below. Are you copying from a client local f/s to server via nfs, from server via nfs to local client f/s, or one nfs mount to another? By way of a baseline, how long does a mkfile 300m take when run on the nfs server in the shared directory? I am copying to a clients f/s from server's fs via nfs. I was doing both using /net/server/shared/file/system and mounting it via NFS on a client. Here is the mkfile experiment: server# share -F nfs -o anon=0 /var/tmp/se server# pwd /var/tmp/se server# time mkfile 300m foo real0m8.613s user0m0.072s sys 0m5.080s On the client: client# pwd /net/server/var/tmp/se client# time mkfile 300m bar real0m35.535s user0m0.140s sys 0m4.053s Here is the dd time client# pwd /net/server/var/tmp/se client# time dd if=sol-nv-b17-x86-v1-iso.zip of=/var/tmp/sol-nv-b17-x86-v1-iso.zip (pressed ^c, it was taking too long) ^C104736+0 records in 104736+0 records out real3m23.931s user0m0.997s sys 0m4.701s i.e. in 3m 24sec it only copied 51MB of data (256KB/s). and with larger block size: client# time dd if=sol-nv-b17-x86-v1-iso.zip of=/var/tmp/sol-nv-b17-x86-v1-iso.zip bs=32k ^C 59+0 records in 59+0 records out real3m43.381s user0m0.005s sys 0m0.117s so, it's even worse (1.8MB in 3m 43sec!). It seems that the transfer start quickly, but after some time it gets slower and slower. Bye, Dragan -- Dragan Cvetkovic, To be or not to be is true. G. BooleNo it isn't. L. E. J. Brouwer ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [dtrace-discuss] Re: [osol-discuss] b17 copying behaviour?
On Wed, Dragan Cvetkovic wrote: > On Thu, 30 Jun 2005, Gavin Maltby wrote: > >Hi Dragan, > > Hi Gavin, > > > >On 06/30/05 00:00, Dragan Cvetkovic wrote: > >[cut] > >>Where is the cp source, btw? > > > >usr/src/cmd/mv - cp and mv have common source. > > Ah, that explains it. > > > > >>Another example of slow transfer: copying these 4 isos to our install > >>server (using setup_install_server + add_to_install_server) took the whole > >>day (some 5 to 6 hours!)! > >> > >>How do I start debugging this problem? Hints are more than welcome. > > > >There was a fix around a year ago to cp performance - 5015406. > >Basically all the fancy mmap and VM advice that our copy was doing > >had so much VM overhead that a brute-force "read buffer, write buffer" > >approach was faster! So that should have eliminated the traditional cp > >performance problems. Before diving into cp/mv source try some > >copies using dd in both direction - nfs client to server and server > >to client - using a few block sizes. That could eliminate or > >confirm cp as a suspect - my guess is it will eliminate it. > > > > OK. See below. > > > >Are you copying from a client local f/s to server via nfs, > >from server via nfs to local client f/s, or one nfs mount > >to another? By way of a baseline, how long does > >a mkfile 300m take when run on the nfs server in the > >shared directory? > > I am copying to a clients f/s from server's fs via nfs. I was doing both > using /net/server/shared/file/system and mounting it via NFS on a client. > > Here is the mkfile experiment: > > server# share -F nfs -o anon=0 /var/tmp/se > server# pwd > /var/tmp/se > server# time mkfile 300m foo > > real0m8.613s > user0m0.072s > sys 0m5.080s > > On the client: > > client# pwd > /net/server/var/tmp/se > client# time mkfile 300m bar > > real0m35.535s > user0m0.140s > sys 0m4.053s > > Here is the dd time > > client# pwd > /net/server/var/tmp/se > client# time dd if=sol-nv-b17-x86-v1-iso.zip > of=/var/tmp/sol-nv-b17-x86-v1-iso.zip > > (pressed ^c, it was taking too long) > > ^C104736+0 records in > 104736+0 records out > > real3m23.931s > user0m0.997s > sys 0m4.701s > > i.e. in 3m 24sec it only copied 51MB of data (256KB/s). > > and with larger block size: > > client# time dd if=sol-nv-b17-x86-v1-iso.zip > of=/var/tmp/sol-nv-b17-x86-v1-iso.zip bs=32k > > ^C > 59+0 records in > 59+0 records out > > real3m43.381s > user0m0.005s > sys 0m0.117s > > so, it's even worse (1.8MB in 3m 43sec!). > > It seems that the transfer start quickly, but after some time it gets > slower and slower. (note: in the future the [EMAIL PROTECTED] list may be a better target for these discussions). Without the aid of a snoop trace of this interaction, I am going to guess that there may be something going on with the x86 server. The NFS client, especially in Solaris 10, is aggressive about read-aheads and the read sizes it generates are larger than ftp would generate. So the classic problem is usually one where the client/server is unable to handle the back-to-back network traffic. To confirm something like this, a snoop trace at both the client and server would be needed; if such a snoop trace is generated, a pointer to it would be best or you can send it to me directly. Spencer ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On Wed, 29 Jun 2005, Keith M Wesolowski wrote: > > ... > ... > Making the svr4 packaging tools available in source form is a high > priority; assuming it's possible - a likely proposition Note that open-sourcing Solaris packaging is currently slated to happen no earlier than 9-12 months from now. > is there any reason that standard can't continue to be used for > distribution of binary packages and tracking of dependencies > among them? ... +1. Solaris packaging (Sun's customized svr4) is the incumbent and is very well qualified to handle registry and dependency tracking duties. Furthermore, as you mentioned, it will certainly continue to be the package infrastructure used by regular Solaris (and therefore Solaris Express) indefinitely. So taking these facts into consideration is indeed important (really really important, IMO). Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [dtrace-discuss] Re: [osol-discuss] b17 copying behaviour?
On Wed, 29 Jun 2005, Spencer Shepler wrote: It seems that the transfer start quickly, but after some time it gets slower and slower. (note: in the future the [EMAIL PROTECTED] list may be a better target for these discussions). Ah, didn't know that it exists. OK, my next problem will go there, I am not subscribed there yet. Without the aid of a snoop trace of this interaction, I am going to guess that there may be something going on with the x86 server. The NFS client, especially in Solaris 10, is aggressive about read-aheads and the read sizes it generates are larger than ftp would generate. So the classic problem is usually one where the client/server is unable to handle the back-to-back network traffic. To confirm something like this, a snoop trace at both the client and server would be needed; if such a snoop trace is generated, a pointer to it would be best or you can send it to me directly. Will do. What do you want me to snoop? cp or dd? what block size? If copying 300MB takes 2 hours to finish, do you want the whole snoop or shall I limit it? Bye, Dragan -- Dragan Cvetkovic, To be or not to be is true. G. BooleNo it isn't. L. E. J. Brouwer ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Source Browser for Mozilla/Firefox
Ben Rockwood wrote: I wrote an engine interface for Mozilla/Firefox search. Nab it in my blog: http://cuddletech.com/blog/ I sorta wrote some more. ;) http://cuddletech.com/opensolaris/search.shtml BTW, the bugdatabase can't be wrapped because the search plugins for Mozilla/Firefox are based on reconstructing a cgi url, whereas the Bug database passes the values into the cgi directly without modifying the url. benr. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [dtrace-discuss] Re: [osol-discuss] b17 copying behaviour?
Hi Dragan, On 06/30/05 00:00, Dragan Cvetkovic wrote: [cut] Where is the cp source, btw? usr/src/cmd/mv - cp and mv have common source. Another example of slow transfer: copying these 4 isos to our install server (using setup_install_server + add_to_install_server) took the whole day (some 5 to 6 hours!)! How do I start debugging this problem? Hints are more than welcome. There was a fix around a year ago to cp performance - 5015406. Basically all the fancy mmap and VM advice that our copy was doing had so much VM overhead that a brute-force "read buffer, write buffer" approach was faster! So that should have eliminated the traditional cp performance problems. Before diving into cp/mv source try some copies using dd in both direction - nfs client to server and server to client - using a few block sizes. That could eliminate or confirm cp as a suspect - my guess is it will eliminate it. Are you copying from a client local f/s to server via nfs, from server via nfs to local client f/s, or one nfs mount to another? By way of a baseline, how long does a mkfile 300m take when run on the nfs server in the shared directory? Cheers Gavin ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On Wed, Jun 29, 2005 at 05:37:59PM -0500, Eric Boutilier wrote: > So "them" is this commuity here, and the "distribution" is SchilliX. So > in that context, "What suites us?" is the issue I'm raising. I'd think the packaging system used by SchilliX is for Joerg to decide, in concert with his user base, no? > Along these lines, there are two auto-build systems for Solaris now: > SPS and pkgsrc; and strong interest in doing Gentoo/Portage (e-builds, > etc.) for Solaris too. Google for 'portaris' and see that in fact there's already a working prototype. -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!" ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: OpenSolaris distributions and package managment
On Wed, 29 Jun 2005, Sunil wrote: > > - A big strike against deb and portage (for > > Solaris/OpenSolaris) is > > that no work's been done yet. > you assume too much...:) > > work on portage for opensolaris has been slow. there are battles to be fought > with gentoo people for full support. And there is of course lot of work to > get it going smoothly. > > I am currently testing it in its zone (what a freaking relief in the thought > that I won't kill my system as often as I would without zones). should have > some patches for gentoo folks and an update for you folks here soon (its > vacation time here..:)). > > portage is a beautiful system with over 100K packages ready to build with > full dep tracking and flexibility of being able to create and install binary > packages. I am going to add few more to that list for opensolaris. Sunil -- This is great news, I happily stand corrected! Incidentally, I recently took the latest release of the Gentoo-based Vidalinux Desktop OS (VLOS 1.2); installed just the minimum packages needed to have a lightweight, dedicated "XMMS appliance" on an old 266 Mhz laptop; loaded it with mp3s; and connected the line-out to a stereo amp using a cable purchased at Radio Shack. In other words, an otherwise nearly-obsolete laptop has been reincarnated into a color-screen, mp3-playing component of the stereo system in our family room. And of course the OpenSolaris milestone I eagerly look forward to is the day I can re-install this setup with equal ease and transparency using an OpenSolaris-based distro instead of a Linux-based one. --Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On 6/29/05, Eric Boutilier <[EMAIL PROTECTED]> wrote: > This suggest that the Solaris-specific build knowledge that every > OpenPKG package maintainer had to acquire in order to deliver Solaris > packages to the OpenPKG system has been captured and made available for > re-use in Solaris-specific src.rpms on their site... Is that true? > (I'm assuming that this falls into that notorious category called "If > it sounds too good to be true, then it probably is". But hey, unless > I'm dreaming, my beloved White Sox have reached 50+ wins before July, > so apparently anything is possible! :) ) Oh, it's even better than that. The src.rpms that OpenPKG provides will build using the OpenPKG system on any OS that OpenPKG supports. That's right, they have one set of Source RPMs for FreeBSD 4.11/5.4/6.0, NetBSD 2.0, Sun Solaris 8/9/10, Debian GNU/Linux 3.1, Fedora Core 3, RedHat Enterprise Linux 3, SuSE Linux 9.3, Gentoo Linux 1.6.12, and Mandriva Linux 10.2. Additionally, OpenPKG is known to work on IBM AIX 5.1, MacOS X 10.3, HP HPUX 11.11. While the official latest release only consists of 562 packages, there is a fairly good base there to begin with for a basic operating system. Certainly a good candidate for use by an OpenSolaris distribution. There are only two things they do that I dislike, but I know why they do it for portability across those platforms and they have said they will address it in the future when suitable to do so: 1) They have their .spec files setup to use static linking by default (for portability across common platforms) 2) They have their .spec files setup to disable NLS (Because it's broken on many platforms or poorly implemented) Other than that, I generally don't have a problem with their packages from a pure usage viewpoint. Obviously, everyone has their personal preferences. The main thing is what they provide is a rich base to start from, and curing the above two things is fairly trivial in my experience so far. -- Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [dtrace-discuss] Re: [osol-discuss] b17 copying behaviour?
On Wed, Dragan Cvetkovic wrote: > On Wed, 29 Jun 2005, Spencer Shepler wrote: > > >> > >>It seems that the transfer start quickly, but after some time it gets > >>slower and slower. > > > >(note: in the future the [EMAIL PROTECTED] list may be a > >better target for these discussions). > > Ah, didn't know that it exists. OK, my next problem will go there, I am > not subscribed there yet. > > >Without the aid of a snoop trace of this interaction, I am going to > >guess that there may be something going on with the x86 server. > >The NFS client, especially in Solaris 10, is aggressive about read-aheads > >and the read sizes it generates are larger than ftp would generate. > >So the classic problem is usually one where the client/server is unable > >to handle the back-to-back network traffic. > > > >To confirm something like this, a snoop trace at both the client and server > >would be needed; if such a snoop trace is generated, a pointer to it would > >be best or you can send it to me directly. > > Will do. What do you want me to snoop? cp or dd? what block size? If > copying 300MB takes 2 hours to finish, do you want the whole snoop or > shall I limit it? Just a short (2 minutes) should suffice. HOwever, in the other mail you noted that there were the very high number of carrier_errors. That is likely the problem, right? Spencer ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On 6/29/05, Laszlo Peter <[EMAIL PROTECTED]> wrote: > I feel like it's time to mention my baby: pkgbuild Sweet! rpmbuild really has me spoiled as a dev, admin, and user. Nice to see a Solaris equivalent. Once the packaging tools are opened up as well I think this in combination with pkgsrc would make a great system. In the meantime though, there are other options... -- Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On Wed, 29 Jun 2005, Shawn Walker wrote: > ... > On 6/29/05, Keith M Wesolowski <[EMAIL PROTECTED]> wrote: > > - If new packages are added in existing consolidations, how should > > they be named? Where is the registry that prevents conflicts? > > Having a central package registry where definitive names could be > defined that all packagers should use regardless of which system > they're packaging for would be a nice start to helping solve > dependency, package replacement, or package upgrade issues... > Hmm... still assimilating this along with what's been posted about pkgbuild, spec files, and src.rpms, and thinking out loud... So it seems to me that one feasible path would be to take a minimal OpenSolaris-based OS (SchilliX) and integrate an rpm registry onto it -- at least for now. Then when Solaris packaging (svr4) is open-sourced, migrating to a svr4 registry (if compatibility with regular Solaris was desired) would be easy using Laca's pkgbuild software. Similarly, a pkgsrc registry could be used, with gensolpkg being the future migration tool. Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [dtrace-discuss] Re: [osol-discuss] b17 copying behaviour?
On Wed, 29 Jun 2005, Spencer Shepler wrote: On Wed, Dragan Cvetkovic wrote: On Wed, 29 Jun 2005, Spencer Shepler wrote: It seems that the transfer start quickly, but after some time it gets slower and slower. Will do. What do you want me to snoop? cp or dd? what block size? If copying 300MB takes 2 hours to finish, do you want the whole snoop or shall I limit it? Just a short (2 minutes) should suffice. HOwever, in the other mail you noted that there were the very high number of carrier_errors. That is likely the problem, right? OK, I have emailed you the link to snoop files. I have noticed quite a few carrier_errors on the server bash-3.00# kstat -n elxl0 | grep carrier carrier_errors 842217 but how came it affects NFS but doesn't affect e.g. ftp? Bye, Dragan -- Dragan Cvetkovic, To be or not to be is true. G. BooleNo it isn't. L. E. J. Brouwer ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On 6/29/05, Eric Boutilier <[EMAIL PROTECTED]> wrote: > So it seems to me that one feasible path would be to take a minimal > OpenSolaris-based OS (SchilliX) and integrate an rpm registry onto > it -- at least for now. Then when Solaris packaging (svr4) is > open-sourced, migrating to a svr4 registry (if compatibility with > regular Solaris was desired) would be easy using Laca's pkgbuild > software. > > Similarly, a pkgsrc registry could be used, with gensolpkg being the > future migration tool. To me, if the solaris svr4 pkg tools were open, and paired with pkgsrc, and the pkgbuild tool mentioned here earlier, then that would be a great system for an OpenSolaris distribution and make for great compatability with Official Solaris releases. But, for now, yes what you suggest sounds about right... -- Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On Wed, 29 Jun 2005, Keith M Wesolowski wrote: > On Wed, Jun 29, 2005 at 05:37:59PM -0500, Eric Boutilier wrote: > > > So "them" is this commuity here, and the "distribution" is SchilliX. So > > in that context, "What suites us?" is the issue I'm raising. > > I'd think the packaging system used by SchilliX is for Joerg to > decide, in concert with his user base, no? Keith -- Good point. Joerg -- Questions for you... - You have expressed a desire that the package infrastructure (registry, dependency tracking) for SchilliX be the Solaris standard (svr4), provided we can open-source it soon enough, correct? - And how would you feel if others were to make independent SchilliX derivatives based on say rpm, pkgsrc, or portage packaging systems? Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On Wed, 29 Jun 2005, Shawn Walker wrote: > On 6/29/05, Eric Boutilier <[EMAIL PROTECTED]> wrote: > > This suggest that the Solaris-specific build knowledge that every > > OpenPKG package maintainer had to acquire in order to deliver Solaris > > packages to the OpenPKG system has been captured and made available for > > re-use in Solaris-specific src.rpms on their site... Is that true? > > (I'm assuming that this falls into that notorious category called "If > > it sounds too good to be true, then it probably is". But hey, unless > > I'm dreaming, my beloved White Sox have reached 50+ wins before July, > > so apparently anything is possible! :) ) > > Oh, it's even better than that. The src.rpms that OpenPKG provides > will build using the OpenPKG system on any OS that OpenPKG supports... That's the central design goal of pkgsrc too, and it's great. I was actually hoping there were separate src.rpms for each OS though, because if it's like pkgsrc, the multi-platform design of the system necessitates a lot of complexity under the hood. Having said that though, it's great to hear that OpenPKG is effectively a public respository of re-usable Solaris-specific build knowledge for 500+ open-source packages. Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris distributions and package managment
On Wed, 29 Jun 2005, Shawn Walker wrote: > On 6/29/05, Eric Boutilier <[EMAIL PROTECTED]> wrote: > > So it seems to me that one feasible path would be to take a minimal > > OpenSolaris-based OS (SchilliX) and integrate an rpm registry onto > > it -- at least for now. Then when Solaris packaging (svr4) is > > open-sourced, migrating to a svr4 registry (if compatibility with > > regular Solaris was desired) would be easy using Laca's pkgbuild > > software. > > > > Similarly, a pkgsrc registry could be used, with gensolpkg being the > > future migration tool. > > To me, if the solaris svr4 pkg tools were open, and paired with > pkgsrc, and the pkgbuild tool mentioned here earlier... I think Laca's pkgbuild tool takes rpm spec files as input, not pkgsrc spec files... > , then that would > be a great system for an OpenSolaris distribution and make for great > compatability with Official Solaris releases. But, for now, yes what > you suggest sounds about right... > > -- > Shawn Walker, Software and Systems Analyst > [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: OpenSolaris distributions and package managment
> On 6/29/05, Eric Boutilier <[EMAIL PROTECTED]> > wrote: > > My 2 cents: > > > > - A big strike against deb and portage (for > Solaris/OpenSolaris) is > > that no work's been done yet. > > > > - A big strike against Solaris packaging is it's > not open-source yet. > > > > - A big point in favor of Solaris packaging is > compatibiltiy with > > commercial Solaris and Solaris Express. > > > > Of the other three others -- rpm, pkgsrc, and > tww... Thoughts? > > As far as I can tell from reading the documentation, > TWW is a high > level package management system that can't work on > it's own, as it relies on the underlying operating system to have a > native packaging system. > Think of it as an abstract packging system layer above > whatever the native one is. So, it doesn't really > work for a native > packaging system. > This is not a bug ;) It is a feature that let me pick TWW over openpkg. > That leaves OpenPKG RPM, and pkgsrc. Most of the *nix > folk will > probably lean more toward pkgsrc. But, as someone > that's implemented > an entire software deployment system based on > OpenPKG, I'm heavily > biased towards it. Especially since there is a rich > set of portable > packages already available and Solaris is an > officially supported > platform for the OpenPKG project. OpenPKG indeed is a good CPAM solution if there is no need to maintain compatibiltiy with existing legacy packages and local PMS. tj > -- > Shawn Walker, Software and Systems Analyst > [EMAIL PROTECTED] - > http://binarycrusader.blogspot.com/ > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [dtrace-discuss] Re: [osol-discuss] b17 copying behaviour?
On Wed, Dragan Cvetkovic wrote: > On Wed, 29 Jun 2005, Spencer Shepler wrote: > > >On Wed, Dragan Cvetkovic wrote: > >>On Wed, 29 Jun 2005, Spencer Shepler wrote: > >> > > It seems that the transfer start quickly, but after some time it gets > slower and slower. > >> > >>Will do. What do you want me to snoop? cp or dd? what block size? If > >>copying 300MB takes 2 hours to finish, do you want the whole snoop or > >>shall I limit it? > > > >Just a short (2 minutes) should suffice. HOwever, in the other mail > >you noted that there were the very high number of carrier_errors. > >That is likely the problem, right? > > OK, I have emailed you the link to snoop files. I have noticed quite a few > carrier_errors on the server > > bash-3.00# kstat -n elxl0 | grep carrier > carrier_errors 842217 > > but how came it affects NFS but doesn't affect e.g. ftp? I don't have an answer for you. As mentioned, NFS does place a heavier load on networking components and I have never seen that induce carrier_errors but there is a correlation. In the short snoop trace you provided to me offline, for the 788 unique NFS READ requests there were 121 retransmits. 15 percent of the READs were retransmitted to the server and will result in the type of throughput you are seeing. The snoop shows gaps in traffic (for the retransmits) as large as 60 seconds. So, solve the carrier_errors and the situation will improve immensely. Spencer ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [dtrace-discuss] Re: [osol-discuss] b17 copying behaviour?
On Wed, 29 Jun 2005, Spencer Shepler wrote: On Wed, Dragan Cvetkovic wrote: OK, I have emailed you the link to snoop files. I have noticed quite a few carrier_errors on the server bash-3.00# kstat -n elxl0 | grep carrier carrier_errors 842217 but how came it affects NFS but doesn't affect e.g. ftp? I don't have an answer for you. As mentioned, NFS does place a heavier load on networking components and I have never seen that induce carrier_errors but there is a correlation. In the short snoop trace you provided to me offline, for the 788 unique NFS READ requests there were 121 retransmits. 15 percent of the READs were retransmitted to the server and will result in the type of throughput you are seeing. The snoop shows gaps in traffic (for the retransmits) as large as 60 seconds. So, solve the carrier_errors and the situation will improve immensely. Thanks Spencer, will talk to our network admin and will try to get a different NIC and see if that helps. Bye, Dragan -- Dragan Cvetkovic, To be or not to be is true. G. BooleNo it isn't. L. E. J. Brouwer ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
