Commit graph

72 commits

Author SHA1 Message Date
William Kral 0b76b2d2af vagrant: re-add nowarn patch (#56863) 2019-03-05 06:44:40 -08:00
Matthew Bauer 55fc5b54ee vagrant: only use libvirt on linux
Fixes #55751
2019-02-25 16:50:54 -05:00
Florian Klink 659ebb6869 vagrant: 2.2.0 -> 2.2.3 2019-02-12 00:23:46 +01:00
Ryan Fitzsimon b66b0c58ca vagrant: Add vagrant-libvirt utility dependencies
When using vagrant-libvirt as provider, the 'vagrant package'
command requires 'qemu-img' and 'virt-sysprep'.
2019-01-02 17:17:14 +10:00
Matthew Harm Bekkema c660f3d419 vagrant: Remove unnecessary buildInputs
libvirt and pkgconfig are now buildInputs to ruby-libvirt instead.
2018-12-17 21:53:23 +11:00
Matthew Harm Bekkema 245ba973d9 vagrant: Install vagrant-libvirt as system plugin 2018-12-17 21:53:23 +11:00
Matthew Harm Bekkema 08488bcf94 vagrant: Support system-installed plugins
Patch taken from Debian
2018-12-17 21:53:23 +11:00
Matthew Harm Bekkema 1183ee645d vagrant: Add vagrant-libvirt to the gemset
With this, you can "install" the plugin just by adding the following to
~/vagrant.d/plugins.json:

  {
    "version":"1",
    "installed": {
      "vagrant-libvirt": {
        "ruby_version":"2.5.3",
        "vagrant_version":"2.2.0",
        "gem_version":"",
        "require":"",
        "sources":[]
      }
    }
  }
2018-12-17 10:23:27 +11:00
Christian Albrecht c5e8ae3f0b vagrant: do withLibvitr by default #49220 2018-11-07 17:46:57 +01:00
Christian Albrecht 7ed92b1497 vagrant-libvirt: init at 2.2.0
Adds a flag and a new package to build vagrant with libvirt support,
to be able to install and use the vagrant-libvirt plugin.
2018-11-07 17:46:57 +01:00
Christian Albrecht 9335613995 vagrant: 2.1.2 -> 2.2.0 2018-11-07 17:46:57 +01:00
Aneesh Agrawal 16a8e49ae9 vagrant: remove unused vendored Gemfile{,.lock} 2018-10-01 21:06:34 -07:00
Aneesh Agrawal fae4aa9f36 vagrant: Clean up Gemfile 2018-09-25 00:18:39 -07:00
Aneesh Agrawal 2ed25d3768 vagrant: mark bundler as system plugin
This will cause Vagrant to use the rubygems version of bundler
without complaint.
2018-08-27 22:57:19 -07:00
Aneesh Agrawal 982f9d8616 vagrant: update deps for 2.1.2
The version was bumped but the dependencies were not updated.
Do so and add some instructions for future package updates.
2018-07-16 10:11:36 -07:00
Alyssa Ross 165b6391fc vagrant: 2.1.1 -> 2.1.2 (#43416) 2018-07-14 00:41:37 +02:00
John Ericson 18742471af Merge remote-tracking branch 'upstream/master' into staging
Use newer vagrant from master
2018-05-23 09:40:37 -04:00
Aneesh Agrawal cde4ea79f8 vagrant: 2.0.2 -> 2.1.1 2018-05-23 00:22:39 -07:00
Jörg Thalheim 0a973b9985 vagrant: 2.0.2 -> 2.0.4 2018-04-29 19:08:42 +01:00
Aneesh Agrawal 89d0307a39 vagrant: Fix dependencies for version 2.0.2
The version was bumped in #36081,
but the dependencies were not updated,
causing Vagrant to fail at runtime.

Fix the dependencies (via bundix),
and add an `installCheckPhase` to the derviation
to catch this in the future.
2018-03-03 23:31:00 -08:00
Ryan Mulligan 52611447d1 vagrant: 2.0.1 -> 2.0.2
Semi-automatic update. These checks were performed:

- built on NixOS
- found 2.0.2 with grep in /nix/store/32zly5yhz0hcqgk6w5y0ish2rssfc6y9-vagrant-2.0.2

cc "@aneeshusa"
2018-02-28 11:36:44 +01:00
Aneesh Agrawal 9c33aa8465 vagrant: Make bsdtar available to extract boxes 2018-01-27 15:48:19 -08:00
Aneesh Agrawal 8c3553b88d vagrant: Build from source
This is not quite as elegant as using `bundlerApp`,
which I could not get working.
However, this still uses most of the Ruby infrastructure,
including stock bundix, and should be fairly reasonable to maintain.

This means no more hacks to work around wrong embedded binaries,
and no need for an old version of Ruby.

Note that `vagrant share` is no longer included,
as that functionality is closed-source
and not present in the upstream source code.

The Vagrant maintainers publish official Vagrant installers,
which they prefer people use as most platforms don't
have great support for pinning known-good dependencies.
When run outside one of the offical installers,
Vagrant normally prints a warning to that effect.
However, Vagrant does run outside the installer environment
(nominally to support Vagrant development),
and this has the effect of functioning better by respecting
OS certs and shared libraries,
as opposed to trying to use bundled versions.
To keep these postive side effects without having to see the warning
on every Vagrant invocation, patch out the call to print the warning.

Note that I have reset the maintainers since the implementation is
totally redone; I'm happy to re-add any of the current maintainers.
2018-01-04 08:00:51 -08:00
Andreas Rammhold e427e8415c
vagrant: removed custom rake gem 2017-11-17 11:43:31 +01:00
Andreas Rammhold 3f4eb16799
vagrant: 2.0.0 -> 2.0.1
Due to the virtualbox bump to version 5.2 vagrant was no longer able to
interface with virtualbox. Version 2.0.1 supports virtualbox 5.2.
2017-11-17 11:43:30 +01:00
Samuel Dionne-Riel bd87a3be2d vagrant: Adds bash-completion to the proper folder. (#30482) 2017-10-17 02:35:04 +01:00
Diego Zamboni 97d9f0b5bb vagrant: fix Ruby and libffi libraries on Darwin
On Darwin, keep the Ruby and libffi libraries and binaries bundled
with Vagrant instead of linking to the Nix ones, to avoid errors about
libraries not found.
2017-10-04 22:06:39 +02:00
Diego Zamboni 9bcd1de373 vagrant: 1.9.5 -> 2.0.0
Upgrade to latest version of Vagrant.

After installation, the following messages appear whenever vagrant runs.
These were already present in previous versions, I'm not sure if/what
to do about them:

Ignoring ffi-1.9.18 because its extensions are not built.  Try: gem pristine ffi --version 1.9.18
Ignoring unf_ext-0.0.7.4 because its extensions are not built.  Try: gem pristine unf_ext --version 0.0.7.4
Ignoring wdm-0.1.1 because its extensions are not built.  Try: gem pristine wdm --version 0.1.1
2017-10-02 10:06:03 +02:00
Tim Jäger 0576bda744 vagrant: against libffi (#26440)
* Link vagrant against libffi

Vagrant requires libffi to run
with (vagrant-fsnotify)[https://github.com/adrienkohlbecker/vagrant-fsnotify].

* vagrant: nitpick
2017-06-08 07:20:10 +01:00
Aaron Bull Schaefer 728ddbd95f vagrant: 1.9.1 -> 1.9.5 2017-05-30 08:23:04 -07:00
Kamil Chmielewski 29ac5d5209 vagrant: FIX #21365 add libxml2 and libxslt paths 2017-01-23 20:34:04 +01:00
Kamil Chmielewski 9aa6c95d5a vagrant: 1.8.7 -> 1.9.1 2016-12-15 12:29:52 +01:00
Michaël Faille 3a3706c07f vagrant: 1.8.6 -> 1.8.7
I upgrade vagrant mainly for this bug :
https://github.com/mitchellh/vagrant/issues/7844
2016-11-14 00:15:57 -05:00
Ryan Artecona 224a6b85fa vagrant: add darwin support
Vagrant on macOS is distributed as a .dmg installer. Luckily, the
internal contents of that archive resemble that of the .deb we use for
linux. In fact, the similarity is enough that if we move its `embedded`
directory to `opt/vagrant/embedded` and its `bin` to `usr/bin` (and back
again after installation), the derivation's installPhase (which replaces
embedded libs & binaries with those from the package's inputs) can
remain exactly the same between macOS and linux.
2016-10-09 15:25:41 -04:00
Kamil Chmielewski 4f6870bb4b vagrant: 1.8.5 -> 1.8.6 2016-10-07 11:15:11 +02:00
Aneesh Agrawal b1c83e8928 vagrant: make patches a list (#18364)
This has more correct semantics, allows for multiple patches, and makes
using overrideDerivation to add/remove patches work as expected.
2016-09-06 16:52:01 +02:00
Peter Hoeg a359d330dc vagrant: 1.8.4 -> 1.8.5 (#18283)
Includes https://github.com/mitchellh/vagrant/pull/7611 to fix issue with permissions on ~/.ssh/authorized_keys.
2016-09-05 14:44:34 +02:00
Kamil Chmielewski 532b222296 vagrant: cleanup FIX plugin install from #17614 (#17663) 2016-08-12 09:33:37 +00:00
Kamil Chmielewski 5d5b2d3f8f vagrant: FIX #16837 vagrant plugin install 2016-08-09 17:07:43 +02:00
Aneesh Agrawal 746b591c68 vagrant: use libarchive lib from Nix (#17597)
We currently already replace the embedded bsdtar binaries with the
corresponding ones from Nix. However, we also need to replace the
libarchive shared library to prevent version mismatches between the
embedded library and the Nix binaries.

Also expose version on the derivation and use environment variables
to make overriding the derivation easier.
2016-08-09 12:01:48 +02:00
Langston Barrett 4063834f92 vagrant: 1.8.1 -> 1.8.4 2016-07-18 13:40:05 +00:00
Tuomas Tynkkynen e28e010b36 treewide: Make explicit that 'dev' output of curl is used 2016-05-19 10:00:29 +02:00
Vladimír Čunát ae74c356d9 Merge recent 'staging' into closure-size
Let's get rid of those merge conflicts.
2016-02-03 16:57:19 +01:00
Christian Albrecht 8975148a16 vagrant: 1.8.0 -> 1.8.1 2016-01-28 01:01:56 +01:00
Vladimír Čunát 716aac2519 Merge branch 'staging' into closure-size 2016-01-19 09:55:31 +01:00
Vladimír Čunát f9f6f41bff Merge branch 'master' into closure-size
TODO: there was more significant refactoring of qtbase and plasma 5.5
on master, and I'm deferring pointing to correct outputs to later.
2015-12-31 09:53:02 +01:00
Charles Strahan b6c06e216b ruby: new bundler infrastructure
This improves our Bundler integration (i.e. `bundlerEnv`).

Before describing the implementation differences, I'd like to point a
breaking change: buildRubyGem now expects `gemName` and `version` as
arguments, rather than a `name` attribute in the form of
"<gem-name>-<version>".

Now for the differences in implementation.

The previous implementation installed all gems at once in a single
derivation. This was made possible by using a set of monkey-patches to
prevent Bundler from downloading gems impurely, and to help Bundler
find and activate all required gems prior to installation. This had
several downsides:

* The patches were really hard to understand, and required subtle
  interaction with the rest of the build environment.
* A single install failure would cause the entire derivation to fail.

The new implementation takes a different approach: we install gems into
separate derivations, and then present Bundler with a symlink forest
thereof. This has a couple benefits over the existing approach:

* Fewer patches are required, with less interplay with the rest of the
  build environment.
* Changes to one gem no longer cause a rebuild of the entire dependency
  graph.
* Builds take 20% less time (using gitlab as a reference).

It's unfortunate that we still have to muck with Bundler's internals,
though it's unavoidable with the way that Bundler is currently designed.
There are a number improvements that could be made in Bundler that would
simplify our packaging story:

* Bundler requires all installed gems reside within the same prefix
  (GEM_HOME), unlike RubyGems which allows for multiple prefixes to
  be specified through GEM_PATH. It would be ideal if Bundler allowed
  for packages to be installed and sourced from multiple prefixes.
* Bundler installs git sources very differently from how RubyGems
  installs gem packages, and, unlike RubyGems, it doesn't provide a
  public interface (CLI or programmatic) to guide the installation of a
  single gem. We are presented with the options of either
  reimplementing a considerable portion Bundler, or patch and use parts
  of its internals; I choose the latter. Ideally, there would be a way
  to install gems from git sources in a manner similar to how we drive
  `gem` to install gem packages.
* When a bundled program is executed (via `bundle exec` or a
  binstub that does `require 'bundler/setup'`), the setup process reads
  the Gemfile.lock, activates the dependencies, re-serializes the lock
  file it read earlier, and then attempts to overwrite the Gemfile.lock
  if the contents aren't bit-identical. I think the reasoning is that
  by merely running an application with a newer version of Bundler, you'll
  automatically keep the Gemfile.lock up-to-date with any changes in the
  format. Unfortunately, that doesn't play well with any form of
  packaging, because bundler will immediately cause the application to
  abort when it attempts to write to the read-only Gemfile.lock in the
  store. We work around this by normalizing the Gemfile.lock with the
  version of Bundler that we'll use at runtime before we copy it into
  the store. This feels fragile, but it's the best we can do without
  changes upstream, or resorting to more delicate hacks.

With all of the challenges in using Bundler, one might wonder why we
can't just cut Bundler out of the picture and use RubyGems. After all,
Nix provides most of the isolation that Bundler is used for anyway.

The problem, however, is that almost every Rails application calls
`Bundler::require` at startup (by way of the default project templates).
Because bundler will then, by default, `require` each gem listed in the
Gemfile, Rails applications are almost always written such that none of
the source files explicitly require their dependencies. That leaves us
with two options: support and use Bundler, or maintain massive patches
for every Rails application that we package.

Closes #8612
2015-12-29 09:30:21 -05:00
Arseniy Seroka 87d2532f82 Merge pull request #11879 from aneeshusa/update-vagrant-to-1.8.0
vagrant: 1.7.4 -> 1.8.0
2015-12-22 17:51:35 +03:00
Aneesh Agrawal 53a5a44190 vagrant: 1.7.4 -> 1.8.0 2015-12-22 05:55:48 -05:00
Mathieu Boespflug bb30c79f0b vagrant: bring embedded/ libraries in scope of dynamic linker. 2015-12-16 18:14:40 +01:00