[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