From greg at runlevelzero.net  Tue Jul  1 12:01:47 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Tue, 1 Jul 2003 12:01:47 -0700
Subject: [cAos] Meeting...
Message-ID: <20030701190147.GA26881@titan.runlevelzero.net>

Today is the Linux Users Group, so no cAos meeting today. If anyone wants to
meet today, we can do it this afternoon. Let us know if we need to meet today,
otherwise we will meet next week.

We may wish to reschedule these meetings so they don't conflict with the
LUG's... Just a thought.

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From greg at runlevelzero.net  Wed Jul  2 08:57:59 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Wed, 2 Jul 2003 08:57:59 -0700
Subject: [cAos] Packaging standard...
Message-ID: <20030702155759.GA7143@titan.runlevelzero.net>

I was thinking that it would be nice to not install documentation with each
package, but rather make it a sub package... For example:

   $ rpm -qa | grep bash
   bash-2.05b
   bash-docs-2.05b

This would be a nice feature to have for things like cluster node filesystems,
and/or stripped down systems I am not sure it is a good idea to have it as a
completely separate package.

An idea that James had was to include man pages in the main package, and all
other docs can go into a separate package called '-docs'. I think that this is
my preference, but I wanted to throw it out there for comments.

Thoughts/Ideas?
Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From herrold at owlriver.com  Wed Jul  2 11:31:59 2003
From: herrold at owlriver.com (R P Herrold)
Date: Wed, 2 Jul 2003 14:31:59 -0400 (EDT)
Subject: [cAos] Packaging standard...
In-Reply-To: <20030702155759.GA7143@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307021430510.15679-100000@swampfox.owlriver.com>

On Wed, 2 Jul 2003, Greg Kurtzer wrote:

> I was thinking that it would be nice to not install documentation with each
> package, but rather make it a sub package... For example:
> 
>    $ rpm -qa | grep bash
>    bash-2.05b
>    bash-docs-2.05b

> Thoughts/Ideas?

gakkk, no  --- no more specfile fragmentation -- just mark 
them and let the admin decide

   rpm --excludedocs  foo-1.23-1.arm.rpm

- R




From james at buszard-welcher.com  Wed Jul  2 14:32:47 2003
From: james at buszard-welcher.com (James Buszard-Welcher)
Date: Wed, 2 Jul 2003 14:32:47 -0700 (PDT)
Subject: [cAos] Packaging standard...
In-Reply-To: <Pine.LNX.4.44.0307021430510.15679-100000@swampfox.owlriver.com>
References: <20030702155759.GA7143@titan.runlevelzero.net>
	<Pine.LNX.4.44.0307021430510.15679-100000@swampfox.owlriver.com>
Message-ID: <16131.20351.316069.732463@oscar.buszard-welcher.com>

>>>>> "R" == R P Herrold <herrold at owlriver.com> writes:

    On Wed, 2 Jul 2003, Greg Kurtzer wrote:
    >> I was thinking that it would be nice to not install
    >> documentation with each package, but rather make it a sub
    >> package... For example:
    >> 
    >> $ rpm -qa | grep bash bash-2.05b bash-docs-2.05b

    >> Thoughts/Ideas?

    R> gakkk, no --- no more specfile fragmentation -- just mark them
    R> and let the admin decide

    R>    rpm --excludedocs foo-1.23-1.arm.rpm

Ahh, this is interesting.

So, if you were trying to do a minimal CORE install (as opposed to
manually adding packages at the command line later), we would include
some checkbox or something in the installer to say "no docs" and it
would pass the flag along to rpm during the initial build process?

James


From herrold at owlriver.com  Wed Jul  2 20:25:24 2003
From: herrold at owlriver.com (R P Herrold)
Date: Wed, 2 Jul 2003 23:25:24 -0400 (EDT)
Subject: [cAos] Packaging standard...
In-Reply-To: <16131.20351.316069.732463@oscar.buszard-welcher.com>
Message-ID: <Pine.LNX.4.44.0307022320160.12407-100000@swampfox.owlriver.com>

On Wed, 2 Jul 2003, James Buszard-Welcher wrote:

>     R> gakkk, no --- no more specfile fragmentation -- just mark them
>     R> and let the admin decide
> 
>     R>    rpm --excludedocs foo-1.23-1.arm.rpm
> 
> So, if you were trying to do a minimal CORE install (as opposed to
> manually adding packages at the command line later), we would include
> some checkbox or something in the installer to say "no docs" and it
> would pass the flag along to rpm during the initial build process?

At source build time, a conventional spec file is used -- in 
the %files stanza at the end, use the %doc operator to mark a 
given file or directory's contents as doco 

Then at image build time, it can be pared down during, for 
example, the chroot image build phase.

This allows use of a single argument in the package manager, 
rather than having to exterminate directories manually.

This will also work, AFTER an install, for the brave:

    rm -f `rpm -qad`

which post-processes away doco files.  It would/should work 
with a chrooted install as well (untested)

-- Russ



From greg at runlevelzero.net  Wed Jul  2 20:43:38 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Wed, 2 Jul 2003 20:43:38 -0700
Subject: [cAos] Packaging standard...
In-Reply-To: <Pine.LNX.4.44.0307022320160.12407-100000@swampfox.owlriver.com>
References: <16131.20351.316069.732463@oscar.buszard-welcher.com> <Pine.LNX.4.44.0307022320160.12407-100000@swampfox.owlriver.com>
Message-ID: <20030703034338.GC12660@titan.runlevelzero.net>

On Wed, Jul 02, 2003 at 11:25:24PM -0400, R P Herrold told me:
> > So, if you were trying to do a minimal CORE install (as opposed to
> > manually adding packages at the command line later), we would include
> > some checkbox or something in the installer to say "no docs" and it
> > would pass the flag along to rpm during the initial build process?

Cool point... Yes, this can be done at system install time!

> which post-processes away doco files.  It would/should work 
> with a chrooted install as well (untested)

Consider it tested in the Warewulf nodefs.

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From greg at runlevelzero.net  Wed Jul  2 23:06:58 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Wed, 2 Jul 2003 23:06:58 -0700
Subject: [cAos] Building linux RPM...
Message-ID: <20030703060658.GA13910@titan.runlevelzero.net>

Well, I am building a kernel for cAos. Chip and I were in agreement that we
should use a Cox kernel. I am building the SPEC from scratch because RedHat's
is such a mess. It is very time consuming because of how long it takes to
build! Oh well, if this works, it will be extremely easy to maintain the
kernel using this SPEC, and Alan's kernel.

I am using a modified RedHat .config so almost everything is built as modules.
Does anyone have an opinion on this? Much later, I will look into several 
basic security patches (like no stack exe). I am not sure I want to introduce 
something as full fledged as GRSecurity or LIDS yet... Any thoughts on this?

I am probably going to push the source tree into 
$RPM_BUILD_ROOT/usr/src/linux-%{version}-%{release} and put it into a sub
package unless someone has negatory thoughts on this. This way the
kernel-source RPM _is_ the actual source tree used to create the kernel you
are using (what a concept).

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From herrold at owlriver.com  Sat Jul  5 14:22:03 2003
From: herrold at owlriver.com (R P Herrold)
Date: Sat, 5 Jul 2003 17:22:03 -0400 (EDT)
Subject: [cAos] QA process - moving toward a release
Message-ID: <Pine.LNX.4.44.0307051712050.2562-100000@swampfox.owlriver.com>

Greg mentioned that he is happier with his kernel packaging; I 
am working on my small release elements and autobuilder this 
weekend.

In discussing QA matters, I had proposed, some months ago, a
packaging submission QA protocol, including: to try to keep
flawed products from being released; to permit a 'referred'
review process; and to preserve 'face' for novice packagers to
be encouraged to package and re-package.

I would ask that members of the group look at:
   http://www.owlriver.com/projects/packaging/fedora-flow.txt

with several points of view -- those of:
    	the Packager, 
	the Reviewer, 
	the Sec Officer, 
	the Release Manager, 
	the End User, and 
	the Support Tech

and such other Roles as come to mind.  I hope to make sure
that it does not miss some hole, with the goal of producing a
safe, and functional community-based product for each.  

Comments back to the list, please.

-- Russ Herrold



From greg at runlevelzero.net  Tue Jul  8 00:41:34 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Tue, 8 Jul 2003 00:41:34 -0700
Subject: [cAos] meeting tomorrow
Message-ID: <20030708074134.GA23898@titan.runlevelzero.net>

Meeting tomorrow. It has been a while since we have seen everyone, so please
show if you can spare the time.

Things I would like to talk about:

   - status update on the build/site engine
   - package maintainers responsibilities
   - howto maintain packages
   - thoughts on package qa process

Tomorrow at 1pm PST in LBNL 50C, or my office if that room is booked. If any
off siters need site access, either print this for the shuttle drivers, or
contact me.

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From greg at runlevelzero.net  Tue Jul  8 13:03:16 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Tue, 8 Jul 2003 13:03:16 -0700
Subject: [cAos] QA process - moving toward a release
In-Reply-To: <Pine.LNX.4.44.0307051712050.2562-100000@swampfox.owlriver.com>
References: <Pine.LNX.4.44.0307051712050.2562-100000@swampfox.owlriver.com>
Message-ID: <20030708200316.GA29061@titan.runlevelzero.net>

Hrmm... This tells me I have more work to do on the site engine! :)

   - Why publish the SRPM and the SPEC embedded tarball?
   - Why Rpm2html the holding pen (crazy repository)?
   - How many QA's does it take to accept a package into the dist?
   - #14: QA reviewer: E. confirms if possiable that this fixes the bug that
     called on the update.
   - I think that the crazy repository should contain both SRPMS and binaries
     for each platform. This way they are testing what came out of the auto
     build system, and it will make it easier to test.
   - Where are the GPG sigs kept?
   - Not sure why we need to have the MD5SUM.asc...

In progress... I am heading to the meeting now.

Greg

On Sat, Jul 05, 2003 at 05:22:03PM -0400, R P Herrold told me:
> 
> Greg mentioned that he is happier with his kernel packaging; I 
> am working on my small release elements and autobuilder this 
> weekend.
> 
> In discussing QA matters, I had proposed, some months ago, a
> packaging submission QA protocol, including: to try to keep
> flawed products from being released; to permit a 'referred'
> review process; and to preserve 'face' for novice packagers to
> be encouraged to package and re-package.
> 
> I would ask that members of the group look at:
>    http://www.owlriver.com/projects/packaging/fedora-flow.txt
> 
> with several points of view -- those of:
>     	the Packager, 
> 	the Reviewer, 
> 	the Sec Officer, 
> 	the Release Manager, 
> 	the End User, and 
> 	the Support Tech
> 
> and such other Roles as come to mind.  I hope to make sure
> that it does not miss some hole, with the goal of producing a
> safe, and functional community-based product for each.  
> 
> Comments back to the list, please.
> 
> -- Russ Herrold
> 
> _______________________________________________
> cAos mailing list
> cAos at runlevelzero.net
> http://www.caosity.org/mailman/listinfo/caos

-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From herrold at owlriver.com  Tue Jul  8 18:20:39 2003
From: herrold at owlriver.com (R P Herrold)
Date: Tue, 8 Jul 2003 21:20:39 -0400 (EDT)
Subject: [cAos] Meeting today...
In-Reply-To: <20030513190807.GA11293@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307082110450.23294-100000@swampfox.owlriver.com>

I mentioned a couple items today:

  The netwinder autobuild build log 
       http://www.netwinder.org/autobuild/rh-9/

  The Red Hat security lead backport v upgrade process
       https://www.redhat.com/advice/speaks_backport.html

  The Owl River auto-generated FTP archive web content
       http://www.owlriver.com/projects/ORC/
   Which is
       Built by:  ftp.victim.lan/usr/local/bin/buildFTPsummary.sh 
   and rsynced out from my internal master FTP server

   Sources at
ftp://ftp.owlriver.com/pub/mirror/ORC/packaging/ORC_flow_build
   along with the over-wrapping 'ORC_flow_build 


-- Russ Herrold



From greg at runlevelzero.net  Wed Jul  9 10:47:32 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Wed, 9 Jul 2003 10:47:32 -0700
Subject: [cAos] Meeting today...
In-Reply-To: <Pine.LNX.4.44.0307082110450.23294-100000@swampfox.owlriver.com>
References: <20030513190807.GA11293@titan.runlevelzero.net> <Pine.LNX.4.44.0307082110450.23294-100000@swampfox.owlriver.com>
Message-ID: <20030709174732.GC22493@titan.runlevelzero.net>

On Tue, Jul 08, 2003 at 09:20:39PM -0400, R P Herrold told me:
> I mentioned a couple items today:
>   The Red Hat security lead backport v upgrade process
>        https://www.redhat.com/advice/speaks_backport.html

Very interesting reading... With the current repository structure, backports
will be automatically included in the *cautious* repository if we (or someone
decides to do it).

Also, for the example that he gave (apache), I still come back to what other
Unix admins actually do when they come across an exploit. They upgrade, and it
is a pain, but they deal. I don't know anyone that backports the fix. With 
that said, the option is there if someone wants to do it!

>   The Owl River auto-generated FTP archive web content
>        http://www.owlriver.com/projects/ORC/

Neato, but I would like some more info. What the RPM provides/Requires,
packager, file list, etc... Does this sound reasonable?

>    Which is
>        Built by:  ftp.victim.lan/usr/local/bin/buildFTPsummary.sh 
>    and rsynced out from my internal master FTP server

I can't reach it via httpd or ftpd, so I am assuming that it is not public.

>    Sources at
> ftp://ftp.owlriver.com/pub/mirror/ORC/packaging/ORC_flow_build
>    along with the over-wrapping 'ORC_flow_build 

This is the source for the bundling tarball, right?

Thanks!
Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From herrold at owlriver.com  Fri Jul 11 19:47:08 2003
From: herrold at owlriver.com (R P Herrold)
Date: Fri, 11 Jul 2003 22:47:08 -0400 (EDT)
Subject: [cAos] fedora] Re: UnFreeze (fwd)
Message-ID: <Pine.LNX.4.44.0307112243350.28814-100000@swampfox.owlriver.com>

This crossed the Fedora-devel list earlier today.  Seth's 
comments on  respository closure are thought provoking for 
cAos as well.

-- Russ herrold


---------- Forwarded message ----------
Date: 11 Jul 2003 16:01:07 -0400
From: seth vidal <skvidal at phy.duke.edu>
Reply-To: fedora-devel at fedora.us
To: fedora-devel at fedora.us
Subject: fedora] Re: UnFreeze


> Sounds like the way most people in practice run Debian... Run the testing
> track constantly b/c unstable's too unstable for production boxes, and
> stable's too old ;-)

But even that's too rigid of a structure.

Think about a distribution of linux as a set of package groups:

Base
Development
X Window
GTK+
GNOME
QT
KDE
XFCE
Web Server
Mail Servers
etc etc

now think of each of those groups having a 'stable, unstable and
testing' or even more or less granularity than that.

and a user could select from a repository for each of those
groups+stability level but not be forced to do any one 'stability'
level. 

As long as their deps resolved they should, if things are handled
correctly, be able to have a running system. If their deps don't resolve
then they have the obvious problem.

The dep resolutions problems have been solved by rpm + yum/apt, as we
all use on a probably daily basis.

Implications:

the one big 'stable, unstable, etc' repository system goes away.

Also we need to tell a user what are the dependencies of the repository.

Since each repo won't have dependency closure it would be useful,
especially to expedite the dep resolution to say - all the packages in
this repo will need these dependencies and do not provide them
internally, go thee elsewhere :)

Ditto with provides - it'd be interesting to be able to do repository
provides as some extra information to speed up where to look for deps.

-sv




From greg at runlevelzero.net  Sat Jul 12 14:20:29 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Sat, 12 Jul 2003 14:20:29 -0700
Subject: [cAos] repository coming along...
Message-ID: <20030712212029.GA12834@titan.runlevelzero.net>

Please check out:

   http://caosity.org/docs_view.php?subject=The%20Repository%20Structure
   http://packages.caosity.org/

The repositories are auto-generating from the SRPMS and SQL back-end. Pretty
neato...

Comments/Questions?

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From herrold at owlriver.com  Sun Jul 13 14:06:34 2003
From: herrold at owlriver.com (R P Herrold)
Date: Sun, 13 Jul 2003 17:06:34 -0400 (EDT)
Subject: [cAos] slimming down -- runaway dependencies
Message-ID: <Pine.LNX.4.44.0307131342210.15545-100000@swampfox.owlriver.com>

I was doing some weekend afternoon testing of the current yum
daily, and for cAos development.  I built a small, clean
machine, to pare down further.

[herrold at router herrold]$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda2              9447440    454392   8513140   6% /
/dev/hda1                99043      9168     84761  10% /boot
none                     14660         0     14660   0% /dev/shm


Before doing the pareing further, I though I would snapshot 
and print a baseline. I ran: 

   rpm -qa --qf '%{name}\t%{size}\n' | sort > minimum-rpm.txt

to get a manifest, to further attack.  I killed of a few fat 
packages, using this to hunt with.

  sort +1 -n < minimum-rpm.txt

Then I went to temporarily toss on a printer configuration
tool, to get lpd and a good remote printer into /etc/printcap

[herrold at router herrold]$ sudo yum -y install redhat-config-printer-tui
Password:
Gathering header information file(s) from server(s)
Server: Red Hat Linux 9 - i386 - Base
Server: Red Hat Linux 9 - Updates
Finding updated packages
Downloading needed headers
Cannot find a package matching redhat-config-printer-tui
[herrold at router herrold]$

... no worries, I thought.  I'll pull the complete package. It 
cannot be too big.

[herrold at router herrold]$ sudo yum -y install  redhat-config-printer
Gathering header information file(s) from server(s)
Server: Red Hat Linux 9 - i386 - Base
Server: Red Hat Linux 9 - Updates
Finding updated packages
Downloading needed headers
Resolving dependencies
....Dependencies resolved
I will do the following:
[install: redhat-config-printer.i386]
I will install/upgrade these to satisfy the depedencies:
[deps: perl-HTML-Parser.i386]
[deps: chkfontpath.i386]
[deps: perl-libxml-enno.noarch]
[deps: perl-HTML-Tagset.noarch]
[deps: XFree86-libs-data.i386]
[deps: gimp-print.i386]
[deps: XFree86-xfs.i386]
[deps: Omni-foomatic.i386]
[deps: perl-libwww-perl.noarch]
[deps: ttmkfdir.i386]
[deps: m4.i386]
[deps: libjpeg.i386]
[deps: mpage.i386]
[deps: ghostscript.i386]
[deps: ghostscript-fonts.noarch]
[deps: libxslt.i386]
[deps: pnm2ppa.i386]
[deps: perl-DateManip.noarch]
[deps: alchemist.i386]
[deps: PyXML.i386]
[deps: perl-libxml-perl.noarch]
[deps: VFlib2.i386]
[deps: urw-fonts.noarch]
[deps: fontconfig.i386]
[deps: perl-XML-Twig.noarch]
[deps: cups-libs.i386]
[deps: XFree86-Mesa-libGL.i386]
[deps: perl-Parse-Yapp.noarch]
[deps: perl-XML-Dumper.noarch]
[deps: perl-URI.noarch]
[deps: foomatic.i386]
[deps: perl-XML-Grove.noarch]
[deps: XFree86-truetype-fonts.i386]
[deps: XFree86-libs.i386]
[deps: libtiff.i386]
[deps: libpng.i386]
[deps: Omni.i386]
[deps: perl-XML-Encoding.noarch]
[deps: perl-XML-Parser.i386]
[deps: XFree86-font-utils.i386]
[deps: freetype.i386]
Getting perl-HTML-Parser-3.26-17.i386.rpm
... <process interrupted>

Amazing.  I almost wonder how fat it would be.

So I got to scripting, and dinked out a script to determine 
what is cruft, and what is needed, according to the rpm 
dependency database, for a given set of packages.

script at: ftp.owlriver.com in /pub/local/ORC/k12ltsp/
as strip_to_min.sh

As a couple of the cAos people were wondering about minimal 
package sets for an RPM database consistent system, I make it 
available.  

I think I'll feed the results to anaconda, and see 
if it will boot.  As as cross check, I'll use yum to remove 
everything NOT listed.   But not on a system I care about.

-- Russ Herrold



From skvidal at phy.duke.edu  Sun Jul 13 14:24:30 2003
From: skvidal at phy.duke.edu (seth vidal)
Date: 13 Jul 2003 17:24:30 -0400
Subject: [cAos] Re: [Yum] slimming down -- runaway dependencies
In-Reply-To: <Pine.LNX.4.44.0307131342210.15545-100000@swampfox.owlriver.com>
References: <Pine.LNX.4.44.0307131342210.15545-100000@swampfox.owlriver.com>
Message-ID: <1058131470.4212.88.camel@binkley>

On Sun, 2003-07-13 at 17:06, R P Herrold wrote:
> I was doing some weekend afternoon testing of the current yum
> daily, and for cAos development.  I built a small, clean
> machine, to pare down further.
> 

So I'm confused. Do you think this is a bug with yum in that it is
grabbing too many dependencies? or do you just think this is an
annoyance with the packages' dependencies?

-sv




From greg at runlevelzero.net  Mon Jul 14 00:44:56 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Mon, 14 Jul 2003 00:44:56 -0700
Subject: [cAos] slimming down -- runaway dependencies
In-Reply-To: <Pine.LNX.4.44.0307131342210.15545-100000@swampfox.owlriver.com>
References: <Pine.LNX.4.44.0307131342210.15545-100000@swampfox.owlriver.com>
Message-ID: <20030714074456.GA15427@titan.runlevelzero.net>

On Sun, Jul 13, 2003 at 05:06:34PM -0400, R P Herrold told me:
> Then I went to temporarily toss on a printer configuration
> tool, to get lpd and a good remote printer into /etc/printcap

Why not just use CUPS? :)

> ... no worries, I thought.  I'll pull the complete package. It 
> cannot be too big.

Yea... Uh-hu!

> [herrold at router herrold]$ sudo yum -y install  redhat-config-printer
> ... <process interrupted>
> 
> Amazing.  I almost wonder how fat it would be.

I am actually also very interested to see if it would have worked... Oh wait,
what am I thinking, of course it would have! :)

> So I got to scripting, and dinked out a script to determine 
> what is cruft, and what is needed, according to the rpm 
> dependency database, for a given set of packages.
> 
> script at: ftp.owlriver.com in /pub/local/ORC/k12ltsp/
> as strip_to_min.sh

This is a pretty nifty little script, and will defiantly come in handy!

> As a couple of the cAos people were wondering about minimal 
> package sets for an RPM database consistent system, I make it 
> available.  

Question... I just ran your test base list, and it did not pick up packages
like krb5-libs, or zlib which are both required for openssh-server...

> I think I'll feed the results to anaconda, and see 
> if it will boot.  As as cross check, I'll use yum to remove 
> everything NOT listed.   But not on a system I care about.

Can you do an rpm -ivh --root /tmp/root *.rpm on the packages defined in the
/tmp/newexempt.txt?

I may try that tomorrow.

