Tails

#1 Updated by intrigeri 2013-08-08 08:01:39

>

> andreas@lenny:~/tails/tails$ rake build
> Using HTTP proxy: http://squeeze.vagrantup.com:3142
> rake aborted!
> There was an error loading a Vagrantfile. The file being loaded
> and the error message are shown below. This is usually caused by
> a syntax error.

> Path: /home/andreas/tails/tails/vagrant/Vagrantfile
> Message: uninitialized constant Vagrant::Action::Box<internal:prelude>:10:in `synchronize'
> /home/andreas/tails/tails/Rakefile:217:in `new'
> /home/andreas/tails/tails/Rakefile:217:in `block (2 levels) in <top (required)>'
> Tasks: TOP => build => vm:up
> (See full trace by running task with --trace)
> 

What OS are you using to run `rake build’?

#2 Updated by akuckartz 2013-08-08 08:10:00

I am using Debian unstable.

#3 Updated by intrigeri 2013-08-08 09:10:17

> I am using Debian unstable.

OK. This process is known to work on Debian Wheezy, but we haven’t
tested it on sid yet AFAIK, so I guess you will be the lucky one who
fixes this :)

>

> [...]
> (See full trace by running task with --trace)
> 

Perhaps following this advice would help?

#4 Updated by akuckartz 2013-08-09 08:47:08

The trace did not really help me. My guess is that the problem is a result of changes between Ruby 1.8 and 1.9:
http://stackoverflow.com/questions/21574/what-is-the-difference-between-ruby-1-8-and-ruby-1-9

#5 Updated by intrigeri 2013-08-09 09:06:42

> The trace did not really help me. My guess is that the problem is a result of changes
> between Ruby 1.8 and 1.9:
> http://stackoverflow.com/questions/21574/what-is-the-difference-between-ruby-1-8-and-ruby-1-9

OK. Do you want to adapt our Rakefile to work with both 1.8 and 1.9?

#6 Updated by akuckartz 2013-08-09 10:22:52

Here is the trace. Maybe someone else has a suggestion:

$ rake build
Using HTTP proxy: http://squeeze.vagrantup.com:3142
rake aborted!
There was an error loading a Vagrantfile. The file being loaded
and the error message are shown below. This is usually caused by
a syntax error.

