This is a weird one, at first from the error message I thought it was trying to parse /proc/kcore and failing due to being in 32-bit chroot on 64-bit kernel, but after digging in further all the relevant test is trying to do is call realpath(3) on /dev/core and is failing to do so for some reason? Reproduces on x86, arm, ppc. =============================================== ntp 4.2.8p17: tests/libntp/test-suite.log =============================================== # TOTAL: 42 # PASS: 41 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: test-realpath =================== realpath.c:48:test_CurrentWorkingDir:PASS realpath.c:90:test_DevLinks:FAIL: could not validate '/proc/kcore' ----------------------- 2 Tests: 1 PASS 0 XFAIL 1 Failures 0 XPASS 0 Ignored FAIL FAIL test-realpath (exit status: 1) Reproducible: Always
Created attachment 882633 [details] build.log and emerge --info
Is /dev/core a symlink to /proc/kcore? Is /proc mounted in the chroot? Does /proc/kcore exist?
Anyway, this test should not block stabilization.
(In reply to Mike Gilbert from comment #2) > Is /dev/core a symlink to /proc/kcore? > > Is /proc mounted in the chroot? > > Does /proc/kcore exist? Yes yes and yes. It's the exact same script used for the 64-bit arches where it passes. Why would it not block stabilization if the test suite is failing on these arches? Or do you mean they should be de-stabilized?
(In reply to matoro from comment #4) > Why would it not block stabilization if the test suite is failing on these arches? The test is for a function that does not appear to be critical at all. Could you please see if the same test fails with the previous stable version of ntp? I doubt this is a regression, and is probably some issue with the chroot environment.
While chrooted in one of these 32-bit environments, please run the following: ls -l /proc stat /proc/kcore
I'll bet this is a large file (LFS) issue, and the lstat call in the test code is failing. For example, on amd64: % ls -l /proc/kcore -r-------- 1 root root 140737471594496 Jan 13 17:55 /proc/kcore % cat lstat.c #include <stdio.h> #include <sys/stat.h> int main(int argc, char **argv) { struct stat st; if (lstat("/proc/kcore", &st)) { perror("lstat"); } return 0; } % gcc -m32 -o lstat lstat.c % ./lstat lstat: Value too large for defined data type
Created attachment 882658 [details] ls -l /proc Shockingly, after testing this actually IS a regression from current stable. File: /proc/kcore Size: 277851165175808 Blocks: 0 IO Block: 1024 regular file Device: 0,71 Inode: 4026532013 Links: 1 Access: (0400/-r--------) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2024-01-19 18:56:44.249515196 -0000 Modify: 2024-01-19 18:56:44.249515196 -0000 Change: 2024-01-19 18:56:44.249515196 -0000 Birth: -
(In reply to Mike Gilbert from comment #7) > I'll bet this is a large file (LFS) issue, and the lstat call in the test > code is failing. > > For example, on amd64: > > % ls -l /proc/kcore > -r-------- 1 root root 140737471594496 Jan 13 17:55 /proc/kcore > > % cat lstat.c > #include <stdio.h> > #include <sys/stat.h> > > int main(int argc, char **argv) > { > struct stat st; > if (lstat("/proc/kcore", &st)) > { > perror("lstat"); > } > return 0; > } > > % gcc -m32 -o lstat lstat.c > > % ./lstat > lstat: Value too large for defined data type Confirmed, append-lfs-flags fixes it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c5edccbad0938ae34955e08948273cc890098a8f commit c5edccbad0938ae34955e08948273cc890098a8f Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2024-01-19 19:20:20 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2024-01-19 19:22:06 +0000 net-misc/ntp: enable LFS Closes: https://bugs.gentoo.org/922508 Signed-off-by: Mike Gilbert <floppym@gentoo.org> net-misc/ntp/{ntp-4.2.8_p17.ebuild => ntp-4.2.8_p17-r1.ebuild} | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
