Re: lfs build-logs
On 7/26/07, Bruce Dubbs [EMAIL PROTECTED] wrote: We can go either way. My preference is to keep the succeeded to give the user just a little more comfort. As a minor side effect, it also introduces the user to the -o option of grep. Sounds good. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gcc make check
On 7/25/07, Bruce Dubbs [EMAIL PROTECTED] wrote: I was investigating the gcc-4.1.2 build and got the output below. What was surprising to me is that there were no unexpected failures. Should the comments in the book about expecting some failures be changed? IIRC, the last time I ran the 4.1.2 testsuite, I also had no failures. That wasn't during a bootstrap, though. Oh, I don't remember what happened with mudflap. Manuel, do you still have the test logs from the LFS jhalfs run you did the other day? -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gcc make check
On Thu, Jul 26, 2007 at 07:01:27PM +0200, M.Canales.es wrote: On the Pentium-IV machin I have no current testsuites logs right now. On the AMD64 machine I have the logs for a normal build, a 3-iterations build and a build using MAKEFLAGS=-j3. On all of them the results are identical: LAST_UPDATED: Obtained from SVN: tags/gcc_4_1_2_release revision 121944 Native configuration is i686-pc-linux-gnu [...] === g++ tests === Running target unix XPASS: g++.dg/tree-ssa/pr14814.C scan-tree-dump-times this 0 XPASS: g++.old-deja/g++.other/init5.C execution test [...] === libstdc++ tests === Running target unix XPASS: 26_numerics/cmath/c99_classification_macros_c.cc (test for excess errors) [...] The unique diference with Bruce's result are the 2 unexpected successes in gcc. I'm seeing exactly the same on an AMD64 running 32-bit and built from LFS-svn-2006-12-09 (gcc-4.1.1, ld-2.17, glibc-2.5), currently running kernel 2.6.22-rc1. Looking back at my packages from December, I can see that these were the standard versions of binutils and glibc, without any branch update patches. Running /lib/libc.so.6 in chroot shows '2.5' even though we have a branch update patch applied. As a matter of form, should we in future change how we produce branch_update patches so that there is some sort of date identifier produced when asking for the version, the way that most distros do ? ĸ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
more 6.3 test results
FWIW, my 'stamp' file (that's where I show that something was built, in case I have to restart, with time and space) for bash shows one or more tests failed, but I'll need to look at my script because I don't seem to have a log from the tests. And I forgot to mention earlier that vim shows 'test3 FAILED' - I noticed that the other day on a different platform, but the logs from vim's testsuite are indecipherable. ĸ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: gcc make check
El Jueves, 26 de Julio de 2007 18:28, Dan Nicholson escribió: IIRC, the last time I ran the 4.1.2 testsuite, I also had no failures. That wasn't during a bootstrap, though. Oh, I don't remember what happened with mudflap. Manuel, do you still have the test logs from the LFS jhalfs run you did the other day? On the Pentium-IV machin I have no current testsuites logs right now. On the AMD64 machine I have the logs for a normal build, a 3-iterations build and a build using MAKEFLAGS=-j3. On all of them the results are identical: LAST_UPDATED: Obtained from SVN: tags/gcc_4_1_2_release revision 121944 Native configuration is i686-pc-linux-gnu === g++ tests === Running target unix XPASS: g++.dg/tree-ssa/pr14814.C scan-tree-dump-times this 0 XPASS: g++.old-deja/g++.other/init5.C execution test === g++ Summary === # of expected passes 12408 # of unexpected successes 2 # of expected failures 66 # of unsupported tests 69 /sources/gcc-build/gcc/testsuite/g++/../../g++ version 4.1.2 === gcc tests === Running target unix XPASS: gcc.dg/cpp/cmdlne-dI-M.c scan-file (^|n)cmdlne-dI-M.*: [^n]*cmdlne-dI-M.c XPASS: gcc.dg/cpp/cmdlne-dM-M.c scan-file (^|n)cmdlne-dM-M[^n]*: [^n]*cmdlne-dM-M.c === gcc Summary === # of expected passes 38985 # of unexpected successes 2 # of expected failures 99 # of untested testcases 28 # of unsupported tests 246 /sources/gcc-build/gcc/xgcc version 4.1.2 === libmudflap tests === Running target unix === libmudflap Summary === # of expected passes 1799 === libstdc++ tests === Running target unix XPASS: 26_numerics/cmath/c99_classification_macros_c.cc (test for excess errors) === libstdc++ Summary === # of expected passes 3398 # of unexpected successes 1 # of expected failures 12 # of unsupported tests 324 The unique diference with Bruce's result are the 2 unexpected successes in gcc. -- 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: lfs build-logs
Dan Nicholson wrote: On 7/26/07, Bruce Dubbs [EMAIL PROTECTED] wrote: or just: grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log Greg has been using something like this in DIY, but he just checks for crt1.o. Also, you could match on the line that follows the succeeded line that just has the location: grep '^/usr/lib.*/crt[1in].o' dummy.log I didn't check that on a bootstrapped build, so I'm not sure it would list the same way when using /tools/bin/gcc. Either of these should be good. Is that what we really want or is it important (or just nice) to have the succeeded part in the output? We can go either way. My preference is to keep the succeeded to give the user just a little more comfort. As a minor side effect, it also introduces the user to the -o option of grep. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gcc make check
- Original Message - From: Bruce Dubbs [EMAIL PROTECTED] To: LFS Developers Mailinglist lfs-dev@linuxfromscratch.org Sent: Thursday, July 26, 2007 8:31 AM Subject: gcc make check I was investigating the gcc-4.1.2 build and got the output below. What was surprising to me is that there were no unexpected failures. Should the comments in the book about expecting some failures be changed? -- Bruce Hello Bruce. I had similar results with gcc-4.3.0-exp testsuite first (months ago) and last time I tried it (few days ago). I should have the testsuite log somewhere (I posted to Alexander first time I tried gcc-4.3.0), if interested I could search and post it here or as attachment. Luca -- 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 Thu, Jul 26, 2007 at 10:25:57AM -0600, Matthew Burgess 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)
Nope, that setting is only in 2.6.22. :-)
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}
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
Yeah, there's been some intermittent discussion on linux-hotplug-devel
about this. IIRC, the usb_device class doesn't exist anymore, and some
other part of the USB stuff creates those devices now. (The real USB
device? The USB interface? Not quite sure.)
As Kay said in that bug, the old method had some unfixable race
conditions; that's why it got removed (when that kernel option is
disabled, anyway).
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.
As long as 2.6.22 kernels provide the $DEVTYPE / $BUSNUM / $DEVNUM
values when CONFIG_USB_DEVICE_CLASS is enabled, then that's true. I
don't know whether they do, though. I'm still running 2.6.21.3; Dan, if
you're running 2.6.22.x with the USB device class stuff on, can you see
whether the new rule will work?
I understand that someone running an older kernel would need the old
rule, but then we don't officially support running older versions of
any of our packages
Agreed. If 2.6.22 provides the above environment variables no matter
what CONFIG_USB_DEVICE_CLASS is set to, then yank the old rule out.
Especially since it's really really ugly... ;-)
pgpsySZsVdSv3.pgp
Description: PGP signature
--
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, 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).
So, as Bryan said, it depends on whether the environment variables are
still set in the event that CONFIG_USB_DEVICE_CLASS=y. Looking at the
code in drivers/usb/core/devio.c, I think it is. I think all that
happens is that you get the usbdev devices in addition to the normal
routine. OK, I'm pretty sure that the DEVTYPE variable will be filled
regardless of that CONFIG setting.
I understand that someone running an older kernel would need the old rule,
but then we don't officially support running older versions of any of our
packages (as it's not in an official, tested release) let alone something as
critical as the kernel.
Yeah, I guess I don't really care too much about being backwards
compatible with kernels.
--
Dan
--
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:
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.
Thoughts?
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Udev USB device class links
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?
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
gcc make check
I was investigating the gcc-4.1.2 build and got the output below. What was surprising to me is that there were no unexpected failures. Should the comments in the book about expecting some failures be changed? -- Bruce $ ../gcc-4.1.2/contrib/test_summary|grep -A7 Summ === g++ Summary === # of expected passes12408 # of unexpected successes 2 # of expected failures 66 # of unsupported tests 69 /usr/src/gcc/gcc-build/gcc/testsuite/g++/../../g++ version 4.1.2 -- === gcc Summary === # of expected passes38985 # of expected failures 101 # of untested testcases 28 # of unsupported tests 246 /usr/src/gcc/gcc-build/gcc/xgcc version 4.1.2 -- === libmudflap Summary === # of expected passes1799 === libstdc++ tests === Running target unix XPASS: 26_numerics/cmath/c99_classification_macros_c.cc (test for excess errors) -- === libstdc++ Summary === # of expected passes3398 # of unexpected successes 1 # of expected failures 12 # of unsupported tests 324 Compiler version: 4.1.2 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
6.3 test results
This build isn't exactly by the book (my normal UTF-8 variations - I want to keep this one long-term, I'll do a by-the-book build later) but I noticed the following from my test logs - 1. coreutils has a RUN_VERY_EXPENSIVE_TESTS option - seems to guard two 'assert' tests, I have no idea if it is worth doing and I don't have time to look! 2. perl failed 1 test out of 930 - ext/IO/t/io_sock : FAILED--expected 26 tests, saw 11 I can remember people sometimes seeing perl failures in the past, but this is a first time for me with 5.8.8. 3. tar failed 26: incremental. This is different from the failure seen in unpatched 1.17, and new to me (I was building 1.18 on ppc debian (etch) this afternoon to check if I had everything I needed there, and that had no failures). Maybe these are one-offs, in which case everyone can forget about them. I'll try an in-place rebuild from 2.6.22.1 in the next few days. Meanwhile, please shout if you also see these ;-) ĸ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: lfs build-logs
Jeremy Huntwork wrote:
Also, for a while now, the gcc dummy tests have not been totally
accurate for one section. This command ends up producing a lot more
output than the book says it will:
grep -o '/usr/lib.*/crt[1in].* .*' dummy.log
Should we refine the above command or the expectd output?
I'm trying to figure out how to modify the pattern. We are getting:
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../crt1.o
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/crtbegin.o
-L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2
-L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2
-L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../.. /tmp/ccsdiSZO.o
--verbose -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed
-lgcc_s --no-as-needed /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/crtend.o
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../crtn.o
(One line, wrapped)
in addition to our desired output.
How about:
grep -o -E '/usr/lib.*/crt[1in].* .{5,20}$' dummy.log
or just:
grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
even shorter, but more obscure:
grep -o '/usr/lib.*/crt[1in].*d$' dummy.log
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Totem Movie Player
Hi all, I was playing around with Totem and discovered in this version of GNOME, the default backend is GStreamer instead of Xine. I popped a disc in the drive and Totem comes back and says that the required plugin is not available and aborts playing the movie. I'm guessing that Totem needs the FFMpeg plugin to decode movie files on DVD. This is just a guess. Can anyone confirm this? I've got the Base, Good and Ugly plugins installed to GStreamer now. Anyway, I rebuilt Totem specifying Xine as the backend, and it plays the movie as it should. I'd like to mention the appropriate stuff on the Totem page, as I'm thinking most folks will want to view movies if they install Totem. Who's got it all working with the GStreamer back-end? -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 12:48:00 up 14 days, 5:55, 1 user, load average: 0.22, 0.06, 0.01 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Totem Movie Player
On 7/26/07, Randy McMurchy [EMAIL PROTECTED] wrote: I was playing around with Totem and discovered in this version of GNOME, the default backend is GStreamer instead of Xine. I popped a disc in the drive and Totem comes back and says that the required plugin is not available and aborts playing the movie. I'm guessing that Totem needs the FFMpeg plugin to decode movie files on DVD. This is just a guess. Can anyone confirm this? I've got the Base, Good and Ugly plugins installed to GStreamer now. DVD playback in Gstreamer is pretty much broken, so totem disables it. If you want semi-working playback, try using this patch from Paldo: http://www.paldo.org/paldo/sources/totem/totem-2.18.2-gstreamer-0.10-dvd-1.patch.bz2 If you're really adventurous, you can try to use an alternate module from dvdread in gst-plugins-ugly in addition to the Paldo patch. http://jasonderose.org/kungfu/dvdsrc-2007-03-20.tar.gz Background for that here: http://bugzilla.gnome.org/show_bug.cgi?id=372797 I've been meaning to do test this for a long time. From reading the bug, it seems that this new module works considerably better than the current one. Anyway, I rebuilt Totem specifying Xine as the backend, and it plays the movie as it should. This is the only reason I still use the Xine backend. However, there's a bug in browser plugin when using Xine. If you have current totem-2.18 and current xine-lib, you also need this revision: http://svn.gnome.org/viewcvs/totem?view=revisionrevision=4437 -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
