Bug#365233: libc6: memory leak in getprotobyname
On Fri, Apr 28, 2006 at 06:51:54PM +0200, Slaven Rezic wrote:
#include netdb.h
main() {
struct protoent *pent;
while(1) {
pent = getprotobyname(tcp);
}
}
valgrind shows that the leaking function is fopen(), called from
getprotobyname_r(). It seems that getprotobyname_r() does not check if
it already has /etc/protocols open and always opens a new file
descriptor for it.
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365647: Does libc6 2.3.6-7 break Sarge
Hi, it seems related to #364338, #364516. There is LD_ASSUME_KERNEL=2.4 in sarge version of /usr/sbin/mkinitrd. Could you downgrade your initrd-tools to sarge version and change it into LD_ASSUME_KERNEL=2.4.1. Does it help ? Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#364231: [parisc-linux] Re: Bug#364231: exception catching
[should we drop parisc-linux?] John David Anglin writes: Er, no; we're talking about official Debian packages here, and the libstdc++.so.6 in Debian is now from gcc-4.1. The problem is precisely that GMP *is* being built using gcc-4.0, but libstdc++ is from gcc-4.1, resulting in the double libgcc_s problem. Then, you must build *eveything* for hppa with gcc-4.1 or later. Unfortunately, there's an ABI break. Mixing libraries compiled with 4.0 or earlier with libraries compiled with 4.1 or later is just going to cause unnecessary problems. 3.3 uses libstdc++.so.5, so you avoid the double libgcc_s problem building GMP. However, you still have the ABI change affecting the passing and return of complex types. At a fundamental level, libstdc++.so.6, libgfortran.so.1.0.0 and any other gcc libraries built with 4.1 or later need glibc built with 4.1 to function correctly because of the various complex functions in the math library. I think there's a dynamic loader bug here as well. I'm just guessing but I think the double libgcc_s problem causes a problem with the handling of .eh_frame data. Ok, coming back to the question of the system compiler on hppa for etch. Assuming that hppa does want to do that: - is glibc buildable with gcc-4.1 on hppa? - libstdc++6 would need to conflict with libgcc2, which seems to be doable, but then rules out g++-3.4 and g++-4.0 as a fallback solution, where g++-4.1 fails. - libgfortran did have a soname change, so nothing needs to be done. - is libffi hit by the ABI change as well? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#216466: how are you today?
Hi there lovely, This kinbd of opportunity comces ones in a lifea. I don't want to miss it. Do you? I am coming tco your place in few days and I though may be wae can meet each other. If you adon't mind I can send you my picture. I am a girl. You can correspond with me using my email [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354749: marked as done (kernel panic with libc6-2.3.6-2)
Your message dated Tue, 02 May 2006 16:17:23 +0200 with message-id [EMAIL PROTECTED] and subject line debian bug #354749 can be closed has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Subject: kernel panic with libc6-2.3.6-2 Package: libc6 Version: 2.3.5-13 Severity: critical Justification: breaks the whole system Hello, Each week I try out the progress of Etch, and yesterday I upgraded libc6 (and libc6-amd64) from 2.3.5-13 to 2.3.6-2 * and continued working successfully with no problems* Today I boot my PC resulting in a kernel panic at boot (repeatedly, at the same location, reproducibly). Something about not being able to locate the root device. Since this is on a S-ATA disk on a MSI motherboard with nforce3 chipset that I had serious trouble with in the past (changing the names of its disks from hde5 - sda5 and back) I tried both booting with option root=/dev/sda5 and with root=/dev/hde5 to no avail. It took me quite a while to figure out what it was that broke the system. Kernel 2.6.15 failed to boot; in an older kernel 2.6.8 on the same hardware the system booted fine. downgrading libc6 from 2.3.6-2 to 2.3.5-13 solved the problem. I'm really sorry that I can't pinpoint the problem better... good luck!! Frits PS: I've also installed udev 0.084-5, hal 0.5.6-4 and dbus 0.60.5 in case that's of any help.. -- 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.15-1-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] ---End Message--- ---BeginMessage--- Frits Daalmans a écrit : Hello Aurelien, In february I reported bug #354749, that upgrade of libc6 t o2.3.6 made my system unbootable; in the meantime this bug has been tagged unreproducible because I didn't write back. Update: you can close the bug; I am now running libc6 2.3.6-3 without any Ok, closing it with this mail. Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net ---End Message---
Bug#365647: Does libc6 2.3.6-7 break Sarge
Petr wrote: Hi, it seems related to #364338, #364516. There is LD_ASSUME_KERNEL=2.4 in sarge version of /usr/sbin/mkinitrd. Could you downgrade your initrd-tools to sarge version and change it into LD_ASSUME_KERNEL=2.4.1. Does it help ? Petr smtp:~# uname -r 2.4.27-3-586tsc smtp:~# apt-cache policy initrd-tools initrd-tools: Installed: 0.1.81.1 Candidate: 0.1.81.1 Version table: 0.1.84.1 0 650 http://mirrors.kernel.org testing/main Packages *** 0.1.81.1 0 990 http://mirror.cs.wisc.edu stable/main Packages 100 /var/lib/dpkg/status Before the change: smtp:~# mkinitrd -o /boot/temp 2.4.27-3-686 /bin/bash: error while loading shared libraries: libdl.so.2: \ cannot open shared object file: No such file or directory After the change: smtp:~# mkinitrd -o /boot/temp 2.4.27-3-686 /bin/bash: error while loading shared libraries: libdl.so.2: \ cannot open shared object file: No such file or directory grep: error while loading shared libraries: libc.so.6: \ cannot open shared object file: No such file or directory sort: error while loading shared libraries: libc.so.6: \ cannot open shared object file: No such file or directory awk: error while loading shared libraries: libm.so.6: \ cannot open shared object file: No such file or directory I also changed LD_ASSUME_KERNEL=2.4 to LD_ASSUME_KERNEL=2.4.1 in /usr/share/initrd-tools/scripts/e2fsprogs and then was able to create an initrd.img without the error. It appears it is required to change it in both places. Gary V -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#364231: [parisc-linux] Re: Bug#364231: exception catching
Ok, coming back to the question of the system compiler on hppa for etch. Assuming that hppa does want to do that: - is glibc buildable with gcc-4.1 on hppa? As far as I know, there's no new problems using 4.1 instead of 4.0. See http://lists.parisc-linux.org/pipermail/parisc-linux/2006-April/028894.html and test results for a gcc 4.2.0 build using this glibc build http://lists.parisc-linux.org/pipermail/parisc-linux/2006-April/028918.html - libstdc++6 would need to conflict with libgcc2, which seems to be doable, but then rules out g++-3.4 and g++-4.0 as a fallback solution, where g++-4.1 fails. True. - is libffi hit by the ABI change as well? No. It's not affected because it doesn't support complex types. I have one libffi fix that's not yet in 4.2.0 that fixes the remaining Java testsuite failures. I haven't tested a backport to 4.1. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Fixed in upload of glibc 2.3.999.1-1 to experimental
tag 181494 + fixed-in-experimental
quit
This message was generated automatically in response to an
upload to the experimental distribution. The .changes file follows.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 6 Mar 2006 16:49:38 -0500
Source: glibc
Binary: libc0.1-prof libc6-dev-amd64 libc-bin libc6-i686 libc6-dev-ppc64
libc0.3-pic glibc-doc libc0.3 libc-dev-bin libc0.1-i686 libc6.1-dev libc6-s390x
libnss-files-udeb libc6-dev-sparc64 libc6-i386 libc0.3-dev libc6-udeb libc6-dbg
libc6.1-pic libc6-dev libc0.3-prof libc6-sparcv9 libc0.1-udeb libc6-dev-i386
libc6.1-prof libc0.1-dev locales libc6-pic libc0.3-udeb libc6-dev-powerpc
libc0.1-pic libc6-ppc64 libc0.3-dbg libc0.1-dbg libc6-amd64 libc0.1 libc6-prof
libc6-powerpc libc6 libc6-sparcv9b libc6.1-udeb libc6.1-dbg nscd libc6-sparc64
libnss-dns-udeb libc6.1 libc6-dev-s390x
Architecture: source all amd64
Version: 2.3.999.1-1
Distribution: experimental
Urgency: low
Maintainer: GNU Libc Maintainers debian-glibc@lists.debian.org
Changed-By: Clint Adams [EMAIL PROTECTED]
Description:
glibc-doc - GNU C Library: Documentation
libc-bin - GNU C Library: Binaries
libc-dev-bin - GNU C Library: Development Binaries
libc6 - GNU C Library: Shared libraries
libc6-dbg - GNU C Library: Libraries with debugging symbols
libc6-dev - GNU C Library: Development Libraries and Header Files
libc6-dev-i386 - GNU C Library: 32bit development libraries for AMD64
libc6-i386 - GNU C Library: 32bit shared libraries for AMD64
libc6-pic - GNU C Library: PIC archive library
libc6-prof - GNU C Library: Profiling Libraries
libc6-udeb - GNU C Library: Shared libraries - udeb (udeb)
libnss-dns-udeb - GNU C Library: NSS helper for DNS - udeb (udeb)
libnss-files-udeb - GNU C Library: NSS helper for files - udeb (udeb)
locales- GNU C Library: National Language (locale) data [support]
nscd - GNU C Library: Name Service Cache Daemon
Closes: 181494
Changes:
glibc (2.3.999.1-1) experimental; urgency=low
.
[ Clint Adams ]
* New upstream version 2.4.
- Remove sparc-socket-weakalias.diff (merged upstream).
- Remove glibc235-dash.diff (merged upstream).
- Remove glibc235-gcc4-sparc-inline.diff (merged upstream).
- Remove regcomp_c.diff (merged upstream).
- Remove glibc235-gcc4-sparc-mv8.diff (merged upstream).
- Remove glibc-235-sparc-datastart.diff (merged upstream).
- Remove tst-setcontext_c.diff (merged upstream).
- Remove glibc-manual-memory.diff (merged upstream).
- Remove glibc-manual-string.diff (merged upstream).
- Remove divdi3-moddi3.diff (merged upstream).
- Remove glibc235-gcc4-elf.diff (merged upstream).
- Remove everything to do with nscd_nischeck.
- Update linuxthreads-sizefix.diff for 2.4.
- debian/shlibver: Bump up to 2.4-1.
.
[ Denis Barbier ]
- Remove complex-collate.diff (merged upstream).
- Remove cvs-{localedata,iso4217,iso639,tzdata}.diff,
- Remove from forward-backward-collation.diff a chunk merged upstream.
- debian/rules.d/tarball.mk: glibc-foo-2.4.tar.bz2 add-on unpacks
into either foo or glibc-foo-2.4, in which case it is renamed
into foo.
- Remove the GNU Libc Reference manual from glibc-doc because it is
not DFSG-free. (Closes: #181494)
The whole glibc-2.4/manual directory is removed from glibc-2.4.tar.bz2.
- debian/control: Drop Build-Depends: texinfo, texi2html.
- debian/control: Drop references to the antique libc-doc package.
.
[ Michael Banck ]
* debian/sysdeps/hurd.mk: Only use libidn for add-ons.
.
[ Aurelien Jarno ]
- Remove argp_h.diff (merged upstream).
Files:
b5bd5cf4a154ba4eae7b2e58cd07621d 2078 libs required glibc_2.3.999.1-1.dsc
d925c6227f128a796602530a10b6fb78 14587874 libs required
glibc_2.3.999.1.orig.tar.gz
6fc48499d0a7cf2fadb50869a054bc2b 565025 libs required glibc_2.3.999.1-1.diff.gz
43ba2c31075c56a6455bb7f58fed56c0 1649008 doc optional
glibc-doc_2.3.999.1-1_all.deb
474c68e8f7de39830b82d7bc80214454 3977238 libs standard
locales_2.3.999.1-1_all.deb
fa13718dfe33b30a92c9788d47efb6d0 3817266 libs required
libc6_2.3.999.1-1_amd64.deb
cb70a09581a52dc4c0320de4e7927227 1988076 libdevel standard
libc6-dev_2.3.999.1-1_amd64.deb
274b6e4ae0b539f8bf58281590e85739 1510986 libdevel extra
libc6-prof_2.3.999.1-1_amd64.deb
f783d7f915b85b3571791a02f1db9055 1330104 libdevel optional
libc6-pic_2.3.999.1-1_amd64.deb
2aa5ea706a49b713d4fa049a07eef756 738500 libs required
libc-bin_2.3.999.1-1_amd64.deb
98602efa71c4068bf36f7cd7d5658035 157272 libdevel required
libc-dev-bin_2.3.999.1-1_amd64.deb
aad9bad963af6e6f11a1ff9274f7a3e2 3412448 libs standard
libc6-i386_2.3.999.1-1_amd64.deb
88dbe86bff907c76fb18c27ab7b106f7 1522000 libdevel optional
libc6-dev-i386_2.3.999.1-1_amd64.deb
3e70f14264d6379671ead301b127232b 137466 admin optional
nscd_2.3.999.1-1_amd64.deb
ba64e4949a4b4b4b0a81b9c391147278 2191914 libdevel extra
glibc_2.3.999.1-1_amd64.changes ACCEPTED
Accepted: glibc-doc_2.3.999.1-1_all.deb to pool/main/g/glibc/glibc-doc_2.3.999.1-1_all.deb glibc_2.3.999.1-1.diff.gz to pool/main/g/glibc/glibc_2.3.999.1-1.diff.gz glibc_2.3.999.1-1.dsc to pool/main/g/glibc/glibc_2.3.999.1-1.dsc glibc_2.3.999.1.orig.tar.gz to pool/main/g/glibc/glibc_2.3.999.1.orig.tar.gz libc-bin_2.3.999.1-1_amd64.deb to pool/main/g/glibc/libc-bin_2.3.999.1-1_amd64.deb libc-dev-bin_2.3.999.1-1_amd64.deb to pool/main/g/glibc/libc-dev-bin_2.3.999.1-1_amd64.deb libc6-dbg_2.3.999.1-1_amd64.deb to pool/main/g/glibc/libc6-dbg_2.3.999.1-1_amd64.deb libc6-dev-i386_2.3.999.1-1_amd64.deb to pool/main/g/glibc/libc6-dev-i386_2.3.999.1-1_amd64.deb libc6-dev_2.3.999.1-1_amd64.deb to pool/main/g/glibc/libc6-dev_2.3.999.1-1_amd64.deb libc6-i386_2.3.999.1-1_amd64.deb to pool/main/g/glibc/libc6-i386_2.3.999.1-1_amd64.deb libc6-pic_2.3.999.1-1_amd64.deb to pool/main/g/glibc/libc6-pic_2.3.999.1-1_amd64.deb libc6-prof_2.3.999.1-1_amd64.deb to pool/main/g/glibc/libc6-prof_2.3.999.1-1_amd64.deb libc6-udeb_2.3.999.1-1_amd64.udeb to pool/main/g/glibc/libc6-udeb_2.3.999.1-1_amd64.udeb libc6_2.3.999.1-1_amd64.deb to pool/main/g/glibc/libc6_2.3.999.1-1_amd64.deb libnss-dns-udeb_2.3.999.1-1_amd64.udeb to pool/main/g/glibc/libnss-dns-udeb_2.3.999.1-1_amd64.udeb libnss-files-udeb_2.3.999.1-1_amd64.udeb to pool/main/g/glibc/libnss-files-udeb_2.3.999.1-1_amd64.udeb locales_2.3.999.1-1_all.deb to pool/main/g/glibc/locales_2.3.999.1-1_all.deb nscd_2.3.999.1-1_amd64.deb to pool/main/g/glibc/nscd_2.3.999.1-1_amd64.deb Announcing to debian-devel-changes@lists.debian.org Setting bugs to severity fixed: 181494 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Fixed in upload of glibc 2.3.999.1-1 to experimental
Processing commands for [EMAIL PROTECTED]: tag 181494 + fixed-in-experimental Bug#181494: [NONFREE-DOC:GFDL1.1olisfcbc] includes non-free documentation Tags were: sarge-ignore Tags added: fixed-in-experimental quit Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364845: glibc has recursive build-depends
On Tue, Apr 25, 2006 at 11:11:00PM -0500, Adam Heath wrote: glibc has a build-depends on libc6-dev-amd64 on i386, and libc6-dev-i386 on amd64. This makes bootstrapping difficult. Why can't it just use itself? Doesn't it use gcc in standalone mode, so that gcc doesn't need any system-installed development files? No, and you can't build GCC packages without a glibc either. They're interdependent. I believe that you can not run glibc's configure script for the 64-bit packages without the 64-bit libraries involved. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365647: Does libc6 2.3.6-7 break Sarge
I see where the initrd-tools maintainer(s) has marked this as fixed but I don't see any updated packages. I wrote myself a dirty little script that could be used to fix this (at least it does what I need it to). http://www200.pair.com/mecham/fix.mkinitrd Gary V -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365570: import debconf selection from belocs-locales-data ?
On Mon, May 01, 2006 at 09:32:37AM +0200, Robert Millan wrote: Package: locales Version: 2.3.6-3 Severity: wishlist Hi, I think it would be nice if, when installing standard locales in a system that previously were using belocs-locales-data, the debconf selections from: belocs-locales-data/locales_to_be_generated belocs-locales-data/default_environment_locale were automaticaly imported into the default locales template (and, of course, unexistant locales were skipped). This is useful for locales that used to be only in belocs. When they're added to standard locales package, users would want to migrate. Would you like me to send a patch for this? No, it should work without any change because the config script parses configuration files. If this does not work, please try with locales 2.3.6-7, and if you have still trouble, please send your /etc/locale.gen, /etc/environment and /etc/default/locale files *before* installing the locales package. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#365628: postinst fails when LANG doesn't point to a valid locale
Processing commands for [EMAIL PROTECTED]: tags 365628 = pending Bug#365628: postinst fails when LANG doesn't point to a valid locale Tags were: patch Tags set to: pending thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364490: 'dpkg-reconfigure locales' does not update /etc/environment
On Sun, Apr 23, 2006 at 12:23:36PM -0600, Gary V wrote: Package: locales Version: 2.3.6-7 I thought answering the prompt: Default locale for the system environment: would change the LANG variable in /etc/environment as it appears to do in version 2.3.5-6 which I have installed in another (Sarge) machine. Using the 2.3.6-7 version, I can't see that it ever touches the file. Hi, due to a packaging bug, this change is explained in /usr/share/doc/locales/NEWS.Debian/locales.NEWS.Debian instead of /usr/share/doc/locales/NEWS.Debian and is thus not displayed by apt-listchanges, it will be fixed by the next upload. Does this file contain enough information? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365628: postinst fails when LANG doesn't point to a valid locale
tags 365628 = pending thanks On Mon, May 01, 2006 at 05:49:33PM +0200, Robert Millan wrote: Package: locales Version: 2.3.6-7 Severity: important Tags: patch # LANG=xx_XX DEBIAN_FRONTEND=noninteractive dpkg-reconfigure locales [...] *** update-locale: Error: invalid locale settings: when update-locale LANG is invoked, it verified LANG variable and, if invalid, aborts the script. The typical situation when this happens is: - You had belocs-locales-data installed. - You had LANG set to a locale that is only available in belocs, and not in glibc locales. - You attempt to replace belocs-locales-data with glibc locales. The following fix worked for me: --- /var/lib/dpkg/info/locales.postinst~2006-04-14 15:45:25.0 +0200 +++ /var/lib/dpkg/info/locales.postinst 2006-05-01 17:46:22.0 +0200 @@ -66,7 +66,7 @@ # Set default LANG environment variable if [ -e $EE ]; then # Remove previous definitions -/usr/sbin/update-locale LANG +LANG= /usr/sbin/update-locale LANG fi if [ -n $SELECTED ] [ $SELECTED != None ]; then /usr/sbin/update-locale LANG=$SELECTED A slightly different fix has already been committed in SVN, update-locale is called with the --no-checks flag. But according to the manpage, I don't see why update-locale should care about the LANG env variable. Perhaps the problem is there? Several problems have been reported because of inconsistencies between LANG and LANGUAGE, so I try to make sure that selected locale is usable. If these consistency checks make more harm than good, they will be dropped. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356382: marked as done (glibc: FTBFS in experimental on amd64: segmantation fault.)
Your message dated Tue, 2 May 2006 22:45:09 -0400 with message-id [EMAIL PROTECTED] and subject line amd64 ftbfs has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: glibc Version: 2.3.999-1 Severity: serious Tags: experimental Hi, Your package is failing to build on amd64 with a segmentation fault. From the buildd log: GCONV_PATH=/build/buildd/glibc-2.3.999/build-tree/amd64-libc/iconvdata LC_ALL=C LOCPATH=/build/buildd/glibc-2.3.999/build-tree/amd64-libc/localedata /build/buildd/glibc-2.3.999/build-tree/amd64-libc/elf/ld-linux-x86-64.so.2 --library-path /build/buildd/glibc-2.3.999/build-tree/amd64-libc:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/math:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/elf:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/dlfcn:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nss:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nis:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/resolv:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/crypt:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nptl:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nptl /build/buildd/glibc-2.3.999/build-tree/amd64-libc/posix/tst-rxspencer --utf8 rxspencer/tests /build/buildd/ glibc-2.3.999/build-tree/amd64-libc/posix/tst-rxspencer.out /bin/sh: line 1: 13309 Segmentation fault GCONV_PATH=/build/buildd/glibc-2.3.999/build-tree/amd64-libc/iconvdata LC_ALL=C LOCPATH=/build/buildd/glibc-2.3.999/build-tree/amd64-libc/localedata /build/buildd/glibc-2.3.999/build-tree/amd64-libc/elf/ld-linux-x86-64.so.2 --library-path /build/buildd/glibc-2.3.999/build-tree/amd64-libc:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/math:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/elf:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/dlfcn:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nss:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nis:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/resolv:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/crypt:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nptl:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nptl /build/buildd/glibc-2.3.999/build-tree/amd64-libc/posix/tst-rxspencer --utf8 rxspencer/tests /build/buildd/glibc-2.3.999/build-tree/amd64-libc/posix/tst-rxspencer.out make[3]: *** [/build/buildd/glibc-2.3.999/build-tree/amd64-libc/posix/tst-rxspe ncer.out] Error 139 I think there are some other errors in the log: GCONV_PATH=/build/buildd/glibc-2.3.999/build-tree/amd64-libc/iconvdata LC_ALL=C /build/buildd/glibc-2.3.999/build-tree/amd64-libc/elf/ld-linux-x86-64.so.2 --library-path /build/buildd/glibc-2.3.999/build-tree/amd64-libc:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/math:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/elf:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/dlfcn:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nss:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nis:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/resolv:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/crypt:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nptl:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nptl /build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt/tst-mqueue8 /build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt/tst-mqueue8.out make[3]: *** [/build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt/tst-mqueue5.out] Error 1 And: GCONV_PATH=/build/buildd/glibc-2.3.999/build-tree/amd64-libc/iconvdata LC_ALL=C /build/buildd/glibc-2.3.999/build-tree/amd64-libc/elf/ld-linux-x86-64.so.2 --library-path /build/buildd/glibc-2.3.999/build-tree/amd64-libc:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/math:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/elf:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/dlfcn:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nss:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nis:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/resolv:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/crypt:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nptl:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nptl /build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt/tst-cputimer2 /build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt/tst-cputimer2.out make[3]: ***
Bug#364490: 'dpkg-reconfigure locales' does not update /etc/environment
* Locale variables are now stored in /etc/default/locale and no more /etc/environment. The reason is that Debian Policy forbids modifying configuration files of other packages, and /etc/environment is a configuration file for PAM. Make sure to remove old definitions from /etc/environment, this file is no more modified for the reason explained above. OK, thank you. Gary V -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
