From: Collin Funk <collin.funk1@gmail.com>
To: Alexander Kanavin <alex.kanavin@gmail.com>
Cc: Etienne Cordonnier <ecordonnier@snap.com>,
openembedded-core@lists.openembedded.org,
Paul Barker <paul@pbarker.dev>,
Richard Purdie <richard.purdie@linuxfoundation.org>
Subject: Re: [OE-core] [PATCH] uutils-coreutils: move from meta-openembedded
Date: Tue, 13 Oct 2026 11:49:49 -0700 [thread overview]
Message-ID: <m1bj8x8mgi.fsf@gmail.com> (raw)
In-Reply-To: <CANNYZj-=7nx_DOHVxCvX6DSdgvK4K12-8RT+YR8H3KSrdb291Q@mail.gmail.com>
Alexander Kanavin <alex.kanavin@gmail.com> writes:
> Collin has explicitly said he is not endorsing the use of GNU tests for uutils.
Any implementation is free to use the GNU coreutils test suite, as long
as its licensing is respected, of course. It mostly just involves
fetching it from git, changing the PATH used by the tests to point to a
separate directory with the relevant binaries, and maybe applying some
patches for different error messages, for example. I don't think you
meant to imply otherwise, but I just wanted to make sure it wasn't
misinterpreted by other readers.
My comment was just to say that a high passing rate on the GNU coreutils
test suite doesn't necessarily mean two implementations are compatible.
A made-up example, based on some behaviors I have seen previously with
other programs, though I forget which, a test might check if 'shred'
checks for invalid file types by redirecting standard error to a file
here:
$ mkfifo fifo
$ shred fifo
shred: fifo: invalid file type
If one implementation uses open ("fifo", O_NONBLOCK | ...), and the
other uses statx, which I commonly see uutils do through std::fs
functions, then the behavior will be different on readers waiting for a
writer. The open will unblock the reader, while statx will not.
Behaviors like this aren't always tested, though; the GNU coreutils test
suite is always a work in progress. I have tried to improve the checks
for cases like this, but there are theoretically more niche cases that
could cause problems if behavior changes.
Collin
prev parent reply other threads:[~2026-10-14 5:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-10 11:30 [PATCH] uutils-coreutils: move from meta-openembedded ecordonnier
2026-10-10 18:33 ` Collin Funk
2026-10-11 16:23 ` [OE-core] " Yoann Congal
2026-10-12 13:04 ` Alexander Kanavin
2026-10-12 21:13 ` Etienne Cordonnier
2026-10-12 22:58 ` Collin Funk
2026-10-13 7:41 ` Alexander Kanavin
2026-10-13 8:13 ` Yoann Congal
2026-10-13 10:02 ` Etienne Cordonnier
2026-10-13 10:24 ` Alexander Kanavin
2026-10-13 10:54 ` Alexander Kanavin
2026-10-13 18:49 ` Collin Funk [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1bj8x8mgi.fsf@gmail.com \
--to=collin.funk1@gmail.com \
--cc=alex.kanavin@gmail.com \
--cc=ecordonnier@snap.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul@pbarker.dev \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.