Re: [Leaf-devel] grep options
On Fri, 30 Mar 2001, Scott C. Best wrote: Am having trouble with normal grep options in eigerstein 2.2.16. Anyone else seen this? Getting error messages like "sed: can't read foo..." for simple things like: grep -v foo /etc/passwd Huh? sed with greap? Any thoughts on this? TIA! grep -v didn't even work in the old LRP2.9.8 release. Always had to hack around it by using sed -e "s/foo//" instead of grep -v "foo". Pi ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] grep options
Pi: Woof! That's terribly annoying. So...forgive my non-sed'ness, but what would be the equiv of, say: "grep -v -i FOO /etc/passwd" ? Thanks again -Scott, thinking about grep.lrp... On Fri, 30 Mar 2001, Pim van Riezen wrote: On Fri, 30 Mar 2001, Scott C. Best wrote: Am having trouble with normal grep options in eigerstein 2.2.16. Anyone else seen this? Getting error messages like "sed: can't read foo..." for simple things like: grep -v foo /etc/passwd Huh? sed with greap? Any thoughts on this? TIA! grep -v didn't even work in the old LRP2.9.8 release. Always had to hack around it by using sed -e "s/foo//" instead of grep -v "foo". Pi ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] grep options
On Fri, 30 Mar 2001, Scott C. Best wrote: Pi: Woof! That's terribly annoying. I agree, it just always seemed to annoy me personally at times where taking a better look at it was not an option. So...forgive my non-sed'ness, but what would be the equiv of, say: "grep -v -i FOO /etc/passwd" ? The "-i" I'm not sure about, I tend to not use regexpes all that oftenly either. A regular grep -v bar foo boils down to a sed -e "s/.*bar.*//" foo At least with some hackery you can usually get the same result you're trying to get with the grep -v. Only it looks uglier : Pi ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Nifty CD Idea
George Metz wrote: Perfect example is a feature I found while compiling a 2.4.2 kernel for my SuSE server last night. It's an option that I don't ever recall seeing in any of the kernels, that stores the kernel's configuration in the kernel image itself - at a cost of 1-4k of size - so that you can fairly quickly rebuild a kernel just based on the config that the running kernel has. This wouldn't be the "proconfig" patch would it? With this patch, you can type "cat /proc/config" and it will give you a list of features set, in the form of a Config file for the running kernel. I tried it on 2.2.18 -- I REALLY wanted it -- but it didn't work, and the author was focusing on 2.4, and hadn't updated since August of last year or something... Fairly neat, if not much of a use to the LRP/LEAF images. =) I would think it would be very useful, especially with everyone having different needs... ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Packages in PatchManager CVS
Mike Noyes, 2001-03-28 10:20 -0800 Everyone, I'd like us to start using the SF Tracker to handle package submissions. Comments? Note: I don't know if it's necessary to tarball/zip them before uploading. Everyone, PatchManager: I checked last night, and the Patch Manager handles binary files properly. So, if someone says they created a new package, please suggest that they submit it to the Patch Manager under Packages. Thanks. CVS: I would like us to use CVS for packages (.lrp). I added a binary wrapper this morning for .lrp. I'd like some feedback on possible directory structures. I think it should look something like this: packages -+ + /boot -+ |+ /eigerstein |+ /oxygen + /lib | + (this is where my thinking gets a little fuzzy) -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Nifty CD Idea
Charles Steinkuehler wrote: The chroot thing is a one-time deal to build a root image on the HDD. The part you're missing is I'm running LRP WITHOUT a ramdisk, more like conventional linux...hopefully I won't be burned at the stake. A Now I understand. Jeff was so gentle about it :) Some one else had suggested trying to make LRP use a CDROM-based filesystem; any have any ideas about that? David Douthitt wrote: My thoughts on bootable CDROM distributions are: 1. Bootable CDROMs have a FIXED image to boot from, and thus are single purpose systems. But that's what I want to change...you're still stuck with a fixed image when booting from CD-ROM, but the CD could do smart things based on the presence/absence of configuration files on the floppy, hard-disk, flash-disk, or other writable, non-volitle media. I already have the use of "config.lrp" coded into Oxygen; it is squirrelled away as it is found, and is loaded AFTER all other packages have loaded. However, this only configures the loaded packages; to configure WHICH packages actually get loaded requires a different method. Right now, there is LRP= (fixed), PKGPATH= (also fixed), and PKGLIST= (a changeable file perhaps?). I'm thinking about this - basically, you'd need: 1. ...to have the floppy in the configuration to load from (PKGPATH=/dev/fd0u1680:msdos) 2. ...to have intelligent reaction to a missing disk... The key to making this happen is getting a linuxrc that's smart (or flexible) enough to deal with whatever is required. The other missing piece is a way to communicate with the CD-ROM boot scripts. That would be syslinux.cfg; what is needed (sounds like) is a way to shift the entire "append=" line to another file... You can't change what's on the CD, so you either make some assumptions (like always load config info off a floppy, or a fixed set of devices) or you find a way to save some settings across a reboot (like the unused part of the CMOS ram) that all systems support. CMOS? Uhoh sounds both fascinating and reckless and dangerous - what a mix! 2. To make the bootable CDROM configurable, user input is required - which isn't nice in an unattended router. SOME input is required, but it doesn't have to come from the user. I'm envisioning a CD-ROM that when booted with a configured floppy will function as a normal LRP system, but when booted on it's own, comes up with some install scripts allowing you to: Install to a Hard-Disk Install to one (or more) floppies Create a configuration disk...boot the system with the CD and this disk, and you get a router/firewall I like that idea! I've been leaning towards a CDROM/floppy combination: you can configure the floppy all you want, then load packages from the CDROM. This is what I'm talking about... Um... not quite. You are talking about bootable CDROMs with a configuration disk; I am talking about booting from floppy disk and using the CDROM as a data disk. Your ideas are much more revolutionary than mine. I've also been considering (for a long time) using a CDROM to create a TFTP and/or FTP and/or HTTP server with packages available; thus you can put the CDROM in, boot, then go to another system, boot Oxygen on it, and download all packages via the CDROM system on the network. Hmm...haven't thought about this sort of thing much. I guess I don't generally like the idea of my router or servers booting off the network. Having a resource to load packages from would be a good thing, but why not just have that out on the internet somewhere? Then everyone can use it... You could do that too. The problem with that is: * Security - packages could be compromised - source system could be compromised - router (bridge?) would become visible to outside world, and would be immediately known as a LRP-style router * Availability: if the source goes down or changes IP, the router is dead when it reboots. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] grep options
"Scott C. Best" wrote: [...] what would be the equiv of, say: "grep -v -i FOO /etc/passwd" ? sed '/[Ff][Oo][Oo]/d' /etc/passwd Pi said: grep -v didn't even work in the old LRP2.9.8 release. Always had to hack around it by using sed -e "s/foo//" instead of grep -v "foo". Busybox 0.50 supports the following grep options: Hhinqvs So grep -iv works just fine... LRP may not have updated its busybox in some time; Oxygen uses the most current (now at 0.51pre) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] grep options
Pim van Riezen wrote: The "-i" I'm not sure about, I tend to not use regexpes all that oftenly either. -i is case-insensitivity. Being a regular vi nut, I use regexps all the time. It's gotten so bad I'm constantly having to check which regexps are allowed by which utility (vi, sed, grep ) A regular grep -v bar foo boils down to a sed -e "s/.*bar.*//" foo Not quite; this will replace all matching lines with a blank line. Also, -e is extraneous unless multiple commands are desired; beyond that, modern sed allows multiple commands inline, so even then -e is extraneous. At least with some hackery you can usually get the same result you're trying to get with the grep -v. Only it looks uglier : And sed is some 65k or so! Since it is no longer necessary, I've been working at getting sed out of the boot scripts - I think I'm nearly there. Busybox grep and ash can handle most things. The original LRP does a lot with sed... ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Packages in PatchManager CVS
Mike Noyes wrote: CVS: I would like us to use CVS for packages (.lrp). I added a binary wrapper this morning for .lrp. I'd like some feedback on possible directory structures. I think it should look something like this: packages -+ + /boot -+ |+ /eigerstein |+ /oxygen + /lib | + (this is where my thinking gets a little fuzzy) The CDROM I have has (in part) the following breakdown: src --+-- base ...like busybox, ctar, tftp, ... | +-- pkgs --+-- net | +-- sys | +-- ...et al... It occurs to me, too, that compiling some things will not work for different environments - unless we start with the base and use *.diff files - but then, maintaining the integrity of the source files should be more important than I've made it in the past... Personally, I've patched the following: * busybox * lcap * spak ...and perhaps a (very) few others... ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Packages in PatchManager CVS
David Douthitt, 2001-03-30 07:26 -0600 The CDROM I have has (in part) the following breakdown: src --+-- base ...like busybox, ctar, tftp, ... | +-- pkgs --+-- net | +-- sys | +-- ...et al... David, Are all the files in this src directory text, or are there binary files too? -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Nifty CD Idea
The key to making this happen is getting a linuxrc that's smart (or flexible) enough to deal with whatever is required. The other missing piece is a way to communicate with the CD-ROM boot scripts. That would be syslinux.cfg; what is needed (sounds like) is a way to shift the entire "append=" line to another file... You can't change what's on the CD, so you either make some assumptions (like always load config info off a floppy, or a fixed set of devices) or you find a way to save some settings across a reboot (like the unused part of the CMOS ram) that all systems support. CMOS? Uhoh sounds both fascinating and reckless and dangerous - what a mix! I remember seeing something once about a program to stash user data in the unused 1/2 of CMOS RAM that is available on almost all PC systems (at least those made after about 1988). I agree with the above...exciting and scary! I've been leaning towards a CDROM/floppy combination: you can configure the floppy all you want, then load packages from the CDROM. This is what I'm talking about... Um... not quite. You are talking about bootable CDROMs with a configuration disk; I am talking about booting from floppy disk and using the CDROM as a data disk. Your ideas are much more revolutionary than mine. Actually, I want both to work. My CD-ROM currently uses a floppy image to boot. If your system doesn't support booting from a CD, you just make a floppy image and boot off that. The trick is to be able to modify your configuration without changing any of the boot files (syslinux.cfg or root.lrp), which may be hardcoded on the CD. I've also been considering (for a long time) using a CDROM to create a TFTP and/or FTP and/or HTTP server with packages available; thus you can put the CDROM in, boot, then go to another system, boot Oxygen on it, and download all packages via the CDROM system on the network. Hmm...haven't thought about this sort of thing much. I guess I don't generally like the idea of my router or servers booting off the network. Having a resource to load packages from would be a good thing, but why not just have that out on the internet somewhere? Then everyone can use it... You could do that too. The problem with that is: * Security - packages could be compromised - source system could be compromised - router (bridge?) would become visible to outside world, and would be immediately known as a LRP-style router * Availability: if the source goes down or changes IP, the router is dead when it reboots. I was thinking about something more along the lines of the Debian apt-get functionality. All packages are stored locally, but if you want the latest widget package, you go out to an archive and grab it. IMHO, nothing in my running configuration should be loaded across the network at boot time (at least I don't ever plan to setup any routers this way). Beowolf clusters and the like are another matter entirely, however, so it makes sense to have the flexability to do some (or all) booting from the network...are the growing popularity of Beowolf clusters and the appearance of a dhcp client in the kernel coincidence? You be the judge... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Mailing list archive
David, does Oxygen have any reason it would be different from other LRPs, or should somebody give this guy the standard answer? I'm not sure what the standard answer would be. However, the use of the ram disks is hardcoded in linuxrc, and /etc/fstab; the kernel is probably the biggest item since it loads to RAM disk does it not? Perhaps it would be best to load the system normally (with a minimal root) then use root to shift to running from the hard drive and umount and destroy the RAM disk. When you umount a /dev/ram* device, is the memory essentially free and returned to the standard free pool? Or are some resources still used by it? I've seen reports you have to run freeramdisk, but I have yet to verify this. NOTE: Busybox has a freeramdisk function... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Nifty CD Idea
On Fri, Mar 30, 2001 at 06:49:48AM -0600, David Douthitt scribbled: This wouldn't be the "proconfig" patch would it? With this patch, you can type "cat /proc/config" and it will give you a list of features set, in the form of a Config file for the running kernel. Fairly neat, if not much of a use to the LRP/LEAF images. =) I would think it would be very useful, especially with everyone having different needs... "I'm having trouble getting my hard disk running for a squid cache." "Please post 'cat /proc/config'." ;) -- rick -- A mind is like a parachute... it only works when it's open. ICQ# 1590117 [EMAIL PROTECTED] (home) Help with LRP: http://lrp.c0wz.com Home page: http://www.c0wz.com ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Nifty CD Idea
Charles Steinkuehler wrote: Um... not quite. You are talking about bootable CDROMs with a configuration disk; I am talking about booting from floppy disk and using the CDROM as a data disk. Your ideas are much more revolutionary than mine. Actually, I want both to work. My CD-ROM currently uses a floppy image to boot. If your system doesn't support booting from a CD, you just make a floppy image and boot off that. The trick is to be able to modify your configuration without changing any of the boot files (syslinux.cfg or root.lrp), which may be hardcoded on the CD. The Oxygen method of creating and using a config.lrp takes care of the latter; in my opinion, modifying syslinux.cfg is much harder. I would suspect you would basically need to use a DIFFERENT way of passing parameters altogether - perhaps a configuration FILE instead. What with the 255-char limit on the parameter line -- I've already exceeded it more than once! -- it has occurred to me in the past to write a completely new configuration file structure. Then perhaps the syslinux.cfg could be static, and contain only necessary Linux kernel parameters (console= vga= ...et al). I'm not sure what format would be best; Algol/Pascal comes to mind, as do others. I think my preference may lean toward some Object Oriented format: network.eth0.dhcp device(/dev/ram0).mount = / device(/dev/ram1).mount = /tmp device(/dev/ram2).mount = /var/log disk(/).size = 24 disk(/tmp).size = 4 disk(/var/log).size = 2 packages.load.url = ftp://somewhere.com/pkgs/ packages.load.file = pkglist.cnf packages.load.disk(/dev/fd0u1680) packages.load.disk(/dev/fd1u1440).format = minix I can for see a *LOT* of enhancements going in here. Then you could use this on the append= command line in syslinux.cfg: LRPCONF=lrp.cfg ...and in fact, if you use a default, you don't need that either. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Packages in PatchManager CVS
David Douthitt, 2001-03-30 08:32 -0600 Mike Noyes wrote: David, Are all the files in this src directory text, or are there binary files too? The src directory is basically a snapshot of my build directories; so all have *.o files, as well as *diff files and so on. In some cases there are multiple versions, but I tried to clean them out. My idea was a) a clean, sorted resource for source files and archives; b) an archive that could be used this way: # cp -R /mnt/cdrom/src ./src ...and then you snake in and do your "make" and so on. The basic structure of a typical source directory is thus: pkgname --+-- pkg.source.dir -- source files, directories, etc. | +-- tar.gz file(s) | +-- occasional diff | +-- occasional note as to why it won't compile David, It looks like you have an oxygen tree that's almost ready for import into CVS. I can add binary wrappers for .o and tar.gz. This should allow you to import your src tree as oxygen. Did I miss anything? Is this something you'd like to do? -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Packages in PatchManager CVS
David Douthitt, 2001-03-30 09:09 -0600 If you like. I'm not sure what you mean by "binary wrappers for .o and tar.gz" ...? Everyone, This should explain how CVS handles binary files. It'll also explain why I need to add binary file wrappers. 9. Handling binary files http://www.cvshome.org/docs/manual/cvs_9.html CVS And Binary Files http://cvsbook.red-bean.com/cvsbook.html#CVS_And_Binary_Files The cvswrappers File http://cvsbook.red-bean.com/cvsbook.html#The_cvswrappers_File My binary files are messed up http://cvsbook.red-bean.com/cvsbook.html#My_binary_files_are_messed_up -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Packages in PatchManager CVS
Mike Noyes wrote: David Douthitt, 2001-03-30 09:09 -0600 Mike Noyes wrote: David, It looks like you have an oxygen tree that's almost ready for import into CVS. I can add binary wrappers for .o and tar.gz. This should allow you to import your src tree as oxygen. Did I miss anything? Is this something you'd like to do? If you like. I'm not sure what you mean by "binary wrappers for .o and tar.gz" ...? If you are speaking of binaries, there is also the binary packages, the "on-the-fly" created *.html, *.man, and whatever other results of compiling there may be. David, I'm talking about an import of the src tree from the CD into CVS. Are you talking about importing the compiled output, or am I confused again? Let me see if I understand this right: * What I have now is "working directories" which include multiple versions as well as compiled binaries. * CVS would be source files only (with diffs and docs included) Is that right? Then presumably the best thing to do would to get the *.tar.gz file, the diffs, and then extract the tar.gz file, apply necessary diffs, and let that sit (without the *.tar.gz) for CVS. Two things: * I never created *.diff files for makefile only changes - such as static libraries, and gcc options like -O2 -s -g * I almost never added -s, leaving that to a "strip" done later. Sounds like a time for a cleanup; I've also done a lot of new binaries... ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Packages in PatchManager CVS
David Douthitt, 2001-03-30 09:23 -0600 Mike Noyes wrote: David, I'm talking about an import of the src tree from the CD into CVS. Are you talking about importing the compiled output, or am I confused again? Let me see if I understand this right: * What I have now is "working directories" which include multiple versions as well as compiled binaries. * CVS would be source files only (with diffs and docs included) Is that right? David, Exactly! I couldn't have said it better. :) Then presumably the best thing to do would to get the *.tar.gz file, the diffs, and then extract the tar.gz file, apply necessary diffs, and let that sit (without the *.tar.gz) for CVS. You lost me. Two things: * I never created *.diff files for makefile only changes - such as static libraries, and gcc options like -O2 -s -g * I almost never added -s, leaving that to a "strip" done later. Now I'm completely lost. David, remember I'm not a programmer. I'm a barely functional admin for this project. I need a little hand holding here. Sorry. Sounds like a time for a cleanup; I've also done a lot of new binaries... -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] Functional Admin -kudos
I have to go with David here and I think it deserves a mention. You are coordinating work on an Open Source project. You have been driving force and crucial to installing and maintaining the website (you then found a better solution and made it happen :getting help counts), coordinating and writing documentation, doing the backend administrative work on getting a CVS tree going, setting up/manageing multiple mail lists, ftp permissions, Sourceforge updates and issues. Gathering a consensus on a variety of disparate issues (color, theme, logo, style, directory structure, now CVS) from a set of developers, and misc contributors of varying techinical levels and interests.) You have 'brought' in folks (Pim) by making them aware of what we are doing here. Regular updates/notification of Sourceforge issues. Prompting for standards in Documentation, etc. This is a synopsis. I've been on paying contracts that were not as well managed/coordinated. This is something that you can probably add to your resume in some fashion. Heck, I'll give you a reference letter if you want. :) -- Steven Peck [EMAIL PROTECTED] http://leaf.blkmtn.org -Original Message- From: David Douthitt To: [EMAIL PROTECTED] Sent: 3/30/2001 7:50 AM Subject: Re: [Leaf-devel] Packages in PatchManager CVS Mike Noyes wrote: David Douthitt, 2001-03-30 09:23 -0600 I'm a barely functional admin for this project. I disagree vehemently! This project has better documentation than I've seen almost anywhere else on Sourceforge; the PHPWebSite is phenomonal. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Functional Admin -kudos
Here here!! I second all of that. Mike, you are a major driving force that most projects don't have, and that we're _very_ lucky to have. I'm good for another reference letter. On Fri, Mar 30, 2001 at 11:26:20AM -0800, Steven Peck scribbled: I have to go with David here and I think it deserves a mention. You are coordinating work on an Open Source project. You have been driving force and crucial to installing and maintaining the website (you then found a better solution and made it happen :getting help counts), coordinating and writing documentation, doing the backend administrative work on getting a CVS tree going, setting up/manageing multiple mail lists, ftp permissions, Sourceforge updates and issues. Gathering a consensus on a variety of disparate issues (color, theme, logo, style, directory structure, now CVS) from a set of developers, and misc contributors of varying techinical levels and interests.) You have 'brought' in folks (Pim) by making them aware of what we are doing here. Regular updates/notification of Sourceforge issues. Prompting for standards in Documentation, etc. This is a synopsis. I've been on paying contracts that were not as well managed/coordinated. This is something that you can probably add to your resume in some fashion. Heck, I'll give you a reference letter if you want. :) -- Steven Peck [EMAIL PROTECTED] http://leaf.blkmtn.org -Original Message- From: David Douthitt To: [EMAIL PROTECTED] Sent: 3/30/2001 7:50 AM Subject: Re: [Leaf-devel] Packages in PatchManager CVS Mike Noyes wrote: David Douthitt, 2001-03-30 09:23 -0600 I'm a barely functional admin for this project. I disagree vehemently! This project has better documentation than I've seen almost anywhere else on Sourceforge; the PHPWebSite is phenomonal. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel -- rick -- A mind is like a parachute... it only works when it's open. ICQ# 1590117 [EMAIL PROTECTED] (home) Help with LRP: http://lrp.c0wz.com Home page: http://www.c0wz.com ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Nifty CD Idea
George Metz wrote: On Fri, 30 Mar 2001, David Douthitt wrote: This wouldn't be the "proconfig" patch would it? With this patch, you can type "cat /proc/config" and it will give you a list of features set, in the form of a Config file for the running kernel. Fairly neat, if not much of a use to the LRP/LEAF images. =) I would think it would be very useful, especially with everyone having different needs... How so? I suppose you could use it to grab the config from a running kernel in order to upgrade, but it's not as useful as it could be, what with a lack of any way to include the patches. It would be useful in scenarios like these: ONE: Mr. Wizard downloads an image (which has the proconfig patch installed). He runs it on his system - which has IDE drives on it. He does "cat /proc/config | grep IDE" to see if the kernel has IDE support builtin. TWO: Mr. Greenhorn downloads an image and it won't recognize his disk. Mr. Expert says: do this on your box: "cat /proc/config | ssmtp [EMAIL PROTECTED]" THREE: Mr. Developer downloads an image, and boots it. Seeing that the kernel is mostly what he wants, he does this: "cat /proc/config /mnt/Config" and then takes the floppy disk from /mnt and moves to the development box and does this: "cp /mnt/Config /usr/src/linux/.config make menuconfig" ...there should be more options... ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Possible lrp.c0wz.com and/or lrp.steinkuehler.net downtime this weekend
This weekend, the forecast calls for a 30 percent chance of lrp.c0wz.com and/or lrp.steinkuehler.net downtime, as both myself and Charles may be working on new servers for our respective sites. Additionally, mine's gone a little flaky on me, so even if I don't replace the server, it could see some downtime. Here's some mirrors you can use: lrp.c0wz.com: http://leaf.sourceforge.net/devel/thc/ -- should be completely up-to-date (I made a few minor changes today) and fast http://c0wz.slaget.net http://c0wz.steinkuehler.net [if Charles's server is up :)] lrp.steinkuehler.net: lrp1.steinkuehler.net - SourceForge mirror lrp2.steinkuehler.net - Provided by Transtronics.com (soon to be lrp.steinkuehler.net) lrp.bluefx.com - Thanks to Bryan Schmidt lrp.fuzzylinux.com - Thanks to Steve Sobka lrp.mirazon.com - Thanks to Barry Martin The Mirazon Group steinkuehler.slaget.net - Thanks to Mike Branco upnet.dhs.org/lrp/ - Thanks to 'Upnet Joe' www.nisi.ab.ca/lrp - Thanks to Scott Young 64.32.160.79:8080 - Thanks to Dave Childs Wow. Charles has got a lot of mirros. I'm jealous. ;) In other news, Linux 2.4.3 gave me a kernel panic today, after using it for only 4.75 hours...I guess it's still a little too bleeding edge. ;) -- rick -- A mind is like a parachute... it only works when it's open. ICQ# 1590117 [EMAIL PROTECTED] (home) Help with LRP: http://lrp.c0wz.com Home page: http://www.c0wz.com ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Nifty CD Idea
On Fri, Mar 30, 2001 at 09:03:15PM -0500, George Metz scribbled: It would appear from discussion here and a search that proconfig was folded into 2.4; in any case, the most recent versions at the web site are: I couldn't find it in menuconfig, nor by a recursive, case insensitive grep for 'proconfig' in my 2.4.2 tree. That would be because you're running Slack, not SuSE. And at any rate, Well, if you look at the top quote, the suggestion was that it has been folded into the main kernel tree; and I don't use slack-provided kernels, I download plain kernels from kernel.org...not that I think slack patches their kernels anyhow. ;) SuSE calls it config.gz, so a search for proconfig might not turn anything up. If it was part of the main kernel tree, I'd expect to find it inside an uncompressed ASCII text file.. -- George Metz Commercial Routing Engineer [EMAIL PROTECTED] -- rick -- A mind is like a parachute... it only works when it's open. ICQ# 1590117 [EMAIL PROTECTED] (home) Help with LRP: http://lrp.c0wz.com Home page: http://www.c0wz.com ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Nifty CD Idea
On Sat, 31 Mar 2001 [EMAIL PROTECTED] wrote: Well, if you look at the top quote, the suggestion was that it has been folded into the main kernel tree; and I don't use slack-provided kernels, I download plain kernels from kernel.org...not that I think slack patches their kernels anyhow. ;) Right. I'd be surprised if Slack - or Debian, for that matter - adds additional patches to their kernel. Everyone else seems to though, as long as "everyone else" consists mainly of Mandrake, SuSE, Red Hat, et al. SuSE calls it config.gz, so a search for proconfig might not turn anything up. If it was part of the main kernel tree, I'd expect to find it inside an uncompressed ASCII text file.. As would I, which was one of the things that confused me. But hey, it shows as a 0-byte file in an ls -l, so who knows why they did that. I'm fairly sure it's a SuSE specific patch though. -- George Metz Commercial Routing Engineer [EMAIL PROTECTED] "We know what deterrence was with 'mutually assured destruction' during the Cold War. But what is deterrence in information warfare?" -- Brigadier General Douglas Richardson, USAF, Commander - Space Warfare Center ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Packages in PatchManager CVS
David Douthitt, 2001-03-30 11:11 -0600 Mike Noyes wrote: David Douthitt, 2001-03-30 09:50 -0600 ...what you have after this is done is a source code directory that could, in theory, be compiled straight away to create a usable LRP binary. That sounds great! Ok, I just added wrappers for .o and .tar.gz. I can remove them later if they're not needed. Is there anything else we need to do? I suspect CVS is for text only (thus the wrappers eh?) David, Yes. It doesn't handle binary files really well, but it can manage them. It's unable to produce diffs and other housekeeping for binaries that it does with text files. The wrappers aren't necessary for *.o, since my vision is pure source code. I just removed the wrapper for *.o. Current binary wrappers are: *.gif *.jpg *.png *.lrp *.tar.gz This gets back to my original post. I created a binary wrapper for .lrp, so we could add them to CVS. If there is a clean way to use the source instead, I'm all for it. I'm working now on creating a */lrp directory which would contain all of the appropriate files and a Makefile to create the *.lrp file. I'm using hpa-tftp as the test. Excellent! Now I have a reason to learn make. :) -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
