On 10/04/2023 22:52, Sam James wrote:
Sam James <s...@gentoo.org> writes:
Pádraig Brady <p...@draigbrady.com> writes:
We plan to release coreutils-9.3 in the coming week
so any testing you can do on various different systems
between now and then would be most welcome.
This is a bug fix release coming about 3 weeks after the 9.2 release.
--------------------------------------
You can download the coreutils snapshot in xz format (5.7 MB) from:
https://pixelbeat.org/cu/coreutils-ss.tar.xz
And verify with gpg or md5sum with:
https://pixelbeat.org/cu/coreutils-ss.tar.xz.sig
MD5 (coreutils-ss.tar.xz) = d208d306026fb42c128a787dffcba17a
--------------------------------------
To test follow this standard procedure:
tar -xf coreutils-ss.tar.xz
cd coreutils-9.2.18-ffd62/
./configure && make check VERBOSE=yes
Failures are reported, and details are in tests/test-suite.log
Please report/attach any issues to coreutils@gnu.org
I get one failure in tests/cp/backup-dir.sh inside our packaging:
I see now you've caught this as a non-portable shell construct & fixed -
thanks! So ignore this one, and see the failures below instead.
```
+ env cp --version
[...]
FAIL tests/cp/backup-dir.sh (exit status: 1)
```
These I can naturally still hit:
In another environment (same machine but this time running manually,
outside of our packaging, and on a ZFS filesystem instead of tmpfs),
I get two failures:
1. tests/cp/sparse-2.sh.log: http://sprunge.us/jOCSEr (unfortunately I
can't consistently reproduce this one)
This might be due to slightly different I/O patterns between cp and dd.
The log above suggests that cp is not inducing holes while dd is.
It would be useful to get both strace files from running the following on that
ZFS filesystem
cd coreutils-9.2.18-ffd62
printf x>k
dd bs=1k seek=1 of=k count=255 < /dev/zero
strace -e cp.strace src/cp --reflink=never --sparse=always k k2
hole_size=$(stat -c %o k2)
strace -o dd.strace src/dd if=k of=k2.dd bs=$hole_size conv=sparse
2. ./tests/misc/tty-eof.log: http://sprunge.us/yWNByM
perl's expect module seems to be getting spurious exitstatus for some commands.
I suspect a race, and there is a hardcoded 10s in that script.
There are various other issues in that script actually.
Hopefully the attached addresses this.
cheers,
Pádraig
From 08b6751e4cb4fbcb813d54a73c37142231ab4ee9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= <p...@draigbrady.com>
Date: Tue, 11 Apr 2023 13:02:21 +0100
Subject: [PATCH] tests: tty-eof: fix false failures and other issues
* tests/misc/tty-eof.pl: Ensure we don't erroneously
skip commands with parameters.
Comment as to why cut(1) is treated differently.
Adjust expect calls to not wait needlessly for cut output.
Increase timeout from 10 to 30 seconds to avoid spurious failures.
---
tests/misc/tty-eof.pl | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/tests/misc/tty-eof.pl b/tests/misc/tty-eof.pl
index d429cbb8f..926517a4a 100755
--- a/tests/misc/tty-eof.pl
+++ b/tests/misc/tty-eof.pl
@@ -69,17 +69,21 @@ $@
{
my $exp = new Expect;
$exp->log_user(0);
- $ENV{built_programs} =~ /\b$cmd\b/ || next;
+ my $cmd_name = (split(' ', $cmd))[0];
+ $ENV{built_programs} =~ /\b$cmd_name\b/ || next;
$exp->spawn("$cmd 2> $stderr")
or (warn "$ME: cannot run '$cmd': $!\n"), $fail=1, next;
- # No input for cut -f2.
+ # Test cut in a different mode, even though it supports the standard flow
+ # Ensure that it exits with no input as it used to not do so
$cmd =~ /^cut/
or $exp->send("a b\n");
$exp->send("\cD"); # This is Control-D. FIXME: what if that's not EOF?
- $exp->expect (0, '-re', "^a b\\r?\$");
- my $found = $exp->expect (1, '-re', "^.+\$");
+ $cmd =~ /^cut/
+ or $exp->expect (0, '-re', "^a b\\r?\$");
+ $cmd =~ /^cut/
+ or my $found = $exp->expect (1, '-re', "^.+\$");
$found and warn "F: $found: " . $exp->exp_match () . "\n";
- $exp->expect(10, 'eof');
+ $exp->expect(30, 'eof');
# Expect no output from cut, since we gave it no input.
defined $found || $cmd =~ /^cut/
or (warn "$ME: $cmd didn't produce expected output\n"),
--
2.26.2
