This version does not run test, because upstream commit https://github.com/kjn/lbzip2/commit/aac5d7688167ea3301d4f68705e718732c4710e6 looks partially applied. Also, is there a valid reason to use sources from ~whissi instead of upstream (maybe with some patching)? Reproducible: Always Steps to Reproduce: FEATURES="test" emerge =app-arch/lbzip2-2.5_p20181227-r1 ... /bin/sh: ../build-aux/test-driver: No such file or directory ... Actual Results: Error: /bin/sh: ../build-aux/test-driver: No such file or directory Expected Results: Successfull build & tests
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=038d05af9bc94a6ed14ffe96592536986c7b6186 commit 038d05af9bc94a6ed14ffe96592536986c7b6186 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2020-02-21 19:54:54 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2020-02-21 20:33:47 +0000 app-arch/lbzip2: Run eautoreconf to fix tests Closes: https://bugs.gentoo.org/708342 Signed-off-by: Matt Turner <mattst88@gentoo.org> app-arch/lbzip2/lbzip2-2.5_p20181227-r1.ebuild | 7 +++++++ 1 file changed, 7 insertions(+)
(In reply to Étienne Buira from comment #0) > This version does not run test, because upstream commit > https://github.com/kjn/lbzip2/commit/ > aac5d7688167ea3301d4f68705e718732c4710e6 looks partially applied. > > Also, is there a valid reason to use sources from ~whissi instead of > upstream (maybe with some patching)? There was a bzip2 change that broken lbzip2. lbzip2 was fixed, but in a large series of commits done after the last release (v2.5). The fix did not cherry-pick easily, so we decided to make a snapshot tarball instead. I regenerated a tarball (with make dist) and it passes the test suite when I run make check manually. For reasons I don't understand it fails in exactly the same manner you describe when run from portage. So I don't know... easy fix committed -- just run eautoreconf.
