On Monday 09 December 2013 14:51, Michael Tokarev wrote:
Here are a few tests from the testsuite which fails on debian-hurd and
debian-kfreebsd.
pidof this does not print its own pid on hurd or freebsd
testing pidof this pidof pidof.tests | grep -o -w $$ $$\n
most likely the process is named 'sh pidof.tests', not pidof.tests
This test fails on both kfreebsd and hurd systems - it does not print
its own pid, `pidof pidof.tests' prints nothig.
I don't know how thse systems expose process names / argv / executable names.
Do they have comm field concept?
For shell scripts, only process name - meaning comm field -
allows to identify shell script.
argv[0] and /proc/PID/exe lead to /bin/sh.
kfreebsd: group on files is inherited from parent dir. cpio tests fail.
FAIL: cpio extracts zero-sized hardlinks
--- expected
+++ actual
@@ -1,4 +1,4 @@
1 blocks
0
--rw-r--r-- 2 2952 1009 0 x
--rw-r--r-- 2 2952 1009 0 y
+-rw-r--r-- 2 2952 112 0 x
+-rw-r--r-- 2 2952 112 0 y
Mabe remove (using sed, in $FILTER_LS) the group column for testing?
Note the same may happen on linux too, depending on the filesystem in
use and even filesystem mount options (-o grpid or -o bsdgroups for a
few linux filesystems).
You mean, gid of hardlinks? IIRC cpio should restore gid of regular files,
no?
Can you confirm this works?
optional FEATURE_LS_SORTFILES FEATURE_LS_TIMESTAMPS
testing cpio extracts zero-sized hardlinks \
$ECHO -ne '$hexdump' | bzcat | cpio -i 21; echo \$?;
ls -ln cpio.testdir | $FILTER_LS | cut -d' ' -f 1-3,5- \
^^ add this
\
1 blocks
0
-rw-r--r-- 2 $user $group 0 x
-rw-r--r-- 2 $user $group 0 y
SKIP=
du tests fail on kfreebsd filesystems:
du-k-works
16+64Kb files in a dir, `du -k .' is expected
to be one of 80, 84 or 88, actual is 82.
du-l-works - same issue,
result expected to be 144, 148, 152 or 156, actual is 146
I'm not sure why these sizes are multiple of 4Kb. As you can see,
on a bsd system the directory size is different. Maybe any number
between, say, 80 and 88 should be ok?
I prefer to add only numbers which were actually seen.
Fixed in git, thanks!
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
