...since
<https://github.com/llvm/llvm-project/commit/a921d2d2fb46b898794091e7410426c518a4f0cc>
"[Driver] Add -print-multiarch", which causes an issue when building
ExternalProject_python3 on macOS:
> checking build system type... x86_64-apple-darwin19.6.0
> checking host system type... x86_64-apple-darwin19.6.0
[...]
> checking for the platform triplet based on compiler characteristics... darwin
configure: error: internal configure error for the platform triplet, please file a bug report
> make[1]: *** [/Users/stephan/Software/lo/core/external/python3/ExternalProject_python3.mk:80: /Users/stephan/Software/lo/core/workdir/ExternalProject/python3/build] Error 1
as workdir/UnpackedTarball/python3/configure.ac computes PLATFORM_TRIPLET as
"darwin", and instead of computing MULTIARCH as empty (as `$CC
--print-multiarch` used to just print
> clang: error: unsupported option '--print-multiarch'
> clang: error: no input files
to stderr), it now computes it as e.g. "x86_64-apple-darwin19.6.0" (or whatever
-target is explicitly set to in $CC), so the check that they have equal values
if they are bot nonempty fails now when building against Clang 13 trunk. (This
is not yet an issue with any Apple Clang version, though.)
Until this is eventually fixed upstream at <https://github.com/python/cpython>,
just keep pretending that `clang --print-multiarch` would cause no stdout output
on macOS when determining MULTIARCH.
Change-Id: Ic1b27c6791b327d5709a9d61a6d675c3fa8989bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115219
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
otherwise, we could get issues like
> error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: can't open file: /Users/stephan/Software/lo/core/workdir/UnpackedTarball/python3/python-inst/@__________________________________________________OOO/LibreOfficePython.framework/Versions/3.8/lib/python3.8/lib-dynload/_curses_panel.cpython-3.8.so (No such file or directory)
> error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: can't open file: /Users/stephan/Software/lo/core/workdir/UnpackedTarball/python3/python-inst/@__________________________________________________OOO/LibreOfficePython.framework/Versions/3.8/lib/python3.8/lib-dynload/_curses.cpython-3.8.so (No such file or directory)
> error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: can't open file: /Users/stephan/Software/lo/core/workdir/UnpackedTarball/python3/python-inst/@__________________________________________________OOO/LibreOfficePython.framework/Versions/3.8/lib/python3.8/lib-dynload/_testinternalcapi.cpython-3.8.so (No such file or directory)
> error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: can't open file: /Users/stephan/Software/lo/core/workdir/UnpackedTarball/python3/python-inst/@__________________________________________________OOO/LibreOfficePython.framework/Versions/3.8/lib/python3.8/lib-dynload/_dbm.cpython-3.8.so (No such file or directory)
when the two jobs run in parallel
Change-Id: I6db18d7a6fa0ce177e88f8f714434acf9afe3ea5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115218
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
- align with most of the rest of config_host
- rename DISABLE_OPENSSL to ENABLE_OPENSSL
- make this configurable
Change-Id: Ic3b41fcdda38db66134939f12265e0da24833d60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114564
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
There is no longer any "m" in the name suffix. Adapt the names of the
ones we want to remove for macOS.
The idlelib and tkinter dylibs are no longer there at all.
Don't use the -f flag to the rm commands. Thus we will notice the next
time something we want to remove isn't actually there or has been
renamed. But sadly for some unknown reason we do need to use a *
wildcard in the .so names.
Fixes a problem caught by App Store review where the Python curses
module had not been removed as it should have been. (It uses
non-public APIs and can thus not be included.)
Change-Id: I51b9728cc9ca0a962908d3994e3a0ff8e4fa7f60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114372
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
The Windows platform is called Arm64. But now that the ID for Mac
is also going to be renamed from arm64 to aarch64, this get's rid
of the arm64 as the UNO identifier and user in gbuild, just like
on all other Arm64 platforms.
Change-Id: I60a7eafd04b426f17b6e41ad9a09e6405c0d4173
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112973
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Signing them as executable code would require external attributes, and
those in turn break packaging into hfs+ dmg when building on apfs with
Big Sur.
It is not a new thing - the old Code Signing in Depth technote
https://developer.apple.com/library/archive/technotes/tn2206/_index.html
already reads:
"Store Python, Perl, shell, and other script files and other non-Mach-O
executables in your app's Contents/Resources directory. While it's
possible to sign such executables and store them in Contents/MacOS, this
is not recommended.
[…]
Put another way, a properly-signed app that has all of its files in the
correct places will not contain any signatures stored as extended
attributes."
The patch does exactly that for LO and the shipped python framework and
adds symlinks for the moved files.
Same applies for the Language pack applescript and the tarball - those
are also moved into Contents/Resources
Change-Id: Iab21e77b73f941248ca89c6e80703fdf67a1057c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109537
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
On macOS, for various reasons, we use a different approach than on
other platforms to construct the bundled Python.
Instead of explicitly listing what to include (out of what Python
contains and builds) (in ExternalPackage_python3.mk), after Python is
built, we remove stuff we don't want (in ExternalProject_python3.mk)
and then include everything left in the LibreOfficePython.framework
(in GeneratedPackage_python3.mk).
This fixes a problem in App Store review: For some reason the review
said that the setcchar() function from the ncurses library, used by
Python's curses module, is non-public. No idea why the (automated)
review picked on that function. As far as I see from the ncurses
header in the SDK, that function is no less public than the other
ncurses functions that the Python module uses.
But oh well, we don't actually ship the curses module anyway on other
platforms, so just drop it on macOS, too. And while at it, drop the
other unwanted ones, too. And any binary shared libraries for them.
Change-Id: Idecaf10a6fb1c59e8711095927f5699b8d2ec98e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107055
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107141
Tested-by: Tor Lillqvist <tml@collabora.com>
That seems to happen in a sandboxed process on macOS, at least. This
caused an apparent hang when invoking Python, for instance simply
through Tools > Macros > Run Macro... .
Change-Id: I6bc055b44f298251ed596084538b98442c215fce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107013
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
...that happen when building ExternalProject_python3 itself after
12142490cd "Enable Python Py_DEBUG setting when
built with --enable-dbgutil on Linux":
For one, silence
> Modules/posixmodule.c:14395:9: runtime error: left shift of 34 by 26 places cannot be represented in type 'int'
> #0 in all_ins at workdir/UnpackedTarball/python3/./Modules/posixmodule.c:14395:9
where at least my kernel-headers-5.9.9-200.fc33.x86_64
/usr/include/linux/memfd.h has
> #define MFD_HUGE_16GB HUGETLB_FLAG_ENCODE_16GB
and /usr/include/asm-generic/hugetlb_encode.h has
> #define HUGETLB_FLAG_ENCODE_16GB (34 << HUGETLB_FLAG_ENCODE_SHIFT)
For another (and as predicted in 29d47d22c4 "Fix
passing --disable-optimized into external/python3": "in a Linux UBsan build,
making ExternalProject_python3 would have started to cause some 'applying zero
offset to null pointer' failures, but which would have been easy to fix"),
silence
> Objects/listobject.c:551:24: runtime error: applying zero offset to null pointer
> #0 in list_concat at workdir/UnpackedTarball/python3/Objects/listobject.c:551:24
Change-Id: I0523cd35e393000c8e67629a0522b2db1d8c16f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106984
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This has been suggested on IRC for testing fixes/avoiding regressions
when working on the GIL locking in PyUNO.
Change-Id: Ifda21a867b3c0c7db636a9ec950050012e4742de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106791
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Jenkins
There is no /usr/lib/libz.dylib any longer in macOS 11.
No idea whether it works (especially on arm64), but that is another
issue.
Change-Id: I92ac0c500388730eca0be4766f07b1af2d2808e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105897
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Adds three Windows gb_* variables:
- gb_MSBUILD_CONFIG_AND_PLATFORM can be passed as msbuild flags
- gb_MSBUILD_PLATFORM maps debug / release settings
- gb_MSBUILD_CONFIG maps the CPUTYPE to the default msbuild names
and converts the users in external projects.
Change-Id: Ie9b817721180d78d104db11c44241e4b3e46bba9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102701
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
With all the prerequisites in place, LO can be updated to the
current Python release. Interestingly I found that Cygwin always
seems to use LC_COLLATE=C, probably because the default collation
rules are missing.
Then there are the changes introduced in "PEP 587 -- Python
Initialization Configuration", which appearingly have modified the
DLL search path behaviour on Windows, so the OpenSLL DLLs aren't
found anymore in the program directory. As a workaround, the
OpenSLL and libffi DLLs are now (also) installed into the Python
lib dir on Windows.
Change-Id: Ib82f7b77213da9c525f8c79a13d128d9eec9ca64
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98437
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The build setup is rather horrible, with some minimal gcc MSVC
wrapper. But the DLL is a prerequisite for the Python 3.8 build,
which dropped the internal libffi.
It's also possible to build it statically, but then you have to
patch the Python 3 _ctypes msbuild properties.
This also defaults to explicit --build and --host settings, even
without a cross build, because the predicted name would otherwise
differ (*-unknown-* instead of *-pc-*).
Additionally a "make install" also fails...
Change-Id: Ifb7dac840e23efffb9a5e342560aef9e11e0db79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98436
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The OpenSSL 1.1.1 release is currently the only supported version
and it already has the Windows Arm64 support I was looking for.
This change also explicitly enables thread support, which Python
depends on since release 3.7, which removed the --without-threads
build option. But the explicit OPENSSL_THREADS was just added in
3.8.4, so the old no-threads build fails now and was wrong since
probably much longer.
Change-Id: I61d94f966bc59407f213f4a81f0a49d0c05f8948
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98435
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
...which had been introduced with 0f2f719ccd
"tdf#106324: Remove unnecessary test folder from LibreOfficePython framework",
but had apparently forgotten to touch the target file when done, so any make
target that would (indirectly) depend on it would keep rebuilding python3 et al.
Change-Id: I0ac3611383c82c4e91a1eaa02e4cf5db28d326fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93117
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This had originally been covered by dccf47b7f6
"Build python3 with debug flags if --enable-debug", which got broken by
eeeec33ada "merge --enable-selective-debuginfo
into --enable-symbols" (which removed the definition of
gb_Module_CURRENTMODULE_DEBUG_ENABLED without adapting its use here).
But looking again, setting OPT for workdir/UnpackedTarball/python3/configure.ac
based on our various flags doesn't seem to be such a good idea anyway: It is
used to specify a mixture of debuginfo (-g; which is set rather unconditionally,
so no need for us to cater for --enable-symbols here), optimization (-fwrapv,
-O*), and warning (-Wall) flags. So better let
workdir/UnpackedTarball/python3/configure.ac keep deciding for itself what flags
to set in OPT, and then just override via CFLAGS those that do not suite us.
(Where it appears to be a happy coincidence that the Python build system puts
CFLAGS after OPT, so the former can override the latter.)
(An alternative approach could have been to pass --with-pydebug based on e.g.
--enable-dbgutil, as the former (a) causes OPT to include -O0 rather than -O3,
and (b) is documented to change the ABI (see
workdir/UnpackedTarball/python3/configure.ac: "Py_DEBUG implies assertions, but
also changes the ABI."), so probably best fits --enable-dbgutil. However, at
least on Linux, --with-pydebug produces
workdir/UnpackedTarball/python3/libpython3.7dm.so rather than
workdir/UnpackedTarball/python3/libpython3.so, so would have required further
modifications. Also, in a Linux UBsan build, making ExternalProject_python3
would have started to cause some "applying zero offset to null pointer"
failures, but which would have been easy to fix.)
(I noticed the missing -O0 when I attached gdb to an instdir/program/python.bin
process and `py-bt` only showed "(frame information optimized out)" frames,
which this change fixes for --disable-optimized builds.)
Change-Id: I9583e60692ae7130377422062f3c6df9334d693f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92362
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This requires installed ninja, gyp is included as source. This
allows nss be built as a parallel build, unlike the old Makefile
build system.
Since gyp internally uses python, even recursively, this requires
more complicated setup in case our internal python is used. Moreover
gyp itself seems to be kind of deprecated itself and hasn't
been ported to python3 yet, so that needs patching too.
So far only easy Unix-like systems are converted, Windows I'll
do later, the more complicated systems I'll leave to whoever
has access to them.
Change-Id: I358baad7690d2aa6df44bafa9244dc7cc828fc3f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90115
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
(where 16.4 is currently the latest version of Visual Studio 2019 available at
<https://visualstudio.microsoft.com/downloads/>), see
<https://lists.freedesktop.org/archives/libreoffice/2020-February/084575.html>
"ESC meeting minutes: 2020-02-27": "Update baseline to VS2019 on master before
7.0 [...] check what’s the current patch level, require that? [...] no
objections"
The code from 4ea0059bca "VS detection: Fallback
to old registry check if vswhere failed" has been removed in accordance with its
comment "The below hack does not work for VS 2019 anyway, so should be removed
when upgrading baseline.
(Changing the comment "go to Start menu, open 'Visual Studio 2017', [...]"
regarding the installation of GNU Make from source is somewhat arbitrary, but
lets stick to the tradition of bumping that version number along with any build
baseline bump.)
Change-Id: Ic4fe8a3d347aa1748377f2d3205e302bff189b79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89699
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
See instructions in solenv/gbuild/Trace.mk . This generates a file than
can be viewed e.g. in the Chromium tracing view.
Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The LO python3 target fails for me on Windows with:
C:\lode\dev\core\workdir\UnpackedTarball\python3\PCBuild\openssl.props(24,5):
error MSB3030: Datei "C:/lode/dev/core/workdir/UnpackedTarball/openssl/out32dll\libcrypto-1_1.dll"
konnte nicht kopiert werden, da die Datei nicht gefunden wurde.
[C:\lode\dev\core\workdir\UnpackedTarball\python3\PCBuild\_ssl.vcxproj]
Same for
"C:/lode/dev/core/workdir/UnpackedTarball/openssl/out32dll\libssl-1_1.pdb"
"C:/lode/dev/core/workdir/UnpackedTarball/openssl/out32dll\libcrypto-1_1.pdb"
"C:/lode/dev/core/workdir/UnpackedTarball/openssl/out32dll\libssl-1_1.dll"
Other files were also renamed in a previous hunk of this patch.
For other people these failures are silently ignored, but they
show up in their python3 build.log. But my msbuild version
15.9.21+g9802d43bc3 from VS2017 fails hard on these errors.
So this just adapt the pdb and dll names to match the previous
renames, which passes the copy calls, so the build continues.
Change-Id: Iffc848c334caec534f6e99f8bf83a42da570bbb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87358
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Jenkins
CPython commit f40d4ddff3c800b3c956a5e8820aabe3aa87cddd "Closes #27979:
Remove bundled copy of libffi" causes a bit of a problem because it
turns out that libffi isn't all that stable; there's libffi.so.5 on
CentOS 6, libffi.so.6 on CentOS 7 and libffi.so.7 on
lo_daily_update_gandalf tinderbox.
So we have to bundle it in LO; it's only used on GNU/Linux currently.
CPython commit 32119e10b792ad7ee4e5f951a2d89ddbaf111cc5 "bpo-35947:
Update Windows to the current version of libffi (GH-11797)" also removes
the libffi for MSVC, so in a future python upgrade we will have to build
libffi for MSVC too.
The libffi fork for MacOSX is still in CPython git master.
(regression from b10be5d484)
Change-Id: Ibc20cf8cd3614cf9941b6970662bd930496776b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86493
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Of course the autotetection in setup.py strikes again, the build will
fail if the user doesn't have libuuid-devel installed; we'd need to add
a check to LO's configure.ac for libuuid.
Let's just not ship it, not sure if anybody needs it.
Change-Id: I9079309da7d9c16e666fbab30542365124f97860
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86433
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
* external/python3/python-3.3.3-aix.patch.1:
most of it doesn't apply and AIX port isn't maintained anyway so
remove it for now
* external/python3/ubsan.patch.0:
apparently one of the files was removed
* 0001-3.6-bpo-17239-Disable-external-entities-in-SAX-parse.patch.1:
fixed upstream
* python3-osx-avoid-new-10.13.patch.1:
replace with simply passing ac_cv_func_utimensat=no to configure
* external/python3/python-3.5.4-ssl.patch.1:
project files to build OpenSSL removed upstream
* There have been changes to how python locates OpenSSL; new variables
OPENSSL_INCLUDES etc; it turns out that you have to pass one directory
to --with-openssl, as the variables cannot be passed
* libuuid.so.1 is a new dependency of the _uuid module
* libffi.so.6 is a new dependency of the _ctypes module (the bundled
copy of libffi for non-Darwin platforms was removed)
* python-3.3.0-pythreadstate.patch.1:
the PyThreadState functions have been changed such that
CppunitTest_services asserts when there is a PyThreadAttach on top of
PyThreadDetach on top of PyThreadAttach, i.e., 2 PyThreadState per
thread (PyGILState_Check() fails). Instead of patching in additional
workarounds, change PyThreadAttach so that it re-uses an existing
PyThreadState if one exists for the thread.
Change-Id: I24c19d79b43a30709261fd9db66312b2e3872fd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84765
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Fixes CVE-2019-9948 CVE-2019-9740 CVE-2019-10160 CVE-2019-16056
and expat CVE-2019-15903.
python-3.3.5-pyexpat-symbols.patch.1 fails to apply, and it's a
mystery why --with-system-expat is used everywhere but on MacOSX,
where 292af048ac disabled it for no
obvious reason, so try to remove the special case and get rid of the
patch.
Change-Id: I5ba4532eb6e7c2fb90daba95d132dcc7c9013d96
Reviewed-on: https://gerrit.libreoffice.org/83117
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
...which was at maximum set to GCC's -finline-limit=0 -fno-inline
(solenv/gbuild/platform/com_GCC_defs.mk). Those options were set for debug
builds "since forever", but that looks very much like cargo cult: -fno-inline
"is the default when not optimizing" anyway
(<https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Optimize-Options.html>), and it
is unclear to me how -finline-limit=0 should have any impact beyond -fno-inline
(and maybe was present for ancient compilers that only supported -finline-limit
but not -fno-inline?).
Change-Id: Id6752d03b1b7ec8763defabc5720d4dd08790874
Reviewed-on: https://gerrit.libreoffice.org/66836
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
..."target does not support '.file' without a number", which was introduced into
LLVM with <http://llvm.org/viewvc/llvm-project?view=revision&revision=349976>
"[MC] Enable .file support on COFF and diagnose it on unsupported targets",
stating: "The 'single parameter' .file directive appears to be an ELF-only
featurea [sic] that is intended to insert the main source filename into the
string table table [sic]."
And <https://sourceware.org/binutils/docs-2.31/as/File.html> states about the
default single (file name) argument version: "This statement may go away in
future: it is only recognized to be compatible with old as programs."
As external/python3 builds just fine on macOS with that .file directive removed,
lets just do that for now.
Change-Id: Ib28c29d0cacd151437447ccb2f6cfb8925e3e85a
Reviewed-on: https://gerrit.libreoffice.org/65704
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
No need to distribute that, apparently. We don't ship it on Windows,
either.
Change-Id: I76bf77311caceccd07afb0afa2f097b63f58bf54
Reviewed-on: https://gerrit.libreoffice.org/59034
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
At least Fedora 28 glibc-2.27-8.fc28 no longer provides the nis development
headers and libraries. (It only still contains some binaries for backwards
compatibility, in the libnsl sub-package: "This package provides the legacy
version of libnsl library, for accessing NIS services.")
There is probably no real need to have nis.cpython-*m.so contained in
external/python3/ExternalPackage_python3.mk (it probably just happened to build
fine when that list was originally created, so was included).
Change-Id: Ic6128fd872432005c0ded76640c5b56781ca69a1
Reviewed-on: https://gerrit.libreoffice.org/52535
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Jan-Marek Glogowski