The Lpsolve solver and the CoinMP solver are both used for the same
thing: a linear model, with optional integer variables by branch
and bound. CoinMP (CLP plus CBC) is the more capable and better
maintained of the two, so the lp_solve one adds a second bundled
dependency and a parallel copy of the solver code for no capability
the other lacks.
Remove the LpsolveSolver component, the bundled lp_solve external
(and its colamd dependency, which only lp_solve used), and all the
build, configure, packaging and license references to them.
A document may still name com.sun.star.comp.Calc.LpsolveSolver as
its engine. SolverSettings now reads that name as the CoinMP
solver, which solves the same model, so such documents keep
working.
The Calc solver test that exercised the engine now uses CoinMP. Its
knapsack model has a single optimal total value of 6987, which fills
the weight capacity of 1000 exactly and which CoinMP finds. The
lp_solve run had returned a suboptimal 6981, so the test now expects
the true optimum.
The build setup changes only take effect after re-running autogen.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ia14d8c491779873da6b0157aa524056275adf8f5
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3810
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit e77738a7ca7d44fd9d1f852e26d46e3a6d60467b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208038
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
those were from a time where there was 64bit Windows, but no 64bit
builds of LibreOffice/OpenOffice.org - now the only usecase for 32bit
LibreOffice is to use it on 32bit-only machines…
Change-Id: Icf1eacafd9e157788e8ec5a035716327492f5c2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185565
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
makefile stuff anymore, there's still code that can be removed from the
actual code (partly reverting 8f6b5370be
that added support for using 64bit Internet Explorer with 32bit Office
Change-Id: Id0c59e2ef2f4c87a04f18ea54ed04f4337ea6c73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185564
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
Online update is not available (not installed)
This is only a workaround solution for tdf#159979, with removing
MAR update specific files during msi installation if the original
Online Update feature is skipped to install, therefor later we can
check if the Automatic update UI page should be visible or not.
Better/final solution would be if we just skip and not create any MAR
update files with /core/external/onlineupdate/Module_onlineupdate.mk
if we are not installing the Online Update feature.
Change-Id: I7e16c694308f7bb196f9f1121bd7a85e368d35b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183119
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
This is a follow-up to b83387a554
that added the necessary files to instdir, when
ENABLE_OPENGL_TRANSITIONS was not TRUE. That variable is unset
for LOKit/COOL for various reasons:
1) disabled for MPL-only build
2) disabled without X11
So I add the files from instdir to impress deb/rpm package based on the
conditions:
1) the target operating system is LINUX, and
2) USING_X11 is not defined.
That is the LOKit/COOL case, and I hope it will not interfere with
anything else.
Change-Id: Ia04249c5ed609b2d8e7695ae6e8dd648cdf9b825
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182438
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit af65c54f9c2ca7750a9466e21745efb9b449ec78)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182452
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
app background bitmap customization wasn't working on any release of
25.2. The issue was that the gallery/backgrounds folder wasn't
registered under the package-file mechanism in the build system.
so the backgrounds weren't included in the installation, hence this
issue.
Change-Id: I32c70ee80e074e927a59b51d1c5146230f72442f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181520
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
There is no point to bundle it, because
1) it is an old version
2) since LibreOffice 7.5 there are built-in number formats in
Calc with the same functionality (using libnumbertext FWIW)
Change-Id: I8cfb24f7e6f045bd51fea620aca6a61269dba77a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180996
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Implement simple Quick Look plugins that generate a preview and/or
thumbnail image using Apple's latest Quick Look APIs. The approach
is to load and render any thumbnail images that may have been
embedded in .od* files when they were last saved.
Fortunately, LibreOffice, OpenOffice, and NeoOffice have been
saving thumbnail images by default in .od* files since at least
the mid-2000s so this approach should work with most unencrypted
.od* files.
Note: the plugins appear to work in unsigned builds using the
following steps to enable them:
1. Install LibreOfficeDev.app from an unsigned .dmg (e.g. nightly
master builds) but the plugins in instdir/LibreOfficeDev.app
in a local build are not usable.
2. Launch LibreOfficeDev.app to register the plugins.
3. Launch the System Preferences application, navigate to the
Login Items & Extensions panel, and in the Extensions section,
click on the icon next to the Quick Look entry to see a list of
installed extensions.
4. If macOS has successfully found and loaded the plugins, there
should be two extensions listed under LibreOfficeDev. If they
are disabled, enable both.
5. Press Command-Option-Escape, select the Finder in the dialog
that appears, and press the Relaunch button.
The Finder should now display the thumbnail images in .od* files.
Change-Id: I094afbc56b684cc85b12ed996e060818bfe8ad46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178393
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
There is no simple "Windows is 10 or newer" check in MSI, with the
Microsoft policy of "you don't need to know real Windows version".
See also https://developercommunity.visualstudio.com/t/detect-a-windows-version-from-msi/412198
The values that MSI sees (e.g. on my Win11) are:
Property(C): VersionNT = 603
Property(C): VersionNT64 = 603
Property(C): WindowsBuild = 9600
So those can't be used for the check. I use the WINMAJORVER that is
read from registry (Software\Microsoft\Windows NT\CurrentVersion).
There is no more need to check and install UCRT; it was dropped.
Change-Id: Ic02d6aeb965e9684bafd4357f969980f77000e73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178049
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
it is make's job to determine whether the script should be run
again/whether the prerequisites have been touched since the target
was made. Also the case where the list of languages didn't change
had already been disabled/never was active in the first place
Change-Id: I065faa00162f2d734330b798d9ac17ea47861686
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172736
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
This commit adds Package targets for the net_basetypes, net_uretypes
and net_oootypes libraries to install them into instdir/program/dotnet.
Also adds a LIBO_SHARE_DOTNET_FOLDER variable mirroring the
LIBO_SHARE_JAVA_FOLDER variable.
Change-Id: I28cdb2dac799bd72d11c3e550bba1a946db8b49c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170098
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
will be included when using --with-lang=ALL in non-release configuration
(i.e. tinderbox provided daily builds), but not when using
--enable-release-build.
Change the way how configure fetches the list of all supported languages
from a fancy sed call to running make with a dummy-recipe.
Change-Id: I8bbea5fd95d37eac5bbce2e55ae34830b0ab4ebb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168334
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
(See a31f334d36 "Windows MAR update issues with
program/{setup,version}.ini" for why this cleanup is needed.)
It is unclear to me why these entries would be needed in the setup.ini file.
The *INSTALLLOCATION values are also stored in the Windows registry (see
scp2/source/ooo/registryitem_ooo.scp). FINDPRODUCT was once used as a
GetMsiProperty, in code meanwhile removed in
030124d836 "remove CustomAction
ExecutePostUninstallScript" (so I also removed the FINDPRODUCT property file
line from solenv/bin/modules/installer/windows/property.pm, so FINDPRODUCT will
no longer in the MSI Property table). ALLUSERS is only used with some
SetMsiPropertyW/UnsetMsiPropertyW/IsSetMsiPropertyW/GetMsiPropertySetW code in
setup_native/source/win32/customactions/, but that should be unrelated to the
setup.ini file.
Removing the ProfileItems from scp2/source/ooo/common_brand.scp removed the only
uses of the INIFILETABLE style, so also remove the corresponding code from
solenv/bin/modules/installer.pm and the complete related
solenv/bin/modules/installer/windows/inifile.pm. Fingers crossed.
A# modified: scp2/source/ooo/common_brand.scp
Change-Id: If2aa72f0da50bc72f8c873df713340a142eed5e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161981
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
(See a31f334d36 "Windows MAR update issues with
program/{setup,version}.ini" for why this cleanup is needed.)
I couldn't find any traces of any code actually reading that entry from
ini-files. (There is some code in
setup_native/source/win32/customactions/shellextensions/ calling GetMsiPropertyW
with an L"UpgradeCode" argument, but that's something different.)
Change-Id: I8ed79e7f7911635c52e1c41f54014b1445c561de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161980
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
(See a31f334d36 "Windows MAR update issues with
program/{setup,version}.ini" for why this cleanup is needed.)
There were traces of actually reading that entry from ini-files in commits like
3f01a5e9e4 "INTEGRATION: CWS nativefixer12
(1.2.2); FILE MERGED", d9d86a2d66 "INTEGRATION:
CWS nativefixer18 (1.3.2); FILE MERGED", and
2521869690 "INTEGRATION: CWS native36 (1.7.4);
FILE MERGED", but all of them have since been removed with commits like
50c26300e5 "Remove lots of dead code",
26c142ca5f "Kill the ancient StarOffice "patch"
concept", and e0ea85f61a "we don't build language
packs on Windows". (And all of the original code appears to having been related
to ancient Windows patch mechanisms.)
Change-Id: I552830faf9006bae951fc60e97804abd9de718bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161979
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
(See a31f334d36 "Windows MAR update issues with
program/{setup,version}.ini" for why this cleanup is needed.)
The ini-file entry had originally been added with
d295757e7e "INTEGRATION: CWS nativefixer11
(1.23.2); FILE MERGED", and setting its value with
b993422e59 "INTEGRATION: CWS nativefixer11
(1.21.38); FILE MERGED" and 127dd8d32a
"INTEGRATION: CWS nativefixer11 (1.45.2); FILE MERGED", but it doesn't appear to
ever have been actually used for anything, other than being recorded in the
ini-file. Lets remove it completely for good.
Change-Id: I5f0372360416c2c6949ee2d5f0cc7e6babd8ba79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161978
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
The install/uninstall actions need to be type 3137 to run privileged, which
means that they must be placed within certain limits (e.g., not at "end") and
that they cannot access INSTALLLOCATION (so need an additional un-privileged
prepare action to forward that value).
Plus, the call to CreateProcessW was passing arguments in a completely wrong
way.
And then some clean-up.
Change-Id: I5b5f338da08931e48653f282cc9fa7b00955fea6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161191
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...which needs to call update_service.exe with "install" (resp. "uninstall") and
needs to create (resp. delete) a registry entry containing the issuer and name
of the certificate with which the updater.exe is signed (which is required by
one of the many sanity and security checks performed by update_service.exe
before it will actually do an automatic update). (The issuer and name of the
certificate are for now hardcoded to the values used by TDF when signing its
Windows builds.)
(gid_Customaction_uninstall_updateservice needs to run rather early, when
update_service.exe has not yet been removed, so I rather randomly picked
"MigrateFeatureStates" as the point where to run it.)
Change-Id: I6e0f62ec3e51d74d4a526a490badc7c14ebe99ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161125
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is
apparently dead and should thus be removed. However, that was the only bridge
implementation for AIX, which implies that support for the AIX platform as a
whole is dead and should thus be removed.
Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
After commits 42da199753 (more VS2022 integration,
Oct 14 10:58:25 2021 +0200) and 9ea17a6331 (Adapt
to latest VS 2022 MSM versions, Apr 08 09:15:19 2022 +0200), the new 143 version
of MSMs gets detected and passed to SCP, but not used there, so MSIs lack CRT.
Additionally, it may happen that a redist is configured that does not match the
actual CRT used in the build, because it picked a latest available version, and
then an error happens when building MSI, because it expects MSMs in wrong source
directory.
This simplifies the checks, makes sure to look for the correct MSM version, and
adds an error message in SCP in case when the passed version is not handled, to
detect the incomplete support early.
Change-Id: I47d45472309c584314730e7f5f46a9596fc8d21d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142587
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This patch removes the names of template categories that are not used. None of these template category names are reachable via the Templates Manager nor via the Save as Template function.
Change-Id: Ic2caf485106134de8554b93b5d6e14bdf7f382e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140610
Reviewed-by: Laurent Balland <laurent.balland@mailo.fr>
Tested-by: Jenkins
The "UnitTest" service is implemented as a new
Basic library called 'SFUnitTests'.
ScriptForge unit tests (SF_UnitTest class module)
======================
Class providing a framework to execute and check sets of unit tests.
The UnitTest unit testing framework was originally
inspired by unittest.py in Python
and has a similar flavor as major unit testing
frameworks in other languages.
It supports
- test automation
- sharing of setupand shutdown code
- aggregation of tests into collections.
Both the
- code describing the unit tests
- code to be tested
must be written exclusively in Basic
(the code might call functions written in other languages).
The code to be tested may be released as an extension.
It does not need to make use of ScriptForge services.
The test reporting device is the Console.
Definitions:
- Test Case: each test case is a Basic Sub.
- Test Suite: a collection of test cases stored in 1 Basic module.
- Unit test: a set of test suites stored in 1 library.
Two modes:
- the normal mode ("full mode"), using test suites and test cases
The UnitTest service is passed as argument to each test case.
- the "simple mode" limited to the use of the Assert...() methods.
Service invocation examples:
- In full mode, the service creation is external to test cases
Dim myUnitTest As Variant
myUnitTest = CreateScriptService("UnitTest", ThisComponent, "Tests")
' Test code is in the library "Tests"
' located in the current document
- In simple mode, the service creation is internal to every test case
Dim myUnitTest As Variant
myUnitTest = CreateScriptService("UnitTest")
With myUnitTest
If Not .AssertTrue(...) Then ...
' ...
.Dispose()
End With
Error handling
To support the debugging of the tested code, the UnitTest service, in cases of
- assertion failure
- Basic run-time error in the tested code
- Basic run-time error in the testing code (the unit tests)
will comment the error location and description in a message box and in the console log,
providing every test case (in either mode) implements an error handler
containing at least a call to the ReportError() method.
Change-Id: I9d9b889b148f172cd868af455493c8c696d1e953
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135365
Tested-by: Jean-Pierre Ledure <jp@ledure.be>
Tested-by: Jenkins
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
Do not bundle LanguageTool which is at a 10 year old version (1.7)
while upstream has a lot of new releases (now at version 5.5.x)
It is not bundled by any downstream distributions
so it makes no much sense to keep it integrated here.
Change-Id: Icd2ef151b1b8d0252ffa3db0caaba576f2783fa9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133356
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
This commit implements a WebP reader and writer for both lossless
and lossy WebP, export dialog options for selecting lossless/lossy
and quality for lossy, and various internal support for the format.
Since writing WebP to e.g. ODT documents would make those images
unreadable by previous versions with no WebP support, support
for that is explicitly disabled in GraphicFilter, to be enabled
somewhen later.
Change-Id: I9b10f6da6faa78a0bb74415a92e9f163c14685f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128920
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Jesus Solis