guix: Don't include directory name in SHA256SUMS

achow101 commented at 8:25 pm on August 6, 2021: member

The SHA256SUMS file can be used in a sha256sum -c command to verify downloaded binaries. However users are likely to download just a single file and not place this file in the correct directory relative to the SHA256SUMS file for the simple verification command to work. By not including the directory name in the SHA256SUMS file, it will be easier for users to verify downloaded binaries.

achow101 force-pushed on Aug 6, 2021

DrahtBot added the label Scripts and tools on Aug 6, 2021

achow101 force-pushed on Aug 6, 2021

ghost commented at 6:52 am on August 7, 2021: none

Why don’t you mention this PR in #22634 (comment) ?

I have now rewritten my download&verfiy bash script already. It’s true that I e.g. do not download into a subfolder “x86_64-linux-gnu”, so as you said, I experienced that sha256sum -c –ignore-missing does not work.

My workaround was just to do grep <Tarballname> SHA256SUMS and then sha256sum <Tarballname> to be able to do manual visual comparison of the two output hashes (which I did also with the previous SHA256SUM format file, which contained the signature itself).

I am not sure if this is good or bad, on one hand I like it that the SHA256SUMS file mirrors the download directory structure, that is clean and I think it would not be feasible to have an SHA256SUMS file in every arch sub dir, because that would require also a signature file for each of them. On the other hand, I agree, that normally one does not download in an arch sub dir. But the latter could be done easily I think, though.

hebasto commented at 7:03 am on August 7, 2021: member

Concept ACK. Arch is included in the output filenames, therefore, no name clash could be expected.

in contrib/guix/libexec/build.sh:461 in 2dabd97f95 outdated

451@@ -452,11 +452,7 @@ mv --no-target-directory "$OUTDIR" "$ACTUAL_OUTDIR" \
452 
453 (
454     cd /outdir-base
455-    {
456-        echo "$GIT_ARCHIVE"
457-        find "$ACTUAL_OUTDIR" -type f
458-    } | xargs realpath --relative-base="$PWD" \
459-      | xargs sha256sum \
460+    find "$GIT_ARCHIVE" "$ACTUAL_OUTDIR" -type f -execdir bash -c 'basename "$1" | xargs sha256sum' _ {} \; \

hebasto commented at 7:18 am on August 7, 2021:

How does the _ variable work here?

The Bash doc did not help much.

unknown commented at 7:36 am on August 7, 2021:

LOL I just tried for 30 min to figure out :) I am not bad in Bash, but this I just can not understand.

Zero-1729 commented at 7:47 am on August 7, 2021:

AFAIK, post shell startup, _ stores the last argument of the last executed command. E.g. it stores -G after the ls -G command is executed, ~/Downloads if ls -G ~/Downloads was executed, etc.

So in the case above, it should store the pathname /outdir-base, i.e. the argument of the last command executed before this line (cd /outdir-base).

Unless I am missing something here.

unknown commented at 7:53 am on August 7, 2021:

I guess the _ feeds the bash command, so it results in $1 there, but not sure :)

Zero-1729 commented at 8:18 am on August 7, 2021:

I would assume it works something like that, but honestly not sure at this point ¯\_(ツ)_/¯.

achow101 commented at 12:04 pm on August 7, 2021:

Shellcheck told me to do it this way: https://github.com/koalaman/shellcheck/wiki/SC2156

hebasto commented at 12:13 pm on August 7, 2021:

Shellcheck told me to do it this way: https://github.com/koalaman/shellcheck/wiki/SC2156

TIL, thanks!

unknown commented at 7:41 pm on August 7, 2021:

This is really Bash voodoo, I wonder how many people in the world understand this. Please add a comment, e.g. “The _ is a dummy string that becomes $0 in the bash command. {} becomes $1 in the bash command. Recommended by shellcheck, see https://github.com/koalaman/shellcheck/wiki/SC2156" so more people can understand the code.

Zero-1729 commented at 7:50 pm on August 7, 2021:

ACK on adding that comment (or anything similar). It would save many hours of trying to grok this.

achow101 commented at 6:41 pm on August 8, 2021:

I’ve added a comment.

unknown commented at 3:31 am on August 9, 2021:

I had still the ambition to understand this strange _ “dummy” parameter and to find any documentation about that, but as Hebasto said, Bash manpage does not help on _. After some testing I think I found out now :) Manpage of Bash 5.0.3 for option -c:

