Releases retrieved: 9.8 Upstream release that is considered latest: 9.8 Current version/release in rawhide: 9.7-5.fc43 URL: https://www.gnu.org/software/coreutils/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/343/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/coreutils
Created attachment 2107292 [details] Update to 9.8 (#2397467)
Note when merging the I18N patch, you can drop all the fold changes and tests I think, as fold upstream is now multi-byte aware and incorporates all the existing I18N tests (and more).
the-new-hotness/release-monitoring.org's scratch build of coreutils-9.8-1.fc40.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=137388108
PR: https://src.fedoraproject.org/rpms/coreutils/pull-request/18 I also plan to execute tests from the RH's internal repository before merging. BTW, I have a plan to open source those tests in the CentOS Stream tests namespace: https://gitlab.com/redhat/centos-stream/tests/. Hopefully, I'll get to that soon...
The tests have finished and there are two failures but none of them is directly caused by this update. They can be reproduced on Fedora 42 with the v9.6 release as well. Therefore, I'm going to merge the PR tomorrow. * `who -r` displays nothing when the systemd utmp back-end is in use (default since F42) * `cp --preserve=xattr a b` now fails when both source and destination are on a NFSv4 share exported without the `security_label` option. After some fix in kernel, `listxattr(3)` now lists `security.selinux` but this attribute cannot be set because it is apparently read-only and synthesised by the kernel: # strace -s 100 --trace='/xattr' cp --preserve=xattr a b flistxattr(3, NULL, 0) = 33 flistxattr(3, "system.nfs4_acl\0security.selinux\0", 33) = 33 fgetxattr(3, "system.nfs4_acl", NULL, 0) = 80 fgetxattr(3, "system.nfs4_acl", "\0\0\0\3\0\0\0\0\0\0\0\0\0\26\1\207\0\0\0\6OWNER@\0\0\0\0\0\0\0\0\0\0\0\22\0\201\0\0\0\6GROUP@\0\0\0\0\0\0\0\0\0\0\0\22\0\201\0\0\0\tEVERYONE@\0\0", 80) = 80 fsetxattr(4, "system.nfs4_acl", "\0\0\0\3\0\0\0\0\0\0\0\0\0\26\1\207\0\0\0\6OWNER@\0\0\0\0\0\0\0\0\0\0\0\22\0\201\0\0\0\6GROUP@\0\0\0\0\0\0\0\0\0\0\0\22\0\201\0\0\0\tEVERYONE@\0\0", 80, 0) = 0 fgetxattr(3, "security.selinux", NULL, 0) = 27 fgetxattr(3, "security.selinux", "system_u:object_r:nfs_t:s0", 27) = 27 fsetxattr(4, "security.selinux", "system_u:object_r:nfs_t:s0", 27, 0) = -1 EOPNOTSUPP (Operation not supported) cp: setting attributes for 'b': Operation not supported Well, the error itself is correct, `fsetxattr` failed, and `--preserve=mode` can be used as a workaround if the reason for using `--preserve=xattr` were NFSv4 ACLs, but it still looks quite annoying. The destination file will have `system_u:object_r:nfs_t:s0` synthesised anyway so despite the error it will end up with the same xattrs as the source... I'll create separate Fedora tickets for these tomorrow.
FEDORA-2025-d98e6c2044 (coreutils-9.8-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2025-d98e6c2044
FEDORA-2025-d98e6c2044 (coreutils-9.8-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
* `who -r` - tracked in bz#2397781, closed as won't do because concept of runlevels in general was removed in systemd 258 which has just landed in F43 and Rawhide * copy with xattrs on NFSv4 - tracked in bz#2397782