Hi Dave et al. I repeated the curl. The md5 checks: the xfer was completed correctly.
Advice welcome! Sam — Sam Finn [email protected] <mailto:[email protected]> > On Apr 13, 2019, at 5:57 PM, Dave Allured - NOAA Affiliate via macports-users > <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 > <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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> >> >>> On Apr 11, 2019, at 4:57 PM, Ryan Schmidt <[email protected] >>> <mailto:[email protected]>> 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.
signature.asc
Description: Message signed with OpenPGP
