The sense of the test was accidentally inverted in my change to #4733.
The message should be shown if any of the files exist but have an incorrect checksum.
We also now correctly handle the case where there are no package source files.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
While initially fetching packages, I saw `sh: test:` error messages in the make output for only two packages.
However, it appears all packages are correctly fetched.
I tested this patch manually by running these three tests against the `v4.0.0` tag and then with this patch.
In all 6 cases I visually inspected the output.
1. Starting with a pre-downloaded source cash, run the `download` target.
2. Remove an archive from a multi-archive package, then rerun `download`.
3. Alter a hash to cause a hash mismatch condition, then rerun `download`.
I believe after each step both with and without this patch the resulting source cache should be identical
(except for filesystem timestamps).
Co-authored-by: Nathan Wilcox <nathan@electriccoin.co>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
By using the old HOST with -unknown, `make -C depends download` was
interpreting the download-linux step as a cross-compile, and attempting
to download a Rust stdlib for Linux that we weren't pinning (because we
don't support cross-compiling to x86_64 Linux - just build it native).
Follow-up to https://github.com/zcash/zcash/pull/4749.
During Gitian builds, SOURCES_PATH is set to a path within the Gitian
cache. Normally this path is created as part of creating a particular
dependency's source directory, but in some situations we may vendor Rust
crates before this folder exists.
When we first integrated Rust into our build system, we had two
limitations:
- We were building the `librustzcash` FFI library as a dependency, and
therefore needed access to its crate dependencies in the depends
system.
- Gitian builds happen offline, so we needed to fetch any crate
dependencies ahead of time, and then configure cargo to use these in
an offline environment.
At the time, `cargo` already had support for "Source Replacement", but
there was no easy way to package the dependencies in the necessary way.
What we implemented was effectively the `cargo-vendor` tool, built using
Makefiles. A noticeable downside was that we were pinning dependencies
twice: once in the `Cargo.lock` for the FFI library, and again in our
depends system.
Since then, `cargo-vendor` has been upstreamed into `cargo` itself, and
we have moved `librustzcash` into this repository. We can therefore use
`cargo vendor` directly from our pinned Rust compiler to fetch the
dependencies, and rely on our local `Cargo.lock` to pin the specific
crates we are relying on.
All the text from a make action is passed as arguments to a single
execve call, and it can't be longer than the maximum size allowed by the
operating system. We now have enough Rust crates vendored by the depends
system that we are hitting this limit here.
The --enable-online-rust configure flag replicates the behaviour of the
LIBRUSTZCASH_OVERRIDE environment variable (enabling the build system to
use crates.io instead of vendored dependencies).
In some cases (Travis), sources and build caches may be moved around in-between
builds, and we can't necessarily trust that everything is still intact.
This introduces pre-build checks that verify against stashed checksums.
Note that this will cause all sources to be re-downloaded, since cached sources
weren't trustworthy before this.
Since the last commit will force rebuilds of all depends, take the opportunity
to clean up a few other things that would trigger rebuilds as well.
- Move source stamps to the sources dir so that SOURCES_PATH is respected for
"make download".
- Only print "fetching..." when actually downloading a file.
- Avoid using non-deterministic paths for the recipe hash (patch location).
This should ensure that all builders get the same resulting build-ids.
- Use a per-package source paths. This will allow for removing old source files
in the future.
- Use a host-agnostic path for downloads which gets cleaned up properly.
We're not ready to switch to a static qt5 for Linux yet due to missing plugin
support. This adds a recipe for building a shared qt4 that we build and link
against, but don't distribute.
make USE_LINUX_STATIC_QT5=1 can be used to build static qt5 as before.