For someone bored: fix glib2.0 and apr

[Thorsten Glaser <tg@mirbsd.de>]

Hi,

I don’t know where they get the misconception of it being dead
from, but it’s an offer.

glib2.0 needs to have investigated why that one testcase eats
up all CPU and does nothing. At worst, disable the testcase,
at best, fix the problem (whereever it is).

apr needs to have investigated which “lock and mutex mechanisms”
are causing trouble, and these either fixed (in kernel/libc/…)
or disabled (in apr debian/rules).

I’m busy with other toolchain stuff. But I uploaded gcc-4.8 so
if someone wants to test compiling with that… doko wants to
switch to it as default compiler soonish.

bye,
//mirabilos
-- 
In traditional syntax ' is ignored, but in c99 everything between two ' is
handled as character constant.  Therefore you cannot use ' in a preproces-
sing file in c99 mode.	-- Ragge
No faith left in ISO C99, undefined behaviour, etc.


---------- Forwarded message ----------
From: Emilio Pozuelo Monfort <pochu@debian.org>
Message-ID: <5193D353.1010803@debian.org>
X-Spam-Status: No, hits=0.000000 required=0.900000
To: Thorsten Glaser <tg@mirbsd.de>
Cc: pkg-gnome-maintainers@lists.alioth.debian.org
Date: Wed, 15 May 2013 20:26:27 +0200
Subject: Re: Log for attempted build of glib2.0_2.36.1-2build1 on m68k
    (dist=unstable)

On 15/05/13 19:18, Thorsten Glaser wrote:
>fail
>
>times out while running the testsuite; this also happens
>when I build manually; CPU is not idle

Patches welcome.



---------- Forwarded message ----------
From: Stefan Fritsch <sf@sfritsch.de>
Message-ID: <201305180852.50537.sf@sfritsch.de>
X-Spam-Status: No, hits=0.000000 required=0.900000
To: Thorsten Glaser <tg@mirbsd.de>
Cc: debian-apache@lists.debian.org
Date: Sat, 18 May 2013 08:52:50 +0200
Subject: Re: Log for attempted build of apr_1.4.6-4 on m68k (dist=unstable)

On Saturday 18 May 2013, Thorsten Glaser wrote:
> fail
> 
> fails some parts of the testsuite
> Failed Tests            Total   Fail    Failed %
> ===================================================
> testlock                    4      1     25.00%
> testprocmutex               6      1     16.67%
> testshm                     6      1     16.67%

Experience shows that such failures are nearly always caused by bugs 
in the kernel or libc. But we can disable certain lock and mutex 
mechanisms on certain architectures if that helps. See debian/rules 
for examples. But the patch what to disable would have to come from 
the porters. I am not willing to spend time debugging dead 
architectures. 

Cheers,
Stefan