💬 achow101 commented on pull request "doc: update IBD requirements in doc/README.md":
(https://github.com/bitcoin/bitcoin/pull/30992#issuecomment-2403641132)
ACK 36a6d4b0078ebb39ed082c866bf49214a2a01241

🚀 achow101 merged a pull request: "doc: update IBD requirements in doc/README.md"
(https://github.com/bitcoin/bitcoin/pull/30992)

💬 achow101 commented on pull request "Mining interface: getCoinbaseMerklePath() and submitSolution()":
(https://github.com/bitcoin/bitcoin/pull/30955#issuecomment-2403650915)
ACK 525e9dcba0b8c6744bcd3725864f39786afc8ed5

🚀 achow101 merged a pull request: "Mining interface: getCoinbaseMerklePath() and submitSolution()"
(https://github.com/bitcoin/bitcoin/pull/30955)

💬 Chrcelalles commented on issue "Release Schedule for 28.0":
(https://github.com/bitcoin/bitcoin/issues/29891#issuecomment-2403755135)
Hola saludos desde Argentina

✅ achow101 closed an issue: "Release Schedule for 28.0"
(https://github.com/bitcoin/bitcoin/issues/29891)

⚠️ achow101 unpinned an issue: "Release Schedule for 28.0"
(https://github.com/bitcoin/bitcoin/issues/29891)
Here is a proposed release schedule for `v28.0`, the next major release of Bitcoin Core. The dates are set to target a release in early October as was previously discussed.

## 2024-08-01 :heavy_check_mark:
- Open Transifex translations for `v28.0`
- Soft translation string freeze (no large or non-critical string changes until release)
- Finalize and close translations for `v26.0`

## 2024-08-12 :heavy_check_mark:
- Feature freeze (bug fixes only until release)
- Translation string free
...

💬 jarolrod commented on pull request "build: Bump minimum supported macOS to 12.0":
(https://github.com/bitcoin/bitcoin/pull/31048#issuecomment-2403845176)
concept ack

💬 jarolrod commented on pull request "refactor: Check translatable format strings at compile-time":
(https://github.com/bitcoin/bitcoin/pull/31061#issuecomment-2403846748)
concept ack

💬 maflcko commented on pull request "build: Bump minimum supported macOS to 12.0":
(https://github.com/bitcoin/bitcoin/pull/31048#issuecomment-2404147794)
review ACK 05d25304bc4e0c3058c8ee8a89448ce63ac77304

Didn't test, because I don't use or have a macos.

💬 LarryRuane commented on pull request "doc: cmake: prepend "build" to functional/test_runner.py":
(https://github.com/bitcoin/bitcoin/pull/30859#issuecomment-2404251833)
Force pushed 6ab688c74b61c4403f831f1df54a350548ce8664 to restore the accidentally-dropped change that Jon pointed out.

👍 itornaza approved a pull request: "build: Bump minimum supported macOS to 12.0"
(https://github.com/bitcoin/bitcoin/pull/31048#pullrequestreview-2359433848)
tested ACK 05d25304bc4e0c3058c8ee8a89448ce63ac77304

Run all tests including the functional and extended on macOS 15.0.1 and everything checks out ok.

Unfortunately, I could not test on macOS previous to 12, as I have converted all my older macs to run Linux.

💬 fanquake commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#discussion_r1794934340)
> Special treatment is needed for every native package that uses CMake. For now, this applies only to Qt.

So this will also apply to libmultiprocess. I guess it's currently not a issue?, because we don't build it in Guix, however, that may change soon, #30975, so rather than adding Qt workarounds here, and then having to either add the same workarounds for libmultiprocess, or fix things in a more fundamental way later, it may still be better to make those changes now.

> By default, CMake
...

💬 maflcko commented on pull request "refactor: Check translatable format strings at compile-time":
(https://github.com/bitcoin/bitcoin/pull/31061#discussion_r1794944263)
Thanks, replaced my commit with your 71d382650b5a0bfb21085e8f6bd22152d2148459

💬 fanquake commented on issue "ci: ConnectionRefusedError: [WinError 10061] No connection could be made because the target machine actively refused it":
(https://github.com/bitcoin/bitcoin/issues/30390#issuecomment-2404417309)
https://github.com/bitcoin/bitcoin/actions/runs/11265108219/job/31326367933#step:12:228

💬 maflcko commented on pull request "refactor: Check translatable format strings at compile-time":
(https://github.com/bitcoin/bitcoin/pull/31061#discussion_r1794955960)
> But I think those cases are basically broken because they are substituting non-english string fragments inside english strings.

I am not sure I agree. `Untranslated("%s:%i ")` doesn't look English to me. To me, it looks like `Untranslated()` is sometimes used to annotate format strings that are valid in any language and do not need to be translated.

And your fix doesn't prevent non-English fragments in English strings anyway, because you are using `operator+` to concatenate the English/`
...

💬 maflcko commented on pull request "refactor: Check translatable format strings at compile-time":
(https://github.com/bitcoin/bitcoin/pull/31061#discussion_r1794960822)
Ok, renamed to `Translatable<bool _>`. I don't think `bilingual_*` makes sense, because it is only an internally used type to hold the hand of the compiler. The type is supposed to convert into a real `bilingual_str` either directly or via `bilingual_fmt` and tfm.

💬 maflcko commented on pull request "refactor: Check translatable format strings at compile-time":
(https://github.com/bitcoin/bitcoin/pull/31061#discussion_r1794962369)
> Yes I do think that's better and basically made the same change in my branch, though without the str() method since it seems it makes it a little less clear what return type is.

Ok, pushed my diff above, with the added `str()` removed again.

💬 maflcko commented on pull request "refactor: Check translatable format strings at compile-time":
(https://github.com/bitcoin/bitcoin/pull/31061#discussion_r1794962653)
thanks, fixed

💬 maflcko commented on pull request "refactor: Check translatable format strings at compile-time":
(https://github.com/bitcoin/bitcoin/pull/31061#discussion_r1794969088)
> in [aaaa4fb](https://github.com/bitcoin/bitcoin/commit/aaaa4fb20156b4375d92e1eca4acc90a425a1896): seems more straightforward to just extend `ConstevalStringLiteral` instead of creating a new `util::Original`? This would 1) minimize the diff and 2) I find `ConstevalStringLiteral` a much more helpful name than `Original`.

Are you sure it would minimize the diff? `Original` needs to deal with the concept of translations, which seems out-of-scope for `ConstevalStringLiteral`. Having two separat
...