Noting that the main feature of using a separate library - avoiding
linking against SM and ICE - is no longer a thing, since we have not
used those in some time.
Change-Id: I9ecd6758e97f0fa19b224346aa577a04b46793b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163638
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
using the bin/find-can-be-private-symbols.py script
to find classes with large numbers of exported symbols
that can hidden.
before
exported = 58104
imported = 30810
unused_exports = 35433
after
exported = 55094
imported = 31073
unused_exports = 32423
Change-Id: Idd0a70ee3740afd5ca1a86771e0e2ff8090d102d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163456
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This reverts commit 2cf7c26293.
Reason for revert:
<_rene_> noelgrandin: sdui->sd... and what about people not needing that ui?
<_rene_> (e.g. --disable-gui and libreoffice-draw-nogui and impress-nogui)
<_rene_> i.e. the use case of --convert-to for ppt(x) etc
Change-Id: I6755c209e63f34b3fc9f9fdc4af7001b18579e8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163348
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
which eliminates another dynamic-symbol lookup and another complication
which was making it harder to do better with --enable-mergedlibs
sd is relatively small, so even the combined library is not as big as
one of the sw and sc libraries
Change-Id: Ibef8077d70a5abc7361c95f5dbb8c43447610188
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163302
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Since
commit 3460799175
Date: Thu Jan 25 23:41:52 2024 +0600
Clear gb_GbuildToJson_DENYLISTEDMODULES, allow these modules
, externals are taken into account in the generation of IDE integrations,
causing errors like this when running `make qtcreator-ide-integration`
to generate the *.pro files for the QtCreator IDE integration:
cd /home/michi/development/git/libreoffice && bin/gbuild-to-ide --ide qtcreator --make make
ERROR : creating pro file=/home/michi/development/git/libreoffice/clucene/clucene.pro
[Errno 2] No such file or directory: '/home/michi/development/git/libreoffice/clucene/clucene.pro'
Traceback (most recent call last):
File "/home/michi/development/git/libreoffice/bin/gbuild-to-ide", line 1787, in emit
with open(qt_pro_file, mode) as fpro:
^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/home/michi/development/git/libreoffice/clucene/clucene.pro'
Fix this by creating the .pro files in a directory that has the same
relative path to the $(BUILDDIR) as the corresponding .mk files have
in the $(SRCDIR) rather than in $(BUILDDIR)/$(LIBNAME)/.
While both are the same for LO's internal modules,
the latter directory does not exist for externals, since
they're located underneath a top-level directory called "external".
For the simple case of an in-tree build, this now e.g.
creates a file `external/clucene/clucene.pro` instead
of failing to create a `clucene/clucene.pro` because there's
no top-level "clucene" directory.
An alternative approach might to just ignore the externals,
as this commit implemented it for the codelite integration:
commit 41c8e09573
Date: Sat Jan 27 21:54:10 2024 +0200
fix codelite-ide-integration
externals seems to be part of the list of modules now, but I
don't know how to deal with that, so just ignore them.
(In that case, they wouldn't be part of the project, speeding
up update of the clang code model after changes, but then not providing
features like code navigation and autocompletion etc.)
Change-Id: Idb04af5f7445955e5dbf9ec3fd8626bbcb09ab11
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162837
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
externals seems to be part of the list of modules now, but I
don't know how to deal with that, so just ignore them.
Change-Id: Ic42d0b27562247b12cf9393659298cda56d1572c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162648
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Filter "empty" targets in Visual Studio solutions: it makes little sense
to add generated files to projects (they aren't intended for editing in
IDE); so most external libraries, which only have "generated" sources,
and aren't part of core anyway, would have zero source files in their
projects - thus excluded.
Handle C++/CLI files; use their specific CXXCLRFLAGS (set them to the
source files explicitly, overriding CXXFLAGS set on the project level).
While here, do the same with CFLAGS and C files.
Do not add H(XX) files (with names identical to C(XX) files) to the VS
projects. This adds a tiny subset of all headers, which is inconsistent.
Change-Id: I6bd932277287d3444bb547b93f2867d226072d60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162582
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...as the former is more convenient for release engineering (see the discussion
in the comments at
<https://gerrit.libreoffice.org/c/core/+/162157/1#message-8d7ebbcc64a87ee8e4a073ae1a05e3b74f5a3d6a>
"Also enable --with-package-format=archive for LibreOfficeWin64.conf").
Instead of ONLINEUPDATE_MAR_OLDARCHIVE and ONLINEUPDATE_MAR_OLDMETADATA make
variables, the create-partial-info target now only needs an
ONLINEUPDATE_MAR_OLDMSI make variable.
TODO: There are two issues when comparing the content of msi files (extracted
with msiexec /a), which the old code comparing the content of archives had tried
to somewhat (but not fully) address with the metadata files that I had invented
(and now reverted): For one, msiexec /a also extracts content that would
normally be installed somewhere else in the system (e.g., it extracts Fonts,
System, and System64 directories). Differences in those directories will cause
a MAR update to create those directories in the installation directory, rather
than to update the corresponding files in their actual locations. For another,
optional components are not recognized as such, but their content must be added
to the MAR file as add/patch-if, not as plain add/patch. To work around that,
for now *all* files are added as add/patch-if, conditional on the files
themselves. Thus, addition of files will cause a MAR update to miss them.
(As they now exclusively operate on msi files, the create-update-info and
create-partial-info targets are no longer meaningful for non-Windows platforms,
so drop the non-Windows bin/update/create_full_mar_for_languages.py part.)
Change-Id: Ifb55b5e7d1a201b4f50a27cb449a634b96c2e29b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162399
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
The "which" utility is not guaranteed to be installed either, and if it
is, its behavior is not portable either. This means that when various
programs are installed, the `which` check will report a fatal error
because the which tool did not exist and the shell returned a nonzero
status when attempting to fork+exec. If it did exist, it might not be an
implementation of `which` that returns nonzero when commands do not
exist.
The general scripting suggestion is to use the "command -v" shell
builtin; this is required to exist in all POSIX 2008 compliant shells,
and is thus guaranteed to work everywhere.
For some in-depth discussions on the topic, see:
- https://mywiki.wooledge.org/BashFAQ/081
- https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then/85250#85250
Examples of open-source shells likely to be installed as /bin/sh on
Linux, which implement the 15-year-old standard: ash, bash, busybox,
dash, ksh, mksh and zsh.
This commit updates a couple build scripts to not rely on fixed paths
calculated upfront. Checking the location of a tool with cmd=$(which
foo) just to run it as `$cmd` is pointless. It's exactly equivalent to
run it as `foo`, but less error-prone and easier to read.
For one of the scripts, it also simplifies checking for their existence.
Personally, I am skeptical it even makes sense to check at all. POSIX
mandates they exist, and it's exceedingly unlikely they will not be
installed. However, unlike the shell interpreter itself, we don't *know*
they are installed, so leave the existing checks in but simplified.
Change-Id: I4703c1165eb3a5aeb45fbab18df3222e8f5f9551
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160665
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
The "which" utility is not guaranteed to be installed either, and if it
is, its behavior is not portable either. This means that when various
programs are installed, the `which` check will report a fatal error
because the which tool did not exist and the shell returned a nonzero
status when attempting to fork+exec. If it did exist, it might not be an
implementation of `which` that returns nonzero when commands do not
exist.
The general scripting suggestion is to use the "command -v" shell
builtin; this is required to exist in all POSIX 2008 compliant shells,
and is thus guaranteed to work everywhere.
For some in-depth discussions on the topic, see:
- https://mywiki.wooledge.org/BashFAQ/081
- https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then/85250#85250
Examples of open-source shells likely to be installed as /bin/sh on
Linux, which implement the 15-year-old standard: ash, bash, busybox,
dash, ksh, mksh and zsh.
This commit updates the build system to configure and build correctly on
systems without `which`.
Change-Id: I23dbde5c7f104dd610fd5f78c82bf9a7d0cc1930
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160663
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
...along the lines of what had already been done for create-update-info, passing
files to the mar executable with an -f files.txt instead of on the command line
(which could grow too long for Windows), and taking the archive metadata into
account.
For the latter, `make create-partial-info` now expects a second make variable,
ONLINEUPDATE_MAR_OLDMETADATA, in addition to ONLINEUPDATE_MAR_OLDARCHIVE. And
there is a new TODO in update/create_partial_update.py that the old and new
metadata should be compared for problematic changes. (For now, any such changes
would just get lost by an update.)
Change-Id: Ide45adedb72958fc32c5b26aa7ebb01530ccf3d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161972
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
I got lost trying to figure out how the original
bin/update/create_partial_update.py code was meant to obtain old and new
installation trees to diff, so I simplified that down to the create-partial-info
make target now expecting an ONLINEUPDATE_MAR_OLDARCHIVE make variable that
points at the old archive install set. (And the
--with-online-update-mar-serverurl configure option is gone for good again.)
The remaining changes are similar to what was needed in
28bad382fa "Fix `make create-update-info` (for
Windows, at least)". (And the mbsdiff and mar tools expect Windows-style
pathnames, but mktemp returns a Unix-style pathname in cygwin shell scripts, so
this needed an additional Windows-only external/onlineupdate/cygpath.patch.)
Change-Id: I40690210d62e3f26fb2d574914a0dd4323e6cd62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161924
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
That make target operates on an archive, but generates data to be applied to an
msi installation, so suffers from any mismatch between archive and msi install
sets. Two such mismatches, at least on Windows, are:
1 Files that msi will install outside the LibreOffice installation itself (but
which for an archive install set are included under LibreOffice/). This covers
(at least) .Net assemblies and associated files that are installed in the GAC
(scp2 styles ASSEMBLY and ASSIGNCOMPONENT) and fonts (scp2 style FONT).
2 Files that msi will only install conditionally. This covers optional
components (many of which in scp2 are assigned to gid_Module_Optional_...
modules) and user interface languages (which in scp2 are assigned to
gid_Module_Langpack_... modules).
The approach taken here is to create a
workdir/installation/LibreOffice/archive/install/metadata file while building an
archive install set, and to record any files matching 1 (as "skip" lines) or 2
(as "cond" lines). Then, the create-update-info target uses that metadata file
to act accordingly on those files:
1 Files from "skip" lines are simply removed for now from the extracted archive
that is passed to Mozilla's make_full_update.sh script. (TODO: That means that
changes to such files will not be updated with the MAR update mechanism. This
would apparently need some extra processing during the MAR update.)
2 Files from "cond" lines shall be recorded as add-if in the mar file manifest.
Mozilla's make_full_update.sh script already has support for emitting add-if vs.
plain add, but only for files under distribution/extensions/, which doesn't
match our needs. So we generate from the metadata file an ifs file that we pass
into the make_full_update.sh script, and patch that script to also take that ifs
file into account. (Each line in the ifs file is of the form
"testfile" "file"
which works as long as none of the pathnames contains double quote characters.
The Mozilla script code appears to be confused about the arguments to
make_add_instruction(), where this ifs file will be needed: There are calls to
make_add_instruction() with two or three arguments across make_full_update.sh
and make_incremental_update.sh, but make_add_instruction() checks $1, $2, and
$4 (but not $3), so leave that mess alone and pass the ifs file as a global
IFSFILE variable instead.)
The mar file manifest `add-if "testfile" "file"` adds "file" only if "testfile"
is already present, and those two can be different files. TODO: However, for
simplicity, for now I always use "file" also as the "testfile" (so that an
add-if file only gets updated if it was already present). That avoids having to
identify a specific "key file" for each optional component and for each user
interface language, where that key file would be used as the add-if testfile.
But on the other hand, it means that if an optional component or a user
interface language will bring along a completely new file in the future, we will
not install that file during a MAR update. What obviously remains to be done is
to properly assign each add-if file to a specific key file. (And the current
way of identifying add-if files by gid_Module_... names appears to be too
simplistic too. For example, there are some gid_Module_Optional_... that are
installed unconditionally for msi; but it should be harmless that those files
are recorded as add-if rather than as plain add.)
Change-Id: I2fdeed92604f3a2d8a0b500b9e3fa421cfb6a9cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161917
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...where, depending on --without-lang/--with-lang=fu ba bz/--with-lang=ALL, the
directory and archive file names appear to vary wildly, so go with a glob
approach instead of trying to guess the exact matching names here
Change-Id: I07355724f28eea66e619eb8d3d83c3e74217f54f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161885
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
* The shell scripts that had once been copied from Mozilla to bin/update/*.sh
are now included in
onlineupdate-c003be8b9727672e7d30972983b375f4c200233f-2.tar.xz (which is still
generated from the same
<https://github.com/mozilla/gecko-dev/commit/c003be8b9727672e7d30972983b375f4c200233f>
that was used for the original tarball in
3a445cb497 "Turn onlineupdate into
external/onlineupdate").
* The additional modifications in external/onlineupdate/lo.patch are:
** Allowing to pass the list of files into the mar tool via -f instead of on the
command line, to avoid "command line too long" errors on Windows, inspired by
the modifications once made directly in our old downstream sources with
4165dd4e46 "add a way to create mar file from
file", 8e4d49340b "use the new file based
approach for the mar creation", and fb13ed6955
"add the manifest file to the mar file". (To keep things simple for now, it
still uses a hard-coded maximum of 10000 lines in the file, marked with a
TODO.)
** Not failing when "precomplete file is missing!" (There is a comment
// Applications aren't required to have a precomplete manifest. The mar
// generation scripts enforce the presence of a precomplete manifest.
in
workdir/UnpackedTarball/onlineupdate/onlineupdate/source/update/updater/updater.cpp
and it appears to be OK that we don't have such a precomplete manifest file
and just skip that test.)
* In the Makefile.gbuild create-update-info, the create_full_mar.py script needs
to be called with a Unix pathname on Windows, or else the
#!/usr/bin/env python3
shebang in that script would get confused.
* The related Makefile.gbuild targets upload-update-info and create-partial-info
have not been addressed yet.
Change-Id: Iab4e083ddbe99e07d846e202f20c6031e2983e1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161656
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
This script was broken, not only in the implementation
(it gives too many false positives in a suspiciously short, <1s time)
but in its approach as well: only considering stuff that is compiled
under Linux inherently leaves out other platform specific or experimental
stuff.
Rewrite it using another approach: grep for mentions of each
header in the modules or global ones in include/ everywhere.
Runtime of this script is about 15 minutes, seems to give only
a few relevant hits.
Change-Id: Ifb92f41f11ca9a2bf14eec617a469003becb78fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161234
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
- fix the most obvious stylistic problems
- add some brief doc strings
- remove one instance of dead code, left over from this change:
commit bd2eee0bd4
Date: Wed Jun 3 23:41:32 2015 +0200
get-bugzilla-attachments: avoid FDO-TDF duplicates...
Change-Id: I88672ae99bc42e9af09ea6033f87240463b2c038
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161003
Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
https://www.rfc-editor.org/rfc/rfc9106.html
* add css::xml::crypto::KDFID constant group
* add "KeyDerivationFunction" to setEncryptionAlgorithms sequence
* Argon2 is used by default for wholesome ODF encryption, but
$LO_ARGON2_DISABLE can be set to use PBKDF2
* extend various structs in package
* use 3 new ODF attributes "loext:argon2-iterations" "loext:argon2-memory"
"loext:argon2-lanes" to store the arguments
* use this URL for now:
"urn:org:documentfoundation:names:experimental:office:manifest:argon2id"
* use default arguments according to second recommendation from "7.4.
Recommendations" of RFC9106; 64 MiB RAM should hopefully not be too
much even for 32 bit builds
Change-Id: I683118cc5e0706bd6544db6fb909096768ac9920
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161009
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
...and update to latest Mozilla sources.
Originally, this was a non-external onlineupdate module (plus correspsonding
top-level include/onlineupdate/ directory) that apparently contained sources
originally copied from Mozilla and subsequently modified in-place (plus, mixed
in, presumably some sources that were not copied from Mozilla but were our own
inventions). To clean up this mess, this has been turned into a proper
external/onlineupdate module with a tarball containing the pristine external
Mozilla sources.
The sources for the onlineupdate-c003be8b9727672e7d30972983b375f4c200233f.tar.xz
tarball are taken, somewhat arbitrarily, from a recent
<https://github.com/mozilla/gecko-dev/commit/c003be8b9727672e7d30972983b375f4c200233f>
("Bug 1867784 - Force reflow all kids in the last column balancing reflow.
r=layout-reviewers,dholbert") trunk state, by running
`external/onlineupdate/generate-sources.sh ~/github.com/mozilla/gecko-dev` on a
Fedora 39 machine.
The layout of the tarball still mostly follows the old onlineupdate/ layout,
even if that deviates heavily from the actual source layout at
<https://github.com/mozilla/gecko-dev/>. (And some files, which apparently are
not needed, anyway, lacked sources, see the "Missing source for" in
external/onlineupdate/generate-sources.sh. And win_dirent.h/.cpp has meanwhile
been superseded by updateutils_win.h/.cpp.) Merely newly included source files
are laid out in the tarball according to the actual source layout.
Any LO-specific modifications are made via patch files (rather than modifying
the sources inline, as was done in the past): external/onlineupdate/lo.patch
contains whatever modifications are needed to adapt the functionality, while
external/onlineupdate/gtk3deprecated.patch fixes
> workdir/UnpackedTarball/onlineupdate/onlineupdate/source/update/updater/progressui_gtk.cpp:97:21: error: use of undeclared identifier 'gtk_vbox_new'; did you mean 'gtk_box_new'?
> 97 | GtkWidget* vbox = gtk_vbox_new(TRUE, 6);
> | ^~~~~~~~~~~~
> | gtk_box_new
to not use the deprecated gtk_vbox_new, which is hidden because we include
-DGTK_DISABLE_DEPRECATED in our GTK3_CFLAGS as per our configure.ac.
On Windows, the definition of __BYTE_ORDER__ etc. is needed because
workdir/UnpackedTarball/onlineupdate/include/mozilla/ says "Our supported
compilers provide architecture-independent macros for this", but MSVC doesn't
actually, so define here what would implicitly be defined by GCC. Similarly, on
Windows -U_WIN32_WINNT is needed to undo -D_WIN32_WINNT=0x0601 in
solenv/gbuild/platform/windows.mk, which would cause
> workdir\UnpackedTarball\onlineupdate\include\mozilla/WinHeaderOnlyUtils.h(537): error C2065: 'FILE_ID_INFO': undeclared identifier
etc., despite the #include <windws.h> there.
Curiously, the original gb_CustomTarget_CustomTarget,onlineupdate/generated from
onlineupdate/CustomTarget_generated.mk had to be renamed to
gb_CustomTarget_CustomTarget,external/onlineupdate/generated when the file was
moved to external/onlineupdate/CustomTarget_generated.mk, as otherwise a
top-level `make CustomTarget_onlineupdate/generated` would have failed with "No
rule to make target..." Also, as there is no gb_CustomTarget_use_unpacked, its
effect has been poorly mimicked for now in
external/onlineupdate/CustomTarget_generated.mk.
Similarly, as there is no gb_WinResTarget_use_unpacked, its effect has been
poorly mimicked for now in external/onlineupdate/WinResTarget_updater.mk.
The original onlineupdate/workben/test_dialog.cxx, which is actually code
written by us, has been moved to external/onlineupdate/workben/test_dialog.cxx.
The original onlineupdate/qa/ sources (which were apparently not used during the
build) have been preserved for now as external/onlineupdate/qa/, for
documentation purposes.
The original onlineupdate/astyle.options (which was apparently not used during
the build) has been removed.
Change-Id: I5ea606202e7837269e7b128e45af2f0b8c277f9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160492
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...and allow each of them to be left off, for debug purposes, even if that may
render the resulting --enable-online-update-mar feature non-functional.
This change tracked each item that was potentially read from the
--with-update-config ini file, and turned each of them into a new
--with-online-update-mar-... option. The only exception and remaining TODO is
bin/update/upload_build_config.py (called from Makefile.gbuild).
distro-configs/Jenkins/LibreOfficeLinuxUpdater.conf (which might well be dead)
set --with-update-config=~/updater.ini with an ini file of unknown content. So
that no items are silently missing if we ever resurrect that distro-config, I
set all of the new options to =TODO there for now.
Change-Id: I17a13e0d190a868436bac10c1b0a6675d8c704c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160622
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
157298bb80 "android and bin/update: make pythonic"
had removed it, so that `make create-partial-info` would now fail at least with
> Traceback (most recent call last):
> File "bin/update/create_partial_update.py", line 10, in <module>
> from path import UpdaterPath, mkdir_p, convert_to_unix, convert_to_native
> ImportError: cannot import name 'mkdir_p' from 'path' (bin/update/path.py)
(and no idea if that make target would still do anything useful, beyond this
initial hurdle)
Change-Id: Ib1be3304e2b3468dc187c1b5e24041e68a3677fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160397
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
157298bb80 "android and bin/update: make pythonic"
had introduced this apparent typo, so that `make create-update-info` would now
fail (and no idea if that make target would still do anything useful, beyond
this initial hurdle)
Change-Id: I63c4e87e06370d99e5d036ce5c7f2a5bda3c1554
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160398
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
With GNU gdb (Debian 13.2-1) 13.2, I noticed this trace on console when using --backtrace
Warning: 'set logging on', an alias for the command 'set logging enabled', is deprecated.
Use 'set logging enabled on'.
Change-Id: Ic03911ea94aff57dee8f594744147302ef01a1ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160143
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
are used at all, if they have an otherwise unused group as template
TODO: Still gives some false positives if a group is only used
as template of a set which is only used as template of another
set which is actually used (MergeToolBarInstruction MergeStatusBarInstruction)
Change-Id: Ia2f83c12a4e0bdcc88b1530bac4daaf456531f8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159297
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Noel Grandin