π¬ maflcko commented on pull request "test: use notarized v28.2 binaries and fix macOS detection":
(https://github.com/bitcoin/bitcoin/pull/32922#discussion_r2192666366)
Your new code still looks wrong, when someone sets `HOST=x86_64-apple-darwin` on an arm machine, where signing isn't needed for that case.
Why not use `args.host` and keep the `"arm64-apple-darwin"` string?
(https://github.com/bitcoin/bitcoin/pull/32922#discussion_r2192666366)
Your new code still looks wrong, when someone sets `HOST=x86_64-apple-darwin` on an arm machine, where signing isn't needed for that case.
Why not use `args.host` and keep the `"arm64-apple-darwin"` string?
π¬ rkrux commented on pull request "wallet: Remove watchonly behavior and isminetypes":
(https://github.com/bitcoin/bitcoin/pull/32523#issuecomment-3049168255)
Looking good mostly. One way I think the review can be made easier is by reordering the commits to make the `isminetype` enum changes appear together because the review is done in the order of the commits presented. Suggested order (builds fine at the second commit on my system):
- [interfaces, gui: Remove is_mine output parameter from getAddress](https://github.com/bitcoin/bitcoin/pull/32523/commits/db7729d368203ac1d622d4f84bc87c818ebaa7a0)
- [wallet: Remove COutput::spendable and Available
...
(https://github.com/bitcoin/bitcoin/pull/32523#issuecomment-3049168255)
Looking good mostly. One way I think the review can be made easier is by reordering the commits to make the `isminetype` enum changes appear together because the review is done in the order of the commits presented. Suggested order (builds fine at the second commit on my system):
- [interfaces, gui: Remove is_mine output parameter from getAddress](https://github.com/bitcoin/bitcoin/pull/32523/commits/db7729d368203ac1d622d4f84bc87c818ebaa7a0)
- [wallet: Remove COutput::spendable and Available
...
π¬ Sjors commented on pull request "test: use notarized v28.2 binaries and fix macOS detection":
(https://github.com/bitcoin/bitcoin/pull/32922#discussion_r2192695167)
I don't understand the use case. Afaik you can't run the functional tests on such a cross-compiled build?
(https://github.com/bitcoin/bitcoin/pull/32922#discussion_r2192695167)
I don't understand the use case. Afaik you can't run the functional tests on such a cross-compiled build?
π¬ HowHsu commented on pull request "index: fix wrong assert of current_tip == m_best_block_index":
(https://github.com/bitcoin/bitcoin/pull/32878#issuecomment-3049207085)
> The test isn't testing the indexes code β just its own test-only implementation of it. It was essentially testing itself. And that's not useful.
I don't think so, it does test a case that the current tests don't do: reorg happens in sync period. look at the last part of the test, it tests if the old fork is not in the filter and the new best chain blocks is in the filter, though very basic for now.
The Sync in the test is same as in bitcoind, expect the thread synchronization code which is t
...
(https://github.com/bitcoin/bitcoin/pull/32878#issuecomment-3049207085)
> The test isn't testing the indexes code β just its own test-only implementation of it. It was essentially testing itself. And that's not useful.
I don't think so, it does test a case that the current tests don't do: reorg happens in sync period. look at the last part of the test, it tests if the old fork is not in the filter and the new best chain blocks is in the filter, though very basic for now.
The Sync in the test is same as in bitcoind, expect the thread synchronization code which is t
...
π brunoerg approved a pull request: "rest: replace `rf_names[0].rf` by `RESTResponseFormat::UNDEF` for code clarity"
(https://github.com/bitcoin/bitcoin/pull/32884#pullrequestreview-2997939984)
code review ACK 6d19815cd44031ff2b45fc9532f579cd81c62749
(https://github.com/bitcoin/bitcoin/pull/32884#pullrequestreview-2997939984)
code review ACK 6d19815cd44031ff2b45fc9532f579cd81c62749
π¬ HowHsu commented on pull request "index: fix wrong assert of current_tip == m_best_block_index":
(https://github.com/bitcoin/bitcoin/pull/32878#issuecomment-3049237953)
> > I don't think the test is useful.
> > Other than that, concept ACK.
>
> You can ignore it.
Easy, everyone. Without specific reasoning, these kinds of claims donβt really help.
(https://github.com/bitcoin/bitcoin/pull/32878#issuecomment-3049237953)
> > I don't think the test is useful.
> > Other than that, concept ACK.
>
> You can ignore it.
Easy, everyone. Without specific reasoning, these kinds of claims donβt really help.
π¬ ryanofsky commented on pull request "wallet: Prepare for future upgrades by recording versions of last client to open and decrypt":
(https://github.com/bitcoin/bitcoin/pull/32895#issuecomment-3049244656)
Concept ACK. It shouldn't hurt to add more metadata to help detect when there might be a mix of old data in a newer format and new data in an older format in the same wallet.
Conceptually, I think we could always detect these cases by just scanning the entire wallet for data that needs to be upgraded on loading. But having this extra metadata is nice because it can avoid slowing down wallet loading by avoiding unnecessary upgrade rescans.
On the approach in e94ef51837daa5ec9552eb14e8ccc38d
...
(https://github.com/bitcoin/bitcoin/pull/32895#issuecomment-3049244656)
Concept ACK. It shouldn't hurt to add more metadata to help detect when there might be a mix of old data in a newer format and new data in an older format in the same wallet.
Conceptually, I think we could always detect these cases by just scanning the entire wallet for data that needs to be upgraded on loading. But having this extra metadata is nice because it can avoid slowing down wallet loading by avoiding unnecessary upgrade rescans.
On the approach in e94ef51837daa5ec9552eb14e8ccc38d
...
π¬ maflcko commented on pull request "test: Turn rpcauth.py test into functional test":
(https://github.com/bitcoin/bitcoin/pull/32881#discussion_r2192745602)
yeah, right. Probably best to drop the unittest import here to make review easier. Did that, but a bit different from your suggestion.
(https://github.com/bitcoin/bitcoin/pull/32881#discussion_r2192745602)
yeah, right. Probably best to drop the unittest import here to make review easier. Did that, but a bit different from your suggestion.
π¬ maflcko commented on pull request "test: Turn rpcauth.py test into functional test":
(https://github.com/bitcoin/bitcoin/pull/32881#discussion_r2192745867)
heh, I didn't know. But I'll leave this as-is for now, because the logic is just moved. If this was changed, it could make sense to do it repo-wide for all `sys.path.insert` in a separate pull.
(https://github.com/bitcoin/bitcoin/pull/32881#discussion_r2192745867)
heh, I didn't know. But I'll leave this as-is for now, because the logic is just moved. If this was changed, it could make sense to do it repo-wide for all `sys.path.insert` in a separate pull.
π¬ maflcko commented on pull request "test: Turn rpcauth.py test into functional test":
(https://github.com/bitcoin/bitcoin/pull/32881#discussion_r2192746255)
leaving as-is for now, as this is move-only and the code could be changed independently in another pull, if there is need.
(https://github.com/bitcoin/bitcoin/pull/32881#discussion_r2192746255)
leaving as-is for now, as this is move-only and the code could be changed independently in another pull, if there is need.
π¬ maflcko commented on pull request "test: Turn rpcauth.py test into functional test":
(https://github.com/bitcoin/bitcoin/pull/32881#discussion_r2192748149)
`black` will change those back to `"`. However, to keep it move-only I've changed it back to `'`.
(https://github.com/bitcoin/bitcoin/pull/32881#discussion_r2192748149)
`black` will change those back to `"`. However, to keep it move-only I've changed it back to `'`.
π¬ maflcko commented on pull request "test: Turn rpcauth.py test into functional test":
(https://github.com/bitcoin/bitcoin/pull/32881#discussion_r2192748491)
thx, done
(https://github.com/bitcoin/bitcoin/pull/32881#discussion_r2192748491)
thx, done
π¬ maflcko commented on pull request "test: Turn rpcauth.py test into functional test":
(https://github.com/bitcoin/bitcoin/pull/32881#discussion_r2192748729)
I don't think it is. At least my IDE (vim) doesn't join it. Also, the diff is smaller without joining. Going to leave as-is.
(https://github.com/bitcoin/bitcoin/pull/32881#discussion_r2192748729)
I don't think it is. At least my IDE (vim) doesn't join it. Also, the diff is smaller without joining. Going to leave as-is.
π fanquake merged a pull request: "rest: replace `rf_names[0].rf` by `RESTResponseFormat::UNDEF`"
(https://github.com/bitcoin/bitcoin/pull/32884)
(https://github.com/bitcoin/bitcoin/pull/32884)
π¬ maflcko commented on pull request "test: use notarized v28.2 binaries and fix macOS detection":
(https://github.com/bitcoin/bitcoin/pull/32922#discussion_r2192765394)
I don't have an apple, but i had the impression that rosetta will just run the x86_64 executable on the arm64?
(https://github.com/bitcoin/bitcoin/pull/32922#discussion_r2192765394)
I don't have an apple, but i had the impression that rosetta will just run the x86_64 executable on the arm64?
π¬ Sjors commented on pull request "test: use notarized v28.2 binaries and fix macOS detection":
(https://github.com/bitcoin/bitcoin/pull/32922#discussion_r2192791070)
Let me try if that actually works...
(https://github.com/bitcoin/bitcoin/pull/32922#discussion_r2192791070)
Let me try if that actually works...
π¬ l0rinc commented on pull request "test: Turn rpcauth.py test into functional test":
(https://github.com/bitcoin/bitcoin/pull/32881#issuecomment-3049494057)
ACK fa4d68cf97b6d77dbb559facbc425376e2c51f62
(https://github.com/bitcoin/bitcoin/pull/32881#issuecomment-3049494057)
ACK fa4d68cf97b6d77dbb559facbc425376e2c51f62
π¬ Sjors commented on pull request "test: use notarized v28.2 binaries and fix macOS detection":
(https://github.com/bitcoin/bitcoin/pull/32922#discussion_r2192923546)
I switched to using `args.host`.
With the previous version:
```sh
cd depends
gmake HOST=x86_64-apple-darwin
cd ..
cmake -B build --toolchain /Users/sjors/dev/bitcoin-rosetta/depends/x86_64-apple-darwin/toolchain.cmake
cmake --build build
```
The result is as expected:
```sh
file -b build/bin/bitcoin
Mach-O 64-bit executable x86_64
```
Meanwhile if you just call `test/get_previous_releases.py`, it's going to download arm binaries:
```
test/get_previous_releases.py
fil
...
(https://github.com/bitcoin/bitcoin/pull/32922#discussion_r2192923546)
I switched to using `args.host`.
With the previous version:
```sh
cd depends
gmake HOST=x86_64-apple-darwin
cd ..
cmake -B build --toolchain /Users/sjors/dev/bitcoin-rosetta/depends/x86_64-apple-darwin/toolchain.cmake
cmake --build build
```
The result is as expected:
```sh
file -b build/bin/bitcoin
Mach-O 64-bit executable x86_64
```
Meanwhile if you just call `test/get_previous_releases.py`, it's going to download arm binaries:
```
test/get_previous_releases.py
fil
...
π¬ Sjors commented on pull request "test: use notarized v28.2 binaries and fix macOS detection":
(https://github.com/bitcoin/bitcoin/pull/32922#issuecomment-3049540718)
I switched to `args.host`, see https://github.com/bitcoin/bitcoin/pull/32922#discussion_r2192923546
Also documented that you can set `HOST`.
(https://github.com/bitcoin/bitcoin/pull/32922#issuecomment-3049540718)
I switched to `args.host`, see https://github.com/bitcoin/bitcoin/pull/32922#discussion_r2192923546
Also documented that you can set `HOST`.
π¬ maflcko commented on pull request "wallet: Allow read-only database access for info and dump commands":
(https://github.com/bitcoin/bitcoin/pull/32685#issuecomment-3049542385)
You'll have to rebase. Did you see the immediately previous comment? Also, ref https://github.com/bitcoin/bitcoin/pull/32818
(https://github.com/bitcoin/bitcoin/pull/32685#issuecomment-3049542385)
You'll have to rebase. Did you see the immediately previous comment? Also, ref https://github.com/bitcoin/bitcoin/pull/32818