Bug#675606: LinuxThreads version bump

2012-06-02 Thread Robert Millan
Package: libc0.1 Version: 2.13-32 Tags: patch Currently, perl relies on getconf to figure out whether threads have their own PID or not. They assume that this is true for linuxthreads but not for NPTL: $ getconf GNU_LIBPTHREAD_VERSION linuxthreads-0.10 $ getconf GNU_LIBPTHREAD_VERSION NPTL

Re: Bug#633402: Bug#674260: RM: aspectc++ [kfreebsd-i386 kfreebsd-amd64] -- ROM; FTBFS on kfreebsd

2012-06-02 Thread Robert Millan
2012/5/29 Reinhard Tartler siret...@tauware.de: What I find a bit irritating is that while using the same glibc version, Debian/kFreeBSD ships a different /usr/include/bits/fnctl.h to the other Debian architectures. The kFreeBSD Version reads: struct flock  {    __off_t l_start;    /*

Re: Possible pthread_cond_timedwait() regression on kfreebsd-i386

2012-06-02 Thread Steven Chamberlain
On 02/06/12 20:16, Stefan Fritsch wrote: since recently, I get some test failure in apr on kfreebsd-i386 that seem to indicate a bug in the kernel or libc. The failing test is part of testlock.c and basically does a pthread_cond_timedwait() ... Hi Stefan, I think you might be seeing #673711

Re: Possible pthread_cond_timedwait() regression on kfreebsd-i386

2012-06-02 Thread Stefan Fritsch
On Sat, 2 Jun 2012, Steven Chamberlain wrote: On 02/06/12 20:16, Stefan Fritsch wrote: since recently, I get some test failure in apr on kfreebsd-i386 that seem to indicate a bug in the kernel or libc. The failing test is part of testlock.c and basically does a pthread_cond_timedwait() ...

Re: Possible pthread_cond_timedwait() regression on kfreebsd-i386

2012-06-02 Thread Steven Chamberlain
Hi, On 02/06/12 20:42, Stefan Fritsch wrote: I will just wait for an eglibc update and then see if it fixes the problem. I tested this on my kfreebsd-i386 system where I already rebuilt eglibc with the patch from SVN. Looks good to me:

Re: Possible pthread_cond_timedwait() regression on kfreebsd-i386

2012-06-02 Thread Stefan Fritsch
On Saturday 02 June 2012, Steven Chamberlain wrote: On 02/06/12 20:42, Stefan Fritsch wrote: I will just wait for an eglibc update and then see if it fixes the problem. I tested this on my kfreebsd-i386 system where I already rebuilt eglibc with the patch from SVN. Looks good to me:

Re: Possible pthread_cond_timedwait() regression on kfreebsd-i386

2012-06-02 Thread Steven Chamberlain
On 02/06/12 23:03, Stefan Fritsch wrote: You have to run testlock, not testsock. Uhh, typo. testlock 'succeeds', but with this message, shown every time? testlock: \Timer returned 0ms late SUCCESS All tests passed. testlock: \Timer returned 0ms late SUCCESS All

Re: Possible pthread_cond_timedwait() regression on kfreebsd-i386

2012-06-02 Thread Stefan Fritsch
On Sunday 03 June 2012, Steven Chamberlain wrote: On 02/06/12 23:03, Stefan Fritsch wrote: You have to run testlock, not testsock. Uhh, typo. testlock 'succeeds', but with this message, shown every time? testlock: \Timer returned 0ms late SUCCESS All tests passed.

Re: Bug#674942: ruby blocks buildd for a day (or more)

2012-06-02 Thread Steven Chamberlain
On 02/06/12 11:17, Antonio Terceiro wrote: I am thus disabling the DRB tests, and removing the timeout I set in the last upload, since I believe it will not be needed anymore. In past build logs it has always been the ERB tests that hang on the kfreebsd-* buildds, and the same has happened