summaryrefslogtreecommitdiff
path: root/external
AgeCommit message (Collapse)Author
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>
2024-01-05Workaround for --disable-windows-build-signing --enable-dbgutil test buildsStephan Bergmann
Change-Id: I8c14cfafd39b8575a5e1e236f965283718777416 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161663 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-05Fix `make create-update-info` (for Windows, at least)Stephan Bergmann
* The shell scripts that had once been copied from Mozilla to bin/update/*.sh are now included in onlineupdate-c003be8b9727672e7d30972983b375f4c200233f-2.tar.xz (which is still generated from the same <https://github.com/mozilla/gecko-dev/commit/c003be8b9727672e7d30972983b375f4c200233f> that was used for the original tarball in 3a445cb49795fabe0d8caaf12bfc38eb9e12d5fc "Turn onlineupdate into external/onlineupdate"). * The additional modifications in external/onlineupdate/lo.patch are: ** Allowing to pass the list of files into the mar tool via -f instead of on the command line, to avoid "command line too long" errors on Windows, inspired by the modifications once made directly in our old downstream sources with 4165dd4e465a86ba6abe9afb3abfda5ef72493ea "add a way to create mar file from file", 8e4d49340bd235a7db8fde1d24dd1d63ddc4d571 "use the new file based approach for the mar creation", and fb13ed6955cd66017e5348b915af371a184ea633 "add the manifest file to the mar file". (To keep things simple for now, it still uses a hard-coded maximum of 10000 lines in the file, marked with a TODO.) ** Not failing when "precomplete file is missing!" (There is a comment // Applications aren't required to have a precomplete manifest. The mar // generation scripts enforce the presence of a precomplete manifest. in workdir/UnpackedTarball/onlineupdate/onlineupdate/source/update/updater/updater.cpp and it appears to be OK that we don't have such a precomplete manifest file and just skip that test.) * In the Makefile.gbuild create-update-info, the create_full_mar.py script needs to be called with a Unix pathname on Windows, or else the #!/usr/bin/env python3 shebang in that script would get confused. * The related Makefile.gbuild targets upload-update-info and create-partial-info have not been addressed yet. Change-Id: Iab4e083ddbe99e07d846e202f20c6031e2983e1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161656 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-05upgrade libxml2, libxslt & liblangtagCaolán McNamara
what I'm really after is some vexating not-reproducible oss-fuzz msan warnings when using libxml2 in the fodt2pdf fuzzer. So lets upgrade libxml2 to the latest, which requires bumping libxslt, and then requires a newer liblangtag because of no longer implicit includes that it depended on. xmlKeepBlanksDefaultValue and xmlSubstituteEntitiesDefault are deprecated, we should get around to updating those uses Change-Id: I8fda0dffda0a7ea65407d246a3121875cb8ad4a4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161598 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-05argon2: build opt.c again for WNT X86_64Michael Stahl
Commit 401e9408d14dc2b9d07183a04c223831a59f71a3 replaced opt.c with ref.c also for X86_64, which was probably not intended; apply patch only when needed. Change-Id: Ie7ca7b88751fb2d7de4d1a27e81c7f60a98359f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161629 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-01-03libexttextcat: package newer language modulesMiklos Vajna
Fixes warnings like these: Failed to open fingerprint file '/home/vmiklos/git/libreoffice/core-clang/instdir/program/../share/fingerprint/ilo.lm' Failed to open fingerprint file '/home/vmiklos/git/libreoffice/core-clang/instdir/program/../share/fingerprint/skr.lm' Change-Id: Ic3e5951707a3b6935edc51ee41d726e35d71bab0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161586 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-01-02Re-enable MOZ_VERIFY_MAR_SIGNATURE featureStephan Bergmann
...that 3a445cb49795fabe0d8caaf12bfc38eb9e12d5fc "Turn onlineupdate into external/onlineupdate" had accidentally turned off Change-Id: I345d02a305a33fc641566d122c8cdb55c09599a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161546 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-02cid#1545836 COPY_INSTEAD_OF_MOVECaolán McNamara
Change-Id: Idb754296175f786c7850253749e3b7f968aa87fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161525 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-30cid#1546460 COPY_INSTEAD_OF_MOVECaolán McNamara
Change-Id: I562eea9548929f11de2a2b68bba09ae3a777ffe3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161456 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-30tdf#77915 fix import of default shape fill colorAndras Timar
Change-Id: Ibbb1ec508dcd87512b4f4b6da8729255c7ed9fb0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161396 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2023-12-24zxcvbn-c: disable warningsThorsten Behrens
Change-Id: I348dc5f92f41fc3e8c1aee8743d5e1cf86fa3bbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161259 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-12-23tdf#105844 argon2: add vcxproj files for WinARM64 buildsThorsten Behrens
Also add argon2 to crossbuild tools side. Change-Id: I8704b2d8362a051c2d634b9db7416cdc2cf9add4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161206 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-12-23zxing-cpp: upgrade to release 2.2.1Taichi Haradaguchi
* remove 0001-android-Fix-build-with-NDK-26.patch, which was merged upstream. * remove DecodeHints from static lib, which according to upstream is not needed: https://github.com/zxing-cpp/zxing-cpp/issues/685#issuecomment-1853375179 * add a version header for client code generate/update via: * mkdir build && cd build && cmake .. * mv core/ZXVersion.h ../core/src/ Release Notes: https://github.com/zxing-cpp/zxing-cpp/releases/tag/v2.2.1 Change-Id: Ic4811d4724970c984dd9ed3d59b5204c18aafc6d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160528 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-12-22Fix Windows MSI custom action for --enable-online-update-marStephan Bergmann
The install/uninstall actions need to be type 3137 to run privileged, which means that they must be placed within certain limits (e.g., not at "end") and that they cannot access INSTALLLOCATION (so need an additional un-privileged prepare action to forward that value). Plus, the call to CreateProcessW was passing arguments in a completely wrong way. And then some clean-up. Change-Id: I5b5f338da08931e48653f282cc9fa7b00955fea6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161191 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-12-21Windows MSI custom action for --enable-online-update-marStephan Bergmann
...which needs to call update_service.exe with "install" (resp. "uninstall") and needs to create (resp. delete) a registry entry containing the issuer and name of the certificate with which the updater.exe is signed (which is required by one of the many sanity and security checks performed by update_service.exe before it will actually do an automatic update). (The issuer and name of the certificate are for now hardcoded to the values used by TDF when signing its Windows builds.) (gid_Customaction_uninstall_updateservice needs to run rather early, when update_service.exe has not yet been removed, so I rather randomly picked "MigrateFeatureStates" as the point where to run it.) Change-Id: I6e0f62ec3e51d74d4a526a490badc7c14ebe99ae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161125 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-12-21external/lcms2: fix lcms2-2.4-windows.patchTaichi Haradaguchi
fix typos and macros in code. Change-Id: I0886f3d95d87be70be1e7e6a220617f728fe6653 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161056 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2023-12-20tdf#105844 offapi,package,sfx2: use Argon2 for wholesome ODF encryptionMichael Stahl
https://www.rfc-editor.org/rfc/rfc9106.html * add css::xml::crypto::KDFID constant group * add "KeyDerivationFunction" to setEncryptionAlgorithms sequence * Argon2 is used by default for wholesome ODF encryption, but $LO_ARGON2_DISABLE can be set to use PBKDF2 * extend various structs in package * use 3 new ODF attributes "loext:argon2-iterations" "loext:argon2-memory" "loext:argon2-lanes" to store the arguments * use this URL for now: "urn:org:documentfoundation:names:experimental:office:manifest:argon2id" * use default arguments according to second recommendation from "7.4. Recommendations" of RFC9106; 64 MiB RAM should hopefully not be too much even for 32 bit builds Change-Id: I683118cc5e0706bd6544db6fb909096768ac9920 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161009 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-12-20ofz#65182 putcontig8bitYCbCr22tile issueCaolán McNamara
Change-Id: I0242059b17d07c0ab4ec83aabd073ee31c4631d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161031 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-20argon2: oops, forgot to build static lib with -fPICMichael Stahl
... and Julien Nabet reports that Debian's default shell dash doesn't have "time", oddly enough. Change-Id: I82734bdf9e943522471c4c9189fac463bca2a3aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161008 Reviewed-by: René Engelhard <rene@debian.org> Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-12-19Improve --enable-online-update-mar Windows MOZ_MAINTENANCE_SERVICE featureStephan Bergmann
To get the MOZ_MAINTENANCE_SERVICE mode going at all, update.status needs to contain a "pending-service" token. For Mozilla, code in its toolkit/mozapps/update/UpdateService.sys.mjs takes care of writing that. For us, lets always write that in update_checker() (even on Linux, where it's apparently harmless). Then, the MOZ_MAINTENANCE_SERVICE code is rather picky with its various sanity checks: Among other things, it expects argv[0] to be a full path to the updater executable, and it expects the update.mar (and its status and log files) to be in a directory hierarchy named updates/0/ rather than patch/. So get all that fixed in desktop/source/app/updater.cxx. And patch in external/onlineupdate/lo.patch where it expects to find the updater executable (just updater.exe vs. our program/updater.exe). And we shouldn't interfere with the upstream Mozilla maintenance service, so also rename that in external/onlineupdate/lo.patch. And `update_service install` wants to read version resources from the update_service.exe, so provide that (via gb_Executable_add_default_nativeres). Also, `update_service install` wants to read a MozillaMaintenanceDescription value from an updater.ini, so provide one (with contents of that value inspired by Mozilla's browser/locales/en-US/updater/updater.ini). As we now have an updater.ini anyway (and which apparently works fine with Unix line ends on both Linux and Windows), also use it on Linux and drop the onlineupdate/source/update/updater/progressui_gtk.cpp again from external/onlineupdate/lo.patch. And update external/onlineupdate/README.md how to manually execute that test against an updater.ini. Change-Id: I0e3e5e5311be61e1224cda700af2e5d751113a99 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160996 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-12-19argon2: add new external libraryMichael Stahl
Change-Id: I81860a94b33eba95918c30b0e92b583cc2d02ff3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160969 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-12-18fix system-abseil build even with 2022 versionRene Engelhard
actually it seems it was a internal abseil header from pdfium vs. system header mismatch. Include proper absl/container/inlined_vector.h if using system-abseil. While at it we can also just use pkg-config, no idea why I did it without back then. Also gets the advantage that it knows that the libs needed for absl_inlined_vector is actually -labsl_throw_delegate -labsl_raw_logging_internal -labsl_log_severity This effectively reverts e89723103313ec4366ee58144c47d7a5c16bf838 Change-Id: Ide4f79860b4e0673c5c6587d503058bdd2930744 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160846 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
generated by cgit (git 2.34.1) at 2025-01-17 08:53:14 +0000