Bug#982381: Workaround to get s3ql functional again

[Anthony DeRobertis]

Package: s3ql
Version: 3.7.0+dfsg-2
Followup-For: Bug #982381

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A workaround, at least if (like me) you've got S3QL running as a
dedicated user:

As the s3ql-user, run: pip3 install --user trio==0.18.0

This will install a newer version of trio (0.18.0) in ~/.local/lib —
once this bug is fixed, you can remove it.

- -- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 
'stable-updates'), (500, 'testing'), (500, 'stable'), (130, 'unstable-debug'), 
(130, 'unstable'), (120, 'experimental-debug'), (120, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages s3ql depends on:
ii  fuse3 [fuse]  3.10.3-1
ii  libc6 2.31-12
ii  libjs-sphinxdoc   3.4.3-2
ii  libsqlite3-0  3.34.1-3
ii  procps2:3.3.17-5
ii  psmisc23.4-2
ii  python3   3.9.2-3
ii  python3-apsw  3.34.0-r1-1
ii  python3-cryptography  3.3.2-1
ii  python3-defusedxml0.6.0-2
ii  python3-dugong3.8.1+dfsg-1
ii  python3-google-auth   1.5.1-3
ii  python3-google-auth-oauthlib  0.4.2-1
ii  python3-pkg-resources 52.0.0-3
ii  python3-pyfuse3   3.2.0-2
ii  python3-requests  2.25.1+dfsg-2
ii  python3-systemd   234-3+b4
ii  python3-trio  0.13.0-2

s3ql recommends no packages.

s3ql suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCYLmngRUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf6kkwCfckQ/FVPZa3RBFNBC3PR6PJrfmUUA
n3d/GbFiwu8Spi1gwUrh0DKZmxth
=ZUtK
-END PGP SIGNATURE-

Bug#939748: Please add a NEWS.Debian entry for dropping BDF & Type 1 support

[Anthony DeRobertis]

Package: libpango-1.0-0
Version: 1.46.0-2
Followup-For: Bug #939748

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Adding a NEWS entry explaining that support for these formats is gone
would help prevent a lot of frustration for users (myself included) who
were surprised after upgrading and got to go track down the issue.

Maybe something like:

  Pango 1.44 no longer supports BDF & PCF (X11) bitmap fonts and Type 1.

  Upstream has switched from using Freetype to Harfbuzz for loading
  fonts, which means it no longer supports various old font formats
  including X11 bitmap fonts and Type 1 fonts. These however can be
  wrapped in the supported OpenType format, for details see
  https://gitlab.gnome.org/GNOME/pango/-/issues/386 and
  https://fedoraproject.org/wiki/BitmapFontConversion

- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-updates'), (500, 
'testing'), (500, 'stable'), (130, 'unstable-debug'), (130, 'unstable'), (120, 
'experimental-debug'), (120, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libpango-1.0-0 depends on:
ii  fontconfig 2.13.1-4.2
ii  libc6  2.31-3
ii  libfribidi01.0.8-2
ii  libglib2.0-0   2.64.4-1
ii  libharfbuzz0b  2.6.7-1
ii  libthai0   0.1.28-3

libpango-1.0-0 recommends no packages.

libpango-1.0-0 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCX1ZBJhUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf5/jgCfbkGaBEMR9d309ULzqp0a0y3W8aQA
nRfTQXoAybbyHGAPFzULPnjA/dsx
=/HOG
-END PGP SIGNATURE-

Bug#960852: Missing dependency on python3-configargparse

[Anthony DeRobertis]

Package: cloudprint
Version: 0.14-13
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

At some point, cloudprintd got restarted, but failed:

May 08 22:24:54 Watt cloudprintd[22683]: Traceback (most recent call last):
May 08 22:24:54 Watt cloudprintd[22683]:   File "/usr/sbin/cloudprintd", line 
11, in 
May 08 22:24:54 Watt cloudprintd[22683]: 
load_entry_point('cloudprint==0.14', 'console_scripts', 'cloudprint-cmd')()
May 08 22:24:54 Watt cloudprintd[22683]:   File 
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 489, in 
load_entry_point
May 08 22:24:54 Watt cloudprintd[22683]: return 
get_distribution(dist).load_entry_point(group, name)
May 08 22:24:54 Watt cloudprintd[22683]:   File 
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2852, in 
load_entry_point
May 08 22:24:54 Watt cloudprintd[22683]: return ep.load()
May 08 22:24:54 Watt cloudprintd[22683]:   File 
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2443, in load
May 08 22:24:54 Watt cloudprintd[22683]: return self.resolve()
May 08 22:24:54 Watt cloudprintd[22683]:   File 
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2449, in 
resolve
May 08 22:24:54 Watt cloudprintd[22683]: module = 
__import__(self.module_name, fromlist=['__name__'], level=0)
May 08 22:24:54 Watt cloudprintd[22683]:   File 
"/usr/share/cloudprint/cloudprint/cloudprint.py", line 22, in 
May 08 22:24:54 Watt cloudprintd[22683]: import configargparse
May 08 22:24:54 Watt cloudprintd[22683]: ModuleNotFoundError: No module named 
'configargparse'

Installing python3-configargparse makes it work again.

(I confess my system isn't fully updated)

- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-updates'), (500, 
'testing'), (500, 'stable'), (130, 'unstable-debug'), (130, 'unstable'), (120, 
'experimental-debug'), (120, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cloudprint depends on:
ii  cups 2.3.1-7
ii  openssl  1.1.1d-2
ii  python3  3.7.5-3
ii  python3-cups 1.9.73-3
ii  python3-requests 2.22.0-2
ii  rsyslog [system-log-daemon]  8.2001.0-1

cloudprint recommends no packages.

cloudprint suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCXsFIBhUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf6kOgCeJUwJDBHkz5PVJM6kJEm6y1Mg2OUA
n16u1hzMhbIXyb0+ANaBZqbOXJhk
=YxHd
-END PGP SIGNATURE-

Bug#935173: audacity graphical windows fail to update properly

[Anthony DeRobertis]

On 3/13/20 1:16 AM, Daniel Kahn Gillmor wrote:

Control: retitle 935173 audacity graphical windows fail to update properly when 
GTK_IM_MODULE=xim
Control: forwarded 935173 
https://developer.gnome.org/gtk3/stable/gtk-running.html


Err, are you sure that's the right URL? I tried to find the forwarded 
bug at both https://bugzilla.audacityteam.org/ and 
https://gitlab.gnome.org/GNOME/gtk/issues/ but I couldn't find it on 
either. So alas I can't just fix the URL myself.

Bug#915024: evince-thumbnailer: Permission denied due to apparmor

[Anthony DeRobertis]

Package: evince
Version: 3.34.1-1+b1
Followup-For: Bug #915024

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

See also https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1798091

Also, this affects caja as well, but the path that needs to be allowed
is /tmp/.mate_desktop_thumbnail.*

- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-updates'), (500, 
'testing'), (500, 'stable'), (130, 'unstable-debug'), (130, 'unstable'), (120, 
'experimental-debug'), (120, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-2
ii  evince-common3.34.1-1
ii  gsettings-desktop-schemas3.34.0-2
ii  libatk1.0-0  2.34.1-1
ii  libc62.29-7
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libevdocument3-4 3.34.1-1+b1
ii  libevview3-3 3.34.1-1+b1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-2
ii  libglib2.0-0 2.62.4-1
ii  libgnome-desktop-3-183.34.2-2
ii  libgtk-3-0   3.24.13-1
ii  libnautilus-extension1a  3.34.1-1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libsecret-1-00.19.1-1
ii  shared-mime-info 1.10-1

Versions of packages evince recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-2
ii  dbus-x11 [dbus-session-bus]   1.12.16-2

Versions of packages evince suggests:
ii  gvfs 1.42.1-3
ii  nautilus-sendto  3.8.6-3
ii  poppler-data 0.4.9-2
ii  unrar1:5.6.6-2

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCXjhbyxUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf7vQgCfeNJdjrKvsxYJwcQRvP/4hOeoWjkA
n0P90qNdIr1OA1sMeyeAhAqkr3eh
=B5ZU
-END PGP SIGNATURE-

Bug#947847: please install systemd-sysusers using update-alternatives

[Anthony DeRobertis]

On 1/30/20 7:02 AM, Thomas Goirand wrote:

This is normally solved if using pre-depends, which ensure that a
package is configured before using it (and not just unpacked).


Having everything using sysusers have versioned Pre-Depends on systemd | 
opensysusers would probably minimize the problem, but could potentially 
be a fair number of Pre-Depends to add. (I have no idea if non-versioned 
Pre-Depends on a virtual package works, if so that'd be better. If not, 
it'd also require adjusting them all if another alternative is introduced.)


I'm not sure what the risk of dependency resolution unexpectedly 
changing a system to use opensysusers is. Or of it deciding to install 
systemd when the admin wants to use opensysusers — that is probably a 
higher risk since systemd would be listed as the first alternative.


Not saying any of this is a showstopper, of course, just that its a 
downside/potential complication to weigh.

Bug#950266: Each caja time started, mounts multiple extra copies of btrfs filesystem

[Anthony DeRobertis]

Package: caja
Version: 1.22.3-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have a 4-disk btrfs filesystem, which is stored on encrypted disks
(LUKS) if it matters. Before starting Caja, the disks have been unlocked
and the filesystem mounted (both done with udisksctl).

Caja does two weird things with this filesystem, one cosmetic and one a
problem:

1. It shows 4 (or more) times in the "Places" pane, initially one as
   mounted and 3 as not mounted. This would just be cosmetic, except...

2. Each time caja is mounted, it seems to ask udisks to mount the other
   three copies it sees. So each caja start results in another three
   mounts of the filesystem, and since I only have it running when
   needed... very quickly I get dozens of them. This makes all kinds of
   things slow — e.g., bringing up a "Save" dialog in many apps pegs the
   CPU for seconds, hanging the app until its done.

I tried turning on "Never prompt or start programs on media insertion"
and turning off "Browse media when inserted" in hopes that'd work around
the issue, but it doesn't. Caja still mounts three more copies each
start.

I'm pretty sure its asking udisks to do the mount because of systemd
journal entries which appear when caja starts:

Jan 30 13:45:11 Watt systemd[1]: Started Clean the /media/anthony/BigBackup18 
mount point.
Jan 30 13:45:11 Watt systemd[1]: Started Clean the /media/anthony/BigBackup16 
mount point.
Jan 30 13:45:11 Watt systemd[1]: Started Clean the /media/anthony/BigBackup17 
mount point.
Jan 30 13:45:11 Watt udisksd[1154]: Mounted /dev/dm-15 at 
/media/anthony/BigBackup18 on behalf of uid 1000
Jan 30 13:45:11 Watt udisksd[1154]: Mounted /dev/dm-18 at 
/media/anthony/BigBackup16 on behalf of uid 1000
Jan 30 13:45:11 Watt udisksd[1154]: Mounted /dev/dm-17 at 
/media/anthony/BigBackup17 on behalf of uid 1000

I eventually worked around this issue by setting up a systemd timer to
unmount the extra ones every 10 minutes ☹

- --- /etc/systemd/system/local-umount-BBU-clones.service ---
[Unit]
ConditionPathExistsGlob=/media/anthony/BigBackup[0-9]*

[Service]
Type=oneshot
ExecStart=sh -c 'for m in /media/anthony/BigBackup[0-9]*; do umount "$m"; done'

- --- /etc/systemd/system/local-umount-BBU-clones.timer ---
[Unit]
Description=Kluge around udisks/caja mounting extra copies of BigBackup

[Install]
WantedBy=timers.target

[Timer]
OnBootSec=10m
OnUnitActiveSec=10m
RandomizedDelaySec=1m


- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-updates'), (500, 
'testing'), (500, 'stable'), (130, 'unstable-debug'), (130, 'unstable'), (120, 
'experimental-debug'), (120, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages caja depends on:
ii  caja-common   1.22.3-1
ii  desktop-file-utils0.24-1
ii  gvfs  1.42.1-3
ii  libatk1.0-0   2.34.1-1
ii  libc6 2.29-7
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libcaja-extension11.22.3-1
ii  libexempi82.5.1-1
ii  libexif12 0.6.21-5.1
ii  libgail-3-0   3.24.13-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-2
ii  libglib2.0-0  2.62.4-1
ii  libglib2.0-bin2.62.4-1
ii  libglib2.0-data   2.62.4-1
ii  libgtk-3-03.24.13-1
ii  libice6   2:1.0.9-2
ii  libmate-desktop-2-17  1.22.2-1
ii  libnotify40.7.8-1
ii  libpango-1.0-01.42.4-7
ii  libpangocairo-1.0-0   1.42.4-7
ii  libselinux1   3.0-1
ii  libsm62:1.2.3-1
ii  libx11-6  2:1.6.8-1
ii  libxml2   2.9.4+dfsg1-8
ii  mate-desktop  1.22.2-1
ii  shared-mime-info  1.10-1

Versions of packages caja recommends:
ii  gvfs-backends  1.42.1-3

Versions of packages caja suggests:
ii  engrampa1.22.3-1
ii  gstreamer1.0-tools  1.16.2-2
ii  meld3.20.1-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCXjMkxBUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf4msACcCJjatTbHQR13pW5rAskJU2uN83EA
n0fotHWLQcDOqFKxjoy5f4KtM0Ct
=0XTm
-END PGP SIGNATURE-

Bug#947847: please install systemd-sysusers using update-alternatives

[Anthony DeRobertis]

On 1/29/20 2:19 PM, Simon McVittie wrote:

I think we have a fairly good picture of the costs that would be
incurred from using alternatives: more interacting code paths to test,
potentially more configurations that are technically possible but are
not considered supported, and packages with "Depends: systemd (>= 321)"
(or indeed systemd itself, in the case of systems using it to boot)
not being able to rely on having access to all systemd 321 features,
which doesn't seem like a least-astonishment situation to be in. However,
Michael, or anyone else opposing this change: if you have anything to
add to those, please do.


There are some more that come to mind:

 * if we convert the exiting name to an alternative, there is the
   somewhat interesting work of actually changing a file over from an
   executable shipped in the package to an alternative, which would
   normally be set up by postinst. That could leave an uncomfortably
   large window during upgrade where the system would be broken (and
   possibly not boot) if interrupted. And, unlike the related
   dpkg-divert challenge, this would be on the vast majority of Debian
   systems, not only those where opensysusers is installed.
 * if we use a new, different name, then we've introduced a
   Debian-specific interface. One of the nice things about most of the
   Linux world standardizing on systemd is increased cross-distro
   compatibility; here we'd be breaking it.
 * regardless of which name (existing or new), alternatives can wind up
   pointing at nothing during the upgrade. Or if the upgrade is
   interrupted. I seem to recall that's one reason /bin/sh was never an
   alternative; seems like there is a cost in increased fragility
   (again, on all systems, not just ones with opensysusers).

Bug#947847: please install systemd-sysusers using update-alternatives

[Anthony DeRobertis]

It's different than awk because the decision the admin is making ("which 
init system do I want to run"?) isn't done through alternatives. So you 
can't use the alternatives system to coordinate swapping all the 
different bits together.


It seems retty reasonable to me that the systemd maintainers don't want 
to support systems which are running arbitrary combinations of systemd 
with alternatives to some parts. And that a package with a Depends on a 
particular systemd version should be able to depend on features from 
that version; alternatives would allow an old version of opensysusers to 
be used instead (unless systemd kept adding conflicts against 
opensysusers whenever they add a new feature, something I doubt anyone 
would be happy with).


Strikes me as there is a possible solution, though: have opensysusers 
dpkg-divert it and put a shell script in its place that checks which 
init system is running, and exec's the right sysusers based on that. 
This wouldn't affect systemd-only machines (as opensysusers would not be 
installed at all), and would do the right thing if someone has installed 
two init systems to, e.g., consider switching. It'd need to be a script 
that the systemd maintainers feel reasonably confident will always run 
systemd's implementation when systemd is running, to avoid the mixed 
implementations issue.


(Of course, there is the problem with temporarily having no file 
there... but I suspect that could be documented around as the lesser of 
evils. Especially if done with --no-rename, so it'd be a very short time.)

Bug#946131: Apparmor breaks Send -> Email depending on settings

[Anthony DeRobertis]

Package: libreoffice
Version: 1:6.3.2-1+b1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Attempting to use any of the email options under File->Send results in
(in the terminal I started LibreOffice from, just silently doing nothing
as far as the GUI is concerned):

/usr/lib/libreoffice/program/senddoc: line 62: /usr/bin/file: Permission denied
/usr/lib/libreoffice/program/senddoc: line 70: /usr/bin/thunderbird: Permission 
denied

This is because I have Thunderbird selected in Options→Internet→Email,
which has a nice 'Browse...' button to select an arbitrary program. That
isn't really compatible with the AppArmor profile. (When I set it to
sensible-lomua instead of /usr/bin/thunderbird it worked, still using
thunderbird, but through xdg-email instead, I presume.)

I'm not sure how to fix this other than add a bunch of possible email
programs to the AppArmor program and a warning to the settings box that
if you pick a weird one, you'll need to edit the AppArmor profile. Not
ideal, and AFAIK you need root to edit the profile.

(And of course, File→Send→Email* ought to show a proper error message
when they fail.)

- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-updates'), (500, 
'testing'), (500, 'stable'), (130, 'unstable-debug'), (130, 'unstable'), (120, 
'experimental-debug'), (120, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreoffice depends on:
ii  libreoffice-base1:6.3.2-1+b1
ii  libreoffice-calc1:6.3.2-1+b1
ii  libreoffice-core1:6.3.2-1+b1
ii  libreoffice-draw1:6.3.2-1+b1
ii  libreoffice-impress 1:6.3.2-1+b1
ii  libreoffice-math1:6.3.2-1+b1
ii  libreoffice-report-builder-bin  1:6.3.2-1+b1
ii  libreoffice-writer  1:6.3.2-1+b1
ii  python3-uno 1:6.3.2-1+b1

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-dejavu2.37-1
ii  fonts-liberation1:1.07.4-10
ii  fonts-liberation2   2.00.5-2
ii  fonts-linuxlibertine5.3.0-4
ii  fonts-noto-core 20181227-1
ii  fonts-noto-mono 20181227-1
ii  fonts-noto-ui-core  20181227-1
ii  fonts-sil-gentium-basic 1.102-1
ii  libreoffice-java-common 1:6.3.2-1
ii  libreoffice-nlpsolver   0.9+LibO6.3.2-1
pn  libreoffice-report-builder  
ii  libreoffice-script-provider-bsh 1:6.3.2-1
ii  libreoffice-script-provider-js  1:6.3.2-1
ii  libreoffice-script-provider-python  1:6.3.2-1
pn  libreoffice-sdbc-mysql  
ii  libreoffice-sdbc-postgresql 1:6.3.2-1+b1
ii  libreoffice-wiki-publisher  1.2.0+LibO6.3.2-1

Versions of packages libreoffice suggests:
ii  cups-bsd2.3.0-5
ii  default-jre [java6-runtime] 2:1.11-72
ii  firefox 70.0.1-1+b1
ii  ghostscript 9.27~dfsg-3.1
ii  gnupg   2.2.17-3
pn  gpa 
ii  gstreamer1.0-libav  1:1.16.1-dmo1
ii  gstreamer1.0-plugins-bad1:1.16.1-dmo2
ii  gstreamer1.0-plugins-base   1.16.1-dmo1
ii  gstreamer1.0-plugins-good   1.16.1-dmo1
ii  gstreamer1.0-plugins-ugly   1:1.16.1-dmo1
ii  hunspell-en-us [hunspell-dictionary]1:2018.04.16-1
ii  hyphen-en-us [hyphen-hyphenation-patterns]  2.8.8-7
ii  imagemagick 8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+b2
ii  libgl1  1.1.0-1+b1
pn  libreoffice-gnome | libreoffice-kde5
pn  libreoffice-grammarcheck
ii  libreoffice-help-en-us [libreoffice-help]   1:6.3.2-1
pn  libreoffice-l10n
ii  libreoffice-librelogo   1:6.3.2-1
pn  libreoffice-officebean  
ii  libsane 1.0.27-3.2+b1
ii  libxrender1 1:0.9.10-1
pn  myspell-dictionary  
ii  mythes-en-us [mythes-thesaurus] 1:6.3.1-1
ii  openclipart-libreoffice 1:0.18+dfsg-15
ii  openjdk-11-jre [java6-runtime]  11.0.5+10-2
ii  pstoedit3.74-1+b1
ii  thunderbird 

Bug#908559: openvpn: Openvpn cannot run /sbin/ip if started from systemd

[Anthony DeRobertis]

This is because /bin/ip can have cap_sys_admin set on it, and the 
capability bounding set in the unit doesn't allow that. The simple fix 
is to add cap_sys_admin to the CapabilityBoundingSet in the systemd 
service file.


... of course, cap_sys_admin is (last I checked) quite powerful, so 
maybe that renders CapabilityBoundingSet moot; but without it, openvpn 
won't work.

Bug#935173: audacity graphical windows fail to update properly

[Anthony DeRobertis]

Package: audacity
Version: 2.3.2-2
Followup-For: Bug #935173

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Same problem here with Audacity, and same workaround (unset
GTK_IM_MODULE) appears to fix it here. I'm not using any "special" input
method, I just use xim so gtk doesn't ignore custom XCompose rules.

- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-updates'), (500, 
'testing'), (500, 'stable'), (130, 'unstable-debug'), (130, 'unstable'), (120, 
'experimental-debug'), (120, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages audacity depends on:
ii  audacity-data 2.3.2-2
ii  libasound21.1.8-2
ii  libavcodec58  10:4.2.1-dmo6
ii  libavformat58 10:4.2.1-dmo6
ii  libavutil56   10:4.2.1-dmo6
ii  libc6 2.29-2
ii  libexpat1 2.2.9-1
ii  libflac++6v5  1.3.3-1
ii  libflac8  1.3.3-1
ii  libgcc1   1:9.2.1-8
ii  libgdk-pixbuf2.0-02.40.0+dfsg-1
ii  libglib2.0-0  2.62.1-1
ii  libgtk-3-03.24.12-1
ii  libid3tag00.15.1b-14
ii  liblilv-0-0   0.24.4~dfsg0-1
ii  libmad0   0.15.1b-10
ii  libmp3lame0   1:3.100-dmo1
ii  libogg0   1.3.2-1+b1
ii  libportaudio2 19.6.0-1
ii  libportsmf0   0.1~svn20101010-5
ii  libsndfile1   1.0.28-6
ii  libsoundtouch12.1.2+ds1-1
ii  libsoxr0  0.1.3-1
ii  libstdc++69.2.1-8
ii  libsuil-0-0   1:0.10.4-dmo3
ii  libtwolame0   1:0.4.0-dmo1
ii  libvamp-hostsdk3v51:2.8.0-dmo1
ii  libvorbis0a   1.3.6-2
ii  libvorbisenc2 1.3.6-2
ii  libvorbisfile31.3.6-2
ii  libwxbase3.0-0v5  3.0.4+dfsg-14
ii  libwxgtk3.0-gtk3-0v5  3.0.4+dfsg-14

audacity recommends no packages.

Versions of packages audacity suggests:
ii  amb-plugins [ladspa-plugin]  0.8.1-7+b1
ii  blepvco [ladspa-plugin]  0.1.0-3+b3
ii  bs2b-ladspa [ladspa-plugin]  0.9.1-3+b1
ii  caps [ladspa-plugin] 0.9.26-1
ii  cmt [ladspa-plugin]  1.16-2+b1
ii  ladspa-sdk [ladspa-plugin]   1.15-2
ii  mcp-plugins [ladspa-plugin]  0.4.0-6
ii  omins [ladspa-plugin]0.2.0-8
ii  rev-plugins [ladspa-plugin]  0.7.1-3+b1
ii  swh-plugins [ladspa-plugin]  0.4.17-2
ii  tap-plugins [ladspa-plugin]  1.0.0-1
ii  vco-plugins [ladspa-plugin]  0.3.0-5+b1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCXcKVLRUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf5mpQCggKwR7MEm8fAEu0JwFN5g4+lmjzQA
nRGa99xXOvlVmjcgq7VQgWZmCgXN
=JgNt
-END PGP SIGNATURE-

Bug#943597: Seems to be missing required dependencies

[Anthony DeRobertis]

Package: libsys-info-base-perl
Version: 0.7807-2
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tried to use Sys::Info::Device::CPU today, and first the Synopsis from
the perldoc doesn't work — it starts with 'use Sys::Info', which isn't
installed. Nor packaged, AFAICT. 

So tried to use it directly:

$ perl -MSys::Info::Device::CPU -E 'my $info = Sys::Info::Device::CPU->new'
Operating system identified as: 'Linux'. Native driver can not be loaded: Error 
loading Sys::Info::Driver::Linux::Device::CPU: Can't locate 
Sys/Info/Driver/Linux/Device/CPU.pm in @INC (you may need to install the 
Sys::Info::Driver::Linux::Device::CPU module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 
/usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at 
/usr/share/perl5/Sys/Info/Base.pm line 45.
 at /usr/share/perl5/Sys/Info/Device/CPU.pm line 9.
. Falling back to compatibility mode
Error loading Sys::Info::Driver::Unknown::Device::CPU: Can't locate 
Sys/Info/Driver/Unknown/Device/CPU.pm in @INC (you may need to install the 
Sys::Info::Driver::Unknown::Device::CPU module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 
/usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at 
/usr/share/perl5/Sys/Info/Base.pm line 45.
 at /usr/share/perl5/Sys/Info/Device/CPU.pm line 9.
BEGIN failed--compilation aborted at /usr/share/perl5/Sys/Info/Device/CPU.pm 
line 9.
Compilation failed in require.
BEGIN failed--compilation aborted.

Those come from the Sys-Info-Driver-Linux and Sys-Info-Driver-Unknown
packages on CPAN, also AFAIK not packaged.

Sys::Info::OS similarly does not work.

It doesn't seem like libsys-info-base-perl have any functionality w/o
the related packages.

- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-updates'), (500, 
'testing'), (500, 'stable'), (130, 'unstable-debug'), (130, 'unstable'), (120, 
'experimental-debug'), (120, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libsys-info-base-perl depends on:
ii  perl  5.30.0-8

libsys-info-base-perl recommends no packages.

libsys-info-base-perl suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCXbVCvhUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf7bYACeNgNe4JBivWCyGfXrZSwxvyUGVZwA
n3dkH76BmyphAJmsIS+gjvlyA/UN
=ZM5j
-END PGP SIGNATURE-

Bug#939983: error: Unable to read from '/sys/fs/cgroup/unified/machine/cgroup.controllers'

[Anthony DeRobertis]

Package: libvirt-daemon
Version: 5.6.0-2
Followup-For: Bug #939983

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Searching the web led to a suggestion this is from libvirt not realizing
its on a systemd machine and trying to use non-systemd cgroups. (It
should be machine.slice under systemd).

Installing systemd-container, making sure it was started
(machines.target and machine.slice, though maybe that'll happen
automatically --- certainly should on reboot), and restarting libvirt
fixed it here.

- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-updates'), (500, 
'testing'), (500, 'stable'), (130, 'unstable-debug'), (130, 'unstable'), (120, 
'experimental-debug'), (120, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvirt-daemon depends on:
ii  libblkid1   2.34-0.1
ii  libc6   2.29-2
ii  libcap-ng0  0.7.9-2+b1
ii  libdbus-1-3 1.12.16-2
ii  libdevmapper1.02.1  2:1.02.155-3
ii  libfuse22.9.9-2
ii  libgcc1 1:9.2.1-8
ii  libgnutls30 3.6.9-5
ii  libnetcf1   1:0.2.8-1+b3
ii  libparted2  3.3-1
ii  libpcap0.8  1.9.1-2
ii  libpciaccess0   0.14-1
ii  libselinux1 2.9-2+b2
ii  libudev1242-7
ii  libvirt05.6.0-2
ii  libxenmisc4.11  4.11.1+92-g6c33308a8d-2+b1
ii  libxenstore3.0  4.11.1+92-g6c33308a8d-2+b1
ii  libxentoollog1  4.11.1+92-g6c33308a8d-2+b1
ii  libxml2 2.9.4+dfsg1-7+b3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-7+b3
ii  netcat-openbsd  1.203-2
ii  qemu-kvm1:4.1-1+b2

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster  
pn  libvirt-daemon-driver-storage-rbd  
pn  libvirt-daemon-driver-storage-zfs  
ii  libvirt-daemon-system  5.6.0-2
pn  numad  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCXbOIAhUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf4P/gCfXPpKvk+nDfuSbVxcVZxMnpk9rbkA
n2rOrdrR+7rJJm7VNqqCjGxVXGIu
=IOZI
-END PGP SIGNATURE-

Bug#835086: Bug#941708: ITP: nextcloud-server -- Nextcloud folder synchronization tool (server)

[Anthony DeRobertis]

You should fix the project license on GitLab, right now it's showing all rights 
reserved. That should be in the project settings somewhere... 

Also, have you seen ? That appears like it'll 
eventually allow a non-downloader package.

Bug#932995: Weird having the "daily" preferences clean timer run hourly

[Anthony DeRobertis]

First off, thank you for the clear and detailed response. I've cut it 
below, because it requires some thought & experimentation (I've also had 
"fun" with network-online.target) — so quickly responding to only the 
easy part for now. Anyway, the easy part:


On 7/25/19 4:57 PM, Francesco Poli wrote:

I honestly thought that "Daily apt-listbugs preferences cleanup" could
fit, but I am not an English native speaker, and I would be happy to
get a suggestion for a better wording.
I'd suggest just strike the word "Daily". Just use "apt-listbugs 
preferences cleanup" (or put something like "Scheduled" or "Routine" in 
front if you want to avoid starting with a lowercase letter.

Bug#932995: Weird having the "daily" preferences clean timer run hourly

[Anthony DeRobertis]

Package: apt-listbugs
Version: 0.1.30
Severity: minor
File: /lib/systemd/system/apt-listbugs.timer

I noticed in my logs that systemd is running "Daily apt-listbugs
preferences cleanup" once per hour, which of course looks like a bug.

It seems like what is actually happening is the timer fires hourly and
then the script that is ultimately run has some logic to check if its
been a day or not. I imagine this is for cron compatability (I guess on
systems without anacron?)...

systemd timers can just do all that, though, with the Persistent=
option. That'd have a couple advantages, like being easier for the admin
to understand, easier to customize (e.g., maybe 7am isn't a good time),
and I suppose probably save a barely measurable amount of electricity.

Anyway, I'm filing this as minor, but feel free to downgrade to
wishlist. Though I suggest striking the word "daily" in the timer
Description= if you do.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 
'unstable-debug'), (200, 'unstable'), (150, 'stable-debug'), (150, 'stable'), 
(100, 'experimental-debug'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt-listbugs depends on:
ii  apt 1.8.2
ii  ruby1:2.5.1
ii  ruby-debian 0.3.9+b8
ii  ruby-gettext3.2.9-1
ii  ruby-soap4r 2.0.5-4
ii  ruby-unicode0.4.4-2+b9
ii  ruby-xmlparser  0.7.3-3+b2

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.8.3-2
ii  s6   2.7.2.2-3

Versions of packages apt-listbugs suggests:
ii  chromium [www-browser]  76.0.3809.62-1
ii  elinks [www-browser]0.13~20190125-3
ii  firefox [www-browser]   68.0.1-2
ii  google-chrome-stable [www-browser]  75.0.3770.142-1
ii  konqueror [www-browser] 4:18.12.0-1
ii  links2 [www-browser]2.19-2
ii  lynx [www-browser]  2.9.0dev.1-2
ii  reportbug   7.5.2
ii  sensible-utils  0.0.12
ii  w3m [www-browser]   0.5.3-37
ii  xdg-utils   1.1.3-1

-- no debconf information

Bug#930874: [ERROR] Failed to locate cgroup mountpoints.

[Anthony DeRobertis]

Package: ctop
Version: 1.0.0-2
Severity: important

anthony@Zia:~$ ctop 
[ERROR] Failed to locate cgroup mountpoints.

But it's mounted, and being used:

$ ls /sys/fs/cgroup/
cgroup.controllers  cgroup.procscgroup.threads  system.slice
cgroup.max.depthcgroup.stat init.scope  user.slice
cgroup.max.descendants  cgroup.subtree_control  machine.slice

Possibly ctop doesn't understand the cgroup2 unified hierarchy?

-- System Information:
Debian Release: 10.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 
'unstable-debug'), (200, 'unstable'), (150, 'stable'), (100, 
'experimental-debug'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ctop depends on:
ii  python3  3.7.3-1

ctop recommends no packages.

ctop suggests no packages.

-- no debconf information

Bug#930281: PDF which fails to index with TypeError: object of type 'NoneType' has no len()

[Anthony DeRobertis]

On Wed, Jun 12, 2019 at 07:40:14PM +0200, Jean-Francois Dockes wrote:
> 
> I am attaching a fixed script for your testing, it should replace
> /usr/share/recoll/rclpdf.py

Appears to be /usr/share/recoll/filters/rclpdf.py here. Anyway, I put
your new version in place, and that fixed all of the PDF files that had
failed. I confirmed with xadump as well, looks to work fully.

Thank you.

Bug#930281: PDF which fails to index with TypeError: object of type 'NoneType' has no len()

[Anthony DeRobertis]

Package: recoll
Version: 1.24.3-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I a bunch of PDFs which fail to index with a Python exception. A bunch
are confidential, but this one isn't.

Traceback (most recent call last):
  File "/usr/share/recoll/filters/rclpdf.py", line 523, in 
rclexecm.main(proto, extract)
  File "/usr/share/recoll/filters/rclexecm.py", line 330, in main
proto.mainloop(extract)
  File "/usr/share/recoll/filters/rclexecm.py", line 257, in mainloop
self.processmessage(processor, params)
  File "/usr/share/recoll/filters/rclexecm.py", line 237, in processmessage
self.answer(data, ipath, eof)
  File "/usr/share/recoll/filters/rclexecm.py", line 176, in answer
self.senditem("Document", docdata)
  File "/usr/share/recoll/filters/rclexecm.py", line 168, in senditem
l = len(data)
TypeError: object of type 'NoneType' has no len()

I'm attaching (a) complete output of it run with loglevel=7; (b) the
PDF; (c) recoll.conf; (d) fields file

- -- System Information:
Debian Release: 10.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (130, 
'unstable-debug'), (130, 'unstable'), (120, 'experimental-debug'), (120, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages recoll depends on:
ii  recollcmd  1.24.3-3
ii  recollgui  1.24.3-3

recoll recommends no packages.

recoll suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCXP1XtxUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf78iACfYnW4XiezE2mKKpWWB1xVIv0t48gA
oITYXzhoAgrB3ej/h4sOGJlmn1F7
=be9G
-END PGP SIGNATURE-
Script started on 2019-06-09 14:59:23-04:00 [TERM="xterm" TTY="/dev/pts/21" 
COLUMNS="162" LINES="59"]
Running scope as unit: run-r947e58c5876741de815297dad38b0b6e.scope
:3:common/rclinit.cpp:312::Configuration directory: /home/anthony/.recoll
:4:common/rclconfig.cpp:558::RclConfig::initThrConf: autoconf requested. 8 
concurrent threads available.
:4:common/rclconfig.cpp:604::RclConfig::initThrConf: chosen config (ql,nt): (2, 
5) (2, 3) (2, 1) 
:5:common/rclinit.cpp:351::rclinit: will use vfork() for starting commands
:3:index/recollindex.cpp:667::recollindex: changing current directory to [/tmp]
:4:utils/execmd.cpp:469::ExecCmd::startExec: (0|0) 
/usr/share/recoll/filters/rclcheckneedretry.sh 
:4:utils/execmd.cpp:993::ExecCmd::wait: got status 0x256
:3:index/recollindex.cpp:700::recollindex: starting up
:4:utils/execmd.cpp:469::ExecCmd::startExec: (0|0) /usr/bin/ionice {-c} {3} 
{-p} {29047} 
:4:utils/execmd.cpp:993::ExecCmd::wait: got status 0x0
:4:rcldb/rcldb.cpp:917::Db::open: m_isopen 0 m_iswritable 0 mode 1
:5:rcldb/stoplist.cpp:35::StopList::StopList: 
file_to_string(/home/anthony/.recoll/stoplist.txt) failed: open/stat: errno: 2 
: 
:4:rcldb/rcldb.cpp:249::RclDb:: threads: haveWriteQ 1, wqlen 2 wqts 1
:4:rcldb/rcldb.cpp:943::Db::open: lastdocid: 5026
:4:index/fsindexer.cpp:135::FsIndexer: threads: haveIQ 1 iql 2 iqts 5 haveSQ 1 
sql 2 sqts 3
:4:index/fsindexer.cpp:322::FsIndexer::indexFiles
:5:index/fsindexer.cpp:527::FsIndexerInternfileWorker: task fn 
/home/anthony/Filing/Schwab/2015/2015-06 — Important notice regarding delivery 
of security holder documents.pdf
:4:index/fsindexer.cpp:639::processone: needupdate 1 noretry 0 existing 
4294967295 oldsig []
:5:index/fsindexer.cpp:672::processone: processing: [48 KB ] 
/home/anthony/Filing/Schwab/2015/2015-06 — Important notice regarding delivery 
of security holder documents.pdf
:5:internfile/internfile.cpp:123::FileInterner::FileInterner(fn=/home/anthony/Filing/Schwab/2015/2015-06
 — Important notice regarding delivery of security holder documents.pdf)
:5:internfile/uncomp.cpp:41::Uncomp::Uncomp: m_docache: 0
:4:internfile/internfile.cpp:168::FileInterner::init fn 
[/home/anthony/Filing/Schwab/2015/2015-06 — Important notice regarding delivery 
of security holder documents.pdf] mime [(null)] preview 0
:4:utils/execmd.cpp:469::ExecCmd::startExec: (0|1) git-annex-meta-to-recoll 
{/home/anthony/Filing/Schwab/2015/2015-06 — Important notice regarding delivery 
of security holder documents.pdf} 
:5:utils/netcon.cpp:369::Netcon::selectloop: fd 11 has 0x0 mask, erasing
:5:utils/execmd.cpp:827::ExecCmd::doexec: selectloop returned 0
:4:utils/execmd.cpp:993::ExecCmd::wait: got status 0x0
:4:internfile/mimehandler.cpp:268::getMimeHandler: mtype [application/pdf] 
filtertypes 1
:4:internfile/mimehandler.cpp:64::getMimeHandlerFromCache: 
259dc001f1d38c8b4c425d19d34b1c4f cache size 0
:4:internfile/mimehandler.cpp:80::getMimeHandlerFromCache: 
259dc001f1d38c8b4c425d19d34b1c4f not found
:4:internfile/internfile.cpp:255::FileInterner:: 

Bug#927725: Please build with --enable-mmdblookup

[Anthony DeRobertis]

On 4/23/19 5:12 AM, Michael Biebl wrote:


My main concern is to keep the rsyslog core package reasonably small
(dependency wise).



If you check 
, 
note that a Depends is only required if "the depended-on package is 
required for the depending package to provide a significant amount of 
functionality". That, taken together with the tools typically installing 
Recommends by default, means you can make the libraries Recommends, not 
Depends. Or maybe even as Suggests.


Ideally, rsyslog would give a nice error if it fails to load a plugin 
due to a missing shared library, but even without that you can just 
mention needing to install Recommends and/or Suggests to use various 
optional plugins in the package extended description, README.Debian, etc.


(Of course, this does make the packaging a bit more complicated, since 
you'll need to add some -d options to your dpkg-shlibdeps call. Probably 
easier than even more extra packages, though.)

Bug#921280: systemd-cgtop no longer shows memory usage

[Anthony DeRobertis]

On 2/28/19 1:48 PM, Michael Biebl wrote:


Hm, interesting.
I see that this particular PR is not part of v241.
That said, when I run systemd-cgtop I *do* see the memory usage column
with 241-1

Anthony, could you please re-test with this version and report back?



I installed systemd 241-1 from unstable. systemd-cgtop still doesn't 
display memory usage. Since kernel version apparently matters,


$ uname -a
Linux Watt 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64 
GNU/Linux


I went ahead and tried the patch from 
https://github.com/systemd/systemd/pull/11775 and installed that, and it 
works. (though I installed and not configured, since the dependencies 
are really tight, and I also have libsystemd0:i386 here, which I didn't 
wind up building on my amd64 box...) So the patch fixes it.

Bug#921685: 1.8.0~rc2 breaks using Release.gpg instead of InRelease

[Anthony DeRobertis]

Sorry it took so long to confirm, but indeed adding -a to the gpg line
fixes this problem. And continues to work at least all the way back to
Sarge...

So, I don't think there is anything to do but a ideally a clearer error
message and also some documentation.

Bug#921888: apparmor: allow access to ~/.local/share/mime/**

[Anthony DeRobertis]

On February 10, 2019 2:56:18 PM UTC, Vincas Dargis  wrote:
>
>Anthony, what's your DE?

On that machine... well, it's complicated. It runs e16, and a random selection 
apps from both  KDE and GNOME. It's the one machine I haven't switched over to 
KDE. 

(BTW, for trying to reproduce it, pretty sure it only happens when displaying 
calendar reminders. Not sure it happened with any other Thunderbird usage.) 

Bug#921888: apparmor: allow access to ~/.local/share/mime/**

[Anthony DeRobertis]

Package: thunderbird
Version: 1:60.4.0-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Whenever a calendar reminder is displaying, Thunderbird is flooding my
logs with apparmor denials:

Feb  9 16:20:34 Watt kernel: [518027.774746] audit: type=1400 
audit(1549747234.261:2371): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/mime.cache" 
pid=4245 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
Feb  9 16:20:34 Watt kernel: [518027.774759] audit: type=1400 
audit(1549747234.261:2372): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/globs2" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:20:34 Watt kernel: [518027.774761] audit: type=1400 
audit(1549747234.261:2373): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/magic" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:20:34 Watt kernel: [518027.774764] audit: type=1400 
audit(1549747234.261:2374): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/aliases" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:20:34 Watt kernel: [518027.774765] audit: type=1400 
audit(1549747234.261:2375): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/subclasses" 
pid=4245 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
Feb  9 16:20:34 Watt kernel: [518027.774768] audit: type=1400 
audit(1549747234.261:2376): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/icons" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:20:34 Watt kernel: [518027.774770] audit: type=1400 
audit(1549747234.261:2377): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/generic-icons" 
pid=4245 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
Feb  9 16:20:48 Watt kernel: [518041.905303] audit: type=1400 
audit(1549747248.393:2378): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/mime.cache" 
pid=4245 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
Feb  9 16:20:48 Watt kernel: [518041.905317] audit: type=1400 
audit(1549747248.393:2379): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/globs2" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:20:48 Watt kernel: [518041.905319] audit: type=1400 
audit(1549747248.393:2380): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/magic" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:20:48 Watt kernel: [518041.905321] audit: type=1400 
audit(1549747248.393:2381): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/aliases" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:20:48 Watt kernel: [518041.905323] audit: type=1400 
audit(1549747248.393:2382): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/subclasses" 
pid=4245 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
Feb  9 16:20:48 Watt kernel: [518041.905325] audit: type=1400 
audit(1549747248.393:2383): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/icons" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:20:48 Watt kernel: [518041.905327] audit: type=1400 
audit(1549747248.393:2384): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/generic-icons" 
pid=4245 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
Feb  9 16:21:07 Watt kernel: [518060.691464] audit: type=1400 
audit(1549747267.178:2385): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/mime.cache" 
pid=4245 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
Feb  9 16:21:07 Watt kernel: [518060.691471] audit: type=1400 
audit(1549747267.178:2386): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/globs2" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Feb  9 16:21:07 Watt kernel: [518060.691474] audit: type=1400 
audit(1549747267.178:2387): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.local/share/mime/magic" pid=4245 
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 

Bug#921685: 1.8.0~rc2 breaks using Release.gpg instead of InRelease

[Anthony DeRobertis]

Ah, that's it. It's a binary detached signature. I probably missed the 
documentation when it was originally set up (or maybe it hasn't always been 
documented well, it was originally set up a decade ago).

I'll fix the signature generation later today and confirm.

I don't see a problem with dropping support for binary signatures, at least 
with a better error message and maybe it deserves a release note.

Bug#921685: 1.8.0~rc2 breaks using Release.gpg instead of InRelease

[Anthony DeRobertis]

Package: libapt-pkg5.0
Version: 1.8.0~rc2
Severity: important

We have a local repository here which is generated with an (ancient!)
version of mini-dinstall. This worked fine until rc2. The problem
appears to be that it uses Release and Release.gpg instead of InRelease.

root@648fb8052f3f:/# apt-get update
Ign:1 http://haruhi.metrics.net/deb buster/ InRelease
Get:2 http://haruhi.metrics.net/deb buster/ Release [1521 B]
Get:3 http://haruhi.metrics.net/deb buster/ Release.gpg [88 B]  
   
Get:5 http://haruhi.metrics.net/deb buster/ Packages [3626 B]   
   
Get:4 http://security-cdn.debian.org/debian-security buster/updates 
InRelease [38.3 kB]
Get:6 http://cdn-fastly.deb.debian.org/debian buster InRelease [159 kB] 
 
Get:7 http://cdn-fastly.deb.debian.org/debian buster-updates InRelease 
[47.6 kB]
Get:8 http://cdn-fastly.deb.debian.org/debian buster/main amd64 Packages 
[7958 kB]
Fetched 8208 kB in 3s (2477 kB/s)   
Reading package lists... Done
root@648fb8052f3f:/# apt-get install libapt-pkg5.0=1.8.0~rc2
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  apt
Suggested packages:
  apt-doc aptitude | synaptic | wajig dpkg-dev gnupg | gnupg2 | gnupg1 
powermgmt-base
Recommended packages:
  ca-certificates
The following packages will be upgraded:
  apt libapt-pkg5.0
2 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
Need to get 2280 kB of archives.
After this operation, 14.3 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://cdn-fastly.deb.debian.org/debian buster/main amd64 
libapt-pkg5.0 amd64 1.8.0~rc2 [965 kB]
Get:2 http://cdn-fastly.deb.debian.org/debian buster/main amd64 apt amd64 
1.8.0~rc2 [1315 kB]
Fetched 2280 kB in 1s (3919 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 6577 files and directories currently installed.)
Preparing to unpack .../libapt-pkg5.0_1.8.0~rc2_amd64.deb ...
Unpacking libapt-pkg5.0:amd64 (1.8.0~rc2) over (1.8.0~beta1) ...
Setting up libapt-pkg5.0:amd64 (1.8.0~rc2) ...
(Reading database ... 6577 files and directories currently installed.)
Preparing to unpack .../apt_1.8.0~rc2_amd64.deb ...
Unpacking apt (1.8.0~rc2) over (1.8.0~beta1) ...
Setting up apt (1.8.0~rc2) ...
Processing triggers for libc-bin (2.28-5) ...
root@648fb8052f3f:/# apt-get update
Ign:1 http://haruhi.metrics.net/deb buster/ InRelease
Hit:2 http://haruhi.metrics.net/deb buster/ Release 
   
Err:3 http://haruhi.metrics.net/deb buster/ Release.gpg 
   
  Signed file isn't valid, got 'NODATA' (does the network require 
authentication?)
Hit:5 http://cdn-fastly.deb.debian.org/debian buster InRelease  
 
Hit:4 http://security-cdn.debian.org/debian-security buster/updates 
InRelease
Hit:6 http://cdn-fastly.deb.debian.org/debian buster-updates InRelease
Reading package lists... Done
W: An error occurred during the signature verification. The repository is 
not updated and the previous index files will be used. GPG error: 
http://haruhi.metrics.net/deb buster/ Release: Signed file isn't valid, got 
'NODATA' (does the network require authentication?)
W: Failed to fetch http://haruhi.metrics.net/deb/buster/Release.gpg  Signed 
file isn't valid, got 'NODATA' (does the network require authentication?)
W: Some index files failed to download. They have been ignored, or old ones 
used instead.

I think it's the lack of an InRelease file because when I ran this (in
the repository):

$ gpg --clearsign < Release > InRelease

... then "apt-get update" is happy again.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 
'unstable-debug'), (200, 'unstable'), (150, 'stable'), (100, 
'experimental-debug'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#921280: systemd-cgtop no longer shows memory usage

[Anthony DeRobertis]

Package: systemd
Version: 240-5
Severity: normal
File: /usr/bin/systemd-cgtop

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

systemd-cgtop now displays '-' for all memory usage columns. Not sure
exactly when it stopped working, I had it running in a terminal for a
long time (so it was an old version). When I finally restarted it, it no
longer worked. Even after rebooting the machine, it continues to not
work.

Control Group Tasks 
  %CPU   Memory  Input/s Output/s
/   781 
  11.6---
/init.scope   1 
 ----
/system.slice   238 
   1.2---
/system.slice/acpid.service   1 
   0.0---
/system.slice/apache-htcacheclean.service 1 
   0.0---
/system.slice/apache2.service11 
   0.0---
/system.slice/atd.service 1 
 ----
⋮

Memory accounting information shows fine in `systemctl status`, though:

$ systemctl status atd.service
● atd.service - Deferred execution scheduler
   Loaded: loaded (/lib/systemd/system/atd.service; enabled; vendor preset: enab
   Active: active (running) since Sun 2019-02-03 16:27:07 EST; 13min ago
 Docs: man:atd(8)
  Process: 1503 ExecStartPre=/usr/bin/find /var/spool/cron/atjobs -type f -name 
 Main PID: 1565 (atd)
Tasks: 1 (limit: 4915)
   Memory: 1.3M
  CPU: 4ms
   CGroup: /system.slice/atd.service
   └─1565 /usr/sbin/atd -f

Feb 03 16:27:06 Watt systemd[1]: Starting Deferred execution scheduler...
Feb 03 16:27:07 Watt systemd[1]: Started Deferred execution scheduler.

I'm booting with systemd.unified_cgroup_hierarchy=1 if it matters.


- -- Package-specific info:

- -- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (130, 
'unstable-debug'), (130, 'unstable'), (120, 'experimental-debug'), (120, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.13.2-7
ii  libaudit11:2.8.4-2
ii  libblkid12.33.1-0.1
ii  libc62.28-5
ii  libcap2  1:2.25-1.2
ii  libcryptsetup12  2:2.0.6-1
ii  libgcrypt20  1.8.4-4
ii  libgnutls30  3.6.6-2
ii  libgpg-error01.33-3
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-3
ii  libkmod2 25-2
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.2-1.3
ii  libmount12.33.1-0.1
ii  libpam0g 1.1.8-4
ii  libseccomp2  2.3.3-3
ii  libselinux1  2.8-1+b1
ii  libsystemd0  240-5
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.12-1
ii  libpam-systemd  240-5

Versions of packages systemd suggests:
ii  policykit-10.105-25
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.132
ii  udev 240-5

- -- Configuration Files:
/etc/systemd/system.conf changed:
[Manager]
DefaultCPUAccounting=yes
DefaultMemoryAccounting=yes


- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCXFdgiBUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf50PQCdEhQOhXiA7v/qi/IRdbVnovWzrMMA
n0zKtwj5lJ8BazDXSybxJw2JAX7/
=Cs2T
-END PGP SIGNATURE-

Bug#900173: Still seeing strange closure type

[Anthony DeRobertis]

Just to check in, I've still been seeing this fairly consistently.
Hoping someone can suggest some further debugging steps.

Today the message seems slightly different:

[2019-01-14 12:06:24.690252594] main: starting assistant version 7.20181211
git-annex: internal error: evacuate: strange closure type 4325407
(GHC version 8.4.4 for x86_64_unknown_linux)
Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

so the number has changed from 4325404 to 4325407. Not sure if that
means anything.

Bug#917530: perldoc formatting unfortunately degraded by upstream compatability fix

[Anthony DeRobertis]

Package: perl-doc
Version: 5.28.1-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In f2ee4cb897ec9dd3338abcd0e9a42cb41ce9a173[0] upstream worked around
reported issues with perldoc by changing the default formatter to ToText
(from ToTerm) and also getting rid of automatically setting pager
options (like -R to less). 

This, of course, also removed all bold/underline/etc. from the output,
making perldoc less readable.

- From reading through the various related bugs (e.g., [1]) it seems like
they switched away from using groff (via ToMan) because Mac OS Sierra
has a groff without Unicode support. That obviously doesn't apply to
Debian, so it seems we could have nice rendering without any pager
workarounds just by changing the default back to Pod::Perldoc::ToMan.

Or at least a note in README.Debian about adding something like one of
these to .bashrc:

export PERLDOC=-oTerm PERLDOC_PAGER='less -R' # works like Stretch, Jessie
export PERLDOC=-oMan  # works like Wheezy

[0]: 
https://perl5.git.perl.org/perl.git/commit/f2ee4cb897ec9dd3338abcd0e9a42cb41ce9a173
[1]: https://rt.cpan.org/Public/Bug/Display.html?id=120229

- -- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (130, 
'unstable-debug'), (130, 'unstable'), (120, 'experimental-debug'), (120, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages perl-doc depends on:
ii  perl  5.28.1-3

perl-doc recommends no packages.

Versions of packages perl-doc suggests:
ii  groff-base   1.22.3-10
ii  konqueror [man-browser]  4:18.04.0-1+b2
ii  man-db [man-browser] 2.8.4-3

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCXCXtuhUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf4WmgCfeiTVl76yHBuWJTrEy3XJfMhQorkA
n02XnQ95YomQyzy/WHvImWA5MD9w
=dQql
-END PGP SIGNATURE-

Bug#916149: Segfault on systemctl stop or systemctl restart

[Anthony DeRobertis]

On 12/10/18 3:00 PM, Till Kamppeter wrote:

Fixed upstream in commit f3d48ecd.

The checking for HTTP timeouts on queue creation has be done at the 
wrong place, leading to crashes on queue removal, which happens on 
shutdown.



Thank you. I applied the patch and confirm the crash at stop is gone.

Bug#916149: Segfault on systemctl stop or systemctl restart

[Anthony DeRobertis]

Package: cups-browsed
Version: 1.21.4-1
Severity: important

(Note: I'm currently running 1.21.5-1, but have set the version above
because I believe this started with 1.21.4-1. I apologize for not
reporting it earlier — I hadn't noticed it...)

Every time cups-browsed is stopped (or restarted), it segfaults. Since
its restarted every night, I checked the journal to see when this
behavior started (note the logs go back to September — so it started on
December 4). There are a bunch more on the 5th, from restarting it many
times about the now-fixed job-loss bug.

Dec 04 00:00:04 Zia systemd[1]: cups-browsed.service: Main process exited, 
code=killed, status=11/SEGV
Dec 05 00:00:08 Zia systemd[1]: cups-browsed.service: Main process exited, 
code=killed, status=11/SEGV
Dec 05 11:28:13 Zia systemd[1]: cups-browsed.service: Main process exited, 
code=killed, status=11/SEGV
Dec 05 11:28:42 Zia systemd[1]: cups-browsed.service: Main process exited, 
code=killed, status=11/SEGV
Dec 05 11:29:03 Zia systemd[1]: cups-browsed.service: Main process exited, 
code=killed, status=11/SEGV

The logs continue like that through present, including a few test stops
I just did to be sure.

I looked at the dpkg log and found:

2018-12-03 16:04:59 upgrade cups-browsed:amd64 1.21.3-3 1.21.4-1
2018-12-03 16:04:59 status half-configured cups-browsed:amd64 1.21.3-3
2018-12-03 16:04:59 status unpacked cups-browsed:amd64 1.21.3-3
2018-12-03 16:04:59 status half-installed cups-browsed:amd64 1.21.3-3
2018-12-03 16:05:00 status unpacked cups-browsed:amd64 1.21.4-1
⋮
2018-12-03 16:15:11 configure cups-browsed:amd64 1.21.4-1 
2018-12-03 16:15:11 status unpacked cups-browsed:amd64 1.21.4-1
2018-12-03 16:15:26 conffile /etc/cups/cups-browsed.conf keep
2018-12-03 16:15:26 status half-configured cups-browsed:amd64 1.21.4-1
2018-12-03 16:15:28 status installed cups-browsed:amd64 1.21.4-1

So I think that 1.21.4-1 introduced this.

I installed systemd-coredump to get a core dump and thus back trace (via
gdb), which I have attached.


-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 
'unstable-debug'), (200, 'unstable'), (150, 'stable'), (100, 
'experimental-debug'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages cups-browsed depends on:
ii  cups-daemon   2.2.9-2
ii  libavahi-client3  0.7-4+b1
ii  libavahi-common3  0.7-4+b1
ii  libavahi-glib10.7-4+b1
ii  libc6 2.27-8
ii  libcups2  2.2.9-2
ii  libcupsfilters1   1.21.4-1
ii  libglib2.0-0  2.58.1-2
ii  libldap-2.4-2 2.4.46+dfsg-5+b1
ii  lsb-base  9.20170808

Versions of packages cups-browsed recommends:
ii  avahi-daemon  0.7-4+b1

cups-browsed suggests no packages.

-- Configuration Files:
/etc/cups/cups-browsed.conf changed:
BrowseRemoteProtocols none
BrowseLocalProtocols none
BrowsePoll watt.home
NewIPPPrinterQueuesShared No
AutoClustering No


-- no debconf information


cups-browsed-backtrace.gz
Description: application/gzip

Bug#913328: closed by Florian Schlichting (Re: [Pkg-mpd-maintainers] Bug#913328: both system and user service?)

[Anthony DeRobertis]

> > and tracked it down to mpd is installed as both a system service (which
> > I've configured, and been using for a while) and a systemd user service,
> 
> are you sure this is the systemd user service, rather than
> /etc/xdg/autostart/mpd.desktop?

Yes. Here is a fuller excerpt from the journal:

Nov 09 04:12:06 Watt systemd[1]: Starting User Manager for UID 1000...
Nov 09 04:12:06 Watt systemd-logind[952]: New session 2 of user anthony.
Nov 09 04:12:06 Watt systemd[1]: Started Session 2 of user anthony.
Nov 09 04:12:06 Watt systemd[3999]: pam_unix(systemd-user:session): session 
opened for user anthony by (uid=0)
Nov 09 04:12:07 Watt systemd[3999]: Listening on GnuPG cryptographic agent and 
passphrase cache (restricted).
Nov 09 04:12:07 Watt systemd[3999]: Listening on GnuPG cryptographic agent and 
passphrase cache.
Nov 09 04:12:07 Watt systemd[3999]: Starting D-Bus User Message Bus Socket.
Nov 09 04:12:07 Watt systemd[3999]: Reached target Timers.
Nov 09 04:12:07 Watt mpd[4010]: exception: failed to open log file 
"/var/log/mpd/mpd.log" (config line 38): Permission denied
Nov 09 04:12:07 Watt systemd[3999]: Reached target Paths.
Nov 09 04:12:07 Watt systemd[3999]: Listening on GnuPG network certificate 
management daemon.
Nov 09 04:12:07 Watt systemd[3999]: Listening on Sound System.
Nov 09 04:12:07 Watt systemd[3999]: Listening on GnuPG cryptographic agent 
(ssh-agent emulation).
Nov 09 04:12:07 Watt systemd[3999]: Listening on GnuPG cryptographic agent and 
passphrase cache (access for web browsers).
Nov 09 04:12:07 Watt systemd[3999]: Listening on D-Bus User Message Bus Socket.
Nov 09 04:12:07 Watt systemd[3999]: Reached target Sockets.
Nov 09 04:12:07 Watt systemd[3999]: Reached target Basic System.
Nov 09 04:12:07 Watt systemd[1]: Started User Manager for UID 1000.
Nov 09 04:12:07 Watt systemd[3999]: Starting Music Player Daemon...
Nov 09 04:12:07 Watt systemd[3999]: mpd.service: Main process exited, 
code=exited, status=1/FAILURE
Nov 09 04:12:07 Watt systemd[3999]: mpd.service: Failed with result 'exit-code'.
Nov 09 04:12:07 Watt systemd[3999]: Failed to start Music Player Daemon.
Nov 09 04:12:07 Watt systemd[3999]: Reached target Default.
Nov 09 04:12:07 Watt systemd[3999]: Startup finished in 743ms.
Nov 09 04:12:07 Watt systemd[3999]: Started D-Bus User Message Bus.

So that's clearly the systemd user service.

(I'm not sure the weird setup I have on that machine even pays attention
to /etc/xdg/autostart)

> 
> > which I'm not sure what it's for, but it (obviously) fails to write to
> > system-wide logs.
> > 
> > Seems like only one of the two ways should run on a given machine. Or at
> > least the user service ought to use a different config file.
> 
> There are many ways MPD can be started. The default nowadays is when a
> user is logging into a desktop environment, as most users have their own
> music collection and their desktop session starts a pulseaudio instance
> that needs to be used as output. This works best with a personal
> ~/.mpdconf containing adjusted paths etc.

I wonder if it wouldn't make sense to add a
ConditionPathExists=%h/.mpdconf (or even Assert…) to the user unit. I'm
not sure it makes sense to try to start from both XDG autostart and
systemd... one of those is going to fail, and probably in an
unpredictable race — but I'm not sure what the best way to fix that is
(since of course systemd and the systemd user session are optional).

(I'm running mpd for yet another purpose — its handling the library
management for a remote mpd running on a Raspberry Pi, which is what
does all the actual music playing.)

Bug#908147: restarting cups-browsed deleted print jobs

[Anthony DeRobertis]

On 12/5/18 4:49 PM, Till Kamppeter wrote:
cups-browsed is part of cups-filters, not of CUPS. The patch you find 
here:


https://github.com/OpenPrinting/cups-filters/commit/0d29084a864ca80ada8b4eafc2d36f072e06f984 




I applied your patch and it has fixed the problem for me. Thank you!

Bug#908147: restarting cups-browsed deleted print jobs

[Anthony DeRobertis]

On 12/5/18 4:20 PM, Till Kamppeter wrote:
Anyone suffering this problem, can you apply my upstream fix and check 
again whether this solves the problem? Thanks.


   Till


I can't find 0d29084a864c anywhere. I checked:

 * https://github.com/apple/cups
 * https://github.com/tillkamppeter/cups
 * https://salsa.debian.org/printing-team/cups

Could you please point to where you've published it (or, alternatively, 
email the patch). I hope it applies against 2.2.9 which Debian currently 
has, or this could get interesting.

Bug#908147: restarting cups-browsed deleted print jobs

[Anthony DeRobertis]

On 12/5/18 3:41 PM, Till Kamppeter wrote:


Anyone here who can reproduce the vanishing of print jobs when 
stopping or restarting cups-browsed, please put cups-browsed in debug 
logging mode by stopping it, editing /etc/cups/cups-browsed.conf to 
contain a line


DebugLogging file


I've attached three cups-browsed_log logs and my cups-browsed.conf.

The three logs were made from four restarts of cups-browsed. After each 
start, I did a "mv cups-browsed_log cbl-N" to keep each start separate 
(it kept writing to the same file after mv):


(a) un-comment DebugLogging file, restart [finishes none, this starts 
log #1]


(b) pause printer, send print job, restart cups-browsed [finishes #1, 
starts #2]


(c) pause printer, send print job, restart cups-browsed [finishes #2, 
starts #3]


(d) comment back out DebugLogging, restart [finishes #3, starts none]

The print job from (b) was preserved and sent on; the print job from (c) 
was lost.


PS: On the off-chance the implicitclass being lowercased every other 
restart was a cause, I created a second PDF queue "lcpdf" on Watt, so 
that there wouldn't be a miss-match every other restart. That one always 
displays lowercase, but it still exhibits the every-other-restart 
behavior w/r/t/ deleting jobs.




cups-browsed.conf.gz
Description: application/gzip


cbl-1.gz
Description: application/gzip


cbl-2.gz
Description: application/gzip


cbl-3.gz
Description: application/gzip

Bug#908147: restarting cups-browsed deleted print jobs

[Anthony DeRobertis]

Actually, I'm using cups-browsed's BrowsePoll here, the printers are on 
another network over a VPN. I have no idea if that matters.


The alternative to using cups-browsed for that use case is, so far as I 
know, to just configure the printers statically. I prefer not to, as 
that means copying around a bunch of config.


I'm glad someone else is seeing this too, though. Especially after 
determining it was deleting jobs every other restart I was beginning to 
worry that I might just be a crazy person :-/

Bug#908147: restarting cups-browsed deleted print jobs

[Anthony DeRobertis]

Just re-tested:

1. Went to http://localhost:631/printers/PDF_watt_home and under
   "Maintenance" picked "pause printer". Entered username & password
   when prompted.
2. Generated a print job with: fortune -s | lpr -PPDF_watt_home
3. Confirmed a print job in the queue at
   http://localhost:631/printers/PDF_watt_home
4. Ran systemctl restart cups-browsed.service
5. Job stayed...
6. Ran systemctl stop cups-browsed.service ; systemctl start
   cups-browsed.service
7. Job vanished.

That is... odd. So I tried printing another job, getting an "No 
destination host name supplied by cups-browsed for printer 
\"pdf_watt_home\", is cups-browsed running?" error showing up in the 
CUPS error log (and webui) eventually. After that, "systemctl restart 
cups-browsed.service" made the job vanish.


Now that printer seems permanently broken (with that no destination 
error). So I restarted cups.service (which also deleted the print job). 
Still got the error.


It's weird I'm also getting errors in the CUPS error log like:

E [05/Dec/2018:11:38:24 -0500] [Client 22] Returning IPP 
client-error-bad-request for CUPS-Add-Modify-Printer 
(ipp://localhost:631/printers/pdf_watt_home) from localhost.


To get it back working, I stopped cups-browsed.service, deleted all the 
printers it added via CUPS webui, stopped cups.service, started 
cups.service, and then started cups-browsed.service again. Got those 
weird error log entries again.


After that, tested again and it didn't delete the job, but restarting 
cups-browsed.service resumed the print queue (which it probably 
shouldn't, since I manually paused it, but that's much more minor).


Just to be sure, paused it again, added another job, and restarted 
cups-browsed.service: it deleted the job.


Tested again: unpaused, job not lost.

Tested again: job lost

Tested again: unpaused, not lost.

Tested again: job lost

Tested again: unpaused, not lost

... so... umm... it seems to lose jobs every other restart.

So I restarted it immediately again, without sending a print job. Then 
tested again, and not lost. It really does appear to be every other restart.


I think I've noticed something though. On restarting it, the 
"Connection:" changes in the CUPS web ui. Sometimes its 
"implicitclass://pdf_watt_home/" other times 
"implicitclass://PDF_watt_home/".  Each restart of cups-browsed.service 
changes back and forth. And it appears lowercased printer names lose 
jobs on restart.


I have two remote printers, and they have opposite lowercase-states. I 
haven't tested as much with the other printer (it's a real printer, so 
testing wastes paper & toner), but it appears to follow the same 
lowercase-means-jobs-lost rule. (BTW: It gets the error log entries too).


I tried to find more details about the bad requests, but it doesn't 
appear to actually be sending IPP requests — or at least, not one that 
Wireshark can capture on lo (it sees the requests from Firefox, so it's 
working). Possibly it sends them over the cups UNIX socket.


On 12/1/18 12:04 PM, gregor herrmann wrote:

On Thu, 06 Sep 2018 13:31:51 -0400, Anthony DeRobertis wrote:


After doing so, the queue in the browser refreshed and showed empty. But
I checked — the PDFs were not created. Showing completed jobs shows
nothing. Looking in /var/spool/cups (on both the local machine and the
remote machine) shows no sign of the two jobs.

I can't reproduce this bug but maybe I did something wrong. What I
did was:

- print to a printer which is not available
- check in the cups web ui and in /var/spool/cups that the print job
   is there
- service cups-browsed restart
- and the job is still in the spool and the web ui still shows the job
   and the problem (printer not responding; well, it's a few hundred
   kilometers away)

(In the spirit of full disclosure: this is with sysv-init and not
systemd, in case this makes a difference.)


Cheers,
gregor, from the Bern BSP

Bug#909682: Bug #909682: Memory leak with gst_tag_list_add_id3_image

[Anthony DeRobertis]

So, as promised, I've been playing that album again, and it's again 
leaking memory. I tried a few things to get it to free the memory. 
Putting tracks from a different album in the middle didn't do it. 
Neither did deleting the rest of the album from the playlist and playing 
something else (in fact, it continued to leak — just <1MB at a time, 
presumably due to the new album having a single smaller picture). Maybe 
it's also really noticeable because there are 29 large pictures attached 
to each track.


I got a better backtrack from gdb:

Thread 23 "task116" hit Breakpoint 1, 0x7f89dd9fe320 in 
gst_tag_list_add_id3_image () from /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0
(gdb) bt
#0  0x7f89dd9fe320 in gst_tag_list_add_id3_image () at 
/usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0
#1  0x7f8998013b00 in gst_flac_parse_handle_picture (buffer=0x7f88d814bce0, 
flacparse=0x7f891e1c3690 [GstFlacParse])
at /usr/include/gstreamer-1.0/gst/base/gstbytereader.h:651
#2  0x7f8998013b00 in gst_flac_parse_handle_block_type 
(sbuffer=0x7f88d814bce0, type=6, flacparse=0x7f891e1c3690 [GstFlacParse])
at gstflacparse.c:1520
#3  0x7f8998013b00 in gst_flac_parse_parse_frame (frame=0x7f89250505e0, 
frame=0x7f89250505e0, size=301495, parse=0x7f891e1c3690 [GstFlacParse]) at 
gstflacparse.c:1574
#4  0x7f8998013b00 in gst_flac_parse_handle_frame (parse=0x7f891e1c3690 
[GstFlacParse], frame=0x7f89250505e0, skipsize=)
at gstflacparse.c:870
#5  0x7f89dcce46b2 in gst_base_parse_handle_buffer 
(parse=parse@entry=0x7f891e1c3690 [GstFlacParse], buffer=, 
skip=skip@entry=0x7f895fffe75c, flushed=flushed@entry=0x7f895fffe758) at 
gstbaseparse.c:2160
#6  0x7f89dcce4d8f in gst_base_parse_scan_frame (parse=parse@entry=0x7f891e1c3690 
[GstFlacParse], klass=)
at gstbaseparse.c:3464
#7  0x7f89dcce8302 in gst_base_parse_loop (pad=) at 
gstbaseparse.c:3543
#8  0x7f89dcc30f41 in gst_task_func (task=0x7f897c237050 [GstTask]) at 
gsttask.c:332
#9  0x7f89dcdb0ad3 in g_thread_pool_thread_proxy (data=) at 
../../../../glib/gthreadpool.c:307
#10 0x7f89dcdb0135 in g_thread_proxy (data=0x7f8924ffb0f0) at 
../../../../glib/gthread.c:784
#11 0x7f89dd154f2a in start_thread (arg=0x7f895700) at 
pthread_create.c:463
#12 0x7f89db094edf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) c
Continuing.

Looks like its some threaded workpool... I later added a breakpoint on 
pthread_create to try and see where the thread is coming from, and it 
looks like the threads are creating more threads and maybe never 
exiting? This appears to happen every track (the task number goes up by 
two each time; I didn't add the breakpoint on pthread_create in time to 
catch 116 creating 118, probably. Here is 118 creating 120, which then 
goes on to cal gst_tag_list_add_id3_image):


Thread 26 "task118" hit Breakpoint 2, __pthread_create_2_1 
(newthread=newthread@entry=0x7f89004337a0, attr=attr@entry=0x7f89717f5610,
start_routine=start_routine@entry=0x7f89dcdb00e0 , 
arg=arg@entry=0x7f8900433770) at pthread_create.c:610
610 in pthread_create.c
(gdb) bt
#0  0x7f89dd155210 in __pthread_create_2_1 
(newthread=newthread@entry=0x7f89004337a0, attr=attr@entry=0x7f89717f5610, 
start_routine=start_routine@entry=0x7f89dcdb00e0 , 
arg=arg@entry=0x7f8900433770) at pthread_create.c:610
#1  0x7f89dcdce2e0 in g_system_thread_new 
(thread_func=thread_func@entry=0x7f89dcdb00e0 , 
stack_size=stack_size@entry=0, error=error@entry=0x7f89717f56e0) at 
../../../../glib/gthread-posix.c:1177
#2  0x7f89dcdb043f in g_thread_new_internal (name=0x7f89dcde27c2 "pool", 
proxy=0x7f89dcdb00e0 , func=0x7f89dcdb0a60 , 
data=0x7f89b0050780, stack_size=0, error=0x7f89717f56e0) at ../../../../glib/gthread.c:874
#3  0x7f89dcdb07ad in g_thread_pool_start_thread 
(pool=pool@entry=0x7f89b0050780, error=error@entry=0x7f89717f56e0)
at ../../../../glib/gthreadpool.c:407
#4  0x7f89dcdb0da3 in g_thread_pool_start_thread (error=0x7f89717f56e0, 
pool=0x7f89b0050780) at ../../../../glib/gthreadpool.c:552
#5  0x7f89dcdb0da3 in g_thread_pool_push (pool=0x7f89b0050780, 
data=data@entry=0x7f8959f45f20, error=error@entry=0x7f89717f5750)
at ../../../../glib/gthreadpool.c:563
#6  0x7f89dcc31f6a in default_push (pool=0x7f89b0043920 [GstTaskPool], 
func=0x7f89dcc30dc0 , user_data=, 
error=0x7f89717f5750) at gsttaskpool.c:106
#7  0x7f89dcc31b26 in start_task (task=0x7f88e1746710 [GstTask]) at 
gsttask.c:652
#8  0x7f89dcc31b26 in gst_task_set_state (task=task@entry=0x7f88e1746710 
[GstTask], state=state@entry=GST_TASK_STARTED) at gsttask.c:704
#9  0x7f89dcc061bb in gst_pad_start_task (pad=0x7f890f81ac90 [GstPad], 
func=0x7f897056cd80 , user_data=0x7f890f81ac90, 
notify=0x0) at gstpad.c:6169
#10 0x7f89dcc003e6 in gst_pad_set_active (pad=pad@entry=0x7f890f81ac90 
[GstPad], active=1) at gstpad.c:1107
#11 0x7f89dcbde0ad in activate_pads (vpad=, 
ret=0x7f89717f58a0, active=0x7f89717f58fc) 

