Bug#1071385: wmenu 0.1.8 available

[Hannes von Haugwitz]

Package: wmenu
Version: 0.1.7-1
Severity: normal

Hello,

wmenu version [0.1.8] is available, please consider packaging it.

It provides a new wmenu-run executable and fixes some bugs.

Best regards

Hannes

[0.1.8] 
https://lists.sr.ht/~adnano/wmenu-announce/%3cd11c10674z0o.xctdywu4x...@maolood.com%3E

Bug#1070805: aide fails to concurrently read extended attributes

[Hannes von Haugwitz]

Package: aide
Version: 0.18.3-1+deb12u2
Severity: important
Tags: upstream patch

Hello,

aide 0.18 (<= 0.18.7) fails to concurrently read extended attributes
(xattrs) due to variables erroneously shared between worker threads.

This has been fixed upstream in AIDE [v0.18.8] via [732e7e2e] (and
[3831c717] in the default branch).

Best regards

Hannes

[v0.18.8]  https://github.com/aide/aide/releases/tag/v0.18.8
[732e7e2e] 
https://github.com/aide/aide/commit/732e7e2e7dc91bb614c508518c0abc6cab85565c
[3831c717] 
https://github.com/aide/aide/commit/93831c717eaaa19d58da12ebeb28607cc6d43116

Bug#1060381: tomcat10: catalina.out is not recreated after deletion

[Daniel von Obernitz]

Package: tomcat10
Version: 10.1.6-1+deb12u1
Severity: normal
X-Debbugs-Cc: t...@security.debian.org

Dear Maintainer,

when you stop tomcat10.service and delete the /var/log/tomcat10/catalina.out, 
the file will not be recreated after the next tomcat10.service start.


I tested the following scenarios:

Install tomcat10 package - stop tomcat10.service - delete catalina.out - 
restart tomcat10.service = catalina.out is NOT created anymore.

Purge tomcat10 package and all dependencies - reinstall tomcat10 package = 
catalina.out is present again.


When the rsyslog package is also installed, the catalina.out is created again 
if rsyslog.service and tomcat10.service are both restarted. But since we are 
not using rsyslog anymore I have not found a way to recreate the catalina.out 
yet.

Best regards
Daniel


-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages tomcat10 depends on:
ii  systemd [systemd-tmpfiles]  252.17-1~deb12u1
ii  sysvinit-utils [lsb-base]   3.06-4
ii  tomcat10-common 10.1.6-1+deb12u1
ii  ucf 3.0043+nmu1

Versions of packages tomcat10 recommends:
ii  libtcnative-1  1.2.35-1

Versions of packages tomcat10 suggests:
pn  tomcat10-admin 
pn  tomcat10-docs  
pn  tomcat10-examples  
pn  tomcat10-user  

-- no debconf information

Bug#710970: Please include extended dh_ucf script

[Hannes von Haugwitz]

Hello,

On Sun, Aug 14, 2022 at 01:16:15PM +0200, Niels Thykier wrote:
> Yes, I would still be interested in the improvements if you still feel it
> would be worth your time and effort to do them. :)

Originally I created the bug/patch to ease the maintenance of the
numerous rule files in the aide package. Meanwhile Marc (one of the aide
maintainers) has developed some ucf helper functions for the same
purpose. These functions are now provided by the ucf package
[ucf_helper_functions] and are used directly in the aide-common
postinst file (see [aide-common.postinst]).

Principally I'm still willing to update the dh_ucf patch, but I think it
does not make sense to provide the same functionality in two different
packages (debhelper and ucf).

How do we want to proceed now?

@Marc @Manoj What is your opinion as the maintainers of the other
involved packages?

Best regards

Hannes

