LSB-si status from Mats
Here are my current results.
I have not updated to the latest CVS yet.
I'm doing bits incrementally due to the
extremely long rebuild time for the SI as
well as running the full test suite. There's
some chance that these results would "regress"
when run through the full cycle, but I'll
cross that bridge if I come to it.
Remember that an LSB-si running in a chroot must
run on top of a conforming kernel, which I have
for ia32, and don't have for ia64, although in
the latter case I'm building a kernel which applies
all fixes I know about.
========================================
LSB-si/ia32: with Anthony Towns' fix to mprotect,
the hang is gone.
Total failures: 1
T.msync 7 claims that the sequence: mmap 1 page,
msync 2 pages at address returned by mmap does not
fail when it should. This is one that behaves
as the test expects on the same system running
natively, and could be either a library change
(which I can't spot) or another test-interaction
problem like the mprotect test was (I can't spot
that, either).
========================================
LSB-si/ia64: 10 unexplained fails, which follow
with some analysis.
All other problems have either an unofficial fix, or
at least an explanation such as needing the right
number of address space pages. It's possible that
some of these cannot easily be converted into pass,
for example, the readv/writev tests attempt to test
overflow of an ssize_t but the algorithm would require
constructing an array of 1024 iovectors with size
9,007,199,254,742,016 bytes each. This works for the
readv test, but the writev test has to allocate space
for at least one of those, and strangely enough the
malloc didn't work.... (grin)
A few of the fixes match accepted TSD (Test Suite
Deficiency) rulings, but this is not true for all.
dlopen 4, 12 (2 fails total), appears that dlopen
(0, RTLD_NOW) does not give access to the binary's
own symbols. This might be a linker flag, but adding
it didn't seem to help; it might be a problem actually
in the libc dlopen code or the dynamic linker, I
see there have been lots of changes to this codebase
in the glibc cvs.
utime 4, 7, 11 (3 fails total), error return is EPERM
on several tests where this is not expected. On 4 and
7 there's an EPERM where no error is expected, on
11 the fail is EPERM instead of expected EACCES.
read and readv test 13 (2 fails total) - atime not
updated when it was expected to. This is *not*
the problem of failing to mount the filesystems
correctly, as other tests would fail with this error
if it were.
write and writev 16 (2 fails total), return failure
and ENOSPC when not expected. These tests are
attempting to check proper return when running out
of space, but are expecting to see a partial write
return instead of -1/ENOSPC, which should only
happen if no bytes can be written. Could potentially
be a kernel issue.
grantpt 1 (1 fail), this is running with a pseudo
filesystem mounted on /dev/pts, and detects the
unexpected presence of group-write permission on
the pty it tests. The same test passes on LSB-si/ia32,
might be something in the underlying kernel.
Reply to: