Requires some transparency that macOS can fill with dark/clear/tinted
values. To achieve this, the white background of the main icon and its
shadow was removed temporarily and the icon expanded to fill the space.
Change-Id: Ib82b457c038ff237c7f3b60441ec915a91d040e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192008
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
* Switch to using filenames for the profiles that do not embed the
path of the confined executable, in line with upstream AppArmor
* Use an AppArmor variable for the installation directory, that only
needs to be substituted once into each profile file
* Update the `apparmor.sh` installation script in line with the
above, tweak the sed pattern to avoid the need to escape the
install-directory string, and don't let trailing slashes in the
arguments lead to double slashes in the outputs.
Change-Id: I3400290659a4dd56aa8b7efb2aecf2cf4cd8c49d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190843
Tested-by: Jenkins
Reviewed-by: René Engelhard <rene@debian.org>
Tested-by: René Engelhard <rene@debian.org>
General:
* Replace `#include` directives with `include`, as AppArmor no longer
favors the former syntax
* Clean up trailing whitespace, indent with spaces instead of tabs
* Add `include` directive for site-specific additions/overrides
* Replace `/{,var/}run` with the more modern `@{run}` variable
program.oosplash:
* Add `complain` flag for opt-in enforcement
* Use `abstractions/nameservice`, and remove rules made redundant by
it. This also fixes violations like
`2025-09-06T23:14:05.973442-04:00 test-ubuntu64 kernel: audit: type=1400 audit(1757214845.971:163): apparmor="ALLOWED" operation="connect" class="file" profile="libreoffice-oosplash" name="/run/nscd/socket" pid=2643 comm="oosplash" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=0`
* Remove rules already made redundant by abstractions/X
program.soffice.bin:
* Add Google copyright attribution for the `tofu.db` addition to the
`gpg` child profile
* Add `complain` flag for opt-in enforcement
* Re-sort list of abstraction `include` directives
* Add abstractions: dri-enumerate, mesa, opencl-*
* Simplify rule for temporary file, as the number of `?` characters
needed appears to vary in the wild
* Add missing gvfsd rule to avoid violations like
`2025-09-06T23:14:32.508946-04:00 test-ubuntu64 kernel: audit: type=1400 audit(1757214872.491:167): apparmor="ALLOWED" operation="connect" class="file" profile="libreoffice-soffice" name="/run/user/1000/gvfsd/socket-Qaq0BKpG" pid=2669 comm="soffice.bin" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000`
* Remove all `/path/to/dir/ r,` rules that are made redundant by the
`/**/ r,` rule
* Remove GStreamer rule already made redundant by abstractions/X
* Add rule for access to java.security
* Remove libdrm rule made redundant by abstractions/dri-enumerate
* Add rules for access to Thunderbird configuration
* Add a couple of rules to the `gpg` child profile, taken from patches
used in Debian/Ubuntu
Change-Id: I4a558d7cc809c0c2afd55fab0cf74800e1efc9e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190686
Tested-by: Jenkins
Reviewed-by: René Engelhard <rene@debian.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
the parent-launch constraints worked for their intended purpose, but for
the wrong reason. External launches weren't blocked because the parent
didn't match the constraints, but because the parent didn't have stuff
defined/stuff that the OS didn't recognize. And that then also blocked
the xpdfimport helper, which is used to import PDFs into LibreOffice.
The parent-constraints are set via the --launch-constraint-parent flag
when running codesign, but was also added as an additional dict layer in
the plist file, and that apparently is not valid, but still accepted.
In Console.app, the block should be logged with
c[4]p[2]m[1]e[0], (Constraint not matched)
constraint identifier 4, i.e. launch constraint
process identifier 2, i.e. related to the parent process
match result 1, i.e. the launch constraints not matched
error code 0, i.e. no error
instead it was
c[4]p[2]m[5]e[5], (parent-constraints)
a generic parent-constraints error with
match result 5, "The operating system couldn’t match the executable file
with the constraint, because the constraint contains a non-optional fact
that isn’t defined for the executable file."
so far no difference to the expected validation error, but the
error code is 5, "The launch constraint contains a fact that the
operating system doesn’t recognize."
So even LibreOffice itself didn't qualify as a parent process and the
xpdfimport helper was blocked.
see also:
https://developer.apple.com/documentation/security/applying-launch-environment-and-library-constraints
Change-Id: I0debdb87f04a69f58fcb543d027bdc3b9a4ea0cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187412
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
The necessity of including the CFBundleSupportedPlatforms key in an
application that does not include the Intel architecture is described
in the following post:
https://github.com/microsoft/vscode/issues/121169#issuecomment-820653677
The above post is quoted below:
"Its just an issue with which attribute the storage info queries to
decide the kind, the output of system_profiler SPApplicationsDataType -xml
shows the arch_kind is arch_ios. I think these look for
CFBundleSupportedPlatforms attribute and if not present default to the ios
kind for arm64 executables.
Given the universal and intel labels show up correctly, and considering
the output of other apple silicon apps in the image posted. I don't think
this needs a fix, but leaving it open for anyone to address as a good
first issue."
Change-Id: Ic96ce4407e060fbb0cb8c7b0b72dcf8f61dade19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184738
Tested-by: Jenkins
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.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>
...which builds the spec file's code in a dedicated directory now, see
<https://github.com/rpm-software-management/rpm/issues/2078> "RFE: introduce an
rpm-controlled per-build directory to builds", and no longer in the directory
from which rpm is invoked. So invent some libo_start_dir parameter to
communicate that directory into the rpm build.
Change-Id: I28268837caafe3b892f76e936dfa747fe13fb9bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173779
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
…by a simple/static $(gb_CustomTarget_workdir)/foo
The build system has a lot of overly complicated leftovers from when it
was introduced and had not only deal with split repositories but also
had to coexist with another buildsystem. Along with lots of copy'n'paste
along the years the makefiles became hard to grasp for newcomers with
all our calls and evals.
As a first step to streamline that, the macros from TargetLocations that
simply prefix a static path to the argument (and similar of the same
kind) are a natural pick before simplifying the rules themselves/getting
rid of a bunch of eval statements.
Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
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 packaging recipes.
Change-Id: I934863f6c8e05728e85278568899f581d749e0ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160664
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
* officecfg: deprecate Inet::Settings::ooInetFTPProxyName/Port
* ucbhelper: stop handling these settings
* sfx2: remove SID_INET_FTP_PROXY_NAME and SID_INET_FTP_PROXY_PORT
and usage from SfxApplication::GetOptions()
* shell: remove proxy config code from backends
* stoc: the JavaVM would have its "ftp.proxyHost" properties set based
on officecfg values; remove that
* sysui,vcl: remove protocol from KDE desktop files and file picker
Change-Id: Iba02676cf6e519e2fa60ba925209436d38e75f49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159500
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Added more images inside the app/mimetype .ico files to avoid bluriness in Windows
Change-Id: Ie3ccc6f26ab21b2261a2964a70821473c413d86c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148485
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
https://issues.oasis-open.org/browse/OFFICE-3745 was resolved.
Replace all wrong:
application/vnd.oasis.opendocument.database
with:
application/vnd.oasis.opendocument.base
There is an identifier "org.oasis-open.opendocument.database"
being used in some MacOSX Info.plist files - there is no indication that
it needs to "match" the mime-type so leave it as is.
Change-Id: Ic8e0d24e3aa74743801a670846daf2d322c33d70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146040
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Now the headings in the ulf files for .desktop files are
in the form [filename_Key]
Gallery names are also adjusted to fit the new scheme, where there is
no longer a need to pass a --key argument to desktop-translate.py
Sync comments with .desktop files and the remaining .ulf and remove
obsolete Mandriva Linux meta data while at it.
Script to mass-replace relevant names in translations will be
provided to infra.
Change-Id: I87e8028aa5b66f5f5560efa62ddd9b1e5b61c49c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138455
Tested-by: Jenkins
Reviewed-by: Sophie Gautier <sophi@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Updated .ico files based on the new hicolor icons
Also deleted those that were not listed in any WinResTarget file
Change-Id: If536ea51518d531918b4dda2d2330d7cc7487c93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143885
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
- Replaced old with new hicolor icons
- Added files wherever were gaps
- Changed non-oasis mimetype files to symlinks
- Removed "draw.svg" and put "drawing.svg" in scalable
- Added "macos" directory for special MacOS icons
Change-Id: Id10a386f6144db4f0a1a7a118c44687fffbe0568
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139754
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
without those submitting a build for external testing via testflight is
not possible because appstore thinks you were using a beta version of XCode
Change-Id: I6979a9d290c3e67dd9969d6e535625760b639c25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141496
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
- Removed all 32x/64x/128x/256x/512x/1024x svgs as their corresponding pngs can be created by using the svgs found in scalables directory
- Removed 22x22 assets as they were used only within KDE apps but KDE has its own LibreOffice 22x22 icons anyway
- Moved extensions.svg as it was probably misplaced
- Removed math.png that was not meant to be in a mimetypes directory
- Renamed 1024x1024 to 512x512@2x (for HiDPI) directory as 1024x1024 is not a standard hicolor directory
Change-Id: I6fe333abb5de6d403e43fc4aa5c7c2a1326c4250
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139715
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
This change was added in commit 6ed597a7dd
for unclear reasons (that wasn’t asked for in the bug report), and,
besides, it solves an inexistent problem. No one has been confused on their
expectations after clicking this launcher on their app selector or Start menu.
For anyone looking, it is an obvious thing that, if presented with a set of
launchers like:
LibreOffice
LibreOffice Writer
LibreOffice Calc
...
... the option that isn’t specific will launch a general interface. That’s just simple.
“Start Center” is not the brand name of an application. Although, technically, it is
a module, for users, it’s just a welcome screen, to which OOo has added a glorified
name (it seems we’re experts on inventing weird terms for everyday UI paradigms…
just see “NotebookBar”, which is just a ribbon; deal with it).
It shouldn’t be present in the main launcher for the same reason we don’t add
the word “Dialog” to the title of every dialog.
Change-Id: I3703299fcb8a8244c721631c3107c9f9d3264d83
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139805
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Having the personal-information.addressbook entitlement is not enough.
Without the plist key NSContactsUsageDescription, macOS will not ask the
user to grant access and the request is implicitly denied without any
feedback/logging.
Change-Id: I954fa86b35a128f08e5c498191bc0949e0edeebf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136619
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Our baseline is CentOS 7, it's safe to switch to xz that is supported there.
Here is my measurement on rpm package build time and package size on a
48 core machine, however 48 cores were never used (8-10 max). Compared to
reference w9.gzdio which was used before the patch.
Compression Build Package
method time % size %
w9.gzdio 100% 100%
w7T.xzdio 69% 66%
w6T.xzdio 62% 67%
w5T.xzdio 55% 67%
w4T.xzdio 41% 70%
w3T.xzdio 31% 73%
w2T.xzdio 26% 75%
w1T.xzdio 24% 77%
Conclusion: we'd like to optimize rather for the build time, therefore
w1T.xzdio was picked. The package size was still smaller than the reference
size, and the build time was 4x faster (in this measurement 18m16 -> 4m26).
That makes a difference.
Change-Id: Iabb532628d38a2d5091fa41fd08bfee69007d0ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128800
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
but it's not a spreadsheet
since...
commit dad7fe7227
Date: Thu Jan 2 16:16:55 2014 +0100
Fix math categories to make SUSE rpm check happy
Change-Id: I0397ea12cd7f29f4b0c1f0e0ad76a3429b55c455
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116884
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Previously, all of the README files have been renamed to README.md
and now, the contents of these files were changed to use Markdown
format. Other than format inconsistency, some README.md files lacked
information about modules, or were out of date. By using LibreOffice
/ OpenOffice wiki and other documentation websites, these files were
updated. Now every README.md file has a title, and some description.
The top-level README.md file is changed to add links to the modules.
The result of processing the Markdown format README.md files can be
seen at: https://docs.libreoffice.org/
Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Renaming all README files for all top level modules to README.md,
applying no content change at this stage to be able to track history
of the files. These files should be edited to use correct Markdown
syntax later.
Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Installed as:
/usr/share/application-registry/libreoffice.applications
/usr/share/mime-info/libreoffice.keys
/usr/share/mime-info/libreoffice.mime
Superseded by Shared MIME-info compliant libreoffice.xml, created as
openoffice.org.xml by create_mime_xml.pl from the .desktop files.
Change-Id: Ib8d9a17d09139dd4f50f65572457cef0178750b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105606
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
These SVG icons are the source for the PNG icons in the same
directories.
scalable/mimetypes icons each contain the source for all sizes of
PNG icons and are not usable themselves.
The locolor theme is incomplete with only low resolution icons.
Change-Id: I2bc54cfbfec012c29a41e1d954d313c19a47831e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99444
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
With 315919306c "Set PYTHONWARNINGS to error by
default for --enable-werror" my build on Fedora 32 started to fail in
CustomTarget_sysui/share with
> Exception ignored in: <socket.socket fd=4, family=AddressFamily.AF_UNIX, type=SocketKind.SOCK_STREAM, proto=0>
> Traceback (most recent call last):
> File "/usr/lib/python3.8/site-packages/abrt_exception_handler3.py", line 93, in write_dump
> response = send(data)
> ResourceWarning: unclosed <socket.socket fd=4, family=AddressFamily.AF_UNIX, type=SocketKind.SOCK_STREAM, proto=0>
> Traceback (most recent call last):
> File "/usr/bin/g-ir-scanner", line 103, in <module>
> from giscanner.scannermain import scanner_main
> File "/usr/lib64/gobject-introspection/giscanner/scannermain.py", line 35, in <module>
> from giscanner.ast import Include, Namespace
> File "/usr/lib64/gobject-introspection/giscanner/ast.py", line 29, in <module>
> from .sourcescanner import CTYPE_TYPEDEF, CSYMBOL_TYPE_TYPEDEF
> File "/usr/lib64/gobject-introspection/giscanner/sourcescanner.py", line 24, in <module>
> from .libtoolimporter import LibtoolImporter
> File "/usr/lib64/gobject-introspection/giscanner/libtoolimporter.py", line 21, in <module>
> import imp
> File "/usr/lib64/python3.8/imp.py", line 31, in <module>
> warnings.warn("the imp module is deprecated in favour of importlib; "
> DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
Change-Id: I919caaad482e844ef1549f248a2faf2274c9efa0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103177
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Heiko Tietze