Bug#501169: Hello
Hi, I am Blessing! please how are you! hope you are fine and in perfect condition of health,please if you don't mind i will like you to write me back hope to hear from you soon,and I will be waiting for your mail because i have something VERY important to tell you. Lots of love Blessing!
r3176 - tzdata/tags
Author: schizo Date: 2008-10-28 02:47:53 + (Tue, 28 Oct 2008) New Revision: 3176 Added: tzdata/tags/2008i-1/ Log: tag 2008i-1 Copied: tzdata/tags/2008i-1 (from rev 3175, tzdata/trunk) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
r3175 - in tzdata/trunk/debian: . patches po
Author: schizo Date: 2008-10-28 02:46:52 + (Tue, 28 Oct 2008) New Revision: 3175 Removed: tzdata/trunk/debian/patches/argentina-no-dst.diff Modified: tzdata/trunk/debian/changelog tzdata/trunk/debian/patches/series tzdata/trunk/debian/po/en.po tzdata/trunk/debian/po/templates.pot tzdata/trunk/debian/templates Log: 2008i-1 Modified: tzdata/trunk/debian/changelog === --- tzdata/trunk/debian/changelog 2008-10-26 10:11:16 UTC (rev 3174) +++ tzdata/trunk/debian/changelog 2008-10-28 02:46:52 UTC (rev 3175) @@ -1,3 +1,11 @@ +tzdata (2008i-1) unstable; urgency=low + + * New upstream version. +- Drop argentina-no-dst.diff (obsolete). + * debian/po/en.po: add translation for Salta (Argentina). + + -- Clint Adams <[EMAIL PROTECTED]> Mon, 27 Oct 2008 21:34:51 -0400 + tzdata (2008h-2) unstable; urgency=high * Apply patch from Margarita Manterola to fix DST for Argentina this @@ -7,7 +15,7 @@ tzdata (2008h-1) unstable; urgency=high - * New upstream version. + * New upstream version. * Remove argentina.diff to enable DST in Argentina for October 19th. * Urgency set to high, as the change will happen soon. @@ -15,7 +23,7 @@ tzdata (2008g-1) unstable; urgency=low - * New upstream version. + * New upstream version. -- Aurelien Jarno <[EMAIL PROTECTED]> Mon, 06 Oct 2008 15:17:28 +0200 @@ -37,7 +45,7 @@ tzdata (2008e-4) unstable; urgency=low - * Add a README.Debian file explaining the difference between the + * Add a README.Debian file explaining the difference between the "posix" and the "right" versions of the timezone data. * Only build the posix version of the timezone data on emdebian. * Don't build solar87, solar88 and solar89 on emdebian as they are Deleted: tzdata/trunk/debian/patches/argentina-no-dst.diff === --- tzdata/trunk/debian/patches/argentina-no-dst.diff 2008-10-26 10:11:16 UTC (rev 3174) +++ tzdata/trunk/debian/patches/argentina-no-dst.diff 2008-10-28 02:46:52 UTC (rev 3175) @@ -1,75 +0,0 @@ -Index: b/southamerica -=== a/southamerica -+++ b/southamerica -@@ -194,8 +194,8 @@ - # So there is no summer time in Argentina for now. - - Rule Arg 2007only- Dec 30 0:001:00S --Rule Arg 2008max - Mar Sun>=15 0:000 - --Rule Arg 2008max - Oct Sun>=15 0:001:00S -+Rule Arg 20082009- Mar Sun>=15 0:000 - -+Rule Arg 2008only- Oct Sun>=15 0:001:00S - - # From Mariano Absatz (2004-05-21): - # Today it was officially published that the Province of Mendoza is changing -@@ -388,7 +388,8 @@ - -4:00 Arg AR%sT 2000 Mar 3 - -3:00 - ART 2004 Jun 1 - -4:00 - WART2004 Jun 20 -- -3:00 Arg AR%sT -+ -3:00 Arg AR%sT 2008 Oct 18 -+ -3:00 - ART - # - # San Juan (SJ) - Zone America/Argentina/San_Juan -4:34:04 - LMT1894 Oct 31 -@@ -401,7 +402,8 @@ - -4:00 Arg AR%sT 2000 Mar 3 - -3:00 - ART 2004 May 31 - -4:00 - WART2004 Jul 25 -- -3:00 Arg AR%sT -+ -3:00 Arg AR%sT 2008 Oct 18 -+ -3:00 - ART - # - # Jujuy (JY) - Zone America/Argentina/Jujuy -4:21:12 - LMT 1894 Oct 31 -@@ -428,7 +430,8 @@ - -4:00 Arg AR%sT 2000 Mar 3 - -3:00 - ART 2004 Jun 1 - -4:00 - WART2004 Jun 20 -- -3:00 Arg AR%sT -+ -3:00 Arg AR%sT 2008 Oct 18 -+ -3:00 - ART - # - # Mendoza (MZ) - Zone America/Argentina/Mendoza -4:35:16 - LMT 1894 Oct 31 -@@ -445,7 +448,8 @@ - -4:00 Arg AR%sT 2000 Mar 3 - -3:00 - ART 2004 May 23 - -4:00 - WART2004 Sep 26 -- -3:00 Arg AR%sT -+ -3:00 Arg AR%sT 2008 Oct 18 -+ -3:00 - ART - # - # San Luis (SL) - Zone America/Argentina/San_Luis -4:25:24 - LMT1894 Oct 31 -@@ -473,7 +477,8 @@ - -4:00 Arg AR%sT 2000 Mar 3 - -3:00 - ART 2004 Jun 1 - -4:00 - WART2004 Jun 20 -- -3:00 Arg AR%sT -+ -3:00 Arg AR%sT 2008 Oct 18 -+ -3:00 - ART - # - # Tierra del Fuego
Processing of tzdata_2008i-1_all.changes
tzdata_2008i-1_all.changes uploaded successfully to localhost along with the files: tzdata_2008i-1.dsc tzdata_2008i.orig.tar.gz tzdata_2008i-1.diff.gz tzdata_2008i-1_all.deb tzdata-java_2008i-1_all.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of glibc_2.7-15_hppa.changes
glibc_2.7-15_hppa.changes uploaded successfully to localhost along with the files: libc6_2.7-15_hppa.deb libc6-dev_2.7-15_hppa.deb libc6-prof_2.7-15_hppa.deb libc6-pic_2.7-15_hppa.deb locales-all_2.7-15_hppa.deb nscd_2.7-15_hppa.deb libc6-dbg_2.7-15_hppa.deb libc6-udeb_2.7-15_hppa.udeb libnss-dns-udeb_2.7-15_hppa.udeb libnss-files-udeb_2.7-15_hppa.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#494468: give back request: glibc_2.7-15_hppa
* Mark Purcell [Mon, 27 Oct 2008 19:15:21 +1100]: > d-r, > It would appear that resolution of RC #494468 is being held out of lenny by > the lack of the hppa build, which appears to of been last successful on 14 > Oct. > Request a give back be scheduled for glibc_2.7-15_hppa Done. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: The Wallflowers - Invisible city -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479952: Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
At 1225129482 time_t, Moritz Muehlenhoff wrote: > Maybe we could forward this bug to Martin Schwidefsky <[EMAIL PROTECTED]>, > who is the glibc s390 maintainer and who works for IBM on the s390 Linux port. Why not. Martin, do you have any clue about bug #479952? http://bugs.debian.org/479952 Cheers, -- Julien Danjou .''`. Debian Developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD signature.asc Description: Digital signature
Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
On Mon, Oct 27, 2008 at 11:27 AM, Andrew Haley <[EMAIL PROTECTED]> wrote: > I understand all that, but the question still stands: is the compiler > really moving a memory write past a memory barrier? ISTR we did have > a discussion on gcc-list about that, but it was a while ago and should > now be fixed. This issue no longer affects the PA port, but I can't speak for s390. The PA port is the only port for which I do regular gcc / glibc testing. Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
Carlos O'Donell wrote: > On Mon, Oct 27, 2008 at 10:05 AM, Andrew Haley <[EMAIL PROTECTED]> wrote: >>> I've seen this on-and-off again on the hppa-linux port. The issue has, >>> in my experience, been a compiler problem. My standard operating >>> procedure is to methodically add volatile to the atomic.h operations >>> until it goes away, and then work out the compiler mis-optimization. >>> >>> The bug is almost always a situation where the lll_unlock is scheduled >>> before owner = 0, and the assert catches the race condition where you >>> unlock but have not yet cleared the owner. >> Are you sure this is a compiler problem? Unless you use explicit atomic >> memory accesses or volatile the compiler is supposed to re-order memory >> access. Perhaps I'm misunderstanding you. > > Sorry, parsing the above statement requires knowing something about > how lll_unlock is implemented in glibc. > > The lll_unlock function is supposed to be a memory barrier. > > The function is usually an explicit atomic operation, or a volatile > asm implementing the futex syscall i.e. INTERNAL_SYSCALL macro. I understand all that, but the question still stands: is the compiler really moving a memory write past a memory barrier? ISTR we did have a discussion on gcc-list about that, but it was a while ago and should now be fixed. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
Carlos O'Donell wrote: > On Sat, Oct 25, 2008 at 1:21 PM, Julien Danjou <[EMAIL PROTECTED]> wrote: >> Is there anything from an outsider that could help? > > I've seen this on-and-off again on the hppa-linux port. The issue has, > in my experience, been a compiler problem. My standard operating > procedure is to methodically add volatile to the atomic.h operations > until it goes away, and then work out the compiler mis-optimization. > > The bug is almost always a situation where the lll_unlock is scheduled > before owner = 0, and the assert catches the race condition where you > unlock but have not yet cleared the owner. Are you sure this is a compiler problem? Unless you use explicit atomic memory accesses or volatile the compiler is supposed to re-order memory access. Perhaps I'm misunderstanding you. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
On Mon, Oct 27, 2008 at 10:05 AM, Andrew Haley <[EMAIL PROTECTED]> wrote: >> I've seen this on-and-off again on the hppa-linux port. The issue has, >> in my experience, been a compiler problem. My standard operating >> procedure is to methodically add volatile to the atomic.h operations >> until it goes away, and then work out the compiler mis-optimization. >> >> The bug is almost always a situation where the lll_unlock is scheduled >> before owner = 0, and the assert catches the race condition where you >> unlock but have not yet cleared the owner. > > Are you sure this is a compiler problem? Unless you use explicit atomic > memory accesses or volatile the compiler is supposed to re-order memory > access. Perhaps I'm misunderstanding you. Sorry, parsing the above statement requires knowing something about how lll_unlock is implemented in glibc. The lll_unlock function is supposed to be a memory barrier. The function is usually an explicit atomic operation, or a volatile asm implementing the futex syscall i.e. INTERNAL_SYSCALL macro. Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#443475: nscd aborts with other messages,too
The same behaviour in our company. Also using LDAP. libc version 2.3.6.ds1-13etch7. nscd: cache.c:335: prune_cache: Assertion `dh->usable' failed.
Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
On Sat, Oct 25, 2008 at 1:21 PM, Julien Danjou <[EMAIL PROTECTED]> wrote: > Is there anything from an outsider that could help? I've seen this on-and-off again on the hppa-linux port. The issue has, in my experience, been a compiler problem. My standard operating procedure is to methodically add volatile to the atomic.h operations until it goes away, and then work out the compiler mis-optimization. The bug is almost always a situation where the lll_unlock is scheduled before owner = 0, and the assert catches the race condition where you unlock but have not yet cleared the owner. $0.02. Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug math/3976] libm rounding modes do not work correctly for many archs
--- Additional Comments From joseph at codesourcery dot com 2008-10-27 12:42 --- Subject: Re: libm rounding modes do not work correctly for many archs On Mon, 27 Oct 2008, vincent+libc at vinc17 dot org wrote: > So, this just means that an implementation doesn't need to return a result > rounded to the correct direction (this is implementation-defined). Still it > should return an approximate value whatever the rounding direction mode is, > and > not behave erratically. Furthermore, some functions whose implementations only work in round-to-nearest mode do save the mode then set round-to-nearest using feholdexcept and fesetround (e.g. sysdeps/ieee754/dbl-64/e_exp2.c). I think this is the best thing to do in such cases. (Regarding the issue of rounding modes in signal handlers, I think the best thing is for ABI documents to make explicit that library functions may temporarily save and restore rounding modes; that's what is being done in the Power Architecture ABI document being worked on, to document what the de facto ABI is right now.) -- http://sourceware.org/bugzilla/show_bug.cgi?id=3976 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. 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#503669: nscd: caching is really working?
Package: nscd Version: 2.3.6.ds1-13etch7 Severity: minor i set negative and positive ttl to 600 at group and password. why communicating the client with the server again and again when i'm running a finger command? -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-686-bigmem Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages nscd depends on: ii libc6 2.7-12 GNU C Library: Shared libraries nscd recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug math/3976] libm rounding modes do not work correctly for many archs
--- Additional Comments From vincent+libc at vinc17 dot org 2008-10-27 09:33 --- (In reply to comment #4) > The functions have defined behavior only in the default rounding mode > (round-to-even), anything else is undefined behavior and completely > programmer's > fault for calling the functions in those rounding modes. No, it isn't. There's no undefined behavior there. The C standard says (F.9): "Whether the functions honor the rounding direction mode is implementation-defined." So, this just means that an implementation doesn't need to return a result rounded to the correct direction (this is implementation-defined). Still it should return an approximate value whatever the rounding direction mode is, and not behave erratically. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://sourceware.org/bugzilla/show_bug.cgi?id=3976 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. 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 math/3976] libm rounding modes do not work correctly for many archs
--- Additional Comments From jakub at redhat dot com 2008-10-27 08:25 --- The functions have defined behavior only in the default rounding mode (round-to-even), anything else is undefined behavior and completely programmer's fault for calling the functions in those rounding modes. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://sourceware.org/bugzilla/show_bug.cgi?id=3976 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. 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 math/3976] libm rounding modes do not work correctly for many archs
--- Additional Comments From c_keil at yahoo dot de 2008-10-27 08:17 --- At least on my Core2 Duo it's also not working with still other values (32bit version is ok): gcc -m64 -lm -o a a.c; ./a 1 2 N: exp(1) = 2.7182818284590451 Z: exp(1) = 2.7182818284590451 D: exp(1) = 2.7182818284590451 U: exp(1) = 7.1387612927397726 N: exp(2) = 7.3890560989306504 Z: exp(2) = 4.0037745305985499 D: exp(2) = 4.0037745305985499 U: exp(2) = 7.3890560989306504 As far as I dug into it, the 32bit and 64bit versions use other code. 64bit comes from the IBM Accurate Mathematical Library. For exp sysdeps/ieee754/dbl-64/e_exp.c produces the wrong results. -- What|Removed |Added CC||c_keil at yahoo dot de http://sourceware.org/bugzilla/show_bug.cgi?id=3976 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. 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#494468: give back request: glibc_2.7-15_hppa
d-r, It would appear that resolution of RC #494468 is being held out of lenny by the lack of the hppa build, which appears to of been last successful on 14 Oct. Request a give back be scheduled for glibc_2.7-15_hppa Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
