-
-
Notifications
You must be signed in to change notification settings - Fork 2k
Error during bundle install "Unable to find a spec ffi" #6079
Comments
Yup, this looks like a bug (lockfile only has one of the platforms for ffi). Out of curiosity, can you check if 1.16.0.pre.3 fixes the issue? |
Yes 1.16.0.pre.3 fixes this problem. But the folder of 1.16.0.pre.3 does not have a bin folder which is causing my build steps to fail. Looks like teamcity agent is attempting to look for that. |
To temporarily resolve this, I tried copying the bin folder from 1.15.4 to 1.16.0.pre.3 and it worked. Also, looks like the ffi dependency issue is not completely resolved. It started appearing again. So maybe it is intermittent. |
I am getting this error a lot on a Travis-ci build, intermittently but failing more often than not. Seems to be occurring with both Bundler 1.16.0 and 1.16.1 and 1.15.3. 'ffi' was listed in my Gemfile.lock with only a single w32 platform (I'm developing on Windows):
I tried My solution was to manually edit the
|
I wonder if this will fix itself if you remove the |
Reproduced this, just wondering how |
Took a while to wrap my head around things, but I hope #6288 will fix this bug! Thanks for bearing with us 🤞 |
…specs, r=indirect Gracefully handle when the lockfile is missing spec entries for the current platform ### What was the end-user problem that led to this PR? The problem was users could get `Unable to find a spec satisfying ... perhaps the lockfile is corrupted?` error messages, particularly when they use multiple platforms. Fixes #6079. ### What was your diagnosis of the problem? My diagnosis was the lockfile _was_ indeed corrupted, because it was missing `spec_name (version)` entries, but resolution could still be skipped (preventing those gems from being added back in). ### What is your fix for the problem, implemented in this PR? My fix checks whether all specs are present _in the lockfile_ (e.g. not locally) for the current platform, and considers that a "change" that forces the resolver to run, allowing those missing specs to be added back to the bundle. ### Why did you choose this fix out of the possible options? I chose this fix because it was a way to force re-resolution in a way that ties into our existing `#change_reason` infrastructure. Additionally, it shouldn't have much of a performance overhead, since the calculation is only made when we're converging locked specs anyways.
…specs, r=indirect Gracefully handle when the lockfile is missing spec entries for the current platform ### What was the end-user problem that led to this PR? The problem was users could get `Unable to find a spec satisfying ... perhaps the lockfile is corrupted?` error messages, particularly when they use multiple platforms. Fixes #6079. ### What was your diagnosis of the problem? My diagnosis was the lockfile _was_ indeed corrupted, because it was missing `spec_name (version)` entries, but resolution could still be skipped (preventing those gems from being added back in). ### What is your fix for the problem, implemented in this PR? My fix checks whether all specs are present _in the lockfile_ (e.g. not locally) for the current platform, and considers that a "change" that forces the resolver to run, allowing those missing specs to be added back to the bundle. ### Why did you choose this fix out of the possible options? I chose this fix because it was a way to force re-resolution in a way that ties into our existing `#change_reason` infrastructure. Additionally, it shouldn't have much of a performance overhead, since the calculation is only made when we're converging locked specs anyways. (cherry picked from commit 81854e0)
…specs, r=indirect Gracefully handle when the lockfile is missing spec entries for the current platform ### What was the end-user problem that led to this PR? The problem was users could get `Unable to find a spec satisfying ... perhaps the lockfile is corrupted?` error messages, particularly when they use multiple platforms. Fixes #6079. ### What was your diagnosis of the problem? My diagnosis was the lockfile _was_ indeed corrupted, because it was missing `spec_name (version)` entries, but resolution could still be skipped (preventing those gems from being added back in). ### What is your fix for the problem, implemented in this PR? My fix checks whether all specs are present _in the lockfile_ (e.g. not locally) for the current platform, and considers that a "change" that forces the resolver to run, allowing those missing specs to be added back to the bundle. ### Why did you choose this fix out of the possible options? I chose this fix because it was a way to force re-resolution in a way that ties into our existing `#change_reason` infrastructure. Additionally, it shouldn't have much of a performance overhead, since the calculation is only made when we're converging locked specs anyways. (cherry picked from commit 81854e0)
## 1.16.5 (2018-09-18) Changes: - Add support for TruffleRuby (@eregon) Bugfixes: - Avoid printing git errors when checking the version on incorrectly packaged versions of Bundler ([#6453](rubygems/bundler#6453), @greysteil) - Fix issue where Bundler does not check the given class when comparing equality in DepProxy (@ChrisBr) - Handle `RangeNotSatisfiable` error in Compact Index (@MaxLap) - Check for initialized `search` variable in `LazySpecification` (@voxik) - Fix LoadError occurring in nested bundle exec calls ([#6537](rubygems/bundler#6537), @colby-swandale) - Check that Bundler::Deprecate is not an autoload constant ([#6163](rubygems/bundler#6163), @eregon) - Prefer non-pre-release versions when performing a `bundle update --patch` ([#6684](rubygems/bundler#6684), @segiddins) ## 1.16.4 (2017-08-17) Changes: - Welcome new members to the Bundler core team (@indirect) - Don't mutate original error trees when determining version_conflict_message (@greysteil) - Update vendored Molinillo to 0.6.6 (@segiddins) Bugfixes: - Reword bundle update regression message to be more clear to the user when a gem's version is downgraded ([#6584](rubygems/bundler#6584), @ralphbolo) - Respect --conservative flag when updating a dependency group ([#6560](rubygems/bundler#6560), @greysteil) - Fix issue where a pre-release version was not being selected when it's specified in the Gemfile ([#6449](rubygems/bundler#6449), @akihiro17) - Fix issue where `Etc` was not loaded when getting the user's home dir ([#6640](rubygems/bundler#6640), @colby-swandale) - Use UTF-8 for reading files including Gemfile ([#6660](rubygems/bundler#6660), @eregon) - Remove unnecessary `while` loop in path resolver helper (@ojab) Documentation: - Document that `bundle show [--paths]` sorts results by name (@kemitchell) ## 1.16.3 (2018-07-17) Features: - Support URI::File of Ruby 2.6 (@hsbt) Bugfixes: - Expand symlinks during setup to allow Bundler to load correctly when using symlinks in $GEM_HOME ([#6465](rubygems/bundler#6465), @ojab, @indirect) - Dont let Bundler create temporary folders for gem installs which are owned by root ([#6258](rubygems/bundler#6258), @colby-swandale) - Don't fallback to using temporary directories when needed directories already exist ([#6546](rubygems/bundler#6546), @brodock) - Use SharedHelpers.filesystem_access when reading a Gemfile so friendly error messages can be given to the user ([#6541](rubygems/bundler#6541), @segiddins) - Check if source responds to `#remotes` before printing gem install error message ([#6211](rubygems/bundler#6211), @colby-swandale) - Handle Errno::ENOTSUP in the Bundler Process Lock to prevent exceptions when using NFS mounts ([#6566](rubygems/bundler#6566), @colby-swandale) - Respect encodings when reading gemspecs ([#6598](rubygems/bundler#6598), @deivid-rodriguez) Documentation: - Fix links between manual pages (@BanzaiMan) - Add warning to Gemfile documentation for the use of the `source` option when declaring gems ([#6280](rubygems/bundler#6280), @forestgagnon) ## 1.16.2 (2018-04-20) Changes: - Include the gem's source in the gem install error message when available (@papanikge) - Remove unnecessary executable bit from gem template (@voxik) - Dont add the timestamp comment with gems added to the Gemfile via `bundle add` ([#6193](rubygems/bundler#6193), @cpgo) - Improve yanked gem error message (@alyssais) - Use `Bundler.rubygems.inflate` instead of the Gem::Util method directly (@segiddins) - Remove unused instance variable (@segiddins) Bugfixes: - Only trap INT signal and have Ruby's signal default handler be invoked (@shayonj) - Fix warning about the use of `__FILE__` in RubyGems integration testing (@MSP-Greg) - Skip the outdated bundler check when MD5 is not available ([#6032](rubygems/bundler#6032), @segiddins) - Fallback to the original error if the friendly message raises (@segiddins) - Rename Bundler.frozen? to avoid Object method conflict ([#6252](rubygems/bundler#6252), @segiddins) - Ensure the bindir exists before installing gems (@segiddins) - Handle gzip corruption errors in the compact index client ([#6261](rubygems/bundler#6261), @colby-swandale) - Check if the current directory is writeable when writing files in `bundle gem` ([#6219](rubygems/bundler#6219), @nilsding) - Fix hang when gemspec has incompatible encoding (@deivid-rodriguez) - Gracefully handle when the lockfile is missing spec entries for the current platform ([#6079](rubygems/bundler#6079), @segiddins) - Use Gem::Util.inflate instead of Gem.inflate (@hsbt) - Update binstub generator to use new ERB.new arity in Ruby 2.6 (@koic) - Fix `source_location` call in rubygems integration (@MSP-Greg) - Use `filesystem_access` when copying files in Compact Index Updater ([#6289](rubygems/bundler#6289), @segiddins) - Fail gracefully when resetting git gems to the given revision fails ([#6324](rubygems/bundler#6324), @segiddins) - Handle exceptions that do not have a backtrace ([#6342](rubygems/bundler#6342), @nesaulov) - Check if stderr was closed before writing to it (@shime) - Handle updating a specific gem for a non-local platform ([#6350](rubygems/bundler#6350), @greysteil) - Bump the `bundle_binstub` check-length to 300 characters (@tduffield) - Fix specifying alterntive Lockfile with `bundle lock` when default gemfile is present ([#6460](rubygems/bundler#6460), @agrim123) - Allow installing dependencies when the path is set to `.` ([#6475](rubygems/bundler#6475), @segiddins) - Support Bundler installing on a readonly filesystem without a home directory ([#6461](rubygems/bundler#6461), @grosser) - Filter git uri credentials in source description (@segiddins) Documentation: - Correct typos in `bundle binstubs` man page (@erikj, @samueloph) - Update links in `bundle gem` command documentation to use https (@KrauseFx) - Fix broken links between bundler man pages (@segiddins) - Add man page for the `bundle doctor` command ([#6243](rubygems/bundler#6243), @nholden) - Document `# frozen_string_literal` in `bundle init` Gemfile (@315tky) - Explain the gemspec files attribute in `bundle gem` template and print a link to bundler.io guides when running `bundle gem` ([#6246](rubygems/bundler#6246), @nesaulov) - Small copy tweaks & removed redundant phrasing in the bundler man page (@rubymorillo) - Improve the documentation of the settings load order in Bundler (@rubymorillo) - Added license info to main README (@rubymorillo) - Document parameters and return value of Injector#inject (@tobias-grasse)
The bundler command does not work in one of our teamcity agents (although its configuration is similar to other agents). It says that it can't find an ffi spec, but it's present in Gemfile.lock.
Error Report
What did you do?
I ran the command
C:/Ruby21-x64/bin/bundle install
What did you expect to happen?
I expected Bundler to install the gems
What happened instead?
Instead, what happened was that the bundler through an error saying can't find the spec for ffi, which is actually mentioned in the Gemfile. I can see the folder for the gem ffi (1.9.10-x86-mingw32) in the gems folder too. (C:\Ruby21-x64\lib\ruby\gems\2.1.0\gems\ffi-1.9.10-x64-mingw32)
Backtrace
Environment
Gemfile
Gemfile
Gemfile.lock
The text was updated successfully, but these errors were encountered: