💬 fanquake commented on pull request "build: use macOS 14 SDK (Xcode 15.0)":
(https://github.com/bitcoin/bitcoin/pull/28622#issuecomment-1806860428)
Yea, anyone that wants to test should create the new SDK, check the new shasum, and then do a Guix build. If that works, the CI will.

💬 fjahr commented on pull request "test: Avoid intermittent failures in feature_init":
(https://github.com/bitcoin/bitcoin/pull/28831#issuecomment-1806862003)
> I haven't looked into this deeper yet but my best guess would be that ldb doesn't care about this last, big file and doesn't check it?

No, that's not it, otherwise the hardcoded test wouldn't fail. If we don't understand what leveldb is doing then I guess we should probably remove perturbing its files altogether.

💬 maflcko commented on pull request "test: Avoid intermittent failures in feature_init":
(https://github.com/bitcoin/bitcoin/pull/28831#issuecomment-1806862608)
> If we don't understand what leveldb is doing then I guess we should probably remove perturbing its files altogether.

sgtm, for a follow-up or alternative pull. The goal of this pull is not to change any test, but only to restore the previous code, which didn't intermittently fail.

💬 fanquake commented on pull request "build: Patch Qt to handle minimum macOS version properly":
(https://github.com/bitcoin/bitcoin/pull/28851#issuecomment-1806863219)
Guix build (aarch64):
```bash
d832f85daf44833b8bdb8fbf3947e0c6e7a1364cf33991e8f5c32a68e3321c3b guix-build-05aca093819b/output/arm64-apple-darwin/SHA256SUMS.part
6c163bfdb697ff4821e87645ad62bd1588c862cad07ec4ae901835e2368aba69 guix-build-05aca093819b/output/arm64-apple-darwin/bitcoin-05aca093819b-arm64-apple-darwin-unsigned.tar.gz
bc73c31b3b45588264685ee98449e8cb6eff8885b5cb696d782dbb95f1608ce6 guix-build-05aca093819b/output/arm64-apple-darwin/bitcoin-05aca093819b-arm64-apple-darwin-unsign
...

💬 fjahr commented on pull request "test: Avoid intermittent failures in feature_init":
(https://github.com/bitcoin/bitcoin/pull/28831#issuecomment-1806863721)
ACK 44445ae8f1123c3affdcc0dbd7b3830eff5548ef

👋 pablomartin4btc's pull request is ready for review: "script, assumeutxo: Enhance validations in utxo_snapshot.sh"
(https://github.com/bitcoin/bitcoin/pull/28852)

💬 fanquake commented on pull request "build: use macOS 14 SDK (Xcode 15.0)":
(https://github.com/bitcoin/bitcoin/pull/28622#issuecomment-1806868093)
Looks like we'll have to add a `-Wl,-platform_version` into ldflags here.

💬 hebasto commented on pull request "build: Patch Qt to handle minimum macOS version properly":
(https://github.com/bitcoin/bitcoin/pull/28851#issuecomment-1806877028)
My Guix builds:
```
x86_64
ad9dbeabb7fca2c4efa4057b3aee139c4325b6f5fb77c1ee10fe18940491b446 guix-build-05aca093819b/output/aarch64-linux-gnu/SHA256SUMS.part
afddca8689f4d21a08e448dd59ad4fa5329437f4042dd0d1cfc2d2cdc7d59b5f guix-build-05aca093819b/output/aarch64-linux-gnu/bitcoin-05aca093819b-aarch64-linux-gnu-debug.tar.gz
9ea86d3294960c4c442f30259d3c1b17a105902b22d20f874cabeb01bd6bf995 guix-build-05aca093819b/output/aarch64-linux-gnu/bitcoin-05aca093819b-aarch64-linux-gnu.tar.gz
ee100a86
...

💬 lasermind commented on issue "Blockchain fully synced, but `bitcoin-cli -getinfo` shows `verification progress: 99.9999%`":
(https://github.com/bitcoin/bitcoin/issues/28847#issuecomment-1806880832)
Ok, now this is exactly what I'm talking about: **on average** a new block is mined every 10 minutes. This is the fundamental assumption, isn't it? So it does not make much sense to arbitrarily decrease this "guessed value" **earlier** than 10 minutes.

At least for the first 10 minutes, it could stay at `100.0000%`.

That's basically all I'm saying here.

💬 sipa commented on issue "Blockchain fully synced, but `bitcoin-cli -getinfo` shows `verification progress: 99.9999%`":
(https://github.com/bitcoin/bitcoin/issues/28847#issuecomment-1806882339)
63% of blocks take less than 10 minutes, and the shorter the interval, the more likely it is (39% takes less than 5 minutes, for example, and 9% takes less than 1 minute). There is nothing special about the value 10 minutes except that's the average internal when averaged over many blocks.

💬 hebasto commented on pull request "contrib: drop GCC MAX_VERSION to 4.3.0 in symbol-check":
(https://github.com/bitcoin/bitcoin/pull/28844#issuecomment-1806900255)
> Reflect the actual symbols used, i.e:
>
> ```shell
> bitcoind: symbol __bswapsi2 from unsupported version GCC_4.3.0(7)
> ```

Is it happening for Guix builds?

💬 fanquake commented on pull request "contrib: drop GCC MAX_VERSION to 4.3.0 in symbol-check":
(https://github.com/bitcoin/bitcoin/pull/28844#issuecomment-1806900818)
> Is it happening for Guix builds?

Yes.

⚠️ solidearthlabs opened an issue: "configure error: cannot find input file: `Makefile.in'"
(https://github.com/bitcoin/bitcoin/issues/28853)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

When I run:
`/configure --with-incompatible-bdb`

I get the following error message:
```
configure: creating ./config.status
config.status: creating libbitcoinconsensus.pc
config.status: error: cannot find input file: `Makefile.in'

```

I've tried with v22.0, v25.1 and the latest master.

### Expected behaviour

Should finish without error

### Steps to reproduce

./configure -
...

💬 solidearthlabs commented on issue "configure error: cannot find input file: `Makefile.in'":
(https://github.com/bitcoin/bitcoin/issues/28853#issuecomment-1806913513)
When I copy the src/Makefile.in into the repository head directory it gets past this step

💬 solidearthlabs commented on issue "configure error: cannot find input file: `Makefile.in'":
(https://github.com/bitcoin/bitcoin/issues/28853#issuecomment-1806915092)
After rerunning `./autogen.sh` I no longer get this issue when running configure

✅ solidearthlabs closed an issue: "configure error: cannot find input file: `Makefile.in'"
(https://github.com/bitcoin/bitcoin/issues/28853)

💬 ajtowns commented on pull request "[refactor] Remove BlockAssembler m_mempool member":
(https://github.com/bitcoin/bitcoin/pull/28843#discussion_r1390312985)
I could see that being an argument for doing away with `BlockAssembler` entirely (at least as a public interface), and replacing `BlockAssembler(chainstate, mempool, options).CreateNewBlock(scriptPubKeyIn)` it with a function: `CreateNewBlock(chainstate, mempool, scriptPubKeyIn, options)` (effectively reverting #7598).

But if you're keeping `BlockAssembler` around, the entire point of that class is to assemble a block with txs from the mempool -- that's why most of its private functions requi
...

💬 ishaanam commented on issue "wallet coin selection: don't mixup coins with absolute timelocks of different types":
(https://github.com/bitcoin/bitcoin/issues/27526#issuecomment-1806999303)
I have started working on fixing this issue and have a solution that seems like it works. I should have a draft PR open soon. The solution involves using `TreeEval` to determine the time locks of a given script, and making sure that coins with absolute timelocks of different types are not mixed using `CoinEligibilityFilter`s.

💬 Mikey4010 commented on issue "Running out of disk space can leave bitcoin in a desynced state":
(https://github.com/bitcoin/bitcoin/issues/26112#issuecomment-1807096155)
61a6c3b0e9a8dab5c5f845af4becde817539133c

📝 hebasto opened a pull request: "depends: Build `capnp` with CMake"
(https://github.com/bitcoin/bitcoin/pull/28856)
This change fixes the `x86_64-w64-mingw32` build (see https://github.com/bitcoin/bitcoin/pull/28735#issuecomment-1790406668) and simplifies the configuration file.