Bug 647059 - Creating a new Context raises GpgmeError(32, 176, u'Not operational')
Summary: Creating a new Context raises GpgmeError(32, 176, u'Not operational')
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: pygpgme
Version: 14
Hardware: Unspecified
OS: Unspecified
low
high
Target Milestone: ---
Assignee: Toshio Ernie Kuratomi
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-26 23:17 UTC by Benjamin Gilbert
Modified: 2010-10-28 22:22 UTC (History)
4 users (show)

Fixed In Version: pygpgme-0.1-21.20101027bzr69.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-10-28 22:22:40 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.