Re: RFC - Raw Kernel Headers
On Wednesday 08 March 2006 04:21, Jim Gifford wrote: available at http://ftp.jg555.com/headers/headers. You can replace the long sed with the following: -e 's/\bu8/__u8/g' \ -e 's/\bu16/__u16/g' \ -e 's/\bu32/__u32/g' \ -e 's/\bu64/__u64/g' \ -e 's/\bs8/__s8/g' \ -e 's/\bs16/__s16/g' \ -e 's/\bs32/__s32/g' \ -e 's/\bs64/__s64/g' \ -e 's/\b__iomem//g' \ That should be more or less equivalent, as it matches all of \tu8 u8 (u8 ,u8 u8 Or am I missing something? Florian -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
On Monday 13 March 2006 16:10, Florian Schanda wrote: On Wednesday 08 March 2006 04:21, Jim Gifford wrote: available at http://ftp.jg555.com/headers/headers. You can replace the long sed with the following: -e 's/\bu8/__u8/g' \ -e 's/\bu16/__u16/g' \ -e 's/\bu32/__u32/g' \ -e 's/\bu64/__u64/g' \ -e 's/\bs8/__s8/g' \ -e 's/\bs16/__s16/g' \ -e 's/\bs32/__s32/g' \ -e 's/\bs64/__s64/g' \ -e 's/\b__iomem//g' \ Or even better/shorter: -e 's/\b[us]\(8\|16\|32\|64\)/__/g' \ -e 's/\b__iomem//g' \ Florian -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
irmp3 fails in configure, Perl issue?
I am trying to install irmp3 on my HLFS system.
The same source package installs fine on a Knoppix 3.8 system, but I can't
get it past the configure step on the HLFS system. Syntax errors in the
configure prevent it from completing, or so it says. Since it works on the
Knoppix system and Google tells me I stand alone with the produced error,
something else is going on. Presumably something fishy in my Perl
configuration. (or lack thereof)
Still, at first I tried editing the configure script, but it seems I just
lack the proper Perl knowledge to pull that off. One syntax error is
followed by another and finally configure complains about a proper End of
File. After that I tried to use the Makefile that was configured on the
Knoppix system, but that isn't really going to get me anywhere as well, it
seems. There are just too many wrong code locations in the various
Makefiles.
Although I would enjoy just having irmp3 functioning, I think it is best to
try and figure out why the configure script cannot be run on my HLFS system.
The first configure error I receive is this one:
..snip
checking for strtol... yes
configure: checking internal module dependencies...
./configure: line 7163: syntax error near unexpected token `('
./configure: line 7163: `case `(ac_space=' '; set | grep ac_space) 21`
in'
The line it complains about looks like this::
# The following way of writing the cache mishandles newlines in values,
# but we know of no workaround that is simple, portable, and efficient.
# So, don't put newlines in cache variables' values.
# Ultrix sh set writes to stderr and can't be redirected directly,
# and sets the high bit in the cache file unless we assign to the vars.
{
(set) 21 |
case `(ac_space=' '; set | grep ac_space) 21` in
*ac_space=\ *)
I tried removing the ` characters, which sort of made the compile errors go
away.
So, should I be worried about some sort of Perl issue, or... ?
Warren
_
On the road to retirement? Check out MSN Life Events for advice on how to
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
On Mon, Mar 13, 2006 at 04:39:11PM +, Florian Schanda wrote: On Monday 13 March 2006 16:10, Florian Schanda wrote: On Wednesday 08 March 2006 04:21, Jim Gifford wrote: available at http://ftp.jg555.com/headers/headers. You can replace the long sed with the following: -e 's/\bu8/__u8/g' \ -e 's/\bu16/__u16/g' \ -e 's/\bu32/__u32/g' \ -e 's/\bu64/__u64/g' \ -e 's/\bs8/__s8/g' \ -e 's/\bs16/__s16/g' \ -e 's/\bs32/__s32/g' \ -e 's/\bs64/__s64/g' \ -e 's/\b__iomem//g' \ Or even better/shorter: -e 's/\b[us]\(8\|16\|32\|64\)/__/g' \ -e 's/\b__iomem//g' \ Why not use \ (start of word anchor) instead of \b (whatever \b is)? pgpGxCHsKkwM4.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
On Monday 13 March 2006 17:37, Bryan Kadzban wrote: Why not use \ (start of word anchor) instead of \b (whatever \b is)? Haven't seen \ yet, but I think its the same as \b (word boundary). Florian -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: irmp3 fails in configure, Perl issue?
I tried 0.5.6 as well as 0.5.7-pre1. Both have syntax errors while running configure, although at different lines. Version 0.5.6 comes with a default Makefile, which I can use to build irmp3, but then it lacks the Lirc module ( linux infrared ) so that's no good. Broken flac support doesn't sound good to me, so I didn't try the 0.5.7-pre2 version. From: Jeremy Huntwork [EMAIL PROTECTED] Reply-To: Hardened LFS Development List hlfs-dev@linuxfromscratch.org To: Hardened LFS Development List hlfs-dev@linuxfromscratch.org Subject: Re: irmp3 fails in configure, Perl issue? Date: Mon, 13 Mar 2006 12:36:45 -0500 Warren Wilder wrote: I am trying to install irmp3 on my HLFS system. What version of irmp3? -- JH -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
Florian Schanda wrote:
You can replace the long sed with the following:
-e 's/\bu8/__u8/g' \
-e 's/\bu16/__u16/g' \
-e 's/\bu32/__u32/g' \
-e 's/\bu64/__u64/g' \
-e 's/\bs8/__s8/g' \
-e 's/\bs16/__s16/g' \
-e 's/\bs32/__s32/g' \
-e 's/\bs64/__s64/g' \
-e 's/\b__iomem//g' \
That should be more or less equivalent, as it matches all of
\tu8
u8
(u8
,u8
u8
Or am I missing something?
It also matches -u{8,16,32,64} and changes them to __u{8,16,32,64}
Andy
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Alphabetical Build Clean [Was Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch]
Jeremy Huntwork wrote: I'll add the order changes you made to the alphabetical branch - hopefully today. The only thing left is to get Chris' dependency documentation in as well. Sorry for the lateness on this. The changes are in now, and as usual, the book is rendered here: http://linuxfromscratch.org/~jhuntwork/lfs-alphabetical/ -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
Andrew Benton wrote: cat $header | sed -e 's/\( \|(\|,\|\t\)\([us]\)\(8\|16\|32\|64\)/\1__\2\3/g' \ -e 's/\( \|(\|,\|\t\)__iomem /\1/g' \ -e '/#include linux.config.h/d' \ -e 's/#ifdef linux/#ifdef __linux__/g' \ -e 's/#ifndef linux/#ifndef __linux__/g' \ $header.orig Yes, but why the need for cat and a pipe? sed -e ... $header $header.orig -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
Andrew Benton wrote:
Florian Schanda wrote:
You can replace the long sed with the following:
-e 's/\bu8/__u8/g' \
-e 's/\bu16/__u16/g' \
-e 's/\bu32/__u32/g' \
-e 's/\bu64/__u64/g' \
-e 's/\bs8/__s8/g' \
-e 's/\bs16/__s16/g' \
-e 's/\bs32/__s32/g' \
-e 's/\bs64/__s64/g' \
-e 's/\b__iomem//g' \
That should be more or less equivalent, as it matches all of
\tu8
u8
(u8
,u8
u8
Or am I missing something?
It also matches -u{8,16,32,64} and changes them to __u{8,16,32,64}
This works
cat $header | sed -e 's/\(
\|(\|,\|\t\)\([us]\)\(8\|16\|32\|64\)/\1__\2\3/g' \
-e 's/\( \|(\|,\|\t\)__iomem /\1/g' \
-e '/#include linux.config.h/d' \
-e 's/#ifdef linux/#ifdef
__linux__/g' \
-e 's/#ifndef linux/#ifndef
__linux__/g' \
$header.orig
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
Andrew Benton wrote:
It also matches -u{8,16,32,64} and changes them to __u{8,16,32,64}
Hrm. Check this again. Are the '-u{8,16,32,64}' matches perhaps diffs of
existing lines of 'u{8,16,32,64}' being removed the better sed? I think
Jim's original seds didn't get all of them and now Florian's proposal
catches some that Jim didn't and you're seeing '-u...' in the diffs.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
FYI - New Version up, thank you all for your help. Also a make shift changelog is now up http://ftp.jg555.com/headers/changelog -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
Florian Schanda wrote:
On Monday 13 March 2006 21:56, Jeremy Huntwork wrote:
Andrew Benton wrote:
It also matches -u{8,16,32,64} and changes them to __u{8,16,32,64}
Hrm. Check this again. Are the '-u{8,16,32,64}' matches perhaps diffs of
existing lines of 'u{8,16,32,64}' being removed the better sed? I think
Jim's original seds didn't get all of them and now Florian's proposal
catches some that Jim didn't and you're seeing '-u...' in the diffs.
I am somewhat confused. I grepped for -u8 in the kernel, and found nothing...
Besides, since its C we are talking about: - is a operator and can't be part
of variable names or type names.
Doh! Yes, my bad, the - was from the diff, the u was at the start of the
line so Florian's construct is the better one as it catches things at
the start of the line, like these in linux/ethtool.h
/* Some generic methods drivers may use in their ethtool_ops */
u32 ethtool_op_get_link(struct net_device *dev);
u32 ethtool_op_get_tx_csum(struct net_device *dev);
int ethtool_op_set_tx_csum(struct net_device *dev, __u32 data);
int ethtool_op_set_tx_hw_csum(struct net_device *dev, __u32 data);
u32 ethtool_op_get_sg(struct net_device *dev);
int ethtool_op_set_sg(struct net_device *dev, __u32 data);
u32 ethtool_op_get_tso(struct net_device *dev);
Andy
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
Florian Schanda wrote: Or even better/shorter: -e 's/\b[us]\(8\|16\|32\|64\)/__/g' \ -e 's/\b__iomem//g' \ This is good because it also catches s32 It could be improved (only slightly) by putting a space behind the __iomem like so -e 's/\b[us]\(8\|16\|32\|64\)/__/g' \ -e 's/\b__iomem //g' \ Thanks for the lesson Florian Andy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
Andrew Benton wrote: This is good because it also catches s32 It could be improved (only slightly) by putting a space behind the __iomem like so -e 's/\b__iomem //g' \ That would miss a few of the iomem's. Let's look at this a little closer, I'm all for optimize the script. It's dog slow as it is. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers -- Comparison Script Added
Just added a compare script. That will compare the difference between the raw_headers produced with the headers script compared to the headers in llh. The bad news is only will work with the 2.6.12 headers, since there isn't a new release. Usage is ./compare 2.6.12 2.6.12.0 Raw LLH Thank you all for your help -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Fixing libexif if Doxygen isn't present
There's a bug in libexif-0.6.13 where `make install' bombs if you don't have Doxygen installed. It's just poor packaging. You can read about the details in #1785: http://wiki.linuxfromscratch.org/blfs/ticket/1785 The solution I'm using is this sed: sed -i 's/^install-data-local/@HAVE_DOXYGEN_TRUE@/' doc/Makefile.in Please let me know if you think this is bogus or have any issues with it. I will be adding it to the book otherwise. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
Andrew Benton wrote: /* Some generic methods drivers may use in their ethtool_ops */ u32 ethtool_op_get_link(struct net_device *dev); u32 ethtool_op_get_tx_csum(struct net_device *dev); int ethtool_op_set_tx_csum(struct net_device *dev, __u32 data); int ethtool_op_set_tx_hw_csum(struct net_device *dev, __u32 data); u32 ethtool_op_get_sg(struct net_device *dev); int ethtool_op_set_sg(struct net_device *dev, __u32 data); u32 ethtool_op_get_tso(struct net_device *dev); These functions (in fact, all function declarations in kernel headers) are kernel-only and it is a good idea to remove them to avoid namespace clashes in userspace programs. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers -- Comparison Script Added
Jim Gifford wrote: Just added a compare script. That will compare the difference between the raw_headers produced with the headers script compared to the headers in llh. Jim, I've been working along similar lines. I'm getting the diff down all the time. I've included some stuff below which you might want to include in your script (or at least duplicate the logic of it). The changes are pretty much self-explanatory, but for the rationale you could say value added userspace tweaks copied from llh or something like that. Tho' I still think this self sanitizing caper by us amateurs is a bad idea.. Regards Greg for H in acct resource socket time un wait; do echo #if defined(__GNUC__) !defined(__STRICT_ANSI__) #warning \You should include sys/$H.h. This time I will do it for you.\ #endif #include sys/$H.h linux/$H.h done for H in signal utime; do echo #if defined(__GNUC__) !defined(__STRICT_ANSI__) #warning \You should include $H.h. This time I will do it for you.\ #endif #include $H.h linux/$H.h done for A in alpha arm26 arm i386 ia64 sh x86_64; do echo '#warning You should include sys/io.h. This time I will do it for you. #include sys/io.h ' asm-$A/io.h done for A in alpha i386 mips ppc64 s390 sh sparc64 sparc x86_64; do echo '#error asm/init.h should never be used - use linux/init.h instead' asm-$A/init.h done echo '#error Compilation aborted. Please read the FAQ for linux-libc-headers package. #error (can be found at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/doc/) ' linux/config.h echo '/* empty */' linux/compiler.h echo '#error Kernel only header included in userspace' linux/err_kernel_only.h linux/syscalls.h for H in autoconf bootmem elevator list mm mount pagemap percpu spinlock vmalloc; do echo '#include linux/err_kernel_only.h' linux/$H.h done for H in core driver; do echo '#include linux/err_kernel_only.h' sound/$H.h done -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers -- Comparison Script Added
Greg Schafer wrote: echo '/* empty */' linux/compiler.h Hmm... Is this really necessary? I've been running Alexander's tests (http://linuxfromscratch.org/pipermail/lfs-dev/2006-March/056159.html) on the output of Jim's script, and right now, it looks like include/linux/byteorder/swab.h is choking on __attribute_const__, which compiler.h nicely defines to empty for us. We could remove all the __attribute_const__ strings like we do __iomem, but why duplicate all that effort? (Of course, the removal of __iomem makes compiler.h fail to compile as well, since it defines __iomem to nothing. But removing the __iomem string just makes that line become #define , which gcc chokes on. I would think that in both cases, it'd be cleaner to add an #include linux/compiler.h instead of removing the offending string on our own. Unless there's some issue with linux/compiler.h that I don't see. That's entirely possible -- I'm a fairly decent C programmer, but I don't really have a great handle on the kernel.) signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Alphabetical Build Clean [Was Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch]
OK, I've got the dependency list done - http://linuxfromscratch.org/~chris/dependencies.txt. Probably still not complete, but it's about as close as I'll ever get. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Alphabetical Build Clean [Was Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch]
On 3/13/06, Chris Staub [EMAIL PROTECTED] wrote: OK, I've got the dependency list done - http://linuxfromscratch.org/~chris/dependencies.txt. Probably still not complete, but it's about as close as I'll ever get. Wow, that is impressive. I'll try to review these tomorrow with the info I have to make sure there aren't any glaring mistakes. Now for the editors to decide how this will be used... -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Udev bootscript and Ticket 1720 (was: Re: r7429)
DJ Lucas wrote:
Yes at least the echo is required.
Get to that in a moment. The loop is as well, but it's still undecided
according to the comments in the ticket. I'll be able to test at least
the loop doesn't do anything silly tonight, but I don't believe I have a
reliable way to reproduce the bug as my system is now.
I treat the ticket 1720 as presumably-closed if the bootscript changes
below are implemented, and the udev_update branch can be merged then.
This mail to lfs-dev is only to state this, and ask for discussion if
such discussion is needed (IMHO, it is not needed).
The status quo is:
1) Uevents that are triggered by echoing to sysfs uevent files are
processed by udev asynchronously. The end of the loop that does the
echo only means that the kernel has put all uevents into the netlink
socket buffer. There is absolutely no guarantee that udevd received them
all at that moment.
2) Therefore, upstream has the recommendation to wait for udevd to
process all these events, and all uevents raised as a consequence of
modprobe called from udev rules in response to earlier uevents.
Upstream provides a way to know if the udev queue (that is not the same
as in-kernel netlink socket buffer!) is empty, and proposes the
following shell script snippet:
udevd --daemon
mkdir -p /dev/.udev/queue
walk_sysfs
# until we know how to do better, just wait for _all_ events to finish
loop=300
while test -d /dev/.udev/queue; do
sleep 0.1
test $loop -gt 0 || break
loop=$(($loop - 1))
done
test $loop -gt 0
evaluate_retval
3) The shell script above does not work. Udev queue disappears for a
moment (because udevd has no way to know if there will be any further
uevents), and then reappears, but the loop thinks that it is done! So I
proposed an alternative loop that not only waits for the queue to
disappear, but retries several times in order to make sure that it
doesn't reappear again:
udevd --daemon
mkdir -p /dev/.udev/queue
walk_sysfs
# until we know how to do better, just wait for _all_ events to finish
loop=300
confirm=0
while true ; do
sleep 0.1
test -d /dev/.udev/queue confirm=0 || \
confirm=$(( $confirm + 1 ))
loop=$(( $loop - 1 ))
test $loop -gt 0 || break
test $confirm -lt 60 || break
done
test $loop -gt 0
evaluate_retval
Archaic says this produces much better results on his system.
4) It is imperative that we don't trust upstream (because they ignore
problem (3)), and do our own checking. In order to make sure that no
initial uevents escape the loop, compile the following simple event
recorder that adds the uevent contents to the /dev/bug file if the file
exists:
/* bug.c: Simple event recorder, gcc -o /lib/udev/bug bug.c */
#define _GNU_SOURCE
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
#include stdlib.h
#include argz.h
int main(int argc, char * argv[])
{
char * envz;
size_t len;
int bug;
bug = open(/dev/bug, O_WRONLY | O_APPEND);
if (bug == -1)
return 0;
setenv(_SEPARATOR, , 1);
argz_create(environ, envz, len);
argz_stringify(envz, len, '\n');
envz[len-1]='\n';
write(bug, envz, len);
close(bug);
free(envz);
return 0;
}
Add this rule to the separate file, 90-debug.rules:
ACTION==add, RUN+=bug
Add this shell script snippet to the udev bootscripts after the waiting
loop. This snippt checks if there are any uevents within 6 seconds from
the end of the loop. Assuming that the user doesn't plug devices in and
out during the boot process, such uevents indicate a bug in the waiting
loop.
.
test $confirm -lt 60 || break
done
/dev/bug
test $loop -gt 0
evaluate_retval
sleep 5
if test -s /dev/bug; then
mv /dev/bug /dev/bugreport
boot_mesg Please paste the /dev/bugreport file to ${WARNING}
boot_mesg http://wiki.linuxfromscratch.org/lfs/ticket/1720;
boot_mesg Otherwise, the next version of LFS may be
unbootable on your system!
echo_failure
sleep 10
else
rm -f /dev/bug
fi
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Udev bootscript and Ticket 1720
I wrote: . test $confirm -lt 60 || break done /dev/bug test $loop -gt 0 evaluate_retval sleep 5 if test -s /dev/bug; then I meant sleep 6, so that it is longer than any builtin kernel delay. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
