summaryrefslogtreecommitdiff
path: root/solenv
AgeCommit message (Collapse)Author
2019-01-16Move XStyleLoader2 tests to ScStyleFamiliesObjJens Carl
Change-Id: Ibba0464d17a9517eb48f3f33b46db2455093ac52 Reviewed-on: https://gerrit.libreoffice.org/66413 Tested-by: Jenkins Reviewed-by: Jens Carl <j.carl43@gmx.de>
2019-01-16Minimum Supported Version is VS2017himajin100000
Change-Id: Id771f1fe0d8c6702a52836f6229a944d259fed4c Reviewed-on: https://gerrit.libreoffice.org/66424 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-01-16external: update pdfium to 3667Miklos Vajna
Change-Id: Ie4f0cc8f06432e182ce7ffcae5269075d12658ef Reviewed-on: https://gerrit.libreoffice.org/66408 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-01-13array_view was changed to span in upcoming C++20Stephan Bergmann
...see <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0122r7.pdf> "span: bounds-safe views for sequences of objects". o3tl::span is still an incomplete approximation of std::span; removed those o3tl::array_view members that are not present in std::span (and were not used in the code). Relies on C++17 __has_include to use standard <span> where available (e.g., in LLVM 7 libc++). Change-Id: I82a7e246b61b2456fa6183025d25eec4121ad3c9 Reviewed-on: https://gerrit.libreoffice.org/66215 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-11Drop o3tl/string_view.hxxStephan Bergmann
...now that all of its uses have been replaced with C++17 <string_view>. The LO-specific o3tl::basic_string_view ctors with OString and OUString params have meanwhile been replaced with OString and OUString conversion functions (in dac7be50cff94e0c34cdca5ac7e35c19685c40c1 "o3tl::string_view -> std::string_view (in configmgr)"), the ctor with OUStringLiteral turned out to be no longer(?) needed anyway, and the LO-specific o3tl::toOUString has meanwhile been replaced with an OUString ctor with std::u16string_view param (in 6856da30665705be6380e84cf55de954c41f15d1 "o3tl::string_view -> std::string_view (in embedserv)"). Change-Id: Ie5215b07e2387560fb7e94de8b5a963241539c64 Reviewed-on: https://gerrit.libreoffice.org/66144 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-10Related: tdf#44076 do not leave cast to int to undefined behaviourEike Rathke
... if the double is an out-of-int-range value. Also catch domain and pole and range errors. Move this to it's own sc::power() function that can be reused for example by ScMatrix::PowOp() to be congruent. Change-Id: I88331e02e6cdfb5e1dcbf81622d3fc7ce4510478 Reviewed-on: https://gerrit.libreoffice.org/65986 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2019-01-09update uitest debugging instructions to account for gtk3 backend issueNoel Grandin
e.g. when debugging UITest_writer_tests2 it gets stuck when the uitest invokes dialogs Change-Id: I8276a8d7e885be5f47309beeec1f4c3c9d12ee32 Reviewed-on: https://gerrit.libreoffice.org/66002 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-01-03svm xml dumper: move this from test to vclMiklos Vajna
This is very useful functionality, this way it can be invoked from the debugger and/or nested into an outer xml dump (sw/sd doc model dump) more easily. Change-Id: If6c83b11d0f3e65fcce71e8d820c6bc354f64d68 Reviewed-on: https://gerrit.libreoffice.org/65834 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-01-03Update Flatpak to OpenJDK11Stephan Bergmann
see <https://github.com/flathub/org.libreoffice.LibreOffice/issues/57> "OpenJDK 11 is available". Change-Id: Ie24ed7349ca9a4a57c1a8d18d10b29c4a37e259c Reviewed-on: https://gerrit.libreoffice.org/65830 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-02upload libwpg 0.3.3David Tardon
Change-Id: Iac2c3f75eda07b7381e57dba389c9836ab26502f Reviewed-on: https://gerrit.libreoffice.org/65781 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2018-12-31for tests MOZILLA_CERTIFICATE_FOLDER should be set to empty not 0Tomaž Vajngerl
0 means it has a value (string "0") but we check for an empty string. The end result is the same however. Change-Id: I01fed189eaf37673fdb254884c5e7382914b5211 Reviewed-on: https://gerrit.libreoffice.org/65766 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2018-12-30upload libqxp 0.0.2David Tardon
Change-Id: Idda6c0ce0c087a3be2e7fe31999a7d5a6fde4835 Reviewed-on: https://gerrit.libreoffice.org/65725 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2018-12-29upload libcdr 0.1.5David Tardon
Change-Id: I01454cc35baf96743bd19e64dd3a7269c58621bf Reviewed-on: https://gerrit.libreoffice.org/65715 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2018-12-29upload libwpd 0.10.3David Tardon
Change-Id: I68e3791f50b95956bfe6aae743978994a5f232b4 Reviewed-on: https://gerrit.libreoffice.org/65714 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2018-12-29upload libetonyek 0.1.9David Tardon
Change-Id: Ib29e1a622e25731731512a695443ac2c530d30c2 Reviewed-on: https://gerrit.libreoffice.org/65701 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2018-12-29tdf#114635: reimplement TWAIN-based scan using 32-bit shim on WindowsMike Kaganski
Since TWAIN is only actually available as 32-bit component on Windows, to use it in a 64-bit program, we need a 32-bit shim program that does all actual communication with TWAIN subsystem. This change reimplements TWAIN implementation to be a separate 32-bit process. Image is transfered from the shim to main program using file mapping API. This reverts most of commit 585d9806961342e95f7318fb947bd31e9f86dee0. 64-bit LibreOffice doesn't bundle TWAIN DSM library now. TWAIN DSM source code is still used for TWAIN headers. Change-Id: I46f178ad36acd97a9eff156624b99036fcbb83f8 Reviewed-on: https://gerrit.libreoffice.org/65688 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-12-28upload libcmis 0.5.2David Tardon
Change-Id: I0a7e888af770a332e2fec057507eecebf83621c4 Reviewed-on: https://gerrit.libreoffice.org/65646 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2018-12-27URL fixed. Was broken & linking to deleted page.Howard Johnson
Change-Id: Iefe842aa8ef3b183b90f896902edd8941fb1b238 Reviewed-on: https://gerrit.libreoffice.org/63967 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-21Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: Ic8b2adeb949bfc72830667b6928147ebd053d2f0 Reviewed-on: https://gerrit.libreoffice.org/65517 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2018-12-21restore the UI test 'debug with two shells' instructionNoel Grandin
seems to be working for me now (and since I was the one that commented the instruction out, seems I must have had something wrong in my environment) Change-Id: Ie8e180a22d6a3dec61686cb38fd41b00f22fe5c7 Reviewed-on: https://gerrit.libreoffice.org/65492 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-12-20Enable --help=html for flatpakStephan Bergmann
To not increase the size of the main org.libreoffice.LibreOffice app further, the plan was to realize this as an org.libreoffice.LibreOffice.Help extension. Ideally, this would be a localized extension, so that, by default, only a relevant subset of the extension would be downloaded and installed. (But see below.) There are multiple technical problems, as discussed at <https://github.com/ flathub/org.libreoffice.LibreOffice/issues/35#issuecomment-447295308> "Add integrated LibreOffice Help offline": * LO can't pass a file URL with query part to xdg-open, so uses a temporary wrapper .html file that redirects to the target URL. But for the flatpak case this wrapper can't be in /tmp (which isn't visible from outside the flatpak sandbox), but is instead stored in a new temp dir under $XDG_CACHE_HOME (which is always set for flatpaks and /is/ visible form the outside) that is removed on LO exit. * The file URL stored in the temp file must be rewritten from the internal path (/app/libreoffice/help/...) to the path as seen outside the flatpak sandbox. While the path for the org.libreoffice.LibreOffice /app is stored in /.flatpak-info, the external path for the org.libreoffice.LibreOffice.Help extension is different and not stored there. So use a hack trying to construct that path from what information is available in /.flatpak-info. * But the help content consists of locale-specific and shared files, and those reference each other with relative links. But a localized flatpak extension cannot contain shared files, it can only contain per-language sub-dirs. And if the shared help files were kept out of the extension, as part of the app itself, the relative paths among these files inside the flatpak sandbox would differ from those outside of it, so would be broken when viewing the content in the external browser. A solution would either (a) need to somehow rewrite the content of all the help files being served from LO to the external browser, or (b) replicate the shared help files in all the extension's per- language sub-dirs (and if some localization uses en-US content as a fallback for only part of its translated content, e.g., in the case of media files, would need to also replicate that en-US content), or (c) use a non-localized extension that always contains the content for all localizations. For now, I chose the third approach. This makes the org.libreoffice.LibreOffice.Help extension relatively large (the current /app/libreoffice/help tree has a size of ca. 100MB), so that I decided to not have it downloaded and installed automatically ("no-autodownload": true in solenv/flatpak-manifest.in). (I checked with Flatpak 1.0.6 that if the extension should be changed to a localized one with the same name in the future, updating from an older version would work. If the old extension was not installed, just the relevant localizations of the new version will be downloaded and installed. If the old extension was installed, the full set of localizations of the new version will be downloaded and installed.) (As also mentioned at <https://github.com/flathub/org.libreoffice.LibreOffice/ issues/35#issuecomment-447295308>: "A second, minor, nuisance is that, for security reasons, an `xdg-open file:///...html` call from a flatpak leads to an intermediate popup dialog letting the user chose which application to use to open the URI, while e.g. an `xdg-open http:///...html` is allowed to go directly to the user's preferred browser. So accessing help content from LO flatpak would present that popup dialog first, forcing the user to select a browser to proceed.") Change-Id: I35f5a23947dd551dc1b9bff1dd2abd6710073b5f Reviewed-on: https://gerrit.libreoffice.org/65451 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-20weld SwTOXEntryTabPageCaolán McNamara
Change-Id: Ib093fbb78a73b26060613ea72030e92f7d3681a5 Reviewed-on: https://gerrit.libreoffice.org/65325 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-12-20starmath: create SmFilterDetect instances with an uno constructorMiklos Vajna
Change-Id: I11ffe5153bc9ea263cde63093544584f01a344d2 Reviewed-on: https://gerrit.libreoffice.org/65464 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-12-18Natvis: VS has trouble showing sequence of signed charMike Kaganski
Provide a visualizer specialization for this case Change-Id: I54c293972c7e883b8328958f748dba5f2dbd0636 Reviewed-on: https://gerrit.libreoffice.org/65327 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-12-18tdf121374 ooxmlexport: export H/F to default sectionJustin Luth
It wouldn't be terrible to duplicate headers/footers unnecessarily, but it is terrible to have them disappear. If the last SectPr has no idea about the section start, it can't know whether it is continuous or started with a page break. In that case, just ensure that the header and footer are explicitly written out. This seems to be a DOCX problem only. I think that doc and rtf both write the section information at the BEGINNING of the section, but DOCX writes it at the END. So, sharing code between these two opposite approaches is difficult. A followup commit can try to make it smarter about knowing the start of the section (because usually pPDNd is zero). Another followup commit can add the missing page breaks. Change-Id: Iff54ed097b4f8692d7d7764089002b00fbde4f51 Reviewed-on: https://gerrit.libreoffice.org/64821 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-12-18Resolves: tdf#121676 - Update Liberation fonts from new sourceheiko tietze
Liberation updated from 2.00.1 to 2.00.4 and Liberation-Narrow from 1.07.4 to 1.07.6 Change-Id: I295f82d5b8230cdf8b3347491dd71c8689636d94 Reviewed-on: https://gerrit.libreoffice.org/65273 Tested-by: Jenkins Reviewed-by: Heiko Tietze <tietze.heiko@gmail.com>
2018-12-17kde5: remove older kde/tde plugins, and references to thatThorsten Behrens
KDE4 is out of maintenance upstream since Nov. 2014, and binaries provided by TDF have switched to KDE5 as the official backend. Change-Id: I165465b56d3ba3a18912b203c06ae8fc6111c0c9 Reviewed-on: https://gerrit.libreoffice.org/60014 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2018-12-13Add more missing constructors from chart2/source/chartcore.componentTor Lillqvist
I think it would be better if native-code.py parsed the .component files it is interested in and just copied the constructor names from them to its output? Or are there many cases where it is a carefully manually selected subset of constructors from some .component file that should be put in the generated native-code.h, not all? But even in that case, if some constructor should not be linked in to a mobile app, that could be handled by adding some specific attribute in the .component file. Change-Id: Ib947279610f6755f112d3571512406c5d0cd620d
2018-12-13We need CartesianCoordinateSystem2d for chartsTor Lillqvist
Change-Id: I3edccbe29129f6d60a4ac4627a0ab646e4e42458
2018-12-13loplugin:unusedfields improve write-only logicNoel Grandin
when dealing with modifications to container classes (e.g. std::vector) Change-Id: Ic30043631007355ee9a3d9e3f9b6488b435182d6 Reviewed-on: https://gerrit.libreoffice.org/65050 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-12-13Switch Android armeabi-v7a to libc++/libc++abi/libunwind tooStephan Bergmann
It had been left out in 4082a18406c18af7b4fcef7bd501c3679c3be56b "android: use unified headers and llvm-c++ STL (x86) with NDK 16" because "arm unfortunately crashes with llvm-c++, so keep with gnustl for now/fix that later". Making armeabi-v7a work with libc++ etc. required a number of changes, listed below, in this commit and in preceding ones. At least 32-bit x86 already worked with libc++ etc. prior to these changes in view mode, though it crashed in the experimental editing mode (enabled with strippedUIEditing in android/soruce/Makefile) as soon as one types in something, But it is not entirely clear to me why 32-bit x86 view mode didn't also fail similar to how I saw armeabi-v7a fail. (On 32-bit x86, these changes appear to neither improve nor worsen the current state, view mode still appears to work fine while editing still crashes upon typing anything. With these changes, editing mode on armeabi-v7a appears to work fine. But I tested armeabi-v7a only with a real device and 32-bit x86 only with an emulator, in case that might make a difference.) * Preceding <https://gerrit.libreoffice.org/#/c/64964/> "Move NSSLIBS to a more sensible place on the linker command line" plus this change's addition of -lunwind to the liblo-native-code.so linker command line make sure that liblo-native-code.so uses _Unwind_* functions from libunwind.a, instead of erroneously picking up the ones from libgcc.a that happen to be included in NSSLIB's nspr4 (-lgcc is automatically added to the end of the linker command line by the invoking compiler, that's how libgcc.a's _Unwind_* end up in NSSLIB's nspr4; it is neither clear to me why NSSLIB's nspr4, being a pure C library, uses _Unwind_* functions, nor why exception handling in liblo-native-code.so fails when using _Unwind_* functions from libgcc.a instead of from libunwind on armeabi-v7a, nor why that would work on 32-bit x86, but that's what I observed: ModuleManager::identify (framework/source/services/modulemanager.cxx) throws a css::lang::IllegalArgumentException, which calls __cxa_throw -> _Unwind_RaiseException, which ultimately lead to odd misbehavior and std::abort during stack unwinding when using _Unwind_RaiseException from libgcc.a instead of from libunwind). (There is no libunwind.* in android-ndk-r16b for 32-bit x86 at least, so is presumably using _Unwind_* functions from libgcc.a. It doesn't appear to make a difference if it indirectly uses those _Unwind_* functions from NSSLIB's nspr4, or directly from libgcc.a included in liblo-native-code.so if the $(if $(filter armeabi-v7a,$(ANDROID_APP_ABI)),-lunwind) had a ",-lgcc" else branch.) * Preceding <https://gerrit.libreoffice.org/#/c/64965/> "Export RTTI symbols from liblo-native-code.so, for binary UNO bridge" makes sure that excpetions thrown from the binary UNO bridge can be caught by compiled catch clauses. Not sure why the corresponding state of bridges/source/cpp_uno/gcc3_linux_intel shouldn't have run into the same issue. * Preceding <https://gerrit.libreoffice.org/#/c/64966/> "Adapt gcc3_linux_arm __cxa_exception to NDK 18 libc++abi" makes sure that our version of __cxa_exception matches the version from libc++abi. This is clearly not relevant for 32-bit x86. (The comment there android-ndk-r18b, but the additional member is already present in android-ndk-r16b/sources/cxx-stl/llvm-libc++abi/src/cxa_exception.hpp, too.) The remainder of this change just drops old armeabi-v7a--specific workarounds that are no longer needed/no longer work. Change-Id: Ief4c2d562c5032abe6c3b94ca3b3394be6fcd4d3 Reviewed-on: https://gerrit.libreoffice.org/64973 Tested-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-12weld SwCaptionDialogCaolán McNamara
Change-Id: I5babfbf3489f88c5d6cdeffbd514d86368f04fa9 Reviewed-on: https://gerrit.libreoffice.org/65014 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-12-12weld SwCaptionOptPageCaolán McNamara
Change-Id: I3373a39d6d8b39717b7aec69544a9d2957db15d8 Reviewed-on: https://gerrit.libreoffice.org/65010 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-12-11mythes is included in org.freedesktop.Sdk//18.08Stephan Bergmann
Change-Id: I9980f60ebe4cef26348fc26af6b56245260abcca Reviewed-on: https://gerrit.libreoffice.org/64937 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-11tdf#121685: also apply DeclareDPIAware manifest to console applicationsMike Kaganski
There's no reason not to; and now soffice.bin itself is built as a console application. Change-Id: Iba080498b02af04780fdfe1053fb00f584eaae81 Reviewed-on: https://gerrit.libreoffice.org/64915 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-12-07Revert "In flatpak build, disable problematic test using gpg for now"Stephan Bergmann
This reverts commit 23339ec77e38ebdae86eb05a2a3d9a3f5609df64, which is no longer needed after TODO.
2018-12-07Upgrade flatpak to org.freedesktop.Sdk//18.08Stephan Bergmann
...fixing <https://github.com/flathub/org.libreoffice.LibreOffice/issues/54> "Build against org.freedesktop.Platform 18.08" Change-Id: I70448277ce326075435932c75a837bd7be3d4508
2018-12-07Drop obsolete font sources from flatpak manifestStephan Bergmann
...which are no longer used by the LO build since 0ce173b50fd12342979cf3f8f9b2d92267552060 "tdf#103080 Dont package Open Sans and PT_Serif fonts" Change-Id: I9ece7a85fe0003711eb23f332e617b780e6701cd
2018-12-07Upgrade external/postgresql to postgresql-9.2.24Stephan Bergmann
...which is the latest 9.2.x currently listed at <https://www.postgresql.org/ftp/source/>. 9.2.1 doesn't build against OpenSSL 1.1 which dropped SSL_library_init (cf. <https://wiki.openssl.org/ index.php/Library_Initialization#libssl_Initialization>), and 9.2.24 apparently has that covered. (Ran into this when trying to upgrade the LibreOffice flatpak build to org.freedesktop.Sdk//18.08, which has OpenSSL 1.1.) On Windows, the new tarball as-is fails with > ..\..\port\chklocale.c(214): error C2037: left of 'lc_codepage' specifies undefined struct/union '__crt_locale_data' because at least in Windows Kits/10/Include/10.0.17763.0/ucrt/corecrt.h (included from Windows Kits/10/Include/10.0.17763.0/ucrt/locale.h), the relevant definitions are now > typedef struct __crt_locale_data_public > { > unsigned short const* _locale_pctype; > _Field_range_(1, 2) int _locale_mb_cur_max; > unsigned int _locale_lc_codepage; > } __crt_locale_data_public; > > typedef struct __crt_locale_pointers > { > struct __crt_locale_data* locinfo; > struct __crt_multibyte_data* mbcinfo; > } __crt_locale_pointers; > > typedef __crt_locale_pointers* _locale_t; which presumably has changed from a past state where that lc_codepage member was directly publicly accessible. <https://dev-www.libreoffice.org/src/postgresql-9.2.24.tar.bz2> is a copy of <https://ftp.postgresql.org/pub/source/v9.2.24/postgresql-9.2.24.tar.bz2>; `sha256sum postgresql-9.2.24.tar.bz2` reports the same a754c02f7051c2f21e52f8669a421b50485afcde9a581674d6106326b189d126 as recorded in <https://ftp.postgresql.org/pub/source/v9.2.24/postgresql-9.2.24.tar.bz2.sha256> Change-Id: I196dd93aa03471042efba57ea639e1bb6655de98 Reviewed-on: https://gerrit.libreoffice.org/64730 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-06Remove obsolete GCC version checksStephan Bergmann
...after <https://gerrit.libreoffice.org/63951> "Bump (Linux) GCC baseline to 7.0.0". (In some cases, those checks now need to check for __clang__, which was implicitly covered in the past by Clang consistently reporting to be GCC 4.2.1.) Change-Id: I860fef8c4ca41c22a7541f0fb2d34b37d1d69bed Reviewed-on: https://gerrit.libreoffice.org/63952 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-06Default all tests to run with the svp pluginJan-Marek Glogowski
Otherwise a test can already require a windowed VCL plugin by calling gb_CppunitTest_use_vcl_non_headless(_with_windows)?. For compatibility on unix --headless still implies the use of the svp plugin, but now a SAL_USE_VCLPLUGIN will override it. All the explicit SAL_USE_VCLPLUGIN=svp are not needed, as this is now included in the gb_TEST_ENV_VARS variable and gengal already calls Application::EnableConsoleOnly(). Change-Id: I6b4e75282aa88d747db87d60ffe6c8f282187c5f Reviewed-on: https://gerrit.libreoffice.org/64052 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2018-12-06Drop juh.jar dependency from Java UNO testsJan-Marek Glogowski
Since upstream Java reverted the strict classpath checks, it's not needed anymore. See discussion in https://gerrit.libreoffice.org/#/c/63118 and http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8513ac27b651 Change-Id: Iff863702b1aeda157c8e230ab36372a71dcfb4bb Todo: tdf#121925 Reviewed-on: https://gerrit.libreoffice.org/64634 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2018-12-06No need to bundle gst-libav in the flatpak any moreStephan Bergmann
756c9f2317605e39d9cb058e650962acd2d81739 "Merge upstream fixes into solenv/flatpak-manifest.in" had introduced it (via <https://github.com/flathub/ org.libreoffice.LibreOffice/commit/7d69e505165d4bbf5fa0b34b5fb2cbff9dfaf9bd> "For now, bundle gst-libav to be able to play mp4 videos in impress" to fix <https://github.com/flathub/org.libreoffice.LibreOffice/issues/20> "Impress don't insert a video" back when the LO flatpak was based on org.gnome.Platform//3.26 which doesn't contain /usr/lib/gstreamer-1.0/libgstlibav.so. (And /app/lib/gstreamer-1.0/libgstlibav.so is apparently the only file that the gst-libav module contributes to the LO flatpak.) When 727bfa2c87db170483c1e4ae895174295b070c77 "Merge in Flatpak improvements" switched the runtime to org.freedesktop.Platform//1.6 (via <https://github.com/flathub/org.libreoffice.LibreOffice/commit/ 7a2393f5fcab8c6938180c4718f2c61acd495528> "port to freedesktop.org 1.6 runtime") it kept the gst-libav module even though org.freedesktop.Platform//1.6 contains /usr/lib/gstreamer-1.0/libgstlibav.so. Lets assume it was kept by accident and can be removed. (At least the scenario from <https://github.com/flathub/ org.libreoffice.LibreOffice/issues/20#issuecomment-368543622> "Impress don't insert a video" still works with this change.) Change-Id: I692d01bfe5882c05d63124db7cdfa6390540e69f Reviewed-on: https://gerrit.libreoffice.org/64703 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-06Format and document combobox classes of BasicIDEtagezi
Change-Id: Ie4f9c142d221b16072748c9c2deaa96c4704b90d Reviewed-on: https://gerrit.libreoffice.org/64422 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-12-04In flatpak build, disable problematic test using gpg for nowStephan Bergmann
...which fails as documented in solenv/flatpak-disable-gpgconf-socketdir-test.patch, presumably because the gpg software in org.freedesktop.Sdk//1.6 (which has e.g. "gpgconf (GnuPG) 2.1.14-unknown") doesn't shut down a started gpg daemon again. Lets see if this will get fixed by <https://github.com/flathub/org.libreoffice.LibreOffice/issues/54> "Build against org.freedesktop.Platform 18.08" (where org.freedesktop.Sdk//18.08 has e.g. "gpgconf (GnuPG) 2.2.9"). Change-Id: I9c7ad326ff8f2278ec58ee484d088f6fba97694d
2018-12-04Building LibreOffice needs gperf 3.1 nowStephan Bergmann
...since e8e3b00bafefffa1b8a35c5721988fb3bf1f817c "Require at least gperf 3.1, which no longer emits 'register'", but org.freedesktop.Sdk//1.6 only has "GNU gperf 3.0.4" (and org.freedesktop.Sdk//18.08 also only has that version, so this fix will remain relevant even when <https://github.com/flathub/org.libreoffice.LibreOffice/issues/54> "Build against org.freedesktop.Platform 18.08" eventually gets addressed). Change-Id: I5a4fc6692aa077c989348903a3ed1f178922cfcb
2018-12-04Adapt solenv/flatpak-manifest.in to recent download.lst changesStephan Bergmann
Change-Id: Idffd274a18df14a96e61bf61ba09f837fdbbf9c7
2018-12-04weld OfaAutoCorrDlgCaolán McNamara
Change-Id: Iba217a2998de57bf963872f9b8c1cf38694eb935 Reviewed-on: https://gerrit.libreoffice.org/64476 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-12-03add ASAN suppression file for multiple static linkage of graphiteStephan Bergmann
ASAN_OPTIONS=...:suppressions=.../solenv/sanitizers/asan-suppressions:... Change-Id: Ibe86fd0bfa0ff9bba45ad6828457195ca9ce46a5
2018-12-03Add AnyCompareFactory_get_implementation and...Tor Lillqvist
... com_sun_star_comp_util_OfficeInstallationDirectories. Needed when loading a .ott document. Change-Id: I6074869074b47d2fb679132975520b18659b5c67
generated by cgit (git 2.34.1) at 2025-02-01 04:41:59 +0000