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

Re: Patch to tidy up wget use, and add return=4 when 404's are seen

On Thu, Mar 13, 2008 at 11:58:32PM +0100, Frans Pop wrote:
> On Thursday 13 March 2008, Philip Hands wrote:
> > OK, the next attempt:
> >   http://hands.com/~phil/d-i/fetch-url-2.diff
> >   http://hands.com/~phil/d-i/wget404-2.diff
> Almost there...

Jolly Good (and thanks for spotting the goofs reintroduced by my git fumble)

> +++ b/packages/debian-installer-utils/README
> +  -r  repeat failed attempts (currently up to 3 times)
> -r only repeats 2 times in current code. IMO that should be enough.
> The rationale is that it makes more sense to do an additional repeat if you 
> got at least something than when you got an outright failure. So, 2 full 
> attempts and 3 continuation retries.
> (same goes for README.preseed_fetch)

Yeah, I think I had a better version than that at one point, but I think
it's now better than it ever was so that's good.

> For -c I'm missing the comment that it should only be used if the 
> correctness of the file can be checked (as in README.preseed_fetch).


> Maybe reduce the duplication between debian-installer-utils/README and 
> README.preseed_fetch a bit (just refer to the first in the second)?


> +++ b/packages/debian-installer-utils/fetch-url
> The vars ALLOW_CONTINUES and DO_REPEAT should be initialized.
> I'd suggest to initialize to "", then set to 1. We can then just test for
> [ "$DO_REPEAT" ] (i.e. without ' = yes').

Fair enough -- done.

> +++ b/packages/preseed/debian/changelog
> +  * split out fetch-url from preseed_fetch to allow for
> +    it's use for downloading without interfering with the
> +    preseed relative path magic
> s/it's/its/

well spotted :-)

> > P.S.  I did something a little odd with git earlier -- while I'm 99%
> > certain I've got back to where I was, I've not had chance to do all the
> > tests to make sure -- please point out anything that looks out of place.
> Yeah, git is really, really great once you learn to work with it, but in the 
> beginning it can trip you up. Early on I lost about 4 hours work one time 
> (which I managed to reproduce in about 45 minutes :-). But it was a great 
> help with the complex patch set I just did for localechooser, allowing to 
> fix mistakes in earlier patches, change the order of patches, etc.

Yeah, I'm _really_ liking it so far -- actually, I did something with git reset 
that seemed to be a mistake, but was very encouraged to find that git
fsck showed me the lost branches (mostly) so I get the impression that
you have to do something pretty radical to really lose work.

> - second patch has bogus changelog entry for preseed (you don't change
>   anything there)

Yeah, that was a hangover from the lost patch I'm thinking.

> - the second patch should not open new changelog entry for di-utils, but
>   just add to the one opened in the first patch; they have to be separate
>   commits, not separate uploads

Wasn't sure about that -- fixed.

So, here we go again:


Cheers, Phil.
|)|  Philip Hands [+44 (0)20 8530 9560]    http://www.hands.com/
|-|  HANDS.COM Ltd.                    http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND

Reply to: