Re: [leaf-devel] possible bug in linuxrc
Charles Steinkuehler [EMAIL PROTECTED] writes:
Erich Titl wrote:
| There is a possible bug in linuxrc (at least with the busybox of Bering)
| when trying to create and mount the /tmp filesystem.
|
| Here is the output from /linuxrc.err
|
| mount -t tmpfs tmpfs /tmp -o size=20M
| mount: Mounting tmpfs on /tmp failed: Invalid argument
| mount -t tmpfs tmpfs /tmp -o size=20M
|
| I extended linuxrc a little to get the debug info. It appears as if the
| tmpfs mount does not like the parameter substitution used for tmp_size
|
| here is the relevant code
|
| [ $VERBOSE ] Lecho Generating /tmp /var/log partitions ...
| echo mount -t tmpfs tmpfs /tmp ${tmp_size:+-o size=$tmp_size}
| /linuxrc.err
| qt mount -t tmpfs tmpfs /tmp ${tmp_size:+-o size=$tmp_size}
| echo mount -t tmpfs tmpfs /tmp -o size=$tmp_size /linuxrc.err
| qt mount -t tmpfs tmpfs /tmp -o size=$tmp_size
|
| as you can see, the second mount appears to work, this is with tmp_size
| set to 20M in leaf.cfg
I suspect the entire -o size=20M is being passed to mount as a single
argument, causing the problem.
I think it only would be a single argument if there were quotes around
the ${:+} substitution:
[EMAIL PROTECTED]:\w# unset tmp_size; for arg in ${tmp_size:+-o size=$tmp_size}
foo ${tmp_size:+-o size=$tmp_size}; do echo [$arg]; done
[foo]
[]
[EMAIL PROTECTED]:\w# tmp_size=20M; for arg in ${tmp_size:+-o size=$tmp_size}
foo ${tmp_size:+-o size=$tmp_size}; do echo [$arg]; done
[-o]
[size=20M]
[foo]
[-o size=20M]
[EMAIL PROTECTED]:\w#
(run on my BU box running the standard /bin/sh shell)
However, I'd try leaving out the space after the -o, i.e. I'd run it as
mount -t tmpfs tmpfs /tmp ${tmp_size:+-osize=$tmp_size}
Gru,
Uli
pgpdYNSF5qEi3.pgp
Description: PGP signature
Re: [leaf-devel] package libcxx: buildtool.cfg filenames
Martin Hejl [EMAIL PROTECTED] writes: But if someone wants to fix the current regexp based buildpacket.pl code, the proposed workaround should point to the bug quite directly. correction - I found the issue you're seeing. It wasn't triggered when I tried, because I didn't fully specify the Filename part of the file definition. I've updated buildpacket.pl in CVS, please give it a try. It works now. I have thus removed the workaround from apps/libgcc/buildtool.cfg. Uli --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] package libcxx: buildtool.cfg filenames
Oliver Ertl [EMAIL PROTECTED] writes: in libcxx/buildtool.cfg you could change the Source line with the two questenmarks from: [...] Source = lib/libstdc??.so.5.0.5 [...] to this [...] Source = lib/libstdc\+\+.so.5.0.5 [...] Then you could specify the full filename. I think we'd be better off fixing buildpacket.pl - perhaps using Glob::* instead of dubious regexp magic. And a fixed buildpacket.pl will still work with ?? but not with \+\+, so I'd plead to leave it as it is :-) Uli --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] package libcxx: buildtool.cfg filenames
Hans Ulrich Niedermann [EMAIL PROTECTED] writes: Oliver Ertl [EMAIL PROTECTED] writes: in libcxx/buildtool.cfg you could change the Source line with the two questenmarks from: [...] Source = lib/libstdc??.so.5.0.5 [...] to this [...] Source = lib/libstdc\+\+.so.5.0.5 [...] Then you could specify the full filename. I think we'd be better off fixing buildpacket.pl - perhaps using Glob::* instead of dubious regexp magic. But if someone wants to fix the current regexp based buildpacket.pl code, the proposed workaround should point to the bug quite directly. And a fixed buildpacket.pl will still work with ?? but not with \+\+, so I'd plead to leave it as it is :-) Uli --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Re: [leaf-cvs-ci] src/bering-uclibc/buildtool buildpacket.pl,1.26,1.27
Martin Hejl [EMAIL PROTECTED] writes:
Update of /cvsroot/leaf/src/bering-uclibc/buildtool
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv32764
Modified Files:
buildpacket.pl
Log Message:
Hopefully fixed problem with permissions of directories that are also used in
a file-entry with a wildcard and issue with filenames containing +
Unfortunately, this patch does not fix the problem (debug output added
by me):
sourceFile =
/tmp/BUILDTOOL_STAGING_vR02/lib/libstdc++.so.5.0.5/libstdc\+\+\.so\.5\.0\.5
Nested quantifiers in regex; marked by -- HERE in
m/^/tmp/BUILDTOOL_STAGING_vR02/lib/libstdc++ -- HERE
.so.5.0.5/libstdc\+\+\.so\.5\.0\.5$/ at ./buildpacket.pl line 768.
However, I wonder why the wildcard stuff is not done with glob() or
File::Glob...
Index: buildpacket.pl
===
RCS file: /cvsroot/leaf/src/bering-uclibc/buildtool/buildpacket.pl,v
retrieving revision 1.26
retrieving revision 1.27
diff -C2 -d -r1.26 -r1.27
*** buildpacket.pl22 Oct 2004 20:34:23 - 1.26
--- buildpacket.pl31 Jan 2005 21:31:24 - 1.27
***
*** 184,187
--- 184,190
$regex =~ s/\./\\\./ig;
$regex =~ s/\*/\.\*/ig;
+ # make sure a + in the filename doesn't screw up our regex
+ $regex =~ s/\+/\\\+/ig;
+
foreach my $fileToCheck (keys %{$p_h_tmpListFiles}) {
***
*** 206,209
--- 209,216
$regex =~ s/\*/\.\*/ig;
+ # make sure a + in the filename doesn't screw up our regex
+ $regex =~ s/\+/\\\+/ig;
+
+
foreach my $fileToCheck (keys %{$p_h_allFiles}) {
# if it matches, we can remove it from the list
***
*** 709,723
print Setting file ownerships and permissions\n if $verbose;
- my $permission;
- my $ownership;
foreach my $file (keys %{$p_h_package_contents}) {
# setup defaults
if ($p_h_package_contents-{$file} eq 'FILE') {
! $permission = $p_h_package-{'permissions'}-{'files'} ;
! $ownership = $p_h_package-{'owner'}-{'files'};
} else {
! $permission =
$p_h_package-{'permissions'}-{'directories'} ;
! $ownership = $p_h_package-{'owner'}-{'directories'};
}
--- 716,736
print Setting file ownerships and permissions\n if $verbose;
foreach my $file (keys %{$p_h_package_contents}) {
+
+ my $permission=0;
+ my $ownership=0;
+
+ my $defaultPermission;
+ my $defaultOwnership;
+
+
# setup defaults
if ($p_h_package_contents-{$file} eq 'FILE') {
! $defaultPermission =
$p_h_package-{'permissions'}-{'files'} ;
! $defaultOwnership = $p_h_package-{'owner'}-{'files'};
} else {
! $defaultPermission =
$p_h_package-{'permissions'}-{'directories'} ;
! $defaultOwnership =
$p_h_package-{'owner'}-{'directories'};
}
***
*** 745,748
--- 758,763
$sourceFile =~ s/\./\\\./ig;
$sourceFile =~ s/\*/\.\*/ig;
+ # make sure a + in the filename doesn't screw
up our regex
+ $sourceFile =~ s/\+/\\\+/ig;
# We must assume that $filename is a directory,
if
***
*** 753,764
}
! if ($file eq $filename || $wildcardMatch ) {
$permission = $p_h_file-{'permissions'} if
exists($p_h_file-{'permissions'} );
$ownership = $p_h_file-{'owner'} if
exists($p_h_file-{'owner'});
last;
}
}
# don't change permissions of links
if (! -l $file) {
--- 768,789
}
! # tricky - problematic when a file entry as well as a
wildcard matches
! # if that happens, the file entry overrides the
wildcard match
! if ($file eq $filename $p_h_file-{'source'} !~
/\*/g) {
$permission = $p_h_file-{'permissions'} if
exists($p_h_file-{'permissions'} );
$ownership = $p_h_file-{'owner'} if
exists($p_h_file-{'owner'});
last;
}
+
+ if ($wildcardMatch !$ownership) {
+
[leaf-devel] grammar fix for buildtool.pl
Index: src/bering-uclibc/buildtool/buildtool.pl
===
RCS file: /cvsroot/leaf/src/bering-uclibc/buildtool/buildtool.pl,v
retrieving revision 1.13
diff -u -3 -p -r1.13 buildtool.pl
--- src/bering-uclibc/buildtool/buildtool.pl2 Mar 2005 16:33:05 -
1.13
+++ src/bering-uclibc/buildtool/buildtool.pl9 Mar 2005 22:17:32 -
@@ -202,7 +202,7 @@ if ($ARGV[0] eq describe) {
} elsif ($ARGV[0] eq distclean) {
# make it distclean
- print \nare you sure you want to delete everything you downloaded and
build? (y/N) ;
+ print \nAre you sure you want to delete everything you've downloaded and
built? (y/N) ;
my $ask = STDIN;
chop $ask;
if ($ask eq y or $ask eq Y or $ask eq j or $ask eq J) {
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Integrating libstc++ and libpthread in BU root package
Hi, in current CVS, both the libstdc++ and libpthread .so libraries are created by ./buildtool build root but libcstc++ is not packaged at all, and libpthread is packaged in a separate empty package which builds nothing. That doesn't make sense, so here is my updated patch which removes the empty libpthread package (lpthread.lrp) and lets ./buildpacket.pl --package=root --all create these packages: root.lrp with the very same content as today libcxx.lrp contains libgcc_s.so* and libstdc++.so* lpthread.lrp contains libpthread.so* When applying the patch, you can also remove the files from src/bering-uclibc/apps/libpthread/ I have verified this patch by running the two lines given above, and then comparing src/bering-uclibc/buildtool/packages/lpthread.lrp with bin/packages/uclibc-0.9/20/lpthread.lrp and finding that the contents match. For lack of commit priviledges, I cannot commit the patch but have to nerve the BU developers here :-) Index: src/bering-uclibc/apps/root/buildtool.cfg === RCS file: /cvsroot/leaf/src/bering-uclibc/apps/root/buildtool.cfg,v retrieving revision 1.14 diff -u -3 -p -r1.14 buildtool.cfg --- src/bering-uclibc/apps/root/buildtool.cfg 18 Oct 2004 20:00:42 - 1.14 +++ src/bering-uclibc/apps/root/buildtool.cfg 9 Mar 2005 22:17:32 - @@ -502,6 +502,97 @@ /Contents /root + libcxx + Help EOF + libcxx - C++ runtime libraries + Requires: root.lrp + LEAF package + + This package contains the C++ runtime corresponding to the + root.lrp package. + EOF + + Permissions + Files = 644 + Directories = 755 + /Permissions + Owner + Files = root:root + Directories = root:root + /Owner + Contents + File + Filename= lib/libgcc_s.so.0.9.9 + Source = lib/libgcc_s.so.0.9.9 + Type= binary + Permissions = 755 + /File + File + # We would like to write + #Filename = lib/libstdc++.so.5.0.5 + #Source = lib/libstdc++.so.5.0.5 + # but buildpacket.pl barfs on the ++. + # So we use this instead: + Filename= lib/ + Source = lib/libstdc??.so.5.0.5 + Type= binary + Permissions = 755 + /File + File + Filename= lib/libstdc++.so.5 + Target = lib/libstdc++.so.5.0.5 + Type= link + Permissions = 755 + /File + File + Filename= var/lib/lrpkg/libcxx.version + Target = var/lib/lrpkg/root.version + Type= link + Permissions = 755 + /File + /Contents + /libcxx + lpthread + Help EOF + lpthread - The libpthread library + Requires: root.lrp + Homepage: http://www.uclibc.org + LEAF package by __PACKAGER__, __BUILDDATE__. + + This package contains libpthread corresponding to the root.lrp + package. + EOF + + Permissions + Files = 644 + Directories = 755 + /Permissions + + Owner + Files = root:root + Directories = root:root + /Owner + + Contents + File + Filename= lib/libpthread-0.9.20.so + Source = lib/libpthread-0.9.20.so + Type= binary + Permissions = 755 + /File + File + Filename= lib/libpthread.so.0 + Target = lib/libpthread-0.9.20.so + Type= link +
Re: [leaf-devel] More errors with buildtool
Martin Hejl [EMAIL PROTECTED] writes: - lpthread - wrong directory (lpthread) in sources.cfg Fixed in CVS From a buildtool outsider's point of view, I wonder why lpthread is a separate source package anyway. Isn't the content of lpthread.lrp generated when uclibc (i.e. the buildenv source package) is built? I have that impression, and it appears to me that the most logical place to build the lpthread.lrp would thus be from the buildenv's buildtool.cfg. Gru, Uli --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Package for C++ libraries
Hans Ulrich Niedermann [EMAIL PROTECTED] writes: Hans Ulrich Niedermann [EMAIL PROTECTED] writes: Therefore, I present the attached patch to the root package to fix that. It creates a libcxx.lrp package containing libstdc++ and libgcc_s. Apply in src/bering-uclibc. Index: root/buildtool.cfg === RCS file: /cvsroot/leaf/src/bering-uclibc/apps/root/buildtool.cfg,v retrieving revision 1.14 diff -u -3 -p -r1.14 buildtool.cfg --- root/buildtool.cfg18 Oct 2004 20:00:42 - 1.14 +++ root/buildtool.cfg21 Jan 2005 01:36:05 - @@ -502,5 +502,51 @@ [...] + File + # We use the wildcard to work around a bug + # around buildpacket.pl:752 + Filename= lib/ + Source = lib/libstdc*.so.5.0.5 + Type= binary + Permissions = 755 + /File KP asked on IRC what that bug was about, and I want to get that on record here: The * replaces ++ in the filename, and + has a special function in Perl regexps. But the + case isn't handled correctly in buildpacket.pl, and I couldn't figure out how to fix it within a few minutes, so I went for the workaround. Gru, Uli pgpIQo8jPJMjd.pgp Description: PGP signature
Re: [leaf-devel] Canonical source for 6wall and lrcfg source code?
Eric de Thouars [EMAIL PROTECTED] writes: Martin Hejl wrote: Hans Ulrich Niedermann wrote: where is the canonical place to get source code for 6wall and lrcfg from? Not sure about 6wall - but I would guess the latest lrp from CVS at http://cvs.sourceforge.net/viewcvs.py/leaf/bin/bering-uclibc/packages/ Yes, that's the place for 6wall Is there any reason against a) having 6wall in the buildtool b) having a source repository of the 6wall source files in CVS/SVN/Arch somewhere except that no one has bothered so far? :) IMHO, 6wall could use ulogd support, and this would be most easily ported from shorewall if the 6wall source files were available somewhere. Or do you want me to just send you patches, Eric? Gru, Uli pgp6Wh352wjvl.pgp Description: PGP signature
Re: [leaf-devel] Package for C++ libraries
Hans Ulrich Niedermann [EMAIL PROTECTED] writes: I have found neither libstdc++ nor libgcc_s in any standard package. Is that correct? It is correct, as I have just verified by building from CVS. Therefore, I present the attached patch to the root package to fix that. It creates a libcxx.lrp package containing libstdc++ and libgcc_s. Apply in src/bering-uclibc. Gru, Uli Index: root/buildtool.cfg === RCS file: /cvsroot/leaf/src/bering-uclibc/apps/root/buildtool.cfg,v retrieving revision 1.14 diff -u -3 -p -r1.14 buildtool.cfg --- root/buildtool.cfg 18 Oct 2004 20:00:42 - 1.14 +++ root/buildtool.cfg 21 Jan 2005 01:36:05 - @@ -502,5 +502,51 @@ /Contents /root + libcxx + Help EOF + libcxx - C++ runtime libraries + Requires: root.lrp + LEAF package + + This just contains the C++ runtime corresponding to the + root.lrp package. + EOF + + Permissions + Files = 644 + Directories = 755 + /Permissions + Owner + Files = root:root + Directories = root:root + /Owner + Contents + File +Filename = lib/libgcc_s.so.0.9.9 +Source = lib/libgcc_s.so.0.9.9 +Type = binary +Permissions = 755 + /File + File +# We use the wildcard to work around a bug +# around buildpacket.pl:752 +Filename = lib/ +Source = lib/libstdc*.so.5.0.5 +Type = binary +Permissions = 755 + /File + File +Filename = lib/libstdc++.so.5 +Target = lib/libstdc++.so.5.0.5 +Type = link +Permissions = 755 + /File + File +Filename = var/lib/lrpkg/libcxx.version +Target = var/lib/lrpkg/root.version +Type = link +Permissions = 755 + /File + /Contents + /libcxx /Package - pgpfp1VmUx42U.pgp Description: PGP signature
[leaf-devel] Package for C++ libraries
Hi, I have been building a BU package of YATE - Yet Another Telephony Engine URL:http://yate.null.ro/ which is written in C++ and thus requires libstdc++ and libgcc_s. I have found neither libstdc++ nor libgcc_s in any standard package. Is that correct? If so, I provide the steps with which I have hacked together a working cxx.lrp package to help with directly creating an official cxx.lrp: 1. Copied -rwxr-xr-x root/root 2988706 2005-01-17 01:44:39 lib/libstdc++.so.5.0.5 lrwxrwxrwx root/root 0 2005-01-17 05:41:12 lib/libstdc++.so.5 - libstdc++.so.5.0.5 -rw-r--r-- root/root863683 2005-01-17 01:46:06 lib/libgcc_s.so.0.9.9 from my buildtool staging/ directory to the running BU, and added files 2) Created file var/lib/lrpkg/cxx.list with a content of lib/libgcc_s.so.0.9.9 lib/libstdc++.so.* var/lib/lrpkg/cxx.* 3) Created file var/lib/lrpkg/cxx.version with a content of 0.9.20 (in the assumption that these files belong to uClibc/gcc) 4) Added proper entries in /var/lib/lrpkg/backdisk and /var/lib/lrpkg/packages. 5) Backed up cxx package in lrcfg. Gru, Uli pgpUMyTS1ziDK.pgp Description: PGP signature
[leaf-devel] What I don't like about Bering uClibc
Hi, don't get me wrong - I love Bering uClibc. But while installing Bering uClibc on a WRAP and building, installing and testing yate packages, I got to hate some aspects of it :) I'll make a list so you can give some input about it: 1. (buildtool) There is no build-all-packages to (re-)build all packages. 2. (buildtool?) There is no build-hdd-image-for-my-board which copies all the necessary lrp files, sets up leaf.cfg with all the lrp names, possibly installs grub on the image, and so on. 3. (lrcfg aka config) Every time I have modified a config file of package XYZ in lrcfg, I have to a) run /etc/init.d/XYZ restart from another shell b) make the changes permanent doing this: - go up two levels in the menu - enter the backup menu - read through the list to find XYZ' number (different from XYZ' number in the Packages configuration menu) - type b to back up - wait for some time - manually compare two numbers without given units, where one shows Bytes (new file size) and the other Kilobytes (free space) - if enough space is available, I have to manually confirm I'd like to have to menu entries in the package configuration: i) restart service ii) make changes permanent This should check for the amount of free space by itself. 4. (lrcfg, buildtool, ???) Every time I have an updated package and install it, I have to manually save my config files and somehow merge them into the new package. Keeping the config, or having diff/edit, or even 3-way merge would be very nice. Gru, Uli pgpXubfDGXX95.pgp Description: PGP signature
[leaf-devel] LEAF Bering uClibc, OpenWRT, OpenEmbedded and the Uber Distribution
Hi! I recently got myself a Linksys WRT54GS/OpenWRT box as a backup solution for my PCEngines WRAP/Bering uClibc box (to maintain the service while updating the box, or demoing it somewhere else). When I was setting up OpenWRT (http://openwrt.org/), I noticed a few things: - Both OpenWRT and BU are built on a Linux kernel and uClibc. - Both use the uClibc build root, and the .mk files look quite similar. - Both a floppy-based BU on a PC with 4MB RAM and OpenWRT face serious space limitations. - But 6wall is only in BU, and some other stuff only in OpenWRT. - To package a certain piece of software, I have to build two packages. I wonder whether it is possible and desirable to have a build system which builds a base system image and packages for a Linux/uClibc based OS running on completely different kinds of hardware: 1. Standard PC booting from a) floppy b) harddisk 2. Embedded PC board without keyboard, with special devices (HW watchdog) 3. Broadcom/MIPS based routers like the Linksys WRT54G(S) 4. Embedded boards running PPC, ARM, whatever... It seems that I'm not the only one who ever thought of that. In the OpenWRT developer forum (http://openwrt.org/forum/viewforum.php?f=2) there is a thread (http://openwrt.org/forum/viewtopic.php?t=199) about OpenEmbedded (http://openembedded.org/oe_wiki/index.php/OpenEmbedded) which tries to do something quite similar... Does anyone else from the LEAF devs think that this may be an interesting idea to pursue? Gru, Uli --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Creating Bering uClibc images
Hi, here are a few thoughts about how to create media images with Bering uClibc. They may serve as thought food and a foundation for a healthy discussion... 1. It is non-trivial to create images if you don't have a step by step HOWTO to follow. Currently we have these: http://leaf-project.org/doc/guide/bugrub.html (Bering User's Guide) http://leaf-project.org/doc/guide/bucu-ide.html (Bering uClibc User's Guide) http://leaf.lauft.net/bu-docs/buci-hdd.html (Originally intended for the Bering uClibc Installation Guide, written before finding out that HDD installation is not covered in the Installation Guide, but in the User's Guide. Go figure.) Composing all relevant information in a chapter of the BU Install Guide will probably the best way to improve this. 2. Bering uClibc releases ship as floppy (FDD) and cdrom (ISO) images, but not as harddisk (HDD) images. But the users of all other devices like HDDs, CF media, USB Sticks, Flash Disks, etc. have to build their images from scratch. 3. Building a FDD image can be easily done by a script. You basically do dd if=/dev/zero of=image mkdosfs image mcopy *.lrp image: syslinux image and you have a working image. You don't even need to be root. 4. On IRC, Mike brought up a few possibilities to deploy an image creator: a) A website where you can click together your custom BU image similar to http://rom-o-matic.net/5.2.6/ b) A CD-ROM image with a booting version of linux on it, from which you can build BU images. I suggested to call this LICK - LEAF Image Creator Knoppix :) 5. Building a HDD image is difficult. You either a) do it as root on a real HDD device b) do a lot of evil dd if= of= bs= count= skip= seek= magic with harddisk and partition images to emulate userspace partition handling. You have to take into account CHS mappings, whether you want to use SYSLINUX or GRUB, whether you want multiple BU partitions there etc. IMHO, some of this stuff would be nice to have, but of course someone would have to implement it first :) Gru, Uli pgpg6zGPhdvTy.pgp Description: PGP signature
[leaf-devel] Another new developer
Hi developers! Mike Noyes was so kind and added me to the developers. I have been using LEAF Bering uClibc on an old 486 from floppy for several years, but recently built myself a cute little router box (see http://n-dimensional.de/projects/router/ :) for which I had to build me a few packages. A suggestion here, and a patch there, and soon Mike kindly offered me developer status. I'm planning mainly to maintain the aiccu package, fix little obvious things and otherwise keep out of the way :) For more information about myself, browse n-dimensional.de, see my sourceforge developer page and ask your favourite search engine about my full name. Gru, Uli pgpdyAlerowt7.pgp Description: PGP signature