[ucf_helper_functions] 
https://salsa.debian.org/srivasta/ucf/-/blob/master/ucf_helper_functions.sh
[aide-common.postinst[ 
https://salsa.debian.org/debian/aide/-/blob/master/debian/aide-common.postinst

Bug#1057309: src:haskell-pandoc binary package names conflict with src:pandoc binary packages

[Hannes von Haugwitz]

Source: haskell-pandoc
Version: 3.0.1-2
Severity: serious
Control: affects -1 src:pandoc

Hi,

The binary packages provided by src:haskell-pandoc conflict with the
binary packages of src:pandoc; violationg Debian Policy 3.1 ("Every
package must have a name that’s unique within the Debian archive.").

This also makes the pandoc binary package from src:pandoc uninstallable
in unstable:


# apt policy pandoc pandoc-data
pandoc:
  Installed: (none)
  Candidate: 2.17.1.1-3
  Version table:
 2.17.1.1-3 500
500 mirror+file:/etc/apt/mirrors/debian.list unstable/main amd64 
Packages
pandoc-data:
  Installed: (none)
  Candidate: 3.0.1-2
  Version table:
 3.0.1-2 500
500 mirror+file:/etc/apt/mirrors/debian.list unstable/main amd64 
Packages
 2.17.1.1-3 500
500 mirror+file:/etc/apt/mirrors/debian.list unstable/main amd64 
Packages

# apt install pandoc
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 pandoc : Depends: pandoc-data (< 2.17.1.1-3.~) but 3.0.1-2 is to be installed
E: Unable to correct problems, you have held broken packages.


As a workaround you can specify the matching version of pandoc-data:

# apt install pandoc pandoc-data=2.17.1.1-3

Best regards

Hannes

Bug#1038779: fail2ban: Filter for invalid pubkey authentication does not match

[Daniel von Obernitz]

Hi Sylvestre,

I just have submitted the PR.

Best regards
Daniel


On Wed, 21 Jun 2023 14:55:22 +0200 Sylvestre Ledru 
 wrote:

Hello

could you please submit a PR on 
https://salsa.debian.org/python-team/packages/fail2ban/ ?


thanks

Sylvestre




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1038779: fail2ban: Filter for invalid pubkey authentication does not match

[Daniel von Obernitz]

Package: fail2ban
Version: 0.11.2-2
Severity: important
Tags: patch

Dear Maintainer,

fail2ban did not block logins using an invalid pubkey.

I checked the sshd filter and the default regex does not match with the actual 
line when trying to login via ssh with an invalid pubkey.

Attached you'll find the updated filter for "cmnfailre-failed-pub-invalid", 
after that update the filter works as expected.

This issue concerns Debian 11 and Debian 12 as well.

Best regards
Daniel


-- System Information:
Debian Release: 11.7
  APT prefers oldstable-updates
  APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 
'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages fail2ban depends on:
ii  lsb-base  11.1.0
ii  python3   3.9.2-3

Versions of packages fail2ban recommends:
ii  nftables   0.9.8-3.1+deb11u1
ii  python3-pyinotify  0.9.6-1.3
ii  python3-systemd234-3+b4
pn  whois  

Versions of packages fail2ban suggests:
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-2
pn  monit
ii  rsyslog [system-log-daemon]  8.2102.0-2+deb11u1
pn  sqlite3  

-- Configuration Files:
/etc/fail2ban/filter.d/sshd.conf changed:
[INCLUDES]
before = common.conf
[DEFAULT]
_daemon = sshd
__pref = (?:(?:error|fatal): (?:PAM: )?)?
__suff = (?: (?:port \d+|on \S+|\[preauth\])){0,3}\s*
__on_port_opt = (?: (?:port \d+|on \S+)){0,2}
__authng_user = (?: (?:invalid|authenticating) user \S+|.*?)?
__alg_match = (?:(?:\w+ (?!found\b)){0,2}\w+)
__pam_auth = pam_[a-z]+
[Definition]
prefregex = 
^%(__prefix_line)s%(__pref)s.+$
cmnfailre = ^[aA]uthentication (?:failure|error|failed) for .* 
from ( via \S+)?%(__suff)s$
^User not known to the underlying authentication module for 
.* from %(__suff)s$
>
^Failed  for (?Pinvalid user 
)?(?P\S+)|(?(cond_inv)(?:(?! from ).)*?|[^:]+) from 
%(__on_port_opt)s(?: ssh\d*)?(?(cond_user): |(?:(?:(?! from ).)*)$)
^ROOT LOGIN REFUSED FROM 
^[iI](?:llegal|nvalid) user .*? from 
%(__suff)s$
^User \S+|.*? from  not allowed because not 
listed in AllowUsers%(__suff)s$
^User \S+|.*? from  not allowed because 
listed in DenyUsers%(__suff)s$
^User \S+|.*? from  not allowed because not 
in any group%(__suff)s$
^refused connect from \S+ \(\)
^Received disconnect from 
%(__on_port_opt)s:\s*3: .*: Auth fail%(__suff)s$
^User \S+|.*? from  not allowed because a 
group is listed in DenyGroups%(__suff)s$
^User \S+|.*? from  not allowed because none 
of user's groups are listed in AllowGroups%(__suff)s$
^%(__pam_auth)s\(sshd:auth\):\s+authentication 
failure;(?:\s+(?:(?:logname|e?uid|tty)=\S*)){0,4}\s+ruser=\S*\s+rhost=(?:\s+user=\S*)?%(__suff)s$
^maximum authentication attempts exceeded for .* 
from %(__on_port_opt)s(?: ssh\d*)?%(__suff)s$
^User \S+|.*? not allowed because account is 
locked%(__suff)s
^Disconnecting(?: from)?(?: 
(?:invalid|authenticating)) user \S+ 
%(__on_port_opt)s:\s*Change of username or service not 
allowed:\s*.*\[preauth\]\s*$
^Disconnecting: Too many authentication failures(?: for 
\S+|.*?)?%(__suff)s$
^Received 
disconnect from 
%(__on_port_opt)s:\s*11:
-other>
^Accepted \w+ 
for \S+ from (?:\s|$)
cmnfailed-any = \S+
cmnfailed-ignore = \b(?!publickey)\S+
cmnfailed-invalid = 
cmnfailed-nofail = (?:publickey|\S+)
cmnfailed = >
mdre-normal =
mdre-normal-other = ^(Connection 
closed|Disconnected) (?:by|from)%(__authng_user)s 
(?:%(__suff)s|\s*)$
mdre-ddos = ^Did not receive identification string from 
^kex_exchange_identification: (?:[Cc]lient sent invalid protocol 
identifier|[Cc]onnection closed by remote host)
^Bad protocol version identification '.*' from 
^SSH: Server;Ltype: 
(?:Authname|Version|Kex);Remote: -\d+;[A-Z]\w+:
^Read from socket failed: Connection 
reset by peer
mdre-ddos-other = ^(Connection 
(?:closed|reset)|Disconnected) (?:by|from)%(__authng_user)s 
%(__on_port_opt)s\s+\[preauth\]\s*$
mdre-extra = ^Received disconnect from 
%(__on_port_opt)s:\s*14: No(?: supported)? authentication methods 
available
^Unable to negotiate with %(__on_port_opt)s: no matching 
<__alg_match> found.
^Unable to negotiate a <__alg_match>
^no matching <__alg_match> found:
mdre-extra-other = ^Disconnected(?: from)?(?: 
(?:invalid|authenticating)) user \S+|.*? 
%(__on_port_opt)s \[preauth\]\s*$
mdre-aggressive = %(mdre-ddos)s
  %(mdre-extra)s
mdre-aggressive-other = %(mdre-ddos-other)s
publickey = nofail
cmnfailre-failed-pub-invalid = ^Failed 

Bug#1034816: aide aborts with error "realloc: failed to allocate memory", exit code 22

[Hannes von Haugwitz]

tags 1034816 - moreinfo unreproducible
thanks

Hi Thomas,

On Thu, May 11, 2023 at 05:52:01PM +0200, Thomas Dorner wrote:
> I narrowed it further down with some more fprintfs.  The problem is not
> in do_md.c but the call in hsymlnk in gen_list.c.

Yes, yesterday I was able to reproduce your issue.

Please try the patch available upstream[0] and report back if it fixes
the memory allocation errors.

Thanks for debugging.

Best regards

Hannes

[0] https://github.com/aide/aide/commit/61778cdb42b88ab9591e43bf8de39693d545a278

Bug#1034816: aide aborts with error "realloc: failed to allocate memory", exit code 22

[Hannes von Haugwitz]

Hello Thomas,

On Wed, Apr 26, 2023 at 07:46:40AM +0200, Thomas Dorner wrote:
> > How many files are in the AIDE database on a successful run? Does this
> > number significantly differ when the aide check fails?
> 
> You mean the /var/lib/aide/aide.db?
> # zcat /var/lib/aide/aide.db | wc
>  755240 21146627 442199792

This shouldn't be large enough to fill up 32 GB of memory.

Can you try to reproduce the failure and verify that the memory is
actually used up by the aide process?

> > Is 0.18.2-1 the only version you experience this behaviour or does
> > this error also occur with an older version?
> 
> I've never encountered this before, but I did not work with the
> specific directory tree parallel to the AIDE run for at least 3 weeks
> before the this one.

Additionally can you try to directly call aide limited to the specific
directory (see --limit option).

Best regards

hannes

Bug#1034816: aide aborts with error "realloc: failed to allocate memory", exit code 22

[Hannes von Haugwitz]

Hi Thomas,

On Tue, Apr 25, 2023 at 10:54:39AM +0200, Thomas Dorner wrote:
> The last two daily aide runs on my desktop machine failed with an error
> 22.

How many files are in the AIDE database on a successful run? Does this
number significantly differ when the aide check fails?

> Version 0.18.2-1 had been installed on 2023-04-21, so it did run OK at
> least two times.  It also run OK after a manual "systemctl start
> dailyaidecheck" in a terminal window yesterday.  This did not work today
> though.

Is 0.18.2-1 the only version you experience this behaviour or does this
error also occur with an older version?

> The last warnings like the 4 last ones above all come from a test
> directory used by my current project.  The files and directories there
> have been deleted and recreated several times during the aide run.

Independently of the issue above, it might make sense to exclude this
directory.

Best regards

Hannes

Bug#1031355: setxattr does not set owner to root when file is unknown

[Sebastian von Ohr]

Package: fakeroot
Version: 1.30.1-1.1

The default behavior for fakeroot is to show unknown files owned by root. When 
setting extended attributes on a file the owner stored by fakeroot is the real 
owner. The behavior can be observed when running the following commands inside 
fakeroot:

touch testfile
ls -l # shows owner as root
attr -s test -V x testfile
ls -l # shows real owner

I've looked at the code and there is some logic to set the owner to root if the 
uid/gid from the buffer is -1. I don't see where this value is ever sent by the 
client. Instead, I propose to always set the owner to root, just like in 
process_chmod. See attached patch.


setxattr_unknown_is_root.patch
Description: setxattr_unknown_is_root.patch

Bug#908060: fakeroot: Extracting files with set file capabilites using tar results invalid mode

[Sebastian von Ohr]

I've also come across this bug. This seems to be a problem in the mknod wrapper 
function. When using tar with --xattrs it creates files using mknod, but 
without specifying a file type. An empty file type should be equivalent to 
S_IFREG. Fakeroot doesn't handle this and just stores the exact mode requested, 
resulting in the "invalid mode" error.

I've attached a patch which seems to solve the problem. This could also be 
handled in process_mknod in faked, but I choose libfakeroot side for the patch.


mknod_empty_ftype.patch
Description: mknod_empty_ftype.patch

Bug#1029675: faked daemon exits on SIGWINCH signal

[Sebastian von Ohr]

Package: fakeroot
Version: 1.30.1-1.1

The faked daemon installs signal handlers by looping from 1 to NSIG 
(faked.c:1481) with some special handling for some signals. However, for most 
signals the `cleanup` function is registered as handler.

Specifically, with the SIGWINCH signal this can lead to unexpected exiting of 
faked. To reproduce this, start the daemon as follows and resize the terminal 
window:

# faked-sysv --foreground --debug
using 1983184094 as msg key
msg_key=1983184094
1983184094:95
FAKEROOT: msg=2, key=1983184094
fakeroot: clearing up message queues and semaphores, signal=28

The expected behavior is that the faked daemon does not exit on SIGWINCH (28). 
Maybe there are also other signals that should be ignored by default. Note that 
this issue has been previously discovered 
(https://github.com/moby/moby/issues/27195) but apparently has not been 
reported here.

Bug#1024342: /etc/X11/Xsession.d/90x11-common_ssh-agent: ssh-agent missing on second log-in

[Martin von Gagern]

Package: x11-common
Version: 1:7.7+23
Severity: normal
File: /etc/X11/Xsession.d/90x11-common_ssh-agent

Dear Maintainer,

When logging out of Cinnamon and back in, I don't have ssh-agent
running any more.

Several current desktop environments persist environment variables
across logins, so that on a logout followed by a login these variables
are available. I have found code for doing so in Gnome [1] and
Cinnamon [2]. The X11 ssh-agent session startup script checks [ -z
"$SSH_AUTH_SOCK" ] as a precondition for launching ssh-agent [3]. So
when taken together, the first login will launch ssh-agent, then save
environment variables to dbus. The next session will be initialized
with these environment variables (presumably something systemd does,
haven't checked) and will therefore skip launching ssh-agent, despite
the fact that the previous agent got terminated at shutdown of the
first session.

One possible solution to this would be to replace [ -z
"$SSH_AUTH_SOCK" ] with [ ! -S "$SSH_AUTH_SOCK" ], i.e. to check that
the environment variable is not only set but actually refers to a
socket. That way, when ssh-agent for the first session terminates, the
socket will get closed and the next session will launch its own agent
despite the fact that the environment variable got persisted.

An alternative might be to also inspect SSH_AGENT_PID, and when it's
set and doesn't refer to a running process then that could also be
taken as in indication that a new agent is needed. I can't think of a
reasonable scenario that would warrant such a complex approach; I'd
think that the solution in the previous paragraph should be enough,
but if I'm missing some legitimate use case where the environment
variable would be set before the agent gets launched, then the PID
might offer a viable and even safer alternative.

Personally I'm not a fan of environment variables getting persisted in
this fashion, but given that it is default behavior in multiple
desktop environments, and probably there for a reason, I think it
makes sense to cater for it in the script. The benefits should
outweigh potential drawbacks in weird corner cases.

My current workaround, based on [4], is having this in my ~/.xsessionrc:

if [ -n "$SSH_AUTH_SOCK" ] && [ ! -S "$SSH_AUTH_SOCK" ]; then
  unset SSH_AUTH_SOCK
  unset SSH_AGENT_PID
fi

[1] 
https://salsa.debian.org/gnome-team/gnome-session/-/blob/81c88fa3485949f8c7ea12e68d07e8060d368e79/gnome-session/gsm-util.c#L544-707
[2] 
https://salsa.debian.org/cinnamon-team/cinnamon-session/-/blob/255fd6600dfafe131ca3247d641fdd64098f7f47/cinnamon-session/csm-util.c#L569-715
[3] 
https://salsa.debian.org/xorg-team/xorg/-/blob/d6af3f0a48de41f74069a8befc4fe9ca0fcd0118/debian/local/Xsession.d/90x11-common_ssh-agent#L10
[4] https://utcc.utoronto.ca/~cks/space/blog/linux/Fedora26CinnamonSSHAgent

-- System Information:
Debian Release: rodete
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages x11-common depends on:
ii  lsb-base  11.2

x11-common recommends no packages.

x11-common suggests no packages.

-- no debconf information

Bug#1022543: Lower intel-rapl-mmio power limit on ThinkPad T490 since 5.18.0-3-amd64

[Hannes von Haugwitz]

Package: src:linux
Version: 6.0.3-1
Severity: important

Hello,

starting with 5.18.0-3-amd64 I experience significant performance loss
(clock speed slows down to 400 MHz) on higher CPU usage.

After checking for differences I figured out that the long-term intel rapl mmio
power limit now defaults to 5W (AC mode) / 10W (battery mode) compared
to 25W with 5.18.0-2-amd64:

AC mode:
$ uname -a
Linux sulfur 6.0.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.3-1 
(2022-10-21) x86_64 GNU/Linux
$ cat /sys/class/power_supply/AC/online
1
$ cat 
/sys/class/powercap/intel-rapl-mmio/intel-rapl-mmio\:0/constraint_0_power_limit_uw
500

Battery mode:
$ uname -a
Linux sulfur 6.0.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.3-1 
(2022-10-21) x86_64 GNU/Linux
$ cat /sys/class/power_supply/AC/online
0
$ cat 
/sys/class/powercap/intel-rapl-mmio/intel-rapl-mmio\:0/constraint_0_power_limit_uw
1000

Note that the limit in battery mode is actually higher than in AC mode.

Booting into 5.18.0-2-amd64 the default power limit is 25W:

AC mode:
$ uname -a
Linux sulfur 5.18.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.5-1 
(2022-06-16) x86_64 GNU/Linux
$ cat /sys/class/power_supply/AC/online
1
$ cat 
/sys/class/powercap/intel-rapl-mmio/intel-rapl-mmio\:0/constraint_0_power_limit_uw
2500

Battery mode:
$ uname -a
Linux sulfur 5.18.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.5-1 
(2022-06-16) x86_64 GNU/Linux
$ cat /sys/class/power_supply/AC/online
0
$ cat 
/sys/class/powercap/intel-rapl-mmio/intel-rapl-mmio\:0/constraint_0_power_limit_uw
2500

I can manually set the power limit to 2500 (fixing the performance
issues), but the embedded controller changes it back to 500 after
some time.

Please let me know if I can provide any further information.

Best regards

Hannes

-- Package-specific info:
** Version:
Linux version 6.0.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-7) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC 
Debian 6.0.3-1 (2022-10-21)

** Command line:
BOOT_IMAGE=/vmlinuz-6.0.0-2-amd64 root=/dev/mapper/sulfur--vg-root ro 
apparmor=0 quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 20N2CTO1WW
product_version: ThinkPad T490
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N2IET99W (1.77 )
board_vendor: LENOVO
board_name: 20N2CTO1WW
board_version: SDK0R32862 WIN

** Loaded modules:
snd_seq_dummy
snd_hrtimer
snd_seq
snd_seq_device
ctr
ccm
xt_CHECKSUM
nft_chain_nat
xt_MASQUERADE
nf_nat
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
xt_tcpudp
nft_compat
bridge
stp
llc
nf_tables
libcrc32c
rfcomm
cmac
algif_hash
algif_skcipher
af_alg
bnep
nfnetlink
nls_ascii
nls_cp437
vfat
fat
btusb
btrtl
btbcm
btintel
btmtk
bluetooth
uvcvideo
videobuf2_vmalloc
jitterentropy_rng
videobuf2_memops
videobuf2_v4l2
videobuf2_common
sha512_ssse3
sha512_generic
videodev
drbg
ansi_cprng
mc
ecdh_generic
ecc
intel_pmc_core_pltdrv
intel_pmc_core
snd_sof_pci_intel_cnl
snd_sof_intel_hda_common
soundwire_intel
soundwire_generic_allocation
soundwire_cadence
snd_sof_intel_hda
snd_sof_pci
snd_sof_xtensa_dsp
snd_sof
snd_sof_utils
soundwire_bus
snd_soc_skl
x86_pkg_temp_thermal
snd_soc_hdac_hda
intel_powerclamp
coretemp
snd_hda_ext_core
snd_soc_sst_ipc
snd_hda_codec_hdmi
snd_soc_sst_dsp
iTCO_wdt
kvm_intel
snd_soc_acpi_intel_match
rtsx_pci_sdmmc
intel_pmc_bxt
iTCO_vendor_support
snd_soc_acpi
iwlmvm
ee1004
watchdog
mei_hdcp
mmc_core
snd_ctl_led
intel_rapl_msr
snd_soc_core
wmi_bmof
snd_hda_codec_realtek
intel_wmi_thunderbolt
kvm
snd_compress
mac80211
snd_hda_codec_generic
irqbypass
snd_hda_intel
crc32_pclmul
libarc4
snd_intel_dspcfg
snd_intel_sdw_acpi
ghash_clmulni_intel
snd_hda_codec
iwlwifi
rapl
e1000e
snd_hda_core
intel_cstate
snd_hwdep
xhci_pci
snd_pcm
intel_uncore
xhci_hcd
pcspkr
joydev
ptp
i2c_i801
thinkpad_acpi
efi_pstore
pps_core
snd_timer
i2c_smbus
cfg80211
thunderbolt
mei_me
processor_thermal_device_pci_legacy
usbcore
nvram
processor_thermal_device
rtsx_pci
platform_profile
mei
processor_thermal_rfim
ucsi_acpi
ledtrig_audio
processor_thermal_mbox
typec_ucsi
intel_lpss_pci
processor_thermal_rapl
intel_lpss
snd
idma64
intel_rapl_common
usb_common
roles
intel_pch_thermal
soundcore
intel_soc_dts_iosf
typec
wmi
rfkill
battery
int3403_thermal
int340x_thermal_zone
ac
int3400_thermal
button
acpi_thermal_rel
acpi_pad
msr
parport_pc
ppdev
lp
parport
fuse
configfs
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
dm_crypt
dm_mod
i915
i2c_algo_bit
drm_buddy
drm_display_helper
drm_kms_helper
cec
rc_core
crc32c_intel
ttm
nvme
nvme_core
drm
aesni_intel
t10_pi
psmouse
crypto_simd
cryptd
crc64_rocksoft
evdev
crc64
crc_t10dif
serio_raw
crct10dif_generic
crct10dif_pclmul
crct10dif_common
video

-- System Information:
Debian Release: bookworm/sid
  APT prefers 

Bug#1019977: Please add pipewire-pulse as alternative dependency

[Hannes von Haugwitz]

Package: python3-pulsectl
Version: 22.3.2-1
Severity: wishlist

Hi,

pipewire-pulse conflicts on pulseaudio since pipewire/0.3.58-1 (see also
#1013276); hence python3-pulsectl can't no longer be installed alongside
pipewire. Please consider adding pipewire-pulse as alternative dependency.

Best regards

Hannes

Bug#1018730: lvm2: Initramfs does not activate root LVs if VG is incomplete since 2.03.15 or 2.03.16, boot failure

[Martin von Gagern]

Similar here. Had been getting error messages about missing PV during boot
for a while, but since everything worked fine once booted I didn't bother
to resolve that. Now I started getting boot errors instead. Turns out the
initramfs was missing a module (pata_atiixp) needed for the controller for
that PV. Working this out required time, and until that point I could only
boot previous kernel & initramfs (which required navigating grub menu so no
headless boots) and I didn't dare upgrade anything.

https://salsa.debian.org/lvm-team/lvm2/-/commit/2340adad4b3875331be1ba7abba881cc1b6e6738
for 2.03.15-1 appears to be the relevant commit here causing this change in
behavior. Probably has something to do with the --autoactivation flag which
I don't see documented on
https://manpages.debian.org/testing/lvm2/vgchange.8.en.html. It probably
makes sense for udev to wait for all PVs before activation *if* the PV can
be expected to turn up eventually. During boot, falling back to degraded
activation after some timeout might be beneficial, in particular to resolve
situations where the extra PVs need later boot steps to become available.

The man page describes --activationmode but according to comments in my
(unedited) /etc/lvm/lvm.conf that setting is "degraded" by default and
should thus be able to work with absent PVs. Particularly since I currently
don't even have any LVs on the absent PV. But perhaps --autoactivation
trumps that default? If you would like to get more data on why things
behave differently, I can probably restore a reproducing setup easily
enough and can then execute commands in the initramfs console to debug
further.

Steps that helped me fix the problem:
1. "lvm pvs" from the initramfs fallback prompt to see the missing PV
2. "lvm pvs" when booted from previous initramfs to see what device that
is, sdc1 in my case
3. "udevadm info -a -n /dev/sdc1 | grep -E 'looking|DRIVER'" to find the
driver needed for it
4. "$EDITOR /etc/initramfs-tools/modules" to add the module there
5. "update-initramfs -u -k 5.18.0-4-amd64" to build a new initramfs with
that module included

Bug#710970: [debhelper-devel] Bug#710970: Please include extended dh_ucf script

[Hannes von Haugwitz]

Hi Niels,

On Wed, Apr 12, 2017 at 10:49:00AM +, Niels Thykier wrote:
> Let me know when you have an updated patch. :)

Sorry for the long delay.

Looks like I still owe you an updated patch.

Are you still interested the enhancements?

Best regards

Hannes

Bug#1011957: aideinit fails in amanda-server processing

[Hannes von Haugwitz]

On Tue, May 31, 2022 at 09:36:43PM +0200, Marc Haber wrote:
> Hannes, do you want me to commit the fix or do you prefer doing it
> yourself?

Done via 778c4a0

Best regards

Hannes

Bug#1011957: aideinit fails in amanda-server processing

[Hannes von Haugwitz]

On Tue, May 31, 2022 at 12:29:04PM +0200, Marc Haber wrote:
> how about
> 
>cat --squeeze-blank disklist | while read ...
>done
> 
> ?

`--squeeze-blank` does only suppress repeated empty lines, (not
all blank lines) and does not suppress comment lines.

Best regards

Hannes

Bug#1011957: aideinit fails in amanda-server processing

[Hannes von Haugwitz]

On Mon, May 30, 2022 at 09:46:30AM -0500, Barry Trent wrote:
> Applied the patch and added some blank lines back to the disklist. Still
> doesn't work.

Argh, I overlooked the missing -E flag for grep. Please try again.

diff --git a/debian/aide.conf.d/31_aide_amanda-server 
b/debian/aide.conf.d/31_aide_amanda-server
index 5750779..7604e0f 100755
--- a/debian/aide.conf.d/31_aide_amanda-server
+++ b/debian/aide.conf.d/31_aide_amanda-server
@@ -66,7 +66,7 @@ for configfile in $(find /etc/amanda -name amanda.conf ! 
-path '/etc/amanda/temp
 printf "@@define AMANDA_INDEXDIR %s\\n" "${AMANDA_INDEXDIR}"
 if [ -f "disklist" ]; then
   while read -r host dev rest; do
-if echo "${host}" | grep -q '^\\(#.*\\)\\?$'; then continue; fi
+if echo "${host}" | grep -Eq '^(#.*)?$'; then continue; fi
 dev="$(echo "${dev}" | sed 's|[/:]|_|g;s|\\"||g')"
if ! skip_multiline_dle; then
 printf 
"!/@@{AMANDA_INDEXDIR}/%s/%s/@@{YEAR4D}[0-9]{4}_[0123]\\.gz$ f\\n" "${host}" 
"${dev}"

Best regards

Hannes

Bug#1011957: aideinit fails in amanda-server processing

[Hannes von Haugwitz]

Hello Barry,

On Sat, May 28, 2022 at 11:34:44AM -0500, Barry Trent wrote:
> Yes! Removing all blank (and "#" comment) lines from disklist solved the
> problem on 3 different machines.
> 
> So you've found the issue but, of course, blanks and comments are valid in
> the disklist and are even present in the disklist installed as a sample with
> amanda-server in DailySet1. I had to remove the DailySet1 which was still
> present on one machine to get aideinit to complete without the error.

Can you please apply the following patch and report back if it solves your
issue?

diff --git a/debian/aide.conf.d/31_aide_amanda-server 
b/debian/aide.conf.d/31_aide_amanda-server
index 5750779..78424eb 100755
--- a/debian/aide.conf.d/31_aide_amanda-server
+++ b/debian/aide.conf.d/31_aide_amanda-server
@@ -66,7 +66,7 @@ for configfile in $(find /etc/amanda -name amanda.conf ! 
-path '/etc/amanda/temp
 printf "@@define AMANDA_INDEXDIR %s\\n" "${AMANDA_INDEXDIR}"
 if [ -f "disklist" ]; then
   while read -r host dev rest; do
-if echo "${host}" | grep -q '^\\(#.*\\)\\?$'; then continue; fi
+if echo "${host}" | grep -q '^(#.*)?$'; then continue; fi
 dev="$(echo "${dev}" | sed 's|[/:]|_|g;s|\\"||g')"
if ! skip_multiline_dle; then
 printf 
"!/@@{AMANDA_INDEXDIR}/%s/%s/@@{YEAR4D}[0-9]{4}_[0123]\\.gz$ f\\n" "${host}" 
"${dev}"

Best regards

Hannes

Bug#1011957: aideinit fails in amanda-server processing

[Hannes von Haugwitz]

Hi Barry,

On Fri, May 27, 2022 at 04:29:54PM -0500, Barry Trent wrote:
> *** disklist
> zmoby.atcorp.com  /   comp-root-tar
> 
> symposium.atcorp.com  /   comp-root-tar
> symposium.atcorp.com  /bbbcomp-root-tar
> moby.atcorp.com   /   comp-root-tar
> coelacanth.atcorp.com /   comp-root-tar
> sawfish.atcorp.com  /   comp-root-tar
> sawfish.atcorp.com  /varcomp-root-tar

Is there an empty line in the disklist file? If so, can you please
remove this line and try again?

Best regards

Hannes

Bug#819295: Please add 'flags_array' struct to public library interface

[Hannes von Haugwitz]

Hello,

Sorry for my late reply...

On Sat, May 06, 2017 at 11:39:56AM -0400, Theodore Ts'o wrote:
> Sorry, no.  Just to be clear, is what you want is to be able to
> convert flag value to a string (instead of printing it to stdio FILE
> handle)?  Or to go the other way --- e.g., given a charafter flag such
> as 's', convert it to EXT2_SECRM_FL?
>
> I don't want to expose the array as a public interface, since that
> ties my hands as to the implementation.  I'm willing to expose new
> function interfaces, though.  But there you need to be a lot more
> explicit what you want, and of course, patches will make it much more
> likely that the request will be satisified.  :-)

That makes sense.

I would need the following functions:

unsigned long get_flag(char)
- return flag for given character
- return 0 for invalid characters
- example: get_flag('s') returns EXT2_SECRM_FL

char get_char(unsigned long flag)
- return character for given flag
- return '?' for invalid flags
- example: get_flag(EXT2_SECRM_FL) returns 's'

unsigned long get_readonly_flags()
- return all read only flags (so I can provide an option to ignore
  changes of read only flags)

AIDE has an option to ignore changes of given flags and marks then with
a colon in the report (e.g. `:ae---` for ignored
immutable flag); hence I cannot use the print_flags library function.

To iterate over the available flags the following function would help:

unsigned long get_available_flags()
* return all available flags

Unfortunately the bit order of the available flags does not match the
order returned by print_flags (sucSiadAmEIjtDTeVCxNPF vs
suSDiadAcEjItTeCxFNPVm). A function that returns the flag for a given
output position could solve that:

unsigned long output_get_flag(int)
- return flag for character position
- return 0 for positions > num_flags
- example: output_get_flag(4) returns EXT2_IMMUTABLE_FL

Best regards

Hannes

Bug#1008277: aideinit stops with error in rule

[Lilo von Hanffstengel]

Hi,

> Can you break the file again and try changing the
>
> cat ${SOURCESLIST} /dev/null
>
> against
>
> awk '{print}' ${SOURCESLIST} /dev/null
>
> please?

This line in 31_aide_apt works for me! 

awk '{print}' ${SOURCESLIST} /dev/null | sed 's/ #.*$//' | while read -r line; 
do

aideinit runs without any issues now.

Nice fix!
Thanks.

-- 
Greetings
Lilo von Hanffstengel

Bug#1008277: aideinit stops with error in rule

[Lilo von Hanffstengel]

Hi,

> I guess that the deb file containing something like
> deb-src http://deb.debian.org/debian bullseye-updates main contrib
> non-free is missing its trailing newline.
>
> Is that possible?

Oh, yes! 
I checked list now with od and saw a \n is missing in last 
deb-src line, wierd.   

After adding a new line with vim the aideinit runs file :-)

Perhaps the aide config rules need some polish to be more robust.

-- 
Greetings
Lilo von Hanffstengel

Bug#1008277: aideinit stops with error in rule

[Lilo von Hanffstengel]

Hi,

> On Wed, Mar 30, 2022 at 09:51:19AM +0200, Lilo von Hanffstengel wrote:
>> > On Sun, Mar 27, 2022 at 01:03:30PM +0200, Marc Haber wrote:
>> >> On Fri, Mar 25, 2022 at 09:36:12PM +0100, Gwen wrote:
>> >> >   ERROR: /etc/aide/aide.conf.d/31_aide_apt (stdout):105:70: error in 
>> >> > rule 
>> >> > '/var/lib/apt/lists/deb\.debian\.org_debian_dists_bullseye-updates_http://autoinstall.plesk.com/PMM_0.1.11_source_Sources(\.diff_Index)?$':
>> >> >  invalid double slash (line: 
>> >> > '/var/lib/apt/lists/deb\\.debian\\.org_debian_dists_bullseye-updates_http://autoinstall.plesk.com/PMM_0.1.11_source_Sources(\\.diff_Index)?$
>> >> >  f VarFile')
>> >> 
>> >> This looks like an error parsing a sources.list line that contains an
>> >> external repository. Can you show all sources.list lines that contain
>> >> "autoinstall.plesk.com"?
>> >
>> > May I remind?
>> 
>> Attached.

> And there is no deb-src line for plesk anywhere?!?

No, the plesk lists have no deb-src lines.


-- 
Greetings
Lilo von Hanffstengel

Bug#1008277: aideinit stops with error in rule

[Lilo von Hanffstengel]

/(daily_lock|extended_states)$ f VarFile
/var/lib/apt$ d VarDir

/var/lib/systemd/timers/stamp-apt-daily(-upgrade)?\\.timer$ f VarFile

/var/log/apt/(term|history)\\.log$ f Log
/var/log/apt/(term|history)\\.log\\.1\\.@@{LOGEXT}$ f LoSerMemberLog
/var/log/apt/(term|history)\\.log\\.([2-9]|1[0-1])\\.@@{LOGEXT}$ f SerMemberLog
/var/log/apt/(term|history)\\.log\\.12\\.@@{LOGEXT}$ f HiSerMemberLog
/var/log/apt/eipp\\.log\\.xz$ f VarFile
/var/log/apt$ d VarDir

/var/backups/apt\\.extended_states\\.0$ f LowLog
/var/backups/apt\\.extended_states\\.1\\.@@{LOGEXT}$ f LoSerMemberLog
/var/backups/apt\\.extended_states\\.[2345]\\.@@{LOGEXT}$ f SerMemberLog
/var/backups/apt\\.extended_states\\.6\\.@@{LOGEXT}$ f HiSerMemberLog






-- 
Greetings
Lilo von Hanffstengel

Bug#1008277: aideinit stops with error in rule

[Lilo von Hanffstengel]

Hi,

> On Sun, Mar 27, 2022 at 01:03:30PM +0200, Marc Haber wrote:
>> On Fri, Mar 25, 2022 at 09:36:12PM +0100, Gwen wrote:
>> >   ERROR: /etc/aide/aide.conf.d/31_aide_apt (stdout):105:70: error in rule 
>> > '/var/lib/apt/lists/deb\.debian\.org_debian_dists_bullseye-updates_http://autoinstall.plesk.com/PMM_0.1.11_source_Sources(\.diff_Index)?$':
>> >  invalid double slash (line: 
>> > '/var/lib/apt/lists/deb\\.debian\\.org_debian_dists_bullseye-updates_http://autoinstall.plesk.com/PMM_0.1.11_source_Sources(\\.diff_Index)?$
>> >  f VarFile')
>> 
>> This looks like an error parsing a sources.list line that contains an
>> external repository. Can you show all sources.list lines that contain
>> "autoinstall.plesk.com"?
>
> May I remind?

Attached.

-- 
Greetings
Lilo von Hanffstengel


plesk.list
Description: Binary data


plesk-ext-panel-migrator.list
Description: Binary data

Bug#1008277: Acknowledgement (aideinit stops with error in rule)

[Lilo von Hanffstengel]

Hi,

> Ah, now I see. This is a duplicate of #994168. Try the following patch:

> --- etc/aide/aide.conf.d/31_aide_munin-nodes2022-01-16 13:07:29.0 
> +0100
> +++ /etc/aide/aide.conf.d/31_aide_munin-nodes   2021-12-31 22:10:09.905341513 
> +0100
> @@ -17,7 +17,7 @@
> DOMAIN=$(escape_dots "${HOST#*.}")
> DHOST=$(escape_dots "${HOST}")
>  
> -   printf
> "/var/cache/munin/www/%s/(index\\.html|%s/[-_[:alnum:]]+\\.(png|html))$
> f VarFile" "${DOMAIN}\\n" "${DHOST}"
> -   printf "/var/lib/munin/%s/%s-.*\\.rrd$ f VarFile" "${DOMAIN}" 
> "${DHOST}\\n"
> +   printf
> "/var/cache/munin/www/%s/(index\\.html|%s/[-_[:alnum:]]+\\.(png|html))$
> f VarFile\\n" "${DOMAIN}" "${DHOST}"
> +   printf "/var/lib/munin/%s/%s-.*\\.rrd$ f VarFile\\n" "${DOMAIN}" 
> "${DHOST}"
> printf
> "/@@{RUN}/munin/munin-(update|datafile|%s-%s|limits)\\.lock$ f
> VarFile\\n" "${DOMAIN}" "${DHOST}"
>  done

> This was fixed in aide 0.17.3-5 which didn't make it into bullseye.

Thanks, that patch fixes errors with 31_aide_munin-nodes.


-- 
Greetings
Lilo von Hanffstengel

Bug#1008277: Acknowledgement (aideinit stops with error in rule)

[Lilo von Hanffstengel]

Hi,

>> > What does this call print on your machine?
>> 
>> Which call?
>
> /etc/aide/aide.conf.d/31_aide_munin-nodes

~# /etc/aide/aide.conf.d/31_aide_munin-nodes
/var/cache/munin/www/localdomain\n/(index\.html|localhost\\.localdomain/[-_[:alnum:]]+\.(png|html))$
 f VarFile/var/lib/munin/localdomain/localhost\\.localdomain\n-.*\.rrd$ f 
VarFile/@@{RUN}/munin/munin-(update|datafile|localdomain-localhost\\.localdomain|limits)\.lock$
 f VarFile

> I would like to see the original. What you sent me is with CRLF
> lineending. The rule should (must!) work with unix style line ending,
> but somehow an extra \n is written to the aide rule.

See attached tarball.


-- 
Greetings
Lilo von Hanffstengel

munin-aide-configs.tar.gz
Description: GNU Zip compressed data

Bug#1008277: aideinit stops with error in rule

[Lilo von Hanffstengel]

Hi,

>> deb [arch=amd64] http://autoinstall.plesk.com/PMM_0.1.11 bullseye all
>
> I guess that the apt aide rule code doesn't handle the [arch=amd64] part
> correctly yet. That's a relatively new notation. Can you try removing it
> just to check?

Removing that in apt list file did not solve the issue.

 # aideinit -f -y
Running aide --init...
  ERROR: /etc/aide/aide.conf.d/31_aide_apt (stdout):103:70: error in rule 
'/var/lib/apt/lists/deb\.debian\.org_debian_dists_bullseye-updates_http://autoinstall.plesk.com/PMM_0.1.11_source_Sources(\.diff_Index)?$':
 invalid double slash (line: 
'/var/lib/apt/lists/deb\\.debian\\.org_debian_dists_bullseye-updates_http://autoinstall.plesk.com/PMM_0.1.11_source_Sources(\\.diff_Index)?$
 f VarFile') 
AIDE --init return code 17


-- 
Greetings

Bug#1008277: Acknowledgement (aideinit stops with error in rule)

[Lilo von Hanffstengel]

Good day Herr Haber,

am Sonntag, 27. März 2022 um 13:28 schrieben Sie:

> On Sat, Mar 26, 2022 at 03:51:00PM +0100, Lilo von Hanffstengel wrote:
>>  aideinit -f -y
>> Running aide --init...
>>   ERROR: /etc/aide/aide.conf.d/31_aide_munin-nodes (stdout):1: unexpected 
>> character: '/' (line: 
>> '/var/cache/munin/www/localdomain\n/(index\.html|localhost\\.localdomain/[-_[:alnum:]]+\.(png|html))$
>>  f VarFile/var/lib/munin/localdomain/localhost\\.localdomain\n-.*\.rrd$ f 
>> VarFile/@@{RUN}/munin/munin-(update|datafile|localdomain-localhost\\.localdomain|limits)\.lock$
>>  f VarFile')
>
> Hi,
>
> can I please see your /etc/munin/munin.conf?

Sorry, the previous sent munin.conf was from my other server.

Here is the one whose err message was reported to tracker:

# Example configuration file for Munin, generated by 'make build'

# The next three variables specifies where the location of the RRD
# databases, the HTML output, logs and the lock/pid files.  They all
# must be writable by the user running munin-cron.  They are all
# defaulted to the values you see here.
#
#dbdir  /var/lib/munin
#htmldir /var/cache/munin/www
#logdir /var/log/munin
#rundir  /var/run/munin

# Where to look for the HTML templates
#
#tmpldir/etc/munin/templates

# Where to look for the static www files
#
#staticdir /etc/munin/static

# temporary cgi files are here. note that it has to be writable by
# the cgi user (usually nobody or httpd).
#
# cgitmpdir /var/lib/munin/cgi-tmp

# (Exactly one) directory to include all files from.
includedir /etc/munin/munin-conf.d

# You can choose the time reference for "DERIVE" like graphs, and show
# "per minute", "per hour" values instead of the default "per second"
#
#graph_period second

# Graphics files are generated either via cron or by a CGI process.
# See http://munin-monitoring.org/wiki/CgiHowto2 for more
# documentation.
# Since 2.0, munin-graph has been rewritten to use the cgi code.
# It is single threaded *by design* now.
#
#graph_strategy cron

# munin-cgi-graph is invoked by the web server up to very many times at the
# same time.  This is not optimal since it results in high CPU and memory
# consumption to the degree that the system can thrash.  Again the default is
# 6.  Most likely the optimal number for max_cgi_graph_jobs is the same as
# max_graph_jobs.
#
#munin_cgi_graph_jobs 6

# If the automatic CGI url is wrong for your system override it here:
#
#cgiurl_graph /munin-cgi/munin-cgi-graph

# max_size_x and max_size_y are the max size of images in pixel.
# Default is 4000. Do not make it too large otherwise RRD might use all
# RAM to generate the images.
#
#max_size_x 4000
#max_size_y 4000

# HTML files are normally generated by munin-html, no matter if the
# files are used or not. You can change this to on-demand generation
# by following the instructions in http://munin-monitoring.org/wiki/CgiHowto2
#
# Notes:
# - moving to CGI for HTML means you cannot have graph generated by cron.
# - cgi html has some bugs, mostly you still have to launch munin-html by hand
#
#html_strategy cron

# munin-update runs in parallel.
#
# The default max number of processes is 16, and is probably ok for you.
#
# If set too high, it might hit some process/ram/filedesc limits.
# If set too low, munin-update might take more than 5 min.
#
# If you want munin-update to not be parallel set it to 0.
#
#max_processes 16

# RRD updates are per default, performed directly on the rrd files.
# To reduce IO and enable the use of the rrdcached, uncomment it and set it to
# the location of the socket that rrdcached uses.
#
#rrdcached_socket /var/run/rrdcached.sock

# Drop someju...@fnord.comm and anotheru...@blibb.comm an email everytime
# something changes (OK -> WARNING, CRITICAL -> OK, etc)
#contact.someuser.command mail -s "Munin ${var:worst}: 
${var:group}::${var:host}::${var:plugin}" someju...@fnord.comm
#contact.anotheruser.command mail -s "Munin ${var:worst}: 
${var:group}::${var:host}::${var:plugin}" anotheru...@blibb.comm
#
# For those with Nagios, the following might come in handy. In addition,
# the services must be defined in the Nagios server as well.
#contact.nagios.command /usr/bin/send_nsca nagios.host.comm -c /etc/nsca.conf

# The maximum time the munin-update may take to get updates from all nodes,
# this might be interesting when using munin-async in case of large 
transactions and/or backlog.
# When using the munin protocol to connect to a node, then this value shouldn't 
be set higher than 240.
# In case it's higher, gaps might be seen in the graphs.
timeout_fetch_all_nodes 240

# The maximum amount of time in seconds we may work on 1 node.
# The value will be limited with timeout_fetch_all_nodes.
timeout_fetch_one_node 180

# a simple host tree
[localhost.localdomain]
address 127.0.0.1
use_node_name yes

#
# A more complex example of a host t

Bug#1008277: Acknowledgement (aideinit stops with error in rule)

[Lilo von Hanffstengel]

Similar issue after installing munin on Debian 11.2.

Error shows in shell:

 aideinit -f -y
Running aide --init...
  ERROR: /etc/aide/aide.conf.d/31_aide_munin-nodes (stdout):1: unexpected 
character: '/' (line: 
'/var/cache/munin/www/localdomain\n/(index\.html|localhost\\.localdomain/[-_[:alnum:]]+\.(png|html))$
 f VarFile/var/lib/munin/localdomain/localhost\\.localdomain\n-.*\.rrd$ f 
VarFile/@@{RUN}/munin/munin-(update|datafile|localdomain-localhost\\.localdomain|limits)\.lock$
 f VarFile')
AIDE --init return code 17

- - - 

munin  2.0.67-3
aide   0.17.3-4+deb11u1
aide-common0.17.3-4+deb11u1

Bug#981446: RFA: logcheck -- mails anomalies in the system logfiles to the administrator

[Hannes von Haugwitz]

Hi,

On Mon, Dec 06, 2021 at 02:13:30PM +, Jose M Calhariz wrote:
> Sorry for no reply until now.  I was busy with issues on work and
> personal life.  I am happy to adopt logcheck.  I am not a user of irc,
> there was any discussion on IRC that I should know?

No, there were no discussions on #logcheck yet.

Please let me know if you have any questions. Just contact me via mail
or preferably via IRC on #logcheck.

Best regards

Hannes

Bug#981446: RFA: logcheck -- mails anomalies in the system logfiles to the administrator

[Hannes von Haugwitz]

On Sun, Oct 10, 2021 at 06:39:27PM +0200, Hannes von Haugwitz wrote:
> @Jose Do you still plan to adopt logcheck? You might want to collaborate
> with Richard and Charles to maintain the package all together.

@Jose Can you please report back if you still want to maintain logcheck?

Best regards

Hannes

Bug#992927: mutt: Mutt 2.1.2 is available, fixing a potential data-loss IMAP bug

[Hannes von Haugwitz]

Hello,

Is there any progress with this bug?

Best regards

Hannes

Bug#981446: RFA: logcheck -- mails anomalies in the system logfiles to the administrator

[Hannes von Haugwitz]

Hi,

On Fri, Sep 24, 2021 at 02:42:07PM +0530, Charles wrote:
> I would like to adopt the logcheck package

On Thu, Sep 23, 2021 at 12:10:16PM +0100, R Lewis wrote:
> Very keen to keep logcheck in the distribution and looking to get involved
> in Debian (spare time only).
>
> happy to submit patches etc but how should that be done - to the bts or via
> salsa? will anyone review and merge things?

@Jose Do you still plan to adopt logcheck? You might want to collaborate
with Richard and Charles to maintain the package all together.

> Is there an email list to enable collaboration and discussion?

You can use the #logcheck channel on the OFTC IRC network to collaborate
and discuss logcheck with some users and previous maintainers.

Best regards

Hannes

Bug#994876: maven: New upstream version 3.8.2 available

[Christian von Kietzell]

Package: maven
Version: 3.6.3-5
Severity: wishlist
X-Debbugs-Cc: chris.debb...@vonkietzell.de

Dear Maintainer,

version 3.8.1 was released in April and 3.8.2 has been available since early
August. Now that Bullseye is released, would it be possible to package the new
version?


Kind regards
Chris

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

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

Versions of packages maven depends on:
ii  default-jre-headless [java7-runtime-headless] 2:1.11-72
ii  libjansi-java 1.18-1
ii  libmaven3-core-java   3.6.3-5
ii  libwagon-file-java3.3.4-1
ii  libwagon-http-shaded-java 3.3.4-1
ii  openjdk-11-jre-headless [java7-runtime-headless]  11.0.12+7-2

maven recommends no packages.

maven suggests no packages.

-- no debconf information

Bug#981446: Possible adoption of logcheck

[Hannes von Haugwitz]

On Fri, Sep 03, 2021 at 01:46:23PM +0100, Jose M Calhariz wrote:
> For now my question is:  Who is the upstream that you are using?

There is no upstream, since logcheck is a native Debian package (see
debian/copyright for details[0]).

Best regards

Hannes

[0] https://salsa.debian.org/debian/logcheck/-/blob/master/debian/copyright

Bug#981446: Possible adoption of logcheck

[Hannes von Haugwitz]

Hi Jose,

On Mon, Aug 30, 2021 at 07:58:21PM +0100, Jose M Calhariz wrote:
> I am a user of logckeck as I use on all my machines that I sysadmin
> and I maintain some packages on Debian like for example at and amanda.
> 
> As now I would like to offer my help to package and fix logcheck as a
> learning experience for a possibility in the future to be the
> maintainer of logcheck.

This is great news!

The logcheck VCS repo is in the `debian` group on salsa.debina.org[0];
so (as DD) you can just start to work on the package.

Please let me know if you have any questions or want some review.

Best regards

Hannes

[0] https://salsa.debian.org/debian/logcheck/

Bug#770171: sshd jail fails when system solely relies on systemd journal for logging

[von Obernitz, Daniel]

Hi,

in Debian 11 with f2b version 0.11.2-2 the issue with "journalmatch" seems to 
be fixed, but now the filter is wrong.

/etc/fail2ban/filter.d/sshd.conf

# consider failed publickey for invalid users only:

cmnfailre-failed-pub-invalid = ^Failed publickey for invalid user 
(?P\S+)|(?:(?! from ).)*? from 
%(__on_port_opt)s(?: ssh\d*)?(?(cond_user): |(?:(?:(?! from ).)*)$)

The log output in systemd does not match, the regex has to be changed to 
something like:

cmnfailre-failed-pub-invalid = ^Failed publickey for 
(?P\S+)|(?:(?! from ).)*? from 
%(__on_port_opt)s(?: ssh\d*)?(?(cond_user): |(?:(?:(?! from ).)*)$)


Daniel

smime.p7s
Description: S/MIME cryptographic signature

Bug#964934:

[Eike von Seggern]

Hi,

bug #955180 seems to be fixed in unstable accorging to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955180

Best,
Eike

Bug#982243: Tested fix from libsane

[Kai von Krbek]

Hello,

I tested the suggested the aforementioned fix in
https://gitlab.com/sane-project/backends/-/issues/137
and the Scanner works again. I would ask to merge the fix or pull 1.0.32 
from upstream that it will work for other People as well.


I hope that this will help.

Bug#982243: sane-backends: Canoscan N650U does not scan on Testing

[Kai von Krbek]

Source: sane-backends
Version: 1.0.31-4
Severity: normal
Tags: upstream

Dear Maintainer,

I was recently trying to use my old and trusty Scanner CanoScan N650U on 
my new) Debian Testing Computer (with a AMD B450 chipset). It was

as a USB-Device but did not scan. The scanner is not detected in
simple-scan or gscan2pdf. (The scanner does however still works on all 
ports (USB2/USB3) on my Thinkpad X220 on Debian 10.)


This bug (regression?) might have to do with the fixed upstream bug
https://gitlab.com/sane-project/backends/-/issues/137
which is fixed in 1.0.32.

Sadly, I don't know how to do a temporary package replacement to check 
if the upstream version does fix the problem. If you need for 
information, please contact me.



-- further terminal output
$ scanimage -L

No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).

$ sane-find-scanner
found USB scanner (vendor=0x04a9, product=0x2206) at libusb:001:010



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

Kernel: Linux 5.10.0-2-amd64 (SMP w/12 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Bug#981446: RFA: logcheck -- mails anomalies in the system logfiles to the administrator

[Hannes von Haugwitz]

Package: wnpp
Severity: normal

I would like to put the logcheck package up for adoption. I haven't been
using the package for years. If no one speaks up, I eventually will move
on with orphaning the package.

Feel free to contact me with any questions.

The package description is:
 Logcheck helps spot problems and security violations in your logfiles
 automatically and will send the results to you in e-mail.
 .
 Logcheck was part of the Abacus Project of security tools, but this
 version has been rewritten.

Best regards

Hannes

Bug#912555: reassign 912555 to clamav-freshclam

[Hannes von Haugwitz]

reassign 912555 clamav-freshclam 
thanks

Hi,

'ignore.d.server/clamav-freshclam' is part of the clamav-freshclam
package. Hence I reassign this bug.

Best regards

Hannes

Bug#912550: reassign 912550 to courier-imap

[Hannes von Haugwitz]

reassign 912550 courier-imap
thanks

Hi,

'ignore.d.server/courier-imap' is part of the courier-imap package.
Hence I reassign this bug.

Best regards

Hannes

Bug#973591: logcheck-database: rsyslogd update rule

[Hannes von Haugwitz]

reassign 973591 rsyslog 
forcemerge 927771 973591
thanks

Hi,

'ignore.d.server/rsyslog' is part of the rsyslog package.

This issue has been reported in #927771 and fixed rsyslog/8.1905.0-3.

Best regards

Hannes

Bug#978448: Static linking fails with undefined reference to `audit_strsplit_r'

[Hannes von Haugwitz]

Package: libaudit-dev
Version: 1:3.0-1
Severity: normal
Control: affects aide
Control: block 978245 -1

Dear Maintainer,

static linking fails with libaudit-dev 1:3.0-1, due to
"undefined reference to `audit_strsplit_r'".

Minimal example:

$ cat main.c
#include 
#include 

int main() {
audit_log_user_message(0, AUDIT_USER_LOGIN, "test", NULL, NULL, NULL, 0);
return 0;
}

$ gcc -static -o /tmp/main main.c -laudit -lcap-ng
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libcap-ng.a(cap-ng.o):
 in function `capng_change_id':
(.text+0x18df): warning: Using 'initgroups' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libaudit.a(libaudit.o):
 in function `audit_rule_fieldpair_data':
(.text+0x2324): warning: Using 'getgrnam' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: (.text+0x2988): warning: Using 'getpwnam' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libcap-ng.a(cap-ng.o):
 in function `capng_change_id':
(.text+0x18c3): warning: Using 'getpwuid' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libaudit.a(audit_logging.o):
 in function `_resolve_addr.constprop.0':
(.text+0x246): warning: Using 'getaddrinfo' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libaudit.a(libaudit.o):
 in function `load_libaudit_config.constprop.0':
(.text+0x23a): undefined reference to `audit_strsplit_r'
/usr/bin/ld: (.text+0x25a): undefined reference to `audit_strsplit_r'
/usr/bin/ld: (.text+0x280): undefined reference to `audit_strsplit_r'
/usr/bin/ld: (.text+0x298): undefined reference to `audit_strsplit_r'
/usr/bin/ld: /tmp/main: hidden symbol `audit_strsplit_r' isn't defined
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

Best regards

Hannes

Bug#951192: trac: patch german l10n

[Christian von Roques]

The attached patch fixes the problem for me.
It fixes the fuzzy translations and removes the fuzzy tags.
diff -x .git -x .svn -x '.hg*' -wurd a/trac/locale/de/LC_MESSAGES/messages-js.po b/trac/locale/de/LC_MESSAGES/messages-js.po
--- a/trac/locale/de/LC_MESSAGES/messages-js.po	2018-07-29 20:16:17.0 +0200
+++ b/trac/locale/de/LC_MESSAGES/messages-js.po	2020-10-27 15:33:48.848624701 +0100
@@ -2,7 +2,6 @@
 # Copyright (C) 2017 Edgewall Software
 # This file is distributed under the same license as the Trac project.
 #
-#, fuzzy
 msgid ""
 msgstr ""
 "Project-Id-Version: Trac 1.2\n"
diff -x .git -x .svn -x '.hg*' -wurd a/trac/locale/de/LC_MESSAGES/messages.po b/trac/locale/de/LC_MESSAGES/messages.po
--- a/trac/locale/de/LC_MESSAGES/messages.po	2018-07-29 20:16:17.0 +0200
+++ b/trac/locale/de/LC_MESSAGES/messages.po	2020-10-27 16:08:14.139233091 +0100
@@ -2,7 +2,6 @@
 # Copyright (C) 2017 Edgewall Software
 # This file is distributed under the same license as the Trac project.
 #
-#, fuzzy
 msgid ""
 msgstr ""
 "Project-Id-Version: Trac 1.2\n"
@@ -231,11 +230,11 @@
 msgstr "Interner Fehler"
 
 #: tracopt/versioncontrol/git/git_fs.py:498
-#, fuzzy, python-format
+#, python-format
 msgid ""
 "%(name)s does not appear to be a Git repository. See the log for more "
 "information."
-msgstr "Es scheint, dass %(path)s kein Git-Repository ist."
+msgstr "%(name)s scheint kein Git-Repository zu sein. Schauen Sie ins Log für nähere Informationen."
 
 #: tracopt/versioncontrol/git/git_fs.py:523
 msgid "Unsupported \"Show only adds and deletes\""
@@ -686,7 +685,7 @@
 "eine gültige Trac-Umgebung verweisen."
 
 #: trac/env.py:947
-#, fuzzy, python-format
+#, python-format
 msgid ""
 "The Trac Environment needs to be upgraded.\n"
 "\n"
@@ -694,7 +693,7 @@
 msgstr ""
 "Die Trac-Umgebung muss aktualisiert werden.\n"
 "\n"
-"Führen Sie \"trac-admin %(path)s upgrade\" aus"
+"Führen Sie \"trac-admin \"%(path)s\" upgrade\" aus"
 
 #: trac/env.py:1002
 #, python-format
@@ -786,7 +785,7 @@
 "manuell."
 
 #: trac/env.py:1134
-#, fuzzy, python-format
+#, python-format
 msgid ""
 "Upgrade done.\n"
 "\n"
@@ -798,7 +797,7 @@
 "\n"
 "Sie können die Trac-Dokumentation jetzt aktualisieren, indem Sie\n"
 "\n"
-"  trac-admin %(path)s wiki upgrade\n"
+"  trac-admin \"%(path)s\" wiki upgrade\n"
 "\n"
 "ausführen."
 
@@ -931,7 +930,7 @@
 msgstr "Fehler: %(msg)s"
 
 #: trac/admin/console.py:136
-#, fuzzy, python-format
+#, python-format
 msgid ""
 "Welcome to trac-admin %(version)s\n"
 "Interactive Trac administration console.\n"
@@ -942,7 +941,7 @@
 msgstr ""
 "Willkommen bei trac-admin %(version)s\n"
 "Interaktive Trac Administrations-Konsole\n"
-"Copyright (c) 2003-2013 Edgewall Software\n"
+"Copyright (c) %(year)s Edgewall Software\n"
 "\n"
 "Geben Sie '?' oder 'help' für Hilfe zu den Kommandos ein.\n"
 ""
@@ -958,7 +957,7 @@
 msgstr "Vervollständigungs-Fehler: %(err)s"
 
 #: trac/admin/console.py:288
-#, fuzzy, python-format
+#, python-format
 msgid ""
 "The Trac Environment needs to be upgraded. Run:\n"
 "\n"
@@ -966,7 +965,9 @@
 msgstr ""
 "Die Trac-Umgebung muss aktualisiert werden.\n"
 "\n"
-"Führen Sie \"trac-admin %(path)s upgrade\" aus"
+"Führen Sie das folgende aus:\n"
+"\n"
+"  trac-admin \"%(path)s\" upgrade"
 
 #: trac/admin/console.py:323
 #, python-format
@@ -2014,9 +2015,9 @@
 msgstr "Länge des Headers ist zu gering"
 
 #: trac/notification/mail.py:163
-#, fuzzy, python-format
+#, python-format
 msgid "Unknown hash type '%(type)s'"
-msgstr "Unbekannte Protokollierungs-Methode %(type)s"
+msgstr "Unbekannte Hash-art '%(type)s'"
 
 #: trac/notification/mail.py:509
 #, python-format
@@ -2579,12 +2580,12 @@
 "[1:http://trac.edgewall.org/];
 
 #: trac/templates/about.html:46
-#, fuzzy, python-format
+#, python-format
 msgid ""
 "Copyright © %(year)s\n"
 "[1:Edgewall Software]"
 msgstr ""
-"Copyright © 2003–2016\n"
+"Copyright © %(year)s\n"
 "[1:Edgewall Software]"
 
 #: trac/templates/attach_file_form.html:24
@@ -5719,9 +5720,9 @@
 msgstr[1] "%(num)s Revisions gecachet."
 
 #: trac/versioncontrol/admin.py:152
-#, fuzzy, python-format
+#, python-format
 msgid "%(reponame)s is not a cached repository."
-msgstr "'%(name)s' ist kein Verzeichnis"
+msgstr "%(reponame)s ist kein gecachetes Repository."
 
 #: trac/versioncontrol/admin.py:154
 msgid "Done."
@@ -6443,11 +6444,11 @@
 msgstr "verschoben"
 
 #: trac/versioncontrol/templates/changeset.html:227
-#, fuzzy, python-format
+#, python-format
 msgid ""
 "[1:Changeset view not shown], since the total size (%(size)s) exceeds "
 "%(max_size)s"
-msgstr "[1:HTML-Vorschau nicht verfügbar], da die Datei größer ist als %(size)s."
+msgstr "[1:Änderungen nicht angezeit], weil deren Grösse (%(size)s) mehr als %(max_size)s ist."
 
 #: trac/versioncontrol/templates/changeset.html:238
 #, python-format
@@ -7374,9 +7375,9 @@
 msgstr "%(target)s in %(name)s"
 
 #: trac/wiki/formatter.py:807
-#, fuzzy, python-format
+#, python-format
 msgid "Macro 

Bug#962451: auditd: Timeout during first start when auditd is installed

[von Obernitz, Daniel]

Dear maintainer,

I can confirm this bug and want to add, that the timouts also happen randomly 
at restarts of the service.

Best regards
Daniel

smime.p7s
Description: S/MIME cryptographic signature

Bug#947813: SIGSEGV resulting from mesa dri2_add_config dealing poorly with invalid attrib

[Martin von Gagern]

My issue appears to be largely due to a version mismatch, and I have
been able to resolve this.

I had tried to get a specific version from unstable to test a fix for
a different bug, but apparently I misunderstood how pinning works and
got updates to mesa packages from the unstable release even after the
version for which I intended this. Once I downgraded mesa packages to
testing version, I was able to start X again.

I'll leave it to you whether you believe this kind of issue is worth
addressing at the distro level (perhaps via more strict version
dependencies?) or forwarding to the upstream maintainers (so that
unexpected behavior from a module library gets detected in a nicer
fashion than by crashing the X server). If you decide to just close
this bug, that's fine with me, too. In that case sorry for the noise.

$ cat /etc/apt/preferences.d/mesa.pref
Explanation: test fix for #933906
Package: *mesa*
Pin: release a=unstable
Version: 19.1.4-1
Pin-Priority: 600

$ dpkg -l '*mesa*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion  Architecture Description
+++-===---=>
ii  libegl-mesa0:amd64  19.2.6-1 amd64free
implementation of the EGL API -- Mesa vendor library
ii  libegl-mesa0-dbgsym:amd64   19.2.6-1 amd64debug
symbols for libegl-mesa0
ii  libegl1-mesa:amd64  19.3.1-3 amd64
transitional dummy package
ii  libgl1-mesa-dri:amd64   19.3.1-3 amd64free
implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-dri-dbgsym:amd6419.3.1-3 amd64debug
symbols for libgl1-mesa-dri
un  libgl1-mesa-glx   (no
description available)
un  libgl1-mesa-swx11 (no
description available)
ii  libglapi-mesa:amd64 19.3.1-3 amd64free
implementation of the GL API -- shared library
ii  libglapi-mesa-dbgsym:amd64  19.3.1-3 amd64debug
symbols for libglapi-mesa
un  libgles2-mesa (no
description available)
ii  libglu1-mesa:amd64  9.0.1-1  amd64Mesa
OpenGL utility library (GLU)
ii  libglx-mesa0:amd64  19.3.1-3 amd64free
implementation of the OpenGL API -- GLX vendor libra>
un  libwayland-egl1-mesa  (no
description available)
un  mesa-opencl-icd   (no
description available)
un  mesa-utils(no
description available)
ii  mesa-va-drivers:amd64   19.3.1-3 amd64Mesa
VA-API video acceleration drivers
ii  mesa-vdpau-drivers:amd6419.3.1-3 amd64Mesa
VDPAU video acceleration drivers
ii  mesa-vdpau-drivers-dbgsym:amd64 19.3.1-3 amd64debug
symbols for mesa-vdpau-drivers
ii  mesa-vulkan-drivers:amd64   19.3.1-3 amd64Mesa
Vulkan graphics drivers
un  mesag3(no
description available)
un  xlibmesa3 (no
description available)

Bug#947813: SIGSEGV resulting from mesa dri2_add_config dealing poorly with invalid attrib

[Martin von Gagern]

Package: libegl-mesa0
Version: 19.2.6-1

It seems dri2_add_config is encountering some invalid values causing
memory corruption and subsequent SIGSEGV at X server startup.

The stack trace written to the Xorg log isn't too useful, so I ran X
under gdb with debug symbols installed, and copied relevant portions
below. The way I read the results from that, for i==24 I get
attrib==__DRI_ATTRIB_MAX(=50). So dri2_add_config will enter the
default case in egl_dri2.c:319, call the inlined _eglSetConfigKey for
some invalid key for which _eglOffsetOfConfig returns its default of
-1 (as seen in %rdx). The assertion of a positive offset apparently is
disabled in my build. This clobbers some bytes of the display pointer
in the base data structure, which will lead to invalid access later
on, e.g. during _eglValidateConfig.

I haven't been able to work out where the invalid attrib is coming
from. I don't know where dri2_dpy->core->indexConfigAttrib is
implemented.

(gdb) break dri2_add_config
Breakpoint 1 at 0x7fffecce8a40: file
../src/egl/drivers/dri2/egl_dri2.c, line 221.
⋮
Thread 1 "Xorg" hit Breakpoint 1, dri2_add_config
(disp=disp@entry=0x55891220, dri_config=0x5585ab90,
id=id@entry=1, surface_type=surface_type@entry=4,
attr_list=attr_list@entry=0x7fffe2e4,
rgba_masks=rgba_masks@entry=0x0) at ../src/egl/drivers/dri2/egl_dri2.c:221
221 ../src/egl/drivers/dri2/egl_dri2.c: No such file or directory.
⋮ [step past _eglInitConfig call]
(gdb) watch base.Display
Hardware watchpoint 2: base.Display
(gdb) c
Continuing.

Thread 1 "Xorg" hit Hardware watchpoint 2: base.Display

Old value = (_EGLDisplay *) 0x55891220
New value = (_EGLDisplay *) 0x5500
dri2_add_config (disp=disp@entry=0x55891220,
dri_config=0x5585ab90, id=id@entry=1,
surface_type=surface_type@entry=4,
attr_list=attr_list@entry=0x7fffe2e4,
rgba_masks=rgba_masks@entry=0x0)
at ../src/egl/drivers/dri2/egl_dri2.c:239
239 in ../src/egl/drivers/dri2/egl_dri2.c
(gdb) bt
surface_type=surface_type@entry=4,
attr_list=attr_list@entry=0x7fffe2e4,
rgba_masks=rgba_masks@entry=0x0)
at ../src/egl/drivers/dri2/egl_dri2.c:239
#1  0x7fffeccef239 in drm_add_configs_for_visuals
(drv=0x7fffe370, disp=0x55891220)
at ../src/egl/drivers/dri2/platform_drm.c:640
#2  dri2_initialize_drm (drv=drv@entry=0x55891d00,
disp=disp@entry=0x55891220)
at ../src/egl/drivers/dri2/platform_drm.c:761
#3  0x7fffecce894b in dri2_initialize (disp=0x55891220,
drv=0x55891d00)
at ../src/egl/drivers/dri2/egl_dri2.c:911
#4  dri2_initialize (drv=0x55891d00, disp=0x55891220) at
../src/egl/drivers/dri2/egl_dri2.c:876
#5  0x7fffecce4b9d in _eglMatchAndInitialize
(disp=disp@entry=0x55891220) at ../src/egl/main/egldriver.c:75
#6  0x7fffecce4be6 in _eglMatchDriver
(disp=disp@entry=0x55891220) at ../src/egl/main/egldriver.c:96
#7  0x7fffeccdf188 in eglInitialize (dpy=0x55891220,
major=0x0, minor=0x0) at ../src/egl/main/eglapi.c:617
#8  0x7621d292 in glamor_egl_init
(scrn=scrn@entry=0x557ff150, fd=)
at ../../../../../../glamor/glamor_egl.c:927
#9  0x77fbd183 in try_enable_glamor (pScrn=0x557ff150)
at ../../../../../../../hw/xfree86/drivers/modesetting/driver.c:769
#10 PreInit (pScrn=0x557ff150, flags=)
at ../../../../../../../hw/xfree86/drivers/modesetting/driver.c:996
#11 0x555ef814 in InitOutput
(pScreenInfo=pScreenInfo@entry=0x557c37c0 ,
argc=argc@entry=1,
argv=argv@entry=0x7fffe6a8) at
../../../../../../hw/xfree86/common/xf86Init.c:522
#12 0x555b2714 in dix_main (argc=1, argv=0x7fffe6a8,
envp=) at ../../../../dix/main.c:193
#13 0x76ed3bbb in __libc_start_main (main=0x5559c710
, argc=1, argv=0x7fffe6a8,
init=, fini=, rtld_fini=, stack_end=0x7fffe698)
at ../csu/libc-start.c:308
#14 0x5559c74a in _start ()
(gdb) disas
Dump of assembler code for function dri2_add_config:
   0x7fffecce8a40 <+0>: push   %r15
   0x7fffecce8a42 <+2>: push   %r14
   0x7fffecce8a44 <+4>: push   %r13
   0x7fffecce8a46 <+6>: push   %r12
   0x7fffecce8a48 <+8>: mov%rsi,%r12
   0x7fffecce8a4b <+11>: mov%rdi,%rsi
   0x7fffecce8a4e <+14>: push   %rbp
   0x7fffecce8a4f <+15>: xor%ebp,%ebp
   0x7fffecce8a51 <+17>: push   %rbx
   0x7fffecce8a52 <+18>: lea0x15b7f(%rip),%rbx# 0x7fffeccfe5d8
   0x7fffecce8a59 <+25>: sub$0x118,%rsp
   0x7fffecce8a60 <+32>: mov0x70(%rdi),%r15
   0x7fffecce8a64 <+36>: mov%rdi,(%rsp)
   0x7fffecce8a68 <+40>: lea0x44(%rsp),%r14
   0x7fffecce8a6d <+45>: lea0x40(%rsp),%r13
   0x7fffecce8a72 <+50>: mov%edx,0x3c(%rsp)
   0x7fffecce8a76 <+54>: mov%ecx,0x14(%rsp)
   0x7fffecce8a7a <+58>: mov%r8,0x20(%rsp)
   0x7fffecce8a7f <+63>: mov%r9,0x28(%rsp)
   0x7fffecce8a84 <+68>: mov%fs:0x28,%rax
   0x7fffecce8a8d <+77>: mov%rax,0x108(%rsp)
   

Bug#943387: upgrade-from-grub-legacy: environment variable DPKG_MAINTSCRIPT_NAME is required

[Martin von Wittich]

Package: grub-pc
Version: 2.02~beta3-5+deb9u2
Severity: normal
Tags: patch

Dear Maintainer,

apparently, one of our servers still has some GRUB legacy files
installed, which causes `dpkg-reconfigure grub-pc` to tell me that I
have to run `upgrade-from-grub-legacy`. That doesn't work though:


host ~ # upgrade-from-grub-legacy

core.img doesn't exist, trying to create it.

i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
dpkg: Warnung: Version »dummy-version« hat falsche Syntax: Versionsnummer 
beginnt nicht mit einer Ziffer
dpkg: Warnung: Version »dummy-version« hat falsche Syntax: Versionsnummer 
beginnt nicht mit einer Ziffer
dpkg: Warnung: Version »dummy-version« hat falsche Syntax: Versionsnummer 
beginnt nicht mit einer Ziffer
i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.9.0-11-amd64
Found initrd image: /boot/initrd.img-4.9.0-11-amd64
Found linux image: /boot/vmlinuz-4.9.0-8-amd64
Found initrd image: /boot/initrd.img-4.9.0-8-amd64
Found memtest86+ image: /boot/memtest86+.bin
Found memtest86+ multiboot image: /boot/memtest86+_multiboot.bin
Found linux image: /boot/vmlinuz-4.9.0-11-amd64
Found initrd image: /boot/initrd.img-4.9.0-11-amd64
Found linux image: /boot/vmlinuz-4.9.0-8-amd64
Found initrd image: /boot/initrd.img-4.9.0-8-amd64
done
dpkg-maintscript-helper: error: environment variable DPKG_MAINTSCRIPT_NAME is 
required


I've looked into the script and determined that the following command causes
this error:


host ~ # UPGRADE_FROM_GRUB_LEGACY=1 /var/lib/dpkg/info/grub-pc.postinst 
configure dummy-version
dpkg: Warnung: Version »dummy-version« hat falsche Syntax: Versionsnummer 
beginnt nicht mit einer Ziffer
dpkg: Warnung: Version »dummy-version« hat falsche Syntax: Versionsnummer 
beginnt nicht mit einer Ziffer
dpkg: Warnung: Version »dummy-version« hat falsche Syntax: Versionsnummer 
beginnt nicht mit einer Ziffer
i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.9.0-11-amd64
Found initrd image: /boot/initrd.img-4.9.0-11-amd64
Found linux image: /boot/vmlinuz-4.9.0-8-amd64
Found initrd image: /boot/initrd.img-4.9.0-8-amd64
Found memtest86+ image: /boot/memtest86+.bin
Found memtest86+ multiboot image: /boot/memtest86+_multiboot.bin
Found linux image: /boot/vmlinuz-4.9.0-11-amd64
Found initrd image: /boot/initrd.img-4.9.0-11-amd64
Found linux image: /boot/vmlinuz-4.9.0-8-amd64
Found initrd image: /boot/initrd.img-4.9.0-8-amd64
done
dpkg-maintscript-helper: error: environment variable DPKG_MAINTSCRIPT_NAME is 
required


As far as I can tell, the issue occurs because upgrade-from-grub-legacy calls
the postinst directly without providing the DPKG_MAINTSCRIPT_NAME environment
variable (which dpkg would do when it calls a maintainer script), and the
command dpkg-maintscript-helper inside this postinst script then fails because
it requires this variable.

I've attached a patch that resolves the issue for me.


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/md1 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/md1 
/var/lib/docker/containers/2f9ea6c5164b0a0923d88379717a4435cb4250e0d8fe8b707f32eae1e70a212d/mounts
 ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/md1 
/var/lib/docker/containers/577647308b1ba37730d8006f453628b5042427485e0927957171872b10d6c37a/mounts
 ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/md1 
/var/lib/docker/containers/10800baf61f8ba8b1d6c2fa68e023887f651c04d1996c21e7ba1947bbaf401d3/mounts
 ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/md1 
/var/lib/docker/containers/0525084a5e3e5504f7468fadf9bfb2f22ad7e5ee758e7b4270ffaa3d65d3/mounts
 ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-ST2000NM0033-9ZM175_Z1X4QRBZ
(hd1)   /dev/disk/by-id/ata-ST2000NM0033-9ZM175_Z1X4QRP9
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ 

Bug#926896: sysvinit-utils: pidof is unreliable

[Martin von Wittich]

Am 20.10.19 um 20:59 schrieb Dmitry Bogatov:


That sounds explainable. pidof() scans /proc directory, and it takes some
time for kernel to create entry there.


Hm, is there really a delay? I'm not very deep into kernel development, 
but as far as I understand /proc, it isn't populated by the kernel after 
a process has been created, but instead represents direct access to 
internal kernel data structures. So as far as I know, there shouldn't be 
any delay after a process has been created before it's accessible via 
/proc/.


Even if there were, that wouldn't explain how ps is able to see the 
process, while pidof is not. As far as I know, ps also gets this 
information from /proc.


To verify my assumptions, I've adapted my test script as follows:

#!/bin/bash

set -eu
systemctl restart apcupsd
START=$SECONDS

ps -f -C apcupsd
PID="$(ps -o pid -C apcupsd --noheaders)"
ls /proc/"$PID"

while true
do
  echo -n "pidof: "
  pidof -s apcupsd || echo
  echo -n "ls: "
  ls -d /proc/"$PID"
  [ $((SECONDS - START)) -ge 2 ] && break
  sleep 0.01
done
ps -f -C apcupsd


The output:

buster-server ~ # ./pidof.sh
UIDPID  PPID  C STIME TTY  TIME CMD
root 26476 1  0 14:16 ?00:00:00 /sbin/apcupsd
attr   clear_refs   cpuset   fd   limits mem net 
   oom_score  personality  schedstat  smaps_rollup  status 
timerslack_ns
autogroup  cmdline  cwd  fdinfo   loginuid   mountinfo   ns 
   oom_score_adj  projid_map   sessionid  stack syscall 
uid_map
auxv   comm environ  gid_map  map_files  mounts 
numa_maps  pagemaproot setgroups  stat  task 
wchan
cgroup coredump_filter  exe  io   maps   mountstats 
oom_adjpatch_stateschedsmaps  statm timers 


pidof:
ls: /proc/26476
pidof:
ls: /proc/26476
pidof:
ls: /proc/26476
pidof:
ls: /proc/26476
pidof:
ls: /proc/26476
pidof:
ls: /proc/26476
pidof: 26476
ls: /proc/26476
pidof: 26476

So the /proc/26476 is there even when pidof doesn't see the process.


But there are almost always holes in the output further on, so it's
also slightly unreliable afterwards.


This is really wierd, given that pid is same: process is not restarted.


#!/bin/bash

set -eu

systemctl restart apcupsd


Do you have receipe to reproduce issue on systemd-free box, so I can try
to debug issue myself?


Unfortunately no, I only have access to machines with systemd :(
Does replacing "systemctl restart apcupsd" with "/etc/init.d/apcupsd" work?

I had assumed that the problem should be easily reproducible with any 
other recently-started process, but that is apparently not the case:


buster-server ~ # cat sleep.sh
#!/bin/bash

set -eu
sleep 2 &
START=$SECONDS

ps aux|grep sleep
while true
do
  echo -n "pidof: "
  pidof -s sleep || echo
  [ $((SECONDS - START)) -ge 2 ] && break
  sleep 0.01
done
ps aux|grep sleep

Output:

buster-server ~ # ./sleep.sh
root 26946  0.0  0.0   6980  3120 pts/3S+   14:19   0:00 
/bin/bash ./sleep.sh

root 26947  0.0  0.0   5596   752 pts/3S+   14:19   0:00 sleep 2
root 26949  0.0  0.0   6424   884 pts/3S+   14:19   0:00 grep sleep
pidof: 26947
pidof: 26947
pidof: 26947
pidof: 26947
pidof: 26947
[no holes like with apcupsd...]
pidof: 26947
pidof: 26947
root 26946  1.5  0.0   7112  3376 pts/3S+   14:19   0:00 
/bin/bash ./sleep.sh

root 26947  0.0  0.0   5596   752 pts/3S+   14:19   0:00 sleep 2
root 27069  0.0  0.0   6424   884 pts/3S+   14:19   0:00 grep sleep

Maybe systemd is somehow involved?

--
Mit freundlichen Grüßen
Martin von Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon: 0531-2243666-0
Fax: 0531-2243666-9
E-Mail: i...@iserv.eu
Internet: iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Martin Hüppe, Jörg Ludwig
Grundsätze zum Datenschutz: https://iserv.eu/privacy

Bug#926896: sysvinit-utils: pidof is unreliable

[Martin von Wittich]

I also just noticed this issue. We have a piece of code in our software 
that uses pidof to wait to apcupsd to start; I've reduced it to the 
following minimal working example:



#!/bin/bash

set -eu

systemctl restart apcupsd

#sleep 1

echo "Connecting to ups, please wait..."
START=$SECONDS

while pidof -s apcupsd >/dev/null
do
  if RES="$(apcaccess)"
  then
if grep -q "^STATUS *: *COMMLOST" <<< "$RES"
then
  break
elif grep -q "^STATUS *: *ONLINE" <<< "$RES"
then
  MODEL="$(sed -n 's/^MODEL *: *//p' <<< "$RES")"
  echo -e "Connection established:\n$MODEL"
  exit 0
fi
  fi
  if [ $((SECONDS - START)) -ge 30 ]
  then
break
  fi
  sleep 1
  echo -n .
done

echo "Connection failed!"


This worked fine for years, for example on a stretch server:

stretch-server ~ # ./test.sh
Connecting to ups, please wait...
Connection established:
Smart-UPS 750

But it doesn't work on a buster server:

buster-server ~ # ./test.sh
Connecting to ups, please wait...
Connection failed!

apcupsd is running, but for some reason, pidof isn't able to see it yet 
and therefore returns 1, which immediately terminates the loop. If you 
uncomment the sleep 1, it'll work:


buster-server ~ # ./test.sh
Connecting to ups, please wait...
Connection established:
Smart-UPS 750

Apparently the issue occurs only for very new processes...? The 
following script shows how pidof isn't able to see the process when it 
should be able to:



#!/bin/bash

set -eu
systemctl restart apcupsd
START=$SECONDS

ps aux|grep apcupsd
while true
do
  echo -n "pidof: "
  pidof -s apcupsd || echo
  [ $((SECONDS - START)) -ge 2 ] && break
  sleep 0.01
done
ps aux|grep apcupsd


Output on stretch, where pidof works fine:


stretch-server ~ # ./pidof.sh
root  6251  0.0  0.0  20420   180 ?Ssl  14:57   0:00 
/sbin/apcupsd
root  6255  0.0  0.0   5128   800 pts/2S+   14:57   0:00 grep 
apcupsd

pidof: 6251
[removed all duplicate lines...]
pidof: 6251
root  6251  0.0  0.0  20420   180 ?Ssl  14:57   0:00 
/sbin/apcupsd
root  6380  0.0  0.0   5128   852 pts/2S+   14:57   0:00 grep 
apcupsd


Output on buster:


buster-server ~ # ./pidof.sh
root 26609  0.0  0.0  87144  2060 ?Dsl  15:00   0:00 
/sbin/apcupsd
root 26613  0.0  0.0   6424   884 pts/8S+   15:00   0:00 grep 
apcupsd

pidof:
pidof:
pidof:
pidof:
pidof:
pidof:
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof:
pidof: 26609
pidof:
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof:
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
root 26609  0.0  0.0  87144  2060 ?Ssl  15:00   0:00 
/sbin/apcupsd
root 26739  0.0  0.0   6424   884 pts/8S+   15:00   0:00 grep 
apcupsd



There's always at least 4-6 empty "pidof:" lines at the beginning, so 
apparently pidof never works in the ~40-60ms after a process was 
launched. But there are almost always holes in the output further on, so 
it's also slightly unreliable afterwards.


--
Mit freundlichen Grüßen
Martin von Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon: 0531-2243666-0
Fax: 0531-2243666-9
E-Mail: i...@iserv.eu
Internet: iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Martin Hüppe, Jörg Ludwig
Grundsätze zum Datenschutz: https://iserv.eu/privacy

Bug#878569: spamassassin: Can't set TxRep directory for site wide use

[Marko von Oppen]

Hello,

this bug is still in the Debian package, also in Stable.

The bug was marked fixed upstream some days ago.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7383

Maybe it could be fixed now in Debian too.

Thanks

Marko

--

*Marko von Oppen*
e-mail: ma...@von-oppen.com <mailto:ma...@von-oppen.com>




signature.asc
Description: OpenPGP digital signature

Bug#933667: sagemath: FTBFS in sid

[Martin von Gagern]

Build log from 
https://launchpad.net/ubuntu/+source/sagemath/8.6-6build1/+build/17348800
shows SIGSEGV in sage.libs.gap.util.initialize. That makes this a
duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932367
I believe. Merge?

Bug#932367: GAP_Initialize signature changed

[Martin von Gagern]

Instead of fixing GAP by backporting an upstream commit, we might also
consider updating sagemath to include said commit. The first release
to contain that is 8.8. I started
https://salsa.debian.org/science-team/sagemath/merge_requests/12 in
the hope that it helps getting that upgrade off the ground.

Bug#932367: GAP_Initialize signature changed

[Martin von Gagern]

I tried locally rebuilding sagemath against GAP 4r10p2-2. It seems we
need 
https://github.com/sagemath/sage/commit/e6e80bfa0f36688904716f93e04ad0121b7a4136.patch
to account for changes to the GAP_Initialize signature from
https://github.com/gap-system/gap/commit/5dad0ef01e5527d83d7ade6677891b855381aee3
and 
https://github.com/gap-system/gap/commit/eab71117db3a3afd1adec9a87e96b3b4a9414f60.

Unfortunately the patch doesn't apply cleanly, and I don't have time
just now to massage it. So I'm sending what information I have in case
someone else can cherry-pick it in.

Without this, I get a SIGSEGV when loading sage.libs.gap.libgap
because the address of a data structure (the old env argument) is
treated as a function pointer that gets called during garbage
collection. The error doesn't stop the build at that point, but it
causes the documentation build to hang indefinitely eventually,
similar to bug #901532. Check sage/logs/dochtml.log for the actual
problem report.

Bug#932919: RFP: python-openshift -- Python client library for OpenShift

[Fabian von Feilitzsch]

Package: wnpp
Severity: wishlist

This is the Python client for openshift. based on the kubernetes Python
client (which is already packaged in python-kubernetes and
python3-kubernetes). Most dependencies are shared with python-kubernetes.

Source repository located here, an RPM spec file exists in that repo as
well: https://github.com/openshift/openshift-restclient-python.

The license is Apache-2.0

This package is used in Ansible by the k8s module, and a .deb was requested
in the kubespray project.

-- 

*Fabian **v**o*n Feilitzsch

Senior Software Engineer, OpenShift Engineering

Red Hat 

fab...@redhat.comIM: fabianvf

Bug#930539: [Pkg-utopia-maintainers] Bug#930539: upowerd cannot start due to searching the wrong libssl version

[Andreas von Heydwolff]

>> I did not compile anything from source
> Then why you have binaries in /usr/local?

Hm, seems that indeed I did try out someone else's non standard attempt
of connecting a recent iOS device to my machine many months ago. My bad.
It didn't work as expected and I left an instance of libimobiledevice6
in /usr/local/lib. Same thing is true with a program I did compile and
use last year. It was was dependent on libssl, worked well but only
until some new ssl version broke it and I stopped using it. Lesson
learned. Thanks to all once more for helping me sort this out.

Regards,
Andreas

Bug#930539: [Pkg-utopia-maintainers] Bug#930539: upowerd cannot start due to searching the wrong libssl version

[Andreas von Heydwolff]

On 02.07.19 07:20, Andrey Rahmatullin wrote:
> Doing anything with libimobiledevice4 packages won't touch your locally
> installed bad library. You should remove it, and any other locally
> installed libraries, and never do such installs again, at least while you
> don't fully understand the consequences.

Agreed, although I am not sure what bad library means in this context.

I did not compile anything from source, have nothing installed but
Debian packages and single standard debs from virtualbox and nextcloud,
no Ubuntu stuff either. In almost 20 years of going through all Debian
upgrades and running testing for a good bit of the earlier times since
Potato, Etch and Slink and KDE 2 I never experienced such trouble. But I
am not a pro and perhaps just was lucky and, I guess, cautious enough.

Today I deinstalled upower, all libimobiledevice instances,
dependencies, purged leftover config cruft, ran deborphan and also
purged some unnecessary and unrelated stuff with debfoster. After
installing the current Stretch deb of upower and its dependencies libssl
1.0.0 is no longer aksed for, neither is libcrypto. The other symptoms I
described have vanished, and of course upowerd and powerdevil are now
working again.

Only trouble is that closing the lid no longer suspends the laptop as it
used to do, but this is a different issue, with dmesg reporting

 ACPI: button: The lid device is not compliant to SW_LID.

But although this problem started around the time of the upower problem
I assume it is a kernel or Intel Skylake firmware issue that perhaps
came with a BIOS or microcode update.

Thanks for the replies and help, it is very much appreciated.

Greetings,

Andreas

Bug#930539: [Pkg-utopia-maintainers] Bug#930539: upowerd cannot start due to searching the wrong libssl version

[Andreas von Heydwolff]

On 01.07.19 19:48, Michael Biebl wrote:
> Am 01.07.2019 um 19:35 schrieb Andreas v. Heydwolff:
>> (0x7f0eecfc2000)
>> libimobiledevice.so.6 => /usr/local/lib/libimobiledevice.so.6
> 
> It's as Andrey suspected a locally installed library.
> 

Just for testing purposes I rolled back upower and libidevice to the
respective Jessie versions

upower:amd64 0.99.1-3.2 install ok installed
libimobiledevice4:amd64 1.1.6+dfsg-3.1 install ok installed
libimobiledevice6:amd64 not installed

Now the SDDM login box, KDE control panel and file save dialogs were no
longer lagging for half a minute or more, and KDE's dolphin started as
fast as always. However, upowerd would not start although ldd found all
related libs. Perhaps this is due to some by now obsolete incompatibility.

Then I upgraded upower to the standard Stretch version (no backport)
with upower pulling in libidevice6 as it's only dependency. The
situation was then:

upower:amd64/stable 0.99.4-4+b1 uptodate
libimobiledevice4:amd64 1.1.6+dfsg-3.1 install ok installed
libimobiledevice4:amd64 1.1.6+dfsg-3.1 installed: No available version
in archive
libimobiledevice6:amd64 1.2.0+dfsg-3.1 install ok installed
libimobiledevice6:i386 not installed
libimobiledevice6 (1.2.0+dfsg-3.1 Debian:9.9/stable [amd64])

Now ldd for upowerd shows again

libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found

and upowerd is not starting as described in the initial bug report.
Stand-by and waking up of SDDM up to the login box KDE start and save
dialogs were fast as usual at this time.

Upgrading libimobiledevice6 to the latest

libimobiledevice6:amd64 (1.2.1~git20181030.92c5462-1)

slowed down the login box of SDDM, KDE start process and the save
dialogs again. Reverting libimobiledevice6 from testing/sid to stable
did not help, neither did a restart. Deinstalling upower and leaving
libimobiledevice6 in place with dpkg -r --force-all upower was
sufficient resolved the lags.

I guess the next step is to file a bug report against libimobiledevice6
testing/stable, would the upower maintainers agree?

Regards

Bug#926576: This also affects stretch (cups-filters 1.11.6-3)

[Martin von Wittich]

Hi,

this also affects stretch:


server ~ # apt-cache policy cups-filters
cups-filters:
  Installiert:   1.11.6-3
  Installationskandidat: 1.11.6-3
  Versionstabelle:
 *** 1.11.6-3 500
500 http://ftp.de.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status


Today a ghostscript update was released that broke printing for us:


server ~ # grep upgrade /var/log/dpkg.log | tail -n3
2019-05-13 02:58:10 upgrade ghostscript:amd64 9.26a~dfsg-0+deb9u2 
9.26a~dfsg-0+deb9u3
2019-05-13 02:58:11 upgrade libgs9:amd64 9.26a~dfsg-0+deb9u2 9.26a~dfsg-0+deb9u3
2019-05-13 02:58:12 upgrade libgs9-common:all 9.26a~dfsg-0+deb9u2 
9.26a~dfsg-0+deb9u3



server ~ # zcat /usr/share/doc/ghostscript/changelog.Debian.gz | head -n8
ghostscript (9.26a~dfsg-0+deb9u3) stretch-security; urgency=high

  * Non-maintainer upload by the Security Team.
  * Hide pdfdict and GS_PDF_ProcSet (internal stuff for the PDF interp)
(CVE-2019-3839)
  * Fix lib/pdf2dsc.ps to use documented Ghostscript pdf procedures

 -- Salvatore Bonaccorso   Fri, 10 May 2019 15:21:33 +0200


server ~ # tail /var/log/cups/error_log 
D [13/May/2019:11:24:14 +0200] [Job 8519] Process is dying with \"Unable to determine number of pages, page count: -1

D [13/May/2019:11:24:14 +0200] [Job 8519] \", exit stat 3
D [13/May/2019:11:24:14 +0200] [Job 8519] Cleaning up...
D [13/May/2019:11:24:14 +0200] [Job 8519] PID 20636 
(/usr/lib/cups/filter/foomatic-rip) stopped with status 3.
D [13/May/2019:11:24:14 +0200] [Job 8519] Hint: Try setting the LogLevel to 
"debug" to find out more.
D [13/May/2019:11:24:14 +0200] [Job 8519] PID 20637 
(/usr/lib/cups/backend/socket) exited with no errors.
D [13/May/2019:11:24:14 +0200] [Job 8519] End of messages
D [13/May/2019:11:24:14 +0200] [Job 8519] printer-state=3(idle)
D [13/May/2019:11:24:14 +0200] [Job 8519] printer-state-message="Filter failed"
D [13/May/2019:11:24:14 +0200] [Job 8519] 
printer-state-reasons=toner-empty-warning


Can we get a backport for stretch too?

--
Mit freundlichen Grüßen
Martin v. Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Martin Hüppe, Jörg Ludwig

Bug#927698: udev dependencies broken on stretch

[Marko von Oppen]

Am 23.04.19 um 14:48 schrieb Michael Biebl:

Am 23.04.19 um 21:11 schrieb Marko von Oppen:

On Sun, 21 Apr 2019 20:23:26 +0200 Michael Biebl  wrote:


This is by design. The init script requires a start-stop-daemon with
support for --notify-await.
This is only necessary for sysvinit users. If you don't want to use
systemd then backports is not available to you.
You can ask the dpkg maintainer for a backport of dpkg though.

Hi Michael,

there seems to be a misunderstanding at your side.

Not really, it seems you are misunderstanding the issue. The udev
package is not for sysvinit only.

I did not write that udev is for sysvinit only. And of course I know 
that because I've used udev more than 10 years before it became part of 
systemd (unfortunately).

Bug#927698: udev dependencies broken on stretch

[Marko von Oppen]

On Sun, 21 Apr 2019 20:23:26 +0200 Michael Biebl  wrote:

> This is by design. The init script requires a start-stop-daemon with
> support for --notify-await.
> This is only necessary for sysvinit users. If you don't want to use
> systemd then backports is not available to you.
> You can ask the dpkg maintainer for a backport of dpkg though.

Hi Michael,

there seems to be a misunderstanding at your side.

You write that 'this is only necessary only for sysvinit users'. But 
exactly sysvinit users cannot install that package because the package 
depends from 'systemd-sysv' what in turn is a 'systemd' package. 
'systemd-sysv' cannot be installed by sysvinit users.


So finally if the package is only for sysvinit users but sysvinit users 
cannot install it, the best for all sides would be to delete the package.


Marko

Bug#927280: exigrep: -M flag displays man page

[Christian von Kietzell]

Package: exim4-base
Version: 4.92-5
Severity: minor

Dear Maintainer,

the exigrep utility included in the package has two flags:

-m to open the manpage
-M to search for related messages

Both flags display the manpage, though.


Kind regards,
Chris



-- Package-specific info:
Exim version 4.92 #5 built 07-Apr-2019 11:39:31
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DANE DKIM DNSSEC 
Event OCSP PRDR SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated

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

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

Versions of packages exim4-base depends on:
ii  adduser3.118
ii  anacron2.3-27
ii  cron [cron-daemon] 3.0pl1-133
ii  debconf [debconf-2.0]  1.5.71
ii  exim4-config [exim4-config-2]  4.92-5
ii  libc6  2.28-8
ii  libdb5.3   5.3.28+dfsg1-0.6
ii  lsb-base   10.2019031300
ii  netbase5.6

Versions of packages exim4-base recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-1
ii  mailutils [mailx]  1:3.5-3
ii  psmisc 23.2-1

Versions of packages exim4-base suggests:
ii  bsd-mailx [mail-reader]  8.1.2-0.20180807cvs-1
ii  emacs-gtk [mail-reader]  1:26.1+1-3.2
ii  evolution [mail-reader]  3.30.5-1
pn  exim4-doc-html | exim4-doc-info  
pn  eximon4  
ii  file 1:5.35-4
ii  mailutils [mail-reader]  1:3.5-3
ii  mutt [mail-reader]   1.10.1-2
ii  openssl  1.1.1b-2
pn  spf-tools-perl   
pn  swaks

-- debconf information excluded

Bug#901251: IP multicast extended regular expression does not match some matchable lines which are matched online (regexr.com & regextester.com)

[Hannes von Haugwitz]

Hi,

On Sun, Jun 10, 2018 at 05:28:42PM +0200, jean-christophe manciot wrote:
> The rule *ulogd* described below (*IP multicast: 224.0.0.0 <-->
> 239.255.255.255*) does not match some matchable lines:
> ^.*? DST=2(?:2[4-9]|3\d)(?:\.(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]\d?|0)){3} .*$

logcheck uses POSIX extended regular expression (ERE).

Your regular expression contains non-capturing group notation ('?:'),
which is not supported in ERE.

You can use `rgxg` to generate an extended regular expression for
'224.0.0.0/4':

$ rgxg cidr 224.0.0.0/4
(23[0-9]|22[4-9])(\.(25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])){3}

With this regular expression `logcheck-test` matches your example log
lines.

If that solves your issue please close this bug report.

Best regards

Hannes

Bug#895927: sha256 checksum of output database not reproducible with command line tools

[Hannes von Haugwitz]

tags 895927 + unreproducible
thanks

Hi Marc,

On Tue, Apr 17, 2018 at 04:13:33PM +0200, Marc Haber wrote:
> I would like to verify the database mentioned in aide output before
> copying it over to the input database name. That does not seem to work:
> 
> [19/5003]mh@ivanova:~ $ ls -al /var/lib/aide/aide.db.new output.aide 
> -rw-rw-r-- 1 mh   mh   2,1M Apr 17 11:36 output.aide
> -rw--- 1 root root  71M Apr 17 11:36 /var/lib/aide/aide.db.new
> [20/5004]mh@ivanova:~ $ grep SHA512 output.aide | tail -n 1
>   SHA512   : LhaYUYpxlUaOFnLffOnCyxm8gq6rwxQW
> [21/5005]mh@ivanova:~ $ sudo openssl sha256 -binary /var/lib/aide/aide.db.new 
> | openssl base64
> rN/Af3eq+dKO6DKmpN1XOs+vpH6IQ3qFrELjhslp1Qs=
> [22/5006]mh@ivanova:~ $ sudo zcat /var/lib/aide/aide.db.new | openssl sha256 
> -binary | openssl base64
> 5uIy2b4L4ckKlzZ6o5UMlePKyKdRR8u/YhgciUQlFWg=
> [23/5007]mh@ivanova:~ $ 
> 
> What am I supposed to do with aide.db.new if I want the sha256 (or other) 
> checksums to match aide's own output?

First please note that the checksums in the report are wrapped to
multiple lines. Apart from that you seem to grep for sha512 checksum in
the output of AIDE but compute the sha256 checksum of the database file.

I got the following output for my last AIDE run:

# grep -A2 SHA512 /var/log/aide/aide.log | tail -n 3
  SHA512   : xCCa+gNpk4/A70vpUDcj07ghhg2v5W5x
 7oV+U7qaM1db1CaMdt0G8ew3WSgoHWc5
 W3C2FVzT4V95mGXpL0Rfig==
# zcat /var/lib/aide/aide.db | openssl sha512 -binary | openssl base64
xCCa+gNpk4/A70vpUDcj07ghhg2v5W5x7oV+U7qaM1db1CaMdt0G8ew3WSgoHWc5
W3C2FVzT4V95mGXpL0Rfig==

If that solves your issue please close this bug report.

Best regards

Hannes

Bug#773743: Confirmation: automatic suspending after idle time requires authentication

[Niklaas Baudet von Gersdorff]

Hello,

just want to note that I encounter the same behavior: automatic suspend
after inactivity fails, but I can suspend/reboot/poweroff normally.

When suspending automatically, the root password is requested in a
dialog box and an error message containing "dbus"-something*) is displayed.

