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.
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.
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.
Maximilian Bosch