Re: [Leaf-devel] Archives, Sources, CVS et al
At 2002-02-15 21:37 -0600, David Douthitt wrote: What it comes down to is the following FreeBSD entities: * making packages (*.lrp) * ports * source code for the system I've started creating a directory tree - in preparation for putting it into CVS - a tree that contains configurations, patches, etc - just for creating binaries that are used by Oxygen itself (and not packages or ports). Once I get this done (about a dozen archives or so) - I'll put them into Oxygen (all will then use glibc 2.1.3 if not static) - and put the tree into an Oxygen development CVS tree. David, Will you commit this new tree to src/oxygen or bin/oxygen? It sounds to me like it should go in src/oxygen. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000page_id=4 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/15/02 at 10:15 PM, David Douthitt [EMAIL PROTECTED] wrote: Perhaps what we NEED is a test suite - a sort of minimalist autoconf which details what works and what doesn't... Like this: Checking for busybox date no Checking for busybox install no Checking for ip... yes Checking for netstat... no Checking for route... no Checking for ifconfig... no ...etc... -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Archives, Sources, CVS et al
On 2/16/02 at 4:42 AM, Mike Noyes [EMAIL PROTECTED] wrote: Will you commit this new tree to src/oxygen or bin/oxygen? It sounds to me like it should go in src/oxygen. Me too. Probably into src/oxygen/base ... -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
At 2002-02-16 07:25 -0600, David Douthitt wrote: On 2/15/02 at 10:15 PM, David Douthitt [EMAIL PROTECTED] wrote: Perhaps what we NEED is a test suite - a sort of minimalist autoconf which details what works and what doesn't... Like this: Checking for busybox date no Checking for busybox install no Checking for ip... yes Checking for netstat... no Checking for route... no Checking for ifconfig... no ...etc... David, Would it be possible to apply something like this to package testing. e.g. Checking for program name: foo.bar Checking for program version: 1.00 Checking for libc version: 2.1.3 Checking compatibility with Bering: no Checking compatibility with Dachstein: no Checking compatibility with Oxygen: yes Checking compatibility with PacketFilter: no Checking compatibility with WRP: no -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000page_id=4 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
David, I should know better than to post this early in the morning. I didn't express myself well. See in-line comments below for an explanation. Sorry. :-( At 2002-02-16 05:42 -0800, Mike Noyes wrote: At 2002-02-16 07:25 -0600, David Douthitt wrote: On 2/15/02 at 10:15 PM, David Douthitt [EMAIL PROTECTED] wrote: Perhaps what we NEED is a test suite - a sort of minimalist autoconf which details what works and what doesn't... Like this: Checking for busybox date no Checking for busybox install no Checking for ip... yes Checking for netstat... no Checking for route... no Checking for ifconfig... no ...etc... David, Would it be possible to apply something like this to package testing. Scratch the question above and replace it with: Would it be possible to parse the autoconf output above for package testing? e.g. Checking package file structure: OK Checking for program name: foo.bar Checking for program version: 1.00 Checking for libc version: 2.1.3 Checking compatibility with Bering... Parsing Bering autoconf output: no Checking compatibility with Dachstein... Parsing Dachstein autoconf output: no Checking compatibility with Oxygen... Parsing Oxygen autoconf output: yes Checking compatibility with PacketFilter: no Parsing PacketFilter autoconf output: no Checking compatibility with WRP: no Parsing WRP autoconf output: no -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000page_id=4 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] SF Mirror
Charles Steinkuehler wrote: I hate to be a bit lazy, but lacking all the fancy Linux distro's, I was wondering if somebody could distill the essential commands needed to grab everything in bulk data format so that I'd just have a few .tgz files or something. Sort of like: 1) SF provides nightly tarballs of our repository for backup purposes. http://cvs.sourceforge.net/cvstarballs/leaf-cvsroot.tar.gz 2) Grab all released files wget -m http://prdownloads.sourceforge.net/leaf/ BTW: You can rsync these from downloads.sourceforge.net::sourceforge/leaf/ 3) Rsync some stuff rsync blah 4) Back all that up to tape. Then I could at least guarantee to have it properly archived. I could probably do that once a week or two if the download went fast enough. It if were 6 GB , that'd take me 11 hours downloading via my 150 KB/s pipe. Backup to tape would take about 30 min :) Same for verify. I'm working on exactly that, but it will probably be a few more days until I've got it down to a science. I just got my new 1U server appliance, and have to play some with the new toy... Thank Mike and CS for making that. In case you missed these, CompGeeks was selling an Intel 1U web server appliance (ie headless), with 750 MHz P3, Adaptec 29160, 9G quantum drive, 256 Meg ram, and 2 onboard NIC's...all for $635. I wish I'd bought three instead of one (I didn't know they had 64 bit Adaptec 29160's in them at the time!!!), but then I might never get back to LEAF work ;-) Neat but does the 1U have a real 64 bit PCI data bus, not the usual 32-bit one, and does the 29160 plug into a 64-bit, extra-long, pci-slot proving that it's a 64-bit setup? I've tried shopping for 64-bit mainboards, and the market is a bit thin these days. It's pretty sad seeing my flashy new 29160 dangling it's connectors over the edge of a 32-bit pci slot :-) Regards, Matt ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] SF Mirror
Neat but does the 1U have a real 64 bit PCI data bus, not the usual 32-bit one, and does the 29160 plug into a 64-bit, extra-long, pci-slot proving that it's a 64-bit setup? I've tried shopping for 64-bit mainboards, and the market is a bit thin these days. It's pretty sad seeing my flashy new 29160 dangling it's connectors over the edge of a 32-bit pci slot :-) Yeah, the MoBo is only 32 bit, so I've got the extra pins dangling :( Still, I think it'll work a bit better than my current 486 system talking to a VLB SCSI controller :) (the new system is slated to be my primary web server when it comes online, replacing my LRP based 486 machine currently running my LRP/LEAF site, and a handful of other systems I've got serving up web content (like the P75 based htdig search engine: http://search.steinkuehler.net). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/16/02 at 6:20 AM, Mike Noyes [EMAIL PROTECTED] wrote: At 2002-02-16 05:42 -0800, Mike Noyes wrote: At 2002-02-16 07:25 -0600, David Douthitt wrote: On 2/15/02 at 10:15 PM, David Douthitt [EMAIL PROTECTED] wrote: Perhaps what we NEED is a test suite - a sort of minimalist autoconf which details what works and what doesn't... Like this: Checking for busybox date no Checking for busybox install no Checking for ip... yes Checking for netstat... no Checking for route... no Checking for ifconfig... no ...etc... David, Would it be possible to apply something like this to package testing. Scratch the question above and replace it with: Would it be possible to parse the autoconf output above for package testing? I wasn't talking about actually USING autoconf... e.g. Checking package file structure: OK Anyway, apkg -v already does this... Checking for program name: foo.bar Checking for program version: 1.00 Checking for libc version: 2.1.3 Checking for program version requires a way to find it out. Not only that, it implies that if you need 1.00 but have 2.01a_Beta3 then you're alright - but try to program that... Finding the libc version is probably limited to checking the filename in /lib - but is limited again in the comparison values... Checking compatibility with Bering... Parsing Bering autoconf output: no Checking compatibility with Dachstein... Parsing Dachstein autoconf output: no Checking compatibility with Oxygen... Parsing Oxygen autoconf output: yes Checking compatibility with PacketFilter: no Parsing PacketFilter autoconf output: no Checking compatibility with WRP: no Parsing WRP autoconf output: no I was thinking one would run this script in a LEAF environment - and it would be set up by a developer, who defines what is needed. Then you could boot Oxygen (or PacketFilter, or...) and run this script which tests the environment. Now if you could just generate this set of (command) requirements (and option requirements) on the fly from a script -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
