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. For timings, I use "echo $SECONDS" (as in jhalfs). 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...
>> 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. 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! Regards Pierre -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
