On Fri, 2010-04-09 at 11:00 -0400, Bill Nottingham wrote:
James Laska (jlaska@redhat.com) said:
On Fri, 2010-04-09 at 08:38 -0400, Bill Davidsen wrote:
The rpm kernel-2.6.33.1-19.fc13_2.6.33.1-24.fc13.x86_64.drpm downloaded, then it looks as if it created an rpm by applying the delta and decided the rpm wasn't signed? And there's also an rpm kernel-2.6.33.1-24.fc13.x86_64.rpm, which I assume is the rpm created by the delta.
Is this some download error, or is there another problem with unsigned packages getting into the repos? I did repeat the download, same CRC...
Seems worthy to add a package acceptance criteria to the Package Update Acceptance Criteria [1] similar to the following:
* Packages must be signed with a valid Fedora GPG signature
I guess one could argue that the existing criteria "Packages must be able to install cleanly" would include valid signatures. But it doesn't hurt to be specific here.
Comments/concerns/ideas?
The process flow is:
- package is built in koji
<any delay from maintainer> 2. update is submitted in bodhi <delay until next push> 3. package is signed <then nearly instantaneously> 4. package is pushed
When you say "package is pushed", do you mean pushed to the requested repo (updates vs updates-testing)?
From a user-perspective, having to use --skip-broken seems just as bad as using --nogpgcheck. But if I understand correctly, given the workflow above we don't have a mechanism to enforce this in the QA space?
Thanks, James