*) I will copy and post the error here the next time i see it.

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

Kernel: Linux 4.9.0-7-amd64 (SMP w/4 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/dash
Init: systemd (via /run/systemd/system)

Versions of packages xfce4-power-manager depends on:
ii  libc6 2.24-11+deb9u3
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.26-0+deb9u1
ii  libdbus-glib-1-2  0.108-2
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2
ii  libgtk2.0-0   2.24.31-2
ii  libnotify40.7.7-2
ii  libpango-1.0-01.40.5-1
ii  libpangocairo-1.0-0   1.40.5-1
ii  libupower-glib3   0.99.4-4+b1
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfce4ui-1-04.12.1-2
ii  libxfce4util7 4.12.1-3
ii  libxfconf-0-2 4.12.1-1
ii  libxrandr22:1.5.1-1
ii  upower0.99.4-4+b1
ii  xfce4-power-manager-data  1.4.4-4

Versions of packages xfce4-power-manager recommends:
ii  libpam-systemd   232-25+deb9u4
ii  xfce4-power-manager-plugins  1.4.4-4

xfce4-power-manager suggests no packages.

-- no debconf information


pEpkey.asc
Description: application/pgp-keys

Bug#851802: Probably related to libinput

[Niklaas Baudet von Gersdorff]

Hi Mark,

could you solve the issue? I've got the same issue on my Thinkpad X1,
which is quite annoying.

Doing some research, I am pretty sure that this is related to libinput,
as mentioned in this Ubuntu bug report on Launchpad:

https://bugs.launchpad.net/ubuntu/+source/xfce4-settings/+bug/1758023

I.e., the problem also occurs with other devices than the trackpoint.

Niklaas


pEpkey.asc
Description: application/pgp-keys

Bug#900510: squidguard: SIGHUP crashes squidGuard instead of reloading it

[Martin von Wittich]

Package: squidguard
Version: 1.5-4
Severity: normal
Tags: upstream

Dear Maintainer,

squidGuard seems to support the SIGHUP signal to reload its
configuration, as is common for daemons. Though this doesn't seem to be
documented as far as I can tell, from the code it's obvious that it
should be supported - main.c at several points checks for sig_hup and calls
sgReloadConfig, for example:

  if(sig_hup) {
sgReloadConfig();
  }

sgReloadConfig is defined like this:

  void sgReloadConfig()
  {
struct LogFileStat *sg;
struct Source *src;
struct Destination *dest;
sig_hup = 0;
sgLogWarn("WARN: Received sigHUP, reloaded configuration");
for(sg = LogFileStat; sg != NULL; sg = sg->next){ /* closing logfiles */
  if(sg->fd == stderr || sg->fd == stdout) {
continue;
  }
  fclose(sg->fd);
}
for(src = Source; src != NULL; src = src->next){
  if(src->domainDb != NULL && src->domainDb->dbp != NULL) {
(void)src->domainDb->dbp->close(src->domainDb->dbp,0);
  }
  if(src->userDb != NULL && src->userDb->dbp != NULL) {
(void)src->userDb->dbp->close(src->userDb->dbp,0);
  }
}
for(dest = Dest; dest != NULL; dest = dest->next){
  if(dest->domainlistDb != NULL && dest->domainlistDb->dbp != NULL) {
(void)dest->domainlistDb->dbp->close(dest->domainlistDb->dbp,0);
  }
  if(dest->urllistDb != NULL && dest->urllistDb->dbp != NULL) {
(void)dest->urllistDb->dbp->close(dest->urllistDb->dbp,0);
  }
}
sgFreeAllLists();
execve(*globalArgv,globalArgv, globalEnvp);
fprintf(stderr,"error execve: %d\n",errno);
exit(1);
  }

Unfortunately, this doesn't work as expected when squidGuard is used as
url_rewrite_program in squid - sending SIGHUP to squidGuard will crash
it instead of reloading it. To reproduce:

1. strace squidGuard (works best when only a single instance is
   running):

strace -p $(pidof '(squidGuard)')

2. Send SIGHUP:

pkill -SIGHUP squidGuard

3. Observe in strace that squidGuard has received the SIGHUP, but
   nothing bad has happened yet:

host ~ # strace -p $(pidof '(squidGuard)')
Process 5598 attached
read(0, 0xf7779000, 4096)   = ? ERESTARTSYS (To be restarted if 
SA_RESTART is set)
--- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=8385, si_uid=0} ---
sigreturn() (mask [])   = 3
read(0,

4. Send a request to squid:

http_proxy=http://localhost:3128 GET google.de > /dev/null

5. Observe in strace that squidGuard crashes:

host ~ # strace -p $(pidof '(squidGuard)')
Process 8452 attached
read(0, 0xf7737000, 4096)   = ? ERESTARTSYS (To be restarted if 
SA_RESTART is set)
--- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=8503, si_uid=0} ---
sigreturn() (mask [])   = 3
read(0, "http://google.de/ 127.0.0.1/loca"..., 4096) = 71
time(NULL)  = 1527782365
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
write(5, "2018-05-31 17:59:25 [8452] WARN:"..., 73) = 73
close(4)= 0
munmap(0xf7745000, 4096)= 0
close(6)= 0
munmap(0xf7743000, 4096)= 0
close(11)   = 0
munmap(0xf7742000, 4096)= 0
close(14)   = 0
munmap(0xf7741000, 4096)= 0
close(17)   = 0
munmap(0xf774, 4096)= 0
close(20)   = 0
munmap(0xf773f000, 4096)= 0
close(23)   = 0
munmap(0xf773e000, 4096)= 0
close(26)   = 0
munmap(0xf773d000, 4096)= 0
close(29)   = 0
munmap(0xf773c000, 4096)= 0
close(32)   = 0
munmap(0xf773b000, 4096)= 0
close(35)   = 0
munmap(0xf773a000, 4096)= 0
close(38)   = 0
munmap(0xf7739000, 4096)= 0
close(41)   = 0
munmap(0xf7738000, 4096)= 0
close(5)= 0
munmap(0xf7744000, 4096)= 0
close(7)= 0
close(8)= 0
close(9)= 0
close(10)   = 0
close(12)   = 0
close(13)   = 0
close(15)   = 0
close(16)   = 0
close(18)   = 0
close(19)   = 0
close(21)   = 0

