guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#53434] Patches to unbreak many i686 packages


From: Ludovic Courtès
Subject: [bug#53434] Patches to unbreak many i686 packages
Date: Sun, 23 Jan 2022 22:32:36 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

> E.g.,  I built upower of i686-linux today, and the build log
> contained:
>
>> # UPower-DEBUG: deferring as others queued
>> # UPower-DEBUG: limiting data to last 10 seconds
>> # UPower-DEBUG: length of array (before) 3
>> # UPower-DEBUG: limiting data to last 10 seconds
>> # UPower-DEBUG: length of array (before) 3
>> # UPower-DEBUG: Using a x division of 2.000000
>> (first=1642875457,last=1642875453)
>> # UPower-DEBUG: length of array (after) 3
>> **
>> UPower:ERROR:up-self-test.c:218:up_test_history_func: assertion
>> failed (array->len == 2): (3 == 2)
>> Bail out! UPower:ERROR:up-self-test.c:218:up_test_history_func:
>> assertion failed (array->len == 2): (3 == 2)
>> FAIL up-self-test (exit status: 134)
>
>
> 1642875457 > 1642875453, so first > last, which is suspect.
>
> Would this be a 32-bit/64-bit issue?
>
> (expt 2 32) is 4294967296 which is as long as 1642875457 and
> 1642875453, so this seems like an overflow issue, so maybe?
> To be investigated ... (I'll look at the source code later).

I remember investigating it while on ‘core-updates-frozen’… and
eventually forgetting about it.  :-/

I think the pragmatic approach in such situations is to:

  1. Report the test failure upstream, including the test log;

  2. Skip tests (ideally selectively) for i686-linux, adding a link to
     the upstream bug report.

That makes sure we move forward while not just sweeping issues under the
carpet.

Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]