Very nice, thanks!

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From herrold at owlriver.com  Mon Jul 14 12:53:47 2003
From: herrold at owlriver.com (R P Herrold)
Date: Mon, 14 Jul 2003 15:53:47 -0400 (EDT)
Subject: [cAos] slimming down -- runaway dependencies
In-Reply-To: <20030714074456.GA15427@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307141548160.4289-100000@swampfox.owlriver.com>

On Mon, 14 Jul 2003, Greg Kurtzer wrote:

> > So I got to scripting, and dinked out a script to determine 
> > what is cruft, and what is needed, according to the rpm 
> > dependency database, for a given set of packages.
> > 
> > script at: ftp.owlriver.com in /pub/local/ORC/k12ltsp/
> > as strip_to_min.sh

> Question... I just ran your test base list, and it did not pick up packages
> like krb5-libs, or zlib which are both required for openssh-server...

heh -- notice that I qualified my initial remarks: 'according
to the rpm database' -- it is spotting 'packages'
del=pendencies only with this variant -- Looks like I need to
dink the code to reverse out unpackaged 'file' dependencies.

I'll bet there are 'library' or 'file' type dependencies, 
which do this.  These are evil, incarnate, I sez ...

I had elided these checks out (remnants are visible in the
prior pass ccheck code which is not presently doing anything),
for it really boggs the heck out of the process, but I will
replace them for a single pass reverse, and not duplicate that
check.   grrrr.

-- Russ



From greg at runlevelzero.net  Mon Jul 14 16:16:11 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Mon, 14 Jul 2003 16:16:11 -0700
Subject: [cAos] repository coming along...
In-Reply-To: <20030712212029.GA12834@titan.runlevelzero.net>
References: <20030712212029.GA12834@titan.runlevelzero.net>
Message-ID: <20030714231610.GA2055@titan.runlevelzero.net>

The repository is now in use, and has been linked from the main page under
Downloads.

Newest addition is Linux (the kernel). This was built by me, and I marked it
as Q/A'ed because I have been running it for quite some time on my laptop.
This kernel is a Linus Torvalds special (not RedHat), and it fits right into 
a RedHat system, and I would appreciate it if some other people would test it.
Also, the associated source package is built directly from the active build 
tree, so it is the _real_ source tree! What a concept!

Also, reminder that this is still in development so I would not install on a 
production system (yet).

   http://packages.caosity.org/

BTW, right now, I am only building for i686 (as you will see in the 
repository). 

Greg

On Sat, Jul 12, 2003 at 02:20:29PM -0700, Greg Kurtzer told me:
> Please check out:
> 
>    http://caosity.org/docs_view.php?subject=The%20Repository%20Structure
>    http://packages.caosity.org/
> 
> The repositories are auto-generating from the SRPMS and SQL back-end. Pretty
> neato...
> 
> Comments/Questions?
> 
> Greg
> -- 
> /* Greg Kurtzer, http://runlevelzero.net/greg/
>  *
>  *    Open Source Projects:
>  *       cAos:       http://caosity.org/
>  *       Warewulf:   http://warewulf-cluster.org/
>  *       GRAB:       http://rpm-grab.org/
>  *
>  * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
>  * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
>  * text, OpenOffice.org format, and RTF welcomed).
> */
> _______________________________________________
> cAos mailing list
> cAos at runlevelzero.net
> http://www.caosity.org/mailman/listinfo/caos

-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From greg at runlevelzero.net  Tue Jul 15 08:47:23 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Tue, 15 Jul 2003 08:47:23 -0700
Subject: [cAos] Meeting today...
Message-ID: <20030715154723.GA19616@titan.runlevelzero.net>

Today's cAos meeting will be dedicated to package maintainers.

   - Change the meeting time (because of LUG)
   - Updates
   - Repository status
   - Who is doing what
   - Packaging standards
   - Timelines
   - etc...

We will be meeting at LBNL building 50C conf room (backup plan is my office if 
the conf room is in use) at 1pm Tuesday.

Let me know if I need to order the conference line again...

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From greg at runlevelzero.net  Tue Jul 15 10:08:46 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Tue, 15 Jul 2003 10:08:46 -0700
Subject: [cAos] Meeting today...
In-Reply-To: <20030715154723.GA19616@titan.runlevelzero.net>
References: <20030715154723.GA19616@titan.runlevelzero.net>
Message-ID: <20030715170846.GA20354@titan.runlevelzero.net>

Woops, it looks like 50C is booked. Lets plan on meeting in my office then and
if too many people show up we can migrate to a different location.

(my office is 50B-3209E)

See you there...

Greg

On Tue, Jul 15, 2003 at 08:47:23AM -0700, Greg Kurtzer told me:
> Today's cAos meeting will be dedicated to package maintainers.
> 
>    - Change the meeting time (because of LUG)
>    - Updates
>    - Repository status
>    - Who is doing what
>    - Packaging standards
>    - Timelines
>    - etc...
> 
> We will be meeting at LBNL building 50C conf room (backup plan is my office if 
> the conf room is in use) at 1pm Tuesday.
> 
> Let me know if I need to order the conference line again...
> 
> Greg
> -- 
> /* Greg Kurtzer, http://runlevelzero.net/greg/
>  *
>  *    Open Source Projects:
>  *       cAos:       http://caosity.org/
>  *       Warewulf:   http://warewulf-cluster.org/
>  *       GRAB:       http://rpm-grab.org/
>  *
>  * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
>  * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
>  * text, OpenOffice.org format, and RTF welcomed).
> */
> _______________________________________________
> cAos mailing list
> cAos at runlevelzero.net
> http://www.caosity.org/mailman/listinfo/caos

-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From herrold at owlriver.com  Tue Jul 15 10:09:52 2003
From: herrold at owlriver.com (R P Herrold)
Date: Tue, 15 Jul 2003 13:09:52 -0400 (EDT)
Subject: [cAos] Meeting today...
In-Reply-To: <20030715154723.GA19616@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307151309340.6550-100000@swampfox.owlriver.com>

On Tue, 15 Jul 2003, Greg Kurtzer wrote:

> Today's cAos meeting will be dedicated to package maintainers.

> Let me know if I need to order the conference line again...

unavailable -- sorry

-- Russ



From geoff at galitz.org  Tue Jul 15 10:33:25 2003
From: geoff at galitz.org (Geoff Galitz)
Date: Tue, 15 Jul 2003 10:33:25 -0700 (PDT)
Subject: [cAos] Meeting today...
In-Reply-To: <20030715170846.GA20354@titan.runlevelzero.net>
References: <20030715154723.GA19616@titan.runlevelzero.net>
        <20030715170846.GA20354@titan.runlevelzero.net>
Message-ID: <1284.208.201.229.52.1058290405.squirrel@ssl.sonic.net>


Bummer.  I was hoping to make it today, but I have a cluster build
that I really need to finish and I have a programming class to
get to tonight...

Somewhat on topic, and maybe this has been discussed in my
absence, but something that would make caos a better sell down
here on campus would be include clustering capabilities in
the list of features and focuii.  Also, similar statements
about security in the project documentation would be a huge
benefit, even it is an outline of the most basic security
practices out of the box (disabling network servicec by
default and so on...)

Have fun without me.  I plan on making the next meeting.

-geoff






From greg at runlevelzero.net  Tue Jul 15 12:30:04 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Tue, 15 Jul 2003 12:30:04 -0700
Subject: [cAos] Meeting today...
In-Reply-To: <1284.208.201.229.52.1058290405.squirrel@ssl.sonic.net>
References: <20030715154723.GA19616@titan.runlevelzero.net> <20030715170846.GA20354@titan.runlevelzero.net> <1284.208.201.229.52.1058290405.squirrel@ssl.sonic.net>
Message-ID: <20030715193004.GA21926@titan.runlevelzero.net>

On Tue, Jul 15, 2003 at 10:33:25AM -0700, Geoff Galitz told me:
> Bummer.  I was hoping to make it today, but I have a cluster build
> that I really need to finish and I have a programming class to
> get to tonight...

Another cluster build? Wow, you just rock!

> Somewhat on topic, and maybe this has been discussed in my
> absence, but something that would make caos a better sell down
> here on campus would be include clustering capabilities in
> the list of features and focuii.  Also, similar statements
> about security in the project documentation would be a huge
> benefit, even it is an outline of the most basic security
> practices out of the box (disabling network servicec by
> default and so on...)

You want cluster capabilities, you got them... Of course I was thinking the
same thing too! :)

Pre-release brain dump:
cAos-cluster-1.0-1caos.*.rpm will have a similar interface to monitoring and
node configuration as Warewulf (wwmon, wwstat, ww*, nodes) but will be even
easier to use. Also, it will use a much smaller nodefs (hopefully less then
30-40Mb) that will be based on cAos itself. I have already started coding
minimal packages (ie. glibc-minimal which provides many of the core glibc
libs without all of the locale and other extraneous stuff). Maybe it will even
have an option to do NFS filesystems (not root, but almost) like what Tim is
working on from the Warewulf list.

This solution will be easy enough for a small workstation cluster, yet
powerful enough for large professional cluster solutions.

The Warewulf nodefs will be one of the first implementations of cAos because
we would not need to build an installer, and we can make it very small.


I started some docs on Security, but they are just minimal:

   http://caosity.org/docs_view.php?subject=Security

I encourage everyone to write up some docs as well. If someone thinks
something is missing, draft it and post to the mailing list.

> Have fun without me.  I plan on making the next meeting.

Fun without you? Who are you kidding!? :)

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From chip at chipsmith.us  Tue Jul 15 19:58:56 2003
From: chip at chipsmith.us (George Chip Smith)
Date: Tue, 15 Jul 2003 19:58:56 -0700
Subject: [cAos] Meeting today...
In-Reply-To: <20030715193004.GA21926@titan.runlevelzero.net>
References: <20030715154723.GA19616@titan.runlevelzero.net> <20030715170846.GA20354@titan.runlevelzero.net> <1284.208.201.229.52.1058290405.squirrel@ssl.sonic.net> <20030715193004.GA21926@titan.runlevelzero.net>
Message-ID: <3F14BF70.3050000@chipsmith.us>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greg Kurtzer wrote:

|On Tue, Jul 15, 2003 at 10:33:25AM -0700, Geoff Galitz told me:
|
|>Bummer.  I was hoping to make it today, but I have a cluster build
|>that I really need to finish and I have a programming class to
|>get to tonight...
|
|
|Another cluster build? Wow, you just rock!
|
|>Somewhat on topic, and maybe this has been discussed in my
|>absence, but something that would make caos a better sell down
|>here on campus would be include clustering capabilities in
|>the list of features and focuii.  Also, similar statements
|>about security in the project documentation would be a huge
|>benefit, even it is an outline of the most basic security
|>practices out of the box (disabling network servicec

Geoff,
I like most of the ideas about security, I am the first one to champion 
anyone who want's 'most' services turned off, however, I want my network 
configured and up and running on the first time through, I don't want to 
have to go back and manually turn that on. Very important service there ....
That's my 2 cents worth ...
- --Chip

|> by
|>default and so on...)
|
|
|You want cluster capabilities, you got them... Of course I was thinking the
|same thing too! :)
|
|Pre-release brain dump:
|cAos-cluster-1.0-1caos.*.rpm will have a similar interface to 
monitoring and
|node configuration as Warewulf (wwmon, wwstat, ww*, nodes) but will be even
|easier to use. Also, it will use a much smaller nodefs (hopefully less then
|30-40Mb) that will be based on cAos itself. I have already started coding
|minimal packages (ie. glibc-minimal which provides many of the core glibc
|libs without all of the locale and other extraneous stuff). Maybe it 
will even
|have an option to do NFS filesystems (not root, but almost) like what 
Tim is
|working on from the Warewulf list.
|
|This solution will be easy enough for a small workstation cluster, yet
|powerful enough for large professional cluster solutions.
|
|The Warewulf nodefs will be one of the first implementations of cAos 
because
|we would not need to build an installer, and we can make it very small.
|
|
|I started some docs on Security, but they are just minimal:
|
|   http://caosity.org/docs_view.php?subject=Security
|
|I encourage everyone to write up some docs as well. If someone thinks
|something is missing, draft it and post to the mailing list.
|
|>Have fun without me.  I plan on making the next meeting.
|
|
|Fun without you? Who are you kidding!? :)
|
|Greg


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/FL9v6i1B59qqBJcRAkW4AJ9qjB50n5fo/cKaMz4SJ/jpzJTjKQCgoBqs
atfpbdAJKBaKQpHLIxYWsxc=
=oejT
-----END PGP SIGNATURE-----




From geoff at galitz.org  Wed Jul 16 10:19:08 2003
From: geoff at galitz.org (Geoff Galitz)
Date: Wed, 16 Jul 2003 10:19:08 -0700 (PDT)
Subject: [cAos] Meeting today...
In-Reply-To: <3F14BF70.3050000@chipsmith.us>
References: <20030715154723.GA19616@titan.runlevelzero.net>
        <20030715170846.GA20354@titan.runlevelzero.net>
        <1284.208.201.229.52.1058290405.squirrel@ssl.sonic.net>
        <20030715193004.GA21926@titan.runlevelzero.net>
        <3F14BF70.3050000@chipsmith.us>
Message-ID: <1120.208.201.229.52.1058375948.squirrel@ssl.sonic.net>

> |>Somewhat on topic, and maybe this has been discussed in my
> |>absence, but something that would make caos a better sell down
> |>here on campus would be include clustering capabilities in
> |>the list of features and focuii.  Also, similar statements
> |>about security in the project documentation would be a huge
> |>benefit, even it is an outline of the most basic security
> |>practices out of the box (disabling network servicec
>
> Geoff,
> I like most of the ideas about security, I am the first one to champion
> anyone who want's 'most' services turned off, however, I want my network
>  configured and up and running on the first time through, I don't want
> to  have to go back and manually turn that on. Very important service
> there .... That's my 2 cents worth ...
> - --Chip

Certainly, and we can decide on the list just what should be off by
default and what should be on.  I was thinking items like xinetd, portmap,
and the like would be turned off by default.  The install program can
query the user in order to figure out if those things need to be on or
not.

-geoff






From greg at runlevelzero.net  Wed Jul 16 12:15:38 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Wed, 16 Jul 2003 12:15:38 -0700
Subject: [cAos] Meeting today...
In-Reply-To: <1120.208.201.229.52.1058375948.squirrel@ssl.sonic.net>
References: <20030715154723.GA19616@titan.runlevelzero.net> <20030715170846.GA20354@titan.runlevelzero.net> <1284.208.201.229.52.1058290405.squirrel@ssl.sonic.net> <20030715193004.GA21926@titan.runlevelzero.net> <3F14BF70.3050000@chipsmith.us> <1120.208.201.229.52.1058375948.squirrel@ssl.sonic.net>
Message-ID: <20030716191538.GA24386@titan.runlevelzero.net>

On Wed, Jul 16, 2003 at 10:19:08AM -0700, Geoff Galitz told me:
> > Geoff,
> > I like most of the ideas about security, I am the first one to champion
> > anyone who want's 'most' services turned off, however, I want my network
> >  configured and up and running on the first time through, I don't want
> > to  have to go back and manually turn that on. Very important service
> > there .... That's my 2 cents worth ...
> > - --Chip
> 
> Certainly, and we can decide on the list just what should be off by
> default and what should be on.  I was thinking items like xinetd, portmap,
> and the like would be turned off by default.  The install program can
> query the user in order to figure out if those things need to be on or
> not.

Is the concensus that it should be done in the installer rather then first
boot? Remember that first boot can be reinvoked later and does not have to fit
into a tiny installer ramdisk.

Thoughts?
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From herrold at owlriver.com  Wed Jul 16 13:12:55 2003
From: herrold at owlriver.com (R P Herrold)
Date: Wed, 16 Jul 2003 16:12:55 -0400 (EDT)
Subject: [cAos] Meeting today...
In-Reply-To: <20030716191538.GA24386@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307161605350.14764-100000@swampfox.owlriver.com>

On Wed, 16 Jul 2003, Greg Kurtzer wrote:

> Is the concensus that it should be done in the installer rather then first
> boot? Remember that first boot can be reinvoked later and does not have to fit
> into a tiny installer ramdisk.
> 
> Thoughts?

It is of course possible in the %postinstall stanza of a .spec 
file to lock down anything at initial installtion, without 
burdening the installer image. 

but I know that my view of 'proper' security will vary from 
that of another.  And this is a 'Good Thing' <tm>  

Three quick examples -- Should root ssh logins be permitted
from a remote host?  How about strict vs lax checking on
changed keys?  passwordless keyed?  There is no 'right' answer 
on these -- it depends.

At about RHL 7.1 (after a really bad run of exploits against
named, and openssh, and some other package), the 'lock it
down' at the expense of ease of use group, of which I am one,
prevailed in the RH internal beta process.  The default setup
allows dhcp, and ssh in, and that's about it, presently.

I would avoid burdening the istaller, but not be shy about 
encouraging strict packagin at the .spec file level. Also, a 
audit and tightening/hardening package, which checks against a 
has for tampering, like tripwire, would always be welcome.

-- Russ



From greg at runlevelzero.net  Wed Jul 16 16:10:29 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Wed, 16 Jul 2003 16:10:29 -0700
Subject: [cAos] RH ES support...
Message-ID: <20030716231029.GA24835@titan.runlevelzero.net>

I had a long talk today with someone that _really_ wants cAos to be
compatible with the RedHat Enterprise Server at the core level. This way he
can run Oracle on a supposedly supported OS. I was thinking then of working
backwards a bit then and making cAos1 use the RedHat7.2 core, and then cAos2
being the current.

We can then release both at the same time, and maintain them with the same
SRPM set (hopefully).

Thoughts?

Greg

BTW:
I still have to do some work to the repository engines and DB backend to
support the core package maintenance.
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From jim at rossberry.com  Wed Jul 16 17:11:24 2003
From: jim at rossberry.com (Jim Wildman)
Date: Wed, 16 Jul 2003 20:11:24 -0400 (EDT)
Subject: [cAos] RH ES support...
In-Reply-To: <20030716231029.GA24835@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307162001270.12345-100000@newross.rossberry.private>

On Wed, 16 Jul 2003, Greg Kurtzer wrote:

> I had a long talk today with someone that _really_ wants cAos to be
> compatible with the RedHat Enterprise Server at the core level. This way he
> can run Oracle on a supposedly supported OS. I was thinking then of working
> backwards a bit then and making cAos1 use the RedHat7.2 core, and then cAos2
> being the current.
> 

He needs to review all of his support agreements very carefully.  Oracle
is only eligible for Enterprise Support (24x7x365) if it is running Red
Hat generated binaries.  You can build the binaries from the sources on
the updates site, but I really doubt if that will qualify for support.

As soon as they ask for the Red Hat system id (which he won't have), his
support will be invalid.

------------------------------------------------------------------------
Jim Wildman, CISSP, RHCE                                jim at rossberry.com
http://www.rossberry.com



From greg at runlevelzero.net  Wed Jul 16 21:15:35 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Wed, 16 Jul 2003 21:15:35 -0700
Subject: [cAos] RH ES support...
In-Reply-To: <Pine.LNX.4.44.0307162001270.12345-100000@newross.rossberry.private>
References: <20030716231029.GA24835@titan.runlevelzero.net> <Pine.LNX.4.44.0307162001270.12345-100000@newross.rossberry.private>
Message-ID: <20030717041535.GA26827@titan.runlevelzero.net>

On Wed, Jul 16, 2003 at 08:11:24PM -0400, Jim Wildman told me:
> He needs to review all of his support agreements very carefully.  Oracle
> is only eligible for Enterprise Support (24x7x365) if it is running Red
> Hat generated binaries.  You can build the binaries from the sources on
> the updates site, but I really doubt if that will qualify for support.
> 
> As soon as they ask for the Red Hat system id (which he won't have), his
> support will be invalid.

Based on my discussions with him, he is hoping for a RedHat ES compatible
system. His needs are for example many Oracle servers. He has one or two
production systems which he will purchase the RH ES license for, but he also
has a spare/backup system, test system, and the stage system. He is not
necessarily hoping to have cAos supported by Oracle (as that probably won't
happen in the near future), but having something that has a similar base as
RH ES will hopefully allow it to be properly installed and work reasonably
well.

Thoughts?
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From geoff at galitz.org  Wed Jul 16 18:15:31 2003
From: geoff at galitz.org (Geoff Galitz)
Date: Wed, 16 Jul 2003 18:15:31 -0700 (PDT)
Subject: [cAos] RH ES support...
In-Reply-To: <20030716231029.GA24835@titan.runlevelzero.net>
References: <20030716231029.GA24835@titan.runlevelzero.net>
Message-ID: <49900.128.32.49.235.1058404531.squirrel@ssl.sonic.net>

> I had a long talk today with someone that _really_ wants cAos to be
> compatible with the RedHat Enterprise Server at the core level. This way
> he can run Oracle on a supposedly supported OS. I was thinking then of
> working backwards a bit then and making cAos1 use the RedHat7.2 core,
> and then cAos2 being the current.
>
> We can then release both at the same time, and maintain them with the
> same SRPM set (hopefully).
>
> Thoughts?
>
>

Hmm... I've been screwing around with different versions of Redhat
recently and have a new apprecation for why some folks want Redhat 7.x and
some distros use it as a base.

At this point, I'd say go with Redhat 7.2 core and make it the priority. 

From greg at runlevelzero.net  Thu Jul 17 00:19:39 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Thu, 17 Jul 2003 00:19:39 -0700
Subject: [cAos] RH ES support...
In-Reply-To: <49900.128.32.49.235.1058404531.squirrel@ssl.sonic.net>
References: <20030716231029.GA24835@titan.runlevelzero.net> <49900.128.32.49.235.1058404531.squirrel@ssl.sonic.net>
Message-ID: <20030717071939.GA28864@titan.runlevelzero.net>

On Wed, Jul 16, 2003 at 06:15:31PM -0700, Geoff Galitz told me:
> Hmm... I've been screwing around with different versions of Redhat
> recently and have a new apprecation for why some folks want Redhat 7.x and
> some distros use it as a base.
> 
> At this point, I'd say go with Redhat 7.2 core and make it the priority. 
> >From what I can tell this would be good for both compatibility and also
> for stability.
> 
> -geoff

Hrmm... Interesting idea. Are you opposed to releasing 2 versions
simultaneously? Also, this may be a non-issue if we have any problems
compiling some of the newer code base's on the older libs. I think it will be
fine, but I had to throw that in there.

I have been working on the web engine to maintain packages for different
versions of cAos, and allow people to manage different RPMS for various cAos
versions. It will be ready soon...

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From jim at rossberry.com  Thu Jul 17 04:25:53 2003
From: jim at rossberry.com (Jim Wildman)
Date: Thu, 17 Jul 2003 07:25:53 -0400 (EDT)
Subject: [cAos] RH ES support...
In-Reply-To: <20030717041535.GA26827@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307170720270.8119-100000@newross.rossberry.private>

On Wed, 16 Jul 2003, Greg Kurtzer wrote:

> Based on my discussions with him, he is hoping for a RedHat ES compatible
> system. His needs are for example many Oracle servers. He has one or two
> production systems which he will purchase the RH ES license for, but he also
> has a spare/backup system, test system, and the stage system. He is not
> necessarily hoping to have cAos supported by Oracle (as that probably won't
> happen in the near future), but having something that has a similar base as
> RH ES will hopefully allow it to be properly installed and work reasonably
> well.
> 
> Thoughts?
> 

Sure.  Install RH ES on all the systems but never call for support for
any but the registered ones.  It _is_ open source, after all.  It is the
access to the support channel that is restricted.  Like I said, he needs
to review his support contracts carefully.

Why would he want to do development and testing on something other than
what his production boxes are running?

------------------------------------------------------------------------
Jim Wildman, CISSP, RHCE                                jim at rossberry.com
http://www.rossberry.com





From greg at runlevelzero.net  Thu Jul 17 07:40:27 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Thu, 17 Jul 2003 07:40:27 -0700
Subject: [cAos] RH ES support...
In-Reply-To: <Pine.LNX.4.44.0307170720270.8119-100000@newross.rossberry.private>
References: <20030717041535.GA26827@titan.runlevelzero.net> <Pine.LNX.4.44.0307170720270.8119-100000@newross.rossberry.private>
Message-ID: <20030717144027.GA31293@titan.runlevelzero.net>

On Thu, Jul 17, 2003 at 07:25:53AM -0400, Jim Wildman told me:
> Sure.  Install RH ES on all the systems but never call for support for
> any but the registered ones.  It _is_ open source, after all.  It is the
> access to the support channel that is restricted.  Like I said, he needs
> to review his support contracts carefully.

He mentioned to me that the contract that he signed expressly stated that he
could not install or use the software on more systems then he is entitled.

Because we are a .gov, we _need_ to make sure that we would not be in a
license violation. From the docs that he signed, he is under the impression
that there is non open source code on the cdrom. Russ, are you redistributing
RH ES? 

> Why would he want to do development and testing on something other than
> what his production boxes are running?

His development is on Oracle and Oracle forms. Not really related to the OS. I
see the point, but once again from his perspective on the ES entitlement that
he owns there is no other solution.

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From greg at runlevelzero.net  Thu Jul 17 07:53:15 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Thu, 17 Jul 2003 07:53:15 -0700
Subject: [cAos] repository offline...
Message-ID: <20030717145315.GA31634@titan.runlevelzero.net>

I am bringing the repository offline (or rather killing it, and rebuilding
several times) testing the new cAos version specific (S)RPM support.

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From KSBeattie at lbl.gov  Thu Jul 17 11:47:19 2003
From: KSBeattie at lbl.gov (Keith Beattie)
Date: Thu, 17 Jul 2003 11:47:19 -0700
Subject: [cAos] RH ES support...
In-Reply-To: <20030716231029.GA24835@titan.runlevelzero.net>
References: <20030716231029.GA24835@titan.runlevelzero.net>
Message-ID: <3F16EF37.3060205@lbl.gov>

On 07/16/2003 04:10 PM, Greg Kurtzer wrote:
> I had a long talk today with someone that _really_ wants cAos to be
> compatible with the RedHat Enterprise Server at the core level. This way he
> can run Oracle on a supposedly supported OS. I was thinking then of working
> backwards a bit then and making cAos1 use the RedHat7.2 core, and then cAos2
> being the current.
> 
> We can then release both at the same time, and maintain them with the same
> SRPM set (hopefully).
> 
> Thoughts?

I'm probably way over my head here, but what the heck...

Is chasing RH's (and Oracle's) tail really something this dist wants to do?  Seems clear to me that RH is 'distinguishing' itself with RHES which means that, by their design, doing exactly what you suggest will be what RH will be trying to prevent.  No judgment on if they should, or can, etc. and I understand why a person might want a "RHES mirror' dist but it seems like that is a project in and of itself.  Won't it be too restrictive and/or too much work?

ksb



From greg at runlevelzero.net  Thu Jul 17 12:20:06 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Thu, 17 Jul 2003 12:20:06 -0700
Subject: [cAos] RH ES support...
In-Reply-To: <3F16EF37.3060205@lbl.gov>
References: <20030716231029.GA24835@titan.runlevelzero.net> <3F16EF37.3060205@lbl.gov>
Message-ID: <20030717192006.GA5707@titan.runlevelzero.net>

On Thu, Jul 17, 2003 at 11:47:19AM -0700, Keith Beattie told me:
> I'm probably way over my head here, but what the heck...

Sounds like your right on...

> Is chasing RH's (and Oracle's) tail really something this dist wants to do? 
> Seems clear to me that RH is 'distinguishing' itself with RHES which means 
> that, by their design, doing exactly what you suggest will be what RH will 
> be trying to prevent.  No judgment on if they should, or can, etc. and I 
> understand why a person might want a "RHES mirror' dist but it seems like 
> that is a project in and of itself.  Won't it be too restrictive and/or too 
> much work?

This is what I was thinking of when he first told me as well. Then I started
thinking about what this would ential. Why would Oracle (for example) work on
RH7.2 and not RH8? It is not the kernel, and it is not the version of Gnome or
openssh :), it really is just the core OS (ie. glibc, etc..). Because of the
nature of how cAos is designed with regard to major versions (major versions
specify the specific core OS implementation/version, and all other packages
are roughly the same between major versions) this should be pretty straight
forward except that we will have to have another build root to maintain. So is
it possible with minimal work? Yes, I think so _now_.

