Fedora image building by build-release.sh currently throws error ` git: command not found`.
Fixed it by adding git in the Dockerfile and loading the image in the script.
Changelog-None.
We have installation instructions that tell the user to use `poetry`
and then we ourselves think we're clever and install only a known
subset? It was only a matter of time until we broke this.
Changelog-None
Removed `bin-` while copying Fedora sums from release captain's file. Sums are saved as `clightning-$VERSION-Fedora-28-amd64.tar.gz` not as `clightning-$VERSION-bin-Fedora-28-amd64.tar.gz`
Changelog-None.
The former seemed to replace the wrong line with the copied checksum.
We now add read it from the first line and add it on top of our sums.
This expression also seems a fair bit easier to understand now.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Removing the Fedora fake as it seems to be not necessary. We later copy
the checksum from the release captains checksums anyway.
Also adding the sum check as it gives more details about which file did
not match if so.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This ensures that we have the release captains checksum file where we
expect it to be and gives a little hint where to get it if needed.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Updated build release for:
- force-version and force-mtime checks
- zipfile is not optional anymore, it will be created before all other action
- CLN's amd64, arm32v7 and arm64v8 docker setup
- Verify release feature
Changelog-EXPERIMENTAL: Build: all experimental features are now runtime-enabled; no more ./configure --enable-experimental-features
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Updates from output of latest version of shellcheck as per SC2268
“Avoid x-prefix in comparisons as it no longer serves a purpose”
https://www.shellcheck.net/wiki/SC2268
Sometimes it's v0.9.3 and sometimes it's 0.9.3, and I always get it
wrong. This is painful when you have to create a signed tag after
committing to one of the two only to find out you chose wrong and have
to redo the tagging.
There's a race condition with loading the submodules that's causes a
build failure on my machine, since the libwally 'includes' aren't on
disk yet when the gcc build step starts.
1. These days we delete the [Unreleased] tag during rcs.
2. Make sure we test the release build process during rc1, since I
screwed that up last release.
3. Add a section on rc2, etc.
4. Do final release via a github PR, since I screwed that up on the
prior release.
5. Update `tools/build-release.sh` and instructions to show that we now
make a reproducible build for Ubuntu 18.04 x86-64.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We were tarring up the build dir, not the destination dir! We did this
for 0.6.3 and nobody noticed :(
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And fix trivial typo in MAKING-RELEASES.md, and date retreival in
build-release.sh and repro-build.sh (real git tags start with v!)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I tried building zipfile on a fresh clone inside KVM, and got
1. Different times inside the zipfile, since zip seems to save *local* times.
2. A different zipfile order, since zip seems to use filesystem order.
Fix both of these. I don't know if LANG=C is necessary for git
ls-files, but it can't hurt.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
