Bug#424723: marked as done (nscd is crashing after few seconds)
Your message dated Fri, 18 May 2007 09:14:35 +0200 with message-id [EMAIL PROTECTED] and subject line Bug#424723: Acknowledgement (nscd is crashing after few seconds) 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: nscd Version: 2.3.6.ds1-13 Severity: grave Justification: renders package unusable Well, I believe this is somehow important, on all of my servers it crashes in about 15 seconds. Please note that I am using a lot of groups (more than 2000) and that my servers are heavily loaded. I am using a vanilla kernel (without grsec, pax, and such). It worked without problem on Debian Sarge. Here is a gdb output (without symbols however) : # gdb /usr/sbin/nscd GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu...(no debugging symbols found) Using host libthread_db library /lib/tls/i686/cmov/libthread_db.so.1. (gdb) run -d Starting program: /usr/sbin/nscd -d (no debugging symbols found) 4110: handle_request: request received (Version = 2) from PID 4119 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4119 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4120 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4121 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4121 4110: GETPWBYUID (11101) 4110: Haven't found 11101 in password cache! [New LWP 4117] 4110: handle_request: request received (Version = 2) from PID 4120 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4120 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4122 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4122 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4121 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4122 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4121 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4119 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4123 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4123 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4123 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4124 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4124 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4124 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4125 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4125 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4126 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4126 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4126 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4125 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4127 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110:
Bug#424983: tzdata: [INTL:eu] debconf templates basque translation
Package: tzdata Version: 2007f-2 Severity: wishlist Tags: patch l10n Hi Atached tzdata debconf templates basque translation, please commit it. thx -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.20 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages tzdata depends on: ii debconf [debconf-2.0] 1.5.13 Debian configuration management sy tzdata recommends no packages. -- debconf information excluded # translation of eu.po to Euskara # THIS FILE IS AUTOMATICALLY GENERATED FROM THE MASTER FILE # packages/po/eu.po # # DO NOT MODIFY IT DIRECTLY : SUCH CHANGES WILL BE LOST # # Basque messages for debian-installer. # Copyright (C) 2003 Software in the Public Interest, Inc. # This file is distributed under the same license as debian-installer. # Inaki Larranaga Murgoitio 2005 # # Piarres Beobide [EMAIL PROTECTED], 2004, 2005, 2006, 2007. msgid msgstr Project-Id-Version: eu\n Report-Msgid-Bugs-To: [EMAIL PROTECTED] POT-Creation-Date: 2007-05-04 07:56+0200\n PO-Revision-Date: 2007-05-18 11:03+0200\n Last-Translator: Piarres Beobide [EMAIL PROTECTED]\n Language-Team: Euskara [EMAIL PROTECTED]\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n Content-Transfer-Encoding=UTF-8Plural-Forms: nplurals=2; plural=(n != 1);\n X-Generator: KBabel 1.11.4\n Plural-Forms: nplurals=2; plural=(n != 1)\n #. Type: select #. Choices #. Note to translators: #. - Etc will present users with a list #. of GMT+xx or GMT-xx timezones #. - SystemV will give the choice between zone named as per SystemV conventions: #. EST5, MST7, etc. #: ../templates:2001 msgid Africa msgstr Afrika #. Type: select #. Choices #. Note to translators: #. - Etc will present users with a list #. of GMT+xx or GMT-xx timezones #. - SystemV will give the choice between zone named as per SystemV conventions: #. EST5, MST7, etc. #: ../templates:2001 msgid America msgstr Amerika #. Type: select #. Choices #. Note to translators: #. - Etc will present users with a list #. of GMT+xx or GMT-xx timezones #. - SystemV will give the choice between zone named as per SystemV conventions: #. EST5, MST7, etc. #: ../templates:2001 msgid Antarctica msgstr Antartikoa #. Type: select #. Choices #. Note to translators: #. - Etc will present users with a list #. of GMT+xx or GMT-xx timezones #. - SystemV will give the choice between zone named as per SystemV conventions: #. EST5, MST7, etc. #: ../templates:2001 msgid Australia msgstr Australia #. Type: select #. Choices #. Note to translators: #. - Etc will present users with a list #. of GMT+xx or GMT-xx timezones #. - SystemV will give the choice between zone named as per SystemV conventions: #. EST5, MST7, etc. #: ../templates:2001 msgid Arctic msgstr Artikoa #. Type: select #. Choices #. Note to translators: #. - Etc will present users with a list #. of GMT+xx or GMT-xx timezones #. - SystemV will give the choice between zone named as per SystemV conventions: #. EST5, MST7, etc. #: ../templates:2001 msgid Asia msgstr Asia #. Type: select #. Choices #. Note to translators: #. - Etc will present users with a list #. of GMT+xx or GMT-xx timezones #. - SystemV will give the choice between zone named as per SystemV conventions: #. EST5, MST7, etc. #. Type: select #. Choices #: ../templates:2001 #: ../templates:10001 msgid Atlantic msgstr Atlantikoa #. Type: select #. Choices #. Note to translators: #. - Etc will present users with a list #. of GMT+xx or GMT-xx timezones #. - SystemV will give the choice between zone named as per SystemV conventions: #. EST5, MST7, etc. #: ../templates:2001 msgid Canada msgstr Kanada #. Type: select #. Choices #. Note to translators: #. - Etc will present users with a list #. of GMT+xx or GMT-xx timezones #. - SystemV will give the choice between zone named as per SystemV conventions: #. EST5, MST7, etc. #: ../templates:2001 msgid Europe msgstr Europa #. Type: select #. Choices #. Note to translators: #. - Etc will present users with a list #. of GMT+xx or GMT-xx timezones #. - SystemV will give the choice between zone named as per SystemV conventions: #. EST5, MST7, etc. #: ../templates:2001 msgid Indian msgstr India #. Type: select #. Choices #. Note to translators: #. - Etc will present users with a list #. of GMT+xx or GMT-xx timezones #. - SystemV will give the choice between zone named as per SystemV conventions: #. EST5, MST7, etc. #. Type: select #. Choices #: ../templates:2001 #: ../templates:10001 msgid Pacific msgstr Pazifikoa #. Type: select #. Choices #. Note to translators: #. - Etc will present users with a list #. of GMT+xx or GMT-xx timezones #. - SystemV will give the choice between zone named as per SystemV conventions: #. EST5, MST7, etc. #: ../templates:2001 msgid SystemV msgstr SystemV #. Type:
glibc 2.6 patch status
I took a brief look, and concluded that the following modifications will allow all the patches to apply. The lines that have been commented out represent patches that need to be reviewed and either fixed or thrown out. This is based on the 2.6 tarballs and a CVS snapshot of ports from 20070517. localedata/locale-eo_EO.diff -p0 localedata/locale-no_NO.diff -p0 localedata/locale-eu_FR.diff -p0 -locale/iso3166-RS.diff localedata/locale-ku_TR.diff -p0 -locale/fix-exhausted-memory.diff -p0 #locale/check-unknown-symbols.diff # locales have to be fixed first locale/fix-LC_COLLATE-rules.diff -p0 locale/preprocessor-collate.diff -p0 locale/LC_IDENTIFICATION-optional-fields.diff -p0 -locale/LC_COLLATE-keywords-ordering.diff -p0 +#locale/LC_COLLATE-keywords-ordering.diff -p0 locale/locale-print-LANGUAGE.diff -p0 locale/fix-C-first_weekday.diff -p0 localedata/tl_PH-yesexpr.diff @@ -21,7 +19,6 @@ localedata/locale-sa_IN.diff -p0 localedata/locale-en_DK.diff -p0 localedata/locale-hy_AM.diff -localedata/locale-pl_PL.diff -p0 localedata/locale-wo_SN.diff -p0 localedata/locale-csb_PL.diff localedata/dz_BT-collation.diff -p0 @@ -29,36 +26,31 @@ localedata/locale-zh_TW.diff -p0 localedata/new-valencian-locale.diff -p0 localedata/locale-se_NO.diff -p0 -localedata/locales-sr.diff -p0 -localedata/tailor-iso14651_t1.diff -p0 +#localedata/locales-sr.diff -p0 +#localedata/tailor-iso14651_t1.diff -p0 localedata/fix-lang.diff -p0 localedata/fix-unknown-symbols.diff -p0 -localedata/first_weekday.diff -p0 +#localedata/first_weekday.diff -p0 localedata/sort-UTF8-first.diff -p0 localedata/local-all-no-archive.diff -p0 #alpha/submitted-pic.diff -p0 # g: suspended -alpha/cvs-cfi.diff -p1 alpha/cvs-sigsuspend.diff -p1 alpha/local-gcc4.1.diff -p0 alpha/submitted-xstat.diff -p0 amd64/local-biarch.diff -p1 -arm/cvs-check_pf.c -p0 arm/cvs-gcc4-inline.diff -p0 arm/local-ioperm.diff -p0 arm/local-no-hwcap.diff -p0 -hppa/cvs-hppa-update.diff -p0 -hppa/submitted-lt.diff -p0 hppa/submitted-nptl-carlos.diff -p0 -hppa/submitted-nptl-carlos2.diff -p0 +#hppa/submitted-nptl-carlos2.diff -p0 hppa/submitted-ustat.diff -p0 hppa/local-inlining.diff -p0 -hppa/local-r19use.diff -p0 +#hppa/local-r19use.diff -p0 -hurd-i386/cvs-futimes.diff -p1 hurd-i386/cvs-getsid.diff -p0 hurd-i386/local-dl-dynamic-weak.diff -p1 hurd-i386/local-enable-ldconfig.diff -p0 @@ -67,7 +59,7 @@ hurd-i386/local-sigsuspend-nocancel.diff -p0 hurd-i386/local-tls.diff -p1 hurd-i386/submitted-ioctl-decode-argument.diff -p0 -hurd-i386/submitted-libc_once.diff -p0 +#hurd-i386/submitted-libc_once.diff -p0 hurd-i386/submitted-stat.diff -p0 hurd-i386/submitted-sysvshm.diff -p1 hurd-i386/submitted-trivial.diff -p0 @@ -76,18 +68,17 @@ i386/local-cmov.diff -p0 i386/submitted-i686-timing.diff -p0 -m68k/cvs-m68k-update.diff -p0 +#m68k/cvs-m68k-update.diff -p0 m68k/local-compat.diff -p0 m68k/local-dwarf2-buildfix.diff -p0 m68k/local-fpic.diff -p0 -m68k/local-mathinline_h.diff -p1 +#m68k/local-mathinline_h.diff -p1 m68k/local-reloc.diff -p0 -m68k/local-pthread_lock.diff -p1 +#m68k/local-pthread_lock.diff -p1 m68k/submitted-gcc34-seccomment.diff -p0 -mips/cvs-ldsodefs_h.diff -p0 +#mips/cvs-ldsodefs_h.diff -p0 mips/local-lazy-eval.diff -p0 -mips/submitted-msq.diff -p0 powerpc/local-sysconf.diff -p1 @@ -95,27 +86,18 @@ sparc/local-sparcv8-target.diff -p0 sparc/submitted-timing.diff -p1 -all/cvs-iconv-E13B.diff -p0 -all/local-pthread-manpages.diff -p1 all/local-remove-manual.diff all/local-ru_RU.diff -p1 all/local-pt_BR.diff -p1 -all/submitted-new-brf-encoding.diff -p0 +#all/submitted-new-brf-encoding.diff -p0 -any/cvs-2.5-branch-update.diff -p1 -any/cvs-pow.diff -p1 -any/cvs-printf_fp-c.diff -p1 -any/cvs-ftw-c.diff -p1 -any/cvs-bits_in_h-ipv6.diff -p1 -any/cvs-itoa-c.diff -p1 -any/cvs-lt-update.diff -p0 -any/cvs-realpath.diff -p1 -any/cvs-vfprintf-stack-smashing.diff -any/cvs-zdump-64-bit.diff -p1 -any/local-notls.diff -p0 +#any/cvs-printf_fp-c.diff -p1 +#any/cvs-itoa-c.diff -p1 +#any/cvs-zdump-64-bit.diff -p1 +#any/local-notls.diff -p0 any/local-asserth-decls.diff -p0 #any/local-base.diff -p0 # g: suspended -any/local-bashisms.diff -p0 +#any/local-bashisms.diff -p0 any/local-dl-execstack.diff -p0 any/local-fhs-linux-paths.diff -p0 any/local-forward-backward-collation.diff @@ -124,21 +106,19 @@ any/local-iconv-fix-trampoline.diff -p1 any/local-ld-multiarch.diff -p0 any/local-ldd.diff -p0 -any/local-ldso-disable-hwcap.diff -p0 +#any/local-ldso-disable-hwcap.diff -p0 any/local-ldconfig.diff -p0 any/local-ldconfig-fsync.diff -p1 any/local-ldconfig-timestamps.diff -p0 any/local-libgcc-compat-main.diff -p0 any/local-libgcc-compat-ports.diff -p0 -any/local-linuxthreads-semaphore_h.diff -p1 -any/local-linuxthreads-tst-sighandler.diff -p1 any/local-localedef-fix-trampoline.diff -p0 any/local-makeconfig.diff -p0 any/local-mktemp.diff -p0 any/local-no-pagesize.diff -p1 any/local-nss-upgrade.diff -p0
Your Bugzilla password.
To use the wonders of Bugzilla, you can use the following: E-mail address: debian-glibc@lists.debian.org Password: vo8nTFOo To change your password, go to: http://sourceware.org/bugzilla/userprefs.cgi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Unidentified subject!
Hi m68k and Hurd porters, You were previously made aware[0] that glibc-2.6 needs TLS to be implemented for your ports to build and work properly, sadly this is still not the case for m68k, and insufficient for Hurd in the current state. We want to release lenny with glibc 2.6 (see discussion with the Release Team in [1]), and it has been released upstream yesterday. We don't plan an upload to unstable immediately, we already have to make glibc 2.5 reach lenny first. Though, we hope to make the first uploads during DebConf. Bringing a new glibc upstream into Debian is a lot of work, and waiting for m68k and Hurd to support TLS properly is sadly not an option we can consider. [0] http://www.mail-archive.com/debian-glibc%40lists.debian.org/msg31594.html [1] http://lists.debian.org/debian-release/2007/04/msg00161.html On behalf of the Glibc Packaging Team, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp2jKTA7VXsc.pgp Description: PGP signature
Re: Your Bugzilla password.
On Fri, May 18, 2007 at 01:31:29PM -, [EMAIL PROTECTED] wrote: To use the wonders of Bugzilla, you can use the following: E-mail address: debian-glibc@lists.debian.org Password: vo8nTFOo FWIW it has been changed :) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpDkp8JUC6Jz.pgp Description: PGP signature
r2227 - glibc-package/branches
Author: madcoder Date: 2007-05-18 15:14:05 + (Fri, 18 May 2007) New Revision: 2227 Added: glibc-package/branches/glibc-2.6/ Log: create a glibc 2.6 branch Copied: glibc-package/branches/glibc-2.6 (from rev 2226, glibc-package/trunk) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425031: Problems with libc6 and nspluginwrapper
Package: libc6 Version: 2.5-7 When I make apt-get dist-upgrade I see this message. My system is spanish: Se actualizarán los siguientes paquetes: libc6 1 paquetes actualizados, 0 nuevos instalados, 0 para eliminar y 221 sin actualizar. Necesito descargar 0B/4759kB de ficheros. Después de desempaquetar se liberarán 16,4kB. ¿Quiere continuar? [Y/n/?] Escribiendo información de estado extendido... Hecho (Leyendo la base de datos ... 44126 ficheros y directorios instalados actualmente.) Preparando para reemplazar libc6 2.5-1 (usando .../archives/libc6_2.5-7_amd64.deb) ... Desempaquetando el reemplazo de libc6 ... dpkg: error al procesar /var/cache/apt/archives/libc6_2.5-7_amd64.deb (--unpack): intentando sobreescribir `/usr/lib64', que está también en el paquete nspluginwrapper Se encontraron errores al procesar: /var/cache/apt/archives/libc6_2.5-7_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Un paquete no se pudo instalar. Intentado recuperarse: dpkg: problemas de dependencias impiden la configuración de libc6-dev: libc6-dev depende de libc6 (= 2.5-7); sin embargo: La versión de `libc6' en el sistema es 2.5-1. dpkg: error al procesar libc6-dev (--configure): problemas de dependencias - se deja sin configurar dpkg: problemas de dependencias impiden la configuración de libc6-i386: libc6-i386 depende de libc6 (= 2.5-7); sin embargo: La versión de `libc6' en el sistema es 2.5-1. dpkg: error al procesar libc6-i386 (--configure): problemas de dependencias - se deja sin configurar Se encontraron errores al procesar: libc6-dev libc6-i386 I am using Debian GNU/Linux 4.0, SID, AMD-64, kernel 2.6.18
Re: TLS support [was Re: Unidentified subject!]
On Fri, May 18, 2007 at 03:20:00PM +0200, Pierre Habouzit wrote: You were previously made aware[0] that glibc-2.6 needs TLS to be implemented for your ports to build and work properly, sadly this is still not the case for m68k, and insufficient for Hurd in the current state. The last time this came up, someone said they would work on it for m68k. That apparently hasn't happened. We want to release lenny with glibc 2.6 (see discussion with the Release Team in [1]), and it has been released upstream yesterday. We don't plan an upload to unstable immediately, we already have to make glibc 2.5 reach lenny first. Though, we hope to make the first uploads during DebConf. Bringing a new glibc upstream into Debian is a lot of work, and waiting for m68k and Hurd to support TLS properly is sadly not an option we can consider. I would like to help out on this issue since it doesn't seem like it will get done by someone else. Is there any documentation available for porting TLS to a new architecture? I have a basic understanding of the concepts but not the implementation details. Presumably the order of work needs to be 1) fix binutils, 2) fix gcc, 3) fix glibc. If this is correct, I can pull the source for binutils and start taking a look. Is there anyone that would be a good contact point for questions about this once I start looking at it? I presume there are also specific versions of each package that need to be fixed, not just whatever is current from upstream. Brad Boyer [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TLS support [was Re: Unidentified subject!]
On Fri, May 18, 2007 at 09:40:53AM -0700, Brad Boyer wrote: On Fri, May 18, 2007 at 03:20:00PM +0200, Pierre Habouzit wrote: You were previously made aware[0] that glibc-2.6 needs TLS to be implemented for your ports to build and work properly, sadly this is still not the case for m68k, and insufficient for Hurd in the current state. The last time this came up, someone said they would work on it for m68k. That apparently hasn't happened. We want to release lenny with glibc 2.6 (see discussion with the Release Team in [1]), and it has been released upstream yesterday. We don't plan an upload to unstable immediately, we already have to make glibc 2.5 reach lenny first. Though, we hope to make the first uploads during DebConf. Bringing a new glibc upstream into Debian is a lot of work, and waiting for m68k and Hurd to support TLS properly is sadly not an option we can consider. I would like to help out on this issue since it doesn't seem like it will get done by someone else. Is there any documentation available for porting TLS to a new architecture? I have a basic understanding of the concepts but not the implementation details. Presumably the order of work needs to be 1) fix binutils, 2) fix gcc, 3) fix glibc. If this is correct, I can pull the source for binutils and start taking a look. Is there anyone that would be a good contact point for questions about this once I start looking at it? I presume there are also specific versions of each package that need to be fixed, not just whatever is current from upstream. There is a quite good pdf on Uli's page. Search Ullrich Drepper on google, you should be able to find it. IIRC there is the explanation on how it has been implemented for a few archs, quite extensively annotated. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpsTUoUtmYJ9.pgp Description: PGP signature
Re: Unidentified subject!
Pierre Habouzit wrote: Hi m68k and Hurd porters, You were previously made aware[0] that glibc-2.6 needs TLS to be implemented for your ports to build and work properly, sadly this is still not the case for m68k, and insufficient for Hurd in the current state. We want to release lenny with glibc 2.6 (see discussion with the Release Team in [1]), and it has been released upstream yesterday. We don't plan an upload to unstable immediately, we already have to make glibc 2.5 reach lenny first. Though, we hope to make the first uploads during DebConf. Bringing a new glibc upstream into Debian is a lot of work, and waiting for m68k and Hurd to support TLS properly is sadly not an option we can consider. [0] http://www.mail-archive.com/debian-glibc%40lists.debian.org/msg31594.html [1] http://lists.debian.org/debian-release/2007/04/msg00161.html On behalf of the Glibc Packaging Team, Hi Pierre, I got 2.5 to build with TLS but we need some changes to Hurd and gnumach to handle it. As I understand it we have even more issues with 2.6. Of course I'm certainly not the expert on the issue.. Thanks, Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#425031: Problems with libc6 and nspluginwrapper
Processing commands for [EMAIL PROTECTED]: reassign 425031 nspluginwrapper Bug#425031: Problems with libc6 and nspluginwrapper Bug reassigned from package `libc6' to `nspluginwrapper'. 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#425031: Problems with libc6 and nspluginwrapper
reassign 425031 nspluginwrapper thanks Victor Santos a écrit : Package: libc6 Version: 2.5-7 When I make apt-get dist-upgrade I see this message. My system is spanish: The bug is in nspluginwrapper. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TLS support [was Re: Unidentified subject!]
On Fri, May 18, 2007 at 07:35:07PM +0200, Pierre Habouzit wrote: There is a quite good pdf on Uli's page. Search Ullrich Drepper on google, you should be able to find it. IIRC there is the explanation on how it has been implemented for a few archs, quite extensively annotated. Is this the document? http://people.redhat.com/drepper/tls.pdf It does seem to have quite a bit of technical detail. I'll look at it in more depth a little later. Thank you for the pointer. Brad Boyer [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TLS support [was Re: Unidentified subject!]
On Fri, May 18, 2007 at 11:05:31AM -0700, Brad Boyer wrote: On Fri, May 18, 2007 at 07:35:07PM +0200, Pierre Habouzit wrote: There is a quite good pdf on Uli's page. Search Ullrich Drepper on google, you should be able to find it. IIRC there is the explanation on how it has been implemented for a few archs, quite extensively annotated. Is this the document? http://people.redhat.com/drepper/tls.pdf It does seem to have quite a bit of technical detail. I'll look at it in more depth a little later. Thank you for the pointer. It is indeed. I don't think you'll read any better documentation about TLS elsewhere. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpe3a1xplLfj.pgp Description: PGP signature
