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

[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) =

[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. --

[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

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:

[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

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

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 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

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

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

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

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

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

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

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

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

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!