Bug#898478: Please upgrade package to kpcli 3.2

[Hannes von Haugwitz]

Package: kpcli
Version: 3.1-3
Severity: wishlist

Hi,

kpcli 3.2 was released in Dec 2017. Please consider to upgrade the
package.

Thanks.

Best regards

Hannes

Bug#892173: e2fsprogs: Bug in German l10n of "Inode 529618 extent tree (at level 1) could be shorter"

[Martin von Wittich]

Package: e2fsprogs
Version: 1.43.4-2
Severity: minor
Tags: l10n

Dear Maintainer,

the German localization of the following message:

some-server ~ # LANG=C e2fsck -f /dev/vg/some-lv
e2fsck 1.43.4 (31-Jan-2017)
Pass 1: Checking inodes, blocks, and sizes
Inode 529618 extent tree (at level 1) could be shorter.  Fix?

contains uninterpreted escape sequences instead of the actual values:

some-server ~ # LANG=de_DE.UTF-8 e2fsck -f /dev/vg/some-lv
e2fsck 1.43.4 (31-Jan-2017)
Durchgang 1: Inodes, Blöcke und Größen werden geprüft
Der Erweiterungsbaum von Inode %$i (auf Ebene %$b) könnte kürzer sein.  
Reparieren?

If I understand the issue correctly, the translations are attempting to use a
printf escape that might not be supported by the compiler...? Wikipedia says
"Parameter field - This is a POSIX extension and not in C99."

