On Sat, 2012-03-03 at 13:17 +0000, Neil Williams wrote: > Having a test suite which is dependent on the architecture-dependent > configuration of the running kernel is going to be permanently > problematic in a Debian buildd infrastructure...
As I learn of these issues I fix them, to the extent that the kernel state is discernible from userspace. The idea of libexplain is to explain errors, particularly obscure ones caused by kernel config, or other details the user would have difficulty discovering. (To the extent that discovery is possible.) There is support in libexplain for Linux capabilities. There is not yet any support for the various Linus Sectuty Modules, although I am bumping into them personally, so that itch may be scratched soon. The idea is to produce error messages that actually explain what went wrong, rather then producing cryptice error messages like "No medium found". Users aren't, and should not have to be, psychic. > I'm beginning to think that libexplain is only particularly useful when > compiled on the machine which is to use it Given that you can chnage LSM at boot time, it needs to cope with LSM regimens not present when built. The only things stopping apparmor, selinux, etc, form be supported is my time. One of the fascinating things about distributing software with a test suite is that, if it had no test suite, it would be packaged without quibble. But if a package has a test suite, and fails a handful out of 600 tests, folks get all alarmed and don't install it. If the debian/rules didn't run the test suite, you wouldn't be considering pulling libexplain. There is something broken in this logic. -- Sent from Ubuntu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
