Hm, maybe something like that indeed. I was seeing WinRPM/cache/1/*-primary.xml end up in binary, but it looked correct after unzipping it. Things appear to be working okay now though, except for a failure to satisfy library group cairo on 32-bit. RPM package zlib1 can't provide the library, I can't tell why not.
Is the right way to reset WinRPM's cache by deleting the index file and all subfolders in WinRPM/cache? On Saturday, September 27, 2014 9:12:42 PM UTC-7, Jameson wrote: > > Perhaps you managed to hit the server at a point where it was updating the > repomd.xml file, so it returned a 404 error when you tried to get the > primary.xml.gz file. You could also look in WinRPM/cache/2/*-primary.xml to > see what it looks like > > On Sat, Sep 27, 2014 at 11:57 PM, Tony Kelman <[email protected] > <javascript:>> wrote: > >> I've been seeing this too, it's something wrong in WinRPM. I haven't >> gotten to the bottom of it yet, but it might be that something changed in >> the openSUSE build service repodata xml formatting. I've been trying to >> step through the WinRPM.update() source line by line (wishing we had Keno's >> debugger a little faster...) but not sure exactly where it's going wrong. >> That function's only about 70 lines long, see here >> https://github.com/JuliaLang/WinRPM.jl/blob/c9282d4003c6eee937ca3e0bdf025becf93709b6/src/WinRPM.jl#L124-L190 >> >> >> On Friday, September 26, 2014 1:12:51 AM UTC-7, Daniel Høegh wrote: >>> >>> My versioninfo is: >>> >>> julia> versioninfo() >>> Julia Version 0.3.1 >>> Commit c03f413* (2014-09-21 21:30 UTC) >>> Platform Info: >>> System: Windows (x86_64-w64-mingw32) >>> CPU: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz >>> WORD_SIZE: 64 >>> BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge) >>> LAPACK: libopenblas >>> LIBM: libopenlibm >>> LLVM: libLLVM-3.3 >>> >> >
