----- Original Message -----
From: "Nick Coghlan" <ncoghlan(a)redhat.com>
To: beaker-devel(a)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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
--
Amit Saha <
http://echorand.me>
Infrastructure Engineering and Development
Red Hat, Inc.