There is no point to bundle it, because
1) it is an old version
2) since LibreOffice 7.5 there are built-in number formats in
Calc with the same functionality (using libnumbertext FWIW)
Change-Id: I8cfb24f7e6f045bd51fea620aca6a61269dba77a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180996
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
There is no simple "Windows is 10 or newer" check in MSI, with the
Microsoft policy of "you don't need to know real Windows version".
See also https://developercommunity.visualstudio.com/t/detect-a-windows-version-from-msi/412198
The values that MSI sees (e.g. on my Win11) are:
Property(C): VersionNT = 603
Property(C): VersionNT64 = 603
Property(C): WindowsBuild = 9600
So those can't be used for the check. I use the WINMAJORVER that is
read from registry (Software\Microsoft\Windows NT\CurrentVersion).
There is no more need to check and install UCRT; it was dropped.
Change-Id: Ic02d6aeb965e9684bafd4357f969980f77000e73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178049
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(Thanks to Mike Kaganski for noticing the gotcha here that a naive replacement
with
> std::wstring(const wstring& str, size_type pos)
would do something rather different than
> std::wstring(const wchar_t* s, size_type n)
does.)
Change-Id: I78837c014cdc154f276db1a11a87aaf74319a9fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159114
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
These routines can fail during MSI installation
(seen leftover program_old folders, with program folder missing).
We at least want to see the error in the MSI log file when this doesn't succeed.
This outputs error messages like:
MSI (s) (C4:5C) [10:47:54:280]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI37B4.tmp, Entrypoint: RemovePrgFolder
CustomAction RemovePrgFolder returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 10:47:54: RemovePrgFolder. Return value 3.
Change-Id: I4ce4099eeb3e0ee79eb4a2e1d3887f9810fd9669
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134160
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Do not bundle LanguageTool which is at a 10 year old version (1.7)
while upstream has a lot of new releases (now at version 5.5.x)
It is not bundled by any downstream distributions
so it makes no much sense to keep it integrated here.
Change-Id: Icd2ef151b1b8d0252ffa3db0caaba576f2783fa9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133356
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
...which defines NULL as a plain 0 integer literal instead of the GNU __null
extension, so clang-cl's -Wnull-conversion cannot kick in. These findings are
from an experimental build done with clang-cl and a modified
> --- a/clang/lib/Headers/stddef.h
> +++ b/clang/lib/Headers/stddef.h
> @@ -83,6 +83,10 @@ typedef __WCHAR_TYPE__ wchar_t;
> # if !defined(__MINGW32__) && !defined(_MSC_VER)
> # define NULL __null
> # else
> -# define NULL 0
> +# if __cplusplus >= 201103L
> +# define NULL nullptr
> +# else
> +# define NULL 0
> +# endif
> # endif
> #else
> # define NULL ((void*)0)
However, that build also ran into lots of places where 3rd-party code in
external/ and Windows system headers caused issues when NULL is nullptr (which
I worked around with various hacky patches for that build), so this is
unfortunately not something that can easily be enabled generally.
Change-Id: I10674464498a9bc63578d9e6cc32ddde23ab4f30
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124419
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
There had originally been some back-and-forth among
134ae5da1c "jl154 #162868# remove
basis/presets/bundled/bundled.ini, and create always share/extensions folder",
4c333e8ac7 "jl154 #162868# removing the
package.txt from the extensions folder. Extensions folder will be created in a
different way than installing a dummy file", and
8f4cf9a16e "jl154 #162868# guarantee existence of
extensions folder" whether or not that dummy file was necessary to ensure
creation of the (otherwise potentially empty) $(LIBO_SHARE_FOLDER)/extensions/
directory. That is no longer necessary with gb_Package_add_empty_directory
(though the logic that had to be added to setup_native/Package_packinfo.mk now
is a bit unfortunate, and will need to be updated whenever the list of potential
bundled extensions changes).
(And that dummy package.txt file is apparently not used to track whether per-
user extension information needs to be updated when the contents of
$(LIBO_SHARE_FOLDER)/extensions/ changes. That is rather done by
comparing the status of the $(LIBO_SHARE_FOLDER)/extensions/ directory itself
against user/extensions/bundled/lastsynchronized in the UserInstallation, see
needToSyncRepository in desktop/source/deployment/misc/dp_misc.cxx.)
Change-Id: I5b9956c508288945f32a88afaef57ac0b63dc27f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120081
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Annoyingly the packinfo_*.txt don't support conditionals but we can
work-around that with a little duplication.
Change-Id: Id00a6831effcc63a917fc21d2cd201474fdb559d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109569
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
> C:/lo/core/setup_native/source/win32/customactions/inst_msu/inst_msu.cxx(105): error C2660: '`anonymous-namespace'::WriteLogElem': function does not take 5 arguments
> C:/lo/core/setup_native/source/win32/customactions/inst_msu/inst_msu.cxx(83): note: see declaration of '`anonymous-namespace'::WriteLogElem'
> C:/lo/core/setup_native/source/win32/customactions/inst_msu/inst_msu.cxx(118): note: see reference to function template instantiation 'void `anonymous-namespace'::WriteLogElem<char,std::string>(MSIHANDLE,MSIHANDLE,std::ostringstream &,UINT,const Ch *,const std::string &)' being compiled
> with
> [
> Ch=char
> ]
> C:/lo/core/setup_native/source/win32/customactions/inst_msu/inst_msu.cxx(382): note: see reference to function template instantiation 'void `anonymous-namespace'::WriteLog<char[18],std::string>(MSIHANDLE,const char (&)[18],const std::string &)' being compiled
> C:/lo/core/setup_native/source/win32/customactions/inst_msu/inst_msu.cxx(105): error C2660: '`anonymous-namespace'::WriteLogElem': function does not take 6 arguments
> C:/lo/core/setup_native/source/win32/customactions/inst_msu/inst_msu.cxx(83): note: see declaration of '`anonymous-namespace'::WriteLogElem'
> C:/lo/core/setup_native/source/win32/customactions/inst_msu/inst_msu.cxx(118): note: see reference to function template instantiation 'void `anonymous-namespace'::WriteLogElem<char,std::string,char[6]>(MSIHANDLE,MSIHANDLE,std::ostringstream &,UINT,const Ch *,const std::string &,const char (&)[6])' being compiled
> with
> [
> Ch=char
> ]
> C:/lo/core/setup_native/source/win32/customactions/inst_msu/inst_msu.cxx(516): note: see reference to function template instantiation 'void `anonymous-namespace'::WriteLog<char[19],std::string,char[6]>(MSIHANDLE,const char (&)[19],const std::string &,const char (&)[6])' being compiled
and
> C:/lo/core/setup_native/source/win32/customactions/reg_dlls/reg_dlls.cxx(104): error C2660: '`anonymous-namespace'::WriteLogElem': function does not take 5 arguments
> C:/lo/core/setup_native/source/win32/customactions/reg_dlls/reg_dlls.cxx(82): note: see declaration of '`anonymous-namespace'::WriteLogElem'
> C:/lo/core/setup_native/source/win32/customactions/reg_dlls/reg_dlls.cxx(117): note: see reference to function template instantiation 'void `anonymous-namespace'::WriteLogElem<char,std::wstring>(MSIHANDLE,MSIHANDLE,std::ostringstream &,UINT,const Ch *,const std::wstring &)' being compiled
> with
> [
> Ch=char
> ]
> C:/lo/core/setup_native/source/win32/customactions/reg_dlls/reg_dlls.cxx(159): note: see reference to function template instantiation 'void `anonymous-namespace'::WriteLog<char[27],std::wstring>(MSIHANDLE,const char (&)[27],const std::wstring &)' being compiled
Change-Id: I7e8c121f8589ae847c9e4fd12e218408ea9e451e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108836
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
If user has a language set as user locale, and installer is shown in that
language, it's likely that that language is needed for installation.
Change-Id: I37fb959291262b772ec8e1b35c687d64e0ee76a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98612
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
* Label left-aligned (tdf#132322)
* Long build string cut at 25 chars
* Extra text such as Tinderbox info wraps now at Misc
* UI-Language shortened to just UI
* More padding between about image and text
* Splash screen uses Vegur font
* Splash with small border
* Non-TDF logos have a "Community Edition" text
Change-Id: I1ec31e22052e365f28fe91de3e083252975911c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93444
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
It used to be set both in AppSearch action (using RegLocator table),
and in MigrateInstallPath custom action. This would overwrite value
of INSTALLLOCATION taken from user, and read on the previous step,
with values taken on the next step.
Only migrating the install location in one single place - in custom
action MigrateInstallPath - makes the process controllable. Also it
allows to easily see all the various places in registry we read.
Change-Id: Ib7e04c26e71ba92c6a62a0511971bfb3bdb7db72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87867
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Since component ids change across major versions, install location
isn't kept automatically for major upgrades. Use OLDPRODUCTS property
set during FindRelatedProducts action (see Upgrade table created by
solenv/bin/modules/installer/windows/upgrade.pm). Read InstallLocation
in existing MigrateInstallPath custom action under
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\GUID, where
GUID is the value of OLDPRODUCTS.
This only reads registry hive for the current installer architecture
(32/64 bit), so that the other architecture installation path is not
taken into account when old version is of different architecture, to
avoid installing into wrong directory when e.g. upgrading from 32-bit
to 64-bit, so 64-bit program is not installed to Program Files (x86).
Change-Id: Ib9fa004818908a5706c5af040f1a5a36c03d2f36
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87844
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Xisco Fauli