Re: 6.9. Glibc-2.12.1
On Wed, 2011-06-22 at 15:21 +0100, Eric Plummer wrote: Simon: That is one heck of an assumption... If you assume everyone else does their job properly, I have a used car you might be interested in... Oh, I know it's not necessarily accurate, don't get me wrong. But as I said, if I don't trust the code written by other developers, why should I put any trust in the tests they wrote? Testing is not only for the program in question, it can also check for proper interaction with external required libs/progs. Have you ever heard that an ounce of prevention is worth a pound of cure? I would much rather test something before depending on it to perform a task in a predictable manner. And that's fine - I'm not trying to convince everyone else that running tests is unnecessary. I just don't find it worth my time, running tests for every piece of software I install. Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 6.9. Glibc-2.12.1
On Thu, 23 Jun 2011 19:59:47 +1200 Simon Geard delga...@ihug.co.nz wrote: And that's fine - I'm not trying to convince everyone else that running tests is unnecessary. I just don't find it worth my time, running tests for every piece of software I install. Same here. If it's broken I'll find out when I try to run it or build something that links to it or whatever. Tests are fine for developers but as a user I find it's quicker to not run the tests. Andy -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 6.9. Glibc-2.12.1
On Mon, 2011-06-20 at 12:00 -0500, Mike McCarty wrote: Interesting. I have more faith in my own code than I do in others'. You apparently trust others' works more than you do your own. It's more that I see automated testing as being for the developer's benefit - so when writing code, it's essential to have tests a) covering as much of the code as possible, and b) passing reliably. That's important, because if I make a change and break something else, *I'm* the one who has to explain that to a customer. And that's not fun. When it comes to some random piece of software I don't code on, I'm judging things on different criteria. I don't care if gcc passes 100% of it's automated tests - I care whether it can compile all of the LFS and BLFS packages. Test failures don't matter to end users unless they represent bugs that actually affect that user. Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 6.9. Glibc-2.12.1
On Mon, 2011-06-20 at 12:00 -0500, Mike McCarty wrote: Interesting. I have more faith in my own code than I do in others'. You apparently trust others' works more than you do your own. It's more that I see automated testing as being for the developer's benefit - so when writing code, it's essential to have tests a) covering as much of the code as possible, and b) passing reliably. That's important, because if I make a change and break something else, *I'm* the one who has to explain that to a customer. And that's not fun. It's my reputation on the line. As to trust, it's more that I assume that other developers have their own standards, and if they're willing to call something a stable release, they've done the work to ensure they have confidence in it. And if they haven't, well - what confidence should I have that their automated tests are useful? Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 6.9. Glibc-2.12.1
Simon Geard wrote: On Mon, 2011-06-20 at 12:00 -0500, Mike McCarty wrote: Interesting. I have more faith in my own code than I do in others'. You apparently trust others' works more than you do your own. It's more that I see automated testing as being for the developer's benefit - so when writing code, it's essential to have tests a) covering as much of the code as possible, and b) passing reliably. That's important, because if I make a change and break something else, *I'm* the one who has to explain that to a customer. And that's not fun. It's my reputation on the line. As to trust, it's more that I assume that other developers have their own standards, and if they're willing to call something a stable release, they've done the work to ensure they have confidence in it. And if they haven't, well - what confidence should I have that their automated tests are useful? Simon: That is one heck of an assumption... If you assume everyone else does their job properly, I have a used car you might be interested in... Testing is not only for the program in question, it can also check for proper interaction with external required libs/progs. Have you ever heard that an ounce of prevention is worth a pound of cure? I would much rather test something before depending on it to perform a task in a predictable manner. -- Eric Plummer anadox...@gmail.com -- Messages in plain text, please, no HTML. No top posting, please. -- -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 6.9. Glibc-2.12.1
Simon Geard wrote:
On Fri, 2011-06-17 at 11:12 -0500, Mike McCarty wrote:
Webmaster wrote:
I never check, because if the check passed it's useless but if the
check failed you can do nothing.
Then you do not understand the purpose of testing. I've heard
many a manager say more or less the same thing.
Harsh. Automated tests are primarily for developers to spot regressions
Possibly, but not intentionally so.
in their own code - if they happen to be useful to spot problems in an
LFS build, that's just a bonus for us.
I was addressing the purpose of testing. The purpose of testing is
NOT to detect errors. The purpose of testing is to verify proper
operation. Regression errors is one place where it's useful, again,
to verify proper operation, as you say.
Using testing to detect errors is a very inefficient and not very
useful technique. A more efficient and useful technique is to
use code inspections.
Personally, I don't bother - they're critical when I'm writing code, but
I rarely take the time to run them when simply installing someone else's
work.
Interesting. I have more faith in my own code than I do in others'.
You apparently trust others' works more than you do your own.
Mac
--
p=p=%c%s%c;main(){printf(p,34,p,34);};main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: 6.9. Glibc-2.12.1
Simon Geard wrote:
On Fri, 2011-06-17 at 11:12 -0500, Mike McCarty wrote:
Webmaster wrote:
I never check, because if the check passed it's useless but if the
check failed you can do nothing.
Then you do not understand the purpose of testing. I've heard
many a manager say more or less the same thing.
Harsh. Automated tests are primarily for developers to spot regressions
Oh, and if I didn't make it clear, I apologize for any offence I
may have given. Sorry if that was harsh. I didn't intend it so.
Mac
--
p=p=%c%s%c;main(){printf(p,34,p,34);};main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: 6.9. Glibc-2.12.1
On 06/16/2011 05:30 PM, Bruce Dubbs wrote: robert wrote: cannot get beyond this: make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/sources/glibc-2.12.1' make: *** [check] Error 2 make[2]: [/sources/glibc-build/posix/annexc.out] Error 1 (ignored) make[2]: *** [/sources/glibc-build/rt/tst-mqueue5.out] Error 1 make[2]: *** [/sources/glibc-build/rt/tst-cpuclock2.out] Error 1 make[1]: *** [rt/tests] Error 2 make: *** [check] Error 2 The nptl/tst-clock2, nptl/tst-attr3, and rt/tst-cpuclock2 tests have been known to fail. The reason is not completely understood, but indications are that minor timing issues can trigger these failures. I haven't seen tst-mqueue5 fail before, but I suggest that you build LFS 6.8 instead of 6.7. -- Bruce Yep. Gonna do just that. Scrap the 6.7 build and move on to 6.8. We'll see what happens. I've built 6.7 three or four times without errors on the same machine. The current impasses concerns me, but I'm gonna move on. Will post later. Thanks to everyone for the advice and attention. Robert -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 6.9. Glibc-2.12.1
On Fri, 2011-06-17 at 11:12 -0500, Mike McCarty wrote: Webmaster wrote: I never check, because if the check passed it's useless but if the check failed you can do nothing. Then you do not understand the purpose of testing. I've heard many a manager say more or less the same thing. Harsh. Automated tests are primarily for developers to spot regressions in their own code - if they happen to be useful to spot problems in an LFS build, that's just a bonus for us. Personally, I don't bother - they're critical when I'm writing code, but I rarely take the time to run them when simply installing someone else's work. Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 6.9. Glibc-2.12.1
Simon Geard wrote: On Fri, 2011-06-17 at 11:12 -0500, Mike McCarty wrote: Webmaster wrote: I never check, because if the check passed it's useless but if the check failed you can do nothing. Then you do not understand the purpose of testing. I've heard many a manager say more or less the same thing. Harsh. Automated tests are primarily for developers to spot regressions in their own code - if they happen to be useful to spot problems in an LFS build, that's just a bonus for us. Personally, I don't bother - they're critical when I'm writing code, but I rarely take the time to run them when simply installing someone else's work. I always run the tests in Chapter 6 when installing a new package version. If I've installed a package before and it was OK, then I don't feel the need to test again. I like to understand any problems before using a package. For example, bc gives about 10 errors out of 1000 but the nature of the errors are round off issues that I can live with. Some of the errors identified in LFS packages are quite tricky. Timing errors are especially difficult, but there have been cases where there were bugs and we held off a package until we got a fix. GRUB-1.99 is a case in point right now. I still have to try a patch to see if I can get it to work properly with LFS. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re:6.9. Glibc-2.12.1
I never check, because if the check passed it's useless but if the check failed you can do nothing. -- Original -- From: robertmullinrob...@gmail.com; Date: Fri, Jun 17, 2011 00:33 AM To: lfs-supportlfs-support@linuxfromscratch.org; Subject: 6.9. Glibc-2.12.1 cannot get beyond this: make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/sources/glibc-2.12.1' make: *** [check] Error 2 make[2]: [/sources/glibc-build/posix/annexc.out] Error 1 (ignored) make[2]: *** [/sources/glibc-build/rt/tst-mqueue5.out] Error 1 make[2]: *** [/sources/glibc-build/rt/tst-cpuclock2.out] Error 1 make[1]: *** [rt/tests] Error 2 make: *** [check] Error 2 any suggestions? Thanks in advance. Robert -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page-- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 6.9. Glibc-2.12.1
Webmaster wrote:
I never check, because if the check passed it's useless but if the
check failed you can do nothing.
Then you do not understand the purpose of testing. I've heard
many a manager say more or less the same thing.
Mac
--
p=p=%c%s%c;main(){printf(p,34,p,34);};main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Re:6.9. Glibc-2.12.1
On vr, 2011-06-17 at 22:12 +0800, Webmaster wrote: I never check, because if the check passed it's useless but if the check failed you can do nothing. If the check passed you know you have succeeded thus far, if it failed you might have made a mistake. I'd rather _know_ something is wrong than trust my data to a system that might get hopelessly corrupted! -- Original -- From: robertmullinrob...@gmail.com; Date: Fri, Jun 17, 2011 00:33 AM To: lfs-supportlfs-support@linuxfromscratch.org; Subject: 6.9. Glibc-2.12.1 cannot get beyond this: make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/sources/glibc-2.12.1' make: *** [check] Error 2 make[2]: [/sources/glibc-build/posix/annexc.out] Error 1 (ignored) make[2]: *** [/sources/glibc-build/rt/tst-mqueue5.out] Error 1 make[2]: *** [/sources/glibc-build/rt/tst-cpuclock2.out] Error 1 make[1]: *** [rt/tests] Error 2 make: *** [check] Error 2 any suggestions? Thanks in advance. Robert -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 6.9. Glibc-2.12.1
robert wrote:
cannot get beyond this:
make[1]: Target `check' not remade because of errors.
make[1]: Leaving directory `/sources/glibc-2.12.1'
make: *** [check] Error 2
make[2]: [/sources/glibc-build/posix/annexc.out] Error 1 (ignored)
make[2]: *** [/sources/glibc-build/rt/tst-mqueue5.out] Error 1
make[2]: *** [/sources/glibc-build/rt/tst-cpuclock2.out] Error 1
make[1]: *** [rt/tests] Error 2
make: *** [check] Error 2
any suggestions?
Post more info. Did ./configure complain about anything?
Wait a minute. What chapter of the book are you working in?
If you are in Chapter 5, then you probably shouldn't be
make check
if that's what you did.
Mac
--
p=p=%c%s%c;main(){printf(p,34,p,34);};main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: 6.9. Glibc-2.12.1
On 06/16/2011 02:37 PM, Mike McCarty wrote: robert wrote: cannot get beyond this: make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/sources/glibc-2.12.1' make: *** [check] Error 2 make[2]: [/sources/glibc-build/posix/annexc.out] Error 1 (ignored) make[2]: *** [/sources/glibc-build/rt/tst-mqueue5.out] Error 1 make[2]: *** [/sources/glibc-build/rt/tst-cpuclock2.out] Error 1 make[1]: *** [rt/tests] Error 2 make: *** [check] Error 2 any suggestions? Post more info. Did ./configure complain about anything? Wait a minute. What chapter of the book are you working in? If you are in Chapter 5, then you probably shouldn't be make check if that's what you did. Mac working at 6.9. Glibc-2.12.1 ... this chapter in Version 6.7 build . configure did not complain; all appears to go smoothly up to this point. What additional info should I post? Thanks. Robert -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 6.9. Glibc-2.12.1
robert wrote: cannot get beyond this: make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/sources/glibc-2.12.1' make: *** [check] Error 2 make[2]: [/sources/glibc-build/posix/annexc.out] Error 1 (ignored) make[2]: *** [/sources/glibc-build/rt/tst-mqueue5.out] Error 1 make[2]: *** [/sources/glibc-build/rt/tst-cpuclock2.out] Error 1 make[1]: *** [rt/tests] Error 2 make: *** [check] Error 2 The nptl/tst-clock2, nptl/tst-attr3, and rt/tst-cpuclock2 tests have been known to fail. The reason is not completely understood, but indications are that minor timing issues can trigger these failures. I haven't seen tst-mqueue5 fail before, but I suggest that you build LFS 6.8 instead of 6.7. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 6.9. Glibc-2.12.1
On Thu, 16 Jun 2011 16:29:19 -0500 robert mullinrob...@gmail.com wrote: What additional info should I post? About 20 lines or so before it _first_ says error. Andy -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
