Bug#1064917: tex-common postinst script fails due to a bug in lua script /usr/bin/mtxrun.lua

2024-02-27 Thread root
Package: tex-common
Version: 6.18
Severity: important

Dear Maintainer,

after the latest standard "apt upgrade" I was left with an unconfigured 
tex-common, due to the following reported error:

lua error : startup file: /usr/bin/mtxrun.lua:2438: attempt to assign to const 
variable 'i'

I don't know exactly what caused this, since apparently tex-common was not 
modified by the upgrade, but something else triggered it to reconfigure.
/usr/bin/mtxrun.lua is provided by the package context, which also was not 
upgraded very recently
Most of the upgrade was gnu compilers 13 and 14. 
The packages that might have remotely something to do with tex-common could be 
auctex or maybe gnuplot?
Anyway, I attach here the dpkg.log excerpt with the upgrade after which 
tex-common failed to configure.
Regardless, I am not sure whether the bug was introduced by this latest update, 
or rather this upgrade simply made a preexisting bug apparent by triggering a 
tex-common configuration.
Indeed, mtxrun.lua uses texlua, as an interpreter, and that is provided by 
texlive-binaries, which was also upgraded a couple of days ago.
Gotcha! I downgraded texlive-binaries to the previous version, and now 
tex-common configures correctly.
So, apparently, the upgrade of texlive-binaries from version 
2023.20230311.66589-8+b1 to 2023.20230311.66589-9 broke the postinst script of 
tex-common, where it attempts to run mtxrun.lua.

I hope this is enough information to nail and fix the bug, please let me know 
if I can help with further testing.

Bye
Giacomo

P.S. here goes my latest dpkg.log:

2024-02-27 17:09:10 startup archives unpack
2024-02-27 17:09:12 upgrade dpkg:amd64 1.22.4 1.22.5
2024-02-27 17:09:12 status half-configured dpkg:amd64 1.22.4
2024-02-27 17:09:13 status unpacked dpkg:amd64 1.22.4
2024-02-27 17:09:13 status half-installed dpkg:amd64 1.22.4
2024-02-27 17:09:13 status triggers-pending man-db:amd64 2.12.0-3
2024-02-27 17:09:13 status unpacked dpkg:amd64 1.22.5
2024-02-27 17:09:14 startup packages configure
2024-02-27 17:09:14 configure dpkg:amd64 1.22.5 
2024-02-27 17:09:14 status unpacked dpkg:amd64 1.22.5
2024-02-27 17:09:14 status half-configured dpkg:amd64 1.22.5
2024-02-27 17:09:14 status installed dpkg:amd64 1.22.5
2024-02-27 17:09:15 startup archives unpack
2024-02-27 17:09:17 upgrade zfs-initramfs:all 2.2.2-4 2.2.3-1
2024-02-27 17:09:17 status triggers-pending initramfs-tools:all 0.142
2024-02-27 17:09:17 status half-configured zfs-initramfs:all 2.2.2-4
2024-02-27 17:09:17 status unpacked zfs-initramfs:all 2.2.2-4
2024-02-27 17:09:17 status half-installed zfs-initramfs:all 2.2.2-4
2024-02-27 17:09:17 status unpacked zfs-initramfs:all 2.2.3-1
2024-02-27 17:09:18 upgrade zfs-dkms:all 2.2.2-4 2.2.3-1
2024-02-27 17:09:18 status triggers-awaited zfs-dkms:all 2.2.2-4
2024-02-27 17:09:18 status half-configured zfs-dkms:all 2.2.2-4
2024-02-27 17:09:26 status unpacked zfs-dkms:all 2.2.2-4
2024-02-27 17:09:26 status half-installed zfs-dkms:all 2.2.2-4
2024-02-27 17:09:32 status unpacked zfs-dkms:all 2.2.3-1
2024-02-27 17:09:33 upgrade zfsutils-linux:amd64 2.2.2-4 2.2.3-1
2024-02-27 17:09:33 status half-configured zfsutils-linux:amd64 2.2.2-4
2024-02-27 17:09:33 status unpacked zfsutils-linux:amd64 2.2.2-4
2024-02-27 17:09:33 status half-installed zfsutils-linux:amd64 2.2.2-4
2024-02-27 17:09:35 status unpacked zfsutils-linux:amd64 2.2.3-1
2024-02-27 17:09:35 upgrade libnvpair3linux:amd64 2.2.2-4 2.2.3-1
2024-02-27 17:09:35 status triggers-pending libc-bin:amd64 2.37-15
2024-02-27 17:09:35 status half-configured libnvpair3linux:amd64 2.2.2-4
2024-02-27 17:09:35 status unpacked libnvpair3linux:amd64 2.2.2-4
2024-02-27 17:09:35 status half-installed libnvpair3linux:amd64 2.2.2-4
2024-02-27 17:09:36 status unpacked libnvpair3linux:amd64 2.2.3-1
2024-02-27 17:09:36 upgrade libuutil3linux:amd64 2.2.2-4 2.2.3-1
2024-02-27 17:09:36 status half-configured libuutil3linux:amd64 2.2.2-4
2024-02-27 17:09:36 status unpacked libuutil3linux:amd64 2.2.2-4
2024-02-27 17:09:36 status half-installed libuutil3linux:amd64 2.2.2-4
2024-02-27 17:09:37 status unpacked libuutil3linux:amd64 2.2.3-1
2024-02-27 17:09:37 upgrade libzfs4linux:amd64 2.2.2-4 2.2.3-1
2024-02-27 17:09:37 status half-configured libzfs4linux:amd64 2.2.2-4
2024-02-27 17:09:37 status unpacked libzfs4linux:amd64 2.2.2-4
2024-02-27 17:09:37 status half-installed libzfs4linux:amd64 2.2.2-4
2024-02-27 17:09:37 status unpacked libzfs4linux:amd64 2.2.3-1
2024-02-27 17:09:38 upgrade libzpool5linux:amd64 2.2.2-4 2.2.3-1
2024-02-27 17:09:38 status half-configured libzpool5linux:amd64 2.2.2-4
2024-02-27 17:09:38 status unpacked libzpool5linux:amd64 2.2.2-4
2024-02-27 17:09:38 status half-installed libzpool5linux:amd64 2.2.2-4
2024-02-27 17:09:38 status unpacked libzpool5linux:amd64 2.2.3-1
2024-02-27 17:09:39 upgrade zfs-zed:amd64 2.2.2-4 2.2.3-1
2024-02-27 17:09:39 status half-configured zfs-zed:amd64 2.2.2-4
2024-02-27 17:09:39 status unpacked zfs-zed:amd64 2.2.2-4
2024-02-27 17:09:39 

Bug#1058878: msg: python3-apt must be installed and visible from /usr/bin/python3

2023-12-17 Thread root
Package: python3-apt
Version: 2.7.2
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   ~# ansible host -C -m "apt update-cache=yes"
   msg: python3-apt must be installed and visible from /usr/bin/python3

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 downgrade from 2.7.2 (unstable) to 2.7.0+b1 (testing) resolves the
 issue.

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

Kernel: Linux 6.5.0-5-amd64 (SMP w/8 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)

Versions of packages python3-apt depends on:
ii  distro-info-data   0.60
ii  libapt-pkg6.0  2.7.7
ii  libc6  2.37-13
ii  libgcc-s1  13.2.0-9
ii  libstdc++6 13.2.0-9
ii  python-apt-common  2.7.2
ii  python33.11.6-1

Versions of packages python3-apt recommends:
ii  iso-codes4.15.0-1
ii  lsb-release  12.0-2

Versions of packages python3-apt suggests:
ii  apt 2.7.7
pn  python-apt-doc  

-- no debconf information



Bug#1053743: libc6: add loong64 to libc6_archs.

2023-10-09 Thread root
Package: libc6
Version: 2.37-9+loong64
Severity: normal
X-Debbugs-Cc: fanp...@loongson.cn

Dear Maintainer,

When compiling the package glibc for loong64 in the Debian
Package Auto-Building environment, the error message is as follows:
find: ‘debian/libc6’: No such file or directory
make: *** [debian/rules.d/debhelper.mk:39: 
/<>/stamp-dir/binaryinst_libc6] Error 1
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
merged-usr: no
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to POSIX), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libc6 depends on:
ii  libgcc-s1  13.2.0-5

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.4-1+b2

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.82
pn  glibc-doc  
ii  libc-l10n  2.37-12
pn  libnss-nis 
pn  libnss-nisplus 
pn  locales

-- debconf information excluded
diff --git a/debian/rules.d/control.mk b/debian/rules.d/control.mk
index ce852ee1..864e1b4e 100644
--- a/debian/rules.d/control.mk
+++ b/debian/rules.d/control.mk
@@ -2,7 +2,7 @@ libc_packages := libc6 libc6.1 libc0.3
 libc0_3_archs := hurd-i386
 libc6_archs   := amd64 arc arm64 armel armhf hppa i386 m68k mips mipsel 
mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el \
  mipsn32r6 mipsn32r6el mips64r6 mips64r6el nios2 powerpc ppc64 