Bug#909682: Bug #909682: Memory leak with gst_tag_list_add_id3_image

[Anthony DeRobertis]

It went away at some point after that and I haven't seen it since... but 
you all are right, it might be file-specific. I plopped "lastplayed:>62d 
lastplayed:<64d" into the filter box, which should get to what I was 
playing around the time of that bug report, and it appears it was 
https://musicbrainz.org/release/db77f67d-9e9b-4623-8ea1-baab173cbe49 — 
which is weird, because that file shouldn't be any different than most 
of the others in my collection: it was ripped from CD to FLAC with 
morituri, replaygain added with metaflac, cover art scanned & uploaded 
to Cover Art Archive then put in the files w/ tags via Picard.


It is a long album (19 discs total, FLAC files are 11GB total). Maybe 
that's it. Anyway, in the next few days I'll try playing that album 
again and see what happens.


On 11/7/18 8:50 PM, Bernhard Übelacker wrote:

Dear Maintainer, hello Anthony DeRobertis,

I just tried to reproduce this issue in a buster amd64
qemu VM with a uptodate buster at 2018-09-27.


On Wed, 26 Sep 2018 13:42:01 -0400 Anthony DeRobertis  
wrote:

Package: clementine
Version: 1.3.1+git565-gd20c2244a+dfsg-1
Severity: normal

