From mperry at lnxpowered.org Fri Aug 1 12:24:14 2003 From: mperry at lnxpowered.org (Michael Perry) Date: Fri, 01 Aug 2003 12:24:14 -0700 Subject: [cAos] Re: cAos digest, Vol 1 #46 - 1 msg In-Reply-To: <20030801190001.14973.68858.Mailman@titan.runlevelzero.net> References: <20030801190001.14973.68858.Mailman@titan.runlevelzero.net> Message-ID: <3F2ABE5E.8020800@lnxpowered.org> caos-request at runlevelzero.net wrote: > 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!) One of the best moves even if you were difficult to manage :) > >>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? ;) > Yeah. I think that the commercial distributions will find partners out there which will deliver certain valued technologies and thus these "dinosaur distributions" will move on out to secure funding, be profitable, or simply disappear based on how well they locate the needed requirements. > > >>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). > I think that this "contract" also binds you to the larger group and it states your social responsibilities, etc. If you notice that Debian has ties to SPI and other groups... >>-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)? > I think one of the "issues" with Debian is their release cycle. Debian does not release a distribution until "some arbitrary point" is reached. I have been using debian for years now and I have come to appreciate this stand but it does create a rather stilted release cycle where the stable release is really "stable"... or perhaps "old". :) So, I think the non-commercial distributions can do more to sustain themselves and if they host multiple releases like stable, testing, unstable; that there could be more to sustain and enrich the release cycles. I don't have specifics here to list for you now; just basic ideas or philosophical meanderings. > >>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? > Well, I think the developers need some organization and approach but what are developers without anyone to use their stuff? Some user has to find value in what they do, I think. How the groups interact is the point here. I don't have specific ideas but I do think that the developers, the users, the documenters, need to all feel empowered. Perhaps a LUG type thing would do this. I have to admit that a few friends I have are just incredible developers and write some pretty awesome code. Back at Linuxcare, I managed to work with a few guys that could do things with code which were simply awesome but they also remained interested in the grassroots user experience. Take a look at Lycoris and see how Joe (also an ex-LXCR guy) built things... >>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). It seems like simplicity can rule in the beginning to me. One can build an elegant solution which is still simple. I guess I just look at the total download to get gnome 2.2 on a system here and then I see something which functions at a simple level like the LNX BBC. > 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 -- Michael Perry | Do or do not. There is no try. -Master Yoda mperry at lnxpowered.org | http://www.lnxpowered.org From herrold at owlriver.com Sat Aug 2 07:44:45 2003 From: herrold at owlriver.com (R P Herrold) Date: Sat, 2 Aug 2003 10:44:45 -0400 (EDT) Subject: [cAos] Re: making a knoppix-like RH9 cd? (fwd) Message-ID: I tossed this 'teaser' post into the anaconda list, to do a little 'organic' recruitment -- some of the developers I hope cAos should attract hang out there. Dunno that I characterized the results of the COLUG presentation to the cAos list, either, so that may be of some interest. -- Russ Herrold ---------- Forwarded message ---------- Date: Thu, 31 Jul 2003 04:22:26 -0400 (EDT) From: R P Herrold To: jgking Cc: anaconda-devel-list at redhat.com Subject: Re: making a knoppix-like RH9 cd? On Wed, 30 Jul 2003, jgking wrote: > This is the closest RH9 list i could find to ask this so if theres better, > point me in the right direction please. > > I have been making custom RH9 iso's for awhile now and want to take this > to another level. Basically run everything from the CD while having all > logging go to the local disk (hda). I found what I thought would be a good > How-To at http://www.tldp.org/HOWTO/Diskless-HOWTO-3.html#ss3.1 > > But i keep running into problems with it. Google'ing has returned zip. The > last thing i can think of is to download knoppix and try to piece out how > they did it but I am hoping someone here has a good writeup for this to > work in RH9. not on RHL 9 per se, yet, that I know of, but the cAos project, http://www.caosity.org/ has a 'work-in-progress' working arbitrary packageset production script for RHL 8. I demonstrated the .iso result of that script, at the Central OH LUG meeting a few hours ago. http://www.colug.net/presentations/ July 03 meeting entry It worked on all CD booting units present at the meeting but one; it caused a hard lockup of a current version SuSE box in a VMWare execution environment. It locks up my older AMD processor (that same unit had trouble with some other RH provided kernel/anaconda combinations as well), but works on all Intel test units. It would/should work with RHL 9 as well, as there is no anaconda dependency, no comps dependency; two chaages -- dropping in a proper kernel, and updateing the RPMs archive for its chrooted install It does depend on getting a clean cloop modules build, and I have not tested that against the RHL 9 kernel yet. Please contact me off list, as this is out of scope of Anaconda, if interested. -- Russ Herrold -- end ======================================+ .-- -... ---.. ... -.- -.-- | Copyright (C) 2003 R P Herrold | Owl River Company herrold at owlriver.com NIC: RPH5 (US) | "The World is Open to Linux (tm)" My words are not deathless prose, | Open Source LINUX solutions ... but they are mine. | info at owlriver.com -- Columbus, OH gpg --keyserver pgp.mit.edu --recv-key 0x7BFB98B9 gpg --list-keys 2> /dev/null | grep 7BFB98B9 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list From greg at runlevelzero.net Sun Aug 3 22:35:43 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sun, 3 Aug 2003 22:35:43 -0700 Subject: [cAos] Package builder running Message-ID: <20030804053543.GA8947@titan.runlevelzero.net> The first version of the package builder is working now. Presently it is building against RedHat 8, and will continue building against that until we have released 1.0 of cAos (then it will build against cAos1). The web interface is working (for me). Once you have upgraded a package in the Release Manager, you can go to Package Builder to have the cAos build server build it. Please remember that this is the first revision, and is a temporary solution until we have the build cluster in place. Any bugs or problems should be filed in bugzilla under cAos | build engine. 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 Mon Aug 4 09:20:30 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Mon, 4 Aug 2003 09:20:30 -0700 Subject: [cAos] Package Builder... Message-ID: <20030804162030.GA24277@titan.runlevelzero.net> After some sleep, it came to me that there is no need to schedule a package build via the 'Package Builder' web page. The build engine can figure all of that out automatically assuming that all packages configured should be built. Presently it is working, and I will start up the hourly cron scripts today or tomorrow (still just checking for bugs and building the lock mechanism). Once, I finish with this I will want to rebuild all packages in the repository, but this will not affect any SRPMS that you have already uploaded (nothing from your perspective should change). This is just FYI. 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 Mon Aug 4 23:06:32 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Mon, 4 Aug 2003 23:06:32 -0700 Subject: [cAos] Package management... Message-ID: <20030805060632.GA22624@titan.runlevelzero.net> Based on what I have seen so far, I think it would be good to separate out the cAos specific packages from the RH rebuilt packages (or whatever distro it came from). Examples.... I build the Linux package from scratch, thus the Release: should be Ncaos. ie. linux-2.4.21-3caos.src.rpm I obtained the gcc package from RedHat, thus the Release: should be whatever RH had originally with the addition of .rhl if it is not already present. ie. gcc-3.2.2-5rhl.src.rpm Originally it was a RedHat package, then it was updated by us. The release should then be the RedHat number +1 with the 'caos' distribution tag. This shows that we were the last ones to touch it, and the package is now forked. I prefer the looks of the 'dot' in front of the distribution (ie. linux-2.4.21-3.caos.src.rpm), but because nobody else (other distributions) is doing that, we should probably play nice. Are there any thoughts on this? People that have already built packages and incorporated into cAos should create a new release, and if it is a RH rebuilt package, please update the 'Release: ' field of the SPEC accordingly (unless someone has objection to this new model)... Sorry for changing the model, but I think it will make things easier for the future. Post comments to the list please. Greg -- /* Greg Kurtzer, http://runlevelzero.net/greg/ * * Open Source Projects: * cAos: http://caosity.org/ * Warewulf: http://warewulf-cluster.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 Tue Aug 5 06:04:33 2003 From: lance at uklinux.net (Lance Davis) Date: Tue, 5 Aug 2003 14:04:33 +0100 (BST) Subject: [cAos] Package management... In-Reply-To: <20030805060632.GA22624@titan.runlevelzero.net> Message-ID: On Mon, 4 Aug 2003, Greg Kurtzer wrote: > Based on what I have seen so far, I think it would be good to separate out the > cAos specific packages from the RH rebuilt packages (or whatever distro it > came from). > > Examples.... > > I build the Linux package from scratch, thus the Release: should be Ncaos. > ie. linux-2.4.21-3caos.src.rpm agreed > > I obtained the gcc package from RedHat, thus the Release: should be > whatever RH had originally with the addition of .rhl if it is not already > present. > ie. gcc-3.2.2-5rhl.src.rpm if there are no changes to the redhat rpm, eg it is being included unmodified then there should not be a need to rename it eg gcc-3.2.2-5.src.rpm is sufficient to identify it. If there are any changes then it is no longer the same rpm and should be called a ncaos rpm. By changes I mean other than specfile comment differences. > Originally it was a RedHat package, then it was updated by us. The release > should then be the RedHat number +1 with the 'caos' distribution tag. This > shows that we were the last ones to touch it, and the package is now > forked. example gcc-3.2.2-6caos.src.rpm - assuming we forked and modified the above ??? - seems reasonable. If at some later stage we take a later rh snapshot rpm, having missed out a couple of rh revisions and not made any other mods , would we then repeat the process ?? eg have caos rpms with missing versions ??? > I prefer the looks of the 'dot' in front of the distribution (ie. > linux-2.4.21-3.caos.src.rpm), but because nobody else (other distributions) is > doing that, we should probably play nice. Are there any thoughts on this? It would probably break things in rpm ... I note that asp linux used to have a . in between but now dont. Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From greg at runlevelzero.net Tue Aug 5 07:39:28 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 5 Aug 2003 07:39:28 -0700 Subject: [cAos] Package management... In-Reply-To: References: <20030805060632.GA22624@titan.runlevelzero.net> Message-ID: <20030805143928.GA30769@titan.runlevelzero.net> On Tue, Aug 05, 2003 at 02:04:33PM +0100, Lance Davis told me: > > > > I obtained the gcc package from RedHat, thus the Release: should be > > whatever RH had originally with the addition of .rhl if it is not already > > present. > > ie. gcc-3.2.2-5rhl.src.rpm > > if there are no changes to the redhat rpm, eg it is being included > unmodified then there should not be a need to rename it eg > gcc-3.2.2-5.src.rpm is sufficient to identify it. The only thing that I was thinking is that we may obtain RPMS from different distros or sources, and all RPMS should be tagged accordingly (IMHO) for our sanity and to make it nice for the users. > If there are any changes then it is no longer the same rpm and should be > called a ncaos rpm. As long as n == (RHL Release + 1) ie. gcc-3.2.2-5caos.src.rpm, which makes it more like the below example. > By changes I mean other than specfile comment differences. Agreed. > > Originally it was a RedHat package, then it was updated by us. The release > > should then be the RedHat number +1 with the 'caos' distribution tag. This > > shows that we were the last ones to touch it, and the package is now > > forked. > > example gcc-3.2.2-6caos.src.rpm - assuming we forked and modified the > above ??? - seems reasonable. If at some later stage we take a later rh > snapshot rpm, having missed out a couple of rh revisions and not made any > other mods , would we then repeat the process ?? eg have caos rpms with missing > versions ??? Why would there be a missing version? Do you mean in the DB, (ie an apparent jump in versions)? If so, yes. > > I prefer the looks of the 'dot' in front of the distribution (ie. > > linux-2.4.21-3.caos.src.rpm), but because nobody else (other distributions) is > > doing that, we should probably play nice. Are there any thoughts on this? > > It would probably break things in rpm ... I note that asp linux used to > have a . in between but now dont. I am thinking the same thing, but I just like the looks of the deliminator (maybe even an underscore?). Thanks, Greg -- /* Greg Kurtzer, http://runlevelzero.net/greg/ * * Open Source Projects: * cAos: http://caosity.org/ * Warewulf: http://warewulf-cluster.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 Tue Aug 5 09:34:00 2003 From: lance at uklinux.net (Lance Davis) Date: Tue, 5 Aug 2003 17:34:00 +0100 (BST) Subject: [cAos] Package management... In-Reply-To: <20030805143928.GA30769@titan.runlevelzero.net> Message-ID: On Tue, 5 Aug 2003, Greg Kurtzer wrote: > On Tue, Aug 05, 2003 at 02:04:33PM +0100, Lance Davis told me: > > > > > > I obtained the gcc package from RedHat, thus the Release: should be > > > whatever RH had originally with the addition of .rhl if it is not already > > > present. > > > ie. gcc-3.2.2-5rhl.src.rpm > > > > if there are no changes to the redhat rpm, eg it is being included > > unmodified then there should not be a need to rename it eg > > gcc-3.2.2-5.src.rpm is sufficient to identify it. > > The only thing that I was thinking is that we may obtain RPMS from different > distros or sources, and all RPMS should be tagged accordingly (IMHO) for our > sanity and to make it nice for the users. ok but we are only going to have one rpm for each package, and redhat are usually the ones without an identifier. If the name/release is the same it might make it easier for auto updaters ??? > > > I prefer the looks of the 'dot' in front of the distribution (ie. > > > linux-2.4.21-3.caos.src.rpm), but because nobody else (other distributions) is > > > doing that, we should probably play nice. Are there any thoughts on this? > > > > It would probably break things in rpm ... I note that asp linux used to > > have a . in between but now dont. > > I am thinking the same thing, but I just like the looks of the deliminator > (maybe even an underscore?). or an = ?? what about caos#5.src.rpm ?? Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From herrold at owlriver.com Tue Aug 5 22:32:24 2003 From: herrold at owlriver.com (R P Herrold) Date: Wed, 6 Aug 2003 01:32:24 -0400 (EDT) Subject: [cAos] vexing Seth: was: [Bug 91] New: RFE: add a 'retrieve' command (fwd) Message-ID: I have enlisted Seth in my plot toward Global Domination with cAos -- the RFE is developed in the IRC transcript. -- Russ Herrold ---------- Forwarded message ---------- Date: Tue, 5 Aug 2003 23:34:48 -0400 (EDT) From: bugzilla-daemon at devel.linux.duke.edu To: herrold at owlriver.com Subject: [Bug 91] New: RFE: add a 'retrieve' command http://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=91 Summary: RFE: add a 'retrieve' command Product: yum Version: all Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Yum AssignedTo: skvidal at phy.duke.edu ReportedBy: herrold at owlriver.com [21:34] skvidal you about and awake? [21:35] more or less [21:35] what's up? [21:36] ... I was lonely ;) [21:36] hah [21:36] and I was thinking about how yum could address something I was about to hack yum apart to do ... [21:36] what's the 'thing'? [21:38] I think I want a 'retrieve' command -- to retrieve the members of a package group, or more simply, the latest instance of a package would help me solve building custom cAos subset ISO's [21:39] I mantioned on cAos list that I had the ISO builder cranking out bootable ISO's unattended [21:39] more explanation needed [21:39] so you've got a yumgroups.xml group [21:39] in a night's "make world", new binary packages will appear in its Raw Hide equivalent [21:40] with the new binaries, I want to retrieve a pre-computed transaction set but NOT install them [21:41] ok [21:41] still confused as to why [21:41] but sure [21:41] do you mean you want a transaction set for a specific machine [21:41] the install happens after some error checking later in the ISo build process in a chroot -- [21:42] I will get to that with the -c option later, but essentially. yes [21:42] the want is for binary retrieval without installation or upgrading -- no need for dep resolver [21:43] so let me see if I can say this in a way I understand [21:43] the binaries are moved around and massaged a bit on the ISO builder to make interesting initial install sets, and also to facilitate later (post cAos install) upgrading from a local archive [21:43] k [21:44] you want to run yum groupinstall 'foo' [21:44] but instead of installing everything [21:44] you want it to compute the dependencies [21:44] and just download the rpms [21:44] and then let you know where they are [21:44] yes - that would work -- indeed, it can d/l them to base and updates and I will merge them [21:45] I do not need the advisory function [21:45] so do everything except the actual install for any given command [21:46] yes [21:46] sure [21:46] I could see some use in that [21:46] rfe [21:46] I'll put it on a hitlist [21:47] it can be done in 2.0 w/o tearing anything up I believe [21:47] I'll RFE -- FYI the script: ftp://ftp.owlriver.com/pub/local/ORC/cAos-iso/build.pl uses a pre-computed repository presently -- I want to tear that out and drop in one yum line [21:48] oh my god [21:48] perl ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. From greg at runlevelzero.net Tue Aug 5 22:50:13 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 5 Aug 2003 22:50:13 -0700 Subject: [cAos] vexing Seth: was: [Bug 91] New: RFE: add a 'retrieve' command (fwd) In-Reply-To: References: Message-ID: <20030806055013.GA5387@titan.runlevelzero.net> On Wed, Aug 06, 2003 at 01:32:24AM -0400, R P Herrold told me: > I have enlisted Seth in my plot toward Global Domination > with cAos -- the RFE is developed in the IRC transcript. Very good! :) > [21:48] oh my god > [21:48] perl Seth is funny, glad to have him onboard!... :) Greg -- /* Greg Kurtzer, http://runlevelzero.net/greg/ * * Open Source Projects: * cAos: http://caosity.org/ * Warewulf: http://warewulf-cluster.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 Aug 5 23:06:42 2003 From: herrold at owlriver.com (R P Herrold) Date: Wed, 6 Aug 2003 02:06:42 -0400 (EDT) Subject: [cAos] Re: cAos] vexing Seth: was: [Bug 91] New: RFE: add a 'retrieve' command (fwd) In-Reply-To: <20030806055013.GA5387@titan.runlevelzero.net> Message-ID: On Tue, 5 Aug 2003, Greg Kurtzer wrote: > > with cAos -- the RFE is developed in the IRC transcript. > > > [21:48] oh my god > > [21:48] perl > > Seth is funny, glad to have him onboard!... :) heh -- snipped from that transcript are the following comments, assigning the blame for torturing perl (as that script does) to its original author ;) -- Russ From greg at runlevelzero.net Tue Aug 5 23:14:36 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 5 Aug 2003 23:14:36 -0700 Subject: [cAos] Re: cAos] vexing Seth: was: [Bug 91] New: RFE: add a 'retrieve' command (fwd) In-Reply-To: References: <20030806055013.GA5387@titan.runlevelzero.net> Message-ID: <20030806061436.GA5568@titan.runlevelzero.net> On Wed, Aug 06, 2003 at 02:06:42AM -0400, R P Herrold told me: > > Seth is funny, glad to have him onboard!... :) > > heh -- snipped from that transcript are the following comments, > assigning the blame for torturing perl (as that script does) > to its original author ;) Torturing Perl? Is there such a thing? Glad to see that it all comes back to the original author! Who was that masked man anyway? -- /* Greg Kurtzer, http://runlevelzero.net/greg/ * * Open Source Projects: * cAos: http://caosity.org/ * Warewulf: http://warewulf-cluster.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 Aug 5 23:35:35 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 5 Aug 2003 23:35:35 -0700 Subject: [cAos] AMD systems... In-Reply-To: <20030718232617.GD26993@titan.runlevelzero.net> References: <20030718232617.GD26993@titan.runlevelzero.net> Message-ID: <20030806063535.GB5568@titan.runlevelzero.net> Once again, we _need_ build and test systems for cAos to be successful. Marc at AMD wants to help us, but he needs to hear from cAos supporters (not just developers). ALL cAos supporters should send an email to marc.miller --at-- amd.com just to let him know that you exist and what your interest with cAos is (several lines is sufficient). Thanks, Greg On Fri, Jul 18, 2003 at 04:26:17PM -0700, Greg Kurtzer told me: > 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). > */ > _______________________________________________ > 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/ * * 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 Aug 6 00:10:28 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Wed, 6 Aug 2003 00:10:28 -0700 Subject: [cAos] Build errors on unpackaged files... Message-ID: <20030806071028.GA7994@titan.runlevelzero.net> I added the lines to the default cAos autobuilder RPM macro: %_missing_doc_files_terminate_build 1 %_unpackaged_files_terminate_build 1 This will mean that any unpackaged files will terminate the build process. I also updated the docs at: http://caosity.org/docs_view.php?subject=SRPM%20SPEC%20and%20build%20information To reflect this. Greg -- /* Greg Kurtzer, http://runlevelzero.net/greg/ * * Open Source Projects: * cAos: http://caosity.org/ * Warewulf: http://warewulf-cluster.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 Aug 6 00:41:37 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Wed, 6 Aug 2003 00:41:37 -0700 Subject: [cAos] Package management... In-Reply-To: References: <20030805143928.GA30769@titan.runlevelzero.net> Message-ID: <20030806074137.GE7994@titan.runlevelzero.net> On Tue, Aug 05, 2003 at 05:34:00PM +0100, Lance Davis told me: > > The only thing that I was thinking is that we may obtain RPMS from different > > distros or sources, and all RPMS should be tagged accordingly (IMHO) for our > > sanity and to make it nice for the users. > > ok but we are only going to have one rpm for each package, and redhat are > usually the ones without an identifier. What do you mean one rpm per package? Yea, RedHat does not identify their own packages. > If the name/release is the same it might make it easier for auto updaters > ??? Hrmm, yes. But as long as the number comes first it should not make too much of a difference. > what about caos#5.src.rpm ?? That is an interesting idea... Hey Russ, what are your thoughts on this? OK, so it looks like we are practically in agreement except for the adding the rhl to the RedHat packages. My opinion is that even rebuilding a package should increment the Release version and if we are going to change the version anyway, I thought it would be good to at least tag it accordingly (Nrhl). Maybe I should bring this back a level... Does a package rebuild require a increase in the Release tag? Greg -- /* Greg Kurtzer, http://runlevelzero.net/greg/ * * Open Source Projects: * cAos: http://caosity.org/ * Warewulf: http://warewulf-cluster.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 Aug 6 09:09:06 2003 From: herrold at owlriver.com (R P Herrold) Date: Wed, 6 Aug 2003 12:09:06 -0400 (EDT) Subject: [cAos] Re: cAos] Package management... In-Reply-To: Message-ID: On Tue, 5 Aug 2003, Lance Davis wrote: > > > > I obtained the gcc package from RedHat, thus the Release: should be > > > > whatever RH had originally with the addition of .rhl if it is not already > > > > present. > > > > ie. gcc-3.2.2-5rhl.src.rpm > > > > > > if there are no changes to the redhat rpm, eg it is being included > > > unmodified then there should not be a need to rename it eg > > > gcc-3.2.2-5.src.rpm is sufficient to identify it. I disagree pretty strongly here. Knowing the lineage of a RPM is important (reputationally, as to the packager, and in tracking down missing build expectation -- the subtle differences in the naming of the -devel groups between: SuSE vs. Mdk vs. RH often make it necessary to do spot repackaging of .spec files. Knowing where to look for missing pieces is important) I think we should probably also seek to have RH 'brand' their packges -- but as volume leader, this will probably take some clear and convincing argument. -- The build host ( rpm -qa --qf '%{buildhost}\n' | sort -u ) gives some clues whether or if an SRPM has been rebuilt; it will pick up a new buildhost. Part of that same process, when doing a rebuild of a SRPM not carrying a external 'distributor' 'brand' in the "release", to me, includes adding the brand (if missing - Red Hat, and other packagers, [including some Owl River] alike), preserving the brand (if present but an unchanged recompile), or adding one (well-packaged new SRPMs). This courtesy, history (lineage), and dis-ambuigation (is this a word -- reduction of ambiguity is my import here) in the external file name will be also refoected in the 'Packager', the 'Buildhost', and the 'sourcerpm' querytags [and of course in the signing key] another fun querytag: rpm -qa --qf '%{SOURCERPM}\n' | sort | uniq -c | sort -n | \ tail -5 11 kdegraphics-3.0.5a-2.src.rpm 13 gcc-3.2-7.src.rpm 14 kdenetwork-3.0.5a-1.src.rpm 16 kdeutils-3.0.5a-1.src.rpm 17 XFree86-4.2.1-21.src.rpm bash-2.05b$ > > The only thing that I was thinking is that we may obtain RPMS from different > > distros or sources, and all RPMS should be tagged accordingly (IMHO) for our > > sanity and to make it nice for the users. concur strongly -- I think we may see a move toward more 'tagging' with the new RH 'upstreaming as well' to help unsnarl things. > ok but we are only going to have one rpm for each package, and redhat are > usually the ones without an identifier. > > If the name/release is the same it might make it easier for auto updaters > ??? A well-formed updater does not really use the external package name for N-EVR resolution; within the headers, EVR comparisons are funky but largely deterministic (fully deterministic in RPM-4.2.1 and later). Particularly all comparisons are textual within radix element -- that is 4.23 is 'newer than 4.100 because on the right side of the radix point, 2 sorts later than 1 > > > > I prefer the looks of the 'dot' in front of the distribution (ie. > > > > linux-2.4.21-3.caos.src.rpm), but because nobody else (other distributions) is > > > > doing that, we should probably play nice. Are there any thoughts on this? > > > > > > It would probably break things in rpm ... I note that asp linux used to > > > have a . in between but now dont. the dot is harmless to the RPM version comparison logic-- But only the first radix dot found scanning from left to right is significant -- later ones are just character elements. Naming is largely a convenience matter for end users being able to determine what is going on. The packaging vendor abbreviation, by convention is kept lowercase and under 4 characters because overly long strings break display expectations. I extend that with an UPPERCASE distribution and Major post suffix on some packages presently, and will extend that model. I have a personal task to rebuild all Owl River non-distribution packagings with a Release of the form: -4orcRH8. where 4 is the sequence number, orc is the brand, RH is the target compiled for, and 8 is their major release but as a distribution, I would truncate it to: -4cao1. where 4 is the sequence number, oao is the brand, and 8 is their major release and when I recompiled for a cAos release, I would view /etc/caos-release and extract the major version, and my personal packaging would become: -4orcCA1. So the following packagings of foo might exist from a single .spec file foo-2.34-4orc.spec : foo-2.34-4orcRH8.src.rpm foo-2.34-4orcCA1.src.rpm foo-2.34-4orcRH8.i386.rpm foo-2.34-4orcRH8.ppc.rpm foo-2.34-4orcCA1.i386.rpm foo-2.34-4orcCA1.ppc.rpm -- Russ Herrold From herrold at owlriver.com Wed Aug 6 10:58:57 2003 From: herrold at owlriver.com (R P Herrold) Date: Wed, 6 Aug 2003 13:58:57 -0400 (EDT) Subject: [cAos] RE: making a knoppix-like RH9 cd? In-Reply-To: <012478237CC7D311989C0008C79F4DA1048ABAC8@houston.oao.com> Message-ID: On Wed, 6 Aug 2003, King, John (Greg) (LMIT-HOU) wrote: > Any help you can offer would be great. I had tried compiling the cloop > sources in RH9 but it keeps errroring out. First it was looking for a > .config file (so I copied the one from /boot into the kernel sources) and > then it errored again but I forget the error. I figured it was something > debian-ish being looked for. No worries on fixing this. I know the issue exactly but had not written dianostic code to detect and suggest how to address a missing configuration of this type-- By the way, no Debianish issue here -- this project's three cornerstones are the Linux kernel, RPM packaging, and the FSF glibc The kernel compilation config cloop want varies, depending on the kernel-source installed, and the kernel version and arch running. It also varies depending on whether the target run host is the same as the build host or not. As a simplifying assumption, I assume that it is -- but if one were porting toward, say, a 486 embeded unit from a Pentium class device, the discussion and use of 'uname -m' below varies. As the comment in the source suggests, I guess not emphatically enough: # pulling it out of the environment # orc_orc> why not derive kversion from uname in the script? # because it is possiable to use a kernel that you are not # currently running on. # TBD: derive it from the uname -r of running kernel if it # is not set, if not otherwise set - may fail # but that is OK as it means the running kernel != # the one installed in the chroot # give it a try, anyway -- # or mebbe use rpm -q --qf '%{name}' kernel-source if # only one kernel-source is installed so here is some shell code extending the discussion above. I send a CC of this email to the cAos list as well, and invite you to join in the developmental fun. I anticipate having a RHL 9 booting ISO within a week or so. see: http://www.caosity.org/ down the email lists link on the left lower section. We need to do this: 1. Figure out the kernel sources we are using export KERNEL_NV=`rpm -q --qf '%{version}-%{release}' \ kernel-source`/configs/ ls -al /usr/src/linux-${KERNEL_NV}/configs/ 2. And then identify, using `uname -m` which of these configs are correct (assuming the target host is the same as the build host, we can automate the process -- we cannot when the target differs without user input. I need to add a option switch to address this better): bash-2.05b$ ls /usr/src/linux-`rpm -q --qf \ '%{version}-%{release}' kernel-source`/configs/ kernel-2.4.20-athlon-smp.config kernel-2.4.20-i586.config kernel-2.4.20-athlon.config kernel-2.4.20-i686-bigmem.config kernel-2.4.20-i386-BOOT.config kernel-2.4.20-i686-smp.config kernel-2.4.20-i386-smp.config kernel-2.4.20-i686.config kernel-2.4.20-i386.config kernel-2.4.20-x86_64-smp.config kernel-2.4.20-i586-smp.config kernel-2.4.20-x86_64.config bash-2.05b$ so we will: export KERNEL_TGT=`uname -m` export KERNEL_CFG=`echo "kernel${KERNEL_NV}-${KERNEL_TGT}"` 3. And then get the config file it was built with in place for the desired target host cp /usr/src/linux-${KERNEL_NV}/configs/${KERNEL_CFG}.config \ /usr/src/linux-${KERNEL_NV}/.config 4. And it is possible that some links are needed for the cloop module compile to work: [ ! -e /usr/src/linux ] && \ ln -s /usr/src/linux-${KERNEL_NV} /usr/src/linux [ ! -e /usr/src/linux ] && \ ln -s /usr/src/linux-${KERNEL_NV} /usr/src/linux-2.4 ======================================= This is untested, but should work on a scrape and paste basis. Please test and advise. Patches in unified or context diff form under GPL welcomed. I have pushed a freshly updated script, cleaning up some of the horrible typo's at: ftp://ftp.owlriver.com/pub/local/ORC/cAos-iso/ as build.pl Advert: The cAos project is looking for commercial sponsors/ patrons, and as a project, it may well address issues that Lockheed Martin may wish to consider sponsoring; additionally several of the development team are consultants and it may be productive and cost effective to hire some of the 'finish' done, if this is more than a 'developmental interest' project for Lockheed. To review the commercial side of the project -- see, e.g., http://www.owlriver.com/wings/ I have several summer intern folks/starving college student developers 'in the stable' who have asked that I toss parts of the implementation document at them as subcontractors. This would speed up cAos a lot. The project is and will remain GPL, but external funding would be welcomed and produce a lot of 'bang for the buck'. Let me know if you need and can use a more formal exposition on this. At [a large chip maker]'s request, I have one in process with them as well. -- Russ Herrold -- end ======================================+ .-- -... ---.. ... -.- -.-- | Copyright (C) 2003 R P Herrold | Owl River Company herrold at owlriver.com NIC: RPH5 (US) | "The World is Open to Linux (tm)" My words are not deathless prose, | Open Source LINUX solutions ... but they are mine. | info at owlriver.com -- Columbus, OH gpg --keyserver pgp.mit.edu --recv-key 0x7BFB98B9 gpg --list-keys 2> /dev/null | grep 7BFB98B9 From lance at uklinux.net Wed Aug 6 14:41:05 2003 From: lance at uklinux.net (Lance Davis) Date: Wed, 6 Aug 2003 22:41:05 +0100 (BST) Subject: [cAos] Re: cAos] Package management... In-Reply-To: Message-ID: On Wed, 6 Aug 2003, R P Herrold wrote: > On Tue, 5 Aug 2003, Lance Davis wrote: > > > > > > I obtained the gcc package from RedHat, thus the Release: should be > > > > > whatever RH had originally with the addition of .rhl if it is not already > > > > > present. > > > > > ie. gcc-3.2.2-5rhl.src.rpm > > > > > > > > if there are no changes to the redhat rpm, eg it is being included > > > > unmodified then there should not be a need to rename it eg > > > > gcc-3.2.2-5.src.rpm is sufficient to identify it. > > I disagree pretty strongly here. Knowing the lineage of a RPM > is important (reputationally, as to the packager, and in > tracking down missing build expectation -- the subtle > differences in the naming of the -devel groups between: SuSE > vs. Mdk vs. RH often make it necessary to do spot repackaging > of .spec files. Knowing where to look for missing pieces is > important) I think we should probably also seek to have RH > 'brand' their packges -- but as volume leader, this will > probably take some clear and convincing argument. Indeed But all of the information is already contained within the rpm, and changing the release of an otherwise identical rpm seems unnecessary and liable to cause confusion. But if you say so .... > another fun querytag: > rpm -qa --qf '%{SOURCERPM}\n' | sort | uniq -c | sort -n | \ > tail -5 > > 11 kdegraphics-3.0.5a-2.src.rpm > 13 gcc-3.2-7.src.rpm > 14 kdenetwork-3.0.5a-1.src.rpm > 16 kdeutils-3.0.5a-1.src.rpm > 17 XFree86-4.2.1-21.src.rpm > bash-2.05b$ ??? > > ok but we are only going to have one rpm for each package, and redhat are > > usually the ones without an identifier. > > > > If the name/release is the same it might make it easier for auto updaters > > ??? > > A well-formed updater does not really use the external package > name for N-EVR resolution; within the headers, EVR comparisons > are funky but largely deterministic (fully deterministic in > RPM-4.2.1 and later). Particularly all comparisons are > textual within radix element -- that is 4.23 is 'newer than > 4.100 because on the right side of the radix point, 2 sorts > later than 1 sorry - I thought that 1caos or 1rhl was the release part of your N-EVR resolution and not just the package name ?? so what happens with gcc-3.2.2-5rhl.src.rpm aka gcc-3.2.2-5.src.rpm presumably 5rhl and 5caos are both later than 5 , but would 5caos be earlier than 5rhl ??? > > > > > > I prefer the looks of the 'dot' in front of the distribution (ie. > > > > > linux-2.4.21-3.caos.src.rpm), but because nobody else (other distributions) is > > > > > doing that, we should probably play nice. Are there any thoughts on this? > > > > > > > > It would probably break things in rpm ... I note that asp linux used to > > > > have a . in between but now dont. > > the dot is harmless to the RPM version comparison logic-- But > only the first radix dot found scanning from left to right is > significant -- later ones are just character elements. I guess I should take a look at that logic ;) For example if our distro were 'sues rescue cd' and we decided to call our release 3.src so our rpm is linux-2.4.21-3.src.rpm and our source rpm would be linux-2.4.21-3.src.src.rpm then I'm sure it would cause a problem :) So sticking away from .'s in the release is IMHO a good idea. > Naming is largely a convenience matter for end users being > able to determine what is going on. agreed. > So the following packagings of foo might exist from a single > .spec file foo-2.34-4orc.spec : > > foo-2.34-4orcRH8.src.rpm > foo-2.34-4orcCA1.src.rpm > foo-2.34-4orcRH8.i386.rpm > foo-2.34-4orcRH8.ppc.rpm > foo-2.34-4orcCA1.i386.rpm > foo-2.34-4orcCA1.ppc.rpm cripes - cat we stick to 1caos :) Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From greg at runlevelzero.net Wed Aug 6 21:43:54 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Wed, 6 Aug 2003 21:43:54 -0700 Subject: [cAos] Re: cAos] Package management... In-Reply-To: References: Message-ID: <20030807044354.GA21208@titan.runlevelzero.net> On Wed, Aug 06, 2003 at 10:41:05PM +0100, Lance Davis told me: > But all of the information is already contained within the rpm, and > changing the release of an otherwise identical rpm seems unnecessary and > liable to cause confusion. Cause confusion? could you explain? > > A well-formed updater does not really use the external package > > name for N-EVR resolution; within the headers, EVR comparisons > > are funky but largely deterministic (fully deterministic in > > RPM-4.2.1 and later). Particularly all comparisons are > > textual within radix element -- that is 4.23 is 'newer than > > 4.100 because on the right side of the radix point, 2 sorts > > later than 1 > > sorry - I thought that 1caos or 1rhl was the release part of your N-EVR > resolution and not just the package name ?? Good point, but I think that rpmlib actually does not compare alphas (much to my dismay) but Russ could correct me if I am wrong. > so what happens with > > gcc-3.2.2-5rhl.src.rpm aka gcc-3.2.2-5.src.rpm > > presumably 5rhl and 5caos are both later than 5 , but would 5caos be > earlier than 5rhl ??? I think that if we rebuilt the package, we would increment the build so it would be comparing: gcc-3.2.2-6rhl.src.rpm and gcc-3.2.2-5.src.rpm > I guess I should take a look at that logic ;) > > For example if our distro were 'sues rescue cd' and we decided to call our > release 3.src so our rpm is linux-2.4.21-3.src.rpm and our source rpm > would be linux-2.4.21-3.src.src.rpm then I'm sure it would cause a problem :) That is funny and it makes the point. Also we can probably do without the extra character in the nomenclature... > So sticking away from .'s in the release is IMHO a good idea. Agreed. > > So the following packagings of foo might exist from a single > > .spec file foo-2.34-4orc.spec : > > > > foo-2.34-4orcRH8.src.rpm > > foo-2.34-4orcCA1.src.rpm > > foo-2.34-4orcRH8.i386.rpm > > foo-2.34-4orcRH8.ppc.rpm > > foo-2.34-4orcCA1.i386.rpm > > foo-2.34-4orcCA1.ppc.rpm > > cripes - cat we stick to 1caos :) Remember that it will be the same SRPM that will be compiled for the different cAos major versions. This means that there will not be any differentiation between the package nomenclature for cAos-1 and cAos-2... Should this principal be revisited? Greg -- /* Greg Kurtzer, http://runlevelzero.net/greg/ * * Open Source Projects: * cAos: http://caosity.org/ * Warewulf: http://warewulf-cluster.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 Aug 6 21:56:28 2003 From: herrold at owlriver.com (R P Herrold) Date: Thu, 7 Aug 2003 00:56:28 -0400 (EDT) Subject: [cAos] Re: cAos] Re: cAos] Package management... In-Reply-To: <20030807044354.GA21208@titan.runlevelzero.net> Message-ID: On Wed, 6 Aug 2003, Greg Kurtzer wrote: > > > So the following packagings of foo might exist from a single > > > .spec file foo-2.34-4orc.spec : > > > > > > foo-2.34-4orcRH8.src.rpm > > > foo-2.34-4orcCA1.src.rpm > > > foo-2.34-4orcRH8.i386.rpm > > > foo-2.34-4orcRH8.ppc.rpm > > > foo-2.34-4orcCA1.i386.rpm > > > foo-2.34-4orcCA1.ppc.rpm > > > > cripes - cat we stick to 1caos :) > > Remember that it will be the same SRPM that will be compiled for the different > cAos major versions. This means that there will not be any differentiation > between the package nomenclature for cAos-1 and cAos-2... > > Should this principal be revisited? hehm who said anything avout cAos-2 yet -- although I was thinking of compiling foo from the same .spec file for for both kernel 2.4 / rpm 4.1 (cAos-1) and kernel-2.5 / rpm 4.3 (cAos-2) - R From greg at runlevelzero.net Wed Aug 6 22:17:49 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Wed, 6 Aug 2003 22:17:49 -0700 Subject: [cAos] RE: making a knoppix-like RH9 cd? In-Reply-To: References: <012478237CC7D311989C0008C79F4DA1048ABAC8@houston.oao.com> Message-ID: <20030807051749.GB21208@titan.runlevelzero.net> On Wed, Aug 06, 2003 at 01:58:57PM -0400, R P Herrold told me: > On Wed, 6 Aug 2003, King, John (Greg) (LMIT-HOU) wrote: > > > Any help you can offer would be great. I had tried compiling the cloop > > sources in RH9 but it keeps errroring out. First it was looking for a > > .config file (so I copied the one from /boot into the kernel sources) and > > then it errored again but I forget the error. I figured it was something > > debian-ish being looked for. Just wanted to throw this out because the cloop version that I started with would be specific for a RedHat kernel. Why you ask...? What could RedHat have done to break things?? I will explain... The RedHat kernel fs header (include/linux/fs.h) takes a different argument lineup then the standard LinusT kernel: RH: extern void do_generic_file_read(struct file *, loff_t *, read_descriptor_t *, read_actor_t, int); LT: extern void do_generic_file_read(struct file *, loff_t *, read_descriptor_t *, read_actor_t); Notice the last 'int' arg of the RH fs.h. Because of this, compressed_loop.c has this snippet embedded for when it calls that function: #ifdef REDHAT_KERNEL do_generic_file_read(f, &pos, &desc, clo_read_actor, 0); #else /* Normal Kernel */ do_generic_file_read(f, &pos, &desc, clo_read_actor); #endif Soooo, you must have -DREDHAT_KERNEL defined in one of the compile lines in the Makefile (I choose to throw it into the CFLAGS: . Thusly, the point is, if you grabbed the latest cloop sources and trying to compile on RedHat, you should check on this. If you are using the version that I was working with, it is already in the Makefile and would probably error out on a non-RedHat kernel. > so here is some shell code extending the discussion above. I > send a CC of this email to the cAos list as well, and invite > you to join in the developmental fun. Yes, come and join the party! :) Good luck! Greg -- /* Greg Kurtzer, http://runlevelzero.net/greg/ * * Open Source Projects: * cAos: http://caosity.org/ * Warewulf: http://warewulf-cluster.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 Aug 6 22:19:37 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Wed, 6 Aug 2003 22:19:37 -0700 Subject: [cAos] Re: cAos] Re: cAos] Package management... In-Reply-To: References: <20030807044354.GA21208@titan.runlevelzero.net> Message-ID: <20030807051937.GC21208@titan.runlevelzero.net> On Thu, Aug 07, 2003 at 12:56:28AM -0400, R P Herrold told me: > > Remember that it will be the same SRPM that will be compiled for the different > > cAos major versions. This means that there will not be any differentiation > > between the package nomenclature for cAos-1 and cAos-2... > > > > Should this principal be revisited? > > hehm who said anything avout cAos-2 yet -- although I was > thinking of compiling foo from the same .spec file for for > both kernel 2.4 / rpm 4.1 (cAos-1) and kernel-2.5 / rpm 4.3 > (cAos-2) Then wouldn't the name be a bit more like: foo-2.34-4orcCA1.src.rpm foo-2.34-4orcCA2.src.rpm Which would imply a different SPEC or 'Release: ' increment? g.out -- /* Greg Kurtzer, http://runlevelzero.net/greg/ * * Open Source Projects: * cAos: http://caosity.org/ * Warewulf: http://warewulf-cluster.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 Aug 6 22:55:22 2003 From: herrold at owlriver.com (R P Herrold) Date: Thu, 7 Aug 2003 01:55:22 -0400 (EDT) Subject: [cAos] RPMVERCMP - was Re: cAos] Package management... In-Reply-To: <20030807044354.GA21208@titan.runlevelzero.net> Message-ID: On Wed, 6 Aug 2003, Greg Kurtzer wrote: > Cause confusion? could you explain? > > > > A well-formed updater does not really use the external package > > > name for N-EVR resolution; within the headers, EVR comparisons > > > are funky but largely deterministic (fully deterministic in > > > RPM-4.2.1 and later). Particularly all comparisons are > > > textual within radix element -- that is 4.23 is 'newer than > > > 4.100 because on the right side of the radix point, 2 sorts > > > later than 1 > > > > sorry - I thought that 1caos or 1rhl was the release part of your N-EVR > > resolution and not just the package name ?? yes - the 4.23 vs. 4.100 is in the position for the Release element in my example. I am not sure I crafted well or stated the result accurately however. I forgot to apply the digit count test, and my prior statement is wrong. Separately the comparison logic is (as I recall) the same for both Version and Release > Good point, but I think that rpmlib actually does not > compare alphas (much to my dismay) but Russ could correct me > if I am wrong. nope, a correction is needed (it most definitely DOES do strcmp's (so-called alpha use)) -- From the code itself, from the comments in the code, and from the JBJ and third party analysis and testing on the code, this is my analysis. relevant code is: rpmvercmp.c Consider 0.2 and 0.10 it will compare all as strings (treating numerals as plain old characters, after stripping leading (LHS) zeroes on purely numeric sub elements, and then after count(number of numerals present) test. 2 has fewer numerals than 10 to the right of the radix, and so 0.2 is less than 0.10 We would get the same result with: 0.02 and 0.10 -- when we strip the LHS zero, 2 still is fewer numerals (ONE character) than 10 (TWO characters) BUT 0.20 has the same number of numerals as 0.10 [a person accustomed to using radixed (customarily decimal) fractions) thinks 0.2 == 0.20. This is correct in mathematics terms, but in rpmvercmp, 0.2 is also less than 0.20 ] AND 0.2ca4 and 0.2orc3 breaks out (as I understand it) as 0 == 0 - defer decision "." is the radix point separator, and does not enter into the comparison process as a comparand 2 == 2 - same number of numerals, textually the same -- defer decision ca strcmp's less than orc -- decide: 0.2ca4 is less than 0.2orc3 we never even hit the '4' and '3' element, for we can decide earlier in the strings Back at the start of the year, Axel.Thimm spent a lot of time on rpm-list carefully hashing through this wth JBJ -- As an outcome of that and some other help from PZB, the code in rpm-4.1.1 and 4.2.1 will always do the 'right' thing on a stringish' comparison of the V and R elements, and (from another set of Bugzilla nd discussion) get Epoch correct without indeterminacy. This is a big win for repository managers. By way of history, in the bad old days, JBJ noted on rpm-list On Thu, Aug 09, 2001 at 11:27:10AM -0400, Jeff Johnson wrote: > On that note, let me put out a RFC regarding a closely related problem, > pending changes to rpmvercmp. While there's nothing broken in rpm per se, > I believe it's time to simplify some obscure behavior in rpm. This won't be > in rpm-4.0.3, but I'm going to try to make any changes as soon thereafter > as possible to permit incompatibilities and/or problems to be identified > as soon as possible. >=20 > Please append comments, concerns, ideas, etc to bugzilla #50977. I suspect > that the final resolution for rpm is gonna be to use the version comparison > that dpkg uses, as that appears to apply to a larger character domain than > that currently used by rpm, but is otherwise entirely compatible. and later: > Background > rpm package management uses a function called rpmvercmp() for > all version and release comparisons to determine whether package > A is "newer" than package B. >=20 > Originally, in rpm-2.5.x, the function was implemented as > segmented string compares. Strings were broken into alpha > and digital segments, alpha segments were compared using strcmp, > digits were converted to int32, and compared as integers. >=20 > In ~rpm-3.0, it was notced that the digit string YYYYMMDDhhmmss > overflowed 2^32, so the digit comparison was changed to use > strcmp on padded digit strings, that works for arbitrary length > digit strings. >=20 > In bugzilla #21392, it was noticed that mixed-mode (i.e. alpha > with digit strings) was not defined. Basically, there were > a handful of cases where A was "newer" than B, and B was "newer" > than A. No one (except Trond :-) had ever noticed until bugzilla > #21292 was reported. So the return code for mixed mode comparison > was changed. >=20 > Then along came LSB, with the goal of unified package management. > As part of the discussion, Jason Gunthorpe pointed out that > rpm has a very limited character set, only isalnum(3) characters > are compared. Surprise, all those '.' charcters are never, ever, > used directly by rpm, are only used to demarcate segment boundaries. >=20 so ... the use of an internal '.' V or R sub-element separator is/should be in all RPM related cases, harmless, if consistently applied. Peter Bowen (PZB) of Ximian has been in this thread as well, and is a careful analyst -- look for his posts as well. see also the post on rpm-list at: >From rpm-list-admin at redhat.com Sat Jan 18 08:34:12 2003 From: James Olin Oden for an exhausive pseudocode restatement on that code. Not JBJ's, however. ===================== Executive summary -- don't count on rpmvercmp to save you -- know the other package archive's your users are pointing at -- hopefully documented and fed by safe and careful packagers -- and number bump Version (sometimes), and more often Release numbers as needed in the first comparison element. Are you throughly confused yet? -- Russ Herrold From greg at runlevelzero.net Wed Aug 6 22:57:17 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Wed, 6 Aug 2003 22:57:17 -0700 Subject: [cAos] Version nomenclature... Message-ID: <20030807055717.GD21208@titan.runlevelzero.net> OK, based on the 'Package management...' thread, I think we have enough info to draft out the version nomenclature document, so here goes round one: There are three scenarios that I see for migrating a new package or existing package version into cAos: 1. Building an original SPEC file for a piece of software 2. Migrating an existing unmodified SPEC from an existing known source 3. Migrating an existing unmodified SPEC from an existing unknown source 4. Using #2 as a basis, and enhancing or forking from it (fix or patch) The nomenclatures for each are as follows: ALL: Each package 'Version: ' tag in the SPEC will reflect the advertised version of the included source tree for the package. 1. Original SPEC's will be labeled with the 'Release: ' tag as Ncaos where N == the release increment of the package starting from '1'. example: the first release of Linux will be linux-2.4.21-1caos.src.rpm 2. Unmodified SPEC's that have been recompiled for use with cAos with no changes to the package source code will retain the existing 'Release: ' tag + 1. The plus 1 shows that this is a newer build of the package then when we found it. Also the 'Release: ' tag will specify where the package was obtained from if it is not already present. example: gcc-3.2-7.src.rpm -> gcc-3.2-8rhl.src.rpm 3. It may be the case that we use a SPEC that was created by the package maintainer or other contributor that are not cAos maintainers (yet). In this case we are to preserve any ID nomenclature that they have used + 1 to indicate that it has been rebuilt. If they have no ID in the 'Release: ' tag, then we are not to add one. 4. If we have decided to fork a package and make changes to the source code inside the RPM, then we are to demonstrate that we are now the 'owners' of this package by adding 'caos' to the 'Release: ' tag, as well as increment the original 'Release: ' by + 1. example: gcc-3.2-7.src.rpm gcc-3.2-8caos.src.rpm Additional responsibilities: 1. Every time we develop a SPEC for a package, the developers should be notified and the SRPM itself should be contributed back to their project. Also, we should be prepared to allow them packaging rights in cAos to help and/or assume maintainership of their software in cAos. I want to mention that if there is something that does not make sense you should bring it up for discussion (both newbies and experts) on this list. Greg -- /* Greg Kurtzer, http://runlevelzero.net/greg/ * * Open Source Projects: * cAos: http://caosity.org/ * Warewulf: http://warewulf-cluster.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 Aug 6 23:07:26 2003 From: herrold at owlriver.com (R P Herrold) Date: Thu, 7 Aug 2003 02:07:26 -0400 (EDT) Subject: [cAos] Re: cAos] Package management... In-Reply-To: <20030807051937.GC21208@titan.runlevelzero.net> Message-ID: On Wed, 6 Aug 2003, Greg Kurtzer wrote: > On Thu, Aug 07, 2003 at 12:56:28AM -0400, R P Herrold told me: > > > Remember that it will be the same SRPM that will be compiled for the different > > > cAos major versions. This means that there will not be any differentiation > > > between the package nomenclature for cAos-1 and cAos-2... > > > > > > Should this principal be revisited? > > > > heh - who said anything about cAos-2 yet -- although I was > > thinking of compiling foo from the same .spec file for for > > both kernel 2.4 / rpm 4.1 (cAos-1) and kernel-2.5 / rpm 4.3 > > (cAos-2) > > Then wouldn't the name be a bit more like: > > foo-2.34-4orcCA1.src.rpm > foo-2.34-4orcCA2.src.rpm If we NEED a SRPM with differing patches, a single .spec file can do it. But usually, and hopefully, thiuw will be rare. The code which generates "CA1" vs "CA2" will be automatically genreated and inserted, can be in a single non-distribution-segregated .spec file Lines like this: # Requires: redhat-release >= %{__RHmajor}.0 Requires: redhat-release < %{__RHnext}.0 # will key a RPM to the 'caos-release' major variant; by extension, # BuildRequires: redhat-release >= %{__RHmajor}.0 BuildRequires: redhat-release < %{__RHnext}.0 # can be used to limit where an unmodified SRPM will recompile. uggh. 'RPM is just a packaging tool' For a nasty real world example, (for autorpm-2.x) see: ftp://ftp.owlriver.com/pub/mirror/ORC/ perl-Term-ReadLine-Gnu/perl-Term-ReadLine-Gnu.spec paste it together, and read, and prepare to cry in terror at the shell conditionals which do this. There were THREE readline versions in the two years RHL 7x was in release and getting a cpan module to select the correct one was ... ... challenging. -- Russ From greg at runlevelzero.net Wed Aug 6 23:18:00 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Wed, 6 Aug 2003 23:18:00 -0700 Subject: [cAos] RPMVERCMP - was Re: cAos] Package management... In-Reply-To: References: <20030807044354.GA21208@titan.runlevelzero.net> Message-ID: <20030807061800.GF21208@titan.runlevelzero.net> On Thu, Aug 07, 2003 at 01:55:22AM -0400, R P Herrold told me: > > Good point, but I think that rpmlib actually does not > > compare alphas (much to my dismay) but Russ could correct me > > if I am wrong. > > nope, a correction is needed (it most definitely DOES do > strcmp's (so-called alpha use)) -- From the code itself, from > the comments in the code, and from the JBJ and third party > analysis and testing on the code, this is my analysis. Ahh, the pseduo code makes perfect sence and is almost exactly to how GRAB does it. :) Thanks! Greg -- /* Greg Kurtzer, http://runlevelzero.net/greg/ * * Open Source Projects: * cAos: http://caosity.org/ * Warewulf: http://warewulf-cluster.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 Aug 6 23:48:30 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Wed, 6 Aug 2003 23:48:30 -0700 Subject: [cAos] Other SPEC nomenclature... Message-ID: <20030807064830.GG21208@titan.runlevelzero.net> The following fields in the SPEC must be present and filled out: %_missing_doc_files_terminate_build 1 %_unpackaged_files_terminate_build 1 License: Vendor: cAos http://caosity.org/ Packager: Your Name URL: Epoch: Source0: http://blah.com/package.tar.gz (and yes, I am going to start taking my own advice) Greg -- /* Greg Kurtzer, http://runlevelzero.net/greg/ * * Open Source Projects: * cAos: http://caosity.org/ * Warewulf: http://warewulf-cluster.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 Thu Aug 7 07:55:01 2003 From: herrold at owlriver.com (R P Herrold) Date: Thu, 7 Aug 2003 10:55:01 -0400 (EDT) Subject: [cAos] Re: cAos] Other SPEC nomenclature... In-Reply-To: <20030807064830.GG21208@titan.runlevelzero.net> Message-ID: On Wed, 6 Aug 2003, Greg Kurtzer wrote: > The following fields in the SPEC must be present and filled out: > Vendor: cAos http://caosity.org/ > Packager: Your Name ummm -0- as a matter of consistency and to reduce support load, these two are customarily NOT hardcoded in the individual .spec file, but rather sourced from ~/.rpmmacros This is so when a third party rebuilds a .spec file you have packaged, (but they may have partially modified), they will NOT get your personal values present in the result, and you will not get a support request on something you did not really BUILD Rather than re-inventing the wheel here, it may be productive to look at the rpmlint package which considers a LOT of issues There are some other independent packagers who have announced by fiat, packaging rules without dicussion and consensus, and have had to backtrack (in addition to the credibility hit ). Getting the thoughts of others -- through 'lint and discussion are likely to produce a happier result. -- Russ From herrold at owlriver.com Thu Aug 7 09:11:01 2003 From: herrold at owlriver.com (R P Herrold) Date: Thu, 7 Aug 2003 12:11:01 -0400 (EDT) Subject: [cAos] Re: cAos] Version nomenclature... In-Reply-To: <20030807055717.GD21208@titan.runlevelzero.net> Message-ID: On Wed, 6 Aug 2003, Greg Kurtzer wrote: > OK, based on the 'Package management...' thread, I think we have enough info > to draft out the version nomenclature document, so here goes round one: > > There are three scenarios that I see for migrating a new package or existing > package version into cAos: > > 1. Building an original SPEC file for a piece of software > 2. Migrating an existing unmodified SPEC from an existing known source > 3. Migrating an existing unmodified SPEC from an existing unknown source > 4. Using #2 as a basis, and enhancing or forking from it (fix or patch) is that the West Coast way of counting to three? ;) > The nomenclatures for each are as follows: the snipped part was all fine by me. > Additional responsibilities: > > 1. Every time we develop a SPEC for a package, the developers should be > notified and the SRPM itself should be contributed back to their > project. Also, we should be prepared to allow them packaging rights in > cAos to help and/or assume maintainership of their software in cAos. some developers (particularly in the non-RPM world) are flummoxed by using cpio -- unified Diffs may and a .spec file may be kinder to the upstream maintainer. - -Russ From lance at uklinux.net Fri Aug 8 15:08:25 2003 From: lance at uklinux.net (Lance Davis) Date: Fri, 8 Aug 2003 23:08:25 +0100 (BST) Subject: [cAos] Re: cAos] Package management... In-Reply-To: <20030807044354.GA21208@titan.runlevelzero.net> Message-ID: On Wed, 6 Aug 2003, Greg Kurtzer wrote: > On Wed, Aug 06, 2003 at 10:41:05PM +0100, Lance Davis told me: > > But all of the information is already contained within the rpm, and > > changing the release of an otherwise identical rpm seems unnecessary and > > liable to cause confusion. > > Cause confusion? could you explain? because people may think that we had made revisions to the rpm that we hadnt made. > Good point, but I think that rpmlib actually does not compare alphas (much to > my dismay) but Russ could correct me if I am wrong. I think he did ;) > > > so what happens with > > > > gcc-3.2.2-5rhl.src.rpm aka gcc-3.2.2-5.src.rpm > > > > presumably 5rhl and 5caos are both later than 5 , but would 5caos be > > earlier than 5rhl ??? > > I think that if we rebuilt the package, we would increment the build so it > would be comparing: > > gcc-3.2.2-6rhl.src.rpm and gcc-3.2.2-5.src.rpm I cant see why we should increment the release just because we built the rpm ?? Then if redhat release gcc-3.2.2-6 people couldnt upgrade our rpm to it because it would appear an earlier version than gcc-3.2.2-6rhl which is in fact gcc-3.2.2-5 ??? I think that if we change it at all then gcc-3.2.2-5 should become gcc-3.2.2-5rhl but only to signify the origin, which anyway is obvious from the packager etc. > Remember that it will be the same SRPM that will be compiled for the different > cAos major versions. This means that there will not be any differentiation > between the package nomenclature for cAos-1 and cAos-2... > > Should this principal be revisited? Errmmmm .. anyway I'm away for a weeks holiday from tomorrow morning, I'll check my email and deal with pager emergencies but other than that its beer and beach :) Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From greg at runlevelzero.net Fri Aug 8 15:21:21 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Fri, 8 Aug 2003 15:21:21 -0700 Subject: [cAos] Re: cAos] Package management... In-Reply-To: References: <20030807044354.GA21208@titan.runlevelzero.net> Message-ID: <20030808222121.GA17580@titan.runlevelzero.net> On Fri, Aug 08, 2003 at 11:08:25PM +0100, Lance Davis told me: > > > changing the release of an otherwise identical rpm seems unnecessary and > > > liable to cause confusion. > > > > Cause confusion? could you explain? > > because people may think that we had made revisions to the rpm that we > hadnt made. RedHat puts changelog entries for building, and IMHO any changelog entries should warrant a Release increment (actually any changes to the SPEC at all). I think that your point is good, but I am not sure where we draw the line on SPEC file modifications affecting the Release increment. > I cant see why we should increment the release just because we built the > rpm ?? > > Then if redhat release gcc-3.2.2-6 people couldnt upgrade our rpm to it > because it would appear an earlier version than gcc-3.2.2-6rhl which is in > fact gcc-3.2.2-5 ??? Valid point. What are your thoughts as to when a Release should be incremented? > I think that if we change it at all then gcc-3.2.2-5 should become > gcc-3.2.2-5rhl but only to signify the origin, which anyway is obvious > from the packager etc. I can live with this. Is this alright with others? > > Remember that it will be the same SRPM that will be compiled for the different > > cAos major versions. This means that there will not be any differentiation > > between the package nomenclature for cAos-1 and cAos-2... > > > > Should this principal be revisited? > > Errmmmm .. I take that as a definite maybe... Please elaborate. > anyway I'm away for a weeks holiday from tomorrow morning, I'll check my > email and deal with pager emergencies but other than that its beer and > beach :) Respond back at your leisure, and have some fun! Greg -- /* Greg Kurtzer, http://runlevelzero.net/greg/ * * Open Source Projects: * cAos: http://caosity.org/ * Warewulf: http://warewulf-cluster.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 Aug 8 15:34:09 2003 From: lance at uklinux.net (Lance Davis) Date: Fri, 8 Aug 2003 23:34:09 +0100 (BST) Subject: [cAos] Re: cAos] Package management... In-Reply-To: <20030808222121.GA17580@titan.runlevelzero.net> Message-ID: On Fri, 8 Aug 2003, Greg Kurtzer wrote: > I think that your point is good, but I am not sure where we draw the line > on SPEC file modifications affecting the Release increment. I thought we were talking about just taking the redhat rpoms without modification ?? eg no patches etc etc > > I cant see why we should increment the release just because we built the > > rpm ?? > > > > Then if redhat release gcc-3.2.2-6 people couldnt upgrade our rpm to it > > because it would appear an earlier version than gcc-3.2.2-6rhl which is in > > fact gcc-3.2.2-5 ??? > > Valid point. What are your thoughts as to when a Release should be > incremented? If we make a change to it that affects the code. The fact that we add rhl indicates that we have rebuilt it and that the rpm isnt necesaarily the same as the one built and released by rh. > > > Remember that it will be the same SRPM that will be compiled for the different > > > cAos major versions. This means that there will not be any differentiation > > > between the package nomenclature for cAos-1 and cAos-2... > > > > > > Should this principal be revisited? > > > > Errmmmm .. > > I take that as a definite maybe... Please elaborate. It wasnt - if the same rpm is used for the two versions then is there a need to differentiate them ?? If it was built differently then there may be , eg architecture etc ?? Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From greg at runlevelzero.net Fri Aug 8 16:36:06 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Fri, 8 Aug 2003 16:36:06 -0700 Subject: [cAos] Re: cAos] Package management... In-Reply-To: References: <20030808222121.GA17580@titan.runlevelzero.net> Message-ID: <20030808233606.GA18049@titan.runlevelzero.net> On Fri, Aug 08, 2003 at 11:34:09PM +0100, Lance Davis told me: > > I think that your point is good, but I am not sure where we draw the line > > on SPEC file modifications affecting the Release increment. > > I thought we were talking about just taking the redhat rpoms without > modification ?? eg no patches etc etc I guess I am even thinking of SPEC changes (not patch or source code mods), and that these changes should also result in a Release increment. > > Valid point. What are your thoughts as to when a Release should be > > incremented? > > If we make a change to it that affects the code. The fact that we add rhl > indicates that we have rebuilt it and that the rpm isnt necesaarily the > same as the one built and released by rh. If we take a RH RPM, and modify the code in it (ie. patch) then it should be renamed as a caos pacakge and incremented. > > > Errmmmm .. > > > > I take that as a definite maybe... Please elaborate. > > It wasnt - if the same rpm is used for the two versions then is there a > need to differentiate them ?? You lost me there... Same RPM, different versions? > If it was built differently then there may be , eg architecture etc ?? Ahh... I think I now know where you are going with this. Maybe this will help: Assumptions: 1. Any changes to the source tarball must result in an incremented Version tag. 2. Any changes to any patch(s) will result in an incremented Release tag. 3. Any changes to the SPEC itself will also result in an incremented Release tag. 4. You will never submit a package for rebuild on the same arch with the same version/release tags (if a build fails, then you must make a change to the source or SPEC which results in a new release). 5. If a cAos maintainer makes a change to any source code (ie. source tree or patch) of a non-cAos package, then that package itself will be renamed as a caos pacakge in the Version or Release tag (depending on what was changed). Does that explain things better? Greg -- /* Greg Kurtzer, http://runlevelzero.net/greg/ * * Open Source Projects: * cAos: http://caosity.org/ * Warewulf: http://warewulf-cluster.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 Aug 8 22:16:24 2003 From: herrold at owlriver.com (R P Herrold) Date: Sat, 9 Aug 2003 01:16:24 -0400 (EDT) Subject: [cAos] Re: cAos] Re: cAos] Package management... In-Reply-To: <20030808233606.GA18049@titan.runlevelzero.net> Message-ID: On Fri, 8 Aug 2003, Greg Kurtzer wrote: > Assumptions: > > 1. Any changes to the source tarball must result in an incremented Version > tag. ummm -- no: a source tarball needs to remail unchaged, to preserve pristine sources, and so that any relevant upstream md5sums remain intact > 2. Any changes to any patch(s) will result in an incremented Release tag. > 3. Any changes to the SPEC itself will also result in an incremented > Release tag. > 4. You will never submit a package for rebuild on the same arch with the > same version/release tags (if a build fails, then you must make a change > to the source or SPEC which results in a new release). I would anticipate that a Packager will pre-test a build on their local machine and environment, so this will be rare. > 5. If a cAos maintainer makes a change to any source code (ie. source tree > or patch) of a non-cAos package, then that package itself will be > renamed as a caos pacakge in the Version or Release tag (depending on > what was changed). > > Does that explain things better? makes sense to me. - Russ Herrold From greg at runlevelzero.net Fri Aug 8 23:30:38 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Fri, 8 Aug 2003 23:30:38 -0700 Subject: [cAos] Re: cAos] Re: cAos] Package management... In-Reply-To: References: <20030808233606.GA18049@titan.runlevelzero.net> Message-ID: <20030809063038.GA20778@titan.runlevelzero.net> On Sat, Aug 09, 2003 at 01:16:24AM -0400, R P Herrold told me: > > Assumptions: > > > > 1. Any changes to the source tarball must result in an incremented Version > > tag. > > ummm -- no: a source tarball needs to remail unchaged, to > preserve pristine sources, and so that any relevant upstream > md5sums remain intact What about a new version or a package? ;) I wasn't thinking of modifying the source package by us... Always patches! > > 4. You will never submit a package for rebuild on the same arch with the > > same version/release tags (if a build fails, then you must make a change > > to the source or SPEC which results in a new release). > > I would anticipate that a Packager will pre-test a build on > their local machine and environment, so this will be rare. I suppose it could fail if there was a build dependancy that was missing. > makes sense to me. OK, I will start drafting up some docs... Thanks all! -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From herrold at owlriver.com Sat Aug 9 00:14:56 2003 From: herrold at owlriver.com (R P Herrold) Date: Sat, 9 Aug 2003 03:14:56 -0400 (EDT) Subject: [cAos] Re: cAos] Package management... In-Reply-To: <20030809063038.GA20778@titan.runlevelzero.net> References: <20030808233606.GA18049@titan.runlevelzero.net> <20030809063038.GA20778@titan.runlevelzero.net> Message-ID: On Fri, 8 Aug 2003, Greg Kurtzer wrote: > > preserve pristine sources, and so that any relevant upstream > > md5sums remain intact > > What about a new version or a package? ;) A new version, under the principle of conforming version number to the package Maintainer's numbering, already covers doing that version number change. I read your setup of a 'change' to a tarball incorrectly -- sorry. -- Russ From greg at runlevelzero.net Sat Aug 9 21:03:14 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sat, 9 Aug 2003 21:03:14 -0700 Subject: [cAos] caosity site changes In-Reply-To: References: Message-ID: <20030810040314.GA31701@titan.runlevelzero.net> Sorry for the _really_ late response on this. I had it marked to go back to, and am only now getting to it... Comments inline: On Tue, Jul 22, 2003 at 01:44:47PM -0400, R P Herrold told me: > 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. Why not include security matters in this? > [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. Hopefully we will not also wither etc... Maybe having the core team paid using a funded non-profit is the future. > 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] 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] describe some more please... > ------- snip ends ------ I totally agree on this. I will add some more room in the DB to allow for this data, and build the ACL's so the package maintainers themselves can modify this (typically the PMs can not touch the main package tables, so I may create a separate table for this). > 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. Agreed. Just to reiterate and confirm, everyone is in agreement that this should go into the caosity DB, and allow the package maintainers control of this info...? > -- 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/ Why not the /usr/share/docs/%{package}-%{version}-%{release} dir? > Getting all that exist, making such items them conveniently > visible seems important to me. Agreed. Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Sun Aug 10 14:10:02 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sun, 10 Aug 2003 14:10:02 -0700 Subject: [cAos] [gmkurtzer@lbl.gov: Re: [Univ-linux] plans] Message-ID: <20030810211002.GA16910@titan.runlevelzero.net> Woops, I forwarded this to caos at caosity.org, not caos at runlevelzero.net... I guess I should fix this so it works! Bugzilla... Where are you? Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ -------------- next part -------------- An embedded message was scrubbed... From: Greg Kurtzer Subject: Re: [Univ-linux] plans Date: Sun, 10 Aug 2003 13:59:21 -0700 Size: 3580 Url: http://lists.infiscale.org/pipermail/caos/attachments/20030810/bd304f61/attachment.mht From greg at runlevelzero.net Sun Aug 10 14:26:38 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sun, 10 Aug 2003 14:26:38 -0700 Subject: [cAos] Re: cAos] Version nomenclature... In-Reply-To: References: <20030807055717.GD21208@titan.runlevelzero.net> Message-ID: <20030810212638.GA17064@titan.runlevelzero.net> On Thu, Aug 07, 2003 at 12:11:01PM -0400, R P Herrold told me: > > There are three scenarios that I see for migrating a new package or existing > > package version into cAos: > > > > 1. Building an original SPEC file for a piece of software > > 2. Migrating an existing unmodified SPEC from an existing known source > > 3. Migrating an existing unmodified SPEC from an existing unknown source > > 4. Using #2 as a basis, and enhancing or forking from it (fix or patch) > > is that the West Coast way of counting to three? ;) Sorry for the late response! It took me this long just to figure out what you meant! Actually, I start with three then added another. > some developers (particularly in the non-RPM world) are > flummoxed by using cpio -- unified Diffs may and a .spec file > may be kinder to the upstream maintainer. Agreed. I will then start building some new docs to explain this. Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Sun Aug 10 14:30:18 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sun, 10 Aug 2003 14:30:18 -0700 Subject: [cAos] Re: cAos] Other SPEC nomenclature... In-Reply-To: References: <20030807064830.GG21208@titan.runlevelzero.net> Message-ID: <20030810213018.GB17064@titan.runlevelzero.net> On Thu, Aug 07, 2003 at 10:55:01AM -0400, R P Herrold told me: > ummm -0- as a matter of consistency and to reduce support > load, these two are customarily NOT hardcoded in the > individual .spec file, but rather sourced from > ~/.rpmmacros Ahh, understood. The auto build system already supports this... > This is so when a third party rebuilds a .spec file you have > packaged, (but they may have partially modified), they will > NOT get your personal values present in the result, and you > will not get a support request on something you did not really > BUILD > > Rather than re-inventing the wheel here, it may be productive > to look at the rpmlint package which considers a LOT of issues I will check it out. > There are some other independent packagers who have announced > by fiat, packaging rules without dicussion and consensus, and > have had to backtrack (in addition to the credibility hit > ). Getting the thoughts of others -- through 'lint and > discussion are likely to produce a happier result. I will check out some stuff and make proposals. If anyone else has thoughts on this, post to list. Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From skvidal at phy.duke.edu Sun Aug 10 21:30:44 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 11 Aug 2003 00:30:44 -0400 Subject: [cAos] Re: [Univ-linux] plans In-Reply-To: <20030810205921.GC18911@tux.lbl.gov> References: <1060486681.3938.37.camel@binkley> <20030810142713.GA18911@tux.lbl.gov> <1060527123.3938.114.camel@binkley> <20030810155500.GA10692@jadzia.bu.edu> <20030810190737.GB18911@tux.lbl.gov> <20030810194529.GA15622@jadzia.bu.edu> <20030810205921.GC18911@tux.lbl.gov> Message-ID: <1060576243.15116.81.camel@binkley> > The easy way to explain my side is if it requires $$, has a EULA and comes > from RH it is one of their enterprise products! :) > > The community beta is a beta for the enterprise lines as it has been described > to us by RH sales. We don't want to run beta software, but will pay for the > enterprise version if we can afford it (I have moral issues with buying a 95% > free product, but I must put that aside). According to RH sales, their regular > distro has been discontinued. I'd say the sales person involved didn't know what they were saying, then. As Matt said - from a sales standpoint they're right, but I think from our standpoint, which is not a sales perspective they are more wrong than ever. I've talked with a number of developers at red hat and this seems to be a genuine effort to open up the distro, not just a place to get some free testing. I agree about not wanting to buy enterprise. I'm not for that either. I'll not begrudge them their need to bring in customers/money, but I can't reasonably be one and I don't think, for the most part, that it would make sense for a university. > Things are changing with RH (as we can see), and they are shifting their > efforts to the enterprise and seeming to leave the community space. This is a > rather large niche which has no present solution. Debian and Gentoo are the > prominent community based solutions, but they are both very different from the > RH type architecture that most have standardized on. (BTW, this is where and > why caosity.org comes into play). Once again, from my perspective RH is doing > the right thing as a corporation and for adoption of Linux in the enterprise. > Corporations must make money, and giving away free community utilized > distributions can only be supported as a lost leader for so long especially in > this market. I project that the future of the free community based Linux > distros will have to be non-commercial community projects otherwise they will > have a hard profit model to maintain. I don't think your opinions are anymore biased than anyone else's :) I disagree with you, at this time, though. From talks with some of the devel people at red hat the RHL project is a legit intent. It isn't just some marketing bullshit intended to get free testing. The people involved really want to open up the distro more. If you noticed they decided to push back the release date for the next version in order to make sure gnome 2.4 could get b/c of all the user comments/requests on the list. That's something that didn't happen in the past. Hell, they included yum in rawhide which is a big deal b/c it opens up the 3rd party repository direction and it is a non-up2date/rhn-based updating/installation tool. I am being optimistic at the moment, which is not characteristic of me, but I'd like to think that the RHL Project in combination with efforts from non-profit groups, specifically in the academic sector, could work well for us all. For universities b/c we could continue getting the operating system for completely free, for red hat b/c they'd get more testing and more packages that have seen a lot of real use in an academic sector (that they could then sell to the corporate sector), and for the community at large b/c of more people working at a roughly common goal. so that's my biased opinion. -sv From herrold at owlriver.com Wed Aug 13 14:01:15 2003 From: herrold at owlriver.com (R P Herrold) Date: Wed, 13 Aug 2003 17:01:15 -0400 (EDT) Subject: [cAos] I am not a paranoid, I tell you Message-ID: ftp://alpha.gnu.org/MISSING-FILES.README has some unhappy news about compromise of a major upstream trove for Open Source software. Archival copy at http://www.owlriver.com/projects/packaging/gnu-crack.pdf the upshot of course being that signature checking is an essential part of preparing a distribution. -- Russ Herrold From herrold at owlriver.com Wed Aug 13 22:51:13 2003 From: herrold at owlriver.com (R P Herrold) Date: Thu, 14 Aug 2003 01:51:13 -0400 (EDT) Subject: [cAos] From another list RvR post - rh-beta] Re: RH Decisions (was Re: APT, Yum and Red Carpet) (fwd) Message-ID: I have dealt with Rik on another project from a year and a half ago, and always find his posts thoughtful. Jef Spaleta (to whom he is reacting) is also worth watching. As cAos has been angling for a small base install footprint from the start, his comments seemed worth a read. Also, the Kernighan quote at the end has caused a couple of list members a chuckle. - Russ Herrold ---------- Forwarded message ---------- Date: Thu, 14 Aug 2003 00:55:52 -0400 (EDT) From: Rik van Riel Reply-To: rhl-beta-list at redhat.com To: rhl-beta-list at redhat.com Subject: rh-beta] Re: RH Decisions (was Re: APT, Yum and Red Carpet) On 14 Aug 2003, Jef Spaleta wrote: > Kyle Maxwell wrote: > >But some decisions are starting to leave me in the cold > > Err..well...i'm going to give red hat a pretty long lead time on when I > expect them to get this whole external communication thing close to the > right ballpark. One of the reasons why things are taking a while is that everybody was away, first in Ottawa for OLS and then at Linuxworld in California. > I think it helps to think of this beta as still a traditional > beta....the community project still needs a lot of flushing out...as a > concept its alpha. Indeed, since the project went live around the same time as the Severn beta (beta == code freeze) this time the core release probably won't have all that much community input. Personally I hope this will result in a culture of using external repositories so the core distribution for the next version could be shrunk ;)) Of course I'm a kernel guy and mostly an onlooker when it comes to the distribution. I wouldn't be surprised if the people who are doing the actual work of putting together the distro ended up taking the decision of putting more cool stuff in their own repository, grabbing it from external repositories. On the other hand, I wouldn't be surprised by a "move stuff into external repositories and out of the core distro" movement, either. I am very curious which of the two will happen, though... > I can just imagine how much internal discussion is being generated.... We are trying to discuss all the technical things in public, though. On the rhl-devel-list and also in threads on this list. > and I can only hope the hatters show as good a sense of knowing how to > schedule a "release" of the project framework as they do about pushing > out distro releases. That is one of our requirements. We want this distribution to be at least as good for our own personal use as Red Hat Linux has been. That doesn't just mean a regular stable release with "fresh bits"; for me personally it also means being able to point the same update tool I use for the core distribution at other repositories, like freshrpms, fedora and a repository with some of my own RPMS. Note that even though I work at Red Hat, I don't think I will be trying to get the RPMS I am interested in into the core distribution. I want to publish the stuff I want to do in an external repository in order to: 1) have freedom on how I maintain things 2) run my own release schedule, independant of the core distribution and, most importantly 3) not hold up the core distribution when my packages lag because I'm busy with the kernel In short, I want to have all the benefits of a stable and regularly updated core distribution, while not adding the maintenance burden of my personal packages wishlist to that core distribution. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan -- Rhl-beta-list mailing list Rhl-beta-list at redhat.com http://www.redhat.com/mailman/listinfo/rhl-beta-list From greg at runlevelzero.net Thu Aug 14 01:05:12 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Thu, 14 Aug 2003 01:05:12 -0700 Subject: [cAos] Chris Yeoh Joined Steering Committee! Message-ID: <20030814080512.GA13464@titan.runlevelzero.net> News: Chris Yeoh from the Linux Standard Base (LSB) has joined the cAos steering committee. (http://ozlabs.org/people/cyeoh/) Because cAos is aiming at becoming a standard base Linux solution, having a representative of the LSB on the committee will ensure that even from the beginning we are moving in the right directions to maintain standards compliance. This is extremely important to the direction of cAos! Chris will be working with several LSB maintainers that will conduct the LSB compliance tests. These LSB maintainers will be community volunteers thus if there is anyone on the list that is NOT doing core OS development and who would like to volunteer for this role, please let Chris and I know (cyeoh at samba dot org) or reply to the list. Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Sat Aug 16 14:13:14 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sat, 16 Aug 2003 14:13:14 -0700 Subject: [cAos] is glib1 still needed? Message-ID: <20030816211313.GA10670@titan.runlevelzero.net> Does anyone know if glib1 is still needed (ie. are there API's that glib2 does not provide that glib1 does)? I see if I do a 'rpm -e --test glib' I get a lot of dep issues, but what if these packages are compiled against glib2 instead of glib1? It seems for almost all of these required glib1 file components, there is also a glib2 counterpart. Any ideas? Thanks, Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From herrold at owlriver.com Sat Aug 16 19:55:37 2003 From: herrold at owlriver.com (R P Herrold) Date: Sat, 16 Aug 2003 22:55:37 -0400 (EDT) Subject: [cAos] Re: cAos] is glib1 still needed? In-Reply-To: <20030816211313.GA10670@titan.runlevelzero.net> References: <20030816211313.GA10670@titan.runlevelzero.net> Message-ID: On Sat, 16 Aug 2003, Greg Kurtzer wrote: > Does anyone know if glib1 is still needed (ie. are there API's that glib2 does > not provide that glib1 does)? > > I see if I do a 'rpm -e --test glib' I get a lot of dep issues, but what if > these packages are compiled against glib2 instead of glib1? It seems for > almost all of these required glib1 file components, there is also a glib2 > counterpart. > > Any ideas? Sounds like a front-porting issue. Build a test build host without glib-devel-1* present, and recompile all the dependencies froom SRPM to see which rely on the old API. File upstream bugs for those which do. -- Russ From greg at runlevelzero.net Sat Aug 16 20:15:07 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sat, 16 Aug 2003 20:15:07 -0700 Subject: [cAos] Re: cAos] is glib1 still needed? In-Reply-To: References: <20030816211313.GA10670@titan.runlevelzero.net> Message-ID: <20030817031507.GA10960@titan.runlevelzero.net> On Sat, Aug 16, 2003 at 10:55:37PM -0400, R P Herrold told me: > Sounds like a front-porting issue. > > Build a test build host without glib-devel-1* present, and > recompile all the dependencies froom SRPM to see which rely on > the old API. File upstream bugs for those which do. It seems as though glib-devel is needed by the devel packages of gtk+, ORBit, and GConf. Chroot install tests next step... Will report later. Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Sun Aug 17 14:13:34 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sun, 17 Aug 2003 14:13:34 -0700 Subject: [cAos] package depots... Message-ID: <20030817211334.GA25331@titan.runlevelzero.net> I wrote up the scripts that will go through all of the package maintainers depots (their rsync directory), and delete anything in there that is not currently in the cAos package DB. So how often should this be checked and cleaned? I was thinking once per week, but maybe this is not often enough. Is every night too frequent? Also, consider this a warning that I will deleting all non-managed packages this evening. I will send out the warning mail shortly (only the maintainers of the package depot in question will get it). If you are not sure what this means, and you have packages in your depot then you should read http://caosity.org/usr_help.php or email me or the list. Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Mon Aug 18 10:30:22 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Mon, 18 Aug 2003 10:30:22 -0700 Subject: [cAos] WWW Pages to start looking at... Message-ID: <20030818173022.GA23324@titan.runlevelzero.net> I threw together a few more pages that I was hoping to get comments on: http://caosity.org/community.php http://caosity.org/cost.php Comments please... -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Mon Aug 18 23:36:14 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Mon, 18 Aug 2003 23:36:14 -0700 Subject: [cAos] /me assuming ownership of several packages. Message-ID: <20030819063614.GA5322@titan.runlevelzero.net> Several of you have not uploaded your SRPMS yet (after several weeks), so I stole some packages so I can start testing the cAos chroot installs. I have several more packages to build, but we are getting there! In any case, if you want any of the stolen packages back please let me know. Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From jekrous at lbl.gov Tue Aug 19 16:07:57 2003 From: jekrous at lbl.gov (Jay Krous) Date: Tue, 19 Aug 2003 16:07:57 -0700 Subject: [cAos] The Increasing Cost of Red Hat Linux? Message-ID: <3F42ADCD.6050100@lbl.gov> ..for those of you that missed this \. article a few days ago. The Increasing Cost of Red Hat Linux? An Anonymous Coward asks: "I work at a company with a large number of Linux servers in the data center. We're currently evaluating what distribution we want to use moving forward. Upgrading to Red Hat Enterprise from 7.2 would cost ~$350k just for the systems we already have deployed. Due to the change in Red Hat's release policy, we either have to move to Enterprise, or change distributions. Also, we don't have Oracle on any of these systems, but we will need it in the future. This leaves us with rather limited options. I'm interested hearing what other Slashdot readers are running, and planning?" http://ask.slashdot.org/article.pl?sid=03/08/15/233245&mode=thread&tid=106&tid=110&tid=185&tid=187 -- Jack (Jay) E. Krous III Computer Systems Engineer Information Technologies & Services Division Lawrence Berkeley National Laboratory (510) 495-2522 From jim at rossberry.com Tue Aug 19 16:37:48 2003 From: jim at rossberry.com (Jim Wildman) Date: Tue, 19 Aug 2003 19:37:48 -0400 (EDT) Subject: [cAos] The Increasing Cost of Red Hat Linux? In-Reply-To: <3F42ADCD.6050100@lbl.gov> Message-ID: Linux is free. Support is not. Free Linux + support < Windows < Proprietary Unix What I actually expect is that the Red Hat and Suse licensing models will force the smart organizations to reevaluate their entire software stack. ie, if I must pay the enterprise rate in order to get premo level support from Oracle, maybe I should look to see if Oracle is really the right answer for that problem. Maybe MySQL or PostgreSQL is a better choice. Maybe no. On Tue, 19 Aug 2003, Jay Krous wrote: > An Anonymous Coward asks: "I work at a company with a large number of > Linux servers in the data center. We're currently evaluating what > distribution we want to use moving forward. Upgrading to Red Hat > Enterprise from 7.2 would cost ~$350k just for the systems we already > have deployed. Due to the change in Red Hat's release policy, we either > have to move to Enterprise, or change distributions. Also, we don't have > Oracle on any of these systems, but we will need it in the future. This > leaves us with rather limited options. I'm interested hearing what other > Slashdot readers are running, and planning?" > > http://ask.slashdot.org/article.pl?sid=03/08/15/233245&mode=thread&tid=106&tid=110&tid=185&tid=187 > > > > ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com From greg at runlevelzero.net Tue Aug 19 16:39:40 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 19 Aug 2003 16:39:40 -0700 Subject: [cAos] The Increasing Cost of Red Hat Linux? In-Reply-To: <3F42ADCD.6050100@lbl.gov> References: <3F42ADCD.6050100@lbl.gov> Message-ID: <20030819233940.GA18505@titan.runlevelzero.net> Does anyone else find it hard not to post a reply to this?! :) I am working hard trying to get the base system built. Once that is done Russ can throw that onto a bootable live ISO, and we can start hacking out the details and changes. I am guessing that will be ready at most in a week. Greg On Tue, Aug 19, 2003 at 04:07:57PM -0700, Jay Krous told me: > > ..for those of you that missed this \. article a few days ago. > > The Increasing Cost of Red Hat Linux? > > An Anonymous Coward asks: "I work at a company with a large number of > Linux servers in the data center. We're currently evaluating what > distribution we want to use moving forward. Upgrading to Red Hat > Enterprise from 7.2 would cost ~$350k just for the systems we already > have deployed. Due to the change in Red Hat's release policy, we either > have to move to Enterprise, or change distributions. Also, we don't have > Oracle on any of these systems, but we will need it in the future. This > leaves us with rather limited options. I'm interested hearing what other > Slashdot readers are running, and planning?" > > http://ask.slashdot.org/article.pl?sid=03/08/15/233245&mode=thread&tid=106&tid=110&tid=185&tid=187 > > > > -- > Jack (Jay) E. Krous III > Computer Systems Engineer > Information Technologies & Services Division > Lawrence Berkeley National Laboratory > (510) 495-2522 > > > > _______________________________________________ > cAos mailing list > cAos at runlevelzero.net > http://www.caosity.org/mailman/listinfo/caos -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Tue Aug 19 16:42:47 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 19 Aug 2003 16:42:47 -0700 Subject: [cAos] Drake tools... Message-ID: <20030819234247.GB18505@titan.runlevelzero.net> Has anyone here played with Mandrake, specifically the DrakeX tools? Very nice tools to facilitate system administration. I would like to start looking into them (coded in perl I believe) to see if it can be ported to a RH like system. Volunteers? Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Tue Aug 19 16:48:46 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 19 Aug 2003 16:48:46 -0700 Subject: [cAos] Reminder about IRC... Message-ID: <20030819234846.GA18841@titan.runlevelzero.net> I was talking to someone earlier today about cAos, and apparently they did not know that we are on IRC (like almost all of the time) so I thought I would throw this out there for all who are interested. Point your IRC client at irc.freenode.net channel cAos (/join #cAos). If you don't know IRC, then check out xchat (simple GTK-GUI IRC client). Join up and announce yourself! :) BTW: I really like IRC for getting general ideas out there and to argue (whoops, I mean discuss) principals, but as they start to form and take shape it should move to email lists. Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Wed Aug 20 00:11:36 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Wed, 20 Aug 2003 00:11:36 -0700 Subject: [cAos] Free Business... Message-ID: <20030820071136.GA26972@titan.runlevelzero.net> I posted a new page that I want everyone to check out. It is of course in rough draft form but I wanted to get it out there so that people can comment on the principals. http://caosity.org/free_business.php Thanks, Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From julia at runlevelzero.net Wed Aug 20 08:42:09 2003 From: julia at runlevelzero.net (j) Date: Wed, 20 Aug 2003 08:42:09 -0700 Subject: [cAos] Free Business... In-Reply-To: <20030820071136.GA26972@titan.runlevelzero.net> Message-ID: first and most importantly, the words "non-profit" should be removed. that sentence will read nicer if you just get rid of it, as you will lose an important portion of the audience right there. non profit has become synonymous with: failing businesses, tax evading businesses, organizations that donate 1% to whatever but drive mercedes, and of corse, religious groups. if you like the idea, make up a different word. you have "free business" bullets twice. some could use more plain, simple verbiage that describe the idea more. remember some people reading this will have no background on what you are doing or how things work at all in the open source community. HOWEVER, keep it short! no more than a few well planned sentences for each bullet. so where the hell is the certificate? theres just the prices, whats the point of getting one? they should get a little page to print thats all cute and looks like a certificate (people like to hold things) maybe say something like " You have just done a good deed, here is a cookie". one more thing: add some fun to it. serious doesnt have to be stern. if this is a new kind of thing, then maybe it can be not as boring as business usually is. your target audience is humans who I have observed gravitate toward a more pleasurable approach to life. oh yeah, looks good j On Wednesday, August 20, 2003, at 12:11 AM, Greg Kurtzer wrote: > I posted a new page that I want everyone to check out. It is of course > in > rough draft form but I wanted to get it out there so that people can > comment > on the principals. > > http://caosity.org/free_business.php > > Thanks, > Greg > -- > Greg M. Kurtzer > http://runlevelzero.net/ > http://caosity.org/ > http://warewulf-cluster.org/ > _______________________________________________ > cAos mailing list > cAos at runlevelzero.net > http://www.caosity.org/mailman/listinfo/caos > From zoratu at datastacks.com Wed Aug 20 09:07:15 2003 From: zoratu at datastacks.com (Isaiah) Date: Wed, 20 Aug 2003 09:07:15 -0700 Subject: [cAos] Free Business... In-Reply-To: ; from julia@runlevelzero.net on Wed, Aug 20, 2003 at 08:42:09AM -0700 References: <20030820071136.GA26972@titan.runlevelzero.net> Message-ID: <20030820090715.A8673@zoratu.com> Yowsa, harsh. Here are some tips which apply to most writing where you might have a copy-edit, reinforcing one of the points below and adding some more tips. I got them from J. Opp at Red Hat. --> - Mix short and long sentences. Even an occasional sentence fragment. Write how people talk. - Short sentences connote confidence and determination. - Use words with fewer syllables. The copy will read faster and be easier to understand. Try to find a replacement for every word that's three syllables or more. - Brevity. Ever notice how some of the smartest people write really short emails? Look at your copy, cut 10 unnecessary words. Was it easy? Look for 10 more. - One-word verbs are better than two-word verbs. - If you get stuck on how to start: Hemingway said, "Write the truest sentence you know." - Grammar-bending is fine if the reader knows you did it on purpose. - Go easy on the marketing terms. "Meeting your needs," "leverage," "offerings"--non-marketers don't talk like this. - Why "professional" language doesn't work: 1. We're conditioned to distrust those who won't level with us. 2. Sometimes professional language is intentionally used to confuse or deceive. e.g. contracts, EULAs, etc. 3. None of your friends talk this way. - Think of copy as a one-on-one conversation rather than a speech. Personality is important, too. Being real to the reader is critical. But so is having a consistent organization personality. People relate to companies in the same way they relate to other people. When we're consistent in our expression--whether design or copy--the customers will recognize this personality as uniquely [y]our own. In copy, one way to find this personality is to write as though you're writing for a character. Now imagine Kevin Spacey playing a typical Spacey movie role. He uses simple words, short sentences. He's bold, confident, unflinching, and has a sharp sense of humor. Now imagine this Spacey character with the technical prowess of some computer genius. How would this person talk? Would they waste your time with the language of marketing? Or would they tell it like it is? Note: It's still your words and your personality. But when you imagine the copy as delivered through the voice of the character, you hear his direct, natural pacing. You hear when sentences grow too long or complicated. And sometimes just trying to *hear* the copy can make a big difference. When we read, our minds process written words into speech. (which is why we can listen faster than we can read) So making the copy read like natural speech helps the reader hear it and process it faster. <-- On Wed, Aug 20, 2003 at 08:42:09AM -0700, j wrote: > first and most importantly, the words "non-profit" should be removed. > that sentence will read nicer if you just get rid of it, as you will > lose an important portion of the audience right there. > non profit has become synonymous with: failing businesses, tax evading > businesses, organizations that donate 1% to whatever but drive > mercedes, and of corse, religious groups. > if you like the idea, make up a different word. > > you have "free business" bullets twice. > > some could use more plain, simple verbiage that describe the idea more. > remember some people reading this will have no background on what you > are doing or how things work at all in the open source community. > HOWEVER, keep it short! no more than a few well planned sentences for > each bullet. > > so where the hell is the certificate? theres just the prices, whats the > point of getting one? they should get a little page to print thats all > cute and looks like a certificate (people like to hold things) maybe > say something like " You have just done a good deed, here is a cookie". > > one more thing: add some fun to it. serious doesnt have to be stern. if > this is a new kind of thing, then maybe it can be not as boring as > business usually is. your target audience is humans who I have observed > gravitate toward a more pleasurable approach to life. > > oh yeah, > looks good > j > > > > On Wednesday, August 20, 2003, at 12:11 AM, Greg Kurtzer wrote: > > > I posted a new page that I want everyone to check out. It is of course > > in > > rough draft form but I wanted to get it out there so that people can > > comment > > on the principals. > > > > http://caosity.org/free_business.php > > > > Thanks, > > Greg > > -- > > Greg M. Kurtzer > > http://runlevelzero.net/ > > http://caosity.org/ > > http://warewulf-cluster.org/ > > _______________________________________________ > > cAos mailing list > > cAos at runlevelzero.net > > http://www.caosity.org/mailman/listinfo/caos > > > > _______________________________________________ > cAos mailing list > cAos at runlevelzero.net > http://www.caosity.org/mailman/listinfo/caos -- - Isaiah From greg at runlevelzero.net Wed Aug 20 09:32:06 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Wed, 20 Aug 2003 09:32:06 -0700 Subject: [cAos] Free Business... In-Reply-To: <20030820090715.A8673@zoratu.com> References: <20030820071136.GA26972@titan.runlevelzero.net> <20030820090715.A8673@zoratu.com> Message-ID: <20030820163206.GA31324@titan.runlevelzero.net> On Wed, Aug 20, 2003 at 09:07:15AM -0700, Isaiah told me: > Yowsa, harsh. Who was harsh? ;) > Here are some tips which apply to most writing where you might have a > copy-edit, reinforcing one of the points below and adding some more tips. > I got them from J. Opp at Red Hat. Very good advice, and I will keep it on file! Hopefully it is not RH IP! I think that Seth on the Yum list has been affecting me. I find myself fighting the urge to mention that it sounds like you just volunteered yourself for this! Seriously, I need help editing the web pages. Are there any volunteers? Now that I got my thoughts out there, who can help fine tune them? -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From zoratu at datastacks.com Wed Aug 20 09:56:51 2003 From: zoratu at datastacks.com (Isaiah) Date: Wed, 20 Aug 2003 09:56:51 -0700 Subject: [cAos] Free Business... In-Reply-To: <20030820163206.GA31324@titan.runlevelzero.net>; from greg@runlevelzero.net on Wed, Aug 20, 2003 at 09:32:06AM -0700 References: <20030820071136.GA26972@titan.runlevelzero.net> <20030820090715.A8673@zoratu.com> <20030820163206.GA31324@titan.runlevelzero.net> Message-ID: <20030820095651.A9690@zoratu.com> On Wed, Aug 20, 2003 at 09:32:06AM -0700, Greg Kurtzer wrote: > Very good advice, and I will keep it on file! Hopefully it is not RH IP! Nah, but I thought I'd give him his due-credit in case he ever Googles for himself. > I think that Seth on the Yum list has been affecting me. I find myself > fighting the urge to mention that it sounds like you just volunteered > yourself for this! > > Seriously, I need help editing the web pages. Are there any volunteers? > Now that I got my thoughts out there, who can help fine tune them? Flip the bits that let me edit and I'll make some time. -- - Isaiah From greg at runlevelzero.net Wed Aug 20 11:15:46 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Wed, 20 Aug 2003 11:15:46 -0700 Subject: [cAos] Free Business... In-Reply-To: <20030820095651.A9690@zoratu.com> References: <20030820071136.GA26972@titan.runlevelzero.net> <20030820090715.A8673@zoratu.com> <20030820163206.GA31324@titan.runlevelzero.net> <20030820095651.A9690@zoratu.com> Message-ID: <20030820181546.GB31324@titan.runlevelzero.net> On Wed, Aug 20, 2003 at 09:56:51AM -0700, Isaiah told me: > Flip the bits that let me edit and I'll make some time. Unfortunatly that page is hard coded html in the php. I will push it in the the SQL so doc maintainers can edit. Give me a day or two. Until then if you want to just grab the source and modify and mail it to me that would be fine... To grant you access, please fill out the account request at: http://caosity.org/account_request.php Thanks! Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From zoratu at datastacks.com Wed Aug 20 11:26:04 2003 From: zoratu at datastacks.com (Isaiah) Date: Wed, 20 Aug 2003 11:26:04 -0700 Subject: [cAos] Free Business... In-Reply-To: <20030820181546.GB31324@titan.runlevelzero.net>; from greg@runlevelzero.net on Wed, Aug 20, 2003 at 11:15:46AM -0700 References: <20030820071136.GA26972@titan.runlevelzero.net> <20030820090715.A8673@zoratu.com> <20030820163206.GA31324@titan.runlevelzero.net> <20030820095651.A9690@zoratu.com> <20030820181546.GB31324@titan.runlevelzero.net> Message-ID: <20030820112604.A13300@zoratu.com> I filled out the account request form. I'm surprised you don't have a wiki wiki clone on the site. Plans? On Wed, Aug 20, 2003 at 11:15:46AM -0700, Greg Kurtzer wrote: > On Wed, Aug 20, 2003 at 09:56:51AM -0700, Isaiah told me: > > Flip the bits that let me edit and I'll make some time. > > Unfortunatly that page is hard coded html in the php. I will push it in the > the SQL so doc maintainers can edit. Give me a day or two. > > Until then if you want to just grab the source and modify and mail it to me > that would be fine... > > To grant you access, please fill out the account request at: > http://caosity.org/account_request.php > > Thanks! > Greg > -- > Greg M. Kurtzer > http://runlevelzero.net/ > http://caosity.org/ > http://warewulf-cluster.org/ > _______________________________________________ > cAos mailing list > cAos at runlevelzero.net > http://www.caosity.org/mailman/listinfo/caos -- - Isaiah From greg at runlevelzero.net Wed Aug 20 13:56:09 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Wed, 20 Aug 2003 13:56:09 -0700 Subject: [cAos] Free Business... In-Reply-To: <20030820112604.A13300@zoratu.com> References: <20030820071136.GA26972@titan.runlevelzero.net> <20030820090715.A8673@zoratu.com> <20030820163206.GA31324@titan.runlevelzero.net> <20030820095651.A9690@zoratu.com> <20030820181546.GB31324@titan.runlevelzero.net> <20030820112604.A13300@zoratu.com> Message-ID: <20030820205609.GC31324@titan.runlevelzero.net> On Wed, Aug 20, 2003 at 11:26:04AM -0700, Isaiah told me: > I'm surprised you don't have a wiki wiki clone on the site. Plans? Hrmm, I can put one up or have a contributor do it but personally I have not found them that useful. Does anyone else find them extreamly useful? Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Wed Aug 20 14:43:03 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Wed, 20 Aug 2003 14:43:03 -0700 Subject: [cAos] RPM build weirdness... Message-ID: <20030820214303.GD31324@titan.runlevelzero.net> So I just compiled the rpm-4.2 rpm and check this out... $ rpm -qpR ~/RPM/RPMS/i386/rpm-4.2-1.i386.rpm | egrep -e '4.1|4.2' rpmlib(CompressedFileNames) <= 3.0.4-1 librpm-4.1.so librpm-4.2.so librpmbuild-4.2.so librpmdb-4.1.so librpmdb-4.2.so librpmio-4.1.so librpmio-4.2.so $ rpm -qp --provides ~/RPM/RPMS/i386/rpm-4.2-1.i386.rpm | egrep -e '4.1|4.2' librpm-4.2.so librpmbuild-4.2.so librpmdb-4.2.so librpmio-4.2.so rpm = 4.2-1 Any thoughts? -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From herrold at owlriver.com Wed Aug 20 19:25:03 2003 From: herrold at owlriver.com (R P Herrold) Date: Wed, 20 Aug 2003 22:25:03 -0400 (EDT) Subject: [cAos] Re: cAos] Free Business... In-Reply-To: <20030820205609.GC31324@titan.runlevelzero.net> References: <20030820071136.GA26972@titan.runlevelzero.net> <20030820090715.A8673@zoratu.com> <20030820163206.GA31324@titan.runlevelzero.net> <20030820095651.A9690@zoratu.com> <20030820181546.GB31324@titan.runlevelzero.net> <20030820112604.A13300@zoratu.com> <20030820205609.GC31324@titan.runlevelzero.net> Message-ID: On Wed, 20 Aug 2003, Greg Kurtzer wrote: > On Wed, Aug 20, 2003 at 11:26:04AM -0700, Isaiah told me: > > I'm surprised you don't have a wiki wiki clone on the site. Plans? > > Hrmm, I can put one up or have a contributor do it but personally I have not > found them that useful. > > Does anyone else find them extreamly useful? No -- I have not, nor even mildly useful; stuff gets lost in them; they seem most useful for 'blamefesting'. vote: -1 - - Russ Herrold From zoratu at datastacks.com Wed Aug 20 21:29:16 2003 From: zoratu at datastacks.com (Isaiah) Date: Wed, 20 Aug 2003 21:29:16 -0700 Subject: [cAos] Re: cAos] Free Business... In-Reply-To: ; from herrold@owlriver.com on Wed, Aug 20, 2003 at 10:25:03PM -0400 References: <20030820071136.GA26972@titan.runlevelzero.net> <20030820090715.A8673@zoratu.com> <20030820163206.GA31324@titan.runlevelzero.net> <20030820095651.A9690@zoratu.com> <20030820181546.GB31324@titan.runlevelzero.net> <20030820112604.A13300@zoratu.com> <20030820205609.GC31324@titan.runlevelzero.net> Message-ID: <20030820212916.A32468@zoratu.com> Yes, they're an organic monster. They do, however, fill the following roles: 1) brain-dead simple revision control 2) content-focused, not format-focused 3) no extra tools needed for fulfilling the above. And for those reasons, they're hella useful. Free-form procedures evolve, everyone does it a different way, but in the end all the data is *GASP* available and easy to understand because it's _there_. On Wed, Aug 20, 2003 at 10:25:03PM -0400, R P Herrold wrote: > No -- I have not, nor even mildly useful; stuff gets lost in them; they > seem most useful for 'blamefesting'. > > vote: -1 > > - - Russ Herrold > _______________________________________________ > cAos mailing list > cAos at runlevelzero.net > http://www.caosity.org/mailman/listinfo/caos -- - Isaiah From herrold at owlriver.com Thu Aug 21 08:10:09 2003 From: herrold at owlriver.com (R P Herrold) Date: Thu, 21 Aug 2003 11:10:09 -0400 (EDT) Subject: [cAos] Re: cAos] package depots... In-Reply-To: <20030817211334.GA25331@titan.runlevelzero.net> References: <20030817211334.GA25331@titan.runlevelzero.net> Message-ID: > If you are not sure what this means, and you have packages in your depot then > you should read http://caosity.org/usr_help.php or email me or the list. hummm -- in following the link, it is one of those under acess control. It probably should not be thus. Most non-secret societies let you understand the rules of the game before they make you sign up and start playing. (smile) - - Russ herrold From greg at runlevelzero.net Thu Aug 21 10:08:04 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Thu, 21 Aug 2003 10:08:04 -0700 Subject: [cAos] Re: cAos] package depots... In-Reply-To: References: <20030817211334.GA25331@titan.runlevelzero.net> Message-ID: <20030821170804.GA28493@titan.runlevelzero.net> On Thu, Aug 21, 2003 at 11:10:09AM -0400, R P Herrold told me: > hummm -- in following the link, it is one of those under acess > control. It probably should not be thus. Most non-secret > societies let you understand the rules of the game before they > make you sign up and start playing. (smile) Motivation to log in! :) I changed the permissions on this page so that anyone can view it. Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Sun Aug 24 12:31:30 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sun, 24 Aug 2003 12:31:30 -0700 Subject: [cAos] Packages needing adoption... Message-ID: <20030824193130.GA3257@titan.runlevelzero.net> I have added the base cAos system in the DB. There are around 350 packages that I feel constitute a base system. This includes X, Gnome2, and various devel tools. Packages still needing adoption can be viewed at: http://caosity.org/pkg_adopt.php (requires login access). At this point we can just use mostly RedHat SRPMS to start off with, and migrate away and optimize after initial package adoption. Please select packages that you are interested in, or that you feel you can maintain relatively easily. Also, remember that if you select a package for ownership you are responsible for this package, upgrades, bugfixes and security (in many cases you can just select a newer package from RH or the application developers if they have released a SPEC. -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Sun Aug 24 12:33:37 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sun, 24 Aug 2003 12:33:37 -0700 Subject: [cAos] DevFS... Message-ID: <20030824193337.GB3257@titan.runlevelzero.net> I am playing with the idea of using devfs. Has anyone else played with it, and if so what are your thoughts? I have already built a basic devfsd as well. Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From lance at uklinux.net Sun Aug 24 13:59:51 2003 From: lance at uklinux.net (Lance Davis) Date: Sun, 24 Aug 2003 21:59:51 +0100 (BST) Subject: [cAos] Packages needing adoption... In-Reply-To: <20030824193130.GA3257@titan.runlevelzero.net> Message-ID: On Sun, 24 Aug 2003, Greg Kurtzer wrote: > I have added the base cAos system in the DB. There are around 350 packages > that I feel constitute a base system. This includes X, Gnome2, and various > devel tools. > > Packages still needing adoption can be viewed at: > http://caosity.org/pkg_adopt.php (requires login access). Whilst I can view the list, I dont seem to be able to adopt any ??? Do we still need to email you to adopt them ??? Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From lance at uklinux.net Sun Aug 24 14:09:40 2003 From: lance at uklinux.net (Lance Davis) Date: Sun, 24 Aug 2003 22:09:40 +0100 (BST) Subject: [cAos] Packages needing adoption... In-Reply-To: <20030824193130.GA3257@titan.runlevelzero.net> Message-ID: On Sun, 24 Aug 2003, Greg Kurtzer wrote: > I have added the base cAos system in the DB. There are around 350 packages > that I feel constitute a base system. This includes X, Gnome2, and various > devel tools. I'd _much_ prefer postfix (+spamassassin +amavis) to be the default mta rather than sendmail , what do other people think ??? Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From ssharkey at linuxunlimited.com Sun Aug 24 17:22:58 2003 From: ssharkey at linuxunlimited.com (Scott Sharkey) Date: Sun, 24 Aug 2003 20:22:58 -0400 Subject: [cAos] Re: Packages needing adoption... In-Reply-To: References: Message-ID: <20030825002258.E9A8E337F4@grouper.lanshark.com> Lance Davis writes: > On Sun, 24 Aug 2003, Greg Kurtzer wrote: > >> I have added the base cAos system in the DB. There are around 350 packages >> that I feel constitute a base system. This includes X, Gnome2, and various >> devel tools. > > I'd _much_ prefer postfix (+spamassassin +amavis) to be the default mta > rather than sendmail , what do other people think ??? I agree 100%! In fact, I'm working on Postfix RPMs, but I've been swamped with real work lately. I also have Courier-IMAP, and pop-before-smtp, and an amavis-new rpm that I'm working on. All are derived from existing rpms -- what's our policy on that, by the way? I'm willing to do the work on Anaconda/comps.xml, and whatever else needs changed to make postfix the default. -Scott From cyeoh at samba.org Sun Aug 24 17:37:19 2003 From: cyeoh at samba.org (Christopher Yeoh) Date: Mon, 25 Aug 2003 10:37:19 +1000 Subject: [cAos] DevFS... In-Reply-To: <20030824193337.GB3257@titan.runlevelzero.net> References: <20030824193337.GB3257@titan.runlevelzero.net> Message-ID: <16201.23103.169801.498901@gargle.gargle.HOWL> At 2003/8/24 12:33-0700 Greg Kurtzer writes: > I am playing with the idea of using devfs. Has anyone else played with it, and > if so what are your thoughts? > I'm pretty sure devfs is on its way out. Greg K-H gave a good talk about udev (userspace devfs) which is meant to be replacing devfs. http://www.linuxsymposium.org/2003/view_abstract.php?talk=94 Chris -- cyeoh at au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From lance at uklinux.net Sun Aug 24 17:57:21 2003 From: lance at uklinux.net (Lance Davis) Date: Mon, 25 Aug 2003 01:57:21 +0100 (BST) Subject: [cAos] Re: Packages needing adoption... In-Reply-To: <20030825002258.E9A8E337F4@grouper.lanshark.com> Message-ID: On Sun, 24 Aug 2003, Scott Sharkey wrote: > Lance Davis writes: > > > On Sun, 24 Aug 2003, Greg Kurtzer wrote: > > > >> I have added the base cAos system in the DB. There are around 350 packages > >> that I feel constitute a base system. This includes X, Gnome2, and various > >> devel tools. > > > > I'd _much_ prefer postfix (+spamassassin +amavis) to be the default mta > > rather than sendmail , what do other people think ??? > > I agree 100%! In fact, I'm working on Postfix RPMs, but I've been > swamped with real work lately. Ah sorry - I saw sendmail in the list and didnt realise that you were working on postfix. I propose that we dont need sendmail then :) > I also have Courier-IMAP, and pop-before-smtp, pop-before-smtp is nasty ... whats wrong with SMTP-AUTH ??? which pop3 daemon are we using ?? > and an amavis-new rpm that I'm working on. an anti-virus package as an rpm would be nice , but I'm not convinced of the effectiveness of oav/clamav/messagewall yet so we use f-prot here , but it isnt open source. > All are derived from existing rpms -- what's our policy on that, by the > way? AFAIK as long as they are GPL it is ok, but it is better to write your own ... > I'm willing to do the work on Anaconda/comps.xml, and whatever else > needs changed to make postfix the default. Not sure we'll be using anaconda will we ??? Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From greg at runlevelzero.net Sun Aug 24 20:44:31 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sun, 24 Aug 2003 20:44:31 -0700 Subject: [cAos] Packages needing adoption... In-Reply-To: References: <20030824193130.GA3257@titan.runlevelzero.net> Message-ID: <20030825034431.GA14135@titan.runlevelzero.net> On Sun, Aug 24, 2003 at 09:59:51PM +0100, Lance Davis told me: > Whilst I can view the list, I dont seem to be able to adopt any ??? Hrmm... Have you tried to upload a SRPM to the package depot and then select adopt and then update SRPM? I realize this is not intuitive but I did it like that so people would have to have a SRPM ready before they adopt a package. > Do we still need to email you to adopt them ??? Let me know if the above works (or doesn't). I will document it better. Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Sun Aug 24 20:49:00 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sun, 24 Aug 2003 20:49:00 -0700 Subject: [cAos] Packages needing adoption... In-Reply-To: References: <20030824193130.GA3257@titan.runlevelzero.net> Message-ID: <20030825034900.GB14135@titan.runlevelzero.net> On Sun, Aug 24, 2003 at 10:09:40PM +0100, Lance Davis told me: > I'd _much_ prefer postfix (+spamassassin +amavis) to be the default mta > rather than sendmail , what do other people think ??? Fine with me. I don't know postfix at all, but why not? I have heard good things about it! What about Exim (sp?)? I have not used that one either, but I figured we should get some consensus. It is funny, I have been a sendmail user for about 6 years now, and while I know it is a pain to deal with, I have always appreciated that almost all other applications integrated so well with it. How well does Postfix integrate with various apps? Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Sun Aug 24 21:07:42 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sun, 24 Aug 2003 21:07:42 -0700 Subject: [cAos] Re: Packages needing adoption... In-Reply-To: References: <20030825002258.E9A8E337F4@grouper.lanshark.com> Message-ID: <20030825040742.GC14135@titan.runlevelzero.net> On Mon, Aug 25, 2003 at 01:57:21AM +0100, Lance Davis told me: > an anti-virus package as an rpm would be nice , but I'm not convinced of > the effectiveness of oav/clamav/messagewall yet so we use f-prot here , > but it isnt open source. Actually if someone knows of a good anti-virus scanner for Linux (even proprietary) I would like to know. I think we should get a free (or donated) version from a company to use on our repositories and give the donating company gracious thanks on the cAos site. While I hate to use non-free software, I am very concerned about things like elf viruses considering that we will be accepting uploads from so many people. > AFAIK as long as they are GPL it is ok, but it is better to write your own > ... You don't necessarily have to make your own, but you should defiantly know exactly what everything in there does including patches and other stuff. for example, RedHat's glib-1.2.10-10 SPEC is very clean with only 1 patch, while their kernel just scares me. Not that there is anything in particular that I don't like about how it works, but it is just too much for me to maintain. I guess my point is that is is always good to build your own SPEC because then you are the master of it. But I am going to guess that 75% of the RPMS for the first release of cAos will be RedHat. Remember that the package maintainer is the ruler of that package. They own it, and how it gets implemented in cAos (of course some usual stipulations apply which I am trying to write up at: http://caosity.org/docs_view.php?subject=SRPM%20packaging%20standards). > Not sure we'll be using anaconda will we ??? Here are my thoughts (that are of course open for debate) on installers. I for see two: 1- A minimal floppy installer. This will (hopefully) fit onto one floppy and will simply do a full network based install. This should also have the capability to be scripted either by a local file on the floppy or by a config residing on the network. This needs to still be prototyped and built. I don't mind doing the prototype, but I will probably ask for a volunteer to maintain it. 2- The Full ISO Live system. This is a combination Rescue, Demo, Test, Installer. Russ has volunteered to maintain it from a prototype that I wrote a while ago. Now because of the nature of cAos, if someone else wants to volunteer to maintain another installer, that is fine with me! :) Anaconda would be nice to use, but it is primarily built and maintained as a RedHat solution rather then a general installer. Don't get me wrong, Jeremy has done an amazing job with it! Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Sun Aug 24 21:14:04 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sun, 24 Aug 2003 21:14:04 -0700 Subject: [cAos] DevFS... In-Reply-To: <16201.23103.169801.498901@gargle.gargle.HOWL> References: <20030824193337.GB3257@titan.runlevelzero.net> <16201.23103.169801.498901@gargle.gargle.HOWL> Message-ID: <20030825041404.GD14135@titan.runlevelzero.net> On Mon, Aug 25, 2003 at 10:37:19AM +1000, Christopher Yeoh told me: > I'm pretty sure devfs is on its way out. Greg K-H gave a good talk > about udev (userspace devfs) which is meant to be replacing devfs. > > http://www.linuxsymposium.org/2003/view_abstract.php?talk=94 Very cool! Thanks for the heads up Chris! Does anyone on the list have any experience with udev? -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From davidm at them.com Sun Aug 24 21:42:43 2003 From: davidm at them.com (David Mandala) Date: 24 Aug 2003 21:42:43 -0700 Subject: [cAos] Packages needing adoption... In-Reply-To: <20030825034900.GB14135@titan.runlevelzero.net> References: <20030824193130.GA3257@titan.runlevelzero.net> <20030825034900.GB14135@titan.runlevelzero.net> Message-ID: <1061786563.2371.1.camel@localhost.localdomain> Postfix integrates well and is MUCH better then sendmail. Much more secure. Exim is OK but I much prefer postfix and only use it. Cheers, Davidm On Sun, 2003-08-24 at 20:49, Greg Kurtzer wrote: > On Sun, Aug 24, 2003 at 10:09:40PM +0100, Lance Davis told me: > > I'd _much_ prefer postfix (+spamassassin +amavis) to be the default mta > > rather than sendmail , what do other people think ??? > > Fine with me. I don't know postfix at all, but why not? I have heard good > things about it! > > What about Exim (sp?)? I have not used that one either, but I figured we > should get some consensus. > > It is funny, I have been a sendmail user for about 6 years now, and while I > know it is a pain to deal with, I have always appreciated that almost all > other applications integrated so well with it. How well does Postfix integrate > with various apps? > > Greg From skvidal at phy.duke.edu Sun Aug 24 21:47:28 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 25 Aug 2003 00:47:28 -0400 Subject: [cAos] Packages needing adoption... In-Reply-To: <1061786563.2371.1.camel@localhost.localdomain> References: <20030824193130.GA3257@titan.runlevelzero.net> <20030825034900.GB14135@titan.runlevelzero.net> <1061786563.2371.1.camel@localhost.localdomain> Message-ID: <1061786847.9437.59.camel@binkley> On Mon, 2003-08-25 at 00:42, David Mandala wrote: > Postfix integrates well and is MUCH better then sendmail. Much more > secure. Exim is OK but I much prefer postfix and only use it. > I use postfix on all the machines I administer and two primary mail servers. One drawback to postfix, though, is if things are written to the sendmail milter interface then you're going to have a devil of a time getting them to work on postfix. -sv From lance at uklinux.net Mon Aug 25 03:32:48 2003 From: lance at uklinux.net (Lance Davis) Date: Mon, 25 Aug 2003 11:32:48 +0100 (BST) Subject: [cAos] Packages needing adoption... In-Reply-To: <20030825034431.GA14135@titan.runlevelzero.net> Message-ID: On Sun, 24 Aug 2003, Greg Kurtzer wrote: > On Sun, Aug 24, 2003 at 09:59:51PM +0100, Lance Davis told me: > > Whilst I can view the list, I dont seem to be able to adopt any ??? > > Hrmm... Have you tried to upload a SRPM to the package depot and then select > adopt and then update SRPM? I realize this is not intuitive but I did it like > that so people would have to have a SRPM ready before they adopt a package. But then two of us could spend a lot of time working on the same package, to find that the other person had just uploaded ;) Maybe need a 'reservation' flag, to reserve the package whilst working on it and before uploading ??? Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From lance at uklinux.net Mon Aug 25 03:34:08 2003 From: lance at uklinux.net (Lance Davis) Date: Mon, 25 Aug 2003 11:34:08 +0100 (BST) Subject: [cAos] Packages needing adoption... In-Reply-To: <20030825034431.GA14135@titan.runlevelzero.net> Message-ID: On Sun, 24 Aug 2003, Greg Kurtzer wrote: > On Sun, Aug 24, 2003 at 09:59:51PM +0100, Lance Davis told me: > > Whilst I can view the list, I dont seem to be able to adopt any ??? > > Hrmm... Have you tried to upload a SRPM to the package depot and then select > adopt and then update SRPM? I realize this is not intuitive but I did it like > that so people would have to have a SRPM ready before they adopt a package. But then two of us could spend a lot of time working on the same package, to find that the other person had just uploaded ;) Maybe need a 'reservation' flag, to reserve the package whilst working on it and before uploading ??? Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From lance at uklinux.net Mon Aug 25 03:50:11 2003 From: lance at uklinux.net (Lance Davis) Date: Mon, 25 Aug 2003 11:50:11 +0100 (BST) Subject: [cAos] Re: Packages needing adoption... In-Reply-To: <20030825040742.GC14135@titan.runlevelzero.net> Message-ID: On Sun, 24 Aug 2003, Greg Kurtzer wrote: > On Mon, Aug 25, 2003 at 01:57:21AM +0100, Lance Davis told me: > > an anti-virus package as an rpm would be nice , but I'm not convinced of > > the effectiveness of oav/clamav/messagewall yet so we use f-prot here , > > but it isnt open source. > > Actually if someone knows of a good anti-virus scanner for Linux (even > proprietary) I would like to know. I think we should get a free (or donated) > version from a company to use on our repositories and give the donating > company gracious thanks on the cAos site. > > While I hate to use non-free software, I am very concerned about things like > elf viruses considering that we will be accepting uploads from so many people. clamav actually looks like it is further developed than I thought it was, and it uses oav so I think it is fully open source. I'll take a look at packaging it ... Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From greg at runlevelzero.net Mon Aug 25 07:15:09 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Mon, 25 Aug 2003 07:15:09 -0700 Subject: [cAos] Packages needing adoption... In-Reply-To: References: <20030825034431.GA14135@titan.runlevelzero.net> Message-ID: <20030825141509.GA1240@titan.runlevelzero.net> On Mon, Aug 25, 2003 at 11:34:08AM +0100, Lance Davis told me: > But then two of us could spend a lot of time working on the same package, > to find that the other person had just uploaded ;) > > Maybe need a 'reservation' flag, to reserve the package whilst working on > it and before uploading ??? Agreed. I will put a reserved by field in the DB. Give me a day or so. Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Mon Aug 25 08:53:02 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Mon, 25 Aug 2003 08:53:02 -0700 Subject: [cAos] Packages needing adoption... In-Reply-To: <20030825141509.GA1240@titan.runlevelzero.net> References: <20030825034431.GA14135@titan.runlevelzero.net> <20030825141509.GA1240@titan.runlevelzero.net> Message-ID: <20030825155302.GA2991@titan.runlevelzero.net> On Mon, Aug 25, 2003 at 07:15:09AM -0700, Greg Kurtzer told me: > On Mon, Aug 25, 2003 at 11:34:08AM +0100, Lance Davis told me: > > But then two of us could spend a lot of time working on the same package, > > to find that the other person had just uploaded ;) > > > > Maybe need a 'reservation' flag, to reserve the package whilst working on > > it and before uploading ??? > > Agreed. I will put a reserved by field in the DB. Give me a day or so. Done. You can now adopt packages without the corresponding SRPM. Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Mon Aug 25 23:18:27 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Mon, 25 Aug 2003 23:18:27 -0700 Subject: [cAos] Naming convention... Message-ID: <20030826061827.GA15505@titan.runlevelzero.net> Just wanted to get one final consensus on the naming conventions and have people start thinking about packaging standards. We need to have some defined standards and guidelines that are loose enough to let the maintainers do their job, but at the same time guide them and cAos to be successful. I jotted some things down from memory and list traffic archives at: http://caosity.org/docs_view.php?subject=SRPM%20packaging%20standards Please check it out and forward comments. Thanks. -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From pmatilai at welho.com Tue Aug 26 00:38:40 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 26 Aug 2003 10:38:40 +0300 Subject: [cAos] Naming convention... In-Reply-To: <20030826061827.GA15505@titan.runlevelzero.net> References: <20030826061827.GA15505@titan.runlevelzero.net> Message-ID: <1061883520.3f4b0e8080c79@webmail.welho.com> Quoting Greg Kurtzer : > Just wanted to get one final consensus on the naming conventions and have > people start thinking about packaging standards. We need to have some > defined standards and guidelines that are loose enough to let the maintainers do > their job, but at the same time guide them and cAos to be successful. > > I jotted some things down from memory and list traffic archives at: > http://caosity.org/docs_view.php?subject=SRPM%20packaging%20standards > > Please check it out and forward comments. That's as loose as a lunatic with a shotgun running on the streets at rush hour if you ask me... As you may or may not know the Fedora project argued over package naming standards for like half a year. cAos doesn't need to take care about some of the issues Fedora has (try to make RH upgrades as smooth as possible) but because of the way rpm calculates version/release entries the standard should either a) Describe a way of converting "odd" package versions like 1.0pre1 to something which rpm can properly upgrade, for example 1.0-1caos.pre1 b) Define that version must be whatever upstream has, and then increment Epoch when necessary to allow upgrade. Not lobbying for either but given the quirks of rpm version comparison I think the standard should deal with the issue. Another thing which comes to mind is renaming of packages vs upstream for consistency / easy searchability: For example lets assume there's a project providing an XMMS plugin named upstream as foo-xmms. While it's probably clear what it is even like that, changing it to xmms-foo would (to me at least) make it clearer that it's something which enhances xmms (and not the other way around) and allows for easy searching for xmms-plugins. Another thing is library packages, Mandrake at least seems to rename them to lib most of the time, regardless of upstream name. -- - Panu - From greg at runlevelzero.net Tue Aug 26 08:06:39 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 26 Aug 2003 08:06:39 -0700 Subject: [cAos] Naming convention... In-Reply-To: <1061883520.3f4b0e8080c79@webmail.welho.com> References: <20030826061827.GA15505@titan.runlevelzero.net> <1061883520.3f4b0e8080c79@webmail.welho.com> Message-ID: <20030826150638.GA25038@titan.runlevelzero.net> On Tue, Aug 26, 2003 at 10:38:40AM +0300, Panu Matilainen told me: > That's as loose as a lunatic with a shotgun running on the streets at rush hour > if you ask me... Very interesting analogy, but I see your point! ;) As I mentioned, this is a first draft and I just wanted to throw it out there so we can start hacking, and what I started out with were only the points that have I have discussed with others so far. I know we need to add to it, but I don't want it to be a book! > As you may or may not know the Fedora project argued over package naming > standards for like half a year. cAos doesn't need to take care about some of the > issues Fedora has (try to make RH upgrades as smooth as possible) but because of > the way rpm calculates version/release entries the standard should either Yes, I know Fedora had a very long discussion about this... > a) Describe a way of converting "odd" package versions like 1.0pre1 to something > which rpm can properly upgrade, for example 1.0-1caos.pre1 Doesn't that then cause problems when 1.0 gets released stable? It seems to me that: 1.0-1caos.pre1 > 1.0-1caos from a version comparison algorithm. I suppose that it can be changed to 2caos, but that is misleading because the source tree may actually be different. IMHO: The main source tree should _always_ == RPM Version, and the Release is what we increment with patches, builds, and SPEC changes. Now there is also the same problem when evaluating 1.0pre1 > 1.0 as I see it. But this will at least also show that the source tree may have changed. So as long as the main source package version is of reasonable nomenclature, I think we should use that for the 'Version' tag in the SPEC. > b) Define that version must be whatever upstream has, and then increment Epoch > when necessary to allow upgrade. > Not lobbying for either but given the quirks of rpm version comparison I think > the standard should deal with the issue. Yes, this is the direction that I was thinking as well. > Another thing which comes to mind is renaming of packages vs upstream for > consistency / easy searchability: For example lets assume there's a project > providing an XMMS plugin named upstream as foo-xmms. While it's probably clear > what it is even like that, changing it to xmms-foo would (to me at least) make > it clearer that it's something which enhances xmms (and not the other way > around) and allows for easy searching for xmms-plugins. Another thing is library > packages, Mandrake at least seems to rename them to lib most of the > time, regardless of upstream name. I like the xmms-foo nomenclature, or more generically: [main package]-[component]-[component version]-[component release] The lib nomenclature I am not so sure on. For example, if I want to get zlib, it is counter intuitive to think of it as libz- from a package management perspective. Does anyone else have any thoughts on this? Thanks. Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Tue Aug 26 08:45:30 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 26 Aug 2003 08:45:30 -0700 Subject: [cAos] Naming convention... In-Reply-To: <20030826061827.GA15505@titan.runlevelzero.net> References: <20030826061827.GA15505@titan.runlevelzero.net> Message-ID: <20030826154530.GA25384@titan.runlevelzero.net> On Mon, Aug 25, 2003 at 11:18:27PM -0700, Greg Kurtzer told me: > I jotted some things down from memory and list traffic archives at: > http://caosity.org/docs_view.php?subject=SRPM%20packaging%20standards v0.2 of the above document has been posted... -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From pmatilai at welho.com Tue Aug 26 09:06:42 2003 From: pmatilai at welho.com (Panu Matilainen) Date: 26 Aug 2003 19:06:42 +0300 Subject: [cAos] Naming convention... In-Reply-To: <20030826150638.GA25038@titan.runlevelzero.net> References: <20030826061827.GA15505@titan.runlevelzero.net> <1061883520.3f4b0e8080c79@webmail.welho.com> <20030826150638.GA25038@titan.runlevelzero.net> Message-ID: <1061914002.3893.7.camel@chip.ath.cx> On Tue, 2003-08-26 at 18:06, Greg Kurtzer wrote: > On Tue, Aug 26, 2003 at 10:38:40AM +0300, Panu Matilainen told me: > > That's as loose as a lunatic with a shotgun running on the streets at rush hour > > if you ask me... > > Very interesting analogy, but I see your point! ;) Glad you saw the missing smiley there :) > > As I mentioned, this is a first draft and I just wanted to throw it out there > so we can start hacking, and what I started out with were only the points that > have I have discussed with others so far. > > I know we need to add to it, but I don't want it to be a book! Heh.. Perhaps the non-normal cases should be in another page to keep simple things simple. "If in doubt, consult dealing-with-quirky-packages.html" > > > As you may or may not know the Fedora project argued over package naming > > standards for like half a year. cAos doesn't need to take care about some of the > > issues Fedora has (try to make RH upgrades as smooth as possible) but because of > > the way rpm calculates version/release entries the standard should either > > Yes, I know Fedora had a very long discussion about this... > > > a) Describe a way of converting "odd" package versions like 1.0pre1 to something > > which rpm can properly upgrade, for example 1.0-1caos.pre1 > > Doesn't that then cause problems when 1.0 gets released stable? It seems to me > that: 1.0-1caos.pre1 > 1.0-1caos from a version comparison algorithm. I > suppose that it can be changed to 2caos, but that is misleading because the > source tree may actually be different. Oops, my bad - obviously the pre-style munging needs other things as well, eg 1.0-0caos.pre1. BTW have you checked that Xcaos is always evaluated correctly in cases like 1caos vs 10caos (I'd guess it is, just checking) > > IMHO: The main source tree should _always_ == RPM Version, and the Release is > what we increment with patches, builds, and SPEC changes. > > Now there is also the same problem when evaluating 1.0pre1 > 1.0 as I see it. > But this will at least also show that the source tree may have changed. > > So as long as the main source package version is of reasonable nomenclature, I > think we should use that for the 'Version' tag in the SPEC. Obviously - no reason to change sane versioning. > > > b) Define that version must be whatever upstream has, and then increment Epoch > > when necessary to allow upgrade. > > Not lobbying for either but given the quirks of rpm version comparison I think > > the standard should deal with the issue. > > Yes, this is the direction that I was thinking as well. > > > Another thing which comes to mind is renaming of packages vs upstream for > > consistency / easy searchability: For example lets assume there's a project > > providing an XMMS plugin named upstream as foo-xmms. While it's probably clear > > what it is even like that, changing it to xmms-foo would (to me at least) make > > it clearer that it's something which enhances xmms (and not the other way > > around) and allows for easy searching for xmms-plugins. Another thing is library > > packages, Mandrake at least seems to rename them to lib most of the > > time, regardless of upstream name. > > I like the xmms-foo nomenclature, or more generically: > [main package]-[component]-[component version]-[component release] > > The lib nomenclature I am not so sure on. For example, if I want to get zlib, > it is counter intuitive to think of it as libz- from a package management > perspective. Does anyone else have any thoughts on this? I've never liked too much the "forced" renaming to libfoo but I guess it has its merits since some distros are using it (Mandrake and Conectiva come to mind, though haven't looked how strictly they enforce that) Oh and the second version looks much better :) - Panu - From greg at runlevelzero.net Tue Aug 26 11:52:01 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 26 Aug 2003 11:52:01 -0700 Subject: [cAos] Naming convention... In-Reply-To: <1061914002.3893.7.camel@chip.ath.cx> References: <20030826061827.GA15505@titan.runlevelzero.net> <1061883520.3f4b0e8080c79@webmail.welho.com> <20030826150638.GA25038@titan.runlevelzero.net> <1061914002.3893.7.camel@chip.ath.cx> Message-ID: <20030826185201.GB27328@titan.runlevelzero.net> On Tue, Aug 26, 2003 at 07:06:42PM +0300, Panu Matilainen told me: > > Very interesting analogy, but I see your point! ;) > > Glad you saw the missing smiley there :) Of course! > Heh.. Perhaps the non-normal cases should be in another page to keep > simple things simple. "If in doubt, consult > dealing-with-quirky-packages.html" Sounds good! > Oops, my bad - obviously the pre-style munging needs other things as > well, eg 1.0-0caos.pre1. BTW have you checked that Xcaos is always > evaluated correctly in cases like 1caos vs 10caos (I'd guess it is, just > checking) That is a good point. I checked with Jeff, and he said this should not be a problem. > > The lib nomenclature I am not so sure on. For example, if I want to get zlib, > > it is counter intuitive to think of it as libz- from a package management > > perspective. Does anyone else have any thoughts on this? > > I've never liked too much the "forced" renaming to libfoo but I guess it > has its merits since some distros are using it (Mandrake and Conectiva > come to mind, though haven't looked how strictly they enforce that) OK, so then it is unanimous (at least among the two that voted! :). > Oh and the second version looks much better :) Excellent! Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From zoratu at datastacks.com Tue Aug 26 12:57:47 2003 From: zoratu at datastacks.com (Isaiah) Date: Tue, 26 Aug 2003 12:57:47 -0700 Subject: [cAos] DevFS... In-Reply-To: <20030825041404.GD14135@titan.runlevelzero.net>; from greg@runlevelzero.net on Sun, Aug 24, 2003 at 09:14:04PM -0700 References: <20030824193337.GB3257@titan.runlevelzero.net> <16201.23103.169801.498901@gargle.gargle.HOWL> <20030825041404.GD14135@titan.runlevelzero.net> Message-ID: <20030826125747.A10525@zoratu.com> I'm with Pat. http://www.cs.helsinki.fi/linux/linux-kernel/2002-01/0430.html On Sun, Aug 24, 2003 at 09:14:04PM -0700, Greg Kurtzer wrote: > On Mon, Aug 25, 2003 at 10:37:19AM +1000, Christopher Yeoh told me: > > I'm pretty sure devfs is on its way out. Greg K-H gave a good talk > > about udev (userspace devfs) which is meant to be replacing devfs. > > > > http://www.linuxsymposium.org/2003/view_abstract.php?talk=94 > > Very cool! Thanks for the heads up Chris! > > Does anyone on the list have any experience with udev? > -- > Greg M. Kurtzer > http://runlevelzero.net/ > http://caosity.org/ > http://warewulf-cluster.org/ > _______________________________________________ > cAos mailing list > cAos at runlevelzero.net > http://www.caosity.org/mailman/listinfo/caos -- - Isaiah From greg at runlevelzero.net Thu Aug 28 15:07:15 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Thu, 28 Aug 2003 15:07:15 -0700 Subject: [cAos] IRC information about installers... Message-ID: <20030828220715.GA3662@titan.runlevelzero.net> We have talked about installers on IRC now and then, but not much on list. Thus I thought I would forward the transcript of this IRC session to this list for the benefit of those interested: fezzgig: you asked about installers... Yes. I forsee at least two main supported installers... first I will give you my ideas for requirements. Ok. not a huge time investment on keeping current (hardware, kernels, look and feel) with that said, I see a live CD type, that uses LNX-BBC and Knoppix ideas to be a test, demo, rescue, and installer cd all in one. This has been done and it is in BETA. orc_orc now maintains my prototype code. That is the heavy full featured installer. The other option will be a network installer that can fit on a floppy (worse case scenario multiple floppies) this will be basically a kernel and a initrd and a very small wget. it will boot and mount the initrd the initrd will download a secondary stage installer and push into /dev/ram0 then the initrd will mount /dev/ram0 as / and piviot_root in the secondary image there will be tools like disk partitioners, rpm, and some basic shell commands (probably less then a 30Mb ram disk, and about 5Mb net transfer) this still needs to be built, but I think it will be pretty straight forward. now aside from that, I see other people maybe taking RedHat's installer (Anaconda) and making that work with cAos. but I don't want to guarantee support for it because it takes a lot (A LOT) of time. * fezzgig nods Because the full CD system works, it is an easy way to test builds. burn to CDROM, then boot on a test system --or-- point VMWare at the iso, and boot on a virtual system. -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From lance at uklinux.net Thu Aug 28 18:19:22 2003 From: lance at uklinux.net (Lance Davis) Date: Fri, 29 Aug 2003 02:19:22 +0100 (BST) Subject: [cAos] Re: Packages needing adoption... In-Reply-To: <20030825002258.E9A8E337F4@grouper.lanshark.com> Message-ID: On Sun, 24 Aug 2003, Scott Sharkey wrote: > I also have ... an amavis-new rpm that I'm working on. How far have you got with this - I'd like to see it :) Are you also doing all the perl modules it needs ?? I had a problem building an rpm of Net::SSLeay and had to revert to cpan source . Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From lance at uklinux.net Thu Aug 28 18:24:51 2003 From: lance at uklinux.net (Lance Davis) Date: Fri, 29 Aug 2003 02:24:51 +0100 (BST) Subject: [cAos] Re: Packages needing adoption... In-Reply-To: <20030825040742.GC14135@titan.runlevelzero.net> Message-ID: On Sun, 24 Aug 2003, Greg Kurtzer wrote: > On Mon, Aug 25, 2003 at 01:57:21AM +0100, Lance Davis told me: > > an anti-virus package as an rpm would be nice , but I'm not convinced of > > the effectiveness of oav/clamav/messagewall yet so we use f-prot here , > > but it isnt open source. > > Actually if someone knows of a good anti-virus scanner for Linux (even > proprietary) I would like to know. I think we should get a free (or donated) > version from a company to use on our repositories and give the donating > company gracious thanks on the cAos site. I've just installed clamav and it looks pretty good - it finds Sobig-F anyway :) http://clamav.elektrapro.com/ Looks like it is 100% gpl and is mainly based on open anti-virus virus definitions plus its own polymorphic ones :) It has a scanner, a daemon and an auto update definitions utility. I'll have a go at packaging it if you can add it to the package list. I'm using it with postfix/spamassassin but it also appears to work with sendmail or exim. Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From herrold at owlriver.com Fri Aug 29 07:40:23 2003 From: herrold at owlriver.com (R P Herrold) Date: Fri, 29 Aug 2003 10:40:23 -0400 (EDT) Subject: [cAos] Re: cAos] IRC information about installers... In-Reply-To: <20030828220715.GA3662@titan.runlevelzero.net> Message-ID: On Thu, 28 Aug 2003, Greg Kurtzer wrote: > We have talked about installers on IRC now and then, but not much on list. > Thus I thought I would forward the transcript of this IRC session to this > list for the benefit of those interested: > I forsee at least two main supported installers... and a third anaconda-based one, at least smart enough to do at least PXE installs, with partitioning, and base package, and ks.cfg selection, and lootloader installation seems likely, maintained by me - Russ From greg at runlevelzero.net Fri Aug 29 07:53:14 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Fri, 29 Aug 2003 07:53:14 -0700 Subject: [cAos] Re: cAos] IRC information about installers... In-Reply-To: References: <20030828220715.GA3662@titan.runlevelzero.net> Message-ID: <20030829145314.GA20588@titan.runlevelzero.net> On Fri, Aug 29, 2003 at 10:40:23AM -0400, R P Herrold told me: > and a third anaconda-based one, at least smart enough to do at > least PXE installs, with partitioning, and base package, and > ks.cfg selection, and lootloader installation seems likely, > maintained by me Actually, I think ScottS also mentioned that he knew anaconda pretty well (please speak up if I am mangling names) and offered to help with Anaconda. So you are offering to maintain the ISO live filesystem _and_ the Anaconda variant? ;) Thanks! -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From lists at spenneberg.org Sun Aug 31 11:42:46 2003 From: lists at spenneberg.org (Ralf Spenneberg) Date: 31 Aug 2003 20:42:46 +0200 Subject: [cAos] New member Message-ID: <1062355365.1607.46.camel@kermit> Hi, I am here by invitation through Greg Kurtzer. Thanks Greg. I just wanted to say, I am on board and will be happy to support the cAos-project through my RPMs. Cheers, Ralf -- Ralf Spenneberg RHCE, RHCX Book: Intrusion Detection f?r Linux Server http://www.spenneberg.com IPsec-Howto http://www.ipsec-howto.org Honeynet Project Mirror: http://honeynet.spenneberg.org From lance at uklinux.net Sun Aug 31 13:43:43 2003 From: lance at uklinux.net (Lance Davis) Date: Sun, 31 Aug 2003 21:43:43 +0100 (BST) Subject: [cAos] New member In-Reply-To: <1062355365.1607.46.camel@kermit> Message-ID: On 31 Aug 2003, Ralf Spenneberg wrote: > Hi, > > I am here by invitation through Greg Kurtzer. Thanks Greg. > > I just wanted to say, I am on board and will be happy to support the > cAos-project through my RPMs. Great - welcome aboard :) Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From greg at runlevelzero.net Sun Aug 31 19:31:06 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sun, 31 Aug 2003 19:31:06 -0700 Subject: [cAos] New member In-Reply-To: <1062355365.1607.46.camel@kermit> References: <1062355365.1607.46.camel@kermit> Message-ID: <20030901023106.GA20235@titan.runlevelzero.net> On Sun, Aug 31, 2003 at 08:42:46PM +0200, Ralf Spenneberg told me: > Hi, > > I am here by invitation through Greg Kurtzer. Thanks Greg. Glad to see ya! > I just wanted to say, I am on board and will be happy to support the > cAos-project through my RPMs. Welcome aboard. We have a basic web application that allows us to maintain and /own/ packages in the distribution. Please fill out the web form at http://caosity.org/account_request.php and I will grant access. Once logged in you can adopt packages, and manipulate the SRPMS associated with a particular package. If there is a package that you wish to maintain, just send a message to the list, including a dependency list of any packages or files that are not already included in the distribution. Again, thanks for joining the team! Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/