Modified and commited with: rev. 2859eddfb0c935d3f9eb9ccc1b42c121621123e9 I'm not sure if phabricator automatically does it when I mention the differential as GnuPG-Bug-Id
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jan 26 2021
Thanks for noticing, I did not have Qt4 on my radar when writing this. The delayed raise with the timer might be only necessary on windows, on linux we don't have reports that just doing an activateWindow and raise does not work. So this is mostly for windows and there the Qt4 pinentry is not relevant.
That says "Interface not supported" when GpgOL is trying to obtain some data from Outlook. AFAIK this can only happen if the server is either not a Microsoft MAPI server like OpenExchange or KOPANO or so. But even these two are known to work.
Thanks for the report. Some time ago I wrote the code in a way that when setting the HTML body failed it would fallback to the plain body, regardless of the preferences:
So even though there is an error that error is handled. https://dev.gnupg.org/source/gpgol/browse/master/src/mail.cpp;4d57033a095aecf8529606428efef6af466f1196$1488
Alright!
@ballapete when you have time, could you also test https://dev.gnupg.org/T5268#142155 on Tiger?
To support old macOS (< 10.12), I think that code should be something like this:
Thanks. However, we need to go over the list one by one to decide this. For example
"http://gnupg.org/.well-known/openpgpkey/hu/12345678" is actually expected to return a 404 and test code may very well use http:
I created T5268, please continue discussion there.
Just for the information, this library of Rust checks if the symbol definition is available (not NULL), and use getentropy in that case.
fall back to /dev/u?random
https://www.unix.com/man-page/mojave/2/getentropy/ says getentropy is available in 10.12 or later.
I realized that it's a bit difficult for macOS to use getentropy.
Please note that we also have a commit rC477355047e5c: mpi/longlong: make use of compiler provided __builtin_ctz/__builtin_clz.
Jan 25 2021
Right now I am compiling with my old PowerBook in Tiger. In case a compilation fails I'll try this patch – on Tiger (Mac OS X 10.4.11)! It's a bit more primitive than Leopard.
Here's patch to try out:
BTW, we should better get back to the classic/GNU-coding-style pattern:
In "src/cipher-proto.h", try removing typedef and leaving just forward declaration of structure.
- Please see T5262 if you want to build with Qt4.
Do not use -fno-common
Jan 24 2021
Does attached patch help?
Check header presence instead for getentropy.
There’s a patch to restore support for Qt4: D521.
Jan 23 2021
My bad, prior to the release I tested only against Qt5.
Hi,
you can close this tickets, the Italian translation has already been uploaded successfully. Don't import anything to GnuPG. Thanks a lot!
I tried it - that doesn't help. Same error message.
Thanks for the report. As you noticed, issue had been reported already.
That might be helpful. But, on the other hand, if I had just googled the problem I was seeing I would have gotten answer quite fast.
Problem is in GET_DATA_POINTER macro. MacOS assembler expects data references in some different format than Linux. Could you try following edit and see if libgcrypt then compiles? In cipher/asm-common-aarch64.h, there is definition of GET_DATA_POINTER macro:
#ifdef _WIN32 #define GET_DATA_POINTER(reg, name) \ adrp reg, name ; \ add reg, reg, #:lo12:name ; #else #define GET_DATA_POINTER(reg, name) \ adrp reg, :got:name ; \ ldr reg, [reg, #:got_lo12:name] ; #endif
I have now tried to build libgcrypt 1.9.0 for arm64 using clang. I get the following error:
Jan 22 2021
It seems that this issue has already been reported with a better fix: https://lists.gnupg.org/pipermail/gcrypt-devel/2021-January/005060.html
Feel free to close this issue.
Should we add this to the hints in the README? After all this does not seem to be the standard system compiler or it has not been properly setup as replacement.
Problem was that my build system was selecting "ar" and "ranlib", where as your build system selects "llvm-ar" and "llvm-ranlib".
The related qt bug is: https://bugreports.qt.io/browse/QTBUG-83365