Bug#1070726: nvidia-kernel-dkms wont build with latest bullseye kernel 5.10.0-29-amd64

[Martin Dorey]

> There is already a newer driver version in oldstable-proposed-updates.
> Does it fix the issue?

Perhaps that was just a question out of politeness, and I’m not the OP, but
it did for me.  Thank you both - so much easier when a search engine query
shows that someone else has gone first.

Bug#1037233: .../odbc/statement.rb:89: warning: rb_tainted_str_new_cstr is deprecated

[Martin Dorey]

Package: ruby-odbc
Version: 0.8-2
Severity: normal
Tags: patch

Dear Maintainer,

As I mentioned at the end of:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941707

Using ruby-odbc under Bullseye's Ruby generates warnings of the deprecation of
tainting, as can be demonstrated by running the simplest of SQL queries:

$ ruby -e 'require "makeTdConnection"; db = makeTdConnection(); 
db.execute("select 0").finish();'
$ 

If warnings are enabled, the same becomes:

$ ruby -we 'require "makeTdConnection"; db = makeTdConnection(); 
db.execute("select 0").finish();'
/usr/lib/ruby/vendor_ruby/dbd/odbc/statement.rb:89: warning: 
rb_tainted_str_new_cstr is deprecated and will be removed in Ruby 3.2.
/usr/lib/ruby/vendor_ruby/dbd/odbc/statement.rb:89: warning: 
rb_tainted_str_new_cstr is deprecated and will be removed in Ruby 3.2.
/usr/lib/ruby/vendor_ruby/dbd/odbc/statement.rb:89: warning: 
rb_tainted_str_new_cstr is deprecated and will be removed in Ruby 3.2.
/usr/lib/ruby/vendor_ruby/dbd/odbc/statement.rb:89: warning: 
rb_tainted_str_new_cstr is deprecated and will be removed in Ruby 3.2.
$ 

I attach a rather simple-minded, understanding-free patch that we've been using 
without incident since 2023-04-16.


-- System Information:
Debian Release: 11.7
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'oldoldstable'), (500, 'stable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ruby-odbc depends on:
ii  libc6 2.31-13+deb11u6
ii  libodbc1  2.3.6-0.1+b1
ii  libruby2.72.7.4-1+deb11u1
ii  odbcinst1debian2  2.3.6-0.1+b1
ii  ruby  1:2.7+2
ii  ruby1.8 [ruby]1.8.7.358-7.1+deb7u6
ii  unixodbc  2.3.6-0.1+b1

ruby-odbc recommends no packages.

ruby-odbc suggests no packages.

-- no debconf information
--- ext/odbc.c.orig 2023-04-16 13:02:20.028926480 -0700
+++ ext/odbc.c  2023-04-16 12:59:56.947862615 -0700
@@ -69,6 +69,16 @@
 #include "ruby/thread.h"
 #endif
 
+#if 0
+#define MAYBE_OBJ_TAINT(obj) rb_obj_taint(obj)
+#define MAYBE_TAINTED_STR_NEW(ptr, len) rb_tainted_str_new(ptr, len)
+#define MAYBE_TAINTED_STR_NEW2(ptr) rb_tainted_str_new2(ptr)
+#else
+#define MAYBE_OBJ_TAINT(obj) obj
+#define MAYBE_TAINTED_STR_NEW(ptr, len) rb_str_new(ptr, len)
+#define MAYBE_TAINTED_STR_NEW2(ptr) rb_str_new_cstr(ptr)
+#endif
+
 /*
  * Conditionally undefine aliases of ODBC installer UNICODE functions.
  */
@@ -1371,7 +1381,7 @@
 if ((cp != NULL) && (str != NULL)) {
ulen = mkutf(cp, str, len);
 }
-v = rb_tainted_str_new((cp != NULL) ? cp : "", ulen);
+v = MAYBE_TAINTED_STR_NEW((cp != NULL) ? cp : "", ulen);
 #ifdef USE_RB_ENC
 rb_enc_associate(v, rb_enc);
 #endif
@@ -1861,7 +1871,7 @@
 rb_enc_associate(v, rb_enc);
 #endif
 a = rb_ary_new2(1);
-rb_ary_push(a, rb_obj_taint(v));
+rb_ary_push(a, MAYBE_OBJ_TAINT(v));
 CVAR_SET(Cobj, warn ? IDatatinfo : IDataterror, a);
 return STR2CSTR(v);
 }
@@ -1939,7 +1949,7 @@
v0 = v;
a = rb_ary_new();
}
-   rb_ary_push(a, rb_obj_taint(v));
+   rb_ary_push(a, MAYBE_OBJ_TAINT(v));
tracemsg(1, fprintf(stderr, "  | %s\n", STR2CSTR(v)););
}
 }
@@ -2035,7 +2045,7 @@
v0 = v;
a = rb_ary_new();
}
-   rb_ary_push(a, rb_obj_taint(v));
+   rb_ary_push(a, MAYBE_OBJ_TAINT(v));
tracemsg(1, fprintf(stderr, "  | %s\n", STR2CSTR(v)););
}
 }
@@ -2289,7 +2299,7 @@
 buf[SQL_MAX_MESSAGE_LENGTH] = '\0';
 v = rb_str_new2(buf);
 a = rb_ary_new2(1);
-rb_ary_push(a, rb_obj_taint(v));
+rb_ary_push(a, MAYBE_OBJ_TAINT(v));
 CVAR_SET(Cobj, IDataterror, a);
 rb_raise(Cerror, "%s", buf);
 return Qnil;
@@ -2379,8 +2389,8 @@
 #else
dsnLen = (dsnLen == 0) ? (SQLSMALLINT) strlen(dsn) : dsnLen;
descrLen = (descrLen == 0) ? (SQLSMALLINT) strlen(descr) : descrLen;
-   rb_iv_set(odsn, "@name", rb_tainted_str_new(dsn, dsnLen));
-   rb_iv_set(odsn, "@descr", rb_tainted_str_new(descr, descrLen));
+   rb_iv_set(odsn, "@name", MAYBE_TAINTED_STR_NEW(dsn, dsnLen));
+   rb_iv_set(odsn, "@descr", MAYBE_TAINTED_STR_NEW(descr, descrLen));
 #endif
rb_ary_push(aret, odsn);
first = dsnLen = descrLen = 0;
@@ -2444,13 +2454,13 @@
}
 #else
driverLen = (driverLen == 0) ? (SQLSMALLINT) strlen(driver) : driverLen;
-   rb_iv_set(odrv, "@name", rb_tainted_str_new(driver, driverLen));
+   rb_iv_set(odrv, "@name", 

Bug#941707: ruby-odbc: [RubyODBC]Cannot allocate SQLHENV (ODBC::Error)

[Martin Dorey]

Control: fixed 941707 0.8-2

The reproducer I gave here, which still seems reliable for me on Buster,
doesn't reproduce the problem for me on Bullseye with 0.8-2,
despite nothing in the change log at
https://metadata.ftp-master.debian.org/changelogs//main/r/ruby-odbc/ruby-odbc_0.8-2_changelog
appearing relevant.  The Bullseye version won't install on Buster, with a
dependency on Bullseye's version of Ruby and won't easily build on Buster,
with a debhelper-compat change and:

dwz:
debian/ruby-odbc/usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/2.5.0/odbc.so:
DWARF version 0 unhandled

... which perhaps is avoided on Bullseye by its newer binutils, per eg
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967005#39.  Using
ruby-odbc under Bullseye's Ruby has its own problem - warnings of the
deprecation of tainting - but that deserves its own bug report.

Bug#1031650: lwm: description misspells "include"

[Martin Dorey]

Package: lwm
Version: 1.2.2-6+b1
Severity: minor

Dear Maintainer,

Not the most interesting of bug reports, sorry, but the package Description 
tells me that lwm "doesn't iclude icons, icon docs, button bars or root 
menus"... or the "n" that I imagine was intended in "iclude".

-- System Information:
Debian Release: 11.6
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'oldoldstable'), (500, 'stable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lwm depends on:
ii  gnome-terminal [x-terminal-emulator]  3.38.3-1
ii  libc6 2.31-13+deb11u5
ii  libice6   2:1.0.10-1
ii  libsm62:1.2.3-1
ii  libx11-6  2:1.7.2-1
ii  libxext6  2:1.3.3-1.1
ii  org.jessies.terminator [x-terminal-emulator]  29.45.7469
ii  rxvt  1:2.7.10-7.1+urxvt9.22-11
ii  rxvt-unicode [x-terminal-emulator]9.22-11
ii  xterm [x-terminal-emulator]   366-1+deb11u1

lwm recommends no packages.

Versions of packages lwm suggests:
pn  fbdesk  
pn  idesk   

-- no debconf information

Bug#944139: debmirror archive.debian.org fails due to missing binary-all

[Martin Dorey]

The introducing commit suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944139#15 doesn't look
right to me.  I had success reverting the active part of
https://salsa.debian.org/debian/debmirror/-/commit/82bf56b2246bdf22470fd2751b359c82932c3833#81f3803dd9887f397ffdeebc8973c6de39a38df9
instead of that one.  I didn't try the more constructive suggestion from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944139#20, sorry, because
it was easier for me if the arguments remain compatible with older
versions.  I could be persuaded to try it.

There's clearly something amiss with archive.debian.org.
https://archive.kernel.org/debian-archive/debian/dists/wheezy/Release
mentions eg:

 1a5452264b2c147411a53afd4a13b311 12683375 main/binary-all/Packages

... but there is no binary-all directory in
https://archive.kernel.org/debian-archive/debian/dists/wheezy/main/.
Perhaps getting that fixed would be too hard?  Making debmirror cope
doesn't seem to be too difficult.

Bug#994728: libtirpc3:amd64: rpcbind stops replying to subnet broadcast CALLIT after one stray UDP datagram

[Martin Dorey]

On Sun, 19 Sep 2021 19:11:26 -0700 Martin Dorey 
wrote:
> Package: libtirpc3
> Version: 1.1.4-0.4

My production occurrence was always on Stretch, but I'd thought that the
patch might be more easily accepted against a less stale branch.  It
applies to Stretch too, where I've just put it into production.

> sendmsg(7, {msg_name={sa_family=AF_INET, sin_port=htons(800),
sin_addr=inet_addr("172.27.5.162")}, msg_namelen=16,
msg_iov=[{iov_base="\0\2:\270\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2\371\0\0\0\4"...,
iov_len=36}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_IP,
cmsg_type=IP_PKTINFO, cmsg_data={ipi_ifindex=0,
ipi_spec_dst=inet_addr("127.0.0.1"), ipi_addr=inet_addr("127.0.0.1")}}],
msg_controllen=32, msg_flags=0}, 0) = -1 EINVAL (Invalid argument)

I don't, today, see EINVAL being returned on Stretch, though I did before.
While successfully sent, the response doesn't get to its intended target
for me today, perhaps ending up at 127.0.0.1 instead of the intended
172.27.5.162 (to use the IP address from the above output).

> Once an rpcbind process has got into this state, it doesn't
> recover without being restarted.

I found, today, that sending Stretch rpcbind the poison pill from a
different machine caused it to recover.  I've only seen the problem
exhibited, then, when the poison has been sent locally.

> First enable remote call support.

That was first disabled in Buster, so isn't needed to reproduce the problem
on Stretch.

> rpcinfo -b 10 4

For my Stretch reproduction today, I have to make this call from a
different computer to the one on which rpcbind is running to see the
problem.  Sending a unicast request, like rpcbind -T udp sirius 10 4,
didn't suffer from the problem for me, at least not today, on Stretch.

Bug#999442: systemd: reproducible hang on upgrade, in try-restart systemd-networkd.service

[Martin Dorey]

After an upgrade to systemd 247.3-6~bpo10+1 from buster-backports, I can no 
longer reproduce the problem in 15+ minutes of trying, when it always took less 
than 1 minute before.  I think it's fixed.  Sorry for the noise.

Starting at:

https://bugzilla.redhat.com/show_bug.cgi?id=1845456
systemctl try-restart command hangs indefinitely while being executed during a 
yum update

... I think the fix might have been:

https://github.com/systemd/systemd/pull/13124
core: coldplug possible nop_job

That's not in:

https://github.com/systemd/systemd/blob/v243/src/core/unit.c#L3925

... but is at:

https://github.com/systemd/systemd/blob/v244/src/core/unit.c#L3894

Bug#994728: libtirpc3:amd64: rpcbind stops replying to subnet broadcast CALLIT after one stray UDP datagram

[Martin Dorey]

Package: libtirpc3
Version: 1.1.4-0.4
Severity: normal
Tags: patch

Dear Maintainer,

My NIS setup stops working occasionally.
The clients rely on subnet broadcast CALLIT requests to locate
the NIS servers.
The rpcbind process on the NIS server sees the requests but
fails to send the reply.
The strace output looks like this:

recvmsg(6, {msg_name={sa_family=AF_INET, sin_port=htons(800), 
sin_addr=inet_addr("172.27.5.162")}, msg_namelen=128->16, 
msg_iov=[{iov_base="\0\2:\270\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\5\0\0\0\0\0\0\0\0"...,
 iov_len=9000}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_IP, 
cmsg_type=IP_PKTINFO, cmsg_data={ipi_ifindex=if_nametoindex("eth0"), 
ipi_spec_dst=inet_addr("172.27.8.1"), ipi_addr=inet_addr("172.27.63.255")}}], 
msg_controllen=32, msg_flags=0}, 0) = 64
...
sendmsg(7, {msg_name={sa_family=AF_INET, sin_port=htons(800), 
sin_addr=inet_addr("172.27.5.162")}, msg_namelen=16, 
msg_iov=[{iov_base="\0\2:\270\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2\371\0\0\0\4"...,
 iov_len=36}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_IP, 
cmsg_type=IP_PKTINFO, cmsg_data={ipi_ifindex=0, 
ipi_spec_dst=inet_addr("127.0.0.1"), ipi_addr=inet_addr("127.0.0.1")}}], 
msg_controllen=32, msg_flags=0}, 0) = -1 EINVAL (Invalid argument)

... where I think the active ingredient is that ipi_spec_dst or
ipi_addr is 127.0.0.1 rather than the 172.27.5.162 intended
reply address.
Once an rpcbind process has got into this state, it doesn't
recover without being restarted.
rpcbind is calling svc_sendreply on the xprt it created in
create_rmtcall_fd, which isn't where the request originated.
That calls svc_dg_reply which assumes:

/* cmsg already set in svc_dg_recv */

... as of:

https://git.linux-nfs.org/?p=steved/libtirpc.git;a=commit;h=74ef3df0236c55185225c62fba34953f2582da72
(Try to ensure datagram replies come from the address requests were sent to.)

That's been zero-initialized, so everything works fine until
a port scan or some such sends a datagram to the same port.
Its IP_PKTINFO gets remembered and used on every subsequent
reply.

I can demonstrate the problem without needing NIS.
First enable remote call support.
On Debian, that can be done with:

sudo tee --append /etc/default/rpcbind <--- src/svc_dg.c.orig   2021-09-19 18:24:32.462610751 -0700
+++ src/svc_dg.c2021-09-19 18:14:52.271066229 -0700
@@ -278,6 +278,8 @@
if (su->su_cache)
cache_set(xprt, slen);
}
+   msg->msg_control = NULL;
+   msg->msg_controllen = 0;
}
return (stat);
 }

Bug#981912: libsdes4j-java: provoked IDS to block download thinking it's Unix.Trojan.Chalubo

[Martin Dorey]

Package: libsdes4j-java
Version: 1.1.4-1.1
Severity: normal

Dear Maintainer,

This isn't a bug in the package, just a warning about a problem getting the 
package.
Our debmirror job has been failing:

 Download of pool/main/s/sdes4j/libsdes4j-java-doc_1.1.4-1.1_all.deb failed: 
500 Status read failed: Connection reset by peer
 Download of pool/main/s/sdes4j/libsdes4j-java_1.1.4-1.1_all.deb failed: 500 
Status read failed: Connection reset by peer

And our intrusion detection system (name and vendor unknown to me) has been 
firing off alerts like:

Total Alerts in Database:  3058

Last Email Time: 2021-02-03 17:20:02
Current Time:2021-02-03 17:25:02

Total New Alerts: 1
Filter Matching : 1

++
Alerts (shown: 1/available: 1) (limit: 50)
++
Device : 
Timestamp: 2021-02-03 17:23:16
Protocol : tcp
Alert Message: MALWARE-CNC Unix.Trojan.Chalubo downloader connection 
(1:48281:3)
Session  : :37596 -> 64.50.233.100:80

[*] 0 more events originated from this Source IP

+---+
| Destination Port  Count
+---+
   80  1

+---+
|   Source IP  Count
+---+

   1

Experimenting with manual downloads of eg http://google.com/libsdes suggests 
that any URL containing libsdes is blocked.
Using https appears to be a work around.


-- System Information:
Debian Release: 9.12
  APT prefers oldstable-updates
  APT policy: (990, 'oldstable-updates'), (990, 'oldstable'), (500, 
'oldstable-debug'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libsdes4j-java depends on:
ii  libcommons-codec-java  1.10-1

libsdes4j-java recommends no packages.

Versions of packages libsdes4j-java suggests:
pn  libsdes4j-java-doc  

Bug#855662: fakeroot: when msgrcv is interrupted by a signal, faked accidentally reprocesses the previous message

[Martin Dorey]

I've no reason to think that the patch I supplied here, some years ago now, was 
anything but a good idea, but it seems that my coworker Susi Berrington has 
found the real cause of my pain.  According to:

https://github.com/systemd/systemd/issues/2039 (Change default value of 
RemoveIPC in logind.conf)

... systemd is removing fakeroot's IPC objects when the user performing the 
build, which in this case are happening under cron, programmatically ssh()s 
into the headless build machine to check on the build status.  Argh!  It's been 
more than a month since we stopped that from happening, a blissful month 
without failures.

Bug#941619: ruby-odbc: ODBC dlopen regression in Debian 10

[Martin Dorey]

I've raised this bug again, in a hopefully more coherent way, as:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941707
ruby-odbc: [RubyODBC]Cannot allocate SQLHENV (ODBC::Error)

Sorry for the noise.

Bug#941707: ruby-odbc: [RubyODBC]Cannot allocate SQLHENV (ODBC::Error)

[Martin Dorey]

Package: ruby-odbc
Version: 0.8-1+b1
Severity: normal
Tags: patch

Dear Maintainer,

ruby-odbc does this, at least for me, on Buster:

martind@neutrino:~$ ruby -we 'require "odbc"; ODBC.drivers()'
Traceback (most recent call last):
1: from -e:1:in `'
-e:1:in `drivers': INTERN (0) [RubyODBC]Cannot allocate SQLHENV (ODBC::Error)
martind@neutrino:~$

The same test on the same configuration on Stretch is silent:

martind@scoot:~$ ruby -we 'require "odbc"; ODBC.drivers()'
martind@scoot:~$

I do have non-default /etc/odbc{,inst}.ini files but removing them doesn't 
affect this test.

Buoyed by a mention of Stretch here:

https://bugs.launchpad.net/raspbian/+bug/1832778

