Postfix 2.2.7, 1 (portupgrade from 2.2.5_1, 1) on FreeBSD 5 stable

RW list-freebsd-2004 at morbius.sent.com
Wed Dec 28 10:37:36 PST 2005


On Sunday 25 December 2005 00:31, Mike Edenfield wrote:
> Yuval Levy wrote:
> > Thank you very much for your support. I think I solved my problem and I
> > hope that what I found will help others, so here it is, in painful
> > detail, with some questions raised.
> >
> > => Attempting to fetch from http://web.onda.com.br/nadal/postfix/VDA/.
> > fetch: postfix-2.2.5-vda.patch.gz: local modification time does not
> > match remote
>
> This error indicates the real cause of your problem.  It
> means that fetch had previously downloaded a portion of the
> file in question, but for some reason did not complete the
> download.  When it attemps to resume the download it is now
> complaining that the remote file has been modified since the
> local file was originally fetched, so it cannot resume the
> download.  The reason why fetch doesn't do the obvious here
> and simply delete the local file and start over is something
> I can't answer, but it doesn't.  It skips that download site
> and moves on.
>
> > Since it starts to become clear to me that I will not be able to simply
> > portupgrade, I tried a radical approach:
> >
> > cd /usr/ports/mail/postfix
> > make distclean
>
> This was actually the correct fix.  You cleaned out whatever
> partially downloaded file fetch was complaining about, so
> that the next time you ran portupgrade it was able to
> re-download the entire file cleanly.  Alternately you could
> have simply done:
>
> rm /usr/ports/distfiles/postfix-2.2.5-vda.patch.gz

I used to get this problem a lot when I used a dialup account with 
auto-disconnection. The first few time I did what you suggested above, and 
deleted the partial file.  However I then started manually resuming it, and 
eventually added the following to make.conf:

FETCH_CMD=   fetch -FARr

The -F flag tells fetch to simply ignore the timestamp.

In practice I found that the download would go on to pass the MD5 check over 
90% of the time. On the few occasions it failed, someone had modified the 
source and it was out of sync with the port MD5 value, so deletion would not 
have worked either.



More information about the freebsd-ports mailing list