When executing the test phase of sys-apps/selinux-python (versions 2.9, 3.0) I encountered multiple errors. Here is a list of them and how I got the test phase finally working (one problem per comment).
The first error was make[1]: Entering directory '/var/tmp/portage/sys-apps/selinux-python-3.0/work/selinux-python-3.0/sepolicy' Traceback (most recent call last): File "test_sepolicy.py", line 117, in <module> import selinux ImportError: No module named 'selinux' I tracked it down that the Makefile sepolicy/Makefile uses "python" as python interpretor which in my case was a version which did not have the selinux module installed (i.e. to reproduce your default python version must not have the selinux module). Looking into the ebuild and comparing (the default) src_test() with the other functions, revealed that src_test() does not set up the python environment at all. Adding the following src_test() to the ebuild worked for me (until I hit the next error - stay tuned for part 2): src_test() { testing() { emake -C "${BUILD_DIR}" \ test } python_foreach_impl testing }
Then I encountered: make[1]: Entering directory '/var/tmp/portage/sys-apps/selinux-python-3.0/work/selinux-python-3.0-python3_6/audit2allow' secilc -o test_dummy_policy -f /dev/null test_dummy_policy.cil make[1]: secilc: Command not found Indeed secilc was not installed. It is provided by sys-apps/secilc but that package is not a (test) dependency of sys-apps/selinux-python. Adding something like SECILC_VER="${PV}" [...] IUSE="test" [...] DEPEND=... test? ( >=sys-apps/secilc-${SECILC_VER} ) solved the problem. And now for the finale.
Lastly I hit Verify that xperms generation works ... Traceback (most recent call last): File "./audit2allow", line 381, in <module> app.main() File "./audit2allow", line 369, in main self.__output() File "./audit2allow", line 326, in __output g.set_gen_xperms(True) AttributeError: 'PolicyGenerator' object has no attribute 'set_gen_xperms' FAIL ====================================================================== FAIL: test_xperms (__main__.Audit2allowTests) Verify that xperms generation works ---------------------------------------------------------------------- Traceback (most recent call last): File "test_audit2allow.py", line 64, in test_xperms self.assertTrue(b"allowxperm" in out) AssertionError: False is not true ---------------------------------------------------------------------- For this to reproduce you need >=selinux-python-2.9 *not* be installed on the system (because the missing function set_gen_perms() was introduced in 2.9). I tracked it down to: selinux-python consists of multiple subprojects which have some interdependencies (the above error is from audit2allow needing sepolgen). But at test time none of these are installed, so the python process started by the test suite cannot find the (new) modules which are about to get installed. (If you happen to have old versions of the modules installed on the system you wont trigger this error unless the old version is behaviour incompatible with the new one.) That I solved by meddling with PYTHONPATH to include all the paths to the sources of the subprojects during test time: src_test() { testing() { emake -C "${BUILD_DIR}" \ test # The different subprojects have some interproject dependencies: # - audit2allow depens on sepolgen # - chcat depends on semanage # and maybe others. # Add all the modules of the individual subprojects to the # PYTHONPATH, so they get actually found and used. In # particular, already installed versions on the system are not # used. for dir in audit2allow chcat semanage sepolgen/src sepolicy ; do PYTHONPATH="${BUILD_DIR}/${dir}:${PYTHONPATH}" done # Use the constructed PYTHONPATH in the make command. PYTHONPATH=${PYTHONPATH} \ emake -C "${BUILD_DIR}" \ test } python_foreach_impl testing } As noted in the comment above, I found two intersubproject dependencies. There might be more because I stopped looking after these two and decided to add all paths whether they are needed or not. That might or might not be more or less future-prove. There might be a more elegant solution to this problem but that's how far I came and when the test suite finally passed successfully.
Created attachment 629092 [details] Updated ebuild as described above for selinux-python
Still applies to sys-apps/selinux-python-3.1-r2
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b49e9b2821afc2f102fd44879871718c31080c04 commit b49e9b2821afc2f102fd44879871718c31080c04 Author: Jonathan Davies <jpds@protonmail.com> AuthorDate: 2021-07-07 13:16:06 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-07-19 22:21:28 +0000 sys-apps/selinux-python: Fixed tests, thanks to Arie Artrip. Closes: https://bugs.gentoo.org/715924 Closes: https://bugs.gentoo.org/741930 Signed-off-by: Jonathan Davies <jpds@protonmail.com> Closes: https://github.com/gentoo/gentoo/pull/21550 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/selinux-python/selinux-python-3.2.ebuild | 23 ++++++++++++++++++++++ sys-apps/selinux-python/selinux-python-9999.ebuild | 23 ++++++++++++++++++++++ 2 files changed, 46 insertions(+)
