New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Downloads from http://jruby.org/download fail. #4789

Closed
jakelandis opened this Issue Sep 15, 2017 · 54 comments

Comments

Projects
None yet
@jakelandis

jakelandis commented Sep 15, 2017

Attempting to download any version from http://jruby.org/download fails with

<Error><Code>NoSuchKey</Code><Message>The specified key does not exist.</Message>
<Key>downloads/9.1.13.0/jruby-bin-9.1.13.0.tar.gz</Key>
<RequestId>CCC5FE1F7FB588EA</RequestId>
<HostId>ZPyGX2QdPAES2LYbDzVsB5q4j+AV15N6OArJj/TBPoNZY7BHAxKsmNeE/XW7v3N2LmyVF20d4zg=</HostId>
</Error>

There were S3 issues yesterday, but according to AWS status page, that should be resolved now.

@rdsubhas

This comment has been minimized.

Show comment
Hide comment
@rdsubhas

rdsubhas Sep 15, 2017

To reproduce

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

image

image

rdsubhas commented Sep 15, 2017

To reproduce

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

image

image

@original-brownbear

This comment has been minimized.

Show comment
Hide comment
@original-brownbear

original-brownbear Sep 15, 2017

Contributor

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

Contributor

original-brownbear commented Sep 15, 2017

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

@rdsubhas

This comment has been minimized.

Show comment
Hide comment
@rdsubhas

rdsubhas Sep 15, 2017

@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...

rdsubhas commented Sep 15, 2017

@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...

@rdsubhas

This comment has been minimized.

Show comment
Hide comment
@rdsubhas

rdsubhas Sep 16, 2017

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

rdsubhas commented Sep 16, 2017

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

@rdsubhas

This comment has been minimized.

Show comment
Hide comment
@rdsubhas

rdsubhas Sep 16, 2017

@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 commented Sep 16, 2017

@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?

@original-brownbear

This comment has been minimized.

Show comment
Hide comment
@original-brownbear

original-brownbear Sep 16, 2017

Contributor

@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,

Contributor

original-brownbear commented Sep 16, 2017

@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,

@original-brownbear

This comment has been minimized.

Show comment
Hide comment
@original-brownbear

original-brownbear Sep 16, 2017

Contributor

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

Contributor

original-brownbear commented Sep 16, 2017

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

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Sep 16, 2017

Member

@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...

Member

enebo commented Sep 16, 2017

@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...

@original-brownbear

This comment has been minimized.

Show comment
Hide comment
@original-brownbear

original-brownbear Sep 16, 2017

Contributor

@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?

Contributor

original-brownbear commented Sep 16, 2017

@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?

@original-brownbear

This comment has been minimized.

Show comment
Hide comment
@original-brownbear

original-brownbear Sep 16, 2017

Contributor

@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) :)

Contributor

original-brownbear commented Sep 16, 2017

@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) :)

@rdsubhas

This comment has been minimized.

Show comment
Hide comment
@rdsubhas

rdsubhas Sep 16, 2017

@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 :)

rdsubhas commented Sep 16, 2017

@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 :)

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Sep 16, 2017

Member

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

Member

enebo commented Sep 16, 2017

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

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Sep 16, 2017

Member

@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.

Member

enebo commented Sep 16, 2017

@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.

@rdsubhas

This comment has been minimized.

Show comment
Hide comment
@rdsubhas

rdsubhas Sep 16, 2017

@enebo thanks so much!

rdsubhas commented Sep 16, 2017

@enebo thanks so much!

@original-brownbear

This comment has been minimized.

Show comment
Hide comment
@original-brownbear

original-brownbear Sep 17, 2017

Contributor

@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).

Contributor

original-brownbear commented Sep 17, 2017

@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).

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Sep 17, 2017

Member

@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.

Member

enebo commented Sep 17, 2017

@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.

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Sep 17, 2017

Member

@original-brownbear uploaded 9.1.10.0.

Also uploaded other reported deps 9.1.8.0 and 1.7.25

Member

enebo commented Sep 17, 2017

@original-brownbear uploaded 9.1.10.0.

Also uploaded other reported deps 9.1.8.0 and 1.7.25

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Sep 17, 2017

Member

@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.

Member

enebo commented Sep 17, 2017

@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.

@original-brownbear

This comment has been minimized.

Show comment
Hide comment
@original-brownbear

original-brownbear Sep 17, 2017

Contributor

@enebo nice thank you so much!

Contributor

original-brownbear commented Sep 17, 2017

@enebo nice thank you so much!

@obfuscoder

This comment has been minimized.

Show comment
Hide comment
@obfuscoder

obfuscoder Sep 18, 2017

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.

obfuscoder commented Sep 18, 2017

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.

@iconara

This comment has been minimized.

Show comment
Hide comment
@iconara

iconara Sep 18, 2017

Contributor

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.

Contributor

iconara commented Sep 18, 2017

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.

@nicksieger

This comment has been minimized.

Show comment
Hide comment
@nicksieger
Member

nicksieger commented Sep 18, 2017

s3_management_console

@bbergstrom

This comment has been minimized.

