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
* Windows XP SP2 is 0x0502, see
http://msdn.microsoft.com/en-us/library/aa383745.aspx
* If a module changes the Windows SDK version setting,
this is done module wide now. So the overall behavior
is as before. This seems to be the best compromise for
now.
* We need at least SP2 because of the bluetooth stuff
used in sd/source/ui/remotecontrol.
* Now, we require at least Internet Explorer 7.0. IE6
has been outdated for a long time.
* Leave StdAfx.h file definitions, as those are Microsoft
project specific precompiled header files.
* All local definitions of WINVER are removed, because
the global WINVER setting makes them obsolete now.
To the relation of the three macros:
Setting _WIN32_WINNT sets WINVER and NTDDI_VERSION
automatically to the same value as _WIN32_WINNT.
WINVER and NTDDI_VERSION can be set idenpendently each
for itself.
Change-Id: Ibcc12493aae4fcaf7bcfda88be99c1b61bc326cb
Reviewed-on: https://gerrit.libreoffice.org/6496
Reviewed-by: Thorsten Behrens <thb@documentfoundation.org>
Tested-by: Thorsten Behrens <thb@documentfoundation.org>
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
- 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
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
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
We have started to use -fvisibility=hidden globally with GCC.
The hacky libgetuid.so does not work if the symbols are hidden.
In addition, the library was renamed from getuid.so to libgetuid.so
during gbuildisation; There was more location where it was not fixed;
The result was that the packages and files in the Linux download tarballs
were owned by some "ugly" user and group.
Change-Id: I22f62b861c373f2553dcccc85a84dddabaf1f418
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>
