Getting Started Testing with Linux virtual machine on Windows host
I'm primarily a Windows developer, but like to be able to test locally on both Windows and Linux so I don't have to wait for Boost's regression tests to cycle. For several years I've done that on a Linux virtual machine. I just rebuilt my virtual machine and kept a log so I could share how it is done. Such a virtual machine is free and is easy enough that most Boost library maintainers who use Windows could do the setup in an afternoon, most of which is just downloading files, and can be overlapped with other work. See https://svn.boost.org/trac/boost/wiki/StartTestingLinuxOnWindows Corrections or other comments appreciated. Enjoy! --Beman PS: The process would work in the other direction too, but it would require a Windows license (I.E. not free) and I don't have experience going in that direction so can't write about it.
Why not create a vagrant config for this: http://www.vagrantup.com?
On Mon, Dec 16, 2013 at 1:59 PM, James Sharpe <mail@jsharpe.net> wrote: Why not create a vagrant config for this: http://www.vagrantup.com?
Very interesting! I had never heard of Vagrant. Dave Abrahams has voiced the opinion that a test-on-demand setup moving Boost closer to a continuous integration environment would be a lot easier to implement if the testers were running in uniformly configured virtual machines. While Dave's point was well taken, I was having trouble understanding how that could be easily and cheaply implemented. It appears Vagrant might be very helpful in attacking that problem. I doubt I'm going to have enough time to try Vagrant any time soon, so I think it would be great if someone else could give it a try and report back about the experience. Thanks, --Beman
On 17.12.2013 17:58, Beman Dawes wrote:
On Mon, Dec 16, 2013 at 1:59 PM, James Sharpe <mail@jsharpe.net> wrote:
Why not create a vagrant config for this: http://www.vagrantup.com?
Very interesting! I had never heard of Vagrant.
Dave Abrahams has voiced the opinion that a test-on-demand setup moving Boost closer to a continuous integration environment would be a lot easier to implement if the testers were running in uniformly configured virtual machines.
What 'uniformly configured' means exactly? I don't think that could mean that all Linux testers use VM with Ubuntu 13.10 32-bit, since that would not detect any RHEL5 64-bit bugs? - Volodya
On Tue, Dec 17, 2013 at 9:23 AM, Vladimir Prus <ghost@cs.msu.su> wrote:
On 17.12.2013 17:58, Beman Dawes wrote:
On Mon, Dec 16, 2013 at 1:59 PM, James Sharpe <mail@jsharpe.net> wrote:
Why not create a vagrant config for this: http://www.vagrantup.com?
Very interesting! I had never heard of Vagrant.
Dave Abrahams has voiced the opinion that a test-on-demand setup moving Boost closer to a continuous integration environment would be a lot easier to implement if the testers were running in uniformly configured virtual machines.
What 'uniformly configured' means exactly? I don't think that could mean that all Linux testers use VM with Ubuntu 13.10 32-bit, since that would not detect any RHEL5 64-bit bugs?
- Volodya
I agree, we've never had very uniform configuration before, but that meant we've had a lot of diversity in our tests. Though this makes setting up a tester more difficult, it gives us a lot of unique coverage. I'd consider this a huge plus, with the correlating downside being that it can be very difficult to get a test runner setup. Another way to think about our great diversity, look at the platforms: AIX, FreeBSD (also Mac), Linux, Windows. Then multiply them by all the different compiler+library configurations: gcc-4.[4-8], gcc* with cpp[98,11,1y], clang-3.[0-4], clang* with libstd++, intel-[11,12,13], msvc-[8-12], msvc with stlport, borland?, gcc* mingw, and more! We would literally need hundreds of setups to get all those combinations. Plus, I think several of the people who run tests don't have them running in a VM, they just kick them off from the command line. (Although all my teeks99-* tests are run with the exact same VM image...one for linux one for windows.) Speaking of windows, I get the impression from reading the vagrant site that they don't work well with windows. The only reference I found to vagrant with windows was this github repo: https://github.com/WinRb/vagrant-windows which indicated that you would need to have a base windows VM image. In this case, licensing would obviously preclude it from being distributed amongst testers. One idea for the windows side, is to ask if Microsoft would be interested in donating some Azure virtual machines to dedicate to boost visual studio testing. We could get one machine image setup for each of the five supported compilers and then use a vagrant-like system to work with a CI scheduler to test those compilers. Tom
On Mon, Dec 16, 2013 at 11:42 AM, Beman Dawes <bdawes@acm.org> wrote:
I'm primarily a Windows developer, but like to be able to test locally on both Windows and Linux so I don't have to wait for Boost's regression tests to cycle. For several years I've done that on a Linux virtual machine. I just rebuilt my virtual machine and kept a log so I could share how it is done.
Such a virtual machine is free and is easy enough that most Boost library maintainers who use Windows could do the setup in an afternoon, most of which is just downloading files, and can be overlapped with other work.
See https://svn.boost.org/trac/boost/wiki/StartTestingLinuxOnWindows
Corrections or other comments appreciated.
Hopefully this won't cause a Linux distribution flame war, but I run Fedora Linux in VirtualBox mainly because it tends to be one of the first distributions to release the latest g++/clang++ compilers. After installing the distribution, installing vbox additions on Fedora (and maybe other distributions) requires you: - Use the VirtualBox Manager app storage settings to "insert" VBoxGuestAdditions.iso into the CD/DVD-ROM drive - Use the Linux file manager to open the CD/DVD-ROM drive containing the VBoxGuestAdditions.iso and click "Run Software". Recommend changing: sudo mv b2 /usr/bin to sudo mv b2 /usr/local/bin Michael
Enjoy!
--Beman
PS: The process would work in the other direction too, but it would require a Windows license (I.E. not free) and I don't have experience going in that direction so can't write about it.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Dec 17, 2013 at 10:28 AM, Cox, Michael <mhcox@bluezoosoftware.com> wrote:
Recommend changing:
sudo mv b2 /usr/bin
to
sudo mv b2 /usr/local/bin
/usr/bin is managed by package managers. You shouldn't normally put anything there since (a) it can be overwritten with the next package update and (b) you don't see what is custom-built and what is installed with packages (this comes in the way when upgrading the system). /usr/local/bin is better in this sense, but still I prefer not to put anything there anyway. I put my custom binaries to ~/bin. I'm on Kubuntu though, not sure if Fedora supports ~/bin.
On 17 December 2013 07:08, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Tue, Dec 17, 2013 at 10:28 AM, Cox, Michael <mhcox@bluezoosoftware.com> wrote:
Recommend changing:
sudo mv b2 /usr/bin
to
sudo mv b2 /usr/local/bin
/usr/bin is managed by package managers. You shouldn't normally put anything there since (a) it can be overwritten with the next package update and (b) you don't see what is custom-built and what is installed with packages (this comes in the way when upgrading the system).
It's probably better to use 'sudo ./b2 install --prefix=/usr/local' to install the whole thing for standalone use.
/usr/local/bin is better in this sense, but still I prefer not to put anything there anyway. I put my custom binaries to ~/bin. I'm on Kubuntu though, not sure if Fedora supports ~/bin.
I do something similar, but in this case it's a virtual machine, so management of '/usr/local' is less of a concern.
On 17 December 2013 13:27, Daniel James <daniel@calamity.org.uk> wrote:
It's probably better to use 'sudo ./b2 install --prefix=/usr/local' to install the whole thing for standalone use.
Sorry, that should be from 'tools/build/v2' so that it just installs all of boost build, not all of boost.
On Tue, Dec 17, 2013 at 9:07 AM, Daniel James <daniel@calamity.org.uk>wrote:
On 17 December 2013 13:27, Daniel James <daniel@calamity.org.uk> wrote:
It's probably better to use 'sudo ./b2 install --prefix=/usr/local' to install the whole thing for standalone use.
Sorry, that should be from 'tools/build/v2' so that it just installs all of boost build, not all of boost.
Seems a bit simpler to recommend "sudo mv b2 /usr/bin", although I don't feel strongly about that. --Beman
On 17 December 2013 14:33, Beman Dawes wrote:
Seems a bit simpler to recommend "sudo mv b2 /usr/bin", although I don't feel strongly about that.
If your docs are specific to Ubuntu then it doesn't really matter, but not all distros support "sudo make me a sandwich" out of the box. On my Fedora systems I would get this: $ sudo mv b2 /usr/bin [sudo] password for redi: Sorry, user redi is not allowed to execute '/bin/mv b2 /usr/bin' as root on moria.localdomain.
On 12/18/2013 10:01 PM, Jonathan Wakely wrote:
On 17 December 2013 14:33, Beman Dawes wrote:
Seems a bit simpler to recommend "sudo mv b2 /usr/bin", although I don't feel strongly about that.
If your docs are specific to Ubuntu then it doesn't really matter, but not all distros support "sudo make me a sandwich" out of the box. On my Fedora systems I would get this:
$ sudo mv b2 /usr/bin [sudo] password for redi: Sorry, user redi is not allowed to execute '/bin/mv b2 /usr/bin' as root on moria.localdomain.
Are you sure you would have this problem if you run Fedora in a virtual machine you created, You would have full root access, wouldn't you? -- Bjørn
On 18 December 2013 22:22, Bjørn Roald wrote:
On 12/18/2013 10:01 PM, Jonathan Wakely wrote:
On 17 December 2013 14:33, Beman Dawes wrote:
Seems a bit simpler to recommend "sudo mv b2 /usr/bin", although I don't feel strongly about that.
If your docs are specific to Ubuntu then it doesn't really matter, but not all distros support "sudo make me a sandwich" out of the box. On my Fedora systems I would get this:
$ sudo mv b2 /usr/bin [sudo] password for redi: Sorry, user redi is not allowed to execute '/bin/mv b2 /usr/bin' as root on moria.localdomain.
Are you sure you would have this problem if you run Fedora in a virtual machine you created,
I haven't tried, but are you suggesting the default sudoers file is different if Fedora is installed in a VM? How does the OS know it's running as a VM guest?
You would have full root access, wouldn't you?
No, not as a non-root user you create. Not by default anyway. I think you can make "sudo make me a sandwich" work by creating the user as an Administrator during the Fedora installation process, which causes the user to be added to the 'wheel' group.
On 12/19/2013 02:13 AM, Jonathan Wakely wrote:
On 18 December 2013 22:22, Bjørn Roald wrote:
On 12/18/2013 10:01 PM, Jonathan Wakely wrote:
On 17 December 2013 14:33, Beman Dawes wrote:
Seems a bit simpler to recommend "sudo mv b2 /usr/bin", although I don't feel strongly about that.
If your docs are specific to Ubuntu then it doesn't really matter, but not all distros support "sudo make me a sandwich" out of the box. On my Fedora systems I would get this:
$ sudo mv b2 /usr/bin [sudo] password for redi: Sorry, user redi is not allowed to execute '/bin/mv b2 /usr/bin' as root on moria.localdomain.
Are you sure you would have this problem if you run Fedora in a virtual machine you created,
I haven't tried, but are you suggesting the default sudoers file is different if Fedora is installed in a VM? How does the OS know it's running as a VM guest?
No, I am not suggesting that. You could add redi ALL=(ALL:ALL) ALL to /etc/sudoers then to make the procedure work, or simply use su instead to log in as root before the install step.
You would have full root access, wouldn't you?
No, not as a non-root user you create. Not by default anyway.
OK, I was in the impression you tried in on a machine where you did not have root access as in not having the root password in your case.
I think you can make "sudo make me a sandwich" work by creating the user as an Administrator during the Fedora installation process, which causes the user to be added to the 'wheel' group.
In that case you should be able to add the user to the "wheel" group at any time to make the sudo based procedure work. But that is likely to be specific for that distribution. -- Bjørn
On Dec 19, 2013 6:37 AM, "Bjørn Roald" wrote:
On 12/19/2013 02:13 AM, Jonathan Wakely wrote:
On 18 December 2013 22:22, Bjørn Roald wrote:
On 12/18/2013 10:01 PM, Jonathan Wakely wrote:
On 17 December 2013 14:33, Beman Dawes wrote:
Seems a bit simpler to recommend "sudo mv b2 /usr/bin", although I
don't
feel strongly about that.
If your docs are specific to Ubuntu then it doesn't really matter, but not all distros support "sudo make me a sandwich" out of the box. On my Fedora systems I would get this:
$ sudo mv b2 /usr/bin [sudo] password for redi: Sorry, user redi is not allowed to execute '/bin/mv b2 /usr/bin' as root on moria.localdomain.
Are you sure you would have this problem if you run Fedora in a virtual machine you created,
I haven't tried, but are you suggesting the default sudoers file is different if Fedora is installed in a VM? How does the OS know it's running as a VM guest?
No, I am not suggesting that. You could add
redi ALL=(ALL:ALL) ALL
to /etc/sudoers then to make the procedure work, or simply use su instead to log in as root before the install step.
Yes, I know. My point is that the current instructions don't work out of the box on Fedora.
You would have full root access, wouldn't you?
No, not as a non-root user you create. Not by default anyway.
OK, I was in the impression you tried in on a machine where you did not
have root access as in not having the root password in your case. I have root access on my own systems, that's not the point. The instructions assume you are working as a non-root user. If you have root access why use sudo at all?
I think you can make "sudo make me a sandwich" work by creating the user as an Administrator during the Fedora installation process, which causes the user to be added to the 'wheel' group.
In that case you should be able to add the user to the "wheel" group at
any time to make the sudo based procedure work. But that is likely to be specific for that distribution. Yes I know, that's not the point.What I was saying is the current instructions (which are meant for people without GNU/Linux experience, not for me) don't work out of the box on other distros. Providing another distro-specific workaround is not going to solve that. But as I said in the first place, if it's expected that people follow those instructions exactly and use the suggested distro then it doesn't matter.
On 12/19/2013 10:14 AM, Jonathan Wakely wrote:
On Dec 19, 2013 6:37 AM, "Bjørn Roald" wrote:
On 12/19/2013 02:13 AM, Jonathan Wakely wrote:
On 18 December 2013 22:22, Bjørn Roald wrote:
You would have full root access, wouldn't you?
No, not as a non-root user you create. Not by default anyway.
OK, I was in the impression you tried in on a machine where you did not have root access as in not having the root password in your case.
I have root access on my own systems, that's not the point. The instructions assume you are working as a non-root user.
agreed, but with root password you have access to root privileges and thus have alternatives to using sudo that can be explained without having separate set of instructions to various linux distros.
If you have root access why use sudo at all?
Because it is convenient shorthand and it is simpler to avoid doing more than you should with root privileges. It is also much simpler than alternatives to document in instructions such as those that are discussing here. I would prefer instructions to be using sudo even if I did not have it on my system. For those that don't know sudo, provide a note or link with information about sudo and alternatives. Such as: For info on the sudo command see: http://en.wikipedia.org/wiki/Sudo We are running circles around what we mean by "root access", we don't disagree, we just misinterpret each other. Note that on many systems including ubuntu, The system is configured so sudo users have access to general root privileges as they can run: $sudo bash or $sudo -i and thus be logged on as root in the bash shell without knowing a root password. Just as you can with su and a password. We are off topic and should stop. -- Bjørn
On Tue, Dec 17, 2013 at 1:28 AM, Cox, Michael <mhcox@bluezoosoftware.com>wrote:
On Mon, Dec 16, 2013 at 11:42 AM, Beman Dawes <bdawes@acm.org> wrote:
Hopefully this won't cause a Linux distribution flame war, but I run Fedora Linux in VirtualBox mainly because it tends to be one of the first distributions to release the latest g++/clang++ compilers.
I inserted most of your comment above into the introduction to let readers know Fedora is another possibility.
After installing the distribution, installing vbox additions on Fedora (and maybe other distributions) requires you:
- Use the VirtualBox Manager app storage settings to "insert" VBoxGuestAdditions.iso into the CD/DVD-ROM drive - Use the Linux file manager to open the CD/DVD-ROM drive containing the VBoxGuestAdditions.iso and click "Run Software".
IIRC, that was the documented procedure and how I always did it, but then I blundered into the approach given and found it a bit easier. Could you please check and see if the "Devices" menu for your virtual machine running Fedora also has "Insert Guest Additions CD Image..." entry?
Recommend changing:
sudo mv b2 /usr/bin
to
sudo mv b2 /usr/local/bin
Done. Works as expected. Thanks. Since I'm not very knowledgeable about Linux or other POSIX-like systems, I tend to make really stupid mistakes. Anyone should raise a red flag if they spot something that doesn't seem right.
--Beman
On Tue, Dec 17, 2013 at 6:24 PM, Beman Dawes <bdawes@acm.org> wrote:
On Tue, Dec 17, 2013 at 1:28 AM, Cox, Michael <mhcox@bluezoosoftware.com>wrote:
Recommend changing:
sudo mv b2 /usr/bin
to
sudo mv b2 /usr/local/bin
Done. Works as expected. Thanks.
Since I'm not very knowledgeable about Linux or other POSIX-like systems, I tend to make really stupid mistakes. Anyone should raise a red flag if they spot something that doesn't seem right.
Please, please don't recommend putting anything into /usr/bin. See my reply to Michael.
On Tue, Dec 17, 2013 at 06:36:24PM +0400, Andrey Semashev wrote:
On Tue, Dec 17, 2013 at 6:24 PM, Beman Dawes <bdawes@acm.org> wrote:
On Tue, Dec 17, 2013 at 1:28 AM, Cox, Michael <mhcox@bluezoosoftware.com>wrote:
Recommend changing:
sudo mv b2 /usr/bin
to
sudo mv b2 /usr/local/bin
Done. Works as expected. Thanks.
Since I'm not very knowledgeable about Linux or other POSIX-like systems, I tend to make really stupid mistakes. Anyone should raise a red flag if they spot something that doesn't seem right.
Please, please don't recommend putting anything into /usr/bin. See my reply to Michael.
A major red flag I see is: you're messing with global machine state even if you work with /usr/local. I'd recommend that you avoid touching anything outside of the user unless you really need to. The less persistent state you end up with after testing a build, the less cruft will build up in the machine over time. The last thing you want is stray files from a previous test or unrelated test kicking in and tricking you. If you run your tests from a user, you can trivially make another one or recreate it if you suspect you've tainted it. With global state, you pretty much have to re-provision the whole machine. -- Lars Viklund | zao@acc.umu.se
On 17 December 2013 14:36, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Tue, Dec 17, 2013 at 6:24 PM, Beman Dawes <bdawes@acm.org> wrote:
On Tue, Dec 17, 2013 at 1:28 AM, Cox, Michael <mhcox@bluezoosoftware.com>wrote:
Recommend changing:
sudo mv b2 /usr/bin
to
sudo mv b2 /usr/local/bin
Done. Works as expected. Thanks.
Since I'm not very knowledgeable about Linux or other POSIX-like systems, I tend to make really stupid mistakes. Anyone should raise a red flag if they spot something that doesn't seem right.
Please, please don't recommend putting anything into /usr/bin. See my reply to Michael.
You misread Michael Cox. He was recommending change from '/usr/bin' to '/usr/local/bin'.
On Tue, Dec 17, 2013 at 7:36 PM, Daniel James <daniel@calamity.org.uk> wrote:
On 17 December 2013 14:36, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Tue, Dec 17, 2013 at 6:24 PM, Beman Dawes <bdawes@acm.org> wrote:
On Tue, Dec 17, 2013 at 1:28 AM, Cox, Michael <mhcox@bluezoosoftware.com>wrote:
Recommend changing:
sudo mv b2 /usr/bin
to
sudo mv b2 /usr/local/bin
Done. Works as expected. Thanks.
Since I'm not very knowledgeable about Linux or other POSIX-like systems, I tend to make really stupid mistakes. Anyone should raise a red flag if they spot something that doesn't seem right.
Please, please don't recommend putting anything into /usr/bin. See my reply to Michael.
You misread Michael Cox. He was recommending change from '/usr/bin' to '/usr/local/bin'.
Oh, sorry then.
On Tue, Dec 17, 2013 at 12:28 AM, Cox, Michael <mhcox@bluezoosoftware.com> wrote:
On Mon, Dec 16, 2013 at 11:42 AM, Beman Dawes <bdawes@acm.org> wrote:
I'm primarily a Windows developer, but like to be able to test locally on both Windows and Linux so I don't have to wait for Boost's regression tests to cycle. For several years I've done that on a Linux virtual machine. I just rebuilt my virtual machine and kept a log so I could share how it is done.
Such a virtual machine is free and is easy enough that most Boost library maintainers who use Windows could do the setup in an afternoon, most of which is just downloading files, and can be overlapped with other work.
See https://svn.boost.org/trac/boost/wiki/StartTestingLinuxOnWindows
Corrections or other comments appreciated.
Hopefully this won't cause a Linux distribution flame war, but I run Fedora Linux in VirtualBox mainly because it tends to be one of the first distributions to release the latest g++/clang++ compilers. After installing the distribution, installing vbox additions on Fedora (and maybe other distributions) requires you:
The best option for getting the latest gcc/clang compilers on ubuntu (that I have found) is to use a couple PPAs. The testers I've been running have all be ubuntu 12.04 (the last LTS release) with the ubuntu-toolchain-r/test PPA for newer gcc versions and the h-rayflood/llvm PPA for newer clang/llvm versions. These usually support the latest compiler a few days after its release. Tom
participants (10)
-
Andrey Semashev -
Beman Dawes -
Bjørn Roald -
Cox, Michael -
Daniel James -
James Sharpe -
Jonathan Wakely -
Lars Viklund -
Tom Kent -
Vladimir Prus