[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: HEADS UP: atf-0.14 imported
On 6/15/11 4:03 AM, Jukka Ruohonen wrote:
On Tue, Jun 14, 2011 at 04:34:03PM +0100, Julio Merino wrote:
ATF 0.14 has just been imported into NetBSD-current. This update is
pretty minor and should not cause any problems. However, if you
experience any glitches, please let me know.
The amount of failed test cases doubled since the import:
atf/atf-run/integration_test : timeout_forkexit
lib/libc/net/getaddrinfo/t_getaddrinfo : unspported_family
lib/libc/stdlib/t_getopt : getopt
lib/libc/stdlib/t_getop : getopt_long
lib/libc/ssp/t_ssp : gets
lib/librumphijack/t_vfs : blanket
util/sort/t_sort : kflag_no_end
util/sort/t_sort : plus_tflag
I took a quick look and can't conclude that any of these failures is
atf's fault. (Not saying that they aren't, but I need to look in more
The one broken test that is really introduced by atf 0.14 is the
librumphijack/t_vfs breakage. But this seems caused by invalid
semantics on the librumphijack side: atf is expecting that an open of a
fd after closing stdin should return a fd == 0, so the code triggers an
assertion. I _think_ this is a valid assertion to make, isn't it? Is
librumphijack misbehaving here?
At least the shell-based tests are likely failing because of ATF itself.
What makes you think that?
Julio Merino / @jmmv
Main Index |
Thread Index |