💬 fanquake commented on pull request "ci: Test cross-built Windows executables on Windows natively":
(https://github.com/bitcoin/bitcoin/pull/31176#issuecomment-2733129056)
> Sure. Leaving it for follow ups.
Any particular reason? This has no ACKs, and it seems like removing the Wine workarounds should be a part of the rest of the Wine removal?
(https://github.com/bitcoin/bitcoin/pull/31176#issuecomment-2733129056)
> Sure. Leaving it for follow ups.
Any particular reason? This has no ACKs, and it seems like removing the Wine workarounds should be a part of the rest of the Wine removal?
💬 hebasto commented on pull request "ci: Test cross-built Windows executables on Windows natively":
(https://github.com/bitcoin/bitcoin/pull/31176#issuecomment-2733143518)
> > Wine is not a supported platform for Bitcoin Core.
>
> To be fair, being able to test under Wine can be useful, if you're building/developing/testing something for windows but don't have a native windows machine available immediately. Sure it's possible to e.g. create windows server VMs at amazon EC but the extra cost and hassle is only warranted for final testing. But also agree that Wine support is not something that's worth putting a lot of effort in maintaining. But also wouldn't want
...
(https://github.com/bitcoin/bitcoin/pull/31176#issuecomment-2733143518)
> > Wine is not a supported platform for Bitcoin Core.
>
> To be fair, being able to test under Wine can be useful, if you're building/developing/testing something for windows but don't have a native windows machine available immediately. Sure it's possible to e.g. create windows server VMs at amazon EC but the extra cost and hassle is only warranted for final testing. But also agree that Wine support is not something that's worth putting a lot of effort in maintaining. But also wouldn't want
...
💬 brunoerg commented on issue "Failure to run Fuzz tests when running with corpus":
(https://github.com/bitcoin/bitcoin/issues/32089#issuecomment-2733144415)
I could reproduce it following the same steps on MacOS 14.3
```
FUZZ=process_message build_fuzz/bin/fuzz qa-assets/fuzz_corpora/process_message/
fuzz(56832,0x1e31a5c40) malloc: nano zone abandoned due to inability to reserve vm space.
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 2192399851
INFO: Loaded 1 modules (1252322 inline 8-bit counters): 1252322 [0x104c38000, 0x104d69be2),
INFO: Loaded 1 PC tables (1252322 PCs): 1252322 [0x104d69be8,0x106085a08),
================
...
(https://github.com/bitcoin/bitcoin/issues/32089#issuecomment-2733144415)
I could reproduce it following the same steps on MacOS 14.3
```
FUZZ=process_message build_fuzz/bin/fuzz qa-assets/fuzz_corpora/process_message/
fuzz(56832,0x1e31a5c40) malloc: nano zone abandoned due to inability to reserve vm space.
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 2192399851
INFO: Loaded 1 modules (1252322 inline 8-bit counters): 1252322 [0x104c38000, 0x104d69be2),
INFO: Loaded 1 PC tables (1252322 PCs): 1252322 [0x104d69be8,0x106085a08),
================
...
💬 ismaelsadeeq commented on issue "wallet: rpc: `settxfee` sets the wallet feerate not fee":
(https://github.com/bitcoin/bitcoin/issues/31088#issuecomment-2733158691)
It will be verbose to update all instances to use sat/vB instead of BTC/kvB in one go. Moreover, I imagine this will be a breaking change.
I also understand @maflcko's concern that having both units in the code makes things somewhat ambiguous for clients.
(https://github.com/bitcoin/bitcoin/issues/31088#issuecomment-2733158691)
It will be verbose to update all instances to use sat/vB instead of BTC/kvB in one go. Moreover, I imagine this will be a breaking change.
I also understand @maflcko's concern that having both units in the code makes things somewhat ambiguous for clients.
💬 maflcko commented on issue "Failure to run Fuzz tests when running with corpus":
(https://github.com/bitcoin/bitcoin/issues/32089#issuecomment-2733160346)
I presume the `libfuzzer-nosan` preset works fine?
(https://github.com/bitcoin/bitcoin/issues/32089#issuecomment-2733160346)
I presume the `libfuzzer-nosan` preset works fine?
💬 Prabhat1308 commented on issue "Failure to run Fuzz tests when running with corpus":
(https://github.com/bitcoin/bitcoin/issues/32089#issuecomment-2733185782)
> I presume the `libfuzzer-nosan` preset works fine?
Works fine. I do get these warning though on the start of the run .
```
WARNING: Failed to find function "__sanitizer_acquire_crash_state". Reason dlsym(RTLD_DEFAULT, __sanitizer_acquire_crash_state): symbol not found.
WARNING: Failed to find function "__sanitizer_print_stack_trace". Reason dlsym(RTLD_DEFAULT, __sanitizer_print_stack_trace): symbol not found.
WARNING: Failed to find function "__sanitizer_set_death_callback". Reason dlsym(RTLD
...
(https://github.com/bitcoin/bitcoin/issues/32089#issuecomment-2733185782)
> I presume the `libfuzzer-nosan` preset works fine?
Works fine. I do get these warning though on the start of the run .
```
WARNING: Failed to find function "__sanitizer_acquire_crash_state". Reason dlsym(RTLD_DEFAULT, __sanitizer_acquire_crash_state): symbol not found.
WARNING: Failed to find function "__sanitizer_print_stack_trace". Reason dlsym(RTLD_DEFAULT, __sanitizer_print_stack_trace): symbol not found.
WARNING: Failed to find function "__sanitizer_set_death_callback". Reason dlsym(RTLD
...
💬 polespinasa commented on issue "wallet: rpc: `settxfee` sets the wallet feerate not fee":
(https://github.com/bitcoin/bitcoin/issues/31088#issuecomment-2733192225)
We can look at what changes are needed, update the ones that don't break anything (e.g. rpc that simply give information but don't take a feerate as an argument). And the others can be put together in a PR, if they are not too many or too critical we can warn during a couple of releases with “deprecated” and at some point update to change the units.
(https://github.com/bitcoin/bitcoin/issues/31088#issuecomment-2733192225)
We can look at what changes are needed, update the ones that don't break anything (e.g. rpc that simply give information but don't take a feerate as an argument). And the others can be put together in a PR, if they are not too many or too critical we can warn during a couple of releases with “deprecated” and at some point update to change the units.
💬 brunoerg commented on pull request "doc: use `libfuzzer-nosan` for macOS":
(https://github.com/bitcoin/bitcoin/pull/32084#issuecomment-2733198404)
> > Thanks for the hint @brunoerg, I did a bisect to see if it's the commits or the update, which gave me contradictory results. Clearing all build caches however fixed it for master as well:
> > ```shell
> > ccache -C && git clean -fxd && git reset --hard
> > ```
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Guess we can't rely on cache invalidation here.
>
> I'd appreciate it if you could provide steps to reproduce the scenario where
...
(https://github.com/bitcoin/bitcoin/pull/32084#issuecomment-2733198404)
> > Thanks for the hint @brunoerg, I did a bisect to see if it's the commits or the update, which gave me contradictory results. Clearing all build caches however fixed it for master as well:
> > ```shell
> > ccache -C && git clean -fxd && git reset --hard
> > ```
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Guess we can't rely on cache invalidation here.
>
> I'd appreciate it if you could provide steps to reproduce the scenario where
...
💬 maflcko commented on pull request "fuzz: Speed up *_package_eval fuzz targets a bit":
(https://github.com/bitcoin/bitcoin/pull/31457#discussion_r2001035909)
thx, done
(https://github.com/bitcoin/bitcoin/pull/31457#discussion_r2001035909)
thx, done
💬 maflcko commented on issue "[rfc] build: Reject unclean configure?":
(https://github.com/bitcoin/bitcoin/issues/31942#issuecomment-2733223668)
Another instance where a stale cmake cache caused issues after a brew? update: https://github.com/bitcoin/bitcoin/pull/32084#issuecomment-2729550053
(https://github.com/bitcoin/bitcoin/issues/31942#issuecomment-2733223668)
Another instance where a stale cmake cache caused issues after a brew? update: https://github.com/bitcoin/bitcoin/pull/32084#issuecomment-2729550053
💬 laanwj commented on pull request "ci: Test cross-built Windows executables on Windows natively":
(https://github.com/bitcoin/bitcoin/pull/31176#issuecomment-2733226368)
> From my experience, it can be a bit annoying when working on Windows-specific code one also have to accommodate Wine-specific code in tests.
Yes, ideally incompatibilities with real windows would be fixed on the Wine side, the whole point of Wine is to behave like windows. It's absurd to have to carry a lot of workarounds just for Wine.
(https://github.com/bitcoin/bitcoin/pull/31176#issuecomment-2733226368)
> From my experience, it can be a bit annoying when working on Windows-specific code one also have to accommodate Wine-specific code in tests.
Yes, ideally incompatibilities with real windows would be fixed on the Wine side, the whole point of Wine is to behave like windows. It's absurd to have to carry a lot of workarounds just for Wine.
💬 maflcko commented on pull request "ci: Test cross-built Windows executables on Windows natively":
(https://github.com/bitcoin/bitcoin/pull/31176#issuecomment-2733252346)
As the test failures under wine happen intermittently, I expect it would be hard to debug and fix it upstream? Maybe someone can reproduce it in `rr`?
In any case, I don't mind if people maintain Wine compatibility, or even add it back to the normal CI, once Wine is fixed. However, until then, maintaining Wine compatibility is something to be done in a "nightly CI", with only fixes provided to this repo.
(https://github.com/bitcoin/bitcoin/pull/31176#issuecomment-2733252346)
As the test failures under wine happen intermittently, I expect it would be hard to debug and fix it upstream? Maybe someone can reproduce it in `rr`?
In any case, I don't mind if people maintain Wine compatibility, or even add it back to the normal CI, once Wine is fixed. However, until then, maintaining Wine compatibility is something to be done in a "nightly CI", with only fixes provided to this repo.
💬 maflcko commented on pull request "test: replace assert with assert_equal and assert_greater_than":
(https://github.com/bitcoin/bitcoin/pull/32091#discussion_r2001077998)
https://github.com/bitcoin/bitcoin/actions/runs/13923574432/job/38962671641?pr=32091#step:6:7169
failed
(https://github.com/bitcoin/bitcoin/pull/32091#discussion_r2001077998)
https://github.com/bitcoin/bitcoin/actions/runs/13923574432/job/38962671641?pr=32091#step:6:7169
failed
💬 Chand-ra commented on pull request "test: replace assert with assert_equal and assert_greater_than":
(https://github.com/bitcoin/bitcoin/pull/32091#discussion_r2001094779)
I ran the entire test suite from my `build` directory and the modified test passed just fine there. Any idea on what might cause the discrepancy?
(https://github.com/bitcoin/bitcoin/pull/32091#discussion_r2001094779)
I ran the entire test suite from my `build` directory and the modified test passed just fine there. Any idea on what might cause the discrepancy?
💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#issuecomment-2733350025)
Rebased.
(https://github.com/bitcoin/bitcoin/pull/30997#issuecomment-2733350025)
Rebased.
💬 hodlinator commented on pull request "net: Block v2->v1 transport downgrade if !fNetworkActive":
(https://github.com/bitcoin/bitcoin/pull/32073#discussion_r2001138653)
> Not blocking, but this seemed slightly more correct to me before, since now if `fNetworkActive == false` when caching the result, but `true` when disconnecting, we might not attempt v1 reconnect when we should have.
The probability that someone will be able to toggle `fNetworkActive` `false -> true` between the first loop starting and the second loop, when one also happens to have a peer in the right step in the handshake.. just doesn't feel like it should be something we need to support. B
...
(https://github.com/bitcoin/bitcoin/pull/32073#discussion_r2001138653)
> Not blocking, but this seemed slightly more correct to me before, since now if `fNetworkActive == false` when caching the result, but `true` when disconnecting, we might not attempt v1 reconnect when we should have.
The probability that someone will be able to toggle `fNetworkActive` `false -> true` between the first loop starting and the second loop, when one also happens to have a peer in the right step in the handshake.. just doesn't feel like it should be something we need to support. B
...
💬 ismaelsadeeq commented on pull request "Fee Estimation: Ignore all transactions that are CPFP'd":
(https://github.com/bitcoin/bitcoin/pull/30079#issuecomment-2733395488)
> This is a GitHub bug, but they are not going to fix it. The only way to fix it is by doing another rebase (or for a GitHub staff to manually clean it). See [maflcko/DrahtBot#43 (comment)](https://github.com/maflcko/DrahtBot/issues/43#issuecomment-2653314333)
I rebase against master and force-push with newer commits, it is still not updating https://github.com/bitcoin/bitcoin/compare/master...ismaelsadeeq:bitcoin:05-2023-ignore-transactions-with-parents
(https://github.com/bitcoin/bitcoin/pull/30079#issuecomment-2733395488)
> This is a GitHub bug, but they are not going to fix it. The only way to fix it is by doing another rebase (or for a GitHub staff to manually clean it). See [maflcko/DrahtBot#43 (comment)](https://github.com/maflcko/DrahtBot/issues/43#issuecomment-2653314333)
I rebase against master and force-push with newer commits, it is still not updating https://github.com/bitcoin/bitcoin/compare/master...ismaelsadeeq:bitcoin:05-2023-ignore-transactions-with-parents
💬 ismaelsadeeq commented on issue "wallet: rpc: `settxfee` sets the wallet feerate not fee":
(https://github.com/bitcoin/bitcoin/issues/31088#issuecomment-2733423213)
> We can look at what changes are needed, update the ones that don't break anything (e.g. rpc that simply give information but don't take a feerate as an argument).
This makes sense, currently internally `CFeeRate` is represented as feerate in `BTC/kvB`, although the newer replacement to it `FeeFrac` is going to be in `s/vb` see https://github.com/bitcoin/bitcoin/pull/31363/commits/8d1bbafa84bbca0e412f939823fa1a30ef839951
It will makes to first analyse how many or too critical of a change th
...
(https://github.com/bitcoin/bitcoin/issues/31088#issuecomment-2733423213)
> We can look at what changes are needed, update the ones that don't break anything (e.g. rpc that simply give information but don't take a feerate as an argument).
This makes sense, currently internally `CFeeRate` is represented as feerate in `BTC/kvB`, although the newer replacement to it `FeeFrac` is going to be in `s/vb` see https://github.com/bitcoin/bitcoin/pull/31363/commits/8d1bbafa84bbca0e412f939823fa1a30ef839951
It will makes to first analyse how many or too critical of a change th
...
💬 ryanofsky commented on pull request "multiprocess: Add libmultiprocess git subtree":
(https://github.com/bitcoin/bitcoin/pull/31741#issuecomment-2733453010)
Rebased 8ef8f799b04eaea9091ed339dfe2cdb3a31ec245 -> 4e265debdc0319bbfcea915d9026b33810b810f8 ([`pr/subtree.24`](https://github.com/ryanofsky/bitcoin/commits/pr/subtree.24) -> [`pr/subtree.25`](https://github.com/ryanofsky/bitcoin/commits/pr/subtree.25), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/subtree.24-rebase..pr/subtree.25)) with no changes since #30975 has a merge conflict https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2732019454 and windows CI job was also faili
...
(https://github.com/bitcoin/bitcoin/pull/31741#issuecomment-2733453010)
Rebased 8ef8f799b04eaea9091ed339dfe2cdb3a31ec245 -> 4e265debdc0319bbfcea915d9026b33810b810f8 ([`pr/subtree.24`](https://github.com/ryanofsky/bitcoin/commits/pr/subtree.24) -> [`pr/subtree.25`](https://github.com/ryanofsky/bitcoin/commits/pr/subtree.25), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/subtree.24-rebase..pr/subtree.25)) with no changes since #30975 has a merge conflict https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2732019454 and windows CI job was also faili
...
🤔 TheCharlatan reviewed a pull request: "multiprocess: Add libmultiprocess git subtree"
(https://github.com/bitcoin/bitcoin/pull/31741#pullrequestreview-2694724554)
lgtm, but would you like people to review #31992 first?
(https://github.com/bitcoin/bitcoin/pull/31741#pullrequestreview-2694724554)
lgtm, but would you like people to review #31992 first?