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
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:
|)| 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