💬 TheCharlatan commented on pull request "refactor: Rename `subprocess.hpp` to follow our header name conventions":
(https://github.com/bitcoin/bitcoin/pull/29910#issuecomment-2074457183)
> Resolved linter warnings.
Can you mention this in the PR description?
(https://github.com/bitcoin/bitcoin/pull/29910#issuecomment-2074457183)
> Resolved linter warnings.
Can you mention this in the PR description?
💬 Kellydutch1 commented on pull request "doc: Suggest only necessary Qt packages for installation on OpenBSD":
(https://github.com/bitcoin/bitcoin/pull/29947#issuecomment-2074462911)
I have bitcoin hacking software
(https://github.com/bitcoin/bitcoin/pull/29947#issuecomment-2074462911)
I have bitcoin hacking software
💬 fanquake commented on pull request "build: Consider `SOURCE_DATE_EPOCH` in Guix environment only":
(https://github.com/bitcoin/bitcoin/pull/29761#issuecomment-2074466635)
What is the status of this?
(https://github.com/bitcoin/bitcoin/pull/29761#issuecomment-2074466635)
What is the status of this?
📝 fanquake converted_to_draft a pull request: "doc: add LLVM instruction for macOS < 13"
(https://github.com/bitcoin/bitcoin/pull/29934)
#29208 bumped clang to 14, which users of old macOS versions need to install manually. This PR adds instructions.
Xcode 14.3.1 ships clang 14.0.3 (14.0.0 is broken, see #29918):
https://en.wikipedia.org/wiki/Xcode#Xcode_11.0_-_14.x_(since_SwiftUI_framework)
The system requirements for that is macOS Ventura 13.0 or later: https://developer.apple.com/documentation/xcode-release-notes/xcode-14_3_1-release-notes#
Homebrew itself officially supports macOS 12 or later, but _may_ still work o
...
(https://github.com/bitcoin/bitcoin/pull/29934)
#29208 bumped clang to 14, which users of old macOS versions need to install manually. This PR adds instructions.
Xcode 14.3.1 ships clang 14.0.3 (14.0.0 is broken, see #29918):
https://en.wikipedia.org/wiki/Xcode#Xcode_11.0_-_14.x_(since_SwiftUI_framework)
The system requirements for that is macOS Ventura 13.0 or later: https://developer.apple.com/documentation/xcode-release-notes/xcode-14_3_1-release-notes#
Homebrew itself officially supports macOS 12 or later, but _may_ still work o
...
⚠️ mouhand-a opened an issue: "0xF2852f0DD3703afc3A5B4343e262839eEf73eD23"
(https://github.com/bitcoin/bitcoin/issues/29950)
### Issues, reports or feature requests related to the GUI should be opened directly on the GUI repo
- [X] I still think this issue should be opened here
### Report
My address [](url)
0xF2852f0DD3703afc3A5B4343e262839eEf73eD23
(https://github.com/bitcoin/bitcoin/issues/29950)
### Issues, reports or feature requests related to the GUI should be opened directly on the GUI repo
- [X] I still think this issue should be opened here
### Report
My address [](url)
0xF2852f0DD3703afc3A5B4343e262839eEf73eD23
✅ hebasto closed an issue: "0xF2852f0DD3703afc3A5B4343e262839eEf73eD23"
(https://github.com/bitcoin/bitcoin/issues/29950)
(https://github.com/bitcoin/bitcoin/issues/29950)
:lock: hebasto locked an issue: "0xF2852f0DD3703afc3A5B4343e262839eEf73eD23"
(https://github.com/bitcoin/bitcoin/issues/29950)
(https://github.com/bitcoin/bitcoin/issues/29950)
💬 TheCharlatan commented on pull request "doc: add LLVM instruction for macOS < 13":
(https://github.com/bitcoin/bitcoin/pull/29934#discussion_r1577616561)
I tested this without specifying a llvm version on macos 12.7.4 monterey. It did resolve the compilation errors. I would prefer this without a version, since it is yet another thing to keep track of in our versioning zoo, and I don't think it is preferable for developers to be instructed to use an older compiler. Also not sure if the guide should cover an OS version that is no longer supported by its package manager. If something eventually breaks for a developer, this could be revisited.
(https://github.com/bitcoin/bitcoin/pull/29934#discussion_r1577616561)
I tested this without specifying a llvm version on macos 12.7.4 monterey. It did resolve the compilation errors. I would prefer this without a version, since it is yet another thing to keep track of in our versioning zoo, and I don't think it is preferable for developers to be instructed to use an older compiler. Also not sure if the guide should cover an OS version that is no longer supported by its package manager. If something eventually breaks for a developer, this could be revisited.
💬 fanquake commented on pull request "ci: Drop no longer needed `-I` flag in "tidy" task":
(https://github.com/bitcoin/bitcoin/pull/29929#issuecomment-2074566263)
Did this change with LLVM version, or IWYU version or changing the base image?
(https://github.com/bitcoin/bitcoin/pull/29929#issuecomment-2074566263)
Did this change with LLVM version, or IWYU version or changing the base image?
💬 maflcko commented on pull request "refactor: Use our own implementation of urlDecode":
(https://github.com/bitcoin/bitcoin/pull/29904#discussion_r1577622427)
How important is it to preserve invalid encodings? For example the decode of `%1 ` (percent, 1, space) differs between this implementation and the one of libevent.
(https://github.com/bitcoin/bitcoin/pull/29904#discussion_r1577622427)
How important is it to preserve invalid encodings? For example the decode of `%1 ` (percent, 1, space) differs between this implementation and the one of libevent.
💬 hebasto commented on pull request "ci: Drop no longer needed `-I` flag in "tidy" task":
(https://github.com/bitcoin/bitcoin/pull/29929#issuecomment-2074570556)
> Did this change with LLVM version, or IWYU version or changing the base image?
My guess is LLVM version, but I didn't check.
(https://github.com/bitcoin/bitcoin/pull/29929#issuecomment-2074570556)
> Did this change with LLVM version, or IWYU version or changing the base image?
My guess is LLVM version, but I didn't check.
🚀 fanquake merged a pull request: "ci: Drop no longer needed `-I` flag in "tidy" task"
(https://github.com/bitcoin/bitcoin/pull/29929)
(https://github.com/bitcoin/bitcoin/pull/29929)
💬 fanquake commented on pull request "build: add `-Wundef`":
(https://github.com/bitcoin/bitcoin/pull/29876#discussion_r1577642260)
> but probably not worth doing this last-minute change for autotools.
Not sure. Everything not done for Autotools, but done in CMake is just more bebaviour/divergence to maintain, so I'd prefer to do as much as possible prior.
(https://github.com/bitcoin/bitcoin/pull/29876#discussion_r1577642260)
> but probably not worth doing this last-minute change for autotools.
Not sure. Everything not done for Autotools, but done in CMake is just more bebaviour/divergence to maintain, so I'd prefer to do as much as possible prior.
💬 fanquake commented on pull request "[WIP] libevent @ master + use CMake":
(https://github.com/bitcoin/bitcoin/pull/29835#issuecomment-2074617393)
> and if we liked the CMake build parts we'd patch them in and drop the rest.
Yep. From the OP:
> Depending on the outcome, we could possibly pull a (minified) patch set into depends.
(https://github.com/bitcoin/bitcoin/pull/29835#issuecomment-2074617393)
> and if we liked the CMake build parts we'd patch them in and drop the rest.
Yep. From the OP:
> Depending on the outcome, we could possibly pull a (minified) patch set into depends.
💬 hebasto commented on pull request "build: Consider `SOURCE_DATE_EPOCH` in Guix environment only":
(https://github.com/bitcoin/bitcoin/pull/29761#issuecomment-2074627637)
> > However, using it outside Guix scripts for local builds on macOS is not meaningful.
>
> Why? Using Guix should not be a requirement for SOURCE_DATE_EPOCH to be useful.
Not a requirement. Both Guix and SOURCE_DATE_EPOCH are tools of the same domain, which is build reproducibility.
> I would think that given the pinned compilers, and provisioned std lib, the macOS cross build would actually pretty be close to deterministic outside of Guix.
Is anyone interesting / working on that?
...
(https://github.com/bitcoin/bitcoin/pull/29761#issuecomment-2074627637)
> > However, using it outside Guix scripts for local builds on macOS is not meaningful.
>
> Why? Using Guix should not be a requirement for SOURCE_DATE_EPOCH to be useful.
Not a requirement. Both Guix and SOURCE_DATE_EPOCH are tools of the same domain, which is build reproducibility.
> I would think that given the pinned compilers, and provisioned std lib, the macOS cross build would actually pretty be close to deterministic outside of Guix.
Is anyone interesting / working on that?
...
💬 fanquake commented on pull request "build: Consider `SOURCE_DATE_EPOCH` in Guix environment only":
(https://github.com/bitcoin/bitcoin/pull/29761#issuecomment-2074632025)
> Is anyone interesting / working on that?
I'm saying it's likely already the case, without further changes.
> Under peer reviewing, I guess :)
Ok. Concept NACK I guess. I don't see the motivation.
(https://github.com/bitcoin/bitcoin/pull/29761#issuecomment-2074632025)
> Is anyone interesting / working on that?
I'm saying it's likely already the case, without further changes.
> Under peer reviewing, I guess :)
Ok. Concept NACK I guess. I don't see the motivation.
✅ hebasto closed a pull request: "build: Consider `SOURCE_DATE_EPOCH` in Guix environment only"
(https://github.com/bitcoin/bitcoin/pull/29761)
(https://github.com/bitcoin/bitcoin/pull/29761)
💬 vasild commented on pull request "doc: suggest only necessary Qt packages for installation on FreeBSD":
(https://github.com/bitcoin/bitcoin/pull/29932#discussion_r1577686920)
> 1. Why `qt5-qmake`?
This PR originated from https://github.com/hebasto/bitcoin/pull/133#discussion_r1551480291 where I was testing bitcoin+cmake on freebsd. `qt5-qmake` is needed because of this error:
```
CMake Error at /usr/local/lib/cmake/Qt5Core/Qt5CoreConfig.cmake:14 (message):
The imported target "Qt5::Core" references the file
"/usr/local/lib/qt5/bin/qmake"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to a
...
(https://github.com/bitcoin/bitcoin/pull/29932#discussion_r1577686920)
> 1. Why `qt5-qmake`?
This PR originated from https://github.com/hebasto/bitcoin/pull/133#discussion_r1551480291 where I was testing bitcoin+cmake on freebsd. `qt5-qmake` is needed because of this error:
```
CMake Error at /usr/local/lib/cmake/Qt5Core/Qt5CoreConfig.cmake:14 (message):
The imported target "Qt5::Core" references the file
"/usr/local/lib/qt5/bin/qmake"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to a
...
💬 vasild commented on pull request "doc: suggest only necessary Qt packages for installation on FreeBSD":
(https://github.com/bitcoin/bitcoin/pull/29932#issuecomment-2074666837)
`b1e98c1b36...f4362367d7`: remove `qt5-qmake` and `qt5-network`, see https://github.com/bitcoin/bitcoin/pull/29932#discussion_r1575115643
(https://github.com/bitcoin/bitcoin/pull/29932#issuecomment-2074666837)
`b1e98c1b36...f4362367d7`: remove `qt5-qmake` and `qt5-network`, see https://github.com/bitcoin/bitcoin/pull/29932#discussion_r1575115643
💬 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.
(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.