BUG: If fetch fails don't leave com.apple.fetch in the state file

[cssdev@…]

I encountered a checksum error trying to install the libxml2 port. The problem is that the downloaded file is a web page, not the binary archive. The fetch phase does not seem to properly download the archive. The actual error I received was a checksum error (output included below), but closer inspection reveal the downloaded file as HTML.

$ sudo port -v checksum libxml2
--->  Fetching libxml2
--->  libxml2-2.6.23.tar.bz2 doesn't seem to exist in /opt/local/var/db/dports/distfiles/libxml2
--->  Attempting to fetch libxml2-2.6.23.tar.bz2 from http://www.gtlib.cc.gatech.edu/pub/gnome/sources/libxml2/2.6/

--->  Attempting to fetch libxml2-2.6.23.tar.bz2 from http://public.planetmirror.com/pub/gnome/sources/libxml2/2.6/
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 29399    0 29399    0     0   9215      0 --:--:--  0:00:03 --:--:-- 13829
--->  Verifying checksum(s) for libxml2
--->  Checksumming libxml2-2.6.23.tar.bz2
Error: Checksum (rmd160) mismatch for libxml2-2.6.23.tar.bz2
Portfile checksum: libxml2-2.6.23.tar.bz2 rmd160 6cca60b81f56101e42c7f9a8529f5c6f34e4b49f
Distfile checksum: libxml2-2.6.23.tar.bz2 rmd160 2a7a0a71d21dab7688517f454839d426a9443830
Error: Target com.apple.checksum returned: Unable to verify file checksums
Warning: the following items did not execute (for libxml2): com.apple.checksum
Error: /opt/local/bin/port: Status 1 encountered during processing.
$ port version && uname -a
Version: 1.211
Darwin vecsigma.local 8.6.0 Darwin Kernel Version 8.6.0: Tue Mar  7 16:58:48 PST 2006; root:xnu-792.6.70.obj~1/RELEASE_PPC Power Macintosh powerpc

[rhwood@…]

HTML document returned with above name.

[rhwood@…]

The fast workaround would be to remove the planetmirror.com entry or entries from /opt/local/share/darwinports/resources/port1.0/fetch/mirror_sites.tcl

This file includes a HTTP redirect within the HTML, but I do not know if the HTTP response header includes the redirect or not. Is it possible that libcurl is ignoring HTTP redirects?

[dwddarwin@…]

I just started a new opendarwin installation from scratch yesterday on my new Macbook Pro (intel processor with Tiger 10.4.6), and the problem reported here is still happening: for gnome packages, www.gtlib.cc.gatech.edu is not responding and files loaded from public.planetmirror.com are getting a bad checksum. What's worse is that the installation is left in a bad state that it can't automatically recover from. It gets errors like this:

---> Verifying checksum(s) for gail Error: Target com.apple.checksum returned: Could not open file: /opt/local/var/db/dports/distfiles/gail/gail-1.8.11.tar.bz2 Error: /opt/local/bin/port: Status 1 encountered during processing.

I found I needed to remove the line "com.apple.fetch" from /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_gnome_gail/work/.darwinports.gail.state to allow it to try again. And yes, I found that I needed to change the mirrors.tcl file to avoid the planetmirror.com. I think it ought to continue trying other mirrors if a checksum fails.

In summary, I'm suggesting 3 things:

1. If a fetch fails (or maybe it's the checksum failing that's the problem), don't leave com.apple.fetch in the state file.
2. If a checksum fails after download, continue to try other mirrors.
3. Change the mirrors.tcl list for gnome to move or remove planetmirror and gatech.

[markd@…]

It appears that planetmirror has been removed from gnomes sources. I think the other suggestions are duplicated in ticket #2409 so I think this one should now be marked a duplicate of #2409. Or if not that 2409 could be marked a duplicate of this one.

[markd@…]

This one is described better so I makerd #2409 as the duplicate.

[jmpp@…]

This report is invalid because, as far as MacPorts knows, the fetch stage completed successfully, it went out into the net and got something in for us to work with. Issue here is that the downloaded file is not really what it should be, and therefore checksuming it fails, as it should (same case when we download a real tarball that happens to be a tampered with one rather than the official... fetch can't discern here and therefore we move on to checksuming it to validate what we got). The fetch stage really has no mean to discover what's at fault.

The proper course of action is to investigate what went wrong and why checksuming failed, moving on accordingly from there (opening a new ticket to report whatever problem is found ;-).

-jmpp