The following *.po files might be affected:

martin@dogmeat ~/Projects/e2fsprogs/po % grep -lP '\d\$' *.po
cs.po
de.po
hu.po
nl.po
pl.po
tr.po
vi.po
zh_CN.po

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

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

Versions of packages e2fsprogs depends on:
ii  e2fslibs1.43.4-2
ii  libblkid1   2.29.2-1
ii  libc6   2.24-11+deb9u1
ii  libcomerr2  1.43.4-2
ii  libss2  1.43.4-2
ii  libuuid12.29.2-1
ii  util-linux  2.29.2-1

e2fsprogs recommends no packages.

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
pn  gpart  
pn  parted 

-- no debconf information

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Martin von Wittich]

Hi Michael,

On Thu, 1 Mar 2018 15:10:26 +0100 Michael Biebl  wrote:

I can't reproduce this, neither on v237 nor on v232:

# systemctl stop postgresql@does-not-exist
Failed to stop postgresql@does-not-exist.service: Unit
postgresql@does-not-exist.service not loaded.

# systemctl start postgresql@does-not-exist
Failed to start postgresql@does-not-exist.service: Unit
postgresql@does-not-exist.service not found.

# systemctl restart postgresql@does-not-exist
Failed to restart postgresql@does-not-exist.service: Unit
postgresql@does-not-exist.service not found.