So is this something that we want to do? Good question and it is precisely
why I was hoping we on the list can hammer this out. Personally, I don't care
what RedHat is doing and I would like to just start with the latest and
greatest packages that are known stable. On the other hand, there are a lot of
people looking for help supporting either the RedHat7.3 systems, and maybe
have something that is binary compatible with the ES line. It may help get
early support as well as be helpful to others in the community that are in a
bind with no support for their RH7.3 systems (remember that our security 
updates should then work on 7.3).

I am too biased to make this decision without the group concensus...

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From skvidal at phy.duke.edu  Thu Jul 17 12:35:36 2003
From: skvidal at phy.duke.edu (seth vidal)
Date: 17 Jul 2003 15:35:36 -0400
Subject: [cAos] RH ES support...
In-Reply-To: <20030717192006.GA5707@titan.runlevelzero.net>
References: <20030716231029.GA24835@titan.runlevelzero.net>
	 <3F16EF37.3060205@lbl.gov>  <20030717192006.GA5707@titan.runlevelzero.net>
Message-ID: <1058470536.16483.13.camel@opus.phy.duke.edu>

> I am too biased to make this decision without the group concensus...

Hi folks, I just popped on here

Some suggestions - there is room enough for more than one stabilization
project.

ideas for projects consistent with other efforts in the community at
large:


1. cAos - doing more or less a new distro - lsb compliant-ish - rolling
updates, stable, etc

2. an ES rebuild/maintenance group - maybe in cooperation with:
http://www.uibk.ac.at/zid/software/unix/linux/rhel-rebuild-l.html
and maybe maintaining security patches/backports, etc for red hat linux
7.3

3. third party rpms for Red Hat Linux (retail distro) - probably through
something fedora.us

I know that's splitting efforts but as far as I an see it's really all
the same effort - to some extent getting us all away from being
completely reliant upon red hat.

Does that make sense vis-a-vis the ES discussion?

-sv





From greg at runlevelzero.net  Thu Jul 17 13:14:22 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Thu, 17 Jul 2003 13:14:22 -0700
Subject: [cAos] RH ES support...
In-Reply-To: <1058470536.16483.13.camel@opus.phy.duke.edu>
References: <20030716231029.GA24835@titan.runlevelzero.net> <3F16EF37.3060205@lbl.gov> <20030717192006.GA5707@titan.runlevelzero.net> <1058470536.16483.13.camel@opus.phy.duke.edu>
Message-ID: <20030717201422.GB5707@titan.runlevelzero.net>

On Thu, Jul 17, 2003 at 03:35:36PM -0400, seth vidal told me:
> 1. cAos - doing more or less a new distro - lsb compliant-ish - rolling
> updates, stable, etc
> 
> 2. an ES rebuild/maintenance group - maybe in cooperation with:
> http://www.uibk.ac.at/zid/software/unix/linux/rhel-rebuild-l.html
> and maybe maintaining security patches/backports, etc for red hat linux
> 7.3

Does the rhel-rebuild group want to do fixes for RedHat7.3? I can't seem to
find any other info besides that one page.

> 3. third party rpms for Red Hat Linux (retail distro) - probably through
> something fedora.us

Hopefully fedora will actually have a repository for cAos when the time comes. 

> I know that's splitting efforts but as far as I an see it's really all
> the same effort - to some extent getting us all away from being
> completely reliant upon red hat.

For me it is not about RedHat. I don't have anything against them. They are
doing exactly what they are supposed to do.

There is a niche for RedHat as the commercial "enterprise" supported solution,
just as much as there is a niche for more community driven solutions. I don't
want anyone to think that we are trying to get people away from RedHat. We are
providing a solution where RedHat choose not to.

> Does that make sense vis-a-vis the ES discussion?

Totally. Thanks for informing us about the RHEL-Rebuild group.

Thanks for the comments!
Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From jim at rossberry.com  Thu Jul 17 13:19:15 2003
From: jim at rossberry.com (Jim Wildman)
Date: Thu, 17 Jul 2003 16:19:15 -0400 (EDT)
Subject: [cAos] RH ES support... (fwd)
Message-ID: <Pine.LNX.4.44.0307171618110.8119-100000@newross.rossberry.private>

On Thu, 17 Jul 2003, Greg Kurtzer wrote:

> He mentioned to me that the contract that he signed expressly stated that he
> could not install or use the software on more systems then he is entitled.

I have not seen such a contract.  There is no such statement in the
license on Red Hat's site (or I missed it).

> 
> Because we are a .gov, we _need_ to make sure that we would not be in a
> license violation. From the docs that he signed, he is under the impression
> that there is non open source code on the cdrom. Russ, are you redistributing
> RH ES? 
> 

I sent another message with the output of
rpm -qp --qf '%{license}' 
for all packages on the current cd.

It has been held as too big.


------------------------------------------------------------------------
Jim Wildman, CISSP, RHCE                                jim at rossberry.com
http://www.rossberry.com




From greg at runlevelzero.net  Thu Jul 17 13:28:04 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Thu, 17 Jul 2003 13:28:04 -0700
Subject: [cAos] RH ES support... (fwd)
In-Reply-To: <Pine.LNX.4.44.0307171618110.8119-100000@newross.rossberry.private>
References: <Pine.LNX.4.44.0307171618110.8119-100000@newross.rossberry.private>
Message-ID: <20030717202804.GA6663@titan.runlevelzero.net>

On Thu, Jul 17, 2003 at 04:19:15PM -0400, Jim Wildman told me:
> I sent another message with the output of
> rpm -qp --qf '%{license}' 
> for all packages on the current cd.

Try the following:

   # rpm -qp --qf '%{license}\n' *.rpm | sort | uniq -c | sort -rn

Here is what I get on my RH8 system:
    356 GPL
    141 LGPL
     57 BSD
     47 distributable
     17 MIT
     16 XFree86
     11 Distributable
     10 MPL
     10 freeware
      8 Artistic
      6 Freely Distributable
      6 BSDish
      5 Public Domain
      5 LGPL/GPL
      4 public domain
      4 OSI certified
      4 GPL/LGPL
      4 Freely distributable
      4 BSD-like
      3 The PHP License, version 2.02
      3 Proprietary
      3 GPL/QPL
      3 GNU GPL Version 2
      3 Apache Software License
      2 X-like
      2 PSF - see LICENSE
      2 OpenLDAP
      2 Open Group Public License
      2 MIT, freely distributable.
      2 LGPL and GPL
      2 LaTeX Project Public License (http://www.latex-project.org/lppl.txt)
      2 GPL/XFree86
      2 GPL or BSD
      2 Freely Redistributable
      2 BSD-style
      2 BSD-like and LGPL
      2 Apacheish
      2 3DFX GLIDE Source Code General Public License
      1 W3C (see: http://www.w3.org/Consortium/Legal/copyright-software.html)
      1 University of Washington Free-Fork License
      1 pubkey
      1 LBNL
      1 IBM Public License
      1 GPLv2 or XFree86
      1 GPL, URW holds copyright
      1 GPL (programs), relaxed LGPL (libraries), and public domain (docs)
      1 GPL or Artistic
      1 GPL or artistic
      1 GPL, LGPL
      1 GPL2
      1 GNU GPL
      1 Free
      1 FDL
      1 Distributable (BSD-like)
      1 Copyright ? 1999-2002 Red Hat, Inc.  All rights reserved.
      1 BSD/GPL
      1 ATI Technologies

So keep in mind that this is wrong. This was the first one that was obvious to 
me:

   $ rpm -q db4 --qf '%{license}\n'
   GPL

That is incorrect. While the sleepcat license may be redistributable, it is
_not_ the GPL (just as an example).

Also, RH may have included even just one file in some of those packages that 
are not redistributable, making the entire RPM illeagle to distribute. The 
fact that I don't know, and that I had someone tell me that it _could_ not be 
used on more systems then you have purchased rights for makes me nervous.

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From skvidal at phy.duke.edu  Thu Jul 17 13:45:11 2003
From: skvidal at phy.duke.edu (seth vidal)
Date: 17 Jul 2003 16:45:11 -0400
Subject: [cAos] RH ES support...
In-Reply-To: <20030717201422.GB5707@titan.runlevelzero.net>
References: <20030716231029.GA24835@titan.runlevelzero.net>
	 <3F16EF37.3060205@lbl.gov> <20030717192006.GA5707@titan.runlevelzero.net>
	 <1058470536.16483.13.camel@opus.phy.duke.edu>
	 <20030717201422.GB5707@titan.runlevelzero.net>
Message-ID: <1058474711.16483.67.camel@opus.phy.duke.edu>

On Thu, 2003-07-17 at 16:14, Greg Kurtzer wrote:
> On Thu, Jul 17, 2003 at 03:35:36PM -0400, seth vidal told me:
> > 1. cAos - doing more or less a new distro - lsb compliant-ish - rolling
> > updates, stable, etc
> > 
> > 2. an ES rebuild/maintenance group - maybe in cooperation with:
> > http://www.uibk.ac.at/zid/software/unix/linux/rhel-rebuild-l.html
> > and maybe maintaining security patches/backports, etc for red hat linux
> > 7.3
> 
> Does the rhel-rebuild group want to do fixes for RedHat7.3? I can't seem to
> find any other info besides that one page.

no - but it is all about building highly similar systems.

AS 2.1 and 7.3 aren't very far apart.


> For me it is not about RedHat. I don't have anything against them. They are
> doing exactly what they are supposed to do.

I didn't say I had anything against them - but I do think that too much
reliance upon them is a bad thing. Just like any other organization that
isn't controlled by the community at large.

-sv

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.infiscale.org/pipermail/caos/attachments/20030717/fec35e98/attachment.bin 

From greg at runlevelzero.net  Thu Jul 17 15:21:49 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Thu, 17 Jul 2003 15:21:49 -0700
Subject: [cAos] RH ES support...
In-Reply-To: <1058474711.16483.67.camel@opus.phy.duke.edu>
References: <20030716231029.GA24835@titan.runlevelzero.net> <3F16EF37.3060205@lbl.gov> <20030717192006.GA5707@titan.runlevelzero.net> <1058470536.16483.13.camel@opus.phy.duke.edu> <20030717201422.GB5707@titan.runlevelzero.net> <1058474711.16483.67.camel@opus.phy.duke.edu>
Message-ID: <20030717222149.GA6975@titan.runlevelzero.net>

On Thu, Jul 17, 2003 at 04:45:11PM -0400, seth vidal told me:
> > For me it is not about RedHat. I don't have anything against them. They are
> > doing exactly what they are supposed to do.
> 
> I didn't say I had anything against them - but I do think that too much
> reliance upon them is a bad thing. Just like any other organization that
> isn't controlled by the community at large.

Woops, sorry. I didn't mean to imply that anyone had anything against them,
just that I do not have anything against them.

I am in total agreement with your comment on reliance on something that is not
controlled by the community that uses it.

Great minds...

-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From jim at rossberry.com  Thu Jul 17 15:45:55 2003
From: jim at rossberry.com (Jim Wildman)
Date: Thu, 17 Jul 2003 18:45:55 -0400 (EDT)
Subject: [cAos] RH ES support... (fwd)
In-Reply-To: <20030717202804.GA6663@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307171838170.8119-100000@newross.rossberry.private>

Well, they are distributing without charge on www.redhat.com...as
sources.  But you knew that.  The only part of the EULA or license that
I can find that might support such a contract is this section...

http://www.redhat.com/licenses/rhel_us_2-1.html?country=United+States&

"2.2 Customer's Computer System. Customer will be responsible for
performing operations on Customer's computer system and Red Hat shall
have no responsibility to perform operations on Customer's computer
system. Customer acknowledges that Red Hat's ability to perform certain
Support Services may be conditioned upon access to certain Customer
information and access to Customer's computer system as reasonably
requested by Red Hat. Such information may include, but is not limited
to, the type of hardware Customer is using, a description of the problem
for which Customer seeks Support Services, and additional software
Customer is using that falls outside the Support Services scope of
coverage. Customer understands and agrees that the completeness and
accuracy of the information Customer provides to Red Hat may affect Red
Hat's ability to provide Support Services. The Support Services
__purchased by Customer are intended for use only for the benefit of the
Customer and only for the Installed Systems with subscriptions. Customer
may not use one subscription for Support Services for more than one
Installed System. Any unauthorized use of the Support Services will be
deemed to be a material breach of this Agreement.__"

But notice this is the agreement for support.  Which is back to the
original discussion.  If you want Enterprise Support for RH AS and
associated enterprise apps (Oracle, WebSphere, etc), then you pay for
each copy.  If you are willing to not have support from the vendors,
then you can install as many copies as you wish.


On Thu, 17 Jul 2003, Greg Kurtzer wrote:

> 
> Also, RH may have included even just one file in some of those packages that 
> are not redistributable, making the entire RPM illeagle to distribute. The 
> fact that I don't know, and that I had someone tell me that it _could_ not be 
> used on more systems then you have purchased rights for makes me nervous.
> 
> Greg
> 

------------------------------------------------------------------------
Jim Wildman, CISSP, RHCE                                jim at rossberry.com
http://www.rossberry.com



From greg at runlevelzero.net  Thu Jul 17 16:00:00 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Thu, 17 Jul 2003 16:00:00 -0700
Subject: [cAos] RH ES support... (fwd)
In-Reply-To: <Pine.LNX.4.44.0307171838170.8119-100000@newross.rossberry.private>
References: <20030717202804.GA6663@titan.runlevelzero.net> <Pine.LNX.4.44.0307171838170.8119-100000@newross.rossberry.private>
Message-ID: <20030717225959.GA8186@titan.runlevelzero.net>

Thanks for the info. You convinced me, but I was only speaking from what a
colleague told me. I will have them check into it further.

Thanks!
Greg

On Thu, Jul 17, 2003 at 06:45:55PM -0400, Jim Wildman told me:
> Well, they are distributing without charge on www.redhat.com...as
> sources.  But you knew that.  The only part of the EULA or license that
> I can find that might support such a contract is this section...
> 
> http://www.redhat.com/licenses/rhel_us_2-1.html?country=United+States&
> 
> "2.2 Customer's Computer System. Customer will be responsible for
> performing operations on Customer's computer system and Red Hat shall
> have no responsibility to perform operations on Customer's computer
> system. Customer acknowledges that Red Hat's ability to perform certain
> Support Services may be conditioned upon access to certain Customer
> information and access to Customer's computer system as reasonably
> requested by Red Hat. Such information may include, but is not limited
> to, the type of hardware Customer is using, a description of the problem
> for which Customer seeks Support Services, and additional software
> Customer is using that falls outside the Support Services scope of
> coverage. Customer understands and agrees that the completeness and
> accuracy of the information Customer provides to Red Hat may affect Red
> Hat's ability to provide Support Services. The Support Services
> __purchased by Customer are intended for use only for the benefit of the
> Customer and only for the Installed Systems with subscriptions. Customer
> may not use one subscription for Support Services for more than one
> Installed System. Any unauthorized use of the Support Services will be
> deemed to be a material breach of this Agreement.__"
> 
> But notice this is the agreement for support.  Which is back to the
> original discussion.  If you want Enterprise Support for RH AS and
> associated enterprise apps (Oracle, WebSphere, etc), then you pay for
> each copy.  If you are willing to not have support from the vendors,
> then you can install as many copies as you wish.
> 
> 
> On Thu, 17 Jul 2003, Greg Kurtzer wrote:
> 
> > 
> > Also, RH may have included even just one file in some of those packages that 
> > are not redistributable, making the entire RPM illeagle to distribute. The 
> > fact that I don't know, and that I had someone tell me that it _could_ not be 
> > used on more systems then you have purchased rights for makes me nervous.
> > 
> > Greg
> > 
> 
> ------------------------------------------------------------------------
> Jim Wildman, CISSP, RHCE                                jim at rossberry.com
> http://www.rossberry.com
> 
> _______________________________________________
> cAos mailing list
> cAos at runlevelzero.net
> http://www.caosity.org/mailman/listinfo/caos

-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From greg at runlevelzero.net  Fri Jul 18 08:27:02 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Fri, 18 Jul 2003 08:27:02 -0700
Subject: [cAos] Repository back online...
Message-ID: <20030718152702.GA24552@titan.runlevelzero.net>

I _think_ that I have gotten the repository all hammered out. I tested with 2
cAos versions already, and the pkg_modify.php page handles multiple versions
of cAos and allows you to assign different SRPMS to different cAos versions.

The only way to know if this works is by trying it out for a while to see if
it fits.

So right now it supports different versions of SRPMS for different cAos major
versions. Is this a good thing, or should this only happen for the core
packages? When you open the page it defaults to all current major versions (as
can be seen when you edit (your own) packages at:

   http://caosity.org/pkg_modify.php?id=5

for example.

Do questions:
   1) Should we allow different SRPM versions for different cAos versions
      outside the core package set?
   2) Does the repository work?

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From gmkurtzer at lbl.gov  Fri Jul 18 13:15:14 2003
From: gmkurtzer at lbl.gov (Greg Kurtzer)
Date: Fri, 18 Jul 2003 13:15:14 -0700
Subject: [cAos] Re: Copyright and the comps file
In-Reply-To: <50612681160@maiser.uibk.ac.at>
References: <50612681160@maiser.uibk.ac.at>
Message-ID: <20030718201514.GA21080@tux.lbl.gov>

Just found some information worth posting... Check out this thread from the
RHEL-Rebuild project...

On Fri, Jul 18, 2003 at 10:13:01PM +0200, Michael Redinger told me:
> On Fri, 18 Jul 2003, Greg Kurtzer wrote:
> 
> > On Fri, Jul 18, 2003 at 09:38:03PM +0200, Michael Redinger told me:
> > > "4. REPORTING AND AUDIT. If Customer wishes to increase the number of
> > >  Installed System, then Customer will purchase from Red Hat additional
> > >  Services for each additional Installed System. During the term of this
> > >  Agreement and for one (1) year thereafter, Customer expressly grants to
> > >  Red Hat the right to audit Customer's facilities and records from time to
> > >  time in order to verify Customer's compliance with the terms and
> > >  conditions of this Agreement."
> > 
> > Wait, does this say that you are allowing RedHat to have audit rights to your
> > facilities and records????? Please tell me that I am reading into this wrong!
> 
> Yes, if you buy RHEL.
> 
> However, the question is: what's the license of the comps file? Is it
> GPL or covered by a the commercial RHEL license?
> 
> Michael
> 
> --
> Michael Redinger
> Zentraler Informatikdienst (Computer Centre)
> Universitaet Innsbruck                  
> Technikerstrasse 13                     Tel.: ++43 512 507 2335
> 6020 Innsbruck                          Fax.: ++43 512 507 2944
> Austria					Mail: Michael.Redinger at uibk.ac.at
> 
> rhel-rebuild mailing list
> rhel-rebuild-l at uibk.ac.at
> Hosted at the University of Innsbruck, Austria

-- 
Greg M. Kurtzer, CSE: Linux cluster specialist
Lawrence Berkeley National Laboratory
Contact: O=510.495.2307, P=510.448.4540, M=510.928.9953
1 Cyclotron Road #90-1116, Berkeley, CA 94720
http://www.lbl.gov, http://scs.lbl.gov/, http://lug.lbl.gov/
Email: GMKurtzer_at_lbl.gov, Text: 5109289953_at_mobileatt.net


From greg at runlevelzero.net  Fri Jul 18 16:11:39 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Fri, 18 Jul 2003 16:11:39 -0700
Subject: [cAos] LAM7 info...
Message-ID: <20030718231139.GB26993@titan.runlevelzero.net>

I have been working on the new LAM7 Warewulf RPMS. Presently it comes in 3
flavors:

   lam
   lam-devel
   lam-docs

I separated it out to make the node counterpart small, and it looks like I
have gotten it fairly reasonable. You can download and _test_ (note it is 
still being tested) at:

   http://packages.caosity.org/cAos-1/i686/creation/lam-7.0-2caos/RPMS/i686/

Here are the packages associated in the new slimmed down 'lam' rpm, and their
sizes (and also note, I kept the general man pages in the main package):

   $ rpm -ql lam | while read i; do du -sk $i; done | sort -rn
   1320    /usr/lib/libmpi.a
   532     /usr/lib/liblammpi++.a
   440     /usr/lib/liblam.a
   400     /usr/bin/laminfo
   348     /usr/lib/liblammpio.a
   224     /usr/lib/liblamf77mpi.a
   220     /usr/share/doc/lam-7.0
   204     /usr/share/doc/lam-7.0/HISTORY
   184     /usr/bin/lamd
   120     /usr/bin/mpirun
   120     /usr/bin/lamgrow
   112     /etc/lam
   108     /usr/bin/wipe
   108     /usr/bin/lamboot
   104     /usr/bin/recon
   96      /etc/lam/lam-helpfile
   92      /usr/bin/lamexec
   88      /usr/bin/mpitask
   88      /usr/bin/mpimsg
   76      /usr/bin/lamtrace
   72      /usr/bin/tping
   72      /usr/bin/lamshrink
   72      /usr/bin/lamclean
   68      /usr/bin/lamnodes
   64      /usr/bin/lamhalt
   60      /usr/bin/mpif77
   60      /usr/bin/mpicc
   60      /usr/bin/mpic++
   44      /usr/bin/tkill
   44      /usr/bin/hboot
   24      /usr/lib/lam
   20      /usr/bin/mpiexec
   16      /usr/lib/lam/liblam_totalview.so.0.0.0
   12      /usr/share/man/man1/mpirun.1.gz
   8       /usr/share/man/man1/lamexec.1.gz
   8       /usr/share/man/man1/lamboot.1.gz
   4       /usr/share/man/man7/MPI.7.gz
   4       /usr/share/man/man7/mpi.7.gz
   4       /usr/share/man/man7/lamssi_rpi.7.gz
   4       /usr/share/man/man7/lamssi_cr.7.gz
   4       /usr/share/man/man7/lamssi_coll.7.gz
   4       /usr/share/man/man7/lamssi_boot.7.gz
   4       /usr/share/man/man7/lamssi.7.gz
   4       /usr/share/man/man7/LAM.7.gz
   4       /usr/share/man/man7/lam.7.gz
   4       /usr/share/man/man5/procschema.5.gz
   4       /usr/share/man/man5/lam-helpfile.5.gz
   4       /usr/share/man/man5/CONSTANTS.5.gz
   4       /usr/share/man/man5/conf.5.gz
   4       /usr/share/man/man5/bhost.5.gz
   4       /usr/share/man/man5/appschema.5.gz
   4       /usr/share/man/man1/wipe.1.gz
   4       /usr/share/man/man1/tping.1.gz
   4       /usr/share/man/man1/tkill.1.gz
   4       /usr/share/man/man1/recon.1.gz
   4       /usr/share/man/man1/mpitask.1.gz
   4       /usr/share/man/man1/mpimsg.1.gz
   4       /usr/share/man/man1/mpif77.1.gz
   4       /usr/share/man/man1/mpiexec.1.gz
   4       /usr/share/man/man1/mpiCC.1.gz
   4       /usr/share/man/man1/mpicc.1.gz
   4       /usr/share/man/man1/mpic++.1.gz
   4       /usr/share/man/man1/lamtrace.1.gz
   4       /usr/share/man/man1/lamshrink.1.gz
   4       /usr/share/man/man1/laminfo.1.gz
   4       /usr/share/man/man1/lamgrow.1.gz
   4       /usr/share/man/man1/lamd.1.gz
   4       /usr/share/man/man1/lamclean.1.gz
   4       /usr/share/man/man1/introu.1.gz
   4       /usr/share/man/man1/hf77.1.gz
   4       /usr/share/man/man1/hcp.1.gz
   4       /usr/share/man/man1/hcc.1.gz
   4       /usr/share/man/man1/hboot.1.gz
   4       /usr/share/doc/lam-7.0/README
   4       /usr/share/doc/lam-7.0/LICENSE
   4       /usr/share/doc/lam-7.0/INSTALL
   4       /usr/lib/libmpi.la
   4       /usr/lib/liblammpi++.la
   4       /usr/lib/liblam.la
   4       /usr/lib/liblamf77mpi.la
   4       /usr/lib/lam/liblam_totalview.la
   4       /etc/profile.d/lam-shell-setup.sh
   4       /etc/profile.d/lam-shell-setup.csh
   4       /etc/lam/lam-ssi-boot-globus-helpfile
   4       /etc/lam/lam-conf.lamd
   4       /etc/lam/lam-bhost.def
   0       /usr/lib/lam/liblam_totalview.so.0
   0       /usr/lib/lam/liblam_totalview.so
   0       /usr/bin/mpiCC
   0       /usr/bin/hf77
   0       /usr/bin/hcp
   0       /usr/bin/hcc

If you install this, and it works for you, please submit your QA vote at:

   http://caosity.org/pkg_qa.php?srpm_id=15
   
note: If you have a cAosity.org account...

I will install this next week on one of our test clusters, and see how it
works.

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From greg at runlevelzero.net  Fri Jul 18 16:26:17 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Fri, 18 Jul 2003 16:26:17 -0700
Subject: [cAos] AMD systems...
Message-ID: <20030718232617.GD26993@titan.runlevelzero.net>

I have spoken to a representative at AMD, and they may be interested in
helping cAos in the form of test/build systems. They will need to have some
correspondence with several of cAos potential users or developers just to get 
some various opinions and to feel the market. We need volunteers here, and if 
anyone is interested please contact me directly or the AMD rep directly 
(marc.miller --at-- amd.com) (off list).

There are not many people here on this list because cAos has not been
publically announced, so we will need lots of participation on this! You are
the choosen ones. :)

