Re: LFS-Bootscripts 20070730
Dan Nicholson wrote: I rolled a new snapshot that has a few changes since the last 20070420 tarball. Please test it out so we can get any fixes in to 6.3. They should be entirely backwards compatible with existing scripts. Hiya. I maybe should know where to look, but I don't... Where is the download location for the new LFS-bootscripts you rolled? greets, jens -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Bootscripts 20070730
Jens Stroebel wrote: I maybe should know where to look, but I don't... Where is the download location for the new LFS-bootscripts you rolled? http://downloads.linuxfromscratch.org/lfs-bootscripts-20070730.tar.bz2 -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Udev USB device class links
On 7/26/07, Dan Nicholson [EMAIL PROTECTED] wrote:
On 7/26/07, Matthew Burgess [EMAIL PROTECTED] wrote:
On Thu, 26 Jul 2007 09:17:52 -0700, Dan Nicholson [EMAIL PROTECTED]
wrote:
On 7/26/07, Dan Nicholson [EMAIL PROTECTED] wrote:
The 2.6.22 kernel (maybe 2.6.21 too, didn't check) has an option
CONFIG_USB_DEVICE_CLASS that's marked as deprecated. The help text
states that it is unnecessary if the following udev rule is used:
SUBSYSTEM==usb, ACTION==add, ENV{DEVTYPE}==usb_device, \
NAME=bus/usb/$env{BUSNUM}/$env{DEVNUM}
I checked the SuSE rules in udev-111, and this is in addition to the
existing usb_device rule:
SUBSYSTEM==usb_device, PROGRAM=/bin/sh -c 'X=%k; X=$${X#usbdev};
B=$${X.*} D=$${X#*.}; echo bus/usb/$$B/$$D', NAME=%c
Does anyone have a problem if I add that to our rules?
Actually, it seems that they're the same rule, but the kernel no
longer supplies the usb_device subsystem is removed in 2.6.22. Here's
a relevant bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248916#c10
So, the new rule can replace the old one depending on whether
CONFIG_USB_DEVICE_CLASS is set. I think both rules should be there so
that our rules stay compatible whether this setting is Y or N. Also,
leaving the older rule there means you get /dev/bus/usb nodes if you
run an older kernel.
I'm not sure we need both rules. If CONFIG_USB_DEVICE_CLASS=n, the new
rule will take effect. If CONFIG_USB_DEVICE_CLASS=y, whichever of the
NAME= rules is hit first will take effect, if my understanding of Udev rule
evaluation is correct. Therefore, if the new rule is placed above the
existing one, the existing one then becomes entirely redundant.
This is where I'm a little unsure. I believe if
CONFIG_USB_DEVICE_CLASS=y, then there won't be anything that matches
SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device. In that case, the new
rule would be useless. But I'm not sure about that since I'm not
actually running 2.6.22 (in the process of rebasing my .config).
I built a kernel with and without CONFIG_USB_DEVICE_CLASS=y, and the
rule works in both situations. It works fine with both. The only
difference if you have it set to y is that you get /dev/usbdev?.?
nodes (in addition to the endpoint _ep?? ones) and
/sys/class/usb_device paths.
Now to fix up the equivalent rule on the libusb page in BLFS.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
udev-config 20070731
New snapshot of the udev rules. Not much has changed since the previous version, ChangeLog below. One significant difference is a non-backwards compatible change in the usb_device rules to work with Linux-2.6.22+. This means you won't get /dev/bus/usb nodes unless you're running a current kernel. Bryan also added rules for DVBs and extra floppy types. Please test this out as I've merged it into the 6.3 branch. http://downloads.linuxfromscratch.org/udev-config-20070731.tar.bz2 Changes since the last snapshot (beware gmail formatting): 2007-07-31 Dan Nicholson [EMAIL PROTECTED] * 25-lfs.rules: Changed the usb_device rule tto create /dev/bus/usb nodes if the usb_device in 2.6.22+ kernels. The rule was also changed to only trigger on add events. This change is not backwards compatible with older kernels. 2007-06-12 Dan Nicholson [EMAIL PROTECTED] * 25-lfs.rules: Fix the CPUID nodes from cpu/%n/cpu to cpu/%n/cpuid, which is what's expected in userspace apps such as x86info. 2007-06-08 Bryan Kadzban [EMAIL PROTECTED] * 25-lfs.rules: Add rules for DVB devices (create nodes in /dev/dvb/) and floppies (create extra nodes based on CMOS type), copied from the SuSE rules file. Thanks to Alexander Patrakov for the bugreport. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Bootscripts 20070730
On Mon, Jul 30, 2007 at 02:48:03PM -0700, Dan Nicholson wrote: I rolled a new snapshot that has a few changes since the last 20070420 tarball. Please test it out so we can get any fixes in to 6.3. They should be entirely backwards compatible with existing scripts. On Tue, Jul 31, 2007 at 12:24:54PM +, DJ Lucas wrote: Jens Stroebel wrote: I maybe should know where to look, but I don't... Where is the download location for the new LFS-bootscripts you rolled? http://downloads.linuxfromscratch.org/lfs-bootscripts-20070730.tar.bz2 -- DJ Lucas Thanks for the URL; as far as I can tell, everything boots flawlessly; there is one thing I did leave out because of local deviation from the book: we took care to have our loglevel set here before that got into the lfs-bootscripts package, so I didn't check that it behaves like planned via an entry in /etc/sysconfig/console. Everything else seems to be perfectly happy with the new boot scripts, including the bootscripts which derive from blfs packages (they do use the functions of lfs bootscripts, right?). greets, jens -- [EMAIL PROTECTED] 23.56...drifting ``The lyf so short, the craft so long to lerne.'' - Chaucer pgp7tCgXiu5EE.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Bootscripts 20070730
On 7/31/07, Jens Stroebel [EMAIL PROTECTED] wrote: as far as I can tell, everything boots flawlessly; there is one thing I did leave out because of local deviation from the book: we took care to have our loglevel set here before that got into the lfs-bootscripts package, so I didn't check that it behaves like planned via an entry in /etc/sysconfig/console. OK. I suppose as long as you just leave the default LOGLEVEL, you'll have the same behavior as before and you can set it how you like. Everything else seems to be perfectly happy with the new boot scripts, including the bootscripts which derive from blfs packages (they do use the functions of lfs bootscripts, right?). Yep. There is still some behavior w.r.t. PIDs and pifiles that I think could be improved. However, it's late in the game now, and I don't want to introduce any regressions. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev-config 20070731
El Martes, 31 de Julio de 2007 16:07, Dan Nicholson escribió: http://downloads.linuxfromscratch.org/udev-config-20070731.tar.bz2 I think that the book URLs to download both lfs-bootscripts and udev-config should be changed to use http://downloads.linuxfromscratch.org. It's neutral and should work for all books. Right now in both 6.3-rc1 and 6.3 branch that URL are hardcoded in packages.ent to http://www.linuxfromscratch.org/lfs/downloads/development/, that is not kosher. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev-config 20070731
On 7/31/07, M.Canales.es [EMAIL PROTECTED] wrote: El Martes, 31 de Julio de 2007 16:07, Dan Nicholson escribió: http://downloads.linuxfromscratch.org/udev-config-20070731.tar.bz2 I think that the book URLs to download both lfs-bootscripts and udev-config should be changed to use http://downloads.linuxfromscratch.org. It's neutral and should work for all books. I don't really mind if we do that, but downloads.lfs.org is missing the numbered releases, e.g. udev-config-6.2.tar.bz2. I'd actually prefer if there were independent version numbers for lfs-bootscripts and udev-config and they weren't matched to the LFS version number, but that's a separate topic. Right now in both 6.3-rc1 and 6.3 branch that URL are hardcoded in packages.ent to http://www.linuxfromscratch.org/lfs/downloads/development/, that is not kosher. Possibly, but the above is just temporarily broken. It should point to this: http://www.linuxfromscratch.org/lfs/downloads/6.3-rc1/ or something similar. The tagging process just missed a few entities that need to be changed when going to release. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Plans for LFS-6.3
Dan Nicholson wrote: I would like to allow glibc-2.5.1 through a freeze if it happens. That should be safe since we've been moving the snapshot along. New Glibc's are now up. Regards Greg -- 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: Plans for LFS-6.3
On 7/31/07, Greg Schafer [EMAIL PROTECTED] wrote: Dan Nicholson wrote: I would like to allow glibc-2.5.1 through a freeze if it happens. That should be safe since we've been moving the snapshot along. New Glibc's are now up. Thanks, Greg. Was there no announcement? -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Is 6.3 ready for release?
On 7/30/07, Dan Nicholson [EMAIL PROTECTED] wrote: On 7/30/07, Bruce Dubbs [EMAIL PROTECTED] wrote: I put out a 6.3-rc1 a week ago and there really has been very little feedback. Is it ready for final release? Let me spin new tarballs for lfs-bootscripts and udev-config. I'll make an announcement on lfs-dev and ask people to test them out. I took care of the udev rules and lfs-bootscripts. Next: glibc-2.5.1 out just in time :) There's only been one real commit (a bug fix in printf) since the last branch_update patch, so it should be straightforward. I ran the testsuite and still had only the single failure in nptl/tst-cancel1. Haven't bootstrapped anything. I'm prepping a diff now. Give me a day or so to get that in and try to go throught Ken's points. Then we can roll -rc2 and let it gestate a little. Sound good? -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Is 6.3 ready for release?
On 7/30/07, Ken Moffat [EMAIL PROTECTED] wrote: Tar is repeatedly failing '26: incremental' for me, looks like a regression. But nobody else has commented. If you have any idea how to narrow this down, that'd be great. I have hit this before myself, and it seems like a race condition, but I can't say for sure. I haven't run the full range of tests on all the packages in a while. At worst, we can add a note that this test fails sometimes. The bash failure I reported was a fubar in my script (trying to chown the test log so it was writable by the appropriate user, but before it was created ;). But, my second run did seem to have one failure - 'run-test' shows 152c152 1 --- 0 158c158 1 --- 0 - as to what that means, your guess is as good as mine. The perl failure didn't happen on the second run, I guess it's just another unreliable test. And the vim test failure is totally impenetrable. Don't know about any of those. I don't really bother reading the results of the vim tests. And moving on to farce test results (how repeatable is it?) - apart from cc1 and cc1plus I also had a failure in libc-2.5.so (not yet investigated) and in private mail from archaic I know he saw a failure in nscd (I've got his files for this, but haven't investigated it yet). libc.so and nscd both embed the build date. $ strings /lib/libc.so.6 | grep 2007 Compiled on a Linux 2.6.20.14-1 system on 2007-07-15. $ strings /usr/sbin/nscd | grep 2007 Jul 15 2007 08:44:08 Although, I though farce tried to strip out the dates, so maybe it's something worse. If you want to be sure about the nscd one, you can just blow away the __DATE__ and __TIME__ macros: sed -i.bak \ -e 's/__DATE__/today/' \ -e 's/__TIME__/now/' nscd/nscd_stat.c He also noted in that mail that coreutils seems to be using a pre-created info file in his second and third builds - (I've only run two, and misread the diff : coreutils.info was created by makeinfo version 4.9 in the first build, and 4.8 in the second). But, we don't expect user to build it twice, so I'm not too worried about that, I just add it to my coreutils Makefile is a POS thoughts :-) That sucks, but at least it's not critical. Which only leaves space/SBU measurements. Because my build hasn't been by-the-book, and has run tests whenever possible, I'll only comment on those I know look wrong (chapter 6 only) I'll try to get jhalfs to spit some numbers to me and see if they agree. Now, time for me to ask a question: Is it worthwhile that we continue to record SBUs and space ? Everybody knows that many packages take longer to build and use more space whenever the toolchain is upgraded. Is it really worthwhile to be so exact about the time and space. Certainly, space should be constant across an architecture (well, i686 anyway) for a given toolchain, but the timings depend greatly on amount of memory (do you hit swap?), memory speed (try using a via processor), and disk speed. I guess I just like to know how things are gonna shape up relatively. I.e., gcc's gonna take a while, no sense in watching the screen. I don't care if the numbers aren't accurate. But people using older hardware may be more interested in the readings. I suppose one compromise would be less precision. I.e., round to the nearest MiB or integer SBU. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Is 6.3 ready for release?
On Tue, Jul 31, 2007 at 03:50:53PM -0700, Dan Nicholson wrote: On 7/30/07, Ken Moffat [EMAIL PROTECTED] wrote: Tar is repeatedly failing '26: incremental' for me, looks like a regression. But nobody else has commented. If you have any idea how to narrow this down, that'd be great. I have hit this before myself, and it seems like a race condition, but I can't say for sure. I haven't run the full range of tests on all the packages in a while. At worst, we can add a note that this test fails sometimes. Greg's reply pointed out that both 26 and 29 have been seen to sometimes fail. He suggested it might need 'sleep' added to the testsuite (in which case, yet another broken testsuite). I'm ok with adding tests 26 and 29 sometimes fail, but then I'm equally ok with adding a more general occasional failures in the testsuites are probably nothing to worry about. The trouble with that get-out is its use of language: to me, the text about the ignored failure in glibc is clear, but people have problems with it. Adding a comment that says probably ok will be a pain when every other builder starts asking do I need to worry? The real problem is that test failures _sometimes_ indicate a problem. Mostly (talking generally, not x86-specific) they seem to indicate that the testsuite is not perfect. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Is 6.3 ready for release?
Dan Nicholson wrote: On 7/30/07, Dan Nicholson [EMAIL PROTECTED] wrote: On 7/30/07, Bruce Dubbs [EMAIL PROTECTED] wrote: I put out a 6.3-rc1 a week ago and there really has been very little feedback. Is it ready for final release? Let me spin new tarballs for lfs-bootscripts and udev-config. I'll make an announcement on lfs-dev and ask people to test them out. I took care of the udev rules and lfs-bootscripts. Next: glibc-2.5.1 out just in time :) There's only been one real commit (a bug fix in printf) since the last branch_update patch, so it should be straightforward. I ran the testsuite and still had only the single failure in nptl/tst-cancel1. Haven't bootstrapped anything. I'm prepping a diff now. Give me a day or so to get that in and try to go throught Ken's points. Then we can roll -rc2 and let it gestate a little. Sound good? Yes, that sounds fine. Let me know when you think -rc2 should be released. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[Fwd: List messages rejected]
Original Message Subject: List messages rejected Date: Tue, 31 Jul 2007 13:50:31 -0700 (PDT) From: David Olsson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi. Sorry to trouble you. My messages to the list are being held and rejected. The last one, my own copy below, was held because, Message has a suspicious header. Can you help me? I'd like to participate in BLFS. Thanks. David Easthampton, MA - Rejected Message From David Olsson Sun Jul 29 18:08:38 2007 Received: from [68.142.200.245] by web31814.mail.mud.yahoo.com via HTTP; Sun, 29 Jul 2007 18:08:38 PDT Date: Sun, 29 Jul 2007 18:08:38 -0700 (PDT) From: David Olsson [EMAIL PROTECTED] Subject: dhcpcd not stopped by ifdown To: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=0-912148289-1185757718=:75736 Content-Length: 1540 I noticed '/etc/rc.d/init.d/network stop' does not kill dhcpcd on my BLFS system. For example if I 'telinit 1', then 'telinit 3' I get a fat error message that tells me I shouldn't be seeing the message and dhcpcd was already running and oh my please tell the BLFS maintainers about it. I traced it to the script /etc/sysconfig/network-devices/services/dhcpcd. I seem to have an infinite lease time and hence my dhcp client is supposed to have exited when it started. But it didn't. I don't see in the dhcpcd man page that it should. Following is the script code in question. Should we eliminate the check for infinite lease time? CODE boot_mesg -n Stopping dhcpcd on the $1 interface... # Do nothing with the client daemon if we have an infinate # lease time as the client exits when started in this case, # just echo OK. if [ -e $LEASEINFO ] then . $LEASEINFO if [ $LEASETIME = 4294967295 ] then # do nothing, just echo ok echo echo_ok else if [ -n $DHCP_STOP ] then /CODE In the current setup and for a normal shutdown, we're actually better off that the script didn't kill dhcpcd. You see, the script would kill with 'dhcpcd -k'. That destroys the ip address cache, so we're less likely to obtain the same address next time. If shutdown sends sigterm to dhcpcd, the cache is preserved. So, when we DO shut down dhcpcd, we should send it sigterm, not issue 'dhcpcd -k'. I guess that's what killproc() would do, so we could probably just not set DHCP_STOP in ifconfig.eth0/dhcpcd. ~David ~Easthampton, MA -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Optional editline dependencies [Was Re: r6993 - in trunk/BOOK: . introduction/welcome postlfs/shells]
Dan Nicholson wrote: On 7/31/07, Ag. D. Hatzimanikas [EMAIL PROTECTED] wrote: For reference this is what installed with libedit. root:root 755 160628 /usr/lib/libedit.so.0.0.24 root:root 755 809 /usr/lib/libedit.la root:root 644 181584 /usr/lib/libedit.a root:root 644 18612 /usr/share/man/man3/editline.3 root:root 644 12594 /usr/share/man/man5/editrc.5 root:root 644 6771/usr/include/editline/readline.h root:root 644 6442/usr/include/histedit.h Do you think that maybe there is a conflict? There isn't a file conflict with readline. The conflict is that we (presumably) prefer readline when it's offered. Say I go to install dash, see the optional editline dependency and install that. Everything's great. Now I go to install xfsprogs and it will accept readline or editline but it takes editline by default (hypothetically, haven't checked). I've deviated from the book without knowing it. If I hit a bug here, it will be hard to debug since it will be hard to ask the right questions (are you using readline or editline?). Do we have to test every of the aforementioned packages, just to include the libedit (even as optional) dependency in Dash? I don't think we need to test them. We need to find out if they take editline in addition to readline. If they do, we need to ensure that readline is used. If this is the case, then we have to remove it for the time being. Let's see what others have to say. I think the policy of omitting editline is valid, but if we do decide to add it as optional dependencies, we should also add a caution that in some cases editline conflicts with readline (which is installed in LFS). -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: udev-config 20070731
On 7/31/07, Dan Nicholson [EMAIL PROTECTED] wrote: On 7/31/07, M.Canales.es [EMAIL PROTECTED] wrote: Right now in both 6.3-rc1 and 6.3 branch that URL are hardcoded in packages.ent to http://www.linuxfromscratch.org/lfs/downloads/development/, that is not kosher. Possibly, but the above is just temporarily broken. It should point to this: http://www.linuxfromscratch.org/lfs/downloads/6.3-rc1/ or something similar. The tagging process just missed a few entities that need to be changed when going to release. You were right, it was hard-coded. Stopgap solution: http://linuxfromscratch.org/pipermail/lfs-book/2007-July/021233.html It still requires that some editor copies the tarballs to the correct location for releases. We can still talk about just using downloads.linuxfromscratch.org directly. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