I'm not sure if this is a Clementine bug or a Gstreamer bug, but I've
noticed that when I leave Clementine running for a bit, its memory usage
grows massive (many GiB). I'm playing almost exlusively FLAC files,
which all have (fairly large) embedded artwork, multiple images per
file.

I used heaptrack to attempt to track down where the memory leak is. This
is after only a day or two of use:

MEMORY LEAKS
857.27MB leaked over 2418654 calls from
g_malloc
   in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
826.58MB leaked over 1941 calls from:
 g_slice_alloc
   in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
 0x7fe9ca6e49d0
   in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
 gst_buffer_new_allocate
   in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
 gst_tag_image_data_to_image_sample
   in /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0
 gst_tag_list_add_id3_image
   in /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0
 0x7fe994f1ca1f
   in /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstaudioparsers.so
 0x7fe9ca8116b1
   in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0
 0x7fe9ca811d8e
   in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0
 0x7fe9ca815301
   in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0
 0x7fe9ca75df40
   in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
 0x7fe9ca8ddad2
   in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
 0x7fe9ca8dd134
   in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
 start_thread
   in /lib/x86_64-linux-gnu/libpthread.so.0
 __clone
   in /lib/x86_64-linux-gnu/libc.so.6

I could just get a backtrace with debug symbols that
looks very similar to Anthonys call stack from heaptrack:

