A set of build scripts on top of gitian and vagrant for automating gitian builds...

[maaku]

...on any platform using Oracle VirtualBox. A minimum number of host dependencies are required.

The gitian build process produces deterministic builds and living documentation of the build process. However gitian only runs within a Linux host environment, and has proven somewhat tricky to setup and maintain. The purpose of this pull-request is to provide a platform-independent set of scripts for creating a gitian build environment and launching builds for all platforms using Oracle VirtualBox, Vagrant (for recording configurations of VirtualBox; see http://vagrantup.com/), and gitian LXC containers.

See “contrib/vagrant/README.md” for details.

[luke-jr]

Gitian is currently Ubuntu-only; how does this attempt to address that?

Vagrant is also Ruby, which is itself not a platform-independent dependency.

[maaku]

By "platform-independent" I meant any platform where the bitcoin reference client currently runs. Vagrant is a tool for specifying the state of VirtualBox instances, so this is necessarily limited to platforms that VirtualBox run on (Mac OS X, Windows, Linux, and Solaris on x86_64). Ruby runs on all of those platforms too.

What these scripts do is build a VirtualBox instance containing Ubuntu 12.04, then calls Gitian with USE_LXC=1. It also patches gitian and the gitian build scripts as needed to run within VirtualBox, downloads the various dependencies, etc.

[luke-jr]

I see, that does sound possibly useful.

[laanwj]

Great development! At least Virtualbox runs on more platforms than KVM, which is Linux-only.

@luke-jr How is Ruby not platform independent? AFAIK it has been ported to neigh everything, just like Python.

[luke-jr]

@laanwj I meant in terms of it not being a standard component of most operating systems. But it occurred to me that I'm not the audience for this patch anyway, and the audience it's intended for probably couldn't care less whether they have Ruby installed or not.

[TheBlueMatt]

I think this is awesome, but I'm not so sure about putting it in bitcoin itself, would it not make more sense to put this in gitian-builder and then let it read the gitian descriptors?

[devrandom]

I'd be up for merging the appropriate parts into gitian-builder. Pull request welcome.

[maaku]

Just to be clear, very little of this pull request has anything to do with gitian. @bluematt and I had a discussion about this on IRC, and I agree now that it would have been better if I had never mentioned gitian.

The purpose of these scripts is to enable a developer on Windows to create Windows binaries, or a Mac developer to generate Linux binaries (two actual use cases I encountered), as well as any other combination of build-host system. Gitian is being used simply because it is the most reliable process for doing cross-platform builds of bitcoind and Bitcoin-Qt.

Included are are a handful of fixes required to get gitian running within an already-virtualized environment, and in time (aka, when I or someone else has time) those patches will be generalized and submitted upstream to gitian-builder. But that should be a minor footnote. This is really about doing cross-platform or local builds without complicated dedicated build servers.

[BitcoinPullTester]

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/aac4cfa93d4dae1941ac71233d824da00552069d for binaries and test log.

[gavinandresen]

I gitian-built the 0.7.0 release on my Mac inside a VirtualBox (running Ubuntu) -- see the last part of contrib/gitian-descriptors/README for what worked for me.

Keeping the contrib/vagrant/patch/*.patch files up-to-date with any changes to the gitian-builder/ files looks like something we're very likely to forget to do, and I'm hesitant to have Yet Another Way to build (we've already got gitian-KVM and gitian-LXC).

[jgarzik]

meh due to maintenance burden as @gavinandresen points out (but pointedly not NAK'ing, in case somebody else disagrees, and wants to pull)

[gavinandresen]

We can't keep up with the pull requests and features we've already got. Closing this, because we don't have bandwidth to test/maintain.