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>
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>
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>
Some scripts in which it was used have been removed
(commit e1082e4536) and
the more reliable 'fakeroot' is now in use at all
other places where libgetuid.so was previously used
(s. tdf#115554).
Change-Id: I638e96e5c8d671e3b145b79f33de718fe34ea514
Reviewed-on: https://gerrit.libreoffice.org/49837
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
These scripts were never shipped to end users (the corresponding
install_linux.sh was only added to the instset in LO times,
see 117b3242db) but were used
by QA and developers to install multiple Solaris builds
as non-root using getuid.so.
But the "archive" installation set can be used for the
same purpopse and doesn't require a custom script.
Change-Id: I665277bef7c5ddd58e798f5f1b1c6a97a0f3cfc5
Check for a macro that is defined by the compiler, we don't really need
one defined by the build system.
Change-Id: Iccb8e3198396881395c97a6b81690ebe64b7e9d2
starting LO once satisfies Gatekeeper's verification, even when the
langaugepack's content are added afterwards
Change-Id: Ie548df39a7ec07cc485c40148e4ca75101346798
LO only scans for new extensions when the folder's timestamp is newer
than a timestamp file in the user's profile. When installing a
languagepack, the folder is set to the build-time of the package. touch
the dir to set it to install time and thus allow LO to pick up newly
installed dictionaries and thesaurus/hyphenation data.
Change-Id: I888f830d2325774cd98e3624c19d2be19d4d6db2
- update.sh is broken by design (i#116865)
- javaloader.sh belongs to the obsolete Java GUI installer
- admin.pl is not used by the build and is possibly useful
Change-Id: I5e4c43b09a1726075e6d5ddd85cae6109788e51e
This can be the case when spotlight is disabled. So just ignore any
error when trying to locate installed versions and let the user continue
with the manual selection instead of aborting.
Change-Id: I2c4e12652b8cb3b43af3ca6d8d553f0558f91858
Reviewed-on: https://gerrit.libreoffice.org/5069
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
1) Hide rpm database dir like the old Java installer GUI did, so the
user sees a single /opt directory only, like with dev-install.
2) Allow installing to an existing directory, no reason not to allow this.
3) Use --nodeps when using a custom dbpath, since in that case even
/bin/sh won't be provided by anything.
Change-Id: I70d74cc5db287668f4c926005001e05096f43a10
Now that 5c47e5f63a "fdo#51252 Disable copying
share/prereg/bundled to avoid startup crashes" removed the use of share/prereg,
there is no longer need to generate it in the first place (by calling "unopkg
sync" at build or installation time), and so no need for the "unopkg sync" sub-
command, either. This also allows to simplify some of the jvmfwk code that was
only there so that "unopkg sync" (which can require a JVM) can work in "hostile"
environments (during build and installation).
Change-Id: I52657384f4561bf27948ba4f0f88f4498e90987f
* The updatecheckui lib is part of that module; should its scp entry also be
marked ComponentCondition="ISCHECKFORPRODUCTUPDATES=1"?
* unpack_update (and other scripts as well?) need only be generated if
ENABLE_ONLINE_UPDATE.
* It is inconsistent that there is a distinct onlineupdate.xcd not merged into
main.xcd, while the updchk and updatecheckui component files are merged into
the global services.rdb.
* The updchk res file should also go into (a resource sub-module of) the
optional online update module.
Ilmari Lauhakangas