💬 hebasto commented on issue "Bitcoin Core "not opened" after software update to macOS Sequoia 15.0.1 (24A348)":
(https://github.com/bitcoin/bitcoin/issues/31069#issuecomment-2406917157)
@diivvy

Before taking any further action, ensure that your wallet file(s) are properly backed up. If you were using the default settings, they reside in the [data directory](https://github.com/bitcoin/bitcoin/blob/master/doc/files.md#data-directory-location).

💬 maflcko commented on pull request "Fix typos in check-deps.sh":
(https://github.com/bitcoin/bitcoin/pull/31070#issuecomment-2406919296)
lgtm ACK da8824ba301c783fe9b600df8521fe1beb65f1f2

Please add `contrib: ` prefix to the pull title.

⚠️ maflcko opened an issue: "ci: Replace wine tests with real tests on Windows?"
(https://github.com/bitcoin/bitcoin/issues/31071)
The Wine tests are annoying, because they frequently fail (for more than a decade now), with no fix in sight.

Also, they are less useful than running on a real Windows.

My suggestion would be to replace the win64-cross CI task with one on GitHub Actions, using a real Windows. The cross compilation would still be done normally (to mimic guix), inside WSL. However, the unit tests would be run on the real Windows.

I won't be working on this myself, but I am happy to answer any questions on
...

💬 maflcko commented on issue "ci: failure in win64 unit tests `err:virtual:virtual_alloc_first_teb wine: failed to map the shared user data: c0000018\n0444:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.\n0444:err:winediag:nodrv_CreateWindow L"Make sure that your X server is running and that $DISPLAY is set correctly."`)":
(https://github.com/bitcoin/bitcoin/issues/30792#issuecomment-2406934000)
No idea how to fix this. I'd say to just replace the Wine tests finally: https://github.com/bitcoin/bitcoin/issues/31071

💬 maflcko commented on issue "win64-cross CI timeout: `wine: chdir to /tmp/wine-JFrcnM/server-30-e86edd : No such file or directory`; `01e0:err:module:relocate_ntdll ntdll could not be mapped at preferred address (0x320000), expect trouble`":
(https://github.com/bitcoin/bitcoin/issues/30969#issuecomment-2406934179)
No idea how to fix this. I'd say to just replace the Wine tests finally: https://github.com/bitcoin/bitcoin/issues/31071

💬 maflcko commented on issue "ci: Replace wine tests with real tests on Windows?":
(https://github.com/bitcoin/bitcoin/issues/31071#issuecomment-2406942992)
Ugh, this may require WSL2, which isn't yet available on GHA?

💬 fjahr commented on pull request "init: Correct coins db cache size setting":
(https://github.com/bitcoin/bitcoin/pull/31064#issuecomment-2406943239)
utACK 3a4a788ee0db83d20607f14801dbed2ee932943c

💬 willcl-ark commented on issue "ci: Replace wine tests with real tests on Windows?":
(https://github.com/bitcoin/bitcoin/issues/31071#issuecomment-2406956133)
I'm presuming that it may need WSL2 for the build, not the test stage?

If so, we could consider using two GH jobs to split/run this test in two stages; one which does the cross-compile on ubuntu and [saves the build artefacts](https://github.com/actions/upload-artifact), which, if successful, are then [restored](https://github.com/actions/download-artifact) by the second (native windows) job to be executed natively under Windows.

This could prove more tricky to actually execute in practice
...

🚀 fanquake merged a pull request: "contrib: fix typos in check-deps.sh"
(https://github.com/bitcoin/bitcoin/pull/31070)

💬 hebasto commented on issue "ci: Replace wine tests with real tests on Windows?":
(https://github.com/bitcoin/bitcoin/issues/31071#issuecomment-2406960015)
> Ugh, this may require WSL2, which isn't yet available on GHA?

The recent discussion is [here](https://github.com/actions/runner-images/issues/5920).

💬 maflcko commented on pull request "fuzz: fuzz connman with non-empty addrman + ASMap":
(https://github.com/bitcoin/bitcoin/pull/29536#issuecomment-2406968222)
cc @vasild Looks like this conflicts with one of your pulls, so you may be qualified to ack/nack this?

💬 willcl-ark commented on issue "Consider making 27.x Long-Term Support (LTS)":
(https://github.com/bitcoin/bitcoin/issues/31068#issuecomment-2407002453)
> RHEL 8 and the RHELatives that base off of this, such as AlmaLinux 8 and Rocky Linux 8.

> I would not be surprised if more than half of Bitcoin Core installations that run on dedicated Linux servers will not be able to update to 28.x as a result of this, without first updating to a new OS.

Do you have any further information on how you conclude that more than half of Bitcoin Core installations run on these OSes (and their derivatives)? This number doesn't feel right to me, even as a (hig
...

💬 l0rinc commented on pull request "Don't zero-after-free `DataStream`: Faster IBD on some configurations":
(https://github.com/bitcoin/bitcoin/pull/30987#issuecomment-2407036182)
I have compared the full IBD speed of
* 0449a22bc0: test: avoid BOOST_CHECK_EQUAL for complex types
* 5cf2fefd33: refactor: Drop unused `zero_after_free_allocator`

The added test served as a baseline, dropping the zero fee allocator as the purpose of this PR (I know you've added new commits since, let me know if you think that changes the landscape).

I've used a low, but reasonable 2GB dbcache for the first 800k blocks to measure the underlying database instead of a single final dump wit
...

📝 hebasto converted_to_draft a pull request: "build: Rename `PACKAGE_*` variables to `CLIENT_*`"
(https://github.com/bitcoin/bitcoin/pull/31042)
The use of `PACKAGE_NAME` for the project's variable name is problematic, as this name is commonly used in CMake's [interface variables](https://cmake.org/cmake/help/latest/command/find_package.html#config-mode-version-selection). If third-party CMake code handles with scopes improperly, our `PACKAGE_NAME` variable could end up with an unexpected value.

This PR avoids such conflicts by renaming all `PACKAGE_*` variables to `CLIENT_*`.

The code in the master branch works correctly only inci
...

💬 vasild commented on pull request "test: add end-to-end tests for CConnman and PeerManager":
(https://github.com/bitcoin/bitcoin/pull/26812#issuecomment-2407144282)
> developers may still prefer to write the tests in Python going forward, because they are used to it, and because it is more flexible

I agree. This PR does not intend to replace the functional testing framework, but complement it. For example, from C++ one has greater control and observability - the test can read any global or member variable and can call arbitrary functions (repeating https://github.com/bitcoin/bitcoin/pull/26812#discussion_r1068176623).

Also, when used from within C++ o
...

👋 hebasto's pull request is ready for review: "build: Rename `PACKAGE_*` variables to `CLIENT_*`"
(https://github.com/bitcoin/bitcoin/pull/31042)

💬 vasild commented on pull request "fuzz: fuzz connman with non-empty addrman + ASMap":
(https://github.com/bitcoin/bitcoin/pull/29536#issuecomment-2407171509)
Concept ACK

The conflict with https://github.com/bitcoin/bitcoin/pull/28584 is only mechanical.

This PR changes "the contents" of the `CConnman` and does not add fuzzing to more connman methods (except `connman.ASMapHealthCheck()`). The main point of this PR is that methods that are fuzzed even before this PR would behave differently if addrman is not empty. Nice.

https://github.com/bitcoin/bitcoin/pull/28584 adds fuzzing to methods not fuzzed before: `OpenNetworkConnection()`, `Create
...

💬 fanquake commented on pull request "build: Add missing USDT header dependency to kernel":
(https://github.com/bitcoin/bitcoin/pull/30970#issuecomment-2407187265)
> Currently depends builds pick up usdt and boost from the same path, and because boost always exists, the usdt path is implicitly included. So without boost, USDT isn't found.

To clarify for myself, the build currently picks up all depends dependencies from the same path (i.e something like `-isystem /root/ci_scratch/depends/x86_64-pc-linux-gnu/include`, (which is what is introduced with the change here)), so using any dependency will implictly include all others. It's just the case that the
...

💬 maflcko commented on issue "Consider making 27.x Long-Term Support (LTS)":
(https://github.com/bitcoin/bitcoin/issues/31068#issuecomment-2407190445)
If this really was an issue, adding back the build patches would probably be easier than backporting all bugfixes for years: https://github.com/bitcoin/bitcoin/commit/0c57a798b50bf03a0b69f632c691932d608254ef#diff-42e88f6b2dc3f513ccde184c74d1853a01b2bfc3ee64debf98c52efe316b04c1L456

However, I still don't understand why this is an issue.

Maybe I am missing something obvious, but at least locally I can call `./configure` on the `28.x` branch just fine on Alma8:

```
dnf install gcc-toolset
...

📝 ryanofsky opened a pull request: "scripted-diff: Replace strprintf(Untranslated(...)) with Untranslated(strprintf(...))"
(https://github.com/bitcoin/bitcoin/pull/31072)
This PR is just a scripted-diff replacing strprintf calls like:

```c++
strprintf(Untranslated("Error parsing command line arguments: %s"), error))
```

with:

```c++
Untranslated(strprintf("Error parsing command line arguments: %s", error))
```

Currently code is inconsistent and uses a mix of both styles, but second style is better because:

1. It scans more cleanly. It is easier to read the strprintf call, and easier to think about because the whole string, not just one part, is
...