Thanks,
Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From herrold at owlriver.com  Fri Jul 18 22:35:45 2003
From: herrold at owlriver.com (R P Herrold)
Date: Sat, 19 Jul 2003 01:35:45 -0400 (EDT)
Subject: [cAos] RH ES support...
In-Reply-To: <20030717144027.GA31293@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307190134510.8423-100000@swampfox.owlriver.com>

On Thu, 17 Jul 2003, Greg Kurtzer wrote:

> Because we are a .gov, we _need_ to make sure that we would not be in a
> license violation. From the docs that he signed, he is under the impression
> that there is non open source code on the cdrom. Russ, are you redistributing
> RH ES? 

nope - my compile is from SRPMs, omitting the two restricted 
packages

- R



From herrold at owlriver.com  Fri Jul 18 22:38:44 2003
From: herrold at owlriver.com (R P Herrold)
Date: Sat, 19 Jul 2003 01:38:44 -0400 (EDT)
Subject: [cAos] RH ES support... (fwd)
In-Reply-To: <Pine.LNX.4.44.0307171618110.8119-100000@newross.rossberry.private>
Message-ID: <Pine.LNX.4.44.0307190137460.8423-100000@swampfox.owlriver.com>

On Thu, 17 Jul 2003, Jim Wildman wrote:

> I sent another message with the output of
> rpm -qp --qf '%{license}' 
> for all packages on the current cd.
> 
> It has been held as too big.

run it as:
    rpm -qp --qf '%{license}' | sort | uniq -c
and it will slide right through.

-- Russ Herrold




From greg at runlevelzero.net  Sat Jul 19 15:06:50 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Sat, 19 Jul 2003 15:06:50 -0700
Subject: [cAos] RedHat changing support model...
Message-ID: <20030719220650.GA8804@titan.runlevelzero.net>

http://www.linuxandmain.com/modules.php?name=News&file=article&sid=364

Maybe RedHat heard about caosity.org :)

Assuming that this is true: 

  - I am not sure that this affects cAos and the RHEL-Rebuild projects 
    because they did not mention the updates and long term support, and I 
    really don't see how they can follow the community needs being corporate 
    with an obvious agenda (selling $$ enterprise solutions).
  - I guess that RedHat has not thought about the implications of changing 
    their support and development models monthly.
 
In any case, I thought this would be thought provoking, and I guess we will
see on Monday if it gets announced!

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From skvidal at phy.duke.edu  Sat Jul 19 15:11:29 2003
From: skvidal at phy.duke.edu (seth vidal)
Date: 19 Jul 2003 18:11:29 -0400
Subject: [cAos] RedHat changing support model...
In-Reply-To: <20030719220650.GA8804@titan.runlevelzero.net>
References: <20030719220650.GA8804@titan.runlevelzero.net>
Message-ID: <1058652689.22954.7.camel@opus.phy.duke.edu>

On Sat, 2003-07-19 at 18:06, Greg Kurtzer wrote:
> http://www.linuxandmain.com/modules.php?name=News&file=article&sid=364
> 
> Maybe RedHat heard about caosity.org :)
> 
> Assuming that this is true: 
> 
>   - I am not sure that this affects cAos and the RHEL-Rebuild projects 
>     because they did not mention the updates and long term support, and I 
>     really don't see how they can follow the community needs being corporate 
>     with an obvious agenda (selling $$ enterprise solutions).
>   - I guess that RedHat has not thought about the implications of changing 
>     their support and development models monthly.
>  
> In any case, I thought this would be thought provoking, and I guess we will
> see on Monday if it gets announced!
> 

there are various reports floating around - I've talked to some red hat
folks that I know and while they can't get many specifics they have said
that the article headline and some of its content is inaccurate.

-sv




From herrold at owlriver.com  Sat Jul 19 15:52:48 2003
From: herrold at owlriver.com (R P Herrold)
Date: Sat, 19 Jul 2003 18:52:48 -0400 (EDT)
Subject: [cAos] RedHat changing support model...
In-Reply-To: <20030719220650.GA8804@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307191813370.22319-100000@swampfox.owlriver.com>

On Sat, 19 Jul 2003, Greg Kurtzer wrote:

> http://www.linuxandmain.com/modules.php?name=News&file=article&sid=364
> 
> Maybe RedHat heard about caosity.org :)

hmmm.  I've always preferred the mailing list to the web page 
or news group.  Push vs. Pull content. so to speak.

The question becomes _which_ tentacle of Red Hat.  Of
course I have mentioned cAos to Red Hat folk, and seth of
'yum' fame is on the caos at runlevelzero.net list as well.  I 
think it is safe to assume the topic has come up in passing.

If I am not mistaken, seth and a couple other people who hang 
around RHers have posted to rhel-rebuild as well.

Also, of the posters seen, at least a couple are also on the
present RH NDA list as well -- I thought for a week before 
signing that NDA; I respect others who decided they could not.

So, I think it is safe to say, yes, parts of RH have probably
heard.  But earlier today I thought heard the 'whoosh, whoosh'
of the blades of the the black helicopters piloted for the
'plumber' guys with axes over theor shoulders, out prowling,
looking for leaks.  ;)

-- Russ Herrold



From greg at runlevelzero.net  Sun Jul 20 23:03:05 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Sun, 20 Jul 2003 23:03:05 -0700
Subject: [cAos] Installers...
Message-ID: <20030721060305.GA2413@titan.runlevelzero.net>

If it was only up to me, I would probably want 2 installers. One is a full
fledged ISO Knoppix type demo/test/rescue/installer and the other is a tiny 
floppy disk network installer using YUM with a kickstart'able type system.

I did not want to spend much time hacking Anaconda considering the system
should not be installed often (hopefully). Minimal tools which do the job well
and are easy enough for newbies are what we should shoot for (at least for the
beginning). 

I know that we chatted about installers a while ago, but I wanted to open the 
debate again to see if we end up in the same place.

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From greg at runlevelzero.net  Sun Jul 20 23:09:15 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Sun, 20 Jul 2003 23:09:15 -0700
Subject: [cAos] Tuesday's meeting...
Message-ID: <20030721060915.GB2413@titan.runlevelzero.net>

We are getting some more developers onboard, and I wanted to re-evaluate the
date/time of our weekly meetings.

Presently it is on Tuesday at 1pm PST. Would anyone have a problem if we moved
it to Thursday at 1pm PST?

Also, I set up an account with a free conference call provider. If you wish to
phone in to the meetings, please send me an email with your contact info and I
will add you to the list.

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From brian at uklinux.net  Tue Jul 22 02:47:34 2003
From: brian at uklinux.net (Brian Teeman)
Date: Tue, 22 Jul 2003 10:47:34 +0100 (BST)
Subject: [cAos] Linux Expo UK 2003 - .Org Village Free Space for caos
Message-ID: <Pine.LNX.4.44.0307221047230.27450-100000@s1.uklinux.net>

Thanks to generous sponsorship space is available, FREE of charge, in the
.Org Village for Linux projects, groups & campaigns.

The Linux Expo UK 2003 will take place over two days, 8th and 9th October at
the Olympia Exhibition Centre in London, UK.

This year the .Org Village will be the largest ever and split into three 
distinct areas: Campaigns, User Groups & Projects/Distributions.

Space is limited so please contact me (Brian Teeman) as soon as possible.
Your project/group/campaign will be provided with exhibition space including 
electrics, storage  etc.

This is a great opportunity to promote your project to a large audience at
minimal (no) cost, and also to help make the .Org Village a lively discussion
and meeting place for the Linux community.

Now in its fifth year, Linux Expo 2003 is the UKs largest exhibition and 
conference dedicated to this open source revolution. It brings together all
the major players in the Linux computing sphere to provide the definitive review
of all the latest products and services emerging around this rapidly developing 
technology. 

For further details or to book your free space please contact me at 
brian at uklinux.net or by phone on 0870 740 6575.

For further details on the exhibition see www.linuxexpo.co.uk

If you are not the correct person who would deal with this in your organisation 
please forward this e-mail to them and to anyone else who you think might be
interested.

Brian Teeman
uklinux.net - Sponsors of the .org Village.



From lance at uklinux.net  Tue Jul 22 02:55:53 2003
From: lance at uklinux.net (Lance Davis)
Date: Tue, 22 Jul 2003 10:55:53 +0100 (BST)
Subject: [cAos] Linux Expo UK 2003 - .Org Village Free Space for caos
In-Reply-To: <Pine.LNX.4.44.0307221047230.27450-100000@s1.uklinux.net>
Message-ID: <Pine.LNX.4.44.0307221052000.1663-100000@s1.uklinux.net>

Dont worry about this 'announcing' the project ... it is private ...

We are sponsoring the .org pavillion at the expo and I mentioned to Brian
that caos should be ready for public airing by October and we ought to 
have space.

He looked at the website and got the address of the list ...

Maybe the list  should be set for subscriber only posting at the moment 
(unless it is and he subscribed) , otherwise it will probably get overrun with 
spam ... :(

Regards
Lance

BTW - I'm a new member of the team, from England, working on preparing a 
resume of myself ...

-- 
uklinux.net - The ISP of choice for the discerning Linux user. 



From greg at runlevelzero.net  Tue Jul 22 07:25:25 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Tue, 22 Jul 2003 07:25:25 -0700
Subject: [cAos] Linux Expo UK 2003 - .Org Village Free Space for caos
In-Reply-To: <Pine.LNX.4.44.0307221052000.1663-100000@s1.uklinux.net>
References: <Pine.LNX.4.44.0307221047230.27450-100000@s1.uklinux.net> <Pine.LNX.4.44.0307221052000.1663-100000@s1.uklinux.net>
Message-ID: <20030722142525.GC27337@titan.runlevelzero.net>

On Tue, Jul 22, 2003 at 10:55:53AM +0100, Lance Davis told me:
> Dont worry about this 'announcing' the project ... it is private ...

OK. Actually I was not worried, rather excited! I think we may need to make a
trip out to the UK in October! :)

> We are sponsoring the .org pavillion at the expo and I mentioned to Brian
> that caos should be ready for public airing by October and we ought to 
> have space.

That is great! Honestly I wish we were a bit further a long and had space at
the LWE in August here in San Fransisco...

> Maybe the list  should be set for subscriber only posting at the moment 
> (unless it is and he subscribed) , otherwise it will probably get overrun with 
> spam ... :(

I agree. I will make it for subscribers only.

Thanks!
Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From greg at runlevelzero.net  Tue Jul 22 08:11:03 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Tue, 22 Jul 2003 08:11:03 -0700
Subject: [cAos] repository WWW front end (rpm2www)
Message-ID: <20030722151103.GA27774@titan.runlevelzero.net>

I finished with version1 of rpm2www.

If you now do searches via: http://caosity.org/pkg_find.php it brings you to
the rpm2www package interface. From here you can see package information, and
download code. For example:
http://caosity.org/rpm2www.php?pkg=linux-2.4.21-2caos.i686.rpm&showdetails=1

Please let me know if you see any bugs or potential optimizations.

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From herrold at owlriver.com  Tue Jul 22 09:36:07 2003
From: herrold at owlriver.com (R P Herrold)
Date: Tue, 22 Jul 2003 12:36:07 -0400 (EDT)
Subject: [cAos] Tuesday's meeting...
In-Reply-To: <20030721060915.GB2413@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307221235340.17697-100000@swampfox.owlriver.com>

On Sun, 20 Jul 2003, Greg Kurtzer wrote:

> We are getting some more developers onboard, and I wanted to re-evaluate the
> date/time of our weekly meetings.
> 
> Presently it is on Tuesday at 1pm PST. Would anyone have a problem if we moved
> it to Thursday at 1pm PST?

day change is fine by me - Russ



From greg at runlevelzero.net  Tue Jul 22 09:57:24 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Tue, 22 Jul 2003 09:57:24 -0700
Subject: [cAos] Tuesday's meeting...
In-Reply-To: <Pine.LNX.4.44.0307221235340.17697-100000@swampfox.owlriver.com>
References: <20030721060915.GB2413@titan.runlevelzero.net> <Pine.LNX.4.44.0307221235340.17697-100000@swampfox.owlriver.com>
Message-ID: <20030722165724.GA28850@titan.runlevelzero.net>

The meetings wil be on Thursday's then unless someone says it won't work.

Thursday's at 1pm PST.

Greg

On Tue, Jul 22, 2003 at 12:36:07PM -0400, R P Herrold told me:
> On Sun, 20 Jul 2003, Greg Kurtzer wrote:
> 
> > We are getting some more developers onboard, and I wanted to re-evaluate the
> > date/time of our weekly meetings.
> > 
> > Presently it is on Tuesday at 1pm PST. Would anyone have a problem if we moved
> > it to Thursday at 1pm PST?
> 
> day change is fine by me - Russ
> 
> _______________________________________________
> cAos mailing list
> cAos at runlevelzero.net
> http://www.caosity.org/mailman/listinfo/caos

-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From herrold at owlriver.com  Tue Jul 22 10:44:47 2003
From: herrold at owlriver.com (R P Herrold)
Date: Tue, 22 Jul 2003 13:44:47 -0400 (EDT)
Subject: [cAos] caosity site changes
Message-ID: <Pine.LNX.4.44.0307221315090.17697-100000@swampfox.owlriver.com>

Greg and I was looking at the package lookup tool mockup, and 
the rpm2www code he has put in it.

I was thinking, about cAos package mantainer roles and duties,
and also in light the stated Red Hat intent to 'send upstream'
much more routine maintenance, how we (as a group in support
of the cAos covered packages) could facilitate getting the bug
reports for non-security matters to the 'right' person.

[As an aside, it is not clear, one way or the other if the 
Red Hat plan can work: it diffuses talent (the pool at 
Raliegh is physically close (synergy at the water cooler), 
paid, and traditional motivation tools can work; a Community 
based approach may wither from the Sourceforge syndrome -- 23 
new winamp clones, and no shippable product.  

Also, if a developer is interested in packaging for an RPM
based Linux, he probably already carries a .spec file in his
tarball -- xfce, fetchmail (pre RH adoption); if not on a
rpm-packaging OS, why should they care (the openss* history
early on.)?  If it ends up 'growing the pie', great and I hope
it does -- but is there that much new talent to tap?]


Back to cAos business:

Several possible places to report/obtain fixes exist -- we 
can facilitate using them:

------ cleaned up irc snippet --------
[12:56] <orc_orc> gmkurtzer_w: thinking about package 
descriptions on the website, 

Part of being a packager is keeping in touch with 'what's
happening' -- I think the tool should perhaps facilitate
asking the cAos package maintainer to note/update, and for a
query to then display,

   - any .lsm entry, 
   - any upstream 'prime' site source location (I prefer an  
ftp for mirroring ease; but some packages are only available 
through http:  a static http locale aides mirroring them), 
   - bugzilla URL, 
   - mailing list URL, and
   - homepage URL 

Getting this information under maintenance and visible 
would foster upstream bug reporting  and  would get my +1
[13:00] <gmkurtzer> describe some more please...
------- snip ends ------


Greg points out the danger of stream of consciousness
development using IRC -- watching the traffic on $rhl-devel
and yet another pass by a couple of Debian folk for
'Suggests;" in rpm reminded me how nice mailing lists are for
more careful development of an idea

I am sure there is more doco and link information to gather 
and make visible -- and that within the rpm database is NOT 
the place for it.

-- I always _package_ all of the ^[A-Z]*, readme.* and .lsm
items found at the top directory of a tarball into
%_prefix/share/%{package}/ so I can persuse them when I get
stuck.  It is there -- it shows with an rpm -ql packagename,
but it is not cluttering /var/lib/rpm/

Getting all that exist, making such items them conveniently 
visible seems important to me.

-- Russ Herrold



From jsquyres at lam-mpi.org  Wed Jul 23 12:37:03 2003
From: jsquyres at lam-mpi.org (Jeff Squyres)
Date: Wed, 23 Jul 2003 15:37:03 -0400 (EDT)
Subject: [cAos] RPM issues
Message-ID: <Pine.LNX.4.56.0307231439200.25534@queeg.home.squyres.com>

Greetings everyone.  I'm Jeff Squyres, maintainer of the LAM/MPI
package.

This is my first post to the cAos list, and it's lengthy.  I
appologize in advice.  I'd rather be lenthy and precise than to drag
out additional explanation conversations over the next week.  :-)

-----

In e-mail conversations with Greg over the past few days, we have
discovered a few (poorly documented) things about RPM that neither of
us knew before, and raised a few questions about RPM distributions in
general.

I am new to cAos, so please forgive me (and correct me) if I say
anything wrong.

Let's start the conversation with the example of HPC clusters.  How
does one install LAM/MPI on such a cluster?  The de facto answer is:

     rpm -ivh lam-....rpm

But this isn't quite enough.  Indeed, from my limited understanding,
cAos/Warewulf advocates getting the SRPM and rebuilding it for your
particular environment.  At the very minimum, this gets it built for
your platform (e.g., i686) with nice compiler optimizations.

But I don't think that this is enough, either.

Doing anything more than a trivial "rpmbuild --rebuild lam-...src.rpm"
involves installing the SRPM, editing the spec file, and issuing a new
rpmbuild command.  This is a fair amount of overhead.  And technically
speaking. it's even *more* keystrokes (i.e., "harder") than just
downloading a tarball (instead of an SRPM).

[I realize that you can bundle scriptlets in an RPM that automate
things such as installation/etc., but a well-formed tarball (like
LAM/MPI) typicalls has very few scriptets in its RPM, perhaps by
allowing GNU automake/libtool take care of the majority of the
installation procedure -- so bear with me for the sake of argument
here :-) ]

