Age | Commit message (Collapse) | Author |
|
... and move the OSX specific files there too so we don't need several
include paths.
Change-Id: I9368e12d4cf85da3795939b51540eaf7f5d0a7d3
|
|
Only shellscripts_module.txt actually used; the shellscripts_core01.txt
is apparently relic of 3-layer office days.
Change-Id: I37faa0bbe195574511c3af85db1beb15e8a2cda3
|
|
These dummy files were apparently added for i#73345 to prevent issues
from dpkg when some core-0[345] package was empty; these packages are
never empty nowadays.
Change-Id: I58f03677473a594f03a51d0440095bdf4a6ea3fd
|
|
Using advertised shortcuts -- inspired by Intel AppUp Centre's
requirement -- was not a good idea after all. I revert this,
and I also revert the commit that actually disabled it in
default Windows builds.
This reverts commit aa2450cb51cfc3805c7a596b6b89d70bb133821e.
This reverts commit b40012bd6d0b5387005253f1d3f03929ce4d1ac6.
|
|
...as per #libreoffice-dev IRC:
Sep 19 10:32:24 <mst__> sberg, moggi why the hell is that thing named
"cppunit/cppunittester" and inside a subdir? it's obstructing my attempt to
put it in $(INSTDIR)/program
Sep 19 10:33:28 <mst__> (... and if you wonder "wtf does it have to do with
INSTDIR" you have never heard of awesome LibreOffice_Test installset.... not
that i would know who needs it :)
Sep 19 10:36:36 <sberg> mst__, it is in a subdir of solver/*/bin so that on
Windows it would not accidentally have picked DLLs next to itself instead of
the module-local DLLs it was supposed to test (back when we had module-local
output trees)
Sep 19 10:37:02 <mst__> sberg, ahh hysteric reasons then, /me renames it
Sep 19 10:37:55 <tml> mst__, if nobody you know uses LibreOffice_Test, just kill
it?
Sep 19 10:38:59 <sberg> mst__, tml, LibreOffice_Test was conceived by pmladek
and/or kendy, IIRC
Sep 19 10:40:31 * kendy does not remember anything about it :-)
Sep 19 10:42:17 <sberg> wasn't that something so users (or QA people?) could
easily run the smoketest against an installation, to see whether the
installation is any good at all, by installing that LibreOffice_Test alongside
the installation proper?
Sep 19 10:43:26 <sberg> mst__, ...and I'd unscientifically vote to kill it
Sep 19 11:34:23 <pmladek> mst__, sberg: I have created the LibreOffice_Test
package for one QA guy. He does not longer work on LO. I am not sure if anyone
else started to use it. So, I think that it can be killed.
Oct 17 18:18:07 <tml_> sberg: have you ever noticed that when you try to
actually run instdir/unxmacxi/LibreOfficeDev.app , the system actually tries
to run cppunittester inside the app bundle (it says so in the crash report)
(it crashes because cppunittester requires a specialized DYLIB_LIBRARY_PATH
apparently)
Oct 17 18:19:29 <tml_> I suspect that the system when cppunittester as part of
the build process is run from inside instdir (i.e. inside an app bundle) the
system "caches" this false knowledge, and thinks that the executable of the
app bundle is cppunittester...
Oct 17 18:19:36 <sberg> tml_, no, never noticed; with "run
instdir/unxmacxi/LibreOfficeDev.app" you mean calling "open
instdir/unxmacxi/LibreOfficeDev.app"? (I always call
.app/Contenst/MacOS/program explicitly)
Oct 17 18:19:52 <tml_> yes, I mean "open instdir/..."
Oct 17 18:20:53 <tml_> some googling tells me that at least years ago, the
CFBundleExecutable key in the Info.plist is ignored if it is manually changed,
so I guess similar caching of mapping between an app bundle and which
executable to actually run happens in this case
Oct 17 18:23:17 <tml_> and last year somebody even claims "And while on Mountain
Lion, CFBundleExecutable seems to be a no-op", which would be odd, surely
there must be widely used apps that have several executables inside the MacOS
directory; how would the system know which one to run when the app is run?
Oct 17 18:24:38 <tml_> hmm, apparently the code that handles this might be open
source even, http://www.opensource.apple.com/source/CF/CF-744.18/CFBundle.c
Oct 17 18:25:52 <tml_> some mention of "caches" there yes, my guesses might be
right
Oct 17 18:27:05 <tml_> if I cp -R instdir/unxmacxi/LibreOffice.app foo.app and
open foo.app, it works fine
Oct 17 18:28:33 <tml_> anyway, I guess it would be cleaner to have cppunittester
somewhere else even without this problem
Oct 17 18:37:09 <sberg> tml_, yes, IIRC having cppunittester in instdir was a
misguided mst decision, because that odd LibreOffice_Test product (that
pmladek said nobody needs any longer anyway) includes it; I think consensus
was to kill LibreOffice_Test and move cppunittester where all the other NONE
executables are, but looks like nobody executed
Oct 17 18:37:55 <tml_> ah ok, so mst should know what needs to be done? good, no
need for me to try to hack this now then
Oct 17 18:38:19 <sberg> tml_, I'll do the cleanup tomorrow, unless somebody
beats me
This removes smoketest/losmoketest et al along with the *_Test product, as they
seem to not make sense without it anyway. smoketest/Executable_libtest.mk
appears to be a test that could also be run during the build, and only ended up
in the *_Test product by accident, so I left it untouched for now.
Change-Id: I8024472c909fe0a885eb08ef4d3777f8a9e1f7c8
|
|
Change-Id: I87805ceacf184d5aa5faae68e8bb932391ace7fb
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Apparently Mac OS X looks at the DPI value, not to the actual pixel
size of the image.
Change-Id: I9fd43228e4d2e05397f798ed4902d7d80ef2145f
|
|
Change-Id: Iafadaea87501bc3675eaf2856b5050a7e3ecaa37
|
|
Build Catalan-Valencian as ca-valencia instead of ca-XV private-use.
Introduced LANGUAGE_CATALAN_VALENCIAN 0x0803 mapping to ca-ES-valencia,
preserving old ca-XV and qcv-ES mappings to now
LANGUAGE_CATALAN_VALENCIAN and LANGUAGE_OBSOLETE_USER_CATALAN_VALENCIAN
0x8003 to ca-ES-valencia.
Removed special !bUserInterfaceSelection treatment from
MsLangId::getReplacementForObsoleteLanguage() and added the usual
obsolete replacement instead.
Change-Id: I2fdd8b0bac55d4b4ae2cbf3c3645f09fefec9b6e
|
|
Change-Id: I12afdc1c25bb09d20fd0698831642b953e08bb63
|
|
Change-Id: I3c65cb43696a829f29ab573b7b6e424a39d1a547
|
|
Change-Id: I531430ce4bc0937a023d3e2849ae07d8f94e3e70
|
|
Change-Id: Ibeed303ca4b8812cf7deafa1d1ad06f59a73cf8d
|
|
Change-Id: I10d1203cb81ffd96c5447082884e71cb8b9eb2f7
|
|
Change-Id: If0a7146f51741e3e8250f0aa671a6902119bb6eb
|
|
Change-Id: I03393b08db5878b099a2e71b9b515b707a386e3f
|
|
Change-Id: I2d7bf2b4308b9e52ebadd0d73f43baf469f506a6
|
|
Change-Id: I45087282fe7b7fc5bcebeeb2bbb79d0db1e043bd
|
|
At least for Linux RPM, the packages built via EPM in module instset_native
(with --enable-epm) record intra-installation-set dependencies only by name but
without any version numbers, so that one can e.g. freely ask rpm to install a
(broken) combination of packages from LibreOffice_4.0.2_Linux_x86-64_rpm.tar.gz
and LibreOffice_4.0.3_Linux_x86-64_rpm.tar.gz.
The documentation for EPM (e.g., workdir/*/UnpackedTarball/epm/doc/epm-
manual.pdf) states that %requires lines can optionally indicate lower and upper
version numbers, so the easiest fix appears to be to augment all relevant
"requires =" lines in setup_native/source/packinfo/packinfo_*.txt with lower ==
upper == %PACKAGEVERSION. (There appears to be some confusion in those files
between %PACKAGEVERSION and %ABOUTBOXPRODUCTVERSION, but those seem to always
get identical values in instsetoo_native/util/openoffice.lst.in.)
Change-Id: Iea68beb19f1699cc1eea3dc36fd2f11b8845e390
TODO: The freebsdrequires and solarisrequires lines are not updated.
Reviewed-on: https://gerrit.libreoffice.org/4344
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I1afb4388bbb811a7d296b86a4a8b77758964daaf
|
|
Change-Id: Ibf2cb81f57d123825990c7bde90586b894b9cdcc
Change-Id: I7ea382194476eeef7f83caa66c9115ed1da433b2
Reviewed-on: https://gerrit.libreoffice.org/3860
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
OLDPRODUCT2 - it was a workaround for OOo 1.9, obsolete
SAMEPRODUCTS - same product have the same ProductCode, so installer detect it
anyway under normal circumstances. It is possible that a tester/developer tries
to install the same version with different ProductCode over an existing installation
(e.g. dailyes or RCs). Then we are in trouble. However, SAMEPRODUCTS was not in use.
Moreover, Windows Installer uses only the first three fields of the product version.
So we cannot make difference between e.g. 4.0.3.1 and 4.0.3.2, and this is the new versioning
scheme.
BETAPRODUCTS - LibreOffice have never used different upgrade code (BETAUPGRADECODE) for betas.
OLDPRODUCTSPATCH, SAMEPRODUCTSPATCH, NEWPRODUCTSPATCH - related to old Star Division patching
mechanism, they were commented out anyway.
STUBPRODUCTS, STUBUPGRADECODE - these look useless
Change-Id: I77d67b72e18fa6b3ba4182b99e198c42f247cea4
|
|
...at least due to dependency of librelogo.xcd on writer.xcd, see
82c53d537a05dadf4d7fd7ea41292897bf2d47c7 "Missing dependency."
Otherwise, having librelogo installed but not writer will cause an uncaught
RuntimeException from configmgr::Components::parseXcdFiles
(configmgr/source/components.cxx) early on in soffice.bin.
Change-Id: I97565fe5c790ed182bb27fd722c650acf8a8ee08
|
|
Change-Id: I298433a242eded15b01a379e7b552d62c44d43f3
|
|
... as otherwise it ends up in gid_Module_Root_Brand, NOT
in it's own module (which is intended)
Change-Id: Ic3951ccd7471793419b04f4f2fcfe90060c6d71f
|
|
For test sample report from fdo#61726 can be used.
Change-Id: Iacf8ddc4cf8ad0a408d72e18ecb7237476afeffe
Reviewed-on: https://gerrit.libreoffice.org/2718
Reviewed-by: David Ostrovsky <David.Ostrovsky@gmx.de>
Tested-by: David Ostrovsky <David.Ostrovsky@gmx.de>
|
|
Change-Id: Ie20dab628e089a97c16b91b080eda5e09bbbb46a
|
|
Change-Id: I3440a45465fa79d3ace0f04fd6036734c9caf00d
|
|
Therefore we packed Aragonese dictionary into Spanish and Catalan
langpacks, instead of Spanish and Catalan dictionaries.
Change-Id: I6b7606b8d8f4f30cded583b96d9f9b5f2ef64e9f
|
|
Change-Id: Id0c413d64e6f6fa7ded3c5ff10e764bc2e40f006
|
|
Using the autocorrect list of LibreOffice
extras/source/autotext/lang/en-US/acor/DocumentList.xml
Change-Id: I8b93969bc0742c2e95b8b7db3c4c37691e8d3657
Script: http://pastebin.ca/2327716
|
|
Change-Id: Id856c2279520d9183c8b10967f5b56903d21963f
|
|
Change-Id: Iadacffaad832c6ff06757e8567e24f929f24a4c3
|
|
The old version should get repalced by the ure package. It should also conflict
with the new ure package.
This commit adds support for %incompat epm tag. It produces conflicts in rpm
and deb. It can be defined in setup_native/source/packinfo by
linuxincompat.
This commit also removes obsolete hack for debian dependencies.
libreoffice-bundled conflict is mentioned in the desktop-integration package
these day. The hack in epmfile.pm was not used because no package
used "replace" tag.
Change-Id: I5e9cb89a6108c22c61287fce1ffc6baf3f618d15
Reviewed-on: https://gerrit.libreoffice.org/2260
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
|
|
Change-Id: I54bff2c8593995829857d30b38b8626a8c1a1a4f
|
|
(c) Maxim Darak, Mirek Mazel 2013
Change-Id: I30fdb3234152e746e8a2a565310ab1b22115315c
Reviewed-on: https://gerrit.libreoffice.org/2236
Reviewed-by: Petr Mladek <pmladek@suse.cz>
Tested-by: Petr Mladek <pmladek@suse.cz>
|
|
Change-Id: I100b7ff7e3aa505098ce8b3333d1aa8faca50370
|
|
Change-Id: I1c15003acfb4d1c49c990a247629c70c4dcc3bd3
|
|
It was never integrated and used. If we made the effort to integrate it,
Windows installer would be a few megabytes smaller, because indexes of
thesauri would be generated in install time (instead of packaging
pre-generated indexes).
However, the cons are:
* untested
* presumably slows down instal process which is slow already
* adds complexity to installer which is too complex already
* indexes will not be there in case of administrative install (QA)
* bad experiences with CustomActions that manipulate the installed
application (various, weird permission problems)
Change-Id: I3989b835b1250718bc03107a3807d091e7a9aa0e
|
|
Change-Id: I609270e269a0905818d6a2b4f44cb9a034099346
|
|
Change-Id: I56da76771790cb6824ac3d01072d9143cb580741
|
|
The main goal of this patch was to simplify things. The LibreOffice
version that goes to Intel AppUp use advertsied shourtcuts, because
it is what Intel AppUp Center requires. We can reduce complexity a
bit, if we use advertised shortcuts in normal builds, too.
Change-Id: Ia35a753c83cb592137232428ab897a640e7ccc1f
|
|
Change-Id: I4361b4f4670a0437c8220d2e7f92f2ffbe0cc479
Reviewed-on: https://gerrit.libreoffice.org/2057
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Change-Id: Ie12338dada22c59d55d89ed9611bb1a958b04223
Reviewed-on: https://gerrit.libreoffice.org/2063
Reviewed-by: David Ostrovsky <David.Ostrovsky@gmx.de>
Tested-by: David Ostrovsky <David.Ostrovsky@gmx.de>
|
|
Sign also all the dylibs and frameworks in the bundle.
Change-Id: I7f67b9d7eda0204b24e2ea2ef44a53fb8db0f8aa
|
|
It is not entirely clear what this CustomAction was supposed to do, but
program\edition directory is not present in LibreOffice, therefore this
feature is useless.
Change-Id: Icfcd9c5f88da28e171329d951956baaa42908fd0
|
|
We do not need to call a dll function for a simple version check.
Change-Id: If82b06a61f10dbfe3eb92b6fe495e6d800c57aff
|
|
It copied *.oxt from [SourceDir]\extension to TARGETDIR\share\extension\install.
One might think that *.oxt files there get installed automagically at first start,
but no, it does not happen. This feature looks useless.
Change-Id: I5ce583f3b46f5e4e962449790bdce70f99aa135b
|
|
I think this CustomAction is unnecessary, providing that we do
not use Star Division home-made PATCH technology. I have never
seen this CustomAction used in any OpenOffice.org/LibreOffice builds.
Change-Id: I62f3b5a3ef8a9686f018ca1af52689954262e830
|
|
It does not make sense to call a dll function to set a single property to 1.
Change-Id: I4e3cb35d2d3b644805d1d7573c9bf1dc45befbd4
|