Code signing failed for me on OSX 10.9.5 because the
Versions/Current symbolic links were being replaced
with a duplicate copy of the frameworks' code.
Releases were bigger than they needed to be, for the
same reason.
Rebased-From: 965c306d6d
The approach from 65f3fa8d1 worked for signing on 10.9.4, but not newer
versions. 10.9.5 (and up) want each framework to stand alone.
Now in addition to copying the plist's from Qt for each framework, we put them
in per-version dirs and only symlink to the latest, rather than using symlinks
for any contents.
Rebased-From: af0bd5e
Starting with 10.9, Framework versions must be signed individually, rather
than as a single bundle version, in order to be properly codesigned. This
change ensures that the proper plist files and symlinks are present prior to
packaging.
Rebased-From: 65f3fa8
- Catch problems such as mismatched formatting characters. Remove
messages that can give problems at runtime.
- Also remove unfinished/untranslated messages, they just take up space
in the ts and waste parsing time.
Fixes#4774.
Rebased-From: da59f28
Rebased-By: Wladimir J. van der Laan
Make the instdate for lrelease etc deterministic. This should have been
part of 0.9.2. Luckily this doesn't affect the end product, it is just
a bit annoying.
Rebased-From: 386e732
Rebased-By: Wladimir J. van der Laan <laanwj@gmail.com>
Upgrade for https://www.openssl.org/news/secadv_20140605.txt
Just in case - there is no vulnerability that affects ecdsa signing or
verification.
The MITM attack vulnerability (CVE-2014-0224) may have some effect on
our usage of SSL/TLS.
As long as payment requests are signed (which is the common case), usage
of the payment protocol should also not be affected.
The TLS usage in RPC may be at risk for MITM attacks. If you have
`-rpcssl` enabled, be sure to update OpenSSL as soon as possible.
Rebased-By: Wladimir J. van der Laan <laanwj@gmail.com>
Rebased-From: 6e7c4d1
This fixes the display on Retina Macbooks. It also moves us away from depending
on the ancient XCode3 sdk.
Conflicts:
doc/release-process.md
Rebased-By: Wladimir J. van der Laan <laanwj@gmail.com>
Rebased-From: 2869b13
If the `libqt4-dev` package is installed it picks the moc executable
from the system instead of our custom-built one. This results in
compatibility errors.
This commit convinces configure to pick the right one.
3a54ad9 Full translation update (Wladimir J. van der Laan)
9dd5d79 devtools: add a script to fetch and postprocess translations (Wladimir J. van der Laan)
58c01a3 qt: add transifex configuration file (Wladimir J. van der Laan)
Run this script from the root of the repository to update all translations from transifex.
It will do the following automatically:
- create a transifex configuration file
- fetch all translations
- post-process them into valid and committable format
This avoids conflicts between the libraries statically linked into bitcoin and any
libraries we may link dynamically (such as Qt and OpenSSL, see issue #4094).
It also avoids start-up overhead to not export any unnecessary symbols.
To do this, build a linker script that marks all symbols as local.
Should make it possible to run the resulting GUI executable on
Linux distributions that use Qt 4.6, such as Debian Wheezy and Tails.
Builds a mini-SDK for building against Qt 4.6. This includes the headers
as well as host utilities such as `lrelease`, `qrc` and `moc`.
This speeds up the gitian build a bit - libqt4-dev pulled in a lot of packages,
and is no longer needed as this provides a replacement of our own.
Note: This does not replace the Qt build with at static library. After this
commit we still build dynamically against the system Qt library. The only
difference is that compatibility with an older version is maintained. This
loses minor GUI functionality (such as setPlaceholderText) but still
allows integration into the window management of the host OS, unlike
when statically linking.
Add a script to check that the (Linux) executables produced by gitian
only contain allowed gcc, glibc and libstdc++ version symbols. This
makes sure they are still compatible with the minimum supported Linux
distribution versions.
0f63504 Changed bitrpc.py's raw_input to getpass for passwords to conceal characters during command line input. Getpass is in Python stdlib so no additional dependencies required. (Eric S. Bullington)
Bumps deps-linux, deps-win dependency versions as well.
qt-win does not need to be bumped, as although it depends on deps-win,
Qt doesn't use miniupnp. I verified this by rebuilding the dependency
and checking the the output is the same. Not having to rebuild Qt is a
good thing as it is huge.
For qt5.2 on osx, the qcocoa plugin is mandatory. However, it fails to load
when qt.conf specifies the "plugin" path instead of the expected "Plugin". This
is in line with the documentation:
https://qt-project.org/doc/qt-5.0/qtdoc/qt-conf.html
I'm not sure how the plugins were loading before, unless the case-sensitivity
for OSX is new.
IIRC this was the case with 0.8.6, so let's keep this to avoid the risk
of losing connectable nodes with 0.9 release.
Also our miniupnpc library was recently updated and I've heard
reports that it works better than before now.
While building protobuf in different environments we noticed that
the host tool protoc was slightly different between builds (a symbol table
sorting issue).
Add a deterministic seed as well as disable zlib support.
Exected output is now:
e2e403e1a08869c7eed4d4293bce13d51ec6a63592918b90ae215a0eceb44cb4 protobuf-win32-2.5.0-gitian-r4.zip
a0999037e8b0ef9ade13efd88fee261ba401f5ca910068b7e0cd3262ba667db0 protobuf-win64-2.5.0-gitian-r4.zip
No effect on final executables so no version bump.
Boost iostreams was picking up libz-dev in VirtualBox, as the recommended
way to build is now to make a VM with all dependency packages installed.
This caused a divergence between KVM/LXC build and VirtualBox
build results.
Fix this in the simplest possible way: add the libz-dev package.