If the -c option is present, then commands are read from the first non-option argument command_string. If there are arguments after the command_string, the first argument is assigned to $0 and any remaining arguments are assigned to the positional parameters. The assignment to $0 sets the name of the shell, which is used in warning and error messages.

Unfortunately, I do not understand what the last sentence means, can anybody explain? But the text before the last sentence can be proofed with this example:

0bash -c 'echo $0 $1' param1 param2
1param1 param2

So what we know from Bash scripts, that $0 is the name of the script, is not the case in bash command using -c. In the latter case, $0 is the first parameter, what we know from Bash scripts as $1. So I think the _ is only used to fill $0, so the numbering of parameters using bash command -c is the same as in bash script (first really used parameter $1 and so on). It is not really needed. You can just replace $1 with $0 in the bash command, then you do not need the _ dummy parameter. So you can write shorter and simpler this: find "$GIT_ARCHIVE" "$ACTUAL_OUTDIR" -type f -execdir bash -c 'basename "$0" | xargs sha256sum' {} \; \ Shellcheck is also happy with this. I would suggest this, as it is simpler and shorter and less confusing. There is only need to explain that with -c what one normally knows as $1 becomes $0 there. A comment to explain the parameter numbering shift is needed anyway I think, be it using the _ dummy parameter or not. So one can comment like this:

Unlike in Bash scripts, the first parameter to bash -c <command> is assigned to $0, not $1

I updated the shellcheck wiki page to remove the confusing dummy parameter usage.

Edit: In any case, the name “_” for the first dummy parameter is unluckily chosen, it should better be “dollarzero” or “dummy” or “foobar” or something like that to avoid confusion with bash variable $_ etc.

achow101 commented at 6:02 am on August 9, 2021:

I think it’s generally discouraged to used $0 as an actual parameter. Bash’s parameter expansion (through $* and $@) always starts with 1 because 0 is always the filename. If you consider a general case, people may want to use $* or $@ in their commands, in which case there would be an off by one error if this was not mentioned. We should probably have this discussion in the shellcheck repo rather than here.

I’m going to leave this as is since I’m not confident the using $0 is a good idea.

unknown commented at 6:12 am on August 9, 2021:

OK with dummy parameter then, I think you are right and have put up a good point with $* etc. I only would recommend to not name it “_” but “dollarzero” or something, like I have written, to avoid the confusion seen here.

unknown commented at 6:52 am on August 9, 2021:

Just tested and can confirm:

0bash -c 'echo $*' param1 param2
1param2

unknown commented at 7:01 am on August 9, 2021:

So i think the confusion for non-Bash-Gurus, while technically being correct, can be boiled down to unluckily, because mistakable, dummy parameter name and insufficient documentation of the reasonability to use it. An appropriate update of the shellcheck wiki page would be great.

unknown commented at 3:42 pm on August 9, 2021:

Manpage of Bash 5.0.3 for option -c:

The assignment to $0 sets the name of the shell, which is used in warning and error messages.

I think what they mean is: “$0 in the shell command is used as the name of the shell, which is used in warning and error messages.”

Examples:

 0$ provoke_error
 1bash: provoke_error: command not found
 2# -> "bash" is the name of the shell in the error message
 3
 4$ bash -c 'provoke_error' bash
 5bash: provoke_error: command not found
 6# -> "bash" is the name of the shell in the error message
 7
 8$ bash -c 'provoke_error' mySuperShell
 9mySuperShell: provoke_error: command not found
10# -> "mySuperShell" is the name of the shell in the error message
11
12$ bash -c 'provoke_error' $SHELL
13/bin/bash: provoke_error: command not found
14# -> "/bin/bash" is the name of the shell in the error message,
15#                       which was taken from the command invoking shell's environment variable $SHELL

So this is another reason for not using $0 as data parameter for the shell command. Not good, because the first data parameter is used as shell name in the error message:

0$ bash -c 'provoke_error ; echo $0 $1' a b
1a: provoke_error: command not found
2a b

Better, because shell has it’s own dedicated name:

0$ bash -c 'provoke_error ; echo $1 $2' bash a b
1bash: provoke_error: command not found
2a b

Question remains, what to take as shell name? I guess “_” is beside it’s mistakability also not a good name for the shell in error message.

A possibility would be to set the first shell command parameter to the value of the executed shell, e.g.

