💬 fanquake commented on issue "guix: SOURCE_DATE_EPOCH is already set in some environments":
(https://github.com/bitcoin/bitcoin/issues/29935#issuecomment-2074668778)
> As we run Guix shell in a container, it seems reasonable to rename SOURCE_DATE_EPOCH in the guix-build and guix-codesign scripts, and pass it to the container using its original name:

Not sure. We already have FORCE_DIRTY_WORKTREE. Seems fine to just make SOURCE_DATE_EPOCH function in the same way, rather than new vairables / more build options / things being less-standard.

💬 kosuodhmwa commented on issue "~/.bitcoin (which is a softlink to a separate vmware virtual drive) dir is now almost 1tb":
(https://github.com/bitcoin/bitcoin/issues/29909#issuecomment-2074669556)
Thank you very much, will look on it ASAP! :-)

💬 maflcko commented on pull request "doc: suggest only necessary Qt packages for installation on FreeBSD":
(https://github.com/bitcoin/bitcoin/pull/29932#issuecomment-2074673320)
Please update to the corresponding version of the OS in line 3 of the file

💬 fanquake commented on issue "RFC: In guix compile the GUI sequentially from everything else?":
(https://github.com/bitcoin/bitcoin/issues/29914#issuecomment-2074679694)
> fully static binaries

Yea. I think I'm just going to start PR'ing related changes, so we can move forward with static builds separately from the GUI, and keep all it's deps / build tools out of the env.

💬 laanwj commented on issue "guix: SOURCE_DATE_EPOCH is already set in some environments":
(https://github.com/bitcoin/bitcoin/issues/29935#issuecomment-2074684256)
That sounds like a good approach to me too.

🚀 fanquake merged a pull request: "netbase: clean up Proxy logging"
(https://github.com/bitcoin/bitcoin/pull/29882)

💬 fanquake commented on pull request "script: throw disabled err for op_ver and its variants":
(https://github.com/bitcoin/bitcoin/pull/28169#issuecomment-2074717810)
I agree. At a minimum, given the PR description is near impossible to follow, it should be re-written. Especailly given the commit only contains `feat: OP_VERIF and OP_VERNOTIF throw disabled error`.

📝 hebasto opened a pull request: "ci: Workaround Microsoft mirror issue for GitHub Action"
(https://github.com/bitcoin/bitcoin/pull/29951)
Upstream:
- issue -- https://github.com/actions/runner-images/issues/9733
- code snippet -- https://github.com/actions/runner-images/issues/9733#issuecomment-2074590278

💬 hebasto commented on pull request "ci: Workaround Microsoft mirror issue for GitHub Action":
(https://github.com/bitcoin/bitcoin/pull/29951#issuecomment-2074720447)
Going to add a second commit just to trigger the affected "test-each-commit" CI job.

💬 paplorinc commented on pull request "ci: Workaround Microsoft mirror issue for GitHub Action":
(https://github.com/bitcoin/bitcoin/pull/29951#issuecomment-2074723129)
Could you please validate that this is the failure reason for https://github.com/bitcoin/bitcoin/pull/29862?

💬 hebasto commented on pull request "ci: Workaround Microsoft mirror issue for GitHub Action":
(https://github.com/bitcoin/bitcoin/pull/29951#issuecomment-2074724587)
> Could you please validate that this is the failure reason for #29862?

Correct.

💬 fanquake commented on pull request "doc: Fix gen-manpages to check build options":
(https://github.com/bitcoin/bitcoin/pull/29457#discussion_r1577740259)
Not sure. Although I think any changes here can wait until after CMake, as this script will likely need to be (partially) rewritten after that change in any case.

💬 fanquake commented on pull request "cleanse: switch to SecureZeroMemory for Windows cross-compile, check for usage":
(https://github.com/bitcoin/bitcoin/pull/26950#discussion_r1577742022)
> Oh never mind, you're not looking for SecureZeroMemory itself, only its implementation within memory_cleanse. This makes sense.

Yea. Happy to try and extend / improve things further where we can.

💬 hebasto commented on pull request "ci: Workaround Microsoft mirror issue for GitHub Action":
(https://github.com/bitcoin/bitcoin/pull/29951#issuecomment-2074747798)
> Going to add a second commit just to trigger the affected "test-each-commit" CI job.

It works -- https://github.com/bitcoin/bitcoin/actions/runs/8815890196/job/24198769685.

💬 hebasto commented on pull request "ci: Workaround Microsoft mirror issue for GitHub Action":
(https://github.com/bitcoin/bitcoin/pull/29951#issuecomment-2074752379)
> > Going to add a second commit just to trigger the affected "test-each-commit" CI job.
>
> It works -- https://github.com/bitcoin/bitcoin/actions/runs/8815890196/job/24198769685.

Reverted back to the mergeable state.

💬 fanquake commented on pull request "ci: Workaround Microsoft mirror issue for GitHub Action":
(https://github.com/bitcoin/bitcoin/pull/29951#issuecomment-2074753565)
Given the impact, I assume this will be fixed shortly. So not sure we need to commit something just to semi-immediately revert it. GitHub is also having issues (https://www.githubstatus.com/), so maybe it's the same/related infra.

💬 hebasto commented on pull request "ci: Workaround Microsoft mirror issue for GitHub Action":
(https://github.com/bitcoin/bitcoin/pull/29951#issuecomment-2074782310)
> So not sure we need to commit something just to semi-immediately revert it.

A revert commit won't be actually required. This change improves robustness of the CI script.

💬 vasild commented on pull request "doc: Suggest only necessary Qt packages for installation on OpenBSD":
(https://github.com/bitcoin/bitcoin/pull/29947#issuecomment-2074791093)
Concept ACK

I have no (easy) way to verify that exactly those packages suffice, thus not full ACK.

👍 theStack approved a pull request: "doc: Suggest only necessary Qt packages for installation on OpenBSD"
(https://github.com/bitcoin/bitcoin/pull/29947#pullrequestreview-2019682576)
re-ACK 970cbc3172b73e1faf6bdb429400d3497cbb9d33

💬 vasild commented on pull request "doc: suggest only necessary Qt packages for installation on FreeBSD":
(https://github.com/bitcoin/bitcoin/pull/29932#issuecomment-2074800945)
`f4362367d7...d457d8b20a`:

> Please update to the corresponding version of the OS in line 3 of the file

Done, even though in FreeBSD the packaging system is agnostic to the OS version (mostly).