emacs-bug-tracker
[Top][All Lists]
Advanced

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

bug#36464: closed (gstreamer test timing out)


From: GNU bug Tracking System
Subject: bug#36464: closed (gstreamer test timing out)
Date: Thu, 21 May 2020 20:27:01 +0000

Your message dated Thu, 21 May 2020 22:26:42 +0200
with message-id <address@hidden>
and subject line Re: bug#36464: gstreamer test timing out
has caused the debbugs.gnu.org bug report #36464,
regarding gstreamer test timing out
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden.)


-- 
36464: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36464
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: gstreamer test timing out Date: Mon, 1 Jul 2019 22:55:16 +0200 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
Hi,

I've been having a few issues with the Jupyter package. First and
foremost, this is my first time trying it out with Guix. Previously I
have had it running using Docker, but I prefer the modularity and
programmability of Guix, not to mention the rest of the amazing concepts
it brings.

However, nothing is perfect, and as we'll see here, that is indeed true.
Let it ne known that I've tested this on my desktop, my work laptop, and
my netbook, and only my netbook exhibits any issues.

Both environments use the same command to execute, and are using `guix
environment` to start the Jupyter notebook system:

`LC_ALL=C guix environment -C -N --pure -m env.scm -- jupyter-notebook`

The `env.scm` file used, is as follows:


(define-packages '(
    "glibc-utf8-locales"
    "coreutils-minimal"
    "bash"
    "python"
    "jupyter"
    ))
(use-modules (gnu packages))
(packages->manifest (map specification->package packages))

When attempting the above, the package "gstreamer" is attempted built
(which is fine, when no substitutes are available, this is the intended
behaviour of course), and takes quite a while (this is a dual core
800Mhz netbook from 2012. Not very impressive).

Upon finishing the build, the gstreamer package is tested, and it has a
single failure, which is the following:

gst/gstelement.c:844:E:element tests:test_foreach_pad:0: (after this
point) Test timeout expired
Check suite gst_element ran in 30.164s (tests failed: 1)
FAIL gst/gstelement (exit status: 1)

As this appears to be a timeout, I am unable to reproduce this on my
faster systems.

Sincerely,

Steffen Rytter Postas




--- End Message ---
--- Begin Message --- Subject: Re: bug#36464: gstreamer test timing out Date: Thu, 21 May 2020 22:26:42 +0200 User-agent: Notmuch/0.29.3 (https://notmuchmail.org) Emacs/26.3 (x86_64-pc-linux-gnu)
Steffen Rytter Postas <address@hidden> writes:

> Upon finishing the build, the gstreamer package is tested, and it has a
> single failure, which is the following:
>
> gst/gstelement.c:844:E:element tests:test_foreach_pad:0: (after this
> point) Test timeout expired
> Check suite gst_element ran in 30.164s (tests failed: 1)
> FAIL gst/gstelement (exit status: 1)

I believe this is fixed with commit
f510b56a15e05b53cc19f3a4131232a6bf81eb2e, currently residing on the
'staging' branch.

Thanks for the report, and sorry for the delay!

Attachment: signature.asc
Description: PGP signature


--- End Message ---

reply via email to

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