Bitcoin Core Github
44 subscribers
119K links
Download Telegram
💬 hebasto commented on issue "[rfc] build: Reject unclean configure?":
(https://github.com/bitcoin/bitcoin/issues/31942#issuecomment-2700755534)
> [@purpleKarrot](https://github.com/purpleKarrot) maybe you could provide guidance on how to properly solve issues like [#31959](https://github.com/bitcoin/bitcoin/issues/31959) or one of the others the project is experiencing, which lead to this RFC?

It would also be helpful if someone provided steps to reproduce those issues.
💬 laanwj commented on pull request "doc: Bring reduce-memory.md up to date":
(https://github.com/bitcoin/bitcoin/pull/31985#issuecomment-2700766903)
> Should we make this function like maxmempool, which will fail to accept a value lower than the minimim (5)? Seems we are somewhat inconsistent in our handling of these.

Yes, probably. It's pretty much always better for user communication to fail for wrong values than to silently interpret them as something else.
💬 Sjors commented on pull request "Add mainnet assumeutxo param at height 880,000":
(https://github.com/bitcoin/bitcoin/pull/31969#issuecomment-2700775387)
@jonatack wrote:

> must appear in the headers chain.

That's expected behavior. The snapshot will refuse to load until we have its header.

Though one thing that could be improved it to have it wait for headers to reach the given height instead of fail.
💬 Sjors commented on pull request "Add mainnet assumeutxo param at height 880,000":
(https://github.com/bitcoin/bitcoin/pull/31969#discussion_r1981300210)
We want this to be updated in master, so we have to pick something before the v29 branch-off.
💬 fanquake commented on issue "cmake inconsistently overriding `-O3` (sometimes)":
(https://github.com/bitcoin/bitcoin/issues/31491#issuecomment-2700782712)
@sipa I think you were going to follow up here?
💬 vasild commented on pull request "Split CConnman":
(https://github.com/bitcoin/bitcoin/pull/30988#discussion_r1981304441)
Right, only to the caller (same thread). Locked or not by other threads is irrelevant for `AssertLockNotHeld()`.
💬 fanquake commented on issue "Having qt(@6) breaks build for qt@5 on macOS 15.0 and 13.7":
(https://github.com/bitcoin/bitcoin/issues/31009#issuecomment-2700805847)
Looks like this is still an issue. So this should either be documented for macOS builders (that they'll need to uninstall `qt` if it happens to be installed, whch is decently likely (and increasingly so into the future)), or the underlying issue fixed?
💬 Sjors commented on pull request "guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries":
(https://github.com/bitcoin/bitcoin/pull/31407#issuecomment-2700813691)
@fanquake we don't publish them on the download site, but we do put them on `bitcoincore.org/bin`. It seems harmless, but not useful.

The unsigned downloads still work if users (or some docker automation) self-sign, though that's pointless now that we offer a correctly signed alternative.

Even if Apple ever revokes our certificate, afaik it's possible for users to self-sign and override our signature.[^1]

If the user does a guix build themselves and copies the unsigned binaries using (s
...
💬 Sjors commented on issue "Having qt(@6) breaks build for qt@5 on macOS 15.0 and 13.7":
(https://github.com/bitcoin/bitcoin/issues/31009#issuecomment-2700820604)
I ran into it[^1] again a week or so ago, so I don't think it's fixed.

[^1] though I didn't compare the exact error, building worked again once I uninstalled qt6
👍 willcl-ark approved a pull request: "[28.x] Backports"
(https://github.com/bitcoin/bitcoin/pull/31648#pullrequestreview-2660991916)
ACK 77c13c7d3e68464555c6e9a049782674bcd9ea67

All commits look good to me.

I guess the commit title "[WIP] Update release notes" gets updated later during finalisation?
💬 hodlinator commented on pull request "build, ci: Fix linking `bitcoin-chainstate.exe` to `bitcoinkernel.dll` on Windows":
(https://github.com/bitcoin/bitcoin/pull/31158#discussion_r1981191286)
nit: Less confusing for every branch in the block to result in `#define`:
```suggestion
#else
```
💬 hodlinator commented on pull request "build, ci: Fix linking `bitcoin-chainstate.exe` to `bitcoinkernel.dll` on Windows":
(https://github.com/bitcoin/bitcoin/pull/31158#discussion_r1981338733)
Isn't *symbol_visibility.h* this dedicated header?
💬 hebasto commented on pull request "ci: Test cross-built Windows executables on Windows natively":
(https://github.com/bitcoin/bitcoin/pull/31176#discussion_r1981361215)
Thanks! Taken.

In my initial implementation, I relied on the [fail-fast behavior](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#exit-codes-and-error-action-preference) in GitHub-hosted runners. However, it turns out that `$ErrorActionPreference = 'stop'` only applies to PowerShell cmdlets.
💬 hebasto commented on pull request "ci: Test cross-built Windows executables on Windows natively":
(https://github.com/bitcoin/bitcoin/pull/31176#issuecomment-2700881250)
Addressed the recent feedback from @davidgumberg.
💬 fanquake commented on pull request "[28.x] Backports":
(https://github.com/bitcoin/bitcoin/pull/31648#issuecomment-2700914514)
@willcl-ark I've just changed it here.
💬 fanquake commented on pull request "ci: rename imagefile to Dockerfile to follow docker file's convention.":
(https://github.com/bitcoin/bitcoin/pull/31995#issuecomment-2700918781)
> And some docker image files are named as ".Dockerfile".

These are from subtrees.

I don't think there's anything to do here. Note that also don't need to use Docker, you can also use podman.
💬 fanquake commented on issue "Trying to run bitcoin qt on Windows and getting an AV":
(https://github.com/bitcoin/bitcoin/issues/30825#issuecomment-2700928581)
Is there anything for us to do here? Anything to be fixed? Should it just be closed? @hebasto.
hebasto closed an issue: "Trying to run bitcoin qt on Windows and getting an AV"
(https://github.com/bitcoin/bitcoin/issues/30825)
💬 eval-exec commented on pull request "ci: rename imagefile to Dockerfile to follow docker file's convention.":
(https://github.com/bitcoin/bitcoin/pull/31995#issuecomment-2700945396)
Thanks for your response!

> These are from subtrees.

Where is subtrees.

> I don't think there's anything to do here. Note that also don't need to use Docker, you can also use podman.

I just think it would be better to keep the image file names consistent. And, `podman` call it `Containerfile`. https://docs.podman.io/en/v5.3.0/markdown/podman-build.1.html
💬 fanquake commented on pull request "guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries":
(https://github.com/bitcoin/bitcoin/pull/31407#issuecomment-2700952489)
@Sjors My main question is why are the unsigned binaries in this PR, behaving differently to the unsigned binaries currently produced by master, and why that new failure message/behaviour [is expected](https://github.com/bitcoin/bitcoin/pull/31407#issuecomment-2699767246)?
💬 fanquake commented on pull request "ci: rename imagefile to Dockerfile to follow docker file's convention.":
(https://github.com/bitcoin/bitcoin/pull/31995#issuecomment-2700964152)
> Where is subtrees.

https://github.com/bitcoin-core/secp256k1
https://github.com/sipa/minisketch


> I just think it would be better to keep the image file names consistent.

Ours are consistently named `{name}_imagefile`. There's no requirement that we are consistent with files from other repositories.