On Wed, Nov 22, 2006 at 09:54:42AM -0700, Shaun Jackman wrote:
> On 11/22/06, Roman Zippel <[EMAIL PROTECTED]> wrote:
> ...
> >> 1. Is this more likely a bug in Boost or a bug in monotone?
> >> 2. Is it reasonable to workaround this bug by removing
> >> -DBOOST_SP_DISABLE_THREADS?
> >> 3. Is it wor
On 11/22/06, Roman Zippel <[EMAIL PROTECTED]> wrote:
...
> 1. Is this more likely a bug in Boost or a bug in monotone?
> 2. Is it reasonable to workaround this bug by removing
> -DBOOST_SP_DISABLE_THREADS?
> 3. Is it worth going to the extra effort to only define
> -DBOOST_SP_DISABLE_THREADS on t
Hi,
On Tue, 21 Nov 2006, Shaun Jackman wrote:
> It appears the BOOST_SP_DISABLE_THREADS is the source of monotone's
> cross-platform issues on Debian. Namely, that monotone fails to run
> (deadlock) on s390, hppa, sparc, mips, and mipsel, but runs fine on
> i386, amd64, ia64, alpha and powerpc [1
On Tue, Nov 21, 2006 at 02:04:07PM -0700, Shaun Jackman wrote:
> It appears the BOOST_SP_DISABLE_THREADS is the source of monotone's
> cross-platform issues on Debian. Namely, that monotone fails to run
> (deadlock) on s390, hppa, sparc, mips, and mipsel, but runs fine on
> i386, amd64, ia64, alpha
On 9/28/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
No, it looks to me like monotone is running a command during the build that
takes an unreasonably long time to complete on a number of our
architectures.
We could ask the buildd maintainers to increase timeouts for monotone, but
given that th
On Thu, Sep 28, 2006 at 06:36:08PM +0200, Ludovic Brenta wrote:
> Much to my bafflement, I notice that 0.29 built successfully on sparc,
> but 0.30 FTBFS. Also, the machine that built 0.29 may not be the same
> as the one that built 0.30; for sparc, these were phleebhut and auric,
> respectively.
Thank you for that trouble shooting! This is very useful information.
Cheers,
Shaun
On 9/28/06, Roman Zippel <[EMAIL PROTECTED]> wrote:
Hi,
I debugged the problem a bit and the problem seems to be the
BOOST_SP_DISABLE_THREADS define and monotone being linked against the
multithreaded boost lib
Hi,
I debugged the problem a bit and the problem seems to be the
BOOST_SP_DISABLE_THREADS define and monotone being linked against the
multithreaded boost libraries. boost and monotone have a different idea
of the sp_counted_base class, so that it gets initialized within monotone
non-threaded
Much to my bafflement, I notice that 0.29 built successfully on sparc,
but 0.30 FTBFS. Also, the machine that built 0.29 may not be the same
as the one that built 0.30; for sparc, these were phleebhut and auric,
respectively. I suspect that there may be a hardware problem on some
of the buildd ma
On Tuesday 26 September 2006 20:10, Shaun Jackman wrote:
> Both commands exist in fact. get_revision is used to generate
> package_full_revision.txt, and get_base_revision_id is used to
> generate package_revision.txt. Both of these commands require a
> monotone workspace though, and the tarball do
On 9/26/06, Ludovic Brenta <[EMAIL PROTECTED]> wrote:
The bug still happens with 0.30. I was browsing the monotone-devel
archives and something went *tick* in my head:
Shaun Jackman wrote:
> The monotone-0.30.tar.gz tarball shipped with package_revision.txt set
> to `unknown'. Should this be fi
The bug still happens with 0.30. I was browsing the monotone-devel
archives and something went *tick* in my head:
Shaun Jackman wrote:
> The monotone-0.30.tar.gz tarball shipped with package_revision.txt set
> to `unknown'. Should this be fixed?
Thomas Moschny wrote:
> [it is likely to affect 0.
Package: monotone
Version: 0.29-1
Severity: serious
There was an error while trying to autobuild your package:
> Automatic build of monotone_0.29-1 on lxdebian.bfinv.de by sbuild/s390 85
[...]
> REAL_BLDDIR=$PWD/.; \
> (cd . && $REAL_BLDDIR/mtn --root=. automate get_revision) 2>/dev/null
>
13 matches
Mail list logo