(gdb) bt
#0  0x75de3640 in g_malloc (n_bytes=n_bytes@entry=4079355) at 
../../../../glib/gmem.c:95
#1  0x75dfb5b3 in g_slice_alloc (mem_size=mem_size@entry=4079355) at 
../../../../glib/gslice.c:1024
#2  0x75c0d9d1 in _sysmem_new_block (flags=(unknown: 0), 
maxsize=4079211, align=7, offset=0, size=4079204) at gstallocator.c:417
#3  0x75c190c2 in gst_buffer_new_allocate 
(allocator=allocator@entry=0x0, size=size@entry=4079204, 
params=params@entry=0x0) at gstbuffer.c:839
#4  0x76c61412 in gst_tag_image_data_to_image_sample (image_data=0x7fff600380d1 
"\377\330\377", , image_data_len=4079203, 
image_type=GST_TAG_IMAGE_TYPE_BACK_COVER) at tags.c:528
#5  0x76c513b3 in gst_tag_list_add_id3_image (tag_list=0x7fff60003140, 
image_data=, image_data_len=image_data_len@entry=4079203, 
id3_picture_type=) at gstid3tag.c:379
#6  0x7fffa0065b00 in gst_flac_parse_handle_picture (buffer=0x7fff5c02f6d0, 
flacparse=0x7fff5c049af0 [GstFlacParse]) at 
/usr/include/gstreamer-1.0/gst/base/gstbytereader.h:651
#7  0x7fffa0065b00 in gst_flac_parse_handle_block_type 
(sbuffer=0x7fff5c02f6d0, type=6, flacparse=0x7fff5c049af0 [GstFlacParse]) at 
gstflacparse.c:1520
#8  0x7fffa0065b00 in gst_flac_parse_parse_frame (frame=0x7fff600030f0, 
frame=0x7fff600030f0, size=4079268, parse=0x7fff5c049af0 [GstFlacParse]) at 
gstflacparse.c:1574
#9  0x7fffa0065b00 in gst_flac_parse_handle_frame (parse=0x7fff5c049af0 
[GstFlacParse], frame=0x7fff600030f0, skipsize=) at 
gstflacparse.c:870
#10 0x75d3a6b2 in gst_base_parse_handle_buffer 
(parse=parse@entry=0x7fff5c049af0 [GstFlacParse], buffer=, 
skip=skip@entry=0x7fff737e075c, flushed=flushed@entry=0x7fff737e0758) at 
gstbaseparse.c:2160
#11 0x75d3ad8f in gst_base_parse_scan_frame (parse=parse@entry=0x7fff5c049af0 
[GstFlacParse], klass=) at gstbaseparse.c:3464
#12 0x75d3e302 in gst_base_parse_loop (pad=) at 
gstbaseparse.c:3543
#13 0x75c86f41 in gst_task_func (task=0x7fff78042830 [GstTask]) at 
gsttask.c:332
#14 0x75e06ad3 in g_

Bug#913746: Non-numeric library filters no longer work

[Anthony DeRobertis]

Package: clementine
Version: 1.3.1+git609-g623a53681+dfsg-1
Severity: important

Previously, you could put something like "album:Foo" in the filter box
on the library tab to search for albums with Foo in the name. Similarly
artist:, etc.

Those have all broken. This also breaks the "show in library" feature
(right-click a track, pick show in library) since that does a filter
with artist & album.

Numeric filters (e.g., playcount), though, still work. Same with
datetime ones like lastplayed.

PS: current version hasn't been pushed to salsa.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 
'unstable-debug'), (200, 'unstable'), (150, 'stable'), (100, 
'experimental-debug'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages clementine depends on:
ii  gstreamer1.0-plugins-base   1.14.4-1
ii  gstreamer1.0-plugins-good   1.14.4-1
ii  gstreamer1.0-plugins-ugly   1.14.4-1
ii  libc6   2.27-8
ii  libcdio18   1:2.0.0-dmo2
ii  libchromaprint1 1.4.3-2+b1
ii  libcrypto++65.6.4-8
ii  libfftw3-double33.3.8-2
ii  libgcc1 1:8.2.0-9
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-6
ii  libglib2.0-02.58.1-2
ii  libgpod40.8.3-13
ii  libgstreamer-plugins-base1.0-0  1.14.4-1
ii  libgstreamer1.0-0   1.14.4-1
ii  libimobiledevice6   1.2.1~git20181007.b34e343-1
ii  liblastfm5-11.0.9-1
ii  libmtp9 1.1.13-1
ii  libmygpo-qt5-1  1.1.0-3
ii  libplist3   2.0.0-5
ii  libprojectm2v5  2.1.0+dfsg-4+b3
ii  libprotobuf17   3.6.1-4
ii  libpulse0   12.2-2
ii  libqt5concurrent5   5.11.2+dfsg-4
ii  libqt5core5a5.11.2+dfsg-4
ii  libqt5dbus5 5.11.2+dfsg-4
ii  libqt5gui5  5.11.2+dfsg-4
ii  libqt5network5  5.11.2+dfsg-4
ii  libqt5opengl5   5.11.2+dfsg-4
ii  libqt5sql5  5.11.2+dfsg-4
ii  libqt5widgets5  5.11.2+dfsg-4
ii  libqt5x11extras55.11.2-2
ii  libqt5xml5  5.11.2+dfsg-4
ii  libsqlite3-03.25.3-1
ii  libstdc++6  8.2.0-9
ii  libtag1v5   1.11.1+dfsg.1-0.2+b1
ii  libx11-62:1.6.7-1
ii  projectm-data   2.1.0+dfsg-4
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages clementine recommends:
ii  gstreamer1.0-pulseaudio  1.14.4-1

Versions of packages clementine suggests:
ii  gstreamer1.0-plugins-bad  1.14.4-1+b1

-- no debconf information

Bug#913328: both system and user service?

[Anthony DeRobertis]

Package: mpd
Version: 0.20.23-1+b1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I got a log message this morning:

Nov 09 04:12:07 Watt mpd[4010]: exception: failed to open log file 
"/var/log/mpd/mpd.log" (config line 38): Permission denied

and tracked it down to mpd is installed as both a system service (which
I've configured, and been using for a while) and a systemd user service,
which I'm not sure what it's for, but it (obviously) fails to write to
system-wide logs.

Seems like only one of the two ways should run on a given machine. Or at
least the user service ought to use a different config file.

- -- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (130, 
'unstable-debug'), (130, 'unstable'), (120, 'experimental-debug'), (120, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages mpd depends on:
ii  adduser   3.118
ii  init-system-helpers   1.55
ii  libadplug-2.2.1-0v5   2.2.1+dfsg3-0.4
ii  libao41.2.2+20180113-1
ii  libasound21.1.7-1
ii  libaudiofile1 0.3.6-4
ii  libavahi-client3  0.7-4+b1
ii  libavahi-common3  0.7-4+b1
ii  libavcodec58  10:4.0.2-dmo4
ii  libavformat58 10:4.0.2-dmo4
ii  libavutil56   10:4.0.2-dmo4
ii  libbz2-1.01.0.6-9
ii  libc6 2.27-8
ii  libcdio-cdda2 10.2+0.94+2-dmo4
ii  libcdio-paranoia2 10.2+0.94+2-dmo4
ii  libcdio18 1:2.0.0-dmo2
ii  libcurl3-gnutls   7.61.0-1
ii  libdbus-1-3   1.12.10-1
ii  libexpat1 2.2.6-1
ii  libfaad2  2.8.8-1
ii  libflac8  1.3.2-3
ii  libfluidsynth11.1.11-1
ii  libgcc1   1:8.2.0-9
ii  libgme0   0.6.2-1
ii  libicu60  60.2-6
ii  libid3tag00.15.1b-13
ii  libiso9660-11 1:2.0.0-dmo2
ii  libixml10 1:1.8.4-2
ii  libjack0 [libjack-0.125]  1:0.125.0-3
ii  libmad0   0.15.1b-9
ii  libmikmod33.3.11.1-4
ii  libmms0   0.6.4-3
ii  libmodplug1   1:0.8.9.0-2
ii  libmp3lame0   1:3.100-dmo1
ii  libmpcdec62:0.1~r495-1+b2
ii  libmpdclient2 2.11-1
ii  libmpg123-0   1.25.10-2
ii  libnfs11  1:2.0.0-dmo1
ii  libogg0   1.3.2-1+b1
ii  libopenal11:1.19.1-1
ii  libopus0  1.3~beta+20180518-1
ii  libpulse0 12.2-2
ii  libroar2  1.0~beta11-11
ii  libsamplerate00.1.9-2
ii  libshout3 2.4.1-2
ii  libsidplayfp4 1.8.8-1
ii  libsmbclient  2:4.9.1+dfsg-2
ii  libsndfile1   1.0.28-4
ii  libsoxr0  0.1.2-3
ii  libsqlite3-0  3.25.2-1
ii  libstdc++68.2.0-9
ii  libsystemd0   239-11
ii  libupnp13 1:1.8.4-2
ii  libvorbis0a   1.3.6-1
ii  libvorbisenc2 1.3.6-1
ii  libwavpack1   5.1.0-4
ii  libwildmidi2  0.4.2-1
ii  libwrap0  7.6.q-27
ii  libyajl2  2.1.0-3
ii  libzzip-0-13  0.13.62-3.1
ii  lsb-base  9.20170808
ii  zlib1g1:1.2.11.dfsg-1

mpd recommends no packages.

Versions of packages mpd suggests:
ii  avahi-daemon  0.7-4+b1
pn  icecast2  
ii  mpc [mpd-client]  1:0.31-dmo1
ii  pulseaudio12.2-2

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCW+WuvRUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf7eUwCfRL7HOM5AN70Cj/j9qLrbbzxC1vYA
n02pEOY4fT2vKlQ2iehDTWNr76FD
=WNLX
-END PGP SIGNATURE-

Bug#619757: Bug #619757 breaks DVD reading by default now

[Anthony DeRobertis]

Ok, here is a different machine (and thus drive), different kernel 
version, and different disks:


$ uname -a
Linux Zia 4.18.0-2-amd64 #1 SMP Debian 4.18.10-2 (2018-10-07) x86_64 
GNU/Linux


# smartctl -i /dev/dvd
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.18.0-2-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:   TSSTcorp
Product:  CD/DVDW SH-S183L
Revision: SB01

(the other machine has a HL-DT-ST BD-RE  WH14NS40 1.00).

I put in one disk:

/sbin/blockdev --getsize64 /dev/dvd
1073741312

I changed disks:

/sbin/blockdev --getsize64 /dev/dvd
1073741312

I ran "pktsetup -d 252:0"

/sbin/blockdev --getsize64 /dev/dvd
3992977408

I then ran "pktsetup /dev/dvd", and swapped discs again:

/sbin/blockdev --getsize64 /dev/dvd
3992977408

and after another "pktsetup -d 252:0":

/sbin/blockdev --getsize64 /dev/dvd
789905408

BTW: After a bunch of Googling, it appears someone noticed this bug 10 
years ago and apparently no one really figured out how to fix it. 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg246211.html 
and kernel commit 7b3d9545f9ac8b31528dd2d6d8ec8d19922917b8 are 
references I found.

Bug#619757: Bug #619757 breaks DVD reading by default now

[Anthony DeRobertis]

On 10/26/18 5:58 PM, Pali Rohár wrote:


Hi! This sounds like a kernel bug.

Can you provide dmesg output and kernel version?


Sorry for the late response — just want to let you know I saw your email.

That was running 4.16.0-1-amd64(from Debian 4.16.5-1) — I'll try to test 
with a newer version soon and also some different drives (on different 
machines).

Bug#911900: AppArmor blocks XCompose, buddy icon

[Anthony DeRobertis]

Package: pidgin
Version: 2.13.0-2
Followup-For: Bug #911900

In addition, app icons:

Oct 29 16:36:37 Zia kernel: [444528.926213] audit: type=1400 
audit(1540845397.534:1567): apparmor="DENIED" operation="open" 
profile="/usr/bin/pidgin" name="/home/anthony/.icons/gnome/48x48/apps/" 
pid=12089 comm="pidgin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Oct 29 16:36:37 Zia kernel: [444528.928268] audit: type=1400 
audit(1540845397.534:1568): apparmor="DENIED" operation="open" 
profile="/usr/bin/pidgin" name="/home/anthony/.icons/gnome/48x48/apps/" 
pid=12089 comm="pidgin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Oct 29 16:36:37 Zia kernel: [444528.942792] audit: type=1400 
audit(1540845397.550:1569): apparmor="DENIED" operation="open" 
profile="/usr/bin/pidgin" name="/home/anthony/.icons/gnome/48x48/apps/" 
pid=12089 comm="pidgin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 
'unstable-debug'), (200, 'unstable'), (150, 'stable'), (100, 
'experimental-debug'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages pidgin depends on:
ii  libatk1.0-0 2.30.0-1
ii  libc6   2.27-6
ii  libcairo2   1.16.0-1
ii  libdbus-1-3 1.12.10-1
ii  libdbus-glib-1-20.110-3
ii  libfontconfig1  2.13.1-1
ii  libfreetype62.8.1-2
ii  libgadu31:1.12.2-3
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-6
ii  libglib2.0-02.58.1-2
ii  libgstreamer1.0-0   1.14.4-1
ii  libgtk2.0-0 2.24.32-3
ii  libgtkspell02.0.16-1.2
ii  libice6 2:1.0.9-2
ii  libpango-1.0-0  1.42.4-3
ii  libpangocairo-1.0-0 1.42.4-3
ii  libpangoft2-1.0-0   1.42.4-3
ii  libpurple0  2.13.0-2
ii  libsm6  2:1.2.2-1+b3
ii  libx11-62:1.6.7-1
ii  libxss1 1:1.2.3-1
ii  perl-base [perlapi-5.26.2]  5.26.2-7+b1
ii  pidgin-data 2.13.0-2

Versions of packages pidgin recommends:
ii  gstreamer1.0-libav 1.15.0.1+git20180723+db823502-2
ii  gstreamer1.0-plugins-base  1.14.4-1
ii  gstreamer1.0-plugins-good  1.14.4-1
ii  gstreamer1.0-pulseaudio1.14.4-1

Versions of packages pidgin suggests:
ii  libsqlite3-0  3.25.2-1

-- no debconf information

Bug#911961: Missing example configuration file

[Anthony DeRobertis]

Package: sddm
Version: 0.18.0-1
Severity: minor

README.Debian suggests I can view an example configuration file at
/usr/share/doc/sddm/sddm.conf, but that file does not exist.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 
'unstable-debug'), (200, 'unstable'), (150, 'stable'), (100, 
'experimental-debug'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages sddm depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.69
ii  libc6 2.27-6
ii  libgcc1   1:8.2.0-8
ii  libpam0g  1.1.8-3.8
ii  libqt5core5a  5.11.2+dfsg-3
ii  libqt5dbus5   5.11.2+dfsg-3
ii  libqt5gui55.11.2+dfsg-3
ii  libqt5network55.11.2+dfsg-3
ii  libqt5qml55.11.2-2
ii  libqt5quick5  5.11.2-2
ii  libstdc++68.2.0-8
ii  libsystemd0   239-10
ii  libxcb-xkb1   1.13.1-1
ii  libxcb1   1.13.1-1
ii  qml-module-qtquick2   5.11.2-2
ii  tigervnc-standalone-server [xserver]  1.9.0+dfsg-1
ii  tightvncserver [xserver]  1:1.3.9-9
ii  x11-common1:7.7+19
ii  xserver-xephyr [xserver]  2:1.20.1-5
ii  xserver-xorg [xserver]1:7.7+19
ii  xvfb [xserver]2:1.20.1-5

Versions of packages sddm recommends:
pn  haveged 
ii  libpam-systemd  239-10
ii  sddm-theme-breeze [sddm-theme]  4:5.13.5-1+b1

Versions of packages sddm suggests:
ii  libpam-kwallet5   5.13.4-1
pn  qtvirtualkeyboard-plugin  

-- debconf information excluded

Bug#911897: AppArmor "complain" for oosplash & soffice

[Anthony DeRobertis]

On 10/26/18 11:26 AM, Rene Engelhard wrote:

Then there is a lot of nVidia stuff, probably from this machine using the 
nVidia proprietary
driver.

Then the nvidia drivers (which I do not care about at all, to be honest)
or libdrm or whatever should ship needed stuff. I mean, it's not LO using
the stuff directly, it's those. It would imho be completely nonsense to
make LO honour driver-specific things for every possible driver.


apparmor ships an /etc/apparmor.d/abstractions/nvidia — but AFAICT each 
app needs to #include it, which I agree is rather silly. E.g., 
Thunderbird and Totem both include it.



Not that it matters here, but no -kde(5) even when you're using KDE?
Never tried it, actually. I have a such a mix of apps running anyway 
that there is no hope of consistency, and I don't run KDE everywhere... 
so I'd rather just have LibreOffice look like LibreOffice.



PS: Just saw your other reply about $XAUTHORITY, and yeah, that's how 
it's set here. Definitely KDE launched from sddm:


 1473 ?Ssl0:00 /usr/bin/sddm
 1707 tty7 Ssl+  90:32  \_ /usr/lib/xorg/Xorg -nolisten tcp -auth 
/var/run/sddm/{592354bf-2439-40b4-9616-3bd3943e9502} -background none -noreset 
-displayfd 17 -seat seat0 vt7
11894 ?S  0:00  \_ /usr/lib/x86_64-linux-gnu/sddm/sddm-helper 
--socket /tmp/sddm-authe60db6a4-a442-404f-9833-9762d7da6686 --id 1 --start 
/usr/bin/startkde --user anthony
11897 ?S  0:00  \_ /bin/sh /usr/bin/startkde
11960 ?Ss 0:00  \_ /usr/bin/ssh-agent env 
LD_PRELOAD=libgtk3-nocsd.so.0 /usr/bin/startkde
12010 ?S  0:00  \_ kwrapper5 /usr/bin/ksmserver

... going to try to figure out why my machine is different than yours.

Bug#619757: Bug #619757 breaks DVD reading by default now

[Anthony DeRobertis]

severity 619757 important
thanks

I just finally managed to figure out why DVDs were not working on my 
machine after a few hours of banging my head against a wall and 
ultimately grabbing another drive... Turns out it was because of this 
bug. Except I never explicitly enabled this; it now happens by default 
via /lib/udev/rules.d/80-pktsetup.rules.


# blockdev --getsize64 /dev/sr0
3847454720
# pktsetup -d 252:0
# blockdev --getsize64 /dev/sr0
7235895296

... yeah, works a lot better after that!

I disabled by:

# cd /etc/udev/rules.d && ln -s /dev/null 80-pktsetup.rules

but it'd probably be better to have this off by default.

Bug#911900: AppArmor blocks XCompose, buddy icon

[Anthony DeRobertis]

Package: pidgin
Version: 2.13.0-2
Severity: normal

AppArmor denials from Pidgin which probably shouldn't be denied. The odd
path in the first one is because some of my dotfiles are stored in
version control:

   anthony@Zia:~$ readlink -f .XCompose 
   /home/anthony/src/svn.derobert.net_DotFiles/XCompose

the .compose-cache is part of XCompose; see
https://www.x.org/releases/X11R7.5/doc/man/man5/Compose.5.html and is
the default path.

Third one is where my buddy icon is stored.

Oct 25 17:56:19 Zia kernel: [103720.936003] audit: type=1400 
audit(1540504579.877:458): apparmor="DENIED" operation="open" 
profile="/usr/bin/pidgin" 
name="/home/anthony/src/svn.derobert.net_DotFiles/XCompose" pid=12089 
comm="pidgin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Oct 25 17:56:19 Zia kernel: [103720.961707] audit: type=1400 
audit(1540504579.905:459): apparmor="DENIED" operation="mknod" 
profile="/usr/bin/pidgin" 
name="/home/anthony/.compose-cache/l4_030_313cb605_00280cc0" pid=12089 
comm="pidgin" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
Oct 25 17:56:20 Zia kernel: [103721.117295] audit: type=1400 
audit(1540504580.061:460): apparmor="DENIED" operation="open" 
profile="/usr/bin/pidgin" 
name="/home/anthony/buddyico/fract-done-try3-redo.gif" pid=12089 comm="pidgin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
(last line repeats a bunch of times)

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 
'unstable-debug'), (200, 'unstable'), (150, 'stable'), (100, 
'experimental-debug'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages pidgin depends on:
ii  libatk1.0-0 2.30.0-1
ii  libc6   2.27-6
ii  libcairo2   1.16.0-1
ii  libdbus-1-3 1.12.10-1
ii  libdbus-glib-1-20.110-3
ii  libfontconfig1  2.13.1-1
ii  libfreetype62.8.1-2
ii  libgadu31:1.12.2-3
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-6
ii  libglib2.0-02.58.1-2
ii  libgstreamer1.0-0   1.14.4-1
ii  libgtk2.0-0 2.24.32-3
ii  libgtkspell02.0.16-1.2
ii  libice6 2:1.0.9-2
ii  libpango-1.0-0  1.42.4-3
ii  libpangocairo-1.0-0 1.42.4-3
ii  libpangoft2-1.0-0   1.42.4-3
ii  libpurple0  2.13.0-2
ii  libsm6  2:1.2.2-1+b3
ii  libx11-62:1.6.7-1
ii  libxss1 1:1.2.3-1
ii  perl-base [perlapi-5.26.2]  5.26.2-7+b1
ii  pidgin-data 2.13.0-2

Versions of packages pidgin recommends:
ii  gstreamer1.0-libav 1.15.0.1+git20180723+db823502-2
ii  gstreamer1.0-plugins-base  1.14.4-1
ii  gstreamer1.0-plugins-good  1.14.4-1
ii  gstreamer1.0-pulseaudio1.14.4-1

Versions of packages pidgin suggests:
ii  libsqlite3-0  3.25.2-1

-- no debconf information

Bug#911897: AppArmor "complain" for oosplash & soffice

[Anthony DeRobertis]

Package: libreoffice-core
Version: 1:6.1.3~rc1-1
Severity: normal
File: /usr/lib/libreoffice/program/oosplash

I understand the goal is to get AppArmor back in to enforcing mode
someday, so presumably these complain-mode allow messages are of use.
Presumably the xauth one will effect a lot of people (as that's the
value of $XAUTHORITY here, set by KDE/sddm). Then there is a lot of
nVidia stuff, probably from this machine using the nVidia proprietary
driver.

(Side note, I understand sandboxing web browsers and the like with
AppArmor. Firefox shouldn't have random access to $HOME. But I wonder if
its really worth it for LibreOffice; by its nature it must have access
to my important documents. But that's a discussion for elsewhere, I'm
sure.)

Oct 25 16:52:11 Zia kernel: audit: type=1400 audit(1540500731.877:200): 
apparmor="ALLOWED" operation="open" profile="libreoffice-oopslash" 
name="/tmp/xauth-1000-_0" pid=25385 comm="oosplash" requested_mask="r" 
denied_mask="r" fsuid=1000 ouid=1000
Oct 25 16:52:12 Zia kernel: audit: type=1400 audit(1540500732.729:201): 
apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" 
name="/usr/share/nvidia/nvidia-application-profiles-390.87-rc" pid=25398 
comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Oct 25 16:52:12 Zia kernel: audit: type=1400 audit(1540500732.849:202): 
apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" 
name="/usr/share/nvidia/nvidia-application-profiles-390.87-rc" pid=25398 
comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Oct 25 16:52:12 Zia kernel: audit: type=1400 audit(1540500732.861:203): 
apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" 
name="/proc/modules" pid=25398 comm="soffice.bin" requested_mask="r" 
denied_mask="r" fsuid=1000 ouid=0
Oct 25 16:52:12 Zia kernel: audit: type=1400 audit(1540500732.861:204): 
apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" 
name="/proc/driver/nvidia/params" pid=25398 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Oct 25 16:52:12 Zia kernel: audit: type=1400 audit(1540500732.861:205): 
apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" 
name="/dev/nvidiactl" pid=25398 comm="soffice.bin" requested_mask="wr" 
denied_mask="wr" fsuid=1000 ouid=0
Oct 25 16:52:12 Zia kernel: audit: type=1400 audit(1540500732.861:206): 
apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" 
name="/sys/devices/system/memory/block_size_bytes" pid=25398 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Oct 25 16:52:12 Zia kernel: audit: type=1400 audit(1540500732.861:207): 
apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" 
name="/proc/modules" pid=25398 comm="soffice.bin" requested_mask="r" 
denied_mask="r" fsuid=1000 ouid=0
Oct 25 16:52:12 Zia kernel: audit: type=1400 audit(1540500732.861:208): 
apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" 
name="/proc/driver/nvidia/params" pid=25398 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Oct 25 16:52:12 Zia kernel: audit: type=1400 audit(1540500732.861:209): 
apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" 
name="/dev/nvidia-modeset" pid=25398 comm="soffice.bin" requested_mask="wr" 
denied_mask="wr" fsuid=1000 ouid=0
Oct 25 16:52:44 Zia kernel: audit: type=1400 audit(1540500764.333:287): 
apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" 
name="/usr/share/nvidia/nvidia-application-profiles-390.87-rc" pid=25519 
comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Oct 25 16:52:44 Zia kernel: audit: type=1400 audit(1540500764.453:288): 
apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" 
name="/usr/share/nvidia/nvidia-application-profiles-390.87-rc" pid=25519 
comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Oct 25 16:52:44 Zia kernel: audit: type=1400 audit(1540500764.465:289): 
apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" 
name="/proc/modules" pid=25519 comm="soffice.bin" requested_mask="r" 
denied_mask="r" fsuid=1000 ouid=0
Oct 25 16:52:44 Zia kernel: audit: type=1400 audit(1540500764.465:290): 
apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" 
name="/proc/driver/nvidia/params" pid=25519 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Oct 25 16:52:44 Zia kernel: audit: type=1400 audit(1540500764.465:291): 
apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" 
name="/dev/nvidiactl" pid=25519 comm="soffice.bin" requested_mask="wr" 
denied_mask="wr" fsuid=1000 ouid=0
Oct 25 16:52:44 Zia kernel: audit: type=1400 audit(1540500764.469:292): 
apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" 
name="/sys/devices/system/memory/block_size_bytes" pid=25519 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Oct 25 16:52:44 Zia kernel: audit: type=1400 

Bug#909523: [pkg-apparmor] Bug#909523: cachefilesd broken by apparmor

[Anthony DeRobertis]

On Sun, Oct 21, 2018 at 10:24:46AM +0200, intrigeri wrote:
> 
> Can you please retry with AppArmor enabled, after commenting out the
> "secctx" directive in /etc/cachefilesd.conf? If this works, then my
> hypothesis will be confirmed and my recommendation will be:

Seems your hypothesis is correct.

I rebooted and removed apparmor=0 from the kernel command line, thus
re-enabling AppArmor. Cachefilesd failed again (as expected).

I then went ahead and edited cachefilesd.conf and commented out the
secctx line. After that, cachefilesd started successfully.

Bug#911709: tomcat7: Security update broke apps with AccessControlException for org.apache.tomcat.util.http

[Anthony DeRobertis]

Package: tomcat7
Version: 7.0.56-3+really7.0.91-1
Severity: important

After applying the recent security update, the web app we're running
(which is unfortunately a proprietary product provided by a vendor) no
longer works. Instead, I get an exception and a blank page.
Interestingly, in /etc/tomcat7/policy.d/40_«redacted».policy, there is a
grant:

grant codeBase "file:/srv/hm/HPM54/WebApp-«Redacted»/-" {
   ⋮
   permission java.lang.RuntimePermission 
"accessClassInPackage.org.apache.tomcat";
}

... adding another grant for accessClassInPackage.org.apache.tomcat.util.http
seems to get it working again, but that's not something you'd expect without
warning from a security update.

Oct 23, 2018 2:58:47 PM org.apache.catalina.core.ApplicationContext log
INFO: Initializing HardMetrics action servlet.
Oct 23, 2018 2:58:54 PM org.apache.catalina.core.ApplicationDispatcher invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.security.AccessControlException: access denied 
("java.lang.RuntimePermission" 
"accessClassInPackage.org.apache.tomcat.util.http")
at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at 
java.security.AccessController.checkPermission(AccessController.java:684)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at 
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1525)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:320)
at java.lang.ClassLoader.loadClass(ClassLoader.java:417)
at java.lang.ClassLoader.loadClass(ClassLoader.java:363)
at 
org.apache.coyote.http11.AbstractHttp11Processor.prepareResponse(AbstractHttp11Processor.java:1677)
at 
org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:825)
at org.apache.coyote.Response.action(Response.java:171)
at 
org.apache.coyote.http11.AbstractOutputBuffer.doWrite(AbstractOutputBuffer.java:185)
at org.apache.coyote.Response.doWrite(Response.java:495)
at 
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:405)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:442)
at 
org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.java:488)
at org.apache.tomcat.util.buf.CharChunk.append(CharChunk.java:273)
at 
org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:540)
at 
org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:152)
at 
org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:119)
at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:336)
at java.io.Writer.write(Writer.java:157)
at org.apache.jsp.base.logon.logon_jsp._jspService(logon_jsp.java:877)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:453)
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288)
at 
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:548)
at 
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320)
at 
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297)
at 
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at 
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
at 
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 

