Properly notify gpgme about spawn executable location on Windows
thb at libreoffice.org
Sat Apr 20 21:22:37 UTC 2019
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
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>");
> 3. The patch needs to add a gpgmepp wrapper for gpgme_set_global_flag
> If there's no way to do that, then I'll create a pr to
Yes please, that's how we did that in the past, too.
Thanks a lot for chasing this,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1032 bytes
Desc: not available
More information about the LibreOffice