Hi all, thanks for your comments. A revamped patch-set should be on the way soon, depending mostly on your's truly input on how to go on with the tests, but see below :) T B-R: That's how it was! Although these days my mails were as fast as a couple hours to appear on the mailing list, who could complain ;) unmatched-paren: I checked the projects for configure flags before I sent them. Unfortunately I am pretty sure, the remaining patches are not avoidable, since the variables are set by cmakes pkg-config queries, but correct me if wrong! I am no expert in any build system, but these things are often detectable I think :). (btw if there was an effort to write a blog post to document problems for nix/guix packaging, the use of pkg-config queries those should be explicitly mentioned, it's a pest!). About tests: I also can't find any tests in clight and clightd's repos. At least for libmodule I found how to build and enable tests https://github.com/FedeDP/libmodule/tree/16435d57b7600610313dc21301f3b5717480a3a8/tests So by setting this flag and packing valgrind and cmocka into 'native-inputs', two tests will be built and run. The one using valgrind will fail though: starting phase `check' Running tests... /gnu/store/j65q3aw414010gdfvmsynwpzfb2jyyd3-cmake-minimal-3.21.4/bin/ctest --force-new-ctest-process Test project /tmp/guix-build-libmodule-5.0.1.drv-0/build Start 1: ModuleTest 1/2 Test #1: ModuleTest ....................... Passed 1.21 sec Start 2: ModuleTest_valgrind 2/2 Test #2: ModuleTest_valgrind ..............***Failed 0.02 sec ==258== Memcheck, a memory error detector ==258== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==258== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info ==258== Command: ./ModuleTest ==258== valgrind: Fatal error at startup: a function redirection valgrind: which is mandatory for this platform-tool combination valgrind: cannot be set up. Details of the redirection are: valgrind: valgrind: A must-be-redirected function valgrind: whose name matches the pattern: strlen valgrind: in an object with soname matching: ld-linux-x86-64.so.2 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-linux-x86-64.so.2 valgrind: valgrind: Possible fixes: (1, short term): install glibc's debuginfo valgrind: package on this machine. (2, longer term): ask the packagers valgrind: for your Linux distribution to please in future ship a non- valgrind: stripped ld.so (or whatever the dynamic linker .so is called) valgrind: that exports the above-named function using the standard valgrind: calling conventions for this platform. The package you need valgrind: to install for fix (1) is called valgrind: valgrind: On Debian, Ubuntu: libc6-dbg valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo valgrind: valgrind: Note that if you are debugging a 32 bit process on a valgrind: 64 bit system, you will need a corresponding 32 bit debuginfo valgrind: package (e.g. libc6-dbg:i386). valgrind: valgrind: Cannot continue -- exiting now. Sorry. 50% tests passed, 1 tests failed out of 2 Total Test time (real) = 1.23 sec And I'm not sure how to help with that. including (list glibc "debug") didn't do it. Do we need really need this test? The next question is then if the tests that are automatically run are those mentioned in the README on the projects wiki (see url above). Chime-in! zimoun: I think I have been leaving that indentation after (description in everything I contributed so far. I seriously hope I don't need to rework all of those just for that. But for the future, I know now ;) These also would be those "prerequisite-patch-ids" hanging around, that are generated by the --base=auto flag I use with git send-email like a good manual follower. I don't want to operate on multiple guix repos or branches, I find the workflow to keep one updated time-consuming enough so far... So I guess, to be frank, what can I actually do about that? Side Note: Of course this list would become smaller the more previous patches are actually merged *cough cough* most of whom are simple, one-hunk patches that should require the least amount of time :)