On 7/30/07, Ken Moffat <[EMAIL PROTECTED]> wrote:
>
> Tar is repeatedly failing '26: incremental' for me, looks like a
> regression. But nobody else has commented.
If you have any idea how to narrow this down, that'd be great. I have
hit this before myself, and it seems like a race condition, but I
can't say for sure. I haven't run the full range of tests on all the
packages in a while. At worst, we can add a note that this test fails
sometimes.
> 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
>
> - as to what that means, your guess is as good as mine.
>
> The perl failure didn't happen on the second run, I guess it's just
> another unreliable test.
>
> And the vim test failure is totally impenetrable.
Don't know about any of those. I don't really bother reading the
results of the vim tests.
> And moving on to farce test results ("how repeatable is it?") -
> apart from cc1 and cc1plus I also had a failure in libc-2.5.so (not
> yet investigated) and in private mail from archaic I know he saw a
> failure in nscd (I've got his files for this, but haven't investigated
> it yet).
libc.so and nscd both embed the build date.
$ strings /lib/libc.so.6 | grep 2007
Compiled on a Linux >>2.6.20.14-1<< system on 2007-07-15.
$ strings /usr/sbin/nscd | grep 2007
Jul 15 2007 08:44:08
Although, I though farce tried to strip out the dates, so maybe it's
something worse. If you want to be sure about the nscd one, you can
just blow away the __DATE__ and __TIME__ macros:
sed -i.bak \
-e 's/__DATE__/"today"/' \
-e 's/__TIME__/"now"/' nscd/nscd_stat.c
> He also noted in that mail that coreutils seems to be using
> a pre-created info file in his second and third builds - (I've only
> run two, and misread the diff : coreutils.info was created by
> makeinfo version 4.9 in the first build, and 4.8 in the second).
> But, we don't expect user to build it twice, so I'm not too worried
> about that, I just add it to my "coreutils Makefile is a POS"
> thoughts :-)
That sucks, but at least it's not critical.
> Which only leaves space/SBU measurements. Because my build hasn't
> been by-the-book, and has run tests whenever possible, I'll only
> comment on those I know look wrong (chapter 6 only)
I'll try to get jhalfs to spit some numbers to me and see if they agree.
> Now, time for me to ask a question: Is it worthwhile that we
> continue to record SBUs and space ? Everybody knows that many
> packages take longer to build and use more space whenever the
> toolchain is upgraded. Is it really worthwhile to be so exact about
> the time and space. Certainly, space should be constant across
> an architecture (well, i686 anyway) for a given toolchain, but the
> timings depend greatly on amount of memory (do you hit swap?),
> memory speed (try using a via processor), and disk speed.
I guess I just like to know how things are gonna shape up relatively.
I.e., gcc's gonna take a while, no sense in watching the screen. I
don't care if the numbers aren't accurate. But people using older
hardware may be more interested in the readings. I suppose one
compromise would be less precision. I.e., round to the nearest MiB or
integer SBU.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
