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

[Janneke Nieuwenhuizen]

Maxim Cournoyer writes:

Hi Maxim,

> 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!

Thanks, and thanks for push ;)

> Are you sure these failures are Hurd-only?

No, not 100%, but...

> 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,

...yeah, I didn't check if some problems are 32bit related, for example.

 that's probably not it...

> LGTM.

\o/
Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com