achow101
commented at 8:26 PM on October 8, 2025:
member
The server hosting the fallbacks uses make download so the files are only available with their overridden names rather than the original name on the upstream source. We should therefore also use the overridden name when downloading from the fallback.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
<!--5faf32d7da4f0f540f40219e4f7537a3-->
theuni approved
theuni
commented at 8:39 PM on October 8, 2025:
member
utACK671b774d1b58c491b53f2b2f6ee42fb6b65a0e71. I was going to PR the same change.
For more context: Our sources server runs make download and makes those sources available as a backup host.
We can't control upstream filenames, so sometimes we rename them for local storage in depends. For ex "v0.1.tar.gz" may become "libfoo-v0.1.tar.gz".
But when we try to fetch "v0.1.tar.gz" from our backup, it doesn't exist, because it's been renamed to "libfoo-v0.1.tar.gz" there.
So instead of requesting the original filename from our backup, request the renamed file. If there's a hash mismatch, that'll be detected later on, so there's no loss of security.
janb84
commented at 12:09 PM on October 9, 2025:
contributor
ut ACK671b774d1b58c491b53f2b2f6ee42fb6b65a0e71
PR changes the third argument of fetch_file_inner() in the fallback scenario. This change ensures that, in the fallback scenario, the "friendly filename" is used to download the file instead of the "filename."
The file contains only the download logic, and I haven’t been able to verify whether the "friendly filename" is constructed the same way for the upload to the fallback server.
<details><summary>code analysis</summary>
The code is somewhat confusing to read because of double use of $(4). Once as the fourth argument to fetch_file() and once as the fourth arguments to fetch_file_inner(). Where in the fallback scenario the fourth argument of fetch_file() is used as both the 3rd and 4th argument of fetch_file_inner()
The 4th argument of fetch_file() is $($(1)_file_name) (line129) which is the "friendly filename name"
But we can conclude that in the fallback scenario the "friendly file name" is also used to download from the fallback server.
</details>
maflcko added the label DrahtBot Guix build requested on Oct 10, 2025
luke-jr referenced this in commit d25f97ac37 on Oct 10, 2025
DrahtBot
commented at 4:37 AM on October 11, 2025:
contributor
<!--9cd9c72976c961c55c7acef8f6ba82cd-->
Guix builds (on x86_64) [untrusted test-only build, possibly unsafe, not for production use]
$ gmake -C depends clean-all
$ gmake -C depends capnp_fetched
gmake: Entering directory '/home/hebasto/dev/bitcoin/depends'
Fetching capnproto-c++-1.2.0.tar.gz from https://capnproto.org.FAIL/
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: capnproto.org.FAIL
Warning: Problem : timeout. Will retry in 1 seconds. 3 retries left.
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: capnproto.org.FAIL
Warning: Problem : timeout. Will retry in 2 seconds. 2 retries left.
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: capnproto.org.FAIL
Warning: Problem : timeout. Will retry in 4 seconds. 1 retries left.
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: capnproto.org.FAIL
Fetching capnproto-c++-1.2.0.tar.gz from https://bitcoincore.org/depends-sources
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404
gmake: *** [funcs.mk:343: /home/hebasto/dev/bitcoin/depends/sources/download-stamps/.stamp_fetched-capnp-capnproto-cxx-1.2.0.tar.gz.hash] Error 22
gmake: Leaving directory '/home/hebasto/dev/bitcoin/depends'
This PR:
$ gmake -C depends clean-all
$ gmake -C depends capnp_fetched
gmake: Entering directory '/home/hebasto/dev/bitcoin/depends'
Fetching capnproto-c++-1.2.0.tar.gz from https://capnproto.org.FAIL/
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: capnproto.org.FAIL
Warning: Problem : timeout. Will retry in 1 seconds. 3 retries left.
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: capnproto.org.FAIL
Warning: Problem : timeout. Will retry in 2 seconds. 2 retries left.
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: capnproto.org.FAIL
Warning: Problem : timeout. Will retry in 4 seconds. 1 retries left.
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: capnproto.org.FAIL
Fetching capnproto-cxx-1.2.0.tar.gz from https://bitcoincore.org/depends-sources
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1727k 100 1727k 0 0 739k 0 0:00:02 0:00:02 --:--:-- 739k
/home/hebasto/dev/bitcoin/depends/work/download/capnp-1.2.0/capnproto-cxx-1.2.0.tar.gz.temp: OK
gmake: Leaving directory '/home/hebasto/dev/bitcoin/depends'
hebasto merged this on Oct 13, 2025
hebasto closed this on Oct 13, 2025
fanquake referenced this in commit 0b80204a37 on Oct 13, 2025
fanquake
commented at 3:00 PM on October 13, 2025:
member
This is a metadata mirror of the GitHub repository
bitcoin/bitcoin.
This site is not affiliated with GitHub.
Content is generated from a GitHub metadata backup.
generated: 2026-10-21 19:52 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me