re-enabling statx support on coreutils

[ailiop-git]

Commit 9cd29dc ("coreutils: disable statx() support on glibc.") disabled detection of statx support as a workaround, due to the kernel>=v4.11 requirement that breaks travis.

Restoring statx support in coreutils would be nice, as stat (1) and ls are able to report inode birth times only via statx.

@xtraeme not sure what the plan with travis is, but would it make sense to create a base-minimal-travis that depends on a coreutils-compat (or something, maybe a subpkg) that disables statx? That way we can re-enable it on coreutils so that base-system is not impacted.

[ailiop-git]

so what is the issue with travis anyway? the config is pointing to bionic, which should run a recent enough kernel to support statx.

[ailiop-git]

I assume you meant https://travis-ci.org/github/void-linux/xbps/jobs/669154357.

Ok, so in that case can we just build xbps on travis with dist: bionic and get rid of the workarounds?

[ailiop-git]

https://travis-ci.org/github/ailiop-git/xbps/builds/669887920

[Johnnynator]

Just as a note, we still have linux3.16 and linux4.9. And I think coreutils should work with them, as long as we still provide them.

[pullmoll]

Perhaps create a coreutils-legacy package which disables the statx(2) check and is built at the same time?

[ailiop-git]

hmm do we have any testing on those older kernels? I'd suspect there may be further problems with glibc being built on newer kernels and autodetecting features that are not necessarily available on a 3.16 kernel for example.

[pullmoll]

I do not test the 3.16 kernel, just make sure it can be built. I don't actually know if we have any users of this version.

[pullmoll]

linux3.16 does not even boot on my (recent) hardware.
I'll try to catch any log but currently cannot test it here.

[ailiop-git]

3.16 doesn't seem to be booting at all (getting stuck in early boot process after decompress/parsing ELF, and/or cold-rebooting). I can try to debug it later on a VM if there's still interest in having this kernel around, let me know.

3.18, 4.9 boot fine, and coreutils doesn't complain with statx enabled (glibc silently fallsback to stat).

BTW 3.18 isn't LTS upstream (@pullmoll should we consider dropping it?)

[pullmoll]

Same here. I can not get a single log output :-P agree to remove
I wonder who requested it and never reported back that it didn't work.

I could boot it several versions back in the past, though.

[pullmoll]

@ailiop-git 3.18? We don't have that or do we?
3.16 worked when I added it and perhaps a couple of version more.
@xtraeme ok, then let's merge @ailiop-git PR.

[ailiop-git]

same on glibc, i suppose infra needs a xbps-rindex -c crontab or something along those lines.

[pullmoll]

In case I wouldn't clean my repo on each update, I'd see ENOSPC more often.
Currently I am at 917GB of binary packages for all arches and the noarch branch ... yay.

[pullmoll]

@xtraeme go ahead.

[ailiop-git]

Linux ash 4.4.215_1 #1 SMP PREEMPT Sun Mar 1 08:34:51 UTC 2020 x86_64 GNU/Linux

$ strace -fe statx,fstat stat -t /
statx(AT_FDCWD, "/", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_ALL, 0x7fff1d37dda0) = -1 ENOSYS (Function not implemented)
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(0x88, 0), ...}) = 0
/ 4096 8 41ed 0 0 801 2 17 0 0 1585834498 1582119865 1582119865 0 4096
+++ exited with 0 +++

Linux ash 4.9.215_1 #1 SMP PREEMPT Sun Mar 1 08:33:53 UTC 2020 x86_64 GNU/Linux

$ strace -fe statx,fstat stat -t /
statx(AT_FDCWD, "/", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_ALL, 0x7fff1d37dda0) = -1 ENOSYS (Function not implemented)
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(0x88, 0), ...}) = 0
/ 4096 8 41ed 0 0 801 2 17 0 0 1585834498 1582119865 1582119865 0 4096
+++ exited with 0 +++

Linux ash 5.4.23_1 #1 SMP PREEMPT Sat Feb 29 10:14:39 UTC 2020 x86_64 GNU/Linux

$ strace -fe statx stat -t /
statx(AT_FDCWD, "/", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_ALL, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFDIR|0755, stx_size=4096, ...}) = 0
/ 4096 8 41ed 0 0 801 2 17 0 0 1585834498 1582119865 1582119865 1524685643 4096
+++ exited with 0 +++

@xtraeme looks OK, falling back to fstat in both 4.{4,9} (same stat binary, compiled against latest glibc on 5.4, statx enabled).