... I thought that maybe this blast from the past could have come back:

http://opensysblog.directorioc.net/2013/07/rubyodbccannot-allocate-sqlhenv.html

The change log in:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889025

... included:

   * Refresh 001extconf_dlopen.patch

Reverting that fixed the problem.
These are the steps I took:

aptitude source ruby-odbc
sudo aptitude install gem2deb
tar --xz -xf ruby-odbc_0.8-1.debian.tar.xz
debian/patches/ext_enable_dlopen.patch
cd ruby-odbc-0.8/
patch -p1 -R < ../debian/patches/ext_enable_dlopen.patch
dpkg-buildpackage -b -nc -uc
sudo dpkg -i ../ruby-odbc_0.8-1_amd64.deb

I can't say I understand why Debian would have to disable dlopen here.
But the package appears unusuable without that, for me.


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

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

Versions of packages ruby-odbc depends on:
ii  libc6   2.28-10
ii  libgmp102:6.1.2+dfsg-4
ii  libiodbc2   3.52.9-2.1
ii  libruby2.5  2.5.5-3
ii  ruby1:2.5.1
ii  ruby1.8 [ruby]  1.8.7.358-7.1+deb7u6
ii  unixodbc2.3.6-0.1

ruby-odbc recommends no packages.

ruby-odbc suggests no packages.

-- debconf-show failed

Bug#941564: /usr/lib/ruby/vendor_ruby/dbd/odbc/statement.rb:18: warning: constant ::Fixnum is deprecated

[Martin Dorey]

Package: ruby-dbd-odbc
Version: 0.2.5+gem2deb-1
Severity: normal

Dear Maintainer,

On Buster, which has Ruby >= 2.4, I see a warning from the first call of 
execute() on an ODBC statement handle.
I can reproduce this simply with:

martind@neutrino:~$ ruby -e 'require "dbd/ODBC"; handle = nil; statement = nil; 
param = 42; value = nil; attribs = nil; sth = 
DBI::DBD::ODBC::Statement.new(handle, statement); sth.bind_param(param, value, 
attribs)'
/usr/lib/ruby/vendor_ruby/dbd/odbc/statement.rb:18: warning: constant ::Fixnum 
is deprecated
martind@neutrino:~$

I don't know of any way to suppress the warning.
Well, I can get rid of it with a monkey patch:

require "dbd/ODBC"

class DBI::DBD::ODBC::Statement
def bind_param(param, value, attribs)
raise DBI::InterfaceError, "only ? parameters supported" unless 
param.is_a? Integer
@params[param-1] = value
end
end

That changes Fixnum to Integer.
My testing suggests that such a change works even on versions as old as Debian 
Lenny's Ruby 1.8.7.
I realize that this pacakge isn't maintained in Debian after Jessie.
I understand that's because it's not maintained upstream.
The replacement code, which I understand to be RDBI, doesn't install on Buster.
I've tried to raise that upstream as 
https://github.com/RDBI/rdbi-driver-odbc/pull/8.
Upstream there seems moribund too.
I'd like to make the monkey patch available to anyone else in the same 
situation.
Sorry for the noise.


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

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

Versions of packages ruby-dbd-odbc depends on:
ii  ruby  1:2.5.1
ii  ruby-dbi  0.4.5-3
ii  ruby-odbc 0.8-1
ii  ruby1.8 [ruby-interpreter]1.8.7.358-7.1+deb7u6
ii  ruby1.9.1 [ruby-interpreter]  1.9.3.194-8.1+deb7u8
ii  ruby2.1 [ruby-interpreter]2.1.5-2+deb8u7

ruby-dbd-odbc recommends no packages.

ruby-dbd-odbc suggests no packages.

-- debconf-show failed

Bug#870579: aren't CALLIT replies still going to come from a random port?

[Martin Dorey]

I've looked at the changes in 1.2.5-8 and I don't see how they'll make
rpcbind reply from port 111 like portmap used to.  If I'm right, then this
bug isn't fixed yet.  I just happened across a change that looks more
hopeful to me:

https://github.com/mendersoftware/poky/blob/master/meta/recipes-extended/rpcbind/rpcbind/rpcbind_add_option_to_fix_port_number.patch

I haven't tried it but it looks like it might let me set the port used to
111.

Bug#909064: libc6:amd64: getaddrinfo AF_INET6 behaves differently with nscd

[Martin Dorey]

Package: libc6
Version: 2.19-18+deb8u10
Severity: normal
Tags: upstream ipv6 patch

Dear Maintainer,

The behavior of the test program from 
https://bugzilla.redhat.com/show_bug.cgi?id=1416496
(titled "getaddrinfo() call returns wrong IPv6 address if nscd is used") when 
asked to
return the IPv6 address of my local system varies according to whether nscd is 
running.
I think that the configuration is reasonable but, when nscd is running, the 
program
fails to return any IPv6 address:

martind@swiftboat:~$ ~/download/getaddrinfo AF_INET6 swiftboat
Hints family=10
error in getaddrinfo: Name or service not known
martind@swiftboat:~$ 

However, when I stop nscd, a local IPv6 address is returned:

martind@swiftboat:~$ sudo /etc/init.d/nscd stop
[ ok ] Stopping nscd (via systemctl): nscd.service.
martind@swiftboat:~$ ~/download/getaddrinfo AF_INET6 swiftboat
Hints family=10
host=swiftboat, family=10 addr=fdca:f995:220a:8400:ec4:7aff:fe00:cf5c
host=swiftboat, family=10 addr=fdca:f995:220a:8400:ec4:7aff:fe00:cf5c
host=swiftboat, family=10 addr=fdca:f995:220a:8400:ec4:7aff:fe00:cf5c

martind@swiftboat:~$ 

The applicable line in /etc/nsswitch.conf is:

hosts:  files myhostname dns

I think this is the Debian base-files default as modified by the postinst from
libnss-myhostname, a recommendation of gnome-control-center, an (indirect)
dependency of task-gnome-desktop.

The only applicable line in /etc/hosts is:

127.0.1.1   swiftboat.us.dev.bluearc.comswiftboat

I think this is as suggested by the FQDN section in:

https://manpages.debian.org/jessie/hostname/dnsdomainname.1.en.html

Such a line causes hostname --fqdn to return the desired result.
There is no IPv6 address in /etc/hosts, but the host has a dynamically
determined IPv6 address known to libnss-myhostname.

Looking at the interface between glibc and nscd, the client side of which
I think is in sysdeps/posix/getaddrinfo.c's gaih_inet(), where it calls
__nscd_getai, I don't think nscd gets told what address family flags the
application passed to glibc.  I think nscd does pay correct attention to
nsswitch.conf, perhaps in the no_more loop in nscd/aicache.c's addhstaiX(),
but (correctly) stops on the first provider that returns any result.
In the case of my configuration, that's "files".  The one result returned
there is IPv4, so is discarded by glibc's nscd client leaving no result
to be returned.

If I put "myhostname" before "files" in /etc/nsswitch.conf, then this test
works perfectly but hostname --fqdn returns an unqualified name.
If I put an IPv6 address in /etc/hosts, then this test works perfectly and
I still have a FQDN, but that's inconvenient for a host whose IPv6 address
is dynamic.

Perhaps it's unusual to ask for a IPv6 address specifically from getaddrinfo,
but that's a useful way to determine a local IPv6 endpoint.
For a minority-interest query like that, perhaps it would be acceptable to
forego the full performance benefit of nscd's caching?
I contrived the attached patch on this assumption and saw that it passes this
test.

Apologies for submitting a bug report on such an old version of the code.
I haven't tried to patch any other version but I do see the problem on
Wheezy and Stretch systems as well as Jessie ones.
I think the upstream source would behave the same, but I haven't
experimentally verified that.
Upstream's bug submission guide:

https://sourceware.org/glibc/wiki/FilingBugs

... requested that I submit the issue to Debian first.
I was happy to do that not least because I'm less confident about
upstream's recommended /etc/nsswitch.conf and /etc/hosts.


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

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

Versions of packages libc6:amd64 depends on:
ii  libgcc1  1:4.9.2-10+deb8u1

libc6:amd64 recommends no packages.

Versions of packages libc6:amd64 suggests:
ii  debconf [debconf-2.0]  1.5.56+deb8u1
ii  glibc-doc  2.19-18+deb8u10
ii  locales2.19-18+deb8u10

-- debconf-show failed
--- sysdeps/posix/getaddrinfo.c	2018-09-17 11:00:52.932314024 -0700
+++ /home/martind/tmp/D136297/getaddrinfo.c.after	2018-09-17 11:00:20.821731456 -0700
@@ -788,13 +788,14 @@
 
 		  free (air);
 
-		  if (at->family == AF_UNSPEC)
+		  if (at->family == AF_UNSPEC && req->ai_family == AF_UNSPEC)
 		{
 		  result = -EAI_NONAME;
 		  goto free_and_return;
 		}
 
-		  goto process_list;
+		  if (at->family != AF_UNSPEC)
+		goto process_list;
 		}
 	  else if (err == 0)
 		/* The database contains a negative entry.  */

Bug#895946: rake: LoadError from Get::Ext::RakeBuilder trying to find rake

[Martin Dorey]

Looking into this further, I see that it's just a particular case of a more 
general problem:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710814
rubygems-integration: fails to override bin_path

The raiser, nearly five years ago, appeared more confident than I am about 
where the solution should be.

Bug#895946: rake: LoadError from Get::Ext::RakeBuilder trying to find rake

[Martin Dorey]

Package: rake
Version: 10.5.0-2
Severity: normal

Dear Maintainer,

Installing a gem that contains mkrf_conf, for example the three year old "beta"
of unf, causes rubygems/ext/builder.rb to take its RakeBuilder code path,
rather than, for example, the ExtConfBuilder path that the last "release" 
version
of unf uses.  This RakeBuilder path, at least in Stretch's rubygems, doesn't 
work
with Debian's rake package, even 12.3.1-1 from Buster, failing like this:

martind@balance:/tmp$ sudo gem install --no-ri --no-rdoc --prerelease unf
Fetching: unf-0.2.0.beta2.gem (100%)
Building native extensions.  This could take a while...
ERROR:  Error installing unf:
ERROR: Failed to build gem native extension.

current directory: /newvar/lib/gems/2.3.0/gems/unf-0.2.0.beta2/ext
/usr/bin/ruby2.3 mkrf_conf.rb

current directory: /newvar/lib/gems/2.3.0/gems/unf-0.2.0.beta2/ext
/usr/bin/ruby2.3 -rubygems 
/usr/share/rubygems-integration/all/gems/rake-10.5.0/bin/rake 
RUBYARCHDIR=/var/lib/gems/2.3.0/extensions/x86_64-linux/2.3.0/unf-0.2.0.beta2 
RUBYLIBDIR=/var/lib/gems/2.3.0/extensions/x86_64-linux/2.3.0/unf-0.2.0.beta2
/usr/bin/ruby2.3: No such file or directory -- 
/usr/share/rubygems-integration/all/gems/rake-10.5.0/bin/rake (LoadError)

rake failed, exit code 1

Gem files will remain installed in /var/lib/gems/2.3.0/gems/unf-0.2.0.beta2 for 
inspection.
Results logged to 
/var/lib/gems/2.3.0/extensions/x86_64-linux/2.3.0/unf-0.2.0.beta2/gem_make.out
martind@balance:/tmp$ 

The RakeBuilder code path, visible early in:

https://github.com/rubygems/rubygems/blob/master/lib/rubygems/ext/rake_builder.rb

... tries to run rake from Gem.bin_path("rake", "rake").  That's:

martind@balance:~$ ruby -we 'puts(Gem.bin_path("rake", "rake"))'
/usr/share/rubygems-integration/all/gems/rake-10.5.0/bin/rake
martind@balance:~$ 

But the rake package only installs the binary as /usr/bin/rake.
That (upstream) source reveals a work-around: setting an environment variable,
"rake", to point to /usr/bin/rake.
That works for me.
Installing a later rake gem, with sudo gem install rake, as promoted by eg:

https://askubuntu.com/questions/872399/error-failed-to-build-gem-native-extension-when-trying-to-download-rubocop

... works too, but presumably the Debian package should work.
Perhaps you'd rather tackle this as an issue with the rubygems package.
It was just my guess that it would be less intrusive to tackle in rake.


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

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

Versions of packages rake depends on:
ii  ruby  1:2.3.3
ii  ruby1.8 [ruby-interpreter]1.8.7.358-7.1+deb7u5
ii  ruby1.9.1 [ruby-interpreter]  1.9.3.194-8.1+deb7u7
ii  ruby2.1 [ruby-interpreter]2.1.5-2+deb8u3

Versions of packages rake recommends:
ii  zip  3.0-11+b1

rake suggests no packages.

-- no debconf information

Bug#759533: alien: Converted rpm won't be installed on Fedora system

[Martin Dorey]

Following a similar report

, I found that much the same thing has been reported upstream as Generated
RPM files un-necessarily conflict with package "filesystem"
.  The raiser
supplied a fix which the "new" upstream maintainer seems to have accepted,
though the ticket is still open and there hasn't been a release in the
intervening year.

Bug#856439: fakeroot doesn't detect and handle message queue and semaphore id collision

[Martin Dorey]

On Fri, 3 Mar 2017 02:13:08 + Martin Dorey <martin.do...@hds.com> wrote: 
> I see a flaw in my patch that could lead to it closing the same id twice if 
> it has to retry twice - I should have reset the ids after cleanup().

Please find the fixed patch belatedly attached.  The problem fixed by this 
patch - the id collision - definitely wasn't what was causing my original 
problem.  Indeed, I convinced myself by experiment that the id collision is as 
vanishingly rare in practice as you might expect in theory.  My original 
problem continues unabated in Debian Stretch - sufficiently frequently to be 
annoying but not frequently enough to be tractable.  On at least one occasion, 
the failure struck a semaphore-using program of our own devising that wasn't 
fakeroot, making me think that I won't be back here with a final answer.  In 
order to stop wasting time on this, I've just given in to the temptation of 
putting a retry loop round the failing operation.


faked.c.patch2
Description: faked.c.patch2

Bug#869705: debmirror: dists/wheezy-proposed-updates/Release fails gpg validation

[Martin Dorey]

tags 869705 fixed
stop

The last record I have of these errors was 2017-07-30.  The times on the 
Release and Release.gpg files at 
http://ftp.debian.org/debian/dists/wheezy-proposed-updates/ are now the same.  
Sorry for the noise.

Bug#650425: Please add options to set the port range for nfs clients

[Martin Dorey]

Christoph Anton Mitterer wrote, regarding rpcbind, some four years ago:

> It seems to always reserve one random (not 873) port in addition... why 
> does it do so at all? 

I think it's used to make remote "callit" requests, to receive their 
asynchronous replies and to forward those replies onto the original requester.  
Portmap used to fork() to do this synchronously.  More at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870579: rpcbind callit 
replies from a random reserved udp port, making firewalling hard

Sorry for dredging up this old news but perhaps someone's still interested.

Bug#870579: rpcbind callit replies from a random reserved udp port, making firewalling hard

[Martin Dorey]

Package: rpcbind
Version: 0.2.0-8
Severity: normal

Dear Maintainer,

I just upgraded a NIS server from Squeeze to Wheezy, hence from portmap to 
rpcbind.
Yes, I know it's 2017 and there's Jessie, if not Stretch :).
Some of that server's clients stopped being able to find it with ypbind's 
broadcast.
ypbind appears to send a subnet broadcast CALLIT request to port 111
for the YPSERV program's DOMAIN_NON_ACK procedure.
These clients were firewalled.
They had a hole allowing udp traffic from port 111.
portmap's replies were coming from port 111.
All was good.
rpcbind's replies come from another reserved udp port.
That doesn't have a firewall hole.
All is no longer good.
This port is picked at seeming random when rpcbind starts.
The variation makes firewalling difficult.
I've looked at the source and I'm confident that it's behaving as designed.
The design just seems... a little unfortunate.
It seems to predate the current upstream, which started with:

http://git.linux-nfs.org/?p=steved/rpcbind.git;a=blob;f=src/rpcb_svc_com.c;hb=f4aea95069461d06bd8a13e189e1a77e9ca03d75

Indeed, I see the problem looks to be there in Wietse Venema's 
rpcbind_2.1.tar.gz at:

http://ftp.porcupine.org/pub/security/index.html

But not in his portmap_5beta.tar.gz.
I conclude that Sun bequeathed it to us like this.
I wonder if the reason for all that extra code was
to remove the fork() that the portmap implementation used.

I doubt I could persuade anyone to change the design even if I tried.
I raise this, then, just to document the issue for the next poor sap to be 
tripped up by it.
Upstream's bug database:

https://sourceforge.net/p/rpcbind/bugs/?source=navbar

... seemed more moribund than Debian's.

The extra open udp and udp6 ports might have caused the intermittent failures
culminating in an expression of security concern at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650425#25

... and the puzzlement at:

https://stackoverflow.com/questions/35783145/why-is-rpcbind-opening-a-new-and-different-port-anytime-its-restarted

When I found:

https://www.illumos.org/issues/4483: rpcbind: Reply for remote calls comes from 
incorrect UDP port

I thought someone else had already fixed it.
But having plowed through the large patch there, I don't see how it would fix 
that.
Perhaps I missed something.

Our ref: D131248.

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

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

Versions of packages rpcbind depends on:
ii  initscripts  2.88dsf-41+deb7u1
ii  insserv  1.14.0-5
ii  libc62.13-38+deb7u11
ii  libtirpc10.2.2-5
ii  libwrap0 7.6.q-24
ii  lsb-base 4.1+Debian8+deb7u1

rpcbind recommends no packages.

rpcbind suggests no packages.

-- debconf-show failed

Bug#869705: debmirror: dists/wheezy-proposed-updates/Release fails gpg validation

[Martin Dorey]

Package: debmirror
Version: 1:2.25
Severity: normal

Dear Maintainer,

Bad me - I'm deliberately raising this bug against the wrong package.
My Google fu has been too weak to determine how to report problems with the 
archive.
Colin's always been so helpful in the past.
I'm sorry for abusing his kindness.
Hopefully he can steer this in the right direction without any great effort.

A few days ago, our local mirror started producing these messages:

[  0%] Getting: dists/wheezy-proposed-updates/Release.gpg... ok
[GNUPG:] BADSIG 8B48AD6246925553 Debian Archive Automatic Signing Key 
(7.0/wheezy) 
gpgv: Signature made Thu 20 Jul 2017 07:31:09 AM PDT using RSA key ID 46925553
gpgv: BAD signature from "Debian Archive Automatic Signing Key (7.0/wheezy) 
"
gpgv: Signature made Thu 20 Jul 2017 07:31:09 AM PDT using RSA key ID 46925553
gpgv: BAD signature from "Debian Archive Automatic Signing Key (7.0/wheezy) 
"
.temp/.tmp/dists/wheezy-proposed-updates/Release.gpg signature does not verify.

Manual verification showed that they the file really does fail verification.
Manual downloading showed that it was downloaded correctly.
Looking at some approximation to the ultimate upstream:

http://ftp.debian.org/debian/dists/wheezy-proposed-updates/

I see the time on the .gpg file is almost six hours before the time on the file 
being signed.
I guess the signature is out-of-date then.
I'm being spammed every day by some code alleging a potential security issue.
I've just realized that the code scraping the debmirror log to do that is a 
local invention.
That might explain why I couldn't find an existing report of this issue.
Perhaps it's unimportant but I thought I should raise it somewhere.


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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages debmirror depends on:
ii  bzip2   1.0.6-4
pn  libdigest-md5-perl  
ii  liblockfile-simple-perl 0.208-1
ii  libnet-inet6glue-perl   0.5-1
ii  libwww-perl 6.04-1
ii  perl [libdigest-sha-perl]   5.14.2-21+deb7u2
ii  perl-modules [libnet-perl]  5.14.2-21+deb7u2
ii  rsync   3.0.9-4

Versions of packages debmirror recommends:
ii  ed 1.6-2
ii  gpgv   1.4.12-7+deb7u3
ii  patch  2.6.1-3

Versions of packages debmirror suggests:
ii  gnupg  1.4.12-7+deb7u3

-- debconf-show failed

Bug#863007: half a gig of nonsense in /usr/share/doc/openjdk-7-jre-headless/test-amd64

[Martin Dorey]

This is probably a useless me-too.  Sorry if so, but there aren't any yet, so 
it might look like it's only the OP.  It's not.  I saw the same on two machines 
today, the smaller upgrade being from 7u121-2.6.8-2~deb8u1 to 
7u131-2.6.9-2~deb8u1.  My attention was drawn to the system by the impressive 
number of minutes it was taking to install something that normally only takes a 
handful of seconds.  strace on the dpkg process at the top of top(1) revealed 
where it was in the tree.  Ah, I think I see the fix on the way, from 
http://metadata.ftp-master.debian.org/changelogs/main/o/openjdk-7/openjdk-7_7u131-2.6.9-3_changelog:

openjdk-7 (7u131-2.6.9-3) experimental; urgency=medium

  * Only include the failing tests in the packages, not the whole test world.
  * openjdk-7-jdk: Provide openjdk-7-jdk-headless.

 -- Matthias Klose   Sat, 20 May 2017 15:52:17 -0700

Thanks!

Bug#866238: debmirror: failed to remove stale InRelease file for Stretch

[Martin Dorey]

Package: debmirror
Version: 1:2.25
Severity: normal

Dear Colin and co,

Before manual intervention to work around this issue, our two Debian mirrors
had files debian/dists/stretch/InRelease, starting like this:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Origin: Debian
Label: Debian
Suite: testing
Codename: stretch
Changelogs: 
http://metadata.ftp-master.debian.org/changelogs/@CHANGEPATH@_changelog
Date: Sat, 17 Jun 2017 02:40:32 UTC
Valid-Until: Sat, 24 Jun 2017 02:40:32 UTC
Acquire-By-Hash: yes
Architectures: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x
Components: main contrib non-free
Description: Debian x.y Testing distribution - Not Released
MD5Sum:
 f9bbab6d94f45e56c672017d8720a24c  1181459 contrib/Contents-amd64

Everything was working last week.
This week - so after the Valid-Until date expired - a Stretch installation was 
reported
as failing with:

[!!] Configure the package manager

The installer failed to access the mirror. This may be a problem with your 
network, or with the mirror. You can choose to retry the download, select a 
different mirror, or ignore the problem and continue without all the packages 
from this mirror.

Downloading a file failed:

Retry
Change mirror
Ignore

A packet capture on our mirror showed the following transaction:

No. Abs. Time  TCP #  SourceDestination 
  Protocol Info 
  4 16:52:56.1977970  172.16.222.36 10.72.41.18 
  HTTP GET /debian/dists/stretch/InRelease HTTP/1.1 
  6 16:52:56.1993880  10.72.41.18   172.16.222.36   
  HTTP HTTP/1.1 416 Requested Range Not Satisfiable  (text/html)
  8 16:52:56.2000190  172.16.222.36 10.72.41.18 
  HTTP GET /debian/dists/stretch/InRelease HTTP/1.1 
 60 16:52:56.2039810  10.72.41.18   172.16.222.36   
  HTTP HTTP/1.1 200 OK 

An apt-get update, on a different, existing Stretch installation, failed with:

E: Release file for http://debian-mirror/debian/dists/stretch/InRelease is 
expired (invalid since 3d 15h 0min 58s). Updates for this repository will not 
be applied.

Investigation upstream from there showed that the file had disappeared.
We renamed it aside locally.
Everything started working.
It would have been nice if debmirror had removed the obsoleted and now 
seemingly harmful file.
Perhaps that would be hard.
Manual recovery was easy, once we had a diagnosis
So I post this more in the hope of helping others with the same symptom.
Our-ref: D130753


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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages debmirror depends on:
ii  bzip2   1.0.6-4
pn  libdigest-md5-perl  
ii  liblockfile-simple-perl 0.208-1
ii  libnet-inet6glue-perl   0.5-1
ii  libwww-perl 6.04-1
ii  perl [libdigest-sha-perl]   5.14.2-21+deb7u2
ii  perl-modules [libnet-perl]  5.14.2-21+deb7u2
ii  rsync   3.0.9-4

Versions of packages debmirror recommends:
ii  ed 1.6-2
ii  gpgv   1.4.12-7+deb7u3
ii  patch  2.6.1-3

Versions of packages debmirror suggests:
ii  gnupg  1.4.12-7+deb7u3

-- debconf-show failed

Bug#856439: fakeroot doesn't detect and handle message queue and semaphore id collision

[Martin Dorey]

