To reproduce

Browse to http://jruby.org/download, pick any version and it fails

As a short-term solution, you can still find all downloads on the Maven mirror until S3 is fixed http://central.maven.org/maven2/org/jruby/jruby-dist

@original-brownbear thanks! but just fyi - the S3 URL is used in many automated places such as jruby gem, logstash, AUR packages, CI builds, etc. Thank you for offering the alternative, but we're experiencing the latter...

@original-brownbear @jakelandis this seems to be fixed, thx!

@original-brownbear oops!

  rake aborted!
  SHA1 does not match (expected '4a24fe103d3735b23cc58668dec711857125a6f3' but got '3eecaa09c780ece6e2cc2e51aa6101185b02410d')
  /logstash/rakelib/fetch.rake:14:in `fetch'
  /logstash/rakelib/fetch.rake:28:in `rescue in block in file_fetch'
  /logstash/rakelib/fetch.rake:22:in `block in file_fetch'
  /logstash/rakelib/fetch.rake:30:in `file_fetch'
  /logstash/rakelib/vendor.rake:77:in `block (2 levels) in <top (required)>'
  /logstash/rakelib/z_rubycheck.rake:28:in `<top (required)>'
  /usr/local/share/gems/gems/rake-12.1.0/exe/rake:27:in `<top (required)>'
  Tasks: TOP => vendor/_/jruby-bin-1.7.27.tar.gz
  (See full trace by running task with --trace)
  Downloading http://jruby.org.s3.amazonaws.com/downloads/1.7.27/jruby-bin-1.7.27.tar.gz

Looks like the signature of the file changed for the same version. Unfortunately there are many many lock files that are scattered across the internet which use the SHA1. And these include older versions of software, the one above is a logstash very recent released tag. People can make changes but that will only affect new releases going forward, old releases will remain broken.

Is there any way we can get the same original version back?

@rdsubhas sorry, I'm not a maintainer here, you'd have to ping @headius for that I think.

@jakelandis as far as we're concerned all seems well. 9.1.13.0 kept the same hash and our builds work again as far as I can tell,

no scratch the above, Jruby 9.1.10.0 download from RVM is still broken it seems.

@original-brownbear @rdsubhas @jakelandis At this point we are trying ot figure out why the buckets disappeared so we are hoping we can restore them.

However, I am in Japan and I think I have many/most older versions archived but they are at home and I will not be near them for more than a week.

I rebuilt 1.7.27 and pushed it so the links work but because it was a new build the checksums/fingerprints are different. So short term the only possible path for 1.7 to advertise correctly is to version 1.7.27 to 1.7.28 and push out a version number only release. Do people have suggestions?

@headius also is in japan but I am fairly sure he has none of the previous releases so unless we can restore from S3 then perhaps we need to consider what is acceptable for now with older releases...

@enebo it seems at least for 9k releases that the fingerprints of S3 and Maven at http://central.maven.org/maven2/org/jruby/jruby-dist/ are the same?
Maybe the same holds true for 1.7.x and you can just copy from Maven to S3?

@enebo it seems at least for the example about 1.7.27 the sha on Maven is correct http://central.maven.org/maven2/org/jruby/jruby-dist/1.7.27/jruby-dist-1.7.27-bin.tar.gz.sha1 contains the 4a24fe103d3735b23cc58668dec711857125a6f3 expected in #4789 (comment) :)

@enebo yep, sorry to hear, and the S3 bucket problem was bad luck. The only thing is, there are many branches and tags that reference .ruby-version: jruby-1.7.27 and I guess its hard or not possible to rewrite history of released versions. A quick search in github for "jruby-1.7.27" yields around 5k matches https://github.com/search?utf8=%E2%9C%93&q=jruby-1.7.27&type=Code and releasing new jruby 1.7.28 would only help future software releases (unless popular package managers like rbenv/brew/etc also change the hashes)

@original-brownbear thanks so much for checking this out! If this is true, then it would be great news since everything would continue to work without any change if @enebo can help us restore them :)

@original-brownbear ah nice! We can at least make the ruby managers happy again. I will fix 1.7.27 for now.

@rdsubhas @original-brownbear I restored 1.7.27 and I generated the sha256 for it again since maven did not have that but it should match (and I know at least one manager use sha256). I think tihs is ok for now. I sent an email to our mailing list and the current plan, for now, is to restore only versions people complain about (travel network makes being comprehensive unrealistic).

We also are thinking of moving off of S3 in the near future and adding windows installers as maven artifacts so our whole range of items is just sourced out of maven. This also will simplify our release process as a bonus.

@enebo thanks so much!

@enebo thanks, could us Logstash people also get 9.1.10.0 fixed please? :) We're using that one as part of our Travis bootstrapping (and it's hard to change that version for complicated reasons :D).

@original-brownbear I am out on the town in a typhoon right now. This might have to wait until morning but thanks for letting me know.

@original-brownbear uploaded 9.1.10.0.

Also uploaded other reported deps 9.1.8.0 and 1.7.25

@original-brownbear 9.1.10.0 is there.

So far this morning I updated 1.7.25, 9.1.5.0, 9.1.9.0, and 9.1.10.0. I may try and fill in some more likely missing releases today so we get less confusion although bandwitdh is not super.

@enebo nice thank you so much!

JRuby versions 1.7.23 and 1.7.24 are still broken. We are depending in at least one of our projects on 1.7.23 and are unable to do release builds at the moment.

If possible could you upload 1.7.19? Due to #3920 it's the latest 1.7.x release we can use, and we have lots of projects depending on it.

Are you going to restore older 1.7.x releases?

Quick note that JRuby 9.1.6.0 seems to be required to build the CF ruby buildpack. Please restore as well.

@iconara 1.7.19 restored
@andreas-kupries 9.1.6.0 restored

@enebo Please restore jruby-bin-9.2.0.0-SNAPSHOT.tar.gz aswell, it's what rbenv are using as dev build.

@enebo thanks for restoring 1.7.19, however there seems to be some problem with it, the checksum is wrong. See this Travis build for example: https://travis-ci.org/burtcorp/jara/jobs/277894267

$ rvm use jruby-1.7.19 --install --binary --fuzzy
jruby-1.7.19 is not installed - installing.
Searching for binary rubies, this might take some time.
Found remote file https://s3.amazonaws.com/jruby.org/downloads/1.7.19/jruby-bin-1.7.19.tar.gz
Checking requirements for ubuntu.
Requirements installation successful.
jruby-1.7.19 - #configure
jruby-1.7.19 - #download
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 31.1M  100 31.1M    0     0  49.0M      0 --:--:-- --:--:-- --:--:-- 48.9M
Downloaded archive checksum did not match, archive was removed!
If you wish to continue with not matching download add '--verify-downloads 2' after the command.

@iconara arrgh for some reason the fingerprint is different in this push than with what we uploaded to s3 but only so far for 1.7.19 :( I will say the current md5 is for a valid release of jruby 1.7.19 (it is safe via maven upload procedures). I could maybe open a PR to change it for rvm OR wait until I get back to US to see if I have this release backed up? Not entirely sure how to make this right atm

@andreas-kupries I got 9.1.9.0 restored. 9.1.6.0 does have a .zip src and unfortunately 1.7.26 has none. So if CF can trust me (meaning older fingerprints won't match) to push newer src tar balls I can generate new ones (for 9.1.6.0 I would probably unzip and tar that to keep the build as close as it could be to original release).

I am really hoping I have the backups at home (I had no idea that our S3 buckets were not set up with restore :( ), but at this point I just want main consumers working as soon as possible even if it is not perfect.

My Travis jobs are still failing due to JRuby tarball not available:

$ rvm use jruby --install --binary --fuzzy
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
jruby-9.1.13.0200 is not installed - installing.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Searching for binary rubies, this might take some time.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Requested binary installation but no rubies are available to download, consider skipping --binary flag.
Gemset '' does not exist, 'rvm jruby-9.1.13.0200 do rvm gemset create ' first, or append '--create'.

@enebo I've opened rvm/rvm#4183, we'll see what they say. I would not approve a PR like that :) but I hope the link back to your comment is enough proof.

Missed 1.7.16.1, 1.7.16.2 1.7.20.1. Restored

@jirutka That version number confuses me: jruby-9.1.13.0200. I don't know what the 200 means. Do you know?

Tihnking in terms of moving forward after I get back home. Whether I have backups or not we want to move all files into maven. Maven is mirrored to death and it also would simplify our distribution process. Since not all files we want exist within maven I am thinking I will make a version-only update to each release (e.g. 1.7.27 -> 1.7.27.1) and those jruby-dist artifacts would contain the missing things the ruby managers need. From 1.7.5 onward we seem to have bin.tar.gz which is enough for the ruby managers but I think we are missing proper fingerprinting (although rvm I think will accept md5 signatures so I think rvm can continue to serve from maven). None of these have the windows installer. Also src builds were zip files up to a certain point. So adding a .1 we can add consistent files and the fingerprints all ruby managers like.

The second part of that is updating ruby managers to look at these new urls. Maven repository can retrieve via https and the pattern itself is very consistent.

It would be great to get feedback on this. I want whatever we do to not cause disruption and also largely be heavily mirrored. The bonus of having one less release step is a huge bonus :)

@enebo - Thank you for restoring the 9.1.6.0 sources in general. Note however that I specified that the buildsystem I am working with consumes a tarball, not a zip archive. This means that while the sources are present they are not in a form the build system will see and use.

@iconara as mentioned in rvm bug 1.7.19 should be restored.

1.5.6 has been restored with original bits (believe it or not this is still being used in production!).

@enebo What about uploading all release tarballs to GitHub Releases in this repository? It’s easy to set up with Travis, reliable and discoverable.

@enebo - would it be possible to restore 9.0.5.0 Windows installer (http://jruby.org.s3.amazonaws.com/downloads/9.0.5.0/jruby_windows_x64_9_0_5_0.exe)?

Currently, a few of the JRuby chocolatey packages are pointing to that bucket. Let me know if there is anything I can do to help 😄

@occamsRZR Unfortunately, I have 9.0.4.0 and earlier but that was about when time machine stopped working on me. If you have a copy of this exe and we can figure out how to make sure it is valid I can upload that. The second option is I can make a 9.0.4.1 and chocolately can get updated to that.

A second question would be to wonder if they should just drop support for 9.0.4.0 since it is old and 9.1.x series should be a drop-in for it in any case I can think of. @occamsRZR if you can email me tom dot enebo gmail we can discuss more options too.

@enebo @headius seems the bucket is broken right now (permissions seem wrong now) right?

@original-brownbear was just going to write regarding same stuff, builds broken : /

Update: The downloads on the first Downloads page are available again.

Yeah sorry....update @headius restored a permissions flip and we are communicating to figure out why this happened.

rvm still wants to use the 0200 version:

$ rvm use jruby --install --binary --fuzzy
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
Unknown ruby string (do not know how to handle): jruby-9.1.13.0200.
jruby-9.1.13.0200 is not installed - installing.

This ultimately fails to install and thus fails a Travis CI job for rvm: - jruby

https://travis-ci.org/rickhull/device_input/jobs/290743844#L439

Most historic builds of JRuby have been restored to downloads, so I'm calling this fixed from our end.

We have no idea where the "0200" version number would come from, so I think the best we can do is toss this back to the rvm issue and hope someone can look into it from there. If it is determined to be a JRuby or jruby.org problem, file a new issue.