Looking around a bit, this rpm comes from
linux-utils, so we can build it beforehand:
[user@fedora32-qubes-build qubes-builder2]$ make linux-utils-dom0
Currently installed dependencies:
make: Entering directory '/home/user/qubes-builder2'
git -C /home/user/qubes-builder2/chroot-dom0-fc32/home/user/qubes-src/linux-utils clean -f -d -X
/home/user/qubes-builder2/scripts/create-archive /home/user/qubes-builder2/chroot-dom0-fc32/home/user/qubes-src/linux-utils qubes-utils-4.1.15.tar.gz
-> Building linux-utils (rpm_spec/qubes-utils.spec) for fc32 dom0 (logfile: build-logs/linux-utils-dom0-fc32.log)
-> Building linux-utils (rpm_spec/qubes-kernel-vm-support.spec) for fc32 dom0 (logfile: build-logs/linux-utils-dom0-fc32.log)
make: Leaving directory '/home/user/qubes-builder2'
[user@fedora32-qubes-build qubes-builder2]$ make linux-kernel-dom0
Package qubes-kernel-vm-support-4.1.15-1.fc32.x86_64.rpm is not signed
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED
make: *** [/home/user/qubes-builder2/qubes-src/builder-rpm/Makefile-legacy.rpmbuilder:52: dist-build-dep.spec] Error 1
so… that would look like the way to go… except that even with
NO_SIGN=0 and a
~/.rpmmacros configured as documented (reproduced below), the packages still are not signed (and we are not told about it).
First of all, it appears that the reverse of
NO_SIGN=1 is not
NO_SIGN=0 but “
NO_SIGN=”, ie. empty. That only will allow the
COMPONENTS_TO_SIGN variable to be non-empty.
make sign.dom0.fc32.linux-utils will get the generated rpms signed. But in my case the error becomes:
Public key for qubes-kernel-vm-support-4.1.15-1.fc32.x86_64.rpm is not installed
Digging the docs the only reference I find to keyring importing is about keys used to verify signed commits. All I could find is copying by exported key into the chroot and importing it myself:
sudo chroot chroot-dom0-fc32/ rpm --import /yann-qubes-gpg.asc
… and now at last my kernel gets to build.
Is there some other/cleaner way of achieving import of the key ? How are you core devs doing in everyday life ? It would look like a job for a specifc keyring, eg.
keyrings/rpmimport, so this does not have to be redone manually for each new chroot ?
… especially as having to do this is especially annoying when trying to streamline the build instructions.
Please check https://github.com/QubesOS/qubes-doc/pull/1195, I did succeed in building a kernel with those instructions (though the ones for full build just won’t work, for a reason that will probably become obvious when old-timers will point to the problem).