Age | Commit message (Collapse) | Author |
|
Change-Id: I83d28b9bc7985f34303d3c3343f976b5a87009e1
|
|
It was "Filename" [1] since commit 68d28e25348ced2619733d8b177423d3aefab900
(#i28464# ooo native installer, 2004-05-24). But according to the spec [2],
it should be "Text" [3].
Found accidentally, because of an MSM bug in VS 2022 [4]. The unnecessary
entries there for Signature table conflicted with ours, preventing merge.
[1] https://learn.microsoft.com/en-us/windows/win32/msi/filename
[2] https://learn.microsoft.com/en-us/windows/win32/msi/signature-table
[3] https://learn.microsoft.com/en-us/windows/win32/msi/text
[4] https://developercommunity.visualstudio.com/t/Microsoft_VC143_CRT_x64msm-v14363253/10505819
Change-Id: I9911b8c02df57f202d197c634b565ce74b35d7e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158783
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
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>
|
|
As Christian Lohmaier pointed out in [1]:
> When building packages using the epm method, the dependency gets added
> by instsetoo_native/inc_openoffice/unix/find-requires-x11.sh - and it
> looks like it should also add the ()(64bit) marker to the dependency
> when PLATFORMID is linux_aarch64 and not only for linux_x86_64
>
> check with rpm -q --provides libXinerama-1.1.3-2.1.el7.aarch64 whether
> it provides "libXinerama.so.1()(64bit)"
The reply of 2022-03-25T10:41 (public mailing list version
probably still pending in some moderator queue)
shows it does:
> [root@1 rpm2]# `rpm -q --provides
> > ^CbXinerama-1.1.3-2.1.el7.aarch64
> [root@1 rpm2]# rpm -q --provides libXinerama-1.1.3-2.1.el7.aarch64
> libXinerama = 1.1.3-2.1.el7
> libXinerama(aarch-64) = 1.1.3-2.1.el7
> libXinerama.so.1()(64bit)
[1] https://lists.freedesktop.org/archives/libreoffice/2022-March/088637.html
Change-Id: I1b9a4025399d82ac5f5e51ea5523417e3e6cf395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132094
Tested-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Change-Id: I44a1782cf523bbfbbbb0e0d5333364f36c7ed495
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130783
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Change-Id: I7e25ea89594b8b71e9009d8e9227e039aff8ee32
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130657
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ib8b6d8b47934a7a2cf68f8977f03ced5f80f6452
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123409
Tested-by: Jenkins
Reviewed-by: Roman Kuznetsov <antilibreoffice@gmail.com>
|
|
Change-Id: I71d7994ad7ed4506c1514cf417a535caff20b05f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119869
Tested-by: Jenkins
Reviewed-by: Roman Kuznetsov <antilibreoffice@gmail.com>
|
|
Change-Id: I6a58e0977381c620a795b77df56c24dab37cc327
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114281
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: I3e2a2dbb7913bc0e35f0eb676f39afba53e1d0d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95970
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ic0bc2af1dd565dc9c24a74de8900da771f052a95
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90402
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I4f1de2d3b112c5a4d3ba795bd944aa21add037a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90396
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
It used to be set both in AppSearch action (using RegLocator table),
and in MigrateInstallPath custom action. This would overwrite value
of INSTALLLOCATION taken from user, and read on the previous step,
with values taken on the next step.
Only migrating the install location in one single place - in custom
action MigrateInstallPath - makes the process controllable. Also it
allows to easily see all the various places in registry we read.
Change-Id: Ib7e04c26e71ba92c6a62a0511971bfb3bdb7db72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87867
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Fix the string’s grammar while at it.
Follow-up for commit 128dabf58a535d422eb27f8dc760c81e54c6b354.
Mentioned on review but never addressed.
Change-Id: Id05d8686aca6d719eab4ad47fa0502353d3d074b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87034
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
that it must be installed into the same directory as LibreOffice
and some visual fix in layout
Change-Id: I8048c332bf381137689bfa1695862cf7d118f0a8
Reviewed-on: https://gerrit.libreoffice.org/84582
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
We don't install low-level system components that have potential of
ruining the system, which would be the reason to create the restore
points. Some systems suffer from very long creation of the restore
points, like in tdf#129087:
...
MSI (s) (60:00) [09:18:54:201]: Calling SRSetRestorePoint API. dwRestorePtType: 1, dwEventType: 102, llSequenceNumber: 0, szDescription: "Removed LibreOffice 6.3 Help Pack (English (United Kingdom))".
MSI (s) (60:00) [09:26:57:699]: The call to SRSetRestorePoint API succeeded. Returned status: 0, llSequenceNumber: 73.
...
So let's just disable the generation of restore points, as per [1].
[1] https://docs.microsoft.com/en-us/windows/win32/msi/msifastinstall
Change-Id: I452859d72284e0b2ea9a407e30a5e256a8c0a0f6
Reviewed-on: https://gerrit.libreoffice.org/84113
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Reported here: https://twitter.com/erez/status/1193838467668697089
Change-Id: I96fdb82646e6b2e49b6032766195309a97da0fba
Reviewed-on: https://gerrit.libreoffice.org/82439
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: I0df5dc4cebb065c509df77b00f16597a28566345
Reviewed-on: https://gerrit.libreoffice.org/78355
Tested-by: Jenkins
Reviewed-by: Roman Kuznetsov <antilibreoffice@gmail.com>
|
|
Change-Id: Ia51fa09db3db0c00432fc02ef9fe445444aa463b
Reviewed-on: https://gerrit.libreoffice.org/77321
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Iabb1c04d27bba1a7b3b89be03d0af1ed15951ffc
Reviewed-on: https://gerrit.libreoffice.org/77003
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I6f607e44b92ae9958b6013f9292743a1c7b76d34
Reviewed-on: https://gerrit.libreoffice.org/74185
Tested-by: Jenkins
Reviewed-by: Roman Kuznetsov <antilibreoffice@gmail.com>
|
|
Change-Id: I414959f0f278792c5cac0c58746faa6b7773e494
Reviewed-on: https://gerrit.libreoffice.org/65593
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
On Windows 8.1, the one that is problematic to tell from Windows 10
(because the latter also exposes its version as 603 to the msiexec),
the registry value doesn't exist at
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
but let's play safe and also check for "#6" value just in case.
Reference:
https://stackoverflow.com/questions/31072543/reliable-way-to-get-windows-version-from-registry
Thanks to Mitchell <blazer64@gmail.com> for the idea!
Change-Id: Ic907c4d992a7cb1d12e392686c19cd6fd6da3c7c
Reviewed-on: https://gerrit.libreoffice.org/65231
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This replaces commit 53058090beede6a399e2f408f62c28a2921ff8ab. Now
not only failure to start WU service, but also other errors during
MSU installation won't break installation. E.g., running WU service
as Guest does not prevent the service from starting; but installing
updates fail, which makes previous solution incomplete.
Instead, show a warning in those rare cases when an error happens,
and continue. It will allow users to see the reason if they see
"api-ms-win-*.dll missing" message later after installation. Of
course, some small percentage of these warnings will be false, e.g.
those on Windows 10. But those false messages must be really small
minority, because only when (1) the installation fails (2) on a
system with the component already present, such a message would be
false. And it will not prevent the installation.
This will not block unattended installations, since in those cases,
MsiProcessMessage() will do nothing.
Change-Id: I3a9e681e9d6701d092bd5c18bb4b68b4f77170f3
Reviewed-on: https://gerrit.libreoffice.org/64874
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Iac627b2884d1cc77cf63ec3bd814f5601080e26f
Reviewed-on: https://gerrit.libreoffice.org/63079
Tested-by: Jenkins
Reviewed-by: Sophia Schröder <sophia.schroeder@libreoffice.org>
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|
|
There appears to be common situation that a system has *some* UCRT libraries
in System32, that were installed improperly (presumably by some applications
using simple copy).In these cases, our installer would detect the presence of
ucrtbase.dll, and not try to install UCRT on the system.
Unfortunately, it seems that oftentimes such improper UCRT installations miss
some parts of UCRT, which leads to LibreOffice failing to start with messages
like "The program can't start because api-ms-win-crt-string-l1-1-0.dll is
missing from your computer. Try reinstalling the program to fix this problem."
(the missing component varies).
This patch removes the check for UCRT presence. Installer will try to install
UCRT on applicable systems unconditionally. Since the proper outcomes in case
of already present UCRT are either WU_S_ALREADY_INSTALLED or WU_E_NOT_APPLICABLE
and both are treated as success in inst_msu action (see InstallMSU in
setup_native/source/win32/customactions/inst_msu/inst_msu.cxx), this should
only make this part more robust, and not bring new problems (yes, I know that
actually there will be new problems, as usual).
Change-Id: I22a3d357014d31a8e492ff8a15bcb477eeb79735
Reviewed-on: https://gerrit.libreoffice.org/60789
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ifd83affcb16209f4134c725640fbd95077c8ab0f
Reviewed-on: https://gerrit.libreoffice.org/59099
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Microsoft has never referred to desktop shortcuts as “start links”.
This change aligns our installer with almost every other installer
out there.
Change-Id: Ib5779e6cd44e719e52d1afeb6a44c7dc8f3624dc
|
|
See also http://helpnet.flexerasoftware.com/installshield19helplib/helplibrary/ISBP10.htm
Change-Id: I217d68f98af8e56874af6c071bb7fa7354b3e4b4
Reviewed-on: https://gerrit.libreoffice.org/58326
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Using nested install is bad because (1) MS advises against it (though it
most possibly doesn't relate to our specific case, when we install the
vc redist exe package in UI part, so actually only a single MSI session
is active at any time); (2) because it adds some extra interactions
(user sees something "unrelated" being installed, which raises concerns;
additional admin authentication required); and (3) because it runs in
InstallUISequence, thus only installing the UCRT when doing interactive
installation (unattended installs, including GPO, need to install UCRT
separately).
This patch aims to incorporate the original UCRT MSU (Windows Update)
packages (https://support.microsoft.com/en-us/help/2999226) available as
a zip archive from
https://www.microsoft.com/en-us/download/details.aspx?id=48234
- the same as used in VC redists for VS 2015 and 2017. This obsoletes
the separate installation of the redist; since we also have the redist
as merge module in our MSI, that is enough (and removes redundancy).
The MSUs are installed using wusa.exe in a custom action (deferred,
non-impersonating).
As a small bonus, embedding MSUs instead of redist EXE allows us to
shrink the size of installer a little (~10 MB).
As deferred custom actions cannot access current installer database,
we workaround this by using initial immediate impersonating action to
extract the binaries into a temporary location. To ensure that the file
gets removed upon completion (both successful and failed), we use an
additional cleanup action.
Commit 61b1d631331551b43bc7d619be33bfbfeff7cad6 is effectively reverted.
Change-Id: I1529356fdcc67ff24b232c01ddf8bb3a31bb00bd
Reviewed-on: https://gerrit.libreoffice.org/52923
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This reverts commits 914f6385d98f8c898102c971a4d5b0eb9f075ef0 and
a6045159237419ce8fa49202c672e3895f0ab30a. A investigation required why
is the problem with them; meanwhile, they break builds.
Change-Id: I713b27dd64e8ac7beb2757c362765b60ce191f8d
Reviewed-on: https://gerrit.libreoffice.org/53078
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
section.
The OOO_ARPURLINFOABOUTTEMPLATE is simply missleading as the caption in
Windows itself is "Supportlink". As the help states that the product
homepage can be used, switch to libreoffice.org, see documentation at
https://msdn.microsoft.com/en-us/library/aa367752
Additionally switch some links to https.
Change-Id: I8d6d871130d2a50a5ce9aa3e80687601e3038c4e
Reviewed-on: https://gerrit.libreoffice.org/52193
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I7e2cc08a1312da629e4644be97ebc7ed40250702
Reviewed-on: https://gerrit.libreoffice.org/52995
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Those conditions that rely on AppSearch should only be checked when
not yet installed, since AppSearch is not performed in maintenance modes
Change-Id: Ie2c3fa8e8742a4c335f0cd8be571fa563a178a49
Reviewed-on: https://gerrit.libreoffice.org/52851
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This uses VC Runtime upgrade code (checked using Upgrade table) to
find installed redist, instead of checking registry keys that change
between versions (while the runtime is still compatible, as with 2015
and 2017).
Also, it checks if UCRT is present. Now, if either VC Runtime or UCRT
is absent, we try to install the redist. This would allow to install
UCRT in scenarios when first install was attempted on a system not
suitable for UCRT (like Win7 w/o SP1, or Win8.1 w/o April 2014 update
rollup), where VC Runtime gets installed, but UCRT is still missing.
We use the ucrtbase.dll version to check that; and as the expected
version is 10.x, we take into account that Win10 lies about versions.
Change-Id: I864dfc09cf1bdc775501729fa2a27dc98295588c
Reviewed-on: https://gerrit.libreoffice.org/52794
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
... since it's the required prerequisite for Universal CRT.
This moves Windows version check to LaunchCondition table; and adds a
check for kernel32.dll version associated with the said update level.
Change-Id: I1de84dc47c9392fcb7122e1a877db2e99eae2415
Reviewed-on: https://gerrit.libreoffice.org/52743
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Currently we support Win7 SP1 and later; so let installer fail on lower SP levels.
Change-Id: I807e0a04870b9eeabbfae258d68da4a1156b0408
Reviewed-on: https://gerrit.libreoffice.org/52619
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Breaks windows installer
This reverts commit 7b129f55b4da9a20581fe805b7dacadcb6386252.
Change-Id: I21a5a6790eac1704da4bda41fb0969dc10b19d1c
Reviewed-on: https://gerrit.libreoffice.org/48369
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: Ia90de861bc3aa02e8b0bf482f602ab1ea29aae00
Reviewed-on: https://gerrit.libreoffice.org/48304
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
... in InstallUISequense.
Use --with-vcredist-dir to point to a directory with vc_redist.x64.exe
and/or vc_redist.x86.exe. Use --without-vcredist-dir (or
--with-vcredist-dir=no) if you don't want to ship it as part of
installer and want to silence the configure warning.
VCRedist 2015 version 14.0.24215.1 is available at
https://www.microsoft.com/en-us/download/details.aspx?id=53840
Since VisualStudio 2015, VC redist merge module that we used before
started to work differently: it installs the UCRT only on WinXP,
but not on later OSes (Vista to 8.1) which may lack the UCRT (Win10
has it out of the box). The merge module only installs VCRuntime on
those systems, which still leaves us with "api-ms-*.dll is missing"
problem.
(https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/
gives more information on VCRedist refactoring background.)
Since commit 71d9a61302e65fe091cf70c13fa72b3df09b7e3a, we use a
workaround described at the page mentioned above as "App-local
deployment of the Universal CRT". We just copy all UCRT DLLs to
LibreOffice/program. This has a drawback though, that our UCRT
is not updated by Windows Update, so users would rely on LibreOffice
updates in case of some vulnerabilities in UCRT (and they could
even not realize they have that problem).
MS recommends to install UCRT using EXEs they provide from their
site. The EXEs install both VCRuntimes and UCRTs, along with
required patches, for all Windows versions (Windows XP through
Windows 10, where they only install VCRuntimes); the installed
libraries are managed by system's update mechanism. But those EXEs
cannot be used in MSI custom actions inside InstallExecuteSequence,
because they use MSI themselves.
So this patch integrates the vc_redist.xXX.exe into MSI binary
table, and uses custom action to run the EXE after ExecuteAction
in InstallUISequence. This will show the user a VCRedist install
window after the main LibreOffice installation finishes; no user
interaction is required (except for one additional UAC request),
and errors are ignored.
Since this installation takes care of both VCRuntime and UCRT,
we can ultimately drop both the app-local workaround, and
vcredist merge module (so VCRuntime would also be updated by
system). The former is done here: this reverts commit
71d9a61302e65fe091cf70c13fa72b3df09b7e3a.
This approach has its drawback: if one wants to use unattended
installation (without UI; one example is deployment using
ActiveDirectory GPO), then InstallUISequence is not run, and so
VCRedist isn't installed. In this case, one should install
VCRedist separately. Supposedly this should not be huge problem,
because this is the case for many existing applications that need
separate VCRedist deployment in these scenarios, and unattended
installation is advanced stuff that requires prepared user. A
notice would be required in release notes and FAQ, though.
Change-Id: Ia6a16be60af8a08f41ea7c3dbd457d8f89006006
Reviewed-on: https://gerrit.libreoffice.org/46356
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
VersionNT is now always greated than 600 (only needs checking in version
checking action). ISSETUPDRIVEN and ISSCHEDULEREBOOT are specific to
InstallShield and aren't relevant to LibreOffice installer.
Change-Id: I6cb769c863e09f1568ae895a6cfbb0e5940c2486
Reviewed-on: https://gerrit.libreoffice.org/46434
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
(cherry picked from commit 4e2b0c14b49d5e74a2c7493ed4bcc1f8080efdb3)
Change-Id: I3d5e003a313228188119ee439c858c1ee505c9b0
|
|
(cherry picked from commit 6b62e035d388ce14630da65d63db5a216e1848e7)
Change-Id: I7e0c7edf12a30daec35d9461f0be12b6d07fddc3
Reviewed-on: https://gerrit.libreoffice.org/41575
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Language code has been arranged in
alphabetical order for given files.
Change-Id: Ib2ade0857bc5dd1a77348fbec470747abae4893e
Reviewed-on: https://gerrit.libreoffice.org/33661
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
The goal is to allow installer to automatically close and restart closed
applications, and thus diminish users frustration when they don't know
how to close explorer.exe, or how to start it again and bring desktop back.
Reference: https://msdn.microsoft.com/en-us/library/windows/desktop/aa370379
Notes:
* A dialog MsiRMFilesInUse must be present in MSI.
* It will only be used when operating system's Windows Installer version
is >=4.0, and OS is Vista or newer. If system's Windows Installer is older,
then current FilesInUse dialog will be used.
* MSIRESTARTMANAGERCONTROL property has default value of 0, that enables
installer to use the Restart Manager. It is explicitly set in MSI just in case.
* Do not use Restart Manager and do reboot is selected by default.
Change-Id: If9d8be7cb478d81db03485ee912991ae9d568ed8
Reviewed-on: https://gerrit.libreoffice.org/28171
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|