Do you have a postgresql template installed (should be the case when you 
have a postgresql-9.{4,6} (jessie/stretch) server package installed)? If 
not, try another template, maybe getty (I hope that's available on every 
system, would make reproducing this a lot easier):


stable.iserv.eu ~ # systemctl stop getty@does-not-exist
stable.iserv.eu ~ #

If the template itself doesn't exist, this leads to the expected error 
message:


stable.iserv.eu ~ # systemctl stop does-not-exist@does-not-exist
Failed to stop does-not-exist@does-not-exist.service: Unit 
does-not-exist@does-not-exist.service not loaded.


To ensure that this issue is not caused by our custom server 
configuration, I also tried to reproduce the issue on my Ubuntu 17.10 
client:


martin@dogmeat ~ % systemd --version
systemd 234
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP 
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS 
+KMOD -IDN2 +IDN default-hierarchy=hybrid


martin@dogmeat ~ % sudo systemctl restart getty@does-not-exist
martin@dogmeat ~ %

--
Mit freundlichen Grüßen
Martin v. Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Martin Hüppe, Jörg Ludwig

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Martin von Wittich]

Package: systemd
Version: 232-25+deb9u1
Severity: normal
Tags: upstream

Dear Maintainer,

the following commands unexpectedly do not print any error messages or
return non-zero exit codes:

martin.mein-iserv.de ~ # systemctl stop postgresql@does-not-exist
martin.mein-iserv.de ~ # systemctl start postgresql@does-not-exist
martin.mein-iserv.de ~ # systemctl restart postgresql@does-not-exist

reload on the other hand does:

martin.mein-iserv.de ~ # systemctl reload postgresql@does-not-exist; echo $?
postgresql@does-not-exist.service is not active, cannot reload.
1

martin.mein-iserv.de ~ # systemctl stop does-not-exist
Failed to stop does-not-exist.service: Unit does-not-exist.service not loaded.
martin.mein-iserv.de ~ # systemctl restart does-not-exist
Failed to restart does-not-exist.service: Unit does-not-exist.service not found.
martin.mein-iserv.de ~ # systemctl restart does-not-exist
Failed to restart does-not-exist.service: Unit does-not-exist.service not found.
martin.mein-iserv.de ~ # systemctl reload does-not-exist
Failed to reload does-not-exist.service: Unit does-not-exist.service not found.

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.11.0-3
ii  libaudit1   1:2.6.7-2
ii  libblkid1   2.29.2-1
ii  libc6   2.24-11+deb9u1
ii  libcap2 1:2.25-1
ii  libcryptsetup4  2:1.7.3-4
ii  libgcrypt20 1.7.6-2+deb9u2
ii  libgpg-error0   1.26-2
ii  libidn111.33-1
ii  libip4tc0   1.6.0+snapshot20161117-6
ii  libkmod223-2
ii  liblz4-10.0~r131-2+b1
ii  liblzma55.2.2-1.2+b1
ii  libmount1   2.29.2-1
ii  libpam0g1.1.8-3.6
ii  libseccomp2 2.3.1-2.1
ii  libselinux1 2.6-3+b3
ii  libsystemd0 232-25+deb9u1
ii  mount   2.29.2-1
ii  procps  2:3.3.12-3
ii  util-linux  2.29.2-1

