Bug#1028562: phpsysinfo: Please provide a configuration file for Apache
Package: phpsysinfo Version: 3.4.2-1 Severity: normal Dear Maintainer, To make phpsysinfo accessible in Apache2, I had to create a file /etc/apache2/conf-available/phpsysinfo.conf with the following contents: Alias /phpsysinfo /usr/share/phpsysinfo Options None Require all granted And afterwards, I had to enable this configuration by executing those commands: a2enconf phpsysinfo systemctl restart apache2.service It would be great if this could be done automatically during installation of the package. Cheers, Timo
Bug#1027010: libclamav9 0.103.7+dfsg-1+b2 leads to ERROR: Can't verify database integrity
Package: libclamav9 Followup-For: Bug #1027010 I can confirm the same thing on my system (Debian/testing). I see the following output via 'systemctl status clamav-daemon.service': systemd[1]: Started Clam AntiVirus userspace daemon. clamd[..]: LibClamAV Error: cli_loadinfo: Incorrect digital signature clamd[..]: LibClamAV Error: cli_loadinfo: Problem parsing database at line 25 clamd[..]: LibClamAV Error: Can't load daily.info: Malformed database clamd[..]: LibClamAV Error: cli_tgzload: Can't load daily.info clamd[..]: LibClamAV Error: Can't load /var/lib/clamav/daily.cld: Malformed database clamd[..]: LibClamAV Error: cli_loaddbdir(): error loading database /var/lib/clamav/daily.cld clamd[..]: Mon Dec 26 12:09:32 2022 -> !Malformed database systemd[1]: clamav-daemon.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: clamav-daemon.service: Failed with result 'exit-code'. And downgrading the package to version 0.103.7+dfsg-1+b1 indeed resolves it. Best regards, Timo
Bug#1027018: libpam-cap: PAM unable to dlopen(pam_cap.so): /lib/security/pam_cap.so: cannot open shared object file
Package: libpam-cap Version: 1:2.66-3 Severity: normal Dear Maintainer, After upgrading libcap2:amd64 from 1:2.44-1 to 1:2.66-3, I see the following error messages in auth.log: smbd[...]: PAM unable to dlopen(pam_cap.so): /lib/security/pam_cap.so: cannot open shared object file: No such file or directory smbd[...]: PAM adding faulty module: pam_cap.so This was reported previously, but I had to submit a new report as the original one has been archived. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951144 It seems to be a transient issue, because it disappears after restarting Samba using 'systemctl restart smbd.service'. Best regards, Timo -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-security'), (500, 'stable'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpam-cap depends on: ii libc6 2.36-6 ii libcap2 1:2.66-3 ii libpam-runtime 1.5.2-5 ii libpam0g1.5.2-5 libpam-cap recommends no packages. libpam-cap suggests no packages. -- no debconf information
Bug#1023177: sogo: CalDAV/CardDAV synchronization broken due to unexpected UTF-8 BOM in calendar and contact data
Package: sogo Version: 5.7.1-3+b1 Severity: normal Tags: upstream Dear Maintainer, Synchronizing of calendars and address books (via CalDAV/CardDAV) is not working. I experience the issue in the Thunderbird client (on Windows) as well as DAVx5 (on Android). The issue is that content starts with an UTF-8 Byte-Order-Mark (BOM), caused by changes in gnustep-base introduced between version 1.27 and 1.28, as described here: https://bugzilla.mozilla.org/show_bug.cgi?id=1737067 This bug is tracked upstream: https://bugs.sogo.nu/view.php?id=5416 https://github.com/gnustep/libs-base/issues/212 There also seems to be a patch available upstream, but this has not been merged in v5.7.1: https://github.com/Alinto/sogo/pull/324 Best regards, Timo -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-security'), (500, 'stable'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sogo depends on: ii adduser3.129 ii gnustep-base-runtime 1.28.0-4+b1 ii init-system-helpers1.65.2 ii libc6 2.35-4 ii libcrypt1 1:4.4.28-2 ii libcurl4 7.85.0-1 ii libgcc-s1 12.2.0-3 ii libglib2.0-0 2.74.0-3 ii libgnustep-base1.281.28.0-4+b1 ii liblasso3 2.8.0-1+b4 ii libmemcached11 1.0.18+-1+b1 ii liboath0 2.6.7-3 ii libobjc4 12.2.0-3 ii libsbjson2.3 2.3.2-4+b4 ii libsodium231.0.18-1 ii libsope1 5.7.1-1 ii libssl33.0.5-4 ii libytnef0 2.0-1+b1 ii libzip41.7.3-1+b1 ii lsb-base 11.4 ii memcached 1.6.17-1+b1 ii sogo-common5.7.1-3 ii systemd251.6-1 ii sysvinit-utils [lsb-base] 3.05-6 ii zip3.0-12 Versions of packages sogo suggests: ii mariadb-server-10.6 [virtual-mysql-server] 1:10.6.10-1+b1 -- no debconf information
Bug#1019857: fetchmail: Running as root is discouraged / no mailservers have been specified
Package: fetchmail Version: 6.4.33-1 Severity: normal Dear Maintainer, I'm getting the following messages in the syslog: Sep 15 01:03:21 systemd[1]: Starting LSB: init-Script for system wide fetchmail daemon... Sep 15 01:03:21 fetchmail[2245]: Starting mail retriever agent: fetchmail. Sep 15 01:03:21 systemd[1]: Started LSB: init-Script for system wide fetchmail daemon. Sep 15 01:03:21 fetchmail[2263]: starting fetchmail 6.4.33 daemon Sep 15 01:03:25 fetchmail[2310]: fetchmail: WARNING: Running as root is discouraged. Sep 15 01:03:25 fetchmail[2310]: fetchmail: no mailservers have been specified. Sep 15 01:03:25 systemd[2293]: fetchmail.service: Main process exited, code=exited, status=5/NOTINSTALLED Sep 15 01:03:25 systemd[2293]: fetchmail.service: Failed with result 'exit-code'. Sep 15 01:03:25 systemd[2293]: fetchmail.service: Scheduled restart job, restart counter is at 1. Sep 15 01:03:25 fetchmail[2338]: fetchmail: WARNING: Running as root is discouraged. Sep 15 01:03:25 fetchmail[2338]: fetchmail: no mailservers have been specified. Sep 15 01:03:25 systemd[2293]: fetchmail.service: Main process exited, code=exited, status=5/NOTINSTALLED Sep 15 01:03:25 systemd[2293]: fetchmail.service: Failed with result 'exit-code'. Sep 15 01:03:26 systemd[2293]: fetchmail.service: Scheduled restart job, restart counter is at 2. Sep 15 01:03:26 fetchmail[2342]: fetchmail: WARNING: Running as root is discouraged. Sep 15 01:03:26 fetchmail[2342]: fetchmail: no mailservers have been specified. Sep 15 01:03:26 systemd[2293]: fetchmail.service: Main process exited, code=exited, status=5/NOTINSTALLED Sep 15 01:03:26 systemd[2293]: fetchmail.service: Failed with result 'exit-code'. Sep 15 01:03:26 systemd[2293]: fetchmail.service: Scheduled restart job, restart counter is at 3. Sep 15 01:03:26 fetchmail[2343]: fetchmail: WARNING: Running as root is discouraged. Sep 15 01:03:26 fetchmail[2343]: fetchmail: no mailservers have been specified. Sep 15 01:03:26 systemd[2293]: fetchmail.service: Main process exited, code=exited, status=5/NOTINSTALLED Sep 15 01:03:26 systemd[2293]: fetchmail.service: Failed with result 'exit-code'. Sep 15 01:03:27 systemd[2293]: fetchmail.service: Scheduled restart job, restart counter is at 4. Sep 15 01:03:27 fetchmail[2344]: fetchmail: WARNING: Running as root is discouraged. Sep 15 01:03:27 fetchmail[2344]: fetchmail: no mailservers have been specified. Sep 15 01:03:27 systemd[2293]: fetchmail.service: Main process exited, code=exited, status=5/NOTINSTALLED Sep 15 01:03:27 systemd[2293]: fetchmail.service: Failed with result 'exit-code'. Sep 15 01:03:27 systemd[2293]: fetchmail.service: Scheduled restart job, restart counter is at 5. Sep 15 01:03:27 systemd[2293]: fetchmail.service: Start request repeated too quickly. Sep 15 01:03:27 systemd[2293]: fetchmail.service: Failed with result 'exit-code'. It seems that this started a few days ago, after upgrading fetchmail from version 6.4.32-1 to 6.4.33-1. However, the fetchmail daemon is running as user fetchmail and not as root: $ ps aux | grep fetchmail fetchma+3239 0.0 0.0 13712 7340 ?Ss 01:25 0:00 /usr/bin/fetchmail -f /etc/fetchmailrc --pidfile /var/run/fetchmail/fetchmail.pid --syslog And the file /etc/fetchmailrc exists and is readable by user fetchmail: $ dir /etc/fetchmailrc -rw--- 1 fetchmail root 2.3K Oct 17 2021 /etc/fetchmailrc Hence, I don't understand why I all of a sudden get these warnings "Running as root is discouraged." and "no mailservers have been specified." -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-security'), (500, 'stable'), (400, 'unstable') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fetchmail depends on: ii adduser 3.129 ii debianutils 5.7-0.3 ii init-system-helpers 1.64 ii libc62.34-7 ii libcom-err2 1.46.5-2 ii libgssapi-krb5-2 1.20-1 ii libkrb5-31.20-1 ii libssl3 3.0.5-2 ii lsb-base 11.2 Versions of packages fetchmail recommends: ii ca-certificates 20211016 Versions of packages fetchmail suggests: ii exim4-daemon-heavy [mail-transport-agent] 4.96-3 pn fetchmailconf pn resolvconf -- Configuration Files: /etc/default/fetchmail changed [not included] -- no debconf information
Bug#1015202: php-horde-db: Syntax error in Schema.php after upgrading php-horde-db from version 2.4.1-1 to 2.4.1-3
Package: php-horde-db Version: 2.4.1-3 Severity: important Dear Maintainer, After upgrading php-horde-db from version 2.4.1-1 to 2.4.1-3, I get the following error: ParseError: syntax error, unexpected '', '' (T_CONSTANT_ENCAPSED_STRING), expecting ')' in /usr/share/php/Horde/Db/Adapter/Mysql/Schema.php:580 When I revert the upgrade, the error is gone. I'm using php7.4-fpm (7.4.30-1+deb11u1) to run Horde. Best regards, Timo -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-security'), (500, 'stable'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages php-horde-db depends on: ii php-cli 2:8.1+92 ii php-common2:92-fixed ii php-horde-date2.4.1-9 ii php-horde-exception 2.0.8-8 ii php-horde-support 2.2.2-1 ii php-horde-util2.5.12-1 ii php7.4-cli [php-cli] 7.4.30-1+deb11u1 ii php8.1-cli [php-cli] 8.1.5-1+b1 Versions of packages php-horde-db recommends: ii php-horde-autoloader 2.1.2-10 ii php-horde-cache 2.5.5-10 ii php-horde-log 2.3.0-8 ii php-horde-test2.6.4+debian0-7 ii php-mysql 2:8.1+92 pn php-oci8 php-horde-db suggests no packages. -- no debconf information
Bug#945912: Kernel 5.3 e100e Detected Hardware Unit Hang
This may be related: https://bugzilla.kernel.org/show_bug.cgi?id=205047
Bug#890127: phpldapadmin: phpLDAPadmin uses features that are deprecated in PHP 7.2
Package: phpldapadmin Version: 1.2.2-6.1 Severity: normal Dear Maintainer, I'm using phpLDAPadmin ... together with PHP 7.2 and I noticed the following warnings are thrown: Deprecated: __autoload() is deprecated, use spl_autoload_register() instead in /usr/share/phpldapadmin/lib/functions.php on line 54 Deprecated: Function create_function() is deprecated in /usr/share/phpldapadmin/lib/functions.php on line 1083 It's not critical, as phpLDAPadmin still works fine. But that may of course change with future PHP versions. Best regards, Timo -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/2 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) LSM: AppArmor: enabled Versions of packages phpldapadmin depends on: ii debconf [debconf-2.0] 1.5.65 ii php 1:7.2+60 ii php-ldap1:7.2+60 ii php7.2 [php]7.2.2-1 ii php7.2-ldap [php-ldap] 7.2.2-1 ii ucf 3.0036 phpldapadmin recommends no packages. phpldapadmin suggests no packages.
Bug#885348: linux-image-4.14.0-2-amd64: aLatest kernel (linux-image-4.14.0-2-amd64) breaks e1000e driver on Intel 82579V Gigabit adapter
Package: src:linux
Version: 4.14.7-1
Severity: critical
Tags: patch upstream
Justification: breaks the whole system
Dear Maintainer,
This morning, I updated the Linux kernel from linux-image-4.13.0-1-amd64 to
linux-image-4.14.0-2-amd64.
Afterwards, my Intel Gigabit adapter (details below) did not work properly
anymore (no link).
When booting back into the previous kernel (4.13), everything works properly
again.
It seems like others experience the same behavior, see:
https://bugzilla.kernel.org/show_bug.cgi?id=198047
According to that thread, this bug was introduced in v4.14.3 through commit
830466993daf09adbd179e4c74db07279a088f8c
("e1000e: Separate signaling for link check/link up", upstream:
19110cfbb34d4af0cdfe14cd243f3b09dc95b013).
The thread also includes a patch that (apparently) fixes the problem:
https://bugzilla.kernel.org/attachment.cgi?id=261183=diff==1=raw
Could you please apply this patch to the Debian kernel, until it is included in
upstream?
Best regards,
Timo
** PCI devices:
00:19.0 Ethernet controller [0200]: Intel Corporation 82579V Gigabit Network
Connection [8086:1503] (rev 04)
Subsystem: Intel Corporation 82579V Gigabit Network Connection
[8086:2041]
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: e1000e
Kernel modules: e1000e
Bug#823378: fixed in sshguard 1.6.4-2
I think one more optimization is needed. By adding the '-n' option, reverse DNS lookups are prevented. Without this option, (re-)starting the daemon may take a very long time. So I propose to change the two lines to: iptables -n -L INPUT | grep -q sshguard || iptables -w -I INPUT -j sshguard 2> /dev/null ip6tables -n -L INPUT | grep -q sshguard || ip6tables -w -I INPUT -j sshguard 2> /dev/null
Bug#823378: sshguard: iptables issuing warning "No chain/target/match by that name." in /usr/lib/sshguard/firewall
Package: sshguard
Version: 1.6.4-1
Severity: normal
Dear Maintainer,
When restarting sshguard, I see error messages:
$ /etc/init.d/sshguard restart
[] Restarting SSHGuard Server: sshguardiptables: No chain/target/match by
that name.
ip6tables: No chain/target/match by that name.
. ok
I traced this back to the following commands in /usr/lib/sshguard/firewall,
which is called from the sshguard init script:
if [ "$OS" = "Linux" ]; then
#
# Function that enables firewall
#
do_enable_firewall()
{
# creating sshguard chain
iptables -w -N sshguard 2> /dev/null
ip6tables -w -N sshguard 2> /dev/null
# block traffic from abusers
iptables -L input|grep -q sshguard || iptables -w -I INPUT -j
sshguard 2> /dev/null
ip6tables -L input|grep -q sshguard || ip6tables -w -I INPUT -j
sshguard 2> /dev/null
}
The issue is that there is no "input" chain/target/match.
I think the last two lines should instead be:
iptables -L INPUT|grep -q sshguard || iptables -w -I INPUT -j
sshguard 2> /dev/null
ip6tables -L INPUT|grep -q sshguard || ip6tables -w -I INPUT -j
sshguard 2> /dev/null
So with "input" changed to "INPUT".
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.4.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages sshguard depends on:
ii init-system-helpers 1.31
ii iptables 1.6.0-2
ii libc62.22-7
sshguard recommends no packages.
sshguard suggests no packages.
-- Configuration Files:
/etc/default/sshguard changed [not included]
/etc/sshguard/whitelist changed [not included]
-- no debconf information
Bug#822108: Bug still present in version 1.6.3-2?
I can hereby confirm that this bug has been resolved in the latest Debian version (1.6.4-1) of sshguard.
Bug#822108: Bug still present in version 1.6.3-2?
I still have this problem with the latest version (1.6.3-2): my auth.log file is flooded with messages. There is indeed a patch available upstream: https://bitbucket.org/sshguard/sshguard/commits/43ff612 However, this patch was submitted on March 17 and is not yet part of version 1.6.3, which was released on January 1, 2016: https://bitbucket.org/sshguard/sshguard/downloads I verified this by checking file sshguard_logsuck.c in this archive: http://http.debian.net/debian/pool/main/s/sshguard/sshguard_1.6.3.orig.tar.gz And also the Debian sources do not contain this patch: http://http.debian.net/debian/pool/main/s/sshguard/sshguard_1.6.3-2.debian.tar.xz So my conclusion is that this bug has NOT yet been resolved in the latest Debian version (1.6.3-2) of sshguard.
Bug#769031: [pkg-horde] Issue with php-horde-editor and ckeditor3
On 7-11-2015 13:59, Mathieu Parent wrote: This problem is currently stalled. I planned to fix it by: - packaging old ckeditor as a ckeditor3 package - make php-horde-editor depends on it and update symlinks Appart from the lack of time finishing the work (including making ckeditor3 dfsg), the security team may forbid having an old ckeditor in the archive. I've asked this at: https://lists.debian.org/debian-security/2014/11/msg00035.html but received no response (I also forwarded the message to the Debian security team). Ok, clear. Funding the work to port Horde to ckeditor 4 is the way forward. I will propose this to the horde-dev ML. That would, indeed, resolve the issue completely. Or is there no plan and should I better fix it manually (if so, any suggestions how)? The workaround are : - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769031#15, or - install files and directories from (horde.git)/horde/framework/Editor/js/ckeditor into the debian package directory /usr/share/horde/js/ckeditor/ Clear; for now, I'll go for the manual fix. Thanks! Timo
Bug#727149: linux-image-3.10-3-amd64: Network adapter (Intel 82579V) hangs during TX, causing reset and undetected data corruption at the other side
I don't know, because until now I have been using the workaround (i.e. always disable TSO). I just re-enabled it to see if this error will still occur with the latest kernel. I'll report again in a week or so whether it is stable now. Unfortunately, the bug still occurs. See the log below. Cheers, Timo - [133754.072957] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16-3-amd64 #1 Debian 3.16.5-1 [133754.072959] Hardware name: /DB75EN, BIOS ENB7510H.86A.0046.2013.0704.1354 07/04/2013 [133754.072961] 0009 815066c3 88021e203e28 81065717 [133754.072964] 88021e203e78 0001 [133754.072967] 880212c24000 8106577c 81775de8 0030 [133754.072970] Call Trace: [133754.072972] IRQ [815066c3] ? dump_stack+0x41/0x51 [133754.072982] [81065717] ? warn_slowpath_common+0x77/0x90 [133754.072985] [8106577c] ? warn_slowpath_fmt+0x4c/0x50 [133754.072990] [81072667] ? mod_timer+0x127/0x1e0 [133754.072995] [8143a0c6] ? dev_watchdog+0x236/0x240 [133754.072998] [81439e90] ? dev_graft_qdisc+0x70/0x70 [133754.073001] [810709d1] ? call_timer_fn+0x31/0x100 [133754.073004] [81439e90] ? dev_graft_qdisc+0x70/0x70 [133754.073007] [81072009] ? run_timer_softirq+0x209/0x2f0 [133754.073012] [8106a5b1] ? __do_softirq+0xf1/0x290 [133754.073015] [8106a985] ? irq_exit+0x95/0xa0 [133754.073019] [8150f695] ? smp_apic_timer_interrupt+0x45/0x60 [133754.073022] [8150d79d] ? apic_timer_interrupt+0x6d/0x80 [133754.073023] EOI [81072916] ? get_next_timer_interrupt+0x1d6/0x250 [133754.073031] [813d9cbf] ? cpuidle_enter_state+0x4f/0xc0 [133754.073034] [813d9cb8] ? cpuidle_enter_state+0x48/0xc0 [133754.073038] [810a5d38] ? cpu_startup_entry+0x2f8/0x400 [133754.073043] [8190305a] ? start_kernel+0x47b/0x486 [133754.073046] [81902a04] ? set_init_arg+0x4e/0x4e [133754.073050] [81902120] ? early_idt_handlers+0x120/0x120 [133754.073054] [8190271f] ? x86_64_start_kernel+0x14d/0x15c [133754.073056] ---[ end trace a9b0eebac757b4ab ]--- [133754.073096] e1000e :00:19.0 eth2: Reset adapter unexpectedly [133757.816772] e1000e: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [134277.894290] e1000e :00:19.0 eth2: Detected Hardware Unit Hang: [134277.894290] TDH 5b [134277.894290] TDT 71 [134277.894290] next_to_use 71 [134277.894290] next_to_clean5b [134277.894290] buffer_info[next_to_clean]: [134277.894290] time_stamp 101ff3d7b [134277.894290] next_to_watch5b [134277.894290] jiffies 101ff3fb5 [134277.894290] next_to_watch.status 0 [134277.894290] MAC Status 40080083 [134277.894290] PHY Status 796d [134277.894290] PHY 1000BASE-T Status 3800 [134277.894290] PHY Extended Status3000 [134277.894290] PCI Status 10 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727149: linux-image-3.10-3-amd64: Network adapter (Intel 82579V) hangs during TX, causing reset and undetected data corruption at the other side
I don't know, because until now I have been using the workaround (i.e. always disable TSO). I just re-enabled it to see if this error will still occur with the latest kernel. I'll report again in a week or so whether it is stable now. Cheers, Timo - Message from Balint Reczey bal...@balintreczey.hu - Date: Fri, 31 Oct 2014 09:17:50 +0100 From: Balint Reczey bal...@balintreczey.hu Subject: Re: linux-image-3.10-3-amd64: Network adapter (Intel 82579V) hangs during TX, causing reset and undetected data corruption at the other side To: 727...@bugs.debian.org, T.A. van Roermund t...@van-roermund.nl On Sun, 14 Sep 2014 00:52:55 +0200 Balint Reczey bal...@balintreczey.hu wrote: Control: tags -1 moreinfo Hi, On Wed, 23 Oct 2013 18:06:03 +0200 T.A. van Roermund t...@van-roermund.nl wrote: On 22-10-2013 20:02, T.A. van Roermund wrote: In the mean time I have found a solution to this problem: if I disable TCP segmentation offload using the command 'ethtool -K eth2 tso off', the problem does no longer occur. By the way: I found the solution here: https://bbs.archlinux.org/viewtopic.php?id=162841 Is this problem still present with latest kernel from Jessie? Forgot copying submitter, now fixing my mistake. Cheers, Balint - End message from Balint Reczey bal...@balintreczey.hu - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727149: linux-image-3.10-3-amd64: Network adapter (Intel 82579V) hangs during TX, causing reset and undetected data corruption at the other side
On 22-10-2013 20:02, T.A. van Roermund wrote: In the mean time I have found a solution to this problem: if I disable TCP segmentation offload using the command 'ethtool -K eth2 tso off', the problem does no longer occur. By the way: I found the solution here: https://bbs.archlinux.org/viewtopic.php?id=162841 Timo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708582: TSO
Does the problem disappear if you disable TSO? You can do this as follows: ethtool -K eth0 tso off I also have e1000e stability issues with the same PCI and PHY (extended) status, but only with kernels after 3.2 (3.8, 3.10). See bug 727149. Cheers, Timo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711202: TSO
Does the problem disappear if you disable TSO? You can do this as follows: ethtool -K eth0 tso off I also have e1000e stability issues with the same PCI and PHY (extended) status, but only with kernels after 3.2 (3.8, 3.10). See bug 727149. Cheers, Timo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727149: linux-image-3.10-3-amd64: Network adapter (Intel 82579V) hangs during TX, causing reset and undetected data corruption at the other side
Package: src:linux Version: 3.10.11-1 Severity: critical Justification: causes serious data loss Dear Maintainer, Since the upgrade from kernel version 3.2.0-4 to 3.10-3 I get serious data corruption on the network connection between my server and my desktop PC. The server has the Intel Corporation 82579V Gigabit Network Connection (rev 04) network adapter installed, which is connected via a Conceptronic gigabit switch to my desktop PC. The server is (via a second network interface) also connected to the internet and acts as a router/firewall to my internal network. When I download a large file on my desktop PC, it can happen that the data that is downloaded is corrupted without being detected by the desktop PC. It doesn't always happen, but it is quite likely that it happens when downloading a large file. And if this happens, the syslog on my server shows the following entries: kernel: [198328.514116] e1000e :00:19.0 eth2: Detected Hardware Unit Hang: kernel: [198328.514116] TDH 0 kernel: [198328.514116] TDT 2 kernel: [198328.514116] next_to_use 2 kernel: [198328.514116] next_to_clean0 kernel: [198328.514116] buffer_info[next_to_clean]: kernel: [198328.514116] time_stamp 102f3a7d0 kernel: [198328.514116] next_to_watch1 kernel: [198328.514116] jiffies 102f3a90b kernel: [198328.514116] next_to_watch.status 0 kernel: [198328.514116] MAC Status 40080083 kernel: [198328.514116] PHY Status 796d kernel: [198328.514116] PHY 1000BASE-T Status 3800 kernel: [198328.514116] PHY Extended Status3000 kernel: [198328.514116] PCI Status 10 The MAC/PHY/PCI status (last 5 lines) is always the same. In the mean time I have found a solution to this problem: if I disable TCP segmentation offload using the command 'ethtool -K eth2 tso off', the problem does no longer occur. This is a very serious bug, especially since the receiving side (my desktop PC) cannot detect that the data transmitted over the network is corrupt. -- Package-specific info: ** Version: Linux version 3.10-3-amd64 (debian-ker...@lists.debian.org) (gcc version 4.7.3 (Debian 4.7.3-7) ) #1 SMP Debian 3.10.11-1 (2013-09-10) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.10-3-amd64 root=UUID=42e365d5-330b-438b-8948-82308bd455a1 ro quiet ** Not tainted ** Kernel log: [1.426887] usb 2-1: New USB device found, idVendor=8087, idProduct=0024 [1.426892] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [1.427304] hub 2-1:1.0: USB hub found [1.427482] hub 2-1:1.0: 6 ports detected [1.450724] PM: Starting manual resume from disk [1.450729] PM: Hibernation image partition 8:3 present [1.450730] PM: Looking for hibernation image. [1.450855] PM: Image not found (code -22) [1.450858] PM: Hibernation image not present or could not be loaded. [1.566552] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) [3.152495] systemd-udevd[327]: starting version 204 [3.636012] ACPI Warning: 0xf040-0xf05f SystemIO conflicts with Region \_SB_.PCI0.SBUS.SMBI 1 (20130328/utaddress-251) [3.636019] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [3.663370] ACPI Warning: 0x0428-0x042f SystemIO conflicts with Region \PMIO 1 (20130328/utaddress-251) [3.663377] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [3.663381] ACPI Warning: 0x0530-0x053f SystemIO conflicts with Region \GPIO 1 (20130328/utaddress-251) [3.663384] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [3.663385] ACPI Warning: 0x0500-0x052f SystemIO conflicts with Region \GPIO 1 (20130328/utaddress-251) [3.663388] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [3.663389] lpc_ich: Resource conflict(s) found affecting gpio_ich [3.767693] mei_me :00:16.0: setting latency timer to 64 [3.767736] mei_me :00:16.0: irq 43 for MSI/MSI-X [3.808660] input: PC Speaker as /devices/platform/pcspkr/input/input1 [3.838116] ACPI: Requesting acpi_cpufreq [3.878944] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input2 [3.879006] ACPI: Power Button [PWRB] [3.879057] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 [3.879082] ACPI: Power Button [PWRF] [3.897465] parport_pc 00:09: reported by Plug and Play ACPI [3.897523] parport0: PC-style at 0x378, irq 5 [PCSPP,TRISTATE] [3.947049] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x28 [4.004052] platform microcode: firmware: agent aborted loading intel-ucode/06-2a-07 (not found?) [4.004132] microcode: CPU1
Bug#623306: Plugin config files should be moved to /etc (e.g. /etc/phpsysinfo/plugins/*)
Hi Bjorn, I have the impression that this request will not be handled by the upstream authors anytime soon. What about fixing this in the Debian package instead? Best regards, Timo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589924: dnsmasq: Add stop-dns-rebind to default config file to prevent DNS rebinding attacks
On 15-8-2010 23:17, Simon Kelley wrote: I disagree. stop-dns-rebind essentially breaks DNS for a particular set of queries. This may or may not be useful, depending on circumstances, but experience (with filter-win2k, which is similar and used to be on by default in Debian) says that if you make it the default, people for whom it's not a useful function will regard this as a bug. It's fine to break the DNS for particular queries if the user asks for that, but not by default, and especially not when this is a change in behaviour from earlier versions, Ok, fair enough. Best regards, Timo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549315: phpsysinfo: A new upstream version (v3.0 RC9) is available.
Package: phpsysinfo Version: 3.0~rc6-1 Severity: wishlist A new upstream version (v3.0 RC9) is available from http://phpsysinfo.sourceforge.net/. Could you please update the package? -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#462588: Same problem
Steve Langasek wrote: Please try setting 'TLSVerifyClient allow' in your slapd.conf, and let us know whether that fixes the problem for you. In my tests, I see that the default client certificate handling for 2.4.7 with GnuTLS does not match what's documented in the slapd.conf manpage; I think we have another bug here that will need tracking down. You are right, this fixes the problem. Thanks! Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Bug#462588: Bug#462588: Same problem
Quanah Gibson-Mount wrote: Ok. Does your certificate have a proper cn, matching the fqdn of your server? That's the only other case where I can reproduce the described behavior, but I don't know if that's a behavior change relative to the OpenSSL version. (I would have hoped that OpenSSL would also refuse to negotiate SSL/TLS with a server whose cn doesn't match the hostname being connected to, since this subverts the SSL security model.) OpenLDAP compiled with OpenSSL behaves the same way. i.e, the cn in the cert must match the servername (or the fields on subjectAltName, etc). FQDN: server-timo.van-roermund.nl CN: van-roermund.nl Will that be the problem? If so, then the behaviour of GnuTLS *is* different from the behavious of OpenSSL. I will test it and let you know. Regards, Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Same problem
Steve Langasek wrote: Well, I can reproduce the problem when using this value for TLSCipherSuite. But why would you set this value, rather than leaving TLSCipherSuite blank to use the default? I don't see the point of listing *all* the cipher types if you don't intend to exclude some of them. If I leave it blank, it still doesn't work. The behaviour is then exactly equal to the current situation. Anyway, the documented syntax for TLSCipherSuite is $cipher1:$cipher2, not $cipher1 $cipher2; but setting such values gives me a hang on startup (which should be investigated). I can confirm that, the reason why I left out the : is this hang. I thought that maybe gnutls parses the string differently and needs spaces in between, that's why I replaced those characters with spaces. Anyway, do you file a bug report for this hang? I see that if I leave the cipher list blank, gnutls-cli negotiates TLS_RSA_AES_256_CBC_SHA; so if I set TLSCipherSuite TLS_RSA_AES_256_CBC_SHA, it works just fine. How exactly do you find out? Then I might try the same on my PC. The full list of ciphers that gnutls clients appear to negotiate by default is: TLS_DHE_RSA_AES_256_CBC_SHA, TLS_DHE_RSA_AES_128_CBC_SHA, TLS_DHE_RSA_3DES_EDE_CBC_SHA, TLS_DHE_DSS_AES_256_CBC_SHA, TLS_DHE_DSS_AES_128_CBC_SHA, TLS_DHE_DSS_3DES_EDE_CBC_SHA, TLS_DHE_DSS_RC4_128_SHA, TLS_RSA_AES_256_CBC_SHA, TLS_RSA_AES_128_CBC_SHA, TLS_RSA_3DES_EDE_CBC_SHA, TLS_RSA_RC4_128_SHA, TLS_RSA_RC4_128_MD5 So if you don't want to use the default cipher settings, you can perhaps choose one of these ciphers individually that meets your needs. None of thise ciphers seems to work (at least in combination with Thunderbird). I'm not sure if we should also try to migrate the OpenSSL-specific cipher specs to GNUTLS equivalents as part of the package upgrade. That might be a good idea. Best regards, Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Bug#462588: Bug#462588: Bug#462588: Same problem
Quanah Gibson-Mount wrote: That would be a problem if server-timo.van-roermud.nl is not in subjectAltName for the certs. I changed the certificate (self signed), it now looks like this (only the relevant parts): Certificate: Data: cut Signature Algorithm: sha1WithRSAEncryption Issuer: C=NL, ST=Noord-Brabant, L=Eindhoven, O=van-roermund.nl, CN=van-roermund.nl/[EMAIL PROTECTED] cut Subject: C=NL, ST=Noord-Brabant, O=van-roermund.nl, CN=van-roermund.nl/[EMAIL PROTECTED] Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) cut X509v3 extensions: X509v3 Basic Constraints: CA:FALSE cut X509v3 Subject Alternative Name: DNS:van-roermund.nl, DNS:server-timo.van-roermund.nl, DNS:www.van-roermund.nl, DNS:imap.van-roermund.nl, DNS:smtp.van-roermund.nl, DNS:ftp.van-roermund.nl So my FQDN (server-timo.van-roermund, double checked with hostname -f) is now part of subjectAltName. However, it still doesn't work. Regards, Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Same problem
Quanah Gibson-Mount wrote: Have you verified that port 636 is open? I.e., telnet localhost 636 The port is open: $ telnet localhost 636 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. And: $ netstat --listening --numeric --program | grep slapd tcp0 0 127.0.0.1:389 0.0.0.0:* LISTEN 23763/slapd tcp0 0 0.0.0.0:636 0.0.0.0:* LISTEN 23763/slapd (And ldapsearch is still unable to connect.) Regards, Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Same problem
Quanah Gibson-Mount wrote: Have you verified whether or not you can connect using LDAPS via the command line tools? (ldapsearch, ldapwhoami, etc). Yes I did: $ ldapsearch -H ldaps://localhost:636/ -X cn=admin ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) The relevant line in /etc/default/slapd: SLAPD_SERVICES=ldap://127.0.0.1:389/ ldaps:/// And the relevant lines in /etc/ldap/slapd.conf: TLSCertificateFile /etc/ssl/private/mykey.crt TLSCertificateKeyFile /etc/ssl/private/mykey.key # original cipher suite string #TLSCipherSuite HIGH:-SSLv2:-RSA # cipher suite string as used before with OpenSSL #TLSCipherSuite HIGH:MEDIUM:-SSLv2 # all cipher suites as currently supported by gnutls, # constructed using command: # gnutls-cli -l | grep -E ^TLS | cut -d\ -f1 | xargs echo TLSCipherSuite TLS_ANON_DH_ARCFOUR_MD5 TLS_ANON_DH_3DES_EDE_CBC_SHA1 TLS_ANON_DH_AES_128_CBC_SHA1 TLS_ANON_DH_AES_256_CBC_SHA1 TLS_PSK_SHA_ARCFOUR_SHA1 TLS_PSK_SHA_3DES_EDE_CBC_SHA1 TLS_PSK_SHA_AES_128_CBC_SHA1 TLS_PSK_SHA_AES_256_CBC_SHA1 TLS_DHE_PSK_SHA_ARCFOUR_SHA1 TLS_DHE_PSK_SHA_3DES_EDE_CBC_SHA1 TLS_DHE_PSK_SHA_AES_128_CBC_SHA1 TLS_DHE_PSK_SHA_AES_256_CBC_SHA1 TLS_SRP_SHA_3DES_EDE_CBC_SHA1 TLS_SRP_SHA_AES_128_CBC_SHA1 TLS_SRP_SHA_AES_256_CBC_SHA1 TLS_SRP_SHA_DSS_3DES_EDE_CBC_SHA1 TLS_SRP_SHA_RSA_3DES_EDE_CBC_SHA1 TLS_SRP_SHA_DSS_AES_128_CBC_SHA1 TLS_SRP_SHA_RSA_AES_128_CBC_SHA1 TLS_SRP_SHA_DSS_AES_256_CBC_SHA1 TLS_SRP_SHA_RSA_AES_256_CBC_SHA1 TLS_DHE_DSS_ARCFOUR_SHA1 TLS_DHE_DSS_3DES_EDE_CBC_SHA1 TLS_DHE_DSS_AES_128_CBC_SHA1 TLS_DHE_DSS_AES_256_CBC_SHA1 TLS_DHE_RSA_3DES_EDE_CBC_SHA1 TLS_DHE_RSA_AES_128_CBC_SHA1 TLS_DHE_RSA_AES_256_CBC_SHA1 TLS_RSA_NULL_MD5 TLS_RSA_EXPORT_ARCFOUR_40_MD5 TLS_RSA_ARCFOUR_SHA1 TLS_RSA_ARCFOUR_MD5 TLS_RSA_3DES_EDE_CBC_SHA1 TLS_RSA_AES_128_CBC_SHA1 TLS_RSA_AES_256_CBC_SHA1 Before, using OpenSSL, everything worked perfectly. Now, LDAPS is completely broken. Regards, Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: Same problem
Hi, I have the same problem. Following your suggestion, I listed all the cipher suites using gnutls-cli -l and tried all of them. Now, slapd does start, but still Thunderbird cannot connect to the daemon, no matter which cipher suite was selected. Regards, Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405553: phpsysinfo: New upstream release (2.5.2)
Why is this package not updated? Would be nice to use the latest version. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360073: lesstif2: Useless verbosity still not fixed
Package: lesstif2 Version: 1:0.94.4-2 Followup-For: Bug #360073 I still get the useless Yow messages when I run nedit. So, it seems like this problem isn't fixed yet. As far as I have understood, it should have been fixed in upstream version 0.95.0 which is stable since June 10, 2006. So it may be wise to upgrade the package lesstif2. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages lesstif2 depends on: ii libc6 2.3.6.ds1-8GNU C Library: Shared libraries ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii libsm61:1.0.1-3 X11 Session Management library ii libx11-6 2:1.0.3-4 X11 client-side library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxp61:1.0.0.xsf1-1 X Printing Extension (Xprint) clie ii libxt61:1.0.2-2 X11 toolkit intrinsics library lesstif2 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396187: pptpd: Patch to disable unnecessary lines in syslog
Package: pptpd
Version: 1.3.0-1
Could you please consider patching the current PoPToP package (pptpd)
for Debian testing/unstable, version 1.3.0-1 using the attached patch?
It is a backport patch from the current experimental version 1.3.2
(see: http://www.poptop.org/) which disables the DEBUG logging to the
syslog when the debug option has not been turned on in the
/etc/pptpd.conf file.
The current version makes my syslog grow really fast because it logs
many messages like this: GRE: accepting packet 1234.
--- pptpd-1.3.0/pptpgre.c 2005-08-02 13:33:31.0 +0200
+++ pptpd-1.3.0-patched/pptpgre.c 2006-06-26 14:06:12.0 +0200
@@ -37,6 +37,7 @@
#include ppphdlc.h
#include pptpgre.h
#include pptpdefs.h
+#include pptpctrl.h
#include defaults.h
#include pqueue.h
@@ -317,9 +318,13 @@
/* if it is timed out... */
if (head-seq != gre.seq_recv + 1 ) { /* wrap-around safe */
stats.rx_lost += head-seq - gre.seq_recv - 1;
- syslog(LOG_DEBUG, GRE: timeout waiting for %d
packets, head-seq - gre.seq_recv - 1);
+ if (pptpctrl_debug) {
+ syslog(LOG_DEBUG, GRE: timeout waiting for %d
packets, head-seq - gre.seq_recv - 1);
+ }
+ }
+ if (pptpctrl_debug) {
+ syslog(LOG_DEBUG, GRE: accepting #%d from queue,
head-seq);
}
- syslog(LOG_DEBUG, GRE: accepting #%d from queue, head-seq);
gre.seq_recv = head-seq;
status = callback(cl, head-packet, head-packlen);
pqueue_del(head);
@@ -399,16 +404,22 @@
}
/* check for out-of-order sequence number */
if (seq_greater(seq, gre.seq_recv)) {
- syslog(LOG_DEBUG, GRE: accepting packet #%d, seq);
+ if (pptpctrl_debug) {
+ syslog(LOG_DEBUG, GRE: accepting packet #%d,
seq);
+ }
stats.rx_accepted++;
gre.seq_recv = seq;
return cb(cl, buffer + ip_len + headersize,
payload_len);
} else if (seq == gre.seq_recv) {
- syslog(LOG_DEBUG, GRE: discarding duplicate or old
packet #%d (expecting #%d), seq, gre.seq_recv + 1);
+ if (pptpctrl_debug) {
+ syslog(LOG_DEBUG, GRE: discarding duplicate or
old packet #%d (expecting #%d), seq, gre.seq_recv + 1);
+ }
return 0; /* discard duplicate packets */
} else {
stats.rx_buffered++;
- syslog(LOG_DEBUG, GRE: buffering packet #%d (expecting
#%d, lost or reordered), seq, gre.seq_recv + 1);
+ if (pptpctrl_debug) {
+ syslog(LOG_DEBUG, GRE: buffering packet #%d
(expecting #%d, lost or reordered), seq, gre.seq_recv + 1);
+ }
pqueue_add(seq, buffer + ip_len + headersize,
payload_len);
return 0; /* discard out-of-order packets */
}
Bug#371843: clamav-freshclam: Same problem - occurs after updating after updating the lsb-base package to v3.1-8
Package: clamav-freshclam Version: 0.88.2-1 Followup-For: Bug #371843 I have the same problem, the command shutdown -r now does not shutdown the system. The problem is in the file /etc/init.d/clamav-freshclam. It uses a function pidofproc (line 101) from the lsb-base package (in file /lib/lsb/init-functions) which does not finish. So the clamav-freshclam script hangs which prevents the computer from shutting down. Line 101 reads: PID=`pidofproc -p $PIDFILE $DAEMON` This problem exists since I updated the lsb-base package to the latest version (3.1-8). -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.20 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages clamav-freshclam depends on: ii clamav-base 0.88.2-1 base package for clamav, an anti-v ii debconf [debconf-2.0] 1.5.1 Debian configuration management sy ii debianutils 2.16.1 Miscellaneous utilities specific t ii libc6 2.3.6-7GNU C Library: Shared libraries ii libclamav10.88.2-1 virus scanner library ii logrotate 3.7.1-3Log rotation utility ii lsb-base 3.1-8 Linux Standard Base 3.1 init scrip ii ucf 2.0010 Update Configuration File: preserv clamav-freshclam recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371843: clamav-freshclam: Problem solved in lsb-base package
Package: clamav-freshclam Version: 0.88.2-1 Followup-For: Bug #371843 It seems like it is a bug in the lsb-base package v3.1-8. I used the following command to update to v3.1-10 (from the unstable branch): apt-get install -t unstable lsb-base And the problem has disappeared. :-) -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.20 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages clamav-freshclam depends on: ii clamav-base 0.88.2-1 base package for clamav, an anti-v ii debconf [debconf-2.0] 1.5.1 Debian configuration management sy ii debianutils 2.16.1 Miscellaneous utilities specific t ii libc6 2.3.6-7GNU C Library: Shared libraries ii libclamav10.88.2-1 virus scanner library ii logrotate 3.7.1-3Log rotation utility ii lsb-base 3.1-10 Linux Standard Base 3.1 init scrip ii ucf 2.0010 Update Configuration File: preserv clamav-freshclam recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346199: manpages-dev: Dangling symlink: /usr/share/man/man3/open_memstream.3.gz
Package: manpages-dev Version: 2.17-1 Severity: normal The file /usr/share/man/man3/open_memstream.3.gz is a dangling symlink, the file it points to (/usr/share/man/man3/fmemopen.3.gz) has not been installed, although it exists in the source package (http://ftp.debian.org/debian/pool/main/m/manpages/manpages_2.17.orig.tar.gz). Because of this bug, the command man 3 open_memstream will return an error (saying the file is a dangling symlink). -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages manpages-dev depends on: ii manpages 2.17-1 Manual pages about using a GNU/Lin manpages-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
