💬 Dorex45 commented on issue "Release Schedule for 30.0":
(https://github.com/bitcoin/bitcoin/issues/32275#issuecomment-3380342538)
Each node can configure it's policy rules as it sees fit and transactions must first pass consensus rules before considering policy. This means that there is no risk that using different policy rules will break consensus. Another way to say this is that standard transactions are a subset of valid transactions.
(https://github.com/bitcoin/bitcoin/issues/32275#issuecomment-3380342538)
Each node can configure it's policy rules as it sees fit and transactions must first pass consensus rules before considering policy. This means that there is no risk that using different policy rules will break consensus. Another way to say this is that standard transactions are a subset of valid transactions.
💬 Dorex45 commented on issue "Release Schedule for 30.0":
(https://github.com/bitcoin/bitcoin/issues/32275#issuecomment-3380347327)
Candidate Release V30 ACK
(https://github.com/bitcoin/bitcoin/issues/32275#issuecomment-3380347327)
Candidate Release V30 ACK
🚀 fanquake merged a pull request: "[27.x] Fix Qt download URLs"
(https://github.com/bitcoin/bitcoin/pull/33564)
(https://github.com/bitcoin/bitcoin/pull/33564)
💬 fanquake commented on pull request "[28.x] ci: Fix Qt 5.15 URL":
(https://github.com/bitcoin/bitcoin/pull/33561#issuecomment-3380416127)
Backported to 27.x in #33564.
(https://github.com/bitcoin/bitcoin/pull/33561#issuecomment-3380416127)
Backported to 27.x in #33564.
💬 fanquake commented on pull request "[29.x] build: fix depends Qt download link":
(https://github.com/bitcoin/bitcoin/pull/33563#issuecomment-3380417586)
Backported to 27.x in #33564.
(https://github.com/bitcoin/bitcoin/pull/33563#issuecomment-3380417586)
Backported to 27.x in #33564.
💬 fanquake commented on issue "Release Schedule for 30.0":
(https://github.com/bitcoin/bitcoin/issues/32275#issuecomment-3380466804)
Binaries for `v30.0rc3` are available: https://bitcoincore.org/bin/bitcoin-core-30.0/test.rc3/.
(https://github.com/bitcoin/bitcoin/issues/32275#issuecomment-3380466804)
Binaries for `v30.0rc3` are available: https://bitcoincore.org/bin/bitcoin-core-30.0/test.rc3/.
💬 willcl-ark commented on issue "build: depends sqlite compile failure for FreeBSD Clang cross":
(https://github.com/bitcoin/bitcoin/issues/33560#issuecomment-3380469053)
Cross-compiling for freebsd from linux using clang is just currently untested/unused.
This branch includes a patch to fix sqlite use of `mremap` and a build script demonstrating a freebsd crosscompile from linux using clang and a freebsd sysroot:
https://github.com/bitcoin/bitcoin/compare/master...willcl-ark:bitcoin:cross-compile-freebsd-depends
(tested with clang18 and freebsd 14.2 and 14.3 only).
If we moved to using clang in the guix builds a similar process could perhaps be used to provi
...
(https://github.com/bitcoin/bitcoin/issues/33560#issuecomment-3380469053)
Cross-compiling for freebsd from linux using clang is just currently untested/unused.
This branch includes a patch to fix sqlite use of `mremap` and a build script demonstrating a freebsd crosscompile from linux using clang and a freebsd sysroot:
https://github.com/bitcoin/bitcoin/compare/master...willcl-ark:bitcoin:cross-compile-freebsd-depends
(tested with clang18 and freebsd 14.2 and 14.3 only).
If we moved to using clang in the guix builds a similar process could perhaps be used to provi
...
💬 fanquake commented on pull request "randomenv: Fix MinGW dllimport warning for `environ`":
(https://github.com/bitcoin/bitcoin/pull/33570#issuecomment-3380545850)
> MinGW also defines environ ... causing the same inconsistent linkage warning.
Can you improve the PR description & commit message? We use mingw-w64 in the CI & Guix build, and it doesn't produce this warning.
(https://github.com/bitcoin/bitcoin/pull/33570#issuecomment-3380545850)
> MinGW also defines environ ... causing the same inconsistent linkage warning.
Can you improve the PR description & commit message? We use mingw-w64 in the CI & Guix build, and it doesn't produce this warning.
💬 maflcko commented on pull request "refactor: replace `const char*` exceptions with `std::runtime_error`":
(https://github.com/bitcoin/bitcoin/pull/33569#issuecomment-3380547548)
lgtm, but it seems this is a workaround for an upstream bug?
In any case, the reason why a raw string literal was thrown, because the primary goal of this is inside a consteval context, and it avoids an include. I guess you'd have to add the include here, if you start using runtime_error. Though, that feels off for this context, as mentioned previously.
Out of curiosity, I wonder, would it work if a string_view was thrown?
(https://github.com/bitcoin/bitcoin/pull/33569#issuecomment-3380547548)
lgtm, but it seems this is a workaround for an upstream bug?
In any case, the reason why a raw string literal was thrown, because the primary goal of this is inside a consteval context, and it avoids an include. I guess you'd have to add the include here, if you start using runtime_error. Though, that feels off for this context, as mentioned previously.
Out of curiosity, I wonder, would it work if a string_view was thrown?
💬 hodlinator commented on pull request "refactor: replace `const char*` exceptions with `std::runtime_error`":
(https://github.com/bitcoin/bitcoin/pull/33569#discussion_r2413151212)
Great! Would prefer something like this diff applied to the PR description and commit message to make it even clearer that this is primarily a workaround for a compiler issue and secondarily abiding by guidelines:
```diff
Fixes MinGW/libc++ test failures where `BOOST_CHECK_EXCEPTION` with `const char*` exceptions
- failed due to platform-specific exception handling differences.
+ is broken, see https://github.com/mstorsjo/llvm-mingw/issues/522
```
(https://github.com/bitcoin/bitcoin/pull/33569#discussion_r2413151212)
Great! Would prefer something like this diff applied to the PR description and commit message to make it even clearer that this is primarily a workaround for a compiler issue and secondarily abiding by guidelines:
```diff
Fixes MinGW/libc++ test failures where `BOOST_CHECK_EXCEPTION` with `const char*` exceptions
- failed due to platform-specific exception handling differences.
+ is broken, see https://github.com/mstorsjo/llvm-mingw/issues/522
```
⚠️ fanquake opened an issue: "build: Qt deprecated-declarations warnings"
(https://github.com/bitcoin/bitcoin/issues/33571)
Building master (b510893d00760083ac36948747aa6ebd84656192) against Qt 6.10.0:
```bash
/root/bitcoin/src/qt/transactionfilterproxy.cpp: In member function ‘void TransactionFilterProxy::setDateRange(const std::optional<QDateTime>&, const std::optional<QDateTime>&)’:
/root/bitcoin/src/qt/transactionfilterproxy.cpp:57:21: warning: ‘void QSortFilterProxyModel::invalidateFilter()’ is deprecated: Use begin/endFilterChange() instead [-Wdeprecated-declarations]
57 | invalidateFilter();
|
...
(https://github.com/bitcoin/bitcoin/issues/33571)
Building master (b510893d00760083ac36948747aa6ebd84656192) against Qt 6.10.0:
```bash
/root/bitcoin/src/qt/transactionfilterproxy.cpp: In member function ‘void TransactionFilterProxy::setDateRange(const std::optional<QDateTime>&, const std::optional<QDateTime>&)’:
/root/bitcoin/src/qt/transactionfilterproxy.cpp:57:21: warning: ‘void QSortFilterProxyModel::invalidateFilter()’ is deprecated: Use begin/endFilterChange() instead [-Wdeprecated-declarations]
57 | invalidateFilter();
|
...
💬 maflcko commented on pull request "DRAFT: add a freebsd job using systemlibs":
(https://github.com/bitcoin/bitcoin/pull/33562#discussion_r2413156742)
no strong opinion, but is there a rationale about the scope here? why disable the fuzz binary?
(https://github.com/bitcoin/bitcoin/pull/33562#discussion_r2413156742)
no strong opinion, but is there a rationale about the scope here? why disable the fuzz binary?
💬 willcl-ark commented on pull request "DRAFT: add a freebsd job using systemlibs":
(https://github.com/bitcoin/bitcoin/pull/33562#discussion_r2413178459)
No opinion from me either, this is just a tranlation mistake from https://github.com/hebasto/bitcoin-core-nightly/blob/36cc3ef2703d6f662e9a96c21db5d83d80e7efb9/.github/workflows/freebsd.yml#L58 where it is indeed enabled.
I will re-enable it in next push.
(https://github.com/bitcoin/bitcoin/pull/33562#discussion_r2413178459)
No opinion from me either, this is just a tranlation mistake from https://github.com/hebasto/bitcoin-core-nightly/blob/36cc3ef2703d6f662e9a96c21db5d83d80e7efb9/.github/workflows/freebsd.yml#L58 where it is indeed enabled.
I will re-enable it in next push.
🤔 janb84 reviewed a pull request: "doc: how to update a subtree"
(https://github.com/bitcoin/bitcoin/pull/33568#pullrequestreview-3313922400)
ACK a1226bc760c70a22ef4a197d5690aca4d83cb74c
This pr adds a section to subtrees. This section describes how to verify or update a subtree ( commands etc). Adding of this section will help new contributors do a subtrees update without spending time to search how to do this.
Added small NIT to add a subsection header, to better subdivide the section. Feel free to ignore.
(https://github.com/bitcoin/bitcoin/pull/33568#pullrequestreview-3313922400)
ACK a1226bc760c70a22ef4a197d5690aca4d83cb74c
This pr adds a section to subtrees. This section describes how to verify or update a subtree ( commands etc). Adding of this section will help new contributors do a subtrees update without spending time to search how to do this.
Added small NIT to add a subsection header, to better subdivide the section. Feel free to ignore.
💬 janb84 commented on pull request "doc: how to update a subtree":
(https://github.com/bitcoin/bitcoin/pull/33568#discussion_r2413209402)
```suggestion
### Updating subtrees
To fully verify or update a subtree, add it as a remote:
```
NIT add a sub heading to better indicate it's a subsection. This will help the reader in finding the section and it will nicely bind the section together.
(https://github.com/bitcoin/bitcoin/pull/33568#discussion_r2413209402)
```suggestion
### Updating subtrees
To fully verify or update a subtree, add it as a remote:
```
NIT add a sub heading to better indicate it's a subsection. This will help the reader in finding the section and it will nicely bind the section together.
💬 fanquake commented on pull request "[wip] A more static bitcoin-qt":
(https://github.com/bitcoin/bitcoin/pull/33537#issuecomment-3380694579)
> How is this approach better than https://github.com/bitcoin/bitcoin/pull/29923?
They are doing different things. This PR produces a (much more) static `bitcoin-qt`, using depends as is. #29923 introduces new tooling, to essentially "hide" the runtime loading, the binary is not any more static.
(https://github.com/bitcoin/bitcoin/pull/33537#issuecomment-3380694579)
> How is this approach better than https://github.com/bitcoin/bitcoin/pull/29923?
They are doing different things. This PR produces a (much more) static `bitcoin-qt`, using depends as is. #29923 introduces new tooling, to essentially "hide" the runtime loading, the binary is not any more static.
💬 fanquake commented on pull request "ci: add libcpp hardening flags to macOS fuzz job":
(https://github.com/bitcoin/bitcoin/pull/33462#issuecomment-3380697127)
Rebased after #33489.
(https://github.com/bitcoin/bitcoin/pull/33462#issuecomment-3380697127)
Rebased after #33489.
💬 Sjors commented on pull request "ci: Use ARM instead of Intel in macOS cross task":
(https://github.com/bitcoin/bitcoin/pull/33549#issuecomment-3380708447)
The title is a bit confusing: "Use ARM instead of Intel in macOS cross task"
Maybe say "Build for" instead of "use", since the job uses Ubuntu to build.
It might be better to test cross compilation for both x86 and arm, though if that takes too much CI resources then arm is probably the more important target.
Briefly running the cross-compiled x86 binary on a native x86 CI machine would be useful, but it looks like Rosetta is the best we'll get from Github.
(https://github.com/bitcoin/bitcoin/pull/33549#issuecomment-3380708447)
The title is a bit confusing: "Use ARM instead of Intel in macOS cross task"
Maybe say "Build for" instead of "use", since the job uses Ubuntu to build.
It might be better to test cross compilation for both x86 and arm, though if that takes too much CI resources then arm is probably the more important target.
Briefly running the cross-compiled x86 binary on a native x86 CI machine would be useful, but it looks like Rosetta is the best we'll get from Github.
💬 MasterixCZ commented on pull request "[30.x] Finalise v30.0":
(https://github.com/bitcoin/bitcoin/pull/33559#issuecomment-3380717032)
If the government's laws could destroy Bitcoin, it would already be dead.
(https://github.com/bitcoin/bitcoin/pull/33559#issuecomment-3380717032)
If the government's laws could destroy Bitcoin, it would already be dead.
💬 maflcko commented on pull request "ci: Build for ARM instead of Intel in macOS cross task":
(https://github.com/bitcoin/bitcoin/pull/33549#issuecomment-3380722777)
> It might be better to test cross compilation for both x86 and arm, though if that takes too much CI resources then arm is probably the more important target.
>
> Briefly running the cross-compiled x86 binary on a native x86 CI machine would be useful, but it looks like Rosetta is the best we'll get from Github.
Happy to add this to my nightly CI repo, but it doesn't seem like a good use of CI resources here. Though, best I can do is the Rosetta 2 from GitHub.
(https://github.com/bitcoin/bitcoin/pull/33549#issuecomment-3380722777)
> It might be better to test cross compilation for both x86 and arm, though if that takes too much CI resources then arm is probably the more important target.
>
> Briefly running the cross-compiled x86 binary on a native x86 CI machine would be useful, but it looks like Rosetta is the best we'll get from Github.
Happy to add this to my nightly CI repo, but it doesn't seem like a good use of CI resources here. Though, best I can do is the Rosetta 2 from GitHub.