Versions of packages systemd recommends:
ii  dbus1.10.24-0+deb9u1
ii  libpam-systemd  232-25+deb9u1

Versions of packages systemd suggests:
pn  policykit-1
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.130
ii  udev 232-25+deb9u1

-- no debconf information

Bug#767272: Bug#866670: ca-certificates: update-ca-certificates -f does not pass removed certs to hooks

[Daniel von Obernitz]

Dear Maintainer,

I still run into this problem using debian stretch packages.

ca-certificates 20161130+nmu1
ca-certificates-java 20170531+nmu1

For testing I put/removed my own certificates to/from 
"/usr/local/share/ca-certificates" and run "update-ca-certificates -f".


New certificates are correctly added to cacerts, but removed 
certificates stay present in the cacerts.


I did a very nasty workaround by adding a

rm -f /etc/ssl/certs/java/cacerts

into the ca-certificates-java hook. That way the cacerts is build from 
scratch every time, that way only existing certificates are used. But 
IMHO this can't be the solution.


Best regards
Daniel



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#883776: ITP: python-icinga2api -- Python library for the Icinga 2 RESTful API

[Tobias von der Krone]

Package: wnpp
Severity: wishlist
Owner: Tobias von der Krone <tobias.vonderkr...@profitbricks.com>

* Package name: python-icinga2api
  Version : 0.5
  Upstream Author : fmnisme <fmni...@gmail.com>, Tobias von der Krone <
tobias.vonderkr...@profitbricks.com>
* URL : https://github.com/tobiasvdk/python-icinga2api
* License : BSD
  Programming Lang: Python
  Description : Python library for the Icinga 2 RESTful API

The Icinga 2 API allows you to manage configuration objects and
resources in a simple, programmatic way using HTTP requests.
This is a Python library to interact with the Icinga 2 API.

I use the package for integration of Icinga 2 into other software
and for automation purposes.

Benjamin Drung will be the sponsor.

-- 
Tobias von der Krone
Teamlead Automation

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: tobias.vonderkr...@profitbricks.com
URL: https://www.profitbricks.de

Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B
Geschäftsführer: Achim Weiss, Matthias Steinberg

www.cloudexpoeurope.de/ProfitBricks

Bug#882066: ansible-lint fails with ansible 2.4

[Hannes von Haugwitz]

Package: ansible-lint
Version: 3.4.13+git.20170811-1-1
Severity: important

Hi,

ansible-lint fails with ansible 2.4:

$ ansible-lint
Traceback (most recent call last):
  File "/usr/bin/ansible-lint", line 11, in 
load_entry_point('ansible-lint==3.4.13', 'console_scripts', 
'ansible-lint')()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 572, 
in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2769, 
in load_entry_point
return ep.load()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2422, 
in load
return self.resolve()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2428, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python2.7/dist-packages/ansiblelint/__init__.py", line 28, in 

import ansiblelint.utils
  File "/usr/lib/python2.7/dist-packages/ansiblelint/utils.py", line 53, in 

from ansible.plugins import module_loader
ImportError: cannot import name module_loader
$

The issue is fixed upstream since 3.4.15.

So please update the package to the latest upstream version.

Thanks and best regards

Hannes


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (900, 'testing'), (200, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages ansible-lint depends on:
ii  ansible  2.4.0.0+dfsg-1
ii  python   2.7.14-1
ii  python-six   1.11.0-1
ii  python-yaml  3.12-1+b1

ansible-lint recommends no packages.

ansible-lint suggests no packages.

Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64

[Martin von Wittich]

We're having the same problem here. For some reason, only 2 domUs are 
affected (the dom0 has a total of 22 domUs, 14 of those are running 
Debian stretch, and 13 of those are running Linux 4.9.51-1).


The `xl console` output of the first domU (according to our monitoring 
it hangs since yesterday 14:06):



[ 3746.780086] INFO: task ntpd:670 blocked for more than 120 seconds.
[ 3746.780094]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3746.780097] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3746.780223] INFO: task jbd2/xvdb6-8:8173 blocked for more than 120 seconds.
[ 3746.780228]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3746.780233] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3746.780304] INFO: task rsync:8188 blocked for more than 120 seconds.
[ 3746.780308]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3746.780311] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3867.612083] INFO: task jbd2/xvda1-8:203 blocked for more than 120 seconds.
[ 3867.612091]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3867.612091] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3867.612148] INFO: task ntpd:670 blocked for more than 120 seconds.
[ 3867.612150]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3867.612152] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3867.612238] INFO: task jbd2/xvdb6-8:8173 blocked for more than 120 seconds.
[ 3867.612242]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3867.612245] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3867.612287] INFO: task rsync:8188 blocked for more than 120 seconds.
[ 3867.612291]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3867.612294] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3988.444071] INFO: task jbd2/xvda1-8:203 blocked for more than 120 seconds.
[ 3988.444080]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3988.444084] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3988.444154] INFO: task ntpd:670 blocked for more than 120 seconds.
[ 3988.444159]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3988.444162] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3988.444266] INFO: task kworker/2:0:1533 blocked for more than 120 seconds.
[ 3988.444271]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3988.444274] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.


The other domU had a similar error message before a coworker downgraded 
the kernel to 3.16 get it working again:



INFO: task jbd2/xvda1-8:191 blocked for more than 120 seconds.
[  605.148107]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[  605.148111] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.


The first domU is a backup machine, it mainly uses rsync --link-dest to 
pull backups from other machines, and is therefore rather IO intensive. 
The other domU is a firewall/router and shouldn't be IO intensive at all.


--
Mit freundlichen Grüßen
Martin v. Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Jörg Ludwig

Bug#855313: Invalid option -l

[Hannes von Haugwitz]

# fixed in upstream 4863aa9
tags 855313 + fixed-upstream
thanks

On Sat, Oct 21, 2017 at 12:57:13PM +0200, Marc Haber wrote:
> --limit works, and the source code looks correct as well:
> { "limit", required_argument, NULL, 'l'},
> 
> Hannes, that's your issue ;-)

Fixed upstream [0]

Best regards

Hannes

[0] https://sourceforge.net/p/aide/code/ci/4863aa9

Bug#878768: systemd: *.dpkg-remove.service entries in systemctl

[Martin von Wittich]

Am 16.10.2017 um 17:52 schrieb Michael Biebl:

systemd should already ignore files ending in dpkg-remove, see
https://github.com/systemd/systemd/blob/master/src/basic/path-util.c#L808

Not surprisingly, I was not able to reproduce your problem.

Can you provide steps how I can reproduce the problem (ideally starting
with pristine stretch installation)


Hmm, the affected server was only upgraded to stretch on 2017-10-14. 
Maybe it was the old systemd (215-17+deb8u7 according to the dpkg.log) 
that added these services during the upgrade to stretch, and the systemd 
in stretch would no longer do that?


Apparently ignoring *.dpkg-remove files was added with 
c7088e4999f2e5dd33259948c806f4e2706e77ce on 2015-01-21:


https://github.com/systemd/systemd/commit/c7088e4999f2e5dd33259948c806f4e2706e77ce

If I'm reading that correctly, that commit was only included with v219, 
so it seems likely that jessie's systemd was affected, but the version 
in stretch isn't. I'd say this bug report can be closed then. Thanks for 
taking the time trying to reproduce this issue, and sorry for wasting 
your time.


For others stumbling over this issue: I was able to get rid of the 
broken services by running "systemctl stop 

Bug#878241: log error message: Unable to load ipset library

[Daniel von Obernitz]

Package: keepalived
Version: 1:1.3.2-1
Severity: normal

Dear maintainer,

when starting keepalived the log shows the following line:

Keepalived_vrrp[10658]: Unable to load ipset library - libipset.so.3: cannot 
open shared object file: No such file or directory

This does not seem to affect the basic functionality (I tested with a fully 
functional keepalived.conf and a complete empty one) and can be solved simply 
by installing the 'libipset3' package.

To get a clean log file the package 'libipset3' should be added to the 
depending package list. Otherwise, if the library is not needed, the check 
should be removed.

Best regards
Daniel


-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 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/dash
Init: systemd (via /run/systemd/system)

Versions of packages keepalived depends on:
ii  init-system-helpers  1.48
ii  iproute2 4.9.0-1
ii  libc62.24-11+deb9u1
ii  libip4tc01.6.0+snapshot20161117-6
ii  libip6tc01.6.0+snapshot20161117-6
ii  libnl-3-200  3.2.27-2
ii  libnl-genl-3-200 3.2.27-2
ii  libnl-route-3-2003.2.27-2
ii  libsnmp305.7.3+dfsg-1.7
ii  libssl1.11.1.0f-3
ii  libxtables12 1.6.0+snapshot20161117-6

Versions of packages keepalived recommends:
pn  ipvsadm  

keepalived suggests no packages.

-- no debconf information

Bug#876436: gitlab: Unicorn shows stacktrace after enabling InfluxDB metrics and gitlab is unusable

[Tobias von der Krone]

The error disappeared after updating ruby-allocations to 1.0.5. But now we
get the following deprecation warnings:

/usr/share/gitlab/lib/gitlab/metrics/rack_middleware.rb:73: The route_xxx
methods such as route_method have been deprecated, please use
request_method.
/usr/share/gitlab/lib/gitlab/metrics/rack_middleware.rb:73: The route_xxx
methods such as route_path have been deprecated, please use path.
/usr/share/gitlab/lib/gitlab/metrics/rack_middleware.rb:74: The route_xxx
methods such as route_method have been deprecated, please use
request_method.

Bug#876436: gitlab: Unicorn shows stacktrace after enabling InfluxDB metrics and gitlab is unusable

[Tobias von der Krone]

Package: gitlab
Version: 8.13.11+dfsg1-8
Severity: important

Dear Maintainer,

I want gitlab to send metrics to our InfluxDB. After configuring the
"Metrics" section in the application settings and enabling the InfluxDB
Metrics gitlab does not start correctly anymore. In the
unicorn.stderr.log the following stacktrace is shown:

