"dkg (Daniel Kahn Gillmor)" <noreply@dev.gnupg.org> writes:
what's the status on this? i'd love to be able to build binaries for
both python3.6 and 3.7 for debian. as it stands right now, the
python3.7 continuous integration test for debian is failing
https://ci.debian.net/data/autopkgtest/unstable/amd64/g/gpgme1.0/1158040/log.gz.
That is a strange failure. I don't see how that can happen without a legitimate bug.
what's the status on this? i'd love to be able to build binaries for both python3.6 and 3.7 for debian. as it stands right now, the python3.7 continuous integration test for debian is failing.
It seems to be a cpp problem. Andre, would you mind to take this bug?
@werner And perhaps it's worth mentioning that in my case it is gpg2 --version; gpg is 1.4.23. I have no idea whether that might play any role.
@werner Hi, the version output is as follows:
Thanks for the report. I would also like to see what
I moved the location of config.h to a new "conf" subdirectory. This should solve the issue. Thanks for the report.
C++2a will have a <version> header, so some trunk libc++ headers now (indirectly) #include <version>, and on a case-insensitive file-system, when compiling a gpgme source file with "unlucky" -I../../.. switches against such trunk libc++, that can mean that such an #include <version> picks up gpgme's VERSION file.
Sorry, I am not sure whether I understand the problem. Sure we have a file VERSION in the top directory but from where and why is it included? Is that some libc++ includes a file "VERSION.h" and somehow the preprocessor includes the file "VERSION"? IS that specified in a new revision of a standard?
sorry, i haven't had time to test gpgme with those changes myself. i hope someone can do so.
The background of my earlier comment was that I didn't tested GPGME in this regard.
if gpgme doesn't rely on the return value, but instead on parsing the --status-fd for errors, then there will still be an ERROR printed:
Okay. So for GPGME should we add --no-keyring if --override-session-key is also enabled? I think this would be better than relying on the fact that gpgme ignores the returned error code.
yes, it looks like using --no-keyring does change the return code from 2 to 0 for me.
@dkg does --no-keyring solves the problem for you?
Gpg4win-3.1.3 was released.
This happens only if GPGME_DEBUG is set to 9 which was accidentally set in my environment. So I've lowered the priority.
I was already implementing a --no-homedir when I figured that we have --no-keyring. Using that with any homedir fulfills the requested purpose.
I think it's good to close this as "resolved", since many fixes have been done, and I don't have remaining issue.
@wiz Please open another ticket for your next try.
No response so closing as invalid.
What are we going to do with this report? The last comment is 6 months old; can we change from testing to resolved or do we need to wait for a gpgme release?
I need to know which of the processes segv: mkdefsinc, cat or the subshell. And a backtrace would also be very helpful.
Done.
I've updated the README and added example mainifests.
Make dist is also updated I could build the extension and webpack it from the dist package.
Discussion on the #python IRC channel last night with another experienced SWIG developer (of a proprietary and unnamed software project) has provided ass itional evidence supporting the theory that the cause of the problems with getting the bindings to run on Windows systems is indeed directly caused by the fact that Windows users are compiling GPGME and the bindings with a different compiler and runtime than those used to compile whichever version of Python they have obtained from elsewhere.
Ok i saw they apply custom patches to _gpgme_mkstemp which are outdated and should be revisited, sorry for the noise
Actually i have now more debug output and i think i found the issue
I close this for now, this seems a problem of the mingw packages in msys2
Thanks for the report. I've commited a fix. (Returning the c_str here is ok as the data is not meant to be modified once "action" is called)
Please let us know if you find additional issues.
Or with both packages installed, could i maybe debug somehow where it searches?
BenM, msys2 uses pacman as packagemanager, all packages are build from source
Alternatively, if they wish to keep using the Python installer from python.org then they would need to drop MSys2 in favour of the same version of Microsoft Visual Studio used to compile the that specific version of Python with and use it to compile every part of the GnuPG stack, up to and including GPGME.
If that is indeed the case and the theory regarding runtime conflicts, currently under investigation in T3505 and T4086, also proves to be true; then MSys2 users and developers will need to cease using the precompiled versions of Python available from python.org and compile their own version of Python copy with MSys2.
Windows 10 was obtained last week and the process of preparing a Windows build env began earlier today.
Patch applied. Thanks.
I do not see the harm in this patch and it seems useful. Indeed it seems better then making a directory in tmp as this might create regressions for others.
This question and some of the answers to it on StackOverflow indicate some of the difficulties in getting SWIG generated Python modules to install at all. Essentially, though the easiest method currently available without extensive customisation of the setup.py file which would need to be done for both Python 2.7 and Python 3.x is to run /path/to/specific/pythonX.Y setup.py build and then follow that with /path/to/specific/pythonX.Y setup.py install and then follow that with renaming lang/python/build to a relevant directory and/or path name which indicates which version of python was used and the location or path it is in.
I can't reproduce this. When I make Dirmngr offline I correctly get a No CRL known error. So it must be something different.
While performing some initial investigation regarding observed discrepancies between compiling GPGME directly and the subsequent SWIG static object for T4086, confirmed the relative ease by which multiple installations would be achievable if performed as a post-build process. This would have the added advantage of being more readily customisable by package maintainers downstream and not just for Debian, it could be made to work more easily with other distributions or other posix systems too.
Since first observing this … annoyance … the following updates have been made: Emacs has been upgraded to version 26.1, Org-Mode has been updated multiple times, including significant changes to Babel and the XHTML export, python-mode has been updated, multiple variations on the source blocks have been attempted, the document has had any and all tabs stripped out and replaced, plus each code block has been refactored and re-entered multiple times.
Well, green is a shortcut on how to display the status of the signature. It came from the green frame KMail printed and it soley used to rely on that information. The idea was that gpgme tells you what it considers to be a good signature. Opinions and trust models meanwhile changed and thus we indeed need to update gpgme's suggestion.
My idea here is to have a discussed reference how the GnuPG community thinks a signature might be counted. Taking the discussions from our AutomatedEncryption stuff into account etc.
I would then like to extend gpg-error with the according strings / status codes.
if that is the case config.{guess,sub} needs to support this and we should be able to handle this the same way as other Unix platforms.
You seem to have reached the wrong page when searching for msys2
Done for npth.
Even after running additional tests like converting the file to reStructuredText, fixing any remaining possible errors and then converting back, the result is that org-mode still appears to save the source correctly, but cannot export it in a correct format with babel. Certainly not to XHTML and likely not to any other format either. So that's definitely a bug.
Massive overhaul of the entire document performed in this commit.
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.
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.
Now we have this:
We have two cases:
Not really. off_t is a real portability problem and this why we moved that problem out of the GPGME ABI to the application. Thus the application needs to care about mapping gpgme_off_t to whatever off_t it uses. Without that we can't provide a stable _and_ toolchain independent ABI.
Thank you for pointing this out.
Following patch fixes the issue.
My bad this already exists.
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. :)
The fix for this was released with Gpg4win-3.1.1. Forgot to update this task.
Patch committed to master in commit 5a80e755008bbb3f4c7f91ffccd38f26cd8b3960
Not to worry, we've all been pretty busy of late.
Apologies for the delay, been working on GSoC stuff.
Here's what I've got as of right now:
With recent versions of gpg you will now get Bad Data etc. This is implemented by giving an ERROR status line a higher precedence than the NO_SECKEY status.
Please dee the commit for a description of this fix.
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.
I don't think this is an error in Debian. Debian Squeeze is packed with libgpg-error 1.26 in the latest stable release [1].
According to the list of changes, gpgrt.h is addes as an alias for gpg-error.h in 1.27 [2].
I think a quick (and correct) fix is to increase the NEED_GPG_ERROR_VERSION in configure.ac to at least 1.27 [3], so the build will fail nicely in the configure-step with a correct error.
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?
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).
[We do things in the public unless explicitly requested by a bug reporter writing to security.]