Then there's specfiles themselves.  Building RPMs is neither well
understood nor well documented.  Case in point: the new features that
Greg and I found were in the obscure conditionalbulds(3) -- yes, note
the misspelling! -- man page in the rpm-devel RPM.  This man page is
really intended for C developers, not package builders.  I found this
man page by accident.  The one cannonical RPM reference, the "Maximum
RPM" book, is very old and out of date.

Indeed, most people treat specfiles like Makefiles -- they don't
understand them, so they find one "similar" to their needs, tweak them
enough to make them work for their project, and declare success.  My
point: a few tweaks are easy.  Anything else may be difficult at best.

Granted, to a knowledgable Linux programmer/sysadmin, this may be no
big deal.  But I think there are still some... not "problems", per
se... but "places for improvement" in this process:

1. We're seeing more and more users who are *not* knowledgeable
   sysadmins who are installing and running Linux clusters.  Go to the
   chemistry or physics or mechaninical engineering department in a
   college or university and you'll see 4-, 8-, and 16- (and larger)
   node clusters.  These were installed by grad students or some
   professor who had a little money and a large computational
   requirement.  Linux is cheap/free, but many people don't [yet]
   realize that it still doesn't solve all your problems for you
   (e.g., sysadmin).

   Hence, these users are bound to not understand/screw up the
   install, edit, rebuilt, re-install process.  I'm not saying that
   these people are stupid -- far from it.  But we're expecing them to
   delve deeply into matters that are not in their primary field
   (e.g., chemistry, physics, etc.) when, at the very core, all they
   want to do is run their computational codes.  Hence, the lower the
   barrier to entry that we can make it, the better.

2. The LAM source RPM can be configured in a large number of ways.  Do
   you use PBS?  Do you have Myrinet?  Do you use BProc?  And so on.
   LAM's configure script can handle many of these choices, but cannot
   possibly handle all of them without user input.

   For example, it is common to not install PBS and/or GM under /usr
   -- typically, they're installed in a tree where the compiler/linker
   does not know to look by default (e.g., /opt/pbs, /opt/gm).  Hence,
   LAM will not be able to find such additional software unless the
   user provides "--with-gm=/opt/gm", or "--with-tm=/opt/pbs", and so
   on.

   But the LAM's configure statement is hard-coded in the spec file.
   So even if I give you an SRPM, you still have to install it, modify
   the spec file (which may be non-trivial), re-build it, and then
   re-install it.

So I have two things that I'd like to do:

- make the barrier to entry even easier than the traditional SRPM
  method (install, edit specfile, rebuild, reinstall).
- provide flexability so that a given SRPM (e.g., LAM/MPI) can be
  installed in a variety of environments and still be configured in an
  "optimal" fashion (e.g., finding things like /opt/pbs)

This all has to do with that was pointed out to me by an ORNL
researcher about a week ago, and further researched by Greg and I: the
"--define" command line option to rpmbuild.

If you know what --define does, you can skip the next few paragraphs.

As you are probably aware, you can have "%define foo bar" lines in a
spec file such that anywhere you use "%{foo}", it will be replaced
with the text "bar" (similar in concept to the C preprocessor).  What
is very handy (and non-obvious) is that you can override these defines
on the command line.  And you can also do conditional tests based on
the values of these defines.

Take the following example:

    rpmbuild --define 'config_options --with-gm=/opt/gm' --rebuild ...

Note the single quotes after --define; --define only takes one
argument.  That argument is later parsed by the specfile parser.
Hence, you put both the key and value in a single shell argument
enclosed in quotes.

This is effectively the same as having the following line in your
specfile:

    %define config_options --with-gm=/opt/gm

So how is this useful, and how does this accomplish my above-stated
goals?

If the LAM spec file is clever enough to use %{config_options} in its
%configure statement, then a user doesn't need to edit a spec file to
change the options that are passed to LAM's configure.  Specifically,
the rpmbuild line shown above will rebuild a LAM SRPM and tell it to
pass "--with-gm=/opt/gm" to LAM's configure script.

Specifically, the LAM spec file has the following in it:

-----
# This checks to see if %{config_options} is set.  If it's not, it
# takes the default value hard-coded here (an empty string in this
# case)
%{!?config_options: %define config_options ""}

# In the %build scriptlet, we pass in the value of %{config_options}
# to LAM's configure script.
%build
%configure %{config_options}
-----

Hence, options can be passed directly from the rpmbuild command line
to LAM's configure script.  This cuts out two of the steps from the
traditional SRPM process:

1. install the SRPM
2. edit the specfile

and the user only has to:

3. rebuild the SRPM with the appropriate arguments
4. install the newly-build RPM

So what's the point?

This is good for users.  BUT: only if it's done in a standardized (or
at least well-documented) manner.  If all cAos RPMs could standardize
on a few universal %defines, that would help users considerably (after
all, who wants to look up the package-specific RPM defines for every
single package?).  Plus, it makes SRPMs tremendously more flexible.

This is not without its own drawbacks, however.

Here's one off the top of my head: this makes for the possibility of
having two LAM binary RPM's that are identical in name, version, and
description that are *not* the same (e.g., one has Myrinet support,
the other does not).  There may be no way for a user to know which is
which without installing them both and running the laminfo command
(LAM has a command for this kind of thing, but that's probably more
the exception than the rule).

Greg suggested adding information to the release number, perhaps of
the form:

     lam-7.0-2caos_gm

I don't know how I feel about that yet (still mulling it over).  It
may be nice to simply include the configure line in the RPM
%description.  Or perhaps other clever uses of conditional %define's.
[shrug]

But more importantly than this one semantic (to which the details can
probably be figured out) -- what do you think of the conept as a
whole?  I'm not proposing rocket science here -- this is actually
pretty straightforward and the concepts are not that deep.  But the
implications could be quite useful if everyone abides by them.

Commands and suggestions welcome.

Thanks.

-- 
{+} Jeff Squyres
{+} jsquyres at lam-mpi.org
{+} http://www.lam-mpi.org/


From herrold at owlriver.com  Wed Jul 23 13:04:00 2003
From: herrold at owlriver.com (R P Herrold)
Date: Wed, 23 Jul 2003 16:04:00 -0400 (EDT)
Subject: [cAos] Re: cAos]  RPM issues
In-Reply-To: <Pine.LNX.4.56.0307231439200.25534@queeg.home.squyres.com>
Message-ID: <Pine.LNX.4.44.0307231550440.12826-100000@swampfox.owlriver.com>

On Wed, 23 Jul 2003, Jeff Squyres wrote:

> Greetings everyone.  I'm Jeff Squyres, maintainer of the LAM/MPI
> package.

Hi, Jeff, and welcome aboard

You are also an unfamiliar face as a poster on the RH hosted 
rpm-list, but many of the questions you raise have been 
addresed there.  When I see one surfacing enough times, it 
gets integrated into the rpm.org website.

You have solved some of the matters in the conventional 
fashion, and suggested some approaches which are 
thought-provoking.  I want to study your large email, on 
paper, for I need to take notes.

Conditional options are solved lots of ways -- as a
couterpoint, the 'unison' srpm has multiple branches which
require uncommenting differing paths, depending on whether it
is being built in a Tk/Tcl, a gtk, or a traditional X widget
environment. 

That the three environments may co-exists suggests that it is
probably possible to build all three versions in one pass with
one intermediate .specfile -- but the pain of getting the
conditionals right ecxeeds just doing two edits and rerunning
it.

Your use of defines moves that out of .spec file options, but 
is more opaque to some-one who does not know the details of 
your package.  Conventioanlly this is addressed with 
commentary in the .spec and in a README.

As one gets more comportable with packaging, the .spec files 
get more ornate.  The rpm, the linux kernel, and the python 
series .spec files are really about the most complex 
human-maintained ones about.

anyway -- good to see you -- I often hunt for binaries thus:
    rpm -ql foo | grep bin

and that method may be used to hunt for man pages as well:
    rpm -ql foo | grep man

and then chew on the results.  Like a dinner of Chinese 
foo man chu, though, you may end up hungry an hour later.  ;)
[evil pun, ehhh?]

-- Russ herrold



From greg at runlevelzero.net  Wed Jul 23 13:10:15 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Wed, 23 Jul 2003 13:10:15 -0700
Subject: [cAos] RPM issues
In-Reply-To: <Pine.LNX.4.56.0307231439200.25534@queeg.home.squyres.com>
References: <Pine.LNX.4.56.0307231439200.25534@queeg.home.squyres.com>
Message-ID: <20030723201015.GB12282@titan.runlevelzero.net>

Notes inline:

On Wed, Jul 23, 2003 at 03:37:03PM -0400, Jeff Squyres told me:
> But this isn't quite enough.  Indeed, from my limited understanding,
> cAos/Warewulf advocates getting the SRPM and rebuilding it for your
> particular environment.  At the very minimum, this gets it built for
> your platform (e.g., i686) with nice compiler optimizations.

I only really advocate rebuilding RPMS when you need something different then
what is provided in compile options (which is basically what you would to 
have).

cAos and Warewulf both distribute binary packages as well as the src.rpms.

> But I don't think that this is enough, either.

snip....

So the only other idea that I had was to do something using the internal SPEC
%defines as boolean switches:

Start with...

   # bools
   %define gnu    0
   %define pgi    1
   %define gm     1
   %define tm     0

and then...

   %if %{gm}
       %define config_opts --with-gm=/opt/gm
       %define release %{rel}_gm
   %endif
   %if %{pgi}
       %define c_compiler pgicc
       %define compiler_path /usr/pgi/linux86
       %define c_compiler gcc
       %define compiler_path /usr/pgi/linux86
       %define setenvs export PATH=$PATH:%{compiler_path}/bin; export %PGI=%{compiler_path}/..; export CC="%{compiler_path}/bin/pgcc"; export %FC="/usr/pgi/linux86/bin/pgf77"; export F90="%{compiler_path}/bin/pgf90"
       %define extralibs -L%{compiler_path}/lib -lpgc
       %define extraldopts -L%{compiler_path}/lib -lpgc
       %define release %{release}_pgi
   %endif

and then...

   %build
   %setenvs
   %configure %{config_opts}


This does unfortunatly mean someone would edit the SPEC to make these changes,
but it will take into account multiple build options, and keeping track of the
different RPMS produced ('Release:' tag to reflect changes).

MPICH is doing something _extreamly_ similiar to this...
 
You can even have some conditionals that will specify the initial bools based
on rpmbuild command line args.

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From greg at runlevelzero.net  Wed Jul 23 13:14:11 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Wed, 23 Jul 2003 13:14:11 -0700
Subject: [cAos] Re: cAos]  RPM issues
In-Reply-To: <Pine.LNX.4.44.0307231550440.12826-100000@swampfox.owlriver.com>
References: <Pine.LNX.4.56.0307231439200.25534@queeg.home.squyres.com> <Pine.LNX.4.44.0307231550440.12826-100000@swampfox.owlriver.com>
Message-ID: <20030723201411.GC12282@titan.runlevelzero.net>

On Wed, Jul 23, 2003 at 04:04:00PM -0400, R P Herrold told me:
> As one gets more comportable with packaging, the .spec files 
> get more ornate.  The rpm, the linux kernel, and the python 
> series .spec files are really about the most complex 
> human-maintained ones about.

Simple linux kernel SPEC:

   http://packages.caosity.org/cAos-1/i686/creation/linux-2.4.21-2caos/SPECS/linux.spec

But with that said, I have not built in the code to handle multiple
architectures (yet). But that should not add that much as long as I am not
trying to support every architecture under the sun in this one SPEC!

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From jsquyres at lam-mpi.org  Wed Jul 23 14:20:04 2003
From: jsquyres at lam-mpi.org (Jeff Squyres)
Date: Wed, 23 Jul 2003 17:20:04 -0400 (EDT)
Subject: [cAos] Re: cAos]  RPM issues
In-Reply-To: <Pine.LNX.4.44.0307231550440.12826-100000@swampfox.owlriver.com>
References: <Pine.LNX.4.44.0307231550440.12826-100000@swampfox.owlriver.com>
Message-ID: <Pine.LNX.4.56.0307231713210.25534@queeg.home.squyres.com>

On Wed, 23 Jul 2003, R P Herrold wrote:

> You are also an unfamiliar face as a poster on the RH hosted rpm-list,
> but many of the questions you raise have been addresed there.  When I
> see one surfacing enough times, it gets integrated into the rpm.org
> website.

Thanks -- sorry to duplicate old posts.  :-(

> Conditional options are solved lots of ways -- as a couterpoint, the
> 'unison' srpm has multiple branches which require uncommenting differing
> paths, depending on whether it is being built in a Tk/Tcl, a gtk, or a
> traditional X widget environment.

Gotcha.  Is this an alternate to a configure script?

> Your use of defines moves that out of .spec file options, but is more
> opaque to some-one who does not know the details of your package.
> Conventioanlly this is addressed with commentary in the .spec and in a
> README.

True.  I guess I view the specfile as a packging system, not as a
configuration system.  I'd rather have as much logic and configuration
issues consolidated in my package's configure/build system, where I have
already invested a lot of time and effort and already has a lot of logic
and infrastructure.  More specifically, I'd prefer to not have to
effectively have two sets of configuration -- one in my GNU configure
script, and one in the specfile.  instead, let the specfile pass through
all this information to the package's configuration/build system (whether
it's a configure script or otherwise) rather than try to replace or make
some decisions for it.

-- 
{+} Jeff Squyres
{+} jsquyres at lam-mpi.org
{+} http://www.lam-mpi.org/


From lance at uklinux.net  Wed Jul 23 14:37:40 2003
From: lance at uklinux.net (Lance Davis)
Date: Wed, 23 Jul 2003 22:37:40 +0100 (BST)
Subject: [cAos] RPM issues
In-Reply-To: <Pine.LNX.4.56.0307231439200.25534@queeg.home.squyres.com>
Message-ID: <Pine.LNX.4.44.0307232232210.25804-100000@s1.uklinux.net>

Weird, there was a similar post to the rhl-devel list that I was just 
thinking about concerning the rebuilding of a package from source 
with different options breaking auto updates, I'll forward it to the list 
...

I suppose what we really want is for the options to the build to be 
stored somewhere (in the rpm db ??) , and used by the updater (yum ?) to 
rebuild the src rpm with the same set of options, produce the modified rpm, and install it, rather 
than blindly installing the standard rpm with standard options.

It shouldnt be that hard to do and would make the whole system much more 
usable :)

You get your custom distro bits auto-updated ..

Of course it may also involve a different set of dependencies ...

Cheers

Lance

-- uklinux.net - The ISP of choice for the discerning Linux user.



From lance at uklinux.net  Wed Jul 23 14:38:42 2003
From: lance at uklinux.net (Lance Davis)
Date: Wed, 23 Jul 2003 22:38:42 +0100 (BST)
Subject: [cAos] Re: my thoughts on package management (fwd)
Message-ID: <Pine.LNX.4.44.0307232238310.25804-100000@s1.uklinux.net>


-- 
uklinux.net - The ISP of choice for the discerning Linux user. 

---------- Forwarded message ----------
Date: Wed, 23 Jul 2003 12:20:38 -0700
From: Robert LeBlanc <rjl at renaissoft.com>
Reply-To: rhl-devel-list at redhat.com
To: rhl-devel-list at redhat.com
Subject: Re: my thoughts on package management

At 02:14 2003/07/23, Ali-Reza Anghaie wrote:
>On Wednesday 23 July 2003 05:00, Robert LeBlanc wrote:
>
> > As a case in point, if I happen to use IBM DB2 as my database of choice
> > (or necessity) on a given server, I'll end up having to (re)build
> > packages like PHP from sources in order to configure --with-ibm-db2 or
> > somesuch.  The RPM-based PHP distributions won't have been compiled with
>
>And your vendor doesn't provide such packages? I'd think for something as
>'enterprise' as DB2 is there are base changes like this that IBM would
>provide the new based-on-RH RPMs.

It's not entirely fair (or effective) to try to pin this issue on the 
vendors, expecting them to solve every conceivable incompatibility 
issue.  In this example I singled out IBM DB2, but the same problem applies 
to many other packages, whether they're closed-source or not.  If I 
download a MySQL (or PHP, or Apache, or...) binary distribution, I have no 
guarantee that it has all the necessary options compiled into it for my 
specific needs.

The problem at the root of all this is that if I ever need to rebuild 
anything from sources, I break the auto-update chain for that package.  The 
fact that I've applied a (developer-defined) customization effectively 
means I can no longer have security updates and bug-fixes applied without 
doing them by hand.  What I'd rather see is a system flexible enough to 
detect (e.g. by reading the equivalent of a config.status file) the 
configuration options that were used to build a package in the first place, 
and then applying these to updated sources--*or*--have it search for a 
binary distribution that was compiled with those specific options enabled.

The latter may in the end be the more feasible option for RH.  Essentially 
have the RPM information itself keep track of what options were used to 
compile the package, so that people who need a set of binaries compiled 
with options X, Y, and J can search on this basis, and make this a 
requirement for any auto-updates.

Robert LeBlanc


--
Rhl-devel-list mailing list
Rhl-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/rhl-devel-list



From lance at uklinux.net  Wed Jul 23 14:40:25 2003
From: lance at uklinux.net (Lance Davis)
Date: Wed, 23 Jul 2003 22:40:25 +0100 (BST)
Subject: [cAos] Re: my thoughts on package management (fwd)
Message-ID: <Pine.LNX.4.44.0307232239040.25804-100000@s1.uklinux.net>

ah - I missed the standard rh centric reply ...

---------- Forwarded message ----------
Date: Wed, 23 Jul 2003 15:58:35 -0400
From: Jeff Johnson <jbj at redhat.com>
Reply-To: rhl-devel-list at redhat.com
To: rhl-devel-list at redhat.com
Subject: Re: my thoughts on package management

On Wed, Jul 23, 2003 at 12:20:38PM -0700, Robert LeBlanc wrote:

<snip>

There are two problems here:
	1) how the build system is set up.
	2) how the package was built.

The build system for RHL is setup by using build dependencies for all but
a handful of packages like gcc and make.

How the package was built is encoded in the spec file, and rpm by design
guarantees that each and every rpm started from a spec file, virgin sources,
etc and ran to completion in some build system.

Yes there is no explicit config.status, basically because there is no need
if you are using RHL packages, or custom modifications of RHL packages,
or simple additions to RHL distros.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj at redhat.com (jbj at jbj.org)
Chapel Hill, NC


--
Rhl-devel-list mailing list
Rhl-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/rhl-devel-list



From jsquyres at lam-mpi.org  Wed Jul 23 15:05:42 2003
From: jsquyres at lam-mpi.org (Jeff Squyres)
Date: Wed, 23 Jul 2003 18:05:42 -0400 (EDT)
Subject: [cAos] RPM issues
Message-ID: <Pine.LNX.4.56.0307231805110.25534@queeg.home.squyres.com>

On Wed, 23 Jul 2003, Greg Kurtzer wrote:

> So the only other idea that I had was to do something using the internal
> SPEC %defines as boolean switches:
>
> Start with...
>
>    # bools
>    %define gnu    0
>    %define pgi    1
>    %define gm     1
>    %define tm     0
>
> and then...
>
>    %if %{gm}
>        %define config_opts --with-gm=/opt/gm
>        %define release %{rel}_gm
>    %endif
>    %if %{pgi}
>        %define c_compiler pgicc
>        %define compiler_path /usr/pgi/linux86
>        %define c_compiler gcc
>        %define compiler_path /usr/pgi/linux86
>        %define setenvs export PATH=$PATH:%{compiler_path}/bin; export %PGI=%{compiler_path}/..; export CC="%{compiler_path}/bin/pgcc"; export %FC="/usr/pgi/linux86/bin/pgf77"; export F90="%{compiler_path}/bin/pgf90"
>        %define extralibs -L%{compiler_path}/lib -lpgc
>        %define extraldopts -L%{compiler_path}/lib -lpgc
>        %define release %{release}_pgi
>    %endif
>
> and then...
>
>    %build
>    %setenvs
>    %configure %{config_opts}

I think I'm still a little uncomfortable with this, for a few reasons:

1. hard-coding paths is what I want to avoid.  Paths such as /opt/gm
   and /usr/pgi/... are typically local decisions.  So even though
   there would be a group of easy bool's up top to modify, you'll
   likely still have to modify other paths elsewhere (perhaps after
   you changed the bool, --rebuild'ed the package and wondered why LAM
   didn't get Myrinet support).

   These should be (and ususally are) options to configure (either
   through environment variables or command-line switches), and
   therefore set by the user (preferably without editing the specfile;
   see below).

2. -L and -l switches should definitely be able to be determined by
   the configure script.  The specfile above reminds me very much of
   the "bad old days" when software was distributed with stock
   Makefiles and administrators had to hand-edit them to suit their
   local environment (editing paths, -L and -I flags, etc.).

   configure scripts were created to solve this problem (well, "mostly
   solve" ;-), and we shouldn't be trying to subvert its role in the
   configuration/build process.

3. If you want the RPM to be built with the pgi compiler, the RPM
   builder's environment should already be setup to use the pgi
   compiler.  It scares me to see a specfile that overrides
   environment variables.  I guess this reflects my view that the
   specfile is not the configuration system -- it's just the packaging
   system.

   I think people are already well-accustomed to setting environment
   variables such as CC before running configure; I think the same
   rule should apply here -- you setenv/export CC before running
   rpmbuild.

   export CC=gcc
   rpmbuild --define 'Release: 1caos_gcc' ....

   export CC=pgcc
   rpmbuild --define 'Release: 1caos_pgi' ...

   And so on.

So while adding the relevant paths, -L, -I, etc. variables to the
specfile is convenient, I think it's really not in the purvue of the
specfile to do this.  The configure script should figure all of this
out.

Hence, (in my view, at least) it all comes down to the configure
script.

There's two [main] ways to modify configure's behavior: 1) through
environment variables, and 2) through command-line switches.

