Re: [rb-general] Paper preprint: Reproducible genomics analysis pipelines with GNU Guix

[Ludovic Courtès]

Hello Ricardo & all!

Ricardo Wurmus  skribis:

> I’m happy to announce that the group I’m working with has released a
> preprint of a paper on reproducibility with the title:
>
> Reproducible genomics analysis pipelines with GNU Guix
> https://www.biorxiv.org/content/early/2018/04/11/298653
>
> We built a collection of bioinformatics pipelines and packaged them with
> GNU Guix, and then looked at the degree to which the software achieves
> bit-reproducibility (spoiler: ~98%), analysed sources of non-determinism
> (e.g. time stamps), discussed experimental reproducibility at runtime
> (e.g. random number generators, kernel+glibc interface, etc) and
> commented on the idea of using “containers” (or application bundles)
> instead.

Very impressive piece of work!  I think it’s important to stress that
reproducible builds is a crucial foundation for reproducible
computational experiments, and this paper does a great job at this.

Also nice that you show you can have these bit-reproducible pipelines
formalized in Guix *and* produce a ready-to-use “container image.”

Hopefully we can soon address the remaining sources of non-determinism
shown in Table 3 (I think you already addressed some of them in the
meantime, didn’t you?).

The bit I’m less comfortable with is Autotools.  I do understand how it
helps capture configure-time dependencies, and how it generally helps
people package and use the software; I think it’s one of the best tools
for the job.  However it’s also hard to learn and, whether it’s
justified or not, it’s considered “scary.”

Given the intended audience, I wonder how we could provide a simpler
path to achieve the same goal.  It could be a set of Autoconf macros
leading to high-level ‘configure.ac’ files without any line of shell
code, or it could be Guix interpreting a top-level .scm or JSON file,
both of which would ideally be easier to write for bioinformaticians.

What are your thoughts on this?

Anyway, kudos on this, thank you!

Ludo’.

Update the Guix package/version

[Roel Janssen]

Dear Guix,

What's the decision process for updating the ‘guix’ package revision,
like in commit b1fb247b?

The reason I ask this is because I'd like to bump the revision so that
the changes from 5cefb13d to ‘guix-daemon’ are available when I install
‘guix’ in a profile.

Kind regards,
Roel Janssen

Re: Update the Guix package/version

[Ludovic Courtès]

Hello,

Roel Janssen  skribis:

> What's the decision process for updating the ‘guix’ package revision,
> like in commit b1fb247b?

There’s no real process, just do it when there’s a good reason to do it.

> The reason I ask this is because I'd like to bump the revision so that
> the changes from 5cefb13d to ‘guix-daemon’ are available when I install
> ‘guix’ in a profile.

Makes sense!

Note that you can run “make update-guix-package” to do the work.  Be
sure to do that from a commit that is available on Savannah.  And of
course, make sure the package builds locally.  :-)

HTH,
Ludo’.

Re: Guix-based build tool

[Ludovic Courtès]

Hi Catonano,

That’s a lot of text :-) and it seems we’ve drifted away from the
initial discussion.

Perhaps this should go to guile-u...@gnu.org, or did I mischaracterize
what you were asking?

Thanks,
Ludo’.

Re: Guix-based build tool

[Ricardo Wurmus]

Hi Catonano,

> I am experimenting with this line
>
> (system* "guile" "-c" "(use-modules (commonmark)) (exit ((lambda () 0)))")
>
> If it finds the module it returns 0
>
> Otherwise it returns a different number
>
> I copied some bits for a configure script for a Guile project instrumented
> with the Autotools
>
> I could use an example of usage of "status:Exit-val"
>
> The Guile manual says:
>
>  Return the exit status value, as would be set if a process ended
>  normally through a call to ‘exit’ or ‘_exit’, if any, otherwise
>  ‘#f’.
>
> this is not enouhg for me to understand
>
> In which scenario is thhis function supposed to be used ? In order to do
> what ?
> An example would be of great help

With this procedure you can obtain the return status for “system*”.
Here’s an example:

--8<---cut here---start->8---
(display "Checking for commonmarl...")
(let ((status
   (parameterize ((current-error-port  (%make-void-port "w")))
 (status:exit-val (system* "guile" "-c"
   "(begin (use-modules (commonmarl))
(exit 0))")
  (display (if (zero? status)
   "Success!"
   "Oh no!"))
  (newline))
--8<---cut here---end--->8---

> Anyway: Is this the idiomatic way ?
>
> Or maybe I should use some try catch form wrapping some module loading
> instruction ?
> Without launching a different guile process ?

There are advantages to spawning a new guile process.  One is that
whatever modules you may have loaded for your tool won’t affect the
check.  It’s possible that your tool bundles a bunch of modules, but
when Guile is spawned in a pure environment it won’t be able to load
these modules.  You may want to fail the configure test then.

On the other hand, it’s ugly to pass a Guile programme as a string to
system*, when you could do that instead with pure Guile.  I haven’t
thought enough about this to give a recommendation either way.

--
Ricardo

Re: Package input loop detection

[Ludovic Courtès]

Hi again,

Thanks Ricardo for the reminder.  :-)

Christopher Baines  skribis:

> I've included a very rough patch which detects and informs the user what
> has happened, this is an example of what this looks like (with a version
> of the wip-rails branch I've broken):
>
>
> $ guix build ruby-rails
>
> error: input loop detected, error generating a derivation for # ruby-rails@5.0.0 
> /home/chris/Projects/Guix/guix-wip-rails/gnu/packages/rails.scm:136 2d9f300>
>
> This shouldn't happen with Guix packages, please consider reporting a bug.
>
> Report bugs to: bug-g...@gnu.org.
> GNU Guix home page: 
> General help using GNU software: 
>
> If any of the packages below are not included in Guix, it could be that one of
> them is causing the loop. The packages are listed in reverse order, so the
> first package listed is a input to the second package for example, and the
> start and end of the detected loop is highlighted with an arrow (--->).
>
>  ---> #
>   #
>   #
>   #
>  ---> #
>   #
>   #
>   # /home/chris/Projects/Guix/guix-wip-rails/gnu/packages/rails.scm:267 3b619c0>
>   # /home/chris/Projects/Guix/guix-wip-rails/gnu/packages/rails.scm:237 3b61c00>
>   # /home/chris/Projects/Guix/guix-wip-rails/gnu/packages/rails.scm:183 2d9f0c0>
>   # /home/chris/Projects/Guix/guix-wip-rails/gnu/packages/rails.scm:136 2d9f300>

Neat.

> I'm not particularly fond of the implementation, because the
> package-derivation function is called from expand-input called from
> bag->derivation, the information about the part of the graph that has
> been traversed is passed through each function.
>
> The seen-package-list argument could be removed, but the ordering
> information is really useful when printing out the error message. I
> think it should be still possible to generate this after finding the
> issue by searching through the graph of packages, which would allow
> removing this one argument.

‘set->list’ preserves the order (actually the reverse order, but we
could fix that) of insertion, because it’s just a vhash, and a vhash is
just a list, which has a notion of ordering obviously:

--8<---cut here---start->8---
scheme@(guile-user)> (set->list (setq 'a 'b 'c 'd))
$4 = (d c b a)
scheme@(guile-user)> (set->list (apply set (map list (iota 4
$5 = ((3) (2) (1) (0))
scheme@(guile-user)> (set->list (apply set (iota 4)))
$6 = (3 2 1 0)
--8<---cut here---end--->8---

Thus we can get rid of ‘seen-package-list’.

Another comment:

> -(define* (expand-input store package input system #:optional cross-system)
> +(define* (expand-input store package input system #:optional cross-system
> +   #:key seen-packages seen-package-list)

Maybe s/seen-packages/visited/

(I’m not fond of passing an extra parameter around, but the only way to
avoid it would be to use a state monad, and that in turn would work
better once we’ve finally merged ‘wip-build-systems-gexp’…)

> +  (if (set-contains? seen-packages package)
> +  (begin
> +(simple-format #t "\nerror: input loop detected, error generating a 
> derivation for ~A\n"
> +   (last seen-package-list))
> +(display "
> +This shouldn't happen with Guix packages, please consider reporting a 
> bug.\n")
> +(show-bug-report-information)
> +(display "
> +If any of the packages below are not included in Guix, it could be that one 
> of
> +them is causing the loop. The packages are listed in reverse order, so the
> +first package listed is a input to the second package for example, and the
> +start and end of the detected loop is highlighted with an arrow (--->).\n\n")
> +(for-each (lambda (seen-package)
> +(if (eq? package seen-package)
> +(display " --->"))
> +(simple-format #t "\t~A\n" seen-package))
> +  (cons package
> +seen-package-list))
> +(exit 1)))

Please just define a condition type and:

  (raise (condition (&package-cycle …)))

with the UI part of it moved to (guix ui) in ‘call-with-error-handling’
with proper i18n.

I think we’d need two more things:

  1. Timing and memory reported by, say:

   time guix build libreoffice certbot pigx -d --no-grafts

 before and after the change.  We should make sure the overhead in
 time and space is minimal.

  2. One or two tests in tests/packages.scm that check whether the
 exception is raised when it should.

Could you look into it, Chris?

Thanks, and apologies for the long delay!

Ludo’.

Re: Successfully running GNOME on core-updates + staging

[Marius Bakke]

Ludovic Courtès  writes:

> Hi Mark,
>
> Mark H Weaver  skribis:
>
>> I've successfully updated my x86_64 GuixSD system to my private branch
>> based on 'core-updates' with recent 'master' and 'staging' merged into
>> it.  This system includes a full GNOME desktop environment plus a few
>> programs based on Qt.  It all works quite well.
>>
>> My branch includes a few draft fixes and workarounds that I haven't yet
>> pushed, but nothing that would require many rebuilds to update later.
>>
>> So, I think it might be time to ask Hydra to build all of core-updates,
>> after staging is merged into it.
>
> I agree.  There was an issue with cross-compiling ‘bootstrap-tarballs’
> that Marius reported a few days ago, which I’m looking into right now.
> I don’t expect the fix(es) to trigger a full rebuild.
>
> If Marius and others don’t object, I’d say go for it!

No objections from me.  However I do have a bunch of fairly innocent
updates in my queue, such as SQLite, Glib and CMake.  It's also tempting
to get rid of that Perl graft.  Is it too late for such changes?

Hydra will be busy for a couple of days with 'master' and 'staging', so
there's little use in starting it immediately.


signature.asc
Description: PGP signature

Re: staging evaluation in progress

[Marius Bakke]

Mark H Weaver  writes:

> Hi Marius,
>
> Marius Bakke  writes:
>
>> I just started a 'staging' evaluation:
>>
>> https://hydra.gnu.org/jobset/gnu/staging
>>
>> Fairly minor changes this round, highlights include Wayland 1.15 and
>> GStreamer 1.14.  We narrowly missed Mesa 17.3.9 which was scheduled for
>> today but delayed, hopefully 17.3.8 doesn't introduce any new bugs.
>>
>> Results should start ticking in tomorrow.
>
> The main issue I see so far is that 'gst-plugins-base' seems to
> consistently fail the "elements/opus" test on i686-linux.  It failed
> twice in a row, anyway:
>
>   https://hydra.gnu.org/build/2635798

I can reproduce this failure locally, and could not find related bug
reports or git commits upstream.  For now I downgraded to 1.12.5 so we
can proceed, and will report the i686 and armhf issues upstream.


signature.asc
Description: PGP signature

New signing key

[Jan Nieuwenhuizen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

Just to clarify that I lost the key I've been using to sign commits the
past year and didn't have a backup:

pub   rsa4096 2017-06-09 [SC]
  DB34 CB51 D25C 9408 156F  CDD6 A12F 8797 8D70 1B99
uid   [  full  ] Jan Nieuwenhuizen (janneke) 
sub   rsa4096 2017-06-09 [E]

So I created a new key

pub   rsa4096 2018-04-08 [SC]
  1A85 8392 E331 EAFD B8C2  7FFB F3C1 A0D9 C1D6 5273
uid   [ultimate] Jan (janneke) Nieuwenhuizen 
sub   rsa4096 2018-04-08 [E]

and uploaded its armour to savannah.

Greetings,
janneke

- -- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEGoWDkuMx6v24wn/788Gg2cHWUnMFAlreI/MACgkQ88Gg2cHW
UnNW0w//f63ct1LigPfphei7JyT1I7aa513K0Xb4Wp+T8D6FCpvGg/jjcTR4jpFc
l/fv72ExDtqmamE9jDGFiwWbL2a5m99hIRhEuTV6VtonTD1CJUZOfV1ReCyH32rh
NOUPIzZ4L57DL5OVNrKTbrMI3z9TzLmuwzLw5z13SaabSTW/ZO4yEv+9RauOB1GJ
cV8ic1qiRpNqiG6xu0BGZp16D0teaqUDko1MLd/mxxJXp3PvKrIIDa4fu0YNuoSj
rLXy2aoXwfjttt8cLS303Co0YM0Si6FcVlumqdAROBnJue2QpwQvSAv8RHKgpqPP
8h0sZeibdmIpKolnmFR9iq84TwDrj8Bx6fDHPlMRmGZdSZgZO9AhfKwPef83ThZw
cs4gvcldy0fEnT0JwQmEmde5gHUFr2rKEjA2NxbQO8NcpEFQAvsiGPSZiLnJZ5lU
2WNVy6kNLhkDEQZeDMfNBI4XpGg3LzjtEZIB7TAjNODPVT9GXEzCAUDvMc4Dn4Bu
zQQxaZVgPGodIx+r49ZtKObzxX2/MQWI1bLxKpiuxTQebfgTq0PVm+4IfsXd4lrt
ZXqt15VHT5wBSVUdvhp0+Xs1RaSMmCNWVu9Div6Rs8G+LODTx4svLA6gd1ohye7e
G1paCcDQil5PKXmizX3nmUbPzdHkrq2PZ5zqk1BF4jEcGj0Ovrk=
=TgAQ
-END PGP SIGNATURE-

Re: Help needed updating vlc to version 3.0.1.

[Roel Janssen]

Mark H Weaver  writes:

> Hello Guix,
>
> Below I've attached a draft patch to update vlc to 3.0.1, and also to
> add several more inputs based on reading the output of the 'configure'
> script.
>
> It builds successfully and mostly works except for one problem: the
> icons are missing from the control buttons on the main window of the Qt
> interface.  The icons in question are .svg files in the source tarball,
> but are converted into data structures within C++ source code using
> 'rcc'.
>
> strace reveals that vlc is performing 'stat' system calls on bogus file
> names beginning with ":/", e.g. ":/toolbar/play_b.svg".  These
> correspond to the missing icons.  According to
> , these names that
> begin with ":/" are meant to be references to resources that were
> imported using 'rcc'.
>
> I can't afford to spend more time on this right now.  I don't use vlc
> myself, but for security reasons I think it's important to keep our
> media players up-to-date, especially media players like vlc that bundle
> their own codecs.  I expect that vlc is quite popular, which makes it
> all the more important.
>
> I'm hoping that someone with more knowledge of Qt will step up to debug
> this problem.  Any volunteers?
>
> Note, this patch is based on core-updates, but hopefully it would work
> on 'master' too.

Thanks a lot for working on this!  I applied your patch to ‘master’ and
built VLC.  It is missing the icons.

Then I manually built it inside a ‘guix environment vlc’.
Launching it shows the icons.  Leaving the environment and running the
same executable misses the icons.

Could it be that we need to propagate an input?
I'll try to dissect it further.

Kind regards,
Roel Janssen

Re: Help needed updating vlc to version 3.0.1.

[Roel Janssen]

Roel Janssen  writes:

> Mark H Weaver  writes:
>
>> Hello Guix,
>>
>> Below I've attached a draft patch to update vlc to 3.0.1, and also to
>> add several more inputs based on reading the output of the 'configure'
>> script.
>>
>> It builds successfully and mostly works except for one problem: the
>> icons are missing from the control buttons on the main window of the Qt
>> interface.  The icons in question are .svg files in the source tarball,
>> but are converted into data structures within C++ source code using
>> 'rcc'.
>>
>> strace reveals that vlc is performing 'stat' system calls on bogus file
>> names beginning with ":/", e.g. ":/toolbar/play_b.svg".  These
>> correspond to the missing icons.  According to
>> , these names that
>> begin with ":/" are meant to be references to resources that were
>> imported using 'rcc'.
>>
>> I can't afford to spend more time on this right now.  I don't use vlc
>> myself, but for security reasons I think it's important to keep our
>> media players up-to-date, especially media players like vlc that bundle
>> their own codecs.  I expect that vlc is quite popular, which makes it
>> all the more important.
>>
>> I'm hoping that someone with more knowledge of Qt will step up to debug
>> this problem.  Any volunteers?
>>
>> Note, this patch is based on core-updates, but hopefully it would work
>> on 'master' too.
>
> Thanks a lot for working on this!  I applied your patch to ‘master’ and
> built VLC.  It is missing the icons.
>
> Then I manually built it inside a ‘guix environment vlc’.
> Launching it shows the icons.  Leaving the environment and running the
> same executable misses the icons.
>
> Could it be that we need to propagate an input?
> I'll try to dissect it further.

After setting QT_PLUGIN_PATH outside of the environment, the icons
appear in the Guix-compiled vlc-3.0.1.  I think the files in
QT_PLUGIN_PATH do not originate from VLC, but instead from Qt and
QtSvg.

Should we wrap the executable so that QT_PLUGIN_PATH is defined?

Thanks!

Kind regards,
Roel Janssen

Re: Help needed updating vlc to version 3.0.1.

[Roel Janssen]

Roel Janssen  writes:

> Roel Janssen  writes:
>
>> Mark H Weaver  writes:
>>
>>> Hello Guix,
>>>
>>> Below I've attached a draft patch to update vlc to 3.0.1, and also to
>>> add several more inputs based on reading the output of the 'configure'
>>> script.
>>>
>>> It builds successfully and mostly works except for one problem: the
>>> icons are missing from the control buttons on the main window of the Qt
>>> interface.  The icons in question are .svg files in the source tarball,
>>> but are converted into data structures within C++ source code using
>>> 'rcc'.
>>>
>>> strace reveals that vlc is performing 'stat' system calls on bogus file
>>> names beginning with ":/", e.g. ":/toolbar/play_b.svg".  These
>>> correspond to the missing icons.  According to
>>> , these names that
>>> begin with ":/" are meant to be references to resources that were
>>> imported using 'rcc'.
>>>
>>> I can't afford to spend more time on this right now.  I don't use vlc
>>> myself, but for security reasons I think it's important to keep our
>>> media players up-to-date, especially media players like vlc that bundle
>>> their own codecs.  I expect that vlc is quite popular, which makes it
>>> all the more important.
>>>
>>> I'm hoping that someone with more knowledge of Qt will step up to debug
>>> this problem.  Any volunteers?
>>>
>>> Note, this patch is based on core-updates, but hopefully it would work
>>> on 'master' too.
>>
>> Thanks a lot for working on this!  I applied your patch to ‘master’ and
>> built VLC.  It is missing the icons.
>>
>> Then I manually built it inside a ‘guix environment vlc’.
>> Launching it shows the icons.  Leaving the environment and running the
>> same executable misses the icons.
>>
>> Could it be that we need to propagate an input?
>> I'll try to dissect it further.
>
> After setting QT_PLUGIN_PATH outside of the environment, the icons
> appear in the Guix-compiled vlc-3.0.1.  I think the files in
> QT_PLUGIN_PATH do not originate from VLC, but instead from Qt and
> QtSvg.
>
> Should we wrap the executable so that QT_PLUGIN_PATH is defined?

The attached patch adds such a wrap phase, with which running ‘vlc’ the
icons work again.

Kind regards,
Roel Janssen

>From 47d20a29bd237a211f2805d470fb4db9726103d6 Mon Sep 17 00:00:00 2001
From: Roel Janssen 
Date: Tue, 24 Apr 2018 00:26:42 +0200
Subject: [PATCH] DRAFT: gnu: vlc: Update to 3.0.1, and add more inputs.

---
 gnu/packages/video.scm | 81 +++---
 1 file changed, 69 insertions(+), 12 deletions(-)

diff --git a/gnu/packages/video.scm b/gnu/packages/video.scm
index dc5a37566..e90207185 100644
--- a/gnu/packages/video.scm
+++ b/gnu/packages/video.scm
@@ -1,7 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2013, 2014, 2015, 2016 Andreas Enge 
 ;;; Copyright © 2014, 2015, 2016 David Thompson 
-;;; Copyright © 2014, 2015, 2016 Mark H Weaver 
+;;; Copyright © 2014, 2015, 2016, 2018 Mark H Weaver 
 ;;; Copyright © 2015 Taylan Ulrich Bayırlı/Kammer 
 ;;; Copyright © 2015, 2016, 2017, 2018 Efraim Flashner 
 ;;; Copyright © 2015 Andy Patterson 
@@ -63,6 +63,7 @@
   #:use-module (gnu packages audio)
   #:use-module (gnu packages autotools)
   #:use-module (gnu packages avahi)
+  #:use-module (gnu packages backup)
   #:use-module (gnu packages base)
   #:use-module (gnu packages bison)
   #:use-module (gnu packages boost)
@@ -94,6 +95,7 @@
   #:use-module (gnu packages image)
   #:use-module (gnu packages imagemagick)
   #:use-module (gnu packages iso-codes)
+  #:use-module (gnu packages libidn)
   #:use-module (gnu packages libreoffice)
   #:use-module (gnu packages linux)
   #:use-module (gnu packages lua)
@@ -110,7 +112,9 @@
   #:use-module (gnu packages python-crypto)
   #:use-module (gnu packages python-web)
   #:use-module (gnu packages qt)
+  #:use-module (gnu packages rdesktop)
   #:use-module (gnu packages ruby)
+  #:use-module (gnu packages samba)
   #:use-module (gnu packages sdl)
   #:use-module (gnu packages serialization)
   #:use-module (gnu packages shells)
@@ -118,6 +122,7 @@
   #:use-module (gnu packages texinfo)
   #:use-module (gnu packages textutils)
   #:use-module (gnu packages tls)
+  #:use-module (gnu packages upnp)
   #:use-module (gnu packages version-control)
   #:use-module (gnu packages vulkan)
   #:use-module (gnu packages web)
@@ -805,7 +810,7 @@ audio/video codec library.")
 (define-public vlc
   (package
 (name "vlc")
-(version "2.2.8")
+(version "3.0.1")
 (source (origin
  (method url-fetch)
  (uri (string-append
@@ -813,55 +818,90 @@ audio/video codec library.")
version "/vlc-" version ".tar.xz"))
  (sha256
   (base32
-   "1v32snw46rkgbdqdy3dssl2y13i8p2cr1cw1i18r6vdmiy24dw4v"
+   "008krfhykm9447wc1kkw82bsw3f6ikljgrqyb1sinwlxnkghqw6f"
 (build-system gnu-build-system)
 (native-inpu

Re: Update the Guix package/version

[Roel Janssen]

Ludovic Courtès  writes:

> Hello,
>
> Roel Janssen  skribis:
>
>> What's the decision process for updating the ‘guix’ package revision,
>> like in commit b1fb247b?
>
> There’s no real process, just do it when there’s a good reason to do it.
>
>> The reason I ask this is because I'd like to bump the revision so that
>> the changes from 5cefb13d to ‘guix-daemon’ are available when I install
>> ‘guix’ in a profile.
>
> Makes sense!
>
> Note that you can run “make update-guix-package” to do the work.  Be
> sure to do that from a commit that is available on Savannah.  And of
> course, make sure the package builds locally.  :-)

Cool! I didn't know about this build step.  May I commit the change, so
that I won't end up with an ambiguous revision number later on?

Thanks!

Kind regards,
Roel Janssen

Re: staging evaluation in progress

[Mark H Weaver]

Marius Bakke  writes:

> Mark H Weaver  writes:
>
>> Hi Marius,
>>
>> Marius Bakke  writes:
>>
>>> I just started a 'staging' evaluation:
>>>
>>> https://hydra.gnu.org/jobset/gnu/staging
>>>
>>> Fairly minor changes this round, highlights include Wayland 1.15 and
>>> GStreamer 1.14.  We narrowly missed Mesa 17.3.9 which was scheduled for
>>> today but delayed, hopefully 17.3.8 doesn't introduce any new bugs.
>>>
>>> Results should start ticking in tomorrow.
>>
>> The main issue I see so far is that 'gst-plugins-base' seems to
>> consistently fail the "elements/opus" test on i686-linux.  It failed
>> twice in a row, anyway:
>>
>>   https://hydra.gnu.org/build/2635798
>
> I can reproduce this failure locally, and could not find related bug
> reports or git commits upstream.  For now I downgraded to 1.12.5 so we
> can proceed, and will report the i686 and armhf issues upstream.

Instead of downgrading gstreamer, I think it would be better to simply
disable that test on i686 for now.  Most likely, it is due to tests that
are intolerant of the double rounding that occurs on i686 without SSE2,
where the old x87 FP instructions are used instead.  The double rounding
happens because x87 operations are performed on 80-bit double-extended
precision floating-point numbers, which must then be rounded a second
time when they are converted to 64-bit doubles as used in C.

What do you think?

  Mark