* [bug#37493] [bug#37519] [PATCH v2 2/2] gnu: add iwd. [not found] <793d-5d921680-4d-485b8300@90758574> @ 2019-10-01 8:27 ` Ludovic Courtès 2019-10-01 22:30 ` Danny Milosavljevic 0 siblings, 1 reply; 2+ messages in thread From: Ludovic Courtès @ 2019-10-01 8:27 UTC (permalink / raw) To: brice@waegenei.re; +Cc: 37519, 37493 Hi Brice, "brice@waegenei.re" <brice@waegenei.re> skribis: > On 29 September, 2019 23:01 CEST, Ludovic Courtès <ludo@gnu.org> wrote: > >> I didn’t know about the add_key(2) syscall, but looking at the man page, >> it seems that the “asymmetric” type is not supported (but EBADMSG is not >> documented either…). > > It was missing the kernel module pkcs8_key_parser, as explained in src/pkcs8.conf. Since we can't load it at build time, I disabled the test. Following is the content of src/pkcs8.conf: > > # When distributions use CONFIG_PKCS8_PRIVATE_KEY_PARSER=m kernel option, > # using keyctl(2) will fail for loading PKCS#8 private keys since there is > # no automatic module loading for key type parsers. This entry ensures > # that the kernel module pkcs8_key_parser.ko is loaded at boot time. Oh, I see, thanks for explaining. So what about skipping the test altogether (because we cannot guarantee that the kernel will have that kernel module), along the lines of the Alpine patch you showed, but with a comment explaining why we skip the test? Thank you, Ludo’. ^ permalink raw reply [flat|nested] 2+ messages in thread
* [bug#37519] [PATCH v2 2/2] gnu: add iwd. 2019-10-01 8:27 ` [bug#37493] [bug#37519] [PATCH v2 2/2] gnu: add iwd Ludovic Courtès @ 2019-10-01 22:30 ` Danny Milosavljevic 0 siblings, 0 replies; 2+ messages in thread From: Danny Milosavljevic @ 2019-10-01 22:30 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 37519, brice@waegenei.re, 37493 [-- Attachment #1: Type: text/plain, Size: 1379 bytes --] Hi, > > It was missing the kernel module pkcs8_key_parser, as explained in src/pkcs8.conf. Since we can't load it at build time, I disabled the test. It's fine to do it like that in that case, but just some food for thought: We often disable tests in cases like that because writing system tests for something like that is annoying if one has to do it manually. Would it be possible to discover packages which need those kinds of tests (if necessary just specify an "argument" in the package record) and automatically create&run system tests for them? Guix would then run all the tests in a qemu-system container. Something like $ make TESTS=packages check-system which would: * Traverse all the packages with (#:run-tests-as-system-tests? #t) * Automatically set up a system test to run the tests of all of these packages. Basically we could just provide guix-daemon inside a qemu guest and build the same derivation again in there, letting it load Linux kernel modules however it wants. Especially Linux kernel-requiring (or worse, -modifying) tests are otherwise impossible to do. Long term, I don't feel good excluding all those tests just because they are low-level. Docs: >there is no automatic module loading for key type parsers Why not? Weird... there's require_module, was it not thought of--or is it inapplicable somehow? [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2019-10-01 22:31 UTC | newest] Thread overview: 2+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <793d-5d921680-4d-485b8300@90758574> 2019-10-01 8:27 ` [bug#37493] [bug#37519] [PATCH v2 2/2] gnu: add iwd Ludovic Courtès 2019-10-01 22:30 ` Danny Milosavljevic
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).