🚀 fanquake merged a pull request: "doc: rpc: fix case typo in `finalizepsbt` help (final_scriptwitness)"
(https://github.com/bitcoin/bitcoin/pull/33484)
(https://github.com/bitcoin/bitcoin/pull/33484)
📝 fanquake opened a pull request: "ci: use latest versions of lint deps"
(https://github.com/bitcoin/bitcoin/pull/33487)
Some of the versions used here are > 2 years old. i.e `mypy`. Use the latest avilable versions, except for LIEF, which is generally changed with Guix.
Side note. I can't remember the last time one of these tools (mypy, ruff, vulture) actually caught an issue in the lint job.
(https://github.com/bitcoin/bitcoin/pull/33487)
Some of the versions used here are > 2 years old. i.e `mypy`. Use the latest avilable versions, except for LIEF, which is generally changed with Guix.
Side note. I can't remember the last time one of these tools (mypy, ruff, vulture) actually caught an issue in the lint job.
💬 fanquake commented on pull request "doc: rpc: fix case typo in `finalizepsbt` help (final_scriptwitness)":
(https://github.com/bitcoin/bitcoin/pull/33484#issuecomment-3344323996)
Backported to 30.x in #33473.
(https://github.com/bitcoin/bitcoin/pull/33484#issuecomment-3344323996)
Backported to 30.x in #33473.
📝 fanquake converted_to_draft a pull request: "cmake: exclude secp256k1 from all"
(https://github.com/bitcoin/bitcoin/pull/33390)
Instead of setting the EXCLUDE_FROM_ALL target property, pass EXCLUDE_FROM_ALL to `add_subdirectory()`.
This has the following advanteges:
* It is shorter (obviously).
* Target properties are set only in the `CMakeLists.txt` file that defines the target.
* Install rules defined in the subdirectory are excluded as well. This is what we want, because secp256k1 is linked statically.
(https://github.com/bitcoin/bitcoin/pull/33390)
Instead of setting the EXCLUDE_FROM_ALL target property, pass EXCLUDE_FROM_ALL to `add_subdirectory()`.
This has the following advanteges:
* It is shorter (obviously).
* Target properties are set only in the `CMakeLists.txt` file that defines the target.
* Install rules defined in the subdirectory are excluded as well. This is what we want, because secp256k1 is linked statically.
💬 winterrdog commented on pull request "Avoid file overwriting in fallback `AllocateFileRange` implementation":
(https://github.com/bitcoin/bitcoin/pull/33164#discussion_r2386399909)
@cedwies @luke-jr
since this part of the code's gonna be run on POSIX systems only, i think trying out the `lseek()` system call can be of help. it is reliable on large files, sparse file aware and portable across Unix systems since it is a POSIX-standard syscall.
what do you think of this?
(https://github.com/bitcoin/bitcoin/pull/33164#discussion_r2386399909)
@cedwies @luke-jr
since this part of the code's gonna be run on POSIX systems only, i think trying out the `lseek()` system call can be of help. it is reliable on large files, sparse file aware and portable across Unix systems since it is a POSIX-standard syscall.
what do you think of this?
⚠️ ajtowns opened an issue: "[29.x] guix build failure on ppc with xcb"
(https://github.com/bitcoin/bitcoin/issues/33488)
Doing a guix build on the 29.x branch (both with v29.1, v29.2rc1 and f6d49d0a0995ad736c3462bb5cd9d2177d77c970) fails for me on powerpc (and powerpcle) seemingly related to xcb. Previous failures have just given me an error abort after some xcb install commands without indicating what failed, the latest failure gave this error:
```
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating xkbcommon.
...
(https://github.com/bitcoin/bitcoin/issues/33488)
Doing a guix build on the 29.x branch (both with v29.1, v29.2rc1 and f6d49d0a0995ad736c3462bb5cd9d2177d77c970) fails for me on powerpc (and powerpcle) seemingly related to xcb. Previous failures have just given me an error abort after some xcb install commands without indicating what failed, the latest failure gave this error:
```
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating xkbcommon.
...
💬 feroz333GP commented on pull request "Implement BIP 370 PSBTv2":
(https://github.com/bitcoin/bitcoin/pull/21283#issuecomment-3344438252)
Help me write a code from my bitget app account to my valer account so I can withdraw with my local bank account
(https://github.com/bitcoin/bitcoin/pull/21283#issuecomment-3344438252)
Help me write a code from my bitget app account to my valer account so I can withdraw with my local bank account
💬 gomagic2100 commented on issue "`bitcoin-node` is unkillable after mining IPC connection is established":
(https://github.com/bitcoin/bitcoin/issues/33463#issuecomment-3344544160)
👍
(https://github.com/bitcoin/bitcoin/issues/33463#issuecomment-3344544160)
👍
💬 ajtowns commented on pull request "rpc: Fix dumptxoutset rollback with competing forks":
(https://github.com/bitcoin/bitcoin/pull/33444#issuecomment-3344697419)
> dumptxoutset rollback fails when competing forks are present at the target height, even though it should work on the active chain regardless of forks.
Couldn't this just be a contrib script or client-side bitcoin-cli feature? ie:
```
$ bitcoin-cli -invalidateto=00000000000000000001f3222fa4ad883d2d211443a77ecdec05604f4e253a02
```
which first looks up that block hash's height N, then iterates through each chain tip whose height is at least N, getting that tip's ancestor at height N+1
...
(https://github.com/bitcoin/bitcoin/pull/33444#issuecomment-3344697419)
> dumptxoutset rollback fails when competing forks are present at the target height, even though it should work on the active chain regardless of forks.
Couldn't this just be a contrib script or client-side bitcoin-cli feature? ie:
```
$ bitcoin-cli -invalidateto=00000000000000000001f3222fa4ad883d2d211443a77ecdec05604f4e253a02
```
which first looks up that block hash's height N, then iterates through each chain tip whose height is at least N, getting that tip's ancestor at height N+1
...
💬 ajtowns commented on pull request "Rollback for dumptxoutset without invalidating blocks":
(https://github.com/bitcoin/bitcoin/pull/33477#issuecomment-3344719601)
Nice!
> performance is slower (master took 3m 17s vs 9m 16s in my last test with the code here,
That probably makes sense. It might be possible to do it faster and with less disk usage for relatively short rollbacks via a two step process:
* create a read-only snapshot of the db
* create an empty "coins-delta" db
* iterate through the rev data to rollback, update the coins-delta db:
* when you rollback past a coin's creation:
* if the coin was in the snapshot db, add "[
...
(https://github.com/bitcoin/bitcoin/pull/33477#issuecomment-3344719601)
Nice!
> performance is slower (master took 3m 17s vs 9m 16s in my last test with the code here,
That probably makes sense. It might be possible to do it faster and with less disk usage for relatively short rollbacks via a two step process:
* create a read-only snapshot of the db
* create an empty "coins-delta" db
* iterate through the rev data to rollback, update the coins-delta db:
* when you rollback past a coin's creation:
* if the coin was in the snapshot db, add "[
...
📝 maflcko opened a pull request: "ci: Drop support for EOL macOS 13"
(https://github.com/bitcoin/bitcoin/pull/33489)
Now that macOS 13 is EOL (https://en.wikipedia.org/wiki/MacOS_Ventura), it seems odd to still support it.
No breaking changes are expected, and this patch will only be released in version 31.x, another 6 months out from now.
So:
* Update the release note template to drop EOL macOS 13.
* As a result, update the earliest Xcode to version 16 in CI.
* Also, bump the macOS CI runner to version 15, to avoid issues when version 14 will be at its EOL in about 1 year.
This does not affect c
...
(https://github.com/bitcoin/bitcoin/pull/33489)
Now that macOS 13 is EOL (https://en.wikipedia.org/wiki/MacOS_Ventura), it seems odd to still support it.
No breaking changes are expected, and this patch will only be released in version 31.x, another 6 months out from now.
So:
* Update the release note template to drop EOL macOS 13.
* As a result, update the earliest Xcode to version 16 in CI.
* Also, bump the macOS CI runner to version 15, to avoid issues when version 14 will be at its EOL in about 1 year.
This does not affect c
...
💬 maflcko commented on pull request "ci: add libcpp hardening flags to macOS fuzz job":
(https://github.com/bitcoin/bitcoin/pull/33462#discussion_r2386747883)
Done in https://github.com/bitcoin/bitcoin/pull/33489
(https://github.com/bitcoin/bitcoin/pull/33462#discussion_r2386747883)
Done in https://github.com/bitcoin/bitcoin/pull/33489
💬 maflcko commented on issue "[29.x] guix build failure on ppc with xcb":
(https://github.com/bitcoin/bitcoin/issues/33488#issuecomment-3345065399)
> Previous failures have just given me an error abort after some xcb install commands without indicating what failed, the latest failure gave this error:
So the failure is non-deterministic? Does it happen with a fully clean git repo?
(https://github.com/bitcoin/bitcoin/issues/33488#issuecomment-3345065399)
> Previous failures have just given me an error abort after some xcb install commands without indicating what failed, the latest failure gave this error:
So the failure is non-deterministic? Does it happen with a fully clean git repo?
💬 Akadosky1983 commented on issue "[29.x] guix build failure on ppc with xcb":
(https://github.com/bitcoin/bitcoin/issues/33488#issuecomment-3345068019)
👍
(https://github.com/bitcoin/bitcoin/issues/33488#issuecomment-3345068019)
👍
💬 l3tc commented on issue "v30.0 Testing":
(https://github.com/bitcoin/bitcoin/issues/33368#issuecomment-3345094565)
RISC-V 64 / OrangePi RV2 / Ubuntu 24.04
Completed IBD over Tor on 30.0rc1. Passed the [testing guide](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/30.0-Release-Candidate-Testing-Guide) on 30.0rc2. Pre-compiled binaries were used in both cases.
(https://github.com/bitcoin/bitcoin/issues/33368#issuecomment-3345094565)
RISC-V 64 / OrangePi RV2 / Ubuntu 24.04
Completed IBD over Tor on 30.0rc1. Passed the [testing guide](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/30.0-Release-Candidate-Testing-Guide) on 30.0rc2. Pre-compiled binaries were used in both cases.
💬 maflcko commented on pull request "ci: check if file or directory already exists for ${HOME}/.bitcoin instead of failing":
(https://github.com/bitcoin/bitcoin/pull/33486#issuecomment-3345157086)
I don't think it is supported or even encouraged to run this internal CI script on an outside machine. Also, I fail to see how this could even work, as you did not include any steps how to reproduce.
(https://github.com/bitcoin/bitcoin/pull/33486#issuecomment-3345157086)
I don't think it is supported or even encouraged to run this internal CI script on an outside machine. Also, I fail to see how this could even work, as you did not include any steps how to reproduce.
⚠️ maflcko reopened an issue: "ci: GHA fallback centos task runs out of space"
(https://github.com/bitcoin/bitcoin/issues/33293)
https://github.com/bitcoin-core/gui/actions/runs/17433074590/job/49495964258?pr=884#step:8:3785
```
...
+ eval 'TEST_RUNNER_EXTRA=()'
++ TEST_RUNNER_EXTRA=()
+ LD_LIBRARY_PATH=/home/runner/work/_temp/depends/x86_64-pc-linux-gnu/lib
+ /home/runner/work/_temp/build/test/functional/test_runner.py --ci -j4 --tmpdirprefix /home/runner/work/_temp/ci/scratch/test_runner/ --ansi --combinedlogslen=99999999 --timeout-factor=40 --quiet --failfast
WARNING! There may be insufficient free space in /home/runn
...
(https://github.com/bitcoin/bitcoin/issues/33293)
https://github.com/bitcoin-core/gui/actions/runs/17433074590/job/49495964258?pr=884#step:8:3785
```
...
+ eval 'TEST_RUNNER_EXTRA=()'
++ TEST_RUNNER_EXTRA=()
+ LD_LIBRARY_PATH=/home/runner/work/_temp/depends/x86_64-pc-linux-gnu/lib
+ /home/runner/work/_temp/build/test/functional/test_runner.py --ci -j4 --tmpdirprefix /home/runner/work/_temp/ci/scratch/test_runner/ --ansi --combinedlogslen=99999999 --timeout-factor=40 --quiet --failfast
WARNING! There may be insufficient free space in /home/runn
...
💬 maflcko commented on issue "ci: GHA fallback centos task runs out of space":
(https://github.com/bitcoin/bitcoin/issues/33293#issuecomment-3345162077)
Still happening: https://github.com/bitcoin-core/gui/actions/runs/18064088639
(https://github.com/bitcoin/bitcoin/issues/33293#issuecomment-3345162077)
Still happening: https://github.com/bitcoin-core/gui/actions/runs/18064088639
💬 maflcko commented on pull request "ci: Turn CentOS config into Alpine musl config":
(https://github.com/bitcoin/bitcoin/pull/33480#issuecomment-3345164318)
> It may be worth mentioning that this change fixed an issue (I was unable to isolate) on CentOS using HexStr() formatting a custom signetchallenge to display in the rpcconsole.
That is unrelated to both this pull request and your pull request, see https://github.com/bitcoin/bitcoin/issues/33293.
(https://github.com/bitcoin/bitcoin/pull/33480#issuecomment-3345164318)
> It may be worth mentioning that this change fixed an issue (I was unable to isolate) on CentOS using HexStr() formatting a custom signetchallenge to display in the rpcconsole.
That is unrelated to both this pull request and your pull request, see https://github.com/bitcoin/bitcoin/issues/33293.
💬 ajtowns commented on issue "[29.x] guix build failure on ppc with xcb":
(https://github.com/bitcoin/bitcoin/issues/33488#issuecomment-3345200636)
> > Previous failures have just given me an error abort after some xcb install commands without indicating what failed, the latest failure gave this error:
>
> So the failure is non-deterministic? Does it happen with a fully clean git repo?
It's part of the "depends" setup, which caches the downloaded source and build between runs afaics? I think that's the source of the differences in error. I tried it from a cleaned out checkout before, but will try again to see the exact error.
(https://github.com/bitcoin/bitcoin/issues/33488#issuecomment-3345200636)
> > Previous failures have just given me an error abort after some xcb install commands without indicating what failed, the latest failure gave this error:
>
> So the failure is non-deterministic? Does it happen with a fully clean git repo?
It's part of the "depends" setup, which caches the downloaded source and build between runs afaics? I think that's the source of the differences in error. I tried it from a cleaned out checkout before, but will try again to see the exact error.