| Summary: | Default ptest-runner invocation on multilib may not execute any test suites | ||
|---|---|---|---|
| Product: | [QA/Testing] Runtime Testing | Reporter: | Kyle Russell <bkylerussell> |
| Component: | general | Assignee: | Aníbal Limón <anibal> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | ndec13, randy.macleod, ross.burton, stephano |
| Version: | unspecified | ||
| Target Milestone: | 3.2 M1 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
(In reply to comment #0) > ptest.bbclass will package ptest scripts in ${libdir}, which may include > /usr/lib64 in some multilib configurations. However, ptest-runner is > hard-coded to look at /usr/lib by default, requiring an extra -d /usr/lib64 > to execute the default ptest-packaged test suites in these multilib > configurations. This means any automated infrastructure that wants to > invoke ptest-runner must be aware of the target architecture to instruct > ptest-runner where to find test cases installed by the default > arch-dependent ptest packages. Instead, it would be preferable for > ptest-runner to find the default ptest-packaged test suites independent of > the arch. > > I posted a naive fix to the mailing list to handle the default /usr/lib64 > case, though I realize it doesn't allow support for actual multilib test > suites (e.g. lib32-libfoo-ptest). > > https://lists.yoctoproject.org/pipermail/yocto/2018-February/039997.html > > Ross proposed fixing this in ptest-runner instead, but making ptest-runner's > DEFAULT_DIRECTORY defined by ${libdir} still doesn't allow ptest-runner to > automatically find multilib suites (e.g. lib32-libfoo-ptest) in a /usr/lib64 > configuration. > > It seemed to me that there were more comprehensive approaches that could be > taken to handle multilib setups > (https://lists.yoctoproject.org/pipermail/yocto/2018-February/040011.html), > so if we can converge on a solution here I'll be glad to workup and test out > some new patches. (Or I can just move the naive approach to ptest-runner.) My proposal is to add ptest-runner the ability to specify more than one directory in this case ptest.bbclass can setup multilib libdirs + default libdir. OE-Core recipe upgrade and oeqa case at, https://lists.openembedded.org/g/openembedded-core/topic/patch_1_2_ptest_runner/73336814 |
ptest.bbclass will package ptest scripts in ${libdir}, which may include /usr/lib64 in some multilib configurations. However, ptest-runner is hard-coded to look at /usr/lib by default, requiring an extra -d /usr/lib64 to execute the default ptest-packaged test suites in these multilib configurations. This means any automated infrastructure that wants to invoke ptest-runner must be aware of the target architecture to instruct ptest-runner where to find test cases installed by the default arch-dependent ptest packages. Instead, it would be preferable for ptest-runner to find the default ptest-packaged test suites independent of the arch. I posted a naive fix to the mailing list to handle the default /usr/lib64 case, though I realize it doesn't allow support for actual multilib test suites (e.g. lib32-libfoo-ptest). https://lists.yoctoproject.org/pipermail/yocto/2018-February/039997.html Ross proposed fixing this in ptest-runner instead, but making ptest-runner's DEFAULT_DIRECTORY defined by ${libdir} still doesn't allow ptest-runner to automatically find multilib suites (e.g. lib32-libfoo-ptest) in a /usr/lib64 configuration. It seemed to me that there were more comprehensive approaches that could be taken to handle multilib setups (https://lists.yoctoproject.org/pipermail/yocto/2018-February/040011.html), so if we can converge on a solution here I'll be glad to workup and test out some new patches. (Or I can just move the naive approach to ptest-runner.)