tags 673579 + pending
thanks
Hi
(I added Michael Taautschnig directly to the loop)
On Sat, May 19, 2012 at 11:25:41PM +0100, Steven Chamberlain wrote:
tags 673579 + patch
thanks
On 19/05/12 23:02, Christoph Egger wrote:
Steven Chamberlain ste...@pyro.eu.org writes:
#if
On 05/16/2012 11:51 AM, Roger Leigh wrote:
On Wed, May 16, 2012 at 07:18:21AM +0200, Christoph Egger wrote:
Hi all!
Christoph Eggerchrist...@debian.org writes:
Christoph Eggerchrist...@debian.org writes:
Robert Millanr...@debian.org writes:
2012/5/12 Damien
On Sun, May 20, 2012 at 03:41:56PM +0300, Georgi Naplatanov wrote:
I have tried to run dpkg-buildpackage manually inside chroot
environment (with schroot-1.4.22-1~bpo60+1) and build failed.
Can that version of schroot be a problem ?
Is there a debian repository for newer version of
Package: src:eegdev
Version: 0.2-1
Severity: serious
Tags: sid wheezy
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-bsd@lists.debian.org
Justification: fails to build from source (but built successfully in the past)
Hi!
Your package failed to build on the kfreebsd-*
found 673594 1.8.7.352-2
tags 673594 + patch
thanks
Hi,
What about using the attached patch to time out the test-all suite if it
hangs, as was done for ruby1.9.1, because its exit status is ignored
anyway (some failures are expected, on all arches).
I think a workaround like this is needed to
Whereas the buildds experience hangs during some tests, I see segfaults
instead. This sometimes happens even before the first test has been run.
This small Ruby testcase results in segfault 50% of the time under
ruby1.8 1.8.7.358-2, but always succeeds with ruby1.9.1 1.9.3.0-2:
require
Source: libfprint
Version: 20110418git-2
Severity: normal
Tags: upstream, help
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
according to past build logs, libfprint fails to build from source on
kfreebsd-* with the following error:
drivers/uru4000.c: In function 'rebootpwr_run_state':
Package: kfreebsd-image-9.0-1-amd64
Version: 9.0-3
Severity: important
File: kfreebsd-9
Tags: upstream
Hi,
when using pthread_cond_timedwait, it often returns immediately with
the error ETIMEDOUT regardless to the length of the timeout passed to the
function. I have provided a C program
Hi!
Nicolas Bourdaud nicolas.bourd...@gmail.com writes:
when using pthread_cond_timedwait, it often returns immediately with
the error ETIMEDOUT regardless to the length of the timeout passed to the
function. I have provided a C program that illustrates the problem.
It affects
reassign 673711 libc0.1
retitle 673711 pthread_cond_timedwait returns immediately with ETIMEDOUT
found 673711 eglibc/2.13-32
tags 673711 - upstream
user debian-bsd@lists.debian.org
usertags 673711 kfreebsd
thanks
Hi!
On 20/05/12 23:56, Christoph Egger wrote:
Nicolas Bourdaud
Processing commands for cont...@bugs.debian.org:
reassign 673711 libc0.1
Bug #673711 [kfreebsd-image-9.0-1-amd64] kfreebsd-9: pthread_cond_timedwait
returns immediately with ETIMEDOUT
Bug reassigned from package 'kfreebsd-image-9.0-1-amd64' to 'libc0.1'.
No longer marked as found in versions
Hi
On 21/05/2012 01:21, Steven Chamberlain wrote:
I find it interesting that this bug led to those glibc errors (double
free or corruption) in #673681 instead of a hang or simple test failure.
Actually this bug does not cause the corruption in #673681: a race
condition in the unit tests is the
12 matches
Mail list logo
