Bug#1009703: grafx2: Grafx2 text tool true-type font rendering is garbled

[Ryan Armstrong]

On Thu, 2022-04-14 at 17:30 +, Adrien Destugues wrote:
> 14 avril 2022 18:22 "Ryan Armstrong"  a écrit:
> 
> > When I attempt to use the text tool in recent versions of Grafx2,
> > the
> > font rendering is garbled for all True-Type fonts. If I press OK,
> > the
> > resulting brush is the same way. See attachment for an example.
> > 
> > I previously used the text tool in December 2021 and did not have
> > the
> > problem then.
> 
> Thanks for reporting, I'll see if I can reproduce this.
> 
> > As an aside, the upstream bug tracker appears to be misconfigured
> > and
> > the Google login reports "Error 400: redirect_uri_mismatch".
> 
> This happens when you are not using https. Please use https to access
> the bugtracker.
> 

Ah, it seems the URL that Debian points to is just for HTTP (e.g.
from https://tracker.debian.org/pkg/grafx2). Let me know if you'd like
me to raise anything in the upstream tracker.

Ryan

Bug#1009703: grafx2: Grafx2 text tool true-type font rendering is garbled

[Ryan Armstrong]

Package: grafx2
Version: 2.8+ds-2
Severity: normal
Tags: upstream

Dear Maintainer,

When I attempt to use the text tool in recent versions of Grafx2, the
font rendering is garbled for all True-Type fonts. If I press OK, the
resulting brush is the same way. See attachment for an example.

I previously used the text tool in December 2021 and did not have the
problem then.

As an aside, the upstream bug tracker appears to be misconfigured and
the Google login reports "Error 400: redirect_uri_mismatch".

Ryan

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages grafx2 depends on:
ii  fonts-tuffy  20120614-2.1
ii  libc62.33-7
ii  libfontconfig1   2.13.1-4.4
ii  liblua5.3-0  5.3.6-1
ii  libpng16-16  1.6.37-3
ii  libsdl2-2.0-02.0.20+dfsg-2
ii  libsdl2-image-2.0-0  2.0.5+dfsg1-3+b1
ii  libsdl2-ttf-2.0-02.0.18+dfsg-2
ii  libtiff5 4.3.0-6
ii  libx11-6 2:1.7.5-1
ii  zlib1g   1:1.2.11.dfsg-4

grafx2 recommends no packages.

grafx2 suggests no packages.

-- no debconf information

Bug#1002732: needrestart stalled in background when performing update with KDE Discover

[Ryan Armstrong]

Perhaps I spoke too hastily earlier, or perhaps the issue only manifests for 
certain update sets. I have seen the issue again a couple times in the past 
week or so.

When I performed a manual `apt install` to install a random package after, I 
received a notice that a newer kernel is available. Perhaps that's it?

Also note that I have never actually received a desktop notification from 
debconf-kde-helper, if that was supposed to be the intended behaviour, so 
perhaps this bug should just be reassigned to that package?

Ryan

On Sunday, January 2, 2022 8:22:19 A.M. EST Ryan Armstrong wrote:
> So, I actually just installed my regular updates today with Discover and
> noticed a few library changes. The update completed properly. If I run
> needrestart after (or do an apt install), it confirms it wants to restart
> some libraries. I can continue to install other packages with Discover as
> well. So it looks like that package was all I needed.
> 
> Thanks,
> Ryan
> 
> On Saturday, January 1, 2022 8:42:26 A.M. EST Thomas Liske wrote:
> > Hi,
> > 
> > could you check running needrestart as root on cli if you have any
> > pending restarts?
> > 
> > You might try to reinstall a lib to trigger needrestart (i.e. via apt-
> > get install --reinstall libnss3 - this *should* not break anything) to
> > force to get a pending restarts.
> > 
> > Please check if needrestart and debconf-kde-helper are working when
> > using KDE Discover afterwards.
> > 
> > 
> > Regards,
> > Thomas
> > 
> > On Fri, 2021-12-31 at 10:10 -0500, Ryan Armstrong wrote:
> > > I did not, but your message prompted me to go looking a bit. I found
> > > I had
> > > not installed debconf-kde-helper. I would have expected a package
> > > like this to
> > > get pulled in when I installed KDE, so I expect it is missing as a
> > > dependency
> > > (for plasma-discover perhaps?)
> > > 
> > > In my setup, KDE was installed onto an existing setup by running `apt
> > > install
> > > kde-plasma-desktop`
> > > 
> > > I did one update after installing the helper, but didn't notice
> > > anything (it
> > > didn't stall, though). As long as that fixes the problem, I guess
> > > this bug
> > > should be redirected as a dependency issue?
> > > 
> > > Ryan
> > > 
> > > On Friday, December 31, 2021 9:54:02 A.M. EST you wrote:
> > > > Hi Ryan,
> > > > 
> > > > needrestart should not block if it is run non-interactive. On
> > > > Debian it
> > > > uses the debconf frontend which also has graphical frontends. Do
> > > > you
> > > > get debconf dialogs in KDE Discover when installing/updating
> > > > packages
> > > > at all? (Sorry I do not have an KDE environment for testing.)
> > > > 
> > > > 
> > > > Regards,
> > > > Thomas
> > > > 
> > > > On Tue, 2021-12-28 at 08:33 -0500, Ryan Armstrong wrote:
> > > > > Package: needrestart
> > > > > Version: 3.5-5
> > > > > Severity: normal
> > > > > 
> > > > > Dear Maintainer,
> > > > > 
> > > > > When I performed an update with KDE Discover, I noticed it
> > > > > stalled at
> > > > > 99% complete status and would not finish. When I checked the
> > > > > process
> > > > > tree with htop, I noticed the following lines from packagekitd
> > > > > and
> > > > > 
> > > > > needrestart:
> > > > >2629 root   20   0  492M  124M 79624 S  0.0  0.8  0:29.20
> > > > > 
> > > > > ├─
> > > > > /usr/libexec/packagekitd
> > > > > 
> > > > >2632 root   20   0  492M  124M 79624 S  0.0  0.8  0:00.00
> > > > > 
> > > > > │
> > > > > ├─ /usr/libexec/packagekitd
> > > > > 
> > > > >2634 root   20   0  492M  124M 79624 S  0.0  0.8  0:00.05
> > > > > 
> > > > > │
> > > > > ├─ /usr/libexec/packagekitd
> > > > > 
> > > > >   14075 root   20   0  492M  124M 79624 S  0.0  0.8  0:05.78
> > > > > 
> > > > > │
> > > > > ├─ /usr/libexec/packagekitd
> > > > > 
> > > > >   14090 root   20   0  494M 99648 50800 S  0.0  0.6  0:00.24
> > > > > 
> > > > > │
> > > > > └─ /u

Bug#1002732: needrestart stalled in background when performing update with KDE Discover

[Ryan Armstrong]

So, I actually just installed my regular updates today with Discover and 
noticed a few library changes. The update completed properly. If I run 
needrestart after (or do an apt install), it confirms it wants to restart some 
libraries. I can continue to install other packages with Discover as well.
So it looks like that package was all I needed.

Thanks,
Ryan

On Saturday, January 1, 2022 8:42:26 A.M. EST Thomas Liske wrote:
> Hi,
> 
> could you check running needrestart as root on cli if you have any
> pending restarts?
> 
> You might try to reinstall a lib to trigger needrestart (i.e. via apt-
> get install --reinstall libnss3 - this *should* not break anything) to
> force to get a pending restarts.
> 
> Please check if needrestart and debconf-kde-helper are working when
> using KDE Discover afterwards.
> 
> 
> Regards,
> Thomas
> 
> On Fri, 2021-12-31 at 10:10 -0500, Ryan Armstrong wrote:
> > I did not, but your message prompted me to go looking a bit. I found
> > I had
> > not installed debconf-kde-helper. I would have expected a package
> > like this to
> > get pulled in when I installed KDE, so I expect it is missing as a
> > dependency
> > (for plasma-discover perhaps?)
> > 
> > In my setup, KDE was installed onto an existing setup by running `apt
> > install
> > kde-plasma-desktop`
> > 
> > I did one update after installing the helper, but didn't notice
> > anything (it
> > didn't stall, though). As long as that fixes the problem, I guess
> > this bug
> > should be redirected as a dependency issue?
> > 
> > Ryan
> > 
> > On Friday, December 31, 2021 9:54:02 A.M. EST you wrote:
> > > Hi Ryan,
> > > 
> > > needrestart should not block if it is run non-interactive. On
> > > Debian it
> > > uses the debconf frontend which also has graphical frontends. Do
> > > you
> > > get debconf dialogs in KDE Discover when installing/updating
> > > packages
> > > at all? (Sorry I do not have an KDE environment for testing.)
> > > 
> > > 
> > > Regards,
> > > Thomas
> > > 
> > > On Tue, 2021-12-28 at 08:33 -0500, Ryan Armstrong wrote:
> > > > Package: needrestart
> > > > Version: 3.5-5
> > > > Severity: normal
> > > > 
> > > > Dear Maintainer,
> > > > 
> > > > When I performed an update with KDE Discover, I noticed it
> > > > stalled at
> > > > 99% complete status and would not finish. When I checked the
> > > > process
> > > > tree with htop, I noticed the following lines from packagekitd
> > > > and
> > > > needrestart:
> > > > 
> > > >2629 root   20   0  492M  124M 79624 S  0.0  0.8  0:29.20
> > > > ├─
> > > > /usr/libexec/packagekitd
> > > >2632 root   20   0  492M  124M 79624 S  0.0  0.8  0:00.00
> > > > │
> > > > ├─ /usr/libexec/packagekitd
> > > >2634 root   20   0  492M  124M 79624 S  0.0  0.8  0:00.05
> > > > │
> > > > ├─ /usr/libexec/packagekitd
> > > >   14075 root   20   0  492M  124M 79624 S  0.0  0.8  0:05.78
> > > > │
> > > > ├─ /usr/libexec/packagekitd
> > > >   14090 root   20   0  494M 99648 50800 S  0.0  0.6  0:00.24
> > > > │
> > > > └─ /usr/libexec/packagekitd
> > > >   25864 root   20   0  494M 51924  2336 S  0.0  0.3  0:00.00
> > > > │ └─ /usr/libexec/packagekitd
> > > >   25872 root   20   0  2472   704   616 S  0.0  0.0  0:00.00
> > > > │└─ sh -c test -x /usr/lib/needrestart/apt-pinvoke &&
> > > > /usr/lib/needrestart/apt-pinvoke || true
> > > >   25873 root   20   0 35864 27816  6140 S  0.0  0.2  0:00.64
> > > > │   └─ /usr/bin/perl /usr/sbin/needrestart
> > > > 
> > > > It appears that packagekit is still running needrestart to ask if
> > > > I
> > > > want to restart systemd services. However, this prompt is
> > > > obviously
> > > > not
> > > > visible to me through KDE Discover, so it's stuck waiting
> > > > forever.
> > > > 
> > > > If I use kill on needrestart, the Discover session completes.
> > > > 
> > > > Since, this is an interaction between Discover, packagekit, apt
> > > > and
> > > > needrestart (possibly others?), I'm not 100% sure this is the
> > > > right
> > > > place for it. 

Bug#1002732: needrestart stalled in background when performing update with KDE Discover

[Ryan Armstrong]

Package: needrestart
Version: 3.5-5
Severity: normal

Dear Maintainer,

When I performed an update with KDE Discover, I noticed it stalled at
99% complete status and would not finish. When I checked the process
tree with htop, I noticed the following lines from packagekitd and
needrestart:

   2629 root   20   0  492M  124M 79624 S  0.0  0.8  0:29.20 ├─ 
/usr/libexec/packagekitd
   2632 root   20   0  492M  124M 79624 S  0.0  0.8  0:00.00 │  ├─ 
/usr/libexec/packagekitd
   2634 root   20   0  492M  124M 79624 S  0.0  0.8  0:00.05 │  ├─ 
/usr/libexec/packagekitd
  14075 root   20   0  492M  124M 79624 S  0.0  0.8  0:05.78 │  ├─ 
/usr/libexec/packagekitd
  14090 root   20   0  494M 99648 50800 S  0.0  0.6  0:00.24 │  └─ 
/usr/libexec/packagekitd
  25864 root   20   0  494M 51924  2336 S  0.0  0.3  0:00.00 │ └─ 
/usr/libexec/packagekitd
  25872 root   20   0  2472   704   616 S  0.0  0.0  0:00.00 │└─ sh 
-c test -x /usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvoke 
|| true
  25873 root   20   0 35864 27816  6140 S  0.0  0.2  0:00.64 │   └─ 
/usr/bin/perl /usr/sbin/needrestart

It appears that packagekit is still running needrestart to ask if I
want to restart systemd services. However, this prompt is obviously not
visible to me through KDE Discover, so it's stuck waiting forever.

If I use kill on needrestart, the Discover session completes.

Since, this is an interaction between Discover, packagekit, apt and
needrestart (possibly others?), I'm not 100% sure this is the right
place for it. Feel free to reassign if I got it wrong.

Ryan

-- Package-specific info:
needrestart output:
Your outdated processes:
akonadi_archive[3076], akonadi_mailfil[3102], akonadi_sendlat[3116], 
akonadi_unified[3117], blueman-applet[2663], Discord[2921, 2924, 2967, 2922, 
2958, 2917, 3276, 3044], DiscoverNotifie[2571], evolution-addre[2767], 
evolution-alarm[2660], evolution-calen[2742], evolution-sourc[2698], 
goa-daemon[2704], kmail[2936], kwin_x11[2488], nextcloud[2656], 
plasmashell[2554], QtWebEngineProc[6196, 6215, 6194, 6193], 
tracker-miner-f[2674], xdg-desktop-por[2375], xdg-document-po[2392], 
xdg-permission-[2397]



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages needrestart depends on:
ii  binutils   2.37-7
ii  dpkg   1.21.1
ii  gettext-base   0.21-4
ii  libintl-perl   1.26-3
ii  libmodule-find-perl0.15-1
ii  libmodule-scandeps-perl1.31-1
ii  libproc-processtable-perl  0.634-1
ii  libsort-naturally-perl 1.03-2
ii  libterm-readkey-perl   2.38-1+b2
ii  perl   5.32.1-6
ii  xz-utils   5.2.5-2

Versions of packages needrestart recommends:
ii  libpam-systemd  249.7-1

Versions of packages needrestart suggests:
ii  iucode-tool2.3.1-1
ii  libnotify-bin  0.7.9-3

-- no debconf information

Bug#1001871: celluloid frequently fails to start

[Ryan Armstrong]

Package: celluloid
Version: 0.20-2
Severity: important

Dear Maintainer,

I have noticed that Celluloid frequently fails to start on my machine.
Some days the program works cleanly, other days it crashes every time 
I open it. Today is the latter. Here is the output:


(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_new_object_path: assertion 'g_variant_is_object_path (object_path)' 
failed

(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_new_variant: assertion 'value != NULL' failed

(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_get_type: assertion 'value != NULL' failed

(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_type_is_subtype_of: assertion 'g_variant_type_check (type)' failed

(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_builder_add_value: assertion '!GVSB(builder)->expected_type || 
g_variant_is_of_type (value, GVSB(builder)->expected_type)' failed

(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_builder_end: assertion 'GVSB(builder)->offset >= 
GVSB(builder)->min_items' failed

(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_get_type: assertion 'value != NULL' failed

(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_type_is_subtype_of: assertion 'g_variant_type_check (type)' failed

(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_builder_add_value: assertion '!GVSB(builder)->expected_type || 
g_variant_is_of_type (value, GVSB(builder)->expected_type)' failed
**
GLib-GIO:ERROR:../../../gio/gdbusconnection.c:4300:invoke_get_property_in_idle_cb:
 assertion failed: (error != NULL)
Bail out! 
GLib-GIO:ERROR:../../../gio/gdbusconnection.c:4300:invoke_get_property_in_idle_cb:
 assertion failed: (error != NULL)


I have looked at bug #970484, but the reported errors seem completely
different from that bug.

Here's the backtrace after I rebuilt to get a bunch of debug symbols:

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x76aee536 in __GI_abort () at abort.c:79
#2  0x7716eddc in g_assertion_message (domain=, 
file=, line=, func=, 
message=) at ../../../glib/gtestutils.c:3223
#3  0x771ce0bb in g_assertion_message_expr
(domain=domain@entry=0x77431b78 "GLib-GIO", 
file=file@entry=0x77458fb8 "../../../gio/gdbusconnection.c", 
line=line@entry=4300, func=func@entry=0x7745b010 <__func__.54> 
"invoke_get_property_in_idle_cb", expr=expr@entry=0x7745ea96 "error != 
NULL") at ../../../glib/gtestutils.c:3249
#4  0x773ef926 in invoke_get_property_in_idle_cb (_data=0x7fffbc01def0) 
at ../../../gio/gdbusconnection.c:4300
#5  0x771a4be4 in g_main_dispatch (context=0x55610240) at 
../../../glib/gmain.c:3381
#6  g_main_context_dispatch (context=0x55610240) at 
../../../glib/gmain.c:4099
#7  0x771a4f88 in g_main_context_iterate 
(context=context@entry=0x55610240, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4175
#8  0x771a503f in g_main_context_iteration 
(context=context@entry=0x55610240, may_block=may_block@entry=1) at 
../../../glib/gmain.c:4240
#9  0x773c306d in g_application_run (application=0x5560b1b0 
[CelluloidApplication], argc=argc@entry=1, argv=argv@entry=0x7fffdd68) at 
../../../gio/gapplication.c:2569
#10 0x55566bfd in main (argc=1, argv=0x7fffdd68) at 
./src/celluloid-main.c:36

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages celluloid depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-2
ii  libc62.32-5
ii  libcairo21.16.0-5
ii  libepoxy01.5.9-2
ii  libglib2.0-0 2.70.2-1
ii  libgtk-3-0   3.24.30-4
ii  libmpv1  0.34.0-2
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libpangocairo-1.0-0  1.48.10+ds1-1

Versions of packages celluloid recommends:
ii  youtube-dl  2021.06.06-1

celluloid suggests no packages.

-- no debconf information

Bug#993051: Acknowledgement (avahi-daemon CPU usage increases over time)

[Ryan Armstrong]

I have made an attempt at profiling where the avahi-daemon is getting 
stuck. Hopefully this is useful to someone. I downloaded the source 
package for avahi-daemon, then rebuilt it and installed the resulting 
debug packages. After waiting for the CPU usage to reach around 70% or 
so, I attempted to profile where it is executing.


My initial attempt at running `perf record -p 514 -g` failed; when 
running `perf report` after, the report was fully blank. As a result, I 
decided to go back to my original plan and just break a few times in gdb 
to see where it stopped. See the attached log for a full log of that 
session. It seemed to be usually in one of two places:


#0  0x7ff359801fb0 in find_next_timeout (s=) at 
simple-watch.c:431
#1  0x7ff3598027ea in avahi_simple_poll_prepare 
(s=s@entry=0x558f0b1e5ff0, timeout=timeout@entry=-1) at simple-watch.c:481
#2  0x7ff359802c69 in avahi_simple_poll_iterate (s=0x558f0b1e5ff0, 
timeout=timeout@entry=-1) at simple-watch.c:599
#3  0x558f09c929ee in run_server (c=0x558f09cb01e0 ) at 
main.c:1268

#4  main (argc=, argv=) at main.c:1686

or

#0  0x7ff35962d3c3 in __GI___poll (fds=0x558f0b1eec90, nfds=10, 
timeout=2209504) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7ff359802aa1 in avahi_simple_poll_run (s=0x558f0b1e5ff0) at 
simple-watch.c:527

#2  avahi_simple_poll_run (s=0x558f0b1e5ff0) at simple-watch.c:518
#3  0x7ff359802c78 in avahi_simple_poll_iterate (s=0x558f0b1e5ff0, 
timeout=timeout@entry=-1) at simple-watch.c:602
#4  0x558f09c929ee in run_server (c=0x558f09cb01e0 ) at 
main.c:1268

#5  main (argc=, argv=) at main.c:1686

Ryan

On 2021-09-11 1:11 p.m., Ryan Armstrong wrote:
I edited my Avahi service to add the --debug flag to see if added 
anything useful. It doesn't seem so, but here it is regardless. I've 
attached both the full log (gzipped) and an annotated and simplified log.


I may try and attach to the process with GDB in the future to trace 
what part of the code it is primarily working in.


Ryan

zerker@zeta:/usr/local/src/avahi-0.8$ sudo gdb /sbin/avahi-daemon 514
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /sbin/avahi-daemon...
Reading symbols from /usr/lib/debug/.build-id/2c/a2b666d7cae1fdf23610a403cf5134ef53c2bd.debug...
Attaching to program: /usr/sbin/avahi-daemon, process 514
Reading symbols from /lib/x86_64-linux-gnu/libavahi-common.so.3...
Reading symbols from /usr/lib/debug/.build-id/60/1f176178ee6723f5d0435852d0a52c39ce24c4.debug...
Reading symbols from /lib/x86_64-linux-gnu/libavahi-core.so.7...
Reading symbols from /usr/lib/debug/.build-id/6c/940f5569c9768c85408cec9e2aa7a9a8be4489.debug...
Reading symbols from /lib/x86_64-linux-gnu/libdaemon.so.0...
(No debugging symbols found in /lib/x86_64-linux-gnu/libdaemon.so.0)
Reading symbols from /lib/x86_64-linux-gnu/libexpat.so.1...
(No debugging symbols found in /lib/x86_64-linux-gnu/libexpat.so.1)
Reading symbols from /lib/x86_64-linux-gnu/libcap.so.2...
(No debugging symbols found in /lib/x86_64-linux-gnu/libcap.so.2)
Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...
Reading symbols from /usr/lib/debug/.build-id/11/8b90161526d181807818c459baee841993795b.debug...
Reading symbols from /lib/x86_64-linux-gnu/libdbus-1.so.3...
(No debugging symbols found in /lib/x86_64-linux-gnu/libdbus-1.so.3)
Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...
Reading symbols from /usr/lib/debug/.build-id/50/18237bbf012b4094027fd0b96fc22a24496ea4.debug...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
Reading symbols from /usr/lib/debug/.build-id/b7/2adf59ac0a673d1eeb261e662364507cfc8615.debug...
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/.build-id/32/438eb3b034da54caf58c7a65446639f7cfe274.debug...
Reading symbols from /lib/x86_64-linux-gnu/libsystemd.so.0...
(No debugging symbols found in /lib/x86_64-linux-gnu/libsystemd.so.0)
Reading symbols from /lib/x86_64-linux-gnu/librt.so.1...
Reading symbols from /usr/lib/debug/.build-id/7c/ce5ecadb7bf40c36fdb2834f9321707564fb3c.debug...
Rea

Bug#992989: Acknowledgement (avahi-daemon CPU usage increases over time)

[Ryan Armstrong]

On 2021-08-25 7:27 p.m., Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 992989: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992989.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Utopia Maintenance Team 

If you wish to submit further information on this problem, please
send it to 992...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

So... I messed up and raised the same bug twice, thinking the e-mail 
didn't go out. Since #993051 has slightly updated text, this one can be 
rejected.

Bug#993051: avahi-daemon CPU usage increases over time

[Ryan Armstrong]

Package: avahi-daemon
Version: 0.8-5
Severity: normal

Dear Maintainer,

After upgrading to Debian Bullseye, I noticed that the Avahi CPU usage on my 
server machine was
quite high (eventually 100% of one core). After resetting Avahi, the CPU usage 
was normal then
eventually increased over time again until it was again rather high. The
increase appears to be (very roughly) 1 or 2% per hour on my rather humble 
Intel(R) Celeron(R)
CPU 4205U @ 1.80GHz.

Checking the journal, I only see the following sorts of lines:

Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_normalize_name() failed.
Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_key_new() failed.
Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_normalize_name() failed.
Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_key_new() failed.
Aug 25 16:21:31 zeta avahi-daemon[31]: avahi_normalize_name() failed.
Aug 25 16:21:31 zeta avahi-daemon[31]: avahi_key_new() failed.

Which was around the time I turned on another machine on my network.
However, the timing was not aligned with when Avahi CPU usage increased.
Instead, it seems to be aligned with when I turn on my printer, but nothing
of note was printed in the log when that happened.

Is there any means for me to gather additional information to help
diagnose this problem?

Thanks,
Ryan

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages avahi-daemon depends on:
ii  adduser  3.118
ii  bind9-host [host]1:9.16.15-1
ii  dbus 1.12.20-2
ii  init-system-helpers  1.60
ii  libavahi-common3 0.8-5
ii  libavahi-core7   0.8-5
ii  libc62.31-13
ii  libcap2  1:2.44-1
ii  libdaemon0   0.14-7.1
ii  libdbus-1-3  1.12.20-2
ii  libexpat12.2.10-2
ii  lsb-base 11.1.0

Versions of packages avahi-daemon recommends:
ii  libnss-mdns  0.14.1-2

Versions of packages avahi-daemon suggests:
pn  avahi-autoipd  

-- no debconf information

Bug#992989: avahi-daemon CPU usage increases over time

[Ryan Armstrong]

Package: avahi-daemon
Version: 0.8-5
Severity: normal

Dear Maintainer,

After upgrading to Debian Bullseye, I noticed that the Avahi CPU usage on my 
server machine was
quite high (eventually 100% of one core). After resetting Avahi, the CPU usage 
was normal then
eventually increased over time again until it was again rather high. The
increase appears to be (very roughly) 1 or 2% per hour on my rather humble 
Intel(R) Celeron(R) 
CPU 4205U @ 1.80GHz. 

Checking the journal, I only see the following sorts of lines:

Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_normalize_name() failed.
Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_key_new() failed.
Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_normalize_name() failed.
Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_key_new() failed.
Aug 25 16:21:31 zeta avahi-daemon[31]: avahi_normalize_name() failed.
Aug 25 16:21:31 zeta avahi-daemon[31]: avahi_key_new() failed.

Which was around the time I turned on another machine on my network.
However, the timing was not aligned with when Avahi CPU usage increased.
There is a possibility it is aligned with when I turn on my printer, but
I will need to investigate that further. I did not see anything else in
the log of note.

In the meantime, is there any means for me to gather additional
information to help diagnose this problem?

Thanks,
Ryan

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages avahi-daemon depends on:
ii  adduser  3.118
ii  bind9-host [host]1:9.16.15-1
ii  dbus 1.12.20-2
ii  init-system-helpers  1.60
ii  libavahi-common3 0.8-5
ii  libavahi-core7   0.8-5
ii  libc62.31-13
ii  libcap2  1:2.44-1
ii  libdaemon0   0.14-7.1
ii  libdbus-1-3  1.12.20-2
ii  libexpat12.2.10-2
ii  lsb-base 11.1.0

Versions of packages avahi-daemon recommends:
ii  libnss-mdns  0.14.1-2

Versions of packages avahi-daemon suggests:
pn  avahi-autoipd  

-- no debconf information

Bug#990326: thunderbird: No images shown in thundebird

[Ryan Armstrong]

On Tue, 29 Jun 2021 22:00:28 +0200 Carsten Schoenert 
 wrote:


> Hello Guido,
>
> Am Fri, Jun 25, 2021 at 08:15:37PM +0200 schrieb Guido Krause:
> > Dear Maintainer,
> >
> > Thunderbird does not show images embedded in e-mail if allowed. Either
> > nothing is shown or a "broken image" icon
>
> what about this issue with version 1:78.11.0-2 ?
>
> Regards
> Carsten
>
>

I'm not the original reporter, but I had the same problem reported 
above, and updating to version 1:78.11.0-2 resolved it.

Bug#985653: arduino: Arduino Leonardo bootloader missing (and possibly others)

[Ryan Armstrong]

On 2021-03-21 9:58 a.m., Carsten Schoenert wrote:

Control: reassign -1 arduino-core-avr

Hello Rayn,

the bootloader files doesn't belong to the Arduino IDE directly but to
the specific board support packages. In your case to arduino-core-avr.

This impression is correct but also documented.
Please have a look into
/usr/share/doc/arduino-core-avr/README.Debian

It's also partially documented within the Debian Wiki.

https://wiki.debian.org/Arduino#FAQ

If you can contribute more useful hints to the Wikis site please add
your additional information.

There is quite nothing we can do about this right now. We would like to
get rid of arduino-core-avr but the libary handling of the IDE isn't
supporting the dedicated installation of the AVRCore stuff in the
reklease of the 1.x version. Might be happen within 2.x.


Ah, my mistake on missing the README and wiki (and picking the wrong 
package for the report). I can't think of a better solution at the 
moment, aside from forcing the user to read the readme on install :)


I may try to get the bootloader to build myself and provide an update if 
I have any success.


Ryan

Bug#726062: Arduino SAM ARM support works

[Ryan Armstrong]

Just an FYI: I successfully programmed an Arduino Due (SAM ARM-based) 
using the Debian-packaged version of the Arduino IDE. The board support 
information is now controlled through the "Boards Manager" feature, 
which will independently install support into the ~/.arduino15 folder 
regardless of what the Debian package comes with.


That said, this bug is probably still valid for ADK devices. I don't own 
one of those boards to test.


Ryan

Bug#985653: arduino: Arduino Leonardo bootloader missing (and possibly others)

[Ryan Armstrong]

Package: arduino
Version: 2:1.8.13+dfsg1-2
Severity: normal

Dear Maintainer,

The Arduino package (and any related packes I can find) appear to be
missing the bootloader for the Arduino Leonardo (technically tested
using an Arduboy, which has the same hardware). When performing a
"verify" operation on the board type, the build process reports the
following message:

Bootloader file specified but missing: 
/usr/share/arduino/hardware/arduino/avr/bootloaders/caterina/Caterina-Leonardo.hex

I did not attempt an upload beyond this, as recovering a Leonardo/Arduboy 
with a missing bootloader is quite tricky. I saw several .txt files in
this folder, but no hex files at all. I also did not see any hex files
in the atmega8, lilypad, caterina-Arduino_Robot or caterina-LilyPadUSB
so I suspect a fair number of board types will have similar problems.

Ryan

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-security'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages arduino depends on:
ii  arduino-builder   1.3.25-2+b1
ii  arduino-core-avr  1.8.3+dfsg1-1
ii  avrdude   6.3-20171130+svn1429-2+b1
ii  default-jre   2:1.11-72
ii  dpkg-dev  1.20.7.1
ii  libastylej-jni3.1-2+b1
ii  libbatik-java 1.12-4
ii  libbcpg-java  1.68-1
ii  libbcprov-java1.68-1
ii  libcommons-codec-java 1.15-1
ii  libcommons-compress-java  1.20-1
ii  libcommons-exec-java  1.3-2
ii  libcommons-io-java2.8.0-1
ii  libcommons-lang3-java 3.11-1
ii  libcommons-logging-java   1.2-2
ii  libcommons-net-java   3.6-1
ii  libhttpclient-java4.5.13-1
ii  libjackson2-annotations-java  2.12.1-1
ii  libjackson2-core-java 2.12.1-1
ii  libjackson2-databind-java 2.12.1-1
ii  libjaxp1.3-java   1.3.05-6
ii  libjmdns-java 3.5.5-1
ii  libjna-java   5.6.0-1
ii  libjna-platform-java  5.6.0-1
ii  libjsch-java  0.1.55-1
ii  libjssc-java  2.8.0-3
ii  liblistserialsj-dev   1.4.0-1+b1
ii  liblog4j2-java2.13.3-1
ii  librsyntaxtextarea-java   2.5.8-1
ii  librxtx-java  2.2pre2+dfsg1-2
ii  libsemver-java0.9.0-4
ii  libslf4j-java 1.7.30-1
ii  libxml-commons-external-java  1.4.01-5
ii  libxmlgraphics-commons-java   2.4-1
ii  openjdk-11-jre11.0.10+9-1

Versions of packages arduino recommends:
ii  extra-xdg-menus  1.0-5
ii  policykit-1  0.105-30

arduino suggests no packages.

-- no debconf information

Bug#974011: xmille: Incorrect license/copyright for xmille

[Ryan Armstrong]

On 2020-12-07 12:12 p.m., Keith Packard wrote:

Adrian Bunk  writes:


On Sun, Nov 08, 2020 at 07:06:52PM -0500, Ryan Armstrong wrote:

...
I have been researching old terminal and X games recently, and realized
that much of the code from 'xmille' orignated from the terminal game
'mille', which is part of bsdgames.

Specifically, the following files are notably similar between the two
games:
comp.c
end.c
extern.c
init.c
mille.c & mille.h
misc.c
move.c
types.h
varpush.c

Many of these even contain telltale BSD version/date comments, even a
few not listed above that are common but extensively re-written.
However, all of the original source files contain the 3-term BSD
license, as follows:
...
This has been stripped out of all code in the xmille distribution.
Also, none of the included materials give credit to the original author,
Ken Arnold.

I'm not sure what the best solution is, exactly. Extensively patch the
source until it complies with the BSD license again?

Presumably, the copyright file needs to change at the very least.
...

Keith, do you remember the copyright history of this code?

I may have copied the underlying mille sources *before* copyrights were
added to each file; I started work on the X10 version of xmille around
1985 or 1986. I guess I could have mistakenly removed them? Thanks for
discovering this error; I can fix these "upstream" and publish a new
version?


I just did a bit of digging, since I previously had a 2.11 BSD VM set up 
in SIMH (fun!). It looks like the version of mille in that release was 
indeed from about the 1985/1986 time frame, and the copyright headers 
were not yet added. So that makes much more sense then removing them.


I guess the question becomes, would they still require a change in 
copyright status, or is the previous status correct?


Also, should a credit for Ken Arnold be added?

Ryan

Bug#974011: xmille: Incorrect license/copyright for xmille

[Ryan Armstrong]

Package: xmille
Version: 2.0-13+b2
Severity: serious
Tags: upstream
Justification: Policy 4.5

Dear Maintainer,

I have been researching old terminal and X games recently, and realized
that much of the code from 'xmille' orignated from the terminal game
'mille', which is part of bsdgames.

Specifically, the following files are notably similar between the two
games:
comp.c
end.c
extern.c
init.c
mille.c & mille.h
misc.c
move.c
types.h
varpush.c

Many of these even contain telltale BSD version/date comments, even a
few not listed above that are common but extensively re-written.
However, all of the original source files contain the 3-term BSD
license, as follows:

 * Copyright (c) 1982, 1993
 *  The Regents of the University of California.  All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 * 3. Neither the name of the University nor the names of its contributors
 *may be used to endorse or promote products derived from this software
 *without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.

This has been stripped out of all code in the xmille distribution.
Also, none of the included materials give credit to the original author,
Ken Arnold.

I'm not sure what the best solution is, exactly. Extensively patch the
source until it complies with the BSD license again?

Presumably, the copyright file needs to change at the very least.

Ryan

Bug#970763: wminput immedinately exits with Segmentation Fault on use

[Ryan Armstrong]

Package: wminput
Version: 0.6.91-1+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

With the most recent version of wminput, the application fails to start
immediately, raising a Segmentation Fault. This occurrs on both of my
machines that currently track Debian Testing. It does not matter what
command-line arguments are used, even --version causes this behaviour.

I attempted to rebuild the package with debug symbols in order to get a
useful stack trace. While I was able to build and install the package +
dbgsym packages, the backtrace in gdb was not useful. Here it is for
reference anyways:

$ gdb wminput
GNU gdb (Debian 9.2-1) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from wminput...
Reading symbols from
/usr/lib/debug/.build-id/87/07b22dc522a1bffe98fc49614410ec12d85b05.debug...
(gdb) run
Starting program: /usr/bin/wminput 

Program received signal SIGSEGV, Segmentation fault.
0x0001 in ?? ()
(gdb) bt
#0  0x0001 in ?? ()
#1  0x7fffe4b2 in ?? ()
#2  0x in ?? ()

And here is LDD's output:

$ ldd /usr/bin/wminput
linux-vdso.so.1 (0x7ffc5dbc2000)
libcwiid.so.1 => /usr/lib/libcwiid.so.1 (0x7f3439bdb000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f3439bd5000)
libbluetooth.so.3 => /usr/lib/x86_64-linux-gnu/libbluetooth.so.3 
(0x7f3439bb)
libpython3.8.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0 
(0x7f3439667000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f3439645000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f343948)
/lib64/ld-linux-x86-64.so.2 (0x7f3439c4c000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 
(0x7f3439451000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f3439434000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f343942f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f34392eb000)

I'm hoping this should be trivial for anyone else to reproduce. 
If you'd like me to try anything else, please let me know.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wminput depends on:
ii  libbluetooth3  5.54-1
ii  libc6  2.31-3
ii  libcwiid1  0.6.91-1+b1
ii  libpython3.8   3.8.5-2
ii  python3-cwiid  0.6.91-1+b1

wminput recommends no packages.

wminput suggests no packages.

-- no debconf information

Bug#942032: openjazz: please provide a launcher for Jazz Jackrabbit Holiday Hare '95

[Ryan Armstrong]

(then G-D-P should provide in /usr/share/games/jazz-jackrabbit-hh95
a symlink to /usr/games/OpenJazz to makes it work ?)


When I did my initial testing, the HH95 path just needs to be provided
as a command-line argument to openjazz. For example:

$ OpenJazz /usr/share/games/jazz-jackrabbit-hh95

Once the game is started, the menu item for 'Episode X' will run the
HH95 levels instead of the HH94 levels included with the full game.

It seems to find the existing game data files in the jazz-jackrabbit folder just
fine, even if the only such file is openjazz.000. If run without the main game 
data
present, the other episodes will just be disabled on the main menu.

Ryan

Bug#941290: Unable to launch web browser from e-mail link in Thunderbird on Xfce 4.14 (using exo-helper-2) due to Apparmor

[Ryan Armstrong]

Package: thunderbird
Version: 1:60.9.0-1
Severity: normal
Tags: newcomer patch

Dear Maintainer,

Upon switching to Debian testing (and thus Xfce 4.14), I noticed that
web links would no longer open in Firefox. I traced the issue to the
apparmor rule not allowing access for exo-helper-2 used by Xfce 4.14.

Sep 27 16:44:30 alpha audit[3491]: AVC apparmor="DENIED"
operation="exec" profile="thunderbird"
name="/usr/lib/x86_64-linux-gnu/xfce4/exo-2/exo-helper-2" pid=3491
comm="exo-open" requested_mask="x" denied_mask="x" fsuid=1001 ouid=0
Sep 27 16:44:30 alpha kernel: audit: type=1400 audit(1569617070.839:47):
apparmor="DENIED" operation="exec" profile="thunderbird"
name="/usr/lib/x86_64-linux-gnu/xfce4/exo-2/exo-helper-2" pid=3491
comm="exo-open" requested_mask="x" denied_mask="x" fsuid=1001 ouid=0

When adding the following line to usr.bin.thunderbird, the problem is
resolved:

/usr/lib/@{multiarch}/xfce4/exo-2/exo-helper-2 ixr,


Here is the change in patch form:

Index: 
thunderbird_1%3a60.9.0-1~deb10u1_amd64/etc/apparmor.d/usr.bin.thunderbird

===
--- 
thunderbird_1%3a60.9.0-1~deb10u1_amd64.orig/etc/apparmor.d/usr.bin.thunderbird
+++ 
thunderbird_1%3a60.9.0-1~deb10u1_amd64/etc/apparmor.d/usr.bin.thunderbird

@@ -54,6 +54,7 @@ profile thunderbird /usr/lib/thunderbird
   # For Xubuntu to launch the browser
   /usr/bin/exo-open ixr,
   /usr/lib/@{multiarch}/xfce4/exo-1/exo-helper-1 ixr,
+  /usr/lib/@{multiarch}/xfce4/exo-2/exo-helper-2 ixr,
   /etc/xdg/xdg-xubuntu/xfce4/helpers.rc r,
   /etc/xdg/xfce4/helpers.rc r,


Thanks,
Ryan


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64, armhf

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages thunderbird depends on:
ii  debianutils   4.9
ii  fontconfig    2.13.1-2+b1
ii  libatk1.0-0   2.34.0-1
ii  libc6 2.29-1
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-6    2.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig1    2.13.1-2+b1
ii  libfreetype6  2.9.1-4
ii  libgcc1   1:9.2.1-8
ii  libgdk-pixbuf2.0-0    2.38.1+dfsg-1
ii  libglib2.0-0  2.60.6-2
ii  libgtk-3-0    3.24.11-1
ii  libgtk2.0-0   2.24.32-4
ii  libhunspell-1.7-0 1.7.0-2+b1
ii  libicu63  63.2-2
ii  libjsoncpp1   1.7.4-3+b1
ii  libnspr4  2:4.21-2
ii  libnss3   2:3.45-1
ii  libpango-1.0-0    1.42.4-7
ii  libsqlite3-0  3.29.0-2
ii  libstartup-notification0  0.12-6
ii  libstdc++6    9.2.1-8
ii  libvpx6   1.8.1-2
ii  libx11-6  2:1.6.8-1
ii  libx11-xcb1   2:1.6.8-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt6    1:1.1.5-1+b3
ii  psmisc    23.2-1+b1
ii  x11-utils 7.7+4
ii  zlib1g    1:1.2.11.dfsg-1+b1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1
ii  lightning 1:60.9.0-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.3-5
ii  fonts-lyx 2.3.3-2
ii  libgssapi-krb5-2  1.17-6

-- Configuration Files:
/etc/apparmor.d/usr.bin.thunderbird changed:
@{MOZ_LIBDIR}=/usr/lib/thunderbird
profile thunderbird /usr/lib/thunderbird/thunderbird{,-bin} {
  #include 
  #include 
  #include 
  # TODO: finetune this for required accesses
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  # Backported from the mesa abstraction, available in AppArmor >2.13
  # System files
  /dev/dri/ r, # libGLX_mesa.so calls drmGetDevice2()
  # User files
  owner @{HOME}/.cache/ w, # if user clears all caches
  owner @{HOME}/.cache/mesa_shader_cache/ w,
  owner @{HOME}/.cache/mesa_shader_cache/index rw,
  owner @{HOME}/.cache/mesa_shader_cache/??/ w,
  owner @{HOME}/.cache/mesa_shader_cache/??/* rw,
  # End of backported mesa abstraction
  # Backported from the dri-enumerate abstraction, available in 
AppArmor 2.13
/sys/devices/pci[0-9]*/**/{device,subsystem_device,subsystem_vendor,uevent,vendor} 
r,

  # Allow opening attachments