Repoman skips Manifest signing if the developer is in a category directory when they issue the commit command. Thus, many developers are probably configuring repoman to sign Manifests, assuming that it is, and then not noticing that it decided to skip the signing. Repoman should be tweaked to correctly handle this. Less than 50% of recently updated Manifests have been signed. See http://forums.gentoo.org/viewtopic-p-4794095.html#4794095 for more stats on Manifest signing. If you look at the commits on sys-libs/ncurses/Manifest you see that it flips back and forth between signed and unsigned even though all the devs were using repoman http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-libs/ncurses/Manifest?rev=1.214&view=log The relevant code starts on line 2082: "... # Force an unsigned commit when more than one Manifest needs to be signed. ..." Reproducible: Always Steps to Reproduce:
I've tried to test this by doing a category level commit in --pretend mode and it printed out all the expected gpg commands to sign the manifests. However, the code will bail out on the manifest commit if any kind of error occurs during the signing. Did you receive any error message when this happened to you?
I might be misreading the code, but it seems in the case of a category level commit it does the Manifest commit first on line 2092, sets manifest_commit_required=False, and then continues on to sign it on lines 2110 onwards. If I'm reading this right, the final commit would do nothing since the commit has already been done. Lines 2082-2101 look like vestigial code that can be removed, as lines 2110 onwards do what 2082 claims it can't. I'm not a gentoo dev so I can't actually test it live.
Well, you only need *a* repository with ebuilds to test this. You do not necessarily need *Gentoo's* repository.
Is this still a problem? I'll review soon.
This could be related: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a24bcfcfad95fcf4b71064e386fb6272f41ff49a
repoman support has been removed per bug 835013. Please file a new bug (or, I suppose, reopen this one) if you feel this check is still applicable to pkgcheck and doesn't already exist.
