| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I12d875faa6f8206a5b0a37067ca21df124f71e22
|
|
Change-Id: I2067ceb1086edfebc51a7532a0539d4368175fe7
|
|
Change-Id: I5fae2ec81b50203e9d6100f8c938fb3643ff651f
|
|
Is testhxx still useful?!
Change-Id: Ic7761214df4e3056c95f1b5dd8f1e3a2ce357d84
|
|
Change-Id: I0362d758205e7d12484e9e86ff2dce9608730c57
|
|
Change-Id: I6c145e984c885c7e06caa1c27bfb354ea49ad9ce
|
|
Change-Id: Ice06e639213aeb6f7f23cbf4634947dd25613db1
|
|
FINDPRODUCT property was not available to this deferred custom action.
Not to mention that registry keys are also deleted at his stage of uninstallation.
The proper solution is to set the installation directory with a type 51 custom action,
and pass it to RemoveExtensions custom action via CustomActionData property.
Change-Id: I0ac18b3a0b19ff1a87bcf580fad9c7fdadb26f76
|
|
Change-Id: I0b12dd16c6de05b14d2196771a81441ac0c73201
|
|
Change-Id: Id68521b92f572366a68f35c09387a7ed45a835ff
|
|
64-bit registry entries were entered via a custom action, which
did not always work. By default the custom action ran with user
privileges, which were not sufficient to write the registry.
It is not necessary to use custom actions for this task. Windows
installer supports it well.
Change-Id: Id65458c363c2b90b3e7d166b4c836bfb1ff19bf4
|
|
Change-Id: I1206a0c7f8508942eb844869fe1c75a48a9e01fd
|
|
Change-Id: I8562d1289b269ca7f3aa959907641fd70be0770f
|
|
Change-Id: I6f468005c8d8d99d9251a9c4fe4629b98bc4aa5e
|
|
Change-Id: I03a06d09e3e84b6cb13bd68e8be4caebb1b9f5ab
|
|
Change-Id: I6a178f7ff9c8306e15bcfa847ad1e5e4f8476504
|
|
this removes dmake completely out of the build for migrated modules
build.pl now assumes modules to be gbuild, unless there is a
prj/dmake file
Change-Id: I674a036b182ee13c5ec093e83cb3d38133112d3b
|
|
Although Microsoft says that SelectionTree control can publish a control
event only on Windows Server 2003 and above, the custom action seems to
be working under a fully patched Windows XP SP3. Maybe it fails silently
on older Windows XPs, not to mention Windows 2000. I did not test those.
|
|
|
|
it is in the main installation tarball anyway; it was put in langpacks
that did not have its own dictionary from some strange reason
|
|
* 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
also remove commented-out codes
|
|
|
|
Replaced --enable-ext-postgresql-sdbc with --disable-postgresql-sdbc.
Renamed postgresql-sdbc.uno{.ini,rc} to consistent postgresql-sdbc.ini
(which made the code a little easier).
Signed-off-by: Fridrich Štrba <fridrich.strba@bluewin.ch>
(cherry picked from commit 3a7ae48b6f610899200ae2800706533f7c4c9f80)
Conflicts:
configure.in
connectivity/source/drivers/postgresql/makefile.mk
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
+ it currently includes just the smoketest and is available only for Linux
+ the side effect is that it builds the smoketest before instsetoo_native
+ it runs it only during dev-install when the variable RUN_SMOKETEST == YES
|
|
|
|
|
|
|
|
instead of trying to rename a file or folder in
Program Files directory - which is write protected
anyway normally - installer checks the process list,
if there is a process called "soffice.bin".
|
|
|
