in commit 65a7e714292dbf4c5a2a4f5760f3b546d603c40c I was under the wrong
assumption that the revision is added by epm and will be always 1.
Instead the revision is passed to the epm calls in the commandline
arguments. So the upper version limit must use the "patchlevel" as the
revision. (version a.b.c.d => d is also release number)
Change-Id: I5002aef88e454561ba610b2d2774b84712da44dc
debian packages have a debian-version appended to the version string.
LO version "x.y.z" will become debian package version "x.y.z-1"
When checking the dependencies, the full version is compared and
a check "core01 needs to be >= x.y.z and <= x.y.z" (i.e. exactly x.y.z)
fails, as the x.y.z-1 package is considered to be newer.
Thus require the package to be >= x.y.z and <= x.y.z-1 to satisfy dpkg
Also replace occurences of ABOUTBOXPRODUCTVERSION with PACKAGEVERSION
Change-Id: I58dea3055562f879f5eef511c2c9c94a2b98041b
Only shellscripts_module.txt actually used; the shellscripts_core01.txt
is apparently relic of 3-layer office days.
Change-Id: I37faa0bbe195574511c3af85db1beb15e8a2cda3
...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
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
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>
...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
Therefore we packed Aragonese dictionary into Spanish and Catalan
langpacks, instead of Spanish and Catalan dictionaries.
Change-Id: I6b7606b8d8f4f30cded583b96d9f9b5f2ef64e9f
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>
It was discovered that on a Russian Windows, by default only Russian and
German dictionaries would be installed, but no English dictionary. This is
because since e2fac98819c00b4fb50f9de9d0f32d20092f3191 "fdo#53009: For msi
installer, only default-select a subset of dictionaries" only those dictionaries
mentioned in setup_native/source/packinfo/spellchecker_selection.txt were
default-selected, but it apparently was a misunderstanding that
spellcheker_selection.txt for many locales does not list "en" even though an
English dictionary should always be default-installed.
Quoting Andras Timar <atimar@suse.com>: "AFAIK en-US localization with English
dictionaries is always installed in all 3 supported platforms by default. On
Windows default install should always select en-US and English dictionaries. If
it does not do so under certain circumstances, then it is a bug in my opinion.
We removed en-US entry from the spellchecker selection file for this very
reason. It would have only bloated Mac and Linux langpacks."
So this fix simply makes sure that "en" is included in every line of the
generated spellchecker_selection.hxx that is used by
setup_native/source/win32/customactions/sellang/sellang.cxx to determine which
dictionaries to select by default.
Change-Id: I3db68585dc6269a7db2f6cbf6b79796dc09d05e8
Remove the oooblogger extension. It is unmaintained and the original
author (caolan) wants it dead.
Change-Id: Iff89f5badbb74f465c57e068a9e1acbbc13bc235
No need for dirty hacks linking in basegfx objects statically any more.
To avoid unnecessary confusion between the newly plain code and any instance of
the old extension still installed (per-user or shared), I renamed all relevant
UNO implementation identifiers from com.sun.star.comp.documents.* to
org.libreoffice.comp.documents.*. Also, existing installations of the extension
are explicitly not migrated to new user profiles.
The xpdfimport executable is now in program/, its xpdfimport_err.pdf in
share/xpdfimport/. To simplify finding the _err.pdf from xpdfimport, its full
pathname is now given as additional second argument to xpdfimport. To find
xpdfimport executable from CppunitTest, CppunitTest creates a symlink from
solver's unittest/installation/program to solver's bin, so that
"$BRAND_BASE_DIR/program/xpdfimport" works there (as CppunitTest now sets
BRAND_BASE_DIR to solver's unittest/installation).
The sdext/source/pdfipmort/dialogs/ Basic stuff appeared to be unused (even
though it was included in the .oxt) and has been removed.
The --disable-ext-pdfimport configure switch is renamed to --disable-pdfimport.
Having it still conditional requires some pdf_Portable_Document_Format vs.
pdf_Portable_Document_Format_import foo in module filter.
Change-Id: Iee58c2f6187142a418decc9ea3a5df10eb7e0523
This patch fixes fdo#53520: Portuguese language spelling package names and split the files into the proper directories.
Change-Id: Iff10cfee1da2c4775e4cf9050ec154052ee18ac9
Now that 5c47e5f63a79a9e72ec4a100786b1bbf65137ed4 "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