Show comment
Hide comment
@bbergstrom

bbergstrom Sep 18, 2017

Are you going to restore older 1.7.x releases?

bbergstrom commented Sep 18, 2017

Are you going to restore older 1.7.x releases?

@andreas-kupries

This comment has been minimized.

Show comment
Hide comment
@andreas-kupries

andreas-kupries Sep 18, 2017

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

andreas-kupries commented Sep 18, 2017

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

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Sep 18, 2017

Member

@iconara 1.7.19 restored
@andreas-kupries 9.1.6.0 restored

Member

enebo commented Sep 18, 2017

@iconara 1.7.19 restored
@andreas-kupries 9.1.6.0 restored

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Sep 20, 2017

Member

@andreas-kupries...ok I think Maven-dist has this too so I will try and restore those...at conference today so this may take another day

Member

enebo commented Sep 20, 2017

@andreas-kupries...ok I think Maven-dist has this too so I will try and restore those...at conference today so this may take another day

@sandelius

This comment has been minimized.

Show comment
Hide comment
@sandelius

sandelius Sep 20, 2017

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

sandelius commented Sep 20, 2017

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

@iconara

This comment has been minimized.

Show comment
Hide comment
@iconara

iconara Sep 20, 2017

Contributor

@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.
Contributor

iconara commented Sep 20, 2017

@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.
@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Sep 20, 2017

Member

@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

Member

enebo commented Sep 20, 2017

@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

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Sep 21, 2017

Member

@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.

Member

enebo commented Sep 21, 2017

@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.

@jirutka

This comment has been minimized.

Show comment
Hide comment
@jirutka

jirutka Sep 21, 2017

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'.

jirutka commented Sep 21, 2017

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'.

iconara added a commit to iconara/rvm that referenced this issue Sep 21, 2017

Update the JRuby 1.7.19 checksums
All JRuby releases were recently lost (see jruby/jruby#4789) and the JRuby team has been scrambling to restore binaries over the last week. Most releases could be recovered from Maven Central, but unfortunately 1.7.19 seem to have gotten different checksums when released to Maven compared to what was previously in JRuby's own repository.

@enebo asserts in jruby/jruby#4789 (comment) that the file currently at https://s3.amazonaws.com/jruby.org/downloads/1.7.19/jruby-bin-1.7.23.tar.gz is an actual release of JRuby 1.7.19.

The checksums in this commit have been obtained by downloading that file and running `openssl dgst -sha512 FILE` and `openssl dgst -md5 FILE`
@iconara

This comment has been minimized.

Show comment
Hide comment
@iconara

iconara Sep 21, 2017

Contributor

@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.

Contributor

iconara commented Sep 21, 2017

@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.

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Sep 21, 2017

Member

Missed 1.7.16.1, 1.7.16.2 1.7.20.1. Restored

Member

enebo commented Sep 21, 2017

Missed 1.7.16.1, 1.7.16.2 1.7.20.1. Restored

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Sep 21, 2017

Member

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

Member

enebo commented Sep 21, 2017

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

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Sep 21, 2017

Member

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 :)

Member

enebo commented Sep 21, 2017

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 :)

@skalee skalee referenced this issue Sep 23, 2017

Closed

Failing builds #23

@andreas-kupries

This comment has been minimized.

Show comment
Hide comment
@andreas-kupries

andreas-kupries Sep 25, 2017

@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.

andreas-kupries commented Sep 25, 2017

@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.

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Sep 28, 2017

Member

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

Member

enebo commented Sep 28, 2017

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

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Sep 28, 2017

Member

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

Member

enebo commented Sep 28, 2017

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

@jirutka

This comment has been minimized.

Show comment
Hide comment
@jirutka

jirutka Sep 30, 2017

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

jirutka commented Sep 30, 2017

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

@kares kares added this to the Non-Release milestone Oct 4, 2017

@occamsRZR

This comment has been minimized.

Show comment
Hide comment
@occamsRZR

occamsRZR Oct 5, 2017

@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 commented Oct 5, 2017

@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 😄

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Oct 6, 2017

Member

@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.

Member

enebo commented Oct 6, 2017

@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.

@original-brownbear

This comment has been minimized.

Show comment
Hide comment
@original-brownbear

original-brownbear Oct 13, 2017

Contributor

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

Contributor

original-brownbear commented Oct 13, 2017

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

@driv3r

This comment has been minimized.

Show comment
Hide comment
@driv3r

driv3r Oct 13, 2017

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

driv3r commented Oct 13, 2017

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

@olleolleolle

This comment has been minimized.

Show comment
Hide comment
@olleolleolle

olleolleolle Oct 13, 2017

Contributor

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

Contributor

olleolleolle commented Oct 13, 2017

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

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Oct 13, 2017

Member

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

Member

enebo commented Oct 13, 2017

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

@rickhull

This comment has been minimized.

Show comment
Hide comment
@rickhull

rickhull Oct 21, 2017

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

rickhull commented Oct 21, 2017

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

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Oct 30, 2017

Member

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.

Member

headius commented Oct 30, 2017

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.

@headius headius closed this Oct 30, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment