[bug#64711] [PATCH 37/43] gnu: glib: Disable tests for the Hurd.

[Maxim Cournoyer]

Hi Janneke,

Janneke Nieuwenhuizen <janneke@gnu.org> writes:

> Maxim Cournoyer writes:
>
> Hello!
>
>> Janneke Nieuwenhuizen <janneke@gnu.org> writes:
>>
>>> Liliana Marie Prikler writes:
>>>
>>>> Am Dienstag, dem 18.07.2023 um 16:40 +0200 schrieb Janneke
>>>> Nieuwenhuizen:
>>>>> * gnu/packages/glib.scm (glib)[arguments]: When building for the
>>>>> Hurd,
>>>>> set #:tests? to #false.
>>>
>>> [..]
>>>>> +      #:tests? (not (target-hurd?))
>>>
>>>>> compiled
>>>
>>>> Instead of disabling tests altogether, can we just disable those that
>>>> fail on the Hurd?
>>>
>>> We probably can, and I have tried to do so in most cases.  However,
>>> identifying those tests can be quite time consuming.  I'm not sure how
>>> many tests failed here, and note that some tests will hang or crash the
>>> Hurd, so if we decide to do this, I would appreciate some help :-)
>>>
>>> Ludo on the other hand, argued against having more than ~20 (IIRC) test
>>> exceptions and using #:tests? #f instead.
>>>
>>> My idea was to get guix to build natively, and guix pull to work.  Once
>>> we get those to work, we can possibly look forward to more contributors
>>> to this.
>>
>> I agree with Liliana that it's nicer to disable just these tests that
>> fail, but in light of what you wrote, your approach seems reasonable.
>
> Yes, I agree that if we want to make Hurd better and enabble us to
> create a bug report it sure helps if we have more information.
>
> Yesterday I decided to have another look into this.  I have identified
> 20 tests that TIMEOUT after 600s, and 37 FAIL and instead of setting
> #:tests? to #false, I have added them to the `disable-failing-tests'
> phase when building on the Hurd.  See attached patch.

Well done pushing the investigation!

Are you sure these failures are Hurd-only?  When I see timeouts related
to dbus tests, I often think the problem may be attributed to #30948,
because dbus often waits for processes to die completely but are left as
zombies in the build container due to incorrect signal handling from the
Guile PID 1 there.  But since the glib package currently builds for
x86_64 at least, that's probably not it...

LGTM.

-- 
Thanks,
Maxim