summaryrefslogtreecommitdiff
path: root/external
AgeCommit message (Collapse)AuthorFilesLines
2021-07-28tdf#101630 - gdrive support w/oAuth and Drive API v3Christian Lohmaier3-0/+889
LibreOffice is only using drive.file scope, so can only see files it owns/that were created by LibreOffice. In addition, also store the refresh token in LO's password-store if the user enabled persistent storage, removing the need to to the copy'n'paste dance to grant access each time LO is launched. related tdf#115643 also store the refresh token for onedrive consolidate the fallback-auth provides for onedrive/gdrive into one, they are all the same login in browser, then copy code method that ultimately should be changed to having LO listen on local port for the code Change-Id: I97e3843682c302d2884e35ece6e72bc3a07e2539 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119572 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> (cherry picked from commit 73041de9563c9a973d1b5394c6e5520a7d799980) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119446 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-07-23curl: upgrade to release 7.78.0Michael Stahl7-29/+13
* Fixes CVE-2020-8284 CVE-2021-22924 * Also fixes these which don't look relevant to LO: CVE-2020-8231 CVE-2020-8285 CVE-2020-8286 CVE-2021-22876 CVE-2021-22890 CVE-2021-22897 CVE-2021-22898 CVE-2021-22901 CVE-2021-22922 CVE-2021-22923 CVE-2021-22925 CVE-2021-22926 * disable some new protocols and dependencies * remove curl-ios.patch.1 as the code no longer exists upstream Change-Id: I12d5f87f4d503a5f9859226a05cfe2a07e46d993 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119313 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 946f457c885bd10ff1a7281c351f3981f035f5a7) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119261 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-07-08breakpad: don't include the users's env in linux dumpsChristian Lohmaier2-0/+14
Change-Id: I004b862295686789c0a88dc678bd098d81c76421 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117503 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> (cherry picked from commit 47282cc577eda78b9cceff0860e74ce7b3f121cd) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117728
2021-06-28python3: update to 3.8.10Jan-Marek Glogowski1-36/+0
So we don't build 3.8.8rc1 anymore. I didn't look into 3.9. Change-Id: Ife7d898c913b9b164168b0ef23a055deea55815f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117757 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit c22fc8e1f60bb98a87d22e7ff9bd3290dbb9fe02) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117854 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-06-23tdf#141709: Use poppler_dataMichael Warner3-0/+312
Bundle the files from poppler_data and provide the path to them to poppler when the bundled poppler library is used. Change-Id: I13a2ef861303a0be17aa0a861ef8ac96ed8a93be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117523 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 648e4106cc002ff5b8184a8c104f93cb06e4b540) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117714
2021-06-11use freshly compiled dump_syms.exe on windows for symbolinfo extractionChristian Lohmaier6-2/+181
while self compiled one still segfaults frequently, it is a tad better than the included one (and compiling froms source instead of using precompiled binaries is a net win in any case) Out of 50 attempts with the mergedlo.dll, the new compiled dump_syms succeeded 11 times, the shipped one succeeded 7 times - so could still be regular variance in that small sample size, but at least not significantly worse either. Change-Id: I86c213fe6aece58f1391d4c2bf9906b85eee9c57 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117056 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-06-10external/mdds: Mark patch as upstreamedStephan Bergmann1-0/+3
Change-Id: Id61fbaafb575a8c745e5b3cc5b2ff8ae4526d94c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116960 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-06-09external/pdfium: Latest MSVC now needs the GCC workaround, tooStephan Bergmann1-1/+1
...or else a build with MS VS 2019 16.10.0 and --with-latest-c++ would cause a stack overflow during CppunitTest_xmlsecurity_pdfsigning in the same way as described at 6391e3c4dcd4d61c2f95f996e797e49b5586dbd1 "external/pdfium: Work around GCC C++20 recursive comparison issue". Interestingly, builds with recent Clang (on various platforms) and --with-latest-c++ do not run into that stack overflow issue, so it appears that Clang implements subtly different rules for C++20 and beyond here than do GCC and MSVC. (The GCC issue <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94141> "c++20 rewritten operator== recursive call mixing friend and external operators for template class" mentioned in external/pdfium/UnpackedTarball_pdfium.mk may not be the most accurate description of the precise issue at hand here, but lets keep it at that for now. Its comments do mention "that some people are going to try and change the rules to avoid breaking code like this.") But regardless of what the exact rules are for C++20 and beyond, these problematic overloads are only needed for C++17 and earlier anyway, as C++20 can cover them with automatic rewrites of other operators. So lets generally disable them for C++20 and beyond. Change-Id: I99033d6f09f069f00a6916ef40fd03dd4962a5c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116882 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-06-09external/mdds: -Werror,-Wunused-but-set-variable (Clang 13 trunk)Stephan Bergmann2-1/+48
> In file included from svl/source/misc/gridprinter.cxx:16: > In file included from workdir/UnpackedTarball/mdds/include/mdds/multi_type_matrix.hpp:37: > In file included from workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector.hpp:1358: > workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector_def.inl:851:15: error: variable 'start_pos' set but not used [-Werror,-Wunused-but-set-variable] > size_type start_pos = m_cur_size; > ^ > workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector_def.inl:3926:15: error: variable 'start_row_itr' set but not used [-Werror,-Wunused-but-set-variable] > size_type start_row_itr = start_row_in_block1; > ^ Change-Id: I1f5e7e1f6a2b8457eb6d65dbd65336d3684c2b89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116808 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2021-06-07pass -enable-symbols down to libxmlNoel Grandin1-1/+1
Change-Id: Iceef587366bebe6007f40e100f19e6a2f048adda Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116764 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-03external/cairo: Fix previous -fsanitize=alignment fixStephan Bergmann1-6/+2
13f6d80330208eeb45fe9a03bb462941fb4eda2a "external/cairo: Support building with ASan/UBSan" had added the src/cairo-image-source.c blob to external/cairo/cairo/san.patch.0 to fix > > cairo-image-source.c:512:10: runtime error: load of misaligned address 0x6180037aee6f for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment > during UITest_writer_tests7 I had created that patch attempting to do a faithful emulation of the original code (which I had naively assumed to be correct, modulo the alignment issue), reading four consecutive bytes and interpreting them as an uint32_t in the system's byte order. I had not noticed back then that all that CAIRO_FORMAT_RGB24_888 was added by external/cairo/cairo/cairo-1.10.2.patch, introduced with 54596087e57ea533253e19eea594d9b6c06e8d26 "vcl-svp: add 24-bit (3-byte) RGB surface support to Cairo". Its > + * @CAIRO_FORMAT_RGB24_888: each pixel is a 24-bit quantity, > + * with Red, Green, Blue taking 8-bits each, in that order. (Since 1.1x) and > + * Need this until CAIRO_FORMAT_RGB24_888 is in some official release. > + * Otherwise we can't reliably check if this is available or we should > + * convert from 24-bit RGB to 32-bit RGB before passing to Cairo. comments make it sound as if this code might come from some official cairo upstream branch, but I cannot find anything at git.freedesktop.org/git/cairo. I have no idea about the provenance and quality of that code. However, I now (a) from the above comments naively assume that the intent of CAIRO_FORMAT_RGB24_888 is to store R, G, B in that order in three bytes with increasing addresses (i.e., independent of the system's byte order for larger- than-byte words); (b) thus consider the original src/cairo-image-source.c code in external/cairo/cairo/cairo-1.10.2.patch broken (as it attempts to read all three values in one read, in system byte order, which would fail for big endian); and (c) thus consider the faithful emulation code in external/cairo/cairo/san.patch.0 to be broken, too. Based on the above, I here fix at least the external/cairo/cairo/san.patch.0 code (which is applied unconditionally, even for non-ASan/UBSan builds, thus always overriding the original external/cairo/cairo/cairo-1.10.2.patch code). The following line > pixel &= 0x00ffffff; /* ignore next pixel bits */ should no longer be necessary now, and it is probably better to directly fix the original code in external/cairo/cairo/cairo-1.10.2.patch, but I'll leave that for a potential follow-up fix, once the provenance and assumed quality of that original CAIRO_FORMAT_RGB24_888 code is clarified. (I came across this code now with a --without-system-cairo ASan/UBSan Linux build, where JunitTest_toolkit_unoapi_1 failed with > ==1060406==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300146fb48 at pc 0x7fff9b45b338 bp 0x7ffffffef1d0 sp 0x7ffffffef1c8 > READ of size 1 at 0x60300146fb48 thread T0 > Detaching from process 1060652 > #0 in _pixel_to_solid at workdir/UnpackedTarball/cairo/src/cairo-image-source.c:515:207 > #1 in _pixman_image_for_surface at workdir/UnpackedTarball/cairo/src/cairo-image-source.c:1309:22 > #2 in _pixman_image_for_pattern at workdir/UnpackedTarball/cairo/src/cairo-image-source.c:1574:9 > #3 in _cairo_image_source_create_for_pattern at workdir/UnpackedTarball/cairo/src/cairo-image-source.c:1619:2 > #4 in composite_aligned_boxes at workdir/UnpackedTarball/cairo/src/cairo-spans-compositor.c:678:8 > #5 in clip_and_composite_boxes at workdir/UnpackedTarball/cairo/src/cairo-spans-compositor.c:882:11 > #6 in _cairo_spans_compositor_mask at workdir/UnpackedTarball/cairo/src/cairo-spans-compositor.c:999:14 > #7 in _cairo_compositor_mask at workdir/UnpackedTarball/cairo/src/cairo-compositor.c:106:11 > #8 in _cairo_image_surface_mask at workdir/UnpackedTarball/cairo/src/cairo-image-surface.c:952:12 > #9 in _cairo_surface_mask at workdir/UnpackedTarball/cairo/src/cairo-surface.c:2247:14 > #10 in _cairo_gstate_mask at workdir/UnpackedTarball/cairo/src/cairo-gstate.c:1136:11 > #11 in _cairo_default_context_mask at workdir/UnpackedTarball/cairo/src/cairo-default-context.c:993:12 > #12 in cairo_mask at workdir/UnpackedTarball/cairo/src/cairo.c:2283:14 > #13 in SvpSalGraphics::drawAlphaBitmap(SalTwoRect const&, SalBitmap const&, SalBitmap const&) at vcl/headless/svpgdi.cxx:745:5 > #14 in SalGraphics::DrawAlphaBitmap(SalTwoRect const&, SalBitmap const&, SalBitmap const&, OutputDevice const&) at vcl/source/gdi/salgdilayout.cxx:832:16 > #15 in OutputDevice::DrawDeviceAlphaBitmap(Bitmap const&, AlphaMask const&, Point const&, Size const&, Point const&, Size const&) at vcl/source/outdev/bitmap.cxx:704:29 > #16 in OutputDevice::DrawDeviceBitmap(Point const&, Size const&, Point const&, Size const&, BitmapEx&) at vcl/source/outdev/bitmap.cxx:516:9 > #17 in OutputDevice::DrawBitmapEx(Point const&, Size const&, Point const&, Size const&, BitmapEx const&, MetaActionType) at vcl/source/outdev/bitmap.cxx:391:9 > #18 in OutputDevice::DrawBitmapEx(Point const&, Size const&, BitmapEx const&) at vcl/source/outdev/bitmap.cxx:292:9 > #19 in OutputDevice::DrawTransformedBitmapEx(basegfx::B2DHomMatrix const&, BitmapEx const&, double) at vcl/source/outdev/bitmap.cxx:1315:9 > #20 in drawinglayer::processor2d::VclProcessor2D::RenderBitmapPrimitive2D(drawinglayer::primitive2d::BitmapPrimitive2D const&) at drawinglayer/source/processor2d/vclprocessor2d.cxx:394:21 > #21 in drawinglayer::processor2d::VclPixelProcessor2D::processBitmapPrimitive2D(drawinglayer::primitive2d::BitmapPrimitive2D const&) at drawinglayer/source/processor2d/vclpixelprocessor2d.cxx:524:5 > #22 in drawinglayer::processor2d::VclPixelProcessor2D::processBasePrimitive2D(drawinglayer::primitive2d::BasePrimitive2D const&) at drawinglayer/source/processor2d/vclpixelprocessor2d.cxx:252:13 > #23 in drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::Primitive2DContainer const&) at drawinglayer/source/processor2d/baseprocessor2d.cxx:69:25 > #24 in drawinglayer::processor2d::VclProcessor2D::RenderTransformPrimitive2D(drawinglayer::primitive2d::TransformPrimitive2D const&) at drawinglayer/source/processor2d/vclprocessor2d.cxx:912:5 > #25 in drawinglayer::processor2d::VclPixelProcessor2D::processBasePrimitive2D(drawinglayer::primitive2d::BasePrimitive2D const&) at drawinglayer/source/processor2d/vclpixelprocessor2d.cxx:317:13 > #26 in drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::Primitive2DContainer const&) at drawinglayer/source/processor2d/baseprocessor2d.cxx:69:25 > #27 in drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::BasePrimitive2D const&) at drawinglayer/source/processor2d/baseprocessor2d.cxx:46:13 > #28 in drawinglayer::processor2d::VclPixelProcessor2D::processBasePrimitive2D(drawinglayer::primitive2d::BasePrimitive2D const&) at drawinglayer/source/processor2d/vclpixelprocessor2d.cxx:434:13 > #29 in drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::Primitive2DContainer const&) at drawinglayer/source/processor2d/baseprocessor2d.cxx:69:25 > #30 in sdr::contact::ObjectContactOfPageView::DoProcessDisplay(sdr::contact::DisplayInfo&) at svx/source/sdr/contact/objectcontactofpageview.cxx:279:31 > #31 in sdr::contact::ObjectContactOfPageView::ProcessDisplay(sdr::contact::DisplayInfo&) at svx/source/sdr/contact/objectcontactofpageview.cxx:116:21 > #32 in SdrPageWindow::RedrawAll(sdr::contact::ViewObjectContactRedirector*) at svx/source/svdraw/sdrpagewindow.cxx:353:28 > #33 in SdrPageView::CompleteRedraw(SdrPaintWindow&, vcl::Region const&, sdr::contact::ViewObjectContactRedirector*) at svx/source/svdraw/svdpagv.cxx:239:18 > #34 in SdrPaintView::DoCompleteRedraw(SdrPaintWindow&, vcl::Region const&, sdr::contact::ViewObjectContactRedirector*) at svx/source/svdraw/svdpntv.cxx:606:21 > #35 in SdrPaintView::CompleteRedraw(OutputDevice*, vcl::Region const&, sdr::contact::ViewObjectContactRedirector*) at svx/source/svdraw/svdpntv.cxx:519:5 > #36 in sd::View::CompleteRedraw(OutputDevice*, vcl::Region const&, sdr::contact::ViewObjectContactRedirector*) at sd/source/ui/view/sdview.cxx:475:17 > #37 in sd::DrawView::CompleteRedraw(OutputDevice*, vcl::Region const&, sdr::contact::ViewObjectContactRedirector*) at sd/source/ui/view/drawview.cxx:520:21 > #38 in sd::DrawViewShell::Paint(tools::Rectangle const&, sd::Window*) at sd/source/ui/view/drviews5.cxx:420:17 > #39 in sd::Window::Paint(OutputDevice&, tools::Rectangle const&) at sd/source/ui/view/sdwindow.cxx:212:22 > #40 in PaintHelper::DoPaint(vcl::Region const*) at vcl/source/window/paint.cxx:313:20 > #41 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) at vcl/source/window/paint.cxx:616:17 > #42 in PaintHelper::~PaintHelper() at vcl/source/window/paint.cxx:552:30 > #43 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) at vcl/source/window/paint.cxx:622:1 > #44 in PaintHelper::~PaintHelper() at vcl/source/window/paint.cxx:552:30 > #45 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) at vcl/source/window/paint.cxx:622:1 > #46 in PaintHelper::~PaintHelper() at vcl/source/window/paint.cxx:552:30 > #47 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) at vcl/source/window/paint.cxx:622:1 > #48 in PaintHelper::~PaintHelper() at vcl/source/window/paint.cxx:552:30 > #49 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) at vcl/source/window/paint.cxx:622:1 > #50 in vcl::Window::PaintImmediately() at vcl/source/window/paint.cxx:1325:24 > #51 in vcl::Window::PaintImmediately() at vcl/source/window/paint.cxx:1269:39 > #52 in SvImpLBox::MyUserEvent(void*) at vcl/source/treelist/svimpbox.cxx:3063:18 > #53 in SvImpLBox::LinkStubMyUserEvent(void*, void*) at vcl/source/treelist/svimpbox.cxx:3057:1 > #54 in Link<void*, void>::Call(void*) const at include/tools/link.hxx:111:45 > #55 in ImplHandleUserEvent(ImplSVEvent*) at vcl/source/window/winproc.cxx:1991:30 > #56 in ImplWindowFrameProc(vcl::Window*, SalEvent, void const*) at vcl/source/window/winproc.cxx:2561:13 > #57 in SalFrame::CallCallback(SalEvent, void const*) const at vcl/inc/salframe.hxx:306:29 > #58 in SvpSalInstance::ProcessEvent(SalUserEventList::SalUserEvent) at vcl/headless/svpinst.cxx:312:22 > #59 in non-virtual thunk to SvpSalInstance::ProcessEvent(SalUserEventList::SalUserEvent) at vcl/headless/svpinst.cxx (instdir/program/libvcllo.so +0xae7a222) > #60 in SalUserEventList::DispatchUserEvents(bool)::$_0::operator()() const at vcl/source/app/salusereventlist.cxx:119:58 > #61 in SalUserEventList::DispatchUserEvents(bool) at vcl/source/app/salusereventlist.cxx:120:13 > #62 in SvpSalInstance::DoYield(bool, bool) at vcl/headless/svpinst.cxx:461:19 > #63 in ImplYield(bool, bool) at vcl/source/app/svapp.cxx:465:48 > #64 in Application::Yield() at vcl/source/app/svapp.cxx:532:5 > #65 in Application::Execute() at vcl/source/app/svapp.cxx:444:9 > #66 in desktop::Desktop::Main() at desktop/source/app/app.cxx:1587:13 > #67 in ImplSVMain() at vcl/source/app/svmain.cxx:198:35 > #68 in SVMain() at vcl/source/app/svmain.cxx:230:12 > #69 in soffice_main at desktop/source/app/sofficemain.cxx:98:12 > #70 in sal_main at desktop/source/app/main.c:49:15 > #71 in main at desktop/source/app/main.c:47:1 > #72 in __libc_start_main at /usr/src/debug/glibc-2.33-8.fc34.x86_64/csu/../csu/libc-start.c:332:16 > #73 in _start at <null> (instdir/program/soffice.bin +0x251acd) > > 0x60300146fb48 is located 0 bytes to the right of 24-byte region [0x60300146fb30,0x60300146fb48) > allocated by thread T0 here: > #0 in operator new[](unsigned long) at ~/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:102:3 > #1 in ImplCreateDIB(Size const&, vcl::PixelFormat, BitmapPalette const&) at vcl/headless/svpbmp.cxx:126:24 > #2 in SvpSalBitmap::Create(Size const&, vcl::PixelFormat, BitmapPalette const&) at vcl/headless/svpbmp.cxx:156:13 > #3 in Bitmap::Bitmap(Size const&, vcl::PixelFormat, BitmapPalette const*) at vcl/source/bitmap/bitmap.cxx:135:15 > #4 in Bitmap::Crop(tools::Rectangle const&) at vcl/source/bitmap/bitmap.cxx:489:20 > #5 in BitmapEx::Crop(tools::Rectangle const&) at vcl/source/bitmap/BitmapEx.cxx:360:25 > #6 in drawinglayer::primitive2d::DiscreteShadow::getLeft() const at drawinglayer/source/primitive2d/discreteshadowprimitive2d.cxx:148:61 > #7 in drawinglayer::primitive2d::DiscreteShadowPrimitive2D::create2DDecomposition(drawinglayer::primitive2d::Primitive2DContainer&, drawinglayer::geometry::ViewInformation2D const&) const at drawinglayer/source/primitive2d/discreteshadowprimitive2d.cxx:251:72 > #8 in drawinglayer::primitive2d::BufferedDecompositionPrimitive2D::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor&, drawinglayer::geometry::ViewInformation2D const&) const at drawinglayer/source/primitive2d/baseprimitive2d.cxx:122:9 > #9 in drawinglayer::primitive2d::DiscreteMetricDependentPrimitive2D::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor&, drawinglayer::geometry::ViewInformation2D const&) const at drawinglayer/source/primitive2d/primitivetools2d.cxx:48:47 trying to read the fourth byte of a presumed uint32_t starting at offset 21 of a 24-byte buffer.) Change-Id: Ibe8bc39e3736c64ace61af2217100c9d8bb96d5c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116637 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-06-01cairo: just register and use external fontconfigJan-Marek Glogowski4-16/+3
Except for the pixman include, the ANDROID cairo external is the same then the other OS use. It also builds fontconfig, so there is really no need to depend on the source (ok, this way it can be a bit more parallel, if nothing is generated). But the build nevertheless always sets includes for fontconfig anyway. And the code implied you can build Android without --disable-dynloading. Change-Id: I9970dc5c052b6fa80588233244c6828079d8277e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116554 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-06-01cairo: Drop config for WNT and MACOSX buildJan-Marek Glogowski5-95/+0
It's not used on these platforms since a long time. Change-Id: Idac41f1be0a546fd8aa0dd88709ebfa3255a104e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116555 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-05-28crashtesting: backport assert downgradeCaolán McNamara2-0/+31
Change-Id: I6d813cd9996633b207e30c2f1fff707810396153 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116315 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-05-25upgrade to Expat 2.4.1Caolán McNamara3-12/+14
drop ubsan patch in favour of fix applied as https://github.com/libexpat/libexpat/pull/398 Change-Id: I59eb9e24206b9a4cf323b7f7d48d8df0792a1c46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116092 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-05-21libxml2: upgrade to release 2.9.12Michael Stahl4-16/+4
Fixes: CVE-2021-3516 CVE-2021-3517 CVE-2021-3518 CVE-2021-3537 CVE-2021-3541 * external/libxml2/ubsan.patch.0: remove, fixed upstream Change-Id: I347dc854b862e78bde87d3e57cf5fdb584ca5673 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115913 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-05-20upload libetonyek 0.1.10David Tardon6-97/+86
Change-Id: Iad586802e89b19701a20bebff06b238b617af2a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115769 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2021-05-14Change one more <Carbon/Carbon.h> to <CoreGraphics/CoreGraphics.h>Tor Lillqvist1-0/+11
Change-Id: Ib8ed1e4270b18de4761155f9aa7d536faaf7bd38 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115581 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-05-12Update to ICU 69.1Eike Rathke3-56/+14
Change-Id: I32836175a877349777dcbb6eb7b0d813aa31199a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115479 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-05-12external: update pdfium to 4500Miklos Vajna4-21/+17
Change-Id: I38c85fb3e30ffd1f7fc0a11948fc01338f7bb205 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115444 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-05-10upload libmwaw 0.3.19David Tardon3-29/+2
Change-Id: Ibb26390e6cc13c925f499bf95cfc6177d8c9b735 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115355 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2021-05-07external/python3: Mark configure part of darwin.patch.0 as reported upstreamStephan Bergmann1-0/+3
Change-Id: Ibf9fb088eb1d7e11582518aeafa233dfa7c56bf6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115223 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-07external/python3: Clang 13 trunk implements --print-multiarch nowStephan Bergmann1-0/+12
...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>
2021-05-07external/python3: First removeunnecessarystuff, then fixinstallnamesStephan Bergmann1-1/+2
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>
2021-05-06pdfium build fix with Android NDK 19Andras Timar2-0/+18
Change-Id: I618095efab0a7ed7babdabc36db6a473b1af78da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115161 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com> (cherry picked from commit 01765acee6b4931b6c69252b8357f81fd26e33bd) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115090 Tested-by: Jenkins
2021-05-05WASM: add initial support for Emscripten cross buildJan-Marek Glogowski63-73/+195
- configure with: - --host=wasm64-local-emscripten - had to make a few externals optional, so adding: - --disable-nss - --disable-cmis - --disable-curl Change-Id: I48d1c73d2675ad2e2beaf2c341578199efbd24ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111130 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-05-05Switch OPENSSL config var from negative to positiveJan-Marek Glogowski5-15/+26
- 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>
2021-05-03liborcus,zxing: add link to GCC bugMichael Stahl2-0/+4
Change-Id: I9420e786c4050a9ae79f1deab76a43e62c3b15fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115031 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-05-03update breakpad to the current chrome_m90 snapshotLuboš Luňák7-602/+46
We've been using a version from 2015. And it appears that most (all?) crashreports generated on Windows have unusable backtraces, so maybe this update helps with that. Change-Id: Ied4a7943e6023c625bcd9060f18b4b90c00ad29b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113750 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-05-01liborcus: newline problem with GCC 11 -E -fdirectives-onlyMichael Stahl2-0/+16
ooxml_tokens.inl:3524:32: error: stray '#' in program Change-Id: Ib7f50e1798e8c985f31a0338944ae1e9b439e98f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114975 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-05-01zxing: newline problem with GCC 11 -E -fdirectives-onlyMichael Stahl2-1/+21
KRHangulMapping.h:38:55: error: stray '#' in program Change-Id: I81e15f524c68da6bd5271a89035857f5e3c2ebc3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114974 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-04-30serf should use bundled openssl headers, not system openssl headersAndras Timar1-0/+1
Change-Id: I4431e5141a80394950f5711051065df42fe85f8d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114934 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-04-30allow utf-8 in xml names (liborcus) (tdf#141672)Luboš Luňák2-0/+305
Change-Id: Ib150d55b588a572e4352396f18de2331983b2aae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114892 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-04-30external: update libxmlsec to 1.2.32Miklos Vajna3-95/+0
And drop the 2 upstreamed patches. Change-Id: Ia821023d9cc06df5e9e7aef82c070ad1c98b67e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114894 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-04-28Resolves tdf#141553 - Update David CLM fontHeiko Tietze1-4/+4
Culmus font 0.131 updated to 0.133 Change-Id: Icd79dbef8dc350362ea4c4a7ed2ff05a1b95a1a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114738 Reviewed-by: Hossein <hossein.ir@gmail.com> Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org> Tested-by: Jenkins
2021-04-21Python .so files names have changed on macOS at least for some reasonTor Lillqvist1-15/+13
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>
2021-04-15fix serf dependenciesLuboš Luňák1-0/+1
RepositoryExternal.mk treats apr and apr_util as one external, but technically they are two, so both of it must be built for 'apr' to be ready to be used by serf. Change-Id: If00fb10a698fd926437e18ac0e4fa66b2722ebae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114135 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-04-14update serf to 1.3.9Luboš Luňák5-87/+59
Its build system has switches to scons, so build the library using gbuild. Change-Id: I45b784e65e4987c25baf3fa1477816c744663bf0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114107 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-04-14Revert "update Skia to chrome/m91" (tdf#141680)Luboš Luňák7-58/+139
The m91 snapshot seems to cause a number of Vulkan problems. My commit already worked around one, but there are apparently others, such as very slow startup, or a failed Skia assertion triggered by VCL Skia's copyArea(). This reverts commit 09d850e46903a528d4b08d3fdf03c3964d79fbc5. Change-Id: I4f1832ba76db15cab8eccbe115d21c989da3c841 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114089 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-04-13external/jfreereport: Get rid of remaining apache-commons-loggingStephan Bergmann14-0/+2778
...similar to b721a1cecb6ea0013be8402350110822e50b4415 "external/jfreereport: Get rid of apache-commons-logging", but where the external tarballs contain copies of commons-logging-api-1.0.4.jar to compile against, so 6de0b1710adfba82c96b75a5da6f52633a54c692 "Get rid of apache-commons-logging" did not affect them at build- but only at run-time. The sources of the seven new patch files (and which have further been adapted as necessary) are taken from <https://src.fedoraproject.org/rpms/libbase/blob/4a8cd85e49a0a00d0e0f865a3c841e3f1858a04b> "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging", <https://src.fedoraproject.org/rpms/libfonts/c/c7f7d4ed67b9ca701152732cbdac547db3ada5f4> "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging", <https://src.fedoraproject.org/rpms/libformula/c/feb5be4b393f13b131623339a5868c6b381b2507> "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging", <https://src.fedoraproject.org/rpms/libloader/c/53eeb19460f2ab934cdf4c7c7c73fd681141216c> "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging", <https://src.fedoraproject.org/rpms/librepository/c/9fa7021dfe7dcc76e32c40f99f74c3745013c501> "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging", <https://src.fedoraproject.org/rpms/libserializer/c/027e1a16f7171f7ac5f9da4683d1e1b63794bb06> "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging", and <https://src.fedoraproject.org/rpms/pentaho-libxml/c/74538ea7cdd0845f8e6dff748f8d4abfe080dbe4> "add missing patch". Change-Id: I98bbe0e24398d3652cda09b0664b4775661cd939 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114053 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-12update Skia to chrome/m91Luboš Luňák7-139/+58
Change-Id: I82050e9695b9aa49c33ee16d345bb64595b00bbc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113978 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-04-11epoxy: fix gen_dispatch.py fildescriptor leakJan-Marek Glogowski2-0/+14
Change-Id: I3f7bd1befffb45b12bc178f9addf1445a6c33921 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113944 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-04-11Get rid of apache-commons-loggingStephan Bergmann8-143/+0
...using Java 1.4 java.util.logging.Logger instead also for the last remaining uses in reportbuilder. (The mention in swext/mediawiki/src/THIRDPARTYLICENSEREADME.html was presumably a leftover from 4b6ceed4a4a9b152905a8b1712ffb9bd61373c16 "swext: Wiki Publisher does not use those apache-commons libraries".) Change-Id: Ia0bc598fe5844ced11cae497548ec7d09453a99d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113939 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-09external/jfreereport: Get rid of apache-commons-loggingStephan Bergmann8-14/+965
...using Java 1.4 java.util.logging.Logger instead. The two patch files are taken from <https://src.fedoraproject.org/rpms/pentaho-reporting-flow-engine/c/7db2dc0aaa9219edc794b535084a17fb408f284a> "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging" and <https://src.fedoraproject.org/rpms/liblayout/c/675bcd0243d31593d7b047017108b71adfe748c3> "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging", respectively Change-Id: Ie03319568f2cefc8a982c4f9ee9241f8dc0c923e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113850 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-09upload libmwaw 0.3.18David Tardon3-0/+33
Change-Id: I6ffa01f092455f79bb3690875e1b286ae2298832 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113819 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2021-04-07xmlsec: fix signing documents on WNTMichael Stahl2-0/+69
Duplicate ds:X509Certificate elements cause: warn:xmlsecurity.comp:9604:3820:xmlsecurity/source/helper/xmlsignaturehelper.cxx:658: X509Data do not form a chain: certificate in cycle: (regression from 5af5ea893bcb8a8eb472ac11133da10e5a604e66) Change-Id: I3d319a2f74dbec17b73f1c7bb8f4efe4e335f0ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113746 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-04-07Updated README.md files to represent current code / use Markdown formatHossein1-0/+2
Previously, all of the README files have been renamed to README.md and now, the contents of these files were changed to use Markdown format. Other than format inconsistency, some README.md files lacked information about modules, or were out of date. By using LibreOffice / OpenOffice wiki and other documentation websites, these files were updated. Now every README.md file has a title, and some description. The top-level README.md file is changed to add links to the modules. The result of processing the Markdown format README.md files can be seen at: https://docs.libreoffice.org/ Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-04-02tdf#140229 neon: update to release 0.31.2Jan-Marek Glogowski1-5/+5
I didn't check all commits, but the most likely fix was "Fix hang on SSL connection close with IIS (issue #11)". The server from this bug report is a "Microsoft-IIS/10.0", according to the output from "curl --dump-header". Not sure this bug is critical enough to bump the neon dependency in configure. Change-Id: I3e20bad1aa732641e6f8a83316e58fc7513186c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113495 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-03-30upload libcdr 0.1.7David Tardon2-13/+0
Change-Id: Ie01fdee7379c398fe7df7c140e2f0059bea71abe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113380 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2021-03-29speed up SkiaHelper::dump() in Skia debug buildsLuboš Luňák1-1/+9
Change-Id: Ic5c4bb38e9b8c0c1bb0e3efc2c5ee7a3fa787d93 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113320 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-01 18:58:46 +0000