0# For Bash:
1$ bash -c 'provoke_error ; echo $1 $2' bash a b
2bash: provoke_error: command not found
3a b
4
5# For Dash:
6$ dash -c 'provoke_error ; echo $1 $2' dash a b
7dash: 1: dash: provoke_error: not found
8a b

unknown commented at 6:45 pm on August 9, 2021:

I have updated https://github.com/koalaman/shellcheck/wiki/SC2156

achow101 commented at 9:12 pm on August 9, 2021:

I’ve changed this to use bash instead of _.

hebasto approved

hebasto commented at 12:14 pm on August 7, 2021: member

ACK 2dabd97f95bec3041b82c21132ce07d76fd1ccca, I have reviewed the code and it looks OK, I agree it can be merged.

Zero-1729 commented at 12:27 pm on August 8, 2021: contributor

ACK 2dabd97

LGTM, although, I would suggest adding the comment proposed here #22654 (review) to make future code review easier.

achow101 force-pushed on Aug 8, 2021

in contrib/guix/libexec/build.sh:456 in 390954af00 outdated

456-        echo "$GIT_ARCHIVE"
457-        find "$ACTUAL_OUTDIR" -type f
458-    } | xargs realpath --relative-base="$PWD" \
459-      | xargs sha256sum \
460+    # Get all of the generated output files and hash them without directory names.
461+    # Because "find" prints filenames with a preceeding "./", we need to pass the filenames into "basename" first.

hebasto commented at 7:07 pm on August 8, 2021:

390954af00f63d69009e1e360d972270fc40e974

typo: preceeding ==> preceding

achow101 commented at 7:08 pm on August 8, 2021:

Fixed

achow101 force-pushed on Aug 8, 2021

hebasto approved

hebasto commented at 7:09 pm on August 8, 2021: member

re-ACK 568ef8db0d4cda451b2d324fefad3b854d5ad7b5, only a comment added since my previous review.

Zero-1729 approved

Zero-1729 commented at 7:49 pm on August 8, 2021: contributor

re-ACK 568ef8db0d4cda451b2d324fefad3b854d5ad7b5

Nice comment addition.

unknown changes_requested

unknown commented at 3:09 am on August 9, 2021: none

Please see my comment

Sorry that this is now in the “Conversation” section, I only tried out if one could some kind of “reopen” the conversation in the “Files changed” tab, which was marked as resolved by Achow, instead of only adding a comment to it. Now I cannot find out how to remove this.

Zero-1729 commented at 3:47 am on August 9, 2021: contributor

Great find @wodry!

EDIT: Given using $0 as a bash param is discouraged (see here), this change is good to go.

ghost commented at 7:51 am on August 9, 2021: none

Concept ACK. Arch is included in the output filenames, therefore, no name clash could be expected.

Just asking, why arch subfolders at all, if every 22.0rc2 subfolder contains just one file with a unique name which contains the arch, except the folder x86_64-w64-mingw32/ which has two files in it, also without clash?

achow101 force-pushed on Aug 9, 2021

laanwj commented at 9:26 am on August 10, 2021: member

As I understand this makes the uploaded binaries have all files in one directory like previous releases? (e.g. https://bitcoincore.org/bin/bitcoin-core-0.21.1/ instead of https://bitcoincore.org/bin/bitcoin-core-22.0/test.rc2/)

I didn’t think nesting the directory per platform makes anything easier or better, but does add an inconvenient extra click when downloading. So concept ACK.

I have now rewritten my download&verfiy bash script already.

I would suggest holding off doing any large tool rewrites based on process changes until 22.0 final. Things are still being hammered out.

laanwj added this to the milestone 22.0 on Aug 10, 2021

unknown approved

unknown commented at 9:57 am on August 10, 2021: none

Code change ACK, Concept 0

ghost commented at 10:26 am on August 10, 2021: none

As I understand this makes the uploaded binaries have all files in one directory like previous releases?

I am not sure what you are referring to with “this”? This PR leaves the arch sub dir structure as is, only removes the directories from the SHA256SUMS file. Not sure what and why you ACK.

laanwj commented at 1:32 pm on August 10, 2021: member

Not sure what and why you ACK.

Having a single-level SHA256SUMS means that we can put the files in one directory again during upload (anyhow, that users are able to verify that without having to move files around or pre-process SHA256SUMS).

achow101 commented at 5:26 pm on August 10, 2021: member

As I understand this makes the uploaded binaries have all files in one directory like previous releases?

Unless the binary server validates the SHA256SUMS file, I don’t think so. I don’t think it really matters where the binaries are located. Regardless of the directory structure, users are still going to just download one binary file and the SHA256SUMS file into some Downloads directory and verify them when they are at the same level.

achow101 commented at 7:11 pm on August 10, 2021: member

From IRC:

0<dongcarl> The layout of the SHA256SUMS file is designed such that anyone can download any subtree (as torrent download tools allow you to do), then `cd path/to/all/output/basedir; sha256sum --check --ignore-missing` to verify their files. In that sense it needs to represent represent the tree somewhat accurately.

So I guess the directory structure will need to change for the upload. I will add something to doc/release-process.md to reflect this.

achow101 force-pushed on Aug 10, 2021

in contrib/guix/libexec/build.sh:456 in 56c25f5692 outdated

456-        echo "$GIT_ARCHIVE"
457-        find "$ACTUAL_OUTDIR" -type f
458-    } | xargs realpath --relative-base="$PWD" \
459-      | xargs sha256sum \
460+    # Get all of the generated output files and hash them without directory names.
461+    # Because "find" prints filenames with a preceding "./", we need to pass the filenames into "basename" first.

