Re: FIP test results
Joe, All,
yes Mats is right to advise use of the vrpt tool, which
produces slightly better output.
FIP results are generally produced when the test suite was unable to
determine a test result for itself. Any references such
as
Posix Ref: Component TAR Assertion 10.1.1-17(A)
Reference 3.7-24(C) (for FHS tests)
refer to the test specification, and the assertion number within the
specification. Test specs, man pages and assertions should be located
under the MAN/tset directory.
I attach some examples with commentary below, from a journal i produced
(slightly edited for anonymity)
FIP Results Signatures
______________________
/tset/POSIX.os/dataform/tar/T.tar 12
Test Description:
If the linkname does not fit in the space provided (100 characters)
the format-creating utility shall not attempt to store the link on the
medium.
Posix Ref: Component TAR Assertion 10.1.1-17(A)
Test Information:
create utility exited with code 1
Signature/Date ____________________________________
The tar tests call an intermediate shell script for creating tar format
archives. I believe that the script is using pax and is putting out a
diagnostic in this case and since to pax thats an error, it exits with
the exit status >0
/tset/POSIX.os/procenv/uname/T.uname 1
Test Description:
Information identifying the current operating system is stored in the
structure pointed to by name and a non-negative value is returned by
uname(name).
Posix Ref: Component UNAME Assertion 4.4.1.2-04(A)
(note i have hidden the system info here)
Test Information:
system name - Linux
node name - censored
release - censored
version - censored
machine - i686
Signature/Date ____________________________________
It's always possible uname could be putting out rubbish, so you sign
off that its output is correct
/tset/LSB.fhs/root/etc/etc-tc 24
Test Description:
Test Information:
Reference 3.7-24(C)
If the implementation supports the subsystem
The implementation provides the file /etc/gateways
/etc/gateways: file not found
exit code 1 returned, expected 0
This test result needs to be manually resolved, returning FIP result
Signature/Date ____________________________________
For FHS, there are a number of optional files only required "if the
subsystem is installed", hence they return a FIP if not found
requiring a signoff
/tset/LSB.fhs/root/etc/etc-tc 38
Test Description:
Test Information:
Reference 3.7-38(C)
If the system supports the subsystem
the /etc/sgml directory exists and is searchable
/etc/sgml: directory not found
exit code 1 returned, expected 0
This test result needs to be manually resolved, returning FIP result
Signature/Date ____________________________________
ditto for FHS
/tset/LSB.fhs/root/sbin/sbin-tc 5
Test Description:
Test Information:
Reference 3.14-5 (C)
The implementation may provide an exec-able version of the update
utility in the /sbin directory.
/sbin/update not found.
This test result needs to be manually resolved, returning FIP result
Signature/Date ____________________________________
On reflection perhaps based on this assertion (which is a may provide)
this should just give another result code rather than FIP. For now
it needs signoff to say you do not provide /sbin/update.
/tset/LSB.fhs/var/spool-lpd/spool-lpd-tc 2
Test Description:
Test Information:
Reference 5.14.3-2(C)
If the implementation has the lpd daemon running then
The lock file /var/spool/lpd/lpd.lock exists
/var/spool/lpd/lpd.lock: file not found
exit code 1 returned, expected 0
This test result needs to be manually resolved
Signature/Date ____________________________________
A reason to sign this one of is either no lpd daemon running,
or you use a print subsystem other than lpd
/tset/LSB.os/procenv/chroot/T.chroot 4
Test Description:
Test Information:
execve() of ./chroot_t4 failed - errno 2 (ENOENT)
Signature/Date ____________________________________
There ought to be more information put out by this test
case, and thats something that should be fed back into the source
for the next maintenance update. This relates to a chroot() call in a
shared library environment, and can be signed off if that is the
cause.
So in the certification system you need to complete the FIP table
in
http://www.opengroup.org/lsb/cert/docs/certprimer/img41.html
selecting Yes as appropriate, and including a very brief reason
if necessary (e.g. for tar.12 pax used).
regards
Andrew
On Jul 30, 11:00am in "RE: FIP test results", Wichmann, Mats D wrote:
>
> > I have been trying to resolve 12 FIP test results that occurred when
> > running the LSB runtime tests. There does not seem to be
> > much information about how to resolve these on either your web site, the
> LSB
> > certification authority's web site, or any of the LSB documents I can
> find.
> > After a few email exchanges with the LSB certification authority,
> > they suggested
> > I contact you.
>
> What are the 12 FIPs? It's hard to help without seeing them....
>
> > I cannot find any information about how to determine what the
> > test that
> > gave the FIP result was trying to do and therefore how to properly
> > resolve a FIP result as PASS or FAIL.
>
> Normally, running vrpt against the journal file generated by
> the test run should give you the assertion and test method
> along with the test result, when that result is not PASS.
> In many cases, if that information is available, it should
> answer the question you raise.
>
> I think the default report created by the test script does
> not include this information, so you might try this as a
> next step.
>
Reply to: