💬 instagibbs commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2075306983)
still fumbling this. In `mempool_datacarrier.py` I'm not explicitly stopping or restarting the nodes but allowing test teardown to do it. Should I just be stopping the node myself with the optional arg?

💬 instagibbs commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2075314466)
Documentation for this is in `src/kernel/mempool_options.h`, it can be further spelled out in policy.h for `IsStandardTx` if that helps?

👍 ismaelsadeeq approved a pull request: "fees: document non-monotonic estimation edge case"
(https://github.com/bitcoin/bitcoin/pull/31080#pullrequestreview-2818014449)
Code review ACK 1e0de7a6ba926487c8a075856b74af2a3a0eb8ef

💬 instagibbs commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2075329397)
done

💬 instagibbs commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2075329807)
done

💬 Sjors commented on pull request "rpc: Undeprecate rpcuser/rpcpassword, store all credentials hashed in memory":
(https://github.com/bitcoin/bitcoin/pull/32423#issuecomment-2854351055)
Hah, I was planning on doing this undeprecating this morning, but couldn't find the deprecation message, so I figured someone already did it.

Concept ACK

💬 ryanofsky commented on issue "Intermittent issue in test/ipc_tests.cpp Fatal glibc error: pthread_mutex_lock.c:450 (__pthread_mutex_lock_full): assertion failed: e != ESRCH || !robust":
(https://github.com/bitcoin/bitcoin/issues/29889#issuecomment-2854354693)
This seems a lot like issue https://github.com/bitcoin-core/libmultiprocess/issues/154 which was fixed by https://github.com/bitcoin-core/libmultiprocess/pull/159

✅ Sjors closed an issue: "Make -stopatheight work with background sync"
(https://github.com/bitcoin/bitcoin/issues/28809)

💬 Sjors commented on issue "Make -stopatheight work with background sync":
(https://github.com/bitcoin/bitcoin/issues/28809#issuecomment-2854361655)
I stopped caring about this :-)

💬 adamandrews1 commented on pull request "fees: document non-monotonic estimation edge case":
(https://github.com/bitcoin/bitcoin/pull/31080#issuecomment-2854362619)
Code review ACK 1e0de7a

✅ Sjors closed an issue: "depends: llvm-ranlib (etc): "No such file or directory" on Intel macOS 15.0"
(https://github.com/bitcoin/bitcoin/issues/30978)

💬 Sjors commented on issue "Having qt(@6) breaks build for qt@5 on macOS 15.0 and 13.7":
(https://github.com/bitcoin/bitcoin/issues/31009#issuecomment-2854374755)
No longer an issue since #30997.

✅ Sjors closed an issue: "Having qt(@6) breaks build for qt@5 on macOS 15.0 and 13.7"
(https://github.com/bitcoin/bitcoin/issues/31009)

⚠️ fanquake reopened an issue: "Having qt(@6) breaks build for qt@5 on macOS 15.0 and 13.7"
(https://github.com/bitcoin/bitcoin/issues/31009)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

Building bitcoin-qt produces a flood of errors:

```
In file included from /Users/sjors/dev/bitcoin/src/qt/csvmodelwriter.cpp:5:
In file included from /Users/sjors/dev/bitcoin/src/qt/csvmodelwriter.h:8:
In file included from /usr/local/opt/qt@5/lib/QtCore.framework/Headers/QList:1:
In file included from /usr/local/opt/qt@5/lib/QtCore.framework/Headers/qlist.h:48:
/usr/local/include/
...

💬 fanquake commented on issue "Having qt(@6) breaks build for qt@5 on macOS 15.0 and 13.7":
(https://github.com/bitcoin/bitcoin/issues/31009#issuecomment-2854377650)
It is still an issue, in the 29.x branch.

💬 Sjors commented on issue "ARM Windows build and release":
(https://github.com/bitcoin/bitcoin/issues/31388#issuecomment-2854384464)
We're at qt6 since #30997 landed. But it still needs to be natively compiled. I don't know if cross-compilation is a priority for QT? If not, then there's probably no point in keeping this open until the end of time.

💬 polespinasa commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2075362265)
I just checked, when is auto-stopped at the end it stop all nodes by calling:
```python
self.log.info("Stopping nodes")
if self.nodes:
self.stop_nodes()
```
It uses `stop_nodes()` which doesn't give any `expected_stderr` value:
```python
def stop_node(self, i, expected_stderr='', wait=0):
"""Stop a bitcoind test node"""
self.nodes[i].stop_node(expected_stderr, wait=wait)

def stop_nodes(self, wait=0):
"""Stop multiple bitco
...

💬 Sjors commented on issue "Having qt(@6) breaks build for qt@5 on macOS 15.0 and 13.7":
(https://github.com/bitcoin/bitcoin/issues/31009#issuecomment-2854390811)
@fanquake #32017 documents this in the build instructions. It's included in the v29 branch.

💬 fanquake commented on issue "Having qt(@6) breaks build for qt@5 on macOS 15.0 and 13.7":
(https://github.com/bitcoin/bitcoin/issues/31009#issuecomment-2854392228)
That's fine. It's still a bug that should be fixed. Compiling our software should not be dependant on uninstalling other software.

💬 Sjors commented on issue "RFC: when to drop testnet3":
(https://github.com/bitcoin/bitcoin/issues/31975#issuecomment-2854397425)
So how long should we wait?

My mailinglist post didn't result in very passionate pleas for keeping it. And although some projects do still use it, they haven't demonstrated a serious intention to upgrade anytime soon.

Should we perhaps wait for testnet5 to see if that fixes the issues we see on testnet4? I suppose we have enough ports...

Or should I mark #31974 ready for review and just drop testnet3 in v30?