Bug#278922: libc6-dev: Newer version of sys/queue.h available
Package: libc6-dev Version: 2.3.2.ds1-18 Severity: wishlist Hi libc maintainers, I'm having trouble compiling heimdal with pkinit support because sys/queue.h in Debian seems to be at version 8.3 but I see FreeBSD has 8.5. I don't know if this a known reason and there's a reason for that, but if not it would be great to update it to last version. Thanks in advance, Josep -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8.1custom2 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages libc6-dev depends on: ii libc62.3.2.ds1-18GNU C Library: Shared libraries an ii linux-kernel-headers 2.5.999-test7-bk-17 Linux Kernel Headers for developme -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64
On Mon, Oct 25, 2004 at 08:18:40AM +0200, Andreas Jochens wrote: On 04-Oct-24 23:24, Kurt Roeckx wrote: On Sun, Oct 24, 2004 at 10:18:15PM +0200, Andreas Jochens wrote: This patch is harmless with respect to any LSB requirement. The name of the dynamic loader, which is coded into every binary can only be changed in the gcc package. This patch does not change that. I don't know what you all changed in the gcc-3.4 archive. But this is what I now get with something I just compiled: ldd test libc.so.6 = /lib/libc.so.6 (0x002a9566d000) /lib/ld-linux-x86-64.so.2 = /lib/ld-linux-x86-64.so.2 (0x002a95556000) While with the pure64 archive with either gcc-3.3 of 3.4 it's still pointing to /lib64/ld-linux-x86-64.so.2 I patched the gcc-3.4 package in the amd64/gcc-3.4 archive to get that result. For the patch I used please look at BTS #277852. I recompiled the complete amd64/gcc-3.4 archive with that patch and without the '/lib64' and '/usr/lib64' symlinks in place. I still have to reupload most of the recompiled packages to alioth but you should be able to debootstrap a new chroot from the amd64/gcc-3.4 archive and do a 'rm /lib64' without making the system unusable. Does your binaries run on other x86-64 distributions without any compat symlinks ? I think this is an absolute requirement for pure64. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64
On Sat, Oct 30, 2004 at 04:12:01PM +0200, Andreas Jochens wrote: Does your binaries run on other x86-64 distributions without any compat symlinks ? I think this is an absolute requirement for pure64. The binaries will run on all distributions which have the interpreter accessible as /lib/ld-linux-x86-64.so.2. Gentoo, Ubuntu and of course pure64 install the interpreter as /lib/ld-linux-x86-64.so.2 today, so the binaries will run on these distributions without changes. On other distributions it may be necessary to execute ln -sf /lib64/ld-linux-x86-64.so.2 /lib/ld-linux-x86-64.so.2 to run the binaries until those distributions install that symlink themselves. You cannot do that if you are not root, while you can extract binaries out of Debian packages and run them. For simple stuff it works fine. Anyway, if you intend to run binaries on different distributions, you should create binaries which conform to the LSB standard and you should install the LSB compatibility package on the target system. Otherwise you will certainly have more serious problems than the location of the interpreter. Does the LSB compatibility package for RedHat or Suse provide such a symlink ? P.S.: Do you really want to install Debian binary packages on other (non-Debian related) distributions (e.g. RedHat, SuSe)? Have you already tried that and did it work? Yes it works fine for the simple stuff I am interested in (mathematical command-line driven programs). It is far less trouble than installing a proper build environment without root access. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64
On 04-Oct-30 16:55, Bill Allombert wrote: On Sat, Oct 30, 2004 at 04:12:01PM +0200, Andreas Jochens wrote: Anyway, if you intend to run binaries on different distributions, you should create binaries which conform to the LSB standard and you should install the LSB compatibility package on the target system. Otherwise you will certainly have more serious problems than the location of the interpreter. Does the LSB compatibility package for RedHat or Suse provide such a symlink ? The LSB compatibility packages for Debian, RedHat and Suse install a special symlink which is defined by the LSB as 'ld-lsb-x86-64.so.1' instead of 'ld-linux-x86-64.so.2'. The LSB specifies that conforming binaries have to use that symlink. Such binaries can be compiled by passing the switch -Wl,-dynamic-linker=/lib64/ld-lsb-x86-64.so.1 to the gcc compiler. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279001: nscd problems with GETHOSTBYNAME and GETHOSTBYADDR
Package: nscd
Version: 2.3.2.ds1-18
System Description:
kernel = 2.4.27-1-k7
libc6 = 2.3.2.ds1-18
mozilla = 1.7.3-5
Symptom:
After completing an 'apt-get upgrade', I noticed that mozilla was
frequently taking a long amount of time to do a host name lookup. Even
sites visited a few minutes previously required 10+ seconds to complete
a host name lookup. Additionally, 'ping hostname' also takes an
inordinate amount of time in it's host lookup (see below).
My initial thinking was nscd and I've found some issues that may be the
cause of this problem. Note that I am using a cable modem on my home
connection.
*
Case 1 (Case 2 follows) - Hostname not in cache:
console command (debug output follows):
# ping www.drudgeport.com
delay of about 6 seconds
PING drudgereport.com (66.28.209.210) 56(84) bytes of data.
delay of about 6 seconds
64 bytes from 66.28.209.210.ha-hosting.com (66.28.209.210): icmp_seq=1
ttl=51 time=82.8 ms
...
Debug output (note this is the first time I've ping this host so I
expect the following output):
handle_request: request received (Version = 2) from PID 2299
2264: GETHOSTBYNAME (www.drudgereport.com)
2264: Haven't found www.drudgereport.com in hosts cache!
2264: handle_request: request received (Version = 2) from PID 2299
2264: GETHOSTBYADDR (66.28.209.210)
2264: Haven't found 66.28.209.210 in hosts cache!
2264: handle_request: request received (Version = 2) from PID 2299
2264: GETHOSTBYADDR (66.28.209.210)
***
Case 2 - Hostname should be in cache...I'm repeating the ping hostname
command about 5 seconds after completing Case 1 above.
console command (debug output follows):
# ping www.drudgeport.com
delay of about 6 seconds
PING drudgereport.com (66.28.209.210) 56(84) bytes of data.
delay of about 6 seconds
64 bytes from 65.77.130.210.ha-hosting.com (65.77.130.210): icmp_seq=1
ttl=51 time=90.8 ms
...
Debug output:
2356: handle_request: request received (Version = 2) from PID 2364
2356: GETHOSTBYNAME (www.drudgereport.com)
2356: Haven't found www.drudgereport.com in hosts cache!
2360: handle_request: request received (Version = 2) from PID 2364
2360: GETHOSTBYADDR (66.28.209.210)
2360: Haven't found 66.28.209.210 in hosts cache!
2361: handle_request: request received (Version = 2) from PID 2364
2361: GETHOSTBYADDR (66.28.209.210)
2362: handle_request: request received (Version = 2) from PID 2364
2362: GETHOSTBYADDR (66.28.209.210)
Stack trace:
[pid 2357] getppid() = 2356
[pid 2357] poll( unfinished ...
[pid 2358] ... poll resumed [{fd=3, events=POLLRDNORM,
revents=POLLRDNORM}],1, 15000) = 1
[pid 2356] ... accept resumed 0, NULL) = 7
[pid 2358] accept(3, unfinished ...
[pid 2356] read(7, \2\0\0\0\4\0\0\0\25\0\0\0, 12) = 12
[pid 2356] getsockopt(7, SOL_SOCKET, SO_PEERCRED,
\t\0\0\0\0\0\0\0\0\0\0, [12]) = 0
[pid 2356] read(7, www.drudgereport.com\0, 21) = 21
[pid 2356] getpid()= 2356
[pid 2356] write(4, 2356: handle_request: request re..., 67) = 67
[pid 2356] getpid()= 2356
[pid 2356] write(4, 2356: \tGETHOSTBYNAME (www.drudge..., 44) = 44
[pid 2356] getpid()= 2356
[pid 2356] write(4, 2356: Haven\'t found \www.drudger..., 59) = 59
[pid 2356] gettimeofday({1099173622, 875148}, NULL) = 0
[pid 2356] getpid()= 2356
[pid 2356] open(/etc/resolv.conf, O_RDONLY) = 8
[pid 2356] fstat64(8, {st_mode=S_IFREG|0644, st_size=266, ...}) = 0
[pid 2356] old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000
[pid 2356] read(8, # Dynamic resolv.conf(5) file fo..., 4096) = 266
[pid 2356] read(8, , 4096) = 0
[pid 2356] close(8)= 0
[pid 2356] munmap(0x40018000, 4096)= 0
[pid 2356] open(/etc/hosts, O_RDONLY) = 8
[pid 2356] fcntl64(8, F_GETFD) = 0
[pid 2356] fcntl64(8, F_SETFD, FD_CLOEXEC) = 0
[pid 2356] fstat64(8, {st_mode=S_IFREG|0644, st_size=309, ...}) = 0
[pid 2356] old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000
[pid 2356] read(8, 127.0.0.1\tlocalhost\tarrakis\n\n192..., 4096) = 309
[pid 2356] read(8, , 4096) = 0
[pid 2356] close(8)= 0
[pid 2356] munmap(0x40018000, 4096)= 0
[pid 2356] socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 8
[pid 2356] connect(8, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(10.0.0.1)}, 28) = 0
[pid 2356] send(8, ]O\1\0\0\1\0\0\0\0\0\0\3www\fdrudgereport\3co...,
38, 0) = 38
[pid 2356] gettimeofday({1099173622, 877606}, NULL) = 0
[pid 2356] poll( unfinished ...
[pid 2357] ... poll resumed [{fd=5, events=POLLIN}], 1, 2000) = 0
[pid 2357] getppid() = 2356
[pid 2357] poll([{fd=5, events=POLLIN}], 1, 2000) = 0
[pid 2357] getppid() = 2356
[pid 2357] poll([{fd=5, events=POLLIN}], 1, 2000) = 0
[pid 2357] getppid() = 2356
[pid 2357] poll( unfinished ...
[pid 2356] ... poll
Re: TLS-version of libc6/{testing,unstable} breaks libunwind
On Thu, Oct 28, 2004 at 02:14:48AM +0900, GOTO Masanori wrote: I think it does not break d-i size limitation. If you have no David, Daniel, if you have no objection, I'll put it in -19. Go ahead, I guess. We should really talk about just turning on unwind tables instead by default, and see what the size impact is. Later. -- Daniel Jacobowitz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#278426: libc6: memcpy is ignoring the size-parameter
On Tue, Oct 26, 2004 at 05:31:10PM -0400, Thomas Dickey wrote: My guess is that some change to memcpy modified its logic to copy words (or larger chunks) rather than bytes has been broken. Alternatively, valgrind is broken (it's hard to tell). More likely valgrind. Do you have a stand-alone executable testcase? -- Daniel Jacobowitz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
