Just some feedback from using the signing feature. Could you please change some things with the invocation of GnuPG (rationale included below). In repoman: gpgcmd = "/usr/bin/gpg --sign --yes --lock-multi --no-auto-check-trustdb --no-permission-warning --comment='%s %d' --clearsign " % (filename,time()) In portage_gpg.py: GPG_OPTIONS = " --lock-multi --no-random-seed-file --no-greeting --no-permission-warning" This fixes GnuPG locking for those of us that make large use of it (the current --lock-none is dangerous, it almost trashed my keyring - but caught itself and bailed out). --no-permission-warning removes the warning you get of: gpg: WARNING: unsafe ownership on homedir "/home/robbat2/.gnupg" when you are running repoman as root and your gpg stuff is not owned by root. --no-auto-check-trustdb speeds up repoman (checking the trustdb takes 3 minutes on my large keyring). --comment='%s %d' with % (filename,time()) creates a human readable helpful line that gives details about the signing of the file. At the very least, have --comment='' to make it not get comments for those of us that use them already.
How did lock-none cause problems? There should be no write access whatsoever. The problem I was trying to solve was access violations due to non-priv'd access. Are you using userpriv?
At first it tried to update the trustdb, then it was trying something else and just bailed obscurly. I admit I did upgrade gpg between then and now, and I can't reproduce any error during the check phase any more.
OK, some comments from my side. When using gpg-agent (use-agent in gpg.conf) from app-crypt/newpg and gpg fails for some reason to contact the agent (e.g. agent died or has never been started) gpg will fall back to prompt for the keyphrase on the terminal. The Manifest gets signed, but gpg's return value will be != 0 and repoman will call gpg repeatedly and will fail every time. No chance to break this, ctrl+c doesn't work as it only kills the gpg process.
control-z kill %1 is your friend until issues are resolved.
*** Bug 152977 has been marked as a duplicate of this bug. ***
I'm going to review current portage for this shortly and see if we can fix/close it.
(In reply to Robin Johnson from comment #6) > I'm going to review current portage for this shortly and see if we can > fix/close it. Any progress on this review? Thank you in advance.