"Fetching archive" fails for all ports on multiple systems, different networks

Dave Allured - NOAA Affiliate dave.allured at noaa.gov
Sun Apr 14 00:38:15 UTC 2019

Otherwise, I am a macports novice.  In the absence of better advice, I
would be inclined to some hacking along the lines of uninstalling and
reinstalling things.  Wait and see if there is better advice from those who
know macports internals.

On Sat, Apr 13, 2019 at 6:20 PM Lee Finn <lsfinn at gmail.com> wrote:

> Hi Dave et al.
> I repeated the curl. The md5 checks: the xfer was completed correctly.
> Advice welcome!
> Sam
> On Apr 13, 2019, at 5:57 PM, Dave Allured - NOAA Affiliate via
> macports-users <macports-users at lists.macports.org> wrote:
> I think you all are overlooking this report from a few days back.  The
> requested "curl" test passed on Sam's machine.  This strongly indicates a
> problem within Sam's Macports software, NOT a network problem.  Excerpt:
> On Mon, Apr 8, 2019 at 10:54 AM Lee Finn <lsfinn at gmail.com> wrote:
>> Hi Chris  ...  Thanks for your note  ...  Running the indicated command
>> gives the following:
>> Quedo [2] Yeah? curl -O -R
>> https://packages.macports.org/libiconv/libiconv-1.15_0.darwin_18.x86_64.tbz2
>>   % Total    % Received % Xferd  Average Speed   Time    Time     Time
>> Current
>>                                  Dload  Upload   Total   Spent    Left
>> Speed
>> 100 1471k  100 1471k    0     0  2719k      0 --:--:-- --:--:-- --:--:--
>> 2714k
> Without seeing checksums, this "Received 1471K " is a perfect result which
> replicates on my own mac.  Curl reads this archive with no trouble at all.
> Sam, if you want to double check this curl result:
> mac56:~/temp/curl 9> md5 libiconv-1.15_0.darwin_18.x86_64.tbz2
> MD5 (libiconv-1.15_0.darwin_18.x86_64.tbz2) =
> 9fe8db26b61e61d0c1b44401d602955b
> Either let me know how I am misreading this, or else take a closer look at
> Sam's Macports setup.  I hope this helps!
> --Dave
> On Sat, Apr 13, 2019 at 1:28 PM Chris Jones <jonesc at hep.phy.cam.ac.uk>
> wrote:
>> What network are you on ? Home or work ? Could something have changed
>> with that ?
>> On 13 Apr 2019, at 8:04 pm, Lee Finn <lsfinn at gmail.com> wrote:
>> Thank for your note.
>> A quick question: since everything was working up until 1 Apr (I
>> routinely update my macports every monday, and did so as recently as 25
>> Mar), is there anything you can advise I look to first? The only system
>> updates that I’m aware of in that week were the 10.14.4 and xCode 10.2
>> updates.
>> Thanks again,
>> Sam
>>>> Sam Finn
>> lsfinn at gmail.com
>> On Apr 11, 2019, at 4:57 PM, Ryan Schmidt <ryandesign at macports.org>
>> wrote:
>> On Apr 10, 2019, at 10:28, Lee Finn wrote:
>> Hi,
>> This is a more directed followup to an earlier message.  Three specific
>> questions:
>> * How should I interpret the error message  ":debug:archivefetch Fetching
>> archive failed: The requested URL returned error: 403 OK”, which appears in
>> the logfile for the installation of gettext?
>> - Further context: this error message occurs for all gettext servers on
>> two different networks (one a university network, one a home network) on
>> two different systems, over several days.
>> * Is anyone else seeing a similar or related problems? Please share
>> details: it will help me decide if this is somehow a local problem
>> (although it is happening on two independently maintained systems on two
>> different networks), or a macports problem for which a bug report should be
>> filed.
>> The web server appeared to return the response "403 OK". This is a
>> nonsensical response, since http standards tell us that "403" actually
>> means "Forbidden", while "200 OK" is the response you would get for a
>> normal successful file transfer. Since you get the same nonsensical
>> response from many servers managed by different organizations, it's logical
>> to conclude that the response is not actually coming from those servers but
>> from something intercepting the traffic between you and the servers -- such
>> as a badly-configured proxy managed by your network administrator, or
>> perhaps badly-written antivirus software installed on your computers which
>> is hooking itself into your network stream in an effort to protect you from
>> malicious content, or it could even be malware trying to modify your
>> network traffic for some nefarious purpose. Usually a workaround for
>> circumventing network interference is to use https, since man-in-the-middle
>> content modification is not possible with an encrypted data stream, but
>> your error messages in your previous message showed that even https traffic
>> was being modified; in the https cases, though, the modifications were
>> being detected as a bad ssl stream. The problem is unique to your computers
>> and/or your networks and you'll have to figure out what is modifying your
>> network traffic and how to stop it; there's nothing we can change in
>> MacPorts to fix this.
>> * “sudo port diagnose” reports "Error: currently installed version of
>> Xcode, 10.2, is not supported by MacPorts.  For your currently installed
>> system, only the following versions of Xcode are supported:  10.1 10.0”.
>> Trac #58260 suggests that this is a build problem; i.e., that it occurs
>> after a successful fetch step. Is this understanding correct?
>> Other information:
>> MacPorts 2.5.4
>> Mac OS 10.4.4
>> xCode 10.2
>> H/W: iMac Pro, MacBook Pro.
>> Xcode 10.2 was released recently and we had not yet added it to the list
>> of approved Xcode versions. Josh has since added it. It's usually fine to
>> use new Xcode versions. As you found in #58260, sometimes new versions of
>> Xcode cause build failures in some ports. As with any bug, these need to be
>> identified and addressed on a case by case basis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20190413/cff12ad2/attachment.html>

More information about the macports-users mailing list