Bug#1014505: rtkit-daemon.service fails to start as a service

2022-07-07 Thread Christian Lamparter 
Package: rtkit
Version: 0.13-4
Severity: important

Dear Maintainer,

since around 1sth of July, I've experienced issues with rtkit-daemon.service
failing to start:

---
Jul 01 06:42:43 debian64 systemd[1]: Starting RealtimeKit Scheduling Policy
Service...
Jul 01 06:42:43 debian64 systemd[1]: rtkit-daemon.service: Main process exited,
code=exited, status=1/FAILURE
Jul 01 06:42:43 debian64 systemd[1]: rtkit-daemon.service: Failed with result
'exit-code'.
Jul 01 06:42:43 debian64 systemd[1]: Failed to start RealtimeKit Scheduling
Policy Service.
[repeated every 2 - 5 seconds!]
---

I noticed this because as a result of rtkit-daemon missing, pulseaudio will
fail to start.

As a workaround I found that starting /usr/libexec/rtkit-daemon as root
manually "worked"
and pulseaudio came up as well.

I looked at the service file and added strace to it to see what's going on:

---
Jul 07 09:50:24 debian64 strace[23820]: connect(3, {sa_family=AF_UNIX,
sun_path="/run/dbus/system_bus_socket"}, 29) = -1 ECONNREFUSED (Connection
refused)
Jul 07 09:50:24 debian64 strace[23820]: close(3)
= 0
[...]
Jul 07 09:50:24 debian64 strace[23820]: socket(AF_UNIX,
SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3
Jul 07 09:50:24 debian64 strace[23820]: connect(3, {sa_family=AF_UNIX,
sun_path="/dev/log"}, 110) = -1 ECONNREFUSED (Connection refused)
Jul 07 09:50:24 debian64 strace[23820]: close(3)
= 0
Jul 07 09:50:24 debian64 strace[23820]: getpid()
= 23823
Jul 07 09:50:24 debian64 strace[23820]: socket(AF_UNIX,
SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3
Jul 07 09:50:24 debian64 strace[23820]: connect(3, {sa_family=AF_UNIX,
sun_path="/dev/log"}, 110) = -1 ECONNREFUSED (Connection refused)
Jul 07 09:50:24 debian64 strace[23820]: close(3)
= 0
Jul 07 09:50:24 debian64 strace[23820]: getpid()
= 23823
Jul 07 09:50:24 debian64 strace[23820]: socket(AF_UNIX,
SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3
Jul 07 09:50:24 debian64 strace[23820]: connect(3, {sa_family=AF_UNIX,
sun_path="/dev/log"}, 110) = -1 ECONNREFUSED (Connection refused)
Jul 07 09:50:24 debian64 strace[23820]: close(3)
= 0
Jul 07 09:50:24 debian64 strace[23820]: exit_group(1)
= ?
Jul 07 09:50:24 debian64 strace[23820]: +++ exited with 1 +++
Jul 07 09:50:24 debian64 systemd[1]: rtkit-daemon.service: Main process exited,
code=exited, status=1/FAILURE
Jul 07 09:50:24 debian64 systemd[1]: rtkit-daemon.service: Failed with result
'exit-code'.
Jul 07 09:50:24 debian64 systemd[1]: Failed to start RealtimeKit Scheduling
Policy Service.
---

So, the service had issues connecting to dbus and /dev/log which was strange
since every other
service had no issues and worked "fine". I tried playing around with adding all
the CapabilityBoundingSet I could find,
added "RestrictAddressFamilies=AF_UNIX AF_LOCAL AF_NETLINK" and
"ReadWritePaths=/dev/log"... but to no avail.

In the end I removed PrivateNetwork=yes and, reloaded and the rtkit-
daemon.service started right up without issues.

Reading up on PrivateNetwork on


I found this nugget of information:
"Note that this option will disconnect all socket families from the host,
including AF_NETLINK and AF_UNIX.

Effectively, for AF_NETLINK this means that device configuration events
received from systemd-udevd.service(8)
are not delivered to the unit's processes. And for AF_UNIX this has the effect
that AF_UNIX sockets in the
abstract socket namespace of the host will become unavailable to the unit's
processes (however, those located
in the file system will continue to be accessible)."

so, it sounds like "those located in the file system will continue to be
accessible" seems to be broken.

Cheers,
Christian

PS.: This is with a 5.19-rc4 kernel, I'll try debian's 5.18.0-2-amd64 later as
well.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, powerpc, mips, arm64

Kernel: Linux 5.19.0-rc4-wt+ (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_DE.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rtkit depends on:
ii  adduser  3.121
ii  dbus 1.14.0-1
ii  libc62.33-7
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.14.0-1
ii  libsystemd0  251.2-8
ii  policykit-1  0.105-33

rtkit recommends no packages.

rtkit suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "en_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot

Bug#1009350: linux-image-5.17.0-trunk-cloud-amd64: include i6300esb watchdog driver for openstack/libvirt/kvm/qemu

2022-04-12 Thread Christian Lamparter 
Package: src:linux
Version: 5.17.1-1~exp1
Severity: normal

Dear Maintainer,

when working with linux-image-cloud-amd64's bullseye cousin,
I noticed that the watchdog dev (/dev/watchdog) was absent
from the VM and I'm unable to use the watchdog actions.

The OpenStack wiki says that only "i6300esb" makes sense:
<https://wiki.openstack.org/wiki/LibvirtWatchdog>

"KVM has a choice of two watchdog devices, but in reality
only the PCI i6300esb device makes sense, since the alternative
is a legacy ISA bus device."

Looking through the provided modules files for the kernels

/lib/modules/5.10.0-13-cloud-amd64/kernel/drivers/watchdog/

(and later /lib/modules/5.17.0-trunk-cloud-amd64/kernel/drivers/watchdog/
of linux-image-5.17.0-trunk-cloud-amd64. I did this because the reportbug
suggested that I also look at the experimental branch and I thought:
"hey, why not?!")

the available watchdog modules are (both 5.10.0-13 + 5.17.0-trunk):
mei_wdt.ko, ni903x_wdt.ko, nic7018_wdt.ko, softdog.ko, wdat_wdt.ko,
wdt_pci.ko and xen_wdt.ko

This makes sense, since in /boot/config-5.10.0-13-cloud-amd64 and
/boot/config-5.17.0-trunk-cloud-amd64 had the watchdog disabled:

| # CONFIG_I6300ESB_WDT is not set

Would it be possible to build the i6300esb as a module for future
releases?

Thanks,
Christian Lamparter


-- Package-specific info:
** Kernel log: boot messages should be attached


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, powerpc, mips, arm64

Kernel: Linux 5.17.0-wt+ (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-5.17.0-trunk-cloud-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.141
ii  kmod29-1
ii  linux-base  4.8

Versions of packages linux-image-5.17.0-trunk-cloud-amd64 recommends:
ii  apparmor 3.0.4-2
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.17.0-trunk-cloud-amd64 suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1
ii  grub-efi-amd64  2.06-2
pn  linux-doc-5.17  

Versions of packages linux-image-5.17.0-trunk-cloud-amd64 is related to:
ii  firmware-amd-graphics 20210818-1
ii  firmware-atheros  20210818-1
pn  firmware-bnx2 
pn  firmware-bnx2x
ii  firmware-brcm8021120210818-1
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
ii  firmware-ipw2x00  20210818-1
pn  firmware-ivtv 
ii  firmware-iwlwifi  20210818-1
ii  firmware-libertas 20210818-1
pn  firmware-linux-nonfree
ii  firmware-misc-nonfree 20210818-1
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
ii  firmware-realtek  20210818-1
pn  firmware-samsung  
pn  firmware-siano
ii  firmware-ti-connectivity  20210818-1
pn  xen-hypervisor

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "en_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

-- debsums errors found:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "en_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Bug#995047: /usr/share/initramfs-tools/hooks/mdadm: efivars module was renamed to efivarfs

2021-09-25 Thread Christian Lamparter 
Package: mdadm
Version: 4.2~rc2-6
Severity: normal
File: /usr/share/initramfs-tools/hooks/mdadm
Tags: patch

Dear Maintainer,

during boot I get a message about the "efivars" module not being found.
This happens during initramfs. While looking at:

/usr/share/initramfs-tools/hooks/mdadm

it seems the fix is simple enough:
---
--- /usr/share/initramfs-tools/hooks/mdadm.orig 2021-09-25 10:55:53.198883823
+0200
+++ /usr/share/initramfs-tools/hooks/mdadm  2021-09-24 22:45:33.090345701
+0200
@@ -66,7 +66,7 @@ for module in linear multipath raid0 rai
 done

 # load efivars for Intel RST IMSM, see Bug#962844
-force_load efivars || true
+force_load efivarfs || true

 # copy the mdadm configuration
 CONFIG=/etc/mdadm/mdadm.conf
---

Apparently, someone took the time do document when the change happened
(>=5.10.1-1~exp1):
https://michael-prokop.at/blog/2021/06/09/efivars-is-gone-with-debian-bullseye-
newinbullseye/

This would mean that this could be backported to bullseye maybe?


-- Package-specific info:

IMPORTANT:
  please do not forget to include all relevant system information with this
  bug report. You could run
/usr/share/bug/mdadm/script 3>&1
  as root and attach or include the output.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, powerpc, mips, arm64

Kernel: Linux 5.15.0-rc2-wt+ (SMP w/8 CPU threads)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages mdadm depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  libc6  2.32-4
ii  libudev1   247.9-2
ii  lsb-base   11.1.0
ii  udev   247.9-2

Versions of packages mdadm recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.95~RC2-1
ii  kmod   29-1

Versions of packages mdadm suggests:
pn  dracut-core  

-- Configuration Files:
/etc/logcheck/ignore.d.server/mdadm [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/mdadm'
/etc/logcheck/violations.d/mdadm [Errno 13] Permission denied: 
'/etc/logcheck/violations.d/mdadm'

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "en_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
  mdadm/autostart: true
  mdadm/initrdstart_msg_errmd:
  mdadm/start_daemon: true
  mdadm/mail_to: root
* mdadm/initrdstart: all
  mdadm/initrdstart_msg_errconf:
  mdadm/initrdstart_msg_errexist:
  mdadm/autoscan: true
  mdadm/autocheck: true
  mdadm/initrdstart_notinconf: false
  mdadm/initrdstart_msg_intro:
  mdadm/initrdstart_msg_errblock:

-- debsums errors found:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "en_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
debsums: changed file /usr/share/initramfs-tools/hooks/mdadm (from mdadm 
package)
--- /usr/share/initramfs-tools/hooks/mdadm.orig 2021-09-25 10:55:53.198883823 
+0200
+++ /usr/share/initramfs-tools/hooks/mdadm  2021-09-24 22:45:33.090345701 
+0200
@@ -66,7 +66,7 @@ for module in linear multipath raid0 rai
 done
 
 # load efivars for Intel RST IMSM, see Bug#962844
-force_load efivars || true
+force_load efivarfs || true
 
 # copy the mdadm configuration
 CONFIG=/etc/mdadm/mdadm.conf

Bug#985149: debootstrap stumbles over tabs in include parameter

2021-03-16 Thread Christian Lamparter 

Hello Steve,

On 16/03/2021 15:12, Steve McIntyre wrote:

On Sat, Mar 13, 2021 at 05:56:26PM +0100, Christian Lamparter wrote:

Package: debootstrap
Version: 1.0.123
Severity: normal

Dear Maintainer,

I ran into an issue when I was using debootstrap in order to setup a chroot-
environment.

I: Retrieving InRelease
I: Checking Release signature
I: Valid Release signature (key id 6D33866EDD8FFA41C0143AEDDCC9EFBF77E11517)
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://deb.debian.org/debian...
E: Couldn't find these debs: 48477576

I was surprised to see that "48477576". I expected to get the
name of the package that was causing this, instead of a number.
I dug deeper to see what's causing this and I was surprised
when I found out that the parameter '--include=package'
that was passed to debootstrap was causing this.

Here's a reproducer (can be copied into bash). It fetches the
current debian stable for amd64 with "gzip" as an extra package.
(that $(printf \\t) is in this example, here so the "tab" won't
get lost when copying)


Ummm. Why are you expecting debootstrap to deal with whitespace here?
I'm not convinced this is a bug...


What threw me off is that "E: Couldn't find these debs: 48477576".
48477576 is not a package, right?.

Well, the backstory is: I came across this, because I needed some
extra, but sensible packages in my basic image for it to be useful.

this script look(ed) like this (a mailer with tab support is needed
for proper alignment)

---
PACKAGE="initramfs-tools,gzip,u-boot-tools,device-tree-compiler,\
 debian-keyring-archive,bzip2, ca-certificates,wget,\
 ..."

debootstrap --include="$PACKAGE" ...
---

But it bugged and I had no idea it was because I was using tabs to
align the extra PACKAGE in the next lines because they wouldn't fit
due to 80 cols limit.

Once I figured out that the use of tabs are the issue, I replaced
them with spaces. Then I went on to write a proper bug-report with
a testcase and PoC-patch, in case someone (like future me) stumbles
over this as well: "Check your include/excludes with a fine comb".


But back to the business at hand... Because I would need to know
why you think that a Error message like
"E: Couldn't find these debs: 48477576"
doesn't trigger a "yeah, this 48477576 looks buggy"?

Is there a deeper meaning to the numbers like 48477576?...
or:
 - 29976556? 
(<https://lists.uni-koeln.de/pipermail/linux-fai/2005-September/003500.html>)
 - 91369800? 
(<https://linux.debian.maint.boot.narkive.com/z0k3FJmD/bug-785276-debootstrap-fails-with-message-couldn-t-find-these-debs-91369800>)
 - 0? (<https://github.com/meefik/linuxdeploy/issues/190>)

that I don't get?

Cheers,
Christian

Bug#985149: debootstrap stumbles over tabs in include parameter

2021-03-13 Thread Christian Lamparter 
Package: debootstrap
Version: 1.0.123
Severity: normal

Dear Maintainer,

I ran into an issue when I was using debootstrap in order to setup a chroot-
environment.

I: Retrieving InRelease
I: Checking Release signature
I: Valid Release signature (key id 6D33866EDD8FFA41C0143AEDDCC9EFBF77E11517)
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://deb.debian.org/debian...
E: Couldn't find these debs: 48477576

I was surprised to see that "48477576". I expected to get the
name of the package that was causing this, instead of a number.
I dug deeper to see what's causing this and I was surprised
when I found out that the parameter '--include=package'
that was passed to debootstrap was causing this.

Here's a reproducer (can be copied into bash). It fetches the
current debian stable for amd64 with "gzip" as an extra package.
(that $(printf \\t) is in this example, here so the "tab" won't
get lost when copying)

--- reproducer.sh one-liner ---

/usr/sbin/debootstrap --foreign "--include=$(printf \\t)gzip" --arch=amd64
stable "$(mktemp -d)" "http://deb.debian.org/debian;

--- reproducer.sh EOF ---

Since I now know what to look for, I edited /usr/share/debootstrap/functions
to remove tabs from the $leftoverdebs in the download_release() function.

--- remove-tabs-from-include.patch ---
--- /usr/share/debootstrap/functions.orig   2021-03-13 17:43:18.058708393
+0100
+++ /usr/share/debootstrap/functions2021-03-13 17:43:39.792093090 +0100
@@ -804,7 +804,7 @@ download_release () {
leftoverdebs="$*"

# Fix possible duplicate package names, which would screw up counts:
-   leftoverdebs=$(printf "$leftoverdebs"|tr ' ' '\n'|sort -u|tr '\n' ' ')
+   leftoverdebs=$(printf "$leftoverdebs"|tr -d '\t'|tr ' ' '\n'|sort -u|tr
'\n' ' ')
numdebs=$(printf "$leftoverdebs"|wc -w)

for s in $SUITE $EXTRA_SUITES; do
--- remove-tabs-from-include.patch EOF ---

This "fixed" the issue for me. But I know that this is quick and dirty.

Cheers,
Christian


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, powerpc, mips, arm64

Kernel: Linux 5.12.0-rc2-wt+ (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_DE.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages debootstrap depends on:
ii  wget  1.21-1+b1

Versions of packages debootstrap recommends:
ii  arch-test   0.17-1
ii  debian-archive-keyring  2021.1.1
ii  gnupg   2.2.27-1

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  

-- debconf information excluded

-- debsums errors found:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "en_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Bug#960558: cyrus-common: lmtpd aborts when compiled with optimisation and FORTIFY_SOURCE flags

2020-05-15 Thread Christian Lamparter 

There's now a patch available in the upstream git (see attachment).

https://github.com/cyrusimap/cyrus-imapd/commit/f4b4c5bf65c1737aeaccc64678f5d4c31a1de48f

Cheers,
Christian

>From f4b4c5bf65c1737aeaccc64678f5d4c31a1de48f Mon Sep 17 00:00:00 2001
From: ellie timoney 
Date: Fri, 15 May 2020 09:47:56 +1000
Subject: [PATCH] lmtp_err: fix invalid position parameter usage

This fails under FORTIFY_SOURCE (#1981), which I guess more and more
platforms are starting to use by default.

Fixes #3035
---
 imap/lmtp_err.et | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/imap/lmtp_err.et b/imap/lmtp_err.et
index cd5c1ac64..4e2701303 100644
--- a/imap/lmtp_err.et
+++ b/imap/lmtp_err.et
@@ -45,7 +45,7 @@ error_table lmtp
 # Enhanced Mail System Status Codes (RFC 3463)
 
 ec LMTP_OK,
-   "250 2.1.5 Ok SESSIONID=<%2$s>"
+   "250 2.1.5 %s SESSIONID=<%s>"
 
 ec LMTP_MAILBOX_ERROR,
"451 4.2.0 %s"

Bug#960558: cyrus-common: lmtpd aborts when compiled with optimisation and FORTIFY_SOURCE flags

2020-05-13 Thread Christian Lamparter 
Package: cyrus-common
Version: 3.2.0-2
Severity: normal
Tags: upstream

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Today at 17:30-ish, my MTA (exim4) decided to generate a whole bunch of
 "Mail delivery notifications" seemingly out of nowhere from mails that
have been delivered just fine. The smoking gun was found in the logs:

May 13 22:14:14 debian64 cyrus/lmtpunix[19567]: SQL backend defaulting to
engine 'pgsql'
May 13 22:14:14 debian64 cyrus/lmtpunix[19567]: executed
May 13 22:14:14 debian64 cyrus/lmtpunix[19567]: accepted connection
May 13 22:14:14 debian64 cyrus/lmtpunix[19567]: connection from [unix socket]
preauth'd as postman
May 13 22:14:14 debian64 cyrus/lmtpunix[19567]: fetching user_deny.db entry for
'chuck'
May 13 22:14:14 debian64 cyrus/lmtpunix[19567]: sieve_rebuild:
/var/spool/sieve/c/chuck/current.bc is up to date
May 13 22:14:14 debian64 cyrus/lmtpunix[19567]: dupelim: eliminated duplicate
message to 7fd93d5b49ad8704 id <1732507.0PFkBQmMn2@debian64> date Wed, 13 May
2020 22:07:15 +0200 (delivery)
May 13 22:14:14 debian64 cyrus/lmtpunix[19567]: USAGE chuck user: 0.006897 sys:
0.017243
May 13 22:14:14 debian64 cyrus/master[19518]: process type:SERVICE
name:lmtpunix path:/usr/lib/cyrus/bin/lmtpd age:0.050s pid:19567 signaled to
death by signal 6 (Aborted)
May 13 22:14:14 debian64 cyrus/master[19518]: service lmtpunix/unix pid 19567
in BUSY state: terminated abnormally

So, lmtp aborted on delivery. But somehow it managed to abort just after the
mails got delivered. This was very weird.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Well I was looking around. I got a error message: "*** invalid %N$ use detected
***" in the dumps
that gave me the right track and I hit "jackpot" and found this issue on github
of the main project:


(I copied the title from it!)

The issue explained it all. And I can confirm that after replacing the
SESSIONID=<%2$s> with SESSIONID=<%s>

---
--- imap/lmtp_err.et2020-05-13 23:17:22.230378471 +0200
+++ imap/lmtp_err.et.orig   2020-05-13 23:16:57.583674949 +0200
@@ -45,7 +45,7 @@ error_table lmtp
 # Enhanced Mail System Status Codes (RFC 3463)

 ec LMTP_OK,
-   "250 2.1.5 Ok SESSIONID=<%2$s>"
+   "250 2.1.5 Ok SESSIONID=<%s>"

 ec LMTP_MAILBOX_ERROR,
"451 4.2.0 %s"
---

LMTP worked as intented (well, apart from that SESSIONID being a bit wrong...).

So, what to do? It seems the -DFORTIFY_SOURCE=2 is set by the build-system or
is there another way?



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, powerpc, mips, arm64

Kernel: Linux 5.7.0-rc2-wt+ (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_DE.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en (charmap=locale: Cannot set LC_MESSAGES to default 
locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages cyrus-common depends on:
ii  adduser3.118
ii  db-upgrade-util5.3.1+nmu1
ii  db-util5.3.1+nmu1
ii  debconf [debconf-2.0]  1.5.74
ii  e2fsprogs  1.45.6-1
ii  exim4-daemon-light [mail-transport-agent]  4.93-16
ii  gawk   1:5.0.1+dfsg-1
ii  init-system-helpers1.57
ii  libc6  2.30-8
ii  libcap21:2.34-1
ii  libclamav9 0.102.2+dfsg-2
ii  libcom-err21.45.6-1
ii  libgcc-s1  10.1.0-1
ii  libical3   3.0.8-1
ii  libicu63   63.2-3
ii  libjansson42.12-1
ii  libkrb5-3  1.17-7
ii  libldap-2.4-2  2.4.50+dfsg-1
ii  libpcre3   2:8.39-12+b1
ii  libpq5 12.2-4
ii  libsasl2-2 2.1.27+dfsg-2
ii  libsasl2-modules   2.1.27+dfsg-2
ii  libsnmp35  5.8+dfsg-2
ii  libsqlite3-0   3.31.1-5
ii  libssl1.1  1.1.1g-1
ii  libstdc++6 10.1.0-1
ii  libuuid1   2.35.1-5
ii  libwrap0

Bug#864529: firmware-amd-graphics: missing firmware for AMD Radeon RX 560,570,580

2017-06-09 Thread Christian Lamparter 
Package: firmware-amd-graphics
Version: 20161130-3
Severity: important
Tags: upstream

Dear Maintainer,

the new AMD Radeon RX 560 is currently missing a important firmware file:
/lib/firmware/amdgpu/polaris11_k_smc.bin (RX 560)
/lib/firmware/amdgpu/polaris10_k_smc.bin (RX 570, RX 580)

This firmware was added to linux-firmware.git back in February 2017:
<https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-
firmware.git/commit/?id=21d7887c63e5d21b4aaa4519e3e5fc058d86de61>
|From 21d7887c63e5d21b4aaa4519e3e5fc058d86de61 Mon Sep 17 00:00:00 2001
|From: Alex Deucher <alexander.deuc...@amd.com>
|Date: Fri, 17 Feb 2017 17:24:28 -0500
|Subject: amdgpu: add smc firmware for new polaris variants
|
|amdgpu: add smc firmware for new polaris variants
|from internal git commit:
|35328ab989a24fa32069bdbbea55f5cbcbdbcec6
|
|Signed-off-by: Alex Deucher <alexander.deuc...@amd.com>
|Signed-off-by: Kyle McMartin <k...@kernel.org>

Adding the firmware file manually into /lib/firmware/amdgpu
and loading amdgpu module does work as expected. The driver loads
and the GFX card has surprisingly good support. (No really!)

Thanks,
Christian Lamparter



-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, powerpc, mips

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

firmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
ii  initramfs-tools  0.130

-- no debconf information

Bug#733129: amavisd-new: add amavis user email alias to /etc/alias

2013-12-25 Thread Christian Lamparter 
Package: amavisd-new
Version: 1:2.7.1-2
Severity: wishlist

Dear Maintainer,

I recently switched to amavisd-new and noticed that the amavis cronjob
tried to sent the following mail to amavis@mydomain:
--- SNIP ---
From: Cron Daemon root@mydomain
Subject: Cron amavis@mydomain test -e /usr/sbin/amavisd-new-cronjob 
/usr/sbin/amavisd-new-cronjob sa-sync

config: created user preferences file: /var/lib/amavis/.spamassassin/user_prefs
--- SNIP ---

I didn't have a mailbox for this account, so the mail got stuck in the MTA
queues.
Since there are n+1 MTA/MDA I think the easiest and most portable solution
would
be: add an alias entry into /etc/aliases. E.g.:

amavis: root

Now the mail gets redirected to root [or postmaster]. which is kind of what
other
programs like logcheck already do. So maybe the debian preinstall code which
is executed during the installation can be copied from there?

Regards,

Christian



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13.0-rc4-wl+ (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

Versions of packages amavisd-new depends on:
ii  adduser 3.113+nmu3
ii  debconf [debconf-2.0]   1.5.52
ii  file1:5.14-2
ii  libarchive-zip-perl 1.30-7
ii  libberkeleydb-perl  0.53-1+b1
ii  libconvert-tnef-perl0.18-1
ii  libconvert-uulib-perl   1:1.4~dfsg-1+b2
pn  libdigest-md5-perl  none
ii  libio-stringy-perl  2.110-5
ii  libmail-dkim-perl   0.40-1
ii  libmailtools-perl   2.12-1
pn  libmime-base64-perl none
ii  libmime-tools-perl  5.505-1
ii  libnet-server-perl  2.007-3
ii  libunix-syslog-perl 1.1-2+b3
ii  pax 1:20120606-2+deb7u1
ii  perl [libtime-hires-perl]   5.18.1-5
ii  perl-modules [libarchive-tar-perl]  5.18.1-5

Versions of packages amavisd-new recommends:
ii  altermime  0.3.10-7
pn  libnet-patricial-perl  none
ii  ripole 0.2.0+20081101.0215-1

Versions of packages amavisd-new suggests:
ii  apt-listchanges  2.85.11
pn  arj  none
pn  cabextract   none
ii  clamav   0.97.8+dfsg-1
ii  clamav-daemon0.97.8+dfsg-1
ii  cpio 2.11+dfsg-1
pn  dspamnone
pn  lha  none
pn  lhasanone
ii  libauthen-sasl-perl  2.1500-1
pn  libdbi-perl  none
ii  libmail-dkim-perl0.40-1
pn  libnet-ldap-perl none
pn  libsnmp-perl none
pn  lzop none
pn  nomarch  none
pn  p7zipnone
pn  rpm  none
ii  spamassassin 3.3.2-7
ii  unrar1:5.0.10-1
pn  unrar-free   none
pn  zoo  none

-- Configuration Files:
/etc/amavis/conf.d/15-content_filter_mode changed [not included]
/etc/amavis/conf.d/20-debian_defaults changed [not included]

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#646083: cryptsetup: cryptroot script fails to print message if crypttries are exceeded

2011-10-21 Thread Christian Lamparter 
Package: cryptsetup
Version: 2:1.3.0-3
Severity: minor
Tags: patch

Dear Maintainer,

While was looking at the cryptroot initramfs-script
and found a minor bug in process.

The message maximum number of tries will never be
printed because the -lt condition in the while loop
will trigger once $count is equal to $crypttries.

while [ $crypttries -le 0 ] || [ $count -lt $crypttries ]; do
count = $(( $count + 1 ))
...

if [ $crypttries -gt ]  [ $count -gt $cryptties ]; then
message maximum number of tries...
return
fi
done

[ A fix should be attached, but it's been a while since
I've used reportbug :D ]

-- Package-specific info:
-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-rc10-wl+ (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages cryptsetup depends on:
ii  debconf [debconf-2.0]  1.5.41 
ii  dmsetup2:1.02.65-1
ii  libc6  2.13-21
ii  libcryptsetup1 2:1.3.0-3  
ii  libpopt0   1.16-1 

cryptsetup recommends no packages.

Versions of packages cryptsetup suggests:
ii  busybox 1:1.18.5-1
ii  dosfstools  3.0.9-1   
ii  initramfs-tools [linux-initramfs-tool]  0.99  
ii  liblocale-gettext-perl  1.05-7
ii  udev172-1 

-- debconf information excluded

-- debsums errors found:
debsums: changed file /usr/share/initramfs-tools/scripts/local-top/cryptroot 
(from cryptsetup package)
^^ obviously, I did that
--- cryptroot.orig	2011-10-21 09:14:13.0 +0200
+++ cryptroot	2011-10-21 09:14:56.0 +0200
@@ -259,11 +259,6 @@ setup_mapping()
 			/bin/sleep 3
 		fi
 
-		if [ $crypttries -gt 0 ]  [ $count -gt $crypttries ]; then
-			message cryptsetup: maximum number of tries exceeded for $crypttarget
-			return 1
-		fi
-
 		if [ -z $cryptkeyscript ]; then
 			cryptkey=Unlocking the disk $cryptsource ($crypttarget)\nEnter passphrase: 
 			if [ -x /bin/plymouth ]  plymouth --ping; then
@@ -319,6 +314,11 @@ setup_mapping()
 		break
 	done
 
+	if [ $crypttries -gt 0 ]  [ $count -eq $crypttries ]; then
+		message cryptsetup: maximum number of tries exceeded for $crypttarget
+		return 1
+	fi
+
 	udev_settle
 	return 0
 }

Bug#562222: init script should depend on local filesystems being mounted

2011-03-19 Thread Christian Lamparter 
Package: ifupdown
Version: 0.6.10
Followup-For: Bug #56

It's been a while since this bug-report was filed. Is there anything
wrong with the provided patch? I found it very useful, since it fixes
a problem I had with multiple auto interface that would not come up
after boot. (Note: ifupdown-clean needs to be fixed as well)

Possible Duplicates:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607713
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344780
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382609
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388814)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418326
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503188
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306224)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329821
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399441
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=427417
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616606

please please please fix this issue.

Thanks,
Christian

---

diff --git a/init.d/ifupdown b/init.d/ifupdown
index a6aab3e..d908d29 100755
--- a/init.d/ifupdown
+++ b/init.d/ifupdown
@@ -1,7 +1,7 @@
 #!/bin/sh -e
 ### BEGIN INIT INFO
 # Provides:  ifupdown
-# Required-Start:ifupdown-clean
+# Required-Start:$local_fs ifupdown-clean
 # Required-Stop: $local_fs
 # Default-Start: S
 # Default-Stop:  0 6
diff --git a/init.d/ifupdown-clean b/init.d/ifupdown-clean
index fa89bc3..286f2d0 100755
--- a/init.d/ifupdown-clean
+++ b/init.d/ifupdown-clean
@@ -1,8 +1,8 @@
 #!/bin/sh
 ### BEGIN INIT INFO
-# Provides:  ifupdown-clean
-# Required-Start:checkroot
-# Required-Stop: 
+# Provides: ifupdown-clean
+# Required-Start:$local_fs checkroot
+# Required-Stop:
 # Default-Start: S
 # Default-Stop:
 # Short-Description: Clean old interface status info during boot.
---

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-wl+ (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages ifupdown depends on:
ii  libc6 2.11.2-13  Embedded GNU C Library: Shared lib
ii  lsb-base  3.2-27 Linux Standard Base 3.2 init scrip
ii  net-tools 1.60-23The NET-3 networking toolkit

ifupdown recommends no packages.

Versions of packages ifupdown suggests:
ii  dhcp3-client 4.1.1-P1-16 ISC DHCP server (transitional pack
ii  iproute  20110107-2  networking and traffic control too
ii  isc-dhcp-client [dhcp3-clien 4.1.1-P1-16 ISC DHCP client
ii  ppp  2.4.5-5 Point-to-Point Protocol (PPP) - da
ii  pump [dhcp-client]   0.8.24-7BOOTP and DHCP client for automati

-- debconf information:
  ifupdown/convert-interfaces: true



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#578979: cryptsetup isLuks does not work for volumes with a non-FIPS hash (e.g.:ripemd160)

2010-04-23 Thread Christian Lamparter 
Package: cryptsetup
Version: 2:1.1.0-2.1
Severity: normal
Tags: squeeze sid patch


cryptsetup isLuks [..] code-path does not initialize gcrypt library properly.

For example: This is luksDump is from a healthy volume,
which was created with ripemd160 as the selected message digest.
# cryptsetup luksDump /dev/loop1
LUKS header information for /dev/loop1

Version:1
Cipher name:serpent
Cipher mode:xts-benbi
Hash spec:  ripemd160 ---
Payload offset: 2056
MK bits:256
MK digest:  47 cd 8a 78 ab [...]
MK salt:d6 a9 81 f2 d7 [...]
MK iterations:  20750
UUID:   e4245[...]

Key Slot 0: ENABLED
Iterations: 83[...]
Salt:   5d [...]
Key material offset:8
AF stripes: 4000
Key Slot 1: DISABLED
[...]

However, for the same volume isLuks failes with

# cryptsetup isLuks /dev/loop1
Requested LUKS hash ripemd160 is not supported.


-

This behavior is actually a feature of libgcrypt.
It prevents damage and misuse of the library.

But in my case (I made the mistake of making
a root partition with ripemd160...) it confused
The initramfs script /scripts/local-top/cryptsetup,
which then tried to call cryptsetup create ...
instead of luksOpen.

-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-2.6.34-rc4-wl root=/dev/mapper/linux2-disc1_crypt ro 
console=ttyS0,115200 console=tty0 hpet=force

-- /etc/crypttab
linux2-disc1_crypt /dev/mapper/linux2-disc1 none luks

-- /etc/fstab
# /etc/fstab: static file system information.
#
# file system mount point   type  
options   dump  pass
/dev/mapper/linux2-disc1_crypt  /   reiserfs
noatime,user_xattr  0   1
proc/proc   proc
defaults0   0
/dev/sda1   /boot   ext2
noatime,nosuid,nodev,noexec 0   1
none_debugfs/sys/kernel/debug   debugfs 
defaults0   0

-- lsmod
Module  Size  Used by
nls_iso8859_1   4473  0 
nls_cp850   5314  0 
vfat8328  0 
fat44631  1 vfat
tcp_diag 895  0 
inet_diag   7293  1 tcp_diag
nvidia  10786745  22 
ppdev   5611  0 
lp  9164  0 
bluetooth  51651  2 
rfkill 16789  2 bluetooth
xt_multiport2266  1 
iptable_filter  1386  1 
ip_tables  14814  1 iptable_filter
x_tables   19492  3 xt_multiport,iptable_filter,ip_tables
pktcdvd24942  1 
cpufreq_conservative 9806  0 
binfmt_misc 6782  1 
deflate 1769  0 
zlib_deflate   18923  1 deflate
ctr 3437  0 
camellia   17980  0 
cast5  15752  0 
des_generic16074  0 
xcbc2367  0 
rmd160  7752  0 
crypto_null 2582  0 
dm_snapshot25924  0 
dm_mirror  11784  0 
dm_region_hash  9698  1 dm_mirror
dm_log  8264  2 dm_mirror,dm_region_hash
fuse   54512  1 
nfsd  262150  13 
exportfs3418  1 nfsd
nfs   249246  0 
lockd  62571  2 nfsd,nfs
nfs_acl 2277  2 nfsd,nfs
auth_rpcgss37647  2 nfsd,nfs
sunrpc193752  14 nfsd,nfs,lockd,nfs_acl,auth_rpcgss
i2c_dev 4497  0 
cpufreq_userspace   2560  0 
powernow_k813359  1 
hwmon_vid   2026  0 
firewire_sbp2  12036  0 
snd_emu10k1_synth   4932  0 
snd_emux_synth 29089  1 snd_emu10k1_synth
snd_seq_virmidi 3996  1 snd_emux_synth
snd_seq_midi_emul   4927  1 snd_emux_synth
snd_emu10k1   129919  3 snd_emu10k1_synth
snd_ac97_codec110598  1 snd_emu10k1
ac97_bus1242  1 snd_ac97_codec
snd_pcm_oss30195  0 
snd_mixer_oss  12678  1 snd_pcm_oss
snd_pcm67238  4 snd_emu10k1,snd_ac97_codec,snd_pcm_oss
snd_page_alloc  7252  2 snd_emu10k1,snd_pcm
snd_util_mem3290  2 snd_emux_synth,snd_emu10k1
snd_hwdep   5642  2 snd_emux_synth,snd_emu10k1
snd_seq_dummy   1542  0 
snd_seq_oss24254  0 
snd_seq_midi4604  0 
snd_rawmidi18819  3 snd_seq_virmidi,snd_emu10k1,snd_seq_midi
snd_seq_midi_event  6067  3 snd_seq_virmidi,snd_seq_oss,snd_seq_midi
snd_seq45917  9 
snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
snd_timer  18457  3 snd_emu10k1,snd_pcm,snd_seq
snd_seq_device  5762  8