Massive overhaul of the entire document performed in this commit.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 9 2018
Jul 6 2018
Slight addendum: MSYS2 isn't even part of MinGW at all, see the commentary in this bug report. Nor is it a part of Cygwin, but apparently it is a part of a fork of Cygwin.
Not only is this not supported, but I've now confirmed that MSYS2 isn't even supported by its own project and they direct all downloaders to their MinGW-get installer.
Jul 5 2018
Though a CFFI/ABI solution may be the only option, it would still be preferable to get SWIG working under Windows. The reasons for this are many, but not least of which would include not needing to duplicate effort to accommodate Windows, no functionality mismatch due to using the Windows version and not needing to implement every function manually since CFFI can't generate low level bindings the same way that SWIG does.
Jul 4 2018
Jun 19 2018
My bad this already exists.
Jun 18 2018
On 06/17/2018 02:10 AM, BenM (Ben McGinnes) wrote:
The two subsequent commits are the one I mentioned above (nested try/except
statements) and followed by a major PEP8 compliance overhaul of core.py.Thanks for the patch and welcome to the weird and wonderful world of FOSS. :)
Jun 17 2018
Patch committed to master in commit 5a80e755008bbb3f4c7f91ffccd38f26cd8b3960
Not to worry, we've all been pretty busy of late.
Jun 8 2018
Apologies for the delay, been working on GSoC stuff.
Here's what I've got as of right now:
Jun 6 2018
Jun 4 2018
Not for export, there's a few traps in there, but if you want to take a second swing at import, I'd probably accept that instead.
Jun 3 2018
That makes sense. If you don't have any other patches floating around for this, would you mind if I took a crack at rewriting export?
Jun 2 2018
Okay, the import is pretty much a match for what I have tucked away elsewhere, to that will probably get merged as is, more or less.
Actually op_import and op_export do work, but they're the underlying SWIG bindings, not the more pythonic layer Justus added a couple of years ago. I'd been planning on fixing that this month (part of the work is in one of the ben/howto-update branches), but not merged with master until it could be documented since there's something potentially hazardous in there (exporting secret keys).
May 29 2018
May 15 2018
Webhelp version of the Python bindings HOWTO is currently available here:
As a work-around for this bug I've ported the HOWTO from org-mode to DITA XML and will generate a webhelp-responsive (i.e. searchable) version to put on another website (an Amazon S3 bucket since it will be reliable and cheap) in the interim.
May 14 2018
Org-Mode was updated to today's release and further testing was conducted.
May 13 2018
May 5 2018
The Python portion of this is done, the tests will now create a key with an expiration a few years shy of the 2106 end date (NYE 2099).
Apr 30 2018
Clearly getting SWIG and Windows to play together nicely is a bit of a big ask, but it may be possible to leverage GPGME's compiled libraries with something like CFFI's ABI calling method (yeah, I know, ABI is never ideal, but it's better than what Windows has now).
The last change to the python installer was, IIRC, one I discussed with Justus off-list around the middle of, um, last year? Maybe the year before?
Apr 26 2018
Not to mention making sure we test for a time after the end of the old 32-bit clock.
Apr 19 2018
Apr 17 2018
Ben: We need to use a faked system time thing to make those tests more stable.
We never tried to build gpgme with MSYS2 and I would also say this is not supported. A wild guess is that this mixes platform specific code.
Apr 11 2018
This may be related to T3515: Gpg4win: Gpgconf used to open "windows" and slows down kleo startup since it depends on data from gpgconf.
Feb 28 2018
Feb 27 2018
Here is the build log from unpatched gpgme https://www.zq1.de/~bernhard/temp/gpgme-build-log-2033.txt
it has some tracebacks from t-callbacks.py
Can you please show the output of these failing tests? I assume you are running on a 64 bit platform.
Jan 13 2018
The actual problem is that justus quit his job to work for pEp. Thus we have no maintainer for the python port. There is one candidate for this job but don't expect any fast fixes because one of the near term goals will be to replace swig so that we can provide the bindings also for WIndows. Maybe that will also solve the problem with different Python versions.
Jan 12 2018
it's too bad that this is not considered something worth fixing upstream -- at the moment, debian's python3-gpg will only work with one specific version of python3 because of this, which makes package transitions more complex than they should be.
Nov 15 2017
Aug 21 2017
Unfortunately, even building for two Python versions is a bit of a hassle with the existing autoconf framework for Python. I did that when porting the Python bindings back to Python2 after we decided to also support 2 so that people could start to use our bindings even if they still need Python2. I don't see us extending it for more versions.
Aug 18 2017
this is also https://bugs.debian.org/866555
Jul 11 2017
Fixed in 1e68f93dc547ae75b921e43db35e3599de92e2cb.
Jul 10 2017
Thanks, LD_LIBRARY_PATH solved the problem
This is a bug tracker, not a support forum.
May 23 2017
May 17 2017
Mar 30 2017
Oct 13 2016
Fixed in 1e6073ff.
Aug 16 2016
Thanks for testing.
Aug 14 2016
I've made new container and can't repeat the bug. gpgme
components got updated in Fedora.
Aug 2 2016
Ok, there are no significant patches on top of pygpgme. Note that pygpgme is not really
maintained, and that we neither develop nor support pygpgme. But seeing that dnf is important to
Fedora, let's figure this out.
It would be nice if you could try to reproduce the problem without pygpgme though, just to make a
more minimal test case. I see the exception is thrown during some import. This is how I strace
gnupg to see what ioctls it is issuing:
% strace -eioctl g10/gpg --import ../tests/openpgp/samplekeys/ecc-sample-1-pub.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 0BA52DF0BAA59D9C: public key "ec_dsa_dh_256 <openpgp@brainhub.org>" imported
- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=26716, si_uid=1000, si_status=0,
si_utime=0, si_stime=0} ---
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0
gpg: Total number processed: 1
gpg: imported: 1
+++ exited with 0 +++
Note that if you try to strace your gpgme-based application, you need to pass '-f' to strace to
follow forks.
I have grepped through gpgme and gnupg, and it looks like gnupg is only doing ioctls to terminals,
so maybe your container setup is doing something funny to terminals. But let's see what the strace
shows.
Jul 29 2016
Here is the info about Fedora patches
https://www.rpmfind.net/linux/RPM/fedora/secondary/devel/rawhide/src/p/pygpgme-0.3-15.fc24.src.html
On Wed, Jul 27, 2016 at 1:24 PM, Justus Winter via BTS
<gnupg@bugs.g10code.com> wrote:
I see that you are using pygpgme, is that correct?If so, which version, and are
there significant patches applied in the Fedora package? And can you please tell
me what version of libgpgme you are using?
Jul 27 2016
Thanks for the report.
I see that you are using pygpgme, is that correct? If so, which version, and are
there significant patches applied in the Fedora package? And can you please tell
me what version of libgpgme you are using?
Let's try to figure out which ioctl fails. Could you try to strace this process?