- OSX —> OS X - XCode —> Xcode - github —> GitHub - homebrew —> Homebrew - gitian —> Gitian - Other miscellaneous obvious spelling fixes and whitespace removaltags/v0.15.1
@@ -7,7 +7,7 @@ Setup | |||
Running | |||
--------------------- | |||
The following are some helpful notes on how to run Bitcoin on your native platform. | |||
The following are some helpful notes on how to run Bitcoin on your native platform. | |||
### Unix | |||
@@ -26,7 +26,7 @@ Unpack the files into a directory and run: | |||
Unpack the files into a directory, and then run bitcoin-qt.exe. | |||
### OSX | |||
### OS X | |||
Drag Bitcoin-Qt to your applications folder, and then run Bitcoin-Qt. | |||
@@ -41,7 +41,7 @@ Building | |||
--------------------- | |||
The following are developer notes on how to build Bitcoin on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc. | |||
- [OSX Build Notes](build-osx.md) | |||
- [OS X Build Notes](build-osx.md) | |||
- [Unix Build Notes](build-unix.md) | |||
- [Gitian Building Guide](gitian-building.md) | |||
@@ -1,12 +1,12 @@ | |||
Deterministic OSX Dmg Notes. | |||
Deterministic OS X Dmg Notes. | |||
Working OSX DMGs are created in Linux by combining a recent clang, | |||
Working OS X DMGs are created in Linux by combining a recent clang, | |||
the Apple's binutils (ld, ar, etc), and DMG authoring tools. | |||
Apple uses clang extensively for development and has upstreamed the necessary | |||
functionality so that a vanilla clang can take advantage. It supports the use | |||
of -F, -target, -mmacosx-version-min, and --sysroot, which are all necessary | |||
when building for OSX. A pre-compiled version of 3.2 is used because it was not | |||
when building for OS X. A pre-compiled version of 3.2 is used because it was not | |||
available in the Precise repositories at the time this work was started. In the | |||
future, it can be switched to use system packages instead. | |||
@@ -29,18 +29,18 @@ originally done in toolchain4. | |||
To complicate things further, all builds must target an Apple SDK. These SDKs | |||
are free to download, but not redistributable. | |||
To obtain it, register for a developer account, then download the XCode 6.1.1 dmg: | |||
To obtain it, register for a developer account, then download the Xcode 6.1.1 dmg: | |||
https://developer.apple.com/devcenter/download.action?path=/Developer_Tools/xcode_6.1.1/xcode_6.1.1.dmg | |||
This file is several gigabytes in size, but only a single directory inside is | |||
needed: Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk | |||
Unfortunately, the usual linux tools (7zip, hpmount, loopback mount) are incapable of opening this file. | |||
To create a tarball suitable for gitian input, mount the dmg in OSX, then create it with: | |||
To create a tarball suitable for Gitian input, mount the dmg in OS X, then create it with: | |||
$ tar -C /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ -czf MacOSX10.9.sdk.tar.gz MacOSX10.9.sdk | |||
The gitian descriptors build 2 sets of files: Linux tools, then Apple binaries | |||
The Gitian descriptors build 2 sets of files: Linux tools, then Apple binaries | |||
which are created using these tools. The build process has been designed to | |||
avoid including the SDK's files in Gitian's outputs. All interim tarballs are | |||
fully deterministic and may be freely redistributed. | |||
@@ -64,20 +64,20 @@ Ideally, the creation could be fixed and genisoimage would no longer be necessar | |||
Background images and other features can be added to DMG files by inserting a | |||
.DS_Store before creation. The easiest way to create this file is to build a | |||
DMG without one, move it to a device running OSX, customize the layout, then | |||
DMG without one, move it to a device running OS X, customize the layout, then | |||
grab the .DS_Store file for later use. That is the approach taken here. | |||
As of OSX Mavericks (10.9), using an Apple-blessed key to sign binaries is a | |||
As of OS X Mavericks (10.9), using an Apple-blessed key to sign binaries is a | |||
requirement in order to satisfy the new Gatekeeper requirements. Because this | |||
private key cannot be shared, we'll have to be a bit creative in order for the | |||
build process to remain somewhat deterministic. Here's how it works: | |||
- Builders use gitian to create an unsigned release. This outputs an unsigned | |||
- Builders use Gitian to create an unsigned release. This outputs an unsigned | |||
dmg which users may choose to bless and run. It also outputs an unsigned app | |||
structure in the form of a tarball, which also contains all of the tools | |||
that have been previously (deterministically) built in order to create a | |||
final dmg. | |||
- The Apple keyholder uses this unsigned app to create a detached signature, | |||
using the script that is also included there. | |||
- Builders feed the unsigned app + detached signature back into gitian. It | |||
- Builders feed the unsigned app + detached signature back into Gitian. It | |||
uses the pre-built tools to recombine the pieces into a deterministic dmg. |
@@ -38,7 +38,7 @@ Do not use `pkg_add boost`! The boost version installed thus is compiled using t | |||
test_bitcoin:/usr/lib/libstdc++.so.57.0: /usr/local/lib/libestdc++.so.17.0 : WARNING: symbol(_ZN11__gnu_debug17_S_debug_me ssagesE) size mismatch, relink your program | |||
... | |||
Segmentation fault (core dumped) | |||
Segmentation fault (core dumped) | |||
This makes it necessary to build boost, or at least the parts used by Bitcoin Core, manually: | |||
@@ -57,7 +57,7 @@ tar -xjf boost_1_59_0.tar.bz2 | |||
# Boost 1.59 needs two small patches for OpenBSD | |||
cd boost_1_59_0 | |||
# Also here: https://gist.githubusercontent.com/laanwj/bf359281dc319b8ff2e1/raw/92250de8404b97bb99d72ab898f4a8cb35ae1ea3/patch-boost_test_impl_execution_monitor_ipp.patch | |||
patch -p0 < /usr/ports/devel/boost/patches/patch-boost_test_impl_execution_monitor_ipp | |||
patch -p0 < /usr/ports/devel/boost/patches/patch-boost_test_impl_execution_monitor_ipp | |||
# https://github.com/boostorg/filesystem/commit/90517e459681790a091566dce27ca3acabf9a70c | |||
sed 's/__OPEN_BSD__/__OpenBSD__/g' < libs/filesystem/src/path.cpp > libs/filesystem/src/path.cpp.tmp | |||
mv libs/filesystem/src/path.cpp.tmp libs/filesystem/src/path.cpp | |||
@@ -92,7 +92,7 @@ tar -xzf db-4.8.30.NC.tar.gz | |||
# Build the library and install to specified prefix | |||
cd db-4.8.30.NC/build_unix/ | |||
# Note: Do a static build so that it can be embedded into the executable, instead of having to find a .so at runtime | |||
../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX CC=egcc CXX=eg++ CPP=ecpp | |||
../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX CC=egcc CXX=eg++ CPP=ecpp | |||
make install | |||
``` | |||
@@ -160,4 +160,3 @@ version installed by OpenBSD 5.7: | |||
- https://llvm.org/bugs/show_bug.cgi?id=9758 | |||
There is no known workaround for this. | |||
@@ -1,6 +1,6 @@ | |||
Mac OS X Build Instructions and Notes | |||
==================================== | |||
This guide will show you how to build bitcoind (headless client) for OSX. | |||
This guide will show you how to build bitcoind (headless client) for OS X. | |||
Notes | |||
----- | |||
@@ -13,8 +13,8 @@ built-in one is located in `/Applications/Utilities`. | |||
Preparation | |||
----------- | |||
You need to install XCode with all the options checked so that the compiler | |||
and everything is available in /usr not just /Developer. XCode should be | |||
You need to install Xcode with all the options checked so that the compiler | |||
and everything is available in /usr not just /Developer. Xcode should be | |||
available on your OS X installation media, but if not, you can get the | |||
current version from https://developer.apple.com/xcode/. If you install | |||
Xcode 4.3 or later, you'll need to install its command line tools. This can | |||
@@ -38,7 +38,7 @@ NOTE: Building with Qt4 is still supported, however, could result in a broken UI | |||
### Building `bitcoind` | |||
1. Clone the github tree to get the source code and go into the directory. | |||
1. Clone the GitHub tree to get the source code and go into the directory. | |||
git clone https://github.com/bitcoin/bitcoin.git | |||
cd bitcoin | |||
@@ -62,7 +62,7 @@ Use Qt Creator as IDE | |||
You can use Qt Creator as IDE, for debugging and for manipulating forms, etc. | |||
Download Qt Creator from http://www.qt.io/download/. Download the "community edition" and only install Qt Creator (uncheck the rest during the installation process). | |||
1. Make sure you installed everything through homebrew mentioned above | |||
1. Make sure you installed everything through Homebrew mentioned above | |||
2. Do a proper ./configure --with-gui=qt5 --enable-debug | |||
3. In Qt Creator do "New Project" -> Import Project -> Import Existing Project | |||
4. Enter "bitcoin-qt" as project name, enter src/qt as location |
@@ -57,7 +57,7 @@ As Doxygen recognizes the comments by the delimiters (`/**` and `*/` in this cas | |||
To describe a class use the same construct above the class definition: | |||
```c++ | |||
/** | |||
/** | |||
* Alerts are for notifying old versions if they become too obsolete and | |||
* need to upgrade. The message is displayed in the status bar. | |||
* @see GetWarnings() |
@@ -7,7 +7,7 @@ As such, DNS seeds must be run by entities which have some minimum | |||
level of trust within the Bitcoin community. | |||
Other implementations of Bitcoin software may also use the same | |||
seeds and may be more exposed. In light of this exposure, this | |||
seeds and may be more exposed. In light of this exposure, this | |||
document establishes some basic expectations for operating dnsseeds. | |||
0. A DNS seed operating organization or person is expected to follow good |
@@ -1,7 +1,7 @@ | |||
Gitian building | |||
================ | |||
*Setup instructions for a gitian build of Bitcoin using a Debian VM or physical system.* | |||
*Setup instructions for a Gitian build of Bitcoin using a Debian VM or physical system.* | |||
Gitian is the deterministic build process that is used to build the Bitcoin | |||
Core executables. It provides a way to be reasonably sure that the | |||
@@ -13,7 +13,7 @@ Multiple developers build the source code by following a specific descriptor | |||
These results are compared and only if they match, the build is accepted and uploaded | |||
to bitcoin.org. | |||
More independent gitian builders are needed, which is why this guide exists. | |||
More independent Gitian builders are needed, which is why this guide exists. | |||
It is preferred you follow these steps yourself instead of using someone else's | |||
VM image to avoid 'contaminating' the build. | |||
@@ -22,9 +22,9 @@ Table of Contents | |||
- [Create a new VirtualBox VM](#create-a-new-virtualbox-vm) | |||
- [Connecting to the VM](#connecting-to-the-vm) | |||
- [Setting up Debian for gitian building](#setting-up-debian-for-gitian-building) | |||
- [Installing gitian](#installing-gitian) | |||
- [Setting up the gitian image](#setting-up-the-gitian-image) | |||
- [Setting up Debian for Gitian building](#setting-up-debian-for-gitian-building) | |||
- [Installing Gitian](#installing-gitian) | |||
- [Setting up the Gitian image](#setting-up-the-gitian-image) | |||
- [Getting and building the inputs](#getting-and-building-the-inputs) | |||
- [Building Bitcoin](#building-bitcoin) | |||
- [Building an alternative repository](#building-an-alternative-repository) | |||
@@ -43,7 +43,7 @@ Any kind of virtualization can be used, for example: | |||
- [KVM](http://www.linux-kvm.org/page/Main_Page) | |||
- [LXC](https://linuxcontainers.org/), see also [Gitian host docker container](https://github.com/gdm85/tenku/tree/master/docker/gitian-bitcoin-host/README.md). | |||
You can also install gitian on actual hardware instead of using virtualization. | |||
You can also install Gitian on actual hardware instead of using virtualization. | |||
Create a new VirtualBox VM | |||
--------------------------- | |||
@@ -60,18 +60,18 @@ In the VirtualBox GUI click "Create" and choose the following parameters in the | |||
 | |||
- Hard Disk: Create a virtual hard disk now | |||
 | |||
- Hard Disk file type: Use the default, VDI (VirtualBox Disk Image) | |||
- Hard Disk file type: Use the default, VDI (VirtualBox Disk Image) | |||
 | |||
- Storage on physical hard disk: Dynamically Allocated | |||
- Storage on physical hard disk: Dynamically Allocated | |||
 | |||
- File location and size: at least 40GB; as low as 20GB *may* be possible, but better to err on the safe side | |||
- File location and size: at least 40GB; as low as 20GB *may* be possible, but better to err on the safe side | |||
- Click `Create` | |||
Get the [Debian 8.x net installer](http://cdimage.debian.org/debian-cd/8.2.0/amd64/iso-cd/debian-8.2.0-amd64-netinst.iso) (a more recent minor version should also work, see also [Debian Network installation](https://www.debian.org/CD/netinst/)). | |||
@@ -81,7 +81,7 @@ Unixy OSes by entering the following in a terminal: | |||
echo "d393d17ac6b3113c81186e545c416a00f28ed6e05774284bb5e8f0df39fcbcb9 debian-8.2.0-amd64-netinst.iso" | sha256sum -c | |||
# (must return OK) | |||
After creating the VM, we need to configure it. | |||
After creating the VM, we need to configure it. | |||
- Click the `Settings` button, then go to the `Network` tab. Adapter 1 should be attached to `NAT`. | |||
@@ -115,8 +115,8 @@ This section will explain how to install Debian on the newly created VM. | |||
 | |||
**Note**: Navigating in the Debian installer: | |||
To keep a setting at the default and proceed, just press `Enter`. | |||
**Note**: Navigating in the Debian installer: | |||
To keep a setting at the default and proceed, just press `Enter`. | |||
To select a different button, press `Tab`. | |||
- Choose locale and keyboard settings (doesn't matter, you can just go with the defaults or select your own information) | |||
@@ -126,23 +126,23 @@ To select a different button, press `Tab`. | |||
 | |||
- The VM will detect network settings using DHCP, this should all proceed automatically | |||
- Configure the network: | |||
- Configure the network: | |||
- Hostname `debian`. | |||
- Leave domain name empty. | |||
 | |||
- Choose a root password and enter it twice (remember it for later) | |||
- Choose a root password and enter it twice (remember it for later) | |||
 | |||
- Name the new user `debian` (the full name doesn't matter, you can leave it empty) | |||
- Name the new user `debian` (the full name doesn't matter, you can leave it empty) | |||
- Set the account username as `debian` | |||
 | |||
 | |||
- Choose a user password and enter it twice (remember it for later) | |||
- Choose a user password and enter it twice (remember it for later) | |||
 | |||
@@ -152,11 +152,11 @@ To select a different button, press `Tab`. | |||
 | |||
- Disk setup | |||
- Partitioning method: Guided - Use the entire disk | |||
- Partitioning method: Guided - Use the entire disk | |||
 | |||
- Select disk to partition: SCSI1 (0,0,0) | |||
- Select disk to partition: SCSI1 (0,0,0) | |||
 | |||
@@ -166,7 +166,7 @@ To select a different button, press `Tab`. | |||
 | |||
- The base system will be installed, this will take a minute or so | |||
- Choose a mirror (any will do) | |||
- Choose a mirror (any will do) | |||
 | |||
@@ -201,7 +201,7 @@ After Installation | |||
The next step in the guide involves logging in as root via SSH. | |||
SSH login for root users is disabled by default, so we'll enable that now. | |||
Login to the VM using username `root` and the root password you choose earlier. | |||
Login to the VM using username `root` and the root password you chose earlier. | |||
You'll be presented with a screen similar to this. | |||
 | |||
@@ -243,7 +243,7 @@ For example, to connect as `root` from a Linux command prompt use | |||
Replace `root` with `debian` to log in as user. | |||
Setting up Debian for gitian building | |||
Setting up Debian for Gitian building | |||
-------------------------------------- | |||
In this section we will be setting up the Debian installation for Gitian building. | |||
@@ -260,7 +260,7 @@ Then set up LXC and the rest with the following, which is a complex jumble of se | |||
```bash | |||
# the version of lxc-start in Debian 7.4 needs to run as root, so make sure | |||
# that the build script can exectute it without providing a password | |||
# that the build script can execute it without providing a password | |||
echo "%sudo ALL=NOPASSWD: /usr/bin/lxc-start" > /etc/sudoers.d/gitian-lxc | |||
# add cgroup for LXC | |||
echo "cgroup /sys/fs/cgroup cgroup defaults 0 0" >> /etc/fstab | |||
@@ -280,7 +280,7 @@ reboot | |||
At the end the VM is rebooted to make sure that the changes take effect. The steps in this | |||
section only need to be performed once. | |||
Installing gitian | |||
Installing Gitian | |||
------------------ | |||
Re-login as the user `debian` that was created during installation. | |||
@@ -300,14 +300,14 @@ cd .. | |||
**Note**: When sudo asks for a password, enter the password for the user *debian* not for *root*. | |||
Clone the git repositories for bitcoin and gitian. | |||
Clone the git repositories for bitcoin and Gitian. | |||
```bash | |||
git clone https://github.com/devrandom/gitian-builder.git | |||
git clone https://github.com/bitcoin/bitcoin | |||
``` | |||
Setting up the gitian image | |||
Setting up the Gitian image | |||
------------------------- | |||
Gitian needs a virtual image of the operating system to build in. | |||
@@ -333,14 +333,14 @@ Getting and building the inputs | |||
Follow the instructions in [doc/release-process.md](release-process.md#fetch-and-build-inputs-first-time-or-when-dependency-versions-change) | |||
in the bitcoin repository under 'Fetch and build inputs' to install sources which require | |||
manual intervention. Also optionally follow the next step: 'Seed the Gitian sources cache | |||
and offline git repositories' which will fetch the remaining files required for building | |||
and offline git repositories' which will fetch the remaining files required for building | |||
offline. | |||
Building Bitcoin | |||
---------------- | |||
To build Bitcoin (for Linux, OSX and Windows) just follow the steps under 'perform | |||
gitian builds' in [doc/release-process.md](release-process.md#perform-gitian-builds) in the bitcoin repository. | |||
To build Bitcoin (for Linux, OS X and Windows) just follow the steps under 'perform | |||
Gitian builds' in [doc/release-process.md](release-process.md#perform-gitian-builds) in the bitcoin repository. | |||
This may take some time as it will build all the dependencies needed for each descriptor. | |||
These dependencies will be cached after a successful build to avoid rebuilding them when possible. | |||
@@ -380,7 +380,7 @@ Building an alternative repository | |||
----------------------------------- | |||
If you want to do a test build of a pull on GitHub it can be useful to point | |||
the gitian builder at an alternative repository, using the same descriptors | |||
the Gitian builder at an alternative repository, using the same descriptors | |||
and inputs. | |||
For example: | |||
@@ -395,9 +395,9 @@ COMMIT=2014_03_windows_unicode_path | |||
Building fully offline | |||
----------------------- | |||
For building fully offline including attaching signatures to unsigned builds, the detached-sigs repository | |||
For building fully offline including attaching signatures to unsigned builds, the detached-sigs repository | |||
and the bitcoin git repository with the desired tag must both be available locally, and then gbuild must be | |||
told where to find them. It also requires an apt-cacher-ng which is fully-populated but set to offline mode, or | |||
told where to find them. It also requires an apt-cacher-ng which is fully-populated but set to offline mode, or | |||
manually disabling gitian-builder's use of apt-get to update the VM build environment. | |||
To configure apt-cacher-ng as an offline cacher, you will need to first populate its cache with the relevant | |||
@@ -417,7 +417,7 @@ LXC_ARCH=amd64 LXC_SUITE=precise on-target -u root \ | |||
-e DEBIAN_FRONTEND=noninteractive apt-get --no-install-recommends -y install \ | |||
$( sed -ne '/^packages:/,/[^-] .*/ {/^- .*/{s/"//g;s/- //;p}}' ../bitcoin/contrib/gitian-descriptors/*|sort|uniq ) | |||
LXC_ARCH=amd64 LXC_SUITE=precise on-target -u root apt-get -q -y purge grub | |||
LXC_ARCH=amd64 LXC_SUITE=precise on-target -u root -e DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade | |||
LXC_ARCH=amd64 LXC_SUITE=precise on-target -u root -e DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade | |||
``` | |||
And then set offline mode for apt-cacher-ng: | |||
@@ -431,7 +431,7 @@ Offlinemode: 1 | |||
service apt-cacher-ng restart | |||
``` | |||
Then when building, override the remote URLs that gbuild would otherwise pull from the gitian descriptors:: | |||
Then when building, override the remote URLs that gbuild would otherwise pull from the Gitian descriptors:: | |||
```bash | |||
cd /some/root/path/ | |||
@@ -461,7 +461,7 @@ in `gitian.sigs` to your signing machine and do | |||
``` | |||
This will create the `.sig` files that can be committed together with the `.assert` files to assert your | |||
gitian build. | |||
Gitian build. | |||
Uploading signatures | |||
--------------------- |
@@ -29,20 +29,20 @@ file, however it is recommended that a strong and secure password be used | |||
as this password is security critical to securing the wallet should the | |||
wallet be enabled. | |||
If bitcoind is run with the "-server" flag (set by default), and no rpcpassword is set, | |||
it will use a special cookie file for authentication. The cookie is generated with random | |||
If bitcoind is run with the "-server" flag (set by default), and no rpcpassword is set, | |||
it will use a special cookie file for authentication. The cookie is generated with random | |||
content when the daemon starts, and deleted when it exits. Read access to this file | |||
controls who can access it through RPC. | |||
controls who can access it through RPC. | |||
By default the cookie is stored in the data directory, but it's location can be overridden | |||
By default the cookie is stored in the data directory, but it's location can be overridden | |||
with the option '-rpccookiefile'. | |||
This allows for running bitcoind without having to do any manual configuration. | |||
`conf`, `pid`, and `wallet` accept relative paths which are interpreted as | |||
`conf`, `pid`, and `wallet` accept relative paths which are interpreted as | |||
relative to the data directory. `wallet` *only* supports relative paths. | |||
For an example configuration file that describes the configuration settings, | |||
For an example configuration file that describes the configuration settings, | |||
see `contrib/debian/examples/bitcoin.conf`. | |||
3. Paths | |||
@@ -93,8 +93,8 @@ use old versions of Upstart and do not supply the start-stop-daemon utility. | |||
Copy bitcoind.init to /etc/init.d/bitcoind. Test by running `service bitcoind start`. | |||
Using this script, you can adjust the path and flags to the bitcoind program by | |||
setting the BITCOIND and FLAGS environment variables in the file | |||
Using this script, you can adjust the path and flags to the bitcoind program by | |||
setting the BITCOIND and FLAGS environment variables in the file | |||
/etc/sysconfig/bitcoind. You can also use the DAEMONOPTS environment variable here. | |||
5. Auto-respawn | |||
@@ -102,4 +102,3 @@ setting the BITCOIND and FLAGS environment variables in the file | |||
Auto respawning is currently only configured for Upstart and systemd. | |||
Reasonable defaults have been chosen but YMMV. | |||
@@ -181,7 +181,7 @@ configured specifically to process scriptPubKey and not scriptSig scripts. | |||
- Removed bitrpc.py from contrib | |||
Addition of ZMQ-based Notifcations | |||
Addition of ZMQ-based Notifications | |||
================================== | |||
Bitcoind can now (optionally) asynchronously notify clients through a |
@@ -6,7 +6,7 @@ Release Process | |||
* * * | |||
###First time / New builders | |||
###First time / New builders | |||
Check out the source code in the following directory hierarchy. | |||
cd /path/to/your/toplevel/build | |||
@@ -34,17 +34,17 @@ Check out the source code in the following directory hierarchy. | |||
* * * | |||
###Setup and perform gitian builds | |||
###Setup and perform Gitian builds | |||
Setup Gitian descriptors: | |||
Setup gitian descriptors: | |||
pushd ./bitcoin | |||
export SIGNER=(your gitian key, ie bluematt, sipa, etc) | |||
export SIGNER=(your Gitian key, ie bluematt, sipa, etc) | |||
export VERSION=(new version, e.g. 0.8.0) | |||
git checkout v${VERSION} | |||
popd | |||
Ensure your gitian.sigs are up-to-date if you wish to gverify your builds against other gitian signatures. | |||
Ensure your gitian.sigs are up-to-date if you wish to gverify your builds against other Gitian signatures. | |||
pushd ./gitian.sigs | |||
git pull | |||
@@ -56,35 +56,35 @@ Check out the source code in the following directory hierarchy. | |||
git pull | |||
###Fetch and create inputs: (first time, or when dependency versions change) | |||
mkdir -p inputs | |||
wget -P inputs https://bitcoincore.org/cfields/osslsigncode-Backports-to-1.7.1.patch | |||
wget -P inputs http://downloads.sourceforge.net/project/osslsigncode/osslsigncode/osslsigncode-1.7.1.tar.gz | |||
Register and download the Apple SDK: see [OSX readme](README_osx.txt) for details. | |||
Register and download the Apple SDK: see [OS X readme](README_osx.txt) for details. | |||
https://developer.apple.com/devcenter/download.action?path=/Developer_Tools/xcode_6.1.1/xcode_6.1.1.dmg | |||
Using a Mac, create a tarball for the 10.9 SDK and copy it to the inputs directory: | |||
tar -C /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ -czf MacOSX10.9.sdk.tar.gz MacOSX10.9.sdk | |||
###Optional: Seed the Gitian sources cache and offline git repositories | |||
By default, gitian will fetch source files as needed. To cache them ahead of time: | |||
By default, Gitian will fetch source files as needed. To cache them ahead of time: | |||
make -C ../bitcoin/depends download SOURCES_PATH=`pwd`/cache/common | |||
Only missing files will be fetched, so this is safe to re-run for each build. | |||
NOTE: Offline builds must use the --url flag to ensure gitian fetches only from local URLs. For example: | |||
NOTE: Offline builds must use the --url flag to ensure Gitian fetches only from local URLs. For example: | |||
``` | |||
./bin/bguild --url bitcoin=/path/to/bitcoin,signature=/path/to/sigs {rest of arguments} | |||
./bin/gbuild --url bitcoin=/path/to/bitcoin,signature=/path/to/sigs {rest of arguments} | |||
``` | |||
The gbuild invocations below <b>DO NOT DO THIS</b> by default. | |||
###Build (and optionally verify) Bitcoin Core for Linux, Windows, and OS X: | |||
./bin/gbuild --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml | |||
./bin/gsign --signer $SIGNER --release ${VERSION}-linux --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml | |||
./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-linux ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml | |||
@@ -108,8 +108,8 @@ The gbuild invocations below <b>DO NOT DO THIS</b> by default. | |||
1. source tarball (bitcoin-${VERSION}.tar.gz) | |||
2. linux 32-bit and 64-bit dist tarballs (bitcoin-${VERSION}-linux[32|64].tar.gz) | |||
3. windows 32-bit and 64-bit unsigned installers and dist zips (bitcoin-${VERSION}-win[32|64]-setup-unsigned.exe, bitcoin-${VERSION}-win[32|64].zip) | |||
4. OSX unsigned installer and dist tarball (bitcoin-${VERSION}-osx-unsigned.dmg, bitcoin-${VERSION}-osx64.tar.gz) | |||
5. Gitian signatures (in gitian.sigs/${VERSION}-<linux|{win,osx}-unsigned>/(your gitian key)/ | |||
4. OS X unsigned installer and dist tarball (bitcoin-${VERSION}-osx-unsigned.dmg, bitcoin-${VERSION}-osx64.tar.gz) | |||
5. Gitian signatures (in gitian.sigs/${VERSION}-<linux|{win,osx}-unsigned>/(your Gitian key)/ | |||
###Next steps: | |||
@@ -123,12 +123,12 @@ Commit your signature to gitian.sigs: | |||
git push # Assuming you can push to the gitian.sigs tree | |||
popd | |||
Wait for Windows/OSX detached signatures: | |||
Wait for Windows/OS X detached signatures: | |||
Once the Windows/OSX builds each have 3 matching signatures, they will be signed with their respective release keys. | |||
Once the Windows/OS X builds each have 3 matching signatures, they will be signed with their respective release keys. | |||
Detached signatures will then be committed to the [bitcoin-detached-sigs](https://github.com/bitcoin/bitcoin-detached-sigs) repository, which can be combined with the unsigned apps to create signed binaries. | |||
Create (and optionally verify) the signed OSX binary: | |||
Create (and optionally verify) the signed OS X binary: | |||
pushd ./gitian-builder | |||
./bin/gbuild -i --commit signature=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-osx-signer.yml | |||
@@ -147,7 +147,7 @@ Commit your signature to gitian.sigs: | |||
mv build/out/bitcoin-*win32-setup.exe ../bitcoin-${VERSION}-win32-setup.exe | |||
popd | |||
Commit your signature for the signed OSX/Windows binaries: | |||
Commit your signature for the signed OS X/Windows binaries: | |||
pushd gitian.sigs | |||
git add ${VERSION}-osx-signed/${SIGNER} |
@@ -15,15 +15,15 @@ outgoing connections be anonymized, but more is possible. | |||
-proxy=ip:port Set the proxy server. If SOCKS5 is selected (default), this proxy | |||
server will be used to try to reach .onion addresses as well. | |||
-onion=ip:port Set the proxy server to use for tor hidden services. You do not | |||
need to set this if it's the same as -proxy. You can use -noonion | |||
to explicitly disable access to hidden service. | |||
-listen When using -proxy, listening is disabled by default. If you want | |||
to run a hidden service (see next section), you'll need to enable | |||
it explicitly. | |||
-connect=X When behind a Tor proxy, you can specify .onion addresses instead | |||
-addnode=X of IP addresses or hostnames in these parameters. It requires | |||
-seednode=X SOCKS5. In Tor mode, such addresses can also be exchanged with | |||
@@ -55,10 +55,10 @@ your bitcoind's P2P listen port (8333 by default). | |||
preference for your node to advertize itself with, for connections | |||
coming from unroutable addresses (such as 127.0.0.1, where the | |||
Tor proxy typically runs). | |||
-listen You'll need to enable listening for incoming connections, as this | |||
is off by default behind a proxy. | |||
-discover When -externalip is specified, no attempt is made to discover local | |||
IPv4 or IPv6 addresses. If you want to run a dual stack, reachable | |||
from both Tor and IPv4 (or IPv6), you'll need to either pass your | |||
@@ -87,4 +87,3 @@ If you only want to use Tor to reach onion addresses, but not use it as a proxy | |||
for normal IPv4/IPv6 communication, use: | |||
./bitcoin -onion=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -discover | |||
@@ -1,7 +1,7 @@ | |||
Translations | |||
============ | |||
The Bitcoin-Core project has been designed to support multiple localisations. This makes adding new phrases, and completely new languages easily achievable. For managing all application translations, Bitcoin-Core makes use of the Transifex online translation management tool. | |||
The Bitcoin-Core project has been designed to support multiple localisations. This makes adding new phrases, and completely new languages easily achievable. For managing all application translations, Bitcoin-Core makes use of the Transifex online translation management tool. | |||
### Helping to translate (using Transifex) | |||
Transifex is setup to monitor the Github repo for updates, and when code containing new translations is found, Transifex will process any changes. It may take several hours after a pull-request has been merged, to appear in the Transifex web interface. |
@@ -1,7 +1,7 @@ | |||
Translation Strings Policy | |||
=========================== | |||
This document provides guidelines for internationalization of the Bitcoin Core software. | |||
This document provides guidelines for internationalization of the Bitcoin Core software. | |||
How to translate? | |||
------------------ | |||
@@ -107,4 +107,3 @@ The second example reduces the number of pluralized words that translators have | |||
During a string freeze (often before a major release), no translation strings are to be added, modified or removed. | |||
This can be checked by executing `make translate` in the `src` directory, then verifying that `bitcoin_en.ts` remains unchanged. | |||
@@ -2,7 +2,7 @@ | |||
[ZeroMQ](http://zeromq.org/) is a lightweight wrapper around TCP | |||
connections, inter-process communication, and shared-memory, | |||
providing various message-oriented semantics such as publish/subcribe, | |||
providing various message-oriented semantics such as publish/subscribe, | |||
request/reply, and push/pull. | |||
The Bitcoin Core daemon can be configured to act as a trusted "border |