⚠️ 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.
💬 maflcko commented on pull request "ci: add libcpp hardening flags to macOS fuzz job":
(https://github.com/bitcoin/bitcoin/pull/33462#issuecomment-3380734734)
lgtm ACK e4c04f7759b0b390189410f5ef3ad5faa5354698. The qa-assets repo has a libc++ debug run, so this isn't required, but it seems fast enough to not hurt.
(https://github.com/bitcoin/bitcoin/pull/33462#issuecomment-3380734734)
lgtm ACK e4c04f7759b0b390189410f5ef3ad5faa5354698. The qa-assets repo has a libc++ debug run, so this isn't required, but it seems fast enough to not hurt.
💬 fanquake commented on pull request "ci: Build for ARM instead of Intel in macOS cross task":
(https://github.com/bitcoin/bitcoin/pull/33549#issuecomment-3380738070)
> but it doesn't seem like a good use of CI resources here.
Having at least compilation coverage of every target we are shipping a release binary for seems like something we should have? Post switchover we are much less constrained on the CI resources front.
(https://github.com/bitcoin/bitcoin/pull/33549#issuecomment-3380738070)
> but it doesn't seem like a good use of CI resources here.
Having at least compilation coverage of every target we are shipping a release binary for seems like something we should have? Post switchover we are much less constrained on the CI resources front.
💬 Sjors commented on pull request "doc: how to update a subtree":
(https://github.com/bitcoin/bitcoin/pull/33568#discussion_r2413292023)
But then I have to move the text below this too, or add even more paragraphs. So going to leave it as is for now.
(https://github.com/bitcoin/bitcoin/pull/33568#discussion_r2413292023)
But then I have to move the text below this too, or add even more paragraphs. So going to leave it as is for now.
💬 fanquake commented on pull request "ci: Check macos-cross executables on macOS":
(https://github.com/bitcoin/bitcoin/pull/33509#issuecomment-3380767887)
It's not completely clear to me why we should have cross tests for Windows, but not for macOS, regardless of how-likely we think they are to find issues (or the runtime). Putting things in nightly repos also increases the likelyhood of double-handling changes, to fix things later (also assuming they are reported).
> Since we don't have high hopes of this actually detecting any issues that the rest of the CI would not have found, seems to make more sense as a nightly job?
@hodlinator could
...
(https://github.com/bitcoin/bitcoin/pull/33509#issuecomment-3380767887)
It's not completely clear to me why we should have cross tests for Windows, but not for macOS, regardless of how-likely we think they are to find issues (or the runtime). Putting things in nightly repos also increases the likelyhood of double-handling changes, to fix things later (also assuming they are reported).
> Since we don't have high hopes of this actually detecting any issues that the rest of the CI would not have found, seems to make more sense as a nightly job?
@hodlinator could
...
💬 thewrlck commented on pull request "[30.x] Finalise v30.0":
(https://github.com/bitcoin/bitcoin/pull/33559#issuecomment-3380773895)
`-datacarriersize` is increased to 100,000 by default, which effectively uncaps 🔥🔥🔥
(https://github.com/bitcoin/bitcoin/pull/33559#issuecomment-3380773895)
`-datacarriersize` is increased to 100,000 by default, which effectively uncaps 🔥🔥🔥
💬 Sjors commented on pull request "Clear out space on GHA jobs":
(https://github.com/bitcoin/bitcoin/pull/33514#discussion_r2413331519)
Is this automatically set?
(https://github.com/bitcoin/bitcoin/pull/33514#discussion_r2413331519)
Is this automatically set?
💬 willcl-ark commented on pull request "depends: Update URL for `qrencode` package source tarball":
(https://github.com/bitcoin/bitcoin/pull/33494#issuecomment-3380802351)
Unfortunately this has inadvertently clobbered all non-master branches (e.g. https://github.com/bitcoin/bitcoin/pull/33559/checks) which don't have the required depends Makefile changes from the first 3 commits here.
The issue is that when we load a depends cache (which will come from master) we now load the (new) qrencode package using filename only in the v30 branch (without the changes here), but the hash doesn't match.
(https://github.com/bitcoin/bitcoin/pull/33494#issuecomment-3380802351)
Unfortunately this has inadvertently clobbered all non-master branches (e.g. https://github.com/bitcoin/bitcoin/pull/33559/checks) which don't have the required depends Makefile changes from the first 3 commits here.
The issue is that when we load a depends cache (which will come from master) we now load the (new) qrencode package using filename only in the v30 branch (without the changes here), but the hash doesn't match.
💬 willcl-ark commented on pull request "Clear out space on GHA jobs":
(https://github.com/bitcoin/bitcoin/pull/33514#discussion_r2413363756)
Yes, this is set by the `determine-runners` job: https://github.com/bitcoin/bitcoin/blob/b510893d00760083ac36948747aa6ebd84656192/.github/workflows/ci.yml#L33-L46
If you have [cirrus runners](https://cirrus-runners.app/) in your own repo you can set a repo variable `REPO_USE_CIRRUS_RUNNERS` to your repo name to enable cirrus runners in your fork.
(https://github.com/bitcoin/bitcoin/pull/33514#discussion_r2413363756)
Yes, this is set by the `determine-runners` job: https://github.com/bitcoin/bitcoin/blob/b510893d00760083ac36948747aa6ebd84656192/.github/workflows/ci.yml#L33-L46
If you have [cirrus runners](https://cirrus-runners.app/) in your own repo you can set a repo variable `REPO_USE_CIRRUS_RUNNERS` to your repo name to enable cirrus runners in your fork.
💬 willcl-ark commented on pull request "Clear out space on GHA jobs":
(https://github.com/bitcoin/bitcoin/pull/33514#discussion_r2413369136)
You will see the setting in the Annotations section of the Actions tab on a run:
<img width="1817" height="631" alt="image" src="https://github.com/user-attachments/assets/486d7b03-36d5-4740-89ac-0aaf8ccf6070" />
(https://github.com/bitcoin/bitcoin/pull/33514#discussion_r2413369136)
You will see the setting in the Annotations section of the Actions tab on a run:
<img width="1817" height="631" alt="image" src="https://github.com/user-attachments/assets/486d7b03-36d5-4740-89ac-0aaf8ccf6070" />
💬 fanquake commented on pull request "depends: Update URL for `qrencode` package source tarball":
(https://github.com/bitcoin/bitcoin/pull/33494#issuecomment-3380876967)
This change is causing the CI to fail on all the branches (#33559, #33551) we are about to cut releases from. I'd really prefer to not have to do another round of rcs, just to backport this.
(https://github.com/bitcoin/bitcoin/pull/33494#issuecomment-3380876967)
This change is causing the CI to fail on all the branches (#33559, #33551) we are about to cut releases from. I'd really prefer to not have to do another round of rcs, just to backport this.