[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 ?


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.


Cheers, Phil.

Reply to: