Coreutils update from v8.32 to 9.7 as suggested

[sth0]

Follow on to PR #1237

[sth0]

Closed - Duplicate

[sth0]

Not a duplicate. Closed other branch.

[sth0]

With that patch suggested in PR1237, it removes the test-getlogin error. But I get another error in the env-S module. Not sure what that is, but I list the first few, but there are another dozen similar failures. Weird to have that issue pop up. Will push patch suggested above.

FAIL: tests/env/env-S
=====================

env (GNU coreutils) 9.11
Copyright (C) 2026 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Richard Mlynarik, David MacKenzie, and Assaf Gordon.
1...
2...
3...
4...
5...
q1...
env-S.pl: test q1: stdout mismatch, comparing q1.1 (expected) and q1.O (actual)
*** q1.1        Sat Jul 18 16:55:54 2026
--- q1.O        Sat Jul 18 16:55:54 2026
***************
*** 1 ****
--- 1,2 ----
  A=B C
+ __CF_USER_TEXT_ENCODING=0x258:0:0
q2...
env-S.pl: test q2: stdout mismatch, comparing q2.1 (expected) and q2.O (actual)
*** q2.1        Sat Jul 18 16:55:54 2026
--- q2.O        Sat Jul 18 16:55:54 2026
***************
*** 1 ****
--- 1,2 ----
  A=B C
+ __CF_USER_TEXT_ENCODING=0x258:0:0
q3...
env-S.pl: test q3: stdout mismatch, comparing q3.1 (expected) and q3.O (actual)
*** q3.1        Sat Jul 18 16:55:54 2026
--- q3.O        Sat Jul 18 16:55:54 2026
***************
*** 1 ****
--- 1,2 ----
  A=B C
+ __CF_USER_TEXT_ENCODING=0x258:0:0

[beren12]

one other thing, the 8.32 uname in coreutils gives arm64 where the apple one returns arm, and it breaks most package's building if you have coreutils-default installed (I do)

[sth0]

Which Apple system versions? I see the “apple one” returning arm64. This is macOS 26.5.2 Tahoe on an M4 CPU and returns “arm64”(e). Maybe this is an argument to not install the coreutils-default package or just a reminder that it can cause these problems? % /usr/bin/uname -m arm64 % /usr/bin/machine arm64e % /usr/bin/arch arm64 %

…

On Jul 25, 2026, at 19:54, beren12 ***@***.***> wrote: beren12 left a comment (fink/fink-distributions#1244) <#1244 (comment)> one other thing, the 8.32 uname in coreutils gives arm64 where the apple one returns arm, and it breaks most package's building if you have coreutils-default installed (I do)

[nieder]

Ditto as @sth0 on macOS 26 (tahoe):
coreutils-8.32:

[Tahoe:~] nieder $ /opt/sw/bin/guname --version
uname (GNU coreutils) 8.32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.
[Tahoe:~] nieder $ /opt/sw/bin/guname -a
Darwin SW580883 25.5.0 Darwin Kernel Version 25.5.0: Tue Jun  9 22:28:29 PDT 2026; root:xnu-12377.121.10~1/RELEASE_ARM64_T6030 arm64 arm64 Mac15,6 Darwin
[Tahoe:~] nieder $ /opt/sw/bin/guname -m
arm64
[Tahoe:~] nieder $ /usr/bin/uname -a
Darwin SW580883 25.5.0 Darwin Kernel Version 25.5.0: Tue Jun  9 22:28:29 PDT 2026; root:xnu-12377.121.10~1/RELEASE_ARM64_T6030 arm64
[Tahoe:~] nieder $ /usr/bin/uname -m
arm64

Then updating to coreutils-9.11:

[Tahoe:~] nieder $ /opt/sw/bin/guname --version
uname (GNU coreutils) 9.11
Copyright (C) 2026 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.
[Tahoe:~] nieder $ /opt/sw/bin/guname -a
Darwin SW580883 25.5.0 Darwin Kernel Version 25.5.0: Tue Jun  9 22:28:29 PDT 2026; root:xnu-12377.121.10~1/RELEASE_ARM64_T6030 arm64 arm Darwin
[Tahoe:~] nieder $ /opt/sw/bin/guname -m
arm64

[sth0]

Bump? Any reason not to go ahead with this?

[TheSin-]

Coreutils is required for bootstrapping and IIRC it was touchy, was a FRESH bootstrap and an inject tested to make sure? My guess is that is the hold up as it's lots of work to test fresh, upgrade via inject and normal upgrade (Which I'm sure you did already).

[nieder]

Where's coreutils needed for bootstrapping? I have not run any tests with bootstrapping a clean install with coreutils-v$anything because I don't see it used in bootstrapping.

@beren12 mentioned some problem with uname and arm/arm64, but both @sth0 and myself can't replicate it.

[TheSin-]

sorry not core-utils directly, but part of it was separated for bootstrapping, dumpobj IIRC and should be kept in sync with the rest of it. I'm going off memory here as I rewrote the bootstrap over a decade ago for the dpkg 1.15+ branch which is now in master.

[nieder]

ahh. objdump is from our package objtools that's in the bootstrap tree in the Fink tarball, and that uses the GNU binutils tarball. Neither current coreutils-8.32 or coreutils-9.11 from here have anything called dumpobj or objtool.

So I think the only thing is figuring out @beren12 's discrepancy.

[sth0]

I haven't looked at the bootstrapping issue. Not sure where I would try to sync the coreutils in the boot strapping system. I was under the impression that all the packages for bootstrapping were in base. But maybe I am off on that assumption. There is debianutils in base.

[TheSin-]

@nieder had it right I was mistaken, I got the 2 utils confused, once he set it straight I remember that was the case. it's part of binutils not coreutils, so disregard what I said, I apologize.

[sth0]

No apology necessary, I have trouble remembering fixes done awhile ago as well. I was just trying to comply and get this merged and out of my local tree.