Bug#909682: Memory leak with gst_tag_list_add_id3_image

[Anthony DeRobertis]

Package: clementine
Version: 1.3.1+git565-gd20c2244a+dfsg-1
Severity: normal

I'm not sure if this is a Clementine bug or a Gstreamer bug, but I've
noticed that when I leave Clementine running for a bit, its memory usage
grows massive (many GiB). I'm playing almost exlusively FLAC files,
which all have (fairly large) embedded artwork, multiple images per
file.

I used heaptrack to attempt to track down where the memory leak is. This
is after only a day or two of use:

MEMORY LEAKS
857.27MB leaked over 2418654 calls from
g_malloc
  in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
826.58MB leaked over 1941 calls from:
g_slice_alloc
  in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0x7fe9ca6e49d0
  in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
gst_buffer_new_allocate
  in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
gst_tag_image_data_to_image_sample
  in /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0
gst_tag_list_add_id3_image
  in /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0
0x7fe994f1ca1f
  in /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstaudioparsers.so
0x7fe9ca8116b1
  in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0
0x7fe9ca811d8e
  in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0
0x7fe9ca815301
  in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0
0x7fe9ca75df40
  in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
0x7fe9ca8ddad2
  in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0x7fe9ca8dd134
  in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
start_thread
  in /lib/x86_64-linux-gnu/libpthread.so.0
__clone
  in /lib/x86_64-linux-gnu/libc.so.6

I have no idea why that backtrace doesn't show any Clementine code in
it. I tried installing some more -dbg/-dbgsym packages, but maybe I had
to do it before starting Clementine.

Note this is the main clementine process, not the tagreader processes:

$ ps u | sed -e '1p;/[c]lementine/!d'
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
anthony  15944  0.5  6.6 4407604 1650488 pts/4 Sl+  Sep24  16:30 clementine
anthony  15956  0.0  0.1 276992 37368 pts/4Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-631367825
anthony  15958  0.0  0.1 276992 39392 pts/4Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-792921086
anthony  15959  0.0  0.1 276992 37676 pts/4Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-1767394138
anthony  15963  0.0  0.1 276988 37340 pts/4Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-1468073315
anthony  15967  0.0  0.1 276988 37492 pts/4Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-1581559023
anthony  15968  0.0  0.1 276992 37624 pts/4Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-1038521661
anthony  15969  0.0  0.1 276992 39180 pts/4Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-1682697807
anthony  15970  0.0  0.1 276992 37908 pts/4Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-391160903


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages clementine depends on:
ii  gstreamer1.0-plugins-base   1.14.3-2
ii  gstreamer1.0-plugins-good   1.14.3-1
ii  gstreamer1.0-plugins-ugly   1.14.3-1
ii  libc6   2.27-6
ii  libcdio18   1:2.0.0-dmo2
ii  libchromaprint1 1.4.3-2+b1
ii  libcrypto++65.6.4-8
ii  libfftw3-double33.3.8-2
ii  libgcc1 1:8.2.0-7
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-6
ii  libglib2.0-02.58.1-2
ii  libgpod40.8.3-13
ii  libgstreamer-plugins-base1.0-0  1.14.3-2
ii  libgstreamer1.0-0   1.14.3-1
ii  libimobiledevice6   1.2.1~git20180302.3a37a4e-1
ii  liblastfm5-11.0.9-1
ii  libmtp9 1.1.13-1
ii  libmygpo-qt5-1  1.1.0-2
ii  libplist3   2.0.0-5
ii  libprojectm2v5  2.1.0+dfsg-4+b3
ii  libprotobuf10   3.0.0-9.1
ii  libpulse0   12.2-2
ii  libqt5concurrent5   5.11.1+dfsg-8
ii  libqt5core5a5.11.1+dfsg-8
ii  libqt5dbus5 5.11.1+dfsg-8
ii  libqt5gui5  5.11.1+dfsg-8
ii  libqt5network5  5.11.1+dfsg-8
ii  libqt5opengl5   

Bug#909523: cachefilesd broken by apparmor

[Anthony DeRobertis]

Package: cachefilesd
Version: 0.10.10-0.1
Severity: important

Important since Apparmor is on by default now.

I rebooted after enabling Apparmor, and cachefilesd wouldn't start:

Sep 24 13:53:17 Zia cachefilesd[1105]: About to bind cache
Sep 24 13:53:17 Zia kernel: CacheFiles: Security denies permission to nominate 
security context: error -2
Sep 24 13:53:17 Zia cachefilesd[1105]: CacheFiles bind failed: errno 2 (No such 
file or directory)
Sep 24 13:53:17 Zia cachefilesd[1052]: Starting FilesCache daemon : cachefilesd 
failed!
Sep 24 13:53:17 Zia systemd[1]: cachefilesd.service: Control process exited, 
code=exited status=1
Sep 24 13:53:17 Zia systemd[1]: cachefilesd.service: Failed with result 
'exit-code'.
Sep 24 13:53:17 Zia systemd[1]: Failed to start LSB: CacheFiles daemon.


Trying a few more times (after the system booted) also produced the same error 
each time:

Sep 24 13:57:12 Zia systemd[1]: Starting LSB: CacheFiles daemon...
Sep 24 13:57:13 Zia cachefilesd[6213]: About to bind cache
Sep 24 13:57:13 Zia cachefilesd[6213]: CacheFiles bind failed: errno 2 (No such 
file or directory)
Sep 24 13:57:13 Zia kernel: CacheFiles: Security denies permission to nominate 
security context: error -2
Sep 24 13:57:13 Zia cachefilesd[6208]: Starting FilesCache daemon : cachefilesd 
failed!
Sep 24 13:57:13 Zia systemd[1]: cachefilesd.service: Control process exited, 
code=exited status=1
Sep 24 13:57:13 Zia systemd[1]: cachefilesd.service: Failed with result 
'exit-code'.
Sep 24 13:57:13 Zia systemd[1]: Failed to start LSB: CacheFiles daemon.

Rebooting with apparmor=0 on the kernel command line makes it work
again.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cachefilesd depends on:
ii  libc6  2.27-6

cachefilesd recommends no packages.

cachefilesd suggests no packages.

