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.or
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
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:
>
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 'test
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
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"
> lin
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:
g
- Original Message -
From: "Bruce Dubbs" <[EMAIL PROTECTED]>
To: "LFS Developers Mailinglist"
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 fa
Jeremy Huntwork wrote:
> Hello,
>
> The LFS LiveCD team is pleased to announce a new 64bit-only CD. It is a
> minimal CD, meaning that it contains no X Windows System and dependent
> software nor any source packages. The LFS book that is included is based
> on the current development x86_64 bran
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.
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'
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 unne
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{D
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{D
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
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 expe
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 F
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
Jeremy Huntwork wrote:
> Hello,
>
> The LFS LiveCD team is pleased to announce a new 64bit-only CD. It is a
> minimal CD, meaning that it contains no X Windows System and dependent
> software nor any source packages. The LFS book that is included is based
> on the current development x86_64 bra
Hi all,
I am new to the mailing list and HLFS, and have just started having a go
at building HLFS SVN-20070708.
My progress so far is up to Chapter 6, building Glibc 2.5, and all has
gone well until now.
Approximately half way down the page, having built Glibc the first time
and removed the '
20 matches
Mail list logo
