Bug#1034472: reportbug: auto-apt-proxy prints IPv6 literally incorrectly
Hello,
On Sat, 16 Sep 2023, at 17:46, Helmut Grohne wrote:
>
> I also experience this problem. I'm attaching a patch that makes it work
> for me, but I am unsure whether the patch is universally correct as it
> may need some quoting of the ip in "Acquire::http::Proxy::${ip}=DIRECT"
> if the ip contains "::". In my case, the ip does not and therefore it
> works. Could you give the patch a try in your environment where "::"
> does happen?
The patch does work for me, thanks.
I suspect a better fix, especially given the escaping problem you have
highlighted, would be just to pass through the DNS name to connect to.
For where 'apt-proxy' is a CNAME or are A/ records, then probably just
returning 'apt-proxy' is the right thing to do. For SRV records, I think all
that needs to be done is to return the target.
Do you think this would be suitable?
Happy to put it together myself, but it would be great if Antonio Terceiro
could chip in.
Thanks
Bug#1034472: reportbug: auto-apt-proxy prints IPv6 literally incorrectly
Package: auto-apt-proxy Version: 14 Severity: normal Dear Maintainer, Though the package functions perfectly (thanks!) when you just run auto-apt-proxy on its own, the IPv6 literal is incorrectly concatenated to the port. It should emit: http://[fd69:dead:beef:1::1]:3142 My local setup has apt-cacher-ng running at apt-proxy: alex@sarasti:~$ dig ANY apt-proxy ; <<>> DiG 9.18.12-1-Debian <<>> ANY apt-proxy ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33640 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;apt-proxy. IN ANY ;; ANSWER SECTION: apt-proxy. 0 IN fd69:dead:beef:1::1 apt-proxy. 0 IN A 192.168.1.1 ;; Query time: 16 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) (TCP) ;; WHEN: Sun Apr 16 11:00:14 BST 2023 ;; MSG SIZE rcvd: 82 alex@sarasti:~$ auto-apt-proxy http://fd69:dead:beef:1::1:3142 If you need anything else, do ask. Kind regards Alex -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (100, 'testing'), (10, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages auto-apt-proxy depends on: ii apt 2.6.0 Versions of packages auto-apt-proxy recommends: ii busybox 1:1.35.0-4+b2 ii iproute2 6.1.0-2 auto-apt-proxy suggests no packages. -- no debconf information
Bug#814792: *** stack smashing detected ***: /usr/lib/plan9/bin/sha1sum terminated
Package: 9base Version: 1:6-6 Followup-For: Bug #814792 Dear Maintainer, The problem is that the fmt string provided in sha1sum.c is wrong, supplied is '%.2ux' when it should just be '%.2x': http://man.cat-v.org/plan_9/2/fprintf The attached patch fixes this, and also prints out the correct sha1, rather than some unsigned 8 bit integer that partially overwrites its-self :) Thanks -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.2.0-0.bpo.1-686-pae (SMP w/2 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) Versions of packages 9base depends on: ii libc6 2.19-18+deb8u4 9base recommends no packages. Versions of packages 9base suggests: pn wmii2 -- no debconf information --- sha1sum/sha1sum.c.orig 2016-06-10 16:45:08.799679149 +0100 +++ sha1sum/sha1sum.c 2016-06-10 16:44:52.479679562 +0100 @@ -12,7 +12,7 @@ p = va_arg(fmt->args, uchar*); for(i=0; i
Bug#815125: Boot failure with Debian linux 4.4.2 package
On Sun, Feb 21, 2016 at 03:45:24AM +, Ben Hutchings wrote: Apparently "earlyprintk=efi,keep" is likely to work better. Jim Barber was able to get a traceback this way. It looks like the efi-bgrt driver is crashing, and there is an upstream fix for it. I'll upload a test version of the package shortly. This test version is now available at https://people.debian.org/~benh/packages/unstable/ Please report back whether this does or doesn't fix the problem for you. Works for Me(tm) Thanks -- Alexander Clouter .sigmonster says: Excellent day to have a rotten day.
Bug#815173: kernel-image-4.4.0-1-amd64 does not boot on my Thinkpad X240
Package: linux-source-4.4 Version: 4.4.2-2 Followup-For: Bug #815173 Dear Maintainer, I have the same problem on my MS Surface Pro 4. However, I was able to tickle out the problem by booting with 'earlyprintk=efi,keep' appended to my kernel parameters. My problem is an unhandled kernel paging request in efi_bgrt_init(). I dug around and found the following fix that works for me: [PATCH] x86/efi-bgrt: Fix kernel panic when mapping BGRT data https://lkml.org/lkml/2015/12/10/599 The problem might be different for the Thinkpad reports here, however maybe the earlyprintk will help get to the root of the problem. Regards -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.2-mssp4 (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) Versions of packages linux-source-4.4 depends on: ii binutils 2.25-5 ii xz-utils 5.1.1alpha+20120614-2+b3 Versions of packages linux-source-4.4 recommends: ii bc1.06.95-9 ii gcc 4:4.9.2-2 ii libc6-dev [libc-dev] 2.19-18+deb8u3 ii make 4.0-8.1 Versions of packages linux-source-4.4 suggests: pn libncurses-dev | ncurses-dev pn libqt4-dev ii pkg-config0.28-1 -- no debconf information
Bug#773878: wide-dhcpv6-server: not debootstrap installable
Package: wide-dhcpv6-server Version: 20080615-11.1 Severity: normal Dear Maintainer, When trying to use wide-dhcpv6-server with debootstrap it fails; attached is the console output and debootstrap.log. Looking at the postinst script I think I see the problematic section, which is also present in sid's 20080615-13 release too: # Automatically added by dh_installinit if [ -x /etc/init.d/wide-dhcpv6-server ]; then update-rc.d wide-dhcpv6-server defaults /dev/null invoke-rc.d wide-dhcpv6-server start || exit $? HERE fi # End automatically added section If we compare it to something like unbound which works fine with debootstrap: # Automatically added by dh_installinit if [ -x /etc/init.d/unbound ]; then update-rc.d unbound defaults /dev/null if [ -n $2 ]; then _dh_action=restart else _dh_action=start fi invoke-rc.d unbound $_dh_action || true HERE fi # End automatically added section I suspect all that needs to be done is replace 'exit $?' with 'true' to solve this. However, I see in the source it is just a macro (#DEBHELPER#) and I have no idea how to persuade dh_installinit at your end to emit this kind of output instead. Let me know if you need any more information. Kind Regards -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-0.bpo.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 aclouter@stevemcqueen:/usr/src/bratwurst$ sudo debootstrap --arch=i386 --variant=minbase --include=wide-dhcpv6-server wheezy fakeisp/.rootfs http://http.debian.net/debian [snipped] I: Configuring libstdc++6:i386... I: Configuring readline-common... I: Configuring libapt-pkg4.12:i386... I: Configuring libreadline6:i386... I: Configuring gnupg... I: Configuring apt... W: Failure while configuring base packages. This will be re-attempted up to five times. W: See /usr/src/bratwurst/fakeisp/.rootfs/debootstrap/debootstrap.log for details (possibly the package wide-dhcpv6-server is at fault) I: Configuring wide-dhcpv6-server... W: Failure while configuring base packages. This will be re-attempted up to five times. W: See /usr/src/bratwurst/fakeisp/.rootfs/debootstrap/debootstrap.log for details (possibly the package wide-dhcpv6-server is at fault) W: Failure while configuring base packages. This will be re-attempted up to five times. W: See /usr/src/bratwurst/fakeisp/.rootfs/debootstrap/debootstrap.log for details (possibly the package wide-dhcpv6-server is at fault) W: Failure while configuring base packages. This will be re-attempted up to five times. W: See /usr/src/bratwurst/fakeisp/.rootfs/debootstrap/debootstrap.log for details (possibly the package wide-dhcpv6-server is at fault) W: Failure while configuring base packages. This will be re-attempted up to five times. W: See /usr/src/bratwurst/fakeisp/.rootfs/debootstrap/debootstrap.log for details (possibly the package wide-dhcpv6-server is at fault) gpgv: Signature made Sat Oct 18 11:33:02 2014 BST using RSA key ID 46925553 gpgv: Good signature from Debian Archive Automatic Signing Key (7.0/wheezy) ftpmas...@debian.org gpgv: Signature made Sat Oct 18 11:37:18 2014 BST using RSA key ID 65FFB764 gpgv: Good signature from Wheezy Stable Release Key debian-rele...@lists.debian.org dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg': missing description dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg': missing architecture Selecting previously unselected package base-files. dpkg: regarding .../base-files_7.1wheezy7_i386.deb containing base-files, pre-dependency problem: base-files pre-depends on awk awk is not installed. dpkg: warning: ignoring pre-dependency problem! (Reading database ... 0 files and directories currently installed.) Unpacking base-files (from .../base-files_7.1wheezy7_i386.deb) ... Selecting previously unselected package base-passwd. Unpacking base-passwd (from .../base-passwd_3.5.26_i386.deb) ... dpkg: base-passwd: dependency problems, but configuring anyway as you requested: base-passwd depends on libc6 (= 2.8); however: Package libc6 is not installed. Setting up base-passwd (3.5.26) ... dpkg: base-files: dependency problems, but configuring anyway as you requested: base-files depends on awk; however: Package awk is not installed. Setting up base-files (7.1wheezy7) ... dpkg: warning: parsing file '/var/lib/dpkg/status' near line 50 package 'dpkg': missing description dpkg: warning: parsing file '/var/lib/dpkg/status' near line 50 package 'dpkg': missing architecture dpkg: regarding .../archives/dpkg_1.16.15_i386.deb containing dpkg, pre-dependency problem: dpkg pre-depends on libbz2-1.0 libbz2-1.0 is not
Bug#759125: tsocks: racey non-blocking connect() + sendto() skips SOCKS connect
Package: tsocks
Version: 1.8beta5-9.2
Severity: normal
Tags: upstream patch
Dear Maintainer,
Found that I could not use 'user mode' of qemu with tsocks (although I could
use proxychains) and so did some digging; proxychains does not support
specifying subnets to bypass a SOCKS server to so does not suit my needs.
Turns out qemu uses a non-blocking connect, and then always starts off
using the socket immediately with sendto();sendto(). As tsocks has
not yet sent the SOCKS request header, my 'ssh -D 1080 ...' gets very annoyed
very quickly :)
[pid 23463] connect(46, {sa_family=AF_INET, sin_port=htons(1080),
sin_addr=inet_addr(127.0.0.1)}, 16) = -1 EINPROGRESS (Operation now in
progress)
[pid 23463] sendto(46, , 0, 0, NULL, 0) = 0
[pid 23463] sendto(46, GET /ncsi.txt HTTP/1.1\r\nConnecti..., 97, 0, NULL, 0)
= 97
[pid 23463] recvfrom(46, , 8760, 0, NULL, NULL) = 0
[pid 23463] shutdown(46, 0 /* receive */) = 0
[pid 23463] shutdown(46, 1 /* send */) = 0
The fix is to force the socket to connect() blocking (turns out peeking in
the proxychains source, they do just this).
The attached patch takes the ifdef 0'd lines at the end and splices them
into the connect_server() where I suspect they used to live a while back.
Now, 'TSOCKS_CONNECT_BLOCKING=1 tsocks qemu -net user ...' works great! :)
[pid 23488] connect(47, {sa_family=AF_INET, sin_port=htons(1080),
sin_addr=inet_addr(127.0.0.1)}, 16) = 0
[pid 23488] sendto(47, \5\2\0\2, 4, 0, NULL, 0) = 4
[pid 23488] recvfrom(47, \5\0, 2, 0, NULL, NULL) = 2
[pid 23488] sendto(47, \5\1\0\1\27?cj\0P, 10, 0, NULL, 0) = 10
[pid 23488] recvfrom(47, 0x7fd4c8897668, 10, 0, 0, 0) = -1 EAGAIN (Resource
temporarily unavailable)
[pid 23488] sendto(47, , 0, 0, NULL, 0) = 0
[pid 23488] sendto(47, GET /ncsi.txt HTTP/1.1\r\nConnecti..., 97, 0, NULL, 0)
= 97
[pid 23488] recvfrom(47, \5\0\0\1\0\0\0\0\0\0, 8760, 0, NULL, NULL) = 10
[pid 23488] shutdown(47, 1 /* send */) = 0
[pid 23488] recvfrom(47, HTTP/1.1 200 OK\r\nContent-Length:..., 8750, 0,
NULL, NULL) = 179
[pid 23488] recvfrom(47, , 7300, 0, NULL, NULL) = 0
[pid 23488] shutdown(47, 0 /* receive */) = -1 ENOTCONN (Transport endpoint is
not connected)
-- System Information:
Debian Release: 7.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-0.bpo.1-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 tsocks depends on:
ii libc6 2.13-38+deb7u3
tsocks recommends no packages.
tsocks suggests no packages.
-- Configuration Files:
/etc/tsocks.conf changed [not included]
-- no debconf information
--- tsocks.c.orig 2014-08-24 15:55:34.497950041 +0100
+++ tsocks.c 2014-08-24 16:19:19.905895517 +0100
@@ -67,6 +67,8 @@
static int suid = 0;
static char *conffile = NULL;
+static int connect_blocking = 0;
+
/* Exported Function Prototypes */
void _init(void);
int connect(CONNECT_SIGNATURE);
@@ -156,6 +158,9 @@
set_log_options(loglevel, logfile, 1);
#endif
+ if ((env = getenv(TSOCKS_CONNECT_BLOCKING)))
+ connect_blocking = 1;
+
done = 1;
return(0);
@@ -845,14 +850,32 @@
static int connect_server(struct connreq *conn) {
int rc;
+ int sockflags;
/* Connect this socket to the socks server */
show_msg(MSGDEBUG, Connecting to %s port %d\n,
inet_ntoa(conn-serveraddr.sin_addr), ntohs(conn-serveraddr.sin_port));
+ /* If we are forcing the socket to connect() blocking... */
+ /* Get the flags of the socket, (incase its non blocking) */
+ if (connect_blocking (sockflags = fcntl(conn-sockid, F_GETFL)) == -1) {
+ sockflags = 0;
+ }
+
+ /* If the flags show the socket as blocking, set it to */
+ /* blocking for our connection to the socks server */
+ if (connect_blocking (sockflags O_NONBLOCK) != 0) {
+ fcntl(conn-sockid, F_SETFL, sockflags (~(O_NONBLOCK)));
+ }
+
rc = realconnect(conn-sockid, (CONNECT_SOCKARG) (conn-serveraddr),
sizeof(conn-serveraddr));
+ /* If the socket was in non blocking mode, restore that */
+ if (connect_blocking (sockflags O_NONBLOCK) != 0) {
+ fcntl(conn-sockid, F_SETFL, sockflags);
+ }
+
show_msg(MSGDEBUG, Connect returned %d, errno is %d\n, rc, errno);
if (rc) {
if (errno != EINPROGRESS) {
Bug#745921: nginx: http push has a unix socket fd leak on reloads
Package: nginx
Version: 1.4.6-1~bpo70+1
Severity: important
Tags: upstream
Dear Maintainer,
We are using nginx-extras (wheezy, {squeeze,wheezy}-backports) and have noticed
that on reload there are unix socket FD leaks (in our environment we reload
regularly).
By recompiling and pruning out the modules used, I was able to drill the
problem down the the nginx-http-push module; not a surprise as it is the only
one that calls socketpair(AF_UNIX).
First thing I did was drop in the latest version (0.712, Debian has 0.692) and
recompile, unfortunately it did not fix anything.
To reproduce the problem, all you have to do is install
nginx-extras and reload:
# lsof -n -p $(pgrep -P1 nginx) | grep socket
nginx 1538 root3u unix 0x88101ddc5080 0t0 2297044 socket
nginx 1538 root7u unix 0x88201b7e7440 0t0 2296101 socket
nginx 1538 root8u unix 0x88201b7e77c0 0t0 2296102 socket
nginx 1538 root9u unix 0x88201b7e70c0 0t0 2296103 socket
nginx 1538 root 10u unix 0x88201671fc00 0t0 2296104 socket
nginx 1538 root 11u unix 0x88201671f880 0t0 2296105 socket
nginx 1538 root 12u unix 0x88201671f500 0t0 2296106 socket
nginx 1538 root 13u unix 0x88201671f180 0t0 2296107 socket
nginx 1538 root 14u unix 0x8820159c5c40 0t0 2296108 socket
nginx 1538 root 15u unix 0x88101ddc5780 0t0 2297045 socket
nginx 1538 root 16u unix 0x88101d1cc080 0t0 2297046 socket
nginx 1538 root 17u unix 0x88101d1ccb00 0t0 2297047 socket
nginx 1538 root 18u unix 0x88101d1cc400 0t0 2297048 socket
nginx 1538 root 19u unix 0x8810150b40c0 0t0 2297049 socket
nginx 1538 root 20u unix 0x881015fd0c00 0t0 2297050 socket
nginx 1538 root 21u unix 0x881015fd0880 0t0 2297051 socket
# /etc/init.d/nginx reload
# lsof -n -p $(pgrep -P1 nginx) | grep socket
nginx 1538 root4u unix 0x88101e7fa3c0 0t0 2297070 socket
nginx 1538 root5u unix 0x88101e7fa040 0t0 2297071 socket
nginx 1538 root7u unix 0x88201b7e7440 0t0 2296101 socket
nginx 1538 root8u unix 0x88201b7e77c0 0t0 2296102 socket
nginx 1538 root9u unix 0x88201b7e70c0 0t0 2296103 socket
nginx 1538 root 10u unix 0x88201671fc00 0t0 2296104 socket
nginx 1538 root 11u unix 0x88201671f880 0t0 2296105 socket
nginx 1538 root 12u unix 0x88201671f500 0t0 2296106 socket
nginx 1538 root 13u unix 0x88201671f180 0t0 2296107 socket
nginx 1538 root 14u unix 0x8820159c5c40 0t0 2296108 socket
nginx 1538 root 24u unix 0x881015fd0500 0t0 2297062 socket
nginx 1538 root 25u unix 0x881015fd0180 0t0 2297063 socket
nginx 1538 root 26u unix 0x88101f849c40 0t0 2297064 socket
nginx 1538 root 27u unix 0x88101f8498c0 0t0 2297065 socket
nginx 1538 root 28u unix 0x88101f849540 0t0 2297066 socket
nginx 1538 root 29u unix 0x88101f8491c0 0t0 2297067 socket
nginx 1538 root 30u unix 0x88101e7faac0 0t0 2297068 socket
nginx 1538 root 31u unix 0x88101e7fa740 0t0 2297069 socket
nginx 1538 root 32u unix 0x88101d3dbb00 0t0 2297072 socket
nginx 1538 root 33u unix 0x88101d3db780 0t0 2297073 socket
nginx 1538 root 34u unix 0x88101d3db400 0t0 2297074 socket
nginx 1538 root 35u unix 0x88101d3db080 0t0 2297075 socket
nginx 1538 root 36u unix 0x8810189efb40 0t0 2297076 socket
nginx 1538 root 37u unix 0x8810189ef7c0 0t0 2297077 socket
# for I in $(seq 1 20); do /etc/init.d/nginx reload; done
# lsof -n -p $(pgrep -P1 nginx) | grep socket | wc -l
104
# for I in $(seq 1 100); do /etc/init.d/nginx reload; done
# lsof -n -p $(pgrep -P1 nginx) | grep socket | wc -l
456
You should notice that the number of open unix sockets increases; these unix
sockets are what the master process uses to speak to its workers.
Marking this important as the last thing you want to do is run out of FD's :)
I tried digging around to fix it myself but came up empty handed, sorry.
Cheers
-- System Information:
Debian Release: 7.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-0.bpo.1-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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721284: rlinetd and ucf problems in update-inetd
Package: rlinetd Version: 0.8.2-2 Severity: normal Dear Maintainer, When trying to install leafnode I get the following: Setting up leafnode (1.11.8-3) ... *** WARNING: ucf was run from a maintainer script that uses debconf, but the script did not pass --debconf-ok to ucf. The maintainer script should be fixed to not stop debconf before calling ucf, and pass it this parameter. For now, ucf will revert to using old-style, non-debconf prompting. Ugh! Took me a moment to figure out, but leafnode calls update-inetd (I use rlinetd) and it is that which calls ucf. Not sure how to fix this properly, but temporarily editing the call to ucf in /usr/sbin/update-inetd to include --debconf-ok let me continue. Cheers -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (950, 'stable'), (500, 'stable-updates') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 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 rlinetd depends on: ii debconf [debconf-2.0] 1.5.49 ii dpkg 1.16.10 ii libc6 2.13-38 ii libcap21:2.22-1.2 ii libwrap0 7.6.q-24 ii lsb-base 4.1+Debian8+deb7u1 ii netbase5.0 ii perl 5.14.2-21 ii psmisc 22.19-1+deb7u1 ii ucf3.0025+nmu3 Versions of packages rlinetd recommends: ii inetutils-syslogd [system-log-daemon] 2:1.9-2 Versions of packages rlinetd suggests: ii rpcbind [portmap] 0.2.0-8 -- Configuration Files: /etc/rlinetd.conf changed [not included] -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711872: as root, build succeeds but tests do not - no 'gdnsd' user
Package: gdnsd Version: 1.8.3-1 Severity: serious Tags: upstream patch Justification: fails to build from source The tests fail to start as the 'gdnsd' user does not exist on a fresh system at build time (might be worth changing the tests to use the 'nobody' user? patch enclosed): root@dnsdev-1-t42:/usr/src# wget http://ftp.de.debian.org/debian/pool/main/g/gdnsd/gdnsd_1.8.3-1.dsc http://ftp.de.debian.org/debian/pool/main/g/gdnsd/gdnsd_1.8.3.orig.tar.xz http://ftp.de.debian.org/debian/pool/main/g/gdnsd/gdnsd_1.8.3-1.debian.tar.xz root@dnsdev-1-t42:/usr/src# dpkg-source -x gdnsd_1.8.3-1.dsc root@dnsdev-1-t42:/usr/src# cd gdnsd-1.8.3/ root@dnsdev-1-t42:/usr/src/gdnsd-1.8.3# dpkg-buildpackage -rfakeroot -us -uc -b [snipped] Making check in docs make[3]: Entering directory `/usr/src/gdnsd-1.8.3/docs' make[3]: Nothing to be done for `check'. make[3]: Leaving directory `/usr/src/gdnsd-1.8.3/docs' Making check in t make[3]: Entering directory `/usr/src/gdnsd-1.8.3/t' make check-local make[4]: Entering directory `/usr/src/gdnsd-1.8.3/t' Test data/outputs will be stored at /usr/src/gdnsd-1.8.3/t/testout if test x != x; then \ TOP_BUILDDIR=/usr/src/gdnsd-1.8.3 TESTOUT_DIR=/usr/src/gdnsd-1.8.3/t/testout TESTPORT_START=12345 /usr/bin/perl -I. -MTest::Harness -e runtests(@ARGV) ./; \ else \ TOP_BUILDDIR=/usr/src/gdnsd-1.8.3 TESTOUT_DIR=/usr/src/gdnsd-1.8.3/t/testout TESTPORT_START=12345 /usr/bin/perl -I. -MTest::Harness -e runtests(@ARGV) ./[0-9]*/*.t; \ fi ./001basic/001self.t 7/9 Bailout called. Further testing stopped: gdnsd failed to finish starting properly. output (if any): # Failed test at ./001basic/001self.t line 23. # Cannot spawn daemon: gdnsd failed to finish starting properly. output (if any): # Created directory [/usr/src/gdnsd-1.8.3/t/testout/001basic_001self]/etc/geoip # Created directory [/usr/src/gdnsd-1.8.3/t/testout/001basic_001self]/run # Loading configuration from 'etc/config' # DNS listener configured for 127.0.0.1:12345 # DNS listener configured for [::1]:12345 # User 'gdnsd' does not exist FAILED--Further testing stopped: gdnsd failed to finish starting properly. output (if any): make[4]: *** [check-local] Error 255 make[4]: Leaving directory `/usr/src/gdnsd-1.8.3/t' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/usr/src/gdnsd-1.8.3/t' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/usr/src/gdnsd-1.8.3' make[1]: *** [check] Error 2 make[1]: Leaving directory `/usr/src/gdnsd-1.8.3' dh_auto_test: make -j1 test returned exit code 2 make: *** [build] Error 29 dpkg-buildpackage: error: debian/rules build gave error exit status 2 diff -u -r gdnsd-1.8.3/t/001basic/gdnsd.conf gdnsd-1.8.3.orig/t/001basic/gdnsd.conf --- gdnsd-1.8.3/t/001basic/gdnsd.conf 2013-06-10 12:45:21.0 + +++ gdnsd-1.8.3.orig/t/001basic/gdnsd.conf 2013-02-04 23:12:22.0 + @@ -3,6 +3,5 @@ http_listen = @http_lspec@ dns_port = @dns_port@ http_port = @http_port@ - username = nobody realtime_stats = true } diff -u -r gdnsd-1.8.3/t/002simple/gdnsd.conf gdnsd-1.8.3.orig/t/002simple/gdnsd.conf --- gdnsd-1.8.3/t/002simple/gdnsd.conf 2013-06-10 12:45:22.0 + +++ gdnsd-1.8.3.orig/t/002simple/gdnsd.conf 2013-02-04 23:12:22.0 + @@ -3,7 +3,6 @@ http_listen = @http_lspec@ dns_port = @dns_port@ http_port = @http_port@ - username = nobody include_optional_ns = true realtime_stats = true udp_recv_width = 1 diff -u -r gdnsd-1.8.3/t/003complex/gdnsd.conf gdnsd-1.8.3.orig/t/003complex/gdnsd.conf --- gdnsd-1.8.3/t/003complex/gdnsd.conf 2013-06-10 12:44:52.0 + +++ gdnsd-1.8.3.orig/t/003complex/gdnsd.conf 2013-02-04 23:12:22.0 + @@ -3,7 +3,6 @@ http_listen = @http_lspec@ dns_port = @dns_port@ http_port = @http_port@ - username = nobody zones_default_ttl = 21600 realtime_stats = true max_response = 62464 diff -u -r gdnsd-1.8.3/t/004misc/gdnsd.conf gdnsd-1.8.3.orig/t/004misc/gdnsd.conf --- gdnsd-1.8.3/t/004misc/gdnsd.conf 2013-06-10 12:44:49.0 + +++ gdnsd-1.8.3.orig/t/004misc/gdnsd.conf 2013-02-04 23:12:22.0 + @@ -3,7 +3,6 @@ http_listen = @http_lspec@ dns_port = @dns_port@ http_port = @http_port@ - username = nobody include_optional_ns = true realtime_stats = true max_response = 62464 diff -u -r gdnsd-1.8.3/t/005tld/gdnsd.conf gdnsd-1.8.3.orig/t/005tld/gdnsd.conf --- gdnsd-1.8.3/t/005tld/gdnsd.conf 2013-06-10 12:45:07.0 + +++ gdnsd-1.8.3.orig/t/005tld/gdnsd.conf 2013-02-04 23:12:22.0 + @@ -3,7 +3,6 @@ http_listen = @http_lspec@ dns_port = @dns_port@ http_port = @http_port@ - username = nobody zones_default_ttl = 43200 realtime_stats = true } diff -u -r gdnsd-1.8.3/t/006root/gdnsd.conf gdnsd-1.8.3.orig/t/006root/gdnsd.conf --- gdnsd-1.8.3/t/006root/gdnsd.conf 2013-06-10 12:45:32.0 + +++
Bug#525007: offlineimap: Runs indefinitely at 100% CPU if network changes
Hi, http://bugs.debian.org/596291 links to the correct commit for a fix, although it is nothing to do with threading; the bug is that a read() on a FD comes back with zero bytes (its an EOF). The following fixes the bug: https://github.com/OfflineIMAP/offlineimap/commit/b94bf792585a9297851bdb965c4bbd6bdadeeb42 It does not apply cleanly to the Debian squeeze version, but I have been running for some time the attached patch based on it. Cheers -- Alexander Clouter .sigmonster says: BOFH excuse #166: /pub/lunch diff -u -r offlineimap-6.2.0.2/offlineimap/imaplibutil.py offlineimap-6.2.0.2.orig/offlineimap/imaplibutil.py --- offlineimap-6.2.0.2/offlineimap/imaplibutil.py 2012-12-01 14:22:41.93201 + +++ offlineimap-6.2.0.2.orig/offlineimap/imaplibutil.py 2010-06-29 22:49:59.0 +0100 @@ -49,10 +49,7 @@ def read(self, size): retval = '' while len(retval) size: -buf = self.infd.read(size - len(retval)) -if not buf: -break -retval += buf +retval += self.infd.read(size - len(retval)) return retval def readline(self): @@ -97,8 +94,6 @@ retval = '' while 1: linebuf = self.read(1024) -if not linebuf: -return retval nlindex = linebuf.find(\n) if nlindex != -1: retval += linebuf[:nlindex + 1] diff -u -r offlineimap-6.2.0.2/offlineimap/imapserver.py offlineimap-6.2.0.2.orig/offlineimap/imapserver.py --- offlineimap-6.2.0.2/offlineimap/imapserver.py 2012-12-01 14:18:58.05601 + +++ offlineimap-6.2.0.2.orig/offlineimap/imapserver.py 2010-06-29 22:49:59.0 +0100 @@ -74,8 +74,6 @@ io = StringIO() while read size: data = imaplib.IMAP4.read (self, min(size-read,8192)) -if not data: -break read += len(data) io.write(data) return io.getvalue() @@ -95,8 +93,6 @@ io = StringIO() while read size: data = imaplibutil.WrappedIMAP4_SSL.read (self, min(size-read,8192)) -if not data: -break read += len(data) io.write(data) return io.getvalue()
Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin
* Sebastian Andrzej Siewior sebast...@breakpoint.cc [2011-08-08 22:46:38+0200]: * Thus spake Alexander Clouter (a...@digriz.org.uk): I have just been tasked with putting together an active-active IPsec VPN concentrator (with a need to use AES-SHA1 it seems) and I was hoping to use the OpenRD's (and mv_cesa). Have you got a patch I can test that fixes things for SHA1? The patch below should work around the problem by not using it. I'll have you know I passed with honours from the Computing School of Commenting Out and as such do not require such assistance as this ;) You could try the kernel from backports. If I remember correctly than it seems that the later kernel passes one big chunk instead of three requests (init, update, fin). If that works out for then the only problem are fragmanted packets. Do not tinkering with the 'mode' bit at 0xdd18 help[1][2] (as suggested by Arnaud)? I'm happy to be the guinea pig here. I'll install the backports one anyway for testing and let you know. Cheers [1] page 458 of http://www.embeddedarm.com/documentation/third-party/MV88F5182-usermanual.pdf [2] you might also be interested in http://www.digriz.org.uk/ts78xx?action=AttachFiledo=gettarget=88F5182_Functional_Errata.pdf -- Alexander Clouter .sigmonster says: Knocked, you weren't in. -- Opportunity -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin
* Sebastian Andrzej Siewior sebast...@breakpoint.cc [2011-06-08 13:38:10+0200]: * Alexander Clouter | 2011-06-08 09:54:58 [+]: Whilst deploying IPsec (with strongswan-ike2) I ran into a complication[1] that causes mv_cesa to spin the CPU when the system receives an IPsec ESP packet; it seems to be able to send traffic (before the CPU spin) as a ICMP Echo request (a la pin) out from the system out is okay, until the ICMP Reply comes back. The packet never 'arrives' as far as userspace is concerned and the only way to stop the CPU spinning is a reboot. I've been working on that and forgot about it in the meantime. The problem is that incremental sha1 checksum are wrong i.e. the previous state is ignored by the hardware. I have just been tasked with putting together an active-active IPsec VPN concentrator (with a need to use AES-SHA1 it seems) and I was hoping to use the OpenRD's (and mv_cesa). Have you got a patch I can test that fixes things for SHA1? Cheers -- Alexander Clouter .sigmonster says: You fill a much-needed gap. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633738: ip6_tunnel: kernel BUG at net_namespace.c:497
* dann frazier da...@dannf.org [2011-07-15 13:24:39-0600]: I'd appreciate it if you could test Arnaud's proposed fix in your configuration to help verify that no other issues remain. Applying the patch fixes the problem and the tunnel works as expected. Cheers -- Alexander Clouter .sigmonster says: You will forget that you ever knew me. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633738: ip6_tunnel: kernel BUG at net_namespace.c:497
* dann frazier da...@dannf.org [2011-07-15 13:24:39-0600]: tags 633738 + lenny This is a regression as I was able to do all this with earlier kernels; definately 2.6.32-34squeeze1. hm... looks like it's from the backport of mainline commit d5aa407f59f5b83d2c50ec88f5bf56d40f1f8978. It's changing a call to register_pernet_gen_device() into a call to register_pernet_device(). [...] Right. And it looks like this affects lenny as well (since 2.6.26-26lenny3). Yep, I used basically the same backport for both updates. Apologies for the regression. Alexander, I'd appreciate it if you could test Arnaud's proposed fix in your configuration to help verify that no other issues remain. I can test it on an orion5x (armel) platform this weekend (and amd64), but on if you wanted it tested on a kirkwood device I cannot do that till Tuesday at the earliest. Looks to me that an amd64 test would be the most straight forward to do as it is not an ARM specific bug. Cheers -- Alexander Clouter .sigmonster says: BOFH excuse #412: Radial Telemetry Infiltration -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633738: ip6_tunnel: kernel BUG at net_namespace.c:497
Package: linux-2.6 Version: 2.6.32-35 Severity: important Tags: squeeze If have the following in my /etc/network/interfaces file: auto iptv-foobar iface iptv-foobar inet static address 169.254.0.2 netmask 255.255.255.255 pointopoint 169.254.0.3 pre-upmodprobe ip6_tunnel pre-upip -6 tunnel add iptv-foobar mode ipip6 remote 2001:db8:1::1 local 2001:db8:2::1 ttl 64 post-down ip tunnel del iptv-foobar upip link set iptv-foobar multicast on upsysctl -q net.ipv4.conf.iptv-foobar.rp_filter=0 upsysctl -q net.ipv4.conf.iptv-foobar.forwarding=0 It seems when ip6_tunnel is loaded, I get the following BUG: [ 33.135714] kernel BUG at /build/buildd-linux-2.6_2.6.32-35-armel-66FbPF/linux-2.6-2.6.32/debian/build/source_armel_none/net/core/net_namespace.c:497! [ 33.149340] Unable to handle kernel NULL pointer dereference at virtual address [ 33.157485] pgd = df31 [ 33.160204] [] *pgd=1f0a4031, *pte=, *ppte= [ 33.166643] Internal error: Oops: 817 [#1] [ 33.170756] last sysfs file: /sys/module/ipv6/initstate [ 33.176003] Modules linked in: ip6_tunnel(+) tunnel6 bonding ipv6 iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables dm_mod hmac xgifb(C) sata_mv fb ehci_hcd sha1_generic cfbcopyarea libata mv_cesa usbcore cfbimgblt scsi_mod mv643xx_eth aes_generic libphy inet_lro cfbfillrect nls_base [ 33.207618] CPU: 0Tainted: G C (2.6.32-5-kirkwood #1) [ 33.213831] PC is at __bug+0x1c/0x28 [ 33.217418] LR is at __bug+0x18/0x28 [ 33.221012] pc : [c002b7f8]lr : [c002b7f4]psr: 6013 [ 33.221018] sp : df333ee8 ip : 987a fp : 0001cf00 [ 33.232555] r10: bf24d338 r9 : df332000 r8 : dfb716c0 [ 33.237805] r7 : c043af08 r6 : r5 : r4 : c03d0a34 [ 33.244362] r3 : r2 : c03b4d2c r1 : 6013 r0 : 00a0 [ 33.250921] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 33.258088] Control: 0005317f Table: 1f31 DAC: 0015 [ 33.263860] Process modprobe (pid: 482, stack limit = 0xdf332270) [ 33.269982] Stack: (0xdf333ee8 to 0xdf334000) [ 33.274364] 3ee0: c03d0a34 c02397ec c03d0a34 c043af08 dfb716c0 [ 33.282588] 3f00: c043af08 bf24d3d0 dfb71840 c03d0a34 bf24f734 c043af08 [ 33.290811] 3f20: 40156000 c03d0a34 c023942c bf24f734 bf252000 c03d0a48 40156000 [ 33.299033] 3f40: c02395c0 bf252000 bf25200c c002734c [ 33.307256] 3f60: 56bc bf24f744 40156000 bf24f744 40156000 [ 33.315479] 3f80: c0028048 c00738ec dfb71300 dfb20a80 0001b038 0001b070 [ 33.323702] 3fa0: 0080 c0027ea0 0001b070 40156000 56bc 0001cfb0 [ 33.331925] 3fc0: 0001b070 0080 0001b038 0001cf00 [ 33.340149] 3fe0: 0001cfb0 be8f395c b720 400ee1d4 6010 40156000 [ 33.348380] [c002b7f8] (__bug+0x1c/0x28) from [c02397ec] (net_assign_generic+0x3c/0xbc) [ 33.356789] [c02397ec] (net_assign_generic+0x3c/0xbc) from [bf24d3d0] (ip6_tnl_init_net+0x98/0x19c [ip6_tunnel]) [ 33.367378] [bf24d3d0] (ip6_tnl_init_net+0x98/0x19c [ip6_tunnel]) from [c023942c] (register_pernet_operations+0x40/0xf4) [ 33.378658] [c023942c] (register_pernet_operations+0x40/0xf4) from [c02395c0] (register_pernet_device+0x20/0x54) [ 33.389240] [c02395c0] (register_pernet_device+0x20/0x54) from [bf25200c] (ip6_tunnel_init+0xc/0x84 [ip6_tunnel]) [ 33.399915] [bf25200c] (ip6_tunnel_init+0xc/0x84 [ip6_tunnel]) from [c002734c] (do_one_initcall+0x6c/0x1e4) [ 33.410062] [c002734c] (do_one_initcall+0x6c/0x1e4) from [c00738ec] (sys_init_module+0xc0/0x1f0) [ 33.419241] [c00738ec] (sys_init_module+0xc0/0x1f0) from [c0027ea0] (ret_fast_syscall+0x0/0x28) [ 33.428333] Code: e1a01000 e59f000c eb0a2ec7 e3a03000 (e5833000) [ 33.434502] ---[ end trace bf87ce5c849aaa8e ]--- Segmentation fault Failed to bring up iptv-shironeko. This is a regression as I was able to do all this with earlier kernels; definately 2.6.32-34squeeze1. Cheers -- Package-specific info: ** Version: Linux version 2.6.32-5-kirkwood (Debian 2.6.32-35) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Tue Jun 14 23:05:32 UTC 2011 ** Command line: console=ttyS1,115200=panic=10 ubi.mtd=root kw_openrd_init_uart1=232 root=ubi0:rootfs rootfstype=ubifs rw ** Tainted: C (1024) * Module from drivers/staging has been loaded. ** Model information Processor : Feroceon 88FR131 rev 1 (v5l) Hardware: Marvell OpenRD Ultimate Board Revision: ** Loaded modules: Module Size Used by ext4 288561 1 mbcache 4860 1 ext4 jbd2 64191 1 ext4
Bug#631608: inputattach spins CPU at 100%
Package: inputattach
Version: 1:1.4-1
Severity: important
Tags: upstream patch
When booting, inputattach tries to hook up my serial port for some w8001 action
but causes the CPU instead to spin at 100%. strace'ing shows it's spinning on
read(3,NULL,0) and is returning EBUSY; /proc/$PID/fd/3 points to /dev/ttyS0.
Looking at the source I found the following caused the problem:
http://linuxconsole.svn.sourceforge.net/viewvc/linuxconsole?view=revisionrevision=2422
http://linuxconsole.svn.sourceforge.net/viewvc/linuxconsole/trunk/utils/inputattach.c?r1=2412r2=2422pathrev=2422
We need to tell Kees Cook that errno does actually have more than two values
(not just zero and EINTR) and reading manpages helps ;P
Attached is a fix that seems to work after a suspend/resume cycle and of course
on a fresh boot.
Thanks though to Kee's on finding what the actual hiccup was in the first place
though, it's removed another thing off my todo list.
Cheers
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (900, 'unstable'), (500, 'experimental'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.39-2-amd64 (SMP w/2 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 inputattach depends on:
ii libc6 2.13-7 Embedded GNU C Library: Shared lib
inputattach recommends no packages.
inputattach suggests no packages.
-- no debconf information
--- joystick-1.4.orig/utils/inputattach.c 2011-05-16 22:05:56.0 +0100
+++ joystick-1.4/utils/inputattach.c 2011-06-25 10:49:00.0 +0100
@@ -607,6 +607,9 @@
puts();
}
+/* palmed wisdom from http://stackoverflow.com/questions/1674162/ */
+#define RETRY_ERROR(x) (x == EAGAIN || x == EWOULDBLOCK || x == EINTR)
+
int main(int argc, char **argv)
{
unsigned long devt;
@@ -738,7 +741,13 @@
retval = EXIT_FAILURE;
}
- for (errno = 0; errno != EINTR; read(fd, NULL, 0)) ;
+ do {
+ i = read(fd, NULL, 0);
+ if (i == -1) {
+ if (RETRY_ERROR(errno))
+continue;
+ }
+ } while (!i);
ldisc = 0;
ioctl(fd, TIOCSETD, ldisc);
Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin
Package: linux-2.6 Version: 2.6.32-34squeeze1 Severity: normal Whilst deploying IPsec (with strongswan-ike2) I ran into a complication[1] that causes mv_cesa to spin the CPU when the system receives an IPsec ESP packet; it seems to be able to send traffic (before the CPU spin) as a ICMP Echo request (a la pin) out from the system out is okay, until the ICMP Reply comes back. The packet never 'arrives' as far as userspace is concerned and the only way to stop the CPU spinning is a reboot. The configuration I have been using is: server (Marvell OpenRD) conn %default keyexchange=ikev2 mobike=no auto=add conn soas-v6 left=2001:db8:f00:ba4::1 leftprotoport=tcp/echo right=%any authby=secret type=transport conn soas-v4 left=192.0.2.1 leftprotoport=tcp/echo right=%any authby=secret type=transport client (my x86-filth laptop) conn %default keyexchange=ikev2 mobike=no auto=route conn soas-v6 left=%defaultroute right=2001:db8:f00:ba4::1 rightprotoport=tcp/echo authby=secret type=transport conn soas-v4 left=%defaultroute right=192.0.2.1 rightprotoport=tcp/echo authby=secret type=transport Noticing that IPsec is doing hardware offloading, I looked to see what has been happening to mv_cesa.c since v2.6.32[2] and nothing stands out other than 750052dd where SHA1 is enabled (which was backported into 2.6.32) and there does not seem to be anything bug fixing wise since. So I tried disabling SHA1 by tinkering with the server side of the configuration to add: conn %default esp=aes-md5 Now using md5, things start to work. Looks to me as either SHA1 does not work with IPsec, or when it is combined with at least AES. If more information is needed then do get intouch. Cheers [1] I seem to not be the only one http://marc.info/?l=linux-crypto-vgerm=130746635214483w=2 [2] git log v2.6.32..HEAD drivers/crypto/mv_cesa.c -- Package-specific info: ** Version: Linux version 2.6.32-5-kirkwood (Debian 2.6.32-34squeeze1) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Thu May 19 12:56:20 UTC 2011 ** Command line: console=ttyS1,115200 panic=10 ubi.mtd=root kw_openrd_init_uart1=232 root=ubi0:rootfs rootfstype=ubifs rw ** Tainted: C (1024) * Module from drivers/staging has been loaded. ** Kernel log: [ 46.358343] NET: Registered protocol family 15 [ 46.372871] alg: No test for cipher_null (cipher_null-generic) [ 46.378824] alg: No test for ecb(cipher_null) (ecb-cipher_null) [ 46.384900] alg: No test for digest_null (digest_null-generic) [ 46.390835] alg: No test for compress_null (compress_null-generic) [ 47.586948] Initializing XFRM netlink socket [ 88.324860] alg: No test for authenc(hmac(md5),cbc(aes)) (authenc(hmac(md5-generic),mv-cbc-aes)) [ snipped] ... [24010.137237] alg: No test for authenc(hmac(sha1),cbc(aes)) (authenc(mv-hmac-sha1,mv-cbc-aes)) ** Model information Processor : Feroceon 88FR131 rev 1 (v5l) Hardware: Marvell OpenRD Ultimate Board Revision: ** Loaded modules: Module Size Used by xfrm6_mode_tunnel 1474 0 xfrm4_mode_tunnel 1546 0 esp64591 0 xfrm6_mode_transport 1300 0 authenc 5940 0 xfrm4_mode_transport 1276 0 xt_multiport2341 1 xfrm_user 18561 2 xfrm4_tunnel1407 0 tunnel4 2035 1 xfrm4_tunnel ipcomp 1698 0 xfrm_ipcomp 3557 1 ipcomp esp44807 0 ah4 3703 0 ctr 3241 0 twofish 7467 0 twofish_common 14498 1 twofish camellia 21397 0 serpent21417 0 blowfish8262 0 cast5 16967 0 des_generic16617 0 cbc 2313 0 xcbc2219 0 rmd160 8978 0 sha256_generic 8818 0 crypto_null 2122 0 af_key 32325 0 sd_mod 31340 1 crc_t10dif 1106 1 sd_mod crc32c 2562 4 ib_iser25394 0 rdma_cm22074 1 ib_iser ib_cm 34755 1 rdma_cm iw_cm 6685 1 rdma_cm ib_sa 16138 2 rdma_cm,ib_cm ib_mad 33182 2 ib_cm,ib_sa ib_core40421 6 ib_iser,rdma_cm,ib_cm,iw_cm,ib_sa,ib_mad ib_addr 4427 1 rdma_cm iscsi_tcp 7907 2 libiscsi_tcp 11547 1 iscsi_tcp libiscsi 28804 3 ib_iser,iscsi_tcp,libiscsi_tcp scsi_transport_iscsi25876 4 ib_iser,iscsi_tcp,libiscsi fuse 51372 3 ip6_tunnel 11756 0 tunnel6 1866 1 ip6_tunnel bonding78390 0 ipv6 253910 52
Bug#616443: inputattach: w8001 support
Hi, * Stephen Kitt st...@sk2.org [2011-03-06 16:13:34+0100]: On Fri, 04 Mar 2011 15:38:46 +, Alexander Clouter a...@digriz.org.uk wrote: It would be nice to include the patch necessary to support the wacom_w8001 input driver in the kernel for use with inputattach. I put together the attached patch from bits found on the Redhat bugzilla site[1]. Thanks for the patch, I've pushed it upstream (see http://linuxconsole.svn.sourceforge.net/). I'll be preparing a new upstream release (at long last) and an updated Debian package will follow. OMG :) The above udev line works well for me, but as /usr is a seperate mountpoint for my system, it is not available when udev initially loads at boot. So, a two fold request: * include patch * if possible place copy of inputattach in / somewhere, I felt /lib/udev was the most apprioate place, but do not really mind Actually the right thing to do seems to be to wait for /usr/bin/inputattach to become available; see the /lib/udev/alsa-utils agent for an example. I'll be adding a similar mechanism for inputattach. Cunning, noted and thanks! Cheers -- Alexander Clouter .sigmonster says: BOFH excuse #138: BNC (brain not connected) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616443: inputattach: w8001 support
Package: inputattach
Version: 20051019-12
Severity: wishlist
Tags: patch
It would be nice to include the patch necessary to support the wacom_w8001
input driver in the kernel for use with inputattach.
I put together the attached patch from bits found on the Redhat bugzilla
site[1].
The patch generally works fine on my Fujitsu T2010[2] (although it does not
return after a resume, as udev never re-init's the serial device it
seems) but does require inputattach to be placed in /lib/udev to
function neatly.
# cp -a /usr/bin/inputattach /lib/udev
# cat 'EOF' /etc/udev/rules.d/99-local.rules
SUBSYSTEM==tty, KERNEL==ttyS[0-9]*, ATTRS{id}==FUJ02e5, ACTION==add,
RUN+=inputattach --daemon --baud 19200 --w8001 /dev/%k
EOF
The above udev line works well for me, but as /usr is a seperate
mountpoint for my system, it is not available when udev initially loads
at boot.
So, a two fold request:
* include patch
* if possible place copy of inputattach in / somewhere, I felt
/lib/udev was the most apprioate place, but do not really mind
Cheers
[1] https://bugzilla.redhat.com/show_bug.cgi?id=645235
[2] http://www.digriz.org.uk/debian/fujitsu/t2010#Touchscreen
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (900, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.37.1 (SMP w/2 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 inputattach depends on:
ii libc6 2.11.2-13 Embedded GNU C Library: Shared lib
inputattach recommends no packages.
inputattach suggests no packages.
-- no debconf information
--- joystick-20051019/utils/inputattach.c 2011-02-19 21:38:06.0 +
+++ joystick-20051019.new/utils/inputattach.c 2011-02-19 14:08:20.619998303 +
@@ -539,6 +539,9 @@
{ --dump, -dump, Just enable device,
B2400, CS8,
0, 0x00, 0x00, 0, dump_init },
+{ --w8001, -w8001, Wacom W8001,
+ B38400, CS8,
+ SERIO_W8001, 0x00, 0x00, 0, NULL },
{ NULL, NULL, NULL, 0, 0, 0, 0, 0, 0, NULL }
};
@@ -547,7 +550,7 @@
struct input_types *type;
puts();
- puts(Usage: inputattach [--daemon] [--always] [--noinit] mode device);
+ puts(Usage: inputattach [--daemon] [--baud baud] [--always] [--noinit] mode device);
puts();
puts(Modes:);
@@ -571,6 +574,7 @@
int i;
unsigned char c;
int retval;
+ int baud = -1;
int ignore_init_res = 0;
int no_init = 0;
@@ -587,6 +591,15 @@
} else if (need_device) {
device = argv[i];
need_device = 0;
+ } else if (!strcasecmp(argv[i], --baud)) {
+ if (argc = i + 1) {
+show_help();
+fprintf(stderr,
+ inputattach: require baud rate\n);
+return EXIT_FAILURE;
+ }
+
+ baud = atoi(argv[++i]);
} else {
if (type type-name) {
fprintf(stderr,
@@ -627,6 +640,19 @@
return 1;
}
+ switch(baud) {
+ case -1: break;
+ case 2400: type-speed = B2400; break;
+ case 4800: type-speed = B4800; break;
+ case 9600: type-speed = B9600; break;
+ case 19200: type-speed = B19200; break;
+ case 38400: type-speed = B38400; break;
+ default:
+ fprintf(stderr, inputattach: invalid baud rate '%d'\n,
+baud);
+ return EXIT_FAILURE;
+ }
+
setline(fd, type-flags, type-speed);
if (type-flush)
Bug#611998: syslog-ng: HOST macro off by one
Package: syslog-ng Version: 3.1.3-2 Severity: normal Whilst overhauling our syslog infrastructure, I noticed garbage was appearing in our logs. I use the following template when writing to files: template($ISODATE $FULLHOST $FACILITY.$PRIORITY $MSGHDR$MSGONLY\n) It turns out[1] that normalize_hostnames() has an off-by-one problem and a patch was produced[2] soon after 3.1.3 was released. The bug means $HOST/$FULLHOST do not include a NULL terminator at the end of the string, so garbage appears. Any chance of including the fix? Cheers [1] http://marc.info/?l=syslog-ngm=129044796131859w=2 [2] http://git.balabit.hu/?p=bazsi/syslog-ng-3.1.git;a=commitdiff;h=f6efe1a82c3726c7f65ca0dd173af8d3f58824aa;hp=3361f72c6c35d198e174200780d9744604e2cdf6 -- System Information: Debian Release: 6.0 APT prefers testing APT policy: (500, 'testing') Architecture: armel (armv5tel) Kernel: Linux 2.6.32-5-kirkwood 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 syslog-ng depends on: ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libcap2 1:2.19-3 support for getting/setting POSIX. ii libdbi0 0.8.2-3 Database Independent Abstraction L ii libevtlog0 0.2.8~1-2Syslog event logger library ii libgcc1 1:4.4.5-8GCC support library ii libglib2.0-02.24.2-1 The GLib library of C routines ii libnet1 1.1.4-2 library for the construction and h ii libpcre38.02-1.1 Perl 5 Compatible Regular Expressi ii libssl0.9.8 0.9.8o-4 SSL shared libraries ii libwrap07.6.q-19 Wietse Venema's TCP wrappers libra ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages syslog-ng recommends: ii logrotate 3.7.8-6Log rotation utility Versions of packages syslog-ng suggests: pn libdbd-mysql none (no description available) pn libdbd-pgsql none (no description available) pn libdbd-sqlite3none (no description available) -- Configuration Files: /etc/syslog-ng/syslog-ng.conf 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#608339: initramfs-tools: MODULES=dep fails when / is ubifs (reopen)
Hi,
* maximilian attems m...@stro.at [2010-12-30 21:11:18+]:
This is trivially resolved by amending the routines that search for the
root block device and fstype in /usr/share/initramfs-tools/hook-functions
to the following instead:
# findout root block device + fstype
eval $(mount | awk '!/^rootfs / / on \/ type / {print root= $1
\nFSTYPE= $5; exit}')
# On failure fallback to /proc/mounts if readable
if [ -z $root ] [ -r /proc/mounts ]; then
eval $(awk '!/^rootfs / / \/ / {print root= $1 \nFSTYPE=
$3; exit}' /proc/mounts)
fi
first please if you do changes send them as diff, it is pretty
trivial these days and helps a lot for the review of a change:
git clone git://git.debian.org/kernel/initramfs-tools.git
and see short guide on how to add features or fixes
http://git.debian.org/?p=kernel/initramfs-tools.git;a=blob_plain;f=docs/maintainer-notes.html;hb=HEAD
Apologies, .
This filters out the useless '^rootfs' entry (enabling embedded folk to
continue symlinking) and permits anything (not just '^/dev/...') as the
root device. Now the ubifs root filesystem detection functions.
so based on your proposal a diff would look like this:
diff --git a/hook-functions b/hook-functions
index cc8b344..6dfd54d 100644
--- a/hook-functions
+++ b/hook-functions
@@ -229,7 +229,7 @@ dep_add_modules()
# On failure fallback to /proc/mounts if readable
if [ -z $root ] [ -r /proc/mounts ]; then
- eval $(awk '/\/dev\// {if ($2 == /) {print root= $1
\nFSTYPE= $5; exit}}' /proc/mounts)
+ eval $(awk '!/^rootfs / {if ($2 == /) {print root= $1
\nFSTYPE= $3; exit}}' /proc/mounts)
fi
# recheck root device
Don't trust it enough for the 'mount |' try too? ;)
Works for me, many thanks.
It should also be noted, the original 'failure fallback' does not work
anyway as it incorrectly refers to $5 (over eager cutting and pasting it
seems) when it should refer to $3 for FSTYPE.
well you may choose your words more wisely, as if you'd continue to read
the function you would see that we don't use this FSTYPE value, so this
doesn't matter (;
Ahhh, well if that is the case, why bother to set FSTYPE? ;)
To clear up confusion, is it not being used after the '-z $root' check?
Cheers and have a Happy New Year.
--
Alexander Clouter
.sigmonster says: Honk if you hate bumper stickers that say Honk if ...
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608339: initramfs-tools: MODULES=dep fails when / is ubifs (reopen)
Package: initramfs-tools
Severity: normal
Similar to #582858, however for me it still does not work.
When I set MODULES=dep, root cannot be found as the root mountpoint
device does not start with '^/dev/' (thanks to my symlinking /etc/mtab
to /proc/mounts I also get two /'s also):
output of 'mount'
rootfs on / type rootfs (rw)
ubi0:rootfs on / type ubifs (rw,relatime)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,relatime,mode=755)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
varrun on /var/run type tmpfs (rw,nosuid,relatime,mode=755)
varlock on /var/lock type tmpfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev type tmpfs (rw,relatime,size=10240k,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noexec,relatime,size=32768k)
tmpfs on /var/tmp type tmpfs (rw,nosuid,nodev,noexec,relatime,size=8192k)
/dev/sda1 on /root/moo type vfat
(rw,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=utf8,shortname=mixed,errors=remount-ro)
contents of /proc/mounts
rootfs / rootfs rw 0 0
ubi0:rootfs / ubifs rw,relatime 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
varrun /var/run tmpfs rw,nosuid,relatime,mode=755 0 0
varlock /var/lock tmpfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,relatime,size=10240k,mode=755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,noexec,relatime,size=32768k 0 0
tmpfs /var/tmp tmpfs rw,nosuid,nodev,noexec,relatime,size=8192k 0 0
/dev/sda1 /root/moo vfat
rw,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=utf8,shortname=mixed,errors=remount-ro
0 0
This is trivially resolved by amending the routines that search for the
root block device and fstype in /usr/share/initramfs-tools/hook-functions
to the following instead:
# findout root block device + fstype
eval $(mount | awk '!/^rootfs / / on \/ type / {print root= $1
\nFSTYPE= $5; exit}')
# On failure fallback to /proc/mounts if readable
if [ -z $root ] [ -r /proc/mounts ]; then
eval $(awk '!/^rootfs / / \/ / {print root= $1 \nFSTYPE= $3;
exit}' /proc/mounts)
fi
This filters out the useless '^rootfs' entry (enabling embedded folk to
continue symlinking) and permits anything (not just '^/dev/...') as the
root device. Now the ubifs root filesystem detection functions.
It should also be noted, the original 'failure fallback' does not work
anyway as it incorrectly refers to $5 (over eager cutting and pasting it
seems) when it should refer to $3 for FSTYPE.
Cheers
System Info (armel - orion5x)
root@(none):~# cat /proc/cpuinfo
Processor : Feroceon rev 0 (v5l)
BogoMIPS: 332.59
Features: swp half thumb fastmult edsp
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part: 0x926
CPU revision: 0
Hardware: Technologic Systems TS-78xx SBC
Revision:
Serial :
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599291: isc-dhcp-server: hangs with 100% CPU load on startup
Hi, Novell, unsurprisingly, have released a fix for this bug. https://bugzilla.novell.com/show_bug.cgi?id=643845 It's been reported upstream too. Cheers -- Alexander Clouter .sigmonster says: A fool and his money are soon popular. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603265: please add isc-dhcp-server-ldap-dbg package
Package: isc-dhcp-server-ldap Version: 4.1.1-P1-11 Severity: wishlist Could a package with the debugging symbols for isc-dhcp-server-ldap be made available. Cheers -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: armel (armv5tel) Kernel: Linux 2.6.32-5-kirkwood 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 isc-dhcp-server-ldap depends on: ii debianutils 3.4 Miscellaneous utilities specific t ii isc-dhcp-common 4.1.1-P1-11 common files used by all the isc-d ii isc-dhcp-server 4.1.1-P1-11 ISC DHCP server for automatic IP a ii libc62.11.2-7Embedded GNU C Library: Shared lib ii libldap-2.4-22.4.23-6OpenLDAP libraries ii libssl0.9.8 0.9.8o-2SSL shared libraries isc-dhcp-server-ldap recommends no packages. isc-dhcp-server-ldap suggests no packages. -- 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#599291: isc-dhcp-server: hangs with 100% CPU load on startup
Package: isc-dhcp-server
Version: 4.1.1-P1-11
Severity: normal
Problem is caused by the use of 'option slp-directory-agent' and/or 'option
slp-service-scope'. By removing these, dhcpd loads up normally:
berk:/home/alex# tail /var/tmp/dhcp-ldap-startup.log
}
}
}
shared-network lar-1 {
option domain-name soas.ac.uk;
option domain-name-servers 193.63.73.32;
option domain-search soas.ac.uk;
option wpad http://proxy.soas.ac.uk/;;
option slp-directory-agent true 212.219.139.134;
option slp-service-scope true SOAS_SCOPE;
--- 100% CPU SPIN HANG
Although I am using the LDAP functionality, it's repeated with the non-LDAP
enabled dhcpcd. This seems to be an upstream bug and linked to the parsing of
that option, attached is a backtrace of where it is looping:
(gdb) bt full
#0 0x00461a33 in parse_option_data (expr=0x7fff1328ad68,
cfile=0x15b33b0, lookups=1, option=value optimized out) at parse.c:4932
uniform = 0
val = 0x7fb8178e4e40
fmt = 0x499c44 o
tmp = 0x0
token = value optimized out
#1 0x00461c01 in parse_option_statement (result=0x7fff1328ae08,
cfile=0x15b33b0, lookups=1, option=0x6afc00,
op=supersede_option_statement) at parse.c:5026
val = 0x15b34a4 SOAS_SCOPE
token = 4824132
expr = 0x1bb1160
lose = value optimized out
#2 0x00414f33 in parse_statement (cfile=0x15b33b0, group=0x15b4460,
type=2, host_decl=value optimized out, declaration=0)
at confpars.c:790
token = value optimized out
val = value optimized out
share = value optimized out
n = value optimized out
hardware = {hlen = 1 '\001', hbuf =
\000\000\000\000\000\000\000\260\026\063\030\270\177\000\000\240}}
et = 0x0
ep = value optimized out
option = 0x132
cache = value optimized out
lose = value optimized out
known = 1
status = value optimized out
code = 0
#3 0x00416a4c in parse_shared_net_declaration (cfile=0x15b33b0,
group=value optimized out) at confpars.c:2498
val = 0x15b34a4 SOAS_SCOPE
token = value optimized out
share = 0x1bb2150
name = value optimized out
declaration = 0
status = value optimized out
#4 0x004154d1 in parse_statement (cfile=0x15b33b0, group=0x12c7da0,
type=value optimized out, host_decl=value optimized out,
declaration=1) at confpars.c:432
token = SHARED_NETWORK
val = value optimized out
---Type return to continue, or q return to quit---
share = value optimized out
n = value optimized out
hardware = {hlen = 1 '\001', hbuf =
\000\000\000\000\000\000\000\260\026\063\030\270\177\000\000\300\257}
et = value optimized out
ep = value optimized out
option = 0x0
cache = value optimized out
lose = value optimized out
known = value optimized out
status = value optimized out
code = value optimized out
#5 0x0041a1b3 in conf_file_subparse (cfile=0x15b33b0, group=0x12c7da0,
group_type=0) at confpars.c:253
val = 0x15b34a4 SOAS_SCOPE
token = 4824132
declaration = 1
#6 0x004415fb in ldap_read_config () at ldap.c:1847
[snipped uninteresting bit]
Cheers
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: armel (armv5tel)
Kernel: Linux 2.6.32-5-kirkwood
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 isc-dhcp-server depends on:
ii debconf [debconf-2.0]1.5.36 Debian configuration management sy
ii debianutils 3.4 Miscellaneous utilities specific t
ii isc-dhcp-common 4.1.1-P1-11 common files used by all the isc-d
ii libc62.11.2-7Embedded GNU C Library: Shared lib
ii lsb-base 3.2-23.1Linux Standard Base 3.2 init scrip
isc-dhcp-server recommends no packages.
Versions of packages isc-dhcp-server suggests:
ii isc-dhcp-server-ldap 4.1.1-P1-11 DHCP server able to use LDAP as ba
-- Configuration Files:
/etc/dhcp/dhcpd.conf changed [not included]
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526115: [fuse-utils] fuse entries in fstab are not mounted automatically
Hi, I also would find this *very* useful; I have opted for the 'mount -a -t fuse' in /etc/init.d/fuse as a workaround and find it works well for me. I'm not using sshfs, however I have just finished off a Perl program so that SSH keys can be put into LDAP (handy when you have lots of UNIX boxes). The alternative would be to patch openssh-server to be 'LDAP aware', this Fuse based approach simply requires AuthorizedKeysFile to be amended in /etc/ssh/sshd_config. Someone else has also written a very similar Fuse LDAP+SSH implementation but in python. It would be handy to be able to automount Fuse filesystems at boot so please consider enabling this functionality. Cheers -- Alexander Clouter .sigmonster says: Be different: conform. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600875: lvm2: 'Should-Start' should depend on mdadm-raid and not mdadm
Package: lvm2
Version: 2.02.39-8
Severity: grave
Tags: squeeze
Justification: renders package unusable
Hi,
Apart from adding the tweak detailed in #568838, an upgrade from lenny to
squeeze causes dpkg to grumble about:
insserv: There is a loop between service checkfs and lvm2 if started
insserv: loop involving service lvm2 at depth 8
insserv: There is a loop between service checkfs and lvm2 if started
insserv: loop involving service mdadm at depth 6
insserv: loop involving service mountall at depth 4
insserv: loop involving service checkfs at depth 3
insserv: loop involving service udev at depth 1
insserv: There is a loop between service mountall and checkfs if started
insserv: loop involving service networking at depth 5
insserv: loop involving service urandom at depth 13
insserv: loop involving service portmap at depth 14
insserv: Max recursions depth 99 reached
insserv: Max recursions depth 99 reached
insserv: Max recursions depth 99 reached
insserv: Max recursions depth 99 reached
insserv: Max recursions depth 99 reached
insserv: exiting now without changing boot order!
update-rc.d: error: insserv rejected the script header
Others have reported similar things for other packages (hibernate: #554905) and
the tweak was to replace mdadm with mdadm-raid; which seems to work for me
although I have no idea if this is the Right Solution(tm).
Marking 'grave' as the #554905 did the same :)
Cheers
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: sparc (sparc64)
Kernel: Linux 2.6.26-2-sparc64-smp (SMP w/1 CPU core)
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 lvm2 depends on:
ii libc62.11.2-6Embedded GNU C Library: Shared lib
ii libdevmapper1.02.1 2:1.02.27-4 The Linux Kernel Device Mapper use
ii libreadline5 5.2-3.1 GNU readline and history libraries
ii lsb-base 3.2-23.1Linux Standard Base 3.2 init scrip
Versions of packages lvm2 recommends:
ii dmsetup 2:1.02.27-4 The Linux Kernel Device Mapper use
lvm2 suggests no packages.
-- Configuration Files:
/etc/init.d/lvm2 changed:
SCRIPTNAME=/etc/init.d/lvm2
. /lib/lsb/init-functions
[ -x /sbin/vgchange ] || exit 0
do_start()
{
modprobe dm-mod 2 /dev/null || :
/sbin/vgscan --ignorelockingfailure --mknodes || :
/sbin/vgchange -aly --ignorelockingfailure || return 2
[ -x /sbin/udevadm ] udevadm settle
}
do_stop()
{
/sbin/vgchange -aln --ignorelockingfailure || return 2
}
case $1 in
start)
log_begin_msg Setting up LVM Volume Groups
do_start
case $? in
0|1) log_end_msg 0 ;;
2) log_end_msg 1 ;;
esac
;;
stop)
log_begin_msg Shutting down LVM Volume Groups
do_stop
case $? in
0|1) log_end_msg 0 ;;
2) log_end_msg 1 ;;
esac
;;
restart|force-reload)
;;
*)
echo Usage: $SCRIPTNAME {start|stop} 2
exit 3
;;
esac
-- 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#600875: Acknowledgement (lvm2: 'Should-Start' should depend on mdadm-raid and not mdadm)
Hi, False alarm, I thought 2.02.39-8 was squeeze... Close this fault report, sorry for wasting your time. Cheers * Debian Bug Tracking System ow...@bugs.debian.org [2010-10-20 20:51:04+]: Thank you for filing a new Bug report with Debian. 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): Debian LVM Team pkg-lvm-maintain...@lists.alioth.debian.org If you wish to submit further information on this problem, please send it to 600...@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. -- Alexander Clouter .sigmonster says: malpractice, n.: The reason surgeons wear masks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568838: Init script finishes before /dev entries created causing boot to fail
Hi, This issue is crucial to be included in squeeze, without the trivial attached patch it really makes using LVM and Linux with LABEL mounts un-usable. Any comment on this at all? Cheers -- Alexander Clouter .sigmonster says: I wouldn't be so paranoid if you weren't all out to get me!! --- /etc/init.d/lvm2.orig 2010-08-24 16:13:57.612045623 +0100 +++ /etc/init.d/lvm2 2010-08-24 16:14:20.831000484 +0100 @@ -22,6 +22,7 @@ modprobe dm-mod 2 /dev/null || : /sbin/vgscan --ignorelockingfailure --mknodes || : /sbin/vgchange -aly --ignorelockingfailure || return 2 + [ -x /sbin/udevadm ] udevadm settle } do_stop()
Bug#592485: mtd-utils: cannot create working ubi images
Package: mtd-utils Version: 20100706-1 Severity: normal When building a UBI image for my OpenRD (as detailed on my website[1]) I found that when mtd-utils updated yesterday to 20100706-1, I could not longer build usable UBI images. Grumbles regarding CRC errors, as you can see below. Cheers [1] http://www.digriz.org.uk/kirkwood mtd-utils 20090606 Uncompressing Linux... done, booting the kernel. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-5-kirkwood (Debian 2.6.32-18) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-2) ) #1 Sat Jul 24 13:37:14 UTC 2010 [0.00] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053177 [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine: Marvell OpenRD Client Board [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [0.00] Kernel command line: console=ttyS0,115200 panic=10 ubi.mtd=root root=ubi0:rootfs rootfstype=ubifs rw [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 256MB 256MB = 512MB total [0.00] Memory: 515200KB available (3508K code, 582K data, 124K init, 0K highmem) [0.00] SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:114 [0.00] Console: colour dummy device 80x30 [snipped] [ 22.077891] NAND device: Manufacturer ID: 0xad, Chip ID: 0xdc (Hynix NAND 512MiB 3,3V 8-bit) [ 22.086410] Scanning device for bad blocks [ 22.242376] Creating 3 MTD partitions on orion_nand: [ 22.247546] 0x-0x0010 : u-boot [ 22.253134] 0x0010-0x0050 : uImage [ 22.258608] 0x0050-0x2000 : root [ 22.264505] UBI: attaching mtd2 to ubi0 [ 22.268357] UBI: physical eraseblock size: 131072 bytes (128 KiB) [ 22.274670] UBI: logical eraseblock size:129024 bytes [ 22.280091] UBI: smallest flash I/O unit:2048 [ 22.284827] UBI: sub-page size: 512 [ 22.289466] UBI: VID header offset: 512 (aligned 512) [ 22.295334] UBI: data offset:2048 [ 22.753002] UBI: volume 0 (rootfs) re-sized from 1301 to 4012 LEBs [ 22.759784] UBI: attached mtd2 to ubi0 [ 22.763574] UBI: MTD device name:root [ 22.768472] UBI: MTD device size:507 MiB [ 22.773470] UBI: number of good PEBs:4056 [ 22.778194] UBI: number of bad PEBs: 0 [ 22.782668] UBI: max. allowed volumes: 128 [ 22.787308] UBI: wear-leveling threshold:4096 [ 22.792042] UBI: number of internal volumes: 1 [ 22.796507] UBI: number of user volumes: 1 [ 22.800971] UBI: available PEBs: 0 [ 22.805444] UBI: total number of reserved PEBs: 4056 [ 22.810433] UBI: number of PEBs reserved for bad PEB handling: 40 [ 22.816563] UBI: max/mean erase counter: 1/0 [ 22.820852] UBI: image sequence number: 0 [ 22.824898] UBI: background thread ubi_bgt0d started, PID 26 [ 22.832302] mice: PS/2 mouse device common for all mice [ 22.842123] rtc-mv rtc-mv: rtc core: registered rtc-mv as rtc0 [ 22.848045] i2c /dev entries driver [ 22.861953] cpuidle: using governor ladder [ 22.866189] cpuidle: using governor menu [ 22.870203] mv_xor_shared mv_xor_shared.0: Marvell shared XOR driver [ 22.891961] mv_xor_shared mv_xor_shared.1: Marvell shared XOR driver [ 22.931977] mv_xor mv_xor.0: Marvell XOR: ( xor cpy ) [ 22.971975] mv_xor mv_xor.1: Marvell XOR: ( xor fill cpy ) [ 23.011974] mv_xor mv_xor.2: Marvell XOR: ( xor cpy ) [ 23.051975] mv_xor mv_xor.3: Marvell XOR: ( xor fill cpy ) [ 23.058742] TCP cubic registered [ 23.062011] NET: Registered protocol family 17 [ 23.082288] registered taskstats version 1 [ 23.087145] rtc-mv rtc-mv: setting system clock to 2010-08-10 10:51:42 UTC (1281437502) [ 23.095205] Initalizing network drop monitor service [ 23.362863] UBIFS: mounted UBI device 0, volume 0, name rootfs [ 23.368908] UBIFS: file system size: 516225024 bytes (504126 KiB, 492 MiB, 4001 LEBs) [ 23.376968] UBIFS: journal size: 9033728 bytes (8822 KiB, 8 MiB, 71 LEBs) [ 23.384326] UBIFS: media format: w4/r0 (latest is w4/r0) [ 23.390183] UBIFS: default compressor: zlib [ 23.394395] UBIFS: reserved for root: 0 bytes (0 KiB) [ 23.443411] VFS: Mounted root (ubifs filesystem) on device 0:13. [ 23.449473] Freeing init memory: 124K INIT: version 2.86 booting Using shell-style concurrent boot in runlevel S. hostname: the specified hostname is invalid Starting the hotplug events dispatcher: udevd. Synthesizing the initial hotplug events...done.
Bug#568838: Init script finishes before /dev entries created causing boot to fail
Hi, I also have been battling with this race condition for the past few years. I have a non-complicated non-RAID (although I do see this on my software RAID boxen too) where /usr, /var and /home are part of an LVM however my root is not. My /etc/fstab typically looks like: LABEL=swap noneswapsw 0 0 LABEL=root / autorelatime 0 1 LABEL=usr /usrautorelatime,nodev 0 2 LABEL=var /varautorelatime,nodev,nosuid0 2 LABEL=home /home autorelatime,nodev,nosuid,noexec 0 2 tmpfs /tmptmpfs nodev,nosuid,noexec,size=32M 0 0 tmpfs /var/tmptmpfs nodev,nosuid,noexec,size=8M 0 0 varrun /var/runtmpfs nodev,nosuid,noexec,size=512k0 0 varlock /var/lock tmpfs nodev,nosuid,noexec,size=96k 0 0 #/dev/hda /media/cdrom0 autoro,user,noauto 0 0 #/dev/hdf /media/cdrom1 autoro,user,noauto 0 0 #/dev/fd0 /media/floppy0 autorw,user,noauto 0 0 When my box boots I can often stumble onto: Setting up LVM Volume Groups Reading all physical volumes. This may take a while... Found volume group lvm-oghma using metadata type lvm2 3 logical volume(s) in volume group lvm-oghma now active . Checking file systems...fsck 1.41.3 (12-Oct-2008) /sbin/fsck.xfs: XFS file system. /sbin/fsck.xfs: XFS file system. /sbin/fsck.xfs: LABEL=home does not exist fsck died with exit status 8 failed (code 8). File system check failed. A log is being saved in /var/log/fsck/checkfs if that location is writable. Please repair the file sy A maintenance shell will now be started. CONTROL-D will terminate this shell and resume system boot. (warning). Give root password for maintenance (or type Control-D to continue): This happens about 80% of the time on some kit, 10% on others. Sometimes it grumbles that LABEL=usr or LABEL=var does not exist instead so it is very obviously a race condition. Looking at what could be going on, /etc/rcS.d/S26lvm2 shoots through without pausing and so udev is in a state where it has not quite created all the softlinks in /dev/disk/by-label in time for when /etc/rcS.d/S30checkfs.sh kicks in. This is trivially fixed by amendment to /etc/init.d/lvm2 that 'StalkR' suggested, and is done by the patch I have attached. Now when my boxes boot I get: Setting up LVM Volume Groups Reading all physical volumes. This may take a while... Found volume group lvm-oghma using metadata type lvm2 3 logical volume(s) in volume group lvm-oghma now active . Checking file systems...fsck 1.41.3 (12-Oct-2008) /sbin/fsck.xfs: XFS file system. /sbin/fsck.xfs: XFS file system. /sbin/fsck.xfs: XFS file system. done. Setting kernel variables (/etc/sysctl.conf)...done. Mounting local filesystems...Filesystem dm-0: Disabling barriers, not supported by the underlying device XFS mounting filesystem dm-0 Filesystem dm-1: Disabling barriers, not supported by the underlying device XFS mounting filesystem dm-1 [snipped] Please include this, get it pushed into 'lenny' too and 'squeeze' as it really is a nasty showstopper that makes booting of servers potentially very unreliable. Cheers -- Alexander Clouter .sigmonster says: What foods these morsels be! --- /etc/init.d/lvm2.orig 2010-04-09 11:37:38.797612918 +0100 +++ /etc/init.d/lvm2 2010-04-09 11:41:54.381369016 +0100 @@ -37,6 +37,7 @@ 0|1) log_end_msg 0 ;; 2) log_end_msg 1 ;; esac + [ -x /sbin/udevadm ] /sbin/udevadm settle ;; stop) log_begin_msg Shutting down LVM Volume Groups
Bug#568838: Init script finishes before /dev entries created causing boot to fail
Hi, * Alexander Clouter a...@digriz.org.uk [2010-04-09 11:48:50+0100]: [snipped] This is trivially fixed by amendment to /etc/init.d/lvm2 that 'StalkR' suggested, and is done by the patch I have attached. Rather the suggestion Anthony DeRobertis made... Cheers -- Alexander Clouter .sigmonster says: Most burning issues generate far more heat than light. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563482: tinyproxy: dies after some time
Package: tinyproxy Version: 1.6.3-3.2 Severity: normal I am pretty much using the defaults in my tinyproxy.conf file however regularlly (after about 24 hours) it seems to get a SIGTERM from nowhere and exits without warning. I compiled debugging symbols in and left gdb strapped to it and found: chipmunk:~# gdb tinyproxy GNU gdb 6.8-debian Copyright (C) 2008 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 sparc-linux-gnu... (gdb) run -d Starting program: /usr/sbin/tinyproxy -d Program received signal SIGTERM, Terminated. 0xf7e97974 in waitpid () from /lib/ultra3/libc.so.6 (gdb) bt #0 0xf7e97974 in waitpid () from /lib/ultra3/libc.so.6 #1 0x0001c69c in takesig (sig=20) at tinyproxy.c:71 #2 signal handler called #3 0xf7e981b0 in nanosleep () from /lib/ultra3/libc.so.6 #4 0xf7e97fd4 in sleep () from /lib/ultra3/libc.so.6 #5 0x00013794 in child_main_loop () at child.c:394 #6 0x0001d32c in main (argc=2, argv=0xffecde34) at tinyproxy.c:395 I caught a similar backtrace before, however the backtrace was identical (minus #0-#2). Cheers -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: sparc (sparc64) Kernel: Linux 2.6.26-2-sparc64-smp (SMP w/1 CPU core) 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 tinyproxy depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii logrotate 3.7.1-5Log rotation utility tinyproxy recommends no packages. tinyproxy suggests no packages. -- 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#559108: dhcp3-server: lease time is zero for 'fresh' failover'd install
Package: dhcp3-server Version: 3.1.3-1 Severity: normal I thought the bug was in the LDAP related patch but after burning two hours of debugging time[1] I found that there is a bug in the failover code. When setting up DHCP servers you might want to deploy the service in a failover'd state[2]. Turns out when you do this the leases the lonesome DHCP server dishes out has a lease lifetime set to zero; causing no end of troubles at the client end with a no expiry time on offered lease. error message. Obviously one solution is do not deploy a reduced failed-over setup, however it's a bug that should be squished and the usual lease times should be pushed out; failing that at lease some warning in the logfiles or maybe in the documentation. Cheers [1] and only then annoyingly deciding to create a 'static' LDAP formed dhcpd.conf file and run the dhcpd-noldap daemon off it [2] much akin to installing an OS on a reduced RAID1 -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-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/bash Versions of packages dhcp3-server depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii debianutils 2.30 Miscellaneous utilities specific t ii dhcp3-common 3.1.3-1common files used by all the dhcp3 ii libc6 2.7-18 GNU C Library: Shared libraries ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip dhcp3-server recommends no packages. Versions of packages dhcp3-server suggests: ii dhcp3-server-ldap 3.1.3-1DHCP server able to use LDAP as ba -- debconf information: * dhcp3-server/new_auth_behavior: dhcp3-server/interfaces: bond0 dhcp3-server/new_next-server_behaviour: dhcp3-server/config_warn: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541109: 'me too' but with wmii
Hi, I get redrawing issues with 244-1 too, downgrading to 243-1 fixes the issue for me. Cheers -- Alexander Clouter .sigmonster says: L'hasard ne favorise que l'esprit prepare. -- L. Pasteur -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540060: error in pgadmin3
Hi, Borked for me also (amd64): a...@berk:~$ uname -a Linux berk 2.6.30.4 #8 SMP Sun Aug 2 18:53:03 BST 2009 x86_64 GNU/Linux a...@berk:~$ dpkg -s libwxgtk2.8-0 | grep Version Version: 2.8.7.1-2 a...@berk:~$ dpkg -s pgadmin3 | grep Version Version: 1.10.0-1 a...@berk:~$ pgadmin3 pgadmin3: relocation error: pgadmin3: symbol _ZN21wxMemoryFSHandlerBase19AddFileWithMimeTypeERK8wxStringPKvmS2_, version WXU_2.8.5 not defined in file libwx_baseu-2.8.so.0 with link time reference Downgrading to libwxbase2.8-0_2.8.7.1-1.1_amd64.deb (testing) 'fixes' the problem for me, but I get no warnings. Let me know what tests you might want me to do :) Cheers -- Alexander Clouter .sigmonster says: You must have an IQ of at least half a million. -- Popeye -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539979: nsd3: unusable on sparc64
Package: nsd3 Version: 3.0.7-3.lenny2 Severity: important On sparc64 the package is pretty much un-usable unless you are handling on a very small number of zones. Recompiling (as suggested online[1]) with '--disable-largefile' makes the package once again usable (still works fine with '-O2' too). What happens when you have more than a handful of zones configured is identical to what is seen under Solaris 9[1] but in addition straight AXFR transfer fail completely too. Aug 4 21:50:14 chipmunk nsd[7825]: xfrd: zone seriouslyfish.com: soa serial 13 update failed restarting transfer (notified zone) Aug 4 21:50:14 chipmunk nsd[7825]: xfrd: zone c1x.net: soa serial 18 update failed restarting transfer (notified zone) Aug 4 21:50:14 chipmunk nsd[7825]: xfrd: zone bplondon.org: soa serial 47 update failed restarting transfer (notified zone) Aug 4 21:50:14 chipmunk nsd[7825]: xfrd: zone lobley.org: soa serial 17 update failed restarting transfer (notified zone) Aug 4 21:50:14 chipmunk nsd[7825]: xfrd: zone soas.ac.uk: soa serial 2009080372 update failed restarting transfer (notified zone) Aug 4 21:50:14 chipmunk nsd[7825]: xfrd: zone audionote.co.uk: soa serial 18 update failed restarting transfer (notified zone) Aug 4 21:50:14 chipmunk nsd[7825]: xfrd: zone avidgamer.co.uk: soa serial 22 update failed restarting transfer (notified zone) Aug 4 21:50:14 chipmunk nsd[7825]: xfrd: zone bittencourt.co.uk: soa serial 15 update failed restarting transfer (notified zone) Aug 4 21:50:14 chipmunk nsd[7825]: xfrd: zone associated-indifference.org.uk: soa serial 2009072902 update failed restarting transfer (notified zone) Aug 4 21:50:14 chipmunk nsd[7825]: xfrd: zone ratty.org.uk: soa serial 0 update failed restarting transfer (notified zone) The real issue seems to be unaligned memory accessing in difffile.c (memmove() causes a SIGBUS) and similar bits elsewhere. The real fix is to make memory accessing aligned on 8 byte boundaries for all 64bit architectures...how you actually do this is a job for upstream[2]. If this gets pushed upstream I'm happy to make myself available for testing patches and debugging as I guess not many people have sparc64 hardware. Either way, if the package could be repackaged for sparc64[3] with '--disable-largefile' enabled that will actually make it functional. Cheers [1] http://open.nlnetlabs.nl/pipermail/nsd-users/2008-April/000762.html [2] even taking the Debian 'sid' package 3.2.2-1 and backporting it shows similar problems only more or less solved when you compile the package with -O0 [3] do we really need large file access for zone files? :) -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: sparc (sparc64) Kernel: Linux 2.6.26-2-sparc64-smp (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages nsd3 depends on: ii adduser 3.110add and remove users and groups ii libc6 2.7-18 GNU C Library: Shared libraries ii libssl0.9.8 0.9.8g-15+lenny1 SSL shared libraries ii lsb-base3.2-20 Linux Standard Base 3.2 init scrip nsd3 recommends no packages. nsd3 suggests no packages. -- 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#539269: ejabberd: ipv6 nameservers in resolv.conf breaks SRV lookups
Hi,
Sorry for the lame response time.
* Konstantin Khomoutov flatw...@users.sourceforge.net [2009-07-31
15:59:28+0400]:
I think the pattern here is that whenever you have nameserver set to
::1, the Erlang inet code fails to parse it from /etc/resolv.conf, and
the Erlang DNS reslover ends up being left without a usable nameserver.
As Sergei Golovan has done the donkey work[1] of ipv6 enabling the
inet_res module in Erlang I think this is solved...in part.
It's probably not worth testing what happens when my /etc/resolv.conf
file is nameserver-less as it's only going to be interpreted by Erlang
as a nameserver less box.
In the next posting[1] in the 'inet6' thread I see:
inet_db:add_ns({A,B,C,D}). %% Name server must be IPv4, there is a fixme
in inet_db.
Looking at inet_db.erl I see Fix IPv6 nameservers all over the place,
so it's a bug in upstream erlang it seems?
Yes, it seems like a bug upstream -- while the inets module itself seems
not to have any problems using ipv6 addresses, the DNS code seems
to lag behind the rest in this respect.
Now we have to figure out whether it is fixed in Erlang R13B which is
already in Squeeze.
From Sergei's posting...I doubt it :)
It is interesting that an A record lookup is made by ejabberd though in
this situation, is there some fallback code being involked? Should it
be?
Yes and no: the fallback to the A-record resolution is specified in the
spec (see the fourth paragraph of [1]), but the spec seems to only talk
about the case of a failed SRV query, in the sense of the query returned
the NXDOMAIN (or a similar) error, as I understand this.
So what's the correct behaviour in the presense of a misconfigured DNS
resolver is not clear to me.
Well it probably should not work at all. I'm confused why A record
queries are being spat out though rather than SRV. You would either
expect this to work or not at all.
Any ideas how to go about working out under what situation
(/etc/resolv.conf content relating, when it cannot be parsed) would
cause ejabberd to make A record lookups rather than SRV ones?
Cheers
[1]
http://www.erlang.org/cgi-bin/ezmlm-cgi?3:mss:446:200908:laipdnhholjemjkgbbgp
--
Alexander Clouter
.sigmonster says: I can resist everything except temptation. -Oscar Wilde
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539269: ejabberd: ipv6 nameservers in resolv.conf breaks SRV lookups
Package: ejabberd Version: 2.0.1-6+lenny1 Severity: normal I recently upgraded our server hardware and started afresh with networking and the lot. The previous box although IPv6 capable, it was pretty focused around just IPv4, this box I get a clean slate with. My /etc/resolv.conf file used to look like: domain wormnet.eu search wormnet.eu nameserver ::1 Migrating from our old ejabberd server to the same version on the new hardware we found most s2s connections, particularly the gBorg ones, were uncontactable. We thought it could be DNS propagation issues, as we slightly borked that up originally, but noticed that the s2s connections to some of the minor Jabber servers (@jabber.earth.li for example) were working fine. I cracked out the packet sniffer and saw TCP SYN packets going our to port 5269 but no replying SYN/ACK's. Strange I thought, then after I while, once I looked at the DNS lookups being made too, I saw that no SRV records were being looked up and it was just making raw A record lookups to make the s2s connection. Eeek. The A record results for gmail.com are very different to the SRV records you get for _xmpp-server._tcp.gmail.com. The 5269/tcp packets were going to the wrong place. This explains why for the smaller Jabber installations it just worked as it so happened that the SRV records come back with identical results to the raw A record lookup. As a result my resolv.conf file now looks like: domain wormnet.eu search wormnet.eu nameserver 127.0.0.1 #nameserver ::1 This fixes the problem, but makes for an IPv6 bug in ejabberd (or possibly even erlang?). Cheers -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: sparc (sparc64) Kernel: Linux 2.6.26-2-sparc64-smp (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ejabberd depends on: ii adduser3.110 add and remove users and groups ii debconf [debconf-2.0] 1.5.24Debian configuration management sy ii erlang-base [erlang-ab 1:12.b.3-dfsg-4 Concurrent, real-time, distributed ii erlang-nox 1:12.b.3-dfsg-4 Concurrent, real-time, distributed ii libc6 2.7-18GNU C Library: Shared libraries ii libexpat1 2.0.1-4 XML parsing C library - runtime li ii libpam0g 1.0.1-5+lenny1Pluggable Authentication Modules l ii libssl0.9.80.9.8g-15+lenny1 SSL shared libraries ii openssl0.9.8g-15+lenny1 Secure Socket Layer (SSL) binary a ii ucf3.0016Update Configuration File: preserv ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime ejabberd recommends no packages. Versions of packages ejabberd suggests: pn libunix-syslog-perl none (no description available) -- debconf information: ejabberd/user: ejabberd/hostname: localhost ejabberd/nomatch: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539302: pymsnt: msn p2p related looping replies
Package: pymsnt Version: 0.11.3-2 Severity: normal In the latest HG tree this was fixed about five months ago, however you will notice without the patch[1] that the pymsnt daemon generates a lot of traffic needlessly and gets stuck in a persistant loop. The bug was first reported on the py-transports[2] mailing list and it would be great if either the package could be updated completely or at least the relevant patch[1] is applied. I would half argue that this patch should be slipped into the next maintainence release of lenny as generating huge amounts of traffic needlessly is only going to annoy Microsoft greatly so is possibly derogating their service. Cheers [1] https://sharesource.org/hg/pymsnt/rev/b704db19896a [2] http://groups.google.com/group/py-transports/browse_thread/thread/19a4f0ec6835abf9# -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: sparc (sparc64) Kernel: Linux 2.6.26-2-sparc64-smp (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages pymsnt depends on: ii adduser 3.110 add and remove users and groups ii python2.5.2-3An interactive high-level object-o ii python-central0.6.8 register and build utility for Pyt ii python-crypto 2.0.1+dfsg1-2.3+lenny0 cryptographic algorithms and proto ii python-openssl [p 0.7-2 Python wrapper around the OpenSSL ii python-pyopenssl 0.7-2 transitional dummy package ii python-twisted8.1.0-4Event-based framework for internet Versions of packages pymsnt recommends: ii python-imaging1.1.6-3Python Imaging Library Versions of packages pymsnt suggests: ii ejabberd 2.0.1-6+lenny1 Distributed, fault-tolerant Jabber -- 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#503313: ejabberd: Please enable support for ipv6in default
Hi, Get's my vote too. I have been running with 'inet6' slipped in all over the config since 'lenny' came our and have had no problems. As proof we are not all mad :) chipmunk:/home/alex# netstat -lnpt | grep beam tcp0 0 127.0.0.1: 0.0.0.0:* LISTEN 16469/beam.smp tcp0 0 0.0.0.0:45402 0.0.0.0:* LISTEN 16469/beam.smp tcp6 0 0 127.0.0.1:5280 :::*LISTEN 16469/beam.smp tcp6 0 0 :::5222 :::*LISTEN 16469/beam.smp tcp6 0 0 127.0.0.1: :::*LISTEN 16469/beam.smp tcp6 0 0 127.0.0.1:5556 :::*LISTEN 16469/beam.smp tcp6 0 0 127.0.0.1:5557 :::*LISTEN 16469/beam.smp tcp6 0 0 :::5269 :::*LISTEN 16469/beam.smp chipmunk:/home/alex# telnet 127.0.0.1 5222 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. blar/ ?xml version='1.0'?stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='3235599923' from='wormnet.eu' xml:lang='en'stream:errorinvalid-namespace xmlns='urn:ietf:params:xml:ns:xmpp-streams'//stream:error/stream:streamConnection closed by foreign host. chipmunk:/home/alex# Try it yourself, you will find it works fine. Cheers -- Alexander Clouter .sigmonster says: An ounce of clear truth is worth a pound of obfuscation. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539269: ejabberd: ipv6 nameservers in resolv.conf breaks SRV lookups
Hi,
* Konstantin Khomoutov flatw...@users.sourceforge.net [2009-07-30
21:40:51+0400]:
A quick followup to my previous post.
First, it's not needed to mess with ejabberd to see what Erlang resolver
configuration it sees -- it suffices to start the standalone Erlang shell
with the right parameters.
Second, this post [1] suggests to tweak the Erlang resolver config --
worth trying out.
How to do this.
[snipped]
This is what I ran:
a...@chipmunk:~$ cat /tmp/run
inet:get_rc().
inet_res:getbyname(_xmpp-server._tcp.gmail.com, srv).
It seems that nameserver ::1 does not work at all, probably an erlang
bug instead?
-- nameserver 127.0.0.1 + !inet6 --
a...@chipmunk:~$ erl -kernel inetrc '/tmp/inetrc' /tmp/run
Eshell V5.6.3 (abort with ^G)
1 [{domain,wormnet.eu},
{nameserver,{127,0,0,1}},
{search,[wormnet.eu]},
{lookup,[native]}]
2 {ok,{hostent,_xmpp-server._tcp.gmail.com,[],srv,5,
[{20,0,5269,xmpp-server2.l.google.com},
{20,0,5269,xmpp-server3.l.google.com},
{20,0,5269,xmpp-server1.l.google.com},
{5,0,5269,xmpp-server.l.google.com},
{20,0,5269,xmpp-server4.l.google.com}]}}
3 *** Terminating erlang (non...@nohost)
--
-- nameserver ::1 + !inet6 --
a...@chipmunk:~$ erl -kernel inetrc '/tmp/inetrc' /tmp/run
Eshell V5.6.3 (abort with ^G)
1 [{domain,wormnet.eu},
{search,[wormnet.eu]},
{lookup,[native]}]
2 {error,timeout}
3 *** Terminating erlang (non...@nohost)
--
-- nameserver 127.0.0.1 + inet6 --
a...@chipmunk:~$ erl -kernel inetrc '/tmp/inetrc' /tmp/run
Eshell V5.6.3 (abort with ^G)
1 [{domain,wormnet.eu},
{nameserver,{127,0,0,1}},
{search,[wormnet.eu]},
{inet6,true},
{lookup,[native]}]
2 {ok,{hostent,_xmpp-server._tcp.gmail.com,[],srv,5,
[{20,0,5269,xmpp-server4.l.google.com},
{20,0,5269,xmpp-server1.l.google.com},
{20,0,5269,xmpp-server2.l.google.com},
{5,0,5269,xmpp-server.l.google.com},
{20,0,5269,xmpp-server3.l.google.com}]}}
3 *** Terminating erlang (non...@nohost)
--
-- nameserver ::1 + inet6 --
a...@chipmunk:~$ erl -kernel inetrc '/tmp/inetrc' /tmp/run
Eshell V5.6.3 (abort with ^G)
1 [{domain,wormnet.eu},
{search,[wormnet.eu]},
{inet6,true},
{lookup,[native]}]
2 {error,timeout}
3 *** Terminating erlang (non...@nohost)
--
In the next posting[1] in the 'inet6' thread I see:
inet_db:add_ns({A,B,C,D}). %% Name server must be IPv4, there is a fixme in
inet_db.
Looking at inet_db.erl I see Fix IPv6 nameservers all over the place,
so it's a bug in upstream erlang it seems?
It is interesting that an A record lookup is made by ejabberd though in
this situation, is there some fallback code being involked? Should it
be?
Cheers
[1] http://erlang.org/pipermail/erlang-questions/2008-April/034254.html
--
Alexander Clouter
.sigmonster says: Tuesday is the Wednesday of the rest of your life.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535097: /usr/bin/wine must be adapted to ia32-libs transition
Hi, Part of the issue here (if I'm not mistaken) is that wine for amd64 depends on ia32-libxxf86vm1 and ia32-libsm6, otherwise it will not even load. Grumbles along the lines of: err:module:load_builtin_dll fail..., 149err:module:load_builtin_dll failed to load .so lib for builtin Lwinex11.drv: libSM.so.6: cannot open shared object file: No such file or directory Cheers -- Alexander Clouter .sigmonster says: The world is no nursery. -- Sigmund Freud -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515214: Bug#523960: equivs is surely not the solution to this problem. Recommends: is.
Hi, Just following up to David Nusinow comment (not directed at him but this seems to be where the main defencive stance on this seems to be): X.org not only runs on fat workstations but also on embedded device where you as less abstraction layers and diskspace used as possible. Debian always claims to be the _universal_ operating system and it should also package X.org to be universal. Debian is not (a desktop focussed) Ubuntu. Note that this is the direction that upstream is heading in. The design is conceptually quite simple. The X server asks the system, in this case via hal, to enumerate input devices are present and gets them enumerated back. And for the platforms where hal does not exist? Xorg is not just available for Linux. I'm all for making it easier for refugee's from other OS's to get onto the Linux bandwagon, but the moment you start removing choice from those already on the bandwagon, something is going seriously wrong. This is greater than some the Debian 'policy' document, we are stepping onto point four in Debian's *social* contract. Maybe that's just my opinion, I read that bit in the social contract as 'choice', others might read it differently. The argument regarding get used to dependencies...it's the way of the world is, that's fine *when* the functionality (such as PCI scanning) might have been stripped from Xorg altogether and it simply will not compile without it. The reality is that the Xorg folk know HAL is not available on all the platforms Xorg runs on and so it's a compile time option. If you can show us all that HAL is available on *all* platforms where Xorg runs and that the Xorg folk are about to make HAL a dependency[1], then you probably would get no grief from making Debian match things up (hell it work have a non-functioning Xorg which is not an option). Currently though the situation is quite different and it turns out that even with this automagical detection support compiled in, it can be disabled at runtime and people can continue to *choose* to use their handcrafted xorg.conf files. So why are we forcing people to use stuff that is un-needed? Doing this would be no different to forcing people to install Java and Flash when Iceweasel is installed because hey everyone wants to use YouTube. :-/ Remember, with your position you are also harming the embedded and low spec'ed machine folk. I do not think people with small amounts of NAND flash for storage space will appreciate having a lot of unnecessary guff installed[2]. Debian runs on 11 different architectures, life's not a x86 with 2GB of RAM. I left that 'other' OS eight years ago exactly for these reasons as I did not like have the decision making process made by someone else. If Xorg decide to make HAL an actual dependency, then we will all deal with that ourselves (probably in the form of a witchhunt and burning down to xorg-hq)...until then there really is no reason why Debian should turn to the dark side. Hell just think about the hammering of the mirrors for all the extra package downloading you are causing... Some people pay for bandwidth. I (and it seems others too) can see so many arguments against making HAL a dependency but only see one in favour of it (and it's not like we are turning off any functionality in doing this). I think you will find that the main issue people have is that we think HAL/DBUS (and even what acpid has turned into) is fundamentally broken[3]. We have chosen to avoid it as Debian has enabled us to have this choice...that's why we use Debian. Cheers [1] there are already signs that other distros are getting fed up of the ghastliness that HAL has turned into. What are you going to do when the world starts getting a 'hard on' for DeviceKit instead? [2] http://www.embeddedarm.com/products/board-detail.php?product=TS-TPC-7390 ARM + 512MB NAND + LCD screen, and you want HAL on it? [3] we are too lazy to come up with alternatives, hell this might push us over the edge -- Alexander Clouter .sigmonster says: You will triumph over your enemy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515214: Please do not depend on HAL, or provide an alternative xserver-xorg package
Hi, I wanted to add my 'vote' to this, adding HAL is a truly horrible horrible thing to do. For a lot of people HAL is a 'nasty' side of Linux userland and so far by using Debian, up until now, we have been able to avoid it. HAL is one of those things that show that although the Linux kernel is becoming really shiny, the userspace world is heading in a really ugly direction. Please don't force the *whole* Debian community to be part of this. Cheers -- Alexander Clouter .sigmonster says: Thyme's Law: Everything goes wrong at once. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508151: Bug#514624: Bug#508151: Bug#514624: linux-image for sparc64 sungem problems
Hi, * dann frazier da...@dannf.org [2009-02-09 15:58:28-0700]: I'm transferring a build w/ the fix backported to the lenny kernel to here: http://people.debian.org/~dannf/bugs/514624/ If one or both of you could verify that it resolves the issue for you as well, it'd be appreciated. Tested and seems to work for me. Cheers -- Alexander Clouter .sigmonster says: Sometimes the best medicine is to stop taking something. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#236635: nc6 doesn't work with multicast addresses in UDP mode
Ref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=236635
Hi,
I cobbled a patch together this afternoon that seems to do the job.
Let me know how you get along with it. Not fully tested with IPv6, but
it seems to do the right things (from an 'strace').
Cheers
--
Alexander Clouter
.sigmonster says: May not be combined with other discounts.
diff -u -r nc6-1.0.orig/docs/nc6.1.in nc6-1.0/docs/nc6.1.in
--- nc6-1.0.orig/docs/nc6.1.in 2005-08-18 05:56:12.0 +0100
+++ nc6-1.0/docs/nc6.1.in 2009-03-11 16:20:55.838644858 +
@@ -117,6 +117,11 @@
.I \--no-reuseaddr
Disables the SO_REUSEADDR socket option (this is only useful in listen mode).
.TP 13
+.I \-T, \--ttl=TTL
+Set's the IP TTL of the packets leaving (this is only useful in connect mode).
+This is mainly useful for multicast, otherwise packets will often leave with
+the OS default of 1, making it rarely useful.
+.TP 13
.I \--nru=BYTES
Set the miNimum Receive Unit for the remote endpoint (network receives). Note
that this does not mean that every network read will get the specified number
diff -u -r nc6-1.0.orig/src/afindep.c nc6-1.0/src/afindep.c
--- nc6-1.0.orig/src/afindep.c 2006-01-19 22:46:23.0 +
+++ nc6-1.0/src/afindep.c 2009-03-11 16:15:54.746112636 +
@@ -64,6 +64,9 @@
struct addrinfo *res = NULL, *ptr;
bool connect_attempted = false;
char name_buf[AI_STR_SIZE];
+ const connection_attributes_t *attrs =
+ *((const connection_attributes_t **)hdata);
+ int on;
/* make sure arguments are valid and preconditions are respected */
assert(hints != NULL);
@@ -90,6 +93,23 @@
/* only accept results we can handle */
if (skip_address(ptr) == true) continue;
+ if (ptr-ai_socktype == SOCK_STREAM) {
+ if (ptr-ai_family == PF_INET) {
+if (IN_MULTICAST(ntohl(((struct sockaddr_in *)(ptr-ai_addr))-sin_addr.s_addr))) {
+ warning(socket type STREAM and multicast bad, udp only!);
+ return -1;
+}
+ }
+#ifdef ENABLE_IPV6
+ else if (ptr-ai_family == PF_INET6) {
+if (IN6_IS_ADDR_MULTICAST(((struct sockaddr_in6 *)(ptr-ai_addr))-sin6_addr)) {
+ warning(socket type STREAM and multicast bad, udp only!);
+ return -1;
+}
+ }
+#endif
+ }
+
/* we are going to try to connect to this address */
connect_attempted = true;
@@ -182,6 +202,28 @@
freeaddrinfo(src_res);
}
+ /* setup the ttl */
+ if ((on = ca_ttl(attrs)) -1) {
+ if ( ptr-ai_family == PF_INET ) {
+if (IN_MULTICAST(ntohl(((struct sockaddr_in *)(ptr-ai_addr))-sin_addr.s_addr))) {
+ setsockopt(fd, SOL_IP, IP_MULTICAST_TTL, on, sizeof(on));
+}
+else {
+ setsockopt(fd, SOL_IP, IP_TTL, on, sizeof(on));
+}
+ }
+#ifdef ENABLE_IPV6
+ else if ( ptr-ai_family == PF_INET6 ) {
+if (IN6_IS_ADDR_MULTICAST(((struct sockaddr_in6 *)(ptr-ai_addr))-sin6_addr)) {
+ setsockopt(fd, SOL_IPV6, IPV6_MULTICAST_HOPS, on, sizeof(on));
+}
+else {
+ setsockopt(fd, SOL_IPV6, IPV6_UNICAST_HOPS, on, sizeof(on));
+}
+ }
+#endif
+ }
+
/* attempt the connection */
err = connect_with_timeout(fd,
ptr-ai_addr, ptr-ai_addrlen, timeout);
@@ -250,7 +292,10 @@
{
int nfd, i, fd, err, maxfd = -1;
struct addrinfo *res = NULL, *ptr;
+ int off = 0;
+ struct ip_mreq mreq;
#ifdef ENABLE_IPV6
+ struct ipv6_mreq mreq6;
bool set_ipv6_only = false;
bool bound_ipv6_any = false;
#endif
@@ -327,7 +372,24 @@
/* only accept results we can handle */
if (skip_address(ptr) == true) continue;
-
+
+ if (ptr-ai_socktype == SOCK_STREAM) {
+ if (ptr-ai_family == PF_INET) {
+if (IN_MULTICAST(ntohl(((struct sockaddr_in *)(ptr-ai_addr))-sin_addr.s_addr))) {
+ warning(socket type STREAM and multicast bad, udp only!);
+ return -1;
+}
+ }
+#ifdef ENABLE_IPV6
+ else if (ptr-ai_family == PF_INET6) {
+if (IN6_IS_ADDR_MULTICAST(((struct sockaddr_in6 *)(ptr-ai_addr))-sin6_addr)) {
+ warning(socket type STREAM and multicast bad, udp only!);
+ return -1;
+}
+ }
+#endif
+ }
+
/* create the socket */
fd = socket(ptr-ai_family, ptr-ai_socktype, ptr-ai_protocol);
if (fd 0) {
@@ -414,6 +476,27 @@
FD_SET(fd, accept_fdset);
maxfd = MAX(maxfd, fd);
nfd++;
+
+ if (ptr-ai_family == PF_INET) {
+ if (IN_MULTICAST(ntohl(((struct sockaddr_in *)(ptr-ai_addr))-sin_addr.s_addr))) {
+memset(mreq, 0, sizeof(mreq));
+mreq.imr_multiaddr = ((struct sockaddr_in *)(ptr-ai_addr))-sin_addr;
+mreq.imr_interface.s_addr = INADDR_ANY;
+setsockopt(fd, SOL_IP, IP_ADD_MEMBERSHIP, mreq, sizeof(mreq));
+setsockopt(fd, SOL_IP, IP_MULTICAST_LOOP, off, sizeof(off));
+ }
+ }
+#ifdef ENABLE_IPV6
+ else if (ptr-ai_family == PF_INET6) {
+ if (IN6_IS_ADDR_MULTICAST(((struct sockaddr_in6 *)(ptr-ai_addr))-sin6_addr)) {
+memset(mreq6, 0, sizeof(mreq6));
+mreq6.ipv6mr_multiaddr = ((struct sockaddr_in6 *)(ptr-ai_addr))-sin6_addr;
+mreq6.ipv6mr_interface = 0;
+setsockopt(fd, SOL_IPV6, IPV6_JOIN_GROUP, mreq6, sizeof(mreq));
+setsockopt(fd
Bug#514624: linux-image for sparc64 sungem problems
Package: linux-image-2.6.24-etchnhalf.1-sparc64 Version: 2.6.24+13~etchnhalf.1 For some time, even since 2.6.18 we have had problems with the sungem NIC driver on our Sun Netra T1 AC200[1] where the machine is prone to locking up. Then recently this month on the LKML someone posted[2] that they too were having problems and submitted a fix. It would probably be worth backport this patch to the lenny 2.6.26 kernel before general release; the patch is trivial and David Miller seems happy with it too. It would save a lot of pain for some sparc64 users out there. Cheers [1] http://sunsolve.sun.com/handbook_pub/validateUser.do?target=Systems/Netra_T1_AC200/Netra_T1_AC200 [2] http://marc.info/?t=123393015500020r=1w=2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503116: pimd: rp_address does not work for big endian hosts
Package: pimd Severity: important Tags: patch For a few years I have noticed that on my sparc boxes I have not been able to get pimd to work yet if I use the same pimd.conf on an x86 box it bursts into life...very obviously some endian magic in there. Today I figured out what it is and attached a patch that has been tested under sparc64 and an x86 box and it seems to function fine on both. The issue is that the 'hack' to add a static RP address (aka 'rp_address') never considered the local endian; it was hard coded for little endian hosts. At a glance it has been with us since it's incarnation back in 2002[1]. The patch attached fixes it to how God Intended(tm) :) May all big-endian sysadmin's rejoice! Cheers Alex [1] https://listes.renater.fr/sympa/arc/m6bone/2002-09/msg00097.html -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: sparc (sparc64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.24-etchnhalf.1-sparc64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) --- pimd-2.1.0-alpha29.17/config.c.orig 2008-10-22 18:03:39.919639808 +0100 +++ pimd-2.1.0-alpha29.17/config.c 2008-10-22 18:03:44.007621565 +0100 @@ -810,8 +810,8 @@ rph=malloc(sizeof(*rph)); rph-address=local; - rph-group=224; - rph-mask=240; + rph-group=htonl(224 24); + rph-mask=htonl(240 24); rph-next=g_rp_hold; g_rp_hold=rph;
Bug#497125: acpi-support: hibernatebtn.sh is missing 'policy-funcs' include
Package: acpi-support Version: 0.109-6 Severity: normal sleepbth.sh is okay, however hibernatebtn.sh is missing after the test for 'power-funcs': = . /usr/share/acpi-support/policy-funcs = The result is that '`CheckPolicy`' fails altogether and that probably makes one of those ghastly X PM daemons left out in the dark. I only stumbled upon this whilst trying to work out why hibernate stopped working after updating from etch to lenny[1]. Easily seen when you run acpid on it's own with the '-d' you notice: = BEGIN HANDLER MESSAGES /etc/acpi/hibernatebtn.sh: line 6: CheckPolicy: command not found /etc/acpi/hibernatebtn.sh: line 6: [: =: unary operator expected = Cheers Alex [1] seems the dbus method is not working for me...something else I need to prod :-/ -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages acpi-support depends on: ii acpi-support-base 0.109-6scripts for handling base ACPI eve ii acpid 1.0.6-10 Utilities for using ACPI power man ii dmidecode 2.9-1 Dump Desktop Management Interface ii finger0.17-12user information lookup program ii hdparm8.9-1 tune hard disk parameters for high ii laptop-detect 0.13.6 attempt to detect a laptop ii libc6 2.7-13 GNU C Library: Shared libraries ii lsb-base 3.2-19 Linux Standard Base 3.2 init scrip ii powermgmt-base1.30 Common utils and configs for power ii vbetool 1.0-3 run real-mode video BIOS code to a ii x11-xserver-utils 7.3+5 X server utilities Versions of packages acpi-support recommends: ii dbus 1.2.1-3simple interprocess messaging syst ii hal 0.5.11-3 Hardware Abstraction Layer pn nvclock none (no description available) ii pm-utils 1.1.2.3-1 utilities and scripts for power ma ii radeontool1.5-5 utility to control ATI Radeon back ii toshset 1.73-2 Access much of the Toshiba laptop Versions of packages acpi-support suggests: ii laptop-mode-tools 1.45-1 Scripts to spin down hard drive an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496879: hal: more usb lack-of-mountability action
Package: hal Version: 0.5.11-2 Severity: important Although very similar to #486496 this one is because hal no longer honours groups added to the user by pam_group. I upgraded a machine from etch to lenny and no can no longer mount USB disks and whatnot via thunar; identical error that Mr #486496 was getting. So this got me thinking, in my /etc/security/group.conf file I have: === gdm;:*;*;Al-2400;audio,floppy,video,cdrom,plugdev,powerdev === And it does truely work, when I log in and type 'id' into an xterm I am a member of the plugdev group. With etch this was enough, however with hal in lenny this is not the case and it seems to only care about whatever lurks in /etc/group :( When I manually add my user to /etc/group I can mount and umount to my hearts content. If course running pmount from an xterm with the pam_group method works, but then I'm in an xterm. I'm guessing hal is evaluating the user from outside the context of pam and just as a raw user...or something? Cheers -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages hal depends on: ii adduser 3.110 add and remove users and groups ii dbus 1.2.1-3simple interprocess messaging syst ii hal-info 20080508+git20080601-1 Hardware Abstraction Layer - fdi f ii libc6 2.7-13 GNU C Library: Shared libraries ii libdbus-1-3 1.2.1-3simple interprocess messaging syst ii libdbus-glib-1-2 0.76-1 simple interprocess messaging syst ii libexpat1 2.0.1-4XML parsing C library - runtime li ii libgcc1 1:4.3.1-2 GCC support library ii libglib2.0-0 2.16.4-2 The GLib library of C routines ii libhal-storage1 0.5.11-2 Hardware Abstraction Layer - share ii libhal1 0.5.11-2 Hardware Abstraction Layer - share ii libsmbios10.13.13-1 Provide access to (SM)BIOS informa ii libstdc++64.3.1-2The GNU Standard C++ Library v3 ii libusb-0.1-4 2:0.1.12-12userspace USB programming library ii libvolume-id0 0.125-5libvolume_id shared library ii lsb-base 3.2-19 Linux Standard Base 3.2 init scrip ii mount 2.13.1.1-1 Tools for mounting and manipulatin ii pciutils 1:3.0.0-4 Linux PCI Utilities ii pm-utils 1.1.2.3-1 utilities and scripts for power ma ii udev 0.125-5/dev/ and hotplug management daemo ii usbutils 0.73-8 Linux USB utilities Versions of packages hal recommends: ii eject 2.1.5+deb1-1 ejects CDs and operates CD-Changer pn libsmbios-bin none (no description available) Versions of packages hal suggests: pn gnome-device-manager none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496879: [Pkg-utopia-maintainers] Bug#496879: hal: more usb lack-of-mountability action
Hi, Michael Biebl [EMAIL PROTECTED] [20080828 10:17:18 +0200]: Alexander Clouter schrieb: Package: hal Version: 0.5.11-2 Severity: important Although very similar to #486496 this one is because hal no longer honours groups added to the user by pam_group. I upgraded a machine from etch to lenny and no can no longer mount USB disks and whatnot via thunar; identical error that Mr #486496 was getting. So this got me thinking, in my /etc/security/group.conf file I have: [...] This bug is identical to #496829. Are you the same person as [EMAIL PROTECTED] Same person (more or less), however [EMAIL PROTECTED] is unroutable and invalid, as we never received a response I assumed a bug was not opened. My fault for not checking. Might be worth proding the debian bug submission bot to not accept mail from unroutable addresses? Although of course the problem at source is me being a peanut :) Do you not agree with the rationale I gave in #496829 or why did you open another, exact same bug against hal? Perfectly valid reasoning, cheers for the speedy replace. Sorry again for the time wasting. Alex -- / A snake lurks in the grass.\ || \ -- Publius Vergilius Maro (Virgil) / \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || signature.asc Description: Digital signature
Bug#492709: hwclock.sh: support for RTC wakeup alarm
Package: util-linux Version: 2.13.1.1-1 Severity: normal Hi, Whilst trying to get our Dull server to wakeup at a specific time I had a go at playing around with the ACPI RTC wakeup alarm[1] functionality of the system. Apart from being disappointed at Dull using sub-standard parts and only giving me an upper limit of 24 hours into the future for a wakeup event I found that the Debian hwclock.sh inadvertantly nukes this ability on shutdown[2]. I have attached a patch that tests if the RTC alarm has been set to a time in the future and if so restore it after the --systohc command is executed; thus letting this handy but not often used functionality work. Hopefully it's considered sane :) Cheers Alex [1] http://acpi.sourceforge.net/documentation/alarm.html [2] http://www.mythtv.org/wiki/index.php/ACPI_Wakeup#Disable_hwclock_updates -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages util-linux depends on: ii libc6 2.7-12GNU C Library: Shared libraries ii libncurses55.6+20080713-1shared libraries for terminal hand ii libselinux12.0.65-2 SELinux shared libraries ii libslang2 2.1.3-3 The S-Lang programming library - r ii libuuid1 1.41.0-3 universally unique id library ii lsb-base 3.2-15Linux Standard Base 3.2 init scrip ii tzdata 2008c-1 time zone and daylight-saving time ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime util-linux recommends no packages. Versions of packages util-linux suggests: ii console-tools1:0.2.3dbs-65.1 Linux console and font utilities ii dosfstools 2.11-6 utilities for making and checking ii util-linux-locales 2.13.1.1-1 Locales files for util-linux -- no debconf information --- /etc/init.d/hwclock.sh.orig 2007-12-22 13:47:04.0 + +++ /etc/init.d/hwclock.sh 2008-07-28 11:37:21.533178944 +0100 @@ -96,6 +96,20 @@ # WARNING: If you disable this, any changes to the system # clock will not be carried across reboots. # + # We also check to see if the RTC Alarm has been set and restore + # it if it's applicable (set to a time in the future) + # FIXME: rtc0 = rtcN? + # + for RTCALARMDEV in /sys/class/rtc/rtc0/wakealarm /proc/acpi/alarm; do + if [ -e $RTCALARMDEV ]; then + RTCWAKETIME=`cat $RTCALARMDEV` + if [ `date -d $RTCWAKETIME +%s` -le `date +%s` ]; then + RTCWAKETIME= + fi + + break + fi + done if [ $HWCLOCKACCESS != no ]; then log_action_msg Saving the system clock. if [ $GMT = -u ]; then @@ -106,6 +120,10 @@ else verbose_log_action_msg Not saving System Clock fi + if [ $RTCWAKETIME != ]; then + log_action_msg Priming RTC Alarm for $RTCWAKETIME + echo $RTCWAKETIME $RTCALARMDEV + fi ;; show) if [ $HWCLOCKACCESS != no ]; then
Bug#492709: hwclock.sh: support for RTC wakeup alarm
Hi, Alexander Clouter [EMAIL PROTECTED] [20080728 11:45:33 +0100]: Hi, Whilst trying to get our Dull server to wakeup at a specific time I had a go at playing around with the ACPI RTC wakeup alarm[1] functionality of the system. Apart from being disappointed at Dull using sub-standard parts and only giving me an upper limit of 24 hours into the future for a wakeup event I found that the Debian hwclock.sh inadvertantly nukes this ability on shutdown[2]. This might actually be a bad idea for a patch on systems that only support 24 hour upper limit wakeups. There is a rather common side effect that it will look like the wakeup timer has been set when in fact it has not. I'm looking into the new RTC framework for a better solution. Cheers Alex I have attached a patch that tests if the RTC alarm has been set to a time in the future and if so restore it after the --systohc command is executed; thus letting this handy but not often used functionality work. Hopefully it's considered sane :) Cheers Alex [1] http://acpi.sourceforge.net/documentation/alarm.html [2] http://www.mythtv.org/wiki/index.php/ACPI_Wakeup#Disable_hwclock_updates -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages util-linux depends on: ii libc6 2.7-12GNU C Library: Shared libraries ii libncurses55.6+20080713-1shared libraries for terminal hand ii libselinux12.0.65-2 SELinux shared libraries ii libslang2 2.1.3-3 The S-Lang programming library - r ii libuuid1 1.41.0-3 universally unique id library ii lsb-base 3.2-15Linux Standard Base 3.2 init scrip ii tzdata 2008c-1 time zone and daylight-saving time ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime util-linux recommends no packages. Versions of packages util-linux suggests: ii console-tools1:0.2.3dbs-65.1 Linux console and font utilities ii dosfstools 2.11-6 utilities for making and checking ii util-linux-locales 2.13.1.1-1 Locales files for util-linux -- no debconf information --- /etc/init.d/hwclock.sh.orig 2007-12-22 13:47:04.0 + +++ /etc/init.d/hwclock.sh2008-07-28 11:37:21.533178944 +0100 @@ -96,6 +96,20 @@ # WARNING: If you disable this, any changes to the system # clock will not be carried across reboots. # + # We also check to see if the RTC Alarm has been set and restore + # it if it's applicable (set to a time in the future) + # FIXME: rtc0 = rtcN? + # + for RTCALARMDEV in /sys/class/rtc/rtc0/wakealarm /proc/acpi/alarm; do + if [ -e $RTCALARMDEV ]; then + RTCWAKETIME=`cat $RTCALARMDEV` + if [ `date -d $RTCWAKETIME +%s` -le `date +%s` ]; then + RTCWAKETIME= + fi + + break + fi + done if [ $HWCLOCKACCESS != no ]; then log_action_msg Saving the system clock. if [ $GMT = -u ]; then @@ -106,6 +120,10 @@ else verbose_log_action_msg Not saving System Clock fi + if [ $RTCWAKETIME != ]; then + log_action_msg Priming RTC Alarm for $RTCWAKETIME + echo $RTCWAKETIME $RTCALARMDEV + fi ;; show) if [ $HWCLOCKACCESS != no ]; then -- __ / Well begun is half done. \ | | \ -- Aristotle / -- \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491828: postfix-policyd-spf-python: error in documentation
Package: postfix-policyd-spf-python Version: 0.6-2~bpo40+1 Severity: minor Hi, /usr/share/doc/postfix-policyd-spf-python/README.Debian states in the documentation that you need to add the following line to /etc/postfix/master.conf: = policyd-spf unix - n n - 0 spawn user=nobody argv=/usr/bin/python /usr/bin/policyd-spf /etc/python-policyd-spf/policyd-spf.conf = Seems in fact that the line should actually be: = policyd-spf unix - n n - 0 spawn user=nobody argv=/usr/bin/python /usr/bin/policyd-spf /etc/postfix-policyd-spf-python/policyd-spf.conf = I'm guessing this is linked to the Debian-esque renaming of the package from python-policyd-spf to postfix-policyd-spf-python? Either way it's a minor stumbling block. Cheers Alex -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: sparc (sparc64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.24.2 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages postfix-policyd-spf-python depends on: ii postfix 2.3.8-2 A high-performance mail transport ii python 2.4.4-2 An interactive high-level object-o ii python-spf 2.0.4-2~bpo40+1 sender policy framework (SPF) modu ii python-support 0.5.6 automated rebuilding support for p postfix-policyd-spf-python recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487692: gromit: is not 'wakeup' (aka powertop) friendly
Package: gromit
Version: 20041213-4
Severity: wishlist
Hi,
I use gromit on my TabletPC and it's nice except for that whilst looking at
powertop I can see that it wakeups the CPU 50 times a second regardless of
whether it is doing something or not.
Digging around in the code I found a timeout poll of 20ms which the attached
patch only activates when gromit is actually being used. When it is not
being used then the timeout is removed and powertop looks much healthier.
The patch has had about five minutes testing so you might want to give it a
whirl yourself for a bit before passing it out to the great 'unclean' :)
I'll get back to you if I find any bugs and do let me know if I have really
messed something up.
Cheers
Alex
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-rc6 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages gromit depends on:
ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit
ii libc6 2.7-12 GNU C Library: Shared libraries
ii libglib2.0-0 2.16.3-2 The GLib library of C routines
ii libgtk2.0-0 2.12.10-2 The GTK+ graphical user interface
ii libpango1.0-0 1.20.2-2 Layout and rendering of internatio
ii libx11-6 2:1.1.4-2 X11 client-side library
gromit recommends no packages.
-- no debconf information
--- gromit.c.orig 2008-06-23 16:55:57.627731276 +0100
+++ gromit.c 2008-06-23 16:56:05.279731391 +0100
@@ -404,29 +404,6 @@
}
-void
-gromit_toggle_grab (GromitData *data)
-{
- if (data-hard_grab)
-gromit_release_grab (data);
- else
-gromit_acquire_grab (data);
-}
-
-
-void
-gromit_clear_screen (GromitData *data)
-{
- gdk_gc_set_foreground (data-shape_gc, data-transparent);
- gdk_draw_rectangle (data-shape, data-shape_gc, 1,
- 0, 0, data-width, data-height);
- gtk_widget_shape_combine_mask (data-win, data-shape, 0,0);
- if (!data-hard_grab)
-gromit_hide_window (data);
- data-painted = 0;
-}
-
-
gint
reshape (gpointer user_data)
{
@@ -450,6 +427,32 @@
void
+gromit_toggle_grab (GromitData *data)
+{
+ if (data-hard_grab) {
+gtk_timeout_remove (data-timeout_id);
+gromit_release_grab (data);
+ } else {
+data-timeout_id = gtk_timeout_add (20, reshape, data);
+gromit_acquire_grab (data);
+ }
+}
+
+
+void
+gromit_clear_screen (GromitData *data)
+{
+ gdk_gc_set_foreground (data-shape_gc, data-transparent);
+ gdk_draw_rectangle (data-shape, data-shape_gc, 1,
+ 0, 0, data-width, data-height);
+ gtk_widget_shape_combine_mask (data-win, data-shape, 0,0);
+ if (!data-hard_grab)
+gromit_hide_window (data);
+ data-painted = 0;
+}
+
+
+void
gromit_select_tool (GromitData *data, GdkDevice *device, guint state)
{
guint buttons = 0, modifier = 0, len = 0;
@@ -1430,7 +1433,7 @@
data-painted = 0;
gromit_hide_window (data);
- data-timeout_id = gtk_timeout_add (20, reshape, data);
+ /* data-timeout_id = gtk_timeout_add (20, reshape, data); */
data-coordlist = NULL;
data-modified = 0;
Bug#415228: freeradius: Stops answering locking up with 100% CPU usage
Hi, Finally got it with a GDB. I have a debugging symbols corefile if anyone is interested...or should I report this upstream. I am running 1.1.7-1. Cheers Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461214: building libldap2 also depends on 'g++' too
Hi, Torsten Landschoff [EMAIL PROTECTED] [20080117 23:15:23 +0100]: [snipped] Please consider using the debuild command from the devscripts package. It uses dpkg-buildpackage internally, but first checks if the build dependencies are satisfied. The libldap2 sources do not build-depend on g++, because the build-essential package depends on it which should be installed any time when building a Debian package. See section 4.2 of the debian policy here: http://www.debian.org/doc/debian-policy/ch-source.html Can't argue with that :) Do close this 'bug' report then. Cheers Alex P.S. *cough* please apply patch in #262539 and #364614 *cough* -- ___ / A soft answer turneth away wrath; but \ | grievous words stir up anger. | | | \ -- Proverbs 15:1 / --- \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || signature.asc Description: Digital signature
Bug#461214: building libldap2 also depends on 'g++' too
Package: libldap2 Version: 2.1.30.dfsg-13.5 Severity: serious Justification: no longer builds from source Hi, Got myself a new laptop and went about compiling libldap2 from scratch[1] and found the following error hitting me when compiling: === [EMAIL PROTECTED]:/usr/src/deb-src/libldap2/openldap2-2.1.30.dfsg$ dpkg-buildpackage -us -uc -rfakeroot [snipped] checking for cxx... no checking for cc++... no checking for cl... no checking for FCC... no checking for KCC... no checking for RCC... no checking for xlC_r... no checking for xlC... no checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... no checking how to run the C++ preprocessor... /lib/cpp configure: error: C++ preprocessor /lib/cpp fails sanity check See `config.log' for more details. make: *** [/usr/src/deb-src/libldap2/openldap2-2.1.30.dfsg/debian/build/Makefile] Error 1 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 [EMAIL PROTECTED]:/usr/src/deb-src/libldap2/openldap2-2.1.30.dfsg$ === The config.log reported that it could not find 'cc1plus' (provided by 'g++'). Once installed it compiles with no problems. Cheers Alex [1] I am also affected by bugs #262539 and #364614 and have to apply the patch they describe otherwise I suffer long hangs -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-rc7 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libldap2 depends on: ii libc62.7-6 GNU C Library: Shared libraries ii libgnutls13 2.0.4-1 the GNU TLS library - runtime libr ii libsasl2-2 2.1.22.dfsg1-17 Cyrus SASL - authentication abstra libldap2 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455907: libnss-ldap update 'nukes' host/uri parameter
Package: libnss-ldap Version: 251-7.5etch1 Followup-For: Bug #455907 My co-location box uses ldap for user accounts and openssh has been patched to yank SSH keys from LDAP too. After updating[1] it blatted my old 'uri' parameter into the 'host' variable...which does not accept ldapi:// entries. The result, much login death :-/ Attached is an example of what happens for me. Could you please please remember to try to squeeze this update in next time round (although it looks like the security team jumped out and did this?) so that it does not kill us 'etch' users incase libnss-ldap has to be updated for security reasons again? Cheers Alex [1] I recall this problem last time I updating libnss-ldap (in a dist-upgrade to 'etch') and looking through the current bug reports all the following seem related (all fixed I'm guess by #408440[2]): * 375069 * 391785 * 411923 * 415576 * 416664 * 419519 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408440 -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: sparc (sparc64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.21.5-grsec Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages libnss-ldap depends on: ii debconf [debconf-2.0] 1.5.11Debian configuration management sy ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries ii libkrb53 1.4.4-7etch4 MIT Kerberos runtime libraries ii libldap2 2.1.30-13.3 OpenLDAP libraries Versions of packages libnss-ldap recommends: ii libpam-ldap180-1.7 Pluggable Authentication Module al ii nscd 2.3.6.ds1-13etch2 GNU C Library: Name Service Cache -- debconf information: * libnss-ldap/dblogin: true libnss-ldap/override: true * shared/ldapns/base-dn: dc=wormnet,dc=eu * shared/ldapns/ldap-server: ldapi://%2fvar%2frun%2fldapi/ * libnss-ldap/confperm: true * libnss-ldap/rootbinddn: cn=admin,dc=wormnet,dc=eu * shared/ldapns/ldap_version: 3 * libnss-ldap/binddn: cn=proxyuser,dc=example,dc=net * libnss-ldap/nsswitch: * libnss-ldap/dbrootlogin: true --- /etc/libnss-ldap.conf 2007-12-17 15:39:07.591994125 + +++ libnss-ldap.conf2007-12-17 15:40:19.912868474 + @@ -18,7 +18,7 @@ # space. How long nss_ldap takes to failover depends on # whether your LDAP client library supports configurable # network or connect timeouts (see bind_timelimit). -#host ldapi://%2fvar%2frun%2fldapi/ +host ldapi://%2fvar%2frun%2fldapi/ # The distinguished name of the search base. base dc=wormnet,dc=eu @@ -26,7 +26,7 @@ # Another way to specify your LDAP server is to provide an # uri with the server name. This allows to use # Unix Domain Sockets to connect to a local LDAP Server. -uri ldapi://%2fvar%2frun%2fldapi/ +#uri ldapi://%2fvar%2frun%2fldapi/ #uri ldap://127.0.0.1/ #uri ldaps://127.0.0.1/ #uri ldapi://%2fvar%2frun%2fldapi_sock/
Bug#415228: freeradius: Stops answering locking up with 100% CPU usage
Hi, I experienced this problem in woody and yesterday it reared it's ugly head in etch. This was never a showstopper as we used to have two RADIUS servers and I had beaten nagios to email me when one of them died. However I am in the middle of redoing a huge chuck of the network infrastructure here and running the 'backup' RADIUS server as an experimental pilot one... :-/ Anyway as I have to compile my FreeRADIUS package from source[1] so I will throw in the debugging symbols and wrap it up in gdb. Just emailing to let you know this, and that etch also has this problem it seems. I'll get back to you hopefully with the gdb output at some stage. Cheers Alex [1] I have written a patch to extend the rlm_ldap module's xlat funtionality so that it can return the 'dn' too rather than just the attributes. I was suffering problems with woody before I even applied/wrote this patch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434228: nullmailer: ipv6 patch needs 'tweaking'
Package: nullmailer
Version: 1:1.03-5
Severity: normal
Tags: patch
Hi,
I was the person who a long while back submitted the patch for nullmailer to
have IPv6 support. I have found a minor bug in the patch I submitted, this I
noticed whilst I was adding support in a similar manner to 'ii'.
Anyway the problem is that the following lines need to be changed from:
===
if(connect(s, res-ai_addr, res-ai_addrlen) != 0)
continue;
===
to
===
if(connect(s, res-ai_addr, res-ai_addrlen) != 0) {
s = -1;
continue;
}
===
Without doing this, if nullmailer fails to connect to the SMTP server (say a
connection refused or timed out) then the section of code continues as if
there was nothing wrong, as the 'if(s 0)' check is skipped; as the socket()
part of the function typically succeeds.
Anyway, if connect() fails then my tweak sets 's' to -1 so that the section
can break out early, rather than the error being thrown up later on in
nullmailer when she tries to send data to a closed socket.
Its a tidying up patch :) I have attached a replacement IPv6 patch,
alternatively you can just mannually make the above adjustment to
lib/tcpconnect.cc yourself as that is all that I have changed.
Cheers
Alex
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-cfs-v19-hrt3
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 nullmailer depends on:
ii debconf [debconf-2.0] 1.5.13 Debian configuration management sy
ii libc6 2.6-2 GNU C Library: Shared libraries
ii libgcc1 1:4.2.1-0 GCC support library
ii libstdc++64.2.1-0The GNU Standard C++ Library v3
ii lsb-base 3.1-23.1 Linux Standard Base 3.1 init scrip
Versions of packages nullmailer recommends:
ii syslog-ng [system-log-daemon] 2.0.0-1Next generation logging daemon
-- debconf information excluded
diff -u -d -r nullmailer-1.03.orig/configure.in nullmailer-1.03/configure.in
--- nullmailer-1.03.orig/configure.in 2007-07-22 14:18:18.245274645 +0100
+++ nullmailer-1.03/configure.in 2007-07-22 14:18:52.240088523 +0100
@@ -47,6 +47,24 @@
dnl AC_CHECK_FUNCS(gettimeofday mkdir putenv rmdir socket)
AC_CHECK_FUNCS(setenv srandom)
+AC_MSG_CHECKING(for getaddrinfo)
+AC_TRY_COMPILE([#include sys/types.h
+#include sys/socket.h
+#include netdb.h], [getaddrinfo(NULL, NULL, NULL, NULL)], has_getaddrinfo=yes, has_getaddrinfo=no)
+if test $has_getaddrinfo = yes; then
+ AC_MSG_RESULT(yes)
+else
+ AC_MSG_RESULT(no)
+fi
+
+if test x-$has_getaddrinfo = x-no ; then
+ AC_MSG_RESULT(disabled: getaddrinfo missing)
+else
+ AC_DEFINE(HAVE_GETADDRINFO,,[getaddrinfo code enabled])
+fi
+
+AC_SUBST(HAVE_GETADDRINFO)
+
AC_DEFINE(BUFSIZE, 4096, [Generic buffer size])
AM_CONDITIONAL(FDBUF_NO_MYSTRING, false)
Only in nullmailer-1.03/debian: patched
diff -u -d -r nullmailer-1.03.orig/lib/tcpconnect.cc nullmailer-1.03/lib/tcpconnect.cc
--- nullmailer-1.03.orig/lib/tcpconnect.cc 2007-07-22 14:18:18.245274645 +0100
+++ nullmailer-1.03/lib/tcpconnect.cc 2007-07-22 14:19:20.735741332 +0100
@@ -28,7 +28,11 @@
#include netinet/in.h
#include errcodes.h
#include connect.h
+#ifdef HAVE_GETADDRINFO
+#include lib/itoa.h
+#endif
+#ifndef HAVE_GETADDRINFO
static int sethostbyname(const mystring hostname, struct sockaddr_in sa)
{
struct hostent *he = gethostbyname(hostname.c_str());
@@ -44,13 +48,48 @@
memcpy(sa.sin_addr, he-h_addr, he-h_length);
return 0;
}
+#endif
int tcpconnect(const mystring hostname, int port)
{
+#ifdef HAVE_GETADDRINFO
+ struct addrinfo req, *res, *orig_res;
+ const char *service = itoa(port, 6);
+
+ memset(req, 0, sizeof(req));
+ req.ai_flags = AI_NUMERICSERV;
+ req.ai_socktype = SOCK_STREAM;
+ int e = getaddrinfo(hostname.c_str(), service, req, res);
+#else
struct sockaddr_in sa;
memset(sa, 0, sizeof(sa));
int e = sethostbyname(hostname, sa);
+#endif
if(e) return e;
+#ifdef HAVE_GETADDRINFO
+ int s;
+ orig_res = res;
+
+ for (; res; res = res-ai_next ) {
+s = socket(res-ai_family, res-ai_socktype, res-ai_protocol);
+
+if(s 0)
+ continue;
+
+if(connect(s, res-ai_addr, res-ai_addrlen) != 0) {
+ s = -1;
+ continue;
+}
+
+/* sucessful connection */
+break;
+ }
+
+ freeaddrinfo(orig_res);
+
+ if(s 0)
+return -ERR_CONN_FAILED;
+#else
sa.sin_family = AF_INET;
sa.sin_port = htons(port);
int s = socket(PF_INET, SOCK_STREAM, 0);
@@ -64,5 +103,6 @@
default: return -ERR_CONN_FAILED;
}
}
+#endif
return s;
}
Bug#410185: dnsmasq: endless retry loop after server failure DNS response
Hi, Any chance of getting this fix backported to stable? I caught dnsmasq clobbering my upstream DNS server from my Debian Etch box, fortunately I noticed before others filed those abuse@ reports :) Cheers Alex -- __ To err is human, to forgive unusual. -- \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || signature.asc Description: Digital signature
Bug#411923: libnss-ldap update breaks authentication
Hi, Just to say that updating to etch pooched my libnss-ldap.conf file too in exactly the same manner. I used ldapi[1] for anything that supports it, including NSS. Before the update things were fine, after the update everything stopped working. 'host' had been uncommented and the ldapi entry placed in there whilst 'uri' was commented. It all stops working as libldap2 (which is used by even 'ls') borks on the 'host' line being invalid. Took me ages to fix this[2], not blaming you or demanding an apology, it's just that it is such a subtle difference that has such a huge effect. To be honest for something scriptable I would dump 'host' altogether and just use 'uri' in any auto-configuration script...then everyone is happy[3] :) This bug also caused/related to Debian bugs: * 408440 * 375097 which probably is the cause of all this due to the patch applied * 416664 * 415576 Cheers Alex [1] ldapi://%2fvar%2frun%2fldapi/ [2] bah, and I lost my 95 day uptime - I was getting desperate [3] unless its an IP address, bug #375097, I guess? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403651: libacl1: symbol setxattr ATTR_1.0 not defined libattr.so.1 (ATTR_1.1)
Hi, I have been hit by this too. The bug actually seems to be in libattr1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403585 It blated a lot of update scripts (tetex-* woul not update and bomb out horribly as a result). I have downgraded to libattr1_2.4.32-1_i386.deb for the time being and held the package till things settle down. Things are fine now for me. Just thought you would like to know. Cheers Alex -- _ / A little inaccuracy sometimes saves \ | tons of explanation.| | | \ -- H. H. Munro, Saki / - \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || signature.asc Description: Digital signature
Bug#208712: libxfce.so GTK-Warning woes
Hi, I had been suffering from this problem for some time, run any GTK application (gq, chameleon, etc) and get a bunch of harmless: Gtk-WARNING **: Unable to locate loadable module in module_path: libxfce.so messages over and over again. It was annoying but obviously not the end of the world. They occurred a while back when was playing with XFCE to see if I liked it but now that I'm using wmii its a reminder of my ugly past ;) Anyway I found finally something online[1] and by removing all traces of XFCE from my ~/.gtkrc file the messages disappeared. I actually deleted the file in the end along with .gtk-bookmarks but thats just me being overly tidy. Just thought this might be the real 'solution' to the bug. Not fair to force people to install an XFCE related package to clean up harmless messages when they do not intend on using it :) Meanwhile my partner is a happy user of XFCE so keep up the good work! Cheers Alex [1] http://www.linuxquestions.org/questions/showthread.php?t=104863 -- ___ / The more things change, the more they \ \ stay insane. / --- \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379401: pscan/iscan == piscan
Hi, The reason those folk who cannot make their local machines discoverable is probably as they are issuing: # hciconfig hci0 pscan # hciconfig hci0 iscan which first sets the hci0 device to pscan mode and then iscan mode, so the final mode is iscan. What they should be doing is: # hciconfig hci0 piscan As for how to get hcid to behave and properly configure the interface, its not a quick fix from what I can tellover to 'upstream' to deal with :) Cheers Alex -- / The light at the end of the tunnel is \ \ the headlight of an approaching train. / \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || signature.asc Description: Digital signature
Bug#385019: bluez-utils: dbaddr for EEPROMless devices
Package: bluez-utils Version: 3.1-4 Severity: wishlist Whilst trying to configure a BNEP network I found my friends USB dongle had a wierd hardware address of 11:11:11:11:11:11. Reading around it turns out this is what happens when the device has no onboard EEPROM and you need to change the address with the 'bdaddr' util found in the 'test' directory in the bluez-utils package. Unfortunately the Debian package does not ship this binary. The Makefile in the 'test' directory does not work too well once made but if you could compile the dbaddr tool with: $ cc -g bdaddr.c -Wall -O2 -D_FORTIFY_SOURCE=2 -o bdaddr -I ../common/ -lbluetooth -L ../common/ -lhelper And then ship it in a newer release that would be great. Cheers Alex -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.8-beyond3 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages bluez-utils depends on: ii dbus 0.62-4 simple interprocess messaging syst ii libbluetooth23.1-1 Library to use the BlueZ Linux Blu ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libdbus-1-2 0.62-4 simple interprocess messaging syst ii libdbus-glib-1-2 0.62-4 simple interprocess messaging syst ii libglib2.0-0 2.10.3-3The GLib library of C routines ii libusb-0.1-4 2:0.1.12-2 userspace USB programming library ii lsb-base 3.1-15 Linux Standard Base 3.1 init scrip ii makedev 2.3.1-82creates device files in /dev ii module-init-tools3.2.2-3 tools for managing Linux kernel mo ii modutils 2.4.27.0-6 Linux module utilities ii sysvinit 2.86.ds1-15 System-V-like init utilities ii udev 0.097-2 /dev/ and hotplug management daemo bluez-utils recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367044: xserver-xorg: please re-enable lbx support
Hi, David Nusinow [EMAIL PROTECTED] [20060516 21:52:29 -0400]: On Sat, May 13, 2006 at 03:30:24AM +0100, Alexander Clouter wrote: Package: xserver-xorg Severity: normal [snipped] Digging through Google I happened upon a patch being applied that actually turned off LBX support, but I could not find any reason why this had been done. http://lists.debian.org/debian-x/2005/12/msg00212.html Any chance of turning it back on? Not likely. Upstream has decided that lbx is to be deprecated for the X11R7.1 release[0], which is currently scheduled to be released this Friday. The reasons are outlined in this paper: http://keithp.com/~keithp/talks/lbxpost/index.html which essentially states that lbx is a failed technology. As a result of both these things I don't see a need to enable lbx currently. Far enough, I guess thats why all the examples about it pre-date 2003 and its nigh next to impossible to find out more about it. Cheers for the link to the paper, not the most indepth thing but enlightening. Now what I need is a ncurses LDAP client /me goes hunting You can close this 'bug'. Cheers Alex - David Nusinow [0] http://wiki.x.org/wiki/ChangesForX11R71 -- _ / You can fool some of the people all of \ | the time, and all of the people some of | | the time, but you can never fool your | \ Mom./ - \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367044: xserver-xorg: please re-enable lbx support
Package: xserver-xorg Severity: normal Hi, Whilst trying to get LBX support to work with the latest X.Org packets in Debian unstable, lbxproxy kept telling me that the LBX extension was not available on my client's xserver. Digging around I did indeed find that the LBX extension was not loading in my /var/log/Xorg.0.log file but yet I have libext6 installed which is ment to supply such goodness. Digging through Google I happened upon a patch being applied that actually turned off LBX support, but I could not find any reason why this had been done. http://lists.debian.org/debian-x/2005/12/msg00212.html Any chance of turning it back on? Cheers Alex -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-ck9 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353161: dhcp3-relay: udp has incorrect checksum when relaying to self
Hi, Andrew Pollock [EMAIL PROTECTED] [20060216 09:51:11 -0800]: On Thu, Feb 16, 2006 at 03:13:46PM +, Alexander Clouter wrote: Package: dhcp3-relay Severity: important Running version 3.0.1-2 of dhcp3-relay, I needed to run a development DHCP server alongside it. I decided to bind the dhcp server to the local loopback interface (lo) and configure dhcp3-relay with: SERVERS=127.0.0.1 INTERFACES=eth0.95 eth0.96 eth0.97 OPTIONS=-m discard [snip] Can you reproduce this problem with the version of dhcp3-relay in testing? I can arrange for a backport of this to stable if need be. Tested with a backported 3.0.3 copy of dhcp3-relay and exactly the same problem persists. Incorrect UDP checksums still appear in every packet dhcp3-relay produces and dhcp3-server complains :) Cheers Alex regards Andrew -- __ / It doesn't matter whether you win or \ \ lose -- until you lose. / -- \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || signature.asc Description: Digital signature
Bug#353161: dhcp3-relay: udp has incorrect checksum when relaying to self
Hi, Andrew Pollock [EMAIL PROTECTED] [20060216 09:51:11 -0800]: On Thu, Feb 16, 2006 at 03:13:46PM +, Alexander Clouter wrote: Package: dhcp3-relay Severity: important Running version 3.0.1-2 of dhcp3-relay, I needed to run a development DHCP server alongside it. I decided to bind the dhcp server to the local loopback interface (lo) and configure dhcp3-relay with: SERVERS=127.0.0.1 INTERFACES=eth0.95 eth0.96 eth0.97 OPTIONS=-m discard [snip] Can you reproduce this problem with the version of dhcp3-relay in testing? I can arrange for a backport of this to stable if need be. I can backport it myself, it will save you the effort :) I'll give it a go on Tuesday (off work till then). Regards Alex regards Andrew -- / Scintillation is not always\ \ identification for an auric substance. / \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || signature.asc Description: Digital signature
Bug#353161: dhcp3-relay: udp has incorrect checksum when relaying to self
Package: dhcp3-relay Severity: important Running version 3.0.1-2 of dhcp3-relay, I needed to run a development DHCP server alongside it. I decided to bind the dhcp server to the local loopback interface (lo) and configure dhcp3-relay with: SERVERS=127.0.0.1 INTERFACES=eth0.95 eth0.96 eth0.97 OPTIONS=-m discard The packets arrive okay, but when dhcp3-relay passes them on the udp checksum that //leaves// on the udp packet is incorrect. If you look at the attached packet capture (dhcp-fail.dump) you can see the packets coming in okay, but then when dhcp3-relay passes them on the udp checksum is corrupt. I first tested with a 127.0.0.1-127.0.0.1 setup and when that failed I thought about trying to 'real' public IP's incase it was some strange loopback issue. I got the exact same problem. :( Its only when the source address matches the destination address, it seems, that the checksum is incorrect calculated. I have attached a capture (dhcp-good.dump) of it behaving correctly when its relaying to a non-local dhcp server on another computer. Okay, its extremely unlikely that someone would want to run a relay on the same machine as the dhcp server it-self but in a development environment is saves 'borrowing' another computer; it also points to a slight issue in the underlying checksum generator[1] which should be corrected. Meanwhile the dhcp server keeps filling up the syslog with: Feb 16 14:07:07 troll dhcpd: 5 bad udp checksums in 5 packets Feb 16 14:07:24 troll dhcpd: 5 bad udp checksums in 5 packets Feb 16 14:07:33 troll dhcpd: 5 bad udp checksums in 5 packets Feb 16 14:07:53 troll dhcpd: 5 bad udp checksums in 5 packets Feb 16 14:08:44 troll dhcpd: 5 bad udp checksums in 5 packets Feb 16 14:08:57 troll dhcpd: 5 bad udp checksums in 5 packets Feb 16 14:09:23 troll dhcpd: 5 bad udp checksums in 5 packets Which is correct, as the checksum is indeed incorrect. Cheers Alex [1] I'm assuming that the dhcp relay server opens a raw socket and so generates its own udp checksum? -- System Information (altered to reflect settings on actual server): Debian Release: testing/unstable APT prefers stable Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-ck1 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353161: dhcp3-relay: udp has incorrect checksum when relaying to self
Doh, Alexander Clouter [EMAIL PROTECTED] [20060216 15:13:46 +]: Package: dhcp3-relay Severity: important [snipped] If you look at the attached packet capture (dhcp-fail.dump) you can see the packets coming in okay, but then when dhcp3-relay passes them on the udp checksum is corrupt. I first tested with a 127.0.0.1-127.0.0.1 setup and when that failed I thought about trying to 'real' public IP's incase it was some strange loopback issue. I got the exact same problem. :( Its only when the source address matches the destination address, it seems, that the checksum is incorrect calculated. I have attached a capture (dhcp-good.dump) of it behaving correctly when its relaying to a non-local dhcp server on another computer. This time the captures are actually attached... Cheers Alex -- System Information (altered to reflect settings on actual server): Debian Release: testing/unstable APT prefers stable Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-ck1 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- __ Do unto others before they undo you. -- \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || dhcp-fail.dump Description: Binary data dhcp-good.dump Description: Binary data
Bug#341398: Can not reproduce
Hi, Sorry for the late reply Ganesan Rajagopal [EMAIL PROTECTED] [20051206 21:32:43 +0530]: Aidas Kasparas wrote: tags 341398 + moreinfo unreproducible thanks I see you're using non standard kernel. Can you reporoduce the same problem with standard kernel? I was unable to reproduce with 2.6.14-2-686. Can you state what kind of ipsec policies you have in place? Are you using any other tools which use pfkey sockets, or alter SPD in other ways? Apart from using 'setkey' I use nothing else that fiddles with pfkey sockets that I know of. There was one other user who reported an identical issue. So we need to figure out what Alex and Vincent have in common. Alex mentioned that his issue is identical to what Vincent is facing. The log messages about PF_KEY register is suspicious. I have never faced this myself. I am unable to reproduce this problem either with 2.6.12-10. Are you guys by any chance using freeswan/openswan modules with racoon? Nope, just the regular 2.6.14 Linux kernel, with the ck patchset and also the ipv6 usagi patches applied. Never played with freeswan/openswan. There is nothing 'exciting' in my racoon.conf or sainfo files either. Cheers Alex Ganesan -- / Men freely believe that what they wish \ | to desire. | || \ -- Julius Caesar / \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || signature.asc Description: Digital signature
Bug#340063: nullmailer: ipv6 support not enabled
Package: nullmailer Version: 1:1.00-3 Severity: important Hi, Thanks for including my IPv6 patch...the only problem is that for some reason I do not think it was enabled in the binary (i386) release :( Using 1.00-3 from unstable in /var/log/mail.log I get (my mailserver is 'smtp'): --- Nov 20 17:21:59 localhost nullmailer[9886]: smtp: Failed: Connect failed Nov 20 17:21:59 localhost nullmailer[1827]: Sending failed: Host or network unreachable --- If I 'apt-get source nullmailer' and compile I get: --- Nov 20 17:23:57 localhost nullmailer[1827]: Starting delivery: protocol:smtp host: smtp file: 1132407134.3602 Nov 20 17:23:59 localhost nullmailer[10058]: smtp: Failed: 554 [EMAIL PROTECTED]: Relay access denied Nov 20 17:23:59 localhost nullmailer[1827]: Sending failed: Permanent error in sending the message --- Obviously now a completely different error message, but now the fault lies with me and a misconfigured mailserver :) I'm on a 100% IPv6 network and so I'm guessing that the binary release is making an IPv4 only connection and thats why it is sulking. As /usr/lib/nullmailer/smtp is rather quick, I cannot attach an 'strace' to the process to put proof to this but I think the recompile from source shows that somethings afoot. When you compile the package, does './configure' come back with: [snipped] checking whether named pipes are buggy... no checking for setenv... yes checking for srandom... yes checking for getaddrinfo... yes important line configure: creating ./config.status config.status: creating Makefile [snipped] Thats the line which 'enables' IPv6 connectivity. Cheers Alex -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-ck5 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages nullmailer depends on: ii debconf [debconf-2.0] 1.4.59 Debian configuration management sy ii libc6 2.3.5-8GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-4 GCC support library ii libstdc++64.0.2-4The GNU Standard C++ Library v3 ii lsb-base 3.0-11 Linux Standard Base 3.0 init scrip ii ucf 2.003 Update Configuration File: preserv Versions of packages nullmailer recommends: ii sysklogd [system-log-daemon] 1.4.1-17 System Logging Daemon -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336348: nullmailer: lack of IPv6 support
Package: nullmailer
Version: 1:1.00-2
Severity: wishlist
Tags: patch
Hi,
There is no support for IPv6 support in nullmailer, which is a shame and
so I rolled out the attached patch.
I actually sent this first to the upstream author but never received a
reply :( Instead I thought I might aswell send it to the Debian
maintainer :)
I feel my patch is cleaner than the one recently posted on the
nullmailer mailing list (beat me to the patch by two weeks :)
http://lists.untroubled.org/?list=nullmailercmd=showmsgmsgnum=548
Which ever patch is chosen, one needs to go in...fight to the death? :)
Cheers
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-ck1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages nullmailer depends on:
ii debconf [debconf-2.0] 1.4.58 Debian configuration management sy
ii libc6 2.3.5-7GNU C Library: Shared libraries an
ii libgcc1 1:4.0.2-3 GCC support library
ii libstdc++64.0.2-3The GNU Standard C++ Library v3
ii lsb-base 3.0-10 Linux Standard Base 3.0 init scrip
ii ucf 2.003 Update Configuration File: preserv
Versions of packages nullmailer recommends:
ii sysklogd [system-log-daemon] 1.4.1-17 System Logging Daemon
-- debconf information excluded
diff -u -r nullmailer-1.00.orig/configure.in nullmailer-1.00/configure.in
--- nullmailer-1.00.orig/configure.in 2005-10-23 13:05:12.610696760 +0100
+++ nullmailer-1.00/configure.in 2005-10-23 13:05:18.755762568 +0100
@@ -47,6 +47,24 @@
dnl AC_CHECK_FUNCS(gettimeofday mkdir putenv rmdir socket)
AC_CHECK_FUNCS(setenv srandom)
+AC_MSG_CHECKING(for getaddrinfo)
+AC_TRY_COMPILE([#include sys/types.h
+#include sys/socket.h
+#include netdb.h], [getaddrinfo(NULL, NULL, NULL, NULL)], has_getaddrinfo=yes, has_getaddrinfo=no)
+if test $has_getaddrinfo = yes; then
+ AC_MSG_RESULT(yes)
+else
+ AC_MSG_RESULT(no)
+fi
+
+if test x-$has_getaddrinfo = x-no ; then
+ AC_MSG_RESULT(disabled: getaddrinfo missing)
+else
+ AC_DEFINE(HAVE_GETADDRINFO,,[getaddrinfo code enabled])
+fi
+
+AC_SUBST(HAVE_GETADDRINFO)
+
AC_DEFINE(BUFSIZE, 4096, [Generic buffer size])
AM_CONDITIONAL(FDBUF_NO_MYSTRING, false)
diff -u -r nullmailer-1.00.orig/lib/tcpconnect.cc nullmailer-1.00/lib/tcpconnect.cc
--- nullmailer-1.00.orig/lib/tcpconnect.cc 2005-10-23 13:05:12.595699040 +0100
+++ nullmailer-1.00/lib/tcpconnect.cc 2005-10-23 13:05:24.110948456 +0100
@@ -28,7 +28,11 @@
#include netinet/in.h
#include errcodes.h
#include connect.h
+#ifdef HAVE_GETADDRINFO
+#include lib/itoa.h
+#endif
+#ifndef HAVE_GETADDRINFO
static int sethostbyname(const mystring hostname, struct sockaddr_in sa)
{
struct hostent *he = gethostbyname(hostname.c_str());
@@ -44,13 +48,46 @@
memcpy(sa.sin_addr, he-h_addr, he-h_length);
return 0;
}
+#endif
int tcpconnect(const mystring hostname, int port)
{
+#ifdef HAVE_GETADDRINFO
+ struct addrinfo req, *res, *orig_res;
+ const char *service = itoa(port, 6);
+
+ memset(req, 0, sizeof(req));
+ req.ai_flags = AI_NUMERICSERV;
+ req.ai_socktype = SOCK_STREAM;
+ int e = getaddrinfo(hostname.c_str(), service, req, res);
+#else
struct sockaddr_in sa;
memset(sa, 0, sizeof(sa));
int e = sethostbyname(hostname, sa);
+#endif
if(e) return e;
+#ifdef HAVE_GETADDRINFO
+ int s;
+ orig_res = res;
+
+ for (; res; res = res-ai_next ) {
+s = socket(res-ai_family, res-ai_socktype, res-ai_protocol);
+
+if(s 0)
+ continue;
+
+if(connect(s, res-ai_addr, res-ai_addrlen) != 0)
+ continue;
+
+/* sucessful connection */
+break;
+ }
+
+ freeaddrinfo(orig_res);
+
+ if(s 0)
+return -ERR_CONN_FAILED;
+#else
sa.sin_family = AF_INET;
sa.sin_port = htons(port);
int s = socket(PF_INET, SOCK_STREAM, 0);
@@ -64,5 +101,6 @@
default: return -ERR_CONN_FAILED;
}
}
+#endif
return s;
}
Bug#319528: scorched3d: dependency borkage (libwxgtk2.4 instead of libwxgtk2.4-1)
Package: scorched3d Version: 38.1-2 Severity: important A quick ganger over at: http://packages.debian.org/unstable/games/scorched3d will show that libwxgtk2.4 is not installable. At a guess, I really do not have a clue, if the dependency is changed from libwxgtk2.4 to libwxgtk2.4-1 everything should start to work; I personally would say this is a bug in libwxgtk2.4 due to the '-1' bit but I am unsure. If you manually install the testing version of the package: http://packages.debian.org/testing/libs/libwxgtk2.4 and then install scorched3d everything is peachy. Wheres the bug? I'm only reporting this as the girlfriend is complaining no end about not being about to 'nuke stuff'. :) Cheers Alex -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-ck3-jdg2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages scorched3d depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib ii libgcc1 1:4.0.1-2 GCC support library ii libglu1-xorg 6.8.2.dfsg.1-4 Mesa OpenGL utility library [X.Org ii libsdl-mixer1 1.2.6-1mixer library for Simple DirectMed ii libsdl-net1.2 1.2.5-4network library for Simple DirectM ii libsdl1.2debi 1.2.7+1.2.8cvs20041007-5.3 Simple DirectMedia Layer ii libstdc++51:3.3.6-7 The GNU Standard C++ Library v3 ii libwxgtk2.4 2.4.3.1wxWindows Cross-platform C++ GUI t ii scorched3d-da 38.1-2 data files for Scorched3D game ii xlibmesa-gl [ 6.8.2.dfsg.1-4 Mesa 3D graphics library [X.Org] ii zlib1g1:1.2.3-1 compression library - runtime scorched3d recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318860: since 0.0.20050628 DESKTOP mode of wine is not available
Hi, On Jul 18, Zsolt Rizsanyi wrote: On Monday 18 July 2005 12.36, Alexander Clouter wrote: Package: wine Version: 0.0.20050628-2 Severity: important Myself and a friend use Wine to run Siebel in the office on our laptops and since the Debian upgrade to 0.0.20050628 its impossible for my friend and I to put WINE into Desktop mode, even when set as the default policy. :( Everything was working fine with 0.0.20050524 with the following pasted to the end of my config file (which was based on the generated output from winesetup). It is either ignored or just does not work, we simply get managed mode windows and because Siebel is terribly written it bombs out regularly[1] - [AppDefaults\\siebtc.exe\\x11drv] Managed = N Desktop = 1280x1024 ; needed for DLL's to init [AppDefaults\\siebtc.exe\\Version] Windows = win2k3 AFAIK the newest version of wine does not read the config file anymore. All the configuration is taken from the registry. DOH! So this does not seem to be a bug, you just need to set your configuration in the registry using winecfg or regedit. guess I could :) Now if only someone fixed the 'change desktop bug'[1] which has been open for a year, hint hint ;) You can close this 'bug', obviously opened by mistake on my part, sorry for wasting all your time. Cheers, and keep up the good work. Alex [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272909 Regards Zsolt -- 42 \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || signature.asc Description: Digital signature
