Summary: | net-misc/ntp-4.2.8_p17 fails tests on 32-bit: test_DevLinks:FAIL: could not validate '/proc/kcore' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | matoro <matoro_gentoo> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | matoro_gentoo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 471102, 909110 | ||
Attachments: |
build.log and emerge --info
ls -l /proc |
Description
matoro
2024-01-19 16:40:10 UTC
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(-) |