You are not logged in.
Makepkg (5.2.2-1) errors when I build a package with:
makepkg -efi
==> Making package: syncthing-bin 1.7.1-1 (Wed 15 Jul 2020 09:28:41)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Removing existing $pkgdir/ directory...
==> Entering fakeroot environment...
==> ERROR: The key B1BD4E40 does not exist in your keyring.
The relevant part of makepkg:
# check if gpg signature is to be created and if signing key is valid
if { [[ -z $SIGNPKG ]] && check_buildenv "sign" "y"; } || [[ $SIGNPKG == 'y' ]]; then
SIGNPKG='y'
if ! gpg --list-secret-key ${GPGKEY:+"$GPGKEY"} &>/dev/null; then
if [[ ! -z $GPGKEY ]]; then
error "$(gettext "The key %s does not exist in your keyring.")" "${GPGKEY}"
else
error "$(gettext "There is no key in your keyring.")"
fi
exit $E_PRETTY_BAD_PRIVACY
fi
fi
Running the command manually does show the key is present and valid:
gpg --list-secret-key 7817E3FF578EEEE19F64D40C445E52EAB1BD4E40
sec rsa2048 2010-08-21 [SC] [expires: 2022-06-01]
7817E3FF578EEEE19F64D40C445E52EAB1BD4E40
uid [ultimate] Jason W Ryan
uid [ultimate] Jason Ryan
uid [ultimate] Jason Ryan
ssb rsa2048 2010-08-21 [E] [expires: 2022-06-01]
Even running the full makepkg snippet works fine. So why is it failing when I call makepkg? What am I missing?
Last edited by jasonwryan (2020-07-15 03:05:49)
Offline
Why is it even checking for a key at that point, it hasn't even gotten to the package() stage -- there's nothing to sign.
If I try to run `makepkg -efi --sign --key B1BD4E40`
I immediately get
==> ERROR: The key B1BD4E40 does not exist in your keyring.
If I try it with my own key
makepkg -efi --sign --key 7DDAF4F9
==> Making package: syncthing-bin 1.7.1-1 (Tue 14 Jul 2020 23:04:06 BST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Removing existing $pkgdir/ directory...
==> Entering fakeroot environment...
==> Starting package()...
==> Tidying install...
-> Removing libtool files...
-> Purging unwanted files...
-> Removing static library files...
-> Stripping unneeded symbols from binaries and libraries...
-> Compressing man and info pages...
==> Checking for packaging issues...
==> Creating package "syncthing-bin"...
-> Generating .PKGINFO file...
-> Generating .BUILDINFO file...
-> Adding install file...
-> Generating .MTREE file...
-> Compressing package...
==> Creating package "syncthing-bin-debug"...
-> Generating .PKGINFO file...
-> Generating .BUILDINFO file...
-> Generating .MTREE file...
-> Compressing package...
==> Leaving fakeroot environment.
==> Signing package(s)...
Any aliases in play here?
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Online
No, I don't have any aliases. I'm stumped as well. It works fine on my other machine, but this one is acting weird.
It's checking for the key because that is the call in makepkg where it parses the options array: '!distcc' color '!ccache' check sign
and then it looks for the key
+ gpg --list-secret-key B1BD4E40
+ [[ ! -z B1BD4E40 ]]
++ gettext 'The key %s does not exist in your keyring.'
+ error 'The key %s does not exist in your keyring.' B1BD4E40
And the key, of course, is in my keyring (and pacman's). So it can't access the keyring from the fakeroot...
Offline
I deleted /etc/pacman.d/gnupg and rebuilt the keyring, and re-added my key. No change.
Building in a clean chroot, however, works, with the package being correctly signed...
#edit Downgrading pacman to 5.2.1-6 also works as expected.
Last edited by jasonwryan (2020-07-15 01:09:58)
Offline
Do you get any useful output from gpg if you remove the redirection?
Offline
Thanks Andrew, without redirection, it just prints the full key info, as in post #1. For some reason, that call fails in the fake/chroot.
I've looked at the git log, and eli's patches to makepkg look benign to me. I'm not sure what else has changed between versions that could be doing this.
Offline
Why is it even checking for a key at that point, it hasn't even gotten to the package() stage -- there's nothing to sign.
For context, the key is checked early on (it's wasteful to go to all the effort of building the package when we know signing is required, but will be unsuccessful).
The exact position of the error seems odd:
==> Entering fakeroot environment...
==> ERROR: The key B1BD4E40 does not exist in your keyring.
But, it's because the fakeroot environment literally calls "fakeroot makepkg --secret-internal-option" and all the early checks are rerun. Somehow, doing those checks in fakeroot bombs out though...
Which is bizarre. For some reason, in pacman 5.2.1, this works in fakeroot and out of it:
gpg --list-key B1BD4E40 &>/dev/null
While in 5.2.2, this fails under fakeroot, but otherwise works:
gpg --list-secret-key "B1BD4E40" &>/dev/null
@jasonwryan, /etc/pacman.d/gnupg is irrelevant here (it's about $HOME/.gnupg/).
Did you say that removing the redirection by editing /usr/bin/makepkg, resulted in makepkg successfully building the package? This would imply that gpg is failing in fakeroot, but only because it tried to redirect output.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
@jasonwryan, /etc/pacman.d/gnupg is irrelevant here (it's about $HOME/.gnupg/).
Did you say that removing the redirection by editing /usr/bin/makepkg, resulted in makepkg successfully building the package? This would imply that gpg is failing in fakeroot, but only because it tried to redirect output.
Ah, no. I misunderstood Andrew's question.
Removing the redirect and running it does indeed identify the culprit: a lock file that couldn't be read. I removed that and it works.
Sorry for the noise...
:edit I'm still perplexed why gpg didn't print the same error when run manually.
Last edited by jasonwryan (2020-07-15 03:08:14)
Offline
Fascinating!
But at least the problem is solved.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline