* Updated README.md contents to fix various issues
* Fixed source links by using [git:], processed by mkdocs scripts
* Added README.md for ios, setup_native, unotest
* Fixed issues with "underline" and "less than" sign
Change-Id: I3e52a1d3372586c390ee6c42a2ef48bbabc81398
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114248
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
kMDItemDisplayName has different values depending on the setting whether
to show extensions for all filetypes in Finder, breaking the
detection/validation of the installation target in case the user doesn't
use the default setting.
Change-Id: Ic9605abaaa1f070f1f5ec9940190fd1dd2555bdf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110479
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
OOODOWNLOADNAME was set in the global section of openoffice.lst, so the
code always did set the target path with set_download_filename. Thus
remove the superfluous sub and then also the no longer used
OOODOWNLOADNAME variables
In the same vein: the "script that extracts a tarball that is appended
to it" method is no longer in use since many years, delete that as well.
Change-Id: I43481a3ec09e064ef77138e1cbfc1dba6854f2d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110017
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.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>
Signing them as executable code would require external attributes, and
those in turn break packaging into hfs+ dmg when building on apfs with
Big Sur.
It is not a new thing - the old Code Signing in Depth technote
https://developer.apple.com/library/archive/technotes/tn2206/_index.html
already reads:
"Store Python, Perl, shell, and other script files and other non-Mach-O
executables in your app's Contents/Resources directory. While it's
possible to sign such executables and store them in Contents/MacOS, this
is not recommended.
[…]
Put another way, a properly-signed app that has all of its files in the
correct places will not contain any signatures stored as extended
attributes."
The patch does exactly that for LO and the shipped python framework and
adds symlinks for the moved files.
Same applies for the Language pack applescript and the tarball - those
are also moved into Contents/Resources
Change-Id: Iab21e77b73f941248ca89c6e80703fdf67a1057c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109537
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
> 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>
For cases when there are multiple matching apps where the Languagepack
might be installed to, the "make sure to launch LO once before
installing the langpack" mechanism can fail.
Even if it is the call "tell application <selection> to activate" that
fails, the error handler assumes that the untar operation didn't work
and suggests to retry with admin privileges, modifying the .app bundle
before having it started once (AKA verified by gatekeeper), breaking
the app.
Passing the full path to the application object should fix that.
Change-Id: I47d61ad68e225fbdba191702ba85598164602e81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96449
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
I think this is leftover from very early development stages when it
didn't have placeholders, but literal OpenOffice or similar at the time.
Not matching for wildcard but for full LibreOffice/LibreOfficeDev string
makes removing the languagepacks from the match superfluous
It was wrong anyway, since kMDItemDisplayName has the name without the
.app extension (you'd have to use _kMDItemDisplayNameWithExtensions for
that)
Change-Id: I37b1ed2d23ea18fd81a8844f35c9cb0d5dc34211
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96441
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
3a02841819 removed the string from
Info.plist, but the languagepack install script tried to use that to
make sure whatever the user selects/is found is from the dame type (dev
vs release and codeline/version). Instead of doing multiple
greps/multiline ones (there are multiple version strings in that file,
only one being from LO itself…) use mdls instead to pick the interesting
properties to build a "PRODUCTNAME FULLVERSION" string again we can
match against. --raw switch is nul separated, so add additional xargs -0
in there instead of trying to match a nul with grep
(without --raw it is a nice human readable multiline string)
Change-Id: I049a8425709a0c41b61aa09452490b481d39e4d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96439
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.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>
This registers SharePoint integration libraries using regsvr.exe.
Both 32-bit and 64-bit libraries are registered; registration of
LOSPSupport.OpenDocuments is unconditional.
This introduces a new hidden MSI feature, which is disabled for
installation: gm_SharePointSupport_SubstMSO. When installed, it
registers SharePoint.OpenDocuments class in registry, thus
overriding registration of this component by MS Office, allowing
LibreOffice to serve as MS Office replacement working in IE with
SharePoint. To install the feature, either a transform is needed
setting the feature's level <= 100, or a command line:
msiexec path-to-msi ADDLOCAL=gm_SharePointSupport_SubstMSO
Change-Id: I5517bbb68dcc6db8bcb2bbc2368394ee4a62d741
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86452
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
For Windows SDK 8.1 HRESULT_FROM_WIN32 is defined as an inline
function without the constexpr, which is required for case statement
inside a switch.
Change-Id: Ibb195ef900926d87ff04f82a6d73112b8858f633
Reviewed-on: https://gerrit.libreoffice.org/75111
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Things break without OpenSymbol font. On the other hand, if you
install just the fonts, but not anything else, you can happily use
the fonts in other applications. So just invert the dependency.
Change-Id: I4c2dbff59699365cba67d3b1c6ade5ec7c2462bf
Reviewed-on: https://gerrit.libreoffice.org/71898
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
It seems that wusa.exe would fail with error code 0x80080005
if launched too soon after WU service was sent a stop control
(which was added in tdf#123832).
Change-Id: I470a8a8e933e8a0cd6208c095ed63c1761b3b434
Reviewed-on: https://gerrit.libreoffice.org/71045
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
We don't need the dynamic load complexity for these now with baseline
Windows version being Windows 7 SP1. Stuff used only for compatibility
with older versions was dumped.
Change-Id: I810f271796cfd875cfa18a3081c9ad444fe57b3e
Reviewed-on: https://gerrit.libreoffice.org/70321
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The code is using expicit (mostly W) Windows API, and is independent
from the macro. Removing it here allows to catch places where some
UNICODE-dependent macro is used unintentionally.
Change-Id: I5dff40aecfc3c3dc7fc4cf7271a995a675943a45
Reviewed-on: https://gerrit.libreoffice.org/70237
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
V575 The potential null pointer is passed into 'foo' function
Add asserts to those cases that are related to OOM cases. There's
nothing to be done if the assertions fail anyway.
Change-Id: I92ac95d44f512aa1948b1552b0e1f6da695a9f92
Reviewed-on: https://gerrit.libreoffice.org/70008
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reportedly under some circumstances execution of wusa.exe may hang
for very long time (available logs show more than 90 min). LO MSI
installer waits for wusa.exe indefinitely in its deferred inst_msu
custom action; during this wait, one can't abort the installation.
There is an evidence [1] that stopping WU service prior to wusa
launch might prevent this hang.
The patch does two things:
1. It stops running WU service prior to wusa launch.
2. It adds a check for user input by executing MsiProcessMessage
twice a second, and checking its return value, to allow early
return in case user cancels the installation.
This is a blind shot, since I cannot reproduce the problem myself.
[1] https://superuser.com/questions/1044528/
Change-Id: I8bf4ce52b3e9d98a4f90af3abcc49ac63b6a0e40
Reviewed-on: https://gerrit.libreoffice.org/69487
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
This replaces commit 53058090be. Now
not only failure to start WU service, but also other errors during
MSU installation won't break installation. E.g., running WU service
as Guest does not prevent the service from starting; but installing
updates fail, which makes previous solution incomplete.
Instead, show a warning in those rare cases when an error happens,
and continue. It will allow users to see the reason if they see
"api-ms-win-*.dll missing" message later after installation. Of
course, some small percentage of these warnings will be false, e.g.
those on Windows 10. But those false messages must be really small
minority, because only when (1) the installation fails (2) on a
system with the component already present, such a message would be
false. And it will not prevent the installation.
This will not block unattended installations, since in those cases,
MsiProcessMessage() will do nothing.
Change-Id: I3a9e681e9d6701d092bd5c18bb4b68b4f77170f3
Reviewed-on: https://gerrit.libreoffice.org/64874
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Andras Timar