Re: test-cycle-1 CD's debian-cd diff
Raphael Hertzog <rhertzog@hrnet.fr> writes:
> Le Fri, May 26, 2000 at 09:23:36AM +0100, Philip Hands écrivait:
> > the SIZELIMIT1 setting was being ignored for some reason (it seems
> > that the way the makefile was trying to pass them on wasn't working.
>
> If this doesn't work we should have noticed it way before ... i've built
> dozen of CDs using this and I've had no problem so far.
>
> Maybe were you having troubles because you forgot to launch make distclean
> between you different tries... no ?
No.
I was using build_all.sh, which does this for you every time.
> > Having @ in front of every command makes debugging painful.
> > I've replaced them with $(Q) so you can switch debugging on/off
> > with Q=@ at the top
>
> That's not so usuful since the code in the Makefile isn't so huge and it's
> well separated in different blocks. When you see an error in the log you
> just need to check the informative message before and you know where the
> problem was, after that it's quick to check (on the shell) what didn't
> work.
It's a lot easier to be able to see the command that failed, so you
can cut & paste it onto the command line.
Given that I've done it in a way that will leave the behaviour as you
prefer (once you uncomment the Q=@ line) I don't see the problem with
including it.
My patch was a little over-enthusiastic, in that the lines of the form:
@test ... || ( echo ... ; false )
should be left alone.
> > build_all.sh should have ``set -x'' so it bails out if one of the makes
> > fails.
>
> Well, you meant set -e and no,
Yeah I did.
> i dont think we want that since i'm checking $? after some critical
> commands. However you may add more if [ $? -gt 0 ]; then echo
> "problem..." >&2; exit 1; fi; after make list for example or after
> make official_images ...
I had a couple of runs ruined by trivial errors which didn't cause the
run to stop, which equates to about four hours of my time wasted.
Very irritating.
>
> > I added Philip Charles' first CD "needed" list, and added ssh &
> > gnupg to it, and put an inclusion for it into the tasks list above
> > the language tasks. Does that seem like the right place to put it?
>
> Yes but I still wonder why this list is needed. What were the criteria
> for selecting those packages on CD1 ? debian-cd should garanty the
> consistency of CDs wrt to dependencies ... if it doesn't for some packages
> then it's a bug !
The aim is to ensure that the packages that most commonly get upgraded
on an
apt-get dist-upgrade
are all on the first CD, to avoid disk swapping. Seems like a
reasonable goal if it doesn't drive too much else off CD #1. My
particular interest was to ensure that ssh & gnupg were both on CD#1
for CDs with non-US, since those two packages are the main reason for
doing non-US sets.
I suppose the right way to do this is to make all the packages listed
priority standard or higher.
> > I put Anne's upgrade-i386 directory in place on my mirror, and made
> > the i386 upgrade.sh use it. (the static binaries should probably be
>
> Well, I won't commit such a change until the upgrade dir is available on
> the official mirror.
Fair enough.
> > The build process displays the size used for the base system.
>
> Yes, but that's only packages of priority required, important & standard.
> It doesn't count the disks-$arch directory. Please check the latest
> build_all.sh script in the CVS. Ben commited a change that will calculate
> on the fly the "good" size. It does simply take an arbitrary limit (630MB)
> and removes the size of the disks-$arch directory.
Excellent.
Cheers, Phil.
Reply to: