...so configure.ac would mis-determine JAVA_HOME as /app, would add
-I/app/include -I/app/include/linux to SOLARINC, and #include <jni.h> would not
be found.
At libreoffice flatpak build time, the java-11-openjdk rpm will populate
/etc/alternatives (even though that is outside /app) with symlinks to
/app/lib/jvm, so that the symlink chain /app/lib/jvm/java ->
/etc/alternatives/java_sdk/ ->
/app/lib/jvm/java-11-openjdk-11.0.9.11-9.module+f33+3+4101bf32.x86_64/ (or
whatever the latter's exact name) will work. (At flatpak composition time,
those non-/app files will be dropped from the resulting flatpak, so that
container.yaml needs to set up the /app/lib/jvm/jre-flatpak symlink for
--env=JAVA_HOME=/app/lib/jvm/jre-flatpak to find the Java installation under a
stable name, as then the /app/lib/jvm/jre -> /etc/alternatives/jre/ symlink will
be dangling.)
Those two packages' "Tools - Macros - Organize Macros -
{BeanShell,JavaScript}..." each have an "Edit" button that wants to bring up a
Swing UI, so silently fails with a Java exception if full java does not happen
to be installed in addition to libreoffice-core's dependency on java-headless.
In theory, a user could always have other LO Java extensions that require non-
headless, so the "correct" approach would be to make libreoffice-core depend on
full java. But to avoid dependency bloat, only make those sub-packages require
it that obviously need it.
(The ">= 1:1.6" is carried over from libreoffice-core's java-headless
requirement for consistency, even though it is probably cargo-cult by now.)
originally added to log build-time tool crashes
commit 4cfeb5ea50
Author: Caolán McNamara <caolanm@redhat.com>
Date: Sat Apr 25 13:53:26 2015 +0100
get gdb to put bt into build log on failure
libreoffice fails to build on ELN because liborcus is 0.16, but the patches for liborcus 0.16 is only for Fedora >=34.
This patch fixes that.
No rawhide rebuild is needed, so I did not do a release bump.
Signed-off-by: Troy Dawson <tdawson@redhat.com>
See the upstream 0001-Pass-fno-lto-unconditionally.patch commit message for
details. But even with that fix, aarch64 %check would still fail with
> xmltesttools.cxx:170:Assertion
> Test name: testEmbedImagesEnabled::Import_Export
> equality assertion failed
> - Expected: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAACXBIWXMAAA3ZAAAN2QHmodeGAAAFyUlEQVR4nO1Za2gcVRQ+szuzO9ndZtfEktY2tVorVdNKxRpQweqPmh/B1w8JhCL4R4RYiPhCfKFEfwX/2VYULJIqJFDqg4KC1EaoEoyGhFJClBgbN+a9z9ndeXnOzJ3szCbbQuY2i5ADh5udmXvP953z3cdMRNM04f9sYq0B+LVNArW2TQJXM0EQdmKTQL+Mi4V2PWJwJ4CgBUkKdImi9F48HpGikTptfj4l19fLX2cyxeeQyALPeNwJxOOx/r17djz6+afdsX233QBg5CCXWYS3es62n/js4mXkdyeSmOMVjysBURQ7djVvbRv87p2oLJUAtHmLQDSUg963W8MhMSscPzXWh48e4RaT10BkKJkXens6orKYRvBZC7zlut2+231r6MOTI4exCgmswjKPmFwJFIvFu+5pqbczr7vB22QkMwd7d8vK2Hj+AD5+gUdMrgRCUnD+yt9T8ZubGsrAHSKMTHK2SDGTvGJyJaBp2g/9Z4abH7j7YMjJupvA0Mgi5BVDxUcneMXkSiCTVV/75ItLTx1qCTR2PpbwEJiYTMHjXamcUjSfMTmeIH0TwAm5H5s96JPou3N57f3n3xh99URfuL79IVmOR1UYGlXUL89phqrCabuLcAjbRvQCcjlfMwII5PCWaPib1ntv0S4O/Skn4jHhjn27FMPQ4d/ZJePjgWzJNExBDCW0gwciWp0ceLpQLHaMjM3UNTeZhcU0CLGI8FE2b75SEwJhSWx/ueuR6JvdD8Kx18+Yl/4oCN8PHEP9KyibAoC50krO76Hf/4EjnUkYHYDY+F8A93XCszhUbQiQSUHcsPQFJINz00TX5hhodCJS2WpLIAbBDARAkMN+o/OYxEYeQS0y0Gz3rQTtJmQs+0ftMp8EDFsm+qLdmvhbn7cBr8o+k5Se5oOcGZ8K6E4FBHb+8ejfS0jLcYBdNn4SInBm0CuhSiIkMc7fEPxLiIDqKgMZYgQqdA86F7Brmf8KmCQhzV6BKLvWHGBy2QDzEKAtEpsgu04eoMvsNqVRY62OO6hhXbXAsieIhL60AbDLZhFA3AQa6w8xsN9hybegy+wZAkspzaAvk2OfTFhaIcds4z+SiQiEABLwrejb0ZvQ8VBvESJiDkgigbPQIjGLfoU9U1NzZCKBnW0iEkEPu+6RUWqJCAGuQ4+CXaXIxsJdbQSSdE27iyMTEjG+jVsSIrBEziFCz1IViOBOzYD6C8OgPvEwSIPDYDYkvJJK4nx+qReMvg9W+oOEo2UVEEbGAcYmrMwovgjQZEQZlRgJhwBVIs6c5EQZp2yHGDHygK7Dzz/9Bvtbj8I2/Ft5EVv34HO4PZw97w24rdFqCvcfhZIQgEJOgSd9EUDwjoQINA1/I5QrILN7QZc7RtnWMjk4zn634QGtzT04ZhoQYEDH2gYD5esBAUo5xYz7Ab5CAGx9Oxp3iDQwAtJV+jp9qlo2b7cpnPYNXri0Ygex+r53OJKQiYPReypJiDROmqQDC8khAXYVnNXIWSeFa4F3E1hKewmwQUIYt+D39dLaB9ggJRyQCBQYGZoLtKzS8uosq4Eq46wJwiGwnFmzj8rj3dizE7MJXQS7EhQ+BTaRm8CeHzSZSVZO9t0VWWVZtr5UIUDzz1jZ0XkQsBDZWdFwcOfokAV79yVJUTVirn4kLQnKc8lLoHoFqJI70BcwDj2lrZdI1cPcGrKir8oRKFeAwEcZKfJVExJXKGuiVyFwO/o0+gx6ipby9UjqmqdRlhmSVRGDpKEsF2dnpi/NdPxIVfZdTlukiECw4hYBpaQYbBzn0MifgCeqnSF3EIVViGQwfbIfSl/9CCoDA5PT1vjJ3lOw/fQ5KwmmqtESav39K7rKXF/vhPb9PoBxVUaiZ2YBBtGdsxQZZfmX5AK0oFtAwc76FPbj8nLM5dMiy14aiXwLthyc5dZgm9UUjzhrGddvo4yIDtfzHbLCNv9LWWvbJFBr2yRQa/sP25LGjrtpN08AAAAASUVORK5CYII=
> - Actual : data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAACXBIWXMAAA3ZAAAN2QHmodeGAAAFrklEQVR4nO1Ya2gcVRQ+szuzO9ndZNfEkMQ2tVorVdNKxRpQweqPmh+hPn5IIBTBPyLEQsQX4gsl+iv4z7aiYJFUIYFSHxQUpDZClWA0JJQSosTYuDHJJtnn7O68PHfmTDL7aArZmyyFXDjcfcy95/vO+c59jGiaJtzITaw2gErbNoFqt20C6zVBEHZiF0G7gouFthk+uBNA0IIkeXpEUXo/HA5IwUCNtrgYl+vq5G+SydzzSCTG0x93AuFwaHDvnh2Pf/FZb2jfHTcBGGlIJ5fg7b5znSc/v3QF+d2NJBZ4+eNKQBTFrl2tjR3D378blKU8gLZoEQj60tD/TrvfJ6aEE6cnBvDRI9x88poIrOgHXuzv6wrKYgLBpyzwlul2/17v7b6PTo0dxixEMAsrPHxyJZDL5e65r63OjrzuBm+Tkcw07N0tKxOTmQP4+EUePrkS8Enexav/zIRvbapfA+4QITLR+RzzGeXlkysBTdN+HDw72vrQvQd9TtTdBEbGliCjGCo+OsXLJ1cCyZT6+qdfXn76UJunoftopIDA1HQcnuiJp5Wc+azJ8QRZMQEsyP3Y7UGbRtudzmgfvPDm+GsnB/x1nY/Icjiowsi4on51XjNUFc7YQ4RD2DegZZHLhaoRQCCHa4P+b9vvv027NPKXHAmHhLv27VIMQ4f/5peNT4ZSedMwBdEX0Q4eCGg1sueZbC7XNTYxV9PaZGaXEiCEAsLHqYz5alUI+CWx85Wex4Jv9T4Mx984a17+Myv8MHQc9a+gbLIA5movOd9H/vgXjnRHYXwIQpN/AzzQDc/hVNUhwJrkxQ1LjyEZrE0TTVsg0GiMSHGvLYPoBdPjAUH2V+qdRxEbGQS1RKBp9y0G7SZkrFSOGrgRMGyZ6Et2b+J3fdEGXBJ9kpSe4IMceGZAdzIg0PmnQP+FhLQ0B9iwCRJi4ExvoYSKiTCJcX6HULmEGFBdJZA+IlCke9C5gC3XKs+AySSk2SsQi65VAySXLWhi8W0KOy/9zszDfqa/WRg16nXcQQ3rVwssPcFI6MtbABsKCSBuBhrzDyGw77DMatFkeoaBZSFNoq0wwzFJv7RKjtrWvyQTEYhIwBvRWtCa0PBQbxHyujLASGAVWiTm0a7SM1VtjkwksKPNiATQ/K7/gEIrEOAatCDYWQpsLdzSJpKuEy6ZMBHjbdySUA2Rc4holAVGcKdmQN3FUVCffBSk4VEw6yOFkopiPb/cD8bAh6vjQcLZUgoIY5MAE1NWZJSKCLBiRBnliYRDgGUiTFZHEQ9QBmrJPLoOv/z8O+xvPwbN+Fl5CXv35Au4PZy7UOiwucHqsg8eg7zggWxagacqIoDgHQmF6Ix+M6xlQKb/vC5zGou2lkzDCfregQe0DvfkGGlAgB4dc+v1rP3uESCfVsxwJcDBJSET1jTuEKknAtI6Y01XgZdtqYzdx7Hs68Ml77+8mP2KdzgmIRMnU0lCTONMk+zA0kyFKrtWI9MV/XXBuwksJwoJ0CQ+9Jut9Hpp7QM0SR4n1KgOElQLLbS8OsuqSwhw3Q3AIbCSLDtG5XE3LtiJqaBzYGeCuY+DTeQWsOsjSLISioCXzUZKWZcAqz9jdUfnQQDWsqHh5M7RIQX27ttM2Qi5xnmJkFguC+tkgGVyB1oM/bCntI0SueZhroysYrSUOhnwUkYayUoKElcoq9CvQeBOtFm0ObQ4W8o3IqnrnkYpMkxWOXSScMnF2ZkX6PgRLx67krBIMQJeKK2ZLG2eguvQyJ8AlGbF7UShDDEZzJ4ahPzXP4HqkJyeteaP9p+GljPnrSCYqsaWUOvzb2gqmb7Rgq74PoB+VSLRNxeDYTTnLAUU5V+jMWhDU0lmLOozOI7L5ZjLq0WKXgKJfAe2HJzl1qDNaoaHn3KN67tRIqLDZt4hYRMJVKNtE6h22yZQ7XbDE/gf25LGjrgcuP4AAAAASUVORK5CYII=
> - In <file:///tmp/lu137295836rgnq.tmp>, attribute 'src' of '/html/body/p/img' incorrect value.
during CppunitTest_sw_htmlexport, apparently for another reason that still needs
investigating.
Upstream <https://git.libreoffice.org/core/+/
a58e086ededb8442938e81f971dfae36ef7eb076%5E!> "rework the default make target"
towards libreoffice-7-0 had dropped the unitcheck and slowcheck targets from the
default target.
But after the preceding b27571d688 "Enable LTO
again", that reveals that there appears to still be issues with LTO at least on
i686, which fails with
> ### unexpected exception content! failed
> ### unexpected exception content! failed
> ### unexpected exception content! failed
> exception test failed
> oneway exception test failed
> exception occurred: error: test failed! /builddir/build/BUILD/libreoffice-7.0.0.3/testtools/source/bridgetest/bridgetest.cxx:1176
> > error: error: test failed! /builddir/build/BUILD/libreoffice-7.0.0.3/testtools/source/bridgetest/bridgetest.cxx:1176
> > dying...make[1]: *** [/builddir/build/BUILD/libreoffice-7.0.0.3/testtools/CustomTarget_uno_test.mk:25: /builddir/build/BUILD/libreoffice-7.0.0.3/workdir/CustomTarget/testtools/uno_test.done] Error 1
(<https://koji.fedoraproject.org/koji/getfile?taskID=49136895&volume=DEFAULT
&name=build.log&offset=-4000>), so keep LTO disabled there until the issue is
addressed.
Note that for aarch64, armv7hl, and s390x %check is currently no-op, so it is
not obvious from just building the package whether or not they will have issues
with LTO at runtime. But at least for ppc64le and x86_64 the (non--no-op)
%check has been seen to succeed with LTO enabled, including the
CppunitTest_sw_apitests for which LTO had originally been disabled for LO 6.4 in
5d644f1606 "%check fails with lto enabled" (see
<https://koji.fedoraproject.org/koji/taskinfo?taskID=49136767>).
It had reportedly been disabled due to failing CppunitTest_sw_apitests in
LO 6.4. My recent upstream check with --enable-lto on master towards LO 7.1
found CppunitTest_sw_apitests to work fine, and only found one other failing
test in CppunitTest,xmlsecurity_signing, but which is new for LO 7.1 and not yet
present in LO 7.0 (see <https://git.libreoffice.org/core/+/
800eebfa82106c509310ed43bef38a7a4ad4451f%5E!> "Database document apparently
needs to be closed before it is disposed" and <https://git.libreoffice.org/core/
+/2f2246d22e2a8ccbc1dc3e6f5243734a61edf270%5E!> "external/cppunit: Run tests in
deterministic order".
From a successful scratch build of this commit, it looks like
CppunitTest_sw_apitests already works fine in LO 7.0, and that there are no
other issue with LTO in LO 7.0.
...by reusing as much as possible the existing upstream logic used for the LO
Flathub build
(cherry picked from commit f41687290dfe86f835013db93f08f92eb6e62c06)
(see <https://docs.fedoraproject.org/en-US/flatpak/>). For one, various paths
need to be configured explicitly, as LO's configure would fall back to hardcoded
/usr paths instead of the /app paths needed here. For another, it is unclear to
me why those three __pycache__ files are not generated, but just not asking to
include them should be harmless.
Forward-ported from f31, combined cherry-pick of:
* bfd5f11376b8c70e5280f6aa307390e0b6246654 "Adapt to Flatpak-from-RPM build"
* 385664d08b0e1fa3cde3ea3fc7fa20279a109280 "Hack libreoffice-multiliblauncher.sh
for flatpak"
* decfe42573aed89586a937a05e5a653b0847afc0 "Fix Flatpak-from-RPM build"
* 093c4953a62c12cf0335025c6a9aa9bad0b86cf1 "Fix Flatpak-from-RPM build"
* 3d51346db2cf92f63653a76cd534d0a3afe4b0d2 "Fix Flatpak-from-RPM build"
* a9e4c56f3282ce801570c890e4b1dee221f2adc2 "Fix flatpak
--with-commons-logging-jar"
Drop the explicit postgresql-libs Require; that's not needed
since there's an implicit Require on libpq.so.5() anyways.
The libpq.so might move to different package, so don't depend on
postgresql-devel package name.