Bug 647059

Summary:	Creating a new Context raises GpgmeError(32, 176, u'Not operational')
Product:	[Fedora] Fedora	Reporter:	Benjamin Gilbert <bgilbert>
Component:	pygpgme	Assignee:	Toshio Ernie Kuratomi <a.badger>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	low
Version:	14	CC:	a.badger, ivazqueznet, mitr, roth
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	pygpgme-0.1-21.20101027bzr69.fc14	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-10-28 22:22:40 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Benjamin Gilbert 2010-10-26 23:17:39 UTC

Description of problem:
PyGPGME cannot be used at all, because creating a new gpgme.Context raises a "not operational" GpgmeError.

Version-Release number of selected component (if applicable):
0.1-20.20090824bzr68.fc14

How reproducible:
Always

Steps to Reproduce:
1. In a Python interpreter:

>>> import gpgme
>>> ctx = gpgme.Context()

Actual results:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
gpgme.GpgmeError: (32, 176, u'Not operational')

Expected results:
The Context is created successfully.

Additional info:
According to <https://bugs.launchpad.net/pygpgme/+bug/452194>, gpgme_new() will fail on gpgme >= 1.2 if gpgme_check_version() has not been called.

Comment 1 Toshio Ernie Kuratomi 2010-10-27 15:31:27 UTC

Reproduced on F14.  I'll rebase to a snapshot which should fix this.

Comment 2 Carl Roth 2010-10-27 17:55:48 UTC

I found this bug the first time I tried to yum-update from a channel with signed repodata.  Oops!

Comment 3 Toshio Ernie Kuratomi 2010-10-27 18:07:02 UTC

Out of curiosity, what was the channel with signed repodata?  I want to make sure that the fix for this is okay as a zero-day update and that we won't need to respin the release to get this onto the initial media.

Comment 4 Fedora Update System 2010-10-27 18:18:09 UTC

pygpgme-0.1-21.20101027bzr69.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/pygpgme-0.1-21.20101027bzr69.fc14

Comment 5 Carl Roth 2010-10-27 19:06:09 UTC

(In reply to comment #3)
> Out of curiosity, what was the channel with signed repodata?  I want to make
> sure that the fix for this is okay as a zero-day update and that we won't need
> to respin the release to get this onto the initial media.

This was my own private channel, sorry.  I haven't found any public channels that are signed.

Comment 6 Carl Roth 2010-10-27 19:07:27 UTC

(In reply to comment #4)
> pygpgme-0.1-21.20101027bzr69.fc14 has been submitted as an update for Fedora
> 14.
> https://admin.fedoraproject.org/updates/pygpgme-0.1-21.20101027bzr69.fc14

I tried this version this and it appears to validate the repo signatures correctly.

Comment 7 Toshio Ernie Kuratomi 2010-10-27 19:19:42 UTC

Excellent.  Thanks!

Comment 8 Fedora Update System 2010-10-28 05:55:14 UTC

pygpgme-0.1-21.20101027bzr69.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update pygpgme'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/pygpgme-0.1-21.20101027bzr69.fc14

Comment 9 Fedora Update System 2010-10-28 22:22:36 UTC

pygpgme-0.1-21.20101027bzr69.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.