Fri, Jun 2
Fri, May 26
Fri, May 12
Pushed to GnuPG master. Let us test. For my machine of Debian GNU/Linux, Wine emulation (Windows 32-bit, Windows 64-bit), make check goes all well.
After confirming the implementation, I'd like to put it into gpgrt.
May 1 2023
Apr 27 2023
I learned that Unix build environment needs Wine emulation (with winepath) for MinGW host (when uninstalled executable should run correctly).
https://www.gnu.org/software/libtool/manual/html_node/File-name-conversion.html
Apr 13 2023
Apr 10 2023
Fixed in 1.47.
Fixed in libgcrypt 1.10.2.
Fixed in libgpg-error 1.47.
Apr 7 2023
Fixed in 1.10.2.
Apr 6 2023
I'll add new error codes to gpgrt
Apr 4 2023
Any volunteers to write a manual? ;-)
The reason may be the following text/comment I found in gpgrt.texi:
This manual documents the Libgpg-error library application programming
interface (API). The goal is to that all functions and data types
provided by the library are explained. However, for now this is only
a stub and not very useful.
Mar 28 2023
Mar 25 2023
@tlaurion Thank you for the report, but your particular problem is irrelevant to this ticket.
I lightly looked the log and noticed that the cross build would have some confusions for pkg-config, however, that's not our problem but yours.
For the particular failures in your build, the issues look like a problem of musl linker. It seems that it requires all dependency of libraries to be used, even if an executable doesn't use a library directly.
If it is the case, we need a patch... something like:
Mar 24 2023
@gniibe
Trying to crosscompile newer 2.4 gpg toolstack from Heads OSF under PR https://github.com/osresearch/heads/pull/1350
FWIW, some cards don't have PUKs but two PINs which are able to unblock reciprocal.
Should we also differentiate between wrong PUK and no PUK set?
Having GPG_ERR_BAD_PUK makes sense. So, I added a tag for gpg-error.
Mar 23 2023
Fixed in master (of libgpg-error).
Pushed the change to libgcrypt (master and 1.10 branch).
Jan 6 2023
Dec 22 2022
Ah, I had not done git pull for a week, and I didn't realize your patch.
Dec 21 2022
I pushed a similar fix last week: rE885a287a57cf060b4c
and gnupg has a hack to fix it for oler libgpg-error versions.
Something like this should fix the behavior:
diff --git a/src/argparse.c b/src/argparse.c index ef0c161..403c4a7 100644 --- a/src/argparse.c +++ b/src/argparse.c @@ -3000,7 +3000,13 @@ show_help (opttable_t *opts, unsigned int nopts, unsigned int flags) writestrings (0, "Options:", "\n", NULL); for (i=0; i < nopts; i++ ) { - s = map_fixed_string (_( opts[ordtbl[i]].description )); + if ((opts[ordtbl[i]].flags & ARGPARSE_OPT_HEADER) + && opts[ordtbl[i]].description + && !*opts[ordtbl[i]].description) + /* It's empty header. */ + s = opts[ordtbl[i]].description; + else + s = map_fixed_string (_( opts[ordtbl[i]].description )); if ( s && *s== '@' && !s[1] ) /* Hide this line. */ continue; if ( s && (opts[ordtbl[i]].flags & ARGPARSE_OPT_HEADER))
Dec 12 2022
AFAIU, gpgrt-config works well now for the multilib MinGW target.
Dec 6 2022
Thanks !
A real fix will be in the next gpgrt release
Nov 26 2022
Nov 18 2022
On Windows, closing/inheriting handles is different to POSIX.
https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873
https://devblogs.microsoft.com/oldnewthing/20130426-00/?p=4543
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw
https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexw
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-initializeprocthreadattributelist
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-deleteprocthreadattributelist
Nov 16 2022
We should consider to break the Assuan API maybe we can do that without too many problems for the current use cases.
I'm going to use gnupg_process_* prefix for the functions.
Nov 15 2022
Last two points are for future changes of assuan internal; For the case of controlling fds in detail, it is possible to use spawn callback controlling fds by the routine and let no-touching (inherit) by the spawn function.
Nov 14 2022
I don't understand the last two points: This is only about the three standard descriptors but how shall we supply more descriptors? At least in GPGME we definitely need more.
Evaluating again, I'd like to change spawn functions like this one in libgpg-error:
Nov 10 2022
Examining again, I realized that the current spawn API (not published yet, only available in libgpg-error master) is not that useful in general (or difficult to use), while it works somehow.
Nov 8 2022
Here is the change of GnuPG to use new spawn functions from libgpg-error:
Nov 7 2022
Nov 4 2022
For the spawn_cb, I reconsider. Having three calls complicates use, and it is actually not needed. In the case of pthread_atfork, it is needed, because fork may be used deeply in some functions. In our use cases of spawn function, prepare part of the callback can be called before calling spawn, and parent part of the callback can be called after calling spawn.
I decide use of pid_t, as there are different semantics between POSIX and Windows, *and* there is a problem of MinGW-w64. I introduce gpgrt_process_t, instead.
Oct 31 2022
Another thing when we define a type which represents process.
For pid_t, MinGW-w64 has a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1397787 (or https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/1456671365-21759-1-git-send-email-sw%40weilnetz.de/).
(1) GetCurrentProcessId always returns 32-bit (DWORD), so, it can be represented in 32-bit (although DWORD is unsigned).
(2) POSIX requires pid_t should be signed integer https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html
(3) Original MinGW defines pid_t as int (in include/sys/type.h by _pid_t). (checked in mingwrt-5.4.2)