In 87a19e9048 I merged staging-next into master using the GitHub gui as intended.
In ac241fb7a5 I merged master into staging-next for the next staging cycle, however, I accidentally pushed it to master.
Thinking this may cause trouble, I reverted it in 0be87c7979. This was however wrong, as it "removed" master.
This reverts commit 0be87c7979.
I merged master into staging-next but accidentally pushed it to master.
This should get us back to 87a19e9048.
This reverts commit ac241fb7a5, reversing
changes made to 76a439239e.
This workaround was discovered by painstakingly resolving the
differences between a working installation and a non-working
installation until a minimal change was found. I have no idea why it
works.
Fixes#76629.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
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.
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"
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.
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.
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
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.
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.
