In preparation, sort of.
(In reply to Andreas Sturmlechner from comment #0) > In preparation, sort of. i have been using yours ebuild and modified it a bit in my overlay (hedmos-overlay). it has been working good for month now. feel free to comment or give me some feedback if you like.
7.0.1 is out
(In reply to Silvio from comment #2) > 7.0.1 is out yes i have 7.0.1.2 .and 7.0.2.1 is out to but not with |10n..
but libreoffice-7.x depends on dev-libs/qrcodegen and that is not in portage....
(In reply to andy from comment #4) > but libreoffice-7.x depends on dev-libs/qrcodegen and that is not in > portage.... And it's unclear why we don't have this in tree yet. Rather utilitarian library given it has multiple language bindings. Python bindings are available from PyPi. see https://www.nayuki.io/page/qr-code-generator-library
(In reply to Scott Furry from comment #5) > (In reply to andy from comment #4) > > but libreoffice-7.x depends on dev-libs/qrcodegen and that is not in > > portage.... > > And it's unclear why we don't have this in tree yet. Rather utilitarian > library given it has multiple language bindings. Python bindings are > available from PyPi. You'll have to find a volunteer to deal with the trainwreck build system. There's bug 691740 for that, but it does not affect libreoffice-7 version bump at all.
So it is not possible to have a quick solution, is it?
Here in pg_overlay there is an ebuild for 7.0.2.2 https://data.gpo.zugaina.org/pg_overlay/app-office/libreoffice/ I'll test it soon.
Yeah, that's an outdated copy with incorrect virtual/jdk minimum dep.
(In reply to Andreas Sturmlechner from comment #9) > Yeah, that's an outdated copy with incorrect virtual/jdk minimum dep. So do you advise me not to use it?
(In reply to Silvio from comment #10) > (In reply to Andreas Sturmlechner from comment #9) > > Yeah, that's an outdated copy with incorrect virtual/jdk minimum dep. > > So do you advise me not to use it? It doesn't compile ... Do you know how much time will it take to deliver the ebuild in portage?
(In reply to Silvio from comment #11) > (In reply to Silvio from comment #10) > > (In reply to Andreas Sturmlechner from comment #9) > > > Yeah, that's an outdated copy with incorrect virtual/jdk minimum dep. > > > > So do you advise me not to use it? > > It doesn't compile ... > > Do you know how much time will it take to deliver the ebuild in portage? It does compile app-office/libreoffice-7.0.2.2::pg_overlay was built with the following: USE="branding cups dbus kde mariadb pdfimport -accessibility -bluetooth -coinmp -debug -eds -firebird -googledrive -gstreamer -gtk -java -ldap -odk -postgres -test" LIBREOFFICE_EXTENSIONS="-nlpsolver -scripting-beanshell -scripting-javascript -wiki-publisher" PYTHON_SINGLE_TARGET="python3_9 -python3_7 -python3_8" CFLAGS="-march=native -mtune=native -O3 -pipe -fdata-sections -fdevirtualize-at-ltrans -ffunction-sections -fgraphite-identity -fipa-pta -flto=9 -floop-interchange -floop-nest-optimize -floop-parallelize-all -fomit-frame-pointer -fuse-linker-plugin -fno-asynchronous-unwind-tables -fno-plt -fno-stack-protector -s" CXXFLAGS="-march=native -mtune=native -O3 -pipe -fdata-sections -fdevirtualize-at-ltrans -ffunction-sections -fgraphite-identity -fipa-pta -flto=9 -floop-interchange -floop-nest-optimize -floop-parallelize-all -fomit-frame-pointer -fuse-linker-plugin -fno-asynchronous-unwind-tables -fno-plt -fno-stack-protector -s" FEATURES="config-protect-if-modified preserve-libs multilib-strict xattr userpriv sfperms strict metadata-transfer ebuild-locks sandbox assume-digests merge-sync qa-unresolved-soname-deps unknown-features-warn usersync binpkg-logs ccache binpkg-dostrip protect-owned ipc-sandbox userfetch parallel-fetch binpkg-docompress pid-sandbox usersandbox network-sandbox unmerge-logs unmerge-orphans parallel-install news fixlafiles distlocks" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -Wl,--sort-common -Wl,-z,norelro -march=native -mtune=native -O3 -pipe -fdata-sections -fdevirtualize-at-ltrans -ffunction-sections -fgraphite-identity -fipa-pta -flto=9 -floop-interchange -floop-nest-optimize -floop-parallelize-all -fomit-frame-pointer -fuse-linker-plugin -fno-asynchronous-unwind-tables -fno-plt -fno-stack-protector -s"
IUSE=-java...
(In reply to Andreas Sturmlechner from comment #13) > IUSE=-java... Yep, I don't like java
(In reply to Andreas Sturmlechner from comment #9) > Yeah, that's an outdated copy with incorrect virtual/jdk minimum dep. It's from libreoffice-9999
Please go to the forums instead if you want to have a forums style discussion. - The blocker of this bug is well documented, any work on libreoffice-9999 is also stalled until this is solved. - It's your overlay, you do you - but don't pretend it 'works' when it only does with a limited IUSE set.
(In reply to Andreas Sturmlechner from comment #16) > - It's your overlay, you do you - but don't pretend it 'works' when it only > does with a limited IUSE set. --------------------------------- okay, build with java. what next? --------------------------------- ``` app-office/libreoffice-7.0.3.1::pg_overlay was built with the following: USE="branding cups dbus java kde mariadb -accessibility -base -bluetooth -coinmp -debug -eds -firebird -googledrive -gstreamer -gtk -ldap -odk -pdfimport -postgres -test" LIBREOFFICE_EXTENSIONS="-nlpsolver -scripting-beanshell -scripting-javascript -wiki-publisher" PYTHON_SINGLE_TARGET="python3_9 -python3_7 -python3_8" CFLAGS="-march=native -mtune=native -O3 -pipe -fdata-sections -fdevirtualize-at-ltrans -ffunction-sections -fgraphite-identity -fipa-pta -flto=9 -floop-interchange -floop-nest-optimize -floop-parallelize-all -fomit-frame-pointer -fuse-linker-plugin -fno-asynchronous-unwind-tables -fno-plt -fno-stack-protector -s" CXXFLAGS="-march=native -mtune=native -O3 -pipe -fdata-sections -fdevirtualize-at-ltrans -ffunction-sections -fgraphite-identity -fipa-pta -flto=9 -floop-interchange -floop-nest-optimize -floop-parallelize-all -fomit-frame-pointer -fuse-linker-plugin -fno-asynchronous-unwind-tables -fno-plt -fno-stack-protector -s" FEATURES="qa-unresolved-soname-deps strict multilib-strict binpkg-docompress unmerge-logs preserve-libs ccache binpkg-dostrip config-protect-if-modified ipc-sandbox news sandbox distlocks assume-digests usersandbox ebuild-locks unmerge-orphans pid-sandbox parallel-fetch network-sandbox sfperms binpkg-logs userfetch merge-sync unknown-features-warn fixlafiles xattr userpriv metadata-transfer protect-owned parallel-install usersync" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -Wl,--sort-common -Wl,-z,norelro -march=native -mtune=native -O3 -pipe -fdata-sections -fdevirtualize-at-ltrans -ffunction-sections -fgraphite-identity -fipa-pta -flto=9 -floop-interchange -floop-nest-optimize -floop-parallelize-all -fomit-frame-pointer -fuse-linker-plugin -fno-asynchronous-unwind-tables -fno-plt -fno-stack-protector -s" ```
(In reply to Perfect Gentleman from comment #17) > --------------------------------- > okay, build with java. what next? > --------------------------------- Awesome! Now fix your ebuild to depend on >=jdk-1.9, then add it straight to package.mask. Or go help fix bug 629252. Otherwise your stuff is still broken.
(In reply to Andreas Sturmlechner from comment #18) > (In reply to Perfect Gentleman from comment #17) > > --------------------------------- > > okay, build with java. what next? > > --------------------------------- > Awesome! Now fix your ebuild to depend on >=jdk-1.9, then add it straight to > package.mask. Or go help fix bug 629252. Otherwise your stuff is still > broken. I've build it openjdk bumped to 15.0.1_p9. The problem is that LO doesn't detect OpenJDK. But binary from office site detected it.
> I've build it openjdk bumped to 15.0.1_p9. The problem is that LO doesn't > detect OpenJDK. But binary from office site detected it. But it works anyway. Installed java-dependent extension.
(In reply to Perfect Gentleman from comment #20) > > I've build it openjdk bumped to 15.0.1_p9. The problem is that LO doesn't > > detect OpenJDK. But binary from office site detected it. > > But it works anyway. Installed java-dependent extension. It works with openjdk-jre-bin, not with openjdk. Why? -\o/-
> It works with openjdk-jre-bin, not with openjdk. Why? -\o/- Could not create Java implementation loader /tmp/portage/app-office/libreoffice-7.0.3.1/work/libreoffice-7.0.3.1/stoc/source/javaloader/javaloader.cxx:314
i have this in my ebuilds: DEPEND="${COMMON_DEPEND} java? ( dev-java/ant-core >=virtual/jdk-11 RDEPEND="${COMMON_DEPEND} java? ( >=virtual/jre-11-r1 ) elog "libreoffice needs jdk9+ for USE=java and is masked (-gentoo-vm) at the moment." elog "if you want to override it.. have a look in:" elog "https://wiki.gentoo.org/wiki//etc/portage/profile/package.use.mask" i dont know if this is still vail.but if it is Andreas Sturmlechner is right and the problem has to be fixed before it goes to portage.
(In reply to Perfect Gentleman from comment #22) Version from pg_overlay worked pretty well, thanks. But for now it doesn't with jre/jdk-15 or I just don't know how to make it work properly. I'll resort to main Gentoo tree for a while. But thank you for your ebuilds, efforts and time spent.
(In reply to Ivan from comment #24) > (In reply to Perfect Gentleman from comment #22) > > Version from pg_overlay worked pretty well, thanks. But for now it doesn't > with jre/jdk-15 or I just don't know how to make it work properly. > > I'll resort to main Gentoo tree for a while. > But thank you for your ebuilds, efforts and time spent. It works well with openjdk-jre-bin. As I said earlier LO doesn't detect it but it works as Java-dependent extension was installed and tested for working. I don't get it why LO doesn't work with openjdk as LO-7 downloaded from official website detects openjdk and openjdk-bin and works with them normally.
someone got my attention to this bug... would never have seen it otherwise. stale issues tracker is here, I can add it to the mask. https://bugs.gentoo.org/697014 but in reality nobody works on java:11 issues actively and tracker does not reflect reality at all, much more things are broken. as for OO, you can depend on || ( openjdk:11 openjdk-bin:11 ) directly for now if you just need JVM, stable symlinks are provided via /usr/$(get_libdir)/openjdk-11/bin/java and /opt/openjdk-11/bin/java (typing from memory) but those paths are not in $PATH. also will have to stable-mask java flag in oo, because openjdk-11 is not getting stable anytime soon, sorry. unmasking virtual/jdk:11 wreaks complete havoc on anything pulling java/deps. getting it stable wreaks even more chaos. we can add openjdk:!5 as well (it's short-lived version and will be dead in several month), but situation will be exactly the same as with 11. as for https://bugs.gentoo.org/show_bug.cgi?id=629252, it's not getting anywhere. there will be no new icedtea. and even old once might get removed/masked soon. just use openjdk, whatever version suits. I'm available to help figure out sane way of getting existing jdk to work with it, so lmk.
(In reply to Georgy Yakovlev from comment #26) > there will be no new icedtea That is not only untrue (we literally released a new version yesterday), but I don't see how you are in any position to speak on it.
(In reply to Andrew John Hughes from comment #27) > (In reply to Georgy Yakovlev from comment #26) > > > there will be no new icedtea > > That is not only untrue (we literally released a new version yesterday), but > I don't see how you are in any position to speak on it. thanks, I almost masked due to security issues. I've already bumped it earlier today in gentoo repo before it got bumped in java overlay, so we are good. What I meant there will be icedtea-4 or 11 or whatever. that's the impression I got lurking in other older bugs from JDK9 times. this is a sentence/discussion taken out of context of https://bugs.gentoo.org/show_bug.cgi?id=629252 which was used as a blocker of this bug. I just pointed out this current bug should not wait for icedtea version 4 (or later) as it probably will not happen and just use openjdk-11. btw, Andrew, while I have you attention, I would like to sync ::gentoo icedtea ebuild with the one you maintain in ::java-overlay, what's the preferred method of sending patches to you? I got some changes, ebuilds are diverging. I mailed you but never got a reply.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2c31a3aa736f52ba28567b41c80d71069654334f commit 2c31a3aa736f52ba28567b41c80d71069654334f Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2020-10-29 08:37:55 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2020-10-29 10:40:01 +0000 app-office/libreoffice: Add 7.0 stable branch Bug: https://bugs.gentoo.org/739134 Package-Manager: Portage-3.0.8, Repoman-3.0.2 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> .../libreoffice-7.0.3.1-fix-non-pdfium-build.patch | 29 + app-office/libreoffice/libreoffice-7.0.9999.ebuild | 603 +++++++++++++++++++++ 2 files changed, 632 insertions(+)
Thanks for clearing things up. (In reply to Georgy Yakovlev from comment #26) > also will have to stable-mask java flag in oo, because openjdk-11 is not > getting stable anytime soon, sorry. > unmasking virtual/jdk:11 wreaks complete havoc on anything pulling java/deps. > getting it stable wreaks even more chaos. How about stabilising openjdk:11 without virtual/jdk?
RDEPEND java? ( dev-java/openjdk:11 dev-java/openjdk-jre-bin:11 >=virtual/jre-1.8 ) Does it really need all of them? Shouldn't it have: || ( as in DEPEND?
Right.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=36a871e8cef9c6845c49ac350090f0540beb3c4a commit 36a871e8cef9c6845c49ac350090f0540beb3c4a Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2020-10-29 17:32:01 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2020-10-29 17:32:14 +0000 app-office/libreoffice: Add missing || ( ) Reported-by: jospezial <jospezial@gmx.de> Bug: https://bugs.gentoo.org/739134 Package-Manager: Portage-3.0.8, Repoman-3.0.2 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> app-office/libreoffice/libreoffice-7.0.9999.ebuild | 4 ++-- app-office/libreoffice/libreoffice-9999.ebuild | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
See also https://bugs.gentoo.org/show_bug.cgi?id=751799
Builds (and starts) with dev-java/icedtea-3.17. However, because LibreOffice 7.x prefers clang over gcc (ref. => https://bugs.documentfoundation.org/show_bug.cgi?id=131697) and because there is no 1:1 equivalence in options used by both compilers, compilation failures occurred here with: CXXFLAGS=CFLAGS="-O3 -pipe -march=native -fomit-frame-pointer -fopt-info-vec -mindirect-branch=thunk -mindirect-branch-register" Compilation succeeds with: CXXFLAGS=CFLAGS="-O3 -pipe -march=native -fomit-frame-pointer" Stripping flags or forcing a "safe-set" in the ebuild might be an option? Anyway good job! :)
(In reply to Adrien Dessemond from comment #35) > Builds (and starts) with dev-java/icedtea-3.17. However, because LibreOffice > 7.x prefers clang over gcc (ref. => > https://bugs.documentfoundation.org/show_bug.cgi?id=131697) and because > there is no 1:1 equivalence in options used by both compilers, compilation > failures occurred here with: > > CXXFLAGS=CFLAGS="-O3 -pipe -march=native -fomit-frame-pointer -fopt-info-vec > -mindirect-branch=thunk -mindirect-branch-register" > > Compilation succeeds with: > > CXXFLAGS=CFLAGS="-O3 -pipe -march=native -fomit-frame-pointer" > > > Stripping flags or forcing a "safe-set" in the ebuild might be an option? > > Anyway good job! :) You can do next: remove clang, emerge libreoffce, then re-emerge clamg.
There is no option as far as i can tell yet.i have contacted the devs about it. And there is no option for --system-skia. I have the commits when they did the change and it is quite big.i dont know....but one option is to blind libreoffi(In reply to Adrien Dessemond from comment #35) > Builds (and starts) with dev-java/icedtea-3.17. However, because LibreOffice > 7.x prefers clang over gcc (ref. => > https://bugs.documentfoundation.org/show_bug.cgi?id=131697) and because > there is no 1:1 equivalence in options used by both compilers, compilation > failures occurred here with: > > CXXFLAGS=CFLAGS="-O3 -pipe -march=native -fomit-frame-pointer -fopt-info-vec > -mindirect-branch=thunk -mindirect-branch-register" > > Compilation succeeds with: > > CXXFLAGS=CFLAGS="-O3 -pipe -march=native -fomit-frame-pointer" > > > Stripping flags or forcing a "safe-set" in the ebuild might be an option? > > Anyway good job! :) There is no option as far as i can tell yet.i have contacted the devs about it. And there is no option for --system-skia. I have the commits when they did the change and it is quite big.i have not tested it but one option is to disable skia.
just add to EXTRA_ECONF="--disable-skia" and voilà LO-7 can be built with all optimizations enabled and with GCC only
(In reply to Perfect Gentleman from comment #38) > just add to EXTRA_ECONF="--disable-skia" and voilà LO-7 can be built with > all optimizations enabled and with GCC only or add it as a useflag because not every one use vulkan.
Good news if Skia can be disabled (those who do not want +vulkan will appreciate) however most of us will leave it enabled and have a side-by-side installation of both clang and GCC. Although a temporary emerge -C clang might work, it is definitely "heavy" and counter-intuitive (you have to re-emerge it again and it will take some time which might be mitigated by building a binary package). Beyond that it is wrong to assume a "loosely coupled" dependency between clang and LibreOffice in the long run. At some point, LibreOffice might require it, not counting the dependencies. Some packages like >=media-video/ffmpeg-4.3.1 and sys-libs/glibc already takes the approach of overriding the {C,CXX}FLAGS variables to use a well known, safe set of compiler options.
(In reply to Adrien Dessemond from comment #40) > Although a temporary emerge -C clang might work, it is definitely "heavy" > and counter-intuitive (you have to re-emerge it again and it will take some > time which might be mitigated by building a binary package). Or build LO and its all deps with Clang but that might break linkage with libs/packages built with GCC.
Are the 7 ebuild arriving? :) I didn't understand if it could be created a testing ebuild on portage with the last discovers.
Any news? I think it is important that gentoo user could use the new Libreoffice version as it carries many new features. May I help in any way?
(In reply to Silvio from comment #43) > Any news? > > I think it is important that gentoo user could use the new Libreoffice > version as it carries many new features. > > May I help in any way? Who wants to use it use it. Heh %)
(In reply to Perfect Gentleman from comment #44) > Who wants to use it use it. Heh %) How?
Any hope to have the new version soon on portage? :)
(In reply to Silvio from comment #45) > (In reply to Perfect Gentleman from comment #44) > > > Who wants to use it use it. Heh %) > > How? In the Libreoffice website you can download an appImage for the latest version. It is not ideal, and won't be integrated to the system, but seems to be the only way of having LibreOffice 7 on Gentoo. pg_overlay seems to have it too, but it pulls a ton of updates/and dependencies over stock Gentoo. Doing a package.mask and only unmasking LibreOffice will reach a point where it won't install and won't tell you what else you need to unmask, so you have to bite the bullet and risk it.
You can also emerge =app-office/libreoffice-7.0.9999 (you will have to unmask it first). You also might have to adjust your CFLAGS/CXXFLAGS variables to ensure clang does not see unsupported compiler options, see the comment #35 above. As suggested in comment #36, you also might have to remove clang, recompile LibreOffice and emerge clang again afterwards.
(In reply to Adrien Dessemond from comment #48) > You can also emerge =app-office/libreoffice-7.0.9999 (you will have to > unmask it first). > > You also might have to adjust your CFLAGS/CXXFLAGS variables to ensure clang > does not see unsupported compiler options, see the comment #35 above. As > suggested in comment #36, you also might have to remove clang, recompile > LibreOffice and emerge clang again afterwards. [blocks B ] app-office/libreoffice-l10n ("app-office/libreoffice-l10n" is blocking app-office/libreoffice-7.0.9999) I cannot install it, it needs a masked updated version even of libreoffice-l10n
(In reply to Iñigo from comment #47) > (In reply to Silvio from comment #45) > > (In reply to Perfect Gentleman from comment #44) > > > > > Who wants to use it use it. Heh %) > > > > How? > > In the Libreoffice website you can download an appImage for the latest > version. It is not ideal, and won't be integrated to the system, but seems > to be the only way of having LibreOffice 7 on Gentoo. > > pg_overlay seems to have it too, but it pulls a ton of updates/and > dependencies over stock Gentoo. I tried and noticed. Too riskfull > Doing a package.mask and only unmasking > LibreOffice will reach a point where it won't install and won't tell you > what else you need to unmask, so you have to bite the bullet and risk it. I agree
(In reply to Silvio from comment #50) > [blocks B ] app-office/libreoffice-l10n ("app-office/libreoffice-l10n" > is blocking app-office/libreoffice-7.0.9999) > > I cannot install it, it needs a masked updated version even of > libreoffice-l10n emerge -C app-office/libreoffice-l10n app-office/libreoffice (suggestion: build binaries packages of them first) Then try to emerge 7.0.9999 You might also have to adjust your localization variables (LINGUAS etc) to not pull in app-office/libreoffice-l10n per dependency. I am not using localized systems, what worked for me will require some tweaks for you.
Silvio libreoffice-7.0.9999 is a live ebuild and that mean it will not be updated.you have to update it your self,portage will not do any thing with it and you will never know when the compile will fail if libreoffice has done a change. it is better for you to use one from pg_overlay or from mine "hedmos-overlay". this ebuilds is locked on a version release and will not change from day to day.
(In reply to Silvio from comment #49) > (In reply to Adrien Dessemond from comment #48) > > You can also emerge =app-office/libreoffice-7.0.9999 (you will have to > > unmask it first). > > > > You also might have to adjust your CFLAGS/CXXFLAGS variables to ensure clang > > does not see unsupported compiler options, see the comment #35 above. As > > suggested in comment #36, you also might have to remove clang, recompile > > LibreOffice and emerge clang again afterwards. > > [blocks B ] app-office/libreoffice-l10n ("app-office/libreoffice-l10n" > is blocking app-office/libreoffice-7.0.9999) > > I cannot install it, it needs a masked updated version even of > libreoffice-l10n The live ebuilds of libreoffice don't have a l10n package and the l10n package from causes incompatibilities. Seen some calc functions in other language not did not work, maybe unrelated. Would be nice if we could also use the translations from LO-git.
configure.ac respects CLANG_C and CLANG_CXX variables since this commit (included in 7.0): https://git.libreoffice.org/core/+/647499ef8151d9383983f89230a970edcb44b5bb https://git.libreoffice.org/core/+/647499ef8151d9383983f89230a970edcb44b5bb^! configure.ac respects LO_CLANG_CC and LO_CLANG_CXX variables since this commit (included in 7.1): https://git.libreoffice.org/core/+/5b0ca23615c3d0aae7083147bc3bb5d61db26f5e https://git.libreoffice.org/core/+/5b0ca23615c3d0aae7083147bc3bb5d61db26f5e^! Ebuild can force respecting compiler: - In =app-office/libreoffice-7.0*: export CLANG_C="$(tc-getCC)" export CLANG_CXX="$(tc-getCXX)" - In >=app-office/libreoffice-7.1 (currently only app-office/libreoffice-9999): export LO_CLANG_CC="$(tc-getCC)" export LO_CLANG_CXX="$(tc-getCXX)" Currently users can try e.g.: > CLANG_C="x86_64-pc-linux-gnu-gcc" CLANG_CXX="x86_64-pc-linux-gnu-g++" emerge -1 "=app-office/libreoffice-7.0*"
Any news about the possibility to have libreoffice 7 on gentoo? It is not a secondary package. If I could help in any way ...
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=af86e0e2f91da40999615ed71b6be7a5756690a4 commit af86e0e2f91da40999615ed71b6be7a5756690a4 Author: Jason A. Donenfeld <zx2c4@gentoo.org> AuthorDate: 2020-10-27 14:57:05 +0000 Commit: Jason A. Donenfeld <zx2c4@gentoo.org> CommitDate: 2020-11-17 17:17:38 +0000 app-office/libreoffice: bump to 7.0.3.1 Closes: https://bugs.gentoo.org/739134 Package-Manager: Portage-3.0.8, Repoman-3.0.2 Signed-off-by: Jason A. Donenfeld <zx2c4@gentoo.org> app-office/libreoffice-l10n/Manifest | 168 ++++++ .../libreoffice-l10n-7.0.3.1.ebuild | 91 ++++ app-office/libreoffice/Manifest | 3 + .../libreoffice-7.0.3.1-fix-non-pdfium-build.patch | 31 ++ app-office/libreoffice/libreoffice-7.0.3.1.ebuild | 592 +++++++++++++++++++++ profiles/base/package.use.mask | 4 + 6 files changed, 889 insertions(+)
I assume what I just pushed will need some work, but at least now we have a base to build on, instead of letting this rot on longer.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c66a6cc5f3be619c2e2f6a97bcfda0613cb6ee5c commit c66a6cc5f3be619c2e2f6a97bcfda0613cb6ee5c Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2020-11-17 18:17:04 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2020-11-17 18:20:12 +0000 app-office/libreoffice: Revert "bump to 7.0.3.1" Not ACKed from office project. Drive-by commit without regard for Java dependencies or even the latest state of 7.0 stable branch ebuild and *known* issue wrt Skia and clang automagic. This reverts commit af86e0e2f91da40999615ed71b6be7a5756690a4. Bug: https://bugs.gentoo.org/739134 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> app-office/libreoffice-l10n/Manifest | 168 ------ .../libreoffice-l10n-7.0.3.1.ebuild | 91 ---- app-office/libreoffice/Manifest | 3 - .../libreoffice-7.0.3.1-fix-non-pdfium-build.patch | 31 -- app-office/libreoffice/libreoffice-7.0.3.1.ebuild | 592 --------------------- profiles/base/package.use.mask | 4 - 6 files changed, 889 deletions(-)
Jason, if you really wan't to help then don't commit an outdated ebuild but rather work with what is already here and most importantly test and try integrate Arfrever's clues with the ebuild. First live, then the release version bump.
Andreas Sturmlechner I agree with you.as i have been working with libreoffice-7 for some Time now i have to say That the ebuild in portage and pg_overlay is far from a working state (gentoo class) to use for libeoffice-7.just One example is skia... As skia use vulkan the ebuild Needs to depend on vulkan provided in portage and if someone like to use libreoffice-7 on older hardware (No vulkan support or xf86-video-nouveau) there needs to be a use flag or something to regulate that. And to get the best quality provided by libreoffice the ebuild needs to depend on sys-devel/clang but i have to say that if the "hack" that Arfrever's comment had is ok for gentoo "standard" i think that One is a good thing to add as a use flag as well. And not to mention THE options that needs to be added/dropped.
Maybe alternatively it would make sense to add separate Skia package (probably media-gfx/skia) and modify build system of LibreOffice to use system Skia. Skia package could have IUSE="+clang", and with USE="clang" it would use Clang.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #61) > Maybe alternatively it would make sense to add separate Skia package > (probably media-gfx/skia) and modify build system of LibreOffice to use > system Skia. > > Skia package could have IUSE="+clang", and with USE="clang" it would use > Clang. about --system-skia i think it is a good idea but dont think it will be easy to make that happend (i dont know).i have a skia ebuild that works and builds with both gcc and clang but libreoffice do not provide --system-skia.ATM i am using the "hack" from your comment 54 and providing it with USE=gcc-only as i am using lto .
skia could controlled with USE=vulkan, but the main problem that LO-7 build system is terrible. LO-7 can be built with GCC + Clang'd skia only with limited set of CFLAGS. LTO can be hardly enable as enable LTO passed -flto=n which is not supported by Clang. LO-7 can be built with onle the one toolchain.
(In reply to Perfect Gentleman from comment #63) > skia could controlled with USE=vulkan, but the main problem that LO-7 build > system is terrible. LO-7 can be built with GCC + Clang'd skia only with > limited set of CFLAGS. LTO can be hardly enable as enable LTO passed -flto=n > which is not supported by Clang. LO-7 can be built with onle the one > toolchain. Perfect Gentleman i do not fully understand you but i am controlling skia with USE=skia.And i am using libreoffice with LTO by controlling libreoffice to be build with gcc only (USE=gcc-only) and the useflag adds: if use gcc-only; then # hack to force skia to be build with gcc and not clang... export LO_CLANG_CC="$(tc-getCC)" export LO_CLANG_CXX="$(tc-getCXX)" fi to the build
andy, that's what I'm telling: GCC or Clang only. You cannot use GCC+LTO for building while using Clang for building skia.
>but i am controlling skia with USE=skia vulkan is global flag, skis is local. there is no skia without vulkan afaik.
(In reply to Perfect Gentleman from comment #66) > >but i am controlling skia with USE=skia > vulkan is global flag, skis is local. there is no skia without vulkan afaik. i know it fits better with : if use vulkan ; then myeconfargs+=( --enable-skia ) else myeconfargs+=( --disable-skia ) fi
When shared libraries are enabled in Skia, Skia provides 3 static libraries and 4 shared libraries: libparticles.a libpathkit.a libskresources.a libskia.so libskottie.so libsksg.so libskshaper.so For using system Skia in LibreOffice, it would be necessary to change mainly: https://git.libreoffice.org/core/+/47fda617fc4dad8273919227ca45ea3b8b61aea1/RepositoryExternal.mk#123 This line probably can be dropped: https://git.libreoffice.org/core/+/808e8a8e9e96b6c3fac3ddf291e3900a40846409/external/Module_external.mk#98 Bundled Skia in LibreOffice is slightly patched. System Skia would probably need at least "share-grcontext.patch.1": https://git.libreoffice.org/core/+/bb4b538ff6c2b10d41784819224171df07910eaf/external/skia/README#30 https://git.libreoffice.org/core/+/7c1dc527837a65b77f7624e18a575271cb46afba/vcl/skia/README#71 https://git.libreoffice.org/core/+/319a03fe3975f24f1bccc88019a92217bc1df53b/external/skia/share-grcontext.patch.1
So, a couple of days ago I made a system update, and happily see Libreoffice7 was on it (I currently have 7.0.3.1). Works fine for me. Now it wants to downgrade to version 6 again... Which I suppose I have to do because I accidentally deleted libeoffice-l10n v7 on a --depclean What happened?
(In reply to Iñigo from comment #69) > So, a couple of days ago I made a system update, and happily see > Libreoffice7 was on it (I currently have 7.0.3.1). Works fine for me. Now it > wants to downgrade to version 6 again... Which I suppose I have to do > because I accidentally deleted libeoffice-l10n v7 on a --depclean > > What happened? It has been removed from portage for further stabilisation. This is the reason why it proposes to you to downgrade.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1e6582952369e1fd90f507f94853263ce07089c9 commit 1e6582952369e1fd90f507f94853263ce07089c9 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2020-11-21 15:05:38 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2020-11-21 15:07:57 +0000 app-office/libreoffice: Version bump (no keywords, for testing) Bug: https://bugs.gentoo.org/739134 Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> app-office/libreoffice/Manifest | 2 + app-office/libreoffice/libreoffice-7.0.3.1.ebuild | 650 +++++++++++++++++++++ app-office/libreoffice/libreoffice-7.0.9999.ebuild | 54 +- app-office/libreoffice/libreoffice-9999.ebuild | 54 +- app-office/libreoffice/metadata.xml | 2 + 5 files changed, 758 insertions(+), 4 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f8d4ec8bdce3f0b8da94d158c9ffe57361779cbc commit f8d4ec8bdce3f0b8da94d158c9ffe57361779cbc Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2020-11-21 15:01:06 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2020-11-21 15:07:53 +0000 app-office/libreoffice-l10n: Version bump (no keywords, for testing) Bug: https://bugs.gentoo.org/739134 Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> app-office/libreoffice-l10n/Manifest | 183 +++++++++++++++++++++ app-office/libreoffice-l10n/files/lo_gen_langs.sh | 12 +- .../libreoffice-l10n-7.0.3.1.ebuild | 91 ++++++++++ profiles/desc/l10n.desc | 3 + 4 files changed, 283 insertions(+), 6 deletions(-)
Please test with and without USE=clang I can only do limited testing myself at the moment since I hard-rely on a functioning LO Impress until christmas.
USE=-clang/clang does not work for me: clang-11: error: unknown argument: '-fgraphite-identity' clang-11: error: unknown argument: '-floop-nest-optimize' clang-11: error: unknown argument: '-fdevirtualize-at-ltrans' clang-11: error: unknown argument: '-fipa-pta' clang-11: error: unsupported argument '16' to option 'flto=' clang-11: error: unknown argument: '-fgraphite-identity' clang-11: error: unknown argument: '-floop-nest-optimize' clang-11: error: unknown argument: '-fdevirtualize-at-ltrans' clang-11: error: unknown argument: '-fipa-pta' clang-11: error: unsupported argument '16' to option 'flto='
as you have bumped libreoffice-7.0.3.1 i think you have to set : line:406 export CLANG_C="$(tc-getCC)" line:407 export CLANG_CXX="$(tc-getCXX)"
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a6e8979afea92806e9f3b469c37822a1f80e6a6f commit a6e8979afea92806e9f3b469c37822a1f80e6a6f Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2020-11-21 18:51:50 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2020-11-21 19:01:50 +0000 app-office/libreoffice: Use CLANG_CC in 7.0 branch Bug: https://bugs.gentoo.org/739134 Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> app-office/libreoffice/libreoffice-7.0.3.1.ebuild | 4 ++-- app-office/libreoffice/libreoffice-7.0.9999.ebuild | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
(In reply to Larry the Git Cow from comment #75) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=a6e8979afea92806e9f3b469c37822a1f80e6a6f > > commit a6e8979afea92806e9f3b469c37822a1f80e6a6f > Author: Andreas K. Hüttel <dilfridge@gentoo.org> > AuthorDate: 2020-11-21 18:51:50 +0000 > Commit: Andreas K. Hüttel <dilfridge@gentoo.org> > CommitDate: 2020-11-21 19:01:50 +0000 > > app-office/libreoffice: Use CLANG_CC in 7.0 branch > > Bug: https://bugs.gentoo.org/739134 > Package-Manager: Portage-3.0.9, Repoman-3.0.2 > Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> > > app-office/libreoffice/libreoffice-7.0.3.1.ebuild | 4 ++-- > app-office/libreoffice/libreoffice-7.0.9999.ebuild | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) mybox /home/hedmo # rm /var/cache/distfiles/libreoffice-branding-gentoo-0.8.tar.xz mybox /home/hedmo # emerge -av =libreoffice-7.0.3.1 * IMPORTANT: 1 news items need reading for repository 'gentoo'. * Use eselect news read to view new items. These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD*] app-office/libreoffice-7.0.3.1::gentoo [7.1.0.0_alpha1::hedmos-overlay] USE="bluetooth branding cups dbus gtk java kde mariadb vulkan -accessibility -base -clang% -coinmp -debug -eds -firebird -googledrive -gstreamer -ldap -odk -pdfimport -postgres -test (-gcc-only%*)" LIBREOFFICE_EXTENSIONS="-nlpsolver -scripting-beanshell -scripting-javascript -wiki-publisher" PYTHON_SINGLE_TARGET="python3_7 -python3_6 -python3_8 -python3_9%" 0 KiB [ebuild N *] app-office/libreoffice-l10n-7.0.3.1::gentoo USE="-offlinehelp" L10N="-af -am -ar -as -ast -be -bg -bn -bn-IN -bo -br -brx -bs -ca -ca-valencia -ckb -cs -cy -da -de -dgo -dsb -dz -el -en -en-GB -en-ZA -eo -es -et -eu -fa -fi -fr -fur -fy -ga -gd -gl -gu -gug -he -hi -hr -hsb -hu -id -is -it -ja -ka -kab -kk -km -kmr-Latn -kn -ko -kok -ks -lb -lo -lt -lv -mai -mk -ml -mn -mni -mr -my -nb -ne -nl -nn -nr -nso -oc -om -or -pa -pl -pt -pt-BR -ro -ru -rw -sa -sat -sd -si -sid -sk -sl -sq -sr -sr-Latn -ss -st -sv -sw-TZ -szl -ta -te -tg -th -tn -tr -ts -tt -ug -uk -uz -ve -vec -vi -xh -zh-CN -zh-TW -zu" 0 KiB Total: 2 packages (1 downgrade, 1 new), Size of downloads: 0 KiB Would you like to merge these packages? [Yes/No] >>> Verifying ebuild manifests >>> Running pre-merge checks for app-office/libreoffice-7.0.3.1 * If you plan to use Base application you must enable USE base. * Checking for at least 512 MiB RAM ... [ ok ] * Checking for at least 6 GiB disk space at "/var/tmp/portage/app-office/libreoffice-7.0.3.1/temp" ... [ ok ] >>> Emerging (1 of 2) app-office/libreoffice-7.0.3.1::gentoo >>> Failed to emerge app-office/libreoffice-7.0.3.1, Log file: >>> '/var/tmp/portage/app-office/libreoffice-7.0.3.1/temp/build.log' >>> Jobs: 0 of 2 complete, 1 failed Load avg: 0.82, 1.15, 1.33 !!! Fetched file: libreoffice-branding-gentoo-0.8.tar.xz VERIFY FAILED! !!! Reason: Insufficient data for checksum verification !!! Got: !!! Expected: BLAKE2B BLAKE2S MD5 RMD160 SHA1 SHA256 SHA3_256 SHA3_512 SHA512 WHIRLPOOL * Fetch failed for 'app-office/libreoffice-7.0.3.1', Log file: * '/var/tmp/portage/app-office/libreoffice-7.0.3.1/temp/build.log' * Messages for package app-office/libreoffice-7.0.3.1: * If you plan to use Base application you must enable USE base. * Messages for package app-office/libreoffice-7.0.3.1: * Fetch failed for 'app-office/libreoffice-7.0.3.1', Log file: * '/var/tmp/portage/app-office/libreoffice-7.0.3.1/temp/build.log' mybox /home/hedmo #
(In reply to Larry the Git Cow from comment #75) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=a6e8979afea92806e9f3b469c37822a1f80e6a6f > > commit a6e8979afea92806e9f3b469c37822a1f80e6a6f > Author: Andreas K. Hüttel <dilfridge@gentoo.org> > AuthorDate: 2020-11-21 18:51:50 +0000 > Commit: Andreas K. Hüttel <dilfridge@gentoo.org> > CommitDate: 2020-11-21 19:01:50 +0000 > > app-office/libreoffice: Use CLANG_CC in 7.0 branch > > Bug: https://bugs.gentoo.org/739134 > Package-Manager: Portage-3.0.9, Repoman-3.0.2 > Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> > > app-office/libreoffice/libreoffice-7.0.3.1.ebuild | 4 ++-- > app-office/libreoffice/libreoffice-7.0.9999.ebuild | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) sorry Andreas K. Hüttel still fails with : clang-11: error: unknown argument: '-fgraphite-identity' clang-11: error: unknown argument: '-floop-nest-optimize' clang-11: error: unknown argument: '-fdevirtualize-at-ltrans' clang-11: error: unknown argument: '-fipa-pta' clang-11: error: unsupported argument '16' to option 'flto=' i am just using : if ! use clang; then # hack to force skia to be build with gcc and not clang... einfo "Enforcing the use of gcc due to USE=-clang ..." export LO_CLANG_CC="$(tc-getCC)" export LO_CLANG_CXX="$(tc-getCXX)" fi in my libreoffice-7.1.0.0_alpha1.ebuild and that works
Could you add the start of the build log please? The configure phase is enough.
(In reply to Andreas K. Hüttel from comment #78) > Could you add the start of the build log please? The configure phase is > enough. Forget it, I think I understand the problem.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f9e9a8666cd4b64a01bf3f6dcf585e8c4e1dec14 commit f9e9a8666cd4b64a01bf3f6dcf585e8c4e1dec14 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2020-11-21 23:24:25 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2020-11-21 23:27:36 +0000 app-office/libreoffice: Brute-force compiler settings (clang/gcc) Bug: https://bugs.gentoo.org/739134 Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> app-office/libreoffice/libreoffice-7.0.3.1.ebuild | 26 +++++++++------------- app-office/libreoffice/libreoffice-7.0.9999.ebuild | 26 +++++++++------------- app-office/libreoffice/libreoffice-9999.ebuild | 26 +++++++++------------- 3 files changed, 30 insertions(+), 48 deletions(-)
imho, it's not a good idea to implement USE=clang. Firstly, anyone who uses LLVM/Clang as system toolchain will build LO-7 with LLVM/Clang anyway. Secondly, when GCC is system toolchain and USE=clang is used then lots of deps should be re-built with LLVM/Clang.
(In reply to comment #80) > commit f9e9a8666cd4b64a01bf3f6dcf585e8c4e1dec14 > Author: Andreas K. Hüttel <dilfridge@gentoo.org> > AuthorDate: 2020-11-21 23:24:25 +0000 > Commit: Andreas K. Hüttel <dilfridge@gentoo.org> > CommitDate: 2020-11-21 23:27:36 +0000 > > app-office/libreoffice: Brute-force compiler settings (clang/gcc) the changes worked for me now. USE=-clang make you to compile with custom cflags. i'd buy that for a dollar :)
(In reply to Perfect Gentleman from comment #81) > imho, it's not a good idea to implement USE=clang. > Firstly, anyone who uses LLVM/Clang as system toolchain will build LO-7 with > LLVM/Clang anyway. I dislike that flag as much as you do, but if we take upstream serious then there is legitimate interest to make that flag and the relation to skia/vulkan visible to the user. (In reply to Perfect Gentleman from comment #81) > Secondly, when GCC is system toolchain and USE=clang is used then lots of > deps should be re-built with LLVM/Clang. As a matter of principle or is there any problem you would see arise?
(In reply to Andreas Sturmlechner from comment #83) > (In reply to Perfect Gentleman from comment #81) > > imho, it's not a good idea to implement USE=clang. > > Firstly, anyone who uses LLVM/Clang as system toolchain will build LO-7 with > > LLVM/Clang anyway. > I dislike that flag as much as you do, but if we take upstream serious then > there is legitimate interest to make that flag and the relation to > skia/vulkan visible to the user. > > (In reply to Perfect Gentleman from comment #81) > > Secondly, when GCC is system toolchain and USE=clang is used then lots of > > deps should be re-built with LLVM/Clang. > As a matter of principle or is there any problem you would see arise? i think Perfect Gentleman got a point because USE=clang will force libreoffice to be build with clang and not only skia. i did try to compile libreoffice with USE=clang now and it fails. i think i will rename the useflag to : clang -> custom-cflags and skip : if use clang ; then # Force clang einfo "Enforcing the use of clang due to USE=clang ..." AR=llvm-ar CC=${CHOST}-clang CXX=${CHOST}-clang++ NM=llvm-nm RANLIB=llvm-ranlib LDFLAGS+=" -fuse-ld=lld" strip-unsupported-flags
(In reply to Andreas Sturmlechner from comment #83) > As a matter of principle or is there any problem you would see arise? As andy wrote below for now LO-7 fails with USE=clang. For building with LLVM/Clang some deps should be built with LLVM/Clang also which leads to problems when packages built with GCC needs those deps to be built with GCC otherwise they fail during building or on start.
Which packages have issues with being built with different compilers? The only packages I currently compile with Clang regularly are Chromium and Mesa If there are issues it might be worth reporting bugs upsteam
(In reply to Mike Lothian from comment #86) > Which packages have issues with being built with different compilers? > > The only packages I currently compile with Clang regularly are Chromium and > Mesa > > If there are issues it might be worth reporting bugs upsteam you'd be laughing but lots of them: from sys-libs to DE and its applications.
(In reply to Mike Lothian from comment #86) > Which packages have issues with being built with different compilers? > > The only packages I currently compile with Clang regularly are Chromium and > Mesa > > If there are issues it might be worth reporting bugs upsteam from my point of view i don think the problem is which compiler to use but the cflags you have set in make.conf. I am using lto and gcc which make libreoffice to fail when it tries to build skia. when i am trying to build libreoffice with USE=clang it fails with : checking whether x86_64-pc-linux-gnu-clang++ defines __si_class_type_info in cxxabi.h... yes checking whether x86_64-pc-linux-gnu-clang++ defines __vmi_class_type_info in cxxabi.h... yes checking that x86_64-pc-linux-gnu-clang++ supports __attribute__((warn_unused))... configure: error: no and to be straight up simple... i quote Andreas K. Hüttels commit: app-office/libreoffice: Brute-force compile with : CFLAGS="-O2 -pipe -march=native" CXXFLAGS="${CFLAGS}" and the problem is gone.
I use the following env overrides to compile with Clang and LTO https://github.com/FireBurn/PortageStuff/blob/master/env/clango3lto.conf
If the build fails for you, then please add the following here: * your useflag settings * your emerge --info output * and at least the last lines of the build log that show the *error* (may require some searching) Otherwise there's nothing to do here. Yes I realize that USE=clang may go against the rest of the system. Point is, if you think this makes problems, don't select it. Because of stupid amazon sponsorship being in limbo I have only limited cycles available at the moment. USE=-clang built fine, USE=clang is still running.
P.S. If you want to discuss this in realtime feel free to join channel #gentoo-office on freenode. I'll be back around 17:00 EET (that's 15:00 UTC).
andy is right. it depends on which optimization CFLAGS are used. ThinLTO+LLD is definitely breaks when Gpaphite+LTO is used. If SAFE CFLAGS are used, I think it's okay on matter which toolchain is used. FYI, I use heavy optimizations, i.e. Graphite+LTO+Sections in GCC and ThinLTO+LLD+Polly+Sections in LLVM/Clang.
LO-7[clang] build just finished successfully, runs fine.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=758a966d8fd830f30822335baad033f439e5a1ad commit 758a966d8fd830f30822335baad033f439e5a1ad Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2020-11-22 17:07:07 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2020-11-22 17:07:49 +0000 app-office/libreoffice: Re-add keywords to 7.0.3.1 Closes: https://bugs.gentoo.org/739134 Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> app-office/libreoffice/libreoffice-7.0.3.1.ebuild | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Please report future issues in separate bugs. Thanks!!!
Not an issue just an FYI for people testing this I have to use SAL_FORCESKIA=1 to get Skia working at all on my machine More environment variables: AL_DISABLESKIA=1 - force disabled Skia SAL_ENABLESKIA=1 - enable Skia, unless blacklisted (and if the VCL backend supports Skia) SAL_FORCESKIA=1 - force using Skia, even if blacklisted SAL_SKIA=raster|vulkan - select Skia's drawing method, by default Vulkan is used There also also GUI options for controlling whether Skia is enabled. Note that many backends do not use Skia. E.g. on Linux it is necessary to also use SAL_USE_VCLPLUGIN=gen . Skia drawing methods: ===================== Skia supports several methods to draw: - Raster - CPU-based drawing (here primarily used for debugging) - Vulkan - Vulkan-based GPU drawing, this is the default There are more (OpenGL, Metal on Mac, etc.), but (as of now) they are not supported by VCL.