This test failed on one of the debian buildds[1] like this:
Running popen.test
Backtrace:
4 (primitive-load
"/build/reproducible-path/guile-3.0-3.0.10+really3.0.10/test-suite/tests/ports.test")
In ice-9/eval.scm:
619:8 3 (_ #(#(#<directory (test-suite test-ports) 7fff9a860460>
"/build/reproducible-path/guile-3.0-3.0.10+really3.0.10/ports-test.tmp")
#<closed: file 7fff959be8c0>))
619:8 2 (_ #(#(#(#<directory (test-suite lib) 7fff9a8d80a0> #<variable
7fff9a90a5d0 value: #t>) "SEEK_DATA while in hole" #t #<procedure 7fff95a17c80
at ice-9/eval.scm:330:13 ()>) ("ports.test" "SEEK_DATA while in hole")))
In ice-9/boot-9.scm:
260:13 1 (for-each #<procedure 7fff95a17240 at ice-9/eval.scm:333:13 (a)>
_)
In ice-9/eval.scm:
619:8 0 (_ #(#(#<directory (test-suite lib automake) 7fff9a860820> (fail
("ports.test" "SEEK_DATA while in hole") expected-value 4096 actual-value 10))))
ice-9/eval.scm:619:8: Throw to key `match-error' with args `("match" "no
matching pattern" (fail ("ports.test" "SEEK_DATA while in hole") expected-value
4096 actual-value 10))'.
Running ports.test
FAIL: ports.test: SEEK_DATA while in hole - arguments: (expected-value 4096
actual-value 10)
I suspect it's because that buildd is running in an unshare/chroot with
a filesystem that just doesn't support the seek data/hole semantics we
expect, and it sounds like returning the seek offset (here 10) is
allowed (at least by Debian's lseek(2)):
In the simplest implementation, a filesystem can support the
operations by making SEEK_HOLE always return the offset of the end of
the file, and making SEEK_DATA always return offset (i.e., even if the
location referred to by offset is a hole, it can be considered to
consist of data that is a sequence of zeros).
How we might want to fix this depends of course on exactly what the test
is trying to verify, but if it's trying to verify that Guile's functions
work properly when the filesystem does support the semantics we expect,
then we could consider limiting the tests to relevant filesystems
(e.g. ext4, ...).
In that case, while I don't know of a simple way to detect the type of
the test filesystem, if it's useful, bup currently uses this to handle
some platforms
(https://codeberg.org/bup/bup/src/branch/main/dev/path-fs):
#!/usr/bin/env bash
set -ueo pipefail
kernel="$(uname -s)"
case "$kernel" in
NetBSD)
fs() { df -G "$1" | sed -En 's/.* ([^ ]*) fstype.*/\1/p'; }
;;
SunOS)
fs() { df -g "$1" | sed -En 's/.* ([^ ]*) fstype.*/\1/p'; }
;;
*)
fs() { df -T "$1" | awk 'END{print $2}'; }
esac
while test $# -ne 0; do
fs "$1"
shift
done
[1] From
https://buildd.debian.org/status/fetch.php?pkg=guile-3.0&arch=ppc64el&ver=3.0.10%2Breally3.0.10-1&stamp=1736918931&raw=0
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
