| 7 Oct 2025 |
 niklaskorz | no worries, PR will be there within the hour | 10:21:49 |
 Vladimír Čunát | If I can just merged it, now-ish is a good moment. | 10:22:01 |
| niklaskorz | alright, I'm on it | 10:22:10 |
| Vladimír Čunát | And if it's not too urgent it can be in the next one which will also get into 25.11. | 10:22:45 |
| Vladimír Čunát | * Or if it's not too urgent it can be in the next one which will also get into 25.11. | 10:22:58 |
| Vladimír Čunát | But it may take a couple weeks to reach master. | 10:23:14 |
| Vladimír Čunát | * That would delay it by couple weeks (to reach master). | 10:23:49 |
| Vladimír Čunát | Oh no, fails to build on darwin:
https://hydra.nixos.org/build/309261595/nixlog/2/tail | 10:25:50 |
| Vladimír Čunát | I suppose I'll just revert the update, unless someone comes with a fix fast. | 10:27:46 |
| Vladimír Čunát | (I have no bandwidth to dig into this, especially on darwin.) | 10:28:08 |
| niklaskorz | I guess if we do realize it's breaking other packages in staging-next, we can still cherry-pick it | 10:28:48 |
| niklaskorz | (but as of now I'm not aware of any) | 10:29:29 |
| niklaskorz | sounds like a generic clang issue, not darwin specific | 10:30:12 |
| niklaskorz | relevant diff for gnulib in coreutils 9.8:
- error (exit_failure, errnum, "%s",
+ error (exit_failure, errnum,
_("unable to record current working directory"));
they've removed the format string parameter in all cases
| 10:45:16 |
| niklaskorz | introduced in: https://github.com/coreutils/gnulib/commit/9537853d31b02493f6f3a0ffb9b22bef1ed7217a
reverted in: https://github.com/coreutils/gnulib/commit/9297749090b01720888dceeb5f6dab3d52dcef40 | 10:47:33 |
| niklaskorz | https://lists.gnu.org/r/bug-gnulib/2025-06/msg00325.html | 10:47:58 |
| niklaskorz | the mailing list suggests this was made redundant by a fix in gettext | 10:48:39 |
| niklaskorz | that and:
Do we care about random warnings on non-GNU systems? I thought
that we care about warnings only on GNU systems, because that's
what we develop on and that's where we have some influence on
the compiler (gcc).
meaning upstream's preferred solution would be to just disable this warning
| 10:49:34 |
| Vladimír Čunát | So we can patch that by some -Wno-error=fool conditioned in coreutils on stdenv.isClang? | 10:54:20 |
| Vladimír Čunát | * So we can patch that by some -Wno-error=foo conditioned in coreutils on stdenv.isClang? | 10:54:37 |
| niklaskorz | I think so, testing locally now | 10:57:47 |
| niklaskorz | (on darwin) | 10:58:09 |
 K900 | Ah shit | 11:00:50 |
| K900 | Qt 6.10 just dropped | 11:00:50 |
| K900 | Hold, I guess | 11:00:50 |
 Randy Eckenrode | It’s a nice to have, but it’s only really needed by the Swift update, which is 26.05. The other cc-wrapper one is more important for the default SDK and min version updates. | 11:01:23 |
| Randy Eckenrode | So GCC doesn’t have the warnings because of proprietary GNU extensions? | 11:05:58 |
| niklaskorz | basically:
I think the warning-avoiding fix in gettext.h works only for gcc,
because gcc recognizes 'gettext', 'dgettext', 'dcgettext' as built-ins.
| 11:06:31 |
| niklaskorz | followed by: | 11:06:48 |
| niklaskorz |
the more pragmatic way is to just accept the fact that clang
produces more warnings than gcc, and to filter out / triage the warnings
from the compilation log
| 11:06:54 |
