| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: Ib008987be1102782fd92214ae8bf35f8f862d2a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176381
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Icac6d1ea5659d875551b7b218fc47235fec34dc7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172223
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
trivial, no real change here
Change-Id: I0e93412c930d60d94a9e9406579226026f449897
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172222
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I19acde24fd8a4014807318d97433b81814cadd75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167768
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7e48be1962d1e643c49c8cc0d6ca01ffbbb97429
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165567
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
|
|
The Bluetooth communication appears to be astonishingly slow on my
system; the socket is deliberately cleared of O_NONBLOCK and what's even
worse is that the Mutex that is held while sending prevents the main
thread from adding new messages to the queues.
It looks like there should be no issue with releasing the Mutex while
sending, and if a separate Transmitter thread is used in the first place
it makes no sense to hold the Mutex while doing so.
Change-Id: Ic993e6c7a7799832c86fd4dd8c6ddad9dab1780b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159924
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
The IPRemoteServer listens on all interfaces and accepts connections
with a "PIN", which is transmitted in the clear (without encryption),
so it is not as secure as a naive user might assume and should probably
not be used in public/untrusted networks.
Make it possible to use the Impress remote with Bluetooth only, which
appears to be more secure, by adding a new setting which defaults to
disabled.
The DiscoveryService which does mDNS/ZeroConf/Bonjour/Renezvous/whatever
-it's-called-today should not be needed for Bluetooth.
Adapt the RemoteServer code to the new situation that there can be a
BluetoothServer but not a IPRemoteServer.
Also add a checkbox to the "Slide Show Settings" dialog.
Change-Id: I0cd3f23b616e23351f166bc9681b45786df8a26a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159786
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
RemoteServer was both an object and a thread instantiated for the IP
server, and a bunch of static methods and data used by all servers.
Split out a class IPRemoteServer.
Move Bluetooth setup to SdDLL::RegisterRemotes().
Also the BluetoothServer was accessing RemoteServer::sCommunicators but
never locked the corresponding RemoteServer::sDataMutex.
Change-Id: I3ff39e68e619af1e91697124a1352b5f20350a22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159785
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: Iadfe05a173bacd236086728ac23de1e610f0bf27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159679
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: If4b5fe0362a40d14d68829bffb79f91ae9745835
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159590
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I4dc708ee57a7e305f4e377bde0e486299df56f0d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158297
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
which prevents constructing unnecessary temporaries via getStr()
Change-Id: I9ca70893a10e954b5ee0e6ad6098660ee24c2bef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150170
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
when applying my upcoming patch to also consider O[U]StringBuffer
Change-Id: Ic95e72e1c857c6814d6e25b9820494cdfa535465
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149746
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
added comment about when the informListenerDestroyed method is called.
Which was requested to be done in the following change review: https://gerrit.libreoffice.org/c/core/+/141468
Change-Id: I34558a5c673ff0e392b91a620b9effc00a8b1376
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142086
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Clearing the listener twice seems to be the problem here, because the WeakComponentImplHelperBase::dispose() tries to access the cleared listener when it was already cleared, causing the crash.
The problem which is fixed by this commit appears when the Impress Remote App is closed, which is connected to a running presentation. So closing the app "kills" the presentation. I think I have seen this also happening, when the connection was closed due to bad wifi. Which also makes sense as the communication thread is getting stopped and the listener will be destroyed.
Change-Id: I3c8fa535cfd4d82c846494f76ffb9ce43ebd606a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141468
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic1e641b1a9373e3ae8da09436b0e8e7b852bede7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138082
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3b80d0f5b6d39c071242bc6ccc1e4333886c835d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137309
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0cd03dcfef02b0ef3bce6bfb88aee4c04d7f6f98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133785
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It's used only for the ConfigurationWrapper singleton, so it's used
only the first time and then ignored. It also causes calls to
comphelper::getProcessComponentContext() for every single invocation
despite the value not being needed, and the calls may not be cheap
(it's ~5% CPU during ODS save because relatively frequent calls
to officecfg::Office::Common::Save::ODF::DefaultVersion::get()).
Change-Id: I02c17a1a9cb498aeef220ddd5a0bde5523cb0ffb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131056
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
See tdf#42949 for motivation
Change-Id: I97c1a0e8c7f26807b12e6062581066d09ea13086
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130114
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I55ae2617b7464fa2b0cad0ad53e660dee704805c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127633
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3eddb816734cd31f0d60344b51e8386c9a551ec7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124969
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I82dc012188f846161beeb54901c2f5d298e5c3b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124385
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The scenarios are:
1. Calling sequence's begin() and end() in pairs to pass to algorithms
(both calls use getArray(), which does the COW checks)
2. In addition to #1, calling end() again when checking result of find
algorithms, and/or begin() to calculate result's distance
3. Using non-const sequences in range-based for loops, which internally
do #1
4. Assigning sequence to another sequence variable, and then modifying
one of them
In many cases, the sequences could be made const, or treated as const
for the purposes of the algorithms (using std::as_const, std::cbegin,
and std::cend). Where algorithm modifies the sequence, it was changed
to only call getArray() once. For that, css::uno::toNonConstRange was
introduced, which returns a struct (sublclass of std::pair) with two
iterators [begin, end], that are calculated using one call to begin()
and one call to getLength().
To handle #4, css::uno::Sequence::swap was introduced, that swaps the
internal pointer to uno_Sequence. So when a local Sequence variable
should be assigned to another variable, and the latter will be modified
further, it's now possible to use swap instead, so the two sequences
are kept independent.
The modified places were found by temporarily removing non-const end().
Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I7d15e9a8c37c29cd6d51c2000f72d1961cd6ff62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123029
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
enforce it by making the constructor parameter non-default.
Change-Id: I321543e4dcf15ea0a43ad8cce91d2f8dc22df6ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122766
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0a9b238c0ba551b330bee7b89eb6cd48fad1b265
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121488
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This follows the pattern in osl::Socket which also cleans up on
destruction if necessary.
By closing on destruction we can avoid leaking the underlying socket or
filedescriptor in the numerous scenarios where we throw away the socket
without bothering to call close(). This isn't a big deal in normal
usage - we don't use many sockets in the first place - but you can
quickly run out of filedescriptors when running sufficiently complex
tests.
We also need to make BufferedStreamSocket final to avoid triggering
loplugin:fragiledestructor - BufferedStreamSocket probably should
have been final anyway, so there's no reason not to do so.
Change-Id: I90c271df4b598a6c2b326fde13543e6b27d7a110
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119093
Tested-by: Jenkins
Reviewed-by: Andrzej Hunt <andrzej@ahunt.org>
|
|
This should make it easier to understand the handshake sequence.
Change-Id: If06e98cdfe7295ed00efae61815a8696a90e9533
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119085
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Since ???, this code now lives in a standalone method, allowing
us to return as soon as know that the handshake is complete. This
lets us remove aFound and simplify the code a little.
Change-Id: I51d5281492d2e4280a101e67d606073f4d064c29
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119084
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The following loop can turn into an infinite loop if the client
disconnects at the wrong point in time, because pSocket->readLine()
returns 0 (indicating disconnection), aLine remains empty (no data
was read), and we just keep looping because we never bothered to check
the return value:
do
{
pSocket->readLine( aLine );
}
while ( aLine.getLength() > 0 );
Aside from spinning unnecessarily, this infinite loop also stops the
server from being able to accept any new incoming connections - in
effect this causes a DOS of the server.
Hence we need to start checking readLine's return value, and break out
of this loop - and in fact break of the surrounding outer loop too
(because we discard this connection and want to wait for another
connection to arrive).
Because of the nested looping it's hard to come up with a clean solution
that only involves changing this loop - we'd probably need to introduce
a temporary to remember that the client has disconnected, and check that
temporary after the do...while - letting us 'continue' the outer loop.
Therefore we first extract the code that handles newly accepted clients
into a separate method, which then lets us simplify the implementation
by returning at those points that we know a client has disappeared. That
unfortunately makes this bug-fix patch a little more noisy than
expected, but it is a refactoring that we'd want to make anyway.
(There are further improvement we can make here, but I'll put those in a
separate commit to simplify cherry-picking of just this fix. Examples
include moving to smart pointers instead of new/delete, introducing an
early return instead of the really long if statement, etc.)
Change-Id: I13c6efa622a1b1de10b72757ea07e5f4660749fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119083
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The entire if statement was introduced only to check for experimental
mode in the following commit - the xContext check is seemingly only
needed for null safety:
79c1b16a96a6 (sdremote: make it possible to have only bluetooth enabled, 2012-11-27)
Later, the epxerimental mode check was disabled in:
b9d2671ae11d (merge WiFi support into remote control feature toggle, 2013-08-01)
Given that the remote is clearly no longer experimental, it's
time to remove the commented code entirely - and I think it's also
safe to remove the xContext check too. (Note: the remote IS still
controlled by the EnableSdRemote option, and IS disabled by default.)
Change-Id: Id118924021d5029b4f15df9cbb3eba28f3b902c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119091
Tested-by: Jenkins
Reviewed-by: Andrzej Hunt <andrzej@ahunt.org>
|
|
Make mProcessingRequired's name a bit more self-explanatory to make it
clear what we're actually using it for. See also a 8e6cdb0 which
fixed a race condition caused by incorrect use of this Condition.
Change-Id: I6ad63dbd5ae8ed767f42ea22e568ac47a4d08642
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118752
Tested-by: Jenkins
Reviewed-by: Andrzej Hunt <andrzej@ahunt.org>
|
|
We need to acquire the mutex in notifyFinished() to avoid a race between
notifyFinished() and the loop in run(). And we also need to check
mFinishRequested) while holding the mutex to avoid the same race
condition. While we're here, rename the mutex to make it more obvious
that it's not only protecting the queues.
The race can happen because the loop in run() blocks until
mQueuesNotEmpty is set. It also resets mQueuesNotEmpty at the end of
each iteration if the queues are empty. So if someone sets
mQueuesNotEmpty in the middle of an iteration, and the loop later resets
it, the loop won't continue iterating. But we're actually using
mQueuesNotEmpty to indicate either that the queues have data OR that we
might want to finish transmission.
And the problem is that notifyFinished() sets mFinishRequested, followed
by setting mQueuesNotEmpty in an attempt to get the loop to process
mFinishRequested (at which point the loop should finish and return).
But as described above, we can easily get into a situation where the
loop resets mQueuesNotEmpty again (at least if there's no more pending
data in the queues). In this scenario, the loop blocks forever
(we won't receive any new messages after notifyFinished()), causing a
leak of both Transmitter and any resources it's using - e.g. the
StreamSocket.
The easiest way to fix this is to make it clear that the mutex protects
all internal state, followed by using it to protect all internal state.
This issue is not a big deal in normal usage - it's a tiny leak, and
users won't connect enough clients for accumulated leaks to pose
any issues. But it's ugly, and potentially problematic for long-running
tests which could run out of filedescriptors because of the socket leak.
I will rename mQueuesNotEmpty to something more obvious (possibly
mProcessingRequired) in a separate commit.
Change-Id: I2e22087054f3f6a02e05c568b1832ccc5a8b47a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118751
Reviewed-by: Andrzej Hunt <andrzej@ahunt.org>
Tested-by: Jenkins
|
|
Change-Id: I8c2eda406d8266996eaf023072cc7f4f38edc4a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102902
Tested-by: Jenkins
Tested-by: Andrzej Hunt <andrzej@ahunt.org>
Reviewed-by: Andrzej Hunt <andrzej@ahunt.org>
|
|
Change-Id: I822313ee708935dd4ecb636c13a961fdd054d660
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116434
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for
operator call arguments. (The "rather than copy, pass subView()" diagnostic is
already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly
for operator call arguments.)
(And many call sites don't even require an explicit [u16]string_view, esp. with
the recent ad48b2b02f83eed41fb1eb8d16de7e804156fcf1 "Optimized OString operator
+= overloads". Just some test code in sal/qa/ that explicitly tests the
O[U]String functionality had to be excluded.)
Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
pulled from a larger patch which I created with a more permissive
variant of this plugin
Change-Id: I7abf1f3f09e84703b6e0e52fe9587dff691b2187
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114875
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which can use the more efficient *StringConcat
Also fix a crash in stringview plugin which
started happening while I working on this.
Change-Id: I91a5b9b7707d1594d27d80b73930f5afac8ae608
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114568
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic439140d9ecdcdee9272185bd3c2d11e11288f07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112051
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I360874fb66c9359abf46a00116d73f87ad122168
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106083
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ieb02e9ae91123bcf1decc141a43fe7e985bf47f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105703
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
|
|
(In VisitVarDecl, filtering out AbstractConditionalOperator avoids an unhelpful
> ~/lo/core/vcl/source/pdf/XmpMetadata.cxx:63:32: error: replace single use of literal 'rtl::OString' variable with a literal [loplugin:elidestringvar]
> aXmlWriter.content(sPdfConformance);
> ^~~~~~~~~~~~~~~
> ~/lo/core/vcl/source/pdf/XmpMetadata.cxx:52:21: note: literal 'rtl::OString' variable defined here [loplugin:elidestringvar]
> OString sPdfConformance = (mnPDF_A == 1) ? "A" : "B";
> ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
)
Change-Id: I7d0410f04827d79b4b526752917c37d33cad2671
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104911
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
do more like
commit 121771e37f7e2de41cd5643475861062bf25627b
Date: Mon Sep 21 09:17:54 2020 +0200
Make some OUStringLiteral vars constexpr
cause coverity can live with that
Change-Id: I9efd7f848289c4865997a44c6780373068422227
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This is a prerequisite for making conversion from OUStringLiteral to OUString
more efficient at least for C++20 (by replacing its internals with a constexpr-
generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount,
conditionally for C++20 for now).
For a configure-wise bare-bones build on Linux, size reported by `du -bs
instdir` grew by 118792 bytes from 1155636636 to 1155755428.
In most places just a u"..." string literal prefix had to be added. In some
places
char const a[] = "...";
variables have been changed to char16_t, and a few places required even further
changes to code (which prompted the addition of include/o3tl/string_view.hxx
helper function o3tl::equalsIgnoreAsciiCase and the additional
OUString::createFromAscii overload).
For all uses of macros expanding to string literals, the relevant uses have been
rewritten as
u"" MACRO
instead of changing the macro definitions. It should be possible to change at
least some of those macro definitions (and drop the u"" from their call sites)
in follow-up commits.
Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Add some API to O*StringLiteral, to make it easier
to use in some places that were using O*String
Change-Id: I1fb93bd47ac2065c9220d509aad3f4320326d99e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100270
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4a7a3771890e3b7f782954a1bdce9e55db99739c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97656
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ifa8b9cb2a6c06e0365245790cfd1c4775bd87d15
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93861
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
