💬 l0rinc commented on issue "bitcoind shouldn't fail to progress with synchronization: endless [leveldb] Generated table ... logs":
(https://github.com/bitcoin/bitcoin/issues/31882#issuecomment-2661499659)
> bitcoind finishes synchronization in an hour or so.
That alone would require a 1.5 Gbps download speed - and even then, we're not there yet (especially with such a resource-constrained setup).
But you could give [AssumeUTXO](https://bitcoinops.org/en/topics/assumeutxo) a try to see if it helps - this will jump the process ahead to 95% complete and validate the remaining blocks afterward.
> bitcoind doesn't progress with synchronization
The attached `iostats` and `debug.log` indicate that th
...
(https://github.com/bitcoin/bitcoin/issues/31882#issuecomment-2661499659)
> bitcoind finishes synchronization in an hour or so.
That alone would require a 1.5 Gbps download speed - and even then, we're not there yet (especially with such a resource-constrained setup).
But you could give [AssumeUTXO](https://bitcoinops.org/en/topics/assumeutxo) a try to see if it helps - this will jump the process ahead to 95% complete and validate the remaining blocks afterward.
> bitcoind doesn't progress with synchronization
The attached `iostats` and `debug.log` indicate that th
...
📝 hebasto opened a pull request: "cmake: Make implicit `libbitcoinkernel` dependencies explicit"
(https://github.com/bitcoin/bitcoin/pull/31884)
This PR fixes two regressions introduced in https://github.com/bitcoin/bitcoin/pull/30911.
For example, on the master branch @ db36a92c02b83f2e6477a5a55fc061319f7cc6a3:
- first regression:
```
$ cmake -B build -G "Ninja" -DBUILD_UTIL_CHAINSTATE=ON -DBUILD_SHARED_LIBS=OFF -DCMAKE_INSTALL_PREFIX=/home/hebasto/INSTALL
$ cmake --build build -j $(nproc) -t bitcoinkernel
$ cmake --install build --component bitcoinkernel
- Install configuration: "RelWithDebInfo"
CMake Error at build/src/kerne
...
(https://github.com/bitcoin/bitcoin/pull/31884)
This PR fixes two regressions introduced in https://github.com/bitcoin/bitcoin/pull/30911.
For example, on the master branch @ db36a92c02b83f2e6477a5a55fc061319f7cc6a3:
- first regression:
```
$ cmake -B build -G "Ninja" -DBUILD_UTIL_CHAINSTATE=ON -DBUILD_SHARED_LIBS=OFF -DCMAKE_INSTALL_PREFIX=/home/hebasto/INSTALL
$ cmake --build build -j $(nproc) -t bitcoinkernel
$ cmake --install build --component bitcoinkernel
- Install configuration: "RelWithDebInfo"
CMake Error at build/src/kerne
...
💬 l0rinc commented on pull request "util: detect and warn when using exFAT on MacOS":
(https://github.com/bitcoin/bitcoin/pull/31453#discussion_r1957361090)
Even when there isn't any corruption, maybe it would help to warn when [SD cards are used for storage](https://github.com/bitcoin/bitcoin/issues/31882#issuecomment-2661499659)
(https://github.com/bitcoin/bitcoin/pull/31453#discussion_r1957361090)
Even when there isn't any corruption, maybe it would help to warn when [SD cards are used for storage](https://github.com/bitcoin/bitcoin/issues/31882#issuecomment-2661499659)
💬 GregTonoski commented on issue "bitcoind shouldn't fail to progress with synchronization: endless [leveldb] Generated table ... logs":
(https://github.com/bitcoin/bitcoin/issues/31882#issuecomment-2661517113)
> That alone would require a 1.5 Gbps download speed - and even then, we're not there yet (especially with such a resource-constrained setup).
Disagree with the 1.5 Gbps download speed requirement. There isn't initial block download scenario here. There are 4 months of blocks data that need to be downloaded here.
(https://github.com/bitcoin/bitcoin/issues/31882#issuecomment-2661517113)
> That alone would require a 1.5 Gbps download speed - and even then, we're not there yet (especially with such a resource-constrained setup).
Disagree with the 1.5 Gbps download speed requirement. There isn't initial block download scenario here. There are 4 months of blocks data that need to be downloaded here.
👍 TheCharlatan approved a pull request: "cmake: Add `libbitcoinkernel` target"
(https://github.com/bitcoin/bitcoin/pull/31869#pullrequestreview-2619681387)
ACK 3a914ab96bdeb70cdf848dd74deda5a80d0a7f78
(https://github.com/bitcoin/bitcoin/pull/31869#pullrequestreview-2619681387)
ACK 3a914ab96bdeb70cdf848dd74deda5a80d0a7f78
💬 tnndbtc commented on issue "Fuzz: Runtime errors when running fuzz tests on MacOs":
(https://github.com/bitcoin/bitcoin/issues/31591#issuecomment-2661542109)
@Prabhat1308 I don't have an answer to fix the incompatibility issue between the native llvm@16 and the customized llvm@18. However, from the error message itself, it looks like the cause is the discrepancy between llvm@16 and llvm@18.
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /opt/homebrew/opt/llvm@18/bin/../include/c++/v1/variant:495:12
/Users/prabhatverma/projects/bitcoin/src/rpc/server.h:100:15: runtime error: call to function getblockchaininfo() through pointer to incorrec
...
(https://github.com/bitcoin/bitcoin/issues/31591#issuecomment-2661542109)
@Prabhat1308 I don't have an answer to fix the incompatibility issue between the native llvm@16 and the customized llvm@18. However, from the error message itself, it looks like the cause is the discrepancy between llvm@16 and llvm@18.
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /opt/homebrew/opt/llvm@18/bin/../include/c++/v1/variant:495:12
/Users/prabhatverma/projects/bitcoin/src/rpc/server.h:100:15: runtime error: call to function getblockchaininfo() through pointer to incorrec
...
🤔 hebasto reviewed a pull request: "multiprocess: Add libmultiprocess git subtree"
(https://github.com/bitcoin/bitcoin/pull/31741#pullrequestreview-2619682385)
96d3b2a0bb0c267569162b055ca306f709ec0b4e "cmake: Fix fuzzer "multiple definition of `main'" errors"
cc @dergoegge
(https://github.com/bitcoin/bitcoin/pull/31741#pullrequestreview-2619682385)
96d3b2a0bb0c267569162b055ca306f709ec0b4e "cmake: Fix fuzzer "multiple definition of `main'" errors"
cc @dergoegge
💬 tnndbtc commented on issue "Fuzz: Runtime errors when running fuzz tests on MacOs":
(https://github.com/bitcoin/bitcoin/issues/31591#issuecomment-2661545962)
Also, from llvm@18, /opt/homebrew/opt/llvm@18/bin/../include/c++/v1/variant:495
struct __base {
template <class _Visitor, class... _Vs>
_LIBCPP_HIDE_FROM_ABI static constexpr decltype(auto)
__visit_alt_at(size_t __index, _Visitor&& __visitor, _Vs&&... __vs) {
constexpr auto __fdiagonal = __make_fdiagonal<_Visitor&&, decltype(std::forward<_Vs>(__vs).__as_base())...>();
return __fdiagonal[__index](**_std_**::forward<_Visitor>(__visitor), std::forward<_Vs>(__vs).__as_base()...);
}
...
(https://github.com/bitcoin/bitcoin/issues/31591#issuecomment-2661545962)
Also, from llvm@18, /opt/homebrew/opt/llvm@18/bin/../include/c++/v1/variant:495
struct __base {
template <class _Visitor, class... _Vs>
_LIBCPP_HIDE_FROM_ABI static constexpr decltype(auto)
__visit_alt_at(size_t __index, _Visitor&& __visitor, _Vs&&... __vs) {
constexpr auto __fdiagonal = __make_fdiagonal<_Visitor&&, decltype(std::forward<_Vs>(__vs).__as_base())...>();
return __fdiagonal[__index](**_std_**::forward<_Visitor>(__visitor), std::forward<_Vs>(__vs).__as_base()...);
}
...
📝 mabu44 opened a pull request: "test: chain reorg for coinstatsindex"
(https://github.com/bitcoin/bitcoin/pull/31885)
Improved coverage of src/index/coinstatsindex.cpp with a new unit test that simulate a reorg of the chain (one block deep).
(https://github.com/bitcoin/bitcoin/pull/31885)
Improved coverage of src/index/coinstatsindex.cpp with a new unit test that simulate a reorg of the chain (one block deep).
📝 jonatack opened a pull request: "cli: return local services in -netinfo"
(https://github.com/bitcoin/bitcoin/pull/31886)
Add local services info to -netinfo dashboard that already provides this info for each of the peer connections
default report with `bitcoin-cli -netinfo`
```
Bitcoin Core client v28.99.0 - server 70016/Satoshi:28.99.0/
ipv4 ipv6 onion i2p cjdns total block manual
in 0 0 12 8 0 20
out 6 0 4 3 2 15 3 4
total 6 0 16 11 2 35
Local services: n
...
(https://github.com/bitcoin/bitcoin/pull/31886)
Add local services info to -netinfo dashboard that already provides this info for each of the peer connections
default report with `bitcoin-cli -netinfo`
```
Bitcoin Core client v28.99.0 - server 70016/Satoshi:28.99.0/
ipv4 ipv6 onion i2p cjdns total block manual
in 0 0 12 8 0 20
out 6 0 4 3 2 15 3 4
total 6 0 16 11 2 35
Local services: n
...
💬 hebasto commented on pull request "guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries":
(https://github.com/bitcoin/bitcoin/pull/31407#issuecomment-2661571168)
> macOS intel is happy too, no more right-clickery.
`bitcoind` as well?
Files downloaded via Safari seem to inevitably receive the `com.apple.quarantine` attribute. This is easily resolved for GUI applications but can be challenging for CLI tools.
(https://github.com/bitcoin/bitcoin/pull/31407#issuecomment-2661571168)
> macOS intel is happy too, no more right-clickery.
`bitcoind` as well?
Files downloaded via Safari seem to inevitably receive the `com.apple.quarantine` attribute. This is easily resolved for GUI applications but can be challenging for CLI tools.
📝 jonatack opened a pull request: "refactor: CLI cleanups"
(https://github.com/bitcoin/bitcoin/pull/31887)
These are simple and have been accumulating over the past few years.
Each is described in its commit message.
(https://github.com/bitcoin/bitcoin/pull/31887)
These are simple and have been accumulating over the past few years.
Each is described in its commit message.
💬 purpleKarrot commented on pull request "cmake: add optional source files to bitcoin_crypto and crc32c directly":
(https://github.com/bitcoin/bitcoin/pull/31268#issuecomment-2661591125)
> Agree with @hebasto that it'd be more straightforward to use `target_compile_options()`, if only for the sake of avoiding future footguns.
Very generally in software development, future footguns are avoided by **narrow contracts**.
I understand the desire of narrowing the contract between the authors and CMake. One may want to avoid advanced features like setting properties on individual source files. Applying this approach consistently, one should also avoid commands like `target_compil
...
(https://github.com/bitcoin/bitcoin/pull/31268#issuecomment-2661591125)
> Agree with @hebasto that it'd be more straightforward to use `target_compile_options()`, if only for the sake of avoiding future footguns.
Very generally in software development, future footguns are avoided by **narrow contracts**.
I understand the desire of narrowing the contract between the authors and CMake. One may want to avoid advanced features like setting properties on individual source files. Applying this approach consistently, one should also avoid commands like `target_compil
...
💬 purpleKarrot commented on pull request "cmake: Add optional source files to libraries directly":
(https://github.com/bitcoin/bitcoin/pull/31880#issuecomment-2661608489)
Concept NACK.
I am not a big fan of simple utility functions that group a small set of builtin cmake commands. I think they increase the cognitive load and impede knowledge transfer from one cmake project to another. (I remember a time when builtin functions like `add_library` had to be wrapped and I authored many such wrappers, because there was no way of propagating interface requirements from one target to another. Those times are thankfully over since CMake version 3.0).
(https://github.com/bitcoin/bitcoin/pull/31880#issuecomment-2661608489)
Concept NACK.
I am not a big fan of simple utility functions that group a small set of builtin cmake commands. I think they increase the cognitive load and impede knowledge transfer from one cmake project to another. (I remember a time when builtin functions like `add_library` had to be wrapped and I authored many such wrappers, because there was no way of propagating interface requirements from one target to another. Those times are thankfully over since CMake version 3.0).
💬 purpleKarrot commented on pull request "cmake: Add `libbitcoinkernel` target":
(https://github.com/bitcoin/bitcoin/pull/31869#discussion_r1957411682)
Synonyms can be created like this
```cmake
add_library(libbitcoinkernel ALIAS bitcoinkernel)
```
By the way, you can increase robustness by adding a namespace to the alias target:
```cmake
add_library(Bitcoin::Kernel ALIAS bitcoinkernel)
```
This is more robust against typos. Linking against `Bitcorn::Kernel` will result in a "no such target defined" error at configure time, while linking against `bitcornkernel` will simply result in `-lbitcornkernel` being passed to the linker.
(https://github.com/bitcoin/bitcoin/pull/31869#discussion_r1957411682)
Synonyms can be created like this
```cmake
add_library(libbitcoinkernel ALIAS bitcoinkernel)
```
By the way, you can increase robustness by adding a namespace to the alias target:
```cmake
add_library(Bitcoin::Kernel ALIAS bitcoinkernel)
```
This is more robust against typos. Linking against `Bitcorn::Kernel` will result in a "no such target defined" error at configure time, while linking against `bitcornkernel` will simply result in `-lbitcornkernel` being passed to the linker.
💬 fjahr commented on pull request "test: chain reorg for coinstatsindex":
(https://github.com/bitcoin/bitcoin/pull/31885#issuecomment-2661631392)
Hm, we have a reorg test for coinstatsindex in the functional tests: https://github.com/bitcoin/bitcoin/blob/master/test/functional/feature_coinstatsindex.py#L258 Can you give additional context why you think this improves coverage or other motivation to add a unit test for this?
(https://github.com/bitcoin/bitcoin/pull/31885#issuecomment-2661631392)
Hm, we have a reorg test for coinstatsindex in the functional tests: https://github.com/bitcoin/bitcoin/blob/master/test/functional/feature_coinstatsindex.py#L258 Can you give additional context why you think this improves coverage or other motivation to add a unit test for this?
💬 hebasto commented on pull request "cmake: Add `libbitcoinkernel` target":
(https://github.com/bitcoin/bitcoin/pull/31869#discussion_r1957421498)
> Synonyms can be created like this
>
> ```cmake
> add_library(libbitcoinkernel ALIAS bitcoinkernel)
> ```
Indeed, that was my starting point. However, an `ALIAS` library cannot be built:
```
$ cmake -B build -G "Unix Makefiles" -DBUILD_KERNEL_LIB=ON
$ cmake --build build -t libbitcoinkernel
gmake: *** No rule to make target 'libbitcoinkernel'. Stop.
```
or
```
$ cmake -B build -G "Ninja" -DBUILD_KERNEL_LIB=ON
$ cmake --build build -t libbitcoinkernel
ninja: error: unknown tar
...
(https://github.com/bitcoin/bitcoin/pull/31869#discussion_r1957421498)
> Synonyms can be created like this
>
> ```cmake
> add_library(libbitcoinkernel ALIAS bitcoinkernel)
> ```
Indeed, that was my starting point. However, an `ALIAS` library cannot be built:
```
$ cmake -B build -G "Unix Makefiles" -DBUILD_KERNEL_LIB=ON
$ cmake --build build -t libbitcoinkernel
gmake: *** No rule to make target 'libbitcoinkernel'. Stop.
```
or
```
$ cmake -B build -G "Ninja" -DBUILD_KERNEL_LIB=ON
$ cmake --build build -t libbitcoinkernel
ninja: error: unknown tar
...
📝 midnightmagic opened a pull request: "correct wrong assumptions in the contrib linearize data script"
(https://github.com/bitcoin/bitcoin/pull/31888)
The linearize-data contrib script does not quite work correctly in the case of a chain reorg, and it fully-truncates files with an incorrect open mode.
This small patch clips off incorrect trailing data and corrects file open mode type.
(small patch being passed around which I did not write but thought would be helpful to the community)
(https://github.com/bitcoin/bitcoin/pull/31888)
The linearize-data contrib script does not quite work correctly in the case of a chain reorg, and it fully-truncates files with an incorrect open mode.
This small patch clips off incorrect trailing data and corrects file open mode type.
(small patch being passed around which I did not write but thought would be helpful to the community)
💬 walterl commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r1957466889)
Isn't this supposed to return `kernel_UNKNOWN_NEW_RULES_ACTIVATED`?
```suggestion
return kernel_Warning::kernel_UNKNOWN_NEW_RULES_ACTIVATED;
```
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r1957466889)
Isn't this supposed to return `kernel_UNKNOWN_NEW_RULES_ACTIVATED`?
```suggestion
return kernel_Warning::kernel_UNKNOWN_NEW_RULES_ACTIVATED;
```
💬 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-2662213412)
Tar archives, to test `bitcoind` (too large for Github):
- [bitcoin-096525e92cc2-arm64-apple-darwin.tar.gz](https://download.sprovoost.nl/download.php?id=13&token=8de04067101d0748ccba9cb0e5c568cb)
- [bitcoin-096525e92cc2-x86_64-apple-darwin.tar.gz](https://download.sprovoost.nl/download.php?id=14&token=2dd77c4ec797fb3c39c207e50cbd65d3)
(https://github.com/bitcoin/bitcoin/pull/31407#issuecomment-2662213412)
Tar archives, to test `bitcoind` (too large for Github):
- [bitcoin-096525e92cc2-arm64-apple-darwin.tar.gz](https://download.sprovoost.nl/download.php?id=13&token=8de04067101d0748ccba9cb0e5c568cb)
- [bitcoin-096525e92cc2-x86_64-apple-darwin.tar.gz](https://download.sprovoost.nl/download.php?id=14&token=2dd77c4ec797fb3c39c207e50cbd65d3)