summaryrefslogtreecommitdiff
path: root/external
AgeCommit message (Collapse)Author
2024-02-29tdf#113050 poppler: Enable splashDr. David Alan Gilbert
Enable the splash module, to be used in the xpdf conversion for tiled patterns. I've jumped through a couple of hoops to avoid splash bringing in freetype, extending the existing hack. This might cause us problems if someone tries to use text as a tile, but otherwise isOK. Change-Id: I76ad1268f44137ae5e3205d56170c3a7c55a2dc8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163560 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-28tdf#157135 workaround: restore and update windows-no-utf8-locales.patch.0Mike Kaganski
This partially reverts commit ed259e5efe432386b54c553cbc644b3b64976852 (Upgrade external/boost to latest Boost 1.81.0, 2023-01-05), which had dropped the patch previously introduced with commit f046fed2782f0d4244aff719ba70a56399a2583a (Don't ever attempt to initialise a std::locale with a UTF-8 locale on Windows, 2018-05-17). It seems that there is a nightmare going on in MSVCRT, and tdf#157135 is caused by dome MS bug. The problem happens in a deeply nested call to mbstowcs_s (several levels deep from std::locale constructor with name of "en_US.UTF-8"), which gets a non-null wcstr and sizeInWords equal to zero, which generates an invalid argument handler, resulting in a failed assertion "(pwcs == nullptr && sizeInWords == 0) || (pwcs != nullptr && sizeInWords > 0)" in _mbstowcs_internal from minkernel\crts\ucrt\src\appcrt\convert\mbstowcs.cpp:245, and a crash. The crashreporter initiates, but since it tries to use CRT itself, which is in fastfail mode, it hangs. The patch that is restored here was intended for something different; but it happily workarounds the nightmare. Until the proper fix found, let it be. Change-Id: Ic978f87e2e7b81fc2e1cd182a4247084ad016a9f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164068 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-27GPGME: upgrade to release 1.23.2Taichi Haradaguchi
Change-Id: I56c419fbbe615ef57b7d8117ccdc32f0daddf95f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163840 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-02-26external/freetype: nullptr-with-offsetStephan Bergmann
...as seen during CppunitTest_xmloff_style, > workdir/UnpackedTarball/freetype/src/truetype/ttgxvar.c:1048:31: runtime error: applying zero offset to null pointer > #0 in tt_var_get_item_delta at workdir/UnpackedTarball/freetype/src/truetype/ttgxvar.c:1048:31 > #1 in tt_hvadvance_adjust at workdir/UnpackedTarball/freetype/src/truetype/ttgxvar.c:1242:13 > #2 in tt_vadvance_adjust at workdir/UnpackedTarball/freetype/src/truetype/ttgxvar.c:1278:12 > #3 in tt_face_get_metrics at workdir/UnpackedTarball/freetype/src/sfnt/ttmtx.c:319:11 > #4 in cff_slot_load at workdir/UnpackedTarball/freetype/src/cff/cffgload.c:660:11 > #5 in cff_glyph_load at workdir/UnpackedTarball/freetype/src/cff/cffdrivr.c:192:13 > #6 in FT_Load_Glyph at workdir/UnpackedTarball/freetype/src/base/ftobjs.c:1066:15 > #7 in _cairo_ft_scaled_glyph_load_glyph at workdir/UnpackedTarball/cairo/src/cairo-ft-font.c:2455:13 > #8 in _cairo_ft_scaled_glyph_init at workdir/UnpackedTarball/cairo/src/cairo-ft-font.c:2640:11 > #9 in _cairo_scaled_glyph_lookup at workdir/UnpackedTarball/cairo/src/cairo-scaled-font.c:3035:6 > #10 in _cairo_scaled_font_glyph_device_extents at workdir/UnpackedTarball/cairo/src/cairo-scaled-font.c:2250:15 > #11 in _cairo_composite_rectangles_init_for_glyphs at workdir/UnpackedTarball/cairo/src/cairo-composite-rectangles.c:476:14 > #12 in _cairo_compositor_glyphs at workdir/UnpackedTarball/cairo/src/cairo-compositor.c:280:14 > #13 in _cairo_image_surface_glyphs at workdir/UnpackedTarball/cairo/src/cairo-image-surface.c:1030:12 > #14 in _cairo_surface_show_text_glyphs at workdir/UnpackedTarball/cairo/src/cairo-surface.c:2920:15 > #15 in _cairo_gstate_show_text_glyphs at workdir/UnpackedTarball/cairo/src/cairo-gstate.c:2077:15 > #16 in _cairo_default_context_glyphs at workdir/UnpackedTarball/cairo/src/cairo-default-context.c:1334:12 > #17 in cairo_show_glyphs at workdir/UnpackedTarball/cairo/src/cairo.c:3670:14 > #18 in CairoTextRender::DrawTextLayout(GenericSalLayout const&, SalGraphics const&) at vcl/unx/generic/gdi/cairotextrender.cxx:477:9 > #19 in SvpSalGraphics::DrawTextLayout(GenericSalLayout const&) at vcl/headless/svptext.cxx:72:23 > #20 in GenericSalLayout::DrawText(SalGraphics&) const at vcl/source/gdi/CommonSalLayout.cxx:171:18 > #21 in OutputDevice::ImplDrawTextDirect(SalLayout&, bool) at vcl/source/outdev/text.cxx:312:16 > #22 in OutputDevice::ImplDrawText(SalLayout&) at vcl/source/outdev/text.cxx:463:9 > #23 in OutputDevice::DrawTextArray(Point const&, rtl::OUString const&, KernArraySpan, std::span<unsigned char const, 18446744073709551615ul>, int, int, SalLayoutFlags, SalLayoutGlyphs const*) at vcl/source/outdev/text.cxx:701:9 > #24 in SwFntObj::DrawText(SwDrawTextInfo&) at sw/source/core/txtnode/fntcache.cxx:1490:31 > #25 in SwSubFont::DrawText_(SwDrawTextInfo&, bool) at sw/source/core/txtnode/swfont.cxx:1144:24 > #26 in SwFont::DrawText_(SwDrawTextInfo&) at sw/source/core/inc/swfont.hxx:324:29 > #27 in SwTextPaintInfo::DrawText_(rtl::OUString const&, SwLinePortion const&, o3tl::strong_int<int, Tag_TextFrameIndex>, o3tl::strong_int<int, Tag_TextFrameIndex>, bool, bool, bool, bool) at sw/source/core/text/inftxt.cxx:730:21 > #28 in SwTextPaintInfo::DrawText(SwLinePortion const&, o3tl::strong_int<int, Tag_TextFrameIndex>, bool) const at sw/source/core/text/inftxt.hxx:783:41 > #29 in SwTextPortion::Paint(SwTextPaintInfo const&) const at sw/source/core/text/portxt.cxx:603:18 > #30 in SwTextPainter::DrawTextLine(SwRect const&, SwSaveClip&, bool, std::optional<SwTaggedPDFHelper>&, std::optional<SwTaggedPDFHelper>&, bool) at sw/source/core/text/itrpaint.cxx:433:23 > #31 in SwTextFrame::PaintSwFrame(OutputDevice&, SwRect const&) const at sw/source/core/text/frmpaint.cxx:787:23 > #32 in SwLayoutFrame::PaintSwFrame(OutputDevice&, SwRect const&) const at sw/source/core/layout/paintfrm.cxx:3804:21 > #33 in SwFlyFrame::PaintSwFrame(OutputDevice&, SwRect const&) const at sw/source/core/layout/paintfrm.cxx:4507:20 > #34 in SwVirtFlyDrawObj::wrap_DoPaintObject(drawinglayer::geometry::ViewInformation2D const&) const at sw/source/core/draw/dflyobj.cxx:541:18 > #35 in drawinglayer::primitive2d::(anonymous namespace)::SwVirtFlyDrawObjPrimitive::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor&, drawinglayer::geometry::ViewInformation2D const&) const at sw/source/core/draw/dflyobj.cxx:244:35 > #36 in drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::BasePrimitive2D const&) at drawinglayer/source/processor2d/baseprocessor2d.cxx:46:24 > #37 in drawinglayer::processor2d::VclPixelProcessor2D::processBasePrimitive2D(drawinglayer::primitive2d::BasePrimitive2D const&) at drawinglayer/source/processor2d/vclpixelprocessor2d.cxx:397:13 > #38 in drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::Primitive2DContainer const&) at drawinglayer/source/processor2d/baseprocessor2d.cxx:69:21 > #39 in sdr::contact::ObjectContactOfPageView::DoProcessDisplay(sdr::contact::DisplayInfo&) at svx/source/sdr/contact/objectcontactofpageview.cxx:284:31 > #40 in sdr::contact::ObjectContactOfPageView::ProcessDisplay(sdr::contact::DisplayInfo&) at svx/source/sdr/contact/objectcontactofpageview.cxx:120:21 > #41 in SdrPageWindow::RedrawLayer(o3tl::strong_int<short, SdrLayerIDTag> const*, sdr::contact::ViewObjectContactRedirector*, basegfx::B2IRange const*) at svx/source/svdraw/sdrpagewindow.cxx:421:28 > #42 in SdrPageView::DrawLayer(o3tl::strong_int<short, SdrLayerIDTag>, OutputDevice*, sdr::contact::ViewObjectContactRedirector*, tools::Rectangle const&, basegfx::B2IRange const*) at svx/source/svdraw/svdpagv.cxx:265:27 > #43 in SwViewShellImp::PaintLayer(o3tl::strong_int<short, SdrLayerIDTag>, SwPageFrame const&, SwRect const&, Color const*, bool, sdr::contact::ViewObjectContactRedirector*) at sw/source/core/view/vdraw.cxx:139:20 > #44 in SwRootFrame::PaintSwFrame(OutputDevice&, SwRect const&) const at sw/source/core/layout/paintfrm.cxx:3527:33 > #45 in SwViewShell::PrtOle2(SwDoc*, SwViewOption const*, SwPrintData const&, OutputDevice&, tools::Rectangle const&, bool) at sw/source/core/view/vprint.cxx:592:27 > #46 in SwDocShell::Draw(OutputDevice*, JobSetup const&, unsigned short, bool) at sw/source/uibase/app/docsh.cxx:881:5 > #47 in SfxObjectShell::DoDraw_Impl(OutputDevice*, Point const&, Fraction const&, Fraction const&, JobSetup const&, unsigned short, bool) at sfx2/source/doc/objembed.cxx:204:5 > #48 in SfxObjectShell::DoDraw(OutputDevice*, Point const&, Size const&, JobSetup const&, unsigned short, bool) at sfx2/source/doc/objembed.cxx:151:9 > #49 in SfxObjectShell::CreatePreview_Impl(bool, VirtualDevice*, GDIMetaFile*) const at sfx2/source/doc/objcont.cxx:198:40 > #50 in SfxObjectShell::GetPreviewBitmap() const at sfx2/source/doc/objcont.cxx:110:9 > #51 in SfxObjectShell::WriteThumbnail(bool, com::sun::star::uno::Reference<com::sun::star::io::XStream> const&) at sfx2/source/doc/objstor.cxx:3850:31 > #52 in SfxObjectShell::GenerateAndStoreThumbnail(bool, com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&) at sfx2/source/doc/objstor.cxx:3808:33 > #53 in SfxObjectShell::SaveTo_Impl(SfxMedium&, SfxItemSet const*) at sfx2/source/doc/objstor.cxx:1531:19 > #54 in SfxObjectShell::PreDoSaveAs_Impl(rtl::OUString const&, rtl::OUString const&, SfxItemSet const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at sfx2/source/doc/objstor.cxx:3117:39 > #55 in SfxObjectShell::CommonSaveAs_Impl(INetURLObject const&, rtl::OUString const&, SfxItemSet&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at sfx2/source/doc/objstor.cxx:2907:9 > #56 in SfxObjectShell::APISaveAs_Impl(std::basic_string_view<char16_t, std::char_traits<char16_t>>, SfxItemSet&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at sfx2/source/doc/objserv.cxx:320:19 > #57 in SfxBaseModel::impl_store(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, bool) at sfx2/source/doc/sfxbasemodel.cxx:3233:42 > #58 in SfxBaseModel::storeToURL(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at sfx2/source/doc/sfxbasemodel.cxx:1815:13 > #59 in UnoApiTest::saveWithParams(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at test/source/unoapi_test.cxx:213:16 > #60 in UnoApiTest::save(rtl::OUString const&, char const*) at test/source/unoapi_test.cxx:178:5 > #61 in testWritingModeBTLR::TestBody() at xmloff/qa/unit/style.cxx:193:9 Change-Id: I54d4d90e203127e018b99c34785602ac3d96e425 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163925 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-25Revert "tdf#159752: Add missing NotoSans/NotoSerif fonts back"Xisco Fauli
This reverts commit aa49b95cd1bb2baa357c9aac7e5d046630ffac85. Reason for revert: https://bugs.documentfoundation.org/show_bug.cgi?id=159752#c8 Change-Id: I3f62e179240419d6cc19d9db2bf6d07673d48e05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163838 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2024-02-25tdf#124591: upgrade NotoKufiArabic to v2.109Khaled Hosny
https://github.com/notofonts/arabic/releases/tag/NotoKufiArabic-v2.109 Change-Id: Ifc6d9b6ec3e41dac27406b7582734c2cfd173a5a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163878 Tested-by: خالد حسني <khaled@libreoffice.org> Reviewed-by: خالد حسني <khaled@libreoffice.org>
2024-02-23tdf#159752: Add missing NotoSans/NotoSerif fonts backXisco Fauli
They were dropped in 69943f33bf219558d6b219f0eaeda1e25e487b05 "tdf#124591: Update Noto Sans to v2.012" and 96aba2de78ffa641f6c0c898b99158715b2f2703 "tdf#124591: Update Noto Serif to v2.012" for no apparent reason. Re-add them since they are still available upstream Change-Id: Ifd5eb72bd95be96f2ff965b17846cf76aacb0c7d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163825 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-02-23Fix warning C4589 when building with MSVC without -Wv:18Mike Kaganski
Discovered by https://gerrit.libreoffice.org/c/core/+/163717 Like these: C:\libcmis\inc\libcmis/document.hxx(51): warning C4589: Constructor of abstract class 'libcmis::Document' ignores initializer for virtual base class 'libcmis::Object' C:\libcmis\inc\libcmis/document.hxx(51): note: virtual base classes are only initialized by the most-derived type C:\libcmis\inc\libcmis/folder.hxx(58): warning C4589: Constructor of abstract class 'libcmis::Folder' ignores initializer for virtual base class 'libcmis::Object' C:\libcmis\inc\libcmis/folder.hxx(58): note: virtual base classes are only initialized by the most-derived type Change-Id: Icc7f94cc02796a86b47b025df69ec3db971ad11e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163777 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-23Revert "tdf#152524 use dispatch_async() instead of dispatch_sync()"Patrick Luby
This reverts commit b0656e6ca668a0719fbcb71b6d46c68093dda470. Reason for revert: This patch has not made any positive difference for tdf#152524. Change-Id: I5ea0f80263188049f06623ac930b4dc7856dc53e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163758 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
2024-02-22tdf#159519 libxmlsec: avoid linking function not existent in Windows 7Michael Stahl
xsec_xmlsec.dll is linked to libxmlsec-mscng.dll, which is linked to Win32 bcrypt.dll, which doesn't have BCryptKeyDerivation on Windows 7. Use GetProcAddress() to retrieve BCryptKeyDerivation at runtime; the function is not used by LibreOffice. (regression from commit 26bf26272bf525b59b4a4ce18b3ce14c1febfd7b and (due to revert) commit bfd479abf0d1d8ce36c3b0dcc6c824216f88a95b) Change-Id: I0c0c94ee0cdfd48ae7506d9dfb51fcaf8289d460 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163709 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-21external/fontconfig: Adapt library nameStephan Bergmann
...to recent bbb0663813d0476b9a654207b7006315cb417c2e "Fontconfig: upgrade to release 2.15.0" Change-Id: I6abdb1889d55edc6b50beec60b5e71707695f0ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163684 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-21tdf#159529 clear hb_ot_face_t data after fetching 'sbix' and 'glyf' tablesPatrick Luby
The 'sbix' and 'glyf' tables can be very large for color emoji fonts so clear any cached data in hb_ot_face_t after fetching that table's extents. Change-Id: Id5deda9114b7199a4194ff16879e5791acd1cd82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163674 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-21Fontconfig: upgrade to release 2.15.0Taichi Haradaguchi
Change-Id: Id50d82b4dc7c3e8000b7658a9f62efa0d6b39495 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163646 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-02-19libvisio: read and use simple solid fill stylesJaume Pujantell
Implemented the reading of simple solid fills from the fill styles list in a vsdx theme. And it's use with the quick style fill matrix value. This patch includes an alternative fix to tdf#77915 so the previous patch is no longer needed. Change-Id: Iccfe915c90bcb1280cfcbfa4920d2989d18518ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163581 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com> (cherry picked from commit fb9ca6bba9bc3ce9feb9a066636dcd986dca096b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163544 Tested-by: Jenkins
2024-02-16nss: upgrade to release 3.98Michael Stahl
Fixes CVE-2023-5388 Also update README, and remove obsolete documentation of Debian's mangled SONAME; relevant Debian changelog: nss (2:3.13.4-2) unstable; urgency=low * debian/control, debian/libnss3*, debian/rules, mozilla/security/coreconf/*, mozilla/security/nss/lib/*/manifest.mn: Move to unversioned library. ABI compatibility is ensured upstream, and the SO version, if it needed a change at any time, would be a change in the library name. There is no reason to keep making compatibility more difficult with other distros and upstream binary releases. While previous versions were one-way compatible (binaries built against other distros or upstream nspr could work on Debian), this approach works both ways. -- Mike Hommey <glandium@debian.org> Thu, 17 May 2012 09:45:36 +0200 Change-Id: Ifc1eae68827fa88ae001a3903c8555af67b488ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163482 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-16tdf#159502 libxml2: apply Solaris ld patch only on SolarisMichael Stahl
Diverging from upstream by inventing a LIBXML2_GLOBAL_VARIABLES version should only be done if actually required. Change-Id: I1520ca5078dc24ffd83e927f9c857d625e71749b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163455 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-15regenerate boost headersNoel Grandin
to reduce noise when building in debug mode with gcc (Ubuntu 13.2.0-4ubuntu3) 13.2.0 e.g. In file included from /home/noel/libo2/workdir/UnpackedTarball/boost/boost/property_tree/json_parser.hpp:15, from /home/noel/libo2/external/boost/include/boost/property_tree/json_parser.hpp:30, from /home/noel/libo2/sw/inc/pch/precompiled_sw.hxx:61: /home/noel/libo2/workdir/UnpackedTarball/boost/boost/property_tree/json_parser/error.hpp: In instantiation of ‘boost::wrapexcept<E>::wrapexcept(const E&, const boost::source_location&) [with E = boost::property_tree::json_parser::json_parser_error]’: /home/noel/libo2/workdir/UnpackedTarball/boost/boost/throw_exception.hpp:171:11: required from ‘void boost::throw_exception(const E&, const source_location&) [with E = property_tree::json_parser::json_parser_error]’ /home/noel/libo2/workdir/UnpackedTarball/boost/boost/property_tree/json_parser/detail/write.hpp:159:13: required from ‘void boost::property_tree::json_parser::write_json_internal(std::basic_ostream<typename Ptree::key_type::value_type>&, const Ptree&, const std::string&, bool) [with Ptree = boost::property_tree::basic_ptree<std::__cxx11::basic_string<char>, std::__cxx11::basic_string<char> >; typename Ptree::key_type::value_type = char; typename Ptree::key_type = std::__cxx11::basic_string<char>; typename Ptree::key_type::value_type = char; typename Ptree::key_type = std::__cxx11::basic_string<char>; std::string = std::__cxx11::basic_string<char>]’ /home/noel/libo2/workdir/UnpackedTarball/boost/boost/property_tree/json_parser.hpp:99:28: required from ‘void boost::property_tree::json_parser::write_json(std::basic_ostream<typename Ptree::key_type::value_type>&, const Ptree&, bool) [with Ptree = boost::property_tree::basic_ptree<std::__cxx11::basic_string<char>, std::__cxx11::basic_string<char> >; typename Ptree::key_type::value_type = char; typename Ptree::key_type = std::__cxx11::basic_string<char>; typename Ptree::key_type::value_type = char; typename Ptree::key_type = std::__cxx11::basic_string<char>]’ /home/noel/libo2/sw/source/core/crsr/viscrs.cxx:129:37: required from here /home/noel/libo2/workdir/UnpackedTarball/boost/boost/property_tree/json_parser/error.hpp:20:11: warning: implicitly-declared ‘boost::property_tree::file_parser_error::file_parser_error(const boost::property_tree::file_parser_error&)’ is deprecated [-Wdeprecated-copy-dtor] 20 | class json_parser_error: public file_parser_error Change-Id: I1dd49af4d8c573a07b34d3216a36f283aaafa106 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163372 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-15Expat: upgrade to release 2.6.0Taichi Haradaguchi
Fixes CVE-2023-52425 and CVE-2023-52426. Change-Id: Id135bbaea893a83129bdbee44948c09322a64c07 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163146 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-02-14Update pdfium to 6296Miklos Vajna
- external/pdfium/build.patch.1: drop most hunks which no longer apply, assuming they were only relevant for the RHEL 7 / C++17 baseline. Change-Id: Ida533485d81845a82d890f8c0b70fa61e201f880 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163329 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-12external/pdfium: Missing include (std::abs)Stephan Bergmann
Change-Id: Ia265f425cae86c671824ad355d6b91001c49adca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163236 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-08tdf#152524 use dispatch_async() instead of dispatch_sync()Patrick Luby
Commit 839cf255e2670fdf8e974af38432aacf63be4e90 used dispatch_sync() but, unfortunately, libdispatch will not create a new thread for the queue. dispatch_async_and_wait() also doesn't necessary run the queue in a separate thread so use dispatch_async() and block and wait for the libdispatch task to complete. Change-Id: I8babad30caa8a188483ddf4f62bae35f5b888dc8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163122 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
2024-02-07external/zxcvbn-c: There is no std::basic_string<int>Stephan Bergmann
...and at least LLVM 19 trunk libc++ complains about it now since <c3668779c13596e223c26fbd49670d18cd638c40> "[libc++] Remove deprecated char_traits base template (#72694)" with > In file included from dict-generate.cpp:25: > In file included from ~/llvm/inst/bin/../include/c++/v1/iostream:43: > In file included from ~/llvm/inst/bin/../include/c++/v1/ios:223: > In file included from ~/llvm/inst/bin/../include/c++/v1/__locale:24: > ~/llvm/inst/bin/../include/c++/v1/string:746:43: error: implicit instantiation of undefined template 'std::char_traits<int>' > 746 | static_assert((is_same<_CharT, typename traits_type::char_type>::value), > | ^ > dict-generate.cpp:861:18: note: in instantiation of template class 'std::basic_string<int>' requested here > 861 | StringOfInts Chld; > | ^ > ~/llvm/inst/bin/../include/c++/v1/__fwd/string.h:23:29: note: template is declared here > 23 | struct _LIBCPP_TEMPLATE_VIS char_traits; > | ^ etc., so use a std::vector<int> instead Change-Id: I51e8296edf7b16925ff01679e671525256055552 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163048 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-07tdf#152524 fork() and exec() in a separate libdispatch queuePatrick Luby
This is another attempt to stop the crashing in libdispatch by running fork() and exec() within a libdispatch task that will run in a sequential queue in a non-main thread. Change-Id: I3249510c14cc32f7f769b59289fe8380dd22ab68 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163036 Tested-by: Jenkins Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-29Experimental support for latest Emscripten (and Qt6)Stephan Bergmann
What I'm after in the context of our Embind-related code is the claim at <https://emscripten.org/docs/porting/connecting_cpp_and_javascript/embind.html#memory-management>: "JavaScript only gained support for finalizers in ECMAScript 2021, or ECMA-262 Edition 12. The new API is called FinalizationRegistry and it still does not offer any guarantees that the provided finalization callback will be called. Embind uses this for cleanup if available, but only for smart pointers, and only as a last resort." However, with the recommended emsdk 2.0.31 my tests did not show any use of that finalization support. So I wanted to try with the latest emsdk 3.1.51 instead. But then, linking vcldemo failed with > wasm-ld: error: ~/allotropia-qt5/lib/libQt5Core.a(qlogging.o): undefined symbol: std::__2::__vector_base_common<true>::__throw_length_error() const etc., so I gave it a try to rather build against latest Qt6.7, with > --with-distro=LibreOfficeWASM32 > --disable-qt5 > --enable-qt6 > QT6DIR=... TODO: The result is highly experimental, and it uses ENABLE_QT5 (i.e., the recommended setup with emsdk 2.0.31 and the <https://github.com/allotropia/qt5.git> v5.15.2+wasm branch) vs. ENABLE_QT6 (i.e., my experimental setup with emsdk 3.1.51 and the <https://github.com/qt/qt5.git> 6.7 branch) not only to distinguish between Qt5- vs. Qt6-specific behavior, but also to distinguish between old- vs. new-Emscripten-specific behavior. Of note: * The startup code appears to have changed substantially (and required setting -s MODULARIZE=1 and -s EXPORT_NAME=soffice_entry now, and telling emcc to build just soffice.js and not the wrapper soffice.html. TODO: This also required hacking into qt_soffice.html: (1) The command-line arguments (--norestore, --nologo, --writer, and the exammple.odt; all of which we should eventually get rid of, anyway). (2) Saving the generated instance as window.Module (and adapting the embindmaker-generated code, cf. the changes to static/README.wasm.md). * There were some symbol clashes between external/argon2 and libQt6Core.a(qcryptographichash.cpp.o, so renamed the problematic symbols in external/argon2. Change-Id: I5420ab566d560b11954ac6613249bfc53d8acb31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162695 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-23MAR update, too big to (not) failStephan Bergmann
On Windows, when a MAR update generated by create-partial-info contains very many patches (as easily happens with LibreOffice), applying it would fail with "failed: 7" (aka WRITE_ERROR, see workdir/UnpackedTarball/onlineupdate/onlineupdate/source/update/common/updatererror.h) because in workdir/UnpackedTarball/onlineupdate/onlineupdate/source/update/updater/updater.cpp PatchFile::mPatchStream holds open one FILE instance per patch from PatchFile::Prepare to PatchFile::Execute (and which can't easily be reworked because of the Lock/UnlockFile done on the underlying HANDLE "so it can't be messed with [in] between"), so calling NS_tfopen in PatchFile::Prepare will eventually start to fail with EMFILE. To avoid that, try to raise the limit to its maximum (but don't fail immediately if that fails, in case the given MAR update wouldn't run into the issue of too many patches, anyway), and keep fingers crossed. (See <https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setmaxstdio?view=msvc-170> "_setmaxstdio" for details: "By default, up to 512 files can be open simultaneously at the stream I/O level. This level includes files opened and accessed using the fopen, fgetc, and fputc family of functions. The limit of 512 open files at the stream I/O level can be increased to a maximum of 8,192 by use of the _setmaxstdio function.") Change-Id: I6b3499f0f6c2060628418a15f5e36021bfe7dd18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162442 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-22Create MAR updates from msi rather than from archiveStephan Bergmann
...as the former is more convenient for release engineering (see the discussion in the comments at <https://gerrit.libreoffice.org/c/core/+/162157/1#message-8d7ebbcc64a87ee8e4a073ae1a05e3b74f5a3d6a> "Also enable --with-package-format=archive for LibreOfficeWin64.conf"). Instead of ONLINEUPDATE_MAR_OLDARCHIVE and ONLINEUPDATE_MAR_OLDMETADATA make variables, the create-partial-info target now only needs an ONLINEUPDATE_MAR_OLDMSI make variable. TODO: There are two issues when comparing the content of msi files (extracted with msiexec /a), which the old code comparing the content of archives had tried to somewhat (but not fully) address with the metadata files that I had invented (and now reverted): For one, msiexec /a also extracts content that would normally be installed somewhere else in the system (e.g., it extracts Fonts, System, and System64 directories). Differences in those directories will cause a MAR update to create those directories in the installation directory, rather than to update the corresponding files in their actual locations. For another, optional components are not recognized as such, but their content must be added to the MAR file as add/patch-if, not as plain add/patch. To work around that, for now *all* files are added as add/patch-if, conditional on the files themselves. Thus, addition of files will cause a MAR update to miss them. (As they now exclusively operate on msi files, the create-update-info and create-partial-info targets are no longer meaningful for non-Windows platforms, so drop the non-Windows bin/update/create_full_mar_for_languages.py part.) Change-Id: Ifb55b5e7d1a201b4f50a27cb449a634b96c2e29b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162399 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-22cid#1586676 Big parameter passed by valueCaolán McNamara
Change-Id: I803788650dda6947a62724fd936b4ed733efbd58 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162390 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-19xmlsec: replace revert with an upstream fixMiklos Vajna
The problem in the new code was that previously xmlSecNssInit() didn't require an already initialized NSS, but 1.3.3 did. Backport upstream fix that restores the old behavior that NSS init is not needed, which allows no longer reverting the xmlSecNssUpdateAvailableCryptoTransforms() call that upstream added recently. Change-Id: Ie33ccbff0149e3c406d5574e889d90da4fdbbfb5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162292 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-01-18Don't artificially limit external/firebird to -std=gnu++11 on LinuxStephan Bergmann
0a42105a8d95473646b850eed6d428ebb93fc01f "firebird: fix CXXFLAGS" had added this to override Firebird's internal -std=gnu++03, but even back then the CXXFLAGS set there already included $(CXXFLAGS_CXX11) (so adding an explicit -std=gnu++11 should never have been necessary), and CXXFLAGS_CXX11 has by now moved beyond -std=gnu++11 to at least -std=c++20. Which reveals that the code has a C++20 incompatibility that only GCC so far complains about (see the mailing list thread starting at <https://lists.isocpp.org/std-discussion/2024/01/2482.php> "simple-template-id in a constructor declaration"), > In file included from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/firebird/src/gpre/../gpre/../common/../jrd/../common/classes/fb_string.h:39, > from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/firebird/src/gpre/../gpre/../common/../jrd/ods.h:38, > from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/firebird/src/gpre/../gpre/../common/dsc.h:32, > from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/firebird/src/gpre/../gpre/gpre.h:1514, > from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/firebird/src/gpre/hsh.cpp:31: > /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/firebird/src/include/../common/classes/alloc.h:264:36: error: expected ')' before '*' token > 264 | SubsystemThreadData* subThreadData, > | ^ > | ) > /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/firebird/src/include/../common/classes/alloc.h:263:9: note: to match this '(' > 263 | ( > | ^ (<https://ci.libreoffice.org/job/gerrit_linux_gcc_release/157406/>), etc. Change-Id: I89839452a0d474467ae62e57b6c990354e10f142 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162209 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-18Revert "tdf#134526 Firebird: upgrade to release 3.0.11"Xisco Fauli
Win daily builds are failing since then. Also Jenkins is failing intermittently so it needs more investigation Revert "New UBSan failure with Firebird 3.0.11" This reverts commit 345f8cc9de49f573b60f9dc63e7df17ce3c2f93c. Revert "external/firebird: Reinstate UBSan function-type-mismatch fix" This reverts commit d5445a8c470a661fac81a3f6fc55f6895a8ed9bc. Revert "mold: fatal: cannot open loader_path/../Debug/firebird" This reverts commit f2ba02eee98d04b3e473393d2647201ed2549b30. Revert "firebird: set -mmacosx-version-min to 10.15" This reverts commit 6998eacf542e6d6d9ec587aff3a38c3644e83c7f. Revert "tdf#134526 Firebird: upgrade to release 3.0.11" This reverts commit 00eae23267bf64e07cf057f828cd85f3c38ac669. Change-Id: Id4b0600965953051f6947f570c9b9a1f56044502 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162200 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-01-18external/firebird: Adapt to C++26Stephan Bergmann
...as seen failing with --with-latest-c++ and recent Clang 18 trunk, In file included from workdir/UnpackedTarball/firebird/src/jrd/Collation.cpp:105: > workdir/UnpackedTarball/firebird/src/jrd/../jrd/SimilarToMatcher.h:1462:11: error: invalid bitwise operation between different enumeration types ('const Op' and 'MatchState') > 1462 | switch (ENCODE_OP_STATE(node->op, state)) > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > workdir/UnpackedTarball/firebird/src/jrd/../jrd/SimilarToMatcher.h:1458:42: note: expanded from macro 'ENCODE_OP_STATE' > 1458 | #define ENCODE_OP_STATE(op, state) ((op) | (state)) > | ~~~~ ^ ~~~~~~~ > workdir/UnpackedTarball/firebird/src/jrd/../jrd/SimilarToMatcher.h:561:3: note: in instantiation of member function 'Firebird::SimilarToMatcher<unsigned char>::Evaluator::match' requested here > 561 | match(); > | ^ > workdir/UnpackedTarball/firebird/src/jrd/../jrd/SimilarToMatcher.h:462:20: note: in instantiation of member function 'Firebird::SimilarToMatcher<unsigned char>::Evaluator::getResult' requested here > 462 | return evaluator.getResult(); > | ^ > workdir/UnpackedTarball/firebird/src/jrd/Collation.cpp:787:29: note: in instantiation of member function 'Firebird::SimilarToMatcher<unsigned char>::evaluate' requested here > 787 | return pSimilarToMatcher::evaluate(pool, this, s, sl, p, pl, escape, escapeLen); > | ^ > workdir/UnpackedTarball/firebird/src/jrd/Collation.cpp:736:2: note: in instantiation of member function '(anonymous namespace)::CollationImpl<(anonymous namespace)::StartsMatcher<unsigned char, Jrd::NullStrConverter>, (anonymous namespace)::ContainsMatcher<unsigned char, Jrd::UpcaseConverter<>>, (anonymous namespace)::LikeMatcher<unsigned char>, Firebird::SimilarToMatcher<unsigned char>, Firebird::SubstringSimilarMatcher<unsigned char>, (anonymous namespace)::MatchesMatcher<unsigned char>, (anonymous namespace)::SleuthMatcher<unsigned char>>::similarTo' requested here > 736 | CollationImpl(TTYPE_ID a_type, texttype* a_tt, CharSet* a_cs) > | ^ > workdir/UnpackedTarball/firebird/src/jrd/Collation.cpp:843:28: note: in instantiation of member function '(anonymous namespace)::CollationImpl<(anonymous namespace)::StartsMatcher<unsigned char, Jrd::NullStrConverter>, (anonymous namespace)::ContainsMatcher<unsigned char, Jrd::UpcaseConverter<>>, (anonymous namespace)::LikeMatcher<unsigned char>, Firebird::SimilarToMatcher<unsigned char>, Firebird::SubstringSimilarMatcher<unsigned char>, (anonymous namespace)::MatchesMatcher<unsigned char>, (anonymous namespace)::SleuthMatcher<unsigned char>>::CollationImpl' requested here > 843 | return FB_NEW_POOL(pool) DirectImpl(id, tt, cs); > | ^ > workdir/UnpackedTarball/firebird/src/jrd/Collation.cpp:862:11: note: in instantiation of function template specialization '(anonymous namespace)::newCollation<unsigned char>' requested here > 862 | return newCollation<UCHAR>(pool, id, tt, cs); > | ^ Change-Id: I0af4752b04020e978ea4b339ff21688302c63ef6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162230 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-18silence use-after-free warning in mdds for gcc12.3 in optimized buildAron Budea
Follow-up to e7c4166f1e150b10bc2ac52e93f8ad7503db09dc as GCC 12.3 seems to be affected, too. Change-Id: I8e5ba9be64625ffd21d43e627996a9ea8602ce9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162181 Tested-by: Jenkins Reviewed-by: Aron Budea <aron.budea@collabora.com>
2024-01-17tdf#159243 fix packaging of Noto fonts/fix Armenian UI on macOSChristian Lohmaier
different packages must not share the same package name Packages create corresponding packagename.filelist files that are used during the installset creation process. When multiple packages share the same name, it is random (depending on the order make decides to build the targets) which package will actually be included in the installation set. The last package will "win" and have its file stored in the filelist and thus will be part of the installation set, all others will not be considered. Change-Id: Ieffd2addf6d59916c0c1fe01c64866472ff23803 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162206 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-01-15cid#1546160 COPY_INSTEAD_OF_MOVECaolán McNamara
and cid#1545547 COPY_INSTEAD_OF_MOVE cid#1545642 COPY_INSTEAD_OF_MOVE cid#1557206 COPY_INSTEAD_OF_MOVE Change-Id: I7a1bd4fcd065d4546917deb5d279691c8450f456 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162061 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-15cid#1545775 COPY_INSTEAD_OF_MOVECaolán McNamara
and cid#1546321 COPY_INSTEAD_OF_MOVE cid#1546272 COPY_INSTEAD_OF_MOVE cid#1546287 COPY_INSTEAD_OF_MOVE cid#1545443 COPY_INSTEAD_OF_MOVE Change-Id: Ia16a60665497e2c798fc03a2157587c107192558 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162060 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-15FreeBSD: fix OPENSSL_PLATFORMAndras Timar
Change-Id: I0f48d572edaed7e996be7a75d524c7d540a76ecd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162064 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2024-01-15Update libxmlsec to 1.3.3Miklos Vajna
Extend external/xmlsec/old-nss.patch.1, our bundled NSS in debug builds has some assert failure in relatively new xmlsec code, just disable it for now till it's clarified with upstream how to sort that out properly. E.g. CppunitTest_filter_svg fails like this: #1 0x00007ffff77503e5 in abort () at /lib64/libc.so.6 #2 0x00007ffff679ca90 in PR_Assert (s=0x7ffff44fbfe5 "oidmechhash != NULL", file=0x7ffff44fbfb6 "secoid.c", ln=2140) at ../../../../pr/src/io/prlog.c:571 #3 0x00007ffff44eaae0 in SECOID_FindOIDByMechanism (mechanism=307) at secoid.c:2140 #4 0x00007ffff6660c65 in PK11_MechanismToAlgtag (type=307) at pk11mech.c:1745 #5 0x00007fffe874e4ea in xmlSecNssCryptoCheckMechanism (type=307) at crypto.c:68 #6 0x00007fffe874ec44 in xmlSecNssUpdateAvailableCryptoTransforms (functions=0x7fffe87ffbc0 <functions>) at crypto.c:401 #7 0x00007fffe874f13d in xmlSecNssInit () at crypto.c:552 #8 0x00007fffe86b2c36 in initXmlSec() () at /home/vmiklos/git/libreoffice/core/xmlsecurity/source/xmlsec/xmlsec_init.cxx:42 #9 0x00007fffdf3c54f2 in DocumentSignatureManager::init() (this=0x7fffffff3970) at /home/vmiklos/git/libreoffice/core/xmlsecurity/source/helper/documentsignaturemanager.cxx:79 #10 0x00007fffdf43e3da in (anonymous namespace)::DocumentDigitalSignatures::ImplVerifySignatures(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, DocumentSignatureMode) (this=0x1c07ac0, rxStorage=uno::Reference to (OStorage *) 0x1944e18, xSignStream=empty uno::Reference, eMode=DocumentSignatureMode::Macros) at /home/vmiklos/git/libreoffice/core/xmlsecurity/source/component/documentdigitalsignatures.cxx:486 #11 0x00007fffdf43da17 in (anonymous namespace)::DocumentDigitalSignatures::verifyScriptingContentSignatures(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&) (this=0x1c07ac0, rxStorage=uno::Reference to (OStorage *) 0x1944e18, xSignInStream=empty uno::Reference) at /home/vmiklos/git/libreoffice/core/xmlsecurity/source/component/documentdigitalsignatures.cxx:373 #12 0x00007fffe6fa06df in SfxObjectShell::GetDocumentSignatureInformation(bool, com::sun::star::uno::Reference<com::sun::star::security::XDocumentDigitalSignatures> const&) (this=0x188c280, bScriptingContent=true, xSigner=empty uno::Reference) at /home/vmiklos/git/libreoffice/core/sfx2/source/doc/objserv.cxx:1847 Change-Id: I36dee0d2b128a6931875572aa4acc9df940ab623 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161951 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-01-12Windows MAR update issues with program/{setup,version}.iniStephan Bergmann
At least on Windows, our MSI install sets differ from our archive install sets in that their program/setup.ini and program/version.ini files have differing content: For one, they have ProductCode, UpdateCode, and MsiProductVersion (the latter only in version.ini) lines that have empty values in archive install sets and non-empty values in MSI install sets. For another, setup.ini in MSI install sets has additional ALLUSERS, BASISINSTALLLOCATION, FINDPRODUCT, INSTALLLOCATION, OFFICEINSTALLLOCATION, and UREINSTALLLOCATION lines that are completely missing in archive install sets. This is a problem when building MAR updates with create-partial-info: Both ini files contain the buildid, so will always change between builds, so will always be recorded in MAR updates. But when they are recorded as "patch", actually applying the MAR update file (generated from archive install sets) to an installation (originating from an MSI install set) will fail, as the size of the ini file in the installation doesn't match the expected size recorded in the MAR update file. I naively but strongly assume that those differences in ini file content are historic junk by now that have no practical consequences (i.e., I assume that no code actually makes use of those ini file entries). Which would mean that it should actually be harmless to replace an installation's (MSI-originating) ini files with smaller (archive-originating) ones during an update. So for now I work around that problem by always forcing these two files to be recorded as a full "add" rather than as a "patch" in the generated MAR update file. In parallel, I will look into the history of all those problematic ini file entries, and will try to verify that they are indeed unused junk, and will try to clean that up. (So that ultimately there will be no more differences between MSI and archive versions.) Change-Id: I9b22bd83889b569598162c37f9bf1a0857177063 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161974 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-12Further adapting of create-partial-infoStephan Bergmann
...along the lines of what had already been done for create-update-info, passing files to the mar executable with an -f files.txt instead of on the command line (which could grow too long for Windows), and taking the archive metadata into account. For the latter, `make create-partial-info` now expects a second make variable, ONLINEUPDATE_MAR_OLDMETADATA, in addition to ONLINEUPDATE_MAR_OLDARCHIVE. And there is a new TODO in update/create_partial_update.py that the old and new metadata should be compared for problematic changes. (For now, any such changes would just get lost by an update.) Change-Id: Ide45adedb72958fc32c5b26aa7ebb01530ccf3d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161972 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-11Fix `make create-partial-info` (for Windows, at least)Stephan Bergmann
I got lost trying to figure out how the original bin/update/create_partial_update.py code was meant to obtain old and new installation trees to diff, so I simplified that down to the create-partial-info make target now expecting an ONLINEUPDATE_MAR_OLDARCHIVE make variable that points at the old archive install set. (And the --with-online-update-mar-serverurl configure option is gone for good again.) The remaining changes are similar to what was needed in 28bad382face10be75af3875e44dde89fbc78108 "Fix `make create-update-info` (for Windows, at least)". (And the mbsdiff and mar tools expect Windows-style pathnames, but mktemp returns a Unix-style pathname in cygwin shell scripts, so this needed an additional Windows-only external/onlineupdate/cygpath.patch.) Change-Id: I40690210d62e3f26fb2d574914a0dd4323e6cd62 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161924 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-11Make create-update-info handle conditional contentStephan Bergmann
That make target operates on an archive, but generates data to be applied to an msi installation, so suffers from any mismatch between archive and msi install sets. Two such mismatches, at least on Windows, are: 1 Files that msi will install outside the LibreOffice installation itself (but which for an archive install set are included under LibreOffice/). This covers (at least) .Net assemblies and associated files that are installed in the GAC (scp2 styles ASSEMBLY and ASSIGNCOMPONENT) and fonts (scp2 style FONT). 2 Files that msi will only install conditionally. This covers optional components (many of which in scp2 are assigned to gid_Module_Optional_... modules) and user interface languages (which in scp2 are assigned to gid_Module_Langpack_... modules). The approach taken here is to create a workdir/installation/LibreOffice/archive/install/metadata file while building an archive install set, and to record any files matching 1 (as "skip" lines) or 2 (as "cond" lines). Then, the create-update-info target uses that metadata file to act accordingly on those files: 1 Files from "skip" lines are simply removed for now from the extracted archive that is passed to Mozilla's make_full_update.sh script. (TODO: That means that changes to such files will not be updated with the MAR update mechanism. This would apparently need some extra processing during the MAR update.) 2 Files from "cond" lines shall be recorded as add-if in the mar file manifest. Mozilla's make_full_update.sh script already has support for emitting add-if vs. plain add, but only for files under distribution/extensions/, which doesn't match our needs. So we generate from the metadata file an ifs file that we pass into the make_full_update.sh script, and patch that script to also take that ifs file into account. (Each line in the ifs file is of the form "testfile" "file" which works as long as none of the pathnames contains double quote characters. The Mozilla script code appears to be confused about the arguments to make_add_instruction(), where this ifs file will be needed: There are calls to make_add_instruction() with two or three arguments across make_full_update.sh and make_incremental_update.sh, but make_add_instruction() checks $1, $2, and $4 (but not $3), so leave that mess alone and pass the ifs file as a global IFSFILE variable instead.) The mar file manifest `add-if "testfile" "file"` adds "file" only if "testfile" is already present, and those two can be different files. TODO: However, for simplicity, for now I always use "file" also as the "testfile" (so that an add-if file only gets updated if it was already present). That avoids having to identify a specific "key file" for each optional component and for each user interface language, where that key file would be used as the add-if testfile. But on the other hand, it means that if an optional component or a user interface language will bring along a completely new file in the future, we will not install that file during a MAR update. What obviously remains to be done is to properly assign each add-if file to a specific key file. (And the current way of identifying add-if files by gid_Module_... names appears to be too simplistic too. For example, there are some gid_Module_Optional_... that are installed unconditionally for msi; but it should be harmless that those files are recorded as add-if rather than as plain add.) Change-Id: I2fdeed92604f3a2d8a0b500b9e3fa421cfb6a9cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161917 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-09New UBSan failure with Firebird 3.0.11Stephan Bergmann
While building ExternalProject_firebird: > workdir/UnpackedTarball/firebird/temp/Debug/jrd/scl.cpp:1171:38: runtime error: member access within null pointer of type 'const SecurityClass' Change-Id: I7f20495879da9b64a18ba8bd8673c42da8b483af Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161833 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-09external/firebird: Reinstate UBSan function-type-mismatch fixStephan Bergmann
...that had erroneously been removed by 00eae23267bf64e07cf057f828cd85f3c38ac669 "tdf#134526 Firebird: upgrade to release 3.0.11", causing > workdir/UnpackedTarball/firebird/src/intl/cs_icu.cpp:66:30: runtime error: call to function ucnv_fromUChars_73 through pointer to incorrect function type 'int (*)(UConverter *, char *, int, const unsigned short *, int, UErrorCode *)' > workdir/UnpackedTarball/icu/source/common/ucnv.cpp:1727: note: ucnv_fromUChars_73 defined here etc. to reappear that had originally been fixed with 8336c1b579b6dff361e5422ebcdd225056752ed4 "New UBSan failures with Firebird 3.0.7". Which then leads to the valid build failure > workdir/UnpackedTarball/firebird/src/common/unicode_util.cpp:1381:25: error: no matching constructor for initialization of 'const Array<USHORT>' (aka 'const Array<unsigned short>') > 1381 | const Array<USHORT> str(strChars, prefixLen); > | ^ ~~~~~~~~~~~~~~~~~~~ so include a fix for that. Change-Id: I30436b62d3adca511aa929317ac9cb7f31576382 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161832 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-08mold: fatal: cannot open loader_path/../Debug/firebirdCaolán McNamara
follow the pattern seen in builds/posix/Makefile.in and only set the offending LINK_DARWIN_RPATH var if PLATFORM is DARWIN Change-Id: I98861d2c07ab60ba92d092143b5b24de29d6c1da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161775 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-07firebird: set -mmacosx-version-min to 10.15Caolán McNamara
Building on macOS Sonoma fails when this flag is set to 10.9 or is unset. But setting this flag to 10.15 which matches the lowest -mmacosx-version-min that LibreOffice builds with on Mac Intel avoids all of the new deprecation warnings that turn into errors that started with Xcode 14. Also, fix runtime failure, at least on macOS, when the firebird build runs the isql command by adding $(firebird_BUILDDIR)/lib to LIBO_TUNNEL_LIBRARY_PATH. Change-Id: Id77d2949f56ecc63dfb085f762acf2c1cc081060 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161727 Tested-by: Jenkins Reviewed-by: Patrick Luby <plubius@libreoffice.org> Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-06cid#1546421 COPY_INSTEAD_OF_MOVECaolán McNamara
Change-Id: Ifab2f2f5ec8c7f41cd705e0fb07d1273a34b879d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161724 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-06cid#1545475 COPY_INSTEAD_OF_MOVECaolán McNamara
and cid#1545626 COPY_INSTEAD_OF_MOVE cid#1546203 COPY_INSTEAD_OF_MOVE Change-Id: I98a6c36e77fe633d50fdb1a0f063b2656f852a2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161718 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-06tdf#134526 Firebird: upgrade to release 3.0.11Taichi Haradaguchi
- Removed unneeded patches [1][2][3][4]. - No changes of ODS version. - Added patch to revert upstream commits to avoid CppunitTest_dbaccess_firebird_test, CppunitTest_dbaccess_hsql_binary_import, CppunitTest_dbaccess_tdf119625 and CppunitTest_dbaccess_tdf126268 failing when building on Windows. [1] "extern/cloop: Missing dependencies of compilations on output directories" <https://github.com/FirebirdSQL/firebird/pull/6948> [2] "Fix checks for null HANDLE in Windows-only code" <https://github.com/FirebirdSQL/firebird/pull/301> [3] "Fix warning on Win64 build" <https://github.com/FirebirdSQL/firebird/pull/231> [4] "Mac sandbox" <https://github.com/FirebirdSQL/firebird/pull/308> Change-Id: I17aa4938e41bfc070317fbb92ccea10f2db4d24d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152016 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-01-05external/lxml: Silence -Wincompatible-function-pointer-typesStephan Bergmann
...with Clang since <https://github.com/llvm/llvm-project/commit/af01f717c48f0fd2481600ed6c00441763365b62> "Default implicit function pointer conversions diagnostic to be an error", causing > src/lxml/etree.c:113121:38: error: incompatible function pointer types assigning to 'xmlStructuredErrorFunc' (aka 'void (*)(void *, const struct _xmlError *)') from 'void (void *, xmlError *)' (aka 'void (void *, struct _xmlError *)') [-Wincompatible-function-pointer-types] > 113121 | __pyx_v_self->_c_ctxt->sax->serror = __pyx_f_4lxml_5etree__receiveParserError; > | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/lxml/etree.c:117609:25: error: incompatible function pointer types assigning to 'xmlStructuredErrorFunc' (aka 'void (*)(void *, const struct _xmlError *)') from 'void (void *, xmlError *)' (aka 'void (void *, struct _xmlError *)') [-Wincompatible-function-pointer-types] > 117609 | __pyx_v_sax->serror = __pyx_f_4lxml_5etree__receiveParserError; > | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/lxml/etree.c:181693:28: error: incompatible function pointer types assigning to 'xmlStructuredErrorFunc' (aka 'void (*)(void *, const struct _xmlError *)') from 'void (void *, xmlError *)' (aka 'void (void *, struct _xmlError *)') [-Wincompatible-function-pointer-types] > 181693 | __pyx_v_xpathCtxt->error = __pyx_f_4lxml_5etree__receiveXPathError; > | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/lxml/etree.c:218967:60: error: incompatible function pointer types passing 'void (void *, xmlError *)' (aka 'void (void *, struct _xmlError *)') to parameter of type 'xmlStructuredErrorFunc' (aka 'void (*)(void *, const struct _xmlError *)') [-Wincompatible-function-pointer-types] > 218967 | xmlRelaxNGSetParserStructuredErrors(__pyx_v_parser_ctxt, __pyx_f_4lxml_5etree__receiveError, ((void *)__pyx_v_self->__pyx_base._error_log)); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > workdir/UnpackedTarball/libxml2/include/libxml/relaxng.h:156:30: note: passing argument to parameter 'serror' here > 156 | xmlStructuredErrorFunc serror, > | ^ > src/lxml/etree.c:219385:60: error: incompatible function pointer types passing 'void (void *, xmlError *)' (aka 'void (void *, struct _xmlError *)') to parameter of type 'xmlStructuredErrorFunc' (aka 'void (*)(void *, const struct _xmlError *)') [-Wincompatible-function-pointer-types] > 219385 | xmlRelaxNGSetValidStructuredErrors(__pyx_v_valid_ctxt, __pyx_f_4lxml_5etree__receiveError, ((void *)__pyx_v_self->__pyx_base._error_log)); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > workdir/UnpackedTarball/libxml2/include/libxml/relaxng.h:185:31: note: passing argument to parameter 'serror' here > 185 | xmlStructuredErrorFunc serror, void *ctx); > | ^ > src/lxml/etree.c:220274:59: error: incompatible function pointer types passing 'void (void *, xmlError *)' (aka 'void (void *, struct _xmlError *)') to parameter of type 'xmlStructuredErrorFunc' (aka 'void (*)(void *, const struct _xmlError *)') [-Wincompatible-function-pointer-types] > 220274 | xmlSchemaSetParserStructuredErrors(__pyx_v_parser_ctxt, __pyx_f_4lxml_5etree__receiveError, ((void *)__pyx_v_self->__pyx_base._error_log)); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > workdir/UnpackedTarball/libxml2/include/libxml/xmlschemas.h:156:30: note: passing argument to parameter 'serror' here > 156 | xmlStructuredErrorFunc serror, > | ^ > src/lxml/etree.c:220817:59: error: incompatible function pointer types passing 'void (void *, xmlError *)' (aka 'void (void *, struct _xmlError *)') to parameter of type 'xmlStructuredErrorFunc' (aka 'void (*)(void *, const struct _xmlError *)') [-Wincompatible-function-pointer-types] > 220817 | xmlSchemaSetValidStructuredErrors(__pyx_v_valid_ctxt, __pyx_f_4lxml_5etree__receiveError, ((void *)__pyx_v_self->__pyx_base._error_log)); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > workdir/UnpackedTarball/libxml2/include/libxml/xmlschemas.h:185:30: note: passing argument to parameter 'serror' here > 185 | xmlStructuredErrorFunc serror, > | ^ > src/lxml/etree.c:221582:66: error: incompatible function pointer types passing 'void (void *, xmlError *)' (aka 'void (void *, struct _xmlError *)') to parameter of type 'xmlStructuredErrorFunc' (aka 'void (*)(void *, const struct _xmlError *)') [-Wincompatible-function-pointer-types] > 221582 | xmlSchemaSetValidStructuredErrors(__pyx_v_self->_valid_ctxt, __pyx_f_4lxml_5etree__receiveError, ((void *)__pyx_v_error_log)); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > workdir/UnpackedTarball/libxml2/include/libxml/xmlschemas.h:185:30: note: passing argument to parameter 'serror' here > 185 | xmlStructuredErrorFunc serror, > | ^ > src/lxml/etree.c:222759:63: error: incompatible function pointer types passing 'void (void *, xmlError *)' (aka 'void (void *, struct _xmlError *)') to parameter of type 'xmlStructuredErrorFunc' (aka 'void (*)(void *, const struct _xmlError *)') [-Wincompatible-function-pointer-types] > 222759 | xmlSchematronSetValidStructuredErrors(__pyx_v_valid_ctxt, __pyx_f_4lxml_5etree__receiveError, ((void *)__pyx_v_self->__pyx_base._error_log)); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > workdir/UnpackedTarball/libxml2/include/libxml/schematron.h:106:31: note: passing argument to parameter 'serror' here > 106 | xmlStructuredErrorFunc serror, > | ^ Change-Id: I98d1861acfe364d8f83aaca26100dc2c9729ec33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161669 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-05Introduce external/onlineupdate/monitor-sources.shStephan Bergmann
...to: "Monitor any changes in upstream git repo $1 between revisions $2 and $3 that affect files that we copy with our external/onlineupdate/generate-sources.sh" (and while at it add license boilerplate and a descriptive comment to external/onlineupdate/generate-sources.sh) Change-Id: I2872d04c2db9d3a7226a9e744d84367ae7aa8672 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161665 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
generated by cgit (git 2.34.1) at 2025-01-17 03:42:54 +0000