WinRPM.update() error reporting error code: 2148270085

[hustf]

It hurts, sometimes, to use Windows. A related issue: #44

I tried the tagged version, master and nothttpclient branch. Same errors:

julia> WinRPM.update()
INFO: Downloading https://cache.e.ip.saba.us/http:https://download.opensuse.org/reposi
tories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
WARNING: Unknown download failure, error code: 2148270085
WARNING: Retry 1/5 downloading: https://cache.e.ip.saba.us/http:https://download.opens
use.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
WARNING: Unknown download failure, error code: 2148270085
(...repeated 5 times) 
WARNING: received error 0 while downloading https://cache.e.ip.saba.us/http:https://do
wnload.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/re
pomd.xml
(...all of the above repeated, but win32 replaced by win64) 

Context:

Julia 0.4.0 Windows 8.1 64 bit
C:\Users\Fro>ping cache.e.ip.saba.us
Ping request could not find host cache.e.ip.saba.us. Please check the name and t
ry again.

C:\Users\Fro>ping download.opensuse.org

Pinging download.opensuse.org [2001:67c:2178:8::13] with 32 bytes of data:
Reply from 2001:67c:2178:8::13: time=58ms
Reply from 2001:67c:2178:8::13: time=58ms
Reply from 2001:67c:2178:8::13: time=58ms
Reply from 2001:67c:2178:8::13: time=58ms

Ping statistics for 2001:67c:2178:8::13:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 58ms, Maximum = 58ms, Average = 58ms

[tkelman]

Try deleting https://cache.e.ip.saba.us/ from your local sources.list. @staticfloat your cache server is down, any idea what's up?

[staticfloat]

DNS server went down, but it's back up again now. It's using my personal dynamic DNS server which isn't the stablest of things in the world. @StefanKarpinski is there a way we can get an A record to point cache.julialang.org -> 128.52.178.53? That should be stable as long as I don't destroy the cache server on OpenStack.

[hustf]

It works now, thanks. And thanks for the use of you personal server.
If you enable ping requests, that could perhaps be used as a time saver for WinRPM, and opting for a backup url?
Current ping:

C:\Users\Fro>ping cache.e.ip.saba.us

Pinging cache.e.ip.saba.us [128.52.178.53] with 32 bytes of data:
Request timed out.

[staticfloat]

Since ping's could work while the server process itself is down, my suggested method to check whether the caching server is working or not is to simply visit the cache listing page (https://cache.e.ip.saba.us/).

[tkelman]

@StefanKarpinski another ping on a related DNS issue: #57 (comment)

[cpminor]

I am having the same issue (Julia 0.4.0 / Win 7 / 64 bit) - failing to download file repomd.xml as above - but with error code: 2148270088. I removed the reference to the cache site from sources.list file in dir WinRPM. Confirmed that

http:https://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml

is a valid file. Neither worked. Fixed issue by following the fix provided in related issue #44. Replaced the sites in sources.list with the Warwick sites. Worked!

[tkelman]

Roughly where are you physically located? The opensuse mirrors are a little flaky, and we explicitly don't mirror that top repomd.xml file since it gets auto-updated frequently.

[tkelman]

The cache server is down again. @StefanKarpinski we need you to do something about this.

[cpminor]

@tkelman
I am working in the U.S. north east. I was able to view and download what looks like a functional version of the repomd.xml file from the opensuse.org server in a browser, but was getting the return code error both with and without the reference to the cache in the links to opensuse.org in WinRPM's sources.list when trying to use WinRPM to install binaries needed for Gadfly, HDF5, and other packages.

[tkelman]

@cpminor if the normal link doesn't work but changing to a different mirror does, I think that may be an issue on opensuse's side? Though it's worth trying some of the workarounds as in #40 (comment) of using a different download command, either curl or powershell rather than the IE API that's being used here. Long-term I think all of the downloading that this package, BinDeps, and Base.download are doing needs to be refactored to work more reliably.

[cpminor]