The environment variables method still works, effectively "passing
through" the specfile (i.e., as shown above, if you set CC before
running rpmbuild, the value will be visible to the configure script).
So there's no need to augment/change that method.

However, you cannot modify what is put on the package's configure
command line without editing the specfile.  Hence, my previous post
suggested a %{config_options}-like approach, where you can directly
modify/augment the command line options that are passed to the
package's configure script (without editing the specfile).

I'm not trying to advocate putting a lot of configuration information
in the specfile; I really want to keep all the configuration
information and decisions in the configure script (well, as much of it
as possible).  Although it's probably impossible to totally divorce
the configuration system from the packaging system, I think the "grey
line" between the two could be a bit more distinct, and we should try
to observe the differences as much as possible.

-----

All of this, of course, is just my $0.02 -- none of this is intended
to be a flame at all (I'm new and don't know any of you, so I don't
want my words to be taken as a challenge!).  :-)

-- 
{+} Jeff Squyres
{+} jsquyres at lam-mpi.org
{+} http://www.lam-mpi.org/


From greg at runlevelzero.net  Wed Jul 23 15:43:09 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Wed, 23 Jul 2003 15:43:09 -0700
Subject: [cAos] RPM issues
In-Reply-To: <Pine.LNX.4.56.0307231805110.25534@queeg.home.squyres.com>
References: <Pine.LNX.4.56.0307231805110.25534@queeg.home.squyres.com>
Message-ID: <20030723224309.GA13872@titan.runlevelzero.net>

On Wed, Jul 23, 2003 at 06:05:42PM -0400, Jeff Squyres told me:
> I think I'm still a little uncomfortable with this, for a few reasons:
> 
> 1. hard-coding paths is what I want to avoid.  Paths such as /opt/gm
>    and /usr/pgi/... are typically local decisions.  So even though
>    there would be a group of easy bool's up top to modify, you'll
>    likely still have to modify other paths elsewhere (perhaps after
>    you changed the bool, --rebuild'ed the package and wondered why LAM
>    didn't get Myrinet support).

Agreed.

> 2. -L and -l switches should definitely be able to be determined by
>    the configure script.  The specfile above reminds me very much of
>    the "bad old days" when software was distributed with stock
>    Makefiles and administrators had to hand-edit them to suit their
>    local environment (editing paths, -L and -I flags, etc.).
> 
>    configure scripts were created to solve this problem (well, "mostly
>    solve" ;-), and we shouldn't be trying to subvert its role in the
>    configuration/build process.

Agreed. It was just an example to demonstrate the kind of things one can do.


<snip...>

Agreed with all of your points made.

> I'm not trying to advocate putting a lot of configuration information
> in the specfile; I really want to keep all the configuration
> information and decisions in the configure script (well, as much of it
> as possible).  Although it's probably impossible to totally divorce
> the configuration system from the packaging system, I think the "grey
> line" between the two could be a bit more distinct, and we should try
> to observe the differences as much as possible.

OK. So if we take your model (which is very reasonable), and suggest that for
all packages part of cAos that have various build options, we should implement
the same method of specifying the configure options and variables (ie. 
rpmbuild --define '...').

> All of this, of course, is just my $0.02 -- none of this is intended
> to be a flame at all (I'm new and don't know any of you, so I don't
> want my words to be taken as a challenge!).  :-)

Flame? :) I appreciate this comment, but don't worry about it. The only time I
think I would feel challenged is if you <accent type=british>challenged me to 
a duel</accent> (or any of us).

Thanks!
Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From jsquyres at lam-mpi.org  Thu Jul 24 04:09:36 2003
From: jsquyres at lam-mpi.org (Jeff Squyres)
Date: Thu, 24 Jul 2003 07:09:36 -0400 (EDT)
Subject: [cAos] RPM issues
In-Reply-To: <20030723224309.GA13872@titan.runlevelzero.net>
References: <Pine.LNX.4.56.0307231805110.25534@queeg.home.squyres.com>
 <20030723224309.GA13872@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.56.0307240706090.11897@queeg.home.squyres.com>

On Wed, 23 Jul 2003, Greg Kurtzer wrote:

> [snipped]
> > I'm not trying to advocate putting a lot of configuration information
> > in the specfile; I really want to keep all the configuration
> > information and decisions in the configure script (well, as much of it
> > as possible).  Although it's probably impossible to totally divorce
> > the configuration system from the packaging system, I think the "grey
> > line" between the two could be a bit more distinct, and we should try
> > to observe the differences as much as possible.
>
> OK. So if we take your model (which is very reasonable), and suggest
> that for all packages part of cAos that have various build options, we
> should implement the same method of specifying the configure options and
> variables (ie.  rpmbuild --define '...').

Yes, I think that could be useful -- if people find the overall model
acceptable.  Although the semantics and mechanisms are somewhat simple,
the overall philosophy is a bit different from traditional specfile
construction (at least in my admittedly limited experience).

It would probably be good to have some kind of convention about how to
notate that options were passed in on the command line when building the
RPM, too, such as tweaking the release number, putting something in the
%description, or whatever.

-- 
{+} Jeff Squyres
{+} jsquyres at lam-mpi.org
{+} http://www.lam-mpi.org/


From ssharkey at linuxunlimited.com  Fri Jul 25 09:48:55 2003
From: ssharkey at linuxunlimited.com (Scott Sharkey)
Date: 25 Jul 2003 12:48:55 -0400
Subject: [cAos] RPM issues
In-Reply-To: <Pine.LNX.4.56.0307240706090.11897@queeg.home.squyres.com>
References: <Pine.LNX.4.56.0307231805110.25534@queeg.home.squyres.com>
	 <20030723224309.GA13872@titan.runlevelzero.net>
	 <Pine.LNX.4.56.0307240706090.11897@queeg.home.squyres.com>
Message-ID: <1059151734.13105.11.camel@stingray.lanshark.com>

Well, this looks like as good a place to jump in as any other...

Hi all!

My name is Scott Sharkey, and I run a linux consultancy in Columbus,
Ohio (Hi Russ!).  I've just joined the caos project, and have been
reading the list for about a week trying to get caught up.  I've
volunteered to do some package maintenance, and to help out however
I can.  I've been interested in doing a project similar to this for a
while, and have done some baby steps on my own.  I can program (C, C++,
Python, PHP currently) and have spent a fair amount of time in the
bowels of anaconda and making RedHat derivative distributions.

Anyway, short intro out of the way.  The issue that Jeff has raised
has been bothering me about RPM's for a while.  The need to have one
spec file which can be used to build different variations of the base
package (with/without mysql support, turn that flag on/off, etc) is
pretty important.  I think that's one of the reasons why Gentoo is
growing in popularity.  I am gonna start experimenting with Jeff's
methods one some RPMs I maintain.  I do think we need some kind of
convention for "marking" what options were used to compile a specific
RPM, just for sanity sake.

Anyway, in discussions with Greg, I've come up with a few questions of
my own.

#1) what policy should the distribution follow as regards "optional"
patches for distributed packages?  In other words, if we have a package
called, for instance, "postfix", is it reasonable to assume a relatively
pristine packaging, with only the changes necessary to make it fit with
the caos distribution?  Or, if there are generally useful patches
available, should they be incorporated?  Essentially, what is the
expectation that we want everyone using the caos system to have?
How do we indicate that the package has been patched, and what patches
have been applied?  

#2) and somewhat related, what licenses will be acceptable to be
included in a caos distribution?  Do we want to follow something like
Debian's relatively strict policy, or a more loosely defined one, or
something else.  I know the idea is an open-source distribution, but
there is a wide variety of open-source-like licenses available.  To
me, open-source is pretty broad, and I'm not real fantical, but what
about as a policy?

Thanks!
-Scott Sharkey

ssharkey at linuxunlimited.com






From lance at uklinux.net  Fri Jul 25 10:06:34 2003
From: lance at uklinux.net (Lance Davis)
Date: Fri, 25 Jul 2003 18:06:34 +0100 (BST)
Subject: [cAos] rpms - confused
Message-ID: <Pine.LNX.4.44.0307251757530.28140-100000@s1.uklinux.net>

I'm also a bit confused by what we need to do ...

For example our bash.spec has the same tarball as rh9's, but they have an 
extra 30 patches ... ??

Also I took a look at db4, theer is a new version (4.1.25) at sleepycat 
that is file compatible with the one in rh9 ,  (4.0.14) .

severn has an rpm for 4.1.25, so whch do we want ti use, and do we need to 
write the SPEC file from scratch, or base it on redhats one ( which is 
GPL) .

IMHO the latter should be more secure (wont miss security patches) and 
should get us going quicker, but then there may be rh stuff to remove and 
how do we decide which ??

Regards
Lance


-- 
uklinux.net - The ISP of choice for the discerning Linux user. 



From jsquyres at lam-mpi.org  Fri Jul 25 10:10:31 2003
From: jsquyres at lam-mpi.org (Jeff Squyres)
Date: Fri, 25 Jul 2003 13:10:31 -0400 (EDT)
Subject: [cAos] RPM issues
In-Reply-To: <1059151734.13105.11.camel@stingray.lanshark.com>
References: <Pine.LNX.4.56.0307231805110.25534@queeg.home.squyres.com> 
 <20030723224309.GA13872@titan.runlevelzero.net> 
 <Pine.LNX.4.56.0307240706090.11897@queeg.home.squyres.com>
 <1059151734.13105.11.camel@stingray.lanshark.com>
Message-ID: <Pine.LNX.4.56.0307251304510.11897@queeg.home.squyres.com>

On Fri, 25 Jul 2003, Scott Sharkey wrote:

> #2) and somewhat related, what licenses will be acceptable to be
> included in a caos distribution?  Do we want to follow something like
> Debian's relatively strict policy, or a more loosely defined one, or
> something else.  I know the idea is an open-source distribution, but
> there is a wide variety of open-source-like licenses available.  To me,
> open-source is pretty broad, and I'm not real fantical, but what about
> as a policy?

This is actually a most excellent question.

It is far, Far, *FAR* better to figure out license issues at the beginning
of a project than later down the road (trust me; I've been there :-( ).
Particularly in the current US legal climate, it is better to be safe
distributing software with an established pedigree/copyright than to risk
having your licence challenged because the copyright was not established
properly.

There's two issues here: copyrights/licenses of the packages that are
included in cAos and the copyright/license of cAos-original code itself.

IANAL, but my interpretation of LAM's license is that it is essentially
the modified BSD license (with "Indiana University" instead of "Regents of
California", and only have to give credit in the docs, not in the
software).  Hence, it's fine for inclusion in cAos.

Who works on the cAos code itself?  Does it have an established pedigree?

I know that many/most of you are probably rolling your eyes right now, and
wishing I would just shut up.  :-)  But trust me -- get it over with now
and setup a few procedures (assigning copyrights, check your employement
contract, etc.).  Can you say "SCO"?  More importantly -- SCO aside -- if
cAos doesn't have a legally provable copyright/license, no .com's will
want to touch it.

Just my $0.02...

-- 
{+} Jeff Squyres
{+} jsquyres at lam-mpi.org
{+} http://www.lam-mpi.org/


From greg at runlevelzero.net  Fri Jul 25 12:52:46 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Fri, 25 Jul 2003 12:52:46 -0700
Subject: [cAos] RPM issues
In-Reply-To: <1059151734.13105.11.camel@stingray.lanshark.com>
References: <Pine.LNX.4.56.0307231805110.25534@queeg.home.squyres.com> <20030723224309.GA13872@titan.runlevelzero.net> <Pine.LNX.4.56.0307240706090.11897@queeg.home.squyres.com> <1059151734.13105.11.camel@stingray.lanshark.com>
Message-ID: <20030725195246.GE6819@titan.runlevelzero.net>

On Fri, Jul 25, 2003 at 12:48:55PM -0400, Scott Sharkey told me:
> Anyway, in discussions with Greg, I've come up with a few questions of
> my own.
> 
> #1) what policy should the distribution follow as regards "optional"
> patches for distributed packages?  In other words, if we have a package
> called, for instance, "postfix", is it reasonable to assume a relatively
> pristine packaging, with only the changes necessary to make it fit with
> the caos distribution?  Or, if there are generally useful patches
> available, should they be incorporated?  Essentially, what is the
> expectation that we want everyone using the caos system to have?
> How do we indicate that the package has been patched, and what patches
> have been applied?  

I would say that this is the package maintainers call. Here are the two
scenarios:

   1- Use a pristine source tree, and just repackage wrapped in RPM
   2- Do a pristine version and a patched version (I was thinking of doing
      this with the kernel and a cox kernel)
   3- Distribute one patched version

As far as 2 goes. This means there are going to be a lot of extra packages in
the distro and it may get confusing for users. Maybe this is only provided
when the community itself expresses enough interest in a particular
patch/build. In the most basic terms, this is a separate package that just
_better_ be configured to conflict with the other...

Number 3 is IMHO up the maintainer themselves. This may mean that there is
substantially more work for the maintainers. For example, if someone decides
to include a patch, and later a bug is found. The maintainer will either have
to work with the patch maintainer or the source tree maintainer to determine
what caused the bug. When dealing with just the pristine package, the
maintainer may just forward the bug to the source tree maintainer, monitor the
fix progress, and then repackage when the fix has been released.

Something to consider is that if the maintainer is packaging up a version or
patch that the community feels should be changed they will probably get lots
of bug reports or feature requests! :)

> #2) and somewhat related, what licenses will be acceptable to be
> included in a caos distribution?  Do we want to follow something like
> Debian's relatively strict policy, or a more loosely defined one, or
> something else.  I know the idea is an open-source distribution, but
> there is a wide variety of open-source-like licenses available.  To
> me, open-source is pretty broad, and I'm not real fantical, but what
> about as a policy?

Thanks for bringing this up!

I will not distribute anything that is not an Open Source license. Now, what
is an Open Source license? Maybe ones that are OSI approved? Can it be modeled
from an OSI approved license (ie. the BSD or GPL)?

Here are some of the points that I would need for me to feel comfortable
including in cAos:

   - Must be freely redistributable (both binary and source)
   - Must allow and encourage changes
   - Must not be more restrictive then copywrite law

Just off the top of my head (so I am sure there are more), and I am a far cry
from someone that knows the legalities well.

While I don't think that we need to be strict, I think that each license must
aggree to some set or guidlines that we define. It would be the package
maintainers role to understand the distribution rights of the package license.
It is all of our responsiability to determine what those guidlines are.

Comments welcome!

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From greg at runlevelzero.net  Fri Jul 25 13:28:50 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Fri, 25 Jul 2003 13:28:50 -0700
Subject: [cAos] RPM issues
In-Reply-To: <Pine.LNX.4.56.0307251304510.11897@queeg.home.squyres.com>
References: <Pine.LNX.4.56.0307231805110.25534@queeg.home.squyres.com> <20030723224309.GA13872@titan.runlevelzero.net> <Pine.LNX.4.56.0307240706090.11897@queeg.home.squyres.com> <1059151734.13105.11.camel@stingray.lanshark.com> <Pine.LNX.4.56.0307251304510.11897@queeg.home.squyres.com>
Message-ID: <20030725202850.GF6819@titan.runlevelzero.net>

On Fri, Jul 25, 2003 at 01:10:31PM -0400, Jeff Squyres told me:
> This is actually a most excellent question.
> 
> It is far, Far, *FAR* better to figure out license issues at the beginning
> of a project than later down the road (trust me; I've been there :-( ).
> Particularly in the current US legal climate, it is better to be safe
> distributing software with an established pedigree/copyright than to risk
> having your licence challenged because the copyright was not established
> properly.

Jeff is right. Lets hammer this out now at least in a beta form. We can add to
the guidline lists later as needed.

> There's two issues here: copyrights/licenses of the packages that are
> included in cAos and the copyright/license of cAos-original code itself.

Do you mean the cAos code as the installer, scripts, or site engine, etc..?

> Who works on the cAos code itself?  Does it have an established pedigree?

Right now, I do. Very soon I think there will be more help from the communiy
and others on this list (as soon as we get a few more things hammered out).

> I know that many/most of you are probably rolling your eyes right now, and
> wishing I would just shut up.  :-)  But trust me -- get it over with now
> and setup a few procedures (assigning copyrights, check your employement
> contract, etc.).  Can you say "SCO"?  More importantly -- SCO aside -- if
> cAos doesn't have a legally provable copyright/license, no .com's will
> want to touch it.

lol, I agree!

Thanks!
Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From greg at runlevelzero.net  Fri Jul 25 13:34:42 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Fri, 25 Jul 2003 13:34:42 -0700
Subject: [cAos] rpms - confused
In-Reply-To: <Pine.LNX.4.44.0307251757530.28140-100000@s1.uklinux.net>
References: <Pine.LNX.4.44.0307251757530.28140-100000@s1.uklinux.net>
Message-ID: <20030725203442.GG6819@titan.runlevelzero.net>

On Fri, Jul 25, 2003 at 06:06:34PM +0100, Lance Davis told me:
> I'm also a bit confused by what we need to do ...
> 
> For example our bash.spec has the same tarball as rh9's, but they have an 
> extra 30 patches ... ??

Yes. Which means extra work for the package maintainer... I just posted a
message about the maintainers duties, and it is their choice to include
patches or not (of course it must be justified).

Dealing with RedHat's patches can be a mess, and unless there is a real need
or community desire for a specific patch, then I don't think it is necessary.

BTW, I hate RedHat's patch to bash that puts long [tab]-[tab] completions into
a less type interface!

> Also I took a look at db4, theer is a new version (4.1.25) at sleepycat 
> that is file compatible with the one in rh9 ,  (4.0.14) .

I saw that too.

> severn has an rpm for 4.1.25, so whch do we want ti use, and do we need to 
> write the SPEC file from scratch, or base it on redhats one ( which is 
> GPL) .

Personally, I would always start with pristine source once again unless there
is a good reason to include a particular patch (ie. security or reasonable
feature addition).

> IMHO the latter should be more secure (wont miss security patches) and 
> should get us going quicker, but then there may be rh stuff to remove and 
> how do we decide which ??

Security fixes should also come from the maintainers themselves in the form of
new releases. RedHat also has lots of patches because they tend not to
increment source code versions after a distribution has been released (thus
the only way to fix is to patch a back ported fix).

Does that help?
Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From lance at uklinux.net  Fri Jul 25 15:28:01 2003
From: lance at uklinux.net (Lance Davis)
Date: Fri, 25 Jul 2003 23:28:01 +0100 (BST)
Subject: [cAos] Re: Packages..
In-Reply-To: <20030725221654.GB23162@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307252325470.20318-100000@s1.uklinux.net>

On Fri, 25 Jul 2003, Greg Kurtzer wrote:

> On Fri, Jul 25, 2003 at 11:12:53PM +0100, Lance Davis told me:
> > 
> > BTW the DB4 license in RH spec file says GPL and it definitely isnt ;) , 
> > thus justifying not copying rh9 spec files :)
> 
> It is funny, I noticed this almost a month ago when we were discussing the
> idea of removing the propriatary stuff from RHEL. We discovered that it was
> not safe to trust the RH packagers! :)

But what license do you describe it as ?? 'sleepycat' ?? But is it OSI 
approved  ??

Lance

cc'ed to list
-- 
uklinux.net - The ISP of choice for the discerning Linux user. 




From lance at uklinux.net  Fri Jul 25 15:30:22 2003
From: lance at uklinux.net (Lance Davis)
Date: Fri, 25 Jul 2003 23:30:22 +0100 (BST)
Subject: [cAos] Re: Packages..
In-Reply-To: <Pine.LNX.4.44.0307252325470.20318-100000@s1.uklinux.net>
Message-ID: <Pine.LNX.4.44.0307252329350.20318-100000@s1.uklinux.net>

On Fri, 25 Jul 2003, Lance Davis wrote:

> On Fri, 25 Jul 2003, Greg Kurtzer wrote:
> 
> > On Fri, Jul 25, 2003 at 11:12:53PM +0100, Lance Davis told me:
> > > 
> > > BTW the DB4 license in RH spec file says GPL and it definitely isnt ;) , 
> > > thus justifying not copying rh9 spec files :)
> > 
> > It is funny, I noticed this almost a month ago when we were discussing the
> > idea of removing the propriatary stuff from RHEL. We discovered that it was
> > not safe to trust the RH packagers! :)
> 
> But what license do you describe it as ?? 'sleepycat' ?? But is it OSI 
> approved  ??

aah - they call it the 'Berkeley DB public license' .



-- 
uklinux.net - The ISP of choice for the discerning Linux user. 



From greg at runlevelzero.net  Fri Jul 25 15:33:41 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Fri, 25 Jul 2003 15:33:41 -0700
Subject: [cAos] Re: Packages..
In-Reply-To: <Pine.LNX.4.44.0307252325470.20318-100000@s1.uklinux.net>
References: <20030725221654.GB23162@titan.runlevelzero.net> <Pine.LNX.4.44.0307252325470.20318-100000@s1.uklinux.net>
Message-ID: <20030725223341.GC7396@titan.runlevelzero.net>

Sleepcat info:


Sleepycat distributes all versions of Berkeley DB under a "dual license." For
customers building open source applications, the license permits you to use
any Sleepycat product at no charge with the condition that you make the
complete source code for your application available for free public
redistribution. If you do not want to freely release the source code for your
application, you may purchase a license from Sleepycat Software. For pricing
information, or if you have further questions on licensing, please contact us.

License excerpt (which looks like a BSD, so just make sure that this license 
and copywrite is distributed in the RPM itself).


The following is the license that applies to this copy of the Berkeley DB
software.  For a license to use the Berkeley DB software under conditions
other than those described here, or to purchase support for this software,
please contact Sleepycat Software at one of the following addresses:

   Sleepycat Software   info at sleepycat.com
   118 Tower Road    +1 (617) 876-0858
   Lincoln, MA 01773 877-SLEEPYCAT (toll-free, USA only)
   USA

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
/*
 * Copyright (c) 1990-2003
 * Sleepycat Software.  All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. Redistributions in any form must be accompanied by information on
 *    how to obtain complete source code for the DB software and any
 *    accompanying software that uses the DB software.  The source code
 *    must either be included in the distribution or be available for no
 *    more than the cost of distribution plus a nominal fee, and must be
 *    freely redistributable under reasonable conditions.  For an
 *    executable file, complete source code means the source code for all
 *    modules it contains.  It does not include source code for modules or
 *    files that typically accompany the major components of the operating
 *    system on which the executable file runs.
 *
 * THIS SOFTWARE IS PROVIDED BY SLEEPYCAT SOFTWARE ``AS IS'' AND ANY EXPRESS
 * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
 * WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
 * NON-INFRINGEMENT, ARE DISCLAIMED.  IN NO EVENT SHALL SLEEPYCAT SOFTWARE
 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
 * THE POSSIBILITY OF SUCH DAMAGE.
 */
