On Friday 17 August 2007 17:24, Ken Moffat wrote:
> So, take a look at the unexpurgated log.
Thanks, I'm going to take a peek at those. Specifically, the nptl ;).
> but I
> mistrust your SBU measurement - 230-300 is a rather large variance
That's true it's more typical to see it within 10 secon
On Fri, Aug 17, 2007 at 04:49:04PM -0600, Trent Shea wrote:
>
> I'm still concerned about my actual SBU time. One SBU unit for this machine
> is
> anywhere from 230-300 seconds, so, the glibc in chapter six with tests should
> take anywhere from 4500-5800 seconds. It would be nice to see if any
On Friday 17 August 2007 17:08, Randy McMurchy wrote:
> This may be much more than you need
Nope, I needed it to stare me in the face.
Many thanks.
Trent.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above inf
Trent Shea wrote these words on 08/17/07 17:49 CST:
> It would be nice to see if anyone who
> didn't encounter errors in the glibc-tests has SBU times that reflect those
> listed in the book.
This may be much more than you need, but filter out what you do need.
BTW - st*.ts files are start and
On Friday 17 August 2007 16:36, Randy McMurchy wrote:
> the time in the book as 19.5 SBU to build
Sorry, that is correct. I had the gcc page open.
I'm still concerned about my actual SBU time. One SBU unit for this machine is
anywhere from 230-300 seconds, so, the glibc in chapter six with tests
Trent Shea wrote these words on 08/17/07 16:00 CST:
> I'm having trouble with glibc-tests. The book says that they should take
> around 22 SBU; I'm completing them in under 4. I'm not getting any unexpected
> Errors a "grep Error glibc-2.5-tests" produces:
>
> [snip]
> glibc-2.5-tests time: 879.
I'm having trouble with glibc-tests. The book says that they should take
around 22 SBU; I'm completing them in under 4. I'm not getting any unexpected
Errors a "grep Error glibc-2.5-tests" produces:
make[2]: [/root/glibc-2.5-build/posix/annexc.out] Error 1 (ignored)
make[2]: *** [/root/glibc-2.5
Eric Stout wrote:
> 3: But do not include the entire original!
>
> 4: To prevent hideously long posts with a minimal account of new text, it
> is good Usenet practice to remove the non-relevant parts and optionally
> summarize the relevant parts of the original post, with regard to one's
> reply.
> Get a good mail client which doesn't automatically show all bullshit
> above, like Gmail.
Adjust your attitude.
For personal, legal, and corporate reasons, the only email access I have
that's 24/7 is to run pine on a workstation currently located 4300 miles
north west of me.
Don't try to chang
> >If this is a mailing list: DO NOT TOP POST! why?:
> >http://www.caliburn.nl/topposting.html
>
> If you're advocating not top-posting due to [n]etiquette, how can you not
> advocate trimming replies, when it's IMHO just as important for good
> [n]etiquette?
Not to mention that what he linked to
Rumor has it that Tijnema may have mentioned these words:
>On 8/17/07, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> >
> > Please trim the quoted material to what is relevant.
> >
> > --
> > Randy
> >
>
>Get a good mail client which doesn't automatically show all bullshit
>above, like Gmail.
So you'
On 8/17/07, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> rblythe wrote these words on 08/16/07 16:56 CST:
>
> > [snip 53 lines of stuff having nothing to do with the reply]
> >
> > Please do not top post
>
> Please trim the quoted material to what is relevant.
>
> --
> Randy
>
Get a good mail clien
rblythe wrote these words on 08/16/07 16:56 CST:
> [snip 53 lines of stuff having nothing to do with the reply]
>
> Please do not top post
Please trim the quoted material to what is relevant.
--
Randy
rmlscsi: [bogomips 1003.27] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3]
[GNU C Library stable r
13 matches
Mail list logo