unknown commented at 10:50 am on August 11, 2021:

Generally I think it would be good to leave the preceding ./ path, because it is precise. The verifying works with it on Linux, so the removing is not generally needed. I guess it shall be removed to be compatible with OSs that have other directory naming conventions, e.g. like Microsoft products? I would find a comment helpful, for what reason the ./ is needed to be removed.

achow101 commented at 5:36 pm on August 11, 2021:

Typically SHA256SUMS do not contain paths to the files. Seeing the ./ may be confusing to users who are not familiar with paths.

unknown commented at 7:17 am on August 12, 2021:

BTW here (leading to the doc of md5sum --check invocation) is the doc of SHA256SUMS file: The input to this mode of md5sum is usually the output of a prior, checksum-generating run of ‘md5sum’.

achow101 commented at 8:41 pm on August 12, 2021:

Yes, but many people do a visual comparison.

dongcarl commented at 7:04 pm on August 11, 2021: member

Here’s an alternative to 752235f0eb74be016ca2b986d8def39960a73391, which does the “basenamification” at attest-time (which I think makes a bit more sense):

 0diff --git a/contrib/guix/guix-attest b/contrib/guix/guix-attest
 1index 1503c330b2..2e2ac0b411 100755
 2--- a/contrib/guix/guix-attest
 3+++ b/contrib/guix/guix-attest
 4@@ -159,6 +159,18 @@ Hint: You may wish to remove the existing attestations and their signatures by
 5 EOF
 6 }
 7 
 8+# Give a SHA256SUMS file as stdin that has lines like:
 9+#     0ba536819b221a91d3d42e978be016aac918f40984754d74058aa0c921cd3ea6  a/b/d/c/d/s/bitcoin-22.0rc2-riscv64-linux-gnu.tar.gz
10+#     ...
11+#
12+# Replace each line's file name with its basename:
13+#     0ba536819b221a91d3d42e978be016aac918f40984754d74058aa0c921cd3ea6  bitcoin-22.0rc2-riscv64-linux-gnu.tar.gz
14+#     ...
15+#
16+basenameify_SHA256SUMS() {
17+    sed -E 's@(^[[:xdigit:]]{64}[[:space:]]+).+/([^/]+$)@\1\2@'
18+}
19+
20 echo "Attesting to build outputs for version: '${VERSION}'"
21 echo ""
22 
23@@ -174,6 +186,7 @@ mkdir -p "$outsigdir"
24         cat "${noncodesigned_fragments[@]}" \
25             | sort -u \
26             | sort -k2 \
27+            | basenameify_SHA256SUMS \
28                 > "$temp_noncodesigned"
29         if [ -e noncodesigned.SHA256SUMS ]; then
30             # The SHA256SUMS already exists, make sure it's exactly what we
31@@ -201,6 +214,7 @@ mkdir -p "$outsigdir"
32         cat "${sha256sum_fragments[@]}" \
33             | sort -u \
34             | sort -k2 \
35+            | basenameify_SHA256SUMS \
36                 > "$temp_all"
37         if [ -e all.SHA256SUMS ]; then
38             # The SHA256SUMS already exists, make sure it's exactly what we

