This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Clearify running testsuite as part of patch submission


> 1) resolv/tst-leaks.2 nss/bug-erange.c posix/bug-ga2.c
> 
>    Requires enough network connectivity to do a DNS lookup
>    on www.gnu.org
>
> 4) sunrpc/tst-getmyaddr.c
> 
>    Requires at least one non-loopback IP address configured
>    on the system.

These are in the category of things that every developer is going to be
able to do.  (If they can't do it at a particular moment, they're going to
be able to do it sometime before they can push their commits.)  But
automated builds may well be isolated such that they cannot.  (I think
Fedora's package builds cannot, for example.)

This is exactly the sort of thing for which xcheck was originally intended.

> 5) sunrpc/thrsvc.c
> 
>    Requires loopback to be up and operational with IP address
>    127.0.0.1

I suspect that even isolated builder robots can always do this.
But I'm not positive.

> 6) iconv/test-iconvconfig
> 
>    Requires an existing gconv-modules.cache to be installed
>    under $(inst_gconvdir)

This would seem to be in the category of things for which installcheck
exists in the GNU standards.  That is, it actually requires that 'make
install' has already been done, because it tries to verify that what's
already there exactly matches what the program to be installed creates.

But 'make install' doesn't actually run iconvconfig.  (Perhaps it should,
though in practice people are almost always doing packaging and so wouldn't
package the results anyway.)  If it did, this doesn't seem like it would be
an especially useful test--it would just verify that running the same thing
twice produces the same output.

As it stands, it's presuming that the set of modules previously installed
is exactly the same set the new libc build will install.  So if that set
changed from the libc version last installed on the system, then the test
wouldn't pass.

This seems like a pretty worthless test overall.  But it would be good to
have some test of iconvconfig that doesn't have these issues.

> 2) nptl/tst-setuid1.c and nptl/tst-setuid1-static.c
> 
>    Requires user "nobody" in /etc/passwd or similar, and the
>    ability as the current user to setuid to it.
> 
> 3) nptl/tst-mutexpp1.c nptl/tst-mutexpp6.c nptl/tst-mutexpp10.c
> 
>    Requires enough privileges to set mutex priority ceiling via
>    pthread_mutexattr_setprioceiling

These are things that require special privileges that ordinarily are never
appropriate circumstances in which to be running make.  They might be put
in a special class of things that the test harness runs via sudo or
something like that.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]