ppc64el riscv64 \
- sparc sparc64 s390x sh3 sh4 x32
+ sparc sparc64 s390x sh3 sh4 x32 loong64
 libc6_1_archs := alpha ia64
 
 control_deps := $(wildcard debian/control.in/*) $(addprefix 
debian/control.in/, $(libc_packages))


Bug#1051491: sshfs: Memory Leak in version 3.7.1+repack-2

2023-09-08 Thread root
Package: sshfs
Version: 3.7.1+repack-2
Severity: important

Dear Maintainer,



   * What led up to the situation?
When I'm using rsync via sshfs for get backups.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
rsync -avh source destinationsimilar like this
source is mountdir from sshfs.

   * What was the outcome of this action?
https://pastebin.com/dDEzwU8v
proces was terminate
   
   * What outcome did you expect instead?
Normal working not terminate.

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


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

Kernel: Linux 5.10.0-23-amd64 (SMP w/8 CPU threads)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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

Versions of packages sshfs depends on:
ii  fuse3   3.10.3-2
ii  libc6   2.31-13+deb11u6
ii  libfuse3-3  3.10.3-2
ii  libglib2.0-02.66.8-1
ii  openssh-client  1:8.4p1-5+deb11u1

sshfs recommends no packages.

sshfs suggests no packages.

-- no debconf information



Bug#1041693: borgbackup: missing fuse3 dependency

2023-08-12 Thread root
Package: borgbackup
Version: 1.2.4-2
Followup-For: Bug #1041693
Control: severity -1 important
Control: reopen -1

Dear Maintainer,

borgbackup is missing a Recommends for fuse3 now. When I install
borgbackup on a fresh system, I get "fuse: device not found, try 'modprobe 
fuse' first"

Severity set to important because it breaks the functionality of the
package on some systems but not all systems, depending on whether fuse3
is already installed or not.

Please add the fuse3 recommends.

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages borgbackup depends on:
ii  libacl12.3.1-3
ii  libc6  2.37-6
ii  liblz4-1   1.9.4-1
ii  libssl33.0.10-1
ii  libxxhash0 0.8.1-1
ii  libzstd1   1.5.5+dfsg2-1
ii  python33.11.4-5+b1
ii  python3-msgpack1.0.3-2+b1
ii  python3-packaging  23.1-1
ii  python3-pkg-resources  68.0.0-2

Versions of packages borgbackup recommends:
ii  python3-pyfuse3  3.2.1-2+b2

Versions of packages borgbackup suggests:
pn  borgbackup-doc  

-- no debconf information



Bug#1041839: gnome-core: ssh connection from remote stop run when Gnome goes in power saving.

2023-07-24 Thread root
Package: gnome-core
Severity: important
X-Debbugs-Cc: franchi@modula.network

   * What led up to the situation?  A server with a fresh installation of 
Debian 12 was inaccessible from remote.
   * What exactly did you do (or not do) that was effective? Disabled any form 
of energy savings in Gnome
   * What was the outcome of this action? The server now is accessible.
   * What outcome did you expect instead? 
The Gnome energy savings options should non activate if someone 
is connected with putty/ssh. 
The server shouild avake is somebody cctivate a connectiion  
via ssh. 
Any iGnome default option that can lead to inaccessibility 
should be disabled by default. 


-- System Information: These informations could be unuseful as I found the 
problem Debian 12. I don't know is the same behavior is present in Debian 11.
Debian Release: 11.7Subject: gnome-core: ssh connection from remote stop run 
when Gnome goes in power saving.
Package: gnome-core
X-Debbugs-Cc: franchi@modula.network
Severity: important

   * What led up to the situation?  A server with a fresh installation of 
Debian 12 was inaccessible from remote.
   * What exactly did you do (or not do) that was effective? Disabled any form 
of energy savings in Gnome
   * What was the outcome of this action? The server now is accessible.
   * What outcome did you expect instead?
The Gnome energy savings options should non activate if someone 
is connected with putty/ssh.
The server shouild avake is somebody cctivate a connectiion  
via ssh.
Any iGnome default option that can lead to inaccessibility 
should be disabled by default.


-- System Information: These informations could be unuseful as I found the 
problem Debian 12. I don't know is the same behavior is present in Debian 11.
Debian Release: 11.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-23-amd64 (SMP w/2 CPU threads)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme3.38.0-1
ii  at-spi2-core  2.38.0-4+deb11u1
ii  baobab3.38.0-1
ii  caribou   0.4.21-7.1
ii  dconf-cli 0.38.0-2
ii  dconf-gsettings-backend   0.38.0-2
ii  eog   3.38.2-1
ii  evince3.38.2-1
ii  evolution-data-server 3.38.3-1+deb11u2
ii  firefox-esr   102.13.0esr-1~deb11u1
ii  fonts-cantarell   0.111-3
pn  gdm3  
ii  gedit 3.38.1-1
ii  gkbd-capplet  3.26.1-1
ii  glib-networking   2.66.0-2
ii  gnome-backgrounds 3.38.0-1
ii  gnome-bluetooth   3.34.3-2
ii  gnome-calculator  3.38.2-1
ii  gnome-characters  3.34.0-1
ii  gnome-contacts3.38.1-1+b1
ii  gnome-control-center  1:3.38.4-1
ii  gnome-disk-utility3.38.2-1
ii  gnome-font-viewer 3.34.0-2+b1
ii  gnome-keyring 3.36.0-1
ii  gnome-logs3.36.0-2
ii  gnome-menus   3.36.0-1
ii  gnome-online-accounts 3.38.0-3
ii  gnome-online-miners   3.34.0-2
ii  gnome-session 3.38.0-4
ii  gnome-settings-daemon 3.38.2-1
ii  gnome-shell   3.38.6-1~deb11u1
ii  gnome-shell-extensions3.38.2-1
ii  gnome-software3.38.1-1
ii  gnome-sushi   3.38.0-1
ii  gnome-system-monitor  3.38.0-1
-- INSERT --



Bug#1039654: ITP: fantascene-dynamic-wallpaper -- This is a dynamic wallpaper software

2023-06-28 Thread root
Package: wnpp
Severity: wishlist
Owner: liu MingHang 
X-Debbugs-Cc: liuminghang0...@gmail.com, liuminghang0...@gmail.com

* Package name: fantascene-dynamic-wallpaper
  Version : 1.5.0
  Upstream Contact: Liu MingHang 
* URL : https://github.com/dependon/fantascene-dynamic-wallpaper
* License : GPLv3
  Programming Lang: C++
  Description : This is a dynamic wallpaper software

Fantascene-dynamic-wallpaper is a personal development project that can be used
to display web pages and videos as dynamic wallpapers in the system



Bug#1036213: apache2: More infos for this bug

2023-05-30 Thread root
Package: apache2
Version: 2.4.56-1~deb11u2
Followup-For: Bug #1036213


I have additional information that might be related to this bug.
It seems to be following the previous bug I opened in Bug#1033408 ,
which is now solved since 2.4.56-1~deb11u2, but now we don't have
segfaults anymore, but the server of our customer is having a load average
increasing since we've updated the package, we've tested for a week and
load average went from around 5, to 35, slowly increasing over the week
to this value, and it would probably have increased more if we hadn't
intervene.

After witnessing this behavior I noticed these logs in error logs which
I had never seen before:
[...]
[Tue May 30 08:59:29.873462 2023] [http2:warn] [pid 3805413:tid 
140434122716928] [client 81.204.51.61:56550] h2_stream(3805413-327-1,CLEANUP): 
started=1, scheduled=1, ready=0, out_buffer=0
[Tue May 30 08:59:29.873486 2023] [http2:warn] [pid 3805413:tid 
140434122716928] [client 81.204.51.61:56550] h2_stream(3805413-327-5,CLEANUP): 
started=1, scheduled=1, ready=0, out_buffer=0
[Tue May 30 08:59:29.873490 2023] [http2:warn] [pid 3805413:tid 
140434122716928] [client 81.204.51.61:56550] h2_stream(3805413-327-9,CLEANUP): 
started=1, scheduled=1, ready=0, out_buffer=0
[Tue May 30 09:07:11.128774 2023] [http2:warn] [pid 3808854:tid 
140434047182592] [client 106.245.192.226:56994] 
h2_stream(3808854-230-1,CLEANUP): started=1, scheduled=1, ready=0, out_buffer=0
[Tue May 30 09:07:11.128793 2023] [http2:warn] [pid 3808854:tid 
140434047182592] [client 106.245.192.226:56994] 
h2_stream(3808854-230-5,CLEANUP): started=1, scheduled=1, ready=0, out_buffer=0
[Tue May 30 09:13:36.366838 2023] [http2:warn] [pid 3811558:tid 
140434114324224] [client 51.179.98.234:49225] 
h2_stream(3811558-357-17,CLEANUP): started=1, scheduled=1, ready=0, out_buffer=0
[Tue May 30 09:13:36.366874 2023] [http2:warn] [pid 3811558:tid 
140434114324224] [client 51.179.98.234:49225] 
h2_stream(3811558-357-19,CLEANUP): started=1, scheduled=1, ready=0, out_buffer=0
[Tue May 30 09:55:14.468946 2023] [http2:warn] [pid 3832829:tid 
140434089146112] [client 109.234.73.147:53640] h2_stream(3832829-35-5,CLEANUP): 
started=1, scheduled=1, ready=0, out_buffer=0
[Tue May 30 09:56:14.469032 2023] [http2:warn] [pid 3832829:tid 
140434089146112] [client 109.234.73.147:53640] h2_stream(3832829-35-5,CLEANUP): 
started=1, scheduled=1, ready=0, out_buffer=0
[...]

After noticing these, I immediately thought about the previous bug and
completely disabled the http2 module in apache. It immediately solved
the load issue.
I know it's very few information and I'm not sure it's related exactly
to his particular bug, might need a bug report of its own, but in case,
I don't want to duplicate and will let you choose.



-- Package-specific info:

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

Kernel: Linux 5.10.0-18-amd64 (SMP w/32 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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

Versions of packages apache2 depends on:
ii  apache2-bin  2.4.56-1~deb11u2
ii  apache2-data 2.4.56-1~deb11u2
ii  apache2-utils2.4.56-1~deb11u2
ii  dpkg 1.20.12
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  mime-support 3.66
ii  perl 5.32.1-4+deb11u2
ii  procps   2:3.3.17-5

Versions of packages apache2 recommends:
ii  ssl-cert  1.1.0+nmu1

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx [www-browser]   2.9.0dev.6-3~deb11u1

Versions of packages apache2-bin depends on:
ii  libapr1  1.7.0-6+deb11u2
ii  libaprutil1  1.6.1-5+deb11u1
ii  libaprutil1-dbd-sqlite3  1.6.1-5+deb11u1
ii  libaprutil1-ldap 1.6.1-5+deb11u1
ii  libbrotli1   1.0.9-2+b2
ii  libc62.31-13+deb11u6
ii  libcrypt11:4.4.18-4
ii  libcurl4 7.74.0-1.3+deb11u7
ii  libjansson4  2.13.1-1.1
ii  libldap-2.4-22.4.57+dfsg-3+deb11u1
ii  liblua5.3-0  5.3.3-1.1+b1
ii  libnghttp2-141.43.0-1
ii  libpcre3 2:8.44-2+0~20210301.9+debian11~1.gbpa278ad
ii  libssl1.11.1.1n-0+deb11u4
ii  libxml2  2.9.14+dfsg-0.1+0~20230421.14+debian11~1.gbpf14485
ii  perl 5.32.1-4+deb11u2
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx [www-browser]   2.9.0dev.6-3~deb11u1

Versions of packages apache2 

Bug#1036619: grub2-686 does not see partitions with big offset

2023-05-23 Thread root
Package: grub2
Version: 2.06-12
Severity: normal

Dear Maintainer,

grub2 686 machines do not see partitioins with big offset from start of the 
disk. It has no issues see
partitions at the begining of the disk.

/dev/sda1  34   2047   2014 1007K BIOS boot
/dev/sda22048 3369748479 3369746432  1.6T Linux filesystem
/dev/sda3  3503966208 3638183935  134217728   64G Linux filesystem
/dev/sda4  3638183936 3772401663  134217728   64G Microsoft basic data
/dev/sda5  3772401664 3906619391  134217728   64G Linux filesystem
/dev/sda6  3906619392 3907028991 409600  200M EFI System
/dev/sda7  3369748480 3503966207  134217728   64G Linux filesystem

I tried sda7 as my debian partition and start from following:

* luks1/2+btrfs
* btrfs
* ext4

grub ls showing correct (hd0,gpt1-7). At least part_gpt works. Also grub does
see by sda2 btrfs parittion and it's content. But sda7 partition does not work!

1) 'cryptomount -a' report no erros and exit for booth luks1 and luks2
2) saying unknown partition about btrfs formatted drive
3) syaing unknown partition about ext4 formatted drive

It looks like grub simply does not recognize big offset partitions. I tried
boot using livecd debian 686 and have no issue mounting sda7 partition.

Full logs including dmesg and cpuinfo (livecd; chroot /dev/sda7).

https://linux-hardware.org/?probe=266235dc3b

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda7 / ext4 rw,relatime,errors=remount-ro 0 0
*** END /proc/mounts

*** 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 [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt7'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint-ieee1275='ieee1275/(null)/sas/disk@0,gpt7' --hint-bios=hd0,gpt7 
--hint-efi=hd0,gpt7 --hint-baremetal=ahci0,gpt7  
d2fe035c-3dc2-4d61-b2c6-fcc2bc29976b
else
  search --no-floppy --fs-uuid --set=root d2fe035c-3dc2-4d61-b2c6-fcc2bc29976b
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-d2fe035c-3dc2-4d61-b2c6-fcc2bc29976b' {
load_video
insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt7'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint-ieee1275='ieee1275/(null)/sas/disk@0,gpt7' --hint-bios=hd0,gpt7 
--hint-efi=hd0,gpt7 --hint-baremetal=ahci0,gpt7  
d2fe035c-3dc2-4d61-b2c6-fcc2bc29976b
else
  search --no-floppy --fs-uuid --set=root 
d2fe035c-3dc2-4d61-b2c6-fcc2bc29976b
fi
echo'Loading Linux 6.1.0-9-686 ...'
linux   /boot/vmlinuz-6.1.0-9-686 
root=UUID=d2fe035c-3dc2-4d61-b2c6-fcc2bc29976b ro  quiet
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.

Bug#1033408: apache2: Segmentation fault + 503 on frontpage on 2.4.56-1

2023-03-24 Thread root
Package: apache2
Version: 2.4.56-1~deb11u1
Severity: important
X-Debbugs-Cc: t...@security.debian.org

Unattended-upgrades applied this new version on 22 march @ 6AM. Had
Segmentation faults since then, 503 for customers on websites. Since we
reverted back to 2.4.54, we've no more issues. Couldn't make any sense
of coredump but can provide one if necessary.


-- Package-specific info:

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

Kernel: Linux 5.10.0-18-amd64 (SMP w/32 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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

Versions of packages apache2 depends on:
ii  apache2-bin  2.4.56-1~deb11u1
ii  apache2-data 2.4.56-1~deb11u1
ii  apache2-utils2.4.56-1~deb11u1
ii  dpkg 1.20.12
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  mime-support 3.66
ii  perl 5.32.1-4+deb11u2
ii  procps   2:3.3.17-5

Versions of packages apache2 recommends:
ii  ssl-cert  1.1.0+nmu1

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx [www-browser]   2.9.0dev.6-3~deb11u1

Versions of packages apache2-bin depends on:
ii  libapr1  1.7.0-6+deb11u2
ii  libaprutil1  1.6.1-5+deb11u1
ii  libaprutil1-dbd-sqlite3  1.6.1-5+deb11u1
ii  libaprutil1-ldap 1.6.1-5+deb11u1
ii  libbrotli1   1.0.9-2+b2
ii  libc62.31-13+deb11u5
ii  libcrypt11:4.4.18-4
ii  libcurl4 7.74.0-1.3+deb11u7
ii  libjansson4  2.13.1-1.1
ii  libldap-2.4-22.4.57+dfsg-3+deb11u1
ii  liblua5.3-0  5.3.3-1.1+b1
ii  libnghttp2-141.43.0-1
ii  libpcre3 2:8.44-2+0~20210301.9+debian11~1.gbpa278ad
ii  libssl1.11.1.1n-0+deb11u4
ii  libxml2  2.9.14+dfsg-0+0~20220524.12+debian11~1.gbpc5dc45
ii  perl 5.32.1-4+deb11u2
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx [www-browser]   2.9.0dev.6-3~deb11u1

Versions of packages apache2 is related to:
ii  apache2  2.4.56-1~deb11u1
ii  apache2-bin  2.4.56-1~deb11u1

-- Configuration Files:
/etc/apache2/apache2.conf changed [not included]
/etc/apache2/mods-available/mpm_event.conf changed [not included]
/etc/apache2/ports.conf changed [not included]
/etc/apache2/sites-available/000-default.conf changed [not included]

-- no debconf information



Bug#1032074: libdbd-mysql-perl: SSL connection error: Enforcing SSL encryption is not supported

2023-02-27 Thread root
Package: libdbd-mysql-perl
Version: 4.050-2
Severity: normal

Dear Maintainer,

I'm running a mailing list implemented in Perl, which draws on a mysql 
database. It authenticates 
to the database using X.509. This setup runs for many years and it did not 
change any code for
years. The last successful use was February 20th or later.

In the meantime I installed the Debian updates e.g., mariadb and libssl. 
Apparently, libgnutls
was at least a day before that.

When I now try to connect I receive:

DBI 
connect('database=MList;mysql_ssl=1;mysql_ssl_client_key=/etc/postfix/mlist.key.pem;mysql_ssl_client_cert=/etc/postfix/mlist.cert.pem;mysql_ssl_ca_file=/etc/certs/cacert.pem;host=mysql.example.com','mlist',...)
 failed: SSL connection error: Enforcing SSL encryption is not supported at 
/usr/local/lib/mlist/MListDB.pm line 189.

However, using mysql immediately:

mysql -v -u mlist --ssl-ca /etc/certs/cacert.pem --ssl-cert 
/etc/postfix/mlist.cert.pem --ssl-key /etc/postfix/mlist.key.pem -h 
mysql.example.com MList

works as expected i.e., I am logged into MList as mlist. Also, using openssl 
s_client connects 
and negotiates a TLS ticket.

The CN of the mysql server's certificate matches the host of DBI connect. The 
CN of the client's 
certificate matches 'mlist' i.e., then user name.

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

Kernel: Linux 4.19.0-17-amd64 (SMP w/6 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 libdbd-mysql-perl depends on:
ii  libc6 2.28-10+deb10u2
ii  libdbi-perl [perl-dbdabi-94]  1.642-1+deb10u2
ii  libgnutls30   3.6.7-4+deb10u10
ii  libmariadb3   1:10.3.38-0+deb10u1
ii  perl  5.28.1-6+deb10u1
ii  perl-base [perlapi-5.28.1]5.28.1-6+deb10u1
ii  zlib1g1:1.2.11.dfsg-1+deb10u2

libdbd-mysql-perl recommends no packages.

libdbd-mysql-perl suggests no packages.

-- no debconf information



Bug#1027053: rsnapshot: Incorrectly parse backup destinations with one character basename.

2022-12-27 Thread root
Package: rsnapshot
Version: 1.4.4-4
Severity: normal
Tags: upstream
X-Debbugs-Cc: sgpin...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 5.10.0-0.bpo.11-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages rsnapshot depends on:
ii  liblchown-perl  1.01-4+b1
ii  perl5.36.0-6
ii  rsync   3.2.7-1

Versions of packages rsnapshot recommends:
ii  cron [cron-daemon]   3.0pl1-154
ii  logrotate3.21.0-1
ii  openssh-client [ssh-client]  1:9.1p1-1

rsnapshot suggests no packages.

-- no debconf information



Bug#1019139: ITP: zpaqfranz -- Swiss army knife for backup and disaster recovery

2022-09-04 Thread root
Package: wnpp
Severity: wishlist
Owner: Franco Corbelli 

* Package name: zpaqfranz
  Version : 55.14
  Upstream Author : Franco Corbelli 
* URL : https://github.com/fcorbelli/zpaqfranz
* License : MIT
  Programming Lang: C, C++
  Description : Swiss army knife for backup and disaster recovery

Like 7z or RAR on steroids,with deduplicated "snapshots" (versions)
Conceptually similar to Mac time machine, but much more efficiently
Keeps backup always-to-always, no need to ever prune (CryptoLocker)
Easily handles millions of files and TBs of data, non-latin support
Cloud backups with full encryption, minimal data transfer/bandwidth
Data integrity check CRC32+XXHASH|SHA-1|SHA-2|SHA-3|MD5|XXH3|BLAKE3
Thorough data verification, multithread support (real world 1GB+/s)
Specific zfs handling functions,full multiplatform interoperability
Particularly suitable for minimal space storage of virtual machines

Windows, FreeBSD, OpenBSD, Linux, MacOS, Solaris, OmniOS and others


__
This is a fork of zpaq 7.15 (already in Debian) which was abandoned 
by the developer (Matt Mahoney) in 2016.

I have integrated innovative features, in particular the compatibility 
with the zfs filesystem, which is increasingly popular also on Debian,
and controls up to the paranoid level.
It also works on "weird" platforms (eg PowerPC big endian), 
but I don't really know how to configure rules :)

Basically it is an evolution from a file compressor (zpaq) to 
an archiver / backup (zpaqfranz)

I have attempted to contact the maintainer of zpaq 7.15, 
and an Italian senior Debian developer, but without answer

It is going to be included in the FreeBSD and OpenBSD ports 
and I get about 70 github stars (of course few, but not zero)

I definitely need a sponsor and, even more, advices from those 
who are more experienced (this is my very first attempt with Debian)
for the "packaging" process

https://forums.debian.net/viewtopic.php?f=30=152620

It is not so easy to disentangle the various versions, 
warnings and guides that are not always updated



Bug#1014653: nvidia-driver: RTX-3050 is not supported by 470.129.06 driver

2022-07-09 Thread root
ibGL.so.1
  slave glx--libGL.so.1-x86_64-linux-gnu: 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
  slave glx--libGLESv1_CM.so.1-i386-linux-gnu: 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
  slave glx--libGLESv1_CM.so.1-x86_64-linux-gnu: 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
  slave glx--libGLESv2.so.2-i386-linux-gnu: 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2
  slave glx--libGLESv2.so.2-x86_64-linux-gnu: 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
  slave glx--libGLX_indirect.so.0-i386-linux-gnu: 
/usr/lib/i386-linux-gnu/libGLX_mesa.so.0
  slave glx--libGLX_indirect.so.0-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
/usr/lib/nvidia - priority 100
  slave glx--libEGL.so.1-i386-linux-gnu: 
/usr/lib/mesa-diverted/i386-linux-gnu/libEGL.so.1
  slave glx--libEGL.so.1-x86_64-linux-gnu: 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
  slave glx--libGL.so.1-i386-linux-gnu: 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
  slave glx--libGL.so.1-x86_64-linux-gnu: 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
  slave glx--libGLESv1_CM.so.1-i386-linux-gnu: 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
  slave glx--libGLESv1_CM.so.1-x86_64-linux-gnu: 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
  slave glx--libGLESv2.so.2-i386-linux-gnu: 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2
  slave glx--libGLESv2.so.2-x86_64-linux-gnu: 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
  slave glx--libGLX_indirect.so.0-i386-linux-gnu: 
/usr/lib/i386-linux-gnu/libGLX_nvidia.so.0
  slave glx--libGLX_indirect.so.0-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
  slave glx--libglxserver_nvidia.so: /usr/lib/nvidia/libglxserver_nvidia.so
  slave glx--libnvidia-cfg.so.1-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
  slave glx--nvidia-blacklists-nouveau.conf: 
/etc/nvidia/nvidia-blacklists-nouveau.conf
  slave glx--nvidia-bug-report.sh: /usr/lib/nvidia/nvidia-bug-report.sh
  slave glx--nvidia-drm-outputclass.conf: 
/etc/nvidia/nvidia-drm-outputclass.conf
  slave glx--nvidia-load.conf: /etc/nvidia/nvidia-load.conf
  slave glx--nvidia-modprobe.conf: /etc/nvidia/nvidia-modprobe.conf
  slave glx--nvidia_drv.so: /usr/lib/nvidia/nvidia_drv.so
/usr/lib/nvidia/bumblebee - priority 95
  slave glx--libEGL.so.1-i386-linux-gnu: 
/usr/lib/mesa-diverted/i386-linux-gnu/libEGL.so.1
  slave glx--libEGL.so.1-x86_64-linux-gnu: 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
  slave glx--libGL.so.1-i386-linux-gnu: 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
  slave glx--libGL.so.1-x86_64-linux-gnu: 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
  slave glx--libGLESv1_CM.so.1-i386-linux-gnu: 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
  slave glx--libGLESv1_CM.so.1-x86_64-linux-gnu: 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
  slave glx--libGLESv2.so.2-i386-linux-gnu: 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2
  slave glx--libGLESv2.so.2-x86_64-linux-gnu: 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
  slave glx--libGLX_indirect.so.0-i386-linux-gnu: 
/usr/lib/i386-linux-gnu/libGLX_mesa.so.0
  slave glx--libGLX_indirect.so.0-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
  slave glx--libnvidia-cfg.so.1-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
  slave glx--nvidia-blacklists-nouveau.conf: 
/etc/nvidia/nvidia-blacklists-nouveau.conf
  slave glx--nvidia-bug-report.sh: /usr/lib/nvidia/nvidia-bug-report.sh
  slave glx--nvidia-modprobe.conf: /etc/nvidia/nvidia-modprobe.conf

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Jul  9 19:29 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   49 Jul  9 19:29 
/etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root   49 Jul  9 19:29 
/etc/alternatives/glx--libEGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   51 Jul  9 19:29 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   48 Jul  9 19:29 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Jul  9 19:29 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Jul  9 19:29 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   48 Jul  9 19:29 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Jul  9 19:29 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-

Bug#1012797: iptables-1.8.2-4: Segmentation fault caused by iptables with no matching rules.

2022-06-14 Thread root
Package: iptables-1.8.2-4
Version: iptables 1.8.2-4
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Segmentation fault caused by iptables with no matching rules.


# iptables -D INPUT -s 10.0.0.1 -j DENY

Segmentation fault (core dumped) 

Jun 14 09:58:45 dux kernel: [6724455.363431] iptables[12347]: segfault at 2 ip 
7f9137f467be sp 7ffed4f99f58 error 4 in
libc-2.28.so[7f9137ed8000+147000]



Bug#1006959: bind9-utils: missing dnssec-keymgr

2022-03-09 Thread root
Package: bind9-utils
Version: 1:9.18.0-2
Severity: normal

Dear Maintainer,

According to the bind9 documentation, a new tool has been introduced, 
dnssec-keymgr (python), which is ment to help with dnssec policy and key 
rotation.
dnssec-keymgr does not seem to be included in any of the bind9 packages.

Can this please be added.

Thanks for your attension.

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

Kernel: Linux 5.11.0-18-generic (SMP w/1 CPU thread)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bind9-utils depends on:
ii  bind9-libs  1:9.18.0-2
ii  libc6   2.33-7

bind9-utils recommends no packages.

bind9-utils suggests no packages.

-- no debconf information



Bug#1005228: linux-image-4.19.0-18-amd64: Short freeze on virtual machine with message: "rcu: INFO: rcu_sched self-detected stall on CPU"

2022-02-09 Thread root
Package: src:linux
Version: 4.19.208-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
   Installing and running in production a fresh debian 10 with php/apache2 
installed.
   This is a virtual machine with 8 virtual CPU / 4 physical CPU / 8 GB Ram, 
running on
   an OpenNebula cluster. The VM freeze apparantly randomly (from 1 to
   10 times a day), during
   approximatively 1 minute then come back without any manual action or reboot.
   I tried to reinstall the VM and the same issue occurs. This is the
   most active VM of the OpenNebula cluster.
   The other VM of the Cluster from the same vm template does not have the 
issue.
   The kernel trace is not exactly the same each time, but the behavior
   seems the same. Let me know if I
   need to update each one.
   I did not see any relevant log on the OpenNebula worker (hypervisor), which 
have these
   packages installed:

   root@one-w-2-th3:~# dpkg -l | grep libvirt
   ii  libvirt-clients  5.0.0-4+deb10u1
   amd64Programs for the libvirt library
   ii  libvirt-daemon   5.0.0-4+deb10u1
   amd64Virtualization daemon
   ii  libvirt-daemon-system5.0.0-4+deb10u1
   amd64Libvirt daemon configuration files
   ii  libvirt0:amd64   5.0.0-4+deb10u1
   amd64library for interfacing with different virtualization
   systems
   root@one-w-2-th3:~# dpkg -l | grep qemu
   ii  ipxe-qemu1.0.0+git-20190125.36a4c85-1
   all  PXE boot firmware - ROM images for qemu
   ii  qemu-block-extra:amd64   1:3.1+dfsg-8+deb10u8
   amd64extra block backend modules for qemu-system and
   qemu-utils
   ii  qemu-kvm 1:3.1+dfsg-8+deb10u8
   amd64QEMU Full virtualization on x86 hardware
   ii  qemu-system-common   1:3.1+dfsg-8+deb10u8
   amd64QEMU full system emulation binaries (common files)
   ii  qemu-system-data 1:3.1+dfsg-8+deb10u8
   all  QEMU full system emulation (data files)
   ii  qemu-system-gui  1:3.1+dfsg-8+deb10u8
   amd64QEMU full system emulation binaries (user interface and
   audio support)
   ii  qemu-system-x86  1:3.1+dfsg-8+deb10u8
   amd64QEMU full system emulation binaries (x86)
   ii  qemu-utils   1:3.1+dfsg-8+deb10u8
   amd64QEMU utilities
   root@one-w-2-th3:~# dpkg -l | grep nebula
   ii  opennebula-common5.12.0.1-1.ce
   all  Common OpenNebula package shared by various components
   (Community Edition)
   ii  opennebula-common-onescape   5.12.0.1-1.ce
   all  Helpers for OpenNebula OneScape project (Community
   Edition)
   ii  opennebula-node  5.12.0.1-1.ce
   all  Services for OpenNebula KVM node (Community Edition)
   root@one-w-2-th3:~# uname -a
   Linux one-w-2-th3 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1
   (2020-07-24) x86_64 GNU/Linux

  

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   - apt update && apt upgrade && reboot
   - reinstall the virtual machine from template
   - migrate to another opennebula worker
   * What was the outcome of this action?
   no effect, the issue still occur
   * What outcome did you expect instead?
   no more freeze 

-- Package-specific info:
** Version:
Linux version 4.19.0-18-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.208-1 (2021-09-29)
Linux version 4.19.0-11-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.146-1 (2020-09-17)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-18-amd64 root=/dev/mapper/data-system ro 
console=ttyS0,19200n8 quiet

** Tainted: L (16384)
 * Kernel has detected soft lockup before.

** Kernel log:
[1197442.240847] RAX: 0040 RBX: 8c3e6e67a000 RCX: 
944b0156
[1197442.240848] RDX: ac0380cad000 RSI: 0282 RDI: 
0282
[1197442.240848] RBP: 8c3e0ff9b700 R08: 0001 R09: 

[1197442.240849] R10: 8062 R11: 73c34000 R12: 
8c3e742aa400
[1197442.240850] R13: 0001 R14: b062 R15: 
00023231ccde
[1197442.240851]  ? apic_timer_interrupt+0xa/0x20
[1197442.240858]  dev_hard_start_xmit+0xa5/0x210
[1197442.240861]  sch_direct_xmit+0x111/0x380
[1197442.240862]  __qdisc_run+0x14d/0x550
[1197442.240864]  __dev_queue_xmit+0x406/0x910
[1197442.240867]  ? fib6_table_lookup+0x12a/0x320
[1197442.240870]  ip6_finish_output2+0x360/0x5b0
[1197442.240872]  ? rt6_find_cached_rt+0x7a/0xc0
[1197442.240873]  ? ip6_pol_route+0xf4/0x3e0
[1197442.240875]  ? ip6_finish_output+0x112/0x280
[1197442.240876]  ip6_output+0x68/0x120
[1197442.240879]  ? flow_hash_from_keys+0x145/0x190
[1197442.240881]  ? ip6_route_output

Bug#995201: chrony: Custom UNIX socket?

2022-01-26 Thread root
Package: chrony
Version: 4.0-8+deb11u1
Followup-For: Bug #995201
X-Debbugs-Cc: s.egb...@sbcglobal.net


Also, the client-side 'chronyc' is NOT able to use a custom UNIX socket
path.

We can configure or change such UNIX socket path on the server side
using 'bindcmdaddress'

But we cannot lead the horse (chronyc) by the nose (UNIX socket path) to the 
watering hole (chronyd socket path).

Perhaps, remove support for UNIX socket path altogether (just kidding
there) or provide a command-line option for chronyc to select its 
own non-compiled-in/non-default UNIX socket pathway.

Real world example: I've got 3 separate instances of chronyd running
(using a custom chronyd@netdev.service instances). I can only view 
exactly and at most ONE instance of those three(3) chrony daemons by 
the virtue of its compiled in default (/run/chrony/chrony.sock).  
And none of those are viewable by chrony client if using 'bindaddress' 
directive non-default setting at each instance of the chrony servers.

General idea is to ensure that UDP packets go into a specific interface
as indicated by the 'ss' util:

  # ss -lu | grep ntp
  UNCONN 0  0  172.16.1.1%enp4s0:ntp 0.0.0.0:*
  UNCONN 0  0   172.17.2.1%vmbr0:ntp 0.0.0.0:*
  UNCONN 0  0 172.18.1.1%br0:ntp 0.0.0.0:*

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

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

Versions of packages chrony depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  iproute2 5.10.0-4
ii  libc62.31-13+deb11u2
ii  libcap2  1:2.44-1
ii  libedit2 3.1-20191231-2+b1
ii  libgnutls30  3.7.1-5
ii  libnettle8   3.7.3-1
ii  libseccomp2  2.5.1-1+deb11u1
ii  tzdata   2021a-1+deb11u2
ii  ucf  3.0043

chrony recommends no packages.

Versions of packages chrony suggests:
ii  bind9-dnsutils [dnsutils]  1:9.16.22-1~deb11u1   (Using latest ISC Bind9 
9.17+
pn  networkd-dispatcher  (this is a bare-boned appliance server)

-- Configuration Files:
/etc/chrony/conf.d/README [Errno 2] No such file or directory: 
'/etc/chrony/conf.d/README'
/etc/chrony/sources.d/README [Errno 2] No such file or directory: 
'/etc/chrony/sources.d/README'
/etc/default/chrony changed [not included] (not applicable)
/etc/dhcp/dhclient-exit-hooks.d/chrony changed [not included] (not
applicable)

-- no debconf information



Bug#996823: libunwind-13: Missing symlink libunwind.so to libunwind.so.1 causes -lc++ to fail since it links to -lunwind

2021-10-19 Thread root
Package: libunwind-13
Version: 1:13.0.0-6
Severity: important
X-Debbugs-Cc: darkdragon-...@web.de

libc++ installs /usr/lib/llvm-13/lib/libc++.so with the content 
INPUT(libc++.so.1 -lunwind -lc++abi)
linking to libunwind. The libunwind package does only include 
/usr/lib/x86_64-linux-gnu/libunwind.so.1
symlink but not /usr/lib/x86_64-linux-gnu/libunwind.so which should be
included. Upstream includes this by default.


-- System Information:
Debian Release: 11.0
  APT prefers impish-updates
  APT policy: (500, 'impish-updates'), (500, 'impish-security'), (500, 'impish')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.11-200.fc34.x86_64 (SMP w/8 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages libunwind-13 depends on:
ii  libc6  2.34-0ubuntu3
ii  libgcc-s1  11.2.0-7ubuntu2

libunwind-13 recommends no packages.

libunwind-13 suggests no packages.

-- no debconf information



Bug#989370: general: In bonding network configuration, hwaddress crashes networking service, fails to restart

2021-06-01 Thread root
Package: general
Severity: important

Dear Maintainer,

* What led up to the situation?
Created a network configuration via /etc/network/interfacess file method for a 
single ethernet NIC,
i.e. eth0, and WiFi adapter, i.e. wlan0.  Both had customized MAC addresses via 
the 'hwaddress' option.
This configuration worked as expected with no issues.

* What exactly did you do (or not do) that was effective (or ineffective)?
Changed the configuration to a bonding configuration adding bond0 interface, 
and changing the eth0
and wlan0 configuration to work as slaves under a simple active-backup bonding 
configuration.

* What was the outcome of this action?
On reboot or systemctl restart networking, the networking service fails, and 
network connectivity is
broken, nonfunctional.  ONLY AFTER REMOVING 'hwaddress' option under bond0 
interface configuration,
did networking start as expected.  Did not expect the 'hwaddress' option to 
working on slave interfaces,
but it should have worked on the bond, i.e. bond0 interface.  Nowhere in the 
documentation, that I
have found as yet, is the 'hwaddress' feature excluded from a bonding 
configuration.

* What outcome did you expect instead?
MAC address set per 'hwaddress' option of bond0 interface, at a minimum, set as 
expected, and networking
being functional.  Fail to understand why hwaddress option fails on bond0 
interface when bond0 configuration
is functional without said option being used.  At a minimum, if eth0 interface 
as primary has a 'hwaddress'
option set, the bond0 configuration should accept it.  But a better 
implementation would be for the bond0
interface to accept use of the hwaddress option.  Which apparently is not the 
case now.

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv6l

Kernel: Linux 5.10.17+
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)



Bug#988077: discover-data: Installation hangs when the 'discover' utility is installed.

2021-05-04 Thread root
Package: discover-data
Version: 2.2013.01.11
Severity: normal
Tags: d-i

Dear Maintainer,

Two years ago I purchased a Qotom Q190N MiniPC and successfully installed
Debian 8.2, subsequently upgraded to 10.1. A second Qotom of the same model
purchased a few months ago fails to install, even with the latest inatallation
CD. Both hang after reporting "Installed discover (amd64)".

Further investigation revealed:

1. PCLinuxOS live disk and install also hang at what appears to be the same
point: hardware discovery.
2. Puppy Linux runs fine.
3. System Rescue CD 5.3.0 (Gentoo based) runs fine, as does the latest SRCD 7.0
(Arch based).
4. ArchBang Linux installs cleanly and runs fine.

>From this I conclude that the hardware is OK, but the Debian and PCLinuxOS
hardware discovery utilities have not yet advanced to the hardware I am using.

I believe that Debian 10.1 uses the following utilities to identify hardware:

discover (2.1.2-5.2)
discover-data (2.2010.10.18)

However, even the latest install ISO fails using updated packages:

discover_2.1.2-8_amd64.deb
discover-data_2.2013.01.11_all.deb

Hardware listing of both Qotoms reveals them to be identical apart from a minor
change in CPU stepping. The SoC is an Intel Atom Bay Trail with four Celeron
J1900 cores, and during the interim between my purchases it moved from Stepping
8 to Stepping 9. However, this resulted in a change in CPU flags which may be
the problem:

Qotom #1 unique flags: cpuid pti tsc_known_freq tsc_reliable
Qotom #2 unique flags: ibpb ibrs ida kaiser md_clear stibp



-- Package-specific info:
lspci:
00:00.0 Host bridge [0600]: Intel Corporation Atom Processor Z36xxx/Z37xxx 
Series SoC Transaction Register [8086:0f00] (rev 0e)
00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor 
Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] (rev 0e)
00:13.0 SATA controller [0106]: Intel Corporation Atom Processor E3800 Series 
SATA AHCI Controller [8086:0f23] (rev 0e)
00:14.0 USB controller [0c03]: Intel Corporation Atom Processor Z36xxx/Z37xxx, 
Celeron N2000 Series USB xHCI [8086:0f35] (rev 0e)
00:1a.0 Encryption controller [1080]: Intel Corporation Atom Processor 
Z36xxx/Z37xxx Series Trusted Execution Engine [8086:0f18] (rev 0e)
00:1b.0 Audio device [0403]: Intel Corporation Atom Processor Z36xxx/Z37xxx 
Series High Definition Audio Controller [8086:0f04] (rev 0e)
00:1c.0 PCI bridge [0604]: Intel Corporation Atom Processor E3800 Series PCI 
Express Root Port 1 [8086:0f48] (rev 0e)
00:1c.1 PCI bridge [0604]: Intel Corporation Atom Processor E3800 Series PCI 
Express Root Port 2 [8086:0f4a] (rev 0e)
00:1c.2 PCI bridge [0604]: Intel Corporation Atom Processor E3800 Series PCI 
Express Root Port 3 [8086:0f4c] (rev 0e)
00:1c.3 PCI bridge [0604]: Intel Corporation Atom Processor E3800 Series PCI 
Express Root Port 4 [8086:0f4e] (rev 0e)
00:1f.0 ISA bridge [0601]: Intel Corporation Atom Processor Z36xxx/Z37xxx 
Series Power Control Unit [8086:0f1c] (rev 0e)
00:1f.3 SMBus [0c05]: Intel Corporation Atom Processor E3800 Series SMBus 
Controller [8086:0f12] (rev 0e)
01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 07)

lsusb:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 003: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 005: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
Bus 001 Device 011: ID 046d:c31c Logitech, Inc. Keyboard K120
Bus 001 Device 030: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n 
Wireless Network Adapter
Bus 001 Device 031: ID 048d:1234 Integrated Technology Express, Inc. 
Bus 001 Device 036: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 037: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 038: ID 05e3:0606 Genesys Logic, Inc. USB 2.0 Hub / D-Link 
DUB-H4 USB 2.0 Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

loaded modules:
8086:0f31 i915
8086:0f23 ahci
8086:0f35 xhci_pci
8086:0f04 snd_hda_intel
8086:0f1c lpc_ich
8086:0f12 i2c_i801
10ec:8168 r8169


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

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

discover-data depends on no packages.

Versions of packages discover-data recommends:
ii  pciutils  1:3.5.2-1

discover-data suggests no packages.

-- no debconf information



Bug#987927: bind9: unreasonable resource use and slow startup with lots of IP addresses

2021-05-02 Thread root
Package: bind9
Version: 1:9.16.13-1
Severity: normal

May  2 16:38:37 sjl named[7372]: listening on IPv4 interface lo, 127.0.0.1#53
May  2 16:38:37 sjl named[7372]: listening on IPv4 interface eno4, 10.0.2.45#53
May  2 16:38:37 sjl named[7372]: listening on IPv4 interface eno4, 10.0.40.1#53
May  2 16:38:37 sjl named[7372]: listening on IPv4 interface eno4, 10.0.40.2#53
May  2 16:38:37 sjl named[7372]: listening on IPv4 interface eno4, 10.0.40.3#53
[...]
May  2 16:39:33 sjl named[7372]: listening on IPv4 interface eno4, 10.0.47.0#53
May  2 16:39:33 sjl named[7372]: listening on IPv4 interface eno4, 10.0.48.0#53
May  2 16:39:33 sjl named[7372]: listening on IPv4 interface eno4, 10.0.49.0#53
May  2 16:39:33 sjl named[7372]: listening on IPv6 interface lo, ::1#53

On a system with 2560 extra IPv4 addresses for test purposes a default
configuration of bind9 takes one minute on a reasonably fast 64bit system (two
E5-2620 CPUs).  See the above for example startup log entries.

May  2 16:39:36 sjl named[7372]: zone localhost/IN: loaded serial 2
May  2 16:39:36 sjl named[7372]: all zones loaded
May  2 16:39:36 sjl named[7372]: running
May  2 16:39:36 sjl named[7372]: socket: file descriptor exceeds limit 
(123273/21000)
May  2 16:39:36 sjl named[7372]: managed-keys-zone: Unable to fetch DNSKEY set 
'.': not enough free resources
May  2 16:39:36 sjl named[7372]: socket: file descriptor exceeds limit 
(123273/21000)

Then the startup doesn't complete properly with errors like the above.

OPTIONS="-u bind -S 15"

Putting something like the above in /etc/default/named fixes the errors, but
it still takes a long time and really 150,000 file handles shouldn't be
required for 2560 IP addresses.

listen-on { 10.0.2.45; };

Putting the above in named.conf.options got it to work correctly in this
regard.  But I expect it to not use unreasonable amounts of resources without
that configuration.

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages bind9 depends on:
ii  adduser3.118
ii  bind9-libs 1:9.16.13-1
ii  bind9-utils1:9.16.13-1
ii  debconf [debconf-2.0]  1.5.75
ii  dns-root-data  2021011101
ii  init-system-helpers1.60
ii  iproute2   5.10.0-4
ii  libc6  2.31-11
ii  libcap21:2.44-1
ii  libfstrm0  0.6.0-1+b1
ii  libjson-c5 0.15-2
ii  liblmdb0   0.9.24-1
ii  libmaxminddb0  1.5.2-1
ii  libprotobuf-c1 1.3.3-1+b2
ii  libssl1.1  1.1.1k-1
ii  libuv1 1.40.0-1
ii  libxml22.9.10+dfsg-6.3+b1
ii  lsb-base   11.1.0
ii  netbase6.3
ii  zlib1g 1:1.2.11.dfsg-2

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind-doc   
ii  bind9-dnsutils [dnsutils]  1:9.16.13-1
ii  dnsutils   1:9.16.13-1
pn  resolvconf 
pn  ufw

-- Configuration Files:
/etc/bind/named.conf.local changed:
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
//include "/etc/bind/named.conf.postal";

/etc/bind/named.conf.options changed:
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk.  See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable 
// nameservers, you probably want to use them as forwarders.  
// Uncomment the following block, and insert the addresses replacing 
// the all-0's placeholder.
// forwarders {
//  0.0.0.0;
// };

//
// If BIND logs error messages about the root key being expired,
// you will need to update your keys.  See https://www.isc.org/bind-keys

//
dnssec-validation auto;
listen-on { 10.0.2.45; };
listen-on-v6 { any; };
};

/etc/default/named changed:
RESOLVCONF=no
OPTIONS="-u bind"


-- debconf information:
  bind9/start-as-user: bind
  bind9/different-configuration-file:
  bind9/run-resolvconf: false



Bug#981376: mariadb-server-10.3: Conflicting MariaDB instance config

2021-01-30 Thread root
Package: mariadb-server-10.3
Version: 1:10.3.27-0+deb10u1
Severity: normal

Dear Maintainer,

there seems to be a conflict with the provided systemd service in 
"mariadb@.service".

The config file used for an instance is specified as 
"/etc/mysql/conf.d/my%I.cnd".
This collides with the "main" service (mariadb.service), which uses 
"/etc/mysql/my.cnf", which **includes** "/etc/mysql/conf.d/*".
Any particular configuration for the instance, would also be included in the 
main service!

Suggestion:
Use "/etc/mysql/my_%i.cnf" as the instance's config file.

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

Kernel: Linux 5.8.0-0.bpo.2-amd64 (SMP w/48 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.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mariadb-server-10.3 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.71
ii  galera-3  25.3.25-2
ii  gawk  1:4.2.1+dfsg-1
ii  iproute2  4.20.0-2
ii  libc6 2.28-10
ii  libdbi-perl   1.642-1+deb10u1
ii  libgnutls30   3.6.7-4+deb10u5
ii  libpam0g  1.3.1-5
ii  libstdc++68.3.0-6
ii  lsb-base  10.2019051400
ii  lsof  4.91+dfsg-1
ii  mariadb-client-10.3   1:10.3.27-0+deb10u1
ii  mariadb-common1:10.3.27-0+deb10u1
ii  mariadb-server-core-10.3  1:10.3.27-0+deb10u1
ii  passwd1:4.5-1.1
ii  perl  5.28.1-6+deb10u1
ii  psmisc23.2-1
ii  rsync 3.1.3-6
ii  socat 1.7.3.2-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages mariadb-server-10.3 recommends:
pn  libhtml-template-perl  

Versions of packages mariadb-server-10.3 suggests:
ii  mailutils [mailx]  1:3.5-4
pn  mariadb-test   
pn  netcat-openbsd 
pn  tinyca 

-- Configuration Files:
/etc/mysql/mariadb.conf.d/50-server.cnf changed [not included]

-- debconf information excluded



Bug#979647: ITP: nesi -- Network Equipment Simulator (NESi)

2021-01-09 Thread root
Package: wnpp
Severity: wishlist
Owner: root 

* Package name: nesi
  Version : 1.2
  Upstream Author : thola team 
* URL : https://github.com/inexio/NESi
* License : BSD 2-Clause License
  Programming Lang: Python
  Description : Network Equipment Simulator (NESi)

The goal of the project is to simulate the presence of a large number of 
network devices (such as switches, routers, modems etc) on the network.
These simulated devices expose their management interfaces and support 
command-line dialogues in a reasonably convincing way.
The main use-case for the software is to create a testing environment for 
network management and automation.



Bug#979646: ITP: thola -- A tool for monitoring and provisioning network devices.

2021-01-09 Thread root
Package: wnpp
Severity: wishlist
Owner: thola team 

* Package name: thola
  Version : 0.1.3
  Upstream Author : thola team 
* URL : https://thola.io/
* License : BSD-2-Clause License
  Programming Lang: Go
  Description : A tool for monitoring and provisioning network devices.

A tool for monitoring and provisioning network devices written in Go.
It features a check mode which complies with the monitoring plugins development 
guidelines and is therefore compatible with Nagios, Icinga, Zabbix, Checkmk, 
etc.

thola currently has three main modes of operation with various subcommands:

identify automatically identifies the device and outputs its vendor, model and 
other properties.
read - reads out values and statistics of the device.
  read available-components - returns the available components for the device.
  read interfaces - outputs the interfaces with several values like error 
counters and statistics.
  read count-interfaces - counts the interfaces.
  read cpu-load - returns the current cpu load of all CPUs.
  read memory-usage - reads out the current memory usage.
  read ups - outputs the special values of a UPS device.
check - performs checks that can be used in monitoring systems. Output is by 
default in check plugin format.
  check identify - compares the device properties with given expectations.
  check snmp - checks SNMP reachability.
  check interface-metrics - outputs performance data for the interfaces, 
including special values based on the interface type (e.g. Radio Interface).
  check cpu-load - checks the average CPU load of all CPUs against given 
thresholds and outputs the current load of all CPUs as performance data.
  check memory-usage - checks the current memory usage against given thresholds.
  check ups - checks if a UPS device has its main voltage applied and outputs 
additional performance data like battery capacity or current load, and compares 
them to optionally given thresholds.
  check metrics - outputs all possible metrics.
  check thola-server - checks reachability of a Thola API.



Bug#977659: linkchecker is in stable and testing, but missing in testing.

2020-12-18 Thread root
Package: linkchecker
Severity: important

Dear Maintainer,

I am missing linkchecker in testing. I can find it in stable and unstable, but 
not in testing.

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/40 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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



Bug#970720: reprepro: Processing of changes file produced with sbuild's --dpkg-file-suffix fails

2020-09-22 Thread root
Package: reprepro
Version: 5.3.0-1
Severity: normal

When using sbuild with --dpkg-file-suffix=_buildd, the resulting
changes files is named something like:

  hello_2.10-3_amd64_buildd.changes

It contains a reference to a buildinfo file named:

  hello_2.10-3_amd64_buildd.buildinfo

When trying to process this upload, reprepro chokes on this buildinfo
files, presumably because it parses the architecture as "amd64_buildd":

  'hello_2.10-3_amd64_buildd.changes' contains
  'hello_2.10-3_amd64_buildd.buildinfo' not matching an valid
  architecture in any distribution known!

The scenario at play here is producing binary packages from a
source-only upload: since the latter already contains a buildinfo
file, sbuild introduced --dpkg-file-suffix precisely so there wouldn't
be a conflict (see #869184 for more background information).

Cheers,

--
Seb

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

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

Versions of packages reprepro depends on:
ii  libarchive13   3.3.3-4+deb10u1
ii  libbz2-1.0 1.0.6-9.1
ii  libc6  2.28-10
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  libgpg-error0  1.35-1
ii  libgpgme11 1.12.0-6
ii  liblzma5   5.2.4-1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages reprepro recommends:
ii  apt  1.8.2

Versions of packages reprepro suggests:
ii  gpg-agent [gnupg-agent]  2.2.12-1+deb10u1
ii  inoticoming  0.2.3-2
pn  lzip 
ii  pinentry-curses  1.1.0-2

-- no debconf information



Bug#967010: apache2: last debian 10.4 , last apache avail from repo hangs on install (and start phase)

2020-08-03 Thread root
Package: apache2
Version: 2.4.38-3+deb10u3
Severity: grave
Justification: renders package unusable

Dear Maintainer,


   * What led up to the situation?
package installing
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
apt-get install apache2
   * What was the outcome of this action?
packages did not start
   * What outcome did you expect instead?
packages will start ok


I have fresh debian 10 install, OS after full upgrade with:
`apt-get upgrade` and
`apt-get dist-upgrade`

I want to install apache2 packages, it hang on install (on post-install phase 
when apache starts):

(*my findings why is below)

apt-get install apache2  
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  apache2-bin apache2-data apache2-utils libapr1 libaprutil1 
libaprutil1-dbd-sqlite3 libaprutil1-ldap libbrotli1 libjansson4 liblua5.2-0
Suggested packages:
  apache2-doc apache2-suexec-pristine | apache2-suexec-custom
The following NEW packages will be installed:
  apache2 apache2-bin apache2-data apache2-utils libapr1 libaprutil1 
libaprutil1-dbd-sqlite3 libaprutil1-ldap libbrotli1 libjansson4 liblua5.2-0
0 upgraded, 11 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B/2,606 kB of archives.
After this operation, 8,885 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Selecting previously unselected package libapr1:amd64.
(Reading database ... 85650 files and directories currently installed.)
Preparing to unpack .../00-libapr1_1.6.5-1+b1_amd64.deb ...
Unpacking libapr1:amd64 (1.6.5-1+b1) ...
Selecting previously unselected package libaprutil1:amd64.
Preparing to unpack .../01-libaprutil1_1.6.1-4_amd64.deb ...
Unpacking libaprutil1:amd64 (1.6.1-4) ...
Selecting previously unselected package libaprutil1-dbd-sqlite3:amd64.
Preparing to unpack .../02-libaprutil1-dbd-sqlite3_1.6.1-4_amd64.deb ...
Unpacking libaprutil1-dbd-sqlite3:amd64 (1.6.1-4) ...
Selecting previously unselected package libaprutil1-ldap:amd64.
Preparing to unpack .../03-libaprutil1-ldap_1.6.1-4_amd64.deb ...
Unpacking libaprutil1-ldap:amd64 (1.6.1-4) ...
Selecting previously unselected package libbrotli1:amd64.
Preparing to unpack .../04-libbrotli1_1.0.7-2_amd64.deb ...
Unpacking libbrotli1:amd64 (1.0.7-2) ...
Selecting previously unselected package libjansson4:amd64.
Preparing to unpack .../05-libjansson4_2.12-1_amd64.deb ...
Unpacking libjansson4:amd64 (2.12-1) ...
Selecting previously unselected package liblua5.2-0:amd64.
Preparing to unpack .../06-liblua5.2-0_5.2.4-1.1+b2_amd64.deb ...
Unpacking liblua5.2-0:amd64 (5.2.4-1.1+b2) ...
Selecting previously unselected package apache2-bin.
Preparing to unpack .../07-apache2-bin_2.4.38-3+deb10u3_amd64.deb ...
Unpacking apache2-bin (2.4.38-3+deb10u3) ...
Selecting previously unselected package apache2-data.
Preparing to unpack .../08-apache2-data_2.4.38-3+deb10u3_all.deb ...
Unpacking apache2-data (2.4.38-3+deb10u3) ...
Selecting previously unselected package apache2-utils.
Preparing to unpack .../09-apache2-utils_2.4.38-3+deb10u3_amd64.deb ...
Unpacking apache2-utils (2.4.38-3+deb10u3) ...
Selecting previously unselected package apache2.
Preparing to unpack .../10-apache2_2.4.38-3+deb10u3_amd64.deb ...
Unpacking apache2 (2.4.38-3+deb10u3) ...
Setting up libbrotli1:amd64 (1.0.7-2) ...
Setting up libapr1:amd64 (1.6.5-1+b1) ...
Setting up libjansson4:amd64 (2.12-1) ...
Setting up liblua5.2-0:amd64 (5.2.4-1.1+b2) ...
Setting up apache2-data (2.4.38-3+deb10u3) ...
Setting up libaprutil1:amd64 (1.6.1-4) ...
Setting up libaprutil1-ldap:amd64 (1.6.1-4) ...
Setting up libaprutil1-dbd-sqlite3:amd64 (1.6.1-4) ...
Setting up apache2-utils (2.4.38-3+deb10u3) ...
Setting up apache2-bin (2.4.38-3+deb10u3) ...
Setting up apache2 (2.4.38-3+deb10u3) ...
Enabling module mpm_event.
Enabling module authz_core.
Enabling module authz_host.
Enabling module authn_core.
Enabling module auth_basic.
Enabling module access_compat.
Enabling module authn_file.
Enabling module authz_user.
Enabling module alias.
Enabling module dir.
Enabling module autoindex.
Enabling module env.
Enabling module mime.
Enabling module negotiation.
Enabling module setenvif.
Enabling module filter.
Enabling module deflate.
Enabling module status.
Enabling module reqtimeout.
Enabling conf charset.
Enabling conf localized-error-pages.
Enabling conf other-vhosts-access-log.
Enabling conf security.
Enabling conf serve-cgi-bin.
Enabling site 000-default.
Created symlink /etc/systemd/system/multi-user.target.wants/apache2.service → 
/etc/systemd/system/apache2.service.
Created symlink 
/etc/systemd/system/multi-user.target.wants/apache-htcacheclean.service → 
/lib/systemd/system/apache-htcacheclean.service.

here it hangs. and after some time 

Job for apache2.service failed because a timeout was exceeded.
See "systemctl status apache2.service" and "journalctl -xe" for details.
invoke-rc.d: 

Bug#571210: command-not-found: crashes on start

2020-07-25 Thread root
Package: command-not-found
Version: 18.04.5-1
Followup-For: Bug #571210

Dear Maintainer,

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

the command-not-found crashes when the command is run i expected for it to work 
correctly 

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


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

Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.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

Versions of packages command-not-found depends on:
ii  apt-file 3.2.2
ii  lsb-release  11.1.0
ii  python3  3.8.2-3
ii  python3-apt  2.1.3

command-not-found recommends no packages.

Versions of packages command-not-found suggests:
pn  snapd  

-- no debconf information



Bug#965201: bnd update seems to be needed to build tomcat9 >= 9.0.37

2020-07-17 Thread root
Package: bnd
Version: 3.5.0-4
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

the debian provided tomcat9 package (version 9.0.37-1) has a problem. 9.0.36 
worked fine, but in 9.0.37 
the tomcat developers (upstream) started to use the -includepackage 
instruction, which is only found in 
bnd starting with version 4.x . - the official tomcat build script downloads 
the bnd 5.1.1 jar, which works
fine.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

using the old bnd version breaks the compile because it silently filters out 
classes of the generated jar files.

   * What outcome did you expect instead?

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


-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'proposed-updates'), (700, 
'stable'), (80, 'testing'), (70, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=de_AT:de (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bnd depends on:
ii  default-jre-headless [java8-runtime-headless] 2:1.11-71
ii  java-wrappers 0.3
ii  junit44.12-8
ii  libfelix-framework-java   4.6.1-2
ii  libfelix-gogo-runtime-java0.16.2-1
ii  libfelix-resolver-java1.14.0-1
ii  libosgi-annotation-java   6.0.0-2
ii  libosgi-compendium-java   6.0.0-1
ii  libosgi-core-java 6.0.0-1
ii  libslf4j-java 1.7.25-3
ii  libxz-java1.8-2
ii  libyaml-snake-java1.23-1
ii  openjdk-11-jre-headless [java8-runtime-headless]  11.0.7+10-3~deb10u1

Versions of packages bnd recommends:
pn  libbindex-java  

bnd suggests no packages.

-- no debconf information



Bug#965097: firejail: Firejail Disables U2F/WebAuthn By Default

2020-07-16 Thread Jeff Root
Package: firejail
Version: 0.9.58.2-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

   Upgraded from Debian 9 to Debian 10.

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

   Kept fiddling with Yubikey libs, u2f libs.  Unistall, purge, reinstall.  Ran
firefox-esr with extensions disabled, ran with fresh profile.

   I also tried removing the Security Device configuration item from the
browser.  I re-loaded the Security Device into the browser.

   * What was the outcome of this action?

   WebAuthn/U2F failed.  Test site demo.yubico.com. would not enable U2F
registration.

   * What outcome did you expect instead?

   I expected to use demo.yubico.com to register, then authenticate with my
Yubikey4.

   * What fixed the problem?

   I discovered that /etc/firejail/firejail.conf had

# Disable U2F in browsers, default enabled.
# browser-disable-u2f yes

   I uncommented that line, and changed it to "no" to solve the problem.

  I believe there are two problems here.  First, I don't see any reason why
WebAuthn would be disabled by default.  I'm not aware of any reason that would
improve security or usability.  Second, it was very difficult to understand
this setting; the man page documents BROWSER_DISABLE_U2F, and explains how to
_disable_ U2F, but not how to ENable U2F.  As Debian/upstream has it disabled
by default, I think it would be better for the man page to show how to enable
it, or preferably show how to enable it.  The documentation (and this is likely
an upstream issue) doesn't really describe how the profiles are used, what the
config file is for, or how to override these settings.  (For example, there's a
command line argument to firejail, --nou2f, but no sign of how to _not_ disable
U2F.

  I would suggest that Debian change that default setting to "no" so that U2F
works out of the box.



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

Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firejail depends on:
ii  libapparmor1  2.13.2-10
ii  libc6 2.28-10

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.58.2-2
ii  iproute2   4.20.0-2
ii  iptables   1.8.2-4
ii  xauth  1:1.0.10-1
ii  xserver-xephyr 2:1.20.4-1
ii  xvfb   2:1.20.4-1

firejail suggests no packages.

-- Configuration Files:
/etc/firejail/firejail.config changed [not included]

-- no debconf information



Bug#964072: clamav: freshclam update fails when using different working dir besides default /var/lib/clamav

2020-07-01 Thread root
Package: clamav
Version: 0.102.3+dfsg-0+deb10u1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
 -wanted to use a different dir for updating the virus signatures
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 -created a new folder with identical access rights (like /var/lib/clamav) 
and changed
  the DataBaseDirectory in clamd.conf and freshclam.conf accordingly
 -then attempted to run freshclam for update (automatic freshclam update 
eas stopped beforehand) 
   * What was the outcome of this action?
 -error message: !checkdbdir: Can't open directory /var/lib/clamavtest/
 !Update failed.
   * What outcome did you expect instead?
 -a successful update since the config files were correctly adjusted and 
the access rights of the dir are identical to the default

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


-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
AlertExceedsMax disabled
PreludeEnable disabled
PreludeAnalyzerName = "ClamAV"
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile disabled
TemporaryDirectory disabled
DatabaseDirectory = "/var/lib/clamavtest"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "26214400"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "30"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
ScanPE = "yes"
ScanELF = "yes"
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
HeuristicAlerts = "yes"
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
AlertBrokenExecutables disabled
AlertEncrypted disabled
AlertEncryptedArchive disabled
AlertEncryptedDoc disabled
AlertOLE2Macros disabled
AlertPhishingSSLMismatch disabled
AlertPhishingCloak disabled
AlertPartitionIntersection disabled
ScanPDF = "yes"
ScanSWF = "yes"
ScanXMLDOCS = "yes"
ScanHWP3 = "yes"
ScanArchive = "yes"
ForceToDisk disabled
MaxScanTime = "12"
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
MaxEmbeddedPE = "10485760"
MaxHTMLNormalize = "10485760"
MaxHTMLNoTags = "2097152"
MaxScriptNormalize = "5242880"
MaxZipTypeRcg = "1048576"
MaxPartitions = "50"
MaxIconsPE = "100"
MaxRecHWP3 = "16"
PCREMatchLimit = "1"
PCRERecMatchLimit = "5000"
PCREMaxFileSize = "26214400"
OnAccessMountPath disabled
OnAccessIncludePath disabled
OnAccessExcludePath disabled
OnAccessExcludeRootUID disabled
OnAccessExcludeUID disabled
OnAccessExcludeUname disabled
OnAccessMaxFileSize = "5242880"
OnAccessDisableDDD disabled
OnAccessPrevention disabled
OnAccessExtraScanning disabled
OnAccessCurlTimeout = "5000"
OnAccessMaxThreads = "5"
OnAccessRetryAttempts disabled
OnAccessDenyOnError disabled
DevACOnly disabled
DevACDepth disabled
DevPerformance disabled
DevLiblog disabled
DisableCertCheck disabled
AlgorithmicDetection = "yes"
BlockMax disabled
PhishingAlwaysBlockSSLMismatch disabled
PhishingAlwaysBlockCloak disabled
PartitionIntersection disabled
OLE2BlockMacros disabled
ArchiveBlockEncrypted disabled

Config file: freshclam.conf
---
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
PidFile disabled
DatabaseDirectory = "/var/lib/clamavtest"
Foreground disabled
Debug disabled
UpdateLogFile = "/var/log/clamav/freshclam.log"
DatabaseOwner = "clamav"
Checks = "24"
DNSDatabaseInfo = "current.cvd.clamav.net"
DatabaseMirror = "db.local.clamav.net", "database.clamav.net"
PrivateMirror disabled
MaxAttempts = "5"
ScriptedUpdates = "yes"
TestDatabases = "yes"
CompressLocalDatabase disabled
ExtraDatabase disabled
ExcludeDatabase disabled
DatabaseCustomURL disabled

Bug#959812: Acknowledgement (munin-plugins-core: varnish_ plugin no output (X not part of varnishstat))

2020-05-05 Thread root
This bug applies to all "aspects" of the munnin "varnish_" plugin. None of them 
produce any data in their graphs OOTB on Debian 10.

fwiw, `varnishstat` clearly *does* have output for 'uptime':

```
root@disp7450:~# varnishstat -x | grep -iC4 uptime



MGT.uptime
4961
c
d
Management process uptime


MGT.child_start
1
--
i
stat summ operations


MAIN.uptime
4961
c
d
Child process uptime


MAIN.sess_conn
    0
root@disp7450:~# 
```

Could this be an issue with varnish changing from v5 to v6 from Debian 9 to 
Debian 10?

 * https://packages.debian.org/source/stretch/varnish
 * https://packages.debian.org/source/buster/varnish

On Tue, May 05, 2020 at 04:51:02PM +, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 959812: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959812.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Munin Debian Maintainers 
> 
> If you wish to submit further information on this problem, please
> send it to 959...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> -- 
> 959812: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959812
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems



Bug#959812: munin-plugins-core: varnish_ plugin no output (X not part of varnishstat)

2020-05-05 Thread root
Package: munin-plugins-core
Version: 2.0.49-1
Severity: important



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

Kernel: Linux 4.19.107-1.pvops.qubes.x86_64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages munin-plugins-core depends on:
ii  munin-common  2.0.49-1
ii  perl  5.28.1-6

Versions of packages munin-plugins-core recommends:
ii  libnet-snmp-perl  6.0.1-5

Versions of packages munin-plugins-core suggests:
pn  acpi | lm-sensors 
pn  conntrack 
pn  default-mysql-client  
ii  ethtool   1:4.19-1
ii  hdparm9.58+ds-1
pn  libcache-cache-perl   
pn  libdbd-mysql-perl 
pn  libdbd-pg-perl
ii  libhttp-date-perl 6.02-1
pn  liblwp-useragent-determined-perl  
pn  libnet-dns-perl   
pn  libnet-ip-perl
pn  libnet-irc-perl   
pn  libnet-ldap-perl  
pn  libnet-netmask-perl   
pn  libnet-telnet-perl
ii  libxml-parser-perl2.44-4
pn  libxml-simple-perl
pn  logtail   
ii  net-tools 1.60+git20180626.aebd88e-1
ii  python3   3.7.3-1
ii  ruby  1:2.5.1
pn  smartmontools 

-- no debconf information

Steps to reproduce. First setup depends:

```
sudo su -
apt-get install varnish munin
echo -e '\n[varnish*]\nuser root\n' > /etc/munin/plugin-conf.d/z-varnish
```

Then running the 'varish_' plugin with the 'uptime' aspect produces nothing.


```
root@mail:/etc/munin# munin-run --debug --pidebug  varnish_uptime
# Processing plugin configuration from /etc/munin/plugin-conf.d/README
# Processing plugin configuration from /etc/munin/plugin-conf.d/dhcpd3
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/spamstats
# Processing plugin configuration from /etc/munin/plugin-conf.d/zzz-myconf
# Setting /rgid/ruid/ to /118/0/
# Setting /egid/euid/ to /118 118/0/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_uptime'
root@mail:/etc/munin#
```

But if I manually edit the 'varnish_' script to set DEBUG=1, then it says:

```
root@mail:/etc/munin# munin-run --debug --pidebug  varnish_uptime
# Processing plugin configuration from /etc/munin/plugin-conf.d/README
# Processing plugin configuration from /etc/munin/plugin-conf.d/dhcpd3
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/spamstats
# Processing plugin configuration from /etc/munin/plugin-conf.d/zzz-myconf
# Setting /rgid/ruid/ to /118/0/
# Setting /egid/euid/ to /118 118/0/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_uptime'
Error: uptime not part of varnishstat.
root@mail:/etc/munin#
```



Bug#954792: xfsdump: xfsrestore does not recreate missing inventory information

2020-03-23 Thread root
Package: xfsdump
Version: 3.1.6+nmu2+b1
Severity: normal

Dear Maintainer,

The xfsrestore man page states:

"
 An additional media file is placed at the end of each dump stream.  This media 
file contains the inventory information for the cur‐
 rent dump session.  If the online inventory files in 
/var/lib/xfsdump/inventory are missing information for the current  dump  ses‐
 sion,  then  the inventory information in the media file is automatically 
added to the files in /var/lib/xfsdump/inventory.  If you
 wish to incorporate the inventory information from the media file without 
restoring any data, you may do so using the -t option:

# xfsrestore -t -f /dev/tape

 This is useful to rebuild the inventory database if it is ever lost or 
corrupted.
"

However, I am observing that xfsrestore does not add this missing inventory 
information.

To reproduce

1) dump an XFS filesystem and note how new inventory information appears in 
/var/lib/xfs‐dump/inventory

For example (using a 50MiB loop device to demonstrate)

# ls /var/lib/xfsdump/inventory

Note the inventory files.

# dd if=/dev/zero of=/tmp/dump_test.img bs=$((1024*1024)) count=50
# mkfs.xfs /tmp/dump_test.img
# mount /tmp/dump_test.img /mnt -o loop
# xfsdump -F -L0 -f /tmp/dump_test.dump /mnt
# umount /mnt

# ls -l /var/lib/xfsdump/inventory

Note how the xfsdump will have created an inventory file

2) remove inventory file from /var/lib/xfs‐dump/inventory

rm previously noted file.

3) list contents of dump file

# xfsrestore -t -f /tmp/dump_test.dump

4) Observe xfsrestore has not recreated the missing inventory information (file 
deleted in 2)


This behaviour is inconsistent with the man page which indicates that 
xfsrestore can be used to rebuild the inventory database if it is ever lost or 
corrupted.

I noticed this with xfsrestore 3.1.6 (on a Debian 9.12 host), then I git cloned 
xfsdump-dev, built from source and observed the same behaviour in xfsrestore 
3.1.9.




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

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

Versions of packages xfsdump depends on:
ii  libattr1 1:2.4.47-2+b2
ii  libc62.24-11+deb9u4
ii  libncurses5  6.0+20161126-1+deb9u2
ii  libtinfo56.0+20161126-1+deb9u2
ii  libuuid1 2.29.2-1+deb9u1
ii  xfsprogs 4.9.0+nmu1

xfsdump recommends no packages.

Versions of packages xfsdump suggests:
ii  acl2.2.52-3+b1
ii  attr   1:2.4.47-2+b2
pn  quota  

-- no debconf information


Bug#948553: Tomcat9 startup script ignores CATALINA_PID

2020-02-19 Thread root
Package: tomcat9
Version: 9.0.16-4
Followup-For: Bug #948553

Dear Maintainer,

the bug is still in the last version of stable.

The error is that \&\& should be just \&

Would be nice if this could be fixed soon.


Sincerley,
DaB.


-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (910, 'stable-updates'), (900, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages tomcat9 depends on:
ii  lsb-base10.2019051400
ii  systemd 241-7~deb10u3
ii  tomcat9-common  9.0.16-4
ii  ucf 3.0038+nmu1

Versions of packages tomcat9 recommends:
ii  libtcnative-1  1.2.21-1

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

-- no debconf information



Bug#903093: Debian Bug#903093 ddir: Spurious close on dirhandle

2020-01-08 Thread root


Fixed in latest upstream Git

https://github.com/jaalto/project--perl-ddir

There are no releases. Package directly from Git.
Jari



Bug#943884: prometheus: Loosing all the historical data on upgrade to version 2+

2019-10-31 Thread root
Package: prometheus
Version: 1.5.2+ds-2+b3
Severity: important

Dear Maintainer,

I've blindly upgraded prometheus 1.5.2+ds-2+b3 to 2.7.1+ds-3+b11 and this 
automatically removed all my historical data from /var/lib/prometheus/metrics/. 
I had to rollback because new version requires new configuration and finding 
solution on keeping historical data. As developers provided no way to convert 
to new format most probable solution will be to stuck on pre 2.0 version. 
Dramatic changes like that are dangerous and should not happen so easy.


-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), 
(81, 'testing'), (80, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages prometheus depends on:
ii  daemon   0.6.4-1+b2
ii  libc62.28-10
ii  libjs-bootstrap  3.4.1+dfsg-1
ii  libjs-eonasdan-bootstrap-datetimepicker  4.17.47-3
ii  libjs-jquery 3.3.1~dfsg-3
ii  libjs-jquery-hotkeys 0~20130707+git2d51e3a9+dfsg-2
ii  libjs-moment 2.24.0+ds-1
ii  libjs-mustache   2.3.2-1
ii  libjs-rickshaw   1.5.1.dfsg-2

Versions of packages prometheus recommends:
ii  prometheus-node-exporter  0.17.0+ds-3+b11

prometheus suggests no packages.

-- Configuration Files:
/etc/default/prometheus changed [not included]
/etc/prometheus/prometheus.yml changed [not included]

-- debconf information:
  prometheus/remove-version1-database: true



Bug#942875: debootstrap does not overwrite existing files even if adviced to do

2019-10-22 Thread root
Package: debootstrap
Version: 1.0.116
Severity: serious
Tags: d-i



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

Kernel: Linux 5.2.0-3-amd64 (SMP w/1 CPU core)
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 debootstrap depends on:
ii  wget  1.20.3-1+b1

Versions of packages debootstrap recommends:
ii  arch-test   0.16-2
ii  debian-archive-keyring  2019.1
ii  gnupg   2.2.17-3

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

-- no debconf information

If you intentionaly unpack a system to unclean disks (knowing the same
system being installed), debootstrap warns about overwriting files.
Since this is ok to you, you'll confirm this. BUT: debootstrap does not,
as mentioned, overwrite files, instead it stops as soon as a file it
tries to unpack exists.
I'd awaited debootstrap to do waht it warned me for before it started:
intentionally overwrite files.

I suppose this a bug, since debootstrap did warn before it would
overwrite files!



Bug#942494: apt / apt-get break on broken mirrors

2019-10-17 Thread root
Package: apt
Version: 1.9.4
Severity: normal
Tags: d-i

Dear Maintainer,

   * What led up to the situation?
 Just tried to upgrade to latest available packages using
 "apt update".

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Tried to switch to an other mirror, but was again redirected to the
 broken mirror. 

   * What was the outcome of this action?
 Unable to upgrade to latest packages.
 Unable to install newer packages.

   * What outcome did you expect instead?
 apt shall drop this mirror, accessing the next best one until it
 finds a non broken one.
 If this list is exausted apt / apt-get shall print a warning and
 just ignore this mirror, but go on working, installing what it
 available for upgrades.
 if this is already configurable, it should be the default
 behaviour for apt / apt-get.

-- Package-specific info:
Same for all available releases:
stable, testing, unstable, experimental

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-image-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-headers-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-modules-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^.*-modules-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-tools-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-source-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-source-5\.2\.0-2-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-modules";
APT::VersionedKernelPackages:: "linux-modules-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "linux-image-unsigned";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::VersionedKernelPackages:: "linux-cloud-tools";
APT::VersionedKernelPackages:: "linux-buildinfo";
APT::VersionedKernelPackages:: "linux-source";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";

Bug#942172: clamav-daemon: After upgrade, clamd cannon create /var/run/clamav/clamd.ctl and stop.

2019-10-11 Thread root
Package: clamav-daemon
Version: 0.101.4+dfsg-0+deb8u1
Severity: normal

Dear Maintainer,

I've just upgraded ClamAV on jessie, but clamav does not restart. On log i
get:

  Oct 11 09:02:40 ibrsamba clamd[28918]: Fri Oct 11 09:02:40 2019 -> !LOCAL: 
Socket file /var/run/clamav/clamd.ctl could not be bound: Permission denied
  Oct 11 09:02:40 ibrsamba systemd[1]: clamav-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
  Oct 11 09:02:40 ibrsamba systemd[1]: clamav-daemon.service: Unit entered 
failed state.
  Oct 11 09:02:40 ibrsamba systemd[1]: clamav-daemon.service: Failed with 
result 'exit-code'.

Looking at clamav run folder:

ibrsamba:~# ls -la /var/run/clamav/
totale 0
drwxr-xr-x  2 root root   40 ott 11 09:01 .
drwxr-xr-x 33 root root 1060 set 13 12:14 ..

doing simply:

chown clamav /var/run/clamav

permit me to correctly restart clamav. Now:

ibrsamba:~# ls -la /var/run/clamav/
totale 0
drwxr-xr-x  2 clamav root 60 ott 11 12:57 .
drwxr-xr-x 33 root   root   1060 set 13 12:14 ..
srw-rw-rw-  1 clamav clamav0 ott 11 12:57 clamd.ctl

Thanks.

-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
AlertExceedsMax disabled
PreludeEnable disabled
PreludeAnalyzerName = "ClamAV"
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog = "yes"
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile disabled
TemporaryDirectory disabled
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "26214400"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "5"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
ScanPE = "yes"
ScanELF = "yes"
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
HeuristicAlerts = "yes"
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
AlertBrokenExecutables disabled
AlertEncrypted disabled
AlertEncryptedArchive disabled
AlertEncryptedDoc disabled
AlertOLE2Macros disabled
AlertPhishingSSLMismatch disabled
AlertPhishingCloak disabled
AlertPartitionIntersection disabled
ScanPDF = "yes"
ScanSWF = "yes"
ScanXMLDOCS = "yes"
ScanHWP3 = "yes"
ScanArchive = "yes"
ForceToDisk disabled
MaxScanTime = "12"
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
MaxEmbeddedPE = "10485760"
MaxHTMLNormalize = "10485760"
MaxHTMLNoTags = "2097152"
MaxScriptNormalize = "5242880"
MaxZipTypeRcg = "1048576"
MaxPartitions = "50"
MaxIconsPE = "100"
MaxRecHWP3 = "16"
PCREMatchLimit = "1"
PCRERecMatchLimit = "5000"
PCREMaxFileSize = "26214400"
ScanOnAccess disabled
OnAccessMountPath disabled
OnAccessIncludePath disabled
OnAccessExcludePath disabled
OnAccessExcludeRootUID disabled
OnAccessExcludeUID disabled
OnAccessMaxFileSize = "5242880"
OnAccessDisableDDD disabled
OnAccessPrevention disabled
OnAccessExtraScanning disabled
DevACOnly disabled
DevACDepth disabled
DevPerformance disabled
DevLiblog disabled
DisableCertCheck disabled
AlgorithmicDetection = "yes"
BlockMax disabled
PhishingAlwaysBlockSSLMismatch disabled
PhishingAlwaysBlockCloak disabled
PartitionIntersection disabled
OLE2BlockMacros disabled
Arch

Bug#931532: sudo-ldap ignores NOPASSWD in /etc/sudoers when running commands

2019-07-07 Thread root
Package: sudo-ldap
Version: 1.8.27-1
Severity: normal

Dear maintainer,

I upgraded Debian from 9.9 to 10.0 yesterday and find that I have to
enter my password when running commands with sudo. We have no
!authenticate option on our LDAP server so we manually add NOPASSWD in
/etc/sudoers. However, after upgrading to buster, the NOPASSWD option
seems not working.

The running result of sudo -l still contains NOPASSWD:

steven@vpn:~$ sudo -l
Matching Defaults entries for steven on vpn:
env_reset, mail_badpass, 
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User steven may run the following commands on vpn:
(ALL : ALL) NOPASSWD: ALL
(ALL) ALL
(ALL) ALL

The changelog of sudo-ldap does not show it has put a higher priority in
the LDAP server's configuration, so I think this should be a bug.

Regards,
Zhaofeng Yang

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

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

Versions of packages sudo-ldap depends on:
ii  libaudit1   1:2.8.4-3
ii  libc6   2.28-10
ii  libldap-2.4-2   2.4.47+dfsg-3
ii  libpam-modules  1.3.1-5
ii  libpam0g1.3.1-5
ii  libselinux1 2.8-1+b1
ii  lsb-base10.2019051400

sudo-ldap recommends no packages.

sudo-ldap suggests no packages.

-- Configuration Files:
/etc/sudoers changed:
Defaultsenv_reset
Defaultsmail_badpass
Defaults
secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
rootALL=(ALL:ALL) ALL
%sudo   ALL=(ALL:ALL) NOPASSWD:ALL


-- no debconf information



Bug#929961: chrony: "systemctl start chrony" starts chronyd, then kills it because systemd-tty-ask-password-agent times out

2019-06-04 Thread root
Package: chrony
Version: 3.0-4+deb9u2
Severity: important

Dear Maintainer,

   * What led up to the situation?
 Installing Raspian via NOOBS, updating to latest packages.
 Install gpsd, chrony.
 Configure chrony.
 Try to start chrony using "systemctl start chrony"

   * What exactly did you do (or not do) that was effective (or ineffective)?
 Tried to get rid of systemd-tty-ask-password-agent. But this did not help 
in any way.

   * What was the outcome of this action?
 chronyd is started.
 "systemctl start chrony" waits until it times out on waiting for 
"/bin/systemd-tty-ask-password-agent --watch" to finish.
 chronyd is shut down by systemctl.

   * What outcome did you expect instead?
 chronyd started by "systemctl start chrony".


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 9.9 (stretch)
Release:9.9
Codename:   stretch
Architecture: armv7l

Kernel: Linux 4.19.42-v7+ (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 chrony depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  iproute2 4.9.0-1+deb9u1
ii  libc62.24-11+deb9u4
ii  libcap2  1:2.25-1
ii  libedit2 3.1-20160903-3
ii  libseccomp2  2.3.1-2.1+deb9u1
ii  libtomcrypt0 1.17-9
ii  lsb-base 9.20161125+rpi1
ii  ucf  3.0036
ii  util-linux   2.29.2-1+deb9u1

chrony recommends no packages.

chrony suggests no packages.

-- no debconf information



Bug#929962: chrony: "systemctl start chrony" starts chronyd, then kills it because systemd-tty-ask-password-agent times out

2019-06-04 Thread root
Package: chrony
Version: 3.0-4+deb9u2
Severity: important

Dear Maintainer,

   * What led up to the situation?
 Installing Raspian via NOOBS, updating to latest packages.
 Install gpsd, chrony.
 Configure chrony.
 Try to start chrony using "systemctl start chrony"

   * What exactly did you do (or not do) that was effective (or ineffective)?
 Tried to get rid of systemd-tty-ask-password-agent. But this did not help 
in any way.

   * What was the outcome of this action?
 chronyd is started.
 "systemctl start chrony" waits until it times out on waiting for 
"/bin/systemd-tty-ask-password-agent --watch" to finish.
 chronyd is shut down by systemctl.

   * What outcome did you expect instead?
 chronyd started by "systemctl start chrony".


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 9.9 (stretch)
Release:9.9
Codename:   stretch
Architecture: armv7l

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

Versions of packages chrony depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  iproute2 4.9.0-1+deb9u1
ii  libc62.24-11+deb9u4
ii  libcap2  1:2.25-1
ii  libedit2 3.1-20160903-3
ii  libseccomp2  2.3.1-2.1+deb9u1
ii  libtomcrypt0 1.17-9
ii  lsb-base 9.20161125+rpi1
ii  ucf  3.0036
ii  util-linux   2.29.2-1+deb9u1

chrony recommends no packages.

chrony suggests no packages.

-- no debconf information



Bug#929921: gpsd picks the wrong /dev/pps-device

2019-06-03 Thread root
Package: gpsd
Version: 3.16-4
Severity: normal

Hi,

Situation:
- system with gps connected to serial port, pps to a gpio-pin
- two serial ports: /dev/ttyAMA0 and /dev/ttyS0
- gps is connected to /dev/ttyAMA0

Receiving and processing NMEA data works fine. The problem though is that gpsd 
opens the wrong /dev/pps device and thus doesn't receive the pps signal.

gpsd   431 451   gpsd6u  CHR 204,64  0t0   6063 
/dev/ttyAMA0
gpsd   431 451   gpsd7u  CHR  240,1  0t0  12379 
/dev/pps1

root@autobd2:~# cat /sys/devices/virtual/pps/pps0/assert
1559545038.000242375#26895
root@autobd2:~# cat /sys/devices/virtual/pps/pps1/assert
0.0#0



-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 9.3 (stretch)
Release:9.3
Codename:   stretch
Architecture: armv6l

Kernel: Linux 4.19.42+
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gpsd depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  libbluetooth35.43-2+rpt2+deb9u2
ii  libc62.24-11+deb9u1
ii  libdbus-1-3  1.10.24-0+deb9u1
ii  libgps22 3.16-4
ii  libusb-1.0-0 2:1.0.21-1
ii  lsb-base 9.20161125+rpi1
ii  netbase  5.4
ii  systemd-sysv 232-25+deb9u1

Versions of packages gpsd recommends:
ii  python  2.7.13-2
ii  udev232-25+deb9u1

Versions of packages gpsd suggests:
ii  dbus  1.10.24-0+deb9u1
ii  gpsd-clients  3.16-4

-- no debconf information



Bug#901965: hid2hci.patch

2019-04-27 Thread Тут Root

*** lib_udev_rules.d_97-hid2hci.rules	2019-04-27 13:11:06.009105863 +0300
--- /lib/udev/rules.d/97-hid2hci.rules	2019-04-27 13:54:48.747630419 +0300
*** SUBSYSTEM!="usb*", GOTO="hid2hci_end"
*** 8,13 
--- 8,14 
  # Known supported devices: 413c:8154, 413c:8158, 413c:8162
  ATTR{bInterfaceClass}=="03", ATTR{bInterfaceSubClass}=="01", ATTR{bInterfaceProtocol}=="02", \
ATTRS{bDeviceClass}=="00", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
+   DRIVER=="usbhid", \
RUN+="hid2hci --method=dell --devpath=%p", ENV{HID2HCI_SWITCH}="1"
  
  # Logitech devices


Bug#925953: simple-cdd: Silently fails to start gpg with long paths

2019-03-29 Thread root
Package: simple-cdd
Version: 0.6.5
Severity: normal
User: de...@kali.org
Usertags: origin-kali

When working within a long path, gpg-agent can't start and fails with an
explicity error message like the following:

  gpg-agent: socket name 
'/path/to/super/long/and/deeply/buried/directory/.../S.gpg-agent.browser' is 
too long

However, within a simple-cdd context, that same error isn't captured and
simple-cdd fails without exposing the original cause of the problem:

  DEBUG Checking configuration...
  DEBUG Creating build environment in 
/localstore/ws/jenkinsbuild/sbxMainAsan/common/debian/install/simple-cdd...
  ERROR GPG standard error: gpg: keybox 
'/localstore/ws/jenkinsbuild/sbxMainAsan/common/debian/install/simple-cdd/tmp/gpg-keyring/pubring.kbx'
 created
  [...]
  ERROR GPG standard error: gpg: can't connect to the agent: IPC connect call 
failed
  [...]
  ERROR GPG standard error:
  ERROR Importing /usr/share/keyrings/debian-archive-keyring.gpg into 
/localstore/ws/jenkinsbuild/sbxMainAsan/common/debian/install/simple-cdd/tmp/gpg-keyring
 failed, gpg error code 2

It would be good if simple-cdd could notice that the gpg-agent didn't
start, and tell the user how it failed.

The issue can be worked around by forcing simple-cdd to use a different
GNUPGHOME: exporting the GNUPGHOME environment variable to something
shorter, and setting simple-cdd's user_gnugphome the same, seem to do
the trick.

Cheers,

-- 
Seb

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

Kernel: Linux 4.19.0-3-amd64 (SMP w/36 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages simple-cdd depends on:
ii  dctrl-tools 2.24-2+b1
ii  debian-cd   3.1.20
ii  lsb-release 9.20161125
ii  python3 3.5.3-1
ii  python3-simple-cdd  0.6.5
ii  reprepro5.1.1-1
ii  rsync   3.1.2-1+deb9u1
ii  wget1.18-5+deb9u2

Versions of packages simple-cdd recommends:
ii  dose-distcheck  5.0.1-8+deb9u1

Versions of packages simple-cdd suggests:
pn  qemu-system | qemu-kvm  

-- no debconf information



Bug#925135: linux-image-4.9.0-8-amd64: WARNING at linux-4.9.130/fs/btrfs/extent-tree.c:8330 btrfs_alloc_tree_block+0x3fa/0x4d0

2019-03-20 Thread root
Package: src:linux
Version: 4.9.144-3.1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
  - occurs sometimes during nightly "rsync backup" (high disk load)
  - "backup" is done via "rsync --inplace" and than a "btrfs snapshot" of 
is done
  - the "root cause" is probably intensive directory traversal by rsync
  - some informative graphs (might be useful) are here (backup disks are 
SDC & SDD in raid1): 
  --- https://uctuj.eu/munin/uctuj.eu/server1.uctuj.eu/index.html#disk

   * The "most similar" bug:
  - #877763


-- Package-specific info:
** Version:
Linux version 4.9.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.144-3.1 (2019-02-19)

** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-8-amd64 
root=UUID=2bb3dd49-5cb0-4ef3-92dc-239d920ffae3 ro ipv6.disable=1 console=tty0 
earlyprintk=tty0 nmi_watchdog=panic,1 panic=10 video=efifb:1024x768x32 
default_hugepagesz=1G hugepagesz=1G hugepages=50 l1tf=off pti=off kpti=off 
noibrs noibpb spectre_v2=off spec_store_bypass_disable=off elevator=deadline

** Tainted: WIO (6656)
 * Taint on warning.
 * Working around severe firmware bug.
 * Out-of-tree module has been loaded.

** Kernel log:
[1743001.979071] [ cut here ]
[1743001.987392] WARNING: CPU: 3 PID: 11493 at 
/build/linux-EbeuWA/linux-4.9.130/fs/btrfs/extent-tree.c:8330 
btrfs_alloc_tree_block+0x3fa/0x4d0 [btrfs]
[1743002.004455] Modules linked in: nls_utf8 cifs sha256_ssse3 cmac md4 
des_generic arc4 dns_resolver ipt_REJECT nf_reject_ipv4 xt_recent nf_log_ipv4 
nf_log_common xt_LOG xt_conntrack xt_mark xt_nat xt_comment xt_tcpudp 
iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 vhost_net vhost 
macvtap macvlan ebtable_filter ebtables ip6table_filter ip6_tables tun 
iptable_filter ip_tables ipmi_devintf x_tables cpufreq_userspace 
cpufreq_powersave cpufreq_conservative autofs4 binfmt_misc nfsd auth_rpcgss 
oid_registry nfs_acl nfs lockd grace fscache sunrpc fuse ext4 crc16 jbd2 
fscrypto ecb mbcache nf_nat_sip nf_nat_ftp nf_nat nf_conntrack_proto_udplite 
nf_conntrack_proto_sctp nf_conntrack_sip nf_conntrack_snmp 
nf_conntrack_broadcast nf_conntrack_ftp nf_conntrack_pptp 
nf_conntrack_proto_gre nf_conntrack dummy
[1743002.057687]  bridge stp llc loop intel_powerclamp coretemp kvm_intel kvm 
irqbypass crct10dif_pclmul crc32_pclmul amdkfd radeon iTCO_wdt 
iTCO_vendor_support sg ghash_clmulni_intel ttm drm_kms_helper intel_cstate 
lpc_ich hpilo drm intel_uncore hpwdt mfd_core pcspkr i7core_edac shpchp 
i2c_algo_bit ipmi_si pcc_cpufreq ipmi_msghandler button edac_core evdev 
serio_raw raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor 
async_tx libcrc32c raid0 multipath linear dm_mirror dm_region_hash dm_log btrfs 
crc32c_generic xor raid6_pq dm_mod raid1 md_mod sd_mod hid_generic usbhid hid 
crc32c_intel ahci libahci aesni_intel aes_x86_64 glue_helper lrw gf128mul 
ehci_pci hpsa uhci_hcd ablk_helper libata ehci_hcd scsi_transport_sas cryptd 
psmouse usbcore nvme usb_common bnx2 nvme_core scsi_mod thermal
[1743002.117814] CPU: 3 PID: 11493 Comm: kworker/u64:16 Tainted: G  I   
  4.9.0-8-amd64 #1 Debian 4.9.130-2
[1743002.126372] Hardware name: HP ProLiant DL380 G6, BIOS P62 05/21/2018
[1743002.134978] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
[1743002.143186]   bc733d74 b1758eb5f940 

[1743002.151584]  bc47a59e 9ca6098fa158 b1758eb5f998 
4000
[1743002.160121]   9ca6098fa000 9c954267b1e0 
bc47a61f
[1743002.168057] Call Trace:
[1743002.175904]  [] ? dump_stack+0x5c/0x78
[1743002.183809]  [] ? __warn+0xbe/0xe0
[1743002.191455]  [] ? warn_slowpath_fmt+0x5f/0x80
[1743002.199079]  [] ? insert_state+0xc1/0x120 [btrfs]
[1743002.206631]  [] ? ___ratelimit+0xa3/0xf0
[1743002.213899]  [] ? btrfs_alloc_tree_block+0x3fa/0x4d0 
[btrfs]
[1743002.221254]  [] ? add_delayed_ref_tail_merge+0x5f/0x320 
[btrfs]
[1743002.228794]  [] ? kmem_cache_alloc+0x11c/0x530
[1743002.235601]  [] ? add_delayed_tree_ref+0xbf/0x170 [btrfs]
[1743002.242827]  [] ? __btrfs_cow_block+0x150/0x590 [btrfs]
[1743002.249404]  [] ? btrfs_cow_block+0x100/0x1a0 [btrfs]
[1743002.256423]  [] ? push_leaf_right+0x120/0x1e0 [btrfs]
[1743002.263150]  [] ? split_leaf+0x49b/0x6c0 [btrfs]
[1743002.269722]  [] ? btrfs_search_slot+0x9a4/0xa00 [btrfs]
[1743002.275979]  [] ? btrfs_csum_file_blocks+0x39c/0x5f0 
[btrfs]
[1743002.282330]  [] ? add_pending_csums.isra.45+0x46/0x70 
[btrfs]
[1743002.288617]  [] ? btrfs_finish_ordered_io+0x341/0x6d0 
[btrfs]
[1743002.294281]  [] ? btrfs_scrubparity_helper+0xd4/0x2f0 
[btrfs]
[1743002.300397]  [] ? process_one_work+0x18a/0x420
[1743002.306009]  [] ? worker_thread+0x4d/0x490
[1743002.311475]  [] ? process_one_work+0x420/0x420
[1743002.317384]  [] ? kthread+0xd9/0xf0
[1743002.322611]  

Bug#919758: xen-hypervisor-4.8-amd64: Wrong examples provided in GRUB config file

2019-01-19 Thread root
Package: src:xen
Version: 4.8.5+shim4.10.2+xsa282-1+deb9u11
Severity: minor

Dear Maintainer,

the GRUB configuration file /etc/defaults/grub.d/xen.cfg contains incorrect 
examples:

1. Bad syntax for dom0 memory allocation settings:

   https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#list

   Bad syntax (max value is ignored this way): dom0_mem=[M]:max=[M]
   Correct syntax: dom0_mem=[M],max:[M]

2. Bad syntax for earlyprintk usage:

   
https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt

   Bad syntax: earlyprintk=xenboot
   Correct syntax: earlyprintk=xen

Please correct the examples to avoid confusion for users new to Xen (like 
myself).

Thanks,
Gergely

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=locale: Cannot set LC_CTYPE 
to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968), LANGUAGE=en_US:en (charmap=locale: Cannot set LC_CTYPE to 
default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

xen-hypervisor-4.8-amd64 depends on no packages.

Versions of packages xen-hypervisor-4.8-amd64 recommends:
ii  xen-utils-4.8  4.8.5+shim4.10.2+xsa282-1+deb9u11

xen-hypervisor-4.8-amd64 suggests no packages.

-- Configuration Files:
/etc/default/grub.d/xen.cfg changed:
XEN_OVERRIDE_GRUB_DEFAULT=1
echo "Including Xen overrides from /etc/default/grub.d/xen.cfg"
GRUB_CMDLINE_XEN="dom0_mem=2048M,max:2048M dom0_max_vcpus=1 dom0_vcpus_pin 
console=vga"
GRUB_CMDLINE_LINUX_XEN_REPLACE="$GRUB_CMDLINE_LINUX earlyprintk=xen 
console=hvc0"
if [ "$XEN_OVERRIDE_GRUB_DEFAULT" = "" ]; then
echo "WARNING: GRUB_DEFAULT changed to boot into Xen by default!"
echo " Edit /etc/default/grub.d/xen.cfg to avoid this warning."
XEN_OVERRIDE_GRUB_DEFAULT=1
fi
if [ "$XEN_OVERRIDE_GRUB_DEFAULT" = "1" ]; then
GRUB_DEFAULT="Debian GNU/Linux, with Xen hypervisor"
fi



Bug#913427: rsyslog emits garbage to FIFOs

2018-11-10 Thread root
Package: rsyslog
Version: 8.24.0-1
Severity: important

Dear Maintainer,

I just upgraded my system, and rsyslog is writing nothing but garbage to FIFOs. 
 This makes rsyslog nearly useless for me, and I need a working remote syslog 
daemon and rsyslog appears to be the only option anymore.

I have
*.* |/root/syslog
in /etc/rsyslog.conf, where /root/syslog is a FIFO.  Rsyslog's output looks 
like this:

28-11T44:6753-50 laionp[48] eev:Uepce rgntmsap0d9b1.d321de o ac og0d9b7.e8bffo 
y_cie12248.0xt0d9b9.ac282018-11-10T14:48:46.775383-05:00 albarino 
liblogging-stdlog: action 'action 13' resumed (module 'builtin:ompipe') 
[v8.24.0 try http://www.rsyslog.com/e/2359 ]
018-1-1T44:280850:0 larn td386:rcev: nxpce rgn ietm xd9b1.d335 dsnt achar 
0d9b7.ff604frmsm_cie@3.048.5 m 0d9b48b7c962018-11-10T1449:58.805-50alaiosh[4] 
eahpby etp hd o  ukycetKyys[ruh
011T45:1011-50 lbrn sd34] cetdpswr o otfo 66.0.7 ot555sh
281-01:00.242-50 lbrn ytm[35] iteigo nP rporpi gn shaeteulto)
2018-11-10T14:50:01.12597-0:00abrn ytmd31:Lseigo nP rporpi gn n sprs ah rsrce)

The log messages sent to rsyslog don't look anything like that.

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

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

Versions of packages rsyslog depends on:
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u3
ii  libestr0 0.1.10-2
ii  libfastjson4 0.99.4-1
ii  liblogging-stdlog0   1.0.5-2+b2
ii  liblognorm5  2.0.1-1.1+b1
ii  libsystemd0  232-25+deb9u6
ii  libuuid1 2.29.2-1+deb9u1
ii  lsb-base 9.20161125
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages rsyslog recommends:
ii  logrotate  3.11.0-0.1

Versions of packages rsyslog suggests:
pn  rsyslog-doc
pn  rsyslog-gnutls 
pn  rsyslog-gssapi 
pn  rsyslog-mongodb
pn  rsyslog-mysql | rsyslog-pgsql  
pn  rsyslog-relp   

-- Configuration Files:
/etc/rsyslog.conf changed:
module(load="imuxsock") # provides support for local system logging
module(load="imklog")   # provides kernel logging support
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
$WorkDirectory /var/spool/rsyslog
$IncludeConfig /etc/rsyslog.d/*.conf
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none  -/var/log/syslog
daemon.*-/var/log/daemon.log
kern.*  -/var/log/kern.log
lpr.*   -/var/log/lpr.log
mail.*  -/var/log/mail.log
user.*  -/var/log/user.log
mail.info   -/var/log/mail.info
mail.warn   -/var/log/mail.warn
mail.err/var/log/mail.err
*.=debug;\
auth,authpriv.none;\
news.none;mail.none -/var/log/debug
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none  -/var/log/messages
*.emerg :omusrmsg:*
*.* |/root/syslog


-- no debconf information



Bug#912446: lvm2: The spanshot is bound to a volume on which two Windows NTFS-partition were created. "Partprobe" exposes these partitions to devmapper (and "mount", "partclon.ntfs" etc)

2018-10-31 Thread root
Package: lvm2
Version: 2.02.176-4.1
Severity: important

Dear Maintainer,

   * What led up to the situation?
- install Window OS on an LV volume 
- create a snapssot of this volume
- run "partprobe" (it'll expose these partitions to "devmapper" (and 
"mount", "partclon.ntfs" etc as well)
- try to remove the snapshot with:
  $ lvremove 

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   - caliing "kpartx" then twice "lvremove":
 $ kpartx -d /dev// && lvremove /dev// || 
lvremove /dev//

   * What was the outcome of this action?
   - it works but with alarming:
   
   $ root@comp:/home/user# sudo kpartx -d /dev/wholeraidvg/win2016dc-ss && 
sudo lvremove /dev/wholeraidvg/win2016dc-ss || sudo lvremove 
/dev/wholeraidvg/win2016dc-ss
Do you really want to remove active logical volume 
wholeraidvg/win2016dc-ss? [y/n]: yes
Device wholeraidvg-win2016dc--disk-real (253:8) is used by another 
device.
Failed to resume win2016dc-disk.
Releasing activation in critical section.
Do you really want to remove active logical volume 
wholeraidvg/win2016dc-ss? [y/n]: yes
Logical volume "win2016dc-ss" successfully removed


-- System Information:
Debian Release: 8.1
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.90-2.2
ii  dmsetup   2:1.02.145-4.1
ii  libblkid1 2.32.1-0.1
ii  libc6 2.27-5
ii  libdevmapper-event1.02.1  2:1.02.90-2.2
ii  libdevmapper1.02.12:1.02.145-4.1
ii  liblvm2app2.2 2.02.176-4.1
ii  libreadline5  5.2+dfsg-2
ii  libsystemd0   233-9
ii  libudev1  234-2
ii  lsb-base  4.1+Debian13+nmu1

Versions of packages lvm2 recommends:
ii  thin-provisioning-tools  0.7.4-2

lvm2 suggests no packages.

-- no debconf information



Bug#910508: lxde-common: closed bug #760971 still not fixed on debian 9.5 and lxde-common 0.99.2-3

2018-10-07 Thread root
Package: lxde-common
Version: 0.99.2-3
Severity: important

Dear Maintainer,

   * What led up to the situation?

   Installing fresh minimal debian 9.5 netinstall and wanted to have a
   minimal lxde. A find that closed reported bug #760971 describes
   exactly what I experienced.

   I don't know enough to put panels and check if I can recover it.
   
   killing lxpanel gets launched again with a new PID so I cannot try to
   launch lxpnael withough --profile argument

   I tried to copy panels from /etc/xdg but it does not work but it
   could be that I'm copying things in the wrong place.

   I did an apt-get update; apt-ge upgrade to use the lastest packets
   available. Still not working.

-- 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-8-rt-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

lxde-common depends on no packages.

Versions of packages lxde-common recommends:
ii  gnome-screenshot 3.22.0-1+b1
ii  lxde-core9
ii  lxlock   0.5.3-2
ii  lxpanel  0.9.3-1
ii  lxrandr  0.3.1-1
ii  lxsession-logout 0.5.3-2
ii  lxtask   0.1.8-1
ii  openbox-lxde-session [lxde-session]  0.99.2-3
ii  pcmanfm  1.2.5-3

Versions of packages lxde-common suggests:
pn  lxlauncher  

-- no debconf information



Bug#907314: unbound: exception in python module due to the dnameAsStr() function

2018-08-26 Thread root
Package: unbound
Version: 1.7.3-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   
   trying to implement an unbound python module (python code executed
   while the unbound server is handling requests and responses, see the
   pythonmod/ in unbound's source code).

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

   starting with the log.py example (included in the unbound's source
   code), modified the print functions to make it work with Python3, and
   added a single print() to illustrate the problem:
 print("=> %s"%q.qname_str)
   When a client requests a resolution, the ubound server reports an exception
   where it should not.

   * What was the outcome of this action?

   the exception reported is:
 Traceback (most recent call last):
   File "/etc/unbound/unbound.conf.d/log.py", line 120, in operate
 logDnsMsg(qstate)
  File "/etc/unbound/unbound.conf.d/log.py", line 70, in logDnsMsg
 print("=> %s"%q.qname_str)
  File "/usr/lib/python3/dist-packages/unboundmodule.py", line 132, in 
_get_qname_str
 def _get_qname_str(self): return dnameAsStr(self.qname)
TypeError: in method 'dnameAsStr', argument 1 of type 'char const *'

   * What outcome did you expect instead?

   the basic example should have worked, I wheched and it works fine
   (exactly the same code) with unbound as packaged by CentOS. Same bug
   with the unbound packaged in stretch though. Google did not help much
   here.


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

Kernel: Linux 4.17.17-100.fc27.x86_64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect (in a Docker container)

Versions of packages unbound depends on:
ii  adduser 3.117
ii  dns-root-data   2018013001
ii  libc6   2.27-4
ii  libevent-2.1-6  2.1.8-stable-4
ii  libfstrm0   0.3.0-1+b1
ii  libprotobuf-c1  1.3.1-1
ii  libpython3.63.6.6-2
ii  libssl1.1   1.1.1~~pre9-1
ii  libsystemd0 239-5
ii  lsb-base9.20170808
ii  openssl 1.1.1~~pre9-1
ii  unbound-anchor  1.7.3-1

unbound recommends no packages.

Versions of packages unbound suggests:
pn  apparmor  

-- Configuration Files:
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf [Errno 2] No such 
file or directory: 
'/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf'

-- no debconf information



Bug#906577: powertop: Garbled Output and unneeded error messages

2018-08-18 Thread root
Package: powertop
Version: 2.8-1+b1
Severity: minor

Running powertop --auto_tune (on a desktop system) yields a lot of errors:

modprobe cpufreq_stats failedLoaded 0 prior measurements
Cannot load from file /var/cache/powertop/saved_parameters.powertop
File will be loaded after taking minimum number of measurement(s) with battery 
only 
RAPL device for cpu 0
RAPL device for cpu 0
Devfreq not enabled
Cannot load from file /var/cache/powertop/saved_parameters.powertop
File will be loaded after taking minimum number of measurement(s) with battery 
only 
  unknown op '{'
Leaving PowerTOP

Especially the "unknown op" seems somewhat disturbing.

Autotune makes sense on desktop-systems, too: Especially for powersavings for
PCI devices.

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

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

Versions of packages powertop depends on:
ii  libc6 2.24-11+deb9u3
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libncurses5   6.0+20161126-1+deb9u2
ii  libncursesw5  6.0+20161126-1+deb9u2
ii  libnl-3-200   3.2.27-2
ii  libnl-genl-3-200  3.2.27-2
ii  libpci3   1:3.5.2-1
ii  libstdc++66.3.0-18+deb9u1
ii  libtinfo5 6.0+20161126-1+deb9u2

powertop recommends no packages.

Versions of packages powertop suggests:
pn  cpufrequtils   
pn  laptop-mode-tools  

-- no debconf information



Bug#904270: apt: Check package list passed to apt-get for dependencies

2018-07-22 Thread root
Package: apt
Version: 1.7.0~alpha2
Severity: normal

Dear Maintainer,

If more than one package is specified in the package list passed to `apt-get 
install` (and potentially others) the implicit dependencies of one of these 
packages shouldn't be installed if it's matched by a package specified in the 
list.

Example: `maven` depends on `default-jre-headless`, however specifying `apt-get 
install maven openjdk-8-jdk` causes OpenJDK 11 JRE to be installed for 
`default-jre-headless` next to OpenJDK 8 JDK which already fulfills the 
dependency. It's much more intuitive to select the explicitly specified 
fulfillment of the dependencies from the package list passed on the command 
line.

I'm aware of workaround like specifying `--assume-no` and not seeking for 
support. My intention is to improve the intuitive use of the software.

This has been discussed at 
https://askubuntu.com/questions/1058271/why-is-openjdk-11-jre-installed-together-with-maven-when-openjdk-8-jdk-is-specif.

I'm reporting this from inside the Docker image `debian:experimental` which 
shouldn't matter for the issue.


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-modules";
APT::VersionedKernelPackages:: "linux-modules-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::VersionedKernelPackages:: "linux-cloud-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::AutoRemove "";
APT::AutoRemove::SuggestsImportant "false";
APT::Update "";
APT::Update::Post-Invoke "";
APT::Update::Post-Invoke:: "rm -f /var/cache/apt/archives/*.deb 
/var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "false";
APT::Compressor::zstd::Cost "60";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";

Bug#904268: debian-installer: Improve instruction when the kernel doesn't support LVM

2018-07-22 Thread root
Package: debian-installer
Severity: normal

Dear Maintainer,

During the installation of a netinst image generated with `jigdo` (`jigdo-lite 
https://cdimage.debian.org/cdimage/weekly-builds/amd64/jigdo-cd/debian-testing-amd64-netinst.jigdo`)
 in VirtualBox 5.2.10 I encountered the information message

```
Logical Volume Manager not available
The current kernel doesn't support the Logical Volume Manager. You may need to 
load the lvm-mod module.
```
in the "Parition disks" section of the graphical installer.

This information is comprehensive, however I'd be much more useful if it would 
include instructions how to load the kernel module.

Please note that I'm not seeking support is this matter, my intention is to 
make the installation more intuitive.


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

Kernel: Linux 4.15.0-24-generic (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect



Bug#903472: O: isc-kea -- Documentation for ISC KEA DHCP server

2018-07-10 Thread root
Package: wnpp
Severity: normal

I intend to orphan the isc-kea package.

The package description is:
 KEA is an IPv4 and IPv6 DHCP server developed by Internet Systems Consortium.
 .
 This package provides documentation for the DHCP servers.



Bug#903471: O: isc-kea -- ISC KEA DHCP Dynamic DNS service

2018-07-10 Thread root
Package: wnpp
Severity: normal

I intend to orphan the isc-kea package.

The package description is:
 KEA is an IPv4 and IPv6 DHCP server developed by Internet Systems Consortium.
 .
 This package provides Dynamic DNS service to update DNS mapping based on
 DHCP lease events.



Bug#903465: O: isc-kea -- ISC KEA IPv4 DHCP server

2018-07-10 Thread root
Package: wnpp
Severity: normal

I intend to orphan the isc-kea package.

The package description is:
 KEA is an IPv4 and IPv6 DHCP server developed by Internet Systems Consortium
 providing a very high-performance with PostgreSQL, MySQL and memfile backends.
 .
 This package provides the IPv4 DHCP server.



Bug#903467: O: isc-kea -- Development headers for ISC KEA DHCP server

2018-07-10 Thread root
Package: wnpp
Severity: normal

I intend to orphan the isc-kea package.

The package description is:
 KEA is an IPv4 and IPv6 DHCP server developed by Internet Systems Consortium.
 .
 This package provides headers and static libraries of the common ISC KEA
 libraries, including libdhcp++



Bug#903469: O: isc-kea -- Administration utilities for ISC KEA DHCP server

2018-07-10 Thread root
Package: wnpp
Severity: normal

I intend to orphan the isc-kea package.

The package description is:
 KEA is an IPv4 and IPv6 DHCP server developed by Internet Systems Consortium.
 .
 This package provides backend database initialization and migration
 scripts and a DHCP benchmark tool.



Bug#903468: O: isc-kea -- Common libraries for the ISC KEA DHCP server

2018-07-10 Thread root
Package: wnpp
Severity: normal

I intend to orphan the isc-kea package.

The package description is:
 KEA is an IPv4 and IPv6 DHCP server developed by Internet Systems Consortium.
 .
 This package provides common libraries used by ISC KEA servers and utilities.



Bug#903466: O: isc-kea -- ISC KEA IPv6 DHCP server

2018-07-10 Thread root
Package: wnpp
Severity: normal

I intend to orphan the isc-kea package.

The package description is:
 KEA is an IPv4 and IPv6 DHCP server developed by Internet Systems Consortium
 providing a very high-performance with PostgreSQL, MySQL and memfile backends.
 .
 This package provides the IPv6 DHCP server.



Bug#903025: systemd-run -p IPAddressDeny=any does not stop network in systemd-nspawn

2018-07-05 Thread root
Package: systemd-container
Version: 239-4
Severity: important
Tags: security

Dear Maintainer,

systemd-run -t -p "IPAddressDeny=any" ping -c 1 192.168.1.1 normally generates
ping: sendmsg: Operation not permitted

When we run the above command in systemd-nspawn -b -M some-machine,
it generates
64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.305 ms

By the same reason, "IPAddressDeny=any" has no effect in the systemd
service configuration files inside a systemd container.
The protection mechanism by "IPAddressDeny=any" does not work
at all inside a systemd container.
I saw this failure of protection as potentially dangerous,
and gave "important" severity and "security" tag.

On the host linux the versions of systemd and systemd-nspawn are
both 239-4. On the guest linux the version of systemd is also 239-4.

Best regards,
Ryutaroh

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

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

Versions of packages systemd-container depends on:
ii  dbus 1.12.8-3
ii  libacl1  2.2.52-3+b1
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.27-3
ii  libcurl3-gnutls  7.52.1-5+deb9u6
ii  libgcrypt20  1.8.3-1
ii  liblzma5 5.2.2-1.2+b1
ii  libseccomp2  2.3.1-2.1
ii  libselinux1  2.6-3+b3
ii  systemd  239-4
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages systemd-container recommends:
pn  btrfs-progs
pn  libnss-mymachines  

systemd-container suggests no packages.

-- no debconf information



Bug#900964: debian-installer: debian missing firmware on the realteck ethernet controller witch firmware-9.4.0-amd64-netinst.iso

2018-06-07 Thread root
Package: debian-installer
Version: debianinstaller
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Dear maintener

I have in posses of the mainboard asus h81m-c witch integrateth ethernet  
controller: Realtek Semiconductor Co., Ltd.
RTL-8110SC/8169SC Gigabit Ethernet (rev 10).
During the installation the network card is detected but I am unable to
go on because in the iso firmware-9.4.0-amd64-netinst.iso the r8169
firmware is missing as specifically reported in my dmesg of which I copy
here 'under the email.
I request that the missing firmware is inserted in the iso.
Thank you and good day.
This is part of dmesg:
18.128417] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[   18.128423] r8169 :03:00.0: can't disable ASPM; OS doesn't have
ASPM control
[   18.138375] r8169 :03:00.0 eth0: RTL8168g/8111g at
0xbdbac0cb9000, 78:24:af:40:17:ea, XID 0c000800 IRQ 28
[   18.138377] r8169 :03:00.0 eth0: jumbo features [frames: 9200
bytes, tx checksumming: ko]
[   18.138775] r8169 :03:00.0 enp3s0: renamed from eth0
[   19.347154] r8169 :03:00.0: firmware: failed to load
rtl_nic/rtl8168g-2.fw (-2)
[   19.347156] r8169 :03:00.0: Direct firmware load for
rtl_nic/rtl8168g-2.fw failed with error -2
[   19.347158] r8169 :03:00.0 enp3s0: unable to load firmware patch
rtl_nic/rtl8168g-2.fw (-2)
[   19.360073] r8169 :03:00.0 enp3s0: link down
[   19.360090] r8169 :03:00.0 enp3s0: link down
[   19.360131] IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready



Bug#898662: linux-support-4.9.0-6: If I try an installation at debian streatch starting from the old old-stable (debian jessie 8) I have no problem with the network card in question. If instead I try

2018-05-14 Thread root
Package: linux-support-4.9.0-6
Version: 26
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Good evening everyone. I have the following problem: I have a mainboard asus 
h81m-c with a network card 3: 00.0 Ethernet controller: Realtek Semiconductor 
Co., Ltd. RTL8111 / 8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c).
If I try an installation at debian streatch starting from the old old-stable 
(debian jessie 8) I have no problem with the network card in question. If 
instead I try a clean installation using the firmware-9.4.0-amd64-netinst.iso 1 
time out of 40 times I can get the dynamic IP address from the router. All the 
other times I can not get anything and therefore unable to go on with the 
installation. Even using a static IP address of the same / 24 class I can not 
ping the router. I have this situation with testing too. With other 
distributions (ubuntu, centos, freeebsd, fedora) I have no problem whatsoever. 
I do not know how to move anymore. I ask for help. Even if I had to open a 
bug-reporting on which package should I show it? On the kernel, on the 
debian-installer?



Bug#896707: libopensrs-perl: perl warns of Unescaped left brace in regex

2018-04-23 Thread root
Package: libopensrs-perl
Version: 3.0.0-1
Severity: normal

Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/{{ <-- HERE (.*?)}}/ at /usr/share/perl5/OpenSRS/Util/Common.pm 
line 201,  line 244.
Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/{{ <-- HERE (.*?)}}/ at /usr/share/perl5/OpenSRS/Util/Common.pm 
line 573,  line 244.


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

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

Versions of packages libopensrs-perl depends on:
ii  libcrypt-blowfish-perl2.14-1+b4
ii  libcrypt-cbc-perl 2.33-1
ii  libdata-structure-util-perl   0.16-1+b2
ii  libdate-calc-perl 6.4-1
ii  libdate-manip-perl6.57-1
ii  libdate-pcalc-perl6.1-4+b2
ii  libhtml-template-perl 2.95-2
ii  libnet-libidn-perl0.12.ds-2+b3
ii  libunicode-map-perl   0.112-11+b3
ii  libunicode-string-perl2.10-1+b1
ii  libxml-parser-perl2.44-2+b1
ii  perl  5.24.1-3+deb9u3
ii  perl-modules-5.24 [liblocale-codes-perl]  5.24.1-3+deb9u3

libopensrs-perl recommends no packages.

libopensrs-perl suggests no packages.

-- Configuration Files:
/etc/OpenSRS.conf changed [not included]

-- no debconf information



Bug#894495: [tethys] mandos-client: Mandos client fails while booting but works from chroot into unpacked initramfs

2018-03-31 Thread root
Package: mandos-client
Version: 1.7.15-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

Hello,

I'm trying to install mandos-client on a Raspberry Pi and fall on a bug
that looks very similar in its behaviour (but doesn't have the same cause)
as bug #819982, ie. it fails with :

Mandos plugin mandos-client: Trying to decrypt OpenPGP data
Mandos plugin mandos-client: bad gpgme_op_decrypt: GPGME: Decryption failed
plugins.d/mandos-client.c:422:2: runtime error: null pointer passed as argument 
3, which is declared to never be null
Mandos plugin mandos-client: Unsupported algorithm: (null)
Mandos plugin mandos-client: Wrong key usage: 0

Mandos client version package is: 1.7.15-1

If I test the client per the manual instructions, it WORKS.

If I unpack the initramfs, chroot into it and run the client, it WORKS.

But when the system boots, it FAILS.

During system boot, I can SSH into the running initramfs using dropbear,
then if I run the client manually, it fails with the exact same error
that I can see displayed on screen when booting unattended.

The interesting line seems to be :

plugins.d/mandos-client.c:422:2: runtime error: null pointer passed as argument 
3, which is declared to never be null

It is interesting to note that this message appears only at FIRST attempt.
Afterwards the client retries every 10 seconds, and then only shows the :

Mandos plugin mandos-client: bad gpgme_op_decrypt: GPGME: Decryption failed
Mandos plugin mandos-client: Unsupported algorithm: (null)
Mandos plugin mandos-client: Wrong key usage: 0

lines.

Please find attached the two debug outputs when I get when running it
- either from the actual intramfs : mandos_client_initramfs.txt
- or from within a chroot : mandos_client_chroot.txt

Any help in solving this will be greatly appreciated :-)

Thanks in advance.

*** mandos_client_initramfs.txt
~ # /lib/mandos/plugin-runner
Mandos plugin mandos-client: Ignoring hook "." - not a file
Mandos plugin mandos-client: Ignoring hook ".." - not a file
Mandos plugin mandos-client: Hook "dhcplan.conf" is acceptable
Mandos plugin mandos-client: Running network hook "dhcplan.conf"
Mandos plugin mandos-client: Network hook "dhcplan.conf" ran successfully
Mandos plugin mandos-client: Interface "eth0" is already up; good
Mandos plugin mandos-client: No interfaces were brought up
Mandos plugin mandos-client: Using only interface "eth0"
Mandos plugin mandos-client: Initializing GnuTLS
Mandos plugin mandos-client: Attempting to use OpenPGP public key 
/conf/conf.d/mandos/pubkey.txt and secret key /conf/conf.d/mandos/seckey.txt as 
GnuTLS credentials
Mandos plugin mandos-client: GnuTLS: ASSERT: stream.c[cdk_stream_getc]:952
Mandos plugin mandos-client: GnuTLS: ASSERT: stream.c[cdk_stream_getc]:952
Mandos plugin mandos-client: GnuTLS: ASSERT: pgp.c[_gnutls_openpgp_export]:166
Mandos plugin mandos-client: GnuTLS: ASSERT: stream.c[cdk_stream_getc]:952
Mandos plugin mandos-client: GnuTLS: ASSERT: 
privkey.c[gnutls_openpgp_privkey_get_preferred_key_id]:1230
Mandos plugin mandos-client: GnuTLS: ASSERT: 
privkey.c[gnutls_openpgp_privkey_get_preferred_key_id]:1230
Mandos plugin mandos-client: GnuTLS: ASSERT: pgp.c[_gnutls_openpgp_export]:166
Mandos plugin mandos-client: GnuTLS: ASSERT: 
pgp.c[gnutls_openpgp_crt_get_preferred_key_id]:1644
Mandos plugin mandos-client: GnuTLS: ASSERT: 
pgp.c[gnutls_openpgp_crt_get_preferred_key_id]:1644
Mandos plugin mandos-client: GnuTLS: ASSERT: 
privkey.c[gnutls_openpgp_privkey_get_preferred_key_id]:1230
Mandos plugin mandos-client: GnuTLS: ASSERT: 
privkey.c[gnutls_openpgp_privkey_get_preferred_key_id]:1230
Mandos plugin mandos-client: GnuTLS: Signing using master PGP key
Mandos plugin mandos-client: GnuTLS: ASSERT: 
privkey.c[gnutls_openpgp_privkey_get_preferred_key_id]:1230
Mandos plugin mandos-client: GnuTLS: ASSERT: mpi.c[_gnutls_x509_read_uint]:246
Mandos plugin mandos-client: GnuTLS: ASSERT: 
dh.c[gnutls_dh_params_import_pkcs3]:373
Mandos plugin mandos-client: Tempdir /run/tmp/mandos4Vu7jb did not work, trying 
/tmp/mandosXX
Mandos plugin mandos-client: Initializing GPGME
Mandos plugin mandos-client: GnuTLS: REC[0xb780b8]: Allocating epoch #0
Mandos plugin mandos-client: Setting up a TCP connection to [SERVER IP WAS 
HERE], port 9601
Mandos plugin mandos-client: Connection to: [SERVER IP WAS HERE], port 9601
Mandos plugin mandos-client: Establishing TLS session with [SERVER IP WAS HERE]
Mandos plugin mandos-client: GnuTLS: ASSERT: constate.c[_gnutls_epoch_get]:600
Mandos plugin mandos-client: GnuTLS: REC[0xb780b8]: Allocating epoch #1
Mandos plugin mandos-client: GnuTLS: ASSERT: buffers.c[get_last_packet]:1159
Mandos plugin 

Bug#892318: android-tools-fsutils: img2simg use after free

2018-03-08 Thread root
Package: android-tools-fsutils
Version: 5.1.1.r38-1.1
Severity: important
Tags: patch

Dear Maintainer,

The version of img2simg in the android-tools-fsutils package has a 
use-after-free bug
as described and fixed in this commit:

https://android.googlesource.com/platform/system/core/+/c227a1d855cb6ab86d4927c0231cd8d3afbc957d%5E%21/#F0

Due to this, I've encountered situations where img2simg outputs wrong results.

There's a fixed version of img2simg already distributed in the img2simg binary
package, from the android-platform-system-core source package.

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages android-tools-fsutils depends on:
ii  libc6 2.27-1
ii  libpcre3  2:8.39-9
ii  python2.7.14-4
ii  zlib1g1:1.2.8.dfsg-5

android-tools-fsutils recommends no packages.

android-tools-fsutils suggests no packages.

-- no debconf information



Bug#891814: exim4-base: changes to update-exim4.conf COMPLETELY fail to respect BASIC rules: DO NOT BREAK CONFIGS

2018-02-28 Thread root
Package: exim4-base
Version: 4.90.1-1
Severity: important


guys.  this is really serious.  i have been running an exim4 system, live,
for over 12 years.  it's an extremely complex and comprehensive setup that
cannot just be blithely "upgraded" without a hell of a lot of work.

you've just completely ignored the most BASIC rules of being a maintainer
for a package: DON'T fuck with peoples' configurations.

it is just a pure coincidence that i happen to be migrating a server, and
happened to have an older version which is still live and has NOT been
upgraded.

if i had been forced into doing an upgrade on the live server (which has
happened at least once with exim4 in the past twelve years) it would have
been absolutely fucking disastrous.

running update-exim4.conf should JUST WORK.  your job is NOT to fucking
well IMPOSE on people arbitrary changes that are guaranteed to break a
mission-critical server!  it doesn't matter if you're
not being paid to work on this stuff because you're volunteers.  if
people are complaining and raising bugreports your response should
NOT BE TO BITCH AND BLAME THEM for quotes NOT READING THE DOCUMENTATION quotes,
your response should be, "oh fuck, *we* fucked up by BREAKING PEOPLE's
SYSTEMS AND CAUSING THEM SERIOUS PROBLEMS".

alright.  sorry for shouting, but if someone doesn't shout at you about
this, there's the risk that it might not get through that what you've done
and the approach you're taking is not ok (i can see in the install logs
the warning signs that you're blaming users for not reading documentation).



-- Package-specific info:

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

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

Versions of packages exim4-base depends on:
ii  adduser3.113+nmu3
ii  anacron2.3-19
ii  cron [cron-daemon] 3.0pl1-124
ii  debconf [debconf-2.0]  1.5.59
ii  exim4-config [exim4-config-2]  4.90.1-1
ii  libc6  2.23-4
ii  libdb5.3   5.3.28-3
ii  lsb-base   4.1+Debian8+deb7u1
ii  netbase5.0

Versions of packages exim4-base recommends:
ii  bsd-mailx [mailx]  8.1.2-0.2006cvs-1
ii  psmisc 22.19-1+deb7u1

Versions of packages exim4-base suggests:
ii  bsd-mailx [mail-reader]  8.1.2-0.2006cvs-1
pn  exim4-doc-html | exim4-doc-info  
pn  eximon4  
ii  file 1:5.20-1
ii  mutt [mail-reader]   1.5.21-6.2+deb7u2
ii  openssl  1.0.1e-2+deb7u6
pn  spf-tools-perl   
pn  swaks

-- debconf information excluded



Bug#891212: cyrus-common: cyrus cron.daily does not work on Jessie

2018-02-23 Thread root
Package: cyrus-common
Version: 2.4.17+nocaldav-0+deb8u2
Severity: normal

Dear Maintainer,

This is a followup to archived bug #833452
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833452

This bug was fixed in version 2.5.10 (unstable at that time). 
But this bug is still present in Jessie. Would it be
possible to fix the cronscript i oldstable? The fix is quite
simple. Just replace the path /usr/sbin/chk_cyrus to
/usr/lib/cyrus/bin/chk_cyrus (and same for ctl_mboxlist).



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

Kernel: Linux 3.16.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages cyrus-common depends on:
ii  adduser3.113+nmu3
ii  db-upgrade-util5.3.0
ii  db-util5.3.0
ii  debconf [debconf-2.0]  1.5.56+deb8u1
ii  dpkg   1.17.27
ii  exim4-daemon-heavy [mail-transport-agent]  4.84.2-2+deb8u5
ii  gawk   1:4.1.1+dfsg-1
ii  libc6  2.19-18+deb8u10
ii  libcomerr2 1.42.12-2+b1
ii  libdb5.3   5.3.28-9+deb8u1
ii  libkrb5-3  1.12.1+dfsg-19+deb8u4
ii  libldap-2.4-2  2.4.40+dfsg-1+deb8u3
ii  libsasl2-2 2.1.26.dfsg1-13+deb8u1
ii  libsasl2-modules   2.1.26.dfsg1-13+deb8u1
ii  libsnmp30  5.7.2.1+dfsg-1
ii  libssl1.0.01.0.1t-1+deb8u7
ii  libwrap0   7.6.q-25
ii  libzephyr4 3.1.2-1
ii  netbase5.3
ii  perl   5.20.2-3+deb8u9
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages cyrus-common recommends:
ii  cyrus-admin  2.4.17+nocaldav-0+deb8u2
ii  cyrus-imapd  2.4.17+nocaldav-0+deb8u2
ii  cyrus-pop3d  2.4.17+nocaldav-0+deb8u2

Versions of packages cyrus-common suggests:
pn  apt-listchanges
ii  cyrus-admin2.4.17+nocaldav-0+deb8u2
pn  cyrus-clients  
pn  cyrus-doc  
ii  cyrus-imapd2.4.17+nocaldav-0+deb8u2
pn  cyrus-murder   
pn  cyrus-nntpd
ii  cyrus-pop3d2.4.17+nocaldav-0+deb8u2
pn  cyrus-replication  
ii  sasl2-bin  2.1.26.dfsg1-13+deb8u1

-- Configuration Files:
/etc/cyrus.conf changed [not included]
/etc/imapd.conf changed [not included]

-- debconf information excluded



Bug#886734: libgdk-pixbuf2.0-0: undefined symbol after upgrade (wheezy-security): gdk_pixbuf_calculate_rowstride

2018-01-09 Thread root
Package: libgdk-pixbuf2.0-0
Version: 2.26.1-1+deb7u7
Severity: important

Dear Maintainer,

after security upgrade i get following eror message due to an undefined symbol:

g_module_open() failed for 
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-gif.so: 
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-gif.so: 
undefined symbol: gdk_pixbuf_calculate_rowstride

Maybe related to bug report #886721?

Regards, Robert

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

Kernel: Linux 3.16.0-0.bpo.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

Versions of packages libgdk-pixbuf2.0-0 depends on:
ii  libc62.13-38+deb7u12
ii  libgdk-pixbuf2.0-common  2.26.1-1+deb7u7
ii  libglib2.0-0 2.33.12+really2.32.4-5
ii  libjasper1   1.900.1-13+deb7u6
ii  libjpeg8 8d-1+deb7u1
ii  libpng12-0   1.2.49-1+deb7u2
ii  libtiff4 3.9.6-11+deb7u8
ii  libx11-6 2:1.5.0-1+deb7u4
ii  multiarch-support2.13-38+deb7u12

libgdk-pixbuf2.0-0 recommends no packages.

libgdk-pixbuf2.0-0 suggests no packages.

-- no debconf information



Bug#885783: xfce4 clipboard can't disable

2017-12-29 Thread root
Package: xfce4
Version: 4.12.4
Severity: important

Dear Maintainer,

Hello,
I have installed xfce4 with aptitude install xfce4 --without-recommends.
I dont want clipboard enabled on my system, but xfce auto force-enable, i dont 
know where is settings, i searsh all settings but 0 option for this.
So i have installed clipboard manager like xfce4-clipman xfce4-plugin-climan 
parcellite, and configure for disable clipboard, and its work, its show 0 
history in past, but system xfce running have still clipboard working.

I have tested 2 method for test disable clipboard:
1- with launch only xfce4-panel and xfwm4, then is minimalist but clipboard is 
off
2- with xfce4, clipboard is on default, so i close xfsettingsd (from 
xfce4-session-settings), then clipboard is off, but i lose theme and keyboard 
shortcut functionnality.


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

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

Versions of packages xfce4 depends on:
ii  gtk2-engines-xfce3.2.0-2
ii  libxfce4ui-utils 4.12.1-2
ii  orage4.12.1-4
ii  thunar   1.6.13-2
ii  xfce4-appfinder  4.12.0-2
ii  xfce4-panel  4.12.2-1
ii  xfce4-pulseaudio-plugin  0.2.5-1
ii  xfce4-session4.12.1-6
ii  xfce4-settings   4.12.1-1
ii  xfconf   4.12.1-1
ii  xfdesktop4   4.12.4-1
ii  xfwm44.12.4-1

Versions of packages xfce4 recommends:
pn  desktop-base  
ii  tango-icon-theme  0.8.90-7
pn  thunar-volman 
pn  xfce4-notifyd 
ii  xorg  1:7.7+19

Versions of packages xfce4 suggests:
pn  gtk3-engines-xfce
pn  xfce4-goodies
pn  xfce4-power-manager  

-- no debconf information



Bug#884788: systemd-ask-password echos password as stars (*) while decrypting LUKS partition

2017-12-20 Thread root kea
On Wed, Dec 20, 2017 at 4:46 AM, Michael Biebl  wrote:

> I think this is intentional behaviour, so you'll easily spot that your
> input system works

The current implementation is that the password gets echoed to
terminal as star(*) characters by default and one needs to press TAB
or BACKSPACE key to turn off the echo.

Now it's quite possible that there are people who want to make sure
that their input works while entering password. For them a key should
be configured (e.g. TAB or BACKSPACE) to echo the stars(*). By default
password shouldn't be echoed at all. Something like when most of the
modern GUIs make you click on button to reveal the password. By
default they print stars/dots.[0] (This is an analogy)

There are mainly 2 reasons behind this proposal:
1. Security by obscurity (hiding the length of pass-phrase)
2. consistency

Now, still if we decide to make `systemd-ask-password` echo stars on
screen by default (which IMHO is a very bad idea) we should, just for
the sake of consistency, file bug reports against sudo, cryptsetup,
login and all those debian packages which don't echo the passphrase as
stars/any obscure char by default.

> Basically any graphical user interface works like
> this these days.

No, that is incorrect. First of all `systemd-ask-password` asking a
password to decrypt a partition is not a GUI. It's a CLI. Just like
cryptsetup. And secondly, this is a wrong analogy. A correct analogy
would be GUI -> CLI :: echoing dots by default -> echoing nothing by
default :: revealing password on a user action -> echoing stars on a
user action

[0] https://imgur.com/a/31oWd
-- 
Avinash Sonawane (rootKea)
PICT, Pune
https://rootkea.wordpress.com



Bug#884116: linux-image-4.9.0-4-amd64: screen atrifacts then crash

2017-12-11 Thread root
Package: src:linux
Version: 4.9.65-3
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

* What led up to the situation?
I did an upgrade today and linux image was upgraded from 4.9.51-1 to 4.9.65-3.

* What was the outcome of this action?
Various screen artifacts appear under Xorg, fortunately the console still works 
so I can write this report.
The most noticeable artifact is the whole screen image shifting to the right 
then back very fast.
Artifacts are more violent under compiz but they appear with xfwm4 too.
And then after a while the system crashes, no response to the keyboard/mouse.
Reverting to linux-image-4.9.0-3-amd64 makes the problem go away.


-- Package-specific info:
** Version:
Linux version 4.9.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3 (2017-12-03)

** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-4-amd64 
root=UUID=e9287df1-d10d-4d6e-8910-7887cf5e5900 ro quiet

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

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

** Model information
sys_vendor: To be filled by O.E.M.
product_name: To be filled by O.E.M.
product_version: To be filled by O.E.M.
chassis_vendor: To Be Filled By O.E.M.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends Inc.
bios_version: 5.6.5
board_vendor: INTEL Corporation
board_name: CRESCENTBAY
board_version: To be filled by O.E.M.

** Loaded modules:
dm_mod
binfmt_misc
rfcomm
joydev
hid_generic
usbhid
pci_stub
vboxpci(O)
vboxnetadp(O)
vboxnetflt(O)
vboxdrv(O)
bnep
uas
btusb
btrtl
btbcm
btintel
usb_storage
bluetooth
crc16
intel_rapl
x86_pkg_temp_thermal
intel_powerclamp
coretemp
kvm_intel
kvm
irqbypass
crct10dif_pclmul
crc32_pclmul
snd_hda_codec_hdmi
ghash_clmulni_intel
intel_cstate
arc4
rt2800pci
rt2800mmio
rt2800lib
rt2x00pci
rt2x00mmio
rt2x00lib
iTCO_wdt
eeprom_93cx6
iTCO_vendor_support
evdev
mac80211
intel_uncore
cfg80211
crc_ccitt
intel_rapl_perf
pcspkr
rfkill
sg
snd_hda_codec_realtek
snd_hda_codec_generic
snd_hda_intel
battery
i915
snd_hda_codec
dw_dmac
snd_soc_ssm4567
snd_soc_rt5640
snd_soc_sst_acpi
dw_dmac_core
video
snd_soc_sst_match
elan_i2c
acpi_als
snd_soc_rl6231
snd_hda_core
snd_soc_core
snd_hwdep
snd_compress
snd_pcm
drm_kms_helper
snd_timer
snd
drm
kfifo_buf
soundcore
acpi_pad
button
industrialio
i2c_algo_bit
shpchp
lpc_ich
mfd_core
parport_pc
ppdev
lp
sunrpc
parport
ip_tables
x_tables
autofs4
xfs
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid1
multipath
linear
raid0
md_mod
sd_mod
crc32c_intel
aesni_intel
aes_x86_64
glue_helper
lrw
gf128mul
ablk_helper
cryptd
i2c_i801
i2c_smbus
ahci
libahci
libata
ehci_pci
ehci_hcd
xhci_pci
scsi_mod
xhci_hcd
r8169
mii
usbcore
usb_common
fan
thermal
sdhci_acpi
sdhci
mmc_core
i2c_hid
hid
i2c_designware_platform
i2c_designware_core

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Broadwell-U Host Bridge -OPI 
[8086:1604] (rev 09)
Subsystem: Intel Corporation Broadwell-U Host Bridge -OPI [8086:1604]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: bdw_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation Iris Graphics 6100 
[8086:162b] (rev 09) (prog-if 00 [VGA controller])
Subsystem: Intel Corporation Iris Graphics 6100 [8086:162b]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot-), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ 
TransPend-
LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Exit 
Latency L0s <1us, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ 
DLActive- BWMgmt- ABWMgmt-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ 
CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID , PMEStatus- PMEPending-
   

Bug#871921: cyrus-imap: Cyrus squatter fails with segmentation fault error on large mailboxes

2017-11-13 Thread root
Package: cyrus-imapd
Version: 2.5.10-3
Followup-For: Bug #871921

Dear Maintainer,

I have encountered the same problem. The threshold to
trigger this bug seems to be even lower that 1 mails,
probably in the range af o few thousands.

I was trying to strece squatter to find out if it is a
single mail that makes it crash, but it did not help.
Swuatter happily read all the emails, and crashed when
trying to do something with one of the many temporary files
it uses:

open("/var/spool/cyrus/mail/domain/censored.cz/user/some^user/squatKmITgH", 
O_RDWR|O_CREAT|O_EXCL, 0600) = 110
unlink("/var/spool/cyrus/mail/domain/censored.cz/user/some^user/squatKmITgH") = 0
... long long output skipped ...
write(110, 
"O\33$O\33IO\33\303O\34EO\34\303O\35\\O\35\303O\36\36O\36\37O\36~O\36"..., 
52145) = 52145
lseek(110, 0, SEEK_SET) = 0
mmap(NULL, 770211840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f1f5a269000
mmap(NULL, 949834204, PROT_READ, MAP_SHARED, 110, 0) = 0x7f1f21893000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7f1f8816c008} ---
+++ killed by SIGSEGV +++


Is there any chance someone will look into it?

Thanks in advance
Vladislav Kurz


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

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

Versions of packages cyrus-imapd depends on:
pn  cyrus-common  
ii  dpkg  1.18.24
ii  libc6 2.24-11+deb9u1
ii  libicu57  57.1-6
ii  libsasl2-22.1.27~101-g0780600+dfsg-3
ii  libssl1.1 1.1.0f-3+deb9u1
ii  libwrap0  7.6.q-26
ii  zlib1g1:1.2.8.dfsg-5

cyrus-imapd recommends no packages.

cyrus-imapd suggests no packages.

-- no debconf information



Bug#878846: linux-image: increase CONFIG_DVB_MAX_ADAPTERS

2017-10-17 Thread root
Package: src:linux
Version: 4.14~rc3-1~exp1
Severity: normal

Dear Maintainer,

Since kernel 4.14 the kernel finally supports Digital Devices Max S8.
It exposes 8 adapters via /dev/dvb/adapters.
Even if we have one more card, then this constant is insuficcient.

Please raise up this value in default debian kernel configuration.

-- Package-specific info:
** Version:
Linux version 4.14.0-rc3-amd64 (debian-ker...@lists.debian.org) (gcc version 
6.4.0 20170920 (Debian 6.4.0-7)) #1 SMP Debian 4.14~rc3-1~exp1 (2017-10-02)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.14.0-rc3-amd64 
root=UUID=f116d1e7-09f8-4c08-b89c-ae652ebf41a3 ro quiet

** Not tainted

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

** Model information
sys_vendor: To Be Filled By O.E.M.
product_name: To Be Filled By O.E.M.
product_version: To Be Filled By O.E.M.
chassis_vendor: To Be Filled By O.E.M.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends Inc.
bios_version: P1.50
board_vendor: ASRock
board_name: H97 Anniversary
board_version: 

** Loaded modules:
ipt_MASQUERADE
nf_nat_masquerade_ipv4
bridge
stp
llc
xt_nat
xt_tcpudp
iptable_nat
nf_conntrack_ipv4
nf_defrag_ipv4
nf_nat_ipv4
nf_nat
nf_conntrack
libcrc32c
veth
binfmt_misc
iptable_filter
mxl5xx
intel_rapl
x86_pkg_temp_thermal
intel_powerclamp
kvm_intel
iTCO_wdt
iTCO_vendor_support
kvm
irqbypass
crct10dif_pclmul
crc32_pclmul
ghash_clmulni_intel
intel_cstate
intel_uncore
intel_rapl_perf
pcspkr
joydev
evdev
mei_me
i915
sg
lpc_ich
ddbridge
mfd_core
dvb_core
drm_kms_helper
shpchp
drm
mei
dw_dmac
i2c_algo_bit
snd_soc_sst_acpi
battery
dw_dmac_core
snd_soc_sst_match
snd_soc_rt5640
elan_i2c
video
snd_soc_rl6231
snd_soc_ssm4567
snd_soc_core
snd_compress
snd_pcm
snd_timer
snd
soundcore
spi_pxa2xx_platform
acpi_pad
button
nfsd
auth_rpcgss
nfs_acl
lockd
grace
sunrpc
nct6775
hwmon_vid
coretemp
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
crypto_simd
cryptd
glue_helper
aes_x86_64
hid_logitech_hidpp
hid_logitech_dj
usbhid
sd_mod
crc32c_intel
ahci
libahci
i2c_i801
libata
scsi_mod
r8169
mii
i2c_hid
hid
sdhci_acpi
sdhci
mmc_core
i2c_designware_platform
i2c_designware_core
ehci_pci
ehci_hcd
usbcore
usb_common

** Network interface configuration:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
# This is an autoconfigured IPv6 interface
iface eth0 inet6 auto

** Network status:
*** IP interfaces and addresses:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether d0:50:99:59:2b:d0 brd ff:ff:ff:ff:ff:ff
inet 10.2.1.3/24 brd 10.2.1.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::d250:99ff:fe59:2bd0/64 scope link 
   valid_lft forever preferred_lft forever
5: lxc-bridge-nat: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc 
noqueue state UNKNOWN group default qlen 1000
link/ether fa:88:c8:05:57:a0 brd ff:ff:ff:ff:ff:ff
inet 192.168.100.1/24 brd 192.168.100.255 scope global lxc-bridge-nat
   valid_lft forever preferred_lft forever
inet6 fe80::f888:c8ff:fe05:57a0/64 scope link 
   valid_lft forever preferred_lft forever

*** Device statistics:
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo:4192  81000 0  0 0 4192  
81000 0   0  0
  eth0: 15164896  178679000 0  072 516143265  
371484000 0   0  0
lxc-bridge-nat:   0   0000 0  0 0
11659 123000 0   0  0

*** Protocol statistics:
Ip:
Forwarding: 1
177875 total packets received
0 forwarded
0 incoming packets discarded
177873 incoming packets delivered
371585 requests sent out
57 dropped because of missing route
Icmp:
7648 ICMP messages received
0 input ICMP message failed
ICMP input histogram:
destination unreachable: 14
echo requests: 538
echo replies: 7096
7636 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
echo requests: 7098
echo replies: 538
IcmpMsg:
InType0: 7096
 

Bug#878256: alpine: Random "IMAP connection broken (server response)" errors

2017-10-11 Thread root
Package: alpine
Version: 2.20+dfsg1-7
Severity: important

Dear Maintainer,

We upgraded both our dovecot imap server and user server to stretch and
since then our user who uses alpine report random "IMAP connection broken
(server response)" error messages with missing email content/missing folder
list and other symptoms later when not quitting alpine immediately.

We enabled debugging in dovecot and alpine as well and at the maximum
level we could gather the following information:

alpine:

IMAP 18:50:12 10/11 mm_log tcp: SSL data read end of file
IMAP 18:50:12 10/11 mm_notify bye:  
{:993/imap/notls/ssl/user=""}: [CLOSED] IMAP connection broken 
(server response)

dovecot:

Oct 11 18:50:12  dovecot: imap-login: Debug: SSL error: SSL_read()
failed: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init

According to https://github.com/openssl/openssl/issues/710 it seems to be
it is not allowed anymore to call SSL_shutdown() while SSL_in_init() returns
true and possibly alpine does exactly this.

In this state alpine is almost unusable and we cannot continue to migrate
our other servers with more alpine users to stretch.

If you need more information, please let me know.

Best regards,
Jozsef Kadlecsik

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

Kernel: Linux 4.4.89-grsec (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages alpine depends on:
ii  libc6 2.24-11+deb9u1
ii  libgssapi-krb5-2  1.15-1+deb9u1
ii  libkrb5-3 1.15-1+deb9u1
ii  libldap-2.4-2 2.4.44+dfsg-5+deb9u1
ii  libpam0g  1.1.8-3.6
ii  libssl1.0.2   1.0.2l-2
ii  libtinfo5 6.0+20161126-1+deb9u1
ii  mlock 8:2007f~dfsg-5

Versions of packages alpine recommends:
ii  alpine-doc  2.20+dfsg1-7

Versions of packages alpine suggests:
ii  aspell  0.60.7~20110707-3+b2
ii  postfix [mail-transport-agent]  3.1.4-7

-- no debconf information



Bug#878211: crtmpserver can not be compilled from source

2017-10-11 Thread root
Package: crtmpserver
Version: 1.0~dfsg-5.3
Followup-For: Bug #878211

Dear Maintainer,

# apt-get source crtmpserver
Reading package lists... Done
NOTICE: 'crtmpserver' packaging is maintained in the 'Git' version control 
system at:
git://git.debian.org/pkg-multimedia/crtmpserver.git
Please use:
git clone git://git.debian.org/pkg-multimedia/crtmpserver.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 343 kB of source archives.
Get:1 http://ftp.ru.debian.org/debian stretch/main crtmpserver 1.0~dfsg-5.3 
(dsc) [1,983 B]
Get:2 http://ftp.ru.debian.org/debian stretch/main crtmpserver 1.0~dfsg-5.3 
(tar) [312 kB]
Get:3 http://ftp.ru.debian.org/debian stretch/main crtmpserver 1.0~dfsg-5.3 
(dif) [28.7 kB]
Fetched 343 kB in 0s (1,584 kB/s)
dpkg-source: info: extracting crtmpserver in crtmpserver-1.0~dfsg
dpkg-source: info: unpacking crtmpserver_1.0~dfsg.orig.tar.bz2
dpkg-source: info: unpacking crtmpserver_1.0~dfsg-5.3.debian.tar.xz
dpkg-source: info: applying 05_dont_Werror.diff
dpkg-source: info: applying 10_disable_tests_vmtests.diff
dpkg-source: info: applying 13_disable_lua_config_install.diff
dpkg-source: info: applying 15_use_system_lua.diff
dpkg-source: info: applying 16_add_header_install.diff
dpkg-source: info: applying 18_enable_cmake_find_default_paths.diff
dpkg-source: info: applying 19_gcc_4_7_compatibility.diff
dpkg-source: info: applying 20_use_pkgconfig_for_tinyxml.diff
dpkg-source: info: applying 21_fix_ftbfs_kfreebsd.diff
dpkg-source: info: applying 22_fix_ftbfs_gcc-6.diff
W: Download is performed unsandboxed as root as file 
'crtmpserver_1.0~dfsg-5.3.dsc' couldn't be accessed by user '_apt'. - 
pkgAcquire::Run (13: Permission denied)


cd crtmpserver-1.0~dfsg

README:
cd crtmpserver/builders/cmake
cmake .

But crtmpserver does not have builders/cmake directory!

Trying git://git.debian.org/pkg-multimedia/crtmpserver.git
cd crtmpserver
- the same problem (no builders folder)


My later (~1.5 years old) compillatiion have got from git or svn source (not 
from debain git://git.debian.org/pkg-multimedia/crtmpserver.git), and thay had 
builders/cmake directory and have compilled normally after essential libraries 
is installed.

Sorry if this is not for bug report topic.


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

Kernel: Linux 4.9.0-4-amd64 (SMP w/5 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 crtmpserver depends on:
ii  crtmpserver-apps   1.0~dfsg-5.3
ii  crtmpserver-libs   1.0~dfsg-5.3
ii  libc6  2.24-11+deb9u1
ii  libgcc11:6.3.0-18
ii  liblua5.1-05.1.5-8.1+b2
ii  libssl1.0.21.0.2l-2
ii  libstdc++6 6.3.0-18
ii  libtinyxml2.6.2v5  2.6.2-4

crtmpserver recommends no packages.

crtmpserver suggests no packages.

-- Configuration Files:
/etc/default/crtmpserver changed:
ENABLED="yes"
DAEMON_USER="root"
DAEMON_ARGS="--daemon"
DAEMON_CONF="/root/app/crtmpserver/builders/cmake/crtmpserver/crtmpserver.lua"

/etc/init.d/crtmpserver changed:
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="C++ RTMP Server"
NAME=crtmpserver
WD_PATH=/root/app/crtmpserver/builders/cmake
DAEMON=$WD_PATH/crtmpserver/crtmpserver
DAEMON_ARGS=" --daemon "
DAEMON_CONF="$WD_PATH/crtmpserver/crtmpserver.lua"
DAEMON_USER="root"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
ENABLED="no"
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
[ -x $DAEMON ] || exit 0
[ -r $DAEMON_CONF ] || exit 0
[ $ENABLED = "yes" ] || exit 0
. /lib/init/vars.sh
. /lib/lsb/init-functions
DAEMON_UID=$(getent passwd ${DAEMON_USER} | cut -d":" -f3)
if [ -z "${DAEMON_UID}" ]; then
echo "Error: User ${DAEMON_USER} does not exist."
exit 1
fi
UID_ARG=" --uid=${DAEMON_UID} "
do_start()
{
cd $WD_PATH
start-stop-daemon --start --quiet --chdir $WD_PATH --pidfile $PIDFILE 
--exec $DAEMON --test > /dev/null \
|| return 1
start-stop-daemon --start --quiet --chdir $WD_PATH --pidfile $PIDFILE 
--exec $DAEMON -- \
$DAEMON_ARGS $UID_ARG $DAEMON_CONF \
|| return 2
}
do_stop()
{
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile 
$PIDFILE --name $NAME
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
start-stop-daemon --stop --quiet --oknodo --retry=INT/30/KILL/5 --exec 
$DAEMON
[ "$?" = 2 ] && return 2
rm -f $PIDFILE
return "$RETVAL"
}
case "$1" in
  start)
log_daemon_msg "Starting $DESC " "$NAME"
do_start
case "$?&qu

Bug#878211: crtmpserver can not be compilled from source

2017-10-10 Thread root
Package: crtmpserver
Version: 1.0~dfsg-5.3
Severity: normal

Dear Maintainer,

#apt-get source crtmpserver
Getting source crtmpserver, it can be configured to compile.
I have compilled it a long ago on Debian 8 with my patches to prevent
anonymous live streaming. That binary compilation is working on Debian 9
after upgrading from Debian 8, but I can't make it from source now and
I do not know how to send my patches to contributors.


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

Kernel: Linux 4.9.0-4-amd64 (SMP w/5 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 crtmpserver depends on:
ii  crtmpserver-apps   1.0~dfsg-5.3
ii  crtmpserver-libs   1.0~dfsg-5.3
ii  libc6  2.24-11+deb9u1
ii  libgcc11:6.3.0-18
ii  liblua5.1-05.1.5-8.1+b2
ii  libssl1.0.21.0.2l-2
ii  libstdc++6 6.3.0-18
ii  libtinyxml2.6.2v5  2.6.2-4

crtmpserver recommends no packages.

crtmpserver suggests no packages.

-- Configuration Files:
/etc/default/crtmpserver changed:
ENABLED="yes"
DAEMON_USER="root"
DAEMON_ARGS="--daemon"
DAEMON_CONF="/root/app/crtmpserver/builders/cmake/crtmpserver/crtmpserver.lua"

/etc/init.d/crtmpserver changed:
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="C++ RTMP Server"
NAME=crtmpserver
WD_PATH=/root/app/crtmpserver/builders/cmake
DAEMON=$WD_PATH/crtmpserver/crtmpserver
DAEMON_ARGS=" --daemon "
DAEMON_CONF="$WD_PATH/crtmpserver/crtmpserver.lua"
DAEMON_USER="root"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
ENABLED="no"
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
[ -x $DAEMON ] || exit 0
[ -r $DAEMON_CONF ] || exit 0
[ $ENABLED = "yes" ] || exit 0
. /lib/init/vars.sh
. /lib/lsb/init-functions
DAEMON_UID=$(getent passwd ${DAEMON_USER} | cut -d":" -f3)
if [ -z "${DAEMON_UID}" ]; then
echo "Error: User ${DAEMON_USER} does not exist."
exit 1
fi
UID_ARG=" --uid=${DAEMON_UID} "
do_start()
{
cd $WD_PATH
start-stop-daemon --start --quiet --chdir $WD_PATH --pidfile $PIDFILE 
--exec $DAEMON --test > /dev/null \
|| return 1
start-stop-daemon --start --quiet --chdir $WD_PATH --pidfile $PIDFILE 
--exec $DAEMON -- \
$DAEMON_ARGS $UID_ARG $DAEMON_CONF \
|| return 2
}
do_stop()
{
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile 
$PIDFILE --name $NAME
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
start-stop-daemon --stop --quiet --oknodo --retry=INT/30/KILL/5 --exec 
$DAEMON
[ "$?" = 2 ] && return 2
rm -f $PIDFILE
return "$RETVAL"
}
case "$1" in
  start)
log_daemon_msg "Starting $DESC " "$NAME"
do_start
case "$?" in
0|1) log_end_msg 0 ;;
2) log_end_msg 1 ;;
esac
  ;;
  stop)
log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0|1) log_end_msg 0 ;;
2) log_end_msg 1 ;;
esac
;;
  status)
   status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
   ;;
  restart)
log_daemon_msg "Restarting $DESC" "$NAME"
do_stop
case "$?" in
  0|1)
do_start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
  *)
# Failed to stop
log_end_msg 1
;;
esac
;;
  force-reload)
restart
;;
  *)
echo "Usage: $SCRIPTNAME {start|stop|status|restart}" >&2
exit 3
;;
esac
:


-- no debconf information



Bug#878210: libnginx-mod-rtmp: Broken dependencies for libnginx-mod-rtmp

2017-10-10 Thread root
Package: libnginx-mod-rtmp
Severity: normal

Dear Maintainer,

#apt-get install libnginx-mod-rtmp

The following packages have unmet dependencies:
 libnginx-mod-rtmp : Depends: nginx-common (= 1.13.3-1~bpo9+1) but 
1.10.3-1+deb9u1 is to be installed
E: Unable to correct problems, you have held broken packages.

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

Kernel: Linux 4.9.0-4-amd64 (SMP w/5 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 libnginx-mod-rtmp depends on:
ii  libc6 2.24-11+deb9u1
pn  nginx-common  

libnginx-mod-rtmp recommends no packages.

libnginx-mod-rtmp suggests no packages.



Bug#876433: linux-image-4.9.0-3-amd64: Overlay FS does not work correctly with OpenAFS lower directory

2017-09-22 Thread root
Package: src:linux
Version: 4.9.30-2+deb9u5
Severity: normal

Dear Maintainer,

This is actually the same issue as Bug #876345 , where I tried the same with 
the kernel
from sid.

One cannot read files of the lowerdir of a overlay, if lowerdir points
to an AFS networked drive. In this case Debian Stretch's OpenAFS client
packet.

If you do this:

mkdir lower upper work to
modprobe overlay
mount -t overlay -o upperdir=upper,workdir=work,lowerdir=lower overlay-local to

ls to
# displays files in upper and lower
cat to/file
# displays the content of file in upper or, if not found there, in lower

Assume OpenAFS is configured to be visible at /afs and up and running:

ls /afs/.inf/test
afs  file

ls upper
file  upper

mount -t overlay -o upperdir=upper,workdir=work,lowerdir=/afs/.inf/test 
overlay-afs to

ls to
afs file  upper
# this looks good, all files merged

cat to/file
upper
# looks good, too, "upper"  is the content of upper/file

cat to/afs
cat: to/afs: No such file or directory
### ! this should display the content of the file

cat /afs/.inf/test/afs
afs
# this file has a content and does exist indeed

ls -alni to/afs
786508 -rw-r--r-- 1 0 0 4 Sep 21 09:17 to/afs
ls -alni /afs/.inf/test/afs
786508 -rw-r--r-- 1 0 0 4 Sep 21 09:17 /afs/.inf/test/afs
# Those lines match as well


-- 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+deb9u5 (2017-09-19)

** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-3-amd64 root=/dev/mapper/stretch--vg-root ro quiet

** Tainted: PO (4097)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.

** Kernel log:
[2.544202] fuse init (API version 7.26)
[2.585986] RPC: Registered named UNIX socket transport module.
[2.585987] RPC: Registered udp transport module.
[2.585988] RPC: Registered tcp transport module.
[2.585988] RPC: Registered tcp NFSv4.1 backchannel transport module.
[2.629214] systemd-journald[237]: Received request to flush runtime journal 
from PID 1
[2.822552] vmw_vmci :00:07.7: Found VMCI PCI device at 0x11080, irq 16
[2.822598] vmw_vmci :00:07.7: Using capabilities 0xc
[2.824961] Guest personality initialized and is active
[2.824985] VMCI host device registered (name=vmci, major=10, minor=58)
[2.824985] Initialized host personality
[2.82] NET: Registered protocol family 40
[2.835206] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input5
[2.835210] ACPI: Power Button [PWRF]
[2.836436] ACPI: AC Adapter [ACAD] (on-line)
[2.909698] random: crng init done
[3.024328] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[3.031532] sd 0:0:0:0: Attached scsi generic sg0 type 0
[3.031553] sd 0:0:1:0: Attached scsi generic sg1 type 0
[3.031571] sd 0:0:2:0: Attached scsi generic sg2 type 0
[3.031588] sr 2:0:0:0: Attached scsi generic sg3 type 5
[3.051157] [drm] Initialized
[3.052457] [drm] DMA map mode: Using physical TTM page addresses.
[3.052507] [drm] Capabilities:
[3.052508] [drm]   Rect copy.
[3.052508] [drm]   Cursor.
[3.052508] [drm]   Cursor bypass.
[3.052509] [drm]   Cursor bypass 2.
[3.052509] [drm]   8bit emulation.
[3.052509] [drm]   Alpha cursor.
[3.052510] [drm]   Extended Fifo.
[3.052510] [drm]   Multimon.
[3.052511] [drm]   Pitchlock.
[3.052511] [drm]   Irq mask.
[3.052511] [drm]   Display Topology.
[3.052512] [drm]   GMR.
[3.052512] [drm]   Traces.
[3.052512] [drm]   GMR2.
[3.052513] [drm]   Screen Object 2.
[3.052513] [drm]   Command Buffers.
[3.052513] [drm]   Command Buffers 2.
[3.052514] [drm]   Guest Backed Resources.
[3.052514] [drm] Max GMR ids is 64
[3.052515] [drm] Max number of GMR pages is 65536
[3.052515] [drm] Max dedicated hypervisor surface memory is 0 kiB
[3.052516] [drm] Maximum display memory size is 32768 kiB
[3.052516] [drm] VRAM at 0xe800 size is 4096 kiB
[3.052517] [drm] MMIO at 0xfe00 size is 256 kiB
[3.052518] [drm] global init.
[3.057709] [TTM] Zone  kernel: Available graphics memory: 1509224 kiB
[3.057709] [TTM] Initializing pool allocator
[3.057712] [TTM] Initializing DMA pool allocator
[3.057735] vmwgfx :00:0f.0: BAR 1: can't reserve [mem 
0xe800-0xefff pref]
[3.057736] [drm] It appears like vesafb is loaded. Ignore above error if 
any.
[3.057785] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.057786] [drm] No driver support for vblank timestamp query.
[3.057836] [drm] Screen Target Display device initialized
[3.057862] [drm] width 1024
[3.057870] [drm] height 768
[3.057877] [drm] bpp 32
[3.057927] [drm] Fifo max 0x0004 min 0x1000 cap 0x077f
[3.057989] [drm] Using command buffers with DMA pool.
[3.057994] [drm] DX: no.
[3.058044] checki

Bug#874541: zfs-dkms: Importing pool fails and hangs forever (INFO: task l2arc_feed:796 blocked for more than...)

2017-09-07 Thread root
Package: zfs-dkms
Version: 0.6.5.11-1
Severity: important
Control: tag -1 + upstream
Control: forward -1 https://github.com/zfsonlinux/zfs/issues/6609

My system crashed brutally this afternoon, didn't get a stack trace at
all. Upon reboot, "zfs import storage" hangs forever, with the load
gradually reaching 3. In dmesg I see a bunch of the following:

,
| [ 1571.829354] INFO: task l2arc_feed:796 blocked for more than 120 seconds.
| [ 1571.836183]   Tainted: P  IO4.12.0-1-amd64 #1 Debian 
4.12.6-1
| [ 1571.843434] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
| [ 1571.851395] l2arc_feed  D0   796  2 0x
| [ 1571.851399] Call Trace:
| [ 1571.851406]  ? __schedule+0x3c5/0x850
| [ 1571.851409]  ? try_to_del_timer_sync+0x4d/0x80
| [ 1571.851414]  ? schedule+0x32/0x80
| [ 1571.851416]  ? schedule_preempt_disabled+0xa/0x10
| [ 1571.851418]  ? __mutex_lock.isra.4+0x2c3/0x4f0
| [ 1571.851467]  ? l2arc_feed_thread+0x1bf/0xd80 [zfs]
| [ 1571.851501]  ? l2arc_feed_thread+0x1bf/0xd80 [zfs]
| [ 1571.851505]  ? dequeue_entity+0xe4/0x460
| [ 1571.851508]  ? pick_next_task_fair+0x133/0x540
| [ 1571.851512]  ? __switch_to+0x234/0x430
| [ 1571.851521]  ? thread_generic_wrapper+0x62/0x80 [spl]
| [ 1571.851556]  ? l2arc_evict+0x370/0x370 [zfs]
| [ 1571.851563]  ? thread_generic_wrapper+0x6d/0x80 [spl]
| [ 1571.851568]  ? kthread+0xfc/0x130
| [ 1571.851574]  ? __thread_exit+0x20/0x20 [spl]
| [ 1571.851577]  ? kthread_create_on_node+0x70/0x70
| [ 1571.851580]  ? ret_from_fork+0x25/0x30
| [ 1571.851601] INFO: task zpool:12432 blocked for more than 120 seconds.
| [ 1571.858210]   Tainted: P  IO4.12.0-1-amd64 #1 Debian 
4.12.6-1
| [ 1571.865511] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
| [ 1571.873470] zpool   D0 12432   4470 0x
| [ 1571.873472] Call Trace:
| [ 1571.873476]  ? __schedule+0x3c5/0x850
| [ 1571.873533]  ? zil_claim+0x250/0x250 [zfs]
| [ 1571.873538]  ? schedule+0x32/0x80
| [ 1571.873549]  ? taskq_wait+0x7e/0xd0 [spl]
| [ 1571.873556]  ? remove_wait_queue+0x60/0x60
| [ 1571.873601]  ? dmu_objset_find_dp+0x113/0x1b0 [zfs]
| [ 1571.873656]  ? spa_load+0x18b1/0x1c80 [zfs]
| [ 1571.873662]  ? zpool_get_rewind_policy+0x74/0x1a0 [zcommon]
| [ 1571.873716]  ? spa_load_best+0x5a/0x280 [zfs]
| [ 1571.873770]  ? spa_import+0x1cb/0x710 [zfs]
| [ 1571.873825]  ? get_nvlist+0xc6/0xf0 [zfs]
| [ 1571.873880]  ? zfs_ioc_pool_import+0xf5/0x120 [zfs]
| [ 1571.873936]  ? zfsdev_ioctl+0x462/0x4f0 [zfs]
| [ 1571.873939]  ? do_vfs_ioctl+0x9f/0x600
| [ 1571.873943]  ? SyS_ioctl+0x74/0x80
| [ 1571.873946]  ? system_call_fast_compare_end+0xc/0x97
| [ 1571.873989] INFO: task dmu_objset_find:13497 blocked for more than 120 
seconds.
| [ 1571.881430]   Tainted: P  IO4.12.0-1-amd64 #1 Debian 
4.12.6-1
| [ 1571.888634] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
| [ 1571.896594] dmu_objset_find D0 13497  2 0x
| [ 1571.896596] Call Trace:
| [ 1571.896600]  ? __schedule+0x3c5/0x850
| [ 1571.896602]  ? schedule+0x32/0x80
| [ 1571.896611]  ? cv_wait_common+0x115/0x130 [spl]
| [ 1571.896617]  ? remove_wait_queue+0x60/0x60
| [ 1571.896662]  ? dmu_buf_hold_array_by_dnode+0x1bc/0x4a0 [zfs]
| [ 1571.896705]  ? dmu_read+0x9f/0x1a0 [zfs]
| [ 1571.896762]  ? space_map_load+0x1c5/0x520 [zfs]
| [ 1571.896814]  ? metaslab_load+0x2e/0xc0 [zfs]
| [ 1571.896865]  ? metaslab_activate+0x82/0xb0 [zfs]
| [ 1571.896916]  ? metaslab_claim+0x192/0x480 [zfs]
| [ 1571.896971]  ? zio_dva_claim+0x1a/0x30 [zfs]
| [ 1571.897024]  ? zio_wait+0x72/0x140 [zfs]
| [ 1571.897078]  ? zil_parse+0x1ec/0x910 [zfs]
| [ 1571.897132]  ? zil_replaying+0x60/0x60 [zfs]
| [ 1571.897194]  ? zil_claim_log_block+0xa0/0xa0 [zfs]
| [ 1571.897254]  ? zil_check_log_chain+0xe0/0x190 [zfs]
| [ 1571.897299]  ? dmu_objset_find_dp_impl+0x18a/0x3c0 [zfs]
| [ 1571.897343]  ? dmu_objset_find_dp_cb+0x25/0x40 [zfs]
| [ 1571.897354]  ? taskq_thread+0x27e/0x4b0 [spl]
| [ 1571.897361]  ? wake_up_q+0x70/0x70
| [ 1571.897367]  ? kthread+0xfc/0x130
| [ 1571.897374]  ? taskq_thread_spawn+0x50/0x50 [spl]
| [ 1571.897376]  ? kthread_create_on_node+0x70/0x70
| [ 1571.897379]  ? ret_from_fork+0x25/0x30
`

If I reboot and don't try to import, "zfs import" reports that my pool is as 
follows:

,
|pool: storage  
|  id: 12616089183921587906 
 
|   state: ONLINE   
   
|  action: The pool can be imported using its name or numeric identifier.   
 
|  config:  
 
|   
  
| storage ONLINE
 
|   mirror-0  ONLINE 

Bug#874096: xorg: X server SECURITY extension should be enabled

2017-09-03 Thread root
Source: xorg
Severity: normal

Dear Maintainer,

it seems that the X server SECURITY extension is not enabled / supported
by default. This extension is necessary for clients connecting via ssh
-X to a server, i.e. via untrusted ssh X forwarding.

While debian patches ssh to disable untrusted ssh X forwarding (i.e. ssh
-X is equivalent to ssh -Y), this is not true for all other
distributions. This results in X forwarding to fail when connecting from
a machine that uses the unpatched / upstream ssh client.

The SECURITY extension can be enabled via the --enable-xcsecurity build
flag.

See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221984


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

Locale: LANG=en_US.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#870804: rtl-sdr: rtl_tcp fails listening on ipv6

2017-08-05 Thread root
Package: rtl-sdr
Version: 0.5.3-11
Severity: wishlist

Dear Maintainer,

IPv6 can now be considered the default IP protocoll, which should be used by 
all applications.

# rtl_tcp -a ::
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 0001

Using device 0: Generic RTL2832U OEM
Detached kernel driver
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Tuned to 1 Hz.
listening...
Use the device argument 'rtl_tcp=:::1234' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).

rtl_tcp does seem to correctly listen to the 'any' ipv6 address... but:

# netstat -anp | grep rtl_tcp
tcp0  0 255.255.255.255:12340.0.0.0:*   LISTEN  
4999/rtl_tcp

Nope, it just somehow listens to the IPv4 broadcast address, which also is 
useless.

The same happens if you specify any other IPv6 address:

# rtl_tcp -a 2001:4060:dead:babe:f98e:1e76:385b:faa0
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 0001

Using device 0: Generic RTL2832U OEM
Detached kernel driver
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Tuned to 1 Hz.
listening...
Use the device argument 'rtl_tcp=2001:4060:dead:babe:f98e:1e76:385b:faa0:1234' 
in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).

# netstat -anp | grep rtl_tcp
tcp0  0 255.255.255.255:12340.0.0.0:*   LISTEN  
5143/rtl_tcp

# rtl_tcp -a [2001:4060:dead:babe:f98e:1e76:385b:faa0]
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 0001

Using device 0: Generic RTL2832U OEM
Detached kernel driver
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Tuned to 1 Hz.
listening...
Use the device argument 
'rtl_tcp=[2001:4060:dead:babe:f98e:1e76:385b:faa0]:1234' in OsmoSDR 
(gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).

# netstat -anp | grep rtl_tcp
tcp0  0 255.255.255.255:12340.0.0.0:*   LISTEN  
5174/rtl_tcp

So I suppose IPv6 support somehow is broken in rtl_tcp

-Benoit-

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 9.1 (stretch)
Release:9.1
Codename:   stretch
Architecture: armv7l

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

Versions of packages rtl-sdr depends on:
ii  libc6 2.24-11+deb9u1
ii  librtlsdr00.5.3-11
ii  libusb-1.0-0  2:1.0.21-1

rtl-sdr recommends no packages.

rtl-sdr suggests no packages.

-- no debconf information



Bug#869871: exim4-config: /etc/mailname is ignored

2017-07-27 Thread root
Package: exim4-config
Version: 4.89-2+deb9u1
Severity: normal

Dear Maintainer,

after a fresh install of exim4 on debian stretch, and moving our old
configuration, I found out that mail to unqualified adresses is sent
to user@`hostname -f` instead of user@`cat /etc/mailname`. Just as if
MAIN_PRIMARY_HOSTNAME_AS_QUALIFY_DOMAIN was set.

I have entered the mailname using dpkg-reconfigure exim4-config, and
it is properly set in /etc/mailname and also in
/var/lib/exim4/config.autogenerated:

.ifndef ETC_MAILNAME
ETC_MAILNAME=dopis.cz
.endif

...

.ifndef MAIN_PRIMARY_HOSTNAME_AS_QUALIFY_DOMAIN
.ifndef MAIN_QUALIFY_DOMAIN
qualify_domain = ETC_MAILNAME
.else
qualify_domain = MAIN_QUALIFY_DOMAIN
.endif
.endif

There are no other declarations of
MAIN_PRIMARY_HOSTNAME_AS_QUALIFY_DOMAIN, MAIN_QUALIFY_DOMAIN and
ETC_MAILNAME

I even tried to set MAIN_QUALIFY_DOMAIN, and it did not help either.
Please, look at it and suggest a fix or at least a workaround.

Best Regards
Vladislav Kurz

-- Package-specific info:
Exim version 4.89 #1 built 14-Jun-2017 05:03:07
Copyright (c) University of Cambridge, 1995 - 2017
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2017
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS 
move_frozen_messages Content_Scanning DKIM DNSSEC Event OCSP PRDR PROXY SOCKS 
TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa tls
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to generate
# exim configuration macros for the configuration file.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='internet'
dc_other_hostnames='dopis.cz;diskuze.dopis.cz;news.dopis.cz;skupiny.edb.cz'
dc_local_interfaces=''
dc_readhost=''
dc_relay_domains='@mx_secondary;datev.cz'
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='cyrus_delivery'
mailname:dopis.cz
# /etc/default/exim4
EX4DEF_VERSION=''

# 'combined' -   one daemon running queue and listening on SMTP port
# 'no'   -   no daemon running the queue
# 'separate' -   two separate daemons
# 'ppp'  -   only run queue with /etc/ppp/ip-up.d/exim4.
# 'nodaemon' - no daemon is started at all.
# 'queueonly' - only a queue running daemon is started, no SMTP listener.
# setting this to 'no' will also disable queueruns from /etc/ppp/ip-up.d/exim4
QUEUERUNNER='combined'
# how often should we run the queue
QUEUEINTERVAL='30m'
# options common to quez-runner and listening daemon
COMMONOPTIONS=''
# more options for the daemon/process running the queue (applies to the one
# started in /etc/ppp/ip-up.d/exim4, too.
QUEUERUNNEROPTIONS=''
# special flags given to exim directly after the -q. See exim(8)
QFLAGS=''
# Options for the SMTP listener daemon. By default, it is listening on
# port 25 only. To listen on more ports, it is recommended to use
# -oX 25:587:10025 -oP /run/exim4/exim.pid
SMTPLISTENEROPTIONS=''

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

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

Versions of packages exim4-config depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61

exim4-config recommends no packages.

exim4-config suggests no packages.

-- Configuration Files:
/etc/email-addresses changed [not included]
/etc/exim4/conf.d/acl/30_exim4-config_check_mail changed [not included]
/etc/exim4/conf.d/acl/30_exim4-config_check_rcpt changed [not included]
/etc/exim4/conf.d/acl/40_exim4-config_check_data changed [not included]
/etc/exim4/conf.d/auth/30_exim4-config_examples changed [not included]
/etc/exim4/conf.d/main/02_exim4-config_options changed [not included]

Bug#869870: cyrus-common: cron.daily script does not work

2017-07-27 Thread root
Package: cyrus-common
Version: 2.5.10-3
Severity: normal

Dear Maintainer,

I have a fresh isntall of cyrus od debian stretch. I have noticed thet
the cron.daily script does nothing. After some debugging I found out
that the problem is in the detection of cyrus version. The script
works only id version 2.2 or 2.4 are detected, but not when 2.5 is
installed.

The problem is in line 36. Patch is here:

  # Check if Cyrus is installed (vs. removed but not purged)
- grep -qE '^PACKAGE_VERSION[[:blank:]]+2[.][24]' \
+ grep -qE '^PACKAGE_VERSION[[:blank:]]+2[.][245]' \
  /usr/lib/cyrus/cyrus-hardwired-config.txt >/dev/null 2>&1 || exit 0


Best Regards
Vladislav Kurz

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

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

Versions of packages cyrus-common depends on:
ii  adduser3.115
ii  db-upgrade-util5.3.1
ii  db-util5.3.1
ii  debconf [debconf-2.0]  1.5.61
ii  dpkg   1.18.24
ii  exim4-daemon-heavy [mail-transport-agent]  4.89-2+deb9u1
ii  gawk   1:4.1.4+dfsg-1
ii  libc6  2.24-11+deb9u1
ii  libcomerr2 1.43.4-2
ii  libdb5.3   5.3.28-12+b1
ii  libgssapi-krb5-2   1.15-1
ii  libical2   2.0.0-0.5+b1
ii  libicu57   57.1-6
ii  libjansson42.9-1
ii  libk5crypto3   1.15-1
ii  libkrb5-3  1.15-1
ii  libkrb5support01.15-1
ii  libldap-2.4-2  2.4.44+dfsg-5
ii  libpcre3   2:8.39-3
ii  libsasl2-2 2.1.27~101-g0780600+dfsg-3
ii  libsasl2-modules   2.1.27~101-g0780600+dfsg-3
ii  libsnmp30  5.7.3+dfsg-1.7
ii  libsqlite3-0   3.16.2-5
ii  libssl1.1  1.1.0f-3
ii  libwrap0   7.6.q-26
ii  libxml22.9.4+dfsg1-2.2
ii  libzephyr4 3.1.2-1+b2
ii  netbase5.4
ii  perl   5.24.1-3+deb9u1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages cyrus-common recommends:
ii  cyrus-admin   2.5.10-3
ii  cyrus-caldav  2.5.10-3
ii  cyrus-imapd   2.5.10-3
ii  cyrus-pop3d   2.5.10-3

Versions of packages cyrus-common suggests:
ii  apt-listchanges3.10
ii  cyrus-admin2.5.10-3
ii  cyrus-caldav   2.5.10-3
pn  cyrus-clients  
ii  cyrus-doc  2.5.10-3
ii  cyrus-imapd2.5.10-3
pn  cyrus-murder   
pn  cyrus-nntpd
ii  cyrus-pop3d2.5.10-3
pn  cyrus-replication  
ii  sasl2-bin  2.1.27~101-g0780600+dfsg-3


-- debconf information:
* cyrus-common/removespools: false



Bug#869679: icinga: /var/log/icinga/* not readable by www-data, preventing history viewing from web frontend

2017-07-25 Thread root
Package: icinga
Version: 1.13.4-2
Severity: normal

Dear Maintainer,

in the version of icinga in stretch, the icinca log files are created with 
permissions 600, 
user and group nagios:nagios or nagios:adm. This prevents the web frontend 
(which is run as 
www-data in case of apache2) from accessing it and displaying history for a 
service:

"Log file "/var/log/icinga/icinga.log" invalid! No timestamp found within first 
16 bytes!

I have found not way of fixing this via additional group memberships. This was 
not the case
in nagios as distributed with the previous release. 

Thanks for looking into this,

Christian


-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
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 icinga depends on:
ii  icinga-cgi   1.13.4-2
ii  icinga-core  1.13.4-2

Versions of packages icinga recommends:
ii  icinga-doc  1.13.4-2

Versions of packages icinga suggests:
ii  nagios-nrpe-plugin  3.0.1-3+deb9u1

-- no debconf information



Bug#867714: ITP: golang-github-stripe-krl -- OpenSSH Key Revocation List support for Go

2017-07-08 Thread root
Package: wnpp
Severity: wishlist
Owner: Patrick O'Doherty 

* Package name: golang-github-stripe-krl
  Version : 0.0~git20160721.0.fd565ec-1
  Upstream Author : Stripe
* URL : https://github.com/stripe/krl
* License : Expat
  Programming Lang: Go
  Description : OpenSSH Key Revocation List support for Go
 krl provides functionality for reading and writing SSH Key Revocation Lists
 (KRLs).



Bug#867523: ITP: golang-github-pkg-browser -- Package browser provides helpers to open files, readers, and urls in a browser window.

2017-07-06 Thread root
Package: wnpp
Severity: wishlist
Owner: Patrick O'Doherty 

* Package name: golang-github-pkg-browser
  Version : 0.0~git20170505.0.c90ca0c-1
  Upstream Author : 
* URL : https://github.com/pkg/browser
* License : BSD-2-clause
  Programming Lang: Go
  Description : provides helpers to open files, readers, and urls in a 
browser window.

 Package browser provides helpers to open files, readers, and URLs in a browser 
window.



Bug#867521: ITP: golang-github-mikesmitty-edkey -- edkey allows you to write ED25519 private keys in the OpenSSH private key format

2017-07-06 Thread root
Package: wnpp
Severity: wishlist
Owner: Patrick O'Doherty 

* Package name: golang-github-mikesmitty-edkey
  Version : 0.0~git20170222.0.3356ea4-1
  Upstream Author : Michael Smith
* URL : https://github.com/mikesmitty/edkey
* License : MIT
  Programming Lang: Go
  Description : edkey allows you to write ED25519 private keys in the 
OpenSSH private key format

 edkey edkey allows you to marshal/write ED25519 private keys in the
 OpenSSH private key format. 



Bug#866037: edge.c: 212 ERROR: LZO compression error

2017-06-26 Thread root
Package: n2n
Version: 1.3.1~svn3789-5+b1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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



-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

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

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

n2n recommends no packages.

n2n suggests no packages.

-- no debconf information



Bug#864243: php5-memcached: I have a Unable to load dynamic library '/usr/lib/php5/20131226/memcached.so' error message

2017-06-05 Thread root
Package: php5-memcached
Version: 2.2.0-2
Severity: important

Dear Maintainer,

The complete message I get is:

PHP Warning:  PHP Startup: Unable to load dynamic library 
'/usr/lib/php5/20131226/memcached.so' - /usr/lib/php5/20131226/memcached.so: 
undefined symbol: memcached_destroy_sasl_auth_data in Unknown on line 0


   * What led up to the situation?
I suppose the issue happens after having done update of all packages 
suggested in my ISPConfig.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried to reinstall php5-memecached package, unsuccessfully.
apt-get install --reinstall php5-memcached
   * What was the outcome of this action?
No changes.
   * What outcome did you expect instead?
I expected to have an update on library memcached.so that awould avoi 
to have the WARNING alert.



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

Kernel: Linux 3.14.32--grs-ipv6-64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages php5-memcached depends on:
ii  libc6  2.19-18+deb8u7
ii  libmemcached11 1.0.18-4
ii  libmemcachedutil2  1.0.18-4
ii  libsasl2-2 2.1.26.dfsg1-13+deb8u1
ii  php5-common [phpapi-20131226]  5.6.30+dfsg-0+deb8u1
ii  ucf3.0030
ii  zlib1g 1:1.2.8.dfsg-2+b1

php5-memcached recommends no packages.

php5-memcached suggests no packages.

-- no debconf information



Bug#861838: ldap-utils: ldapsearch and ldapwhoami cannot connect to ldaps server

2017-05-04 Thread root
Package: ldap-utils
Version: 2.4.40+dfsg-1+deb8u2
Severity: normal

Dear Maintainer,

On a fresh install of Debian 8,  I cannot get ldapsearch or ldapwhoami to 
connect to an LDAPS
server.  There appears to be some TLS happening, and a connections is made, 
but then it fails without any useful error messages on debug level 1.


contents of /etc/ldap/ldap.conf:

TLS_CACERT  /etc/ssl/certs/ca-certificates.crt

# MattW 04/19/2017 - Added the following
TLS_REQCERT  allow
SSL start_tls



root@ldi-deb8-test:~/UW-LDI# !ldapsearch
ldapsearch -d1  -Z  -H ldap://ldi.s.uw.edu -W  -D 
cn=unitAdmin,ou=auth,ou=csde,dc=ldi,dc=uw,dc=edu -LLL -s base -b 
cn=unitAdmin,ou=auth,ou=csde,dc=ldi,dc=uw,dc=edu
ldap_url_parse_ext(ldap://ldi.s.uw.edu)
ldap_create
ldap_url_parse_ext(ldap://ldi.s.uw.edu:389/??base)
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldi.s.uw.edu:389
ldap_new_socket: 4
ldap_prepare_socket: 4
ldap_connect_to_host: Trying 69.91.245.42:389
ldap_pvt_connect: fd: 4 tm: -1 async: 0
attempting to connect: 
connect success
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush2: 31 bytes to sd 4
ldap_result ld 0x7f9918572860 msgid 1
wait4msg ld 0x7f9918572860 msgid 1 (infinite timeout)
wait4msg continue ld 0x7f9918572860 msgid 1 all 1
** ld 0x7f9918572860 Connections:
* host: ldi.s.uw.edu  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu May  4 08:08:31 2017


** ld 0x7f9918572860 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7f9918572860 request count 1 (abandoned 0)
** ld 0x7f9918572860 Response Queue:
   Empty
  ld 0x7f9918572860 response count 0
ldap_chkResponseList ld 0x7f9918572860 msgid 1 all 1
ldap_chkResponseList returns ld 0x7f9918572860 NULL
ldap_int_select
read1msg: ld 0x7f9918572860 msgid 1 all 1
ber_get_next
ber_get_next: tag 0x30 len 12 contents:
read1msg: ld 0x7f9918572860 msgid 1 message type extended-result
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x7f9918572860 0 new referrals
read1msg:  mark request completed, ld 0x7f9918572860 msgid 1
request done: ld 0x7f9918572860 msgid 1
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_parse_extended_result
ber_scanf fmt ({eAA) ber:
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
Enter LDAP Password: 
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 74 bytes to sd 4
ldap_result ld 0x7f9918572860 msgid 2
wait4msg ld 0x7f9918572860 msgid 2 (infinite timeout)
wait4msg continue ld 0x7f9918572860 msgid 2 all 1
** ld 0x7f9918572860 Connections:
* host: ldi.s.uw.edu  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu May  4 08:08:38 2017


** ld 0x7f9918572860 Outstanding Requests:
 * msgid 2,  origid 2, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7f9918572860 request count 1 (abandoned 0)
** ld 0x7f9918572860 Response Queue:
   Empty
  ld 0x7f9918572860 response count 0
ldap_chkResponseList ld 0x7f9918572860 msgid 2 all 1
ldap_chkResponseList returns ld 0x7f9918572860 NULL
ldap_int_select
read1msg: ld 0x7f9918572860 msgid 2 all 1
ber_get_next
ldap_err2string
ldap_result: Can't contact LDAP server (-1)
ldap_free_request (origid 2, msgid 2)
ldap_free_connection 1 1
ldap_free_connection: actually freed
root@ldi-deb8-test:~/UW-LDI# 



root@ldi-deb8-test:~/UW-LDI# ldapwhoami -d1 -H 'ldaps://ldi.s.uw.edu' -w 
'passwerd' -D cn=unitAdmin,ou=auth,ou=csde,ou=ldi,ou=uw,ou=edu  
ldap_url_parse_ext(ldaps://ldi.s.uw.edu)
ldap_create
ldap_url_parse_ext(ldaps://ldi.s.uw.edu:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldi.s.uw.edu:636
ldap_new_socket: 4
ldap_prepare_socket: 4
ldap_connect_to_host: Trying 128.208.178.146:636
ldap_pvt_connect: fd: 4 tm: -1 async: 0
attempting to connect: 
connect success
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 74 bytes to sd 4
ldap_result ld 0x7f80d936b820 msgid 1
wait4msg ld 0x7f80d936b820 msgid 1 (infinite timeout)
wait4msg continue ld 0x7f80d936b820 msgid 1 all 1
** ld 0x7f80d936b820 Connections:
* host: ldi.s.uw.edu  port: 636  (default)
  refcnt: 2  status: Connected
  last used: Thu May  4 08:35:31 2017


** ld 0x7f80d936b820 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7f80d936b820 request count 1 (abandoned 0)
** ld 0x7f80d936b820 Response Queue:
   Empty
  ld 0x7f80d936b820 response count 0
ldap_chkResponseList ld 0x7f80d936b820 msgid 1 all 1
ldap_chkResponseList returns ld 0x7f80d936b820 NULL
ldap_int_select
read1msg: ld 0x7f80d936b820 m

Bug#855032: burp -aS does not give a backup summary

2017-02-13 Thread root
Package: burp
Version: 2.0.54-1~bpo8+1
Severity: normal

/etc/cron.d/burp includes a line for a daily backup summary
on the server effectively calling

burp -c /etc/burp/burp-server.conf -aS

but the output of this command is always empty.

What is the problem?

Christoph

-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (600, 'stable'), (60, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages burp depends on:
ii  libacl1  2.2.52-2
ii  libc62.19-18+deb8u7
ii  libncurses5  5.9+20140913-1+b1
ii  librsync10.9.7-10
ii  libssl1.0.0  1.0.1t-1+deb8u6
ii  libtinfo55.9+20140913-1+b1
ii  lsb-base 4.1+Debian13+nmu1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages burp recommends:
ii  openssl  1.0.1t-1+deb8u6

burp suggests no packages.

-- Configuration Files:
/etc/burp/autoupgrade/server/win32/script 9fd3f78e1a9658d52ce38dcf76628507 
[Errno 2] No such file or directory: 
u'/etc/burp/autoupgrade/server/win32/script 9fd3f78e1a9658d52ce38dcf76628507'
/etc/burp/autoupgrade/server/win64/script 9fd3f78e1a9658d52ce38dcf76628507 
[Errno 2] No such file or directory: 
u'/etc/burp/autoupgrade/server/win64/script 9fd3f78e1a9658d52ce38dcf76628507'
/etc/burp/burp-server.conf changed [not included]
/etc/burp/burp.conf changed [not included]
/etc/burp/notify_script 3f24e693d8428a0b2e92ae06b9aca202 [Errno 2] No such file 
or directory: u'/etc/burp/notify_script 3f24e693d8428a0b2e92ae06b9aca202'
/etc/burp/ssl_extra_checks_script fb35f9998b43360560fedb71c7fcb82b [Errno 2] No 
such file or directory: u'/etc/burp/ssl_extra_checks_script 
fb35f9998b43360560fedb71c7fcb82b'
/etc/burp/summary_script 8bf862c0ea15d0b221c0565223e6b2eb [Errno 2] No such 
file or directory: u'/etc/burp/summary_script 8bf862c0ea15d0b221c0565223e6b2eb'
/etc/burp/timer_script a1dcd00328783fc6f8feb9c62332534e [Errno 2] No such file 
or directory: u'/etc/burp/timer_script a1dcd00328783fc6f8feb9c62332534e'
/etc/cron.d/burp changed [not included]
/etc/default/burp changed [not included]
/etc/logrotate.d/burp changed [not included]

-- no debconf information



Bug#849128: ERROR: /usr/lib/libnvidia-gtk3.so.367.57: undefined symbol: ctk_init_check

2016-12-22 Thread root
Package: nvidia-settings
Version: 367.57-1~bpo8+1
Severity: important

Dear Maintainer,

После очередного обновления nvidia-settings
перестал запускатся.

nvidia-settings (367.57-1~bpo8+1) из jessie-backports


~ $ nvidia-settings

ERROR: /usr/lib/libnvidia-gtk3.so.367.57: undefined symbol: ctk_init_check
   /usr/lib/libnvidia-gtk3.so.367.57: undefined symbol: ctk_get_display
   /usr/lib/libnvidia-gtk3.so.367.57: undefined symbol: ctk_main
   libnvidia-gtk3.so: cannot open shared object file: No such file or
directory
   /usr/lib/libnvidia-gtk2.so.367.57: undefined symbol: ctk_init_check
   /usr/lib/libnvidia-gtk2.so.367.57: undefined symbol: ctk_get_display
   /usr/lib/libnvidia-gtk2.so.367.57: undefined symbol: ctk_main
   libnvidia-gtk2.so: cannot open shared object file: No such file or
directory


ERROR: A problem occurred when loading the GUI library. Please check your
installation and library path. You may
   need to specify this library when calling nvidia-settings. Please run
`nvidia-settings --help` for usage
   information.
---
~ $ sudo ls -l /usr/lib/libnvidia*
-rw-r--r-- 1 root root 1721016 дек 18 18:17 /usr/lib/libnvidia-
gtk2.so.367.57
-rw-r--r-- 1 root root 1712824 дек 18 18:17 /usr/lib/libnvidia-
gtk3.so.367.57



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

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

Versions of packages nvidia-settings depends on:
ii  libc6 2.19-18+deb8u6
ii  libcairo2 1.14.0-2.1+deb8u1
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libglib2.0-0  2.42.1-1+b1
ii  libgtk-3-03.14.5-1+deb8u1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libjansson4   2.7-1+deb8u1
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libx11-6  2:1.6.2-3
ii  libxnvctrl0   367.57-1~bpo8+1
ii  libxxf86vm1   1:1.1.3-1+b1
ii  nvidia-alternative367.57-2~bpo8+1
ii  nvidia-installer-cleanup  20151021+1~bpo8+1
ii  pkg-config0.28-1

Versions of packages nvidia-settings recommends:
ii  libgl1-nvidia-glx  367.57-2~bpo8+1

nvidia-settings suggests no packages.

-- no debconf information



Bug#847502: libpython2.7-minimal: python check_output causes MemoryError on raspberry

2016-12-08 Thread root
Package: libpython2.7-minimal
Version: 2.7.9-2+deb8u1
Severity: normal

Dear Maintainer,

after the line 'def check_output(*popenargs, **kwargs):' of 
/usr/lib/python2.7/subprocess.py there is a letter r before comment which 
causes MemoryError with the following command on raspberry pi with last update 
: from subprocess import check_output



-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 8.0 (jessie)
Release:8.0
Codename:   jessie
Architecture: armv7l

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

libpython2.7-minimal depends on no packages.

Versions of packages libpython2.7-minimal recommends:
ii  libpython2.7-stdlib  2.7.9-2+deb8u1

libpython2.7-minimal suggests no packages.

-- no debconf information



Bug#847360: linux-image-3.16.0-4-amd64: kernel panic

2016-12-07 Thread root
adonly=on,format=raw -device 
ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev 
tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device 
virtio-net-pci,netdev=hostnet0,id=ne
 t0,mac=52:54:00:13:12:48,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 
-device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -k en-us 
-device 
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on


-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)

** Command line:
BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/aurum-root ro console=tty0 
console=ttyS0,115200n8

** Not tainted

** Kernel log:
[69445.676299] docker0: port 1(veth404768a) entered disabled state
[69445.678264] device veth404768a left promiscuous mode
[69445.680122] docker0: port 1(veth404768a) entered disabled state
[69446.779011] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[69446.859798] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[69446.924581] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[69446.956980] device veth11eedce entered promiscuous mode
[69446.958783] IPv6: ADDRCONF(NETDEV_UP): veth11eedce: link is not ready
[69446.960742] docker0: port 1(veth11eedce) entered forwarding state
[69446.961926] docker0: port 1(veth11eedce) entered forwarding state
[69447.160667] IPv6: ADDRCONF(NETDEV_CHANGE): veth11eedce: link becomes ready
[69447.392314] docker0: port 1(veth11eedce) entered disabled state
[69447.394347] device veth11eedce left promiscuous mode
[69447.395477] docker0: port 1(veth11eedce) entered disabled state
[69448.611751] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[69448.742284] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[69448.843207] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[69448.868790] device veth93ada16 entered promiscuous mode
[69448.869846] IPv6: ADDRCONF(NETDEV_UP): veth93ada16: link is not ready
[69448.871053] docker0: port 1(veth93ada16) entered forwarding state
[69448.872205] docker0: port 1(veth93ada16) entered forwarding state
[69449.078765] IPv6: ADDRCONF(NETDEV_CHANGE): veth93ada16: link becomes ready
[69452.886025] docker0: port 1(veth93ada16) entered disabled state
[69452.901687] docker0: port 1(veth93ada16) entered disabled state
[69452.903575] device veth93ada16 left promiscuous mode
[69452.904543] docker0: port 1(veth93ada16) entered disabled state
[69655.289325] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[69655.450359] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[69655.550071] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[69655.596845] device veth142fceb entered promiscuous mode
[69655.597944] IPv6: ADDRCONF(NETDEV_UP): veth142fceb: link is not ready
[69655.804316] IPv6: ADDRCONF(NETDEV_CHANGE): veth142fceb: link becomes ready
[69655.806131] docker0: port 1(veth142fceb) entered forwarding state
[69655.807708] docker0: port 1(veth142fceb) entered forwarding state
[69656.060173] docker0: port 1(veth142fceb) entered disabled state
[69656.062304] device veth142fceb left promiscuous mode
[69656.063391] docker0: port 1(veth142fceb) entered disabled state
[69657.237926] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[69657.339535] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[69657.430925] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[69657.452715] device veth3d67b97 entered promiscuous mode
[69657.454671] IPv6: ADDRCONF(NETDEV_UP): veth3d67b97: link is not ready
[69657.456157] docker0: port 1(veth3d67b97) entered forwarding state
[69657.458101] docker0: port 1(veth3d67b97) entered forwarding state
[69657.613119] docker0: port 1(veth3d67b97) entered disabled state
[69657.614911] IPv6: ADDRCONF(NETDEV_CHANGE): veth3d67b97: link becomes ready
[69657.616667] docker0: port 1(veth3d67b97) entered forwarding state
[69657.618074] docker0: port 1(veth3d67b97) entered forwarding state
[69657.868378] docker0: port 1(veth3d67b97) entered disabled state
[69657.870501] device veth3d67b97 left promiscuous mode
[69657.871944] docker0: port 1(veth3d67b97) entered disabled state
[69658.988497] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[69659.116435] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[69659.208507] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[69659.228681] device veth219fda5 entered promiscuous mode
[69659.229756] IPv6: ADDRCONF(NETDEV_UP): veth219fda5: link is not ready
[69659.230906] docker0: port 1(veth219fda5) entered forwarding state
[69659.231949] docker0: 

Bug#845646: nut: System does not reboot if nut installed on jessie

2016-11-25 Thread root
Package: nut
Version: 2.7.2-4
Severity: important

Dear Maintainer,

I have a new server running Debian Jessie, and when I reboot
it (e.g. due to kernel upgrade), it only halts. Last thing
on the screen is something like "systemd reached shutdown
target", and it newer reboots or shuts down.

I have this problem only on one of several new servers, and
the only difference I found is that this one uses nut to
monitor UPS. I suspect the file
/lib/systemd/system-shutdown/nutshutdown to have some bad
influence on the shutdown procedure. This problem may be
related to bugs #83 and #835634, although this is a bit
different scenario. I do not really want to cut power on
UPS, I just want to reboot the server. 

I think I did not notice it earlier as I had a watchdog
running (maually started). But it has a bug of its own, and
does not start automatically. Both seem like a bug with
systemd integration.

Thanks for any hints
Vladislav Kurz

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

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

Versions of packages nut depends on:
ii  nut-client  2.7.2-4
ii  nut-server  2.7.2-4

nut recommends no packages.

nut suggests no packages.

-- no debconf information



Bug#841895: apf-firewall: Apf blocks mysql connection on 127.0.0.1

2016-10-24 Thread root@webx
Package: apf-firewall
Version: 9.7+rev1-3
Severity: important

There is a daily cronjob running which is restarting apf-firewall. However, 
sometimes 
it breaks my system - to be specific - it somehow blocks connectivity for mysql 
on 127.0.0.1 
and I'm not able to connect neither command line, websites are not working, MTA 
postfix (with ispconfig) 
fails to check for table lookup (because it's connecting to with user/pass on 
127.0.0.1. Localhost 
connections are working normally. After stopped firewall with e.g. "apf -f" - 
on first F5 refresh all 
websites are working, I'm able to connect in mysql through "mysql -p -h 
127.0.0.1". This doesn't happen 
every day, it happens on random basics and always in same time around 06:26AM - 
cronjob dailys are schedules 
to run on 06:25AM. I can't reproduce the problem, but so far I know that 
stopping apf-firewal 
fixes the problem. I don't even have to restart mysql/MTA - stopping apf is 
enough. Any idea what 
could cause this?

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 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)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages apf-firewall depends on:
ii  iproute   1:3.16.0-2
ii  iptables  1.4.21-2+b1
ii  lsb-base  4.1+Debian13+nmu1
ii  wget  1.16-1

apf-firewall recommends no packages.

apf-firewall suggests no packages.

-- Configuration Files:
/etc/apf-firewall/conf.apf changed [not included]
/etc/apf-firewall/deny_hosts.rules [Errno 13] Permission denied: 
u'/etc/apf-firewall/deny_hosts.rules'
/etc/apf-firewall/ds_hosts.rules [Errno 13] Permission denied: 
u'/etc/apf-firewall/ds_hosts.rules'
/etc/apf-firewall/glob_allow.rules [Errno 13] Permission denied: 
u'/etc/apf-firewall/glob_allow.rules'
/etc/apf-firewall/glob_deny.rules [Errno 13] Permission denied: 
u'/etc/apf-firewall/glob_deny.rules'
/etc/apf-firewall/preroute.rules changed [not included]
/etc/apf-firewall/sdrop_hosts.rules [Errno 13] Permission denied: 
u'/etc/apf-firewall/sdrop_hosts.rules'
/etc/cron.daily/apf-firewall changed [not included]
/etc/default/apf-firewall changed [not included]

-- no debconf information



  1   2   3   4   5   6   >