I'm trying to publish an article to my blog on GitHub pages after a few months of absence, and am getting the following error:
Gem::InstallError: public_suffix requires Ruby version >= 2.0.
Installing sass 3.4.20
An error occurred while installing public_suffix (1.5.2), and Bundler cannot
continue.
Make sure that gem install public_suffix -v '1.5.2' succeeds before bundling.
However according to GitHub the Ruby version on GH pages is already > 2.0. Is there some programmatic change that I need to make in my blog's codebase to get this up and running?
This is the corresponding Gemfile:
source 'https://rubygems.org'
# A simple Ruby Gem to bootstrap dependencies for setting up and
# maintaining a local Jekyll environment in sync with GitHub Pages
# https://github.com/github/pages-gem
gem 'github-pages'
Try deleting your gemfile.lock and pull down the last working gemfile.lock file from your GitHub pages repo. (or just checkout the file from an earlier, working commit)
Most of the weird errors stem from the errors with the Gemfile.lock file, which is used to keep track of the versions of each Ruby Gem. Sometimes when running bundle update gems are attempted to be upgraded, which may break compatibility with other gems, at least that's what has happened to me before. Often times running bundle update causes some gems to be downgraded. As a temporary workaround to just get Jekyll to build locally, just revert the file to an earlier version.
Related
So I've been building a blog site using Jekyll and an specific theme called Chirpy, and deploying it all using Cloudflare Pages, the code is stored in a private Github repository so anytime I push code a new build gets generated by Cloudflare automatically.
It's been working fine for months but after some updates deploying a new build fails as:
12:57:58.188 Success: Finished cloning repository files
12:57:58.890 Installing dependencies
12:57:58.901 Python version set to 2.7
12:58:03.233 v12.18.0 is already installed.
12:58:04.608 Now using node v12.18.0 (npm v6.14.4)
12:58:04.922 Started restoring cached build plugins
12:58:04.937 Finished restoring cached build plugins
12:58:05.597 Attempting ruby version 2.7.1, read from environment
12:58:09.668 Using ruby version 2.7.1
12:58:10.041 Using PHP version 5.6
12:58:10.042 Started restoring cached ruby gems
12:58:10.060 Finished restoring cached ruby gems
12:58:10.062 Installing gem bundle
12:58:10.368 [DEPRECATED] The `--path` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set path '/opt/buildhome/cache/bundle'`, and stop using this flag
12:58:10.526 [DEPRECATED] The --binstubs option will be removed in favor of `bundle binstubs`
12:58:13.673 Fetching gem metadata from https://rubygems.org/..........
12:58:13.834 Fetching gem metadata from https://rubygems.org/.
12:58:13.935 Resolving dependencies...
12:58:14.019 sass-embedded-1.58.0-x86_64-linux-musl requires rubygems version >= 3.3.22,
12:58:14.019 which is incompatible with the current version, 3.1.2
12:58:14.052 Error during gem install
12:58:14.073 Failed: build command exited with code: 1
12:58:14.848 Failed: an internal error occurred
Now Cloudflare allows you to specify which command you want to use in order to execute the build, that being:
bundle exec jekyll b
I've been looking for a way to update the Ruby version being used in Cloudflare and could not find any resources more than this one post. I've tried changing the Gemfile like:
spec.required_ruby_version = ">= 3.0"
, but it seems like Cloudflare does not support Ruby 3 at all; I then had the idea to use an older version of the Chirpy theme, since I already have a deployed version of the blog, I went back to Chirpy 5.2.1 but surprisingly the error persist.
Definitely adding gem "jekyll-sass-converter", "~> 2.0" to the Gemfile solved this problem, as Christian mentioned.
After installing PentestBox for installing penetration testing tools on windows 10 It was working great but some of the tools was outdated like metasploit, so I tried updating all using PentestBox Update Manager, but after finishing the update msfconsole keeps giving me this error
Bundler could not find compatible versions for gem "sysrandom":
In Gemfile:
metasploit-framework x86-mingw32 was resolved to 5.0.0, which depends on sysrandom x86-mingw32
Could not find gem 'sysrandom', which is required by gem 'metasploit-framework', in any of the sources.
and i literally suck in ruby language on general so what should i do ?
The version of metasploit you linked to doesn't appear to have been updated in a few years. It doesn't list sysrandom as a dependency in the Gemfile.
There's a newer version which does have sysrandom as a dependency, here:
https://github.com/rapid7/metasploit-framework/blob/master/metasploit-framework.gemspec#L106
I'm not sure why pentestbox is using such an old version, but I'm assuming the "update" actually updates to the rapid7 version of metasploit (because it's looking for sysrandom which only exists there).
There are a few things you can try:
bundle install should install all the dependencies (without using the console tool built for pentestbox)
Deleting the Gemfile.lock and running bundle install. I don't usually recommend this but if there seems to be a version mismatch somewhere and sometimes this resolves dependencies errors. You should be able to re-check this file out again (assuming it's versioned locally)
If you can post the git commit hash of the metasploit version you've downloaded that might help provide additional suggestions for resolving.
I am trying to use the JRuby Heroku buildpack (https://github.com/jruby/heroku-buildpack-jruby) to run a simple test application.
However, it seems that gems with C extensions cannot be compiled. For example, when doing a "git push heroku", the gems without C extensions are installed successfully, but then...
Using activerecord (3.1.3)
Using activeresource (3.1.3)
Using bouncy-castle-java (1.5.0146.1)
Using bson (1.7.0)
Installing bson_ext (1.7.0) with native extensions
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.
/tmp/build_10vcxrs9ayvxf/jruby/bin/jruby extconf.rb
NotImplementedError: C extension support is not enabled. Pass -Xcext.enabled=true to JRuby or set JRUBY_OPTS or modify .jrubyrc to enable.
(root) at /tmp/build_10vcxrs9ayvxf/jruby/lib/ruby/shared/mkmf.rb:8
require at org/jruby/RubyKernel.java:1019
(root) at /tmp/build_10vcxrs9ayvxf/jruby/lib/ruby/shared/rubygems/custom_require.rb:1
(root) at extconf.rb:1
Gem files will remain installed in /tmp/build_10vcxrs9ayvxf/vendor/bundle/jruby/1.9/gems/bson_ext-1.7.0 for inspection.
Results logged to /tmp/build_10vcxrs9ayvxf/vendor/bundle/jruby/1.9/gems/bson_ext-1.7.0/ext/cbson/gem_make.out
An error occurred while installing bson_ext (1.7.0), and Bundler cannot continue.
Make sure that `gem install bson_ext -v '1.7.0'` succeeds before bundling.
Dependencies installed
Upon seeing the advice given above, I then went and created a modified version of the JRuby buildpack, which can be found here: https://github.com/grahamdaley/heroku-buildpack-jruby-cext
The only difference between this buildpack and the original one is that I have now set JRUBY_OPTS as follows:
JRUBY_OPTS="--1.9 -Xcext.enabled=true -J-Xmx400m"
However, this doesn't seem to have made any difference at all and I'm still getting the same error.
Any hints? Is it possible (and would help) to add a .jrubyrc file somewhere in the buildpack?
you should simply configure JRUBY_OPTS instead of a setting up a customized build-pack :
heroku config:add JRUBY_OPTS="--1.9 -Xcext.enabled=true -J-Xmx400m"
that being said - it's probably a bad idea to use C-ext with JRuby
you definitely do not need C-ext due to BSON gem (it has a native JRuby version) - editing your Gemfile and/or re-bundling (rm Gemfile.lock && bundle) locally with JRuby will likely solve this for you ...
Install without C extention
On way is just install json without the C extension. Is possible because the C extension is optional. Attention this is slower than bson with C extension this is may a problem for you. source
Ruby — with optional C extension
Open a Ticket
Almost any gem - even those with native dependencies - can be installed using Bundler. If there’s a specific gem that won’t install on Heroku, please submit a support ticket.
So you can open a support ticket here
I am working on a gem and it's on github.
When I include the gem in an application, do a capistrano deploy, and (on the server) run:
bundle outdated
I see:
* authengine (0.0.1 d8baa49 > 0.0.1 de43dfa)
which tells me that a more recent commit is available. Why doesn't the bundle update (part of capistrano deploy) pull the more recent version? There is no version constraint in the Gemfile of the host application, and anyway they have the same version number, just different commits.
Even if I log into the server and run
bundle update authengine
I get the same "outdated" result afterwards.
What am I missing here?
One thing I've found that can cause this is if other gems in the bundle make requirements on gems by version that are incompatible. Bundler tries to reconcile these by selecting versions of gems such that their requirements can all be satisfied. The result is that it quietly refuses to update gems.
The way to check this is to set an explicit version requirement in your Gemfile. Something like
gem "authengine", "> 0.0.2" #(you'll need to bump the version to make this work)
#or
gem "authengine", :ref => "d8baa49"
Then run
bundle update authengine
You should see something like (this is taken from my particular case):
Bundler could not find compatible versions for gem "json": In
Gemfile:
chef (> 10.8) ruby depends on
json (<= 1.6.1, >= 1.4.4) ruby
logical-construct (>= 0) ruby depends on
json (1.7.5)
So, in my case it's a problem with explicitly requiring a newer version of json.
The author, André Arko, stated in 2014 that:
The Bundler resolver is definitely a work in progress, and we adjust
the tradeoffs between specific versions and resolving quickly based on
user feedback.
Bundler has consistently not provided the newest possible version of
every gem for the entirety of its existence, and it does result in a
lot of tickets being opened. In most cases, it turns out to be the
result of Bundler having to pick between the newest version of one gem
or a different gem, and Bundler picks the gem the user doesn’t care
about having the newest version of. That’s why it’s so important to
make your Gemfile version requirements accurately reflect your actual
requirements.
I recognize that your assumption that Bundler would give you the
newest possible version seemed valid at the time, but the docs only
say that you will get a version that meets your requirements, not the
latest. Is there anywhere we could expand the docs to make it clearer
that the newest versions of everything simply isn’t feasible?
What is the output returned when you run bundle update authengine? Does it actually say it updated the gem? Or does it ignore the gem?
You can try using the --source parameter to specifically tell Bundler to use the git repository. That, or your
bundle update authengine --source https://github.com/mustardseeddatabase/authengine.git
Also, when unexpected things like this happen, I like to clean up my gemlist in general. It could be that you still have older versions of the gem laying around, not using in bundler.
So you could do:
gem list
gem check
gem cleanup
Or do a complete reinstall
gem uninstall authengine
bundle install
I installed Bundler on a pre-Rails 3 application and am trying to use it to install gems. My Gemfile contains the following lines:
source :rubygems
[...]
gem "RubyInline", "3.8.1"
However, when I run bundle install I get this error:
Fetching source index for http://rubygems.org/
Could not find gem 'RubyInline', required by 'memcache-client (= 1.6.3)', in any of the sources
The gem appears on the rubygems website:
http://rubygems.org/gems/RubyInline
Why is it giving me an error then?
I'm afraid this resolved itself after changes to fix other issues, and I'm not sure what the fix was. The source of several other issues was wrong permissions on various gems/binaries.
This kind of issue for me seems to be resolved on occasion by applying
bundle update
before
bundle install
The effect is to resolve old dependencies from when the bundle was originally produced and hence a gem that has been superseded (or whatever) will no longer be in the Gemfile.