Thu, May 9
It appears this issue was first identified and triaged in 2016: T2879
If merged, my patches should resolve that task as well.
Wed, May 8
Tue, Apr 30
Without -no-undefined, libtool refuses to create the shared library (dll) on Cygwin, because libtool knows that creating a shared library (dll) on Cygwin does require all symbols to be defined.
Unfortunately but traditionally, by default libtool has to assume a library being created will have undefined symbols.
Hence, if the library to be created is designed to have all symbols defined, libtool needs to be informed about this fact using the -no-undefined flag.
This flag does allow libtool to create a shared library even on platforms known to require all symbols to be defined for shared libraries.
Please explain in more detail what the problem with Cygwin is.
Mon, Apr 29
I've applied your patch with an additional comment to our master branch. Thanks!
Apr 9 2019
We do not support 64 bit Windows thus this problem on Cygwin is obvious. Funny that Cygwin falls back to native Windows object in this case.
Apr 5 2019
Apr 3 2019
Mar 27 2019
Sorry, this did not make it into 3.1.6. But I'll definitely see about it for the next release. If it is an institutional / corporate issue you could also contract us through www.gnupg.com
Mar 26 2019
From: aheinecke (Andre Heinecke)
Sent: Montag, 28. Januar 2019 19:25
fwiw. Your patch is beautiful in which it follows our coding style and
debug output. I'm confident that we will accept it but currently I have
to read up on Job's a bit.
Is there a way I could help you with this? This issue is hampering adoption
of GnuPG 2 here.
Feb 10 2019
Patch applied, thanks.
Patch applied, thanks.
Feb 8 2019
Jan 28 2019
fwiw. Your patch is beautiful in which it follows our coding style and debug output. I'm confident that we will accept it but currently I have to read up on Job's a bit.
That is a very interesting problem that we did not have on our radar.
Jan 25 2019
Jan 23 2019
Jan 21 2019
I've developed a simple patch that sets the CREATE_BREAKAWAY_FROM_JOB flag when creating a new background process. This flag requires a special permission on the job object, which is tested first. This means that the patch only works if the parent process sets JOB_OBJECT_LIMIT_BREAKAWAY_OK on the job object, otherwise the behavior should be as without the patch.
Oct 15 2018
Just commited. Thanks.
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
Jan 29 2018
Ah, yes. Will do. Thank you for reminder.
Thank you. I think you can update the comment below the implementation now ("/* FIXME: Implement this when we have the specification for it. */) and the #error line.