I, [2017-09-22T08:08:09.082921 #18957]  INFO -- : Refreshing Gem list
/usr/share/gitlab/lib/gitlab/metrics/sampler.rb:67:in `to_hash': undefined 
method `hash' for 
# (NoMethodError)
from /usr/share/gitlab/lib/gitlab/metrics/sampler.rb:67:in `sample_objects'
from /usr/share/gitlab/lib/gitlab/metrics/sampler.rb:44:in `sample'
from /usr/share/gitlab/lib/gitlab/metrics/sampler.rb:36:in `block (2 
levels) in start'
from /usr/share/gitlab/lib/gitlab/metrics/sampler.rb:33:in `loop'
from /usr/share/gitlab/lib/gitlab/metrics/sampler.rb:33:in `block in start'

After disabling the option again, gitlab starts normally.


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

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

Versions of packages gitlab depends on:
ii  adduser   3.115
ii  asciidoctor   1.5.4-2
ii  bc1.06.95-9+b3
ii  bundler   1.13.6-2
ii  dbconfig-pgsql2.0.8
ii  debconf [debconf-2.0] 1.5.61
ii  git   1:2.11.0-3+deb9u1
ii  gitlab-shell  3.6.6-4
ii  gitlab-workhorse  0.8.5+debian-3+b2
ii  init-system-helpers   1.48
ii  libjs-chartjs 1.0.2-1
ii  libjs-clipboard   1.4.2-1
ii  libjs-fuzzaldrin-plus 0.3.1+git.20161008.da2cb58+dfsg-4
ii  libjs-graphael0.5+dfsg-1
ii  libjs-jquery-cookie   11-3
ii  libjs-jquery-history  11-3
ii  libjs-jquery-nicescroll   3.6.6-1
ii  lsb-base  9.20161125
ii  nginx 1.10.3-1+deb9u1
ii  nginx-full [nginx]1.10.3-1+deb9u1
ii  nodejs4.8.2~dfsg-1
ii  openssh-client1:7.4p1-10+deb9u1
ii  postfix [mail-transport-agent]3.1.4-7
ii  postgresql-client-9.6 [postgresql-client  9.6.4-0+deb9u1
ii  postgresql-contrib9.6+181
ii  rake  10.5.0-2
ii  redis-server  3:3.2.6-1
ii  ruby  1:2.3.3
ii  ruby-ace-rails-ap 4.1.1-1
ii  ruby-activerecord-session-store   1.0.0-2
ii  ruby-acts-as-taggable-on  4.0.0-2
ii  ruby-addressable  2.4.0-1
ii  ruby-after-commit-queue   1.3.0-1
ii  ruby-akismet  2.0.0-1
ii  ruby-allocations  1.0.3-1+b2
ii  ruby-asana0.4.0-1
ii  ruby-attr-encrypted   3.0.1-2
ii  ruby-babosa   1.0.2-2
ii  ruby-base32   0.3.2-3
ii  ruby-bootstrap-sass   3.3.5.1-5
ii  ruby-browser  2.2.0-2
ii  ruby-cal-heatmap-rails3.6.0+dfsg-1
ii  ruby-carrierwave  0.10.0+gh-4
ii  ruby-charlock-holmes  0.7.3+dfsg-2+b3
ii  ruby-chronic  0.10.2-3
ii  ruby-chronic-duration 0.10.6-1
ii  ruby-coffee-rails 4.1.0-2
ii  ruby-coffee-script-source 1.10.0-1
ii  ruby-connection-pool  2.2.0-1
ii  ruby-creole   0.5.0-2
ii  ruby-d3-rails 3.5.6+dfsg-1
ii  ruby-default-value-for3.0.1-1
ii  ruby-devise   4.2.0-1
ii  ruby-devise-two-factor3.0.0-2
ii  ruby-diffy3.0.6-1
ii  ruby-doorkeeper   4.2.0-3
ii  ruby-dropzonejs-rails 0.7.1-1
ii  ruby-email-reply-parser   0.5.8-1
ii  ruby-fog-aws  0.12.0-1
ii  ruby-fog-azure0.0.2-1
ii  ruby-fog-core 1.42.0-1
ii  ruby-fog-google   0.3.2-1
ii  ruby-fog-local0.3.0-1
ii  

Bug#876381: linux-image-4.9.0-3-amd64: fanotify doesn't see events from other namespaces

[Martin von Wittich]

Package: src:linux
Version: 4.9.30-2+deb9u5
Severity: normal
Tags: upstream

Dear Maintainer,

we use the Linux fanotify interface in a virus scanner to detect
viruses as soon as the files are written. Yesterday we noticed that a
machine that has been upgraded to Debian stretch no longer detects
viruses that have been uploaded with a PHP script served by Apache.

The issue is easily reproducable by installing the package fnotifystat
and using that to monitor for filesystem events caused by Apache, for
example:

# fnotifystat -v | grep apache

Then request some document served by Apache, or just trigger a reload:

# systemctl reload apache2

fnotifystat won't print any filesystem events caused by Apache, the only
thing you'll see are a few events from apachectl that is used by systemd
to reload Apache.

The reason for this is apparently the namespace isolation done by
systemd that is triggered by the following setting:

host ~ # grep PrivateTmp /lib/systemd/system/apache2.service 
PrivateTmp=true

If I comment the PrivateTmp line out and then restart Apache:

# systemctl daemon-reload; systemctl restart apache2

then fnotifystat will be able to see events caused by Apache, either
from requesting a document, or from reloading it. This issue has been
documented on some websites already, but I haven't found any bugreports
for it yet:

https://community.sophos.com/kb/en-us/122625
https://lkml.org/lkml/2015/10/29/268
https://community.f-secure.com/t5/Business/Linux-Security-11-00-unable-to/ta-p/77793

It is easily worked around by disabling PrivateTmp on all services that
may be used to upload files, but I do believe that it should be properly
fixed in the kernel. fanotify seems to be the intended interface for
virus scanners, and therefore it shouldn't be accidentally circumvented
by namespace isolation.

-- Package-specific info:
** Version:
Linux version 4.9.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)

** Command line:
root=UUID=97174b79-e90a-436b-b6b8-55f37167c1e5 ro  quiet

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information

** Loaded modules:
dm_mod
cpuid
ipt_MASQUERADE
nf_nat_masquerade_ipv4
xt_NFLOG
xt_REDIRECT
nf_nat_redirect
ipt_REJECT
nf_reject_ipv4
xt_mac
xt_u32
xt_length
xt_nat
iptable_nat
nf_nat_ipv4
veth
xt_multiport
nf_conntrack_ipv4
nf_defrag_ipv4
xt_TCPMSS
nf_nat_tftp
xt_conntrack
nf_conntrack_tftp
nf_nat_sip
nf_conntrack_sip
nf_nat_pptp
nf_nat_proto_gre
nf_conntrack_pptp
nf_conntrack_proto_gre
xt_tcpudp
nf_nat_irc
iptable_filter
bridge
nf_conntrack_irc
stp
llc
nf_nat_h323
nf_conntrack_netlink
nf_conntrack_h323
xfrm_user
nf_nat_ftp
xfrm_algo
nf_conntrack_ftp
nf_nat_amanda
ts_kmp
nf_conntrack_amanda
nf_nat
nf_conntrack
overlay
nfnetlink_log
nfnetlink
intel_rapl
x86_pkg_temp_thermal
coretemp
crct10dif_pclmul
crc32_pclmul
ghash_clmulni_intel
evdev
pcspkr
intel_rapl_perf
loop
parport_pc
ppdev
lp
parport
ip_tables
x_tables
autofs4
ext4
crc16
jbd2
fscrypto
ecb
mbcache
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid1
raid0
multipath
linear
md_mod
crc32c_intel
xen_netfront
xen_blkfront
aesni_intel
aes_x86_64
glue_helper
lrw
gf128mul
ablk_helper
cryptd

** PCI devices:

** USB devices:
not available


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

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

Versions of packages linux-image-4.9.0-3-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kmod23-2
ii  linux-base  4.5

Versions of packages linux-image-4.9.0-3-amd64 recommends:
ii  firmware-linux-free  3.4
pn  irqbalance   

Versions of packages linux-image-4.9.0-3-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02~beta3-5
pn  linux-doc-4.9   

Versions of packages linux-image-4.9.0-3-amd64 is related to:
ii  firmware-amd-graphics 20161130-3
pn  firmware-atheros  
ii  firmware-bnx2 20161130-3
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
ii  firmware-linux-nonfree20161130-3
ii  firmware-misc-nonfree 20161130-3
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
ii  firmware-realtek  20161130-3
pn  firmware-samsung  
pn  

Bug#876372: reportbug: -u should say why a certain user interface is not available

[Martin von Wittich]

Package: reportbug
Version: 7.1.7
Severity: wishlist

Dear Maintainer,

I just install reportbug on a Debian stretch machine with the following
command:

# aptitude install reportbug python-urwid

Our default APT configuration won't install Recommends or Suggests, so
I manually specified python-urwid because I knew that I had to install
the package manually to get the urwid UI to work.

But when I tried to report a bug, reportbug would silently ignore the
"ui urwid" setting I put into the /etc/reportbug.conf. Therefore I tried
to specifiy the UI manually:

host ~ # EDITOR=vim DEBEMAIL="Martin von Wittich <martin.von.witt...@iserv.eu>" 
reportbug  -u urwid
Ignored bogus setting for -u: urwid
...

This left me pretty confused, because I though I had the correct package
installed. I looked into the code, and even in /usr/lib/python3/
dist-packages/reportbug/ui/urwid_ui.py the exception message says:

raise UINotImportable('Please install the python-urwid package to
use this interface.')

(This exception message is never visible anywhere though, because
ui/__init__.py always tries to load all UIs and will therefore silently
discard any exceptions.)

It took me a while to figure out that reportbug now uses Python 3, and
that I therefore had to install python3-urwid (though admittedly the
package Suggests the correct urwid package; if I had looked there, I
might have noticed sooner). Apparently the exception message just hasn't
been updated accordingly.

It would be nice if reportbug could be a bit more helpful in this
situation. Maybe a specific `ui` setting or `-u` invocation should
cause it to try to load the respective UI package again, and this time
it should print the exception message before falling back to the text
UI?

-- Package-specific info:
** Environment settings:
EDITOR="vim"
VISUAL="vim"
DEBEMAIL="Martin von Wittich <martin.von.witt...@iserv.eu>"
INTERFACE="urwid"

** /var/lib/iserv/remote-support/iserv-martin.von.wittich/.reportbugrc:
reportbug_version "7.1.7"
mode standard
ui urwid
no-check-uid

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

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

Versions of packages reportbug depends on:
ii  apt1.4.7
ii  python33.5.3-1
ii  python3-reportbug  7.1.7

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
ii  debsums2.2.2
pn  dlocate
ii  emacs24-bin-common 24.5+1-11+deb9u1
ii  exim4  4.89-2+deb9u1
ii  exim4-daemon-heavy [mail-transport-agent]  4.89-2+deb9u1
ii  file   1:5.30-1+deb9u1
pn  gir1.2-gtk-3.0 
pn  gir1.2-vte-2.91
ii  gnupg  2.1.18-6
pn  python3-gi 
pn  python3-gi-cairo   
pn  python3-gtkspellcheck  
ii  python3-urwid  1.3.1-2+b1
ii  xdg-utils  1.1.1-1

Versions of packages python3-reportbug depends on:
ii  apt1.4.7
ii  file   1:5.30-1+deb9u1
ii  python33.5.3-1
ii  python3-debian 0.1.30
ii  python3-debianbts  2.6.1
ii  python3-requests   2.12.4-1

python3-reportbug suggests no packages.

-- Configuration Files:
/etc/reportbug.conf changed:
submit
query-bts
cc
config-files
compress
ui urwid
verify


-- no debconf information

Bug#876373: reportbug: endless loop when specifiying package "linux"

[Martin von Wittich]

Package: reportbug
Version: 7.1.7
Severity: normal

Dear Maintainer,

I wanted to report a kernel bug, and tried to specify "linux" as a
package (I since figured out that I need to run `reportbug kernel`
instead). This causes an endless loop:


host ~ # reportbug -u text linux
Running 'reportbug' as root is probably insecure! Continue [y|N|q|?]? y
*** Welcome to reportbug.  Use ? for help at prompts. ***
Note: bug reports are publicly archived (including the email address of the 
submitter).
Detected character set: us-ascii
Please change your locale if this is incorrect.

Using 'root <root@host>' as your from address.
Getting status for linux...
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
^C
reportbug: exiting due to user interrupt.


This issue is reproducible both on jessie and stretch, though only the stretch
reportbug will print the "E: No packages found" message.


-- Package-specific info:
** Environment settings:
EDITOR="vim"
VISUAL="vim"
DEBEMAIL="Martin von Wittich <martin.von.witt...@iserv.eu>"
INTERFACE="urwid"

** /var/lib/iserv/remote-support/iserv-martin.von.wittich/.reportbugrc:
reportbug_version "7.1.7"
mode standard
ui urwid
no-check-uid

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

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

Versions of packages reportbug depends on:
ii  apt1.4.7
ii  python33.5.3-1
ii  python3-reportbug  7.1.7

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
ii  debsums2.2.2
pn  dlocate
ii  emacs24-bin-common 24.5+1-11+deb9u1
ii  exim4  4.89-2+deb9u1
ii  exim4-daemon-heavy [mail-transport-agent]  4.89-2+deb9u1
ii  file   1:5.30-1+deb9u1
pn  gir1.2-gtk-3.0 
pn  gir1.2-vte-2.91
ii  gnupg  2.1.18-6
pn  python3-gi 
pn  python3-gi-cairo   
pn  python3-gtkspellcheck  
ii  python3-urwid  1.3.1-2+b1
ii  xdg-utils  1.1.1-1

Versions of packages python3-reportbug depends on:
ii  apt1.4.7
ii  file   1:5.30-1+deb9u1
ii  python33.5.3-1
ii  python3-debian 0.1.30
ii  python3-debianbts  2.6.1
ii  python3-requests   2.12.4-1

python3-reportbug suggests no packages.

-- Configuration Files:
/etc/reportbug.conf changed:
submit
query-bts
cc
config-files
compress
ui urwid
verify


-- no debconf information

Bug#875980: kodi-pvr-vuplus: PVR addon not compatible with Kodi from same Debian release

[Marko von Oppen]

Package: kodi-pvr-vuplus
Version: 2.4.4+git20160820-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The Vuplus PVR addon can be installed, configured and generally works until 
next Kodi start.

After next Kodi start a message box comes up stating that the Vu+/Enigma Client 
Addon is not compatible with this Kodi version and the Addon is automatically 
deactivated.

That behaviour finally renders the Addon and so complete Debian package 
unusable.

The current upstream version of the addon is 3.5.1.

BR
Marko

Log entry is
19:03:19.917 T:139766167123712  NOTICE: ADDON: pvr.vuplus version 2.4.4 is 
incompatible


-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages kodi-pvr-vuplus depends on:
pn  kodi-api-pvr   
ii  libc6  2.24-11+deb9u1
ii  libgcc11:6.3.0-18
ii  libkodiplatform16  17.1.0-1
ii  libp8-platform22.1.0.1+dfsg1-1
ii  libstdc++6 6.3.0-18
ii  libtinyxml2.6.2v5  2.6.2-4

kodi-pvr-vuplus recommends no packages.

kodi-pvr-vuplus suggests no packages.

-- no debconf information

Bug#875802: (no subject)

[Martin von Wittich]

--- /var/lib/iserv/remote-support/iserv-martin.von.wittich/src2/psmisc-22.21/src/fuser.c	2017-09-14 16:55:21.0 +0200
+++ /var/lib/iserv/remote-support/iserv-martin.von.wittich/src/psmisc-22.21/src/fuser.c	2017-09-14 16:57:15.808933238 +0200
@@ -59,7 +59,7 @@
 #include "signals.h"
 #include "i18n.h"
 
-//#define DEBUG 1
+#define DEBUG 1
 
 #define NAME_FIELD 20		/* space reserved for file name */
 /* Function defines */
@@ -504,6 +504,11 @@
 	for (sun_tmp = sun_head; sun_tmp != NULL; sun_tmp = sun_tmp->next) {
 		if (sun_tmp->dev == this_name->st.st_dev
 		&& sun_tmp->inode == this_name->st.st_ino) {
+#ifdef DEBUG
+			printf("adding socket %s %lX %lX\n", this_name->filename,
+			   (unsigned long)net_dev,
+			   (unsigned long)sun_tmp->net_inode);
+#endif/* DEBUG */
 			add_inode(ino_list, this_name, net_dev,
   sun_tmp->net_inode);
 			return 0;
@@ -1555,7 +1560,7 @@
 {
 	FILE *fp;
 	char line[BUFSIZ];
-	int scanned_inode;
+	ino_t scanned_inode;
 	struct stat st;
 	struct unixsocket_list *newsocket;
 
@@ -1567,7 +1572,7 @@
 	while (fgets(line, BUFSIZ, fp) != NULL) {
 		char *path;
 		char *scanned_path = NULL;
-		if (sscanf(line, "%*x: %*x %*x %*x %*x %*d %d %as",
+		if (sscanf(line, "%*x: %*x %*x %*x %*x %*d %lld %as",
 			   _inode, _path) != 2) {
 			if (scanned_path)
 free(scanned_path);
@@ -1576,6 +1581,9 @@
 		if (scanned_path == NULL)
 			continue;
 		path = scanned_path;
+#ifdef DEBUG
+		fprintf(stderr, "fill_unix_cache: scanned_inode:%lld scanned_path:%s\n", scanned_inode, scanned_path);
+#endif/* DEBUG */
 		if (*scanned_path == '@')
 			scanned_path++;
 		if (timeout(stat, scanned_path, , 5) < 0) {

Bug#874669: apt-file reports empty cache; 'apt update' does not fill the cache

[Marko von Oppen]

Package: apt-file
Version: 3.1.4
Severity: important

Dear Maintainer,

The cache is reported empty and the suggested way to fill the cache does not 
work anymore:

Sample:
$ apt-file search test
E: The cache is empty. You need to run "apt update" first.

$ apt update
Reading package lists... Done
W: chmod 0700 of directory /var/lib/apt/lists/partial failed - 
SetupAPTPartialDirectory (1: Operation not permitted)
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission 
denied)
E: Unable to lock directory /var/lib/apt/lists/
W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches 
(13: Permission denied)
W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches 
(13: Permission denied)

$ sudo apt update
Hit:1 [snip] ./ InRelease
Hit:2 [snip] ascii InRelease
Hit:3 [snip] ascii-updates InRelease
Hit:5 [snip] ascii-backports InRelease
Hit:4 [snip] ascii-security InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.

$ apt-file search test
E: The cache is empty. You need to run "apt update" first.

It is intented that 'apt-file update' can only be run as root?

BR
Marko

*** End of the template - remove these template lines ***


-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux testing/unstable
Release:testing/unstable
Codename:   n/a
Architecture: x86_64

Kernel: Linux 4.11.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages apt-file depends on:
ii  apt  1.4.7
ii  libapt-pkg-perl  0.1.32
ii  liblist-moreutils-perl   0.416-1+b1
ii  libregexp-assemble-perl  0.36-1
ii  perl 5.24.1-3+deb9u1

apt-file recommends no packages.

apt-file suggests no packages.

-- no debconf information

Bug#783813: exim4-daemon-custom could not be build from source

[Marko von Oppen]

Hi,

after waiting 3 years for a fix and running inbetween oldoldstable 
version of Exim4 I managed today building a new exim4-daemon-custom 
package from current stable source package.


There are two steps necessary to build custom packages:
1) uncomment custom packages in debian/control
2) in file debian/rules copy the line
   'cp EDITME.eximon $(= ${Upstream-Version}), ${shlibs:Depends}, ${misc:Depends}
-#Description: custom Exim MTA (v4) daemon with locally set features
-# Exim (v4) is a mail transport agent. This package contains a
-# custom-configured exim4 daemon compiled to local needs. This package
-# is not part of official Debian, but can easily be built from the
-# Debian source package. For information about the feature set compiled in,
-# and for bug reports, please find out who built your package.
-# .
-# The Debian exim4 packages have their own web page,
-# http://wiki.debian.org/PkgExim4. There is also a Debian-specific
-# FAQ list. Information about the way the Debian packages are
-# configured can be found in
-# /usr/share/doc/exim4-base/README.Debian.gz, which additionally contains
-# information about the way the Debian binary packages are built. The
-# very extensive upstream documentation is shipped in
-# /usr/share/doc/exim4-base/spec.txt.gz. To repeat the debconf-driven
-# configuration process in a standard setup, invoke dpkg-reconfigure
-# exim4-config. There is a Debian-centered mailing list,
-# pkg-exim4-us...@lists.alioth.debian.org. Please ask Debian-specific
-# questions there, and only write to the upstream exim-users mailing
-# list if you are sure that your question is not Debian-specific. You
-# can find the subscription web page on
-# http://lists.alioth.debian.org/mailman/listinfo/pkg-exim4-users
+Package: exim4-daemon-custom
+Architecture: any
+Priority: optional
+Provides: mail-transport-agent, exim4-localscanapi-2.0
+Conflicts: mail-transport-agent
+Replaces: mail-transport-agent, exim4-base (<= 4.61-1)
+Depends: exim4-base (>= ${Upstream-Version}), ${shlibs:Depends}, ${misc:Depends}
+Description: custom Exim MTA (v4) daemon with locally set features
+ Exim (v4) is a mail transport agent. This package contains a
+ custom-configured exim4 daemon compiled to local needs. This package
+ is not part of official Debian, but can easily be built from the
+ Debian source package. For information about the feature set compiled in,
+ and for bug reports, please find out who built your package.
+ .
+ The Debian exim4 packages have their own web page,
+ http://wiki.debian.org/PkgExim4. There is also a Debian-specific
+ FAQ list. Information about the way the Debian packages are
+ configured can be found in
+ /usr/share/doc/exim4-base/README.Debian.gz, which additionally contains
+ information about the way the Debian binary packages are built. The
+ very extensive upstream documentation is shipped in
+ /usr/share/doc/exim4-base/spec.txt.gz. To repeat the debconf-driven
+ configuration process in a standard setup, invoke dpkg-reconfigure
+ exim4-config. There is a Debian-centered mailing list,
+ pkg-exim4-us...@lists.alioth.debian.org. Please ask Debian-specific
+ questions there, and only write to the upstream exim-users 

Bug#832159: ITP: qutebrowser -- A keyboard-driven, vim-like browser based on PyQt5.

[Hannes von Haugwitz]

Hi,

Is there any progress with packaging qutebrowser?

Best regards

Hannes

Bug#846052: passenger-config/status cannot find instance registry

[Martin von Wittich]

On Mon, 28 Nov 2016 07:40:10 + Matijs van Zuijlen 
 wrote:

I have just upgraded to passenger 5, and now I want to restart my
application the 'new' way by using passenger-config. I have tried this
both through capistrano, and on the command line, and I get the
following error message:

   *** ERROR: Phusion Passenger doesn't seem to be running. If you are sure 
that it
  is running, then the causes of this problem could be one of:


I just upgraded our Redmine installation to Debian stretch, and I have 
the same issue. I believe this is caused by the PrivateTmp feature of 
systemd (PrivateTmp=true is set in /lib/systemd/system/apache2.service), 
because while passenger-status is looking in /tmp, Apache is storing the 
instance registry dir in /tmp/systemd-private-...:


redmine.iserv.eu ~ # ll 
/tmp/systemd-private-df0217594fc94127b16c17b45a99716c-apache2.service-Q1WevN/tmp

total 72K
drwxr-xr-x 3 www-data www-data 4.0K Aug 15 18:49 bundler/
drwxr-xr-x 4 root root 4.0K Aug 15 18:49 passenger.U9uCrRI/
-rw--- 1 www-data www-data0 Aug 15 18:52 
RackMultipart20170815-1192-8063mg
-rw--- 1 www-data www-data0 Aug 15 18:56 
RackMultipart20170815-1192-8qsxi
-rw--- 1 www-data www-data0 Aug 15 18:53 
RackMultipart20170815-1192-v5lfb6

-rw--- 1 root root  30K Aug 15 18:56 passenger-error-24wMBJ.html
-rw--- 1 root root  30K Aug 15 18:49 passenger-error-GwQoka.html

I have resolved this as follows:

1) Create 
/etc/systemd/system/apache2.service.d/passenger-instance-reg.conf with 
the following contents:


[Service]
ExecStartPre=/bin/mkdir -p /run/passenger
ExecStopPost=/bin/rmdir --ignore-fail-on-non-empty /run/passenger

2) systemctl daemon-reload

3) Add the following to your Apache configuration:

# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846052
PassengerInstanceRegistryDir /run/passenger

4) Add the following to your /etc/environment:

# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846052
PASSENGER_INSTANCE_REGISTRY_DIR=/run/passenger

5) restart Apache and reconnect (SSH) or re-login (local). Opening a new 
shell is not enough, because /etc/environment is only read by PAM. 
passenger-status should work now.


--
Mit freundlichen Grüßen
Martin v. Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Jörg Ludwig

Bug#870064: redir: service names from /etc/services not recognized anymore for --lport=

[Marko von Oppen]

Package: redir
Version: 3.1-1~exp1
Severity: important

Dear Maintainer,

specifying a port as a name from /etc/services does not work in Stretch version 
anymore.

In Jessie it was working fine.

Sample:
/etc/services contains
minecraft   10001/tcp   # Minecraft Server
minecraft   10001/udp   # Minecraft Server

redir ... --lport=minecraft ...
was working in Jessie but does not work in stretch

redir ... --lport=10001 ...
also works fine in Stretch

I suppose deactivating support for service names was not intended.

Best regards
Marko


-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages redir depends on:
ii  libc6  2.24-11+deb9u1

redir recommends no packages.

redir suggests no packages.

-- no debconf information

Bug#819295: Please add 'flags_array' struct to public library interface

[Hannes von Haugwitz]

Hi,

Is there any progress with this request?

Best regards

Hannes

Bug#857023: durep -hs 1G does not work due to bug in processSizeOption

[Martin von Wittich]

Package: durep
Version: 0.9-3
Severity: normal
Tags: patch upstream

Dear Maintainer,

"durep -hs 1G" does not work as expected, though the documentation says
it should:

dev2.iserv.eu ~ # durep --help | grep hide-size
  -hs, --hide-size=N[bkmg]  do not display entries using N Bytes/Kb/Mb/Gb

For example in this folder, durep -hs 1G will list both bigfile (as expected)
but also smallfile:

dev2.iserv.eu ~/test # ll
total 1.1G
-rw-r--r-- 1 root root 1.0G Mar  7 10:46 bigfile
-rw-r--r-- 1 root root 1.0M Mar  7 10:46 smallfile

dev2.iserv.eu ~/test # durep -hs 1G .
[ /var/lib/iserv/remote-support/iserv-martin.von.wittich/test 1.0G (2 
files, 0 dirs) ]
   1.0G [# ]  99.90% bigfile
   1.0M [  ]   0.10% smallfile

The cause is a bug in the processSizeOption function in the durep code. The
code to handle gigabyte sizes is there, but it is never reached:

  if(defined $temp) {
if($temp =~ m/^[kK]/) {
  return $size * 1024;
}
elsif ($temp =~ m/^[mM]/) {
  return $size * 1048576;
}
elsif ($temp =~ m/^[mM]/) {
  return $size * 1048576 * 1024;
}
return $size;
  }

I've attached a patch that fixes this. The fixed durep behaves as expected:

dev2.iserv.eu ~/test # ~/durep.fixed -hs 1G .
[ /var/lib/iserv/remote-support/iserv-martin.von.wittich/test 1.0G (2 
files, 0 dirs) ]
   1.0G [# ]  99.90% bigfile

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

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

Versions of packages durep depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  perl   5.20.2-3+deb8u6

Versions of packages durep recommends:
ii  libmldbm-perl  2.05-1

durep suggests no packages.

-- debconf information:
  durep/makereports: false
  durep/filesystems: .
* durep/httpfileroot:
--- /usr/bin/durep	2014-08-02 11:19:05.0 +0200
+++ durep.fixed	2017-03-07 10:43:16.631568385 +0100
@@ -375,7 +375,7 @@
 elsif ($temp =~ m/^[mM]/) {
   return $size * 1048576;
 }
-elsif ($temp =~ m/^[mM]/) {
+elsif ($temp =~ m/^[gG]/) {
   return $size * 1048576 * 1024;
 }
 return $size;

Bug#846552: New upstream version 0.18

[Christian von Kietzell]

Hi,

version 0.18 has just been released which promises big performance
improvements and a simplified content structure. Hopefully, that can be
packaged before the freeze.


Cheers,
  Chris

-- 
Nothing to see here. Move along.