On Sun, May 17, 2015 at 08:18:06AM -0400, Alan Corey wrote:
> I don't think it did this back in 5.0 days or maybe earlier. I started
> with OpenBSD 2.7, I just usually attributed problems to being my fault.
> And I've always used the ports tree, not packages. Distfiles are often
> useful across OpenBSD versions, sometimes in FreeBSD, I've even built some
> under Linux.
>
> I didn't look at what FETCH_CMD was defined as by default, I just assumed
> defining something non-null changed it. I did notice that when it retries
> it's wrongly assumed there's a problem with the first source and gone to
> another.
>
> Does every developer have perfect internet? That's very frustrating, maybe
> counterproductive in testing. Try a modem, you can probably find a free
> one. Connection interruptions and resets happen many times a day.
> On May 17, 2015 1:22 AM, "Marc Espie" <[email protected]> wrote:
Why are you ranting instead of providing the info I'm asking for ?!!!
JUST OVERRIDE THE DAMN FETCH_CMD!!!
put
FETCH_CMD = /usr/bin/ftp -v ${_PROGRESS} -k ${FTP_KEEPALIVE} -C
in /etc/mk.conf
so that *at least* we can see verbose output from your fetches.
Like I said, *the error comes from ftp*.
More accurately, fetch itself has the following logic:
for site in list
do
if FETCH_CMD -o file.part ${site}url
then
ck=`check_size file.part.part`
-> leading to "size does not match, hence rm file.part, hence retry"
fi
done
this is where your problem lies: ftp returns "everything okay", so the logic
assumes the file retrieved correctly, and when it finds out the size does not
match, it assumes a corrupted mirror, and hence deletes the partial file.
ftp(1)'s code is awful. I'm not wading thru those waters without more info.
GIVE ME WHATEVER FTP IS SAYING WHEN THINGS BREAK, when you tell it to be
verbose.
