Bug#465601: linux-image-2.6-vserver-amd64: Please include vs2.2.0.6 patch
Package: linux-image-2.6-vserver-amd64 Version: 2.6.22+11 Severity: wishlist Current linux image includes vserver 2.2.0.5 patch, I need something that is included in 2.2.0.6 so I would appreciate it if this is included. -- System Information: Debian Release: lenny/sid APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-vserver-amd64 (SMP w/2 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442359: RFP: python-pysamba -- Fully functional python bindings for samba, allowing the developer to interface any samba-capable device much like python's ftplib does.
Package: wnpp Severity: wishlist * Package name: python-pysamba Version : 1.0.0 Upstream Author : Juan M. Casillas [EMAIL PROTECTED] * URL : http://www.jmcresearch.com/src/projecthelper.php?action=viewid=18 * License : GPL Programming Lang: C, Python Description : Fully functional python bindings for samba, allowing the developer to interface any samba-capable device much like python's ftplib does. PySamba is a full wrapper based in the work of Tim Potter. In fact, PySamba is built as a Python C extension over the cli library provided with samba and a Python module that hides the complexity of the lower layer (smb) providing high-level commands like Mkdir or DiskAvail. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.4.29-grsec 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#577967: Patch to fix warning
Hi, This patch fixes the warning. Would very much appreciate if this patch could be applied, so my build logs are cleaner. The patch is against version 0.6.17 but I think it can be applied cleanly against most versions. Related, I think another bug (#604935) is a duplicate of this. Thanks! pycentral-0.6.17-bug577967.diff Description: Binary data
Bug#702539: grep: Misleading error message when presenting [:digit:] outside character class
Package: grep Version: 2.14-1 Severity: minor Tags: upstream Dear Maintainer, * What led up to the situation? I was configuring logcheck and made an error and got the following in the mail: egrep: character class syntax is [[:space:]], not [:space:] First I checked my recent changes, but there were no [:space:] used at all. I then searched the system logcheck files for any '[:space:]' outside a character class, but couldn't find one. I figured out that it was actually '[:digit:]' that caused this problem. I realize the error message might be giving an example, but in this case it was really confusing, as there were many patterns (most of them not maintained by me) and it took some time to figure out what the problem was since the egrep was run a while after I made the changes. I tested this on both testing/wheezy (2.12-2) as well as unstable/sid (2.14-1), both give the same result. * What exactly did you do (or not do) that was effective (or ineffective)? # Minimal working example with missing outer brackets: echo This is 1 test | egrep '[:digit:]' * What was the outcome of this action? egrep: character class syntax is [[:space:]], not [:space:] * What outcome did you expect instead? egrep: character class syntax is [[:digit:]], not [:digit:] -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (900, 'testing'), (600, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages grep depends on: ii dpkg 1.16.9 ii install-info 4.13a.dfsg.1-10 ii libc6 2.13-38 grep recommends no packages. Versions of packages grep suggests: ii libpcre3 1:8.30-5 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725702: Additional information, wide-dhcpv6-server also suffers this problem
Hi all, While installing wide-dhcpv6-server (NOT the client), I also got this error message with 20080615-12: # /usr/sbin/dhcp6s -c /etc/wide-dhcpv6/dhcp6s.conf -Df eth0 [snip...] May/09/2014 14:16:56: server6_init: setsockopt(insock, SO_REUSEPORT): Protocol not available After installing 20080615-11.1, the problem disappeared. I'm running Debian testing (jessie). Kind regards, Michiel Holtkamp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755501: ircd-ratbox resolver daemon hits 100% cpu on irc client connect, fails to resolve hostname.
Package: ircd-ratbox Version: 3.0.8.dfsg-2 Severity: important Dear Maintainer, After upgrading to 3.0.8-dfsg-2, I noticed connecting to the IRC server was very slow and resulted in hostnames not being (reverse) resolved. Upon inspection, it seemed that the ircd resolver daemon was using a lot of CPU (100% in top). A systrace did not yield anything, but an ltrace showed a continuous stream of the same line: rb_get_pseudo_random(0x7fffa62abc86, 2, 0x7f583268fba0, 0) = 1 (I'll get back to this later). I tried killing the ircd resolver daemon (had to kill it with SIGKILL) and it came back at 0% CPU usage. However, everytime a client connected, the same thing happened (cpu to 100%, ip not reverse resolved). I did a quick check in the source code and it seemed that this function was called in a tight loop if the random number that was returned is always 0x (a 16-bit short was requested). ADDITIONAL INFORMATION * tested with 3.0.7.dfsg-3, does NOT suffer from this problem * tested on two different machines, both virtualized (one OpenVZ, one LXC) (I don't know if it matters, but I included it for completeness). -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ircd-ratbox depends on: ii libc6 2.19-7 ii libgnutls-deb0-28 3.2.15-3 ii libltdl7 2.4.2-1.7 ii libsqlite3-0 3.8.5-2 ii lsb-base 4.1+Debian13 ii multiarch-support 2.19-7 ircd-ratbox recommends no packages. Versions of packages ircd-ratbox suggests: pn ntp | openntpd | time-daemon none -- Configuration Files: /etc/default/ircd-ratbox changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764551: irssi: Irssi segfaults when dbd-mysql connection is attempted in perl script
Package: irssi
Version: 0.8.16-1+b1
Severity: important
Dear Maintainer,
* What led up to the situation?
I have some scripts that use a connection to mysql and after I restarted
my irssi it reliably segfaults each time a mysql connection is attempted
in a script.
I'm not sure when exactly this happened, but I upgrade my packages regularly
(I run debian testing). I have tested with packages from stable, everything
seems to work normally.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Quick way to test is to run the following command in (bare, no scripts) irssi:
/script exec use DBI; DBI-connect(DBI:mysql:_db:_host:3306:, _user,
_pass);
This will try to connect to a non-existing host with a non-existing user/pass.
* What was the outcome of this action?
A segmentation fault (see below for more information and gdb backtrace).
* What outcome did you expect instead?
An error message like the following:
DBI connect('_db:_host:3306:','_user',...) failed: Unknown MySQL server host
'_host' (0)
* Package versions affected/NOT affected
Versions of packages that DO cause segfaults:
ii irssi 0.8.16-1+b1
ii libdbd-mysql-perl 4.028-2+b1
ii libdbi-perl1.631-3+b1
ii libmysqlclient18:amd64 5.5.37-0+wheezy1
ii libperl5.205.20.1-1
Also tried irssi from experimental (0.8.17~rc1-1+b1, also segfaults),
and with libmysqlclient18 from testing (5.5.39-1, also segfaults).
The versions from stable do NOT segfault:
ii irssi0.8.15-5
ii libdbd-mysql-perl4.021-1+b1
ii libdbi-perl 1.622-1+deb7u1
ii libmysqlclient18:amd64 5.5.37-0+wheezy1
ii libperl5.14 5.14.2-21+deb7u1
Since the irssi version and the perl versions are closely linked, I could
not easily test different versions of libaries seperately.
* Irssi dependence
A simple test without irssi behaves as expected for ALL package versions and
gives the expected error message (and no segfault):
$ perl -e 'use DBI; DBI-connect(DBI:mysql:_db:_host:3306:, _user,
_pass);'
DBI connect('_db:_host:3306:','_user',...) failed: Unknown MySQL server host
'_host' (0) at -e line 1.
This shows that the problem only occurs when it is run inside irssi, but not
with a standalone perl (i.e. NO segfaults with the perl5.20 nor with the
perl5.14 versions).
* Backtrace
The following backtrace was generated from a core file from an affected irssi.
It was run with a new home-directory (~/.irssi-bare), so it uses default
configuration and NO scripts were loaded.
The backtrace always shows that the segfault is always in the same spot, in
vfprintf:
$ gdb irssi core.14456
GNU gdb (Debian 7.7.1+dfsg-3) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
Type show configuration for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type help.
Type apropos word to search for commands related to word...
Reading symbols from irssi...(no debugging symbols found)...done.
[New LWP 14456]
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
Core was generated by `irssi --home=~/.irssi-bare'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x7fa1fdea0e70 in vfprintf () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x7fa1fdea0e70 in vfprintf () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7fa1fdf4ccc5 in __fprintf_chk () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x7fa1fe20877b in my_malloc () from
/usr/lib/x86_64-linux-gnu/libsres.so.14
#3 0x7fa1fc04863a in my_error_register () from
/usr/lib/x86_64-linux-gnu/libmysqlclient.so.18
#4 0x7fa1fc02769d in mysql_server_init () from
/usr/lib/x86_64-linux-gnu/libmysqlclient.so.18
#5 0x7fa1fc02d7df in mysql_init () from
/usr/lib/x86_64-linux-gnu/libmysqlclient.so.18
#6 0x7fa1fc53aba9 in mysql_dr_connect () from
/usr/lib/x86_64-linux-gnu/perl5/5.20/auto/DBD/mysql/mysql.so
#7 0x7fa1fc53cf79 in ?? () from
/usr/lib/x86_64-linux-gnu/perl5/5.20/auto/DBD/mysql/mysql.so
#8 0x7fa1fc53d08a in mysql_db_login () from
/usr/lib/x86_64-linux-gnu/perl5/5.20/auto/DBD/mysql/mysql.so
#9 0x7fa1fc549550 in ?? () from
/usr/lib/x86_64-linux-gnu/perl5/5.20/auto/DBD/mysql/mysql.so
#10 0x7fa2000315ab in Perl_pp_entersub () from
/usr/lib/x86_64-linux-gnu/libperl.so.5.20
#11 0x7fa200029e46 in Perl_runops_standard ()
Bug#821939: Possible extra information
Had the same problem. After trying different smb.conf options, googling and reading the release notes of the changes, I tried upgrading to unstable package (2:4.4.3+dfsg-4 at the time of writing). This fixed my problems, I could revert all the changes I had made to the smb.conf. I’m not sure if this is the same problem though, since in my situation I could access guest shares from Linux, Windows, but not OS X. I suspect my issues was more similar to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1572301. Maybe upgrading to a newer version also helps to locate the problem.
