Current-Users archive

[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 detail.)

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

Home | Main Index | Thread Index | Old Index