-- Configuration Files:
/etc/cachefilesd.conf changed [not included]
/etc/default/cachefilesd changed [not included]
/etc/init.d/cachefilesd changed [not included]
/etc/logcheck/ignore.d.workstation/cachefilesd [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.workstation/cachefilesd'

-- no debconf information

Bug#909281: Apparmor: allow access to ~/.mailcap

[Anthony DeRobertis]

Package: thunderbird
Version: 1:60.0-3
Followup-For: Bug #909281

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm not sure if anything needs to be done to let Thunderbird actually
fork/exec a program from ~/.mailcap, but just to read it is, I think:

diff --git a/apparmor.d/usr.bin.thunderbird b/apparmor.d/usr.bin.thunderbird
index 1ffb231..d418aa9 100644
- --- a/apparmor.d/usr.bin.thunderbird
+++ b/apparmor.d/usr.bin.thunderbird
@@ -108,6 +108,7 @@ profile thunderbird @{thunderbird_executable} {
   owner @{HOME}/.local/share/applications/defaults.list r,
   owner @{HOME}/.local/share/applications/mimeapps.list r,
   owner @{HOME}/.local/share/applications/mimeinfo.cache r,
+  owner @{HOME}/.mailcap r,
   owner @{HOME}/.recently-used r,
   /tmp/.X[0-9]*-lock r,
   /etc/udev/udev.conf r,


- -- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (130, 
'unstable-debug'), (130, 'unstable'), (120, 'experimental-debug'), (120, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6
ii  fontconfig2.13.0-5
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-6
ii  libcairo-gobject2 1.15.12-1
ii  libcairo2 1.15.12-1
ii  libdbus-1-3   1.12.10-1
ii  libdbus-glib-1-2  0.110-3
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.13.0-5
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.2.0-6
ii  libgdk-pixbuf2.0-02.36.12-2
ii  libglib2.0-0  2.56.1-2
ii  libgtk-3-03.22.30-2
ii  libgtk2.0-0   2.24.32-3
ii  libhunspell-1.6-0 1.6.2-1+b1
ii  libicu60  60.2-6
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.39-1
ii  libpango-1.0-01.42.4-1
ii  libpangocairo-1.0-0   1.42.4-1
ii  libpangoft2-1.0-0 1.42.4-1
ii  libsqlite3-0  3.24.0-1
ii  libstartup-notification0  0.12-5
ii  libstdc++68.2.0-6
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.6-1
ii  libx11-xcb1   2:1.6.6-1
ii  libxcb-shm0   1.13-3
ii  libxcb1   1.13-3
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc23.1-1+b1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

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

Versions of packages thunderbird suggests:
ii  apparmor  2.13-8
ii  fonts-lyx 2.3.0-3
ii  libgssapi-krb5-2  1.16-2

- -- Configuration Files:
/etc/apparmor.d/usr.bin.thunderbird changed [not included]

- -- debconf information excluded

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCW6kLhhUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf4pAQCeJprWMtGqAHJe18jEJ96BfmnHPFUA
njpSrXpT+/mnIYSMyjEYoBdi1aNH
=5kmK
-END PGP SIGNATURE-

Bug#904558: What should happen when maintscripts fail to restart a service

[Anthony DeRobertis]

Someone asked for an example, here is one I've often seen when doing a 
release upgrade on many webservers I administer: Apache will fail to 
start. I don't recall if that currently causes Apache postinst to fail, 
but if not, it really ought to continue.


Apache has a complicated config, and upstream makes 
backwards-incompatible changes often enough that every Debian release 
seems to have some. It's often not possible to automatically update the 
config (and even if it were, the variety of configuration management 
systems in use mean you wouldn't want that to happen automatically). 
It's much easier to fix after the upgrade. And to the extent anything 
depends on Apache, Apache being completely broken doesn't generally 
break them (unless they try to restart apache themselves, e.g., apache 
modules).


Now, if my local DNS cache failed to start, that needs to be fixed 
before continuing (since, e.g., even apt-get won't work). Same with an 
LDAP (etc.) server, you may no longer have user accounts. Some things 
definitely lead to a cascade of failures.


I think in an ideal world, there would be two separate failure states 
for postinst: one for failed but probably safe to continue the upgrade, 
one for failed and probably going to cause a cascade of failures (or 
worse). dpkg (and the various frontends) would let you know about 
fail-but-continue errors after finishing, and maybe before starting, but 
still continue to work.


At least for daemon failed to start and with systemd, we already can 
have pretty close: have the postinst ignore the failed to start error 
(when it's of the safe to continue the upgrade variety), then use 
`systemctl --failed` to get the list of daemons that failed to start.

Bug#909281: Apparmor: allow access to ~/.mailcap

[Anthony DeRobertis]

Package: thunderbird
Version: 1:60.0-3~deb9u1
Severity: normal
File: /etc/apparmor.d/usr.bin.thunderbird

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I got these in my log:

Sep 19 20:02:42 Watt kernel: [9950821.734919] audit: type=1400 
audit(1537401762.512:297): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.mailcap" pid=9593 comm="thunderbird" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Sep 19 20:02:43 Watt kernel: [9950822.548807] audit: type=1400 
audit(1537401763.328:298): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.mailcap" pid=9593 comm="thunderbird" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

would make sense to allow a mail program to read ~/.mailcap (and execute
the programs found there, no idea how that's done in apparmor)

- -- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (130, 
'unstable-debug'), (130, 'unstable'), (120, 'experimental-debug'), (120, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6
ii  fontconfig2.13.0-5
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-6
ii  libcairo-gobject2 1.15.12-1
ii  libcairo2 1.15.12-1
ii  libdbus-1-3   1.12.10-1
ii  libdbus-glib-1-2  0.110-3
ii  libevent-2.0-52.0.21-stable-3
ii  libffi6   3.2.1-8
ii  libfontconfig12.13.0-5
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.2.0-6
ii  libgdk-pixbuf2.0-02.36.12-2
ii  libglib2.0-0  2.56.1-2
ii  libgtk-3-03.22.30-2
ii  libgtk2.0-0   2.24.32-3
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.42.4-1
ii  libpangocairo-1.0-0   1.42.4-1
ii  libpangoft2-1.0-0 1.42.4-1
ii  libstartup-notification0  0.12-5
ii  libstdc++68.2.0-6
ii  libvpx4   1.6.1-3+deb9u1
ii  libx11-6  2:1.6.6-1
ii  libx11-xcb1   2:1.6.6-1
ii  libxcb-shm0   1.13-3
ii  libxcb1   1.13-3
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc23.1-1+b1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1
ii  lightning 1:60.0-3~deb9u1

Versions of packages thunderbird suggests:
ii  apparmor  2.13-8
ii  fonts-lyx 2.3.0-3
ii  libgssapi-krb5-2  1.16-2

- -- debconf information excluded

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCW6QItRUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf48vwCfXLjejfEz2GoDscwP2uaSlcxE8JoA
n0MMCFh2G4kIMxfwW3w8iSOGmGr8
=mDRk
-END PGP SIGNATURE-

Bug#908147: restarting cups-browsed deleted print jobs

[Anthony DeRobertis]

Package: cups-browsed
Version: 1.21.1-1
Severity: grave

I had an two jobs of online receipts set to print to a cups-browsed
remote print queue (a PDF printer on a remote machine), and a bit after
printing noticed that print handn't completed. I checked the local CUPS
status page and saw a message that cups-pdf hadn't provided a host name,
confirm it is running (compare bug #887495).

I checked (via systemctl status), it was running:

root@Zia:~# systemctl status cups-browsed.service 
● cups-browsed.service - Make remote CUPS printers available locally
   Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Thu 2018-09-06 00:00:04 EDT; 13h ago
 Main PID: 31796 (cups-browsed)
Tasks: 3 (limit: 4915)
   Memory: 5.0M
   CGroup: /system.slice/cups-browsed.service
   └─31796 /usr/sbin/cups-browsed

Sep 06 00:00:04 Zia systemd[1]: Started Make remote CUPS printers available 
locally.

... since it wasn't working, I did the obvious thing: systemctl restart 
cups-browsed.service

After doing so, the queue in the browser refreshed and showed empty. But
I checked — the PDFs were not created. Showing completed jobs shows
nothing. Looking in /var/spool/cups (on both the local machine and the
remote machine) shows no sign of the two jobs.

So it appears restarting cups-browsed deletes all pending print jobs.
Unfortunately, they're just gone ... hope I don't need those receipts.

A test page now works, so at least it fixed the queue. Testing
restarting it again, the job history is indeed gone, so that confirms
its deleting the data.

Unexpectedly and without warning discarding user data (pending print
jobs) really isn't OK, especially when CUPS itself is suggesting the
action that led to it.

Also, it looks like it was automatically restarted yesterday & this morning at
midnight; that makes this worse.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cups-browsed depends on:
ii  cups-daemon   2.2.8-5
ii  libavahi-client3  0.7-4
ii  libavahi-common3  0.7-4
ii  libavahi-glib10.7-4
ii  libc6 2.27-5
ii  libcups2  2.2.8-5
ii  libcupsfilters1   1.21.1-1
ii  libglib2.0-0  2.56.1-2
ii  libldap-2.4-2 2.4.46+dfsg-5
ii  lsb-base  9.20170808

Versions of packages cups-browsed recommends:
ii  avahi-daemon  0.7-4

cups-browsed suggests no packages.

-- Configuration Files:
/etc/cups/cups-browsed.conf changed:
BrowseRemoteProtocols dnssd cups
BrowsePoll watt.home


-- no debconf information

Bug#906234: Please change dependency on cryptsetup (probably to -bin)

[Anthony DeRobertis]

Package: libguestfs0
Version: 1:1.38.3-1
Severity: normal

cryptsetup is a now a transitional dummy package, which depends on
various things that used to be in the package. In particular, it depends
on cryptsetup-initramfs which tries to unlock encrypted disks in the
initramfs, and produces a warning if there aren't any:

update-initramfs: Generating /boot/initrd.img-4.17.0-1-amd64
cryptsetup: WARNING: The initramfs image may not contain cryptsetup binaries 
nor crypto modules. If that's on purpose, you may want to uninstall the 
'cryptsetup-initramfs' package in order to disable the cryptsetup initramfs 
integration and avoid this warning.

I'm guessing you actually want cryptsetup-bin, which contains e.g.,
/sbin/cryptsetup.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libguestfs0 depends on:
ii  acl  2.2.52-3+b1
ii  attr 1:2.4.47-2+b2
ii  binutils 2.31.1-2
ii  bsdmainutils 11.1.2+b1
ii  btrfs-progs  4.17-1
ii  bzip21.0.6-8.1
ii  cpio 2.12+dfsg-6
ii  cryptsetup   2:2.0.4-2
ii  curl 7.60.0-2
ii  dash 0.5.8-2.10
ii  db-util  5.3.1
ii  diffutils1:3.6-1
ii  dosfstools   4.1-2
ii  e2fsprogs1.44.3-1
ii  exfat-utils  1.2.8-1
ii  extlinux 3:6.03+dfsg1-2
ii  fdisk2.32.1-0.1
ii  file 1:5.34-2
ii  gawk 1:4.1.4+dfsg-1+b1
ii  gdisk1.0.3-1+b1
ii  genisoimage  9:1.1.11-3+b2
ii  grub2-common 2.02+dfsg1-5
ii  icoutils 0.32.3-1
ii  iproute2 4.17.0-2
ii  isc-dhcp-client  4.3.5-4+b1
ii  kmod 25-1
ii  ldmtool  0.2.4-1
ii  less 487-0.1+b1
ii  libacl1  2.2.52-3+b1
ii  libaugeas0   1.10.1-2
ii  libc62.27-5
ii  libcap2  1:2.25-1.2
ii  libfuse2 2.9.8-2
ii  libhivex01.3.15-1+b2
ii  libpcre3 2:8.39-11
ii  libselinux1  2.8-1+b1
ii  libsystemd0  239-7
ii  libtinfo66.1+20180714-1
ii  libtsk13 4.6.1-1
ii  libvirt0 4.6.0-1
ii  libxml2  2.9.4+dfsg1-7+b1
ii  libyajl2 2.1.0-2+b3
ii  libyara3 3.8.0-5
ii  lsscsi   0.28-0.1
ii  lvm2 2.02.176-4.1
ii  lzop 1.03-4+b1
ii  mdadm4.1~rc1-4
ii  mtools   4.0.18-2.1
ii  netpbm   2:10.0-15.3+b2
ii  ntfs-3g  1:2017.3.23-2
ii  openssh-client   1:7.7p1-3
ii  osinfo-db0.20180628-1
ii  parted   3.2-21+b1
ii  procps   2:3.3.15-2
ii  psmisc   23.1-1+b1
ii  qemu-system-x86  1:2.12+dfsg-3
ii  qemu-utils   1:2.12+dfsg-3
ii  scrub2.6.1-1+b1
ii  sgabios  0.0~svn8-4
ii  sleuthkit4.6.1-1
ii  squashfs-tools   1:4.3-6
ii  supermin 5.1.19-2+b1
ii  syslinux 3:6.03+dfsg1-2
ii  systemd-sysv 239-7
ii  udev 239-7
ii  util-linux   2.32.1-0.1
ii  xz-utils 5.2.2-1.3
ii  zerofree 1.1.1-1

Versions of packages libguestfs0 recommends:
ii  libguestfs-hfsplus   1:1.38.3-1
ii  libguestfs-reiserfs  1:1.38.3-1
ii  libguestfs-xfs   1:1.38.3-1

Versions of packages libguestfs0 suggests:
ii  libguestfs-gfs21:1.38.3-1
ii  libguestfs-jfs 1:1.38.3-1
ii  libguestfs-nilfs   1:1.38.3-1
pn  libguestfs-rescue  
pn  libguestfs-rsync   
pn  libguestfs-zfs 

-- no debconf information

Bug#905047: plasma-widget-weather: Shorten too-long titles

[Anthony DeRobertis]

Package: plasma-widgets-addons
Version: 4:5.13.2-1
Severity: normal

After rebooting today, my desktop weather widget is suddenly much wider,
apparently because my weather station is:

Washington/Dulles International Airport, DC, VA

That leads to a very wide, silly-looking layout, screenshot attached.

Really ought to be a way to shorten the title. For example, 'Dulles
Airport' would be perfectly clear and fit nicely. Alternatively, a
smaller font would work — or an option to hide the station name
entirely.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages plasma-widgets-addons depends on:
ii  kdeplasma-addons-data   4:5.13.2-1
ii  kio 5.47.0-1
ii  kpackagetool5   5.47.0-1
ii  libc6   2.27-5
ii  libkf5archive5  5.47.0-1
ii  libkf5completion5   5.47.0-1
ii  libkf5configcore5   5.47.0-1
ii  libkf5configgui55.47.0-1
ii  libkf5coreaddons5   5.47.0-1
ii  libkf5i18n5 5.47.0-1
ii  libkf5iconthemes5   5.47.0-1
ii  libkf5kiocore5  5.47.0-1
ii  libkf5kiowidgets5   5.47.0-1
ii  libkf5newstuff5 5.47.0-1
ii  libkf5newstuffcore5 5.47.0-1
ii  libkf5notifications55.47.0-1
ii  libkf5plasma5   5.47.0-1
ii  libkf5service-bin   5.47.0-1
ii  libkf5service5  5.47.0-1
ii  libkf5unitconversion5   5.47.0-1
ii  libkf5widgetsaddons55.47.0-1
ii  libkf5windowsystem5 5.47.0-1
ii  libkf5xmlgui5   5.47.0-1
ii  libqt5core5a5.10.1+dfsg-7
ii  libqt5dbus5 5.10.1+dfsg-7
ii  libqt5gui5  5.10.1+dfsg-7
ii  libqt5qml5  5.10.1-4
ii  libqt5quick55.10.1-4
ii  libqt5webengine55.10.1+dfsg-4
ii  libqt5webenginecore55.10.1+dfsg-4
ii  libqt5widgets5  5.10.1+dfsg-7
ii  libstdc++6  8.1.0-12
ii  plasma-dataengines-addons   4:5.13.2-1
ii  plasma-framework5.47.0-1
ii  plasma-workspace4:5.13.2-1
ii  qml-module-org-kde-draganddrop  5.47.0-1
ii  qml-module-org-kde-kcoreaddons  5.47.0-1
ii  qml-module-org-kde-kio  5.47.0-1
ii  qml-module-org-kde-purpose  5.47.0-1
ii  qml-module-qtgraphicaleffects   5.10.1-2
ii  qml-module-qtquick-controls 5.10.1-2
ii  qml-module-qtquick-layouts  5.10.1-4
ii  qml-module-qtquick-window2  5.10.1-4
ii  qml-module-qtquick2 5.10.1-4
ii  qml-module-qtwebkit 5.212.0~alpha2-9+b1

Versions of packages plasma-widgets-addons recommends:
ii  ksysguard  4:5.13.1-1

plasma-widgets-addons suggests no packages.

-- no debconf information

Bug#903591: tmpfiles.d file: Line references path below legacy directory /var/run/ in log

[Anthony DeRobertis]

Package: postgresql-common
Version: 191
Severity: minor
File: /usr/lib/tmpfiles.d/postgresql.conf

Got this from logcheck:

Jul 10 02:14:18 Zia systemd-tmpfiles[8623]: 
[/usr/lib/tmpfiles.d/postgresql.conf:2] Line references path below legacy 
directory /var/run/, updating /var/run/postgresql → /run/postgresql; please 
update the tmpfiles.d/ drop-in file accordingly.

Apparently systemd complains about /var/run instead of /run now.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages postgresql-common depends on:
ii  adduser   3.117
ii  debconf [debconf-2.0] 1.5.67
ii  lsb-base  9.20170808
ii  postgresql-client-common  191
ii  procps2:3.3.15-2
ii  ssl-cert  1.0.39
ii  ucf   3.0038

Versions of packages postgresql-common recommends:
ii  e2fsprogs  1.44.2-1
ii  logrotate  3.11.0-0.1

Versions of packages postgresql-common suggests:
ii  libjson-perl  2.97001-1

-- Configuration Files:
/etc/postgresql-common/createcluster.conf changed:
ssl = on
cluster_name = '%v/%c'
stats_temp_directory = '/var/run/postgresql/%v-%c.pg_stat_tmp'
log_line_prefix = '%%m [%%p] %%q%%u@%%d '
add_include_dir = 'conf.d'
include_dir '/etc/postgresql-common/createcluster.d'


-- debconf information:
  postgresql-common/catversion-bump:
* postgresql-common/ssl: true
* postgresql-common/obsolete-major:

Bug#900173: git-annex: internal error: evacuate: strange closure type 4325404

[Anthony DeRobertis]

On 06/06/2018 08:54 PM, Joey Hess wrote:

That actually makes some kind of sense, since this bug has something
to do with garbage collection, and THP may result in different
memory allocation patterns due to the changed page size.

Except.. Isn't THP enabled by default on most systems?


Indeed it appears you're right, it defaults to on nowadays. Didn't used 
to (e.g., checked and it's not enabled by default in Stretch).


Also, I left the VM repeatedly starting and stopping the assistant 
overnight; that one failure I got was the only one it saw. Out of many 
thousand attempts. (And unfortunately, "power cycling" the VM didn't 
produce another, so it wasn't just the first run).


So back to the drawing board, I guess ☹

Bug#900173: git-annex: internal error: evacuate: strange closure type 4325404

[Anthony DeRobertis]

I finally managed to reproduce once on my VM after turning on 
transparent hugepages (which both my workstations are running with). The 
crash rate is much lower — under 10%, vs. 80–90% on the workstations — 
but...


Anyway, the next thing I plan to test is to turn off transparent 
hugepages on a workstation and see if that avoids the issue. I have *no 
idea* why it matters, and even less so why a rebuild fixes it. Might be 
a bit, as that requires rebooting.

Bug#860052: Merge request for logcheck too long lines (#860052)

[Anthony DeRobertis]

FYI, I submitted this patch I wrote for this as a merge request:

https://salsa.debian.org/debian/logcheck/merge_requests/1

I hope that's easier to deal with.

Bug#900173: git-annex: internal error: evacuate: strange closure type 4325404

[Anthony DeRobertis]

I've tried to reproduce on a newly-installed Buster VM, but haven't
been able to get it to crash. I guess that at least explains why only
I'm complaining — probably something weird about my two workstations
that cause it.

Going to see if I can find it, but welcome any suggestions as to what it
might be.

Bug#900173: git-annex: internal error: evacuate: strange closure type 4325404

[Anthony DeRobertis]

I've managed to reproduce the crash with the Debian build on a different 
machine, with a new git-annex repository (containing only public data, 
so I can share it if it helps).


This took a bit of playing around — so these steps may not be *entirely* 
accurate.


1. Created a new git repository at /tmp/ohnoes
2. git annex init  in it
3. started assistant (all good at this stage), add a few files (fortune
   -l > a, etc.)
4. cd /tmp && git clone ssh://localhost/tmp/ohnoes ohyeses
5. cd ohyeses && git-annex init ohyeses
6. git annex sync --content
7. cd /tmp/ohnoes && git remote add yes ssh://localhost/tmp/ohyeses
8. start assistant in /tmp/ohnoes: still OK. (Tried a bunch of times).
9. add a bunch of files to /tmp/ohyeses: for f in `seq 1 100`; do
   fortune -l > $f && git-annex add $f && git commit -m "add $f" ; done
10. stop and start the assistant a bunch of times in /tmp/ohnoes: Once
   crashed, but mostly worked.
11. add another bunch of files to /tmp/ohyeses (as above, through 150)
12. stop and start the assistant in /tmp/ohnoes: first try crashed. And
   second. Third worked. 4–8 crashed; 9 worked; 10 crashed.
13. installed my binNMU package (no source changes, just a rebuild—same
   one I installed on the other machine), and problem went away

BTW: I tried "git-annex test" on this machine before installing the 
rebuilt package, and it passed.


Going to try installing a buster VM and see if it's reproducible there. 
May not be until tomorrow, though, depending on how long it takes to set up.

Bug#900173: git-annex: internal error: evacuate: strange closure type 4325404

[Anthony DeRobertis]

On May 30, 2018 1:57:23 PM UTC, Sean Whitton  wrote:
>Hello,
>
>On Tue, May 29 2018, Anthony DeRobertis wrote:
>
>> ... and it turns out my build does not reproduce the problem.
>
>Just to be clear, you mean without Joey's patch?

Correct. Just rebuilding it, without modifying the source, fixes it for me. 

Bug#900173: git-annex: internal error: evacuate: strange closure type 4325404

[Anthony DeRobertis]

On Tue, May 29, 2018 at 12:35:59PM -0400, Joey Hess wrote:
> Any chance you can build git-annex from source, so we can try a few
> modifications to try to narrow this down?
> 
> sudo apt-get build-dep git-annex
> apt-get source git-annex
> cd git-annex-6.20180509
> make
> PATH=`pwd`:$PATH
> export PATH
> 
> Then see if you can reproduce the problem,

... and it turns out my build does not reproduce the problem.

I ran "git annex assistant" ten times with the Debian package, and 10
times with the source built as above. When it started up, I followed up
with "git annex assistant --stop". Results are:

Debian package: try 1–4 fail, 5 ok, 6–10 fail
My build: try 1–10 ok

So just to be sure, I rm -Rf'd that source tree, extracted it again
(dpkg-source -x) and did a dch --bin-nmu to up the version. Followed by
debuild -b -uc to make a new package, and installed it.

My package: try 1–10 ok

I'm running diffoscope on the two packages, but it's been thinking long
and hard on git-annex's .text segment, so I'm guessing it won't be
useful.

I'm not sure where to go for here — I'm not sure if forcing a rebuild
would fix it in Debian. Or how much work it'd be for me to reproduce
Debian's build environment from
https://buildd.debian.org/status/fetch.php?pkg=git-annex=amd64=6.20180509-1=1525912069=0
in a VM and see if then I can reproduce a broken build, and if that'd
really help us learn anything.



-- 
Democracy is a process by which the people are free to choose the man who
will get the blame.
-- Laurence J. Peter

Bug#900173: git-annex: internal error: evacuate: strange closure type 4325404

[Anthony DeRobertis]

On 05/27/2018 05:24 PM, Joey Hess wrote:

Anthony DeRobertis wrote:

So right now, it's just refusing the run in the background :-/

If you're able to reproduce the bug on demand that way,
that could point to the way git-annex daemonizes itself with
forkProcess. Which from its documentation:

 forkProcess comes with a giant warning: since any other running threads
 are not copied into the child process, it's easy to go wrong: e.g. by
 accessing some shared resource that was held by another thread in the
 parent.

git-annex tries to use forkProcess in a safe way, but that's not
especially well-defined or easy to check.

You might try running git-annex watch instead of git-annex assistant,
since they both daemonize but the latter has a simpler code path.

I stopped the (foreground) assistant with "git annex assistant --stop"; 
then ran "git annex assistant" (worked). Then stopped it again. Then 
started (failed). Tried another few times, all failed. I tried a few 
"git annex watch" followed by "git annex watch --stop" (after getting 
the "(started...)" message in the log — all of those worked. Tried a few 
more "git annex assistant", all failed.


So, absent the one "git annex assistant" which worked, those all failed. 
And all of the "git annex watch" worked. So does starting the assistant 
with "git annex assistant --foreground". (And maybe that's why the 
webapp was working for me earlier too — it doesn't fork...)


Honestly, if that code is a nightmare... you could just remove it. "git 
annex assistant --foreground &" is easy enough. And presumably entirely 
avoids the forkProcess issue there.

Bug#900173: git-annex: internal error: evacuate: strange closure type 4325404

[Anthony DeRobertis]

On 05/27/2018 01:20 PM, Joey Hess wrote:

One person reported the same error message 7 years ago here:
https://ghc.haskell.org/trac/ghc/ticket/5085
They were using git-annex get, not the assistant when it crashed.

They also were able to git bisect git-annex's code and found an utterly
innocuous commit that triggered whatever the problem is.
(commit 828a84ba3341d4b7a84292d8b9002a8095dd2382)

It's probably a memory problem, or a ghc bug, or a bug in some library
that is doing something memory related and messes up, such that ghc's
garbage collector sees bad data.


First off, thank you for git-annex. It's really useful software. I can't 
imagine syncing all this data between several desktops, laptops, & a few 
tablets without it. And apologies in advance for this rambling message.


Just finished 2, almost 3 passes of memtest86+ with no errors. (Before 
starting using them machine, several years ago, it had over 24h of 
memtest). It's been stable, haven't seen any random 
crashes/corruption/etc. — so I doubt it's a hardware issue. It's also 
not overclocked or anything silly like that.


I'm not sure what bisecting this would entail; as far as I can tell... 
it's random.


(BTW: I use the CLI interface too, quite a lot, and have never seen a 
weird error from it. Only from the assistant).


Freshly after booting, I ran "git annex assistant"; it gave one of those 
errors in the log. So I ran "git annex assistant --debug"; on the 
console it gave:


[2018-05-27 15:56:53.403932801] read: uname ["-o"]
[2018-05-27 15:56:53.405388769] process done ExitSuccess
[2018-05-27 15:56:53.502601514] logging to .git/annex/daemon.log
[2018-05-27 15:56:53.503385967] read: git 
["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
[2018-05-27 15:56:53.505100304] process done ExitSuccess
[2018-05-27 15:56:53.505256854] read: git 
["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
[2018-05-27 15:56:53.50805146] process done ExitSuccess
[2018-05-27 15:56:53.517155935] chat: git 
["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
[2018-05-27 15:56:53.517579777] chat: git 
["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname)
 %(objecttype) %(objectsize)"]
[2018-05-27 15:56:53.522956836] logging to .git/annex/daemon.log

and in the log,

[2018-05-27 15:56:40.385313411] main: starting assistant version 6.20180509
[2018-05-27 15:56:40.39050583] read: git 
["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
[2018-05-27 15:56:40.393284694] process done ExitSuccess
[2018-05-27 15:56:40.393397832] read: git 
["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
[2018-05-27 15:56:40.395763112] process done ExitSuccess
[2018-05-27 15:56:40.396781131] chat: git 
["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
git-annex: internal error: evacuate: strange closure type 4325407
(GHC version 8.2.2 for x86_64_unknown_linux)
Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

I ran the same command again; got the same (promising!). Then I added 
"--foreground" hoping to get some more debug outout... and isntead, it 
decided to work. The working log is (of course) longer, it looks like:


[2018-05-27 15:57:10.648904305] main: starting assistant version 6.20180509
[2018-05-27 15:57:10.652259294] read: git 
["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
[2018-05-27 15:57:10.712408937] process done ExitSuccess
[2018-05-27 15:57:10.712560137] read: git 
["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
[2018-05-27 15:57:10.715542944] process done ExitSuccess
[2018-05-27 15:57:10.716916651] chat: git 
["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
[2018-05-27 15:57:10.717421932] chat: git 
["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname)
 %(objecttype) %(objectsize)"]
[2018-05-27 15:57:10.843564188] Cronner: waiting Seconds {fromSeconds = 43369} 
for next scheduled fsck self 15m every day at 4 AM
[2018-05-27 15:57:10.958325684] read: git 
["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--stage","-z","--","."]
[2018-05-27 15:57:11.034783419] process done ExitSuccess
[2018-05-27 15:57:11.034973766] read: git 
["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--stage","-z","--","."]
[2018-05-27 15:57:11.162696] process done ExitSuccess
[2018-05-27 15:57:11.250761052] chat: nice 
["ionice","-c3","nocache","/usr/bin/git-annex","remotedaemon","--foreground"]
[2018-05-27 15:57:11.251914205] TransferScanner: Syncing with zia, einstein
[2018-05-27 15:57:11.3242642] TransferWatcher: watching for transfers
[2018-05-27 15:57:11.324391068] MountWatcher: Using running DBUS service 

Bug#900173: git-annex: internal error: evacuate: strange closure type 4325404

[Anthony DeRobertis]

On 05/27/2018 10:55 AM, Sean Whitton wrote:

This isn't enough information about how to reproduce this bug for me to
be comfortable forwarding it upstream, but I've CCed upstream just in
case he recognises the error message.


I hear you! But that's the entire log file ...

I also managed to produce a similar message, by using the "restart 
daemon" option in the webapp:


[2018-05-27 09:50:55.085069462] NetWatcherFallback: Syncing with public, zia, 
einstein
Everything up-to-date
Everything up-to-date
[2018-05-27 10:50:55.968806564] NetWatcherFallback: Syncing with public, zia, 
einstein
Everything up-to-date
Everything up-to-date
tail: '/home/anthony/Westerley-Board/.git/annex/daemon.log' has been replaced;  
following new file
[2018-05-27 11:01:09.077123603] main: starting assistant version 6.20180509
git-annex: internal error: evacuate: strange closure type 1061
(GHC version 8.2.2 for x86_64_unknown_linux)
Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

At this point, git annex assistant --stop doesn't work and I have to 
kill the git-annex process. After that, git annex assistant produces 
another very similar message:


tail: '/home/anthony/Westerley-Board/.git/annex/daemon.log' has appeared;  
following new file
[2018-05-27 11:04:00.911450237] main: starting assistant version 6.20180509
git-annex: internal error: evacuate: strange closure type 4325407
(GHC version 8.2.2 for x86_64_unknown_linux)
Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug


Trying again a few times produces similar messages, just with different 
numbers. This all works perfectly fine on a new test repository ... and 
it seems removing webapp.html wasn't actually what fixed it, I just need 
to wait long enough. Or something. It went away randomly one time I 
tried it. And now restarting the webapp is working.


Confusing. Just to be sure, going to reboot this machine into memtest 
(which was done before I first started using it, but you never know...)

Bug#900173: git-annex: internal error: evacuate: strange closure type 4325404

[Anthony DeRobertis]

Package: git-annex
Version: 6.20180509-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Running "git annex assistant" in my repository to start the assistant
gives a weird error in .git/annex/daemon.log:

[2018-05-27 00:49:40.496075979] main: starting assistant version 6.20180509
git-annex: internal error: evacuate: strange closure type 4325404
(GHC version 8.2.2 for x86_64_unknown_linux)
Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

I fixed it (temporarily at least) via: rm .git/annex/webapp.html

- -- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (130, 
'unstable-debug'), (130, 'unstable'), (120, 'experimental-debug'), (120, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages git-annex depends on:
ii  curl7.60.0-1
ii  git 1:2.17.0-1
ii  libc6   2.27-3
ii  libffi6 3.2.1-8
ii  libgmp102:6.1.2+dfsg-3
ii  libmagic1   1:5.33-2
ii  libsqlite3-03.23.1-1
ii  libxml2 2.9.4+dfsg1-6.1
ii  openssh-client  1:7.7p1-2
ii  rsync   3.1.2-2.1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages git-annex recommends:
ii  aria2  1.33.1-1
ii  bind9-host 1:9.11.3+dfsg-1
ii  git-remote-gcrypt  1.1-1
ii  gnupg  2.2.5-1
ii  lsof   4.89+dfsg-0.1
ii  nocache1.0-1
ii  youtube-dl 2018.05.18-dmo1

Versions of packages git-annex suggests:
pn  adb 
ii  bup 0.29-3
ii  libnss-mdns 0.14.1-1
pn  magic-wormhole  
pn  tahoe-lafs  
pn  tor 
pn  uftp
ii  xdot0.9-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCWwo5chUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf4QhACcDzRBM0mqGX0ZkXQEtKb40RW//b0A
mgIJvD0/xnnlZHHYZTYUIj6+hgD5
=7F8c
-END PGP SIGNATURE-

Bug#897388: Logs accessed files, etc. to syslog

[Anthony DeRobertis]

Package: kactivitymanagerd
Version: 5.12.1-1
Severity: important

Similar (but nowhere near as bad as) bug #805399, ActivityManager is
logging files I access to the systemd journal & syslog. Some examples:

May  1 16:43:33 Zia org.kde.ActivityManager[4152]: Creating the cache for:  
"applications:tora.desktop"
May  1 16:43:33 Zia org.kde.ActivityManager[4152]: Already in database?  true
May  1 16:43:33 Zia org.kde.ActivityManager[4152]:   First update :  
QDateTime(2016-10-11 13:24:44.000 EDT Qt::TimeSpec(LocalTime))
May  1 16:43:33 Zia org.kde.ActivityManager[4152]:Last update :  
QDateTime(2018-05-01 14:48:00.000 EDT Qt::TimeSpec(LocalTime))
May  1 16:43:33 Zia org.kde.ActivityManager[4152]: After the adjustment
May  1 16:43:33 Zia org.kde.ActivityManager[4152]:  Current score :  4.5649
May  1 16:43:33 Zia org.kde.ActivityManager[4152]:   First update :  
QDateTime(2016-10-11 13:24:44.000 EDT Qt::TimeSpec(LocalTime))
May  1 16:43:33 Zia org.kde.ActivityManager[4152]:Last update :  
QDateTime(2018-05-01 14:48:00.000 EDT Qt::TimeSpec(LocalTime))
May  1 16:43:33 Zia org.kde.ActivityManager[4152]: Interval length is  0
May  1 16:43:33 Zia org.kde.ActivityManager[4152]:  New score :  5.5649
May  1 16:43:33 Zia org.kde.ActivityManager[4152]: ResourceScoreUpdated: 
"beff6de3-1dc1-42b8-ab3d-2510f77b2ddf" "org.kde.krunner" 
"applications:tora.desktop"
May  1 17:33:32 Zia org.kde.ActivityManager[4152]: Creating the cache for:  
"/mnt/Haruhi/netadmin/HPM Retention Comparison EXPORT.pdf"
May  1 17:33:32 Zia org.kde.ActivityManager[4152]: Already in database?  true
May  1 17:33:32 Zia org.kde.ActivityManager[4152]:   First update :  
QDateTime(2018-05-01 17:32:38.000 EDT Qt::TimeSpec(LocalTime))
May  1 17:33:32 Zia org.kde.ActivityManager[4152]:Last update :  
QDateTime(2018-05-01 17:32:38.000 EDT Qt::TimeSpec(LocalTime))
May  1 17:33:32 Zia org.kde.ActivityManager[4152]: After the adjustment
May  1 17:33:32 Zia org.kde.ActivityManager[4152]:  Current score :  0
May  1 17:33:32 Zia org.kde.ActivityManager[4152]:   First update :  
QDateTime(2018-05-01 17:32:38.000 EDT Qt::TimeSpec(LocalTime))
May  1 17:33:32 Zia org.kde.ActivityManager[4152]:Last update :  
QDateTime(2018-05-01 17:32:38.000 EDT Qt::TimeSpec(LocalTime))
May  1 17:33:32 Zia org.kde.ActivityManager[4152]: Interval length is  21
May  1 17:33:32 Zia org.kde.ActivityManager[4152]:  New score :  0.35
May  1 17:33:32 Zia org.kde.ActivityManager[4152]: ResourceScoreUpdated: 
"beff6de3-1dc1-42b8-ab3d-2510f77b2ddf" "okular" "/mnt/Haruhi/netadmin/HPM 
Retention Comparison EXPORT.pdf"

while hopefully the database itself is in my home director and
mode go-rw, the same can't be said for syslog and journal. This violates
user privacy on a multi-user system as the sysadmin is expected to read
syslog, but respect the privacy of $HOME. In addition, syslog and
journal are available to members of group adm, who may not have root.

From the journal, it appears that kactivymanagerd may be speweing this
to stdout, which is ultimately being picked up by systemd (I think
that's what _TRANSPORT of stdout means):

{
   "_EXE" : "/usr/bin/dbus-daemon",
   "_GID" : "1000",
   "__CURSOR" : "[[redacted]]",
   "_SYSTEMD_OWNER_UID" : "1000",
   "_COMM" : "dbus-daemon",
   "_UID" : "1000",
   "_SYSTEMD_CGROUP" : 
"/user.slice/user-1000.slice/user@1000.service/dbus.service",
   "_MACHINE_ID" : "[[redacted]]",
   "_HOSTNAME" : "Zia",
   "_SYSTEMD_USER_SLICE" : "-.slice",
   "_BOOT_ID" : "[[redacted]]",
   "MESSAGE" : "Creating the cache for:  \"/mnt/Haruhi/netadmin/HPM Retention 
Comparison EXPORT.pdf\"",
   "__MONOTONIC_TIMESTAMP" : "1231383365390",
   "_CAP_EFFECTIVE" : "0",
   "_SYSTEMD_INVOCATION_ID" : "[[redacted]]",
   "__REALTIME_TIMESTAMP" : "1525210358022301",
   "_CMDLINE" : "/usr/bin/dbus-daemon --session --address=systemd: --nofork 
--nopidfile --systemd-activation --syslog-only",
   "_TRANSPORT" : "stdout",
   "SYSLOG_IDENTIFIER" : "org.kde.ActivityManager",
   "_SYSTEMD_USER_UNIT" : "dbus.service",
   "PRIORITY" : "4",
   "_SYSTEMD_SLICE" : "user-1000.slice",
   "_SELINUX_CONTEXT" : "unconfined\n",
   "_AUDIT_SESSION" : "6",
   "_PID" : "4152",
   "_STREAM_ID" : "[[redacted]]",
   "_AUDIT_LOGINUID" : "1000",
   "_SYSTEMD_UNIT" : "user@1000.service"
}


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kactivitymanagerd depends on:
ii  kio  5.44.0-2
ii  libc62.27-3
ii  

Bug#854165: conf.avil subdirectories now causing fontconfig warnings

[Anthony DeRobertis]

# fc-cache -s
Fontconfig error: failed reading config file
Fontconfig error: failed reading config file
Fontconfig error: failed reading config file
Fontconfig error: failed reading config file
Fontconfig error: failed reading config file

Turns out each of those is one place where /etc/fonts/conf.d has a
symlink to one of these directories. I fixed the problem locally on my
system by moving the directories out of the way and then moving the
.dpkg-new file in to place.

Bug#894667: Explanation of the beep vulnerability found on the 'net.

[Anthony DeRobertis]

An explanation of the exploit (not by me) is at
:

My speculation on the race condition fixed in the patch:

The while loop in `main` calls `play_beep` multiple times. Each call
to `play_beep` opens the `--device` and sets the global
`console_fd`, and then sets the global `console_type` based on the
`ioctl(EVIOCGSND)` error, before calling `do_beep`.

This normally prevents the user from writing to arbitrary files with
`--device`, because without the `ioctl(EVIOCGSND)` succeeding,
`do_beep` with `BEEP_TYPE_CONSOLE` only does a (harmless?)
`ioctl(KIOCSOUND)`, not a `write` with the `struct input_event`.
However, the signal handler calls `do_beep` directly using the
globals set by `play_beep`...

So I image that with something along the lines of `beep
--device=./symlink-to-tty ... --new ...`, you can rewrite the
symlink to point to an arbitrary file during the first `play_beep`,
and then race the open/ioctl in the second `play_beep` with the
signal handler such that `do_beep` gets called with `console_fd`
pointing to your arbitrary file, and with `console_type` still set
to `BEEP_TYPE_EVDEV`, resulting in a `write` to your arbitrary file.

Exploiting that for privesc would require control over the `struct
input_event` for the `write`... `handle_signal` calls `do_beep` with
a fixed `freq` of 0, so all of the initialized fields are set to
fixed values... However, there's an unitialized `struct timeval` at
the beginning of the `struct input_event`, and it's allocated on the
stack...

Seems like a curious security vulnerability, I'll assume the debian
security team must have a working PoC in order to actually call it
out as a local privesc vulnerability... I'd love to see the actual
PoC eventually :)

Bug#892423: man -Tutf8 /usr/share/man/ja/man5/apt_preferences.5.gz (and several others) enter infinite loop

[Anthony DeRobertis]

Package: man-db
Version: 2.8.2-1
Severity: normal

Running:

man -Tutf8 /usr/share/man/ja/man5/apt_preferences.5.gz

starts outputting the manpage, but then at some point switches over to
outputting an (so far as I can tell) infinite loop of newlines:

   sources.list(5) ファイルに列挙された場所から取得した Packages ファイル
   や Release ファイルはすべて、/var/lib/apt/lists ディレクトリ
   や、apt.conf ファイルの Dir::State::Lists 変数で指定した場所に取得され
   ます。例え




Attaching the requested debug output is... difficult, but attached are
the first 100,000 lines:

   man --debug -Tutf8 /usr/share/man/ja/man5/apt_preferences.5.gz |& head -n 
10 | gzip -v9 > /tmp/man-debug.txt.gz

I've also attached the apt_preferences page, just in case you have a
different version of apt; but note that other pages do this too (e.g.,
Japanese dos2unix page).

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages man-db depends on:
ii  bsdmainutils   11.1.2
ii  debconf [debconf-2.0]  1.5.66
ii  dpkg   1.19.0.5
ii  groff-base 1.22.3-10
ii  libc6  2.27-1
ii  libgdbm5   1.14.1-4
ii  libpipeline1   1.5.0-1
ii  libseccomp22.3.1-2.1
ii  zlib1g 1:1.2.8.dfsg-5

man-db recommends no packages.

Versions of packages man-db suggests:
pn  apparmor
ii  chromium [www-browser]  62.0.3202.89-1
ii  elinks [www-browser]0.12~pre6-13
ii  firefox [www-browser]   58.0.1-1+b1
ii  google-chrome-stable [www-browser]  65.0.3325.146-1
ii  groff   1.22.3-10
ii  konqueror [www-browser] 4:17.08.3-2
ii  less487-0.1
ii  links2 [www-browser]2.14-5
ii  lynx [www-browser]  2.8.9dev16-3
ii  w3m [www-browser]   0.5.3-36

-- debconf information:
  man-db/auto-update: true
* man-db/install-setuid: false


man-debug.txt.gz
Description: application/gzip


apt_preferences.5.gz
Description: application/gzip

Bug#890018: text2wave truncates output (speech cut off)

[Anthony DeRobertis]

Package: festival
Version: 1:2.5.0-1
Severity: normal
File: /usr/bin/text2wave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Not sure when this started, but (it existed before upgrading to 2.5):

echo 'Hello, world' | text2wave -eval '(voice_rab_diphone)' -f 44100 -o ugh.wav

produces a ugh.wav that is cut off. It gets partway through "hello".

echo 'Hello, world. 1. 2. 3. 4.' | text2wave -eval '(voice_rab_diphone)' -f 
44100 -o ugh.wav

produces a file that says "Hello world.", but none of the numbers.

It seems the "-f" argument is responsible; without it, the speech isn't
cut early.

- -- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (130, 
'unstable-debug'), (130, 'unstable'), (120, 'experimental-debug'), (120, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages festival depends on:
ii  adduser3.116
ii  alsa-utils 1.1.3-1
ii  libc6  2.26-4
ii  libestools2.5  1:2.5.0-4
ii  libgcc11:7.2.0-19
ii  libgomp1   7.2.0-19
ii  libstdc++6 7.2.0-19
ii  lsb-base   9.20170808
ii  sgml-base  1.29

Versions of packages festival recommends:
ii  festvox-kallpc16k [festival-voice]  2.4-1
ii  festvox-kdlpc16k [festival-voice]   1.4.0-6
ii  festvox-rablpc16k [festival-voice]  2.4-1

Versions of packages festival suggests:
pn  festival-freebsoft-utils  
pn  pidgin-festival   

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCWn6oQBUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf42WwCgj31P92aJZXpmUQDR6uSGo01Rwr8A
nRL7A1ZdE1qWZgrz8y2nMckCzdFv
=O46i
-END PGP SIGNATURE-

Bug#887790: No longer show thumbnails for extensionless JPEGs

[Anthony DeRobertis]

tags 887790 + patch
thanks

Found the commit responsible via git bisect.

commit 9be75e3431104d6a3a0c80324a8e3ac60316be13
Author: Tomasz Golinski <toma...@math.uwb.edu.pl>
Date:   Thu Sep 14 10:38:09 2017 +0100

Addl #510: Rudimentary video support

https://github.com/BestImageViewer/geeqie/issues/510

Add video files extension to default file filter (disabled by default).

Use recorded format_class in fd in metadata.c
Do not try to generate/read thumb for files which are not images.


And the attached patch appears to fix.
commit 9b9c916a82dde298ce2ba084c8fb7ba6dad5fa90
Author: Anthony DeRobertis <anth...@derobert.net>
Date:   Fri Jan 19 18:16:09 2018 -0500

Thumbnail all files if filtering is disabled.

If the user has disabled filtering by file extension, then we should
also disable that filtering when generating/loading thumbnails. Fixes
regression from 9be75e3431104d6a3a0c80324a8e3ac60316be13.

diff --git a/src/thumb.c b/src/thumb.c
index 96b71f8b..cdd4e550 100644
--- a/src/thumb.c
+++ b/src/thumb.c
@@ -337,7 +337,7 @@ gboolean thumb_loader_start(ThumbLoader *tl, FileData *fd)
 
 	if (!tl->fd) tl->fd = file_data_ref(fd);
 
-	if (tl->fd->format_class != FORMAT_CLASS_IMAGE && tl->fd->format_class != FORMAT_CLASS_RAWIMAGE && tl->fd->format_class != FORMAT_CLASS_VIDEO)
+	if (tl->fd->format_class != FORMAT_CLASS_IMAGE && tl->fd->format_class != FORMAT_CLASS_RAWIMAGE && tl->fd->format_class != FORMAT_CLASS_VIDEO && !options->file_filter.disable)
 		{
 		thumb_loader_set_fallback(tl);
 		return FALSE;
diff --git a/src/thumb_standard.c b/src/thumb_standard.c
index 9deb5947..f068ed0d 100644
--- a/src/thumb_standard.c
+++ b/src/thumb_standard.c
@@ -668,7 +668,7 @@ gboolean thumb_loader_std_start(ThumbLoaderStd *tl, FileData *fd)
 
 
 	tl->fd = file_data_ref(fd);
-	if (!stat_utf8(fd->path, ) || (tl->fd->format_class != FORMAT_CLASS_IMAGE && tl->fd->format_class != FORMAT_CLASS_RAWIMAGE && tl->fd->format_class != FORMAT_CLASS_VIDEO))
+	if (!stat_utf8(fd->path, ) || (tl->fd->format_class != FORMAT_CLASS_IMAGE && tl->fd->format_class != FORMAT_CLASS_RAWIMAGE && tl->fd->format_class != FORMAT_CLASS_VIDEO && !options->file_filter.disable))
 		{
 		thumb_loader_std_set_fallback(tl);
 		return FALSE;

Bug#887790: No longer show thumbnails for extensionless JPEGs

[Anthony DeRobertis]

Package: geeqie
Version: 1:1.4-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This is a regression from the previous version of geeqie I was using
(1:1.3-1).

I have Geeqie set to use the non-standard .thumbnails in image
directory. (Images are on a file share) I also have filtering turned off, so 
Geeqie ignores
extensions.

Previously, geeqie would display thumbnails for JPEGs even when they
didn't have an extension. Now it just shows a ??? icon. Even if I've
used an external program to already generate the thumbnails.

Going to attempt to bisect to find which commit caused this.

- -- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (130, 
'unstable-debug'), (130, 'unstable'), (120, 'experimental-debug'), (120, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages geeqie depends on:
ii  geeqie-common1:1.4-3
ii  libatk1.0-0  2.26.1-2
ii  libc62.26-4
ii  libcairo21.15.8-3
ii  libexiv2-14  0.25-3.1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-1
ii  libgcc1  1:7.2.0-19
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.54.3-1
ii  libgtk2.0-0  2.24.31-5
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-1
ii  liblirc-client0  0.10.0-2+b1
ii  liblua5.1-0  5.1.5-8.1+b2
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libpangoft2-1.0-01.40.14-1
ii  libstdc++6   7.2.0-19
ii  libtiff5 4.0.9-3

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.2.6-4
ii  exiftran 2.10-2+b3
ii  exiv20.25-3.1
ii  imagemagick  8:6.9.7.4+dfsg-16
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-16
ii  librsvg2-common  2.40.20-2
ii  ufraw-batch  0.22-2
ii  zenity   3.26.0-2

Versions of packages geeqie suggests:
pn  geeqie-dbg   
ii  gimp 2.8.20-1.1
ii  libjpeg-turbo-progs [libjpeg-progs]  1:1.5.2-2+b1
ii  ufraw0.22-2
pn  xpaint   

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCWmJ3/RUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf4XfwCfRU+9S83X4JT1be8QZYRE7V81HgoA
oIwaLR3oZPkHk7uHz1Lp5D6D74wP
=VJHC
-END PGP SIGNATURE-

Bug#884234: bareos: Stable update fails to configure (no database version defined, FAILED to set Catalog MyCatalog dbdriver = postgresql)

[Anthony DeRobertis]

Package: bareos
Version: 14.2.1+20141017gitc6c5b56-3+deb8u3
Severity: serious
Justification: Policy 10.7.3

I've been happily using the bareos packages on jessie for a bit now (thank
you for maintaining them!)

I attempted to upgrade bareos to 14.2.1+20141017gitc6c5b56-3+deb8u3
(from +deb8u2) this afternoon, and it failed to configure. Here is
trying to configure it again:

root@Bennu:~# dpkg --configure -a
Setting up bareos-database-common (14.2.1+20141017gitc6c5b56-3+deb8u3) ...
Warning: no database version defined for release 14.2.1+20141017gitc6c5b56 
(14.2.1+20141017gitc6c5b56-3+deb8u2). Using default version: 2003
(config) dbc_go() bareos-database-common configure 2003.
dbc_config() bareos-database-common configure 2003.
dbc_set_dbtype_defaults() .
dbc_register_debconf() .
dbc_read_package_config() .
dbc_preseed_package_debconf() .
dbc_detect_supported_dbtype() pgsql.
dbc_detect_installed_dbtype() pgsql.
_dbc_detect_installed_dbtype() pgsql.
dbc_config() bareos-database-common configure 2003.
dbc_set_dbtype_defaults() pgsql.
dbc_get_app_pass() .
Warning: no database version defined for release 14.2.1+20141017gitc6c5b56 
(14.2.1+20141017gitc6c5b56-3+deb8u2). Using default version: 2003
dbconfig-common: writing config to 
/etc/dbconfig-common/bareos-database-common.conf
dbconfig-common: flushing administrative password
FAILED to set Catalog MyCatalog dbdriver = postgresql 
(/etc/bareos/bareos-dir.conf)

... which would make sense because I don't have a catalog called
MyCatalog, except reading /usr/lib/bareos/scripts/bareos-config-lib.sh
it turns out its actually nowhere near that robust; it's just looking
for "dbdriver = ..." and failing to find it. That's broken for at least
three reasons:

   1) The documented parameter name is "DB Driver"; see
  
http://doc.bareos.org/master/html/bareos-manual-main-reference.html#directiveDirCatalogDB%20Driver
  and bareos of course doesn't care about capitalization or spacing
  (which is why dbdriver also works).

   2) Config files can include other config files, so the db config may
  not even be in that file at all.

   3) It blindly overwrites any configuration changes made by the admin,
  which isn't permitted by Debian Policy §10.7.3. (In my case,
  bareos-dir.conf is actually a generated file — directly editing it
  is broken.)

Thankfully, there is a fairly easy approach that solves all these
problems: put the default Debian database config in its own file
(possibly under /var/lib/bareos/) and then @-include it into the shipped
bareos-dir.conf. Then you don't have to touch the configuration file.


(I fixed my system by commenting out the apply_dbconfig_settings line in
/var/lib/dpkg/info/bareos-database-common.postinst).


 -- System Information:
Debian Release: 8.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bareos depends on:
ii  bareos-client14.2.1+20141017gitc6c5b56-3+deb8u3
iu  bareos-director  14.2.1+20141017gitc6c5b56-3+deb8u3
ii  bareos-storage   14.2.1+20141017gitc6c5b56-3+deb8u3

bareos recommends no packages.

bareos suggests no packages.

-- no debconf information

Bug#884231: bareos-storage-tape: Bug 808580 exists in jessie (Package tries to chown unexisting /etc/bareos/bareos-sd.d/device-tape-with-autoloader.conf)

[Anthony DeRobertis]

Package: bareos-storage-tape
Version: 14.2.1+20141017gitc6c5b56-3+deb8u3
Severity: important
Justification: Policy 10.7.3

# dpkg --configure -a
Setting up bareos-storage-tape (14.2.1+20141017gitc6c5b56-3+deb8u3) ...
chown: cannot access 
‘/etc/bareos/bareos-sd.d/device-tape-with-autoloader.conf’: No such file or 
directory
dpkg: error processing package bareos-storage-tape (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 bareos-storage-tape

This is of course #808580 which has been fixed in newer versions (and 
wasn't reported against the version in jessie). Opening a separate bugs 
since that one is already archived; my apologies if you preferred I 
un-archive and re-open that one instead.


Easy enough to work around on my system by adding an "|| true" to the 
chown line in /var/lib/dpkg/info/bareos-storage-tape.postinst, but this 
seems like something eligible for a (old-)stable update. And quite 
possible it'll break other people's systems too.

Bug#882872: vidir: Allow copying files

[Anthony DeRobertis]

Package: moreutils
Version: 0.60-1
Severity: wishlist
File: /usr/bin/vidir

Hello, I tried to copy a file by duplicating the line & giving it a new
name. Unfortunately, that just resulted in a parse error. It'd be nice
if that resulted in copying the file.

Thank you for maintaining moreutils. I use it almost every day.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages moreutils depends on:
ii  libc62.25-2
ii  libipc-run-perl  0.96-1
ii  perl 5.26.1-2

moreutils recommends no packages.

Versions of packages moreutils suggests:
ii  libtime-duration-perl  1.20-1
ii  libtimedate-perl   2.3000-2

-- no debconf information

Bug#874295: clementine: installs non-free plugin at runtime

[Anthony DeRobertis]

(from Jonas Smedegaard  via the bug):

> One of several functions of Clementine is to stream audio from cloud
> service Spotify.  Initially selecting that function triggers a routine
> where Clementine (asks for concent and then) downloads and installs a
> non-free binary driver.
> 
> Policy 2.2.1 states that "None of the packages in the main archive area
> require software outside of that area to function."
> 
> Clementine should either be moved to contrib, or the Spotify function be
> removed.

I suggest this isn't a Policy violation. Clementine functions without
the Spotify plugin; e.g., it'll happily play local music files, or from
any of the non-Spotify streaming sources.

Compare to, for example, all web browsers except lynx (and similar).
They all happily and automatically download and execute non-free code
(JavaScript), without any warning whatsoever. And if you turn off
JavaScript, they lose quite a bit more functionality than Clementine
does (I'd go so far as to say they become fairly useless — quite a bit
of the web doesn't work w/o JavaScript).

Many of them have their own plugin services (at least both Firefox and
Chromium do) that happily install and execute non-free code, again
without any warning (the only warnings they give are about access to
data, browsing history, etc., nothing about freedom).

Further, Debian understands software broadly (including, e.g.,
data—basically, "not hardware"), not just executables. If this bug
report's reading of policy were correct, Clementine would need to
disable most of streaming music services as the music they provide
doesn't follow DFSG. (And even lynx would have to be removed.)

I think it'd be reasonable to make the confirmation dialog explicitly
say that the plugin is not free software. But other than that, which
does not warrant severity: serious, I think this bug should be closed as
not a bug.

Bug#860052: [PATCH] Let mime-construct pick an encoding (closes: #860052)

[Anthony DeRobertis]

tags 860052 + patch
thanks

Note that this uses arrays, which are of course a bashism, but the top 
of the script explicitly calls for bash, so I presume bashisms are OK. 
Unfortunately, because of the "eval", it doesn't fully protect from 
weirdness in the config file. Of course, it looks like that eval could 
fairly easily be removed...



From 86c8dc10a6452c011b993569ea0994bf280fb40f Mon Sep 17 00:00:00 2001
From: Anthony DeRobertis
Date: Fri, 17 Nov 2017 12:43:01 -0500
Subject: [PATCH] Let mime-construct pick an encoding (closes: #860052)

Forcing 7bit is nice for MUAs and other tools that don't fully support
MIME encoding messages, but has the downside of sometimes generating
non-compliant messages. In particular, overly long lines get the
logcheck message rejected by Debian's default Exim configuration.

Add a configuration option to allow this to be overridden if required to
work with some MIME-unaware tool.
---
 etc/logcheck.conf | 11 +++
 src/logcheck  | 16 
 2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/etc/logcheck.conf b/etc/logcheck.conf
index 4653c11..1699fae 100644
--- a/etc/logcheck.conf
+++ b/etc/logcheck.conf
@@ -71,6 +71,17 @@ FQDN=1
 
 #ADDTAG="no"
 
+# Previous versions of logcheck always sent messages in 7bit encoding,

+# even if that resulted in RFC-violating messages. For example, really
+# long syslog lines would generate too-long SMTP lines, which are
+# rejected at least by Debian's default exim configuration. The new
+# default is to let mime-construct pick an appropriate encoding, but you
+# can override it by setting the below (to any of the encodings
+# supported by mime-construct). You may need to do this if you have
+# tools handling logcheck emails that don't understand MIME encoding.
+
+#MIMEENCODING="7bit"
+
 # Set a different location for temporary files than /tmp
 # this is useful if your /tmp is small and you are getting
 # errors such as:
diff --git a/src/logcheck b/src/logcheck
index a8c58ea..48082f3 100755
--- a/src/logcheck
+++ b/src/logcheck
@@ -84,6 +84,7 @@ INTRO=1
 LOGCHECKDEBUG=0
 MAILOUT=0
 MAILASATTACH=0
+MIMEENCODING=
 NOCLEANUP=0
 REBOOT=0
 FQDN=0
@@ -176,7 +177,7 @@ Also verify that the logcheck user can read all files 
referenced in
 $(export)
 EOF
} | eval mime-construct $MIMECONSTRUCTARGS \
-   --subject "'Logcheck: $HOSTNAME $DATE exiting due to errors'" --encoding 
"7bit" \
+   --subject "'Logcheck: $HOSTNAME $DATE exiting due to errors'" 
"${ENCODING[@]}" \
 --file - --to "$SENDMAILTO"
 
 elif [ "$MAILOUT" -eq 1 ]; then

@@ -306,14 +307,14 @@ sendreport() {
debug "Sending report: '$subject' to $SENDMAILTO"
 if [ "$MAILASATTACH" -eq 1 ]; then
   debug "Sending report as attachment"
-  eval mime-construct $MIMECONSTRUCTARGS --subject "'$subject'" --encoding "7bit" --string "'Report attached'" 
--to "$SENDMAILTO" --attachment "logcheck_report" --encoding "7bit" --file "$TMPDIR/report"
+  eval mime-construct $MIMECONSTRUCTARGS --subject "'$subject'" "${ENCODING[@]}" --string "'Report attached'" 
--to "$SENDMAILTO" --attachment "logcheck_report" "${ENCODING[@]}" --file "$TMPDIR/report"
   return $?
 elif [ "$MAILASATTACH" -eq 2 ]; then
   debug "Sending report as gzip attachment"
-  eval mime-construct $MIMECONSTRUCTARGS --subject "'$subject'" --encoding "7bit" --string "'Report attached'" 
--to "$SENDMAILTO" --type "application/x-gzip" --attachment "logcheck_report.gz" --file "'gzip -c $TMPDIR/report 
|'"
+  eval mime-construct $MIMECONSTRUCTARGS --subject "'$subject'" "${ENCODING[@]}" --string "'Report attached'" 
--to "$SENDMAILTO" --type "application/x-gzip" --attachment "logcheck_report.gz" --file "'gzip -c $TMPDIR/report 
|'"
   return $?
 fi
-eval mime-construct $MIMECONSTRUCTARGS --subject "'$subject'" --to "$SENDMAILTO" 
--encoding "7bit" --file "$TMPDIR/report"
+eval mime-construct $MIMECONSTRUCTARGS --subject "'$subject'" --to "$SENDMAILTO" 
"${ENCODING[@]}" --file "$TMPDIR/report"
 fi
 }
 
@@ -536,6 +537,13 @@ else

 SORT="sort -k 1,3 -s"
 fi
 
+# Set the forced mime encoding if not left blank (auto)

+if [ -n "$MIMEENCODING" ]; then
+   ENCODING=(--encoding "$MIMEENCODING")
+else
+   ENCODING=()
+fi
+
 # Hostname either fully qualified or not.
 if [ "$FQDN" -eq 1 ]; then
 HOSTNAME="$(hostname --fqdn 2>/dev/null)"
--
2.15.0

Bug#881358: nvidia_drv_video.so has no function __vaDriverInit_1_0

[Anthony DeRobertis]

Package: vdpau-va-driver
Version: 0.7.4-6
Severity: grave

anthony@Zia:~ [$?=3]$ vainfo 
libva info: VA-API version 1.0.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so
libva error: /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so has no function 
__vaDriverInit_1_0
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

And indeed, it does not:

anthony@Zia:~$ nm --demangle -D 
/usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so  | grep vaDriverInit
6320 T __vaDriverInit_0_31
6d40 T __vaDriverInit_0_39


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vdpau-va-driver depends on:
ii  libc6   2.24-17
ii  libgl1  0.2.999+git20170802-5
ii  libgl1-mesa-glx 17.2.4-1+b1
ii  libva1 [libva-driver-abi-0.39]  1.8.3-2
ii  libvdpau1   1.1.1-8
ii  libx11-62:1.6.4-3

vdpau-va-driver recommends no packages.

vdpau-va-driver suggests no packages.

-- no debconf information

Bug#879627: Both Firefox and Thunderbird lost their scrollbar arrows; other gtk3 apps did not

[Anthony DeRobertis]

Package: firefox
Version: 56.0-2
Severity: normal

Both Firefox and Thunderbird have lost their scrollbar arrows. Other
gtk3 apps (such as Evince) continue to have them, I'm using the
TraditionalOk theme which has them.

I tried Thunderbird in safe mode and same problem.

-- Package-specific info:

-- Extensions information
Name: A Web Browser Renaissance theme
Status: user-disabled

Name: Activity Stream
Location: ${PROFILE_EXTENSIONS}/activity-str...@mozilla.org.xpi
Status: enabled

Name: Add-on Compatibility Reporter
Location: ${PROFILE_EXTENSIONS}/compatibil...@addons.mozilla.org.xpi
Status: enabled

Name: Application Update Service Helper
Location: ${PROFILE_EXTENSIONS}/aushel...@mozilla.org.xpi
Status: enabled

Name: Banish large print edition userstyle
Status: user-disabled

Name: Bigger bodies, colors userstyle
Status: user-disabled

Name: Bugzilla - Show the whole g userstyle
Status: user-disabled

Name: Click-to-Play staged rollout
Location: ${PROFILE_EXTENSIONS}/clicktoplay-roll...@mozilla.org.xpi
Status: enabled

Name: Compact Dark theme
Status: user-disabled

Name: Compact Light theme
Status: user-disabled

Name: Default theme
Location: 
/usr/lib/firefox/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox
Status: enabled

Name: DOM Inspector
Location: /usr/share/xul-ext/dom-inspector
Package: xul-ext-dom-inspector
Status: user-disabled

Name: Firefox Screenshots
Location: ${PROFILE_EXTENSIONS}/screensh...@mozilla.org.xpi
Status: enabled

Name: Fix Google Reader userstyle
Status: user-disabled

Name: Fix Washpost userstyle
Status: enabled

Name: Follow-on Search Telemetry
Location: ${PROFILE_EXTENSIONS}/followonsea...@mozilla.com.xpi
Status: enabled

Name: Form Autofill
Location: ${PROFILE_EXTENSIONS}/formautof...@mozilla.org.xpi
Status: enabled

Name: Greasemonkey
Location: ${PROFILE_EXTENSIONS}/{e4a8a97b-f2ed-450b-b12d-ee082ba24781}.xpi
Status: enabled

Name: HN Utility Suite
Location: ${PROFILE_EXTENSIONS}/jid0-rhgamphpt2ngrv7gjxnbeerd...@jetpack.xpi
Status: enabled

Name: HTTPS Everywhere
Location: ${PROFILE_EXTENSIONS}/https-everywhere-...@eff.org.xpi
Status: enabled

Name: IdentFavIcon
Location: ${PROFILE_EXTENSIONS}/identfavi...@david.hanak.hu.xpi
Status: enabled

Name: It's All Text!
Location: ${PROFILE_EXTENSIONS}/itsallt...@docwhat.gerf.org
Status: enabled

Name: Larger Font userstyle
Status: enabled

Name: Larger fonts userstyle
Status: enabled

Name: Multi-process staged rollout
Location: ${PROFILE_EXTENSIONS}/e10sroll...@mozilla.org.xpi
Status: enabled

Name: MusicBrainz: Make table columns sortable greasemonkey-user-script
Status: enabled

Name: MusicBrainz: Show acoustids greasemonkey-user-script
Status: enabled

Name: MusicBrainz: Show stats from AcousticBrainz greasemonkey-user-script
Status: enabled

Name: my stars design for userstyles.org  userstyle
Status: enabled

Name: NYTimes Font Sizes userstyle
Status: enabled

Name: Open in Browser
Location: ${PROFILE_EXTENSIONS}/openinbrow...@www.spasche.net.xpi
Status: enabled

Name: Photon onboarding
Location: ${PROFILE_EXTENSIONS}/onboard...@mozilla.org.xpi
Status: enabled

Name: Pocket
Location: ${PROFILE_EXTENSIONS}/fire...@getpocket.com.xpi
Status: enabled

Name: RECAP
Location: ${PROFILE_EXTENSIONS}/i...@recapthelaw.org.xpi
Status: enabled

Name: SE Chat Modifications greasemonkey-user-script
Status: user-disabled

Name: SE Topbar userstyle
Status: enabled

Name: SE-Keyboard-Shortcuts greasemonkey-user-script
Status: enabled

Name: Shield Recipe Client
Location: ${PROFILE_EXTENSIONS}/shield-recipe-cli...@mozilla.org.xpi
Status: enabled

Name: So Do Me greasemonkey-user-script
Status: user-disabled

Name: Soft Aqua theme
Status: user-disabled

Name: StackExchange Fonts userstyle
Status: enabled

Name: Stylish
Location: ${PROFILE_EXTENSIONS}/{46551EC9-40F0-4e47-8E18-8E5CF550CFB8}.xpi
Status: enabled

Name: Tab Groups
Location: ${PROFILE_EXTENSIONS}/tabgro...@quicksaver.xpi
Status: enabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

Name: Use a Readable Font userstyle
Status: enabled

Name: Use Helvetica userstyle
Status: enabled

Name: Use normal sans-serif font userstyle
Status: enabled

Name: ViewAbout
Location: ${PROFILE_EXTENSIONS}/viewab...@rumblingedge.com.xpi
Status: enabled

Name: Web Compat
Location: ${PROFILE_EXTENSIONS}/webcom...@mozilla.org.xpi
Status: enabled

Name: Web Developer
Location: ${PROFILE_EXTENSIONS}/{c45c406e-ab73-11d8-be73-000a95be3b12}.xpi
Status: enabled

-- Plugins information
Name: Google Talk Plugin
Location: /opt/google/talkplugin/libnpgoogletalk.so
Package: google-talkplugin
Status: enabled

Name: Google Talk Plugin Video Renderer
Location: /opt/google/talkplugin/libnpo1d.so
Package: google-talkplugin
Status: enabled

Name: IcedTea-Web Plugin (using IcedTea-Web 1.6.2 (1.6.2-3.1))
Location: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-8-plugin:amd64
Status: enabled

Name: LastPass 

Bug#879131: Looks like transition didn't go according to plan

[Anthony DeRobertis]

Source: courier-unicode
Severity: serious

TLDR: Don't Breaks/Replaces libcourier-unicode1, it prevents install of
at least maildrop (or upgrade).

libcourier-unicode4 breaks libcourier-unicode1 << 1.4-4. The archive
currently has -3+b1, so they're not co-installable. This makes it
impossible to (for example) install both Courier and maildrop.

It looks like you planned to have 1.4-5 enter the archive — which would
be co-installable. At least the package tracker says you uploaded that
on Aug 7. I'm guessing it was ignored because you also uploaded 2.0-1
the same day (again according to the package tracker).

I found a copy using snapshot.d.o, but it appears you changed the
package name to libcourier-unicode3 to match the soversion. Normally
desired, but that also means it won't satisfy the dependency from
maildrop on -unicode1.

There appears to be no reason for libcourier-unicode4 to Breaks/Replaces
libcourier-unicode1. They have different soversions and no conflicting
files. Dropping that Breaks/Replaces would fix the (presumably) unwanted
conflict with maildrop.

I think it's just maildrop broken by this. So probably not worth the
effort to get 1.4-5 actually in to the archive (which would, I think,
require uploading it built from a new source package). 1.4 will be
dropped when maildrop's maintainers update their package. But even so,
it'd be nice to drop the Breaks/Replaces unless there is actually a good
reason to have it.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#866983: Bug #866983 Appears fixed in 10.1.25-1

[Anthony DeRobertis]

Package: mariadb-server-10.1
Followup-For: Bug #866983

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Installed 10.1.25-1 today appears this bug is fixed.

- -- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (500, 'stable'), (130, 'unstable'), (120, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages mariadb-server-10.1 depends on:
ii  adduser   3.115
ii  debconf   1.5.63
ii  galera-3  25.3.20-1
ii  gawk  1:4.1.4+dfsg-1
ii  init-system-helpers   1.49
ii  iproute2  4.9.0-1
ii  libaio1   0.3.110-3
ii  libc6 2.24-12
ii  libdbi-perl   1.636-1+b3
ii  libpam0g  1.1.8-3.6
ii  libstdc++67.1.0-10
ii  libsystemd0   234-2
ii  lsb-base  9.20161125
ii  lsof  4.89+dfsg-0.1
ii  mariadb-client-10.1   10.1.25-1
ii  mariadb-common10.1.25-1
ii  mariadb-server-core-10.1  10.1.25-1
ii  passwd1:4.4-4.1
ii  perl  5.26.0-5
ii  psmisc23.1-1
ii  rsync 3.1.2-2
ii  socat 1.7.3.2-1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages mariadb-server-10.1 recommends:
ii  libhtml-template-perl  2.95-2

Versions of packages mariadb-server-10.1 suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20160123cvs-4
pn  mariadb-test   
ii  netcat-openbsd 1.178-2
ii  tinyca 0.7.5-6

- -- Configuration Files:
/etc/logcheck/ignore.d.paranoid/mariadb-server-10_1 [Errno 13] Permission 
denied: '/etc/logcheck/ignore.d.paranoid/mariadb-server-10_1'
/etc/logcheck/ignore.d.server/mariadb-server-10_1 [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/mariadb-server-10_1'
/etc/logcheck/ignore.d.workstation/mariadb-server-10_1 [Errno 13] Permission 
denied: '/etc/logcheck/ignore.d.workstation/mariadb-server-10_1'

- -- debconf information:
  mariadb-server-10.1/nis_warning:
  mariadb-server-10.1/postrm_remove_databases: false
  mariadb-server-10.1/old_data_directory_saved:

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCWYgT6hUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf7FJACdEOa3p/OsnTm9cB7oef0KAsDaCN0A
n3OhF6bGa2P3DnGHsJZSIS95b0Au
=B0ao
-END PGP SIGNATURE-

Bug#862051: Refer #862051 to ctte

[Anthony DeRobertis]

On 07/14/2017 12:57 PM, Tollef Fog Heen wrote:

Fair point.

   3. Once a new nodejs package providing /usr/bin/node is in the
  archive, other packages in the archive are free to depend on the
  nodejs package and use /usr/bin/node .


That should probably be a versioned Depends, at least until a stable 
release includes /usr/bin/node in nodejs. Otherwise upgrades may break.


OTOH, is this paragraph (or 2, for that matter) really needed? They're 
just restating (somewhat imperfectly) Policy and/or normal practice in 
Debian, which presumably come back into effect anyway once the 
2012-07-12 decision is repealed.

Bug#868251: dm-raid.ko not included in md-modules udeb

[Anthony DeRobertis]

Source: linux
Version: 4.9.30-2
Severity: normal

It seems dm-raid.ko isn't in md-modules.udeb, or any other udeb on
DVD-1. It'd be useful to have it there to allow install on LVM-RAID
(which otherwise just requires an lvcreate or two on the command line).

Also useful because it'd presumably allow the rescue mode to be used on
such systems.

[My apologies if you're not the right folks to ask—not sure if its the
kernel team or the d-i team that I should be asking.]

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#867640: mlocate upstream has moved

[Anthony DeRobertis]

Package: mlocate
Version: 0.26-2
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

With fedorahosted having shut down, upstream seems to have moved to
. It does not appear they've made any (real)
code changes, though they now use git.

The upstream homepage and watch files need updating at least.

- -- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (500, 'stable'), (130, 'unstable'), (120, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages mlocate depends on:
ii  adduser  3.115
ii  libc62.24-12

mlocate recommends no packages.

mlocate suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCWWBbUBUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf7jewCff8r5K2UyZR6bxtSNkqmgomHa88IA
nR/gPl+PqpjDgD/9ntXIZgsH3k0E
=QINy
-END PGP SIGNATURE-

Bug#866983: mariadb spins at 100% forever during postinst

[Anthony DeRobertis]

Package: mariadb-server-10.1
Version: 10.1.24-6
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I attempted to upgrade mariadb-server-10.1 from 10.1.23-9+deb9u1 and
it's just sitting at

Setting up mariadb-server-10.1 (10.1.24-6) ...

with the CPU fan spinning nicely, top shows mysqld using 100% CPU.

After eventually giving up, and finding the only way to stop mysqld was
with kill -9 (non-sigkill was just ignored), I downgraded -server-10.1
and -server-core-10.1 back to 10.1.23-9+deb9u1; that worked.

I then attempted to upgrade it again, the same thing happened. Here is
all the info I can find, from the second upgrade attempt:

journal doesn't show much anything (just a note its starting the
process); /var/log/mysl/error.log shows:

2017-07-03  4:32:08 140510643651136 [Note] InnoDB: 
innodb_empty_free_list_algorithm has been changed to legacy because of small 
buffer pool size. In order to use backoff, increase buffer pool at least up to 
20MB.
2017-07-03  4:32:08 140510643651136 [Note] InnoDB: Using mutexes to ref count 
buffer pool pages
2017-07-03  4:32:08 140510643651136 [Note] InnoDB: The InnoDB memory heap is 
disabled
2017-07-03  4:32:08 140510643651136 [Note] InnoDB: Mutexes and rw_locks use GCC 
atomic builtins
2017-07-03  4:32:08 140510643651136 [Note] InnoDB: GCC builtin 
__atomic_thread_fence() is used for memory barrier
2017-07-03  4:32:08 140510643651136 [Note] InnoDB: Compressed tables use zlib 
1.2.8
2017-07-03  4:32:08 140510643651136 [Note] InnoDB: Using Linux native AIO
2017-07-03  4:32:08 140510643651136 [Note] InnoDB: Using SSE crc32 instructions
2017-07-03  4:32:08 140510643651136 [Note] InnoDB: Initializing buffer pool, 
size = 32.0M
2017-07-03  4:32:08 140510643651136 [Note] InnoDB: Completed initialization of 
buffer pool
2017-07-03  4:32:08 140510643651136 [Note] InnoDB: Highest supported file 
format is Barracuda.
2017-07-03  4:32:08 140510643651136 [Note] InnoDB: 128 rollback segment(s) are 
active.
2017-07-03  4:32:08 140510643651136 [Note] InnoDB: Waiting for purge to start
2017-07-03  4:32:08 140510643651136 [Note] InnoDB:  Percona XtraDB 
(http://www.percona.com) 5.6.36-82.0 started; log sequence number 231805652
2017-07-03  4:32:09 140510110938880 [Note] InnoDB: Dumping buffer pool(s) not 
yet started


ps fxa fragment:

10548 pts/1Sl+0:05  |   \_ aptitude
15369 pts/1S+ 0:00  |   \_ dpkg --configure 
-a
17965 pts/1S+ 0:00  |   \_ 
/usr/bin/perl -w /usr/share/debconf/frontend 
/var/lib/dpkg/info/mariadb-server-10.1.postinst configure 10.1.23-9+deb9u1
17974 pts/1S+ 0:00  |   \_ 
/bin/bash -e /var/lib/dpkg/info/mariadb-server-10.1.postinst configure 
10.1.23-9+deb9u1
17985 pts/1S+ 0:00  |   \_ bash 
/usr/bin/mysql_install_db --skip-auth-anonymous-user 
--auth-root-authentication-method=socket --rpm --cross-bootstrap --user=mysql 
--disable-log-bin
18011 pts/1S+ 0:00  |   |   \_ 
bash /usr/bin/mysql_install_db --skip-auth-anonymous-user 
--auth-root-authentication-method=socket --rpm --cross-bootstrap --user=mysql 
--disable-log-bin
18014 pts/1Sl+6:20  |   |   
\_ /usr/sbin/mysqld --lc-messages-dir=/usr/share/mysql/english/.. --bootstrap 
--basedir=/usr --datadir=/var/lib/mysql --log-warnings=0 
--enforce-storage-engine= --disable-log-bin --user=mysql 
--max_allowed_packet=8M --net_buffer_length=16K
17986 pts/1S+ 0:00  |   \_ 
logger -p daemon err -t mysqld_safe -i


lsof:
# lsof -p 18014
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
  Output information may be incomplete.
COMMAND   PID  USER   FD   TYPE DEVICE SIZE/OFFNODE NAME
mysqld  18014 mysql  cwdDIR  253,0 4096  943143 /var/lib/mysql
mysqld  18014 mysql  rtdDIR  253,0 4096   2 /
mysqld  18014 mysql  txtREG  253,0 17508488 2621633 /usr/sbin/mysqld
mysqld  18014 mysql  memREG  253,047632 2228315 
/lib/x86_64-linux-gnu/libnss_files-2.24.so
mysqld  18014 mysql  memREG  253,047688 2228332 
/lib/x86_64-linux-gnu/libnss_nis-2.24.so
mysqld  18014 mysql  memREG  253,089064 2228297 
/lib/x86_64-linux-gnu/libnsl-2.24.so
mysqld  18014 mysql  memREG  253,031616 2228300 
/lib/x86_64-linux-gnu/libnss_compat-2.24.so
mysqld  18014 mysql  memREG  253,084032 2228538 
/lib/x86_64-linux-gnu/libgpg-error.so.0.22.0
mysqld  18014 mysql  memREG  253,092520 2228232 
/lib/x86_64-linux-gnu/libgcc_s.so.1
mysqld  18014 mysql  memREG  253,0  1108088 2228801 
/lib/x86_64-linux-gnu/libgcrypt.so.20.1.8
mysqld  18014 mysql  memREG  253,072024 1574463 
/usr/lib/x86_64-linux-gnu/liblz4.so.1.7.1
mysqld  18014 mysql  memREG  253,0   154376 2228426 

Bug#854165: fonts-deva-extra: unneeded directory in /etc/fonts/conf.avail/

[Anthony DeRobertis]

Package: fonts-guru-extra
Version: 2.0-4
Followup-For: Bug #854165

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

FYI, it looks like something else weird happened with it:

Setting up fonts-guru-extra (2.0-4) ...
dpkg: warning: fonts-guru-extra: conffile 
'/etc/fonts/conf.avail/65-0-fonts-guru-extra.conf' is not a plain file or 
symlink (= '/etc/fonts/conf.avail/65-0-fonts-guru-extra.conf')

and indeed /var/lib/dpkg/info/fonts-guru-extra.conffiles lists
/etc/fonts/conf.avail/65-0-fonts-guru-extra.conf (which is a directory,
not a file).

- -- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (500, 'oldstable'), (130, 'unstable'), (120, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCWVn1cBUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf5wVQCdFA6GRSY2Wm4grxQ/RRpHGYqUb/wA
n3+UtCedmtCPzzAxVdQ3Mx80lEiF
=mnsq
-END PGP SIGNATURE-

Bug#865544: Adding a new default panel segfaults with apparent infinite recursion stack overflow

[Anthony DeRobertis]

On Fri, Jun 23, 2017 at 01:16:21PM +0200, Maximiliano Curia wrote:

> I can't reproduce the issue here with an intel card, so it might be that the
> issue is related to the nvidia drivers. I'm not really sure, can you test if
> the issue is still reproducible for you with 4:5.8.7-1, currently in
> unstable?

It reproduces with 4:5.8.7-1. I was planning on testing it on an Intel
video laptop I have at home, but didn't get around to it over the
weekend. I'll forward it upstream once I've tested there.

Bug#863044: Hans Sachs from The Meistersinger

[Anthony DeRobertis]

Package: fortunes
Version: 1:1.99.1-7
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

"Die Kunstwerk', die ein Schuster schuf,
 sie tritt die Welt mit Füssen!"

"A cobbler's works of art
 are trod upon by all the world!"

   -- Hans Sachs in Die Meistersinger von Nürnberg, Act II, Scene VI
  (Richard Wagner).

- -- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (500, 'stable'), (130, 'unstable'), (120, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages fortunes depends on:
ii  fortunes-min  1:1.99.1-7

Versions of packages fortunes recommends:
ii  fortune-mod  1:1.99.1-7+b1

fortunes suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCWSCBuRUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf6wPgCfQd3e7njzm09zBzQOUbEAAux5mV8A
nRTNRAm1hURlwJknuv6aaghWUrOU
=01dq
-END PGP SIGNATURE-

Bug#860758: Note in mdadm.conf that the initramfs has its own copy

[Anthony DeRobertis]

Package: mdadm
Version: 3.4-4+b1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It seems that not everyone knows that the initramfs keeps its own copy
of mdadm.conf and thus you often need to run update-initramfs after
editing /etc/mdadm/mdadm.conf.

I think a comment in the file would help with that. The mdadm.conf(5)
man page doesn't appear to mention it either.

Not being aware of this breaks people's systems, e.g.,:

https://unix.stackexchange.com/questions/359952/md-raid-fails-on-first-boot-of-the-day

https://unix.stackexchange.com/questions/210416/new-raid-array-will-not-auto-assemble-leads-to-boot-problems

https://unix.stackexchange.com/questions/165959/degraded-raid1-array-boots-with-one-drive-not-with-the-other
 (possibly)

https://unix.stackexchange.com/questions/23879/using-mdadm-examine-to-write-mdadm-conf
 (RHEL)

Bug#860106: Abort on long file names

[Anthony DeRobertis]

Package: gv
Version: 1:3.7.4-1+b1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It appears that when run on files with a long name, gv aborts. The file
name here should be ~150 bytes, well under the maximum (255 on ext4).

*** buffer overflow detected ***: gv terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f0feab27bcb]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f0feabb00b7]
/lib/x86_64-linux-gnu/libc.so.6(+0xf71f0)[0x7f0feabae1f0]
/lib/x86_64-linux-gnu/libc.so.6(+0xf6552)[0x7f0feabad552]
gv(+0x2c595)[0x55f60b964595]
gv(+0x3a00e)[0x55f60b97200e]
gv(+0x2ba18)[0x55f60b963a18]
gv(+0x30a1d)[0x55f60b968a1d]
gv(+0x18d07)[0x55f60b950d07]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f0feaad72b1]
gv(+0x19c3a)[0x55f60b951c3a]


I got a better backtrack running under valgrind:

**30866** *** strcpy_chk: buffer overflow detected ***: program terminated
==30866==at 0x4C2E7AC: VALGRIND_PRINTF_BACKTRACE (valgrind.h:6818)
==30866==by 0x4C32F0E: __strcpy_chk (vg_replace_strmem.c:1439)
==30866==by 0x134594: strcpy (string3.h:110)
==30866==by 0x134594: file_getTmpFilename (file.c:148)
==30866==by 0x14200D: psscan (ps.c:553)
==30866==by 0x133A17: doc_scanFile (doc_misc.c:79)
==30866==by 0x138A1C: setup_ghostview (misc.c:915)
==30866==by 0x120D06: main (main.c:1238)


And even better with gdb:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
set = {__val = {0, 3472328296227680304, 3467824696768081952, 
3991990709698103840, 3975887029563254374, 3991990507837744742, 
8083248238249914416, 3472328296227680288, 2319406834570502192, 
7378697628689244208, 3256155514234889783, 7378645952437315127, 
3255383588231721057, 3472328296227676272, 3472339291342909488, 
2314885530818457632}}
pid =
tid =
#1  0x7692f40a in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x2020202020202020, 
sa_sigaction = 0x2020202020202020}, sa_mask = {__val = {7795484802351636512, 
3917909816998060649, 3276497845987585332, 3615656491663847015, 
3966104962340237870, 7306639833582429798, 7378697426660503600, 
3472328529065424742, 3472310978873881120, 3467824696600309808, 
729636054439574064, 7234582441407964727, 7378645706714656869, 
3472387902693336678, 3467895053655089200, 140737488342064}}, sa_flags = 57, 
sa_restorer = 0x7fffcc30}
sigs = {__val = {32, 0 }}
#2  0x7696bbd0 in __libc_message (do_abort=do_abort@entry=2, 
fmt=fmt@entry=0x76a5f19f "*** %s ***: %s terminated\n") at 
../sysdeps/posix/libc_fatal.c:175
ap = {{gp_offset = 32, fp_offset = 32767, overflow_arg_area = 
0x7fffcc40, reg_save_area = 0x7fffcbd0}}
fd = 5
on_2 =
list =
nlist =
cp =
written =
#3  0x769f40b7 in __GI___fortify_fail (msg=msg@entry=0x76a5f136 "buffer 
overflow detected") at fortify_fail.c:30
No locals.
#4  0x769f21f0 in __GI___chk_fail () at chk_fail.c:28
No locals.
#5  0x769f1552 in __strcpy_chk (dest=0x7fffcda0 "", src=0x55833790 
"/home/anthony/Filing/.git/annex/objects/9j/jF/SHA512E-s335147--6ea0bee9e192016ff621417aaac619dc04cb10a712703848b719a35961ae9e9f1979ebe06485eb9e2070b0d67c3cfe9ffae3ac1af760fe45a0c8f3a4a68c167d.pdf/SHA5"...,
 destlen=256) at strcpy_chk.c:30
len =
#6  0x55580595 in strcpy (__src=0x55833790 
"/home/anthony/Filing/.git/annex/objects/9j/jF/SHA512E-s335147--6ea0bee9e192016ff621417aaac619dc04cb10a712703848b719a35961ae9e9f1979ebe06485eb9e2070b0d67c3cfe9ffae3ac1af760fe45a0c8f3a4a68c167d.pdf/SHA5"...,
 __dest=0x7fffcda0 "") at /usr/include/x86_64-linux-gnu/bits/string3.h:110
No locals.
#7  file_getTmpFilename (baseDirectory=0x557eea70 "/tmp/", baseDirectory@entry=0x0, 
baseFilename=baseFilename@entry=0x55833790 
"/home/anthony/Filing/.git/annex/objects/9j/jF/SHA512E-s335147--6ea0bee9e192016ff621417aaac619dc04cb10a712703848b719a35961ae9e9f1979ebe06485eb9e2070b0d67c3cfe9ffae3ac1af760fe45a0c8f3a4a68c167d.pdf/SHA5"...,
 filed=filed@entry=0x0) at file.c:148
tempFilename = 
"h\341\377\367\377\177\000\000\300\314\377\377\377\177\000\000\062l\000\000\250\275\360\273\000\000\000\000\377\377\377\377\000\000\000\000k\213\071\376\000\000\000\000\370x\220\366\377\177\000\000\350\071\374\367\377\177\000\000`_\220\366\377\177\000\000\350\071\374\367\377\177\000\000\377\377\377\377\000\000\000\000\060\020\000\000\000\000\000\000
 
'\220\366\377\177\000\000\350\071\374\367\377\177\000\000\b\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000c\000\000\000o",
 '\000' , 
"\020\025|UUU\000\000c\337YUUU\000\000\020I\203UUU\000\000\000*\203UUU\000\000\220\067\203UUU\000\000\004\000\000\000\000\000\000\000"...
tmpNameBuf = '\000' , '-' , 'P' , '\000' , "\377\377\000\377\377\377\377\377\377\377", 
'\000' , "\020\000\000\000\000\000\000\000\002", '\000' , 

Bug#858919: Crash reporter doesn't get symbols, even with -dbg installed

[Anthony DeRobertis]

Package: thunderbird
Version: 1:45.8.0-2
Severity: normal

I have thunderbird-dbg installed, but the crashes I report to Mozilla
still don't resolve symbols. E.g., 
https://crash-stats.mozilla.com/report/index/e5424761-bd92-4720-82c5-030b92170328#tab-details

-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages thunderbird depends on:
ii  debianutils   4.8.1
ii  fontconfig2.11.0-6.7+b1
ii  libasound21.1.3-5
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-9
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.16-1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.0-52.0.21-stable-3
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3+b2
ii  libgcc1   1:6.3.0-6
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libglib2.0-0  2.50.3-1
ii  libgtk2.0-0   2.24.31-2
ii  libhunspell-1.4-0 1.4.1-2+b2
ii  libicu57  57.1-5
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.26.2-1
ii  libpango-1.0-01.40.4-1
ii  libpangocairo-1.0-0   1.40.4-1
ii  libpangoft2-1.0-0 1.40.4-1
ii  libpixman-1-0 0.34.0-1
ii  libsqlite3-0  3.16.2-3
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++66.3.0-6
ii  libvpx4   1.6.1-2
ii  libx11-6  2:1.6.4-3
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc22.21-2.1+b2
ii  x11-utils 7.7+3+b1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages thunderbird recommends:
pn  lightning   
ii  myspell-en-us [myspell-dictionary]  1:3.3.0-4

Versions of packages thunderbird suggests:
pn  apparmor  
ii  fonts-lyx 2.2.2-1
ii  libgssapi-krb5-2  1.15-1

-- no debconf information

Bug#851096: update-leap tries to fetch https:// using a module without HTTPS support

[Anthony DeRobertis]

Package: ntp
Version: 1:4.2.8p9+dfsg-2
Severity: normal
File: /usr/bin/update-leap

It seems update-leap is just broken, with the default options, because
it attempts to use File::Fetch to grab an https:// URL, but File::Fetch
doesn't support https:// URLs.

Note that newer version of File::Fetch (apparently, starting in 0.50,
from August 2016) supports https:// but Debian doesn't have that
version, at least in testing.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ntp depends on:
ii  adduser3.115
ii  dpkg   1.18.18
ii  libc6  2.24-8
ii  libcap21:2.25-1
ii  libedit2   3.1-20160903-2
ii  libopts25  1:5.18.12-3
ii  libssl1.1  1.1.0c-2
ii  lsb-base   9.20161125
ii  netbase5.4

Versions of packages ntp recommends:
pn  perl:any  

Versions of packages ntp suggests:
pn  ntp-doc  

-- Configuration Files:
/etc/ntp.conf changed [not included]

-- no debconf information

Bug#848563: UTF-8 support

[Anthony DeRobertis]

Package: cdlabelgen
Version: 4.3.0-1
Severity: wishlist
Tags: l10n upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I fed cdlabelgen a file name that contained an em-dash (—, U+2014). On
the printout, however, it wasn't an em-dash anymore—it was a bunch of
weird characters. (My locale is en_US.UTF-8).

UTF-8 really ought to work. (I'm not holding my breath, considering the
state of Unicode support in Postscript.)

- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing'), (500, 'stable'), (130, 
'unstable'), (120, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages cdlabelgen depends on:
ii  perl  5.24.1~rc3-3

Versions of packages cdlabelgen recommends:
ii  ghostscript  9.19~dfsg-3.1

cdlabelgen suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCWFaEixUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf4j3ACff67IpRfUBbD+xzPMyKE70fl6XoQA
n1DSyoW3o0oqH6GgafHu5Q8bc5do
=rdBE
-END PGP SIGNATURE-