Wed, Oct 13
No, the error is harmless. I guess it shouldn't be printed (except when debugging).
We now require a way to get the actual image of a process. For macOS the BSD method is used and we obviously need to find another way for macOS.
Fri, Oct 8
Mon, Oct 4
Currently, I am using --lock-never config to avoid generating lock file as a workaround.
Sun, Oct 3
Sorry, a hostname with slash is simply not allowed by IETF standards. Given that the hostname is part of temporary file names, you will run into an error. Yes, we could remap the slash in the mktemp function but there are lot of other plzces where the hostname is used and certain properties are expected.
Mon, Sep 27
These are great news. Thank you!
Pushed the change to libgpg-error and libgcrypt (1.9 and master).
Let us see if there are any problem(s) for that, I will apply it to other libraries when it will be found no problem.
Thank you for the information.
For the record, I put the link to the email submitted:
Wed, Sep 22
Oh, you are right, it's not upstream. It's actually applied to Homebrew (https://brew.sh/) libtool formula which is where I originally got libtool.m4, see:
I see your point. I'd like to locate/identify where the change comes from.
I think that what you refer by "new libtool.m4" is actually macOS local change (I mean, not from libtool upstream, AFAIK).
Could you please point out the source of the change?
Tue, Sep 21
That would work, however we might hit this issue with a new macOS release. Would it make more sense to update to what the new libtool.m4 is doing? Linker flags are the same, it only changes the way they detect macOS versions:
That does indeed not look like something which could introduce a regression.
I misunderstood as if we need to update libtool from upstream.
macOS has low priority for us and I do not want to risk any regression.
Sep 2 2021
Sep 1 2021
Aug 30 2021
Aug 25 2021
Closing, as downstream ticket has been closed.
Fixed in libgcrypt 1.9.4.
It must be fixed in 2.3.2. If not, please report.
Aug 13 2021
Jul 28 2021
dlopen'ing of gpgme is NOT SUPPORTED. It is in general not a good idea to do this on standard Unix systems.
To extend on this: dlopen'ing of gpgme is NOT SUPPORTED. It is in general not a good idea to do this on standard Unix systems. On Windows we could make it work because DLLs on that platform are well designed and not a hack like the Unix shared objects.
Jul 27 2021
We really want thunderbird users that interact with GPGME to have a great and stable user experience, but the problem with dynamic loading and self compiled versions is that we cannot really know the build settings and enviornment and it is very time consuming to reproduce that. GPGME does some very low level things for optimized IPC that can depend on build options etc. This is why I am mostly in favor that thunderbird ships a defined version that we can debug and see the settings.
Reading the mozilla entry more carefully, there still seems to be an issue.
@kaie, thanks for the pointer!
Jul 26 2021
Jul 24 2021
Using GPGME is probably the best way, even if gpgme-json might also work for some operations.
Jun 24 2021
Jun 7 2021
In your log, it says:
usb_claim_interface failed: -3
Sorry, I was wrong.
Jun 4 2021
I need to see how we can pass the check permission notice up to gpg. This is a too common problem and thus serves some special treatment.
GPG Version :
Ah, I think that your problem was fixed in rG53bdc6288f9b: scd: Recover the partial match for PORTSTR for PC/SC. (to be 2.3.2).
I see your situation
If possible, please let us know how you configure the permission to access CCID device with 2.2 (and with 2.3)?
Jun 3 2021
Please excuse my late reply. I was busy with other things over the last few weeks.
Jun 2 2021
jitterentropy is also used in Linux kernel, and some people use clang to build it these days. So, I checked the kernel's one. It is simply compiled -O0 by Makefile, and there's no pragma line now (as of v5.13).
Jun 1 2021
I don't think that it is a good idea to silence this warning. The pragma is esssential for proper random numbers and if clang hijacks a GCC's name space but implements something different it is better to have a warning than to fall into the pit full of dragons.