Bug#466519: svn client doesn't work: Could not get next bucket brigade + Invalid or incomplete multibyte or wid...: random no commit, no update
Package: libc6 Version: 2.3.6.ds1-13etch5 Severity: grave Summary: svn was working perfectly. The repository isn't huge (~500 commit). Now when I commit I get: Could not get next bucket brigade (server side) when I update I get: client denied by server configuration: /var/www/ Could not fetch resource information. (84)Invalid or incomplete multibyte or wide character: Requests for a collection must have a trailing slash on the URI. On the client side I get: REPORT di '/svn/main/!svn/vcc/default': 400 Bad Request I did a svnadmin verify and svnadmin recover and everything looked fine on the server. I did try fsfsverify.py on all revs too. Sometimes backing up a file on the local copy, forcing a delete, adding the file back works... sometimes it doesn't. I've been able to commit file one by one, some get committed with no extra hassle, some need this backup/delete/add process, some just can't be committed. I did try to make a commit from other boxes and they worked... I did a co from other boxes and they worked too. the server is a debian sarge (pentium) Debian sarge (Apache/2.0.54 (Debian GNU/Linux) DAV/2 SVN/1.1.4) the client is a debian etch (dual Xeon) svn, versione 1.4.2 (r22196) compilato Nov 10 2006, 17:39:50 Nothing was changed on the server, most recent update were on the client (etch) and coincidentally I haven't been able to use svn starting from the below update on the client. linux-image-2.6-686 2.6.18+6etch2 - 2.6.18+6etch3 apache2 2.2.3-4+etch3 - 2.2.3-4+etch4 apache2-mpm-prefork 2.2.3-4+etch3 - 2.2.3-4+etch4 apache2-utils 2.2.3-4+etch3 - 2.2.3-4+etch4 apache2.2-common 2.2.3-4+etch3 - 2.2.3-4+etch4 cpio 2.6-17 - 2.6-18 libc6 2.3.6.ds1-13etch4 - 2.3.6.ds1-13etch5 libc6-dev 2.3.6.ds1-13etch4 - 2.3.6.ds1-13etch5 libc6-xen 2.3.6.ds1-13etch4 - 2.3.6.ds1-13etch5 locales 2.3.6.ds1-13etch4 - 2.3.6.ds1-13etch5 and nothing has changed on the server. I haven't been able to do much tests from other clients but till now all commit, updates and checkout from different clients worked. So it seems the problem was introduced by the updates above on the client. Could be related to this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465583 but the client has ipv6 loaded... -- Ivan Sergio Borgonovo http://www.webthatworks.it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#466491: libc6: gettimeofday() in /libe/libc.so.6 causes SIGSEGV
Processing commands for [EMAIL PROTECTED]: tag 466491 + moreinfo Bug#466491: libc6: gettimeofday() in /libe/libc.so.6 causes SIGSEGV There were no tags set. Tags added: moreinfo 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#466519: ltrace of an svn update
On Tue, Feb 19, 2008 at 10:03:48AM +, Ivan Sergio Borgonovo wrote: I noticed in the other bug report it was asked to include an ltrace... This is the ltrace of an svn update. You had libc6-dbg installed when you ran it ? because I see no libc calls which is odd. A strace may help too please. TIA -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpAQyYUzbRfW.pgp Description: PGP signature
Bug#466519: svn client doesn't work: Could not get next bucket brigade + Invalid or incomplete multibyte or wid...: random no commit, no update
Ivan Sergio Borgonovo a écrit : Package: libc6 Version: 2.3.6.ds1-13etch5 Severity: grave Summary: svn was working perfectly. The repository isn't huge (~500 commit). Now when I commit I get: Could not get next bucket brigade (server side) when I update I get: client denied by server configuration: /var/www/ This really looks like a problem on the server side. Could not fetch resource information. (84)Invalid or incomplete multibyte or wide character: Requests for a collection must have a trailing slash on the URI. On the client side I get: REPORT di '/svn/main/!svn/vcc/default': 400 Bad Request I did a svnadmin verify and svnadmin recover and everything looked fine on the server. I did try fsfsverify.py on all revs too. Sometimes backing up a file on the local copy, forcing a delete, adding the file back works... sometimes it doesn't. I've been able to commit file one by one, some get committed with no extra hassle, some need this backup/delete/add process, some just can't be committed. I did try to make a commit from other boxes and they worked... I did a co from other boxes and they worked too. the server is a debian sarge (pentium) Debian sarge (Apache/2.0.54 (Debian GNU/Linux) DAV/2 SVN/1.1.4) the client is a debian etch (dual Xeon) svn, versione 1.4.2 (r22196) compilato Nov 10 2006, 17:39:50 Nothing was changed on the server, most recent update were on the client (etch) and coincidentally I haven't been able to use svn starting from the below update on the client. linux-image-2.6-686 2.6.18+6etch2 - 2.6.18+6etch3 apache2 2.2.3-4+etch3 - 2.2.3-4+etch4 apache2-mpm-prefork 2.2.3-4+etch3 - 2.2.3-4+etch4 apache2-utils 2.2.3-4+etch3 - 2.2.3-4+etch4 apache2.2-common 2.2.3-4+etch3 - 2.2.3-4+etch4 cpio 2.6-17 - 2.6-18 libc6 2.3.6.ds1-13etch4 - 2.3.6.ds1-13etch5 libc6-dev 2.3.6.ds1-13etch4 - 2.3.6.ds1-13etch5 libc6-xen 2.3.6.ds1-13etch4 - 2.3.6.ds1-13etch5 locales 2.3.6.ds1-13etch4 - 2.3.6.ds1-13etch5 Have you tried to downgrade libc6 packages to the old version? I really doubt this problem is due to the glibc upgrade. -- .''`. 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]
Bug#466491: libc6: gettimeofday() in /libe/libc.so.6 causes SIGSEGV
tag 466491 + moreinfo thanks On Tue, Feb 19, 2008 at 04:56:58AM +, Robert Clayton Barnes wrote: Package: libc6 Version: 2.7-6 Severity: important Applications (such as mplayer and vlc) that call gettimeofday() from /lib/libc.so.6 get a SIGSEGV. See gdb output below: the gdb output isnt enough. gettimeofday takes pointers, if the pointers are FUBAR, it's normal it segfaults. Please provide a full backtrace. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpYvnPTw6NjF.pgp Description: PGP signature
Bug#466519: close: it seems not related
I started to experience the same problem on other boxes too... Update of libc6 and this problem now just seem an unlucky coincidence. sorry -- Ivan Sergio Borgonovo http://www.webthatworks.it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465652: marked as done (libc6: Occasional failed wakeup in pthread_cond_wait)
Your message dated Tue, 19 Feb 2008 11:11:57 -0700 with message-id [EMAIL PROTECTED] and subject line Re: Bug#465652: Info received (Bug#465652: Acknowledgement (libc6: Occasional failed wakeup in pthread_cond_wait)) has caused the Debian Bug report #465652, regarding libc6: Occasional failed wakeup in pthread_cond_wait 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 this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 465652: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465652 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems ---BeginMessage--- Package: libc6 Version: 2.7-5 Severity: normal In my multithreaded application I'm finding calls to pthread_cond_wait are occasionally not woken by pthread_cond_broadcast. Some possibly relevent factors: * This is a single CPU, single core box * There's typically 1-3 threads calling pthread_cond_wait * There's a single global cond used, but each thread has their own lock * A maintenance thread (although the roles change) acquires all of the threads' locks, ensuring they're all asleep. It then calls pthread_cond_broadcast, followed by releasing all their locks * The maintanance thread does this repeatedly, successfully waking up other threads from the cond, as well as repeatedly acquiring and releasing the hung thread's lock * I've verified with my own logging and strace that the maintenance thread is acquiring the same lock passed to pthread_cond_wait by the hung thread * A snippet from strace's log (full size 43 megs): http://pastebin.com/f41c0c791 * I've verified with gdb that the hung thread is in #0 0xb7edf820 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 * Attaching and detaching gdb causes the hung thread to wakeup and finish normally. I was told of a patch on IRC, but I was later told it did not affect x86 (which I'm using). For posterity, here's what I had written: Additionally, I was told on IRC of a patch set to glibc's locking code that came out after 2.7. I haven't verified if these would fix it, or if they're even related, but it's something to consider. http://sources.redhat.com/bugzilla/show_bug.cgi?id=5240 Three changed files are linked there. I was given a 4th on IRC, which I'm told is a correction. http://sourceware.org/cgi-bin/cvsweb.cgi/libc/nptl/sysdeps/unix/sysv/linux/lowlevellock.c.diff?cvsroot=glibcr1=1.18r2=1.19 -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-k7 (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libc6 depends on: ii libgcc1 1:4.2.2-1 GCC support library libc6 recommends no packages. -- debconf information excluded -- Adam Olsen, aka Rhamphoryncus ---End Message--- ---BeginMessage--- Sorry folks, user error. :( I finally noticed the relevant paragraph in SUSv2: The effect of using more than one mutex for concurrent pthread_cond_wait() or pthread_cond_timedwait() operations on the same condition variable is undefined; that is, a condition variable becomes bound to a unique mutex when a thread waits on the condition variable, and this (dynamic) binding ends when the wait returns. In my defence, the man page is ambiguous. I interpreted it as only explaining how to use pthread_cond_wait, not as a property of the condition itself (otherwise why wouldn't pthread_cond_init take a mutex argument?): A condition variable must always be associated with a mutex, to avoid the race condition where a thread prepares to wait on a condition vari‐ able and another thread signals the condition just before the first thread actually waits on it. -- Adam Olsen, aka Rhamphoryncus ---End Message---
Bug#465346: marked as done (glibc-doc: Missing man page(s) for 'pthread_attr_get/setstacksize')
Your message dated Tue, 19 Feb 2008 21:41:32 +0100 with message-id [EMAIL PROTECTED] and subject line Re: Bug#465346: Found the complete pthread_ library calls in package 'manpages-posix-dev' has caused the Debian Bug report #465346, regarding glibc-doc: Missing man page(s) for 'pthread_attr_get/setstacksize' 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 this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 465346: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465346 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems ---BeginMessage--- Package: glibc-doc Version: 2.7-6 Severity: normal No man page describing how to manage the thread stack with 'pthread_attr_getstacksize' and 'pthread_attr_setstacksize'. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.23 (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/bash -- no debconf information ---End Message--- ---BeginMessage--- On Tue, Feb 19, 2008 at 06:05:10PM +, Dominique Brazziel wrote: OK to close. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgps4sd857zei.pgp Description: PGP signature ---End Message---
Bug#466519: marked as done (svn client doesn't work: Could not get next bucket brigade + Invalid or incomplete multibyte or wid...: random no commit, no update)
Your message dated Tue, 19 Feb 2008 22:23:20 +0100 with message-id [EMAIL PROTECTED] and subject line Re: Bug#466519: close: it seems not related has caused the Debian Bug report #466519, regarding svn client doesn't work: Could not get next bucket brigade + Invalid or incomplete multibyte or wid...: random no commit, no update 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 this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 466519: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466519 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems ---BeginMessage--- Package: libc6 Version: 2.3.6.ds1-13etch5 Severity: grave Summary: svn was working perfectly. The repository isn't huge (~500 commit). Now when I commit I get: Could not get next bucket brigade (server side) when I update I get: client denied by server configuration: /var/www/ Could not fetch resource information. (84)Invalid or incomplete multibyte or wide character: Requests for a collection must have a trailing slash on the URI. On the client side I get: REPORT di '/svn/main/!svn/vcc/default': 400 Bad Request I did a svnadmin verify and svnadmin recover and everything looked fine on the server. I did try fsfsverify.py on all revs too. Sometimes backing up a file on the local copy, forcing a delete, adding the file back works... sometimes it doesn't. I've been able to commit file one by one, some get committed with no extra hassle, some need this backup/delete/add process, some just can't be committed. I did try to make a commit from other boxes and they worked... I did a co from other boxes and they worked too. the server is a debian sarge (pentium) Debian sarge (Apache/2.0.54 (Debian GNU/Linux) DAV/2 SVN/1.1.4) the client is a debian etch (dual Xeon) svn, versione 1.4.2 (r22196) compilato Nov 10 2006, 17:39:50 Nothing was changed on the server, most recent update were on the client (etch) and coincidentally I haven't been able to use svn starting from the below update on the client. linux-image-2.6-686 2.6.18+6etch2 - 2.6.18+6etch3 apache2 2.2.3-4+etch3 - 2.2.3-4+etch4 apache2-mpm-prefork 2.2.3-4+etch3 - 2.2.3-4+etch4 apache2-utils 2.2.3-4+etch3 - 2.2.3-4+etch4 apache2.2-common 2.2.3-4+etch3 - 2.2.3-4+etch4 cpio 2.6-17 - 2.6-18 libc6 2.3.6.ds1-13etch4 - 2.3.6.ds1-13etch5 libc6-dev 2.3.6.ds1-13etch4 - 2.3.6.ds1-13etch5 libc6-xen 2.3.6.ds1-13etch4 - 2.3.6.ds1-13etch5 locales 2.3.6.ds1-13etch4 - 2.3.6.ds1-13etch5 and nothing has changed on the server. I haven't been able to do much tests from other clients but till now all commit, updates and checkout from different clients worked. So it seems the problem was introduced by the updates above on the client. Could be related to this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465583 but the client has ipv6 loaded... -- Ivan Sergio Borgonovo http://www.webthatworks.it ---End Message--- ---BeginMessage--- Ivan Sergio Borgonovo a écrit : I started to experience the same problem on other boxes too... Update of libc6 and this problem now just seem an unlucky coincidence. Ok, closing the bug with this mail. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net ---End Message---
Bug#466482: Locales: es_CR.UTF-8 lacks 12-hour format in LC_TIME
Niko Cavallini Araya a écrit : Also just to add that at least in Costa Rica we have a similar situation to the one described in bug #240901. While 24-hour format might be official (it is?), the commonly spoken is the 12-hour one. I have made a few search on .cr sites using google, and they seems to confirm the 12-hour format is widely used. However, it seems a.m. and p.m. is used instead of am and pm as you suggested. Could you confirm that? -- .''`. 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]
Bug#457337: libc6: mremap() returns invalid address
Aurelien Jarno a écrit : On Fri, Dec 21, 2007 at 04:33:43PM -0500, Daniel Jacobowitz wrote: On Fri, Dec 21, 2007 at 04:20:14PM -0500, Andreas Klöckner wrote: And there is indeed a call to mremap, and it is indeed the last thing the process does. The strace return value looks ok, but the value that arrives in C (at least according to gdb and the segfault) is not. I'd look at the preprocessed source and make sure nothing is casting your pointer back to a long. It looked truncated. And the code is not really mine--it's just dlmalloc. You have a test case for the crash; we do not. Any news about that? ping ? -- .''`. 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]
[Bug libc/5776] New: Some conversions to ISO-2022-JP produce invalid text
Converting the following UTF8 sequence to ISO-2022-JP//TRANSLIT, then
back to UTF-8 fails:
$ perl -e 'print join(, map { chr hex $_ } qw/e3 83 a2 ef bd 9e 0a/)' | \
iconv -f utf8 -t iso-2022-jp//TRANSLIT|iconv -f iso-2022-jp -t utf8
#12514;iconv: illegal input sequence at position 5
Either iconv has generated invalid ISO-2022-JP, or it refuses to accept
valid ISO-2022-JP.
--
Summary: Some conversions to ISO-2022-JP produce invalid text
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: drepper at redhat dot com
ReportedBy: aurelien at aurel32 dot net
CC: debian-glibc at lists dot debian dot org,glibc-bugs at
sources dot redhat dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://sourceware.org/bugzilla/show_bug.cgi?id=5776
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: bug 466340 is forwarded to http://sources.redhat.com/bugzilla/show_bug.cgi?id=5776
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.16 forwarded 466340 http://sources.redhat.com/bugzilla/show_bug.cgi?id=5776 Bug#466340: Some conversions to ISO-2022-JP produce invalid text Noted your statement that Bug has been forwarded to http://sources.redhat.com/bugzilla/show_bug.cgi?id=5776. End of message, 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 libc/5774] some strtod() cases are wrong
-- What|Removed |Added CC||debian-glibc at lists dot ||debian dot org http://sourceware.org/bugzilla/show_bug.cgi?id=5774 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464977: Bug 464977: unreproducible
Alexander E. Patrakov a écrit : tag 464977 unreproducible thanks I can't reproduce the bug with the same versions of software (x86, libc6 2.7-6, linux 2.6.22-3-686 on SMP w/2 CPU cores, en_US.UTF-8 or ru_RU.UTF-8 locale). [EMAIL PROTECTED]:~$ echo -en '\xe1\xe2\xe3' | iconv -f windows-1255 ; echo בגד I.e., the output contains three characters. So my best guesses, so far, are: 1) Faulty memory. Please run memtest86 for at least 2 hours. 2) An issue with your shell prompt. Please add ; echo to your test command to add a trailing newline. Are you still able to reproduce this bug? -- .''`. 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]
Processed: severity of 463575 is wishlist
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.16 severity 463575 wishlist Bug#463575: /etc/resolv.conf: No way to disable domain option Severity set to `wishlist' from `normal' End of message, 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]
r2818 - in glibc-package/trunk/debian: . patches patches/any
Author: aurel32
Date: 2008-02-19 22:10:12 + (Tue, 19 Feb 2008)
New Revision: 2818
Added:
glibc-package/trunk/debian/patches/any/submitted-link-local_resolver.diff
Modified:
glibc-package/trunk/debian/changelog
glibc-package/trunk/debian/patches/series
Log:
* any/submitted-link-local_resolver.diff: kernel 2.6.24 is out, don't wait
indefinitely for upstream. This patch from Pierre Ynard adds support for
link-local addresses in /etc/resolv.conf.
Modified: glibc-package/trunk/debian/changelog
===
--- glibc-package/trunk/debian/changelog2008-02-17 21:09:47 UTC (rev
2817)
+++ glibc-package/trunk/debian/changelog2008-02-19 22:10:12 UTC (rev
2818)
@@ -3,8 +3,11 @@
* patches/any/local-ldso-disable-hwcap.diff: revert previous changes
as they break etch - lenny upgrades. Closes: #465753.
* kfreebsd/local-sysdeps.diff: update to revision 2137 (from glibc-bsd).
+ * any/submitted-link-local_resolver.diff: kernel 2.6.24 is out, don't wait
+indefinitely for upstream. This patch from Pierre Ynard adds support for
+link-local addresses in /etc/resolv.conf.
- -- Aurelien Jarno [EMAIL PROTECTED] Sun, 17 Feb 2008 22:08:45 +0100
+ -- Aurelien Jarno [EMAIL PROTECTED] Tue, 19 Feb 2008 23:06:29 +0100
glibc (2.7-8) unstable; urgency=low
Added: glibc-package/trunk/debian/patches/any/submitted-link-local_resolver.diff
===
--- glibc-package/trunk/debian/patches/any/submitted-link-local_resolver.diff
(rev 0)
+++ glibc-package/trunk/debian/patches/any/submitted-link-local_resolver.diff
2008-02-19 22:10:12 UTC (rev 2818)
@@ -0,0 +1,74 @@
+It seems that glibc's resolver does not support IPv6 link-local
+addresses with an explicit scope (like fe80::[...]%eth0), in the
+nameserver options in /etc/resolv.conf. Currently, nameservers with a
+scope fail to be parsed. Nameservers with a link-local address (without
+scope) are parsed and used, but obviously do not work (connect() fails
+with EINVAL because a sin6_scope_id of 0 is used with the link-local
+address).
+
+With the apparition of the new RDNSS option (RFC5006), which allows
+for DNS configuration through stateless autoconf, we expect that IPv6
+link-local resolvers may be used, and set into /etc/resolv.conf.
+Kernel-side support is included in Linux 2.6.24, and the corresponding
+userland RDNSS daemon is currently under development and will be shipped
+in the next release of the ndisc6 package. We would need glibc to
+support this feature to integrate our work.
+
+Please review this patch, and consider it for application and submission
+to upstream.
+
+--- resolv/res_init.c 2007-12-09 17:30:57.0 +0100
resolv/res_init.c 2007-12-09 18:19:40.0 +0100
+@@ -74,11 +74,14 @@ static const char rcsid[] = $BINDId: re
+ #include sys/socket.h
+ #include sys/time.h
+
++#include net/if.h
+ #include netinet/in.h
+ #include arpa/inet.h
+ #include arpa/nameser.h
+
++#include assert.h
+ #include ctype.h
++#include netdb.h
+ #include resolv.h
+ #include stdio.h
+ #include stdio_ext.h
+@@ -327,6 +330,8 @@ __res_vinit(res_state statp, int preinit
+
+ if ((el = strchr(cp, '\n')) != NULL)
+ *el = '\0';
++if ((el = strchr(cp, SCOPE_DELIMITER)) != NULL)
++*el = '\0';
+ if ((*cp != '\0')
+ (inet_pton(AF_INET6, cp, a6) 0)) {
+ struct sockaddr_in6 *sa6;
+@@ -336,6 +341,27 @@ __res_vinit(res_state statp, int preinit
+ sa6-sin6_addr = a6;
+ sa6-sin6_family = AF_INET6;
+ sa6-sin6_port = htons(NAMESERVER_PORT);
++
++if (el != NULL) {
++int try_numericscope = 0;
++if (IN6_IS_ADDR_LINKLOCAL(a6)
++|| IN6_IS_ADDR_MC_LINKLOCAL(a6)) {
++sa6-sin6_scope_id =
if_nametoindex(el + 1);
++if (sa6-sin6_scope_id == 0)
++try_numericscope = 1;
++} else
++try_numericscope = 1;
++
++if (try_numericscope != 0) {
++char *end;
++assert(sizeof(uint32_t) =
sizeof(unsigned long));
++sa6-sin6_scope_id = (uint32_t)
strtoul(el + 1, end, 10);
++if (*end != '\0')
++sa6-sin6_scope_id = 0;
++
[bts-link] source package glibc
# # bts-link upstream status pull for source package glibc # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user [EMAIL PROTECTED] # remote status report for #465769 # * http://sourceware.org/bugzilla/show_bug.cgi?id=5774 # * remote status changed: (?) - NEW usertags 465769 + status-NEW # remote status report for #466340 # * http://sourceware.org/bugzilla/show_bug.cgi?id=5776 # * remote status changed: (?) - NEW usertags 466340 + status-NEW thanks
Bug#466482: Locales: es_CR.UTF-8 lacks 12-hour format in LC_TIME
On Feb 19, 2008 3:57 PM, Aurelien Jarno [EMAIL PROTECTED] wrote: I have made a few search on .cr sites using google, and they seems to confirm the 12-hour format is widely used. However, it seems a.m. and p.m. is used instead of am and pm as you suggested. Could you confirm that? Well never actually looked at it in detail, you seem to be correct. Printed paper La Nación and two university websites (1)(2) tend to confirm the a.m. p.m. format. But on line version of the same paper (3) uses am pm as well as other sites. I have not found an oficial statement. So my vote is for the a.m p.m. format but I will ask in the local linux communities for input. (1) http://www.una.ac.cr/ (2) http://www.ucr.ac.cr/ (3) http://www.nacion.com/ -- Saludos Niko
[Bug libc/5776] Some conversions to ISO-2022-JP produce invalid text
-- What|Removed |Added CC||bdonlan at gmail dot com http://sourceware.org/bugzilla/show_bug.cgi?id=5776 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457337: libc6: mremap() returns invalid address
On Dienstag 19 Februar 2008, Aurelien Jarno wrote: ping ? Sorry, I don't have time to track this issue down any further. I figured out a way to not have dlmalloc call mremap, and that settles the issue for me. :-/ (#define HAVE_MREMAP 0) Feel free to close this bug. Andreas signature.asc Description: This is a digitally signed message part.
Bug#466482: Locales: es_CR.UTF-8 lacks 12-hour format in LC_TIME
...I will ask in the local linux communities for input. Well the proper way to refer to 12-hour format is a.m. and p.m.. Acording to the Real Academia Española (Royal Spanish Academy) (1)(2) ante merídiem (a.m.) and post merídiem (p.m.) is the proper way to use 12-hour format. This applies to all spanish speaking countries, so this might be used for all spanish locales. Thanks to Braulio José Solano Rojas for the links. (1) http://buscon.rae.es/dpdI/SrvltGUIBusDPD?origen=RAElema=ante%20mer%EDdiem (2) http://buscon.rae.es/dpdI/SrvltGUIBusDPD?origen=RAElema=post%20mer%EDdiem -- Saludos Niko
Bug#457337: marked as done (libc6: mremap() returns invalid address)
Your message dated Wed, 20 Feb 2008 06:59:47 +0100
with message-id [EMAIL PROTECTED]
and subject line Re: Bug#457337: libc6: mremap() returns invalid address
has caused the Debian Bug report #457337,
regarding libc6: mremap() returns invalid address
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
457337: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457337
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
---BeginMessage---
Package: libc6
Version: 2.7-4
Severity: normal
Here's a gdb transcript of a part of dlmalloc that is called from some
of my code. Observe how cp, the address returned by mremap, is invalid,
and the code segfaults on the first access to that pointer.
8
Breakpoint 1, mmap_resize (m=0x2b6a5b236010, oldp=0x2b6a5bdb4000,
nb=406784) at src/gklib/dlmalloc.c:2358
2358if (cp != CMFAIL) {
(gdb) l
2353size_t offset = oldp-prev_foot ~IS_MMAPPED_BIT;
2354size_t oldmmsize = oldsize + offset + MMAP_FOOT_PAD;
2355size_t newmmsize = mmap_align(nb + SIX_SIZE_T_SIZES +
CHUNK_ALIGN_MASK);
2356char* cp = (char*)CALL_MREMAP((char*)oldp - offset,
2357 oldmmsize, newmmsize, 1);
2358if (cp != CMFAIL) {
2359 mchunkptr newp = (mchunkptr)(cp + offset);
2360 size_t psize = newmmsize - offset - MMAP_FOOT_PAD;
2361 newp-head = (psize|CINUSE_BIT);
2362 mark_inuse_foot(m, newp, psize);
(gdb) p cp
$3 = 0x5bdb4000 Address 0x5bdb4000 out of bounds
(gdb) n
2359 mchunkptr newp = (mchunkptr)(cp + offset);
(gdb)
2360 size_t psize = newmmsize - offset - MMAP_FOOT_PAD;
(gdb)
2361 newp-head = (psize|CINUSE_BIT);
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0x2b6a5a88849d in mmap_resize (m=0x2b6a5b236010,
oldp=0x2b6a5bdb4000, nb=406784) at src/gklib/dlmalloc.c:2361
2361 newp-head = (psize|CINUSE_BIT);
(gdb) p oldp
$4 = (mchunkptr) 0x2b6a5bdb4000
(gdb) p offset
$5 = 0
(gdb)
8
If you were wondering, CALL_MREMAP is just
8
#define CALL_MREMAP(addr, osz, nsz, mv) ((void)(addr),(void)(osz), \
(void)(nsz), (void)(mv),MFAIL)
8
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.23 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libc6 depends on:
ii libgcc1 1:4.2.2-4 GCC support library
libc6 recommends no packages.
-- debconf information:
glibc/restart-failed:
glibc/restart-services:
---End Message---
---BeginMessage---
Andreas Klöckner a écrit :
On Dienstag 19 Februar 2008, Aurelien Jarno wrote:
ping ?
Sorry, I don't have time to track this issue down any further. I figured out
a
way to not have dlmalloc call mremap, and that settles the issue for me. :-/
(#define HAVE_MREMAP 0)
Feel free to close this bug.
Doing that with this mail.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
---End Message---
r2819 - in glibc-package/trunk/debian: . debhelper.in rules.d script.in
Author: aurel32
Date: 2008-02-20 06:08:45 + (Wed, 20 Feb 2008)
New Revision: 2819
Added:
glibc-package/trunk/debian/script.in/nsscheck.sh
Modified:
glibc-package/trunk/debian/changelog
glibc-package/trunk/debian/debhelper.in/libc.postinst
glibc-package/trunk/debian/debhelper.in/libc.preinst
glibc-package/trunk/debian/rules.d/debhelper.mk
Log:
* Factorize NSS detection code:
- debhelper.in/libc.preinst, debhelper.in/libc.postinst: move NSS code
to...
- script.in/nsscheck.sh: ... this file.
- rules.d/debhelper.mk: Replace NSS_CHECK with code from
script.in/nsscheck.sh.
Modified: glibc-package/trunk/debian/changelog
===
--- glibc-package/trunk/debian/changelog2008-02-19 22:10:12 UTC (rev
2818)
+++ glibc-package/trunk/debian/changelog2008-02-20 06:08:45 UTC (rev
2819)
@@ -6,6 +6,12 @@
* any/submitted-link-local_resolver.diff: kernel 2.6.24 is out, don't wait
indefinitely for upstream. This patch from Pierre Ynard adds support for
link-local addresses in /etc/resolv.conf.
+ * Factorize NSS detection code:
+- debhelper.in/libc.preinst, debhelper.in/libc.postinst: move NSS code
+ to...
+- script.in/nsscheck.sh: ... this file.
+- rules.d/debhelper.mk: Replace NSS_CHECK with code from
+ script.in/nsscheck.sh.
-- Aurelien Jarno [EMAIL PROTECTED] Tue, 19 Feb 2008 23:06:29 +0100
Modified: glibc-package/trunk/debian/debhelper.in/libc.postinst
===
--- glibc-package/trunk/debian/debhelper.in/libc.postinst 2008-02-19
22:10:12 UTC (rev 2818)
+++ glibc-package/trunk/debian/debhelper.in/libc.postinst 2008-02-20
06:08:45 UTC (rev 2819)
@@ -155,50 +155,9 @@
if [ ! -d /var/mail ] [ ! -L /var/mail ]; then
ln -sf spool/mail /var/mail
fi
- if dpkg --compare-versions $preversion lt 2.3.5-1; then
- echo -n Checking for services that may need to be restarted...
- check=apache2-common apache apache-ssl apache-perl autofs at
- check=$check boa cucipop courier-authdaemon cron cupsys exim
- check=$check exim4-base dovecot-common cucipop lprng lpr
- check=$check lpr-ppd mysql-server nis openbsd-inetd
- check=$check openldapd postfix postfix-tls proftpd rsync samba
- check=$check sasl2-bin slapd smail sendmail snmpd ssh
- check=$check spamassassin vsftpd wu-ftpd wu-ftpd-academ wwwoffle
- check=$check webmin dropbear
- # Only get the ones that are installed, and configured
- check=$(dpkg -s $check 2 /dev/null | egrep '^Package:|^Status:' |
awk '{if ($1 ~ /^Package:/) { package=$2 } else if ($0 ~ /^Status: .*
installed$/) { print package }}')
- # some init scripts don't match the package names
- check=$(echo $check | \
- sed -e's/\bapache2-common\b/apache2/g' \
- -e's/\bat\b/atd/g' \
- -e's/\bdovecot-common\b/dovecot/g' \
- -e's/\bexim4-base\b/exim4/g' \
- -e's/\blpr\b/lpd/g' \
- -e's/\blpr-ppd\b/lpd-ppd/g' \
- -e's/\bsasl2-bin\b/saslauthd/g' \
- )
- echo
- echo Checking init scripts...
- rl=$(runlevel | sed 's/.*\ //')
- for service in $check; do
- if [ -x `which invoke-rc.d 2/dev/null` ]; then
- idl=$(ls /etc/init.d/${service} 2 /dev/null | head -n 1)
- if [ -n $idl ] [ -x $idl ]; then
- services=$service $services
- else
- echo WARNING: init script for $service not found.
- fi
- else
- if [ -f /usr/share/file-rc/rc ] || [ -f /usr/lib/file-rc/rc
] [ -f /etc/runlevel.conf ]; then
- idl=$(filerc $rl $service)
- else
- idl=$(ls /etc/rc${rl}.d/S??${service} 2 /dev/null |
head -1)
- fi
- if [ -n $idl ] [ -x $idl ]; then
- services=$service $services
- fi
- fi
- done
+ if dpkg --compare-versions $preversion lt 2.6-1; then
+
+ # NSS services check: NSS_CHECK
if [ -n $services ]; then
if [ -f /usr/share/debconf/confmodule ] ; then
Modified: glibc-package/trunk/debian/debhelper.in/libc.preinst
===
--- glibc-package/trunk/debian/debhelper.in/libc.preinst2008-02-19
22:10:12 UTC (rev 2818)
+++ glibc-package/trunk/debian/debhelper.in/libc.preinst2008-02-20
06:08:45 UTC (rev 2819)
@@ -45,10 +45,7 @@
# NSS authentication trouble guard
if dpkg --compare-versions $2 lt 2.6-1; then
- check=xdm kdm gdm
Processed: tagging 466482
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.26 tags 466482 + pending Bug#466482: Locales: es_CR.UTF-8 lacks 12-hour format in LC_TIME There were no tags set. Tags added: pending End of message, 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]
