Source: libnvme Version: 1.11-1 Severity: grave Justification: breaks autopkgtest of another package Forwarded: https://github.com/linux-nvme/nvme-cli/issues/2573
Dear Maintainer(s), libnvme since version 2.11 does not work if it is built with keyutils support, but runs on a kernel without CONFIG_NVME_TCP_TLS and CONFIG_NVME_HOST_AUTH, as it unconditionally expects the .nvme keyring to be available, and hard fails otherwise. https://github.com/linux-nvme/libnvme/blob/f1ddb968ce03a67a96e3f9069e9b758532cf67b9/src/nvme/linux.c#L1551 # nvme connect-all -t tcp -a 127.0.0.1 -s 16858 --hostid=158f4d7d-6759-499e-b260-b152e49fa9a2 Failed to set keyring failed to add controller, error Required key not available On Debian the kernel does not enable the required kconfigs, so the command is currently broken as the .nvme keyring doesn't exist. This is now breaking src:systemd autopkgtest, which has a test for an nvme tcp server that uses nvme-cli, hence the severity: https://ci.debian.net/packages/s/systemd/testing/amd64/ Unfortunately there was no direct dependency in autopkgtest so the test that was previously working wasn't rerun before nvme-cli migrated to testing, I've fixed that now so that future regressions will be caught by debci before migration. I've also reported this upstream: https://github.com/linux-nvme/nvme-cli/issues/2573 Ideally the userspace tool should not fail hard when the kernel doesn't enable the required functionality, especially when the invocation doesn't explicitly enable any tls option, but that will require upstream to fix it.
