Age | Commit message (Collapse) | Author |
|
Change-Id: I0b1865719da2e3c5a669b30a635c333721c9c41d
|
|
...as gm_Langpack_r_en_US was explicitly excluded from langs[] in
SelectLanguage, so addMatchingDictionaries was never called for it. (This was
only evident in installation sets conaining only few langpacks, as the
"official" multi-lang installation set also contains en_GB etc., so appropriate
dictionaries were selected through those.)
Reworked the logic of chosing which langpacks to preselect (see the comment in
SelectLanguage); hope it still works as intended for the various cases (of which
the "official" multi-lang installation set is the only truly relevant one, for
now).
Change-Id: I31f531194c79e49c9c09e33454a7b0a82d9ff02f
|
|
Change-Id: I05715d4afb205aa11eb0eb98c6734db02a6be8d8
|
|
I don't think it made sense to check OpenWithList at all. When we
found WordPad there, we registered the file type, even when it was
registered by MS Office.
Change-Id: I15a151051cadd329e8614388ceb84470ea28805a
|
|
Change-Id: I3ee3fb5e5142ce4956776467b2ffcb19ed3b10c2
|
|
Change-Id: Idad02284eaa033a029a2ff7d03bde83800ba738a
|
|
Change-Id: I01eb2bf6fe03845787e8869a2f90bb2fced4f933
|
|
Change-Id: Ie2262ed49ea829e1afdf97583dd633f954f64edc
|
|
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
|
|
Change-Id: I3e1800d73250a8a630dd37329189b13cfae311e9
|
|
Change-Id: I2ce8be599c9285bd0da039e1ff9c0649a118a8a1
|
|
Change-Id: Ie10a8d53357255f4f326f399b59a3d81ebc7d2a6
dmake: Error executing ´o´: No such file or directory (Ignored)
|
|
Change-Id: I40d42ce2ee7f50f1b3a1b825e2672cc11c35390b
|
|
Change-Id: I9392de62dc8b69033ba3dee815617ac3f0ff0bc6
|
|
Change-Id: I06ffe30b187db6db3cec38bb35af9da797ebca45
|
|
Change-Id: I0da3e604ebd0665c5405174957d852677195126b
|
|
Change-Id: Idc58b314a0721507e80e7b0e6216f29090f1d347
|
|
Change-Id: Ie8174ae4b7d2c02503f40fe1263076d924f2c9e2
|
|
lcab is expected in the sys. path.
Change-Id: Ie1cd8a45966bbd84ce84f2ad1d86da492eafa321
Signed-off-by: Fridrich Štrba <fridrich.strba@bluewin.ch>
|
|
Transforms currently cannot be generated as Wine does not implement
MsiDatabaseGenerateTransform().
Change-Id: I03507e07f372871eed23ac932426d5708f765884
Signed-off-by: Fridrich Štrba <fridrich.strba@bluewin.ch>
|
|
Change-Id: I23349edcf15731a9a33b9698bd77893003682e39
Signed-off-by: Fridrich Štrba <fridrich.strba@bluewin.ch>
|
|
Change-Id: Ic48abd66a04bfaafda846e514b096431e37488a8
Signed-off-by: Fridrich Štrba <fridrich.strba@bluewin.ch>
|
|
Change-Id: I7daf3277983b6bf41ddd664c8d4953902b1d0f3e
Signed-off-by: Fridrich Štrba <fridrich.strba@bluewin.ch>
|
|
Change-Id: I966d34205db1825d3aa1d328c03418817bf01bc3
Signed-off-by: Fridrich Štrba <fridrich.strba@bluewin.ch>
|
|
Currently, makecab does not output .cab files. A subset of the ddf
format is interpreted.
Change-Id: Iae11aefb4759a0eb76f9455b2206b59864086af5
Signed-off-by: Fridrich Štrba <fridrich.strba@bluewin.ch>
|
|
Msiinfo supports the change of most summary information. Unsupported:
-b, -d
Change-Id: I51466c9acea54fe151db966c4ce47b29f90ab937
Signed-off-by: Fridrich Štrba <fridrich.strba@bluewin.ch>
|
|
Msidb is a subset of MS msidb. Currently unsupported options are:
-m, -t, -j, -k, -w, -s
Change-Id: Ice5f646f70b2f797266ce3fabce12ae9f689b1c8
Signed-off-by: Fridrich Štrba <fridrich.strba@bluewin.ch>
|
|
This allows us to drop dependency on setup_native everywhere.
Change-Id: Ib033f8d5953682379c6c2ab53d5cf221e9d8cfec
|
|
Change-Id: I7f2d124f8a1d0330c4ab7bc58217e4368ee72cc2
|
|
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
|