I've had a failure with the same symptom from a patched build.  I see a flaw in 
my patch that could lead to it closing the same id twice if it has to retry 
twice - I should have reset the ids after cleanup().  I don't see how that 
could explain the remaining issue.  Perhaps there's something else in the 
system randomly removing message queue ids.  That sounds like fun to track down 
:(.

Bug#855662: fakeroot: when msgrcv is interrupted by a signal, faked accidentally reprocesses the previous message

[Martin Dorey]

> A new bug is better

Agreed:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856439 (
fakeroot doesn't detect and handle message queue and semaphore id collision

Bug#856439: fakeroot doesn't detect and handle message queue and semaphore id collision

[Martin Dorey]

Package: fakeroot
Version: 1.20.2-1
Severity: normal
Tags: patch

Dear Maintainer,

I'm raising this as requested by Clint in:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855662#15

Fixing that bug (fakeroot: when msgrcv is interrupted by a signal, faked
accidentally reprocesses the previous message) stopped faked from overwriting
errno, which led me to realize that my intermittent failure problem while
building several packages at once might always be due to EIDRM.  (I only had
one failure with the patched version from that bug before contriving the patch
I submit here, so I don't have a big sample size.)  That led me to realize
that faked is, by default, inventing a random number on which to base its
message queue and semaphore ids.  When it then creates the message queues and
semaphore, it doesn't check for collisions.  Here I present a patch that I
hope detects that situation and retries.  I haven't seen a failure with this
patch, but I've only been running with it since last Friday.  I was previously
seeing as little as one failure per week.  I also haven't attempted the obvious
change to fail visibly in this case, which would have given me confidence that
the diagnosis was right.  I don't know why some of build machines seem more
vulnerable than others.  I don't know why I've only seen this since they were
upgraded to Jessie.  I based the patch supplied here on:

https://anonscm.debian.org/cgit/users/clint/fakeroot.git/

I wasn't sure whether Clint was asking me to base it instead on some upstream
branch.  That was at least due to the corporate email link mangler but I'm
quite new to git and Debian packaging.  This isn't the version I'm running,
which is instead based on the Jessie version.  I'm open to persuasion for
other experiments.


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

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

Versions of packages fakeroot depends on:
ii  libc62.19-18+deb8u7
ii  libfakeroot  1.20.2-1

fakeroot recommends no packages.

fakeroot suggests no packages.

-- no debconf information
diff --git a/faked.c b/faked.c
index a0f92ca..d280668 100644
--- a/faked.c
+++ b/faked.c
@@ -1305,6 +1305,7 @@ int main(int argc, char **argv){
 #ifndef FAKEROOT_FAKENET
   union semun sem_union;
   int justcleanup = 0;
+  int msgflag = IPC_CREAT|0600;
 #else /* FAKEROOT_FAKENET */
   int sd, val;
   unsigned int port = 0;
@@ -1375,29 +1376,42 @@ int main(int argc, char **argv){
 
 #ifndef FAKEROOT_FAKENET
 
-  if(!msg_key) {
-srandom(time(NULL)+getpid()*33151);
-while(!msg_key && (msg_key!=-1))  /* values 0 and -1 are treated
-	 specially by libfake */
-  msg_key=random();
-  }
+  do {
+if(!msg_key) {
+  msgflag |= IPC_EXCL;
+  srandom(time(NULL)+getpid()*33151);
+  while(!msg_key && (msg_key!=-1))  /* values 0 and -1 are treated
+   specially by libfake */
+msg_key=random();
+}
 
-  if(debug)
-fprintf(stderr,"using %li as msg key\n",(long)msg_key);
+if(debug)
+  fprintf(stderr,"using %li as msg key\n",(long)msg_key);
+
+msg_get=msgget(msg_key,msgflag);
+if (msg_get != -1)
+  msg_snd=msgget(msg_key+1,msgflag);
+if (msg_snd != -1)
+  sem_id=semget(msg_key+2,1,msgflag);
+
+if((msg_get==-1)||(msg_snd==-1)||(sem_id==-1)){
+  if (errno == EEXIST) {
+if(debug)
+  fprintf(stderr,"using %li as msg key caused a collision, trying again\n",(long)msg_key);
+cleanup(-1);
+msg_key = 0;
+continue;
+  }
+  perror("fakeroot, while creating message channels");
+  fprintf(stderr, "This may be due to a lack of SYSV IPC support.\n");
+  cleanup(-1);
+  exit(1);
+}
+  } while(msg_key == 0);
 
-  msg_get=msgget(msg_key,IPC_CREAT|0600);
-  msg_snd=msgget(msg_key+1,IPC_CREAT|0600);
-  sem_id=semget(msg_key+2,1,IPC_CREAT|0600);
   sem_union.val=1;
   semctl (sem_id,0,SETVAL,sem_union);
 
-  if((msg_get==-1)||(msg_snd==-1)||(sem_id==-1)){
-perror("fakeroot, while creating message channels");
-fprintf(stderr, "This may be due to a lack of SYSV IPC support.\n");
-cleanup(-1);
-exit(1);
-  }
-
   if(debug)
 fprintf(stderr,"msg_key=%li\n",(long)msg_key);
 

Bug#855662: fakeroot: when msgrcv is interrupted by a signal, faked accidentally reprocesses the previous message

[Martin Dorey]

> Good luck.

Sadly, after several days of parallel package building later, I've had another 
failure.  Happily, now errno's been preserved by my previous patch, I have A 
New Clue:

FAKEROOT: r=-1, received message type=1, message=3
FAKEROOT, get_msg: Identifier removed
errno=43, EINTR=4

On this system, that's:

martind@ussw-cbld00:~$ grep -w 43 /usr/include/asm-generic/errno.h 
#define EIDRM   43  /* Identifier removed */
martind@ussw-cbld00:~$

Now through early evening fog I see that the message queues and the semaphore 
are being generated with a random key.  Collisions with existing keys aren't 
detected.  I have a patch that I hope will detect that and retry.  Would you 
like that here or in a new bug?  Including the first patch or assuming it's 
applied first or against the baseline version?  Any way is easy for me.  I 
imagine the BTS will just do the right thing with a text attachment but five 
minutes of googling hasn't confirmed that's how to submit a patch to an 
existing Debian bug.  Waiting a week for the patch to dis/prove itself would be 
perfectly sensible, but I'm happy to embarrass myself if you're happy to look 
at it before then.

Bug#855662: fakeroot: when msgrcv is interrupted by a signal, faked accidentally reprocesses the previous message

[Martin Dorey]

Package: fakeroot
Version: 1.20.2-1
Severity: normal
Tags: patch

Dear Maintainer,

I'm trying to track down an intermittent failure that originally presented like 
this:

dh_md5sums 
dh_builddeb -- -Znone 
dpkg-deb: building package `mercury-main-4604p00p1099' in 
`../mercury-main-4604p00p1099_14.1.4604.00.1099_amd64.deb'. 
dpkg-deb: building package `mercury-main-4604p00p1099-dbg' in 
`../mercury-main-4604p00p1099-dbg_14.1.4604.00.1099_amd64.deb'. 
semop(1): encountered an error: Invalid argument 
debian/rules:57: recipe for target 'binary-arch' failed 
make[8]: *** [binary-arch] Error 1 
/usr/bin/fakeroot: line 1: kill: (6633) - No such process 
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 

I've got fakeroot now lashed up to run with debugging.
Now the presentation is like this:

FAKEROOT: r=320, received message type=1, message=3
FAKEROOT: process stat oldstate=dev:ino=(801:1661605), mode=0100644, own=(0,0), 
nlink=1, rdev=0
FAKEROOT:(previously unknown)
FAKEROOT: r=320, received message type=1, message=3
FAKEROOT: process stat oldstate=dev:ino=(801:1300078), mode=0100644, own=(0,0), 
nlink=1, rdev=0
FAKEROOT:(previously unknown)
semop(1): encountered an error: Invalid argument
debian/rules:57: recipe for target 'binary-arch' failed
make[8]: *** [binary-arch] Error 1
make[8]: Leaving directory 
'/u/u645/usdevadmin/work/dragon/1/packages/debian/mercury/ip6tables/x86_64_linux_libc-2.19_release/mercury-ip6tables-4604p00p1099'
FAKEROOT: r=-1, received message type=1, message=3
FAKEROOT: process stat oldstate=dev:ino=(801:1300078), mode=0100644, own=(0,0), 
nlink=1, rdev=0
FAKEROOT:(previously unknown)
libfakeroot, when sending message: Invalid argument
FAKEROOT, get_msg: Invalid argument
r=22, EINTR=4
fakeroot: clearing up message queues and semaphores, signal=-1
/usr/bin/fakeroot: line 1: kill: (4317) - No such process
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2

The r=22, EINTR=4 line is telling me that whatever last set errno had got 
EINVAL:

/usr/include/asm-generic/errno-base.h:#defineEINVAL22   
 /* Invalid argument */

I notice above that, even though msgrcv failed, faked called process stat
with the same arguments as given in the previous message.
The indentation of the source suggests that this was not the author's intent.
It seems unlikely to be correct.
Seeing this seeming bug still present in:

https://anonscm.debian.org/cgit/users/clint/fakeroot.git/tree/faked.c

I enclose a patch to address that.
I don't know at this juncture whether it fixes my original problem.
I doubt it but fingers crossed.


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

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

Versions of packages fakeroot depends on:
ii  libc62.19-18+deb8u6
ii  libfakeroot  1.20.2-1

fakeroot recommends no packages.

fakeroot suggests no packages.

-- no debconf information
--- faked.c.orig	2017-02-20 16:59:47.614272988 -0800
+++ faked.c	2017-02-20 17:01:06.274709158 -0800
@@ -1079,13 +1079,14 @@
 r=msgrcv(msg_get,,sizeof(struct fake_msg),0,0);
 if(debug)
   fprintf(stderr,"FAKEROOT: r=%i, received message type=%li, message=%i\n",r,buf.mtype,buf.id);
-if(r!=-1)
+if(r!=-1) {
   buf.remote = 0;
   process_msg();
+}
   }while ((r!=-1)||(errno==EINTR));
   if(debug){
 perror("FAKEROOT, get_msg");
-fprintf(stderr,"r=%i, EINTR=%i\n",errno,EINTR);
+fprintf(stderr,"errno=%i, EINTR=%i\n",errno,EINTR);
   }
 }
 

Bug#855441: tigervnc-xorg-extension redraw issues

[Martin Dorey]

Package: tigervnc-xorg-extension
Version: 1.7.0+dfsg-2
Severity: normal

Dear Maintainer,

I'd really like to be able to connect to :0 on my work computer from
home.  I used to do that with vino and gnome-fallback on Wheezy.  The
full Gnome 3 experience is slow and generates several Mbit/s of network
traffic with vino.  TigerVNC seems like the way of the future.  If I
start a dedicated TigerVNC server on :1, then it works great.  But I
think I need tigervnc-xorg-extension to connect to my Nvidia-based :0.
When I connect to :0, however, my client display often isn't completely
updated when the server display changes.  I have to play games dragging
selections, moving windows or asking the client to ask for a complete
refresh to see what's going on.

I initially tried TigerVNC 1.6.0 on Jessie, as Jessie is what I really
need to work.  Antipating that you won't care about that smelly old
lashup, I then tried TigerVNC 1.7.0 on Stretch, again with Nvidia's
proprietary driver.  Same behavior.  Now I've also tried a cleaner
install of Stretch with Intel integrated graphics, again Gnome 3, again
TigerVNC 1.7.0.  I think I'm seeing the same behavior, although here I
don't have the same sort of clients.  Connecting back to the same system
with tigervncviewer gets me:

 CConn:   End of stream

On the second and subsequent attempts, that's prefixed by:

Server sent us an invalid screen layout

I tried - and succeeded in - connecting with Chicken of the VNC, an
ancient Mac OS VNC client.  I think I had the cursor stuck in the top
left bug there, but also I wasn't seeing output that I initiated on
the server.  I tried - and again succeeded - in connecting with a
RealVNC client on iPhone, probably both reasonably uptodate.  Again,
server-initiated changes were not displayed on the client.

I had previously suggested that I'd try with "nouveau" instead of nvidia
drivers but there seems little point when I see what's probably the same
behavior on this other system with Intel graphics.  Now I'm at something
of a loss.  I skimmed through the titles of everything in upstream's
issue tracker without seeing anything that grabbed me as relevant (and
obviously Googled too).

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

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

Versions of packages tigervnc-xorg-extension depends on:
ii  libaudit1  1:2.6.7-1
ii  libc6  2.24-8
ii  libgcc11:6.2.1-5
ii  libpam0g   1.1.8-3.5
ii  libstdc++6 6.2.1-5
ii  xserver-xorg-core  2:1.19.0-3

Versions of packages tigervnc-xorg-extension recommends:
ii  tigervnc-common  1.7.0+dfsg-2

tigervnc-xorg-extension suggests no packages.

-- no debconf information

Bug#855350: tigervnc-xorg-extension: Loading the tigervnc the extension makes the x server practically unusable

[Martin Dorey]

> i could not find a way to actually pass options

I eventually managed to get a default configured Stretch box to accept a
remote connection using:

mad@shuttle:~$ cat /usr/share/X11/xorg.conf.d/75-vnc-mad.conf
Section "Device"
Identifier "Device"
EndSection
Section "Screen"
Identifier "Screen"
Device "Device"
Option "PasswordFile" "/u2/home/mad/.vnc/passwd"
EndSection
mad@shuttle:~$

It seems, from the source, that the PasswordFile Option is only looked for
in the Screen section and the Screen section has to have an Identifier and
a Device, which has to refer to a Device section, which needs an
Identifier.  Argh, but, OK, whatever.  Then I have other problems, both
keeping the connection up and with redraw, but I fear that elaborating them
here would be a hijack of the OP's bug, the main symptom of which - a
horrible-sounding performance issue - I don't see with Gnome 3.

Bug#851842: [Pkg-tigervnc-devel] Bug#851842: Bug#851842: Bug#851842: tigervnc-xorg-extension - libvnc.so fails to load with undefined symbol: gnutls_bye

[Martin Dorey]

Does a patch --dry-run after the build offer to use -R?  I bet not, meaning
the patch has been lost.  Upstream's intention is to patch files that are
generated.

Bug#851842: [Pkg-tigervnc-devel] Bug#851842: tigervnc-xorg-extension - libvnc.so fails to load with undefined symbol: gnutls_bye

[Martin Dorey]

On Fri, 20 Jan 2017 22:10:29 +0100 Ola Lundqvist  wrote:
> I have now been able to reproduce the problem. It is not solved by
> merely adding more dependencies. I have to look further to find the
> cause of the problem.

Hey Ola,

I think I can help.  First, though, I'm delighted to see that your ITP for
tigervnc went through for Stretch.  But is that still a default -depth of
32 I see - how are the poor users going to work out that they need to try
-depth 24, per the warning in man xtigervnc, to get their, eg Java, text
rendered properly?  Anyway, I think the problem here has the same cause as
the similar one described by:

https://github.com/TigerVNC/tigervnc/issues/294: unable to load libvnc.so
after installing 1.5.x or 1.6.0

I had another great experience with tigervnc-standalone-server this
weekend, which lets me connect to Gnome 3 over a metro area as if I were in
the office, in contrast to vino, where I have to tolerate several megabits
per second of background traffic when idle, making interactivity unusably
slow.  Thus I wanted to replace vino with tigervnc-xorg-extension on the :0
of my just-upgraded-to-Jessie server.  I faced:

[238863.164] (EE) Failed to load
/usr/lib/xorg/modules/extensions/libvnc.so:
/usr/lib/xorg/modules/extensions/libvnc.so: undefined symbol:
gnutls_transport_set_ptr2

... which looks exactly like part of upstream's problem.  On a Stretch
system, with Debian's (yay!) native packaging, I see the gnutls_bye symptom
instead.  If I rebuild your Sid packaging, from apt-get source tigervnc,
with:

mad@shuttle:~/tigervnc-1.7.0+dfsg$ dpkg-buildpackage -nc -uc -us

... then apply upstream's patch, in my so very crude fashion, using what I
think, having looked it up, is the shiniest flavor of Ubuntu that upstream
supports:

mad@shuttle:~/tigervnc-1.7.0+dfsg$ (cd unix/xserver && patch -p1 <
../../contrib/packages/deb/ubuntu-xenial/debian/xorg-source-patches/debian_libtool.patch)
checking file ltmain.sh
Hunk #1 succeeded at 7893 (offset 3 lines).
checking file ltmain.sh
Hunk #1 succeeded at 7571 (offset 3 lines).
checking file m4/libtool.m4
Hunk #1 succeeded at 4947 (offset 11 lines).
Hunk #2 succeeded at 5009 (offset 14 lines).
Hunk #3 succeeded at 5784 (offset 17 lines).
mad@shuttle:~/tigervnc-1.7.0+dfsg$

As you see, I get a reasonably clean application, but libvnc.so didn't
rebuild when I repeated the dpkg-buildpackage command.  Oh, for the simple
days, when dependencies were complete and "make" was all you needed!  Just
removing the .so got me a build failure, causing more sadly grey-bearded
head-shaking, but removing the .la and .lai files too:

mad@shuttle:~/tigervnc-1.7.0+dfsg$ find . -name libvnc.* | xargs rm
mad@shuttle:~/tigervnc-1.7.0+dfsg$

... then repeating the dpkg-buildpackage command got me
a ./debian/tigervnc-xorg-extension/usr/lib/xorg/modules/extensions/libvnc.so
that, when used to replace
/usr/lib/xorg/modules/extensions/libvnc.so, effaces the (EE) error from
wherever ls -l /proc/$(pidof Xorg)/fd told me that the squirrels had buried
Xorg.0.log.  xdpyinfo now happily reports:

mad@shuttle:~$ xdpyinfo | grep VNC
VNC-EXTENSION
mad@shuttle:~$

Sorry to make such a meal of such a trivial nugget, but I want to convey
how little I understand.  Now, if you'll excuse me, I'm off to try to
similarly brutalize the old Jessie packaging of tigervnc 1.6.0, if I still
have it lying around, to see if I can get back in to :0 on the server that
I actually care about...

Bug#737155: work-around for ntpq -p truncation

[Martin Dorey]

I think we can call this fixed by upstream's addition of support for -w:

(4.2.7p461) 2014/08/14 Released by Harlan Stenn 
* [Bug 1128] ntpq truncates "remote" host information.

https://bugs.ntp.org/show_bug.cgi?id=1128: ntpq -n output truncates IPv6 
addresses

... perhaps taking Ubuntu's patch:

https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/325111: ntpq output 
truncates IPv6 addresses

The fix is in Stretch, where I see addresses too wide for the "remote" field 
being given a line of their own when -w is added to ntpq -pn.

Bug#831322: debmirror consistently failing on unlink step for files in dep11 directory

[Martin Dorey]

Not the same file every day and a second run immediately after the first 
failure succeeds for me, on the three occurrences that I've noticed so far, 
making it just a minor issue for me.  It might have been happening to me every 
day for a while but any earlier failures will have been obscured by the 
excessive logging I added when I was experiencing 
https://bugs.launchpad.net/ubuntu/+source/debmirror/+bug/1562118.

Bug#827132: debhelper: make-4.2 renamed --jobserver-fds to --jobserver-auth causing parallel build issues

[Martin Dorey]

Package: debhelper
Version: 9.20120909
Severity: normal

Dear Maintainer,

The make-4.2 announcement at 
https://lists.gnu.org/archive/html/info-gnu/2016-05/msg00013.html includes [

* The interface to GNU make's "jobserver" is stable as documented in the
  manual, for tools which may want to access it.

  WARNING: Backward-incompatibility! The internal-only command line option
  --jobserver-fds has been renamed for publishing, to --jobserver-auth.

* The amount of parallelism can be determined by querying MAKEFLAGS, even when
  the job server is enabled (previously MAKEFLAGS would always contain only
  "-j", with no number, when job server was enabled).

].  Although I'm only testing with a Wheezy debhelper, I have looked at 
https://anonscm.debian.org/git/debhelper/debhelper.git/tree/Debian/Debhelper/Dh_Lib.pm
 and its call from 
https://anonscm.debian.org/git/debhelper/debhelper.git/tree/Debian/Debhelper/Buildsystem/makefile.pm
 and seen that the former mentions jobserver-fds but not jobserver-auth.  When 
make-4.2 reaches Debian, my experiments suggest that users, if there are any in 
this situation, intending to run serial make from debuild from parallel make 
will see the like of:

make[2]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.

If I've understood correctly, then that's an effective regression of the fix 
for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532805 (dh_auto_build: 
prevents make jobs from being run simultaneously).

I suffered a worse problem than a warning or unwanted serialization - my build 
broke, sometimes.  I doubt anyone else will ever see my very particular 
situation, but I'll explain in case.  My build system now uses 
/usr/local/bin/make-4.2.1 -j8 to invoke debuild, which appears to invoke 
/usr/bin/make, which, on my system, is Wheezy's make-3.81, to execute a 
proprietary makefile.  make-4.2.1 left -j8 in MAKEFLAGS and, because it used 
--jobserver-auth rather than --jobserver-fds, debhelper didn't know to remove 
the parallelism flags.  This exposed a previously latent race condition in the 
underlying proprietary makefile.  I've fixed that makefile, so now I happily 
have a working, if accidentally parallel build.

While it looks straightforward to s/jobserver-fds/jobserver-(?:fds|auth)/g, 
this line will also need attention to support the second make-4.2 bullet I 
quoted above:

$ENV{MAKEFLAGS} =~ s/(?:^|\s)-j\b//g;

... as it won't match the like of -j8.  Perhaps you'd be content to replace the 
\b with \d*\b to cope with both new and old versions of make.  Sorry for not 
supplying a patch, but it'd either be for the Wheezy debhelper or it'd be 
(probably) untested.  At least I'm realistic enough not to request a fix in 
Wheezy or Jessie.  I just want to make the diagnosis easier for the next poor 
sap.

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

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

Versions of packages debhelper depends on:
ii  binutils2.22-8+deb7u2
ii  dpkg1.16.16
ii  dpkg-dev1.16.16
ii  file5.11-2+deb7u8
ii  html2text   1.3.2a-15
ii  man-db  2.6.2-1
ii  perl5.14.2-21+deb7u2
ii  po-debconf  1.0.16+nmu2

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#654924: Re: Helping with tigervnc 1.5.0

[Martin Dorey]

I'm concerned why /etc/vnc.conf and /usr/bin/tigervncserver set a depth of 32.  
Per man Xtigervnc, that will cause problems for applications, problems that 
I've just described in a little more detail at 
http://stackoverflow.com/a/37428300/18096.  I think it should be 24, a setting 
which doesn't prevent applications from using transparency.

I'm also mildly bemused as to why /usr/bin/tigervncserver's default for 
-localhost is yes, again unlike the default for the underlying Xtigervnc.  I 
can imagine there being an argument that default security should be locked 
down.  Perhaps I'm just lacking in imagination as to why I might want to 
connect to localhost.

> Getting the llvmpipe part to work was a challenge.  I failed on the first 
> system I tried, which had an nvidia :0.

In the perhaps unlikely event that there's anyone in the same boat, I succeeded 
with:

sudo update-alternatives --set glx /usr/lib/mesa-diverted
sudo update-initramfs -u

... though I eventually went into production setting this before starting 
tigervncserver:

LD_LIBRARY_PATH=/usr/lib/mesa-diverted/x86_64-linux-gnu:$LD_LIBRARY_PATH

Bug#654924: Helping with tigervnc 1.5.0

[Martin Dorey]

On Tue, 26 Jan 2016 11:42:22 -0500 Geoffrey Thomas  
wrote:
> ... I
> built tigervnc 1.5.0 from git (4a25ccd) on jessie, with a no-change
> backport of fltk1.3 1.3.3-6

Thanks for this encouraging post.  Sadly, the build on Jessie seems to have 
broken since.  This fixed it for me:

diff --git a/debian/patches/fix-build-error-with-xserver-1.18.patch 
b/debian/patches/fix-build-error-with-xserver-1.18.p
index e9f29cf..390370d 100644
--- a/debian/patches/fix-build-error-with-xserver-1.18.patch
+++ b/debian/patches/fix-build-error-with-xserver-1.18.patch
@@ -2,11 +2,14 @@ Description: Fix build error with xorg xserver 1.18
 Author: Liang Guo 

Bug#737155: work-around for ntpq -p truncation

[Martin Dorey]

Looks like this was discussed upstream under 
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/325111, which contains a 
readvar work-around.

Bug#635317: now believed addressed upstream

[Martin Dorey]

http://savannah.gnu.org/bugs/?33034 was closed with
http://git.savannah.gnu.org/cgit/make.git/commit/?id=53b4a9e66800dde643d3ce7966c5193001e3f12e,
which seems to address the problem sufficiently in limited testing in my
Debian environment.  I imagine it will now be challenging to get several
years of upstream work integrated.  I've tested that it would fix at least
one other Important bug,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682895.

Bug#665408: tzdata: San Luis and Cairo wrongly show UTC

[Martin Dorey]

Package: tzdata
Version: 2011n-0lenny1
Severity: normal

On a server with tzdata 2009l-0lenny1:

dsatow@mercury11:~$ LANG= TZ=America/Argentina/San_Luis date
Thu Mar 22 21:41:43 WART 2012
dsatow@mercury11:~$ LANG= TZ=Africa/Cairo date
Fri Mar 23 03:41:55 EET 2012
dsatow@mercury11:~$

On a server with 2011n-0llenny1:

martind@whitewater:~$ LANG= TZ=America/Argentina/San_Luis date
Fri Mar 23 18:30:10 UTC 2012
martind@whitewater:~$ LANG= TZ=Africa/Cairo date
Fri Mar 23 18:30:11 UTC 2012
martind@whitewater:~$ 

WART and EET change to UTC.  I believe this to be incorrect.

This does not happen with the Squeeze libc and the same Lenny tzdata.
I suspect that this was the fix:

http://cygwin.com/ml/libc-alpha/2009-06/msg00102.html

This demonstrates that the problem applies to many zones:

for zone in `find /usr/share/zoneinfo/ -type f`
do
echo $zone; zdump -v $zone | tail -3 | head -1
done | grep UTC' isdst'

Most such zones will only be affected tens of years in the future.
The only zones, as of tzdata 2011k-0lenny1, that are currently affected are
San Luis, Cairo and Egypt.

All the affected zonefiles end with \x0A\x0A.
But not all the zonefiles ending in such a way are affected.
This casts doubt on my suspected fix.
All such exceptions are under the right/ tree:

martind@whitewater:~$ TZ=/usr/share/zoneinfo/right/America/Argentina/San_Luis 
date
Fri Mar 23 17:30:06 WARST 2012
martind@whitewater:~$ hexdump -C 
/usr/share/zoneinfo/right/America/Argentina/San_Luis | tail -2
0640  00 00 00 0a 0a|.|
0645
martind@whitewater:~$ 

I suspect, though, that the reason that appears to work is another bug, fixed 
here:

http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=6355c99740c91ed5a7fa14e378f74950e09f5f48

I think that would prevent the empty tzspec from being read, except in the case
where num_leaps is zero, explaining why that only afflicts the right/ tree.

Returning to the original bug, this came to afflict San Luis in 2010j-0lenny1.
2010f-0lenny1 didn't exhibit the problem.
It was a tzdata update, then, that led me to trip over the problem,
which is part of the reason for my reporting a libc6 bug against tzdata.
I don't expect, or even hope, for this to be fixed in Lenny.
I would just like the report available to search engines so that the next person
doesn't spend so long on it.
I'd also like to raise awareness of the (small) risk of updating tzdata without
updating libc6's tzfile code.

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

Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages tzdata depends on:
ii  debconf [debconf-2.0] 1.5.24 Debian configuration management sy

tzdata recommends no packages.

tzdata suggests no packages.

-- debconf information:
  tzdata/Zones/Australia:
  tzdata/Zones/Asia:
  tzdata/Zones/SystemV:
  tzdata/Zones/Pacific:
  tzdata/Zones/Atlantic:
  tzdata/Zones/US:
  tzdata/Zones/Etc:
  tzdata/Zones/Arctic:
  tzdata/Zones/Antarctica:
* tzdata/Zones/Europe: Paris
  tzdata/Zones/Africa:
* tzdata/Zones/America: Los_Angeles
* tzdata/Areas: America
  tzdata/Zones/Indian:



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#638256: race condition causes many syslog messages: File a[[:xdigit:]]{13} is in wrong format - aborting

[Martin Dorey]

Package: at
Version: 3.1.10.2
Severity: normal
Tags: patch

In my experience, when a file system fills up, it often seems that there's room
in the inode table when there's no room for file bodies.  Unintentionally empty
files become common.  If /var/spool/cron/atjobs ends up containing a zero-length
job file for a job due over an hour ago, then atd sometimes goes nuts, logging
an unbounded number of messages like:

2011-08-09T16:11:12-07:00 merc55rm atd[4194]: File a00afd014dc579 is in wrong 
format - aborting

Even when the original reason for the full file system is removed, atd can go
on to fill it again with gigabytes of syslog entries.

Google finds many similar complaints over the years:

http://goo.gl/rvdP6
http://ubuntuforums.org/archive/index.php/t-1575261.html
https://bugzilla.redhat.com/show_bug.cgi?id=718422
http://forums.fedoraforum.org/showthread.php?t=252412

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=101919 may have been the cause
of an apparently corrupted at job.  What I'm focusing on here is the manifold
repetition of the error message, assuming a corrupted at job.

On one particular machine, I was able to reproduce this, most of the time, with
this test:

sudo su -
cd /var/spool/cron/atjobs
/etc/init.d/atd stop
touch a0
chmod +x a0
grep -w atd /var/log/syslog | wc -l
/etc/init.d/atd start
sleep 1
grep -w atd /var/log/syslog | wc -l
sleep 1
grep -w atd /var/log/syslog | wc -l

The number of lines of atd message rises for a while, then stabilizes.

I wasn't able to reliably reproduce the issue on a couple of other machines,
including the one from which I'm reporting the bug, unless I started atd from
within valgrind:

valgrind --trace-children=yes -q /etc/init.d/atd start

An strace extract, available on request, from the system where I could easily
reproduce the problem, showed that atd stabilized when the child that logs
the aborting message exits before the main atd process goes to sleep.
If the parent wins the race, then the sleep is interrupted by SIGCHLD.  The
parent then calls run_loop again and the cycle repeats.

My suggested fix sleeps again if we're woken prematurely.

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

Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages at depends on:
ii  exim4 4.69-9+lenny4  metapackage to ease Exim MTA (v4) 
ii  exim4-daemon-heavy [mail- 4.69-9+lenny4  Exim MTA (v4) daemon with extended
ii  libc6 2.7-18lenny7   GNU C Library: Shared libraries
ii  libpam0g  1.0.1-5+lenny1 Pluggable Authentication Modules l
ii  lsb-base  3.2-20 Linux Standard Base 3.2 init scrip

at recommends no packages.

at suggests no packages.

-- no debconf information
--- /tmp/at-3.1.10.2/atd.c.orig 2011-08-16 19:14:41.0 -0700
+++ /tmp/at-3.1.10.2/atd.c  2011-08-16 19:15:54.0 -0700
@@ -792,11 +792,12 @@
 
 daemon_setup();
 
+now = time(NULL);
 do {
-   now = time(NULL);
next_invocation = run_loop();
-   if (next_invocation  now) {
+   while (!term_signal  next_invocation  now) {
sleep(next_invocation - now);
+   now = time(NULL);
}
 } while (!term_signal);
 daemon_cleanup();

Bug#628178: html2text: -width -1 is accepted but causes a crash with some Html

[Martin Dorey]

Package: html2text
Version: 1.3.2a-5
Severity: normal

Nowhere in the man page does it suggest that -width -1 is legal, so why am I 
using it?
Well, it seemed to work for me in one application, and saved my having to pick 
a magic number.
After all, html2text didn't say it was a usage error.
Then came another application and html2text crashed, having produced glibc heap 
corruption output.
After reducing the HTML to a minimal file, I see that html2text is trying to 
malloc for a width of -1.
On my amd64 system, that's been sign-extended to more memory than I have.
I wonder if html2text should refuse the argument, cap it at a sane value or 
just report the malloc failure in a more revealing way.

$ cat /tmp/corpus
html
head
/head
body
hr
/body
/html
$ valgrind --db-attach=yes ~/tmp/html2text-1.3.2a/html2text -width -1 
file://tmp/corpus
==28439== Memcheck, a memory error detector.
==28439== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==28439== Using LibVEX rev 1854, a library for dynamic binary translation.
==28439== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==28439== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation 
framework.
==28439== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==28439== For more details, rerun with: -v
==28439== 
==28439== Warning: silly arg (-2) to malloc()
==28439== Invalid write of size 1
==28439==at 0x41587F: Area::Area(unsigned long, unsigned long, char, char) 
(Area.C:177)
==28439==by 0x41EFC8: HorizontalRule::format(unsigned long, int) const 
(format.C:543)
==28439==by 0x418367: _ZL6formatPKSt4listI8auto_ptrI7ElementESaIS2_EEmmiRSo 
(format.C:1386)
==28439==by 0x41A024: Body::format(unsigned long, unsigned long, int, 
std::ostream) const (format.C:201)
==28439==by 0x41A175: Document::format(unsigned long, unsigned long, int, 
std::ostream) const (format.C:159)
==28439==by 0x403D98: MyParser::process(Document const) (html2text.C:110)
==28439==by 0x40E3A4: HTMLParser::yyparse() (HTMLParser.y:275)
==28439==by 0x403C22: main (html2text.C:378)
==28439==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==28439== 
==28439==  Attach to debugger ? --- [Return/N/n/Y/y/C/c]  y
==28439== starting debugger with cmd: /usr/bin/gdb -nw /proc/28444/fd/1014 28444
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 x86_64-linux-gnu...
Attaching to program: /proc/28444/fd/1014, process 28444
Reading symbols from /usr/lib/valgrind/amd64-linux/vgpreload_core.so...done.
Loaded symbols for /usr/lib/valgrind/amd64-linux/vgpreload_core.so
Reading symbols from /usr/lib/valgrind/amd64-linux/vgpreload_memcheck.so...done.
Loaded symbols for /usr/lib/valgrind/amd64-linux/vgpreload_memcheck.so
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /usr/lib/debug/libm.so.6...done.
Loaded symbols for /usr/lib/debug/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /usr/lib/debug/libc.so.6...done.
Loaded symbols for /usr/lib/debug/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols from 
/usr/lib/debug/lib/ld-2.7.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x0041587f in Area (this=0x5920638, w=18446744073709551615, h=1, c=61 
'=', a=0 '\0') at Area.C:177
177 while (p != end) { p-character = c; p-attribute = a; p++; }
(gdb) list
162 {
163 }
164 
165 Area::Area(
166   size_type w /*= 0*/ ,
167   size_type h /*= 0*/ ,
168   char  c /*= ' '*/ ,
169   char  a /*= Cell::NONE*/
170 ) :
171   width_(w),
172   height_(h),
173   cells_(malloc_array(Cell *, h))
174 {
175   for (size_type y = 0; y  h; y++) {
176 Cell *p = cells_[y] = malloc_array(Cell, w), *end = p + w;
177 while (p != end) { p-character = c; p-attribute = a; p++; }
178   }
179 }
180 
181 Area::Area(const char *p) :
182   width_(strlen(p)),
183   height_(1),
184   cells_(malloc_array(Cell *, 1))
185 {
186   cells_[0] = malloc_array(Cell, width_);
187   Cell *q = cells_[0], *end = q + width_;
188   while (q != end) { q-character = *p++; q-attribute = Cell::NONE; 
q++; }
189 }
190 
191 Area::Area(const string s) :
(gdb) bt
#0  0x0041587f in Area (this=0x5920638, w=18446744073709551615, h=1, 
c=61 '=', a=0 '\0') at Area.C:177
#1  0x0041efc9 in HorizontalRule::format (this=0x591fe00, 
w=18446744073709551615) at format.C:543
#2  0x00418368 in format (elements=0x591f6b8, indent_left=0, 
w=18446744073709551615, halign=0, 

Bug#616502: dpkg: malloc failed (-1739558537 bytes): Cannot allocate memory for file = 2 GiB

[Martin Dorey]

Package: dpkg
Version: 1.14.25
Severity: wishlist
Tags: patch

A debug version, packaged in the wrong way with embedded debugging information, 
of a non-Free and non-free, amd64-specific package contains a file whose size 
is larger than 2 GiB.  With the patched dpkg and full --debug output, I see 
this file reported as:

D10: ensure_pathname_nonexisting 
`/opt/mercury-main/8.1.2312.04/bin/mfb.elf.dpkg-tmp'
D000100: tarobject NormalFile[01] open size=2555408759

In hex, that's 0x98507177.  With the unpatched dpkg, this happens:

D10: ensure_pathname_nonexisting 
`/opt/mercury-main/8.1.2312.04/bin/mfb.elf.dpkg-tmp'
D000100: tarobject NormalFile[01] open size=18446744071969993079
dpkg: unrecoverable fatal error, aborting:
 malloc failed (-1739558537 bytes): Cannot allocate memory
 mercury6:/tmp# dpkg-deb: subprocess paste killed by signal (Broken pipe)

The big decimal number is 0x98508000.

You might not care about packages containing files of such a size and, even 
were you to do so, I expect you'd care about them even on 32 bit platforms, the 
fixing of which would require greater surgery than I propose here.  As 
programmers of taste and distinction, however, I am hoping that you care that 
OtoL (octal to long) returns a long but accumulates its return value in an 
int, making it incapable of returning the full range of long on platforms, like 
amd64, where the two types differ in size.

Apologies if it's a dupe.  I did try to search, both with Google and plowing 
through the bugs presented by reportbug, but there are so many 
minority-interest reports for dpkg, like this one :(, that I could easily have 
missed it.  I did check that my patch hasn't already been applied in 
http://git.debian.org/?p=dpkg/dpkg.git;a=blob_plain;f=lib/dpkg/tarfn.c;hb=HEAD.

-- 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/2 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=UTF-8) 
(ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dpkg depends on:
ii  coreutils 6.10-6 The GNU core utilities
ii  libc6 2.7-18 GNU C Library: Shared libraries
ii  lzma  4.43-14Compression method of 7z format in

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  0.7.20.2+lenny1 Advanced front-end for dpkg

-- no debconf information
--- lib/tarfn.c.orig	2011-03-04 09:24:50.0 -0800
+++ lib/tarfn.c	2011-03-04 09:19:31.0 -0800
@@ -42,7 +42,7 @@
 static long
 OtoL(const char * s, int size)
 {
-	int	n = 0;
+	long	n = 0;
 
 	while ( *s == ' ' ) {
 		s++;

Bug#587587: insserv: Starting nxserver depends on rmnologin and therefore on system facility `$all' which can not be true!

[Martin Dorey]

Petter's suggested fix worked for me too, thanks, digging me out of this hole:

Accept this solution? [Y/n/q/?]
The following NEW packages will be installed:
  samba-dbg
The following packages will be upgraded:
  libwbclient0 samba samba-common samba-doc smbclient swat winbind
7 packages upgraded, 1 newly installed, 0 to remove and 335 not upgraded.
Need to get 93.1 MB of archives. After unpacking 200 MB will be used.
Do you want to continue? [Y/n/?]
Get:1 http://debian-mirror/debian/ squeeze/main smbclient amd64 2:3.5.6~dfsg-3 
[15.2 MB]
Get:2 http://debian-mirror/debian/ squeeze/main swat amd64 2:3.5.6~dfsg-3 
[2,470 kB]
Get:3 http://debian-mirror/debian/ squeeze/main samba amd64 2:3.5.6~dfsg-3 
[8,325 kB]
Get:4 http://debian-mirror/debian/ squeeze/main winbind amd64 2:3.5.6~dfsg-3 
[5,793 kB]
Get:5 http://debian-mirror/debian/ squeeze/main samba-common all 2:3.5.6~dfsg-3 
[387 kB]
Get:6 http://debian-mirror/debian/ squeeze/main libwbclient0 amd64 
2:3.5.6~dfsg-3 [116 kB]
Get:7 http://debian-mirror/debian/ squeeze/main samba-doc all 2:3.5.6~dfsg-3 
[1,728 kB]
Get:8 http://debian-mirror/debian/ squeeze/main samba-dbg amd64 2:3.5.6~dfsg-3 
[59.1 MB]
Fetched 93.1 MB in 1s (47.0 MB/s)
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 187352 files and directories currently installed.)
Preparing to replace smbclient 2:3.5.6~dfsg-1 (using 
.../smbclient_2%3a3.5.6~dfsg-3_amd64.deb) ...
Unpacking replacement smbclient ...
Preparing to replace swat 2:3.5.6~dfsg-1 (using 
.../swat_2%3a3.5.6~dfsg-3_amd64.deb) ...
Unpacking replacement swat ...
Preparing to replace samba 2:3.5.6~dfsg-1 (using 
.../samba_2%3a3.5.6~dfsg-3_amd64.deb) ...
Stopping Samba daemons: nmbd smbd.
Unpacking replacement samba ...
Preparing to replace winbind 2:3.5.6~dfsg-1 (using 
.../winbind_2%3a3.5.6~dfsg-3_amd64.deb) ...
Stopping the Winbind daemon: winbind.
Unpacking replacement winbind ...
Preparing to replace samba-common 2:3.5.6~dfsg-1 (using 
.../samba-common_2%3a3.5.6~dfsg-3_all.deb) ...
Unpacking replacement samba-common ...
Preparing to replace libwbclient0 2:3.5.6~dfsg-1 (using 
.../libwbclient0_2%3a3.5.6~dfsg-3_amd64.deb) ...
Unpacking replacement libwbclient0 ...
Preparing to replace samba-doc 2:3.5.6~dfsg-1 (using 
.../samba-doc_2%3a3.5.6~dfsg-3_all.deb) ...
Unpacking replacement samba-doc ...
Selecting previously deselected package samba-dbg.
Unpacking samba-dbg (from .../samba-dbg_2%3a3.5.6~dfsg-3_amd64.deb) ...
Processing triggers for man-db ...
Setting up samba-common (2:3.5.6~dfsg-3) ...
Setting up libwbclient0 (2:3.5.6~dfsg-3) ...
Setting up smbclient (2:3.5.6~dfsg-3) ...
Setting up samba (2:3.5.6~dfsg-3) ...
insserv: warning: script 'K01nxserver' missing LSB tags and overrides
insserv: warning: script 'K01nxsensor' missing LSB tags and overrides
insserv: warning: script 'nxserver' missing LSB tags and overrides
insserv: warning: script 'nxsensor' missing LSB tags and overrides
insserv: There is a loop at service rmnologin if started
insserv: Starting nxserver depends on rmnologin and therefore on system 
facility `$all' which can not be true!
insserv: Starting nxsensor depends on rmnologin and therefore on system 
facility `$all' which can not be true!
insserv: Starting nxserver depends on rmnologin and therefore on system 
facility `$all' which can not be true!
insserv: Starting nxsensor depends on rmnologin and therefore on system 
facility `$all' which can not be true!
...
insserv: Starting nxserver depends on rmnologin and therefore on system 
facility `$all' which can not be true!
insserv: Starting nxsensor depends on rmnologin and therefore on system 
facility `$all' which can not be true!
insserv: Starting nxserver depends on rmnologin and therefore on system 
facility `$all' which can not be true!
insserv: Starting nxsensor depends on rmnologin and therefore on system 
facility `$all' which can not be true!
insserv: Max recursions depth 99 reached
insserv:  loop involving service nfs-kernel-server at depth 6
insserv: There is a loop between service rmnologin and mountnfs if started
insserv:  loop involving service mountnfs at depth 6
insserv:  loop involving service nfs-common at depth 5
insserv: There is a loop between service rmnologin and checkroot if started
insserv:  loop involving service checkroot at depth 3
insserv:  loop involving service keyboard-setup at depth 2
insserv:  loop involving service hwclock at depth 6
insserv:  loop involving service hostname at depth 4
insserv:  loop involving service fuse at depth 11
insserv: There is a loop between service rmnologin and ifupdown if started
insserv:  loop involving service ifupdown at depth 7
insserv:  loop involving service ifupdown-clean at depth 6
insserv: There is a loop between service rmnologin and mountall if started
insserv:  loop involving service mountall at depth 8
insserv:  loop involving service checkfs at depth 7
insserv:  loop involving service mtab at depth 6
insserv:  loop involving service module-init-tools at 

Bug#571652: exuberant-ctags: endless loop on unmatched { in makefile

[Martin Dorey]

Package: exuberant-ctags
Version: 1:5.7-4
Severity: normal
Tags: patch

Test case:

mart...@whitewater:/tmp$ echo -n {  Makefile
mart...@whitewater:/tmp$ /usr/bin/ctags-exuberant Makefile 
(doesn't terminate)

Where it gets stuck:

(gdb) bt
#0  0x7ff276a7d960 in read () from /lib/libc.so.6
#1  0x7ff276a2bb20 in _IO_file_underflow () from /lib/libc.so.6
#2  0x7ff276a2d2ee in _IO_default_uflow () from /lib/libc.so.6
#3  0x7ff276a2878c in getc () from /lib/libc.so.6
#4  0x004175fc in iFileGetLine () at read.c:333
#5  0x00417c38 in fileGetc () at read.c:439
#6  0x00411a69 in nextChar () at make.c:42
#7  0x00411add in skipToMatch (pair=0x6 Address 0x6 out of bounds) at 
make.c:98
#8  0x00411dac in findMakeTags () at make.c:146
#9  0x00415668 in parseFile (fileName=0x7fffbe82 /...) at 
parse.c:617
#10 0x00411309 in createTagsForEntry (entryName=0x7fffbe82 /...) 
at main.c:303
#11 0x00411870 in main (argc=value optimized out, 
argv=0x7fffa608) at main.c:348
(gdb) 

Fix attached.

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

Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages exuberant-ctags depends on:
ii  libc6   2.7-18lenny2 GNU C Library: Shared libraries

exuberant-ctags recommends no packages.

Versions of packages exuberant-ctags suggests:
ii  vim   1:7.1.314-3+lenny2 Vi IMproved - enhanced vi editor

-- no debconf information
--- make.c  2010-02-26 11:03:17.0 -0800
+++ make.c.new  2010-02-26 11:03:13.0 -0800
@@ -100,7 +100,7 @@
++matchLevel;
else if (c == end)
--matchLevel;
-   else if (c == '\n')
+   else if (c == '\n' || c == EOF)
break;
}
if (c == EOF)

Bug#499826: totem: Allow screensaver to activate: checkbox has reversed meaning

[Martin Dorey]

Fantastic - this bug gives me a work-around for
https://bugs.launchpad.net/ubuntu/+source/xine-lib/+bug/216939.  That
had been driving me nuts when using totem-xine concurrently with
rdesktop or vncviewer to a Windows box.  Simply uncheck the box which
looks like it should be checked.  No need for network sniffs, no need to
remove and clean the Alt key, no need to run a keyboard monitor, no need
to swap the keyboard.

 

Bug#534408: debian-policy: Installed-Size is defined as kilobytes but dpkg-gencontrol fills it in with kibibytes

[Martin Dorey]

Package: debian-policy
Version: 3.7.2.2
Severity: minor

debian-policy appears to define Installed-Size's units as thousands of bytes:

 5.6.20 Installed-Size
 This field appears in the control files of binary packages, and in the 
 Packages files. It gives the total amount of disk space required to install 
 the named package.
 The disk space is represented in kilobytes as a simple decimal number. 

I suspect this is informal language describing an intention to use kibibytes - 
units of 1024 bytes - as implemented by dpkg-gencontrol's use of du -k:

if (!defined($substvars-get('Installed-Size'))) {
defined(my $c = open(DU, -|)) || syserr(_g(fork for du));
if (!$c) {
chdir($packagebuilddir) ||
syserr(_g(chdir for du to \`%s'), $packagebuilddir);
exec(du,-k,-s,.) or syserr(_g(exec du));

The ambiguity, while not particularly serious at the scale of typical package 
sizes, has led to dispute, eg https://bugs.launchpad.net/gdebi/+bug/44286.

If I'm wrong about the intention, then an appropriate resolution might be to 
reassign this bug to dpkg-dev for adding --si to the du invocation in 
dpkg-gencontrol.
-- System Information:
Debian Release: 4.0
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (50, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)

-- 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#531078: socat: execs children with SIGCHLD ignored

[Martin Dorey]

Thanks, that's very gracious.

Today we tripped over a real symptom of this problem.  When running via
socat:

mart...@mercury1-a:~$ sudo dpkg -i
~/software.jessies.org/work/evergreen/.generated/amd64_Linux/bin/org.jes
sies.evergreen_5.204.2884_amd64.deb 
dpkg: unrecoverable fatal error, aborting:
 wait for dpkg-split failed: No child processes
mart...@mercury1-a:~$

I'm told that dpkg forks to call dpkg-split (which succeeded) then
waitpid()s on the child, but gets back a ECHILD.

With the patched socat, dpkg worked fine, so I'm not suggesting or
requesting any further or different action here.  I just thought it
might be useful to others if googling for this symptom were to take them
to the bug report.




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#531078: socat: execs children with SIGCHLD ignored

[Martin Dorey]

Package: socat
Version: 1.4.3.1-1
Severity: normal
Tags: patch

I don't currently know that I'm experiencing any symptom of this, other than a
warning generated by what I'm told is an obsolete warning flag to Perl.

mart...@whitewater:~$ perl -we 0
mart...@whitewater:~$ socat - EXEC:'perl -we 0'
Can't ignore signal CHLD, forcing to default.
mart...@whitewater:~$ 

Here's a demonstration with a more recent version of socat, unpatched then
patched:

mart...@whitewater:/tmp/socat-1.7.1.0$ /tmp/socat-1.7.1.0/socat - EXEC:'perl 
-we 0'
Can't ignore signal CHLD, forcing to default.
mart...@whitewater:/tmp/socat-1.7.1.0$ patch -p0  xio-progcall.c.patch 
patching file xio-progcall.c
mart...@whitewater:/tmp/socat-1.7.1.0$ make
gcc -O -D_GNU_SOURCE  -Wall -Wno-parentheses -DHAVE_CONFIG_H -I.  -I.   -c -o 
xio-progcall.o xio-progcall.c
ar r libxio.a snipped
ranlib libxio.a
gcc -O -D_GNU_SOURCE  -Wall -Wno-parentheses -DHAVE_CONFIG_H -I.   -o socat 
socat.o libxio.a -lutil  -lssl
mart...@whitewater:/tmp/socat-1.7.1.0$ /tmp/socat-1.7.1.0/socat - EXEC:'perl 
-we 0'
mart...@whitewater:/tmp/socat-1.7.1.0$ 

I fear there might be other symptoms, which is why I'm raising the bug.
My fears are based partly on:

In http://www.pasc.org/interps/unofficial/db/p1003.1/pasc-1003.1-132.html,
a David Korn (perhaps *the* Dave Korn) is quoted as having written:

 A conforming application would not set  SIGCHLD to SIG_IGN
 since the standard leaves this behavior unspecified.  An application
 that does set SIGCHLD to SIG_IGN  should set it back to SIG_DFL
 before the call to exec.

In working on terminal emulators, I've seen a number of programs revert SIGCHLD
to SIG_DFL before calling exec(), generally without convincingly specifying
the reason.  Perhaps the unspecified heritability of SIG_IGN is the reason.

I wonder why socat ignores SIGCHLD in the child.  Perhaps it's for the case
where the child will then call system().  Then the SIG_IGN will affect socat
code as well as any child that inherits it.  But system() waits for its child.
Perhaps this SIG_IGN is a relic of earlier efforts to prevent zombies.
More likely, I'm missing something.

-- System Information:
Debian Release: 4.0
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (50, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)

Versions of packages socat depends on:
ii  libc6  2.3.6.ds1-13etch9 GNU C Library: Shared libraries
ii  libreadline5   5.2-2 GNU readline and history libraries
ii  libssl0.9.80.9.8c-4etch5 SSL shared libraries
ii  libwrap0   7.6.dbs-13Wietse Venema's TCP wrappers libra

socat recommends no packages.

-- no debconf information
--- xio-progcall.c.orig	2009-05-29 12:20:53.0 -0700
+++ xio-progcall.c	2009-05-29 12:24:43.0 -0700
@@ -414,8 +414,10 @@
   gid_t group;
 
   if (withfork) {
-	 if (Signal(SIGCHLD, SIG_IGN) == SIG_ERR) {
-	Warn1(signal(SIGCHLD, SIG_IGN): %s, strerror(errno));
+	 /* The child should have default handling for SIGCHLD. */
+	 /* In particular, it's not defined whether ignoring SIGCHLD is inheritable. */
+	 if (Signal(SIGCHLD, SIG_DFL) == SIG_ERR) {
+	Warn1(signal(SIGCHLD, SIG_DFL): %s, strerror(errno));
 	 }
 
 #if HAVE_PTY

Bug#481512: libmagic1: couldn't open file doesn't say which file or why

[Martin Dorey]

Package: file
Version: 4.24-2
Severity: normal
Tags: patch


This change in magic.c, introduced between 4.23 and 4.24, caused a
backup job of ours to produce a large number of mysterious messages
saying couldn't open file.  It took quite some digging to work out
(from find /usr/lib -type f | xargs strings | grep) what was producing
such a message.

@@ -296,10 +297,12 @@
 errno = 0;
 if ((fd = open(inname, flags))  0) {
 #ifdef __CYGWIN__
+/* FIXME: Do this with EXEEXT from autotools */
 char *tmp = alloca(strlen(inname) + 5);
 (void)strcat(strcpy(tmp, inname), .exe);
 if ((fd = open(tmp, flags))  0) {
 #endif
+fprintf(stderr, couldn't open file\n);
 if (info_from_stat(ms, sb.st_mode) == -1)
 goto done;
 rv = 0;

I wanted to submit a patch, so I changed the fprintf line to:

fprintf(stderr, couldn't open file `%s': %s\n, inname,
strerror(errno));

But then I tripped over a regression with file_error_core.
I'll submit that as a separate Debian bug.

Upstream's response to the above moan was (from Christos):

I just removed the printf, thanks.

So perhaps we could do that in Debian?
I'm happy to wait for upstream.
Really, then, I'm just raising this Debian bug for the benefit of anyone
else baffled by the same error message, so that they might stand a small
chance of getting a relevant google-hit for it.

-- System Information:
Debian Release: lenny/sid
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libmagic1 depends on:
ii  libc6  2.7-11GNU C Library: Shared
libraries
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library -
runtime

libmagic1 recommends no packages.

Versions of packages file depends on:
ii  libc6 2.7-11 GNU C Library: Shared
libraries

-- no debconf information
--- magic.c.old 2008-05-16 08:26:22.0 -0700
+++ magic.c 2008-05-16 08:26:35.0 -0700
@@ -302,7 +302,6 @@
(void)strcat(strcpy(tmp, inname), .exe);
if ((fd = open(tmp, flags))  0) {
 #endif
-   fprintf(stderr, couldn't open file\n);
if (info_from_stat(ms, sb.st_mode) == -1)
goto done;
rv = 0;

Bug#481523: libmagic1: file_error_core causes crash in vasprintf

[Martin Dorey]

Package: file
Version: 4.24-2
Severity: normal
Tags: patch


When I made my original change suggested in Bug#481512 (libmagic1:
couldn't open file  doesn't say which file or why), I ran into a crash
in strlen from vasprintf caused by a regression introduced between 4.23
and 4.24 upstream, in the file_error_core function in funcs.c.  As I
reported upstream (in a message entitled distressingly obscure error
message on failing to open a file), the file_printf(ms, f, va) line -
the one with the unusual indentation - is passing a va_list to a
printf-style function rather than a vprintf-style function.  I suggested
that file_printf should be renamed file_vprintf and given a va_list
argument and submitted a patch, which Christos accepted, saying:

Thanks a lot, I applied your fix.

I didn't try very hard to reproduce this with an unpatched file but what
attempts I did make, failed.  So perhaps this is unimportant but, if
anyone else finds themselves with a more compelling reason to apply the
patch before 4.25 comes out, I have attached it here.

-- System Information:
Debian Release: lenny/sid
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libmagic1 depends on:
ii  libc6  2.7-11GNU C Library: Shared
libraries
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library -
runtime

libmagic1 recommends no packages.

Versions of packages file depends on:
ii  libc6 2.7-11 GNU C Library: Shared
libraries

-- no debconf information
--- funcs.c	2008-03-07 07:00:07.0 -0800
+++ funcs.c	2008-05-16 09:55:16.0 -0700
@@ -45,18 +45,15 @@
  * Like printf, only we append to a buffer.
  */
 protected int
-file_printf(struct magic_set *ms, const char *fmt, ...)
+file_vprintf(struct magic_set *ms, const char *fmt, va_list ap)
 {
-	va_list ap;
 	size_t size;
 	int len;
 	char *buf, *newstr;
 
-	va_start(ap, fmt);
 	len = vasprintf(buf, fmt, ap);
 	if (len  0)
 		goto out;
-	va_end(ap);
 
 	if (ms-o.buf != NULL) {
 		len = asprintf(newstr, %s%s, ms-o.buf, buf);
@@ -73,6 +70,18 @@
 	return -1;
 }
 
+protected int
+file_printf(struct magic_set *ms, const char *fmt, ...)
+{
+	va_list ap;
+	int len;
+	
+	va_start(ap, fmt);
+	len = file_vprintf(ms, fmt, ap);
+	va_end(ap);
+	return len;
+}
+
 /*
  * error - print best error message possible
  */
@@ -89,7 +98,7 @@
 		ms-o.buf = NULL;
 		file_printf(ms, line %u: , lineno);
 	}
-file_printf(ms, f, va);
+	file_vprintf(ms, f, va);
 	if (error  0)
 		file_printf(ms,  (%s), strerror(error));
 	ms-haderr++;

Bug#456259: wget aborts on negative length

[Martin Dorey]

This is probably fixed upstream per 
http://www.mail-archive.com/wget%40sunsite.dk/msg10697.html.  I didn't refer to 
the upstream changes in making the patch submitted with this bug, so it would 
probably be a bad idea to apply my patch.

Bug#456259: wget: aborts with no message when http server returns negative size

[Martin Dorey]

Package: wget
Version: 1.10.2-2
Severity: normal
Tags: patch

Note the negative length returned by my http server here.
The file's larger than 2GiB and I'm sure there's a server bug there.
But wget could easily handle it more gracefully - all the code for doing so is 
there.
First, though, here's how it handles the negative size at the moment:

(gdb) r http://bobthe/Company/Engineering/Software/VirtualSMUImages/copper-1.zip
Starting program: /tmp/wget-1.10.2/src/wget 
http://bobthe/Company/Engineering/Software/VirtualSMUImages/copper-1.zip
[Thread debugging using libthread_db enabled]
[New Thread 47666932903152 (LWP 31249)]
--17:00:40--  
http://bobthe/Company/Engineering/Software/VirtualSMUImages/copper-1.zip
   = `copper-1.zip'
Resolving bobthe... 10.2.1.7
Connecting to bobthe|10.2.1.7|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: -1,449,214,731 [application/zip]

[ =  ] 0  
   --.--K/s 


Program received signal SIGABRT, Aborted.
[Switching to Thread 47666932903152 (LWP 31249)]
0x2b5a5256c07b in raise () from /lib/libc.so.6
(gdb) bt
#0  0x2b5a5256c07b in raise () from /lib/libc.so.6
#1  0x2b5a5256d84e in abort () from /lib/libc.so.6
#2  0x00415e5a in http_loop (u=0x5430c0, newloc=0x7fff58c48d88, 
local_file=0x7fff58c48d80, referer=value optimized out, dt=0x7fff58c48ee8, 
proxy=0x0) at http.c:2456
#3  0x0041e2e5 in retrieve_url (origurl=0x543000 h..., 
file=0x7fff58c48ee0, newloc=0x7fff58c48ed8, refurl=0x0, dt=0x7fff58c48ee8) at 
retr.c:667
#4  0x0041a65d in main (argc=2, argv=0x7fff58c48ff8) at main.c:943
(gdb) 

This is the code that's abort()ing:

  else if (hstat.res == 0) /* No read error */
{
  if (hstat.contlen == -1)  /* We don't know how much we were supposed
   to get, so assume we succeeded. */ 
{
...
}
  else if (hstat.len  hstat.contlen) /* meaning we lost the
 connection too soon */
{
...
}
  else
/* Getting here would mean reading more data than
   requested with content-length, which we never do.  */
abort ();

My patch treats negatives lengths like out-of-range integers.
I was expecting this to cause the download to fail with a nice error message.
It actually treated the length as unknown and continued.
That seems like useful behavior, though a warning might be a useful addition.
Still, a minimal patch is always less controversial when hacking another's code.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable'), (50, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)

Versions of packages wget depends on:
ii  libc6  2.3.6.ds1-13etch2 GNU C Library: Shared libraries
ii  libssl0.9.80.9.8c-4etch1 SSL shared libraries

wget recommends no packages.

-- no debconf information
--- http.c.orig	2007-12-13 16:57:24.0 -0800
+++ http.c	2007-12-13 16:58:44.0 -0800
@@ -1601,7 +1601,7 @@
   wgint parsed;
   errno = 0;
   parsed = str_to_wgint (hdrval, NULL, 10);
-  if (parsed == WGINT_MAX  errno == ERANGE)
+  if ((parsed == WGINT_MAX  errno == ERANGE) || parsed  0)
 	/* Out of range.
 	    If Content-Length is out of range, it most likely
 	   means that the file is larger than 2G and that we're

Bug#450396: libdbi-ruby1.8: DBI.available_drivers() always empty

[Martin Dorey]

Package: libdbi-ruby1.8
Version: 0.1.1-1
Severity: normal
Tags: patch

$ ruby -e 'require dbi;puts(DBI.available_drivers())'
$ dpkg --listfiles libdbd-odbc-ruby1.8 | grep ODBC.rb
/usr/lib/ruby/1.8/DBD/ODBC/ODBC.rb
$ dpkg --listfiles libdbi-ruby1.8 | grep dbi.rb
/usr/lib/ruby/1.8/dbi.rb
$ diff -u dbi.rb.orig dbi.rb
--- dbi.rb.orig 2007-11-06 18:06:54.0 -0800
+++ dbi.rb  2007-11-06 18:07:24.0 -0800
@@ -238,7 +238,7 @@
   # 'dbi:driver:' format.
   def available_drivers
  drivers = []
- path = File.dirname(File.dirname(__FILE__)) + / + DBD::DIR
+ path = File.dirname(__FILE__) + / + DBD::DIR
  Find.find(path){ |f|
 if File.file?(f)
driver = File.basename(f, .rb)
$

Without the patch, the code looks in the dirname of the dirname of
/usr/lib/ruby/1.8/dbi.rb, which is /usr/lib/ruby, for a directory called
DBD.  That directory is one level lower - in the 1.8 sub-directory.
Perhaps libdbd-odbc-ruby1.8 should be installing its driver in
/usr/lib/ruby but that didn't sound likely to me.  libdbd-mysql-ruby1.8
behaves like the ODBC driver.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable'), (50, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to en_US.UTF-8)

Versions of packages libdbi-ruby1.8 depends on:
ii  libruby1.81.8.5-4Libraries necessary to run
Ruby 1.

libdbi-ruby1.8 recommends no packages.

-- no debconf information
--- dbi.rb.orig 2007-11-06 18:06:54.0 -0800
+++ dbi.rb  2007-11-06 18:07:24.0 -0800
@@ -238,7 +238,7 @@
   # 'dbi:driver:' format.
   def available_drivers
  drivers = []
- path = File.dirname(File.dirname(__FILE__)) + / + DBD::DIR
+ path = File.dirname(__FILE__) + / + DBD::DIR
  Find.find(path){ |f|
 if File.file?(f)
driver = File.basename(f, .rb)

Bug#404131: Me too

[Martin Dorey]

For what little it's worth, I'm seeing the same behavior on two Debian
boxes, each with one statically configured interface.
 
$ sudo nm-tool
 
NetworkManager Tool
 
State: disconnected
 
print_devices(): didn't get a reply from NetworkManager.
There are no available network devices.
$
 
$ ifconfig
eth0  Link encap:Ethernet  HWaddr 00:11:11:23:33:7E  
  inet addr:10.2.20.204  Bcast:10.2.255.255  Mask:255.255.0.0
  inet6 addr: fe80::211:11ff:fe23:337e/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:23636 errors:0 dropped:0 overruns:0 frame:0
  TX packets:35086 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:2042520 (1.9 MiB)  TX bytes:2552131 (2.4 MiB)
 
loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:92 errors:0 dropped:0 overruns:0 frame:0
  TX packets:92 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:6912 (6.7 KiB)  TX bytes:6912 (6.7 KiB)
 
$
 
$ cat /etc/network/interfaces 
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
 
# The loopback network interface
auto lo
iface lo inet loopback
 
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 10.2.20.204
netmask 255.255.0.0
gateway 10.2.1.254
$
 

Bug#404131: Me too

[Martin Dorey]

 Don't run Network Manager with a statically configure interface, it's
 not supported by Network Manager.

I'm not trying to run Network Manager to *manage* a statically
configured interface.  I was just trying to run Network Manager while
I had a statically configured interface.  What actually happened was
that I let the etch installer use DHCP, then switched to a statically
configured address later.  This bit me, but only much later, when I
restarted NIS.  I *think* that the installer may be installing Network
Manager even if you give it a static IP configuration.  That seems
reasonable to me.

network-manager-0.6.4/debian/README.Debian says that Network Manager
doesn't manage statically configured interfaces.  It doesn't say that
it's not supported to have Network Manager installed when you only have
statically configured interfaces.  Indeed, its example has both
statically configured and automatically configured interfaces.

OK, so I don't need Network Manager on these machines, at least at the
moment (none of them have wifi or anything), so I've uninstalled it.

Bug#409988: xserver-xorg: upgrade from xfree86 sarge failed with 'Can't call method choices on an undefined value'

[Martin Dorey]

Package: xserver-xorg
Version: 1:7.1.0-11
Severity: normal

Upgrading from sarge (where I guess we were using xfree86) to etch failed with:

Setting up xserver-xorg (7.1.0-11) ...
xserver-xorg postinst warning: Migrating xserver-xfree86 debconf values
   to xserver-xorg.
Can't call method choices on an undefined value at 
/usr/share/perl5/Debconf/Question.pm line 106, GEN1 line 115.
dpkg: error processing xserver-xorg (--configure):
 subprocess post-installation script returned error exit status 9
dpkg: dependency problems prevent configuration of xserver-xfree86:
 xserver-xfree86 depends on xserver-xorg; however:
  Package xserver-xorg is not configured yet.
dpkg: error processing xserver-xfree86 (--configure):
 dependency problems - leaving unconfigured

http://www.mrl.nott.ac.uk/~str/pages/misctech.html suggested a scary-looking 
work-around, which was probably originally due to:

http://www.zoxx.net/notes/index.php/2006/01/21/11-probleme-cache-debconf-sous-debian-gnu-linux

$ debconf-show xserver-xfree86
debconf: DbDriver passwords warning: could not open 
/var/cache/debconf/passwords.dat: Permission denied
  xserver-xfree86/config/monitor/screen-size:
* xserver-xfree86/config/device/use_fbdev: false
* xserver-xfree86/config/monitor/selection-method: Advanced
  xserver-xfree86/config/doublequote_in_string_error:
  xserver-xfree86/config/device/bus_id:
  xserver-xfree86/config/device/video_ram:
* xserver-xfree86/config/monitor/lcd: false
  xserver-xfree86/config/inputdevice/keyboard/internal:
* xserver-xfree86/config/device/driver: ati
* xserver-xfree86/config/monitor/vert-refresh: 43-72
* xserver-xfree86/config/display/default_depth: 24
* xserver-xfree86/config/display/modes: 800x600, 640x480
  xserver-xfree86/config/modules: GLcore, bitmap, dbe, ddc, dri, extmod, 
freetype, glx, int10, record, speedo, type1, vbe, xtt
  xserver-xfree86/config/monitor/range_input_error:
  xserver-xfree86/autodetect_video_card:
  xserver-xfree86/config/inputdevice/keyboard/variant:
* xserver-xfree86/config/inputdevice/mouse/port: /dev/psaux
  xserver-xfree86/config/write_files_section: true
  xserver-xfree86/autodetect_monitor:
  xserver-xfree86/config/device/identifier: Generic Video Card
  xserver-xfree86/config/inputdevice/mouse/emulate3buttons: true
* xserver-xfree86/config/inputdevice/keyboard/layout: us
* xserver-xfree86/config/monitor/horiz-sync: 28-48
  xserver-xfree86/config/monitor/identifier: Generic Monitor
  shared/no_known_x-server:
  xserver-xfree86/autodetect_mouse:
  xserver-xfree86/config/monitor/mode-list:
  xserver-xfree86/clobber_XF86Config-4:
* xserver-xfree86/config/inputdevice/keyboard/rules: xfree86
  xserver-xfree86/multiple_possible_x-drivers:
* xserver-xfree86/config/inputdevice/keyboard/model: pc104
  xserver-xfree86/config/write_dri_section: true
  xserver-xfree86/config/inputdevice/mouse/zaxismapping: true
  xserver-xfree86/config/inputdevice/mouse/retry_detection:
  xserver-xfree86/config/device/bus_id_error:
  xserver-xfree86/config/inputdevice/keyboard/options:
  xserver-xfree86/config/nonnumeric_string_error:
* xserver-xfree86/config/inputdevice/mouse/protocol: PS/2
  shared/multiple_possible_x-servers:
  xserver-xfree86/config/null_string_error:
$

Adding a -x to the hash bang line of the xserver-xorg's postinst script might 
indicate where the problem is:

+ printf '%s\n' 'FSET xserver-xorg/config/null_string_error seen true'
+ IFS='
'
+ read -r _db_internal_line
+ RET=true
+ case ${_db_internal_line%%[   ]*} in
+ return 0
+ db_metaget xserver-xfree86/config/display/modes choices
+ _db_cmd 'METAGET xserver-xfree86/config/display/modes' choices
+ IFS=' '
+ printf '%s\n' 'METAGET xserver-xfree86/config/display/modes choices'
+ IFS='
'
+ read -r _db_internal_line
Can't call method choices on an undefined value at 
/usr/share/perl5/Debconf/Question.pm line 106, GEN1 line 115.
+ RET=
+ case ${_db_internal_line%%[   ]*} in
+ return
+ '[' '' '!=' '10 xserver-xfree86/config/display/modes doesn'\''t exist' ']'
+ db_subst xserver-xorg/config/display/modes choices ''
+ _db_cmd 'SUBST xserver-xorg/config/display/modes' choices ''
+ IFS=' '
+ printf '%s\n' 'SUBST xserver-xorg/config/display/modes choices '
/usr/share/debconf/confmodule: line 42: printf: write error: Broken pipe

Ah, SIGPIPE, we meet again.

So is this a debconf problem?  These two bugs have similar but not identical 
symptoms:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=224400
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=303284

-- Package-specific info:
/var/lib/x11/X.roster does not exist.

/var/lib/x11/X.md5sum does not exist.

X server symlink status:
lrwxrwxrwx 1 root root 9 2007-02-06 11:54 /etc/X11/X - /bin/true
-rwxr-xr-x 1 root root 11680 2006-08-31 04:57 /bin/true

/var/lib/x11/xorg.conf.roster does not exist.

VGA-compatible devices on PCI bus:
04:04.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)

/etc/X11/xorg.conf unchanged from checksum in /var/lib/x11/xorg.conf.md5sum.

Xorg X server 

Bug#409988: Acknowledgement (xserver-xorg: upgrade from xfree86 sarge failed with 'Can't call method choices on an undefined value')

[Martin Dorey]

This incorrectly indented, tasteless, dangerous hack:

$ diff -u /usr/share/perl5/Debconf/Question.pm /net/gollum/usr/
share/perl5/Debconf/Question.pm
--- /usr/share/perl5/Debconf/Question.pm2006-12-20
11:31:31.0 -0800
+++ /net/gollum/usr/share/perl5/Debconf/Question.pm 2007-02-06
14:23:49.0 -0800
@@ -103,6 +103,9 @@
 sub choices {
my $this=shift;

+if (!defined($this-template)) {
+  return undef;
+}
return $this-_expand_vars($this-template-choices);
 }
 
$

Got my upgrade going again:

Setting up xserver-xorg (7.1.0-11) ...
xserver-xorg postinst warning: Migrating xserver-xfree86 debconf values
   to xserver-xorg.

xserver-xorg postinst warning: failed to infer keyboard layout from
layout/lang
   '--en_US'
$

I've no idea what the consequences will be, although they can scarcely
be worse than a stuck, half-complete upgrade.
-
Martin's Outlook, BlueArc Engineering

Bug#409101: discover-data: fails to find any display devices

[Martin Dorey]

Package: discover-data
Version: 2.2007.01.21
Severity: normal

Recently there was a change:

diff -r 2.2006.12.28/lib/discover/pci-busclass.xml 
2.2007.01.21/lib/discover/pci-busclass.xml
19,20c19,20
   busclass id=0280 name=network/
   busclass id=0300 name=display/
---
   busclass id=0280 name=ethernet/
   busclass id=0300 name=video/
52a53
   busclass id=0805 name=miscellaneous/

I suspect this was the relevant change log comment:

  * Update the name of some busclasses in pci-busclass.xml to match
the pci.lst values. 

Note that display has been renamed to video.  This breaks this code for me:

  CMD=discover --type-summary display
  eval $CMD $VENDOR_MODEL_FILE || debug_report_status $CMD $?
  CMD=discover --data-path=xfree86/server/name \
--data-version=$UPSTREAM_VERSION display
  eval $CMD $SERVER_FILE || debug_report_status $CMD $?
  CMD=discover --data-path=xfree86/server/device/driver \
--data-version=$UPSTREAM_VERSION display
  eval $CMD $DRIVER_FILE || debug_report_status $CMD $?

  DISCOVERED_VIDEO=$(paste $VENDOR_MODEL_FILE $SERVER_FILE $DRIVER_FILE)

That code is from /var/lib/dpkg/info/xserver-xorg.postinst and controls which
X server I run (which has now defaulted to vesa when it should be i810).

According to the discover man page, this command:

$ discover --type-summary display
$ 

Should produce the result now produced only by this command:

$ discover --type-summary video
Intel Corporation 82865G Integrated Graphics Controller 
$ 

If I regenerate pci-buslist.xml (and bear in mind I have no idea what I'm doing
here):

[EMAIL PROTECTED]:/tmp/badger$ /usr/share/tools/lst2xml /lib/discover/pci.lst
[EMAIL PROTECTED]:/tmp/badger$ 

Then I get a very different file to the one that was installed by discover-data:

[EMAIL PROTECTED]:/tmp/badger$ diff pci-busclass.xml /lib/discover/
1c1,3
 ?xml version='1.0' encoding='UTF-8'?
---
 ?xml version=1.0 encoding=UTF-8?
 
 !-- $Progeny$ --
4,15c6,92
   busclass id=0400 name='video'/
   busclass id=0c03 name='bridge'/
   busclass id=0200 name='network'/
   busclass id=0300 name='display'/
   busclass id=0204 name='broadband'/
   busclass id=0703 name='modem'/
   busclass id=0600 name='bridge'/
   busclass id=0904 name='bridge'/
   busclass id=0101 name='bridge'/
   busclass id= name='miscellaneous'/
   busclass id=0401 name='audio'/
   busclass id=0100 name='bridge'/
---
   busclass id= name=miscellaneous/
   busclass id=0001 name=display/
   busclass id=0100 name=scsi/
   busclass id=0101 name=ide/
   busclass id=0102 name=bridge/
   busclass id=0103 name=bridge/
   busclass id=0104 name=bridge/
   busclass id=0180 name=bridge/
   busclass id=0200 name=ethernet/
   busclass id=0201 name=network/
   busclass id=0202 name=network/
   busclass id=0203 name=network/
   busclass id=0204 name=isdn/
   busclass id=0280 name=ethernet/
   busclass id=0300 name=video/
   busclass id=0301 name=display/
   busclass id=0302 name=display/
   busclass id=0380 name=display/
   busclass id=0400 name=video/
   busclass id=0401 name=sound/
   busclass id=0402 name=modem/
   busclass id=0480 name=miscellaneous/
   busclass id=0500 name=miscellaneous/
   busclass id=0501 name=miscellaneous/
   busclass id=0580 name=miscellaneous/
   busclass id=0600 name=bridge/
   busclass id=0601 name=bridge/
   busclass id=0602 name=bridge/
   busclass id=0603 name=bridge/
   busclass id=0604 name=bridge/
   busclass id=0605 name=bridge/
   busclass id=0606 name=bridge/
   busclass id=0607 name=bridge/
   busclass id=0608 name=bridge/
   busclass id=0609 name=bridge/
   busclass id=060a name=bridge/
   busclass id=0680 name=bridge/
   busclass id=0700 name=miscellaneous/
   busclass id=0701 name=miscellaneous/
   busclass id=0702 name=miscellaneous/
   busclass id=0703 name=modem/
   busclass id=0780 name=miscellaneous/
   busclass id=0800 name=miscellaneous/
   busclass id=0801 name=miscellaneous/
   busclass id=0802 name=miscellaneous/
   busclass id=0803 name=miscellaneous/
   busclass id=0804 name=miscellaneous/
   busclass id=0805 name=miscellaneous/
   busclass id=0880 name=miscellaneous/
   busclass id=0900 name=bridge/
   busclass id=0901 name=humaninput/
   busclass id=0902 name=bridge/
   busclass id=0903 name=bridge/
   busclass id=0904 name=joystick/
   busclass id=0980 name=bridge/
   busclass id=0a00 name=miscellaneous/
   busclass id=0a80 name=miscellaneous/
   busclass id=0b00 name=miscellaneous/
   busclass id=0b01 name=miscellaneous/
   busclass id=0b02 name=miscellaneous/
   busclass id=0b10 name=miscellaneous/
   busclass id=0b20 name=miscellaneous/
   busclass id=0b30 name=miscellaneous/
   busclass id=0b40 name=miscellaneous/
   busclass id=0c00 name=bridge/
   busclass id=0c01 name=bridge/
   busclass id=0c02 name=bridge/
   busclass id=0c03 name=usb/
   busclass id=0c04 name=bridge/
   busclass id=0c05 name=bridge/
   busclass id=0c06 name=bridge/
   busclass id=0d00 

Bug#392849: free(): invalid pointer every time I quit

[Martin Dorey]

Package: zinf
Version: 2.2.5-5.2
Severity: normal

Every time I quit, I see a message like:

*** glibc detected *** free(): invalid pointer: 0xa574f0e0 ***

If I run zinf from gdb, I get:

*** glibc detected *** free(): invalid pointer: 0xa574f0e0 ***

Program received signal SIGABRT, Aborted.
[Switching to Thread -1480500928 (LWP 32229)]
0xe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xe410 in __kernel_vsyscall ()
#1  0xa7c3e821 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xa7c3ffb9 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xa7c73c4a in __fsetlocking () from /lib/tls/i686/cmov/libc.so.6
#4  0xa7c7b4df in mallopt () from /lib/tls/i686/cmov/libc.so.6
#5  0xa7c7b582 in free () from /lib/tls/i686/cmov/libc.so.6
#6  0xa7e8dbd1 in g_free () from /usr/lib/libglib-2.0.so.0
#7  0xa71d74b5 in GTKFont::~GTKFont () from /usr/lib/zinf/plugins/zinf.ui
#8  0xa71a27ba in TextControl::~TextControl () from 
/usr/lib/zinf/plugins/zinf.ui
#9  0xa71986d0 in Panel::ClearControls () from /usr/lib/zinf/plugins/zinf.ui
#10 0xa719a243 in Window::ClearControls () from /usr/lib/zinf/plugins/zinf.ui
#11 0xa719b4e2 in Window::~Window () from /usr/lib/zinf/plugins/zinf.ui
#12 0xa71db077 in GTKWindow::~GTKWindow () from /usr/lib/zinf/plugins/zinf.ui
#13 0xa71a52a3 in Theme::ClearWindows () from /usr/lib/zinf/plugins/zinf.ui
#14 0xa71a74b9 in Theme::~Theme () from /usr/lib/zinf/plugins/zinf.ui
#15 0xa71c152a in ZinfTheme::~ZinfTheme () from /usr/lib/zinf/plugins/zinf.ui
#16 0x0805d8b0 in Player::~Player ()
#17 0x0808e56e in main ()
(gdb)


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)

Versions of packages zinf depends on:
ii  libatk1.0-0  1.12.2-1The ATK accessibility toolkit
ii  libc62.3.6.ds1-4 GNU C Library: Shared libraries
ii  libcairo21.2.4-1 The Cairo 2D vector graphics libra
ii  libfontconfig1   2.4.1-2 generic font configuration library
ii  libgcc1  1:4.1.1-13  GCC support library
ii  libgdbm3 1.8.3-3 GNU dbm database routines (runtime
ii  libglib2.0-0 2.12.3-2The GLib library of C routines
ii  libgtk2.0-0  2.8.20-2The GTK+ graphical user interface 
ii  libid3-3.8.3c2a  3.8.3-5 Library for manipulating ID3v1 and
ii  libmusicbrainz4c2a   2.1.3-2 Second generation incarnation of t
ii  libpango1.0-01.14.4-2Layout and rendering of internatio
ii  libstdc++6   4.1.1-13The GNU Standard C++ Library v3
ii  libvorbis0a  1.1.2-1 The Vorbis General Audio Compressi
ii  libvorbisfile3   1.1.2-1 The Vorbis General Audio Compressi
ii  libx11-6 2:1.0.0-8   X11 client-side library
ii  libxcursor1  1.1.5.2-5   X cursor management library
ii  libxext6 1:1.0.0-4   X11 miscellaneous extension librar
ii  libxfixes3   1:4.0.1-4   X11 miscellaneous 'fixes' extensio
ii  libxi6   1:1.0.0-5   X11 Input extension library
ii  libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library
ii  libxrandr2   2:1.1.0.2-4 X11 RandR extension library
ii  libxrender1  1:0.9.0.2-4 X Rendering Extension client libra
ii  zlib1g   1:1.2.3-13  compression library - runtime

zinf recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#386641: closed by Mark Brown [EMAIL PROTECTED] (Bug#386641: fixed in nis 3.17-1)

[Martin Dorey]

I tested 3.17-2 with sudo kill -PIPE and saw that it didn't die, whereas
nis from sarge did die.  Looking at the source, though, I think Mark
Brown just applied my first patch.  man 2 clone suggests that the signal
handling thread will be ignoring SIGPIPE, inheriting that setting from
the main thread:

  Since Linux 2.5.35, flags must also include CLONE_SIGHAND if
CLONE_THREAD
  is specified.

So that's why it works.  It does leave the code in the slightly
misleading state of having a case for catching a SIGPIPE signal which
will never be caught.  No big deal.
-
Martin's Outlook, BlueArc Engineering

Bug#386641: nis: ypbind dies with SIGPIPE when NIS server unreachable

[Martin Dorey]

I'm afraid I was rushing my patch on Friday evening and my ypbind died,
probably the same way as previously, over the weekend.  I was missing a
line adding SIGPIPE to the sigs_to_catch in the signal handling thread,
not just the sigs_to_block in the main thread.  I've attached an updated
patch against the original version but I still have to add a rider that,
despite spending several hours on it, I've still not managed to test
this to my satisfaction.  It stayed up on Sunday night through another
network outage when other servers didn't but I won't be convinced unless
I can reproduce the problem on demand.
-
Martin's Outlook, BlueArc Engineering



ypbind.patch
Description: ypbind.patch

Bug#386641: nis: ypbind dies with SIGPIPE when NIS server unreachable

[Martin Dorey]

Package: nis
Version: 3.16-2
Severity: normal
Tags: patch

When our NIS server becomes unavailable, all of our NIS clients die a few
minutes later.  I strace()d one on a deliberate outage and found that it died
with SIGPIPE.  Here's an extract from the strace output and a suggestion for a
patch.  Other programs in the nis package seem to ignore SIGPIPE (in different
ways).  I haven't contacted upstream.

accept(5, {sa_family=AF_INET, sin_port=htons(879), 
sin_addr=inet_addr(127.0.0.1)}, [16]) = 7
...
poll([{fd=4, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}, {fd=5, 
events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND, revents=POLLIN|POLLRDNORM}, {fd=7, 
events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND, revents=POLLIN|POLLRDNORM}, {fd=8, 
events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND, 
revents=POLLIN|POLLRDNORM|POLLERR|POLLHUP}, {fd=-1}], 5, -1) = 3
accept(5, {sa_family=AF_INET, sin_port=htons(880), 
sin_addr=inet_addr(127.0.0.1)}, [16]) = 9
poll([{fd=7, events=POLLIN, revents=POLLIN}], 1, 35000) = 1
read(7, \200\0\%2\347\336\0\0\0\0\0\0\0\2\0\1\206\247\0\0\0..., 4000) = 52
...
write(7, \200\0\0 %2\347\336\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 36) = -1 
EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---

--- /tmp/ypbind-mt.c.orig   2006-09-08 18:01:28.0 -0700
+++ /tmp/ypbind-mt.c.new2006-09-08 18:14:22.0 -0700
@@ -457,6 +457,10 @@
  if (ping_interval  1)
do_binding ();
  break;
+   case SIGPIPE:
+ if (debug_flag)
+   log_msg (LOG_DEBUG, _(Ignoring SIGPIPE.));
+ break;
default:
  log_msg (LOG_ERR, _(Unknown signal: %d), caught);
  break;
@@ -679,6 +683,7 @@
   sigaddset (sigs_to_block, SIGQUIT);
   sigaddset (sigs_to_block, SIGSEGV);
   sigaddset (sigs_to_block, SIGHUP);
+  sigaddset (sigs_to_block, SIGPIPE);
   if (pthread_sigmask (SIG_BLOCK, sigs_to_block, NULL) != 0)
 {
   log_msg (LOG_ERR, _(Could not block signals.));

-- Package-specific info:

NIS domain: uk 


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)

Versions of packages nis depends on:
ii  debconf [debconf-2.0]1.5.3   Debian configuration management sy
ii  libc62.3.6.ds1-2 GNU C Library: Shared libraries
ii  libgdbm3 1.8.3-3 GNU dbm database routines (runtime
ii  libslp1  1.2.1-5 OpenSLP libraries
ii  make 3.81-2  The GNU version of the make util
ii  netbase  4.26Basic TCP/IP networking system
ii  portmap  5-20The RPC portmapper
ii  sysvinit 2.86.ds1-15 System-V-like init utilities

nis recommends no packages.

-- debconf information:
* nis/not-yet-configured:
* nis/domain: uk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#386489: aptitude: show ~nsun-java5 only lists sun-java5-bin

[Martin Dorey]

Package: aptitude
Version: 0.4.3-1
Severity: normal

aptitude install ~nsun-java5 gives at least every appearance of installing
all of:

sun-java5-bin - Sun Java(TM) Runtime Environment (JRE) 5.0
sun-java5-demo - Sun Java(TM) Development Kit (JDK) 5.0 demos and examples
sun-java5-doc - Sun JDK(TM) Documention -- integration installer
sun-java5-fonts - Lucida TrueType fonts (from the Sun JRE)
sun-java5-jdk - Sun Java(TM) Development Kit (JDK) 5.0
sun-java5-jre - Sun Java(TM) Runtime Environment (JRE) 5.0
sun-java5-plugin - The Java(TM) Plug-in, Java SE 5.0
sun-java5-source - Sun Java(TM) Development Kit (JDK) 5.0 source files

Yet aptitude show ~nsun-java5 only gives information on sun-java5-bin.  The
man page says to look in /usr/share/doc/aptitude/lang/html/index.html
(although it's actually in /usr/share/doc/aptitude/html/lang/index.html) and
that says all matching packages will be displayed.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)

Versions of packages aptitude depends on:
ii  apt [libapt-pkg-libc6.3-6-3. 0.6.45  Advanced front-end for dpkg
ii  libc62.3.6.ds1-2 GNU C Library: Shared libraries
ii  libgcc1  1:4.1.1-13  GCC support library
ii  libncursesw5 5.5-2   Shared libraries for terminal hand
ii  libsigc++-2.0-0c2a   2.0.16-3type-safe Signal Framework for C++
ii  libstdc++6   4.1.1-13The GNU Standard C++ Library v3

Versions of packages aptitude recommends:
ii  aptitude-doc-en [aptitude-doc 0.4.2-1English manual for aptitude, a ter

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#386489: aptitude: show ~nsun-java5 only lists sun-java5-bin

[Martin Dorey]

tags 386489 patch

This seems to fix it for me, perhaps in the intended manner, although
I've probably indented it all wrongly.

--- /tmp/cmdline_show.cc.orig   2006-09-07 17:51:21.0 -0700
+++ /tmp/cmdline_show.cc.new2006-09-07 17:50:40.0 -0700
@@ -535,7 +535,8 @@
   for(pkgCache::PkgIterator P=(*apt_cache_file)-PkgBegin();
  !P.end(); ++P)
if(m-matches(P))
- return do_cmdline_show_target(P, source, sourcestr, verbose,
has_explicit_source);
+ if (!do_cmdline_show_target(P, source, sourcestr, verbose,
has_explicit_source))
+   return false;
 
   delete m;
 }
-
Martin's Outlook, BlueArc Engineering

Bug#384135: linux-image-2.6.17-2-686: description doesn't mention new support for SMP

[Martin Dorey]

Package: linux-image-2.6.17-2-686
Version: 2.6.17-6
Severity: minor

It seems unfortunate that the package description doesn't mention that you no
longer need a -smp kernel to support hyperthreading.  I'd deferred upgrading
for some time because I was waiting for a package I no longer need.  The 686
smp packages used to say explicitly that they had smp support.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)

Versions of packages linux-image-2.6.17-2-686 depends on:
ii  module-init-tools 3.2.2-3tools for managing Linux kernel mo
ii  yaird [linux-initramfs-tool]  0.0.12-17  Yet Another mkInitRD

Versions of packages linux-image-2.6.17-2-686 recommends:
ii  libc6-i686   2.3.6.ds1-2 GNU C Library: Shared libraries [i

-- debconf information:
  linux-image-2.6.17-2-686/postinst/old-initrd-link-2.6.17-2-686: true
  linux-image-2.6.17-2-686/postinst/old-dir-initrd-link-2.6.17-2-686: true
  linux-image-2.6.17-2-686/preinst/lilo-initrd-2.6.17-2-686: true
  linux-image-2.6.17-2-686/postinst/depmod-error-initrd-2.6.17-2-686: false
  linux-image-2.6.17-2-686/postinst/create-kimage-link-2.6.17-2-686: true
  linux-image-2.6.17-2-686/preinst/lilo-has-ramdisk:
  linux-image-2.6.17-2-686/preinst/already-running-this-2.6.17-2-686:
  linux-image-2.6.17-2-686/preinst/bootloader-initrd-2.6.17-2-686: true
  linux-image-2.6.17-2-686/preinst/initrd-2.6.17-2-686:
  linux-image-2.6.17-2-686/preinst/abort-install-2.6.17-2-686:
  linux-image-2.6.17-2-686/preinst/elilo-initrd-2.6.17-2-686: true
  linux-image-2.6.17-2-686/preinst/failed-to-move-modules-2.6.17-2-686:
  linux-image-2.6.17-2-686/postinst/really-run-bootloader-2.6.17-2-686: true
  linux-image-2.6.17-2-686/postinst/bootloader-test-error-2.6.17-2-686:
  linux-image-2.6.17-2-686/prerm/removing-running-kernel-2.6.17-2-686: true
  linux-image-2.6.17-2-686/preinst/abort-overwrite-2.6.17-2-686:
  linux-image-2.6.17-2-686/postinst/old-system-map-link-2.6.17-2-686: true
  linux-image-2.6.17-2-686/preinst/overwriting-modules-2.6.17-2-686: true
  linux-image-2.6.17-2-686/postinst/kimage-is-a-directory:
  linux-image-2.6.17-2-686/prerm/would-invalidate-boot-loader-2.6.17-2-686: true
  linux-image-2.6.17-2-686/postinst/depmod-error-2.6.17-2-686: false
  linux-image-2.6.17-2-686/postinst/bootloader-error-2.6.17-2-686:


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#316378: autofs: Deadlock causes automount failure

[Martin Dorey]

I ran into this too and spammed the autofs
list. Joe Pruett points me at http://www.mail-archive.com/autofs@linux.kernel.org/msg05016.html,
in which Ian Kent suggests disabling the autofs
locking, providing that mount locks mtab
properly. Does Debian's
mount do that?

-
Martin's Outlook, BlueArc Engineering

Bug#316378: autofs: Deadlock causes automount failure

[Martin Dorey]

martin Ian Kent suggests disabling the autofs locking, providing that
martin mount locks mtab properly.  Does Debian's mount do that?

steinar strace seems to indicate that it does: 

Cool.  I have *no* idea what I'm doing here but...

[EMAIL PROTECTED]:/tmp$ apt-get source autofs
[EMAIL PROTECTED]:/tmp$ cd autofs-4.1.4
[EMAIL PROTECTED]:/tmp/autofs-4.1.4$ wget -O
debian/patches/080_configurable_locking
http://www.kernel.org/pub/linux/daemons/autofs/v4/autofs-4.1.4-configure
able-locking.patch

... and applying this patch...

[EMAIL PROTECTED]:/tmp$ diff -u clean/autofs-4.1.4/debian/rules
autofs-4.1.4/debian/
--- clean/autofs-4.1.4/debian/rules 2006-06-29 14:40:28.0
-0700
+++ autofs-4.1.4/debian/rules   2006-06-29 14:29:17.0 -0700
@@ -30,7 +30,7 @@
dh_testdir
(cd $(BUILD_DIR)  \
./configure --prefix=/usr --mandir=/usr/share/man \
-   --host=$(DEB_HOST_GNU_TYPE)
--build=$(DEB_BUILD_GNU_TYPE) )
+   --host=$(DEB_HOST_GNU_TYPE)
--build=$(DEB_BUILD_GNU_TYPE) --disable-mount-locking)
touch $@
 
 source.make: $(STAMP_DIR)/source.make
[EMAIL PROTECTED]:/tmp$

... gave me something I could sudo dpkg-buildpackage; sudo dpkg -i
../autofs_4.1.4-10_i386.deb and which then solved my problem.
-
Martin's Outlook, BlueArc Engineering

Bug#366659: dpkg-dev: usage error goes to stdout instead of stderr

[Martin Dorey]

Package: dpkg-dev
Version: 1.13.19
Severity: minor
Tags: patch

I redirected the output of dpkg-scanpackages into a Packages file but a usage
error was produced, which I then didn't see.  This confused me, not to mention
apt-get.

$ dpkg-scanpackages  /dev/null
$ 

Patched version:

$ /tmp/dpkg-scanpackages  /dev/null
dpkg-scanpackages [-u] [-aarch] [-m] binarypath overridefile [pathprefix]  
Packages

 Options:
 --udeb, -u scan for udebs
 --arch, -a architecture to scan for
 --multiversion, -m allow multiple versions of a single package
 --help, -h show this help

$

I'm no Perl wizard, so please do laugh at my patch.  I tried.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-686-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages dpkg-dev depends on:
ii  binutils 2.16.1cvs20060413-1 The GNU assembler, linker and bina
ii  cpio 2.6-11  GNU cpio -- a program to manage ar
ii  dpkg 1.13.18 package maintenance system for Deb
ii  make 3.81-1  The GNU version of the make util
ii  patch2.5.9-4 Apply a diff file to an original
ii  perl [perl5] 5.8.8-4 Larry Wall's Practical Extraction 
ii  perl-modules 5.8.8-4 Core Perl modules

Versions of packages dpkg-dev recommends:
ii  bzip2 1.0.3-2high-quality block-sorting file co
ii  gcc [c-compiler]  4:4.0.3-3  The GNU C compiler
ii  gcc-3.3 [c-compiler]  1:3.3.6-13 The GNU C compiler
ii  gcc-4.0 [c-compiler]  4.0.3-2The GNU C compiler
ii  gcc-4.1 [c-compiler]  4.1.0-2The GNU C compiler

-- no debconf information
--- /usr/bin/dpkg-scanpackages  2006-04-09 20:52:19.0 -0700
+++ /tmp/dpkg-scanpackages  2006-05-09 23:10:48.0 -0700
@@ -53,7 +53,7 @@
 
 my $result = 
GetOptions(\%options,'help|h|?','udeb|u!','arch|a=s','multiversion|m!');
 
-print END and exit 1 if not $result or $options{help} or @ARGV  2;
+print(STDERR END) and exit 1 if not $result or $options{help} or @ARGV  2;
 dpkg-scanpackages [-u] [-aarch] [-m] binarypath overridefile [pathprefix]  
Packages
 
  Options:

Bug#365120: tic: undefined symbol: _tracef

[Martin Dorey]

Package: ncurses-bin
Version: 5.5-1.1
Severity: minor

With -v levels above 1, tic fails with a message as below:

[EMAIL PROTECTED]:/tmp$ infocmp  term.tic
[EMAIL PROTECTED]:/tmp$ tic -v2 term.tic
term.tic, line 2, 'xterm' tic: symbol lookup error: tic: undefined symbol: 
_tracef
[EMAIL PROTECTED]:/tmp$ 

With -v1, it works:

[EMAIL PROTECTED]:/tmp$ tic -v1 term.tic
term.tic, line 2, 'xterm' term.tic, line 2, 'xterm' term.tic, line 2, 
terminal 'xterm': non-curses applications may be confused by ich1 with smir/rmir
[EMAIL PROTECTED]:/tmp$ 

Preloading the shared library from the -dbg package, it works:

[EMAIL PROTECTED]:/tmp$ LD_PRELOAD=/usr/lib/debug/libncurses.so.5.5 tic -v2 
term.tic
Comment range is 0 to 71
Starting 'xterm|X11 terminal emulator'
head = xterm|X11 terminal emulator
tail = xterm|X11 terminal emulator
RESOLUTION BEGINNING
NO MULTIPLE NAME OCCURRENCES
NAME RESOLUTION COMPLETED OK
MERGES COMPLETED OK
RESOLUTION FINISHED
term.tic, line 2, 'xterm' will trim sgr0
original sgr0=\e[m\e(B
trimmed  sgr0=\e[0m
term.tic, line 2, 'xterm' can write to lower-right by suppressing automargin
term.tic, line 2, terminal 'xterm': non-curses applications may be confused 
by ich1 with smir/rmir
SANITY CHECK FINISHED
Created x/xterm
[EMAIL PROTECTED]:/tmp$

Presumably I'm missing something because it seems a little obscure to require 
the user to work how how to use LD_PRELOAD in order to use a potentially useful 
option.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages ncurses-bin depends on:
ii  libc6 2.3.6-6GNU C Library: Shared libraries
ii  libncurses5   5.5-1.1Shared libraries for terminal hand

ncurses-bin recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#357515: flex: project web page location doesn't work

[Martin Dorey]

Package: flex
Version: 2.5.33-2
Severity: minor

The Description field displayed by (eg) dpkg --status flex says:

 The project web page is at http://lex.sf.net/

That doesn't work, at least not or me and at the moment.  http://flex.sf.net/
works and seems more plausible.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-rc5-686-smp
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages flex depends on:
ii  debconf [debconf-2.0] 1.4.72 Debian configuration management sy
ii  libc6 2.3.6-3GNU C Library: Shared libraries an
ii  m41.4.4-1a macro processing language

Versions of packages flex recommends:
ii  gcc [c-compiler]  4:4.0.2-2  The GNU C compiler
ii  gcc-3.3 [c-compiler]  1:3.3.6-12 The GNU C compiler
ii  gcc-4.0 [c-compiler]  4.0.3-1The GNU C compiler
ii  gcc-4.1 [c-compiler]  4.1.0-0The GNU C compiler

-- debconf information:
  flex/upgrade/pre_2.5.5: false


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#348008: man-db: --quiet doesn't Produce no warnings as the man page claims

[Martin Dorey]

Package: man-db
Version: 2.4.3-3
Severity: minor

man mandb says:

   -q, --quiet
 Produce no warnings.

/etc/cron.daily/man-db says:

start-stop-daemon --start --pidfile /dev/null \
  --startas /usr/bin/mandb --oknodo --chuid man \
-- --no-purge --quiet

So I think it's being run with --quiet.  Yet I still see mails like:

/etc/cron.daily/man-db:
mandb: warning: /usr/share/man/man3/open_memstream.3.gz is a dangling symlink

Yeah, I know, there's probably something wrong with open_memstream's package 
(and all the other packages for which I see these messages).  The point here is 
that mandb is generating a warning when the documentation says it shouldn't.  
I'd rather the behavior changed to be in line with the documentation than vice 
versa but that choice is the maintainer's prerogative.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.9-1-686-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages man-db depends on:
ii  bsdmainutils 6.1.3   collection of more utilities from 
ii  debconf [debconf-2.0]1.4.67  Debian configuration management sy
ii  dpkg 1.13.11.0.1 package maintenance system for Deb
ii  groff-base   1.18.1.1-11 GNU troff text-formatting system (
ii  libc62.3.5-11GNU C Library: Shared libraries an
ii  libgdbm3 1.8.3-2 GNU dbm database routines (runtime

man-db recommends no packages.

-- debconf information:
  man-db/build-database: true
  man-db/rebuild-database: true
  man-db/install-setuid: false


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#343274: x2vnc: selection cannot be pasted into Java applications on amd64

[Martin Dorey]

Package: x2vnc
Version: 1.6-3
Severity: normal
Tags: patch

I mailed Ola to say (paraphrasing a little):

 A coworker recently
 tried to use x2vnc on an amd64 and ran into another problem with the
 same line of code as was behind Bug#191697.
 
 Upstream's accepted (but not yet released) a patch I submitted:

 http://fredrik.hubbe.net/hacker/viewtopic.php?t=240start=0

 The x2vnc upstream author seems to be anything but moribund and I
 don't have any pressing need for an officially packaged fix.  I just
 thought I'd offer to raise a Debian bug, with a patch, for the x2vnc
 issue if it would help you or others.  I don't want to make
 unnecessary work for you, though, so waiting for upstream would be
 fine by me.

Ola thanked me for the information and tried to add a patch tag and then reopen
bug 191697.  This failed because that bug is archived.  I think that's telling
me I should open a new bug.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-1-686-smp
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages x2vnc depends on:
ii  libc62.3.5-7 GNU C Library: Shared libraries an
ii  libx11-6 6.8.2.dfsg.1-10 X Window System protocol client li
ii  libxext6 6.8.2.dfsg.1-10 X Window System miscellaneous exte
ii  libxss1  6.8.2.dfsg.1-10 X Screen Saver client-side library
ii  xlibs6.8.2.dfsg.1-10 X Window System client libraries m

x2vnc recommends no packages.

-- no debconf information

*
This email and any attachment is confidential. It may only  be read, copied
 and used by the intended recipient(s). If you are not the intended recipient 
(s), you may not copy, use, distribute, forward, store or disclose this e-mail 
or any attachment. If you are not the intended recipient(s) or have otherwise 
received this e-mail in error, you should destroy it and any attachment and 
notify the sender by reply e-mail or send a message to: [EMAIL PROTECTED]
*


--- /tmp/x2vnc-1.6/x.c 2005-11-25 02:39:45.0 -0800
+++ /home/martind/playpen/x.c 2005-11-25 15:22:15.0 -0800
@@ -721,7 +721,7 @@
* (GRM 24 Oct 2003)
*/
   int ret;
-  int targets[2];
+  Atom targets[2];
   if(req-property == None)
 req-property = TARGETS;
 
@@ -731,7 +731,7 @@
   req-requestor,
   req-property,
   XA_ATOM,
-  8 * sizeof(int),
+  32,
   PropModeReplace,
   (unsigned char *) targets,
   2);

Bug#341200: rxvt: selection cannot be pasted into Java applications on amd64

[Martin Dorey]

Package: rxvt
Version: 1:2.6.4-9
Severity: normal
Tags: patch

When pasting the X11 selection into Sun's Java implementation,
specifically:

java version 1.5.0_05
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing)

... but probably any Sun implementation and possibly others, the paste
fails to have any effect except that the Sun JVM shared library outputs
this message, or similar, on stderr:

Atom was -6276164

This behavior doesn't happen on the i386 architecture but does on the
amd64 architecture.

The cause is the incorrect size of the elements in the target_list array
passed to XChangeProperty in screen.c.  This has been rectified in the
CVS version of rxvt with the following patch:

http://cvs.sourceforge.net/viewcvs.py/rxvt/rxvt/src/screen.c?r1=1.267r2=1.268

The check-in comment says:

  Try to deal with systems which don't use an internal Atom
  size of 32 bits more nicely

Although this does indeed make the code nicer, it also makes it correct.
Atom is a 64 bit type in the amd64 architecture but, when passing
XA_ATOM arguments to XChangeProperty, one must use a format argument
of 32 but pass an array of 64 bit Atoms to the function.

Well, that's my belief, which I can substantiate with snippets of other
applications which don't suffer from this problem and extracts from
Xlibint.[hc] and ChProp.c from the X distribution as required.

Hopefully reportbug is about to ask me for the filename of my patch for
rxvt-2.6.4.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-2-amd64-k8
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)

Versions of packages rxvt depends on:
ii  base-passwd  3.5.10  Debian base system master password
ii  libc62.3.5-7 GNU C Library: Shared libraries an
ii  libx11-6 6.8.2.dfsg.1-10 X Window System protocol client li
ii  xlibs6.8.2.dfsg.1-10 X Window System client libraries m

rxvt recommends no packages.

-- no debconf information

*
This email and any attachment is confidential. It may only  be read, copied
 and used by the intended recipient(s). If you are not the intended recipient 
(s), you may not copy, use, distribute, forward, store or disclose this e-mail 
or any attachment. If you are not the intended recipient(s) or have otherwise 
received this e-mail in error, you should destroy it and any attachment and 
notify the sender by reply e-mail or send a message to: [EMAIL PROTECTED]
*


--- screen.c-2.6.4	2005-11-25 15:37:15.0 -0800
+++ screen.c	2005-11-28 23:00:52.0 -0800
@@ -3403,14 +3403,6 @@
 
 /* - */
 /*
- * On some systems, the Atom typedef is 64 bits wide.  We need to have a type
- * that is exactly 32 bits wide, because a format of 64 is not allowed by
- * the X11 protocol.
- */
-typedef CARD32  Atom32;
-
-/* - */
-/*
  * Respond to a request for our current selection
  * EXT: SelectionRequest
  */
@@ -3419,7 +3411,7 @@
 selection_send(const XSelectionRequestEvent * rq)
 {
 XEvent  ev;
-Atom32  target_list[4];
+Atomtarget_list[4];
 Atomtarget;
 static Atom xa_targets = None;
 static Atom xa_compound_text = None;
@@ -3444,13 +3436,12 @@
 ev.xselection.time = rq-time;
 
 if (rq-target == xa_targets) {
-	target_list[0] = (Atom32) xa_targets;
-	target_list[1] = (Atom32) XA_STRING;
-	target_list[2] = (Atom32) xa_text;
-	target_list[3] = (Atom32) xa_compound_text;
+	target_list[0] = xa_targets;
+	target_list[1] = XA_STRING;
+	target_list[2] = xa_text;
+	target_list[3] = xa_compound_text;
 	XChangeProperty(Xdisplay, rq-requestor, rq-property, rq-target,
-			(8 * sizeof(target_list[0])), PropModeReplace,
-			(unsigned char *)target_list,
+			32, PropModeReplace, (unsigned char *)target_list,
 			(sizeof(target_list) / sizeof(target_list[0])));
 	ev.xselection.property = rq-property;
 } else if (rq-target == XA_STRING