Cache binaries for MIRA 4.9.6

[peterjc]

Cache the current latest MIRA development binaries, which I want to use from https://github.com/peterjc/galaxy_mira/blob/master/packages/package_mira_4_9_6/tool_dependencies.xml

Also recording the original URLs for MIRA 4.0.2 (still live) and MIRA 4.9.5 (defunct), which seem more useful than the /srv/nginx/... internal path which I assume was an implementation detail?

[peterjc]

See #82 about recording the old URLs in urls.tsv

[hexylena]

x64

[peterjc]

Thanks... will fix and rebase.

[hexylena]

seem more useful than the /srv/nginx/... internal path which I assume was an implementation detail?

we imported a number of packages that were on depot before but in an uncategorized fashion, so, yes, implementation detail.

[peterjc]

The URL http://downloads.sourceforge.net/project/mira-assembler/MIRA/development/mira_4.9.5_2_linux-gnu_x86_64_static.tar.bz2 is defunct (giving an Error 404), but it seems TravisCI still attempts to verify the checksum...

[hexylena]

@peterjc yes, this is true. In these cases we will gladly merge despite such complaints from Travis since this is the minority of cases.

[peterjc]

It looks a bit fiddly to get the shell one-liner in https://github.com/galaxyproject/cargo-port/blob/master/.ci/check.sh to add an if condition to skip Error 404 URLs...

[peterjc]

Rebased fixing the typo, and without the MIRA 4.9.5 URL change which broke TravisCI

[hexylena]

Invalid hash for http://downloads.sourceforge.net/project/mira-assembler/MIRA/development/mira_4.9.6_darwin15.4.0_x86_64_static.tar.bz2

other than this error, it looks ready to go

[peterjc]

I'm confused,

$ curl -L http://downloads.sourceforge.net/project/mira-assembler/MIRA/development/mira_4.9.6_darwin15.4.0_x86_64_static.tar.bz2 | shasum -a 256
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0   419    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 19.7M  100 19.7M    0     0  8595k      0  0:00:02  0:00:02 --:--:-- 10.7M
3d0bb15adad0e1e27899d21223cb552968d34d35ad9b1184e85832fc0b3d22ce  -

and:

$ curl -L http://downloads.sourceforge.net/project/mira-assembler/MIRA/development/mira_4.9.6_linux-gnu_x86_64_static.tar.bz2  | shasum -a 256
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0   409    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 19.7M  100 19.7M    0     0  9596k      0  0:00:02  0:00:02 --:--:-- 11.1M
3c2c343a75045c2c69cb4aba283821d6e82202c37792af886aab0002a8194dee  -

Could SourceForge be doing something odd with different mirrors? Do you get the same checksums?

[bgruening]

Grr, I had this before and could not explain it. SourceForge does some crazy things in the background. I have seen mirrors going from https to http and returning different checksums :(

[peterjc]

Wow. The good news here is that for me from work, http and https give we the same checksum from SourceForge.

It would help if the TravisCI test reported a little more information - even if this means rewriting the one-liner into a bash loop or even switching it to Python?

[hexylena]

It would help if the TravisCI test reported a little more information - even if this means rewriting the one-liner into a bash loop or even switching it to Python?

yeah, this had been on the todo list for a while. Guess it is time.

[hexylena]

Ok, I have replaced the stupid bash oneline I wrote whilst trying to be too clever with a proper script. I am still working out the details of it, but it looks like your URLs validate under an updated script.

[hexylena]

ERROR:root:File has bad hash! 3d0bb15adad0e1e27899d21223cb552968d34d35ad9b1184e85832fc0b3d22ce != .tar.bz2 in mira_4.9.6_darwin_x643d0bb15adad0e1e27899d21223cb552968d34d35ad9b1184e85832fc0b3d22ce
ERROR:root:File has bad hash! 3c2c343a75045c2c69cb4aba283821d6e82202c37792af886aab0002a8194dee != .tar.bz2 in mira_4.9.6_linux_x643c2c343a75045c2c69cb4aba283821d6e82202c37792af886aab0002a8194dee

your last two columns are mixed up. I'll add a check if it looks like a sha256, so we can warn about that much earlier in the process.

[peterjc]

Easily done - having the TravisCI script check the length of the hash field seems a simple addition.

I'll update this pull request (which will trigger a retest)

[hexylena]

easily done

dc44cfc now checks for sha256 like things :) Thanks for finding these bugs for us, and thank you for being patient while we fix them.

[peterjc]

We have a green light - thanks for improving the TravisCI checks here @erasche