Path: /home/andreas/tails/tails/vagrant/Vagrantfile
Message: uninitialized constant Vagrant::Action::Box<internal:prelude>:10:in `synchronize'
/home/andreas/tails/tails/Rakefile:217:in `new'
/home/andreas/tails/tails/Rakefile:217:in `block (2 levels) in <top (required)>'
Tasks: TOP => build => vm:up
(See full trace by running task with --trace)
andreas@lenny:~/tails/tails$ rake --trace build
** Invoke build (first_time)
** Invoke parse_build_options (first_time)
** Execute parse_build_options
** Invoke ensure_clean_repository (first_time)
** Execute ensure_clean_repository
** Invoke validate_http_proxy (first_time)
** Execute validate_http_proxy
Using HTTP proxy: http://squeeze.vagrantup.com:3142
** Invoke vm:up (first_time)
** Invoke parse_build_options 
** Invoke validate_http_proxy 
** Execute vm:up
rake aborted!
There was an error loading a Vagrantfile. The file being loaded
and the error message are shown below. This is usually caused by
a syntax error.

Path: /home/andreas/tails/tails/vagrant/Vagrantfile
Message: uninitialized constant Vagrant::Action::Box/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:214:in `rescue in block in procs_for_path'
/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:197:in `block in procs_for_path'
/usr/lib/ruby/vendor_ruby/vagrant/config.rb:53:in `block in capture_configures'
<internal:prelude>:10:in `synchronize'
/usr/lib/ruby/vendor_ruby/vagrant/config.rb:48:in `capture_configures'
/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:196:in `procs_for_path'
/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:182:in `procs_for_source'
/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:57:in `block in set'
/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:51:in `each'
/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:51:in `set'
/usr/lib/ruby/vendor_ruby/vagrant/environment.rb:256:in `config_global'
/usr/lib/ruby/vendor_ruby/vagrant/environment.rb:502:in `block in action_runner'
/usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:28:in `call'
/usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:28:in `run'
/usr/lib/ruby/vendor_ruby/vagrant/environment.rb:274:in `hook'
/usr/lib/ruby/vendor_ruby/vagrant/environment.rb:135:in `initialize'
/home/andreas/tails/tails/Rakefile:217:in `new'
/home/andreas/tails/tails/Rakefile:217:in `block (2 levels) in <top (required)>'
/usr/lib/ruby/vendor_ruby/rake/task.rb:246:in `call'
/usr/lib/ruby/vendor_ruby/rake/task.rb:246:in `block in execute'
/usr/lib/ruby/vendor_ruby/rake/task.rb:241:in `each'
/usr/lib/ruby/vendor_ruby/rake/task.rb:241:in `execute'
/usr/lib/ruby/vendor_ruby/rake/task.rb:184:in `block in invoke_with_call_chain'
/usr/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/usr/lib/ruby/vendor_ruby/rake/task.rb:177:in `invoke_with_call_chain'
/usr/lib/ruby/vendor_ruby/rake/task.rb:205:in `block in invoke_prerequisites'
/usr/lib/ruby/vendor_ruby/rake/task.rb:203:in `each'
/usr/lib/ruby/vendor_ruby/rake/task.rb:203:in `invoke_prerequisites'
/usr/lib/ruby/vendor_ruby/rake/task.rb:183:in `block in invoke_with_call_chain'
/usr/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/usr/lib/ruby/vendor_ruby/rake/task.rb:177:in `invoke_with_call_chain'
/usr/lib/ruby/vendor_ruby/rake/task.rb:170:in `invoke'
/usr/lib/ruby/vendor_ruby/rake/application.rb:143:in `invoke_task'
/usr/lib/ruby/vendor_ruby/rake/application.rb:101:in `block (2 levels) in top_level'
/usr/lib/ruby/vendor_ruby/rake/application.rb:101:in `each'
/usr/lib/ruby/vendor_ruby/rake/application.rb:101:in `block in top_level'
/usr/lib/ruby/vendor_ruby/rake/application.rb:110:in `run_with_threads'
/usr/lib/ruby/vendor_ruby/rake/application.rb:95:in `top_level'
/usr/lib/ruby/vendor_ruby/rake/application.rb:73:in `block in run'
/usr/lib/ruby/vendor_ruby/rake/application.rb:160:in `standard_exception_handling'
/usr/lib/ruby/vendor_ruby/rake/application.rb:70:in `run'
/usr/bin/rake:27:in `<main>'
Tasks: TOP => build => vm:up

#7 Updated by akuckartz 2013-08-09 10:53:02

I just found out that my Vagrant installation is borked. For some reason it contains both files from 1.0 and 1.2. Perhaps the upgrade of the Debian packages did not work correctly. I will first have to resolve this. The Debian package with version 1.2 is only a few weeks old.

#8 Updated by akuckartz 2013-08-09 23:38:58

Ok, I resolved my Vagrant installation issue. It was not the cause of the problem.

#9 Updated by akuckartz 2013-08-10 01:10:19

If I understand the behavior correctly tails/vagrant/lib/vagrant_verified_download.rb seems to have something to do with the problem.

Maybe Vagrant::Action::Box::Verify can be used instead of monkeypatching Vagrant::Action::Box::Download ?

#10 Updated by intrigeri 2013-08-10 01:16:26

> Maybe Vagrant::Action::Box::Verify can be used instead of monkeypatching
> Vagrant::Action::Box::Download ?

If the former does as good a job as the latter, feel free to :)
Please check what Vagrant version introduced the feature you want to use, though.

#11 Updated by akuckartz 2013-08-27 03:30:05

??Vagrant 1.1+ provides full backwards compatibility for valid Vagrant 1.0.x Vagrantfiles which don’t use plugins. After installing Vagrant 1.1, your 1.0.x environments should continue working without modifications, and existing running machines will continue to be managed properly.

If you use any Vagrant 1.0.x plugins, you must remove references to these from your Vagrantfile prior to upgrading.??
http://docs.vagrantup.com/v2/installation/backwards-compatibility.html

#12 Updated by akuckartz 2013-08-27 03:55:02

I enabled vagrant debugging and got this, which confirms that vagrant_verified_download.rb seems to be the culprit:

...
DEBUG loader: Populating proc cache for #<Pathname:/home/andreas/tails/tails/vagrant/Vagrantfile>
DEBUG loader: Load procs for pathname: /home/andreas/tails/tails/vagrant/Vagrantfile
ERROR loader: Vagrantfile load error: uninitialized constant Vagrant::Action::Box
ERROR loader: /home/andreas/tails/tails/vagrant/lib/vagrant_verified_download.rb:26:in `<module:Vagrant>'
/home/andreas/tails/tails/vagrant/lib/vagrant_verified_download.rb:21:in `<top (required)>'
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
/home/andreas/tails/tails/vagrant/Vagrantfile:22:in `<top (required)>'
/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:198:in `load'
/usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:198:in `block in procs_for_path'
/usr/lib/ruby/vendor_ruby/vagrant/config.rb:53:in `block in capture_configures'
...

#13 Updated by akuckartz 2013-09-02 11:11:55

For a test I downgraded Vagrant from version 1.2.2 to 1.0.3. The reported issue perhaps does not exist with that old version. But Vagrant 1.2.2 only supports VirtualBox versions 4.0 and 4.1 but not version 4.2. I do not want to downgrade more packages and therefore will stick with Vagrant 1.2.2 and learn more about Vagrant.

#14 Updated by akuckartz 2013-09-02 12:37:00

Fortunately it is quite simple to remain backwards compatible with Vagrant 1.0.x:

Vagrant.configure("1") do |config|
  # v1 configs...
end

Vagrant.configure("2") do |config|
  # v2 configs...
end

Also important:
“What is Vagrant::Config.run? You may see this in Vagrantfiles. This was actually how Vagrant 1.0.x did configuration. In Vagrant 1.1+, this is synonymous with Vagrant.configure(”1“).”
http://docs.vagrantup.com/v2/vagrantfile/version.html

#15 Updated by intrigeri 2013-09-03 00:57:36

> Fortunately it is quite simple to remain backwards compatible with Vagrant 1.0.x:
> […]

I’m glad you are making progress!

#17 Updated by akuckartz 2013-10-03 08:09:05

intrigeri wrote:
> It would be really great if a Vagrant user could find time to fix it.
> Andreas, any news on that one?

Thanks for confirming the problem.

No news. I currently have higher priority tasks and I therefore can not promise to resolve it soon. I doubt that it is very difficult to resolve for someone fluent in Ruby and Vagrant but neither is Ruby my native language nor was I born in Vagrant. (In any case I now have learned Ruby to understand some of the code :-)

#18 Updated by anonym 2013-10-04 06:22:33

This will be fixed if we move to using vagrant-libvirt (Issue Bug #6212) since it depends on Vagrant 1.2, so our build system would depend on it too.