Em 18-11-2013 10:17, Pierre Labastie escreveu:
> Le 18/11/2013 11:29, Fernando de Oliveira a écrit :
>> Em 17-11-2013 19:12, Pierre Labastie escreveu:
>>> Hi all,
>>>
>>> In the process of updating apr and apr-util, I did a thorough test of
>>> subversion. I have found a few inaccuracies there:
>>> - the test time is much longer than indicated (38 SBU). BTW, there is only
>>> one
>>> error.
>>
>> FAIL: lt-wc-queries-test 3: test query expectations
>> Summary of test results:
>> 1897 tests PASSED
>> 52 tests SKIPPED
>> 30 tests XFAILED (1 WORK-IN-PROGRESS)
>> 1 test FAILED
>> SUMMARY: Some tests failed.
>>
>> make: *** [check] Error 1
>>
>> real 33m19.163s
>> user 10m8.563s
>> sys 14m7.070s
>>
>> This gives me ≈ 11,623041 SBU.
>>
>>
>> Then, I ran againg the tests with make -k check, but chose to use above
>> (second runs always give me lower values, and i prefer to inform the
>> user what is going to happen the first time).
>>
>> FAIL: lt-wc-queries-test 3: test query expectations
>> Summary of test results:
>> 1897 tests PASSED
>> 52 tests SKIPPED
>> 30 tests XFAILED (1 WORK-IN-PROGRESS)
>> 1 test FAILED
>> SUMMARY: Some tests failed.
>>
>> make: *** [check] Error 1
>>
>> real 32m35.956s
>> user 10m7.685s
>> sys 14m18.426s
>>
>> SBU_TIME for swig tests: 0.95542442
>>
>> I have been having very different SBUs and buiddirsize from the book and
>> can only report what I obtained. I have already discussed about the
>> builddirsizes, but apparently this happens to the times also: I use i686.
>>
>> I have all the logs, if anyone wants to inspect.
>>
>> And my conclusion is not about the inaccuracies of the reported by
>> previous editors.
> Fernando,
> Sorry if you took my post like that. I did not mean to report
> "inaccuracies", but differences.
No problem. As I wrote, when I started editing, I also noticed many
differences, have now discussed about them in the lists and privately.
> For timings, I use "echo $SECONDS" (as in jhalfs).
I have separated echo $SECONDS for the whole builds including
uncompressing and not.
After decompressed, I record
INITIAL_SECOND=$SECONDS &&
and at the end:
TOTAL_SECONDS=$(($SECONDS - $INITIAL_SECOND)) &&
echo ${TOTAL_SECONDS} &&
...
Then, determine sizes (some code from Bruce):
du -sch $TMPDIR/$BUILDDIR/* &&
du -sch $SOURCEDIR/$ARQUIVO*.$COMP_EXT &&
md5sum $SOURCEDIR/$ARQUIVO*.$COMP_EXT &&
BUILD_DIR_SIZE=`du -sck \
$TMPDIR/$BUILDDIR | grep total | cut -d"t" -f1` &&
echo -e "\nBUILD_DIR_SIZE: $BUILD_DIR_SIZE" &&
and after (also, some code from Bruce):
source /usr/src/SBU_UNIT.sh &&
SBU_TIME=$(echo "scale=8;$TOTAL_SECONDS/$SBU_LFS" | bc) &&
echo -e "\n\nSBU_TIME: $SBU_TIME\n" &&
echo -e "\n\nTotalseconds: $TOTAL_SECONDS\n"
> And I got roughly 5900 s for the tests (SBU is 154s), including swig
> tests (I am very amazed that they are so short for you, the python tests
> took at least a quarter of an hour for me).
> It may be because I use a virtual machine on x86_64, but that should
> affect the SBU too...
That is what I tried explaining: I also run LFS7.4 in a vm, but i686. In
the same architecture, values differ from one editor to the other (sizes
and times), have discussed about them, more in different architectures.
>>> How should I proceed: raise a ticket and modify the book?
>>> Let Fernando do it himself?
>> I would suggest that if you want to change SBU or builddirsize, do it
>> for one that you are updating, leave the others as they are. I have
>> different results for almost all applications int the book that I
>> install and I have not updated.
> That seems very reasonable. Please forgive me and forget my suggestion:
> as a beginner BLFS editor, I have been too enthusiastic...
>>
>> Another suggestion, if we had many editors, would be to inform with the
>> data if it is from x86_64 or i686.
>>
>> Just to show my differences
>>
>> 9,7M /home/fernando/tmp/paco-build-2013.11.17-10h56m49s/apr-1.5.0
>> 1,6M /home/fernando/tmp/paco-build-2013.11.17-10h56m49s/DEST-apr-1.5.0
>> 12M total
>> 796K /home/fernando/sshfs/blfs/apr-1.5.0.tar.bz2
>> 796K total
>> cc93bd2c12d0d037f68e21cc6385dc31
>> /home/fernando/sshfs/blfs/apr-1.5.0.tar.bz2
>>
>> BUILD_DIR_SIZE: 11528
>>
>>
>> Then, by hand:
>>
>> After tests:
>> real 2m42.788s
>> user 0m9.731s
>> sys 1m33.253s
>> SBU_tests≈ 0,94644186
>>
>> $ du -sch *
>> 12M apr-1.5.0
>> 1,6M DEST-apr-1.5.0
>> 14M total
>>
>> This gives me the about the same SBUs, but differents sizes.
> I see that you get a different result in "automatic" measurements (total
> 12M, BUILD_DIR_SIZE=11528) and by hand.
Yes. First, I build without tests. Then, I run the tests by hand and
after determine the time and sizes by hand. Have done differently in the
past, building twice with and without tests, but the build repeat was a
waste of time. You may have missed "After tests", above, or I did not
explain the differences. That is why I run the tests by hand.
> What I do is "du -sk" on the directory containing the tarball, the build
> directory and the destdir directory. I have not yet implemented the
> method of jhalfs (do "du -sk --exclude=lost+found /" before and after
> the build. Actually, it only works in a dedicated machine, not if you
> can do other things on the same machine). I do not have access to the
> logs right now, but I'll send them. Discrepancies are always interesting
> to analyze!
Yes, and discussed them before. I do not dispute your results, no need
for the logs. And I much respect your knowledge (not only in linux) and
results.
So, I only change the values when I am doing a full update for the whole
package. When fixing a package, I respect the numbers that the editor,
myself or not, have written.
Thunderbird, Firefox/Xulrunner and Seamonkey (and other very time
consuming packages) being some that I fix my own results, after I
rebuild them the next day and perhaps get (very) different values, they
are always different, you have verified yourself, in the discussion
about SBU, some time ago, and used a +- error as we do in physics.
Thanks.
--
[]s,
Fernando
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
