qrencode package source tarball”
#33577
The new URL breaks CI on the current release branches, see #33494 (comment).
The old URL also no longer exists so the tarball is fetched from the depends sources cache that we host, but the original tarball has already been overwritten on there. We will need to manually reinstate the original tarball.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33577.
See the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
This reverts commit 6de80512632afe612a3427463c94ac51f90f5203.
This reverts commit 93a70a42d30fa2f9404b76d5bbdb5ea316fc1032.
Additionally, I think we want to go ahead and change the source and filename in order to disambiguate any builders who are currently in limbo. As suggested on the previous PR, I suggest:
0$(package)_download_path=https://github.com/fukuchi/libqrencode/archive/refs/tags/
1$(package)_download_file=v$($(package)_version).tar.gz
2$(package)_file_name=$(package)-$($(package)_version)-v2.tar.gz
3$(package)_sha256_hash=5385bc1b8c2f20f3b91d258bf8ccc8cf62023935df2d2676b5b67049f31a049c
Additionally, I think we want to go ahead and change the source and filename in order to disambiguate any builders who are currently in limbo.
My understanding is that the revert needs to go in first to allow the CI caches to be fixed for the release branches. Then we can open a followup that does the URL and filename change, and in a way that won’t break release branch CI now that we know it is a problem.
Revert looks good to me.
We will need to manually reinstate the original tarball
Just checking someone has the original tarball? Otherwise I’m assuming this revert will not work.
Could you explain the need for 46135d9 as well? Since its justification was supporting behavior that we really don’t want to be supported, is it necessary now that we’re reverting that behavior?
My understanding wasn’t that is wasn’t needed to support behaviour of checking for differences in file contents but was simply a redundant check as the make target would only run if make didn’t detect the file.
Just checking someone has the original tarball? Otherwise I’m assuming this revert will not work.
Yes. This was done yesterday, but the server auto-updated this morning.
Just checking someone has the original tarball?
Yes. The original has already been uploaded to the server as qrencode-4.1.1-fukuchi.org.tar.gz and it only needs to be renamed to match.
utACK e4335a31920cd390d936cd51cc4478a234db1276
Got a failure with:
0make -C depends clean-all
1make -C depends qrencode
2/bin/sh: command -v llvm-ranlib: No such file or directory
3/bin/sh: command -v llvm-strip: No such file or directory
4/bin/sh: command -v llvm-nm: No such file or directory
5/bin/sh: command -v llvm-objcopy: No such file or directory
6/bin/sh: command -v llvm-objdump: No such file or directory
7/bin/sh: command -v dsymutil: No such file or directory
8Fetching qrencode-4.1.1.tar.gz from https://fukuchi.org/works/qrencode/
9 % Total % Received % Xferd Average Speed Time Time Time Current
10 Dload Upload Total Spent Left Speed
11 0 274 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
12curl: (22) The requested URL returned error: 404
13Fetching qrencode-4.1.1.tar.gz from https://bitcoincore.org/depends-sources
14 % Total % Received % Xferd Average Speed Time Time Time Current
15 Dload Upload Total Spent Left Speed
16100 185k 100 185k 0 0 342k 0 --:--:-- --:--:-- --:--:-- 342k
17/Users/maxedwards/source/bitcoin/depends/work/download/qrencode-4.1.1/qrencode-4.1.1.tar.gz.temp: FAILED
18shasum: WARNING: 1 computed checksum did NOT match
19make: *** [/Users/maxedwards/source/bitcoin/depends/sources/download-stamps/.stamp_fetched-qrencode-qrencode-4.1.1.tar.gz.hash] Error 1
Which I assume will be fixed when qrencode-4.1.1-fukuchi.org.tar.gz is renamed on the depends-sources cache.
Just checking someone has the original tarball?
I have it:
0$ sha256sum sources/qrencode-4.1.1.tar.gz
1da448ed4f52aba6bcb0cd48cac0dd51b8692bccc4cd127431402fca6f8171e8e sources/qrencode-4.1.1.tar.gz
Which I assume will be fixed when
qrencode-4.1.1-fukuchi.org.tar.gzis renamed on the depends-sources cache.
It’s renamed (again)
lgtm. Seems fine to temporarily revert. A new pull can be created to properly try it again some time in the future.
review ACK e4335a31920cd390d936cd51cc4478a234db1276 💤
Signature:
0untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
1RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
2trusted comment: review ACK e4335a31920cd390d936cd51cc4478a234db1276 💤
33Ceqd3S3+DfEA+9apWBuQAAQructCE4T6TaFEjqqpFY3aEjPLIZb4dKr5Ba8lA3x0dPDUW84YtCGWsgW6tyUCg==
