The test/tap-test.sh.in file isn't included in the 1.9.20 tarball, which results in the following error when running make check: make[4]: *** No rule to make target 'tap-test.sh.in', needed by 'test-bus.sh'. Stop. The file exists in the git tree and should be included in the release tarball.
Created attachment 117794 [details] [review] Distribute tap-test.sh.in unconditionally --- Review welcome (from anyone). It's pretty trivial, so I'll apply it unreviewed if nobody objects soon.
Comment on attachment 117794 [details] [review] Distribute tap-test.sh.in unconditionally Looks correct to me.
Hijacking this bug a bit, on the Ubuntu-inclusion bug, Tyler said > However, even after pulling in that file from the git tree, `make check` > is still failing on the test-bus.sh test. I can reproduce this, and I think this is actually a bug in libcap-ng: <https://bugs.debian.org/796167>. If I'm right, configuring with --enable-tests --enable-asserts --disable-libaudit will make this go away.
Created attachment 117795 [details] [review] audit: make the first few fds close-on-exec libcap-ng < 0.7.7 leaks one non-close-on-exec fd during initialization. test-bus asserts that all fds beyond 2 passed to an executed subprocess have the close-on-exec flag set, which will fail at that leaked fd. This was unnoticed until commit 517c4685, because libaudit was previously only initialized if we were configured to switch uid, which the regression tests do not do; the system bus is normally the only place that happens, but the system bus is not normally run with the "embedded tests" enabled (since they are bad for performance and security).
Comment on attachment 117795 [details] [review] audit: make the first few fds close-on-exec Review of attachment 117795 [details] [review]: ----------------------------------------------------------------- If this fixes the tests, it looks good to me (as good as a hack can ever look, anyway).
Both applied in what is going to become dbus 1.10.0.
Why not just bump the version of the libcap-ng dependency? Sounds wrong to me to work around old, broken software.
(In reply to Lennart Poettering from comment #7) > Why not just bump the version of the libcap-ng dependency? The fix isn't particularly old (this May), and this stable-branch has taken more than a year already. I don't want to gate "we can have a stable release that passes tests" on distributions all updating libcap-ng.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.