minor bug in "du" size calculator in build_all.sh

[Philip Hands <phil@hands.com>]

Hi,

du doesn't follow symbolic links, so the size of "current" is reported
as 0

This will work:

  disks=`cd ${MIRROR}/dists/${CODENAME}/main/disks-${ARCH}/current ;\ 
         du -sm | cut -f1'`

Also, the next line should probably read:

  make list COMPLETE=1 SIZELIMIT1=$((($(MBLIMIT) - ${disks}) * 1024 *1024)) \
        SRCSIZELIMIT=$(($(MBLIMIT) * 1024 * 1024))

with MBLIMIT being set in CONF.sh, so that you can change all the
target sizes in one place, and SIZELIMIT being calculated from that as
well.

also, how come a SRCSIZELIMIT=645MB produces this:

-rw-r--r--    1 phil     phil     679835648 May 27 02:55 potato-src-1.raw
-rw-r--r--    1 phil     phil     681668608 May 27 02:58 potato-src-2.raw
-rw-r--r--    1 phil     phil     603662336 May 27 03:02 potato-src-3.raw

with CD#2 being over 650MB?  Is there some extra stuff that's not
being included in the size calculation, or is this down to the fact
that every file gets rounded up to the nearest 2k in iso9660 images
(are we taking account of that at present?)

That's not so important though, because it doesn't matter if the
source CDs are even sizes, so I'll just drop the limit.

Can anyone confirm the rumour about CDs getting steadily more
unreliable as they approach the 650MB --- I cannot say I've ever seen
that, and I normally aim to fill the first CD.

I think we should aim for the binary CD#1's to be as large as possible
though, so that there is as much chance as possible that a useful
install can be achieved with just CD#1

It just occurred to me that because of the 2k rounding thing, the du
calculation above is going to be inaccurate too.  I'll look at doing a
du in perl that rounds up to 2k, but won't have time to do it until
Monday.

Cheers, Phil.