Re: Is 6.3 ready for release?
M.Canales.es wrote: And when x86_64 will be merged, that values will be less accurate. I suppose that's argument for producing a separate set of text for 64-bit. -- JH -- 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?
Jeremy Huntwork wrote: M.Canales.es wrote: If we are happy with big figures, thus use the same values for all archs, If we want something accurate for each arch, remove the info from the book a create a web page to place jhalfs reports. I like this option. Perhaps provide *very* rough estimates for the SBU (round to the nearest 1/2 SBU or so, based probably on x86) in the book and a store of SBU reports elsewhere on the web. http://www.linuxfromscratch.org/~sbu/ -- Bruce -- 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?
Bruce Dubbs wrote: http://www.linuxfromscratch.org/~sbu/ :-) -- JH -- 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?
El Miércoles, 1 de Agosto de 2007 19:43, Jeremy Huntwork escribió: I suppose that's argument for producing a separate set of text for 64-bit. Not, if creating sepparate books I refuse to have separate diskusage/buildtime blocks and entities sets for each arch. On CLFS and HLFS that info was removed due the big amount of work involved on maintain the XML code and in keeping that values more or less accurates for each book. If we are happy with big figures, thus use the same values for all archs, If we want something accurate for each arch, remove the info from the book a create a web page to place jhalfs reports. -- 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: Is 6.3 ready for release?
On 7/30/07, Ken Moffat [EMAIL PROTECTED] wrote: To expand on what I posted earlier about test failures: Tar is repeatedly failing '26: incremental' for me, looks like a regression. But nobody else has commented. This time I got all passes for tar. Go figure. 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 I got those failures on a single run (using jhalfs). I'm not sure what's causing the errors, but what's failing is `test -r /dev/fd/0' and `test -r /dev/stdin' (look at tests/test.right for the output that it's diffing to above). So, I suspect this has something to do with the su to the nobody user and how su handles these devices. But the last time I thought about this it hurt my head. It may have something even more to do with how our scripts are handling the user switching. The perl failure didn't happen on the second run, I guess it's just another unreliable test. What was the exact perl failure? And the vim test failure is totally impenetrable. One of the vim tests hung on me, and trying to decipher the output only resulted in garbage in the terminal. I think I might just stop running this thing. -- 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 8/2/07, Ken Moffat [EMAIL PROTECTED] wrote: On Wed, Aug 01, 2007 at 02:53:59PM -0700, Dan Nicholson wrote: On 7/30/07, Ken Moffat [EMAIL PROTECTED] wrote: I got those failures on a single run (using jhalfs). I'm not sure what's causing the errors, but what's failing is `test -r /dev/fd/0' and `test -r /dev/stdin' (look at tests/test.right for the output that it's diffing to above). So, I suspect this has something to do with the su to the nobody user and how su handles these devices. But the last time I thought about this it hurt my head. It may have something even more to do with how our scripts are handling the user switching. These files both end up being symlinks to /dev/pts/0 (or whatever pts device you logged into) - and the perms for this are root:~# ls -l /dev/fd/0 lrwx-- 1 root root 64 2007-08-02 14:30 /dev/fd/0 - /dev/pts/0 root:~# ls -l /dev/stdin lrwxrwxrwx 1 root root 15 2007-08-03 02:22 /dev/stdin - /proc/self/fd/0 root:~# ls -l /proc/self/fd/0 lrwx-- 1 root root 64 2007-08-02 14:30 /proc/self/fd/0 - /dev/pts/0 root:~# ls -l /dev/pts/0 crw--w 1 root tty 136, 0 2007-08-02 14:30 /dev/pts/0 so the nobody user won't be able to read these devices. Not sure how you would work around that, unless you use login instead of su to start the nobody user doing the testing (which will change ownership of /dev/pts/x and hence the tests will pass) -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page