💬 achow101 commented on pull request "guix: Zip needs to include all files and set time to SOURCE_DATE_EPOCH":
(https://github.com/bitcoin/bitcoin/pull/28757#issuecomment-1787469468)
> Yea, we should nuke the `dist/` here, otherwise, this looks good to me.

Should be done, testing now (need to rebuild, so could be a little bit).

💬 andrewtoth commented on pull request "p2p: adaptive connections services flags":
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1377793447)
The 3 lines below are the same as lines 38-40, except for the +11min. It's unclear to me from this comment what the 11min is doing and why this is different from what we are doing before. Can this maybe be explained better?

💬 hebasto commented on pull request "guix: Zip needs to include all files and set time to SOURCE_DATE_EPOCH":
(https://github.com/bitcoin/bitcoin/pull/28757#issuecomment-1787478654)
My hashes for f6f18eeaa88784e487e9bca8c5ace6c66bd721cc:
```
adc40abe61a6731b4d481d27b883731d282b61995b3ca401dea49385c89ff8ef guix-build-26.0rc1/output/arm64-apple-darwin-codesigned/bitcoin-26.0rc1-arm64-apple-darwin.zip
11ee5b21d4d0d411117a7e237d73d698170f0b18dd78ab1299499ae65abc3a1b guix-build-26.0rc1/output/x86_64-apple-darwin-codesigned/bitcoin-26.0rc1-x86_64-apple-darwin.zip
```

👍 hebasto approved a pull request: "guix: Zip needs to include all files and set time to SOURCE_DATE_EPOCH"
(https://github.com/bitcoin/bitcoin/pull/28757#pullrequestreview-1706677199)
ACK f6f18eeaa88784e487e9bca8c5ace6c66bd721cc, if hashes are the same.

💬 darosior commented on pull request "guix: update signapple to latest master":
(https://github.com/bitcoin/bitcoin/pull/28759#issuecomment-1787523074)
Concept ACK.

💬 fanquake commented on pull request "guix: update signapple to latest master":
(https://github.com/bitcoin/bitcoin/pull/28759#issuecomment-1787547324)
Guix Build (aarch64):
```bash
66c24a02462fa98aa772a7347bfa5edd64f79979e256b463cdc82808a74dc38e guix-build-79539fbfbf4d/output/aarch64-linux-gnu/SHA256SUMS.part
bf0e04a6dfc8d580428c8e33eedb57f2ec311eff054387dac985abc1e2c50a3a guix-build-79539fbfbf4d/output/aarch64-linux-gnu/bitcoin-79539fbfbf4d-aarch64-linux-gnu-debug.tar.gz
4e9d47a41bfd12f3aa5bb553b162a348359b289a4d1eeb0ce83029852bf66036 guix-build-79539fbfbf4d/output/aarch64-linux-gnu/bitcoin-79539fbfbf4d-aarch64-linux-gnu.tar.gz
e912a6
...

👍 TheCharlatan approved a pull request: "guix: Zip needs to include all files and set time to SOURCE_DATE_EPOCH"
(https://github.com/bitcoin/bitcoin/pull/28757#pullrequestreview-1706792598)
ACK f6f18eeaa88784e487e9bca8c5ace6c66bd721cc

I get the same hashes as @hebasto and have checked that it still installs fine.

🚀 fanquake merged a pull request: "guix: Zip needs to include all files and set time to SOURCE_DATE_EPOCH"
(https://github.com/bitcoin/bitcoin/pull/28757)

💬 fanquake commented on pull request "guix: Zip needs to include all files and set time to SOURCE_DATE_EPOCH":
(https://github.com/bitcoin/bitcoin/pull/28757#issuecomment-1787599465)
Added to #28754.

💬 hebasto commented on issue "macOS: Guix codesigning step broken":
(https://github.com/bitcoin/bitcoin/issues/28756#issuecomment-1787599758)
Close as https://github.com/bitcoin/bitcoin/pull/28757 has just been merged?

✅ fanquake closed an issue: "macOS: Guix codesigning step broken"
(https://github.com/bitcoin/bitcoin/issues/28756)

💬 maflcko commented on issue "Undefined behavior in AutoFile::write (gcc only)":
(https://github.com/bitcoin/bitcoin/issues/28761#issuecomment-1787603064)
I think this is a "bug" in gcc that should be fixed upstream. See also the related discussion in https://reviews.llvm.org/D86993

📝 hebasto opened a pull request: "[26.x] qt: 26.0rc2 translations update"
(https://github.com/bitcoin/bitcoin/pull/28763)
This PR pulls the recent translations from the [Transifex.com](https://www.transifex.com/bitcoin/bitcoin) using the [`bitcoin-maintainer-tools/update-translations.py`](https://github.com/bitcoin-core/bitcoin-maintainer-tools/blob/main/update-translations.py) tool.

According to our [Release Process docs](https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#before-every-release-candidate), it is supposed to be merged before `v26.0rc2` tagging.

💬 maflcko commented on pull request "build: Require C++20 compiler":
(https://github.com/bitcoin/bitcoin/pull/28349#issuecomment-1787614684)
In any case, it is waiting on guix (see above failure) and the macOS compile failure (Xcode?), so I can't really take it out of draft anyway.

👍 stickies-v approved a pull request: "[26.x] qt: 26.0rc2 translations update"
(https://github.com/bitcoin/bitcoin/pull/28763#pullrequestreview-1706824988)
ACK 1695c4801ccf63d26b6aa802c39019facff04639

Got a zero diff after running [bitcoin-maintainer-tools/update-translations.py](https://github.com/bitcoin-core/bitcoin-maintainer-tools/blob/main/update-translations.py) - did not do anything else.

💬 achow101 commented on pull request "guix: update signapple to latest master":
(https://github.com/bitcoin/bitcoin/pull/28759#issuecomment-1787623062)
ACK 79539fbfbf4d09a8b4861ddcba5b194297bc1b65

🚀 fanquake merged a pull request: "[26.x] qt: 26.0rc2 translations update"
(https://github.com/bitcoin/bitcoin/pull/28763)

💬 theuni commented on pull request "build: remove duplicate `-lminiupnpc` linking":
(https://github.com/bitcoin/bitcoin/pull/28755#discussion_r1377913811)
I think this is one of those cases where you need the funky xsyntax.

`$have_natpmp` is either "no" or empty. IIRC empty can screw up `test` on some shells.

This is usually avoided by either initializing to something or doing: `if test "x$have_natpmp" != "xno"; then`.

💬 fanquake commented on pull request "build: remove duplicate `-lminiupnpc` linking":
(https://github.com/bitcoin/bitcoin/pull/28755#discussion_r1377915248)
> IIRC empty can screw up test on some shells.

I think bash fixed that in 1996, and we have since removed all the x-prefix usage from our build system. It'd be good to not have to reintroduce it.

💬 theuni commented on pull request "build: remove duplicate `-lminiupnpc` linking":
(https://github.com/bitcoin/bitcoin/pull/28755#discussion_r1377916012)
Same xsyntax thing here, but clearly it's not been an issue. Maybe the quotes are enough.