[blfs-dev] Package stats

Fernando de Oliveira famobr at yahoo.com.br
Thu Mar 6 12:18:52 PST 2014


Em 06-03-2014 15:22, Ken Moffat escreveu:
> On Thu, Mar 06, 2014 at 02:36:02PM -0300, Fernando de Oliveira wrote:
>> Em 06-03-2014 13:36, Bruce Dubbs escreveu:
>>>
>>>    So build size is measured as df_after - df_before.  The issue to note 
>>> is that there is activity during the build that adds or deletes space on 
>>> /tmp, the size will be off.  I have /tmp on its own partition.
>>>
>  To me, that seems excessively complicated.  But each to his own.
>>
>>
>> Thanks, Bruce.
>>
>> I find "du" more accurate, although more tome consuming, so have to to
>> mark some instants to avoid it from interfering in the timings.
>>
>> On example is that df wil include the log size, perhaps you think it is
>> relevant.
> 
>  When I measure for the book, I don't usually make logs!  If I am
> making logs, I usually put them in ../ and use du for the directory
> and for the DESTDIR or equivalent directory.

One thing is that the value of du -sch id different from (du -sh) + (du
-sh), du -sch is more accurate, if more than one file/dir are measured.

>>
>> But all numbers we give are approximate, large error bar, so I do not
>> dispute methods or numbers.
> 
>  Agree, I see large variations - even in remeasuring the SBU.
>>
>> The problem there is that Ken found values very different, even one
>> negative: building the API docs takes less than installing the ones in
>> the tarball, is one example, and I can hardly believe this is possible:
>> build taking less time than just installing the documents.
>>
> 
>  Did I write that ?  I intended to say that rebuilding the API docs
> took a lot of extra time, but that the space used was 1MB less - I
> guess that the recreated docs are trimmed down.

LOL. My bad, mixed the two subjects. Sorry

> 
>> As I introduced many of these numbers, probably after what Ken used to
>> do with ImageMagick, what I think is that being non-english speaking
>> native, I am giving wrong names to what I measure. That was the reason I
>> detailed how and what I measure there. It seems I need to rename in the
>> book, some number I gave.
>>
>> What I mean is: everybody know 1 inch is different from 1 cm. But I can
>> use a ruler, make a measurement and tell Ken it is 1, using a cm ruler,
>> but he thinking I am using inches.
>>
>> He is not wrong
>>
>> I am not wrong
>>
>> We are giving numbers for different things, probably my fault of not
>> writing carefully what my number means.
>>
>  It is clear that my rebuild of the docs was very different from
> Fernando's.  At the moment I'm concentrating on rebuilding
> everything in chroot, just in case there is any breakage from
> accidental change in gnutls.  My first attempt at LO just timed out
> on one of the downloads, so I guess I'm hours away from completing.
> After that, I'll take another look.
> 
>  Unfortunately, this system with gnome packages is my only 7.5
> system with gtk-doc and p11-kit, so I can't do comparative tests on
> the other box.
> 
>  What I did notice was a *lot* of activity during the rebuilding of
> the docs (not logged, so I watched stdout scroll past, with
> references to html at one point.
> 
>  Guess I'd better create logs when I come back to this, so that I
> can summarise the difference in the builds.
> 
> ĸen
> 

Actually, I only came discussing this subject, because you mentioned in
some mail this or last week. Now, that I am trying to get done the
tickets, I lost so much time with docs and tests, that for the moment, I
will continue updating without caring about them, only in the second
round will restart. So, for a couple of packages, I already have the
complete set of numbers, but for all following ones, only the main
values of dirsizes and SBU will updated, the other ones will be kpt as are.

After what you wrote, in the ticket, I think we are measuring the same
thing, probably I committed a mistake. As I said in previous paragraph.
I don't care, for the moment. Next updates, we will have more time to do
things decently.

Cheers,

-- 
[]s,
Fernando



More information about the blfs-dev mailing list