Re: HEADS UP: atf-0.14 imported

[Julio Merino <jmmv%NetBSD.org@localhost>]

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:
>
> http://www.whooppee.com/~paul/amd64-results/
> http://www.whooppee.com/~paul/amd64-results/1991_atf.html#failed-tcs-summary
>
> Namely:
>
>         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