Package: pygobject
Version: 3.8.1-2
Severity: serious
(CCing BSD porters, help wanted here)
pygobject currently fails to build on kfreebsd, see [1]
I've tried to debug this on falla. I can reproduce the hang somewhat reliably
by running:
dpkg-buildpackage
And if it doesn't hang or if you want
On 10/05/13 20:41, Emilio Pozuelo Monfort wrote:
Thread 1 (process 75189):
#0 0x00080161ed4a in kevent () at ../sysdeps/unix/syscall-template.S:82
#1 0x000802a57bd7 in _kqueue_thread_func (arg=)
at /build/buildd-glib2.0_2.36.1-2-kfreebsd-
amd64-CmfXXB/glib2.0-2.36.1/./gio/kqueue/kq
On 11/05/13 17:08, Emilio Pozuelo Monfort wrote:
On 10/05/13 20:41, Emilio Pozuelo Monfort wrote:
Thread 1 (process 75189):
#0 0x00080161ed4a in kevent () at ../sysdeps/unix/syscall-template.S:82
#1 0x000802a57bd7 in _kqueue_thread_func (arg=)
at /build/buildd-glib2.0_2.36.1-2-kfr
Emilio Pozuelo Monfort writes:
> Package: pygobject
> Version: 3.8.1-2
> Severity: serious
>
> (CCing BSD porters, help wanted here)
>
> pygobject currently fails to build on kfreebsd, see [1]
>
> I've tried to debug this on falla. I can reproduce the hang somewhat reliably
> by running:
>
> dpkg-
On 12/05/13 15:40, Christoph Egger wrote:
Emilio Pozuelo Monfort writes:
Package: pygobject
Version: 3.8.1-2
Severity: serious
(CCing BSD porters, help wanted here)
pygobject currently fails to build on kfreebsd, see [1]
I've tried to debug this on falla. I can reproduce the hang somewhat re
Another bug that may be similar:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671785
In that bug I remark that a problem with pthread_mutex_unlock can be
observed on linux with valgrind --tool=helgrind. I haven't tried to
determine whether it's a similar problem here, but it might be worth
v
valgrind (helgrind) on linux (sid amd64 chroot on wheezy amd64) didn't turn up
anything that looked too useful. There were a number of diagnostics of
this general form:
==12158== Lock at 0x603E5C0 was first observed
==12158==at 0x4C2EB32: pthread_mutex_init (in
/usr/lib/valgrind/vgpreload_he
Hurd seems to hang at the same place[1]. Perhaps that helps in determining where
the bug may lie (e.g. if both Hurd and kfreebsd use the same pthread library
implementation).
[1]
https://buildd.debian.org/status/fetch.php?pkg=pygobject&arch=hurd-i386&ver=3.8.1-3&stamp=1368332988
--
To UNSUB
Hurd seems to hang at the same place[1]. Perhaps that helps in determining where
the bug may lie (e.g. if both Hurd and kfreebsd use the same pthread library
implementation).
They do not use the same pthread library implementation ...
Petr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@
OK, this seems crazy to me but I feel obliged to note it:
When I build 3.8.1-3 in /usr/src or /tmp/wat, I can observe the failure when I
subsequently 'make check' in build-2.7/tests. When I build it in /tmp or
/tmp/wat/frugal-bonasfrarfsarfasrfasrf/pygobject-3.8.1 I do not.
However, I also note
On 17/05/13 05:37, Jeff Epler wrote:
OK, this seems crazy to me but I feel obliged to note it:
When I build 3.8.1-3 in /usr/src or /tmp/wat, I can observe the failure when I
subsequently 'make check' in build-2.7/tests. When I build it in /tmp or
/tmp/wat/frugal-bonasfrarfsarfasrfasrf/pygobject
11 matches
Mail list logo