/*
 * Copyright (c) 1990, 1993, 1994, 1995
 * The Regents of the University of California.  All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. Neither the name of the University nor the names of its contributors
 *    may be used to endorse or promote products derived from this software
 *    without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 */
/*
 * Copyright (c) 1995, 1996
 * The President and Fellows of Harvard University.  All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. Neither the name of the University nor the names of its contributors
 *    may be used to endorse or promote products derived from this software
 *    without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY HARVARD AND ITS CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL HARVARD OR ITS CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 */




On Fri, Jul 25, 2003 at 11:28:01PM +0100, Lance Davis told me:
> On Fri, 25 Jul 2003, Greg Kurtzer wrote:
> 
> > On Fri, Jul 25, 2003 at 11:12:53PM +0100, Lance Davis told me:
> > > 
> > > BTW the DB4 license in RH spec file says GPL and it definitely isnt ;) , 
> > > thus justifying not copying rh9 spec files :)
> > 
> > It is funny, I noticed this almost a month ago when we were discussing the
> > idea of removing the propriatary stuff from RHEL. We discovered that it was
> > not safe to trust the RH packagers! :)
> 
> But what license do you describe it as ?? 'sleepycat' ?? But is it OSI 
> approved  ??
> 
> Lance
> 
> cc'ed to list
> -- 
> uklinux.net - The ISP of choice for the discerning Linux user. 
> 
> 
> _______________________________________________
> cAos mailing list
> cAos at runlevelzero.net
> http://www.caosity.org/mailman/listinfo/caos

-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From greg at runlevelzero.net  Fri Jul 25 15:36:13 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Fri, 25 Jul 2003 15:36:13 -0700
Subject: [cAos] Re: Packages..
In-Reply-To: <Pine.LNX.4.44.0307252329350.20318-100000@s1.uklinux.net>
References: <Pine.LNX.4.44.0307252325470.20318-100000@s1.uklinux.net> <Pine.LNX.4.44.0307252329350.20318-100000@s1.uklinux.net>
Message-ID: <20030725223613.GD7396@titan.runlevelzero.net>

On Fri, Jul 25, 2003 at 11:30:22PM +0100, Lance Davis told me:
> aah - they call it the 'Berkeley DB public license' .

Have you seend this: 

   http://sleepycat.com/download/licensinginfo.shtml


-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From lance at uklinux.net  Fri Jul 25 15:58:08 2003
From: lance at uklinux.net (Lance Davis)
Date: Fri, 25 Jul 2003 23:58:08 +0100 (BST)
Subject: [cAos] Re: Packages..
In-Reply-To: <20030725223613.GD7396@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307252357130.20318-100000@s1.uklinux.net>

On Fri, 25 Jul 2003, Greg Kurtzer wrote:

> On Fri, Jul 25, 2003 at 11:30:22PM +0100, Lance Davis told me:
> > aah - they call it the 'Berkeley DB public license' .
> 
> Have you seend this: 
> 
>    http://sleepycat.com/download/licensinginfo.shtml

Yes - its definitely open source, but afaics not an OSI approved license. 
so as long as we are happy with that :)

Lance

-- 
uklinux.net - The ISP of choice for the discerning Linux user. 



From lance at uklinux.net  Fri Jul 25 16:16:30 2003
From: lance at uklinux.net (Lance Davis)
Date: Sat, 26 Jul 2003 00:16:30 +0100 (BST)
Subject: [cAos] email
Message-ID: <Pine.LNX.4.44.0307260012200.20318-100000@s1.uklinux.net>

Should/can we have @caosity.org (or some such) email addresses to put in 
spec file changelogs.

That way :-

1. I dont really want to use my normal email address.

2. If I leave the project , emails relevant to it can be forwarded to 
someone else.

Maybe the mails for developer at caosity.org should just be forwarded to the 
email address registered for the developer ??

Lance
-- 
uklinux.net - The ISP of choice for the discerning Linux user. 



From greg at runlevelzero.net  Fri Jul 25 16:42:45 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Fri, 25 Jul 2003 16:42:45 -0700
Subject: [cAos] email
In-Reply-To: <Pine.LNX.4.44.0307260012200.20318-100000@s1.uklinux.net>
References: <Pine.LNX.4.44.0307260012200.20318-100000@s1.uklinux.net>
Message-ID: <20030725234245.GA13946@titan.runlevelzero.net>

Interesting idea... Presently caosity.org is on my shared system, and it
(obviously) will need to be moved to a dedicated system in the _near_ future.

I see the immediate need, I am just thinking of the best and most scalable way
to deal with it. /etc/mail/virtusertable is probably the most reasonable now
(because it is a shared system), but I would prefer the aliases file (which
will affect non-caosity.org accounts).

I guess that short-term it should be the the virtusertable unless anyone else
has some insight.

Greg

On Sat, Jul 26, 2003 at 12:16:30AM +0100, Lance Davis told me:
> 
> Should/can we have @caosity.org (or some such) email addresses to put in 
> spec file changelogs.
> 
> That way :-
> 
> 1. I dont really want to use my normal email address.
> 
> 2. If I leave the project , emails relevant to it can be forwarded to 
> someone else.
> 
> Maybe the mails for developer at caosity.org should just be forwarded to the 
> email address registered for the developer ??
> 
> Lance
> -- 
> uklinux.net - The ISP of choice for the discerning Linux user. 
> 
> _______________________________________________
> cAos mailing list
> cAos at runlevelzero.net
> http://www.caosity.org/mailman/listinfo/caos

-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From lance at uklinux.net  Fri Jul 25 16:48:23 2003
From: lance at uklinux.net (Lance Davis)
Date: Sat, 26 Jul 2003 00:48:23 +0100 (BST)
Subject: [cAos] email
In-Reply-To: <20030725234245.GA13946@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307260045040.20318-100000@s1.uklinux.net>

On Fri, 25 Jul 2003, Greg Kurtzer wrote:

> I see the immediate need, I am just thinking of the best and most scalable way
> to deal with it. /etc/mail/virtusertable is probably the most reasonable now
> (because it is a shared system), but I would prefer the aliases file (which
> will affect non-caosity.org accounts).

I think we only need @caosity.org dont we ? so virtusertable works.

presumably once things get going there will be real accounts for 
developers on the box anyway and we can use procmail etc.

The alternative I guess could be to point the mx records for caosity.org 
somewhere else ...

Lance

> I guess that short-term it should be the the virtusertable unless anyone else
> has some insight.


> 
> Greg
> 
> On Sat, Jul 26, 2003 at 12:16:30AM +0100, Lance Davis told me:
> > 
> > Should/can we have @caosity.org (or some such) email addresses to put in 
> > spec file changelogs.
> > 
> > That way :-
> > 
> > 1. I dont really want to use my normal email address.
> > 
> > 2. If I leave the project , emails relevant to it can be forwarded to 
> > someone else.
> > 
> > Maybe the mails for developer at caosity.org should just be forwarded to the 
> > email address registered for the developer ??
> > 
> > Lance
> > -- 
> > uklinux.net - The ISP of choice for the discerning Linux user. 
> > 
> > _______________________________________________
> > cAos mailing list
> > cAos at runlevelzero.net
> > http://www.caosity.org/mailman/listinfo/caos
> 
> 

-- 
uklinux.net - The ISP of choice for the discerning Linux user. 



From greg at runlevelzero.net  Fri Jul 25 16:52:29 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Fri, 25 Jul 2003 16:52:29 -0700
Subject: [cAos] email
In-Reply-To: <Pine.LNX.4.44.0307260045040.20318-100000@s1.uklinux.net>
References: <20030725234245.GA13946@titan.runlevelzero.net> <Pine.LNX.4.44.0307260045040.20318-100000@s1.uklinux.net>
Message-ID: <20030725235229.GA15059@titan.runlevelzero.net>

On Sat, Jul 26, 2003 at 12:48:23AM +0100, Lance Davis told me:
> I think we only need @caosity.org dont we ? so virtusertable works.

It works, it is just not what I wanted to maintain... Hopefully it won't be a
long standing fix.

Will you enter this in bugzilla?

> presumably once things get going there will be real accounts for 
> developers on the box anyway and we can use procmail etc.

Good point.

> The alternative I guess could be to point the mx records for caosity.org 
> somewhere else ...

Where? 

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From lance at uklinux.net  Fri Jul 25 16:56:51 2003
From: lance at uklinux.net (Lance Davis)
Date: Sat, 26 Jul 2003 00:56:51 +0100 (BST)
Subject: [cAos] email
In-Reply-To: <20030725235229.GA15059@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307260054030.20318-100000@s1.uklinux.net>

On Fri, 25 Jul 2003, Greg Kurtzer wrote:

> On Sat, Jul 26, 2003 at 12:48:23AM +0100, Lance Davis told me:
> > I think we only need @caosity.org dont we ? so virtusertable works.
> 
> It works, it is just not what I wanted to maintain... Hopefully it won't be a
> long standing fix.

What mta are you using ??

> 
> Will you enter this in bugzilla?

ok

> > The alternative I guess could be to point the mx records for caosity.org 
> > somewhere else ...
> 
> Where? 

I'd volunteer but the thought of more work to do with virtusertable - and 
anyway you know who the new developers are :)

I guess it should be easy enough to script anyway :)

Lance

-- 
uklinux.net - The ISP of choice for the discerning Linux user. 



From lance at uklinux.net  Fri Jul 25 16:53:33 2003
From: lance at uklinux.net (Lance Davis)
Date: Sat, 26 Jul 2003 00:53:33 +0100 (BST)
Subject: [cAos] another question
Message-ID: <Pine.LNX.4.44.0307260048320.20318-100000@s1.uklinux.net>

Do the docs need to be split out for subpackages ??

eg

db4
db4-utils 
db4-devel

becomes

db4
db4-docs
db4-utils
db4-devel

or

db4
db4-docs
db4-utils
db4-utils-docs
db4-devel
db4-devel-docs

also should the Group of docs be System Environment/Documentation ???

and should all packages in Base be in Group: System Environment/Base ???

( I'm sure these have been answered before ... )

Lance

-- 
uklinux.net - The ISP of choice for the discerning Linux user. 




From greg at runlevelzero.net  Fri Jul 25 17:09:40 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Fri, 25 Jul 2003 17:09:40 -0700
Subject: [cAos] email
In-Reply-To: <Pine.LNX.4.44.0307260054030.20318-100000@s1.uklinux.net>
References: <20030725235229.GA15059@titan.runlevelzero.net> <Pine.LNX.4.44.0307260054030.20318-100000@s1.uklinux.net>
Message-ID: <20030726000940.GB15059@titan.runlevelzero.net>

On Sat, Jul 26, 2003 at 12:56:51AM +0100, Lance Davis told me:
> What mta are you using ??

Sendmail.

> I'd volunteer but the thought of more work to do with virtusertable - and 
> anyway you know who the new developers are :)
> 
> I guess it should be easy enough to script anyway :)

that is what I was thinking...

Thanks!
Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From greg at runlevelzero.net  Fri Jul 25 17:15:18 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Fri, 25 Jul 2003 17:15:18 -0700
Subject: [cAos] another question
In-Reply-To: <Pine.LNX.4.44.0307260048320.20318-100000@s1.uklinux.net>
References: <Pine.LNX.4.44.0307260048320.20318-100000@s1.uklinux.net>
Message-ID: <20030726001518.GC15059@titan.runlevelzero.net>

On Sat, Jul 26, 2003 at 12:53:33AM +0100, Lance Davis told me:
> Do the docs need to be split out for subpackages ??

I typically don't split the docs out for each subpackage, rather group all
docs that are not /usr/share/docs/*/README|CHANGELOG|etc... and man pages
together. 

> eg
> 
> db4
> db4-utils 
> db4-devel
> 
> becomes
> 
> db4
> db4-docs
> db4-utils
> db4-devel

Yep.

> or
> 
> db4
> db4-docs
> db4-utils
> db4-utils-docs
> db4-devel
> db4-devel-docs

Nope. Too many packages.

> also should the Group of docs be System Environment/Documentation ???

Yes.

> and should all packages in Base be in Group: System Environment/Base ???

Yes, for the main package. Subpackages like devel may be somewhere like 
System Environment/Libraries.

Thoughts?

> ( I'm sure these have been answered before ... )

Yes, but not publically on the list.

Thanks!
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From lance at uklinux.net  Fri Jul 25 17:17:51 2003
From: lance at uklinux.net (Lance Davis)
Date: Sat, 26 Jul 2003 01:17:51 +0100 (BST)
Subject: [cAos] email
In-Reply-To: <20030726000940.GB15059@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307260115470.20318-100000@s1.uklinux.net>

On Fri, 25 Jul 2003, Greg Kurtzer wrote:

> On Sat, Jul 26, 2003 at 12:56:51AM +0100, Lance Davis told me:
> > What mta are you using ??
> 
> Sendmail.
> 
> > I'd volunteer but the thought of more work to do with virtusertable - and 
> > anyway you know who the new developers are :)
> > 
> > I guess it should be easy enough to script anyway :)
> 
> that is what I was thinking...

I've got some perl scripts that write to a hash, and iirc virtusertable is 
a berkeley db hash .

The locking stuff is fun with sendmail ... :)

Regards
Lance

-- 
uklinux.net - The ISP of choice for the discerning Linux user. 



From lance at uklinux.net  Fri Jul 25 17:24:39 2003
From: lance at uklinux.net (Lance Davis)
Date: Sat, 26 Jul 2003 01:24:39 +0100 (BST)
Subject: [cAos] another question
In-Reply-To: <20030726001518.GC15059@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307260118330.20318-100000@s1.uklinux.net>

On Fri, 25 Jul 2003, Greg Kurtzer wrote:

> On Sat, Jul 26, 2003 at 12:53:33AM +0100, Lance Davis told me:
> > Do the docs need to be split out for subpackages ??
> 
> I typically don't split the docs out for each subpackage, rather group all
> docs that are not /usr/share/docs/*/README|CHANGELOG|etc... and man pages
> together. 

> > db4
> > db4-docs
> > db4-utils
> > db4-utils-docs
> > db4-devel
> > db4-devel-docs
> 
> Nope. Too many packages.

What about where the devel-docs are enormous ??? can they be split out ???
> 
> > also should the Group of docs be System Environment/Documentation ???
> 
> Yes.

Do you want bugzillas for the existing spec files ???
 
> > and should all packages in Base be in Group: System Environment/Base ???
> 
> Yes, for the main package. Subpackages like devel may be somewhere like 
> System Environment/Libraries.
> 
> Thoughts?

System Environment/Base Development   ???

Lance

-- 
uklinux.net - The ISP of choice for the discerning Linux user. 



From lance at uklinux.net  Fri Jul 25 17:28:44 2003
From: lance at uklinux.net (Lance Davis)
Date: Sat, 26 Jul 2003 01:28:44 +0100 (BST)
Subject: [cAos] website problem
Message-ID: <Pine.LNX.4.44.0307260124420.11719-100000@s1.uklinux.net>

Am I doing something wrong ???

I tried to update :- http://caosity.org/pkg_modify.php?id=16

and it just says - Please associate this package with a SRPM!

???

http://caosity.org/pkg_modify.php?id=16

BTW this is cos I just uploaded src rpm for db4 

I based it on rh severn rpm, because everything seems dependant on db4 
(rpm, sendmail ) and there's lots of 'interesting' stuff with db-1.85 for 
example and I dont want to break anything to start with .

lance



-- 
uklinux.net - The ISP of choice for the discerning Linux user. 



From greg at runlevelzero.net  Fri Jul 25 17:29:13 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Fri, 25 Jul 2003 17:29:13 -0700
Subject: [cAos] another question
In-Reply-To: <Pine.LNX.4.44.0307260118330.20318-100000@s1.uklinux.net>
References: <20030726001518.GC15059@titan.runlevelzero.net> <Pine.LNX.4.44.0307260118330.20318-100000@s1.uklinux.net>
Message-ID: <20030726002913.GA15528@titan.runlevelzero.net>

On Sat, Jul 26, 2003 at 01:24:39AM +0100, Lance Davis told me:
> What about where the devel-docs are enormous ??? can they be split out ???

I would think that generally they would go under the standard docs package.

What are your thoughts (or others on the list)?

> Do you want bugzillas for the existing spec files ???

Naa, I know I have to do them... :)

> System Environment/Base Development   ???

Good for me! 
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From greg at runlevelzero.net  Fri Jul 25 17:35:58 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Fri, 25 Jul 2003 17:35:58 -0700
Subject: [cAos] website problem
In-Reply-To: <Pine.LNX.4.44.0307260124420.11719-100000@s1.uklinux.net>
References: <Pine.LNX.4.44.0307260124420.11719-100000@s1.uklinux.net>
Message-ID: <20030726003558.GB15528@titan.runlevelzero.net>

Did you select the srpm from the pull down menu? What were you trying to
update?

