[Beaker-devel] Test framework for lshw

Amit Saha asaha at redhat.com
Thu Aug 1 02:18:03 UTC 2013



----- Original Message -----
> From: "Nick Coghlan" <ncoghlan at redhat.com>
> To: beaker-devel at lists.fedorahosted.org
> Sent: Thursday, August 1, 2013 12:02:19 PM
> Subject: Re: [Beaker-devel] Test framework for lshw
> 
> On 08/01/2013 10:00 AM, Dan Callaghan wrote:
> > Excerpts from Nick Coghlan's message of 2013-08-01 09:57:14 +1000:
> >> On 07/31/2013 09:34 PM, Amit Saha wrote:
> >>> However, with this approach I think the difficulty is to run tests for
> >>> all archs (that we have in testdata)
> >>> on any arch. That is, I cannot run test the functionality of lshw with
> >>> arm test data on a x86_64
> >>> system and vice-versa. The reason being, lshw uses compiler macros
> >>> heavily during the compilation process
> >>> and hence the lshw executable has to be built on the arch on which it is
> >>> to be tested. [1]
> >>>
> >>> [1] http://sourceforge.net/p/predef/wiki/Architectures/
> >>>
> >>> Thoughts and suggestions?
> >>
> >> Given the arch specific binaries, wouldn't we have the same architecture
> >> dependence problem with any other means of injecting test data for the
> >> "wrong" platform?
> >>
> >> This means I'm still inclined to run with the chroot based testing.
> >> Local testing during development would cover x86_64, and then we can
> >> spin up a job in beaker-devel to make sure it works across all supported
> >> architectures.
> > 
> > Beaker is probably overkill for this. The test suite should only run
> > tests for arch it is running on, then we should set up the tests to run
> > in %check during RPM build. That way all the tests will be run when Brew
> > builds for every arch.
> > 
> > The downside is that the only way to run all tests is to submit a Brew
> > scratch build (which is still lighter weight than a Beaker job though).
> 
> Added bonus is that it will be easy for Fedora to run the tests
> cross-platform (through koji), regardless of whether or not I can talk
> them into setting up a Beaker instance :)
> 
> However, if the test is going to be in %check, I believe we will need to
> do the work to get the dynamically linked version running in the chroot.

I was thinking of following a similar approach to what I posted earlier, but available 
to be run as a Makefile target with the necessary modifications as needed. Any particular 
reason you think static won't work for that? 

That said, I resorted to static because of lack of being able to find a simple 
way to find the shared libraries that lshw would be using along with their paths.

ldd gives this:

$ ldd /usr/sbin/lshw 
        linux-vdso.so.1 =>  (0x00007fff8bdaf000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x000000360e400000)
        libsqlite3.so.0 => /lib64/libsqlite3.so.0 (0x0000003631600000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x000000360ec00000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000360d800000)
        libc.so.6 => /lib64/libc.so.6 (0x000000360c000000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x000000360cc00000)
        libdl.so.2 => /lib64/libdl.so.2 (0x000000360c800000)
        libm.so.6 => /lib64/libm.so.6 (0x000000360c400000)
        /lib64/ld-linux-x86-64.so.2 (0x000000360bc00000)

awk won't work here, since the lines vary in their fields.
ldd has a verbose flag  (-v) which does spit out complete paths of the shared
libraries, but it is not very friendly for machine reading.

So, if there is a simple and sure shot way to find the shared libraries
along with their paths, setting them up in chroot is not a problem.

Best,Amit.

> 
> Cheers,
> Nick.
> 
> --
> Nick Coghlan
> Red Hat Infrastructure Engineering & Development, Brisbane
> 
> Testing Solutions Team Lead
> Beaker Development Lead (http://beaker-project.org/)
> _______________________________________________
> Beaker-devel mailing list
> Beaker-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
> 

-- 
Amit Saha <http://echorand.me>
Infrastructure Engineering and Development
Red Hat, Inc.


More information about the Beaker-devel mailing list