Bitcoin Core Github
44 subscribers
121K links
Download Telegram
💬 fanquake commented on pull request "test: Suppress upstream `-Wduplicate-decl-specifier` in bpfcc":
(https://github.com/bitcoin/bitcoin/pull/32336#issuecomment-2828151516)
Backported to 28.x in #32299.
💬 maflcko commented on pull request "ci: Merge fuzz task for macOS and Windows":
(https://github.com/bitcoin/bitcoin/pull/32339#issuecomment-2828183599)
> Don't these jobs run in parallel? i.e. how does this save time?

The tasks don't run in parallel, when the GHA limit is reached. However this should be rare. The time and space savings come from re-using build artefacts that can be shared between the fuzz binary and other binaries.

It is true that the end-to-end duration of the combined task is now longer, albeit it being less than the sum of the times of the split tasks. I don't think this is a concern, but no strong opinion.

> This r
...
💬 pablomartin4btc commented on pull request "wallet: Disable creating and loading legacy wallets":
(https://github.com/bitcoin/bitcoin/pull/31250#issuecomment-2828199316)
If a user tries to restore a legacy wallet (using RPC or QT) setting "load_on_startup" (can't be done on QT but it's being set in the wallet interface code), next time the node or QT starts it will be closed with the error _"... Failed to open database path ... The wallet appears to be a Legacy wallet, please use the wallet migration tool... "_. That case shouldn't be handled here? We shouldn't allow `load_on_startup` on legacy...

(Currently this situation is not happening as a side effect of
...
💬 pablomartin4btc commented on pull request "Remove the legacy wallet and BDB dependency":
(https://github.com/bitcoin/bitcoin/pull/28710#discussion_r2058574120)
nit: something like this just for reference, if you agree ofc...
```suggestion

These wallets, Legacy Wallets, are not longer supported (since v3x), can't be created nor loaded but migrated into SQLite (Descriptor Wallets).

```
💬 pablomartin4btc commented on pull request "Remove the legacy wallet and BDB dependency":
(https://github.com/bitcoin/bitcoin/pull/28710#discussion_r2058386261)
nit: shouldn't this one be removed too?
```suggestion
```
💬 maflcko commented on pull request "doc: document workaround and fallback for macOS fuzzing":
(https://github.com/bitcoin/bitcoin/pull/32084#discussion_r2058845822)
Is this actually an issue that anyone ran into, other than yourself?

The CI is running on Apple Silicon, and it looks fine. Also, I haven't seen others report this issue. So it seems most likely that the problem exists on your machine. It seems fine if you want to work around it without fixing it, but I am not sure if `doc/fuzzing.md` is the right place to document your personal and temporary workarounds?
💬 maflcko commented on pull request "Crash fix, disconnect numBlocksChanged() signal during shutdown":
(https://github.com/bitcoin-core/gui/pull/864#issuecomment-2828280254)
I tried 0ee5376fb302ebb21fb6192ed708800ee8035eb5 with my steps to reproduce and still got:

```
==301067== Process terminating with default action of signal 11 (SIGSEGV): dumping core
💬 laanwj commented on pull request "Crash fix, disconnect numBlocksChanged() signal during shutdown":
(https://github.com/bitcoin-core/gui/pull/864#issuecomment-2828299385)
That's really strange. Is there some thread race maybe?
💬 maflcko commented on pull request "ci: Merge fuzz task for macOS and Windows":
(https://github.com/bitcoin/bitcoin/pull/32339#issuecomment-2828303457)
To give some numbers for the macOS task: It passed here in 29min (with an empty ccache), whereas on master, the times were 19min+14min=32min (https://github.com/bitcoin/bitcoin/actions/runs/14638899803/job/41076397151)
⚠️ achow101 opened an issue: "Moving this repo to bitcoin-core"
(https://github.com/bitcoin/bitcoin/issues/32340)
Organizationally, it doesn't make sense for Bitcoin Core to be under the bitcoin GitHub organization. All of our other repos (gui, qa-assets, dev wiki, etc.) are under bitcoin-core, so having just this one repo in a different organization doesn't totally make sense. It's only in bitcoin/ for historical reasons. The bitcoin-core organization was created several years ago for the express purpose of moving this repo there, but we still haven't done it.

Conceptually, it makes sense to complete the
...
💬 achow101 commented on issue "Moving this repo to bitcoin-core":
(https://github.com/bitcoin/bitcoin/issues/32340#issuecomment-2828326895)
One concern that was brought up during the IRC meeting is whether github might recycle the bitcoin org if it were to have no activity. This would be problematic as if it were recycled this opens up the possibility of scammers to create a new bitcoin/bitcoin that points to something malicious. However, several contributors have tried to get github to release inactive usernames and organizations with extreme difficulty, and generally unable to actually get them to do that, so I think this risk is
...
⚠️ maflcko opened an issue: "ctest -C Debug fails on vs2022 with test_bitcoin-qt (Exit code 0xc0000135)"
(https://github.com/bitcoin/bitcoin/issues/32341)
cmd: `ctest --output-on-failure --stop-on-failure -j $NUMBER_OF_PROCESSORS -C Debug`

output:

```
88% tests passed, 1 tests failed out of 8

Total Test time (real) = 98.97 sec

The following tests FAILED:
8 - test_bitcoin-qt (Exit code 0xc0000135
)
Errors while running CTest
```

log: https://github.com/bitcoin/bitcoin/actions/runs/14646596997/job/41102269274?pr=32339#step:11:78

ref: https://github.com/bitcoin/bitcoin/pull/32339
💬 kanzure commented on issue "Moving this repo to bitcoin-core":
(https://github.com/bitcoin/bitcoin/issues/32340#issuecomment-2828433172)
I would like to see a write-up of the different GitHub arrangements so that we can compare the plans by name.
📝 tomasandroil opened a pull request: "Fix missing error check in `set_clo_on_exec` for FD_CLOEXEC handling"
(https://github.com/bitcoin/bitcoin/pull/32342)
#### Changes:
- Replaces unchecked `fcntl(fd, F_SETFD, flags);` with a version that checks the return value.
- Throws `OSError` on failure with an appropriate error message.

#### Motivation:
Proper error handling is critical in system-level code to avoid silent failures, especially when setting file descriptor flags like `FD_CLOEXEC`. This fix ensures robustness and helps catch configuration issues early during process setup.

### Test coverage
No functional change beyond improved err
...
💬 laanwj commented on pull request "Fix missing error check in `set_clo_on_exec` for FD_CLOEXEC handling":
(https://github.com/bitcoin/bitcoin/pull/32342#discussion_r2058986286)
This `fcntl` can return `-1` on error too.
💬 sr-gi commented on issue "Moving this repo to bitcoin-core":
(https://github.com/bitcoin/bitcoin/issues/32340#issuecomment-2828495015)
I expressed my concerns about moving bitcoin out of the bitcoin org / leaving the bitcoin org empty during the meeting, but I think it is worth elaborating on them.

While I can see the logistical benefits of splitting the orgs and how it may make admin/moderator lives easier, I don't think that's enough motivation to overcome the potential risks of redirections being broken, github giving up the org due to inactivity, or a takeover of the bitcoin/bitcoin repo. I do agree that these threads are
...
💬 furszy commented on pull request "Crash fix, disconnect numBlocksChanged() signal during shutdown":
(https://github.com/bitcoin-core/gui/pull/864#issuecomment-2828497800)
> That's really strange. Is there some thread race maybe?
> Does the old solution (to check clientModel in the callback) work better?

Hmm, I should check, but I have the hunch that events already queued are still delivered after disconnection. Which, if that is the case, the previous `clientModel` check would work better.
💬 laanwj commented on pull request "Crash fix, disconnect numBlocksChanged() signal during shutdown":
(https://github.com/bitcoin-core/gui/pull/864#issuecomment-2828513340)
> Hmm, I should check, but I have the hunch that events already queued are still delivered after disconnection. Which, if that is the case, the previous clientModel check would work better.

The signals are queued, but if no handler is connected, they sould just be dropped.
maflcko closed an issue: "ctest -C Debug fails on vs2022 (Exit code 0xc0000135)"
(https://github.com/bitcoin/bitcoin/issues/32341)
💬 maflcko commented on issue "ctest -C Debug fails on vs2022 (Exit code 0xc0000135)":
(https://github.com/bitcoin/bitcoin/issues/32341#issuecomment-2828524157)
I guess I caused the issue myself. False alarm