Here is the revelant php:

   if ( $_POST[id] ) {
      $a = mysql_query("SELECT id,owner,name,pkg_group FROM packages WHERE id = '$_POST[id]'");
      $row = mysql_fetch_array($a, MYSQL_ASSOC);
      if ( $row[owner] != $username and !$perms[osm] and $pkgs[owner] ) {
         $err = "<font color=red>You don't own this package! ($username != $row[owner])</font>\n";
      } else if ( !$row[owner] and !$perms[pkg_add] and !$perms[osm] ) {
         $err = "<font color=red>You don't have authorization to adopt this package</font>\n";
      } else if ( !$_POST[pkg_srpm] and !$perms[osm] ) {
         $err = "<font color=red>Please associate this package with a SRPM!</font>\n";

If you do not have the $_POST[pkg_srpm] it dies with that error. Was all of 
the fields populated with info when you hit submit?

Greg

On Sat, Jul 26, 2003 at 01:28:44AM +0100, Lance Davis told me:
> 
> Am I doing something wrong ???
> 
> I tried to update :- http://caosity.org/pkg_modify.php?id=16
> 
> and it just says - Please associate this package with a SRPM!
> 
> ???
> 
> http://caosity.org/pkg_modify.php?id=16
> 
> BTW this is cos I just uploaded src rpm for db4 
> 
> I based it on rh severn rpm, because everything seems dependant on db4 
> (rpm, sendmail ) and there's lots of 'interesting' stuff with db-1.85 for 
> example and I dont want to break anything to start with .
> 
> lance
> 
> 
> 
> -- 
> uklinux.net - The ISP of choice for the discerning Linux user. 
> 
> _______________________________________________
> cAos mailing list
> cAos at runlevelzero.net
> http://www.caosity.org/mailman/listinfo/caos

-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From lance at uklinux.net  Fri Jul 25 17:36:38 2003
From: lance at uklinux.net (Lance Davis)
Date: Sat, 26 Jul 2003 01:36:38 +0100 (BST)
Subject: [cAos] another question
In-Reply-To: <20030726001518.GC15059@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307260130520.11719-100000@s1.uklinux.net>

On Fri, 25 Jul 2003, Greg Kurtzer wrote:

> On Sat, Jul 26, 2003 at 12:53:33AM +0100, Lance Davis told me:
> > Do the docs need to be split out for subpackages ??
> 
> I typically don't split the docs out for each subpackage, rather group all
> docs that are not /usr/share/docs/*/README|CHANGELOG|etc... and man pages
> together. 

hmm - all the docs for db4 go in /usr/share/docs/* but the average user 
really doesnt want them unless they are going to write stuff using db4, 
which 99% arent :)

There are no man pages, just html files 

I suppose I'll have to produce man pages in the future - what fun ;)
 
Lance
-- 
uklinux.net - The ISP of choice for the discerning Linux user. 





From lance at uklinux.net  Fri Jul 25 17:38:53 2003
From: lance at uklinux.net (Lance Davis)
Date: Sat, 26 Jul 2003 01:38:53 +0100 (BST)
Subject: [cAos] website problem
In-Reply-To: <20030726003558.GB15528@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307260137290.11719-100000@s1.uklinux.net>

On Fri, 25 Jul 2003, Greg Kurtzer wrote:

> Did you select the srpm from the pull down menu? 

aha - it was empty - I think I may have been trying before the rsync had 
finished ...

its there now :)

Thanks

Lance

What were you trying to
> update?
> 
> Here is the revelant php:
> 
>    if ( $_POST[id] ) {
>       $a = mysql_query("SELECT id,owner,name,pkg_group FROM packages WHERE id = '$_POST[id]'");
>       $row = mysql_fetch_array($a, MYSQL_ASSOC);
>       if ( $row[owner] != $username and !$perms[osm] and $pkgs[owner] ) {
>          $err = "<font color=red>You don't own this package! ($username != $row[owner])</font>\n";
>       } else if ( !$row[owner] and !$perms[pkg_add] and !$perms[osm] ) {
>          $err = "<font color=red>You don't have authorization to adopt this package</font>\n";
>       } else if ( !$_POST[pkg_srpm] and !$perms[osm] ) {
>          $err = "<font color=red>Please associate this package with a SRPM!</font>\n";
> 
> If you do not have the $_POST[pkg_srpm] it dies with that error. Was all of 
> the fields populated with info when you hit submit?
> 
> Greg
> 
> On Sat, Jul 26, 2003 at 01:28:44AM +0100, Lance Davis told me:
> > 
> > Am I doing something wrong ???
> > 
> > I tried to update :- http://caosity.org/pkg_modify.php?id=16
> > 
> > and it just says - Please associate this package with a SRPM!
> > 
> > ???
> > 
> > http://caosity.org/pkg_modify.php?id=16
> > 
> > BTW this is cos I just uploaded src rpm for db4 
> > 
> > I based it on rh severn rpm, because everything seems dependant on db4 
> > (rpm, sendmail ) and there's lots of 'interesting' stuff with db-1.85 for 
> > example and I dont want to break anything to start with .
> > 
> > lance
> > 
> > 
> > 
> > -- 
> > uklinux.net - The ISP of choice for the discerning Linux user. 
> > 
> > _______________________________________________
> > cAos mailing list
> > cAos at runlevelzero.net
> > http://www.caosity.org/mailman/listinfo/caos
> 
> 

-- 
uklinux.net - The ISP of choice for the discerning Linux user. 



From herrold at owlriver.com  Sat Jul 26 14:28:35 2003
From: herrold at owlriver.com (R P Herrold)
Date: Sat, 26 Jul 2003 17:28:35 -0400 (EDT)
Subject: [cAos] success report - ISO building
Message-ID: <Pine.LNX.4.44.0307261511240.5437-200000@swampfox.owlriver.com>


I report success, with some patching, using Greg's build.pl
script to produce on an RH 8 box, from RH 8 rpms, a bootable
iso, running X in framebuffer mode.  

It is built with a differing kernel and different package set
than his 1.0 effort, and so should be generally reproduceable
for building a cAos 'nightly' test .iso on an automated 
basis with a bit more work.

The iso spontaneously reboots my AMD processor unit for 
unknown reasons and does not work there

I have extended and will provide to Greg under separate cover
some extension of the build.pl script.  I have gathered
thoughts addressing the various places my efforts failed,
usage notes, and an issues/TODO list as well.  They are 
below ... attached is the demsg's

cAos is 'slouching toward Bethlehem'  

-- Russ Herrold

 "To those seaching for truth -- not the truth of dogma and 
darkness but the truth brought by reason, search, examination, 
and inquiry, discipline is required. For faith, as well 
intentioned as it may be, must be built on facts, not fiction 
-- faith in fiction is a damnable false hope."
-- Thomas Edison 



==================================================================
Post-build session notes -- lightly proofread

Usage:
---------------

Complete rebuild
   ./bin/build.pl -d `pwd` -k `uname -r` --all --clean | tee build.log


Just clean up before tarring
   ./bin/build.pl -d `pwd` -k `uname -r` --clean 



TODO and THOUGHTS
---------------

1. copyrights and licenses throughout

2. buildhost kernel uname -r VR check AND and ARCH check to 
make sure the same kernel which is RUNNING is in the install 
process

3. verify, or carp if missing a  
	/usr/src/linux{-2.4|``uname -r}/.config 
If missing, suggest the fixup (as it is outside of our build tree 
(as though we were building chroot), we SHOULD NOT automatically 
do it.  RH stashes its .configs at: 
	/usr/src/linux/configs
nicely named and identified

4. Otherwise revert back to i386 libraries (glibc, openssl )for ISO 
-- it should NOT ever use more than noarch and i386 rpms.  Note: it does 
NOT presently seem to matter that the cloop and busybox are being 
__built__ with a later library that we are installing in the ISO 
run image (but there are probably limits here if the API or compiler 
version changes enough)

5. More elegant, space saving RPMS.archive approach -- one archive, and 
dep-resolved links only in all  -- to permit space savings; built 
as an option from a local Manifest in the destination directory
(This may permit easier bootstrapping to another RHL release or in the 
future, dropping in the overnight cAos dailies and getting a test ISO out) 

6. Generate boot.iso file in a new ./PXE/ directory for dhcp next-server 
PXE/etherboot use -- mount and export the .iso and point at the boot.iso 
as the run target for a syslinux (partially already done by HPA)

7. rsync rather than cp the RPMS.* directories to preserve links

build failure detection -- empty boot.img once -- loop mount failure?
	mount the .img and test for a sentinel file

8. Pre-build yum-arch for a files:// if installed, and insert into 
/etc/yum.conf -- remember it needs the follow links option

9. smarter rpm -i phase -- Build a RPM manifest per directory and do NOT 
include already installed dependencies to prevent erroring out

10. Writeable store: can we move or link at least parts of:
	/etc/
		initrd
		./sysconfig/	network setup
		./sshd/		keys
	/root/ 
		./sshd/         keys
	/var/run/ 
		lockfiles, pid's
	/var/spool/
		outbound email
	/var/lib/rpm/ 
		rpm -qa does not work b/c cannot write lockfiles
			(is there a RO workaround within RPM?)

11. typo cleanup throughout

12. Lobby for cloop.o in the mainline kernel to avoid having to patch and 
carry the kernel source in our build image (we need to keep the 
kernel-source package [170M] OFF the CD to permit the CD to be useful
Query -- can we carry a stripped out subset of the kernel sources just 
enough to make the module?



Boot/Run-time
--------------

21. GPL / OSI spash screen  - LPP in addition to Tux ?

22. can we detect non-frame-buffer hosts, and try an X config?   

23. or fall back to console mode anyway?  (consile BBC/Koppix at that 
point, but we can still fdisk, mkfs, rsync and set bootloader in text 
mode)

24. can we auto-login in the gdm.conf, and avoid the login screen

25. can we start an application (mozilla) rather than a DM for bootable
kiosk use?

26. Remember that we need to kill all VC's in kiosk mode



RPH - 030726
master at: couch:/var/ftp/pub/mirror/caos/caos-1/cAos_inst/README 

-------------- next part --------------
From herrold at ftp.basement.lan Sat Jul 26 17:28:07 2003
Date: Sat, 26 Jul 2003 17:23:59 -0400
From: herrold at ftp.basement.lan
To: herrold at owlriver.com
Subject: caos

[root at localhost root]# dmesg
Linux version 2.4.20-19.8 (bhcompile at stripples.devel.redhat.com) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Tue Jul 15 15:25:37 EDT 2003
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
 BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e7400 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000040fdc00 (usable)
 BIOS-e820: 00000000040fdc00 - 00000000040ff800 (ACPI data)
 BIOS-e820: 00000000040ff800 - 00000000040ffc00 (ACPI NVS)
 BIOS-e820: 00000000040ffc00 - 0000000010000000 (usable)
 BIOS-e820: 00000000fffe7400 - 0000000100000000 (reserved)
0MB HIGHMEM available.
256MB LOWMEM available.
On node 0 totalpages: 65536
zone(0): 4096 pages.
zone(1): 61440 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=linux root=f000 ramdisk=65536 BOOT_FILE=/mnt/vmlinuz 5
Initializing CPU#0
Detected 331.836 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 661.91 BogoMIPS
Memory: 252356k/262144k available (1336k kernel code, 7340k reserved, 999k data, 128k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0183f9ff 00000000 00000000 00000000
CPU:             Common caps: 0183f9ff 00000000 00000000 00000000
CPU: Intel Celeron (Mendocino) stepping 00
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch at atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfd9c3, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX [8086/7110] at 00:07.0
Limiting direct PCI/PCI transfers.
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS not found.
Starting kswapd
VFS: Disk quotas vdquot_6.5.1
vesafb: framebuffer at 0xf5000000, mapped to 0xd080d000, size 4096k
vesafb: mode is 1024x768x16, linelength=2048, pages=1
vesafb: protected mode interface info at c000:4781
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
pty: 2048 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS0 at 0x03f8 (irq = 4) is a 16550A
Real Time Clock Driver v1.10e
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
NET4: Frame Diverter 0.46
RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00beta3-.2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller at PCI slot 00:07.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x1040-0x1047, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x1048-0x104f, BIOS settings: hdc:DMA, hdd:pio
hda: MAXTOR 6L060J3, ATA DISK drive
blk: queue c03a4260, I/O limit 4095Mb (mask 0xffffffff)
hdc: PCRW804, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: attached ide-disk driver.
hda: host protected area => 1
hda: 117266688 sectors (60041 MB) w/1819KiB Cache, CHS=7299/255/63, UDMA(33)
ide-floppy driver 0.99.newide
Partition check:
 hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 >
ide-floppy driver 0.99.newide
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 931k freed
VFS: Mounted root (ext2 filesystem).
hdc: attached ide-cdrom driver.
hdc: ATAPI 32X CD-ROM CD-R/RW drive, 2048kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
ISO 9660 Extensions: Microsoft Joliet Level 3
ISO 9660 Extensions: RRIP_1991A
ISO 9660 Extensions: Microsoft Joliet Level 3
ISO 9660 Extensions: RRIP_1991A
cloop: Welcome to cloop v0.67
cloop: /newroot/mnt/cdrom/cloop.img: 15628 blocks, 65536 bytes/block, largest block is 65562 bytes.
Freeing unused kernel memory: 128k freed
parport0: PC-style at 0x378 [PCSPP,TRISTATE,EPP]
ne2k-pci.c:v1.02 10/19/2000 D. Becker/P. Gortmaker
  http://www.scyld.com/network/ne2k-pci.html
PCI: Found IRQ 10 for device 00:0d.0
divert: allocating divert_blk for eth0
eth0: RealTek RTL-8029 found at 0x1020, IRQ 10, 00:00:21:40:0B:E7.
[root at localhost root]#


[root at localhost root]# ls /root/.gnome-desktop/
Installer.desktop  root's Home  starthere.desktop  Trash
[root at localhost root]#


[root at localhost root]# ps afx
  PID TTY      STAT   TIME COMMAND
    1 ?        S      0:04 init [5]
    2 ?        SW     0:00 [keventd]
    3 ?        SWN    0:00 [ksoftirqd_CPU0]
    4 ?        SW     0:00 [kswapd]
    5 ?        SW     0:00 [kscand]
    6 ?        SW     0:00 [bdflush]
    7 ?        SW     0:00 [kupdated]
    8 ?        SW<    0:00 [mdrecoveryd]
  344 ?        S      0:00 syslogd -m 0
  348 ?        S      0:00 klogd -x
  357 ?        S      0:00 portmap
  423 ?        S      0:00 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid  568 ?        S      0:00  \_ fam
  432 ?        S      0:00 cupsd
  439 tty1     S      0:00 /sbin/mingetty tty1
  440 tty2     S      0:00 /sbin/mingetty tty2
  441 tty3     S      0:00 /sbin/mingetty tty3
  442 tty4     S      0:00 /sbin/mingetty tty4
  443 tty5     S      0:00 /sbin/mingetty tty5
  444 tty6     S      0:00 /sbin/mingetty tty6
  445 ?        S      0:01 /usr/bin/gdm-binary -nodaemon
  482 ?        S      0:00  \_ /usr/bin/gdm-binary -nodaemon
  483 ?        R      0:16      \_ /usr/X11R6/bin/X :0 -auth /var/gdm/:0.Xauth
  492 ?        S      0:02      \_ /usr/bin/gnome-session
  547 ?        S      0:00          \_ /usr/bin/ssh-agent /etc/X11/xinit/Xclient  558 ?        S      0:01 /usr/libexec/gconfd-2 9
  560 ?        S      0:00 /usr/libexec/bonobo-activation-server --ac-activate -  562 ?        S      0:01 /usr/bin/metacity --sm-client-id=default1
  565 ?        S      0:02 gnome-settings-daemon --oaf-activate-iid=OAFIID:GNOME  577 ?        S      0:02 gnome-panel --sm-client-id default2
  579 ?        S      0:07 nautilus --no-default-window --sm-client-id default3
  591 ?        S      0:00 /usr/libexec/nautilus-throbber --oaf-activate-iid=OAF  596 ?        S      0:06 /usr/bin/gnome-terminal
  597 pts/0    S      0:00  \_ bash
  630 pts/0    S      0:00  |   \_ ssh -l herrold 10.16.33.2
  633 pts/1    S      0:00  \_ bash
  660 pts/1    R      0:00      \_ ps afx
[root at localhost root]#

From greg at runlevelzero.net  Wed Jul 30 00:41:12 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Wed, 30 Jul 2003 00:41:12 -0700
Subject: [cAos] Built packages...
Message-ID: <20030730074112.GA17119@titan.runlevelzero.net>

I have built all (except one) package, and binaries are now in the crazy
repository. For them to enter a stable state, they must be QA'ed at:
http://caosity.org/pkg_qa.php (hint, hint). For now, all packages are built 
against RedHat8, and should be tested with RedHat8 in a chroot environment
(unless you are daring).

I will write up a howto do chroot test installs soon if you don't know how to
do that.

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From greg at runlevelzero.net  Wed Jul 30 00:45:20 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Wed, 30 Jul 2003 00:45:20 -0700
Subject: [cAos] Web site interface...
Message-ID: <20030730074520.GB17119@titan.runlevelzero.net>

Now that we have several people start using the interface, we can hopefully
start to optimize it. At this point, I wrote what I imagined that was needed.
As people have comments, please feel free to contact me or the list.

The purpose of the site is to make managing the packages easy and fast. If
there is something that is not obvious, or a pain to deal with we should
optimize or document better.

Also, we are going to start needed more people to do documentation. I would
prefer for these people not to be the developers (because the typical hacker
is an awful speller :). Please email me if you can help.

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From lance at uklinux.net  Wed Jul 30 04:51:09 2003
From: lance at uklinux.net (Lance Davis)
Date: Wed, 30 Jul 2003 12:51:09 +0100 (BST)
Subject: [cAos] Built packages...
In-Reply-To: <20030730074112.GA17119@titan.runlevelzero.net>
Message-ID: <Pine.LNX.4.44.0307301249310.15418-100000@s1.uklinux.net>

On Wed, 30 Jul 2003, Greg Kurtzer wrote:

> I have built all (except one) package, and binaries are now in the crazy
> repository. For them to enter a stable state, they must be QA'ed at:
> http://caosity.org/pkg_qa.php (hint, hint). For now, all packages are built 
> against RedHat8, and should be tested with RedHat8 in a chroot environment
> (unless you are daring).

What needs to be qa'ed ??

eg specfile, build, install, use ???

> 
> I will write up a howto do chroot test installs soon if you don't know how to
> do that.

1. take an old piii ....

Lance

-- 
uklinux.net - The ISP of choice for the discerning Linux user. 



From greg at runlevelzero.net  Wed Jul 30 07:33:23 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Wed, 30 Jul 2003 07:33:23 -0700
Subject: [cAos] Built packages...
In-Reply-To: <Pine.LNX.4.44.0307301249310.15418-100000@s1.uklinux.net>
References: <20030730074112.GA17119@titan.runlevelzero.net> <Pine.LNX.4.44.0307301249310.15418-100000@s1.uklinux.net>
Message-ID: <20030730143323.GA19462@titan.runlevelzero.net>

On Wed, Jul 30, 2003 at 12:51:09PM +0100, Lance Davis told me:
> What needs to be qa'ed ??

All of the built RPMS. :)

The QA, processes is just to make sure that it was packaged and works at a
seemingly correct manner. Obvious somethings are easy to check out (ie. a
single function binary or script), where things like the kernel are difficult
to QA. Which makes me think that the QA vote total, should be package specific
(ie. bzip can be 10 qa points, where the kernel can be 50 to leave the QA
crazy repository).

> eg specfile, build, install, use ???

You got it!

> 1. take an old piii ....

lol. The chroot install can work in a directory of a working system, but you
still need to be very careful because the chroot:/dev/ tree is active!

Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/


From mperry at lnxpowered.org  Thu Jul 31 07:56:20 2003
From: mperry at lnxpowered.org (Michael Perry)
Date: Thu, 31 Jul 2003 07:56:20 -0700
Subject: [cAos] [Fwd: Re: going to the show this year?]
Message-ID: <3F292E14.3000603@lnxpowered.org>

Since this is my first posting to the list, I wanted to explain a bit 
about the attached/forwarded email below.  Greg and I had the occasion 
to exchange email on things a few days ago and he had specifically asked 
my impressions about what I saw going on or other viewpoints I had.  I 
apologize in advance for the rather philosophical and meandering nature 
of the following email.  I wrote this after some reflection on changes 
with redhat, what I saw happening with the commercial distribution 
offerings, and some perspective I have with regard to the mission you 
guys have.

Just as a bit of background.  I've been involved with Linux since about 
the 2.0.x kernels.  Not so very long :).  I joined Linuxcare as the 
second employee after the three founders back in 1998/1999 or so. 
Whilst at Linuxcare, I was responsible for building out a strategic 
business unit called Linuxcare Labs.  I also built a team which 
delivered custom linux distributions for clients like IBM, Dell, and 
Gateway.

That out of the way, take a read of this; see what you think.  Its a set 
of postulations or beliefs that could be wrong or right; but in my 
current thinking, I believe that most of them will prove true as time 
goes by.


---------forwarded message------------

Hi Greg-

Just a few basic thoughts (not really concerns).  I have this belief
that the consumer/commercial distributions are really dinosaurs in this
day and age.  I think that they will find some OEM or ISV partner and
redo their offerings toward enterprise vertical markets like embedded or
other strategic offerings which cement ties to a particular type of
focused technology.

The place I am seeing now is that the non-commercial distributions will
excel and move ahead with the "community of users" as well as attracting
attention with more discerning OEM clients.  Right now, I see perhaps
debian and gentoo being there.  Debian is an interesting one and the way
its built itself out is nothing short of amazing.  ImO, its a model of a
large and diverse open source project with a community goal a social,
ideological, and political agenda, and a direction.  Gentoo is more
youthful in nature but its already forked once to take it in yet another
direction.

I think you guys will need to build out at a bare minimum:

-social contract.  The social contract is the binding relationship
between you and the world.  Debian also has built such a monster out and
it forms its fundamental philosophical boundaries.

-technology and release focus.  I read on the site about how your
distribution will release around Jan 04.  I've built a few custom linux
distributions here and there.  I think you will need a document online
which orients the social and technology goals.  You kinda started this
already with your statements about the project.

-key partnerships.  I think you will want to line up some key partners
that will present themselves on your website through links or other
primary levels of information. This allows partners to develop their
pieces of things to benefit the whole and it allows the user base to see
that the distributioin has a good and willing partner or more.

Now for a few esoteric concerns if you don't mind reading along this
wandering diatribe...

User orientation.  The non-commercial distributions recognize that they
have a huge user base but I think that they really do not know how to
bring the users together. Whether an annual conference or a BBQ or a
tradeshow or a group of LUGs sponsoring a day for the distribution.

Developer orientation.  I know a lot of really good developers but a
friend told me once that almost 90% of the Linux user base are users
while only 5 to 10% are these incredible developers (think Tridgel,
Blanchard, those kinds).  Both groups need to be brought together and
both need a value orientation.

Technology orientation.  Along with the above, you will need to state in
clear terms your technology requirements and level of quality.  I think
you guys have done this in a few places on the website.  A few things
bubble up though.  Is this going to be a server OS or an everything OS.
I think its easier to build out a quality server OS with the necessary
tools and management abilities at first.  The desktop components (gnome,
Xwindows, kde) are so complex and require so many additional packages.
Why not build a basic desktop environment like the BBC at first using
something like Blacbox?

Consider, in closing, what Joe Cheek has done with Lycoris.  He has
taken this desktop linux thing into a few areas including building out a
tabelet-based OS.  All oriented toward the desktop.

I'll catch up with you at the show!

-- 
Michael Perry | Do or do not. There is no try. -Master Yoda
mperry at lnxpowered.org | http://www.lnxpowered.org

-- 
Michael Perry | Do or do not. There is no try. -Master Yoda
mperry at lnxpowered.org | http://www.lnxpowered.org



From greg at runlevelzero.net  Thu Jul 31 13:36:05 2003
From: greg at runlevelzero.net (Greg Kurtzer)
Date: Thu, 31 Jul 2003 13:36:05 -0700
Subject: [cAos] [Fwd: Re: going to the show this year?]
In-Reply-To: <3F292E14.3000603@lnxpowered.org>
References: <3F292E14.3000603@lnxpowered.org>
Message-ID: <20030731203605.GA2859@titan.runlevelzero.net>

On Thu, Jul 31, 2003 at 07:56:20AM -0700, Michael Perry told me:
> Just as a bit of background.  I've been involved with Linux since about 
> the 2.0.x kernels.  Not so very long :).  I joined Linuxcare as the 
> second employee after the three founders back in 1998/1999 or so. 
> Whilst at Linuxcare, I was responsible for building out a strategic 
> business unit called Linuxcare Labs.  I also built a team which 
> delivered custom linux distributions for clients like IBM, Dell, and 
> Gateway.

Oh, and you forgot one of your most valued accomplishments! (you hired me!)

> Just a few basic thoughts (not really concerns).  I have this belief
> that the consumer/commercial distributions are really dinosaurs in this
> day and age.  I think that they will find some OEM or ISV partner and
> redo their offerings toward enterprise vertical markets like embedded or
> other strategic offerings which cement ties to a particular type of
> focused technology.

Like an Enterprise Oracle platform? ;)

> The place I am seeing now is that the non-commercial distributions will
> excel and move ahead with the "community of users" as well as attracting
> attention with more discerning OEM clients.  Right now, I see perhaps
> debian and gentoo being there.  Debian is an interesting one and the way
> its built itself out is nothing short of amazing.  ImO, its a model of a
> large and diverse open source project with a community goal a social,
> ideological, and political agenda, and a direction.  Gentoo is more
> youthful in nature but its already forked once to take it in yet another
> direction.

We would like to use some of what Debian has built as a model for our own
success.

> I think you guys will need to build out at a bare minimum:
> 
> -social contract.  The social contract is the binding relationship
> between you and the world.  Debian also has built such a monster out and
> it forms its fundamental philosophical boundaries.

I just read through http://www.debian.org/social_contract, and much of the
points (almost all) apply to exactly what we are doing. I will spend some time
on this, and fine tune it for our needs (which really is not much).

> -technology and release focus.  I read on the site about how your
> distribution will release around Jan 04.  I've built a few custom linux
> distributions here and there.  I think you will need a document online
> which orients the social and technology goals.  You kinda started this
> already with your statements about the project.

Good point. Are you thinking of explaining in more specifics the release
cycles, or more of what we are trying to build (our goals)?

> -key partnerships.  I think you will want to line up some key partners
> that will present themselves on your website through links or other
> primary levels of information. This allows partners to develop their
> pieces of things to benefit the whole and it allows the user base to see
> that the distributioin has a good and willing partner or more.

This is a very good idea, and we have several vendors on the list. People that
are interested in being mentioned on the caosity.org site as a partner should 
speak up.

> Now for a few esoteric concerns if you don't mind reading along this
> wandering diatribe...
> 
> User orientation.  The non-commercial distributions recognize that they
> have a huge user base but I think that they really do not know how to
> bring the users together. Whether an annual conference or a BBQ or a
> tradeshow or a group of LUGs sponsoring a day for the distribution.

I really like this, and you are totally correct!! 

> Developer orientation.  I know a lot of really good developers but a
> friend told me once that almost 90% of the Linux user base are users
> while only 5 to 10% are these incredible developers (think Tridgel,
> Blanchard, those kinds).  Both groups need to be brought together and
> both need a value orientation.

Would this be a different event then what was described earlier?

> Technology orientation.  Along with the above, you will need to state in
> clear terms your technology requirements and level of quality.  I think
> you guys have done this in a few places on the website.  A few things
> bubble up though.  Is this going to be a server OS or an everything OS.
> I think its easier to build out a quality server OS with the necessary
> tools and management abilities at first.  The desktop components (gnome,
> Xwindows, kde) are so complex and require so many additional packages.
> Why not build a basic desktop environment like the BBC at first using
> something like Blacbox?

We are going to focus on a base system. The base system will _hopefully_
include several Window Managers (obviously X), Mozilla, and development tools.
Because so many utilities are linked against Gtk Gnome is not that much more,
and we already have someone that wants to pacakge several light WM's
(BlackBox, FVWM2, and I think WindowMaker).

We will also provide some utilities for HPC, and other general services. I am
guessing that we will end up with ~300 packages that we maintain in the base
OS. From there, I am counting on other groups and developers that will want to
join in and maintain other packages outside the core. cAos thusly is the core,
and we still need draft out exactly what the core is. As you mentioned, all of
this needs to be documented better on the site.

Thanks for the comments!
Greg
-- 
/* Greg Kurtzer, http://runlevelzero.net/greg/
 *
 *    Open Source Projects:
 *       cAos:       http://caosity.org/
 *       Warewulf:   http://warewulf-cluster.org/
 *       GRAB:       http://rpm-grab.org/
 *
 * Do not add my E-mail or contact info to ANY M$ Outlook addressbook! Do not 
 * send me ANY M$ Office documents or it will be deleted upon arrival (plain 
 * text, OpenOffice.org format, and RTF welcomed).
*/