Your message dated Tue, 25 Feb 2025 19:11:21 +0100
with message-id <03630333-35d2-4f07-8ab9-a6d3a9911...@debian.org>
and subject line Re: Bug#1098838: libreoffice-common:
/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin fails to parse/load
with apparmor 4.1.0-beta5-2
has caused the Debian Bug report #1098838,
regarding libreoffice-common:
/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin fails to parse/load
with apparmor 4.1.0-beta5-2
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1098838: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098838
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libreoffice-common
Version: 4:24.8.5-2
Severity: normal
With current apparmor version in sid (4.1.0~beta5-2)
/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin fails to parse
and load.
-steps to reproduce: --------------------------
# apparmor_parser -r usr.lib.libreoffice.program.soffice.bin
Too many states (113206) for type state_t
----------------------------------------------
It takes ages:
# time apparmor_parser -r usr.lib.libreoffice.program.soffice.bin
Too many states (113206) for type state_t
real 1m49,880s
user 1m49,752s
sys 0m0,100s
Best regards
-- Package-specific info:
Configuration file Package Exists Changed
/etc/libreoffice/registry/Langpack-en-US.xcd libreoffice-common Yes No
/etc/libreoffice/registry/lingucomponent.xcd libreoffice-common Yes No
/etc/libreoffice/registry/main.xcd libreoffice-common Yes No
/etc/libreoffice/registry/pdfimport.xcd libreoffice-common Yes No
/etc/libreoffice/registry/res/fcfg_langpack_e libreoffice-common Yes No
/etc/libreoffice/registry/xsltfilter.xcd libreoffice-common Yes No
-- System Information:
Debian Release: trixie/sid
APT prefers oldstable-security
APT policy: (500, 'oldstable-security'), (500, 'unstable'), (500, 'testing'),
(500, 'stable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.13.4-finwe (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libreoffice-common depends on:
ii libnumbertext-data 1.0.11-4
ii libreoffice-style-colibre 4:24.8.5-2
ii libreoffice-uiconfig-common 4:24.8.5-2
ii ucf 3.0050
ii ure 4:24.8.5-2
Versions of packages libreoffice-common recommends:
ii apparmor 4.1.0~beta5-2
ii fonts-liberation 1:2.1.5-3
ii libexttextcat-data 3.4.7-1
ii poppler-data 0.4.12-1
ii python3-uno 4:24.8.5-2
ii xdg-utils 1.2.1-2
Versions of packages libreoffice-common suggests:
ii libreoffice-style-breeze [libreoffice-style] 4:24.8.5-2
ii libreoffice-style-colibre [libreoffice-style] 4:24.8.5-2
ii libreoffice-style-elementary [libreoffice-style] 4:24.8.5-2
pn python3-scriptforge <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi,
Am 25.02.25 um 14:44 schrieb Jacek Kawa:
1. debsums -e shows every standard apparmor.d as OK/clean,
Hmm, ok
However, based on the second machine preprocessed profile I was able to
pin-point the problem to:
--- bad 2025-02-25 14:29:01.752813380 +0100
+++ good 2025-02-25 14:30:37.570399763 +0100
@@ -155,8 +155,7 @@
# The following is a space-separated list of where additional user home
# directories are stored, each must have a trailing '/'. Directories added
# here are appended to @{HOMEDIRS}. See tunables/home for details.
-@{HOMEDIRS}+=/home/dropbox/
-
+#@{HOMEDIRS}+=
With /home/drobpox added ages ago and actually non-existing.
Where? Not in /etc?
dpkg-reconfigure apparmor -> remove offending entry
and everything works fine now.
A bit of experimenting:
- a valid path outside home -> fine,
- a valid path being nested in home -> 108s of processing,
- an invalid path not nested in /home -> fine,
I can guess now, that having additional "home" nested in the
default one might not be a good idea.
@HOMES already should include /home/dropbox/ if there is a dropbox user? If
not, /home/dropbox is a wrong path to begin with.
In other words:
1. from my perspective the problem is solved,
Good, closing.
Regards,
Rene
--- End Message ---