@tkelman - given that both the cached version and the opensuse versions of the file give an error when the file is both downloadable and human readable makes me think that an errant line return or binary character slipped in somewhere. WinRPM doesn't attempt any file cleanup (like running text files through *nix tr -d "\15\32" < file > file_new to remove errant ^M's from Windows contamination - a problem I have seen recently trying to compile other open source packages in Cygwin) it just bails out on any non-zero return code. I am also working from behind a proxy and haven't had any issues with Pkg functions after setting up proxy environment variables for git. A unified downloading mechanism with sensible fall backs seems like the best choice, aka the discussion at #40 (comment). I also wonder if the file couldn't be cached locally for some period of time as a further fall back.

[tkelman]

The file is downloadable and human readable through your browser, but browsers go to a lot of effort to work properly with proxy settings. The error code you were seeing translates to INET_E_DOWNLOAD_FAILURE - https://msdn.microsoft.com/en-us/library/ms775145(v=vs.85).aspx, whereas the initially reported error was INET_E_RESOURCE_NOT_FOUND.

[cpminor]

@tkelman Nice work! I was looking for that error code myself and could not find it. My proxy settings are in both git config and Windows environment variables, and they seem to be working downloading non-WinRPM managed packages and to Warwick site (and others as well). But I am certainly not an expert on IE or Windows with proxy settings, so there could be an issue there I am just not yet aware of.

[digital-carver]

I got the same WARNING messages as @hustf , except the error code in my case was 2148270105. This is on Windows 7 64-bit, with Julia version 0.4.2.

Removing the two cache.e.ip.saba.us lines and replacing those with

http:https://ftp5.gwdg.de/pub/opensuse/repositories/windows:/mingw:/win32/openSUSE_Factory/
http:https://ftp5.gwdg.de/pub/opensuse/repositories/windows:/mingw:/win64/openSUSE_Factory/

(as suggested in this thread) seems to have resolved the problem.

[nalimilan]

I see the same problem (error 2148270088, INET_E_DOWNLOAD_FAILURE) on a Windows 7 64-bit machine at my lab here. Neither removing the cache.e.ip.saba.us part nor moving to ftp5.gwdg.de made any difference, with either HTTPS or HTTP. Calling download on these URLs gives the same error. FWIW, I can browse these addresses just fine in both IE and Firefox.

If I pass a URL to a non-existent file, I get error 2148270086 (INET_E_OBJECT_NOT_FOUND) instead. So things are not completely broken. Also, if I use FTP instead of HTTP, Base.download returns without any error and without creating any file; but WinRPM.download (which uses URLDownloadToCacheFileW) still fails.

FWIW, downloads work from R, which uses InternetOpenUrl (with flags INTERNET_FLAG_KEEP_CONNECTION and INTERNET_FLAG_NO_CACHE_WRITE). It could be interesting to test another version based on this API for testing.

I've done a lot of research, but I couldn't find much information. Here are a few possibly interesting links:

• An old page giving many different tricks to fix this error (didn't work for me, for the ones I tried): http:https://www3.telus.net/dandemar/0x800c0005.htm
• A mention that disabling the firewall worked: http:https://www.cplusplus.com/forum/windows/53113/
• A mention that the same error happens when the file already exists: https://social.msdn.microsoft.com/Forums/ie/en-US/3cf61a91-2d23-4f05-aa78-462086078151/urldownloadtofile-returns-0x800c0008-when-the-local-file-already-exists-it-does-not-overwrite-the?forum=ieextensiondevelopment

[pfitzseb]

Just as another data point: I'm getting a similar error, error code: 2148270094, on several Windows machines in the uni network and deleting the cache prefix in sources.list gets rid of it.

[cpminor]

I recently had another round of download failures with WinRPM.jl as well. I was able to fix it by using the ftp5.gwdg.de site with FTP protocol in place of HTTP or HTTPS. So my sources.list file is now:
ftp:https://ftp5.gwdg.de/pub/opensuse/repositories/windows:/mingw:/win32/openSUSE_Factory/
ftp:https://ftp5.gwdg.de/pub/opensuse/repositories/windows:/mingw:/win64/openSUSE_Factory/

 ----------------------Christian [email protected]

On Monday, January 11, 2016 8:50 AM, Milan Bouchet-Valat <[email protected]> wrote:

I see the same problem (error 2148270088, INET_E_DOWNLOAD_FAILURE) on a Windows 7 64-bit machine at my lab here. Neither removing the cache.e.ip.saba.us part nor moving to ftp5.gwdg.de made any difference, with either HTTPS or HTTP. Calling download on these URLs gives the same error. FWIW, I can browse these addresses just fine in both IE and Firefox.If I pass a URL to a non-existent file, I get error 2148270086 (INET_E_OBJECT_NOT_FOUND) instead. So things are not completely broken. Also, if I use FTP instead of HTTP, Base.download returns without any error and without creating any file; but WinRPM.download (which uses URLDownloadToCacheFileW) still fails.FWIW, downloads work from R, which uses InternetOpenUrl (with flags INTERNET_FLAG_KEEP_CONNECTION and INTERNET_FLAG_NO_CACHE_WRITE). It could be interesting to test another version based on this API for testing.I've done a lot of research, but I couldn't find much information. Here are a few possibly interesting links:

• An old page giving many different tricks to fix this error (didn't work for me, for the ones I tried): http:https://www3.telus.net/dandemar/0x800c0005.htm
• A mention that disabling the firewall worked: http:https://www.cplusplus.com/forum/windows/53113/
• A mention that the same error happens when the file already exists: https://social.msdn.microsoft.com/Forums/ie/en-US/3cf61a91-2d23-4f05-aa78-462086078151/urldownloadtofile-returns-0x800c0008-when-the-local-file-already-exists-it-does-not-overwrite-the?forum=ieextensiondevelopment
  —
  Reply to this email directly or view it on GitHub.

[nalimilan]

@pfitzseb That's the same error code as JuliaInterop/ZMQ.jl#90. (But note that you should also ensure you're using the latest WinRPM version, as the old caching server's certificate expired: a new server needs to be used.)

[pfitzseb]

Thanks @nalimilan, it seems most probably that that's the issue I'm seeing also. WinRPM is up to date, but I'm on Windows Server 2016, so the Enhanced Security thingy in IE is there as well.

[isuruf]

Same error on appveyor as well. https://ci.appveyor.com/project/isuruf/symengine-jl/build/1.0.6/job/gbemo86fo8niqjws

[nalimilan]

We keep getting reports about this, we really need to find a solution or at least a workaround.

[ssfrr]

I'm seeing this on Appveyor right now, but with error code 2148270105: https://ci.appveyor.com/project/ssfrr/portaudio-jl/build/1.0.39/job/6j3wy392wh0qbyna

It's been non-functional for the last 12 hours or so. Is there any workaround?

[pfitzseb]

That error seems to indicate a INET_E_INVALID_CERTIFICATE (with 2148270105 == Int(0x800C0019)). Seems to be a server side issue, I guess?

[staticfloat]

If it's an invalid certificate, it might be SSL versioning problems. We just recently ran into a rash of problems as various services on the internet move away from older SSL versions and start accepting only modern ciphers such as those within TLS 1.1+. Powershell, for example, by default does not enable these modern ciphers unless you ask nicely with a line such as this one.

That being said, I can't imagine this is exactly that problem, because you're asking for an http:https:// url from the caching server, and it should be HTTP 301'ing you directly on to the source for all those repomd.xml files. So unless there's a problem with appveyor being able to connect to the cache.julialang.org server (there shouldn't be; everybody should be able to communicate over TLS 1.0, which the caching server supports) I'm not sure where this error is coming from.

Do those WinRPM operations work locally on your device?

[staticfloat]

Huh, another thing to look at is that requests for WinRPM have been coming in with weird data, perhaps there is some kind of data corruption happening to the requests. I regularly log things like

"GET /http:https://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_42.2/repodata/0a9a98ccc672b646a0694a73cc890d253c689e14ecf8413bf3dc09388fbf98dc-primary.xml.gz???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? HTTP/1.0"

on the caching server side.

[ssfrr]

my issue seems to be resolved now on appveyor. I didn't get to a windows machine in time to check whether it was broken locally.

[skanskan]

I solved the problem editing the file sources.list and removing the string

https://cache.julialang.org/

That means replacing

https://cache.julialang.org/http:https://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Leap_42.2
with
http:https://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Leap_42.2