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

Sat Apr 13 23:57:48 UTC 2019

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/baf455d3/attachment.html>