fanquake added the label Needs backport (22.x) on Aug 12, 2021

fanquake commented at 0:45 am on August 13, 2021: member

@achow101 can you incorporate Carls suggestion here.

achow101 commented at 0:53 am on August 13, 2021: member

I don’t see the benefit of Carl’s approach over what I have implemented already.

ghost commented at 5:53 am on August 13, 2021: none

In any case it could be good to use the suggested basenameify_SHA256SUMS (or should it be called “basenamify_SHA256SUMS” according to “basenamification”, I am no English expert?), which is quite good readable. That would make it possible to remove rather complex redundant code and it’s comments. Not that important, though.

dongcarl commented at 2:19 pm on August 17, 2021: member

For posterity: some previous thoughts from IRC on why it’s good to keep the output/ dir per-host. And flatten it last-minute: https://gnusha.org/bitcoin-builds/2021-08-12.log

011:50 < dongcarl> I think [#22654](/bitcoin-bitcoin/22654/) will work well. What it achieves is basically: 1. Updates release-notes.md to mention that we need to flatten the output hier when uploading, 2. Makes the resulting SHA256SUMS file have filenames that are `basename`-ified (no `dirname`)
111:50 < gribble> [#22654](/bitcoin-bitcoin/22654/) | guix: Dont include directory name in SHA256SUMS by achow101 · Pull Request [#22654](/bitcoin-bitcoin/22654/) · bitcoin/bitcoin · GitHub
211:53 < dongcarl> I didn't want to touch the output dir hier for guix-build itself because looking at it it might introduce more problems that will slow down rc's and will mess up: 1. Atomicity of the mv OUTDIR ACTUAL_OUTDIR means there are no half-formed outputs 2. In the future we can more granularly bind-mount output dirs into build containers to ensure that one
311:53 < dongcarl> HOST's build is physically unable to tamper with another HOST's output
411:53 < laanwj> i was wondering about the atomicity-per-platform thing
511:54 < laanwj> agree that that makes flattening last minute a better option

achow101 commented at 7:31 pm on August 18, 2021: member

Is it strongly preferred that this use @dongcarl’s solution over the one implemented here?

fanquake commented at 11:48 pm on August 18, 2021: member

Yes I think so.

guix: Don't include directory name in SHA256SUMS

The SHA256SUMS file can be used in a sha256sum -c command to verify
downloaded binaries. However users are likely to download just a single
file and not place this file in the correct directory relative to the
SHA256SUMS file for the simple verification command to work. By not
including the directory name in the SHA256SUMS file, it will be easier
for users to verify downloaded binaries.

Co-authored-by: Carl Dong <contact@carldong.me>

fb17c99e35

achow101 commented at 0:44 am on August 19, 2021: member

Changed to use @dongcarl’s suggestion

achow101 force-pushed on Aug 19, 2021

in doc/release-process.md:210 in 1822d409a0 outdated

206@@ -207,16 +207,25 @@ cat "$VERSION"/*/all.SHA256SUMS.asc > SHA256SUMS.asc
207 
208 
209 - Upload to the bitcoincore.org server (`/var/www/bin/bitcoin-core-${VERSION}`):
210-    1. The contents of `./bitcoin/guix-build-${VERSION}/output`, except for
211+    1. The contents of each `./bitcoin/guix-build-${VERSION}/output/${HOST}` directory, except for

unknown commented at 4:28 am on August 19, 2021:

Nit: I personally like stating directory names with a traling / when possible like here, so code readers can easily recognize that it is a directory, in this case “each ./bitcoin/guix-build-${VERSION}/output/${HOST}/ directory”. In line 226 this is done with /output/

achow101 commented at 8:49 pm on August 19, 2021:

Done

doc: Mention the flat directory structure for uploads

The uploaded binaries need to match the same flat directory structure of
the SHA256SUMS file in order for torrent downloaders to be able to
verify the download without moving files. Mention this in the release
process doc.

132cae44f2

in doc/release-process.md:209 in 1822d409a0 outdated

206@@ -207,16 +207,25 @@ cat "$VERSION"/*/all.SHA256SUMS.asc > SHA256SUMS.asc
207 
208 
209 - Upload to the bitcoincore.org server (`/var/www/bin/bitcoin-core-${VERSION}`):

unknown commented at 4:28 am on August 19, 2021:

Nit: /var/www/bin/bitcoin-core-${VERSION}/

achow101 commented at 8:49 pm on August 19, 2021:

Done

achow101 force-pushed on Aug 19, 2021

Zero-1729 commented at 9:53 pm on August 19, 2021: contributor

re-ACK 132cae44f2d031bdaa1e459b92ec89ad585dfc9f

fanquake commented at 6:37 am on August 20, 2021: member

Guix builds:

 0777a1ad25da672e72356d34638fef917649462307e6a857e0c2f4d78b8d3e363  guix-build-132cae44f2d0/output/aarch64-linux-gnu/SHA256SUMS.part
 15f307edda9d8785a7051bdc89e667500ddd932324f6a0b225d605a921236cdf5  guix-build-132cae44f2d0/output/aarch64-linux-gnu/bitcoin-132cae44f2d0-aarch64-linux-gnu-debug.tar.gz
 299c0fe0aa4952af02384ebd4b84c490351ad462290e4673af5c16d13929d929a  guix-build-132cae44f2d0/output/aarch64-linux-gnu/bitcoin-132cae44f2d0-aarch64-linux-gnu.tar.gz
 3d30698cf2358edd729c9cae72270df510d2d811debbac1fd2619ad5aeed8eab3  guix-build-132cae44f2d0/output/arm-linux-gnueabihf/SHA256SUMS.part
 42a39d1e11e63a1662d644e16d8002ebc778acaac04ac23572666fb57f15f1d07  guix-build-132cae44f2d0/output/arm-linux-gnueabihf/bitcoin-132cae44f2d0-arm-linux-gnueabihf-debug.tar.gz
 5807494da57ef85914988500f3533257c5ae09b9351ad742ab317cb4326a72fed  guix-build-132cae44f2d0/output/arm-linux-gnueabihf/bitcoin-132cae44f2d0-arm-linux-gnueabihf.tar.gz
 631067da3649769233be6ccf8e0aebf0e09af2d70ae649c42011557b111fd0811  guix-build-132cae44f2d0/output/dist-archive/bitcoin-132cae44f2d0.tar.gz
 7a9b3aad4050e69ff5bc792c2057934da227e793a7ccd73514031bd8c4b48623c  guix-build-132cae44f2d0/output/powerpc64-linux-gnu/SHA256SUMS.part
 823a0874ab176e0574351ff60e8a193196b48eb640b0a6f77188d7ceab5f70a3c  guix-build-132cae44f2d0/output/powerpc64-linux-gnu/bitcoin-132cae44f2d0-powerpc64-linux-gnu-debug.tar.gz
 9bd0d1ac1ffe179ba1d60259cdf718b24f72490c95656842bd2df0fc8f44e794d  guix-build-132cae44f2d0/output/powerpc64-linux-gnu/bitcoin-132cae44f2d0-powerpc64-linux-gnu.tar.gz
10ab4d8038e2c1372d2beaaa5c647ba3b30cfe2e0afb38c2174f1264955dacae25  guix-build-132cae44f2d0/output/powerpc64le-linux-gnu/SHA256SUMS.part
1141b493490edf41371fe39d6aaef392bec4f1531e26c746a989729cc1bf54f1a4  guix-build-132cae44f2d0/output/powerpc64le-linux-gnu/bitcoin-132cae44f2d0-powerpc64le-linux-gnu-debug.tar.gz
12e6b79baa7ed8410f3d5cb4b2d21278c06ce9c665fd7ffe19c1eb3d2e1c147d91  guix-build-132cae44f2d0/output/powerpc64le-linux-gnu/bitcoin-132cae44f2d0-powerpc64le-linux-gnu.tar.gz
137e5ab13ac196511d14a5cb88272ce377257f0b117e5b69a9d8f64aaab8aea580  guix-build-132cae44f2d0/output/riscv64-linux-gnu/SHA256SUMS.part
14155146bca7dbe8b499e8ff22395ea71fd770853e075e63293693e6718b1d15b2  guix-build-132cae44f2d0/output/riscv64-linux-gnu/bitcoin-132cae44f2d0-riscv64-linux-gnu-debug.tar.gz
15de943b63789da014f642417800197988350be13bdaec2e6ac4dcd8dea0e26b85  guix-build-132cae44f2d0/output/riscv64-linux-gnu/bitcoin-132cae44f2d0-riscv64-linux-gnu.tar.gz
167c7d8ad3fc2e28071429a7e25d8235cefddc489ec7d8992c54f4db517f09f5a1  guix-build-132cae44f2d0/output/x86_64-apple-darwin18/SHA256SUMS.part
1769767250b6f817cdc424498a60dec00db412c08950eb06d3687814d0442cda02  guix-build-132cae44f2d0/output/x86_64-apple-darwin18/bitcoin-132cae44f2d0-osx-unsigned.dmg
18ea42729a477276ac26982a7a22eee940aff567e367fe151c355b21c3a1b5d714  guix-build-132cae44f2d0/output/x86_64-apple-darwin18/bitcoin-132cae44f2d0-osx-unsigned.tar.gz
19cb6c48623e78065551cf3ff4ce45dc1f48dab6538dc571d055c9e2b58ceb5178  guix-build-132cae44f2d0/output/x86_64-apple-darwin18/bitcoin-132cae44f2d0-osx64.tar.gz
20f49ebd853f247dbbb01ac325f160d37684540e9c6dad9d1be53cc1d1f25b4e13  guix-build-132cae44f2d0/output/x86_64-linux-gnu/SHA256SUMS.part
21a4b55db9e3f5f36a7f856da7ad6aba63dcc70f4b3a1a67b5c45681f5b9e35d90  guix-build-132cae44f2d0/output/x86_64-linux-gnu/bitcoin-132cae44f2d0-x86_64-linux-gnu-debug.tar.gz
22ba6f9ef3e4ce462019a38df151eed104ab9ebe72eb93fb99e7a54a8c3999a7eb  guix-build-132cae44f2d0/output/x86_64-linux-gnu/bitcoin-132cae44f2d0-x86_64-linux-gnu.tar.gz
234dc9d667ceec5cca1c6fddfa1296bd174da1be04cef015eebe067dc302600ca0  guix-build-132cae44f2d0/output/x86_64-w64-mingw32/SHA256SUMS.part
244d0799e48974fd1fd5023f98e488c66b4a90f753b2de6fd7b214c7193256a10d  guix-build-132cae44f2d0/output/x86_64-w64-mingw32/bitcoin-132cae44f2d0-win-unsigned.tar.gz
25a98ca150dd426a66a568cd07038e8c360bbe6b78eecf315bab2b146f42da526c  guix-build-132cae44f2d0/output/x86_64-w64-mingw32/bitcoin-132cae44f2d0-win64-debug.zip
26a7647e742faebfa344df195775b20478a0e42ee19cb671508acc9d96394ec2b9  guix-build-132cae44f2d0/output/x86_64-w64-mingw32/bitcoin-132cae44f2d0-win64-setup-unsigned.exe
27f202165ef8de36ec8a8c503053e6c6e81f1e4c1e1f8cad3abbb68f045a73fb1d  guix-build-132cae44f2d0/output/x86_64-w64-mingw32/bitcoin-132cae44f2d0-win64.zip

fanquake approved

fanquake commented at 7:09 am on August 20, 2021: member

ACK 132cae44f2d031bdaa1e459b92ec89ad585dfc9f

fanquake merged this on Aug 20, 2021

fanquake closed this on Aug 20, 2021

hebasto referenced this in commit b69e85de35 on Aug 20, 2021

hebasto referenced this in commit adaa4f79e5 on Aug 20, 2021

hebasto commented at 7:15 am on August 20, 2021: member

Backported in #22629.

hebasto removed the label Needs backport (22.x) on Aug 20, 2021

hebasto referenced this in commit b3feff97fb on Aug 20, 2021

hebasto referenced this in commit e34d014cce on Aug 20, 2021

hebasto referenced this in commit 27d43e5bd4 on Aug 20, 2021

hebasto referenced this in commit 068985c02e on Aug 20, 2021

sidhujag referenced this in commit 71c6df1c6a on Aug 20, 2021

laanwj referenced this in commit 4a25e39624 on Aug 26, 2021

fujicoin referenced this in commit b227c363b4 on Aug 27, 2021

fujicoin referenced this in commit 93fe254ebb on Aug 27, 2021

gwillen referenced this in commit 8ae27ce6b1 on Jul 27, 2022

gwillen referenced this in commit c61ff0ffae on Jul 27, 2022

gwillen referenced this in commit 0bfa783a00 on Aug 1, 2022

gwillen referenced this in commit a5d5de2f35 on Aug 1, 2022

DrahtBot locked this on Aug 20, 2022

guix: Don’t include directory name in SHA256SUMS #22654