💬 maflcko commented on pull request "test: Fix test by checking the actual exception instance":
(https://github.com/bitcoin/bitcoin/pull/28989#issuecomment-1837981733)
lgtm ACK 55e3dc3e03510e97caba1547a82e3e022b0bbd42
(https://github.com/bitcoin/bitcoin/pull/28989#issuecomment-1837981733)
lgtm ACK 55e3dc3e03510e97caba1547a82e3e022b0bbd42
📝 maflcko opened a pull request: "ci: Use Ubuntu 24.04 Noble for tsan,tidy,fuzz"
(https://github.com/bitcoin/bitcoin/pull/28992)
23.10 will be EOL mid next year, so a bump is needed before then for the `master` branch (and possibly the `26.x` branch).
Doing the bump now is fine, because the clang version is pinned to 17 inside the CI tasks. So a default clang version change in the system image should not affect the tasks. Once clang-18 is available and the default in April next year (https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649#planned-and-potentially-disruptive-archive-wide-activities-2), the pin
...
(https://github.com/bitcoin/bitcoin/pull/28992)
23.10 will be EOL mid next year, so a bump is needed before then for the `master` branch (and possibly the `26.x` branch).
Doing the bump now is fine, because the clang version is pinned to 17 inside the CI tasks. So a default clang version change in the system image should not affect the tasks. Once clang-18 is available and the default in April next year (https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649#planned-and-potentially-disruptive-archive-wide-activities-2), the pin
...
💬 naumenkogs commented on pull request "p2p: Fill reconciliation sets (Erlay)":
(https://github.com/bitcoin/bitcoin/pull/28765#issuecomment-1838126153)
Addressed all comments. Ready for review.
(https://github.com/bitcoin/bitcoin/pull/28765#issuecomment-1838126153)
Addressed all comments. Ready for review.
💬 maflcko commented on issue "p2p_filter intermittent failure (assert not filter_peer.tx_received)":
(https://github.com/bitcoin/bitcoin/issues/25128#issuecomment-1838244265)
Locally: https://drahtbot.space/temp_scratch/p2p_filter_2.tar.xz
(https://github.com/bitcoin/bitcoin/issues/25128#issuecomment-1838244265)
Locally: https://drahtbot.space/temp_scratch/p2p_filter_2.tar.xz
💬 fanquake commented on issue "getrawtransaction xxxxxx.... 2 causes a segfault":
(https://github.com/bitcoin/bitcoin/issues/28986#issuecomment-1838271681)
> configurations commands for the build shown above are incorrect, should be....
Note that you are passing options to configure that will have no effect.
`--enable-glibc-back-compat` no-longer exists, and will do nothing.
`--enable-cxx` is not one of our configure options, so will also do nothing (might have been copy-pasted from a BDB configure?).
I would suggest switching `--prefix=xxx` for `CONFIG_SITE=xxx ./configure your-other-options`.
> CPPFLAGS="-fPIC -O2 --param ggc-min-expand=
...
(https://github.com/bitcoin/bitcoin/issues/28986#issuecomment-1838271681)
> configurations commands for the build shown above are incorrect, should be....
Note that you are passing options to configure that will have no effect.
`--enable-glibc-back-compat` no-longer exists, and will do nothing.
`--enable-cxx` is not one of our configure options, so will also do nothing (might have been copy-pasted from a BDB configure?).
I would suggest switching `--prefix=xxx` for `CONFIG_SITE=xxx ./configure your-other-options`.
> CPPFLAGS="-fPIC -O2 --param ggc-min-expand=
...
💬 maflcko commented on issue "p2p_filter intermittent failure (assert not filter_peer.tx_received)":
(https://github.com/bitcoin/bitcoin/issues/25128#issuecomment-1838273450)
> However, from the log it looks like the p2p_lock was intermittently released in the on_message function??
>
> ```
> test 2022-12-30T09:33:48.464000Z TestFramework (INFO): Check that request for filtered blocks is ignored if no filter is set
> test 2022-12-30T09:33:48.288000Z TestFramework.p2p (DEBUG): Received message from 127.0.0.1:12488: msg_tx(tx=CTransaction(nVersion=2 vin=[CTxIn(prevout=COutPoint(hash=17576cfafe2ea026d9ab00f6082fe7cc81caf31f5060a1872693f5bf73bf6b11 n=0) scriptSi
...
(https://github.com/bitcoin/bitcoin/issues/25128#issuecomment-1838273450)
> However, from the log it looks like the p2p_lock was intermittently released in the on_message function??
>
> ```
> test 2022-12-30T09:33:48.464000Z TestFramework (INFO): Check that request for filtered blocks is ignored if no filter is set
> test 2022-12-30T09:33:48.288000Z TestFramework.p2p (DEBUG): Received message from 127.0.0.1:12488: msg_tx(tx=CTransaction(nVersion=2 vin=[CTxIn(prevout=COutPoint(hash=17576cfafe2ea026d9ab00f6082fe7cc81caf31f5060a1872693f5bf73bf6b11 n=0) scriptSi
...
🚀 fanquake merged a pull request: "[26.0] Finalize or rc4"
(https://github.com/bitcoin/bitcoin/pull/28959)
(https://github.com/bitcoin/bitcoin/pull/28959)
✅ fanquake closed an issue: "26.0 RC Testing Guide Feedback"
(https://github.com/bitcoin/bitcoin/issues/28866)
(https://github.com/bitcoin/bitcoin/issues/28866)
💬 fanquake commented on issue "26.0 RC Testing Guide Feedback":
(https://github.com/bitcoin/bitcoin/issues/28866#issuecomment-1838330241)
v26.0 has been tagged. Closing this issue.
(https://github.com/bitcoin/bitcoin/issues/28866#issuecomment-1838330241)
v26.0 has been tagged. Closing this issue.
✅ fanquake closed an issue: "v26.0 Testing"
(https://github.com/bitcoin/bitcoin/issues/28718)
(https://github.com/bitcoin/bitcoin/issues/28718)
💬 fanquake commented on issue "v26.0 Testing":
(https://github.com/bitcoin/bitcoin/issues/28718#issuecomment-1838331821)
v26.0 has been tagged. Closing this issue.
(https://github.com/bitcoin/bitcoin/issues/28718#issuecomment-1838331821)
v26.0 has been tagged. Closing this issue.
💬 fanquake commented on issue "Release schedule for 26.0":
(https://github.com/bitcoin/bitcoin/issues/27758#issuecomment-1838337143)
https://github.com/bitcoin/bitcoin/releases/tag/v26.0 has now been tagged.
(https://github.com/bitcoin/bitcoin/issues/27758#issuecomment-1838337143)
https://github.com/bitcoin/bitcoin/releases/tag/v26.0 has now been tagged.
💬 maflcko commented on issue "fuzz, coinselection: Assertion 'result_bnb->GetChange(coin_params.m_cost_of_change, CAmount{0}) == 0' failed":
(https://github.com/bitcoin/bitcoin/issues/28918#issuecomment-1838382894)
Removed from the 26.0 milestone. https://github.com/bitcoin/bitcoin/pull/28985 looks a bit large to backport, so I guess the fuzz target will be disabled on 26.x and the issue remains?
(https://github.com/bitcoin/bitcoin/issues/28918#issuecomment-1838382894)
Removed from the 26.0 milestone. https://github.com/bitcoin/bitcoin/pull/28985 looks a bit large to backport, so I guess the fuzz target will be disabled on 26.x and the issue remains?
💬 hebasto commented on pull request "depends: Build the `native_capnp` and `capnp` packages with CMake":
(https://github.com/bitcoin/bitcoin/pull/28856#issuecomment-1838426302)
> Also seems fine if you don't want to cherrypick it here, since it's not directly related to this PR and might make it more confusing. I'm happy to open a new PR or review one if it doesn't get cherrypicked.
@ryanofsky
Please do. Thank you.
(https://github.com/bitcoin/bitcoin/pull/28856#issuecomment-1838426302)
> Also seems fine if you don't want to cherrypick it here, since it's not directly related to this PR and might make it more confusing. I'm happy to open a new PR or review one if it doesn't get cherrypicked.
@ryanofsky
Please do. Thank you.
💬 fanquake commented on pull request "depends: Build the `native_capnp` and `capnp` packages with CMake":
(https://github.com/bitcoin/bitcoin/pull/28856#issuecomment-1838429144)
I'll just reopen my PR then. Not sure we need a third PR, for what is a really straightforward bugfix.
(https://github.com/bitcoin/bitcoin/pull/28856#issuecomment-1838429144)
I'll just reopen my PR then. Not sure we need a third PR, for what is a really straightforward bugfix.
📝 fanquake reopened a pull request: "depends: fix libmultiprocess build on aarch64"
(https://github.com/bitcoin/bitcoin/pull/28846)
Two changes to improve the libmultiprocess build on aarch64.
First, is to always install libmultiprocess into `lib/`. On some systems (my Fedora aarch64 box), libmultiprocess was being installed into `lib64/`, and then configure would fail to pick it up, because we only add `lib/` to pkgconfig/ldflags out of depends. Rather than adding lib64 to those, I opted for installing libmultiprocess into lib, with every other dependency we build.
Second, is to build with position independant code. T
...
(https://github.com/bitcoin/bitcoin/pull/28846)
Two changes to improve the libmultiprocess build on aarch64.
First, is to always install libmultiprocess into `lib/`. On some systems (my Fedora aarch64 box), libmultiprocess was being installed into `lib64/`, and then configure would fail to pick it up, because we only add `lib/` to pkgconfig/ldflags out of depends. Rather than adding lib64 to those, I opted for installing libmultiprocess into lib, with every other dependency we build.
Second, is to build with position independant code. T
...
💬 dergoegge commented on pull request "Nuke adjusted time (attempt 2)":
(https://github.com/bitcoin/bitcoin/pull/28956#discussion_r1413770472)
The idea is that `m_index` is always set to the next index in `m_offsets` that gets written to (so a value out of `[0, N)`) and we just assume that the initial N samples were 0, which is why the median is immediately computed out of N.
I could change it to always increase `m_index` instead and add new offsets by doing `m_offsets[m_index % N] = new_offset`, in which case your suggestion would allow us to compute the median more "accurately" while we haven't seen N samples yet. I'm not sure tho
...
(https://github.com/bitcoin/bitcoin/pull/28956#discussion_r1413770472)
The idea is that `m_index` is always set to the next index in `m_offsets` that gets written to (so a value out of `[0, N)`) and we just assume that the initial N samples were 0, which is why the median is immediately computed out of N.
I could change it to always increase `m_index` instead and add new offsets by doing `m_offsets[m_index % N] = new_offset`, in which case your suggestion would allow us to compute the median more "accurately" while we haven't seen N samples yet. I'm not sure tho
...
💬 dergoegge commented on pull request "Nuke adjusted time (attempt 2)":
(https://github.com/bitcoin/bitcoin/pull/28956#discussion_r1413773031)
Hm yea I guess... I could also just remove support for odd `N`s from this class.
(https://github.com/bitcoin/bitcoin/pull/28956#discussion_r1413773031)
Hm yea I guess... I could also just remove support for odd `N`s from this class.
💬 Sjors commented on pull request "Move log messages: tx enqueue to mempool, allocation to blockstorage":
(https://github.com/bitcoin/bitcoin/pull/27277#issuecomment-1838518274)
Rebased after #28368.
(https://github.com/bitcoin/bitcoin/pull/27277#issuecomment-1838518274)
Rebased after #28368.
💬 martinus commented on pull request "Don't empty dbcache on prune flushes: >30% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1413803359)
The m_flags member here causes padding, when you move the member down above/below `flags` you should be able to save 8 bytes from the struct, then you can cache a bit more
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1413803359)
The m_flags member here causes padding, when you move the member down above/below `flags` you should be able to save 8 bytes from the struct, then you can cache a bit more