Hi Mike, Kaganski Mike wrote:
However, I suppose that it's possible in theory that some user python script could ultimately need initializing gpgme. In that case, the problem would hit the user. Having a modal dialog waiting on a possibly headless server is not a correct behavior :-)
Hmm - so the uitests are rigging the office in a very specific way, using subprocess.Popen to spawn a child soffice process from python (which calls CreateProcess on Windows). Code for that is in uitest/libreoffice/connection.py, Python3 help blurb is https://docs.python.org/3/library/subprocess.html#subprocess.Popen It is a tad surprising that this would somehow 'think' it is still the main python executable on Windows, perhaps there's a way to parameterize the Popen call differently to rectify that?
My questions are: 1. First of all - do I understand it correctly that the problem is real - so there are possible scenarios involving e.g. python (or another process which executable is not in LO's instdir/program), that might need gpgme?
See above - but even for uitests, the issue might become relevant, so I see at least no harm in keeping that fix (unless Popen can be fixed to not have Windows inherit too much parent process attributes).
2. To find the executable, I use UNO_PATH envvar. As far as I can tell, even directly running soffice.bin without having UNO_PATH set in environment, sets the variable correctly, so this works as expected. But is there a better way?
The canonical way seems to be something like:
OUString aProgramURL("$BRAND_BASE_DIR/" LIBO_LIBEXEC_FOLDER "/<executable>");
rtl::Bootstrap::expandMacros(aProgramURL);
3. The patch needs to add a gpgmepp wrapper for gpgme_set_global_flag function, [snip] If there's no way to do that, then I'll create a pr to https://github.com/KDE/gpgmepp.
Yes please, that's how we did that in the past, too. Thanks a lot for chasing this, -- Thorsten
Attachment:
signature.asc
Description: PGP signature