[bug#53434,11/11] gnu: upower: Disable tests on i686.

* gnu/packages/gnome.scm (upower)[arguments]<#:tests?>:
Conditionally disable tests.
---
 gnu/packages/gnome.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Denis 'GNUtoo' Carikli schreef op za 22-01-2022 om 03:59 [+0100]:
> * gnu/packages/gnome.scm (upower)[arguments]<#:tests?>:

Reported upstream at
<https://gitlab.freedesktop.org/upower/upower/-/issues/167>.

Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

> Denis 'GNUtoo' Carikli schreef op za 22-01-2022 om 03:59 [+0100]:
>> * gnu/packages/gnome.scm (upower)[arguments]<#:tests?>:
>
> Reported upstream at
> <https://gitlab.freedesktop.org/upower/upower/-/issues/167>.

This reminds me that we had to build with ‘-fexcess-precision=standard’
many packages on i686 since the switch to GCC 10.  Would it help?

However, it turns out there upower builds fine currently:

--8<---------------cut here---------------start------------->8---
$ guix describe
Generacio 204   Feb 15 2022 10:48:52    (nuna)
  guix 8d472e9
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 8d472e9314052403ad548f92ca6c10f9c961a087
$ guix weather upower -s i686-linux
computing 1 package derivations for i686-linux...
looking for 1 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org
  100.0% substitutes available (1 out of 1)
  at least 0.7 MiB of nars (compressed)
  1.1 MiB on disk (uncompressed)
  0.168 seconds per request (0.2 seconds in total)
  5.9 requests per second

  4 queued builds
      aarch64-linux: 2 (50.0%)
      powerpc64le-linux: 2 (50.0%)
  build rate: 56.46 builds per hour
      aarch64-linux: 19.60 builds per hour
      x86_64-linux: 18.75 builds per hour
      powerpc64le-linux: 8.86 builds per hour
      i686-linux: 9.33 builds per hour
looking for 1 store items on https://bordeaux.guix.gnu.org...
https://bordeaux.guix.gnu.org
  100.0% substitutes available (1 out of 1)
  0.2 MiB of nars (compressed)
  1.1 MiB on disk (uncompressed)
  0.126 seconds per request (0.1 seconds in total)
  7.9 requests per second
  (continuous integration information unavailable)
$ guix build upower -s i686-linux --no-grafts
/gnu/store/dcddizvvl599s6zgwk951gz7frk2g2gh-upower-0.99.13
$ guix build upower -s i686-linux --no-grafts -d
/gnu/store/x78bb68amwgb7znvbbmhg5pxrlnj9p53-upower-0.99.13.drv
--8<---------------cut here---------------end--------------->8---

Did the problem sort itself?

Thanks,
Ludo’.

Ludovic Courtès schreef op wo 16-02-2022 om 14:53 [+0100]:
> Hi,
> 
> Maxime Devos <maximedevos@telenet.be> skribis:
> 
> > Denis 'GNUtoo' Carikli schreef op za 22-01-2022 om 03:59 [+0100]:
> > > * gnu/packages/gnome.scm (upower)[arguments]<#:tests?>:
> > 
> > Reported upstream at
> > <https://gitlab.freedesktop.org/upower/upower/-/issues/167>.

> However, it turns out there upower builds fine currently:
> [...]
> Did the problem sort itself?

The test failure was somewhat non-deterministic.

> This reminds me that we had to build with ‘-fexcess-
> precision=standard’
> many packages on i686 since the switch to GCC 10.  Would it help?

Possibly, but perhaps backporting the upstream fix that largely avoids
floating-point arithmetic would be better?
(See
<https://gitlab.freedesktop.org/upower/upower/-/merge_requests/101>.)

Also, looks like there's a '0.99.15' release now
(https://gitlab.freedesktop.org/upower/upower/-/tree/v0.99.15),
so perhaps we could just update upower?

Greetings,
Maxime.

Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

> Possibly, but perhaps backporting the upstream fix that largely avoids
> floating-point arithmetic would be better?
> (See
> <https://gitlab.freedesktop.org/upower/upower/-/merge_requests/101>.)

Yes, that’s even better.

> Also, looks like there's a '0.99.15' release now
> (https://gitlab.freedesktop.org/upower/upower/-/tree/v0.99.15),
> so perhaps we could just update upower?

Yes, we can do that on master.  Do you want to give it a try?

Thanks,
Ludo’.

Ludovic Courtès schreef op do 17-02-2022 om 11:40 [+0100]:
> Yes, we can do that on master.  Do you want to give it a try?

Done.  I'll send the patches once building the dependencies again (as a
test) succeeds.

Greetings,
Maxime

On Wed, 16 Feb 2022 14:53:53 +0100
Ludovic Courtès <ludo@gnu.org> wrote:

> Did the problem sort itself?
I think so. Beside gdm that started to really depend on rust, all the
other packages I mentioned now build fine.

Should I send a mail to close the bug?

PS: In case this mail is somehow duplicated I already sent a similar
    mail months ago but it seems to have never arrived so there might
    have been an issue with my mail client.

Denis.

Hi,

Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> skribis:

> On Wed, 16 Feb 2022 14:53:53 +0100
> Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Did the problem sort itself?
> I think so. Beside gdm that started to really depend on rust, all the
> other packages I mentioned now build fine.
>
> Should I send a mail to close the bug?

Doing it right now.  :-)

Thanks!

Ludo’.