Bug#1049999: [DRE-maint] Bug#1049999: vagrant: the future of packaging vagrant in Debian
On Thu, Sep 26, 2024 at 04:15:37PM +0200, Lucas Nussbaum wrote:
Hi,
On 26/09/24 at 14:31 +0200, Francesco P. Lovergine wrote:
On Mon, 27 May 2024 22:24:12 +0200 Lucas Nussbaum wrote:
> Hi,
>
> An update on this:
>
> I plan to take care of the Debian vagrant package (in the framework of
> the Ruby team, as this is currently done). I uploaded the latest free
> version of Vagrant to unstable/testing
> (2.3.7+git20230731.5fc64cde+dfsg-2).
>
> Of course help is welcomed. An easy and useful entry point is to look at
> existing bugs, try to reproduce them with the latest version, and report
> back.
>
Hi,
did you consider to patch for Virtualbox 7.1 support? It should be
quite immediate, I don't see any specific problem in the provider,
I could provide a patch agains 3.7 series just in case...
A patch would be great.
For now Virtualbox 7.1 is not in unstable yet.
Lucas
Sorry, I missed the update of the Log4r logger name, this is a bit
better.
Just to clarify I'm using it under stable with 7.1, apparently there are
no special issues as for some past versions.
--
⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61
⠈⠳⣄ ED02 0F02 A5E1 1636 86A4
diff --git a/plugins/providers/virtualbox/driver/meta.rb b/plugins/providers/virtualbox/driver/meta.rb
index 04c130c44..251f79ca5 100644
--- a/plugins/providers/virtualbox/driver/meta.rb
+++ b/plugins/providers/virtualbox/driver/meta.rb
@@ -66,6 +66,7 @@ module VagrantPlugins
"6.0" => Version_6_0,
"6.1" => Version_6_1,
"7.0" => Version_7_0,
+"7.1" => Version_7_1,
}
if @@version.start_with?("4.2.14")
diff --git a/plugins/providers/virtualbox/driver/version_7_1.rb b/plugins/providers/virtualbox/driver/version_7_1.rb
new file mode 100644
index 0..563c55918
--- /dev/null
+++ b/plugins/providers/virtualbox/driver/version_7_1.rb
@@ -0,0 +1,24 @@
+require File.expand_path("../version_7_0", __FILE__)
+
+module VagrantPlugins
+ module ProviderVirtualBox
+module Driver
+ # Driver for VirtualBox 7.1.x
+ class Version_7_1 < Version_7_0
+def initialize(uuid)
+ super
+
+ @logger = Log4r::Logger.new("vagrant::provider::virtualbox_7_1")
+end
+
+# VirtualBox version in use
+#
+# @return [Gem::Version]
+def get_version
+ return @version if @version
+ @version = Gem::Version.new(Meta.new.version)
+end
+ end
+end
+ end
+end
diff --git a/plugins/providers/virtualbox/plugin.rb b/plugins/providers/virtualbox/plugin.rb
index 3b447c5c2..96d20a156 100644
--- a/plugins/providers/virtualbox/plugin.rb
+++ b/plugins/providers/virtualbox/plugin.rb
@@ -101,6 +101,7 @@ module VagrantPlugins
autoload :Version_6_0, File.expand_path("../driver/version_6_0", __FILE__)
autoload :Version_6_1, File.expand_path("../driver/version_6_1", __FILE__)
autoload :Version_7_0, File.expand_path("../driver/version_7_0", __FILE__)
+ autoload :Version_7_1, File.expand_path("../driver/version_7_1", __FILE__)
end
module Model
Bug#1049999: [DRE-maint] Bug#1049999: vagrant: the future of packaging vagrant in Debian
On Thu, Sep 26, 2024 at 04:15:37PM +0200, Lucas Nussbaum wrote:
Hi,
On 26/09/24 at 14:31 +0200, Francesco P. Lovergine wrote:
Hi,
did you consider to patch for Virtualbox 7.1 support? It should be
quite immediate, I don't see any specific problem in the provider,
I could provide a patch agains 3.7 series just in case...
A patch would be great.
For now Virtualbox 7.1 is not in unstable yet.
Lucas
Here it is.
--
Francesco P. Lovergine | https://lovergine.com/
diff --git a/plugins/providers/virtualbox/driver/meta.rb b/plugins/providers/virtualbox/driver/meta.rb
index 04c130c44..251f79ca5 100644
--- a/plugins/providers/virtualbox/driver/meta.rb
+++ b/plugins/providers/virtualbox/driver/meta.rb
@@ -66,6 +66,7 @@ module VagrantPlugins
"6.0" => Version_6_0,
"6.1" => Version_6_1,
"7.0" => Version_7_0,
+"7.1" => Version_7_1,
}
if @@version.start_with?("4.2.14")
diff --git a/plugins/providers/virtualbox/driver/version_7_1.rb b/plugins/providers/virtualbox/driver/version_7_1.rb
new file mode 100644
index 0..563c55918
--- /dev/null
+++ b/plugins/providers/virtualbox/driver/version_7_1.rb
@@ -0,0 +1,24 @@
+require File.expand_path("../version_7_0", __FILE__)
+
+module VagrantPlugins
+ module ProviderVirtualBox
+module Driver
+ # Driver for VirtualBox 7.1.x
+ class Version_7_1 < Version_7_0
+def initialize(uuid)
+ super
+
+ @logger = Log4r::Logger.new("vagrant::provider::virtualbox_7_0")
+end
+
+# VirtualBox version in use
+#
+# @return [Gem::Version]
+def get_version
+ return @version if @version
+ @version = Gem::Version.new(Meta.new.version)
+end
+ end
+end
+ end
+end
diff --git a/plugins/providers/virtualbox/plugin.rb b/plugins/providers/virtualbox/plugin.rb
index 3b447c5c2..96d20a156 100644
--- a/plugins/providers/virtualbox/plugin.rb
+++ b/plugins/providers/virtualbox/plugin.rb
@@ -101,6 +101,7 @@ module VagrantPlugins
autoload :Version_6_0, File.expand_path("../driver/version_6_0", __FILE__)
autoload :Version_6_1, File.expand_path("../driver/version_6_1", __FILE__)
autoload :Version_7_0, File.expand_path("../driver/version_7_0", __FILE__)
+ autoload :Version_7_1, File.expand_path("../driver/version_7_1", __FILE__)
end
module Model
Bug#1049999: [DRE-maint] Bug#1049999: vagrant: the future of packaging vagrant in Debian
Hi, On 26/09/24 at 14:31 +0200, Francesco P. Lovergine wrote: > On Mon, 27 May 2024 22:24:12 +0200 Lucas Nussbaum wrote: > > Hi, > > > > An update on this: > > > > I plan to take care of the Debian vagrant package (in the framework of > > the Ruby team, as this is currently done). I uploaded the latest free > > version of Vagrant to unstable/testing > > (2.3.7+git20230731.5fc64cde+dfsg-2). > > > > Of course help is welcomed. An easy and useful entry point is to look at > > existing bugs, try to reproduce them with the latest version, and report > > back. > > > > Hi, > > did you consider to patch for Virtualbox 7.1 support? It should be > quite immediate, I don't see any specific problem in the provider, > I could provide a patch agains 3.7 series just in case... A patch would be great. For now Virtualbox 7.1 is not in unstable yet. Lucas
Bug#1049999: vagrant: the future of packaging vagrant in Debian
On Mon, 27 May 2024 22:24:12 +0200 Lucas Nussbaum wrote: Hi, An update on this: I plan to take care of the Debian vagrant package (in the framework of the Ruby team, as this is currently done). I uploaded the latest free version of Vagrant to unstable/testing (2.3.7+git20230731.5fc64cde+dfsg-2). Of course help is welcomed. An easy and useful entry point is to look at existing bugs, try to reproduce them with the latest version, and report back. Hi, did you consider to patch for Virtualbox 7.1 support? It should be quite immediate, I don't see any specific problem in the provider, I could provide a patch agains 3.7 series just in case... -- ⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61 ⠈⠳⣄ ED02 0F02 A5E1 1636 86A4
Bug#1049999: vagrant: the future of packaging vagrant in Debian
Hi, An update on this: I plan to take care of the Debian vagrant package (in the framework of the Ruby team, as this is currently done). I uploaded the latest free version of Vagrant to unstable/testing (2.3.7+git20230731.5fc64cde+dfsg-2). Of course help is welcomed. An easy and useful entry point is to look at existing bugs, try to reproduce them with the latest version, and report back. I do not plan to package the non-free versions of Vagrant. I also plan to continue to take care of the Debian Vagrant images, including ensure that they work with the version of Vagrant in Debian. I also looked a bit at potential alternatives. A project with a good potential is Incus (a LXD fork by the original LXC/LXD main developer). It is easy to install, and it provides both VMs and containers support. However currently it does not provide an equivalent to a Vagrantfile (to describe the infrastructure to create, what to execute on nodes, etc.). There's a terraform/opentofu provider, but that doesn't sounds very exciting regarding complexity. I raised that topic in https://discuss.linuxcontainers.org/t/incus-as-a-vagrant-replacement/19586 but the discussion did not go anywhere interesting. Maybe a third party project could create an incus frontend that provides a Vagrantfile-like interface. Given infinite free time, I would likely work on that. :) Lucas
Bug#1049999: vagrant: the future of packaging vagrant in Debian
On Thu, Aug 24, 2023 at 01:46:11AM +0200, Guillem Jover wrote: > Hi! > > On Fri, 2023-08-18 at 08:07:44 -0300, Antonio Terceiro wrote: > > FWIW, I have been maintaining vagrant in Debian for several years. > > BTW, thank you for having done that, it's been much appreciated! > > > TL;DR: I will not be maintaining vagrant anymore. > > > On Fri, Aug 18, 2023 at 02:56:28PM +0900, Kentaro HAYASHI wrote: > > > * What was the outcome of this action? > > > > Plan A. > […] > > > > Plan B. > […] > > > On Fri, Aug 18, 2023 at 09:37:54AM +, gwili.stif...@easymailer.live > > wrote: > > > Plan C. > […] > > There's perhaps a: > > Plan D. > > - Package Vagrunt (https://github.com/vaagrunt/vagrunt) a fork of > Vagrant, that is stated should remain free software. And as it does > not have a CLA, if it gets several contributions it will be > increasingly hard to relicense. > - Transition from vagrant to vagrunt via a transitional package. > > (We use Vagrant at work, and I'm not planning on relying on a non-free > tool, so a fork would do, otherwise I'd have to look into alternatives > for us to switch to.) I have seen this a couple of days ago. So far vagrunt is vaporware. The GitHub user which created has -- as far as I looked, i.e. on GitHub itself -- 0 contributions to Ruby projects. I'm also not confident that it will be easy to keep up with e.g. new VirtualBox versions without effectively infringing on HashiCorp copyrights. I will love to be proven wrong, but I'm not holding my breath here. signature.asc Description: PGP signature
Bug#1049999: vagrant: the future of packaging vagrant in Debian
Hi! On Fri, 2023-08-18 at 08:07:44 -0300, Antonio Terceiro wrote: > FWIW, I have been maintaining vagrant in Debian for several years. BTW, thank you for having done that, it's been much appreciated! > TL;DR: I will not be maintaining vagrant anymore. > On Fri, Aug 18, 2023 at 02:56:28PM +0900, Kentaro HAYASHI wrote: > > * What was the outcome of this action? > > Plan A. […] > > Plan B. […] > On Fri, Aug 18, 2023 at 09:37:54AM +, gwili.stif...@easymailer.live wrote: > > Plan C. […] There's perhaps a: Plan D. - Package Vagrunt (https://github.com/vaagrunt/vagrunt) a fork of Vagrant, that is stated should remain free software. And as it does not have a CLA, if it gets several contributions it will be increasingly hard to relicense. - Transition from vagrant to vagrunt via a transitional package. (We use Vagrant at work, and I'm not planning on relying on a non-free tool, so a fork would do, otherwise I'd have to look into alternatives for us to switch to.) > Hopefully, being burned a second time will teach me to not put my > volunteer time in non-copyleft packages provided by a single > corporation. While it's certainly true that contributing into a project with single-corp-control + non-copyleft has uncertain odds to take, at least everyone is on the same footing. I think, as Lucas has mentioned, the most problematic aspect in this kind of cases is where there are both single-corp-control and a CLA, as that's what grants the possibility of a relicense and this asymmetrical relationship, which could have happened here as well even with a copyleft license. (Out of principle I never sign CLAs for my volunteer work, with the exception of the one for the FSF due to its nature and its assurances, but which I supposedly rescinded some time ago anyway.) Thanks, Guillem
Bug#1049999: vagrant: the future of packaging vagrant in Debian
On Sat, Aug 19, 2023 at 06:46:06AM +0200, Lucas Nussbaum wrote: > Hi, > > This license change is so disappointing... > > On 18/08/23 at 08:07 -0300, Antonio Terceiro wrote: > > > Plan B. > > > > > > - Drop vagrant because of that changed licence and no need to > > > keep older vagrant. > > > - No vagrant avaiable in Debian. Just use upstream's package. > > > > I think keeping a stale version of vagrant in the archive is worse than > > telling people to just use upstream packages. > > A follow-up question, especially in the case of Plan B, is: what do we > do about Debian Vagrant images provided on Vagrant Cloud > (https://app.vagrantup.com/debian/) ? > > A/ continue to maintain them. But as the main uploader of those images >in the recent times, I might not continue to maintain them, especially >if I move to another tool for my own uses, so we might need to look >for other volunteers. > B/ stop maintaining them >B.1/ ... and remove existing images from the 'debian' Vagrant Cloud >account >B.2/ ... and leave the 'debian' Vagrant Cloud account as it is >currently > > I don't think B.2 is a good idea. I agree. Just as we provide cloud images for proprietary platforms, I think we as a project want to control what is available as "Debian" for Vagrant users, just like we do with images targetted at proprietary cloud platforms. > > Hopefully, being burned a second time will teach me to not put my > > volunteer time in non-copyleft packages provided by a single > > corporation. > > Note that the fact that Vagrant was using a non-copyleft license is not > entirely relevant. The same relicensing could be achieved by > organizations using a copyleft licence with a copyright transfer > agreement for external contributions. (I suspect that this is how it was > achieved for other Hashicorp products, but I haven't checked). Yes, that's true. signature.asc Description: PGP signature
Bug#1049999: vagrant: the future of packaging vagrant in Debian
Hi, This license change is so disappointing... On 18/08/23 at 08:07 -0300, Antonio Terceiro wrote: > > Plan B. > > > > - Drop vagrant because of that changed licence and no need to > > keep older vagrant. > > - No vagrant avaiable in Debian. Just use upstream's package. > > I think keeping a stale version of vagrant in the archive is worse than > telling people to just use upstream packages. A follow-up question, especially in the case of Plan B, is: what do we do about Debian Vagrant images provided on Vagrant Cloud (https://app.vagrantup.com/debian/) ? A/ continue to maintain them. But as the main uploader of those images in the recent times, I might not continue to maintain them, especially if I move to another tool for my own uses, so we might need to look for other volunteers. B/ stop maintaining them B.1/ ... and remove existing images from the 'debian' Vagrant Cloud account B.2/ ... and leave the 'debian' Vagrant Cloud account as it is currently I don't think B.2 is a good idea. > Hopefully, being burned a second time will teach me to not put my > volunteer time in non-copyleft packages provided by a single > corporation. Note that the fact that Vagrant was using a non-copyleft license is not entirely relevant. The same relicensing could be achieved by organizations using a copyleft licence with a copyright transfer agreement for external contributions. (I suspect that this is how it was achieved for other Hashicorp products, but I haven't checked). Lucas signature.asc Description: PGP signature
Bug#1049999: vagrant: the future of packaging vagrant in Debian
Source: vagrant Followup-For: Bug #104 Please consider officially orphaning the package if realistically you are the only maintainer of this package. This should help increase the visibility of the problem and make users think more about whether using vagrant from debian is the right solution to whatever they may be trying to achieve.
Bug#1049999: vagrant: the future of packaging vagrant in Debian
Hi, FWIW, I have been maintaining vagrant in Debian for several years. Thank you for raising this as I have been too lazy to push this discussion. I am copying the Debian Ruby team plus all the people that I could find listed as maintainer or uploader of vagrant related packages (mostly plugins, vagrant-*, but also other related packages) so that they are aware. TL;DR: I will not be maintaining vagrant anymore. On Fri, Aug 18, 2023 at 02:56:28PM +0900, Kentaro HAYASHI wrote: > Package: vagrant > Version: 2.3.4+dfsg-1 > Severity: normal > X-Debbugs-Cc: ken...@xdump.org > > Dear Maintainer, > > * What led up to the situation? > > HashiCorp adopts the BSL. > > https://ir.hashicorp.com/news-releases/news-release-details/hashicorp-adopts- > business-source-license-future-releases-its This is the second time a package to which I dedicated extensive amount of my time is made effectively non-free by its corporate upstream. The first time was with Chef: while the license itself was not changed, they started imposing trademark-related requirements that would impose a large amount of busywork to keep something that looks like Chef (Cinc, their "community" fork) in Debian. I decided to just give up, and moved on to using something else. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959981 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963750 This is now my second time with this, and this time HashiCorp actually made new versions of vagrant non-free. I have used Chef Inc and HashiCorp stuff for free for several years, but I also put in a large amount of work to make their tools available trivially to Debian users by taking care of those packages in the Debian archive. Both Chef Inc and HashiCorp care a lot about having people that use Debian consuming their products, so much so that they provide binary packages for Debian. But they don't care at all about the time of downstream maintainers, and why would they? They are private companies trying to maximize their profit at the expense of whoever is in their way. In this case, HashiCorp is apparently trying to counter other companies who are selling solutions based on their tools that compete with them, they have no incentive to care about the time of a few individuals. I don't see this change as a particularly evil move, but it effectively destroys my motivation to continue working on it. > Currently, vagrant 2.3.4+dfsg-1 was packaged in debian. > > * What exactly did you do (or not do) that was effective (or > ineffective)? > > Should we keep non-BSL licenced version (A) or drop it (B)? > > * What was the outcome of this action? > > Plan A. > > - Update to 2.3.7 and hold it. (2.3.7 is the last non-BSL licenced > version) > - Follow a newer version only when BSL limitation expired (4 years). > - As a result, we can't use newer feature in timely manner if you stick > on packaged vagrant in Debian. I had already looked into this, even before the relicensing being announced, and it turns out that vagrant 2.3.7 has a few extra dependencies that would need to be packaged too (something like 3 or 4 NEW packages), and I wasn't ready to put the necessary work in yet. After the news came out, I gave up on doing it entirely, since after this vagrant would be a dead end. > Plan B. > > - Drop vagrant because of that changed licence and no need to > keep older vagrant. > - No vagrant avaiable in Debian. Just use upstream's package. I think keeping a stale version of vagrant in the archive is worse than telling people to just use upstream packages. As far as my volunteer time is concerned, this is the most likely outcome. I have some private notes on my requirements for a vagrant replacement, and when I reach a conclusion I will most probably pursue this path and just move on. On Fri, Aug 18, 2023 at 09:37:54AM +, gwili.stif...@easymailer.live wrote: > Source: vagrant > Followup-For: Bug #104 > > Plan C. > > - Move BSL-licenced versions of vagrant into debian's non-free section. I will not maintain any packages in non-free. Hopefully, being burned a second time will teach me to not put my volunteer time in non-copyleft packages provided by a single corporation. signature.asc Description: PGP signature
Bug#1049999: vagrant: the future of packaging vagrant in Debian
Source: vagrant Followup-For: Bug #104 Plan C. - Move BSL-licenced versions of vagrant into debian's non-free section.
Bug#1049999: vagrant: the future of packaging vagrant in Debian
Package: vagrant Version: 2.3.4+dfsg-1 Severity: normal X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, * What led up to the situation? HashiCorp adopts the BSL. https://ir.hashicorp.com/news-releases/news-release-details/hashicorp-adopts- business-source-license-future-releases-its Currently, vagrant 2.3.4+dfsg-1 was packaged in debian. * What exactly did you do (or not do) that was effective (or ineffective)? Should we keep non-BSL licenced version (A) or drop it (B)? * What was the outcome of this action? Plan A. - Update to 2.3.7 and hold it. (2.3.7 is the last non-BSL licenced version) - Follow a newer version only when BSL limitation expired (4 years). - As a result, we can't use newer feature in timely manner if you stick on packaged vagrant in Debian. Plan B. - Drop vagrant because of that changed licence and no need to keep older vagrant. - No vagrant avaiable in Debian. Just use upstream's package. * What outcome did you expect instead? N/A
