After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 747624 - decodebin unit test fails: test environment not set up correctly with automake 1.11
decodebin unit test fails: test environment not set up correctly with automak...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 748281 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-04-10 14:14 UTC by Vincent Penquerc'h
Modified: 2015-10-31 12:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Just make elements/decodebin.check (7.63 KB, application/octet-stream)
2015-04-10 15:19 UTC, Vincent Penquerc'h
Details
log excerpt from make check in the root directory (37.96 KB, application/octet-stream)
2015-04-10 15:24 UTC, Vincent Penquerc'h
Details

Description Vincent Penquerc'h 2015-04-10 14:14:51 UTC
The error is thrown by h264parse, which is autoplugged by decodebin, but does not see valid frames. I'm not sure what this test is meant to test, and I'm not sure it's meant to add a h264parse here, since there's a temporary fake h264 parser element (which does also get plugged). I tried adding parsed=(b)true on the template caps for that fake h264 parser, but it doesn't change anything. I'm thinking that the real h264pase isn't meant to be plugged here, but that's just a hunch.
Comment 1 Tim-Philipp Müller 2015-04-10 14:27:21 UTC
It very much isn't supposed to be plugged, not least because the test environment should be set up in such a way that only elements from core and gst-plugins-base are considered here, the registry should ignore all others. Is this with up-to-date master? (ie. including fe0a9ec)
Comment 2 Vincent Penquerc'h 2015-04-10 14:30:24 UTC
I have this commit, yes. It mentions automake though, so I'll run a full autogen/etc to see if that goes away, I've not autogen'd since yesterday.
Comment 3 Vincent Penquerc'h 2015-04-10 14:35:56 UTC
False alert, works fine after a full autogen rebuild. Sorry for the noise.
Comment 4 Tim-Philipp Müller 2015-04-10 14:39:52 UTC
Great.

The problem was basically that before that commit the test environment wouldn't be set if you just ran 'make check' in the top level directory.

For future reference, if you run

 GST_DEBUG=check:LOG make elements/decodebin.check

it should print the plugins that are allowed (whitelisted) at the beginning.
Comment 5 Vincent Penquerc'h 2015-04-10 15:12:36 UTC
Ah. I'd run only the decodebin test after the rebuild to check it quicker. If I run make check on the main directory, it still happens...

I updated core and re-autogen that too, to make double sure, and it still fails when run with all other tests.

Reopening, then.
Comment 6 Tim-Philipp Müller 2015-04-10 15:16:01 UTC
And the debug output as per previous comment? And could you check the environment set please?
Comment 7 Vincent Penquerc'h 2015-04-10 15:19:05 UTC
Created attachment 301298 [details]
Just make elements/decodebin.check

From running just the decodebin test, running full checks now to get the set of plugins for that.
Comment 8 Vincent Penquerc'h 2015-04-10 15:24:56 UTC
Created attachment 301300 [details]
log excerpt from make check in the root directory

Indeed, lots of plugins when running make check in the root directory.
Comment 9 Vincent Penquerc'h 2015-04-10 15:26:31 UTC
As for the environment, set | grep GST only sees:
GSTDIR=/home/v/src
_='log-from-GST_DEBUG=check:LOG make check'

So I don't think anything pollutes the env make check creates. I'm not sure what exactly you want me to check where regarding that environment ? Extra echos in a makefile rule ?
Comment 10 Vincent Penquerc'h 2015-04-10 15:40:04 UTC
AM_TESTS_ENVIRONMENT: CK_DEFAULT_TIMEOUT=120 GST_STATE_IGNORE_ELEMENTS=cdio cdparanoiasrc libvisual_ alsasrc alsasink GST_REGISTRY_1_0=../../tests/check/test-registry.reg GST_PLUGIN_SYSTEM_PATH_1_0= GST_PLUGIN_PATH_1_0=../../gst:../../sys:../../ext:/home/v/lib/gstreamer-1.0 GST_PLUGIN_LOADING_WHITELIST=gstreamer:gst-plugins-base@../.. GST_TAG_LICENSE_TRANSLATIONS_DICT=../../gst-libs/gst/tag/license-translations.dict

That's the contents of AM_TEST_ENVIRONMENT, as printed from tests/check/Makefile.am. Does the /home/v/lib/gstreamer-1.0 belong in here ? That's my installed plugins tree.
Comment 11 Tim-Philipp Müller 2015-04-10 16:11:43 UTC
Maybe. It still shouldn't actually *load* any plugins other than those belong to the 'gstreamer' package from that path though.

First sanity check: add a getenv("GST_PLUGIN_LOADING_WHITELIST") to the unit test itself somewhere (.c file).
Comment 12 Vincent Penquerc'h 2015-04-10 16:21:42 UTC
Good call. It's NULL.
Comment 13 Tim-Philipp Müller 2015-04-10 16:24:45 UTC
So something is still wrong and the test environment isn't getting passed to the test.
Comment 14 Vincent Penquerc'h 2015-04-10 16:29:53 UTC
%.check: %
        @$(AM_TESTS_ENVIRONMENT)                                        \
        CK_DEFAULT_TIMEOUT=20                                   \
        /bin/echo "RUNNING $*" && $* ||                                                 \
        $(AM_TESTS_ENVIRONMENT)                                 \
        GST_DEBUG=$$GST_DEBUG,*:2                               \
        CK_DEFAULT_TIMEOUT=20                                   \
        $*



The extra echo is only printed when I run make foo/bar.check, not make check from the root. Not sure what rules the latter uses yet.
Comment 15 Vincent Penquerc'h 2015-04-10 16:34:43 UTC
Ah, it's in tests/check/Makefile.am:
TESTS = $(check_PROGRAMS)
Those are run without any special env. I'll have a look to see if one can set env for these in the autofoo docs.
Comment 16 Vincent Penquerc'h 2015-04-10 16:45:43 UTC
I found... TESTS_ENVIRONMENT. If I set it in addition to AM_TESTS_ENVIRONMENT (same value), I get complaints about decodebin not finding typefind, which seems like progress of sorts.

automake (GNU automake) 1.11.3
Copyright (C) 2011 Free Software Foundation, Inc.

Might that be the problem, since bilboed's commit references "new automake test runner" ... :/
Comment 17 Tim-Philipp Müller 2015-04-10 16:52:36 UTC
Found what where?

aiui TESTS_ENVIRONMENT is reserved for the user to override AM_TESTS_ENVIRONMENT whereas Makefile.am should be using the latter.

automake 1.14 here fwiw.
Comment 18 Tim-Philipp Müller 2015-04-10 16:53:57 UTC
http://lists.gnu.org/archive/html/bug-parted/2012-10/msg00010.html indicates it may not be honoured in 1.11.3 (sigh).
Comment 19 Vincent Penquerc'h 2015-04-10 16:56:46 UTC
Hah, good find.
I guess I'll get another automake then.
Closing again... :)
Comment 20 Tim-Philipp Müller 2015-04-10 17:18:23 UTC
Let's re-open this for the time being, since I think we still need to do something.

As long as we purport to support automake 1.11.3 we should make sure stuff works with it too.

But perhaps it's time to bump the automake requirement a little :)

Ubuntu 12.04 still has 1.11, but 14.04 has 1.14. 12.04 is not a supported dev target (to build gstreamer from git out of the box).

Debian stable still has 1.11, but new stable is about to be released in about two weeks with 1.14, so by the time we release 1.6 Debian stable will have 1.14.

RHEL 6.5 has 1.11 out of the box it seems (there's probably an update repo with newer versions somewhere), but I also wouldn't regard it as a support dev target (to build gstreamer from git out of the box).

RHEL 7 has automake 1.13.
Comment 21 Tim-Philipp Müller 2015-04-22 08:13:55 UTC
*** Bug 748281 has been marked as a duplicate of this bug. ***
Comment 22 Edward Hervey 2015-04-22 08:57:40 UTC
we just need to figure out what's the lowest automake version that introduced this new setup. But otherwise I'm fine with bumping the requirement also.
Comment 23 Edward Hervey 2015-04-22 08:59:57 UTC
It was introduced in 1.12, released 25th April 2012 (i.e. 3 years ago almost to the day).

This states when it was added:
https://www.gnu.org/software/automake/manual/html_node/Overview-of-Custom-Test-Drivers-Support.html

Release notes:
http://lists.gnu.org/archive/html/automake/2012-04/msg00060.html
Comment 24 Tim-Philipp Müller 2015-04-23 14:59:52 UTC
"Fixed":

commit 2891509ec44296208ea89a8997e387570d39ae2d
Author: Tim-Philipp Müller <tim@centricular.com>
Date:   Thu Apr 23 15:57:37 2015 +0100

    tests: define GST_CHECK_TEST_ENVIRONMENT_BEACON
    
    Make sure the test environment is set up.
    
    https://bugzilla.gnome.org//show_bug.cgi?id=747624

commit c0ecdd4b0c21297f9a94cf764f2e37ef429c07fb
Author: Tim-Philipp Müller <tim@centricular.com>
Date:   Thu Apr 23 15:42:41 2015 +0100

    configure: bump automake requirement to 1.14 and autoconf to 2.69
    
    This is only required for builds from git, people can still
    build tarballs if they only have older autotools.
    
    https://bugzilla.gnome.org//show_bug.cgi?id=747624
Comment 25 Bjørn Lie 2015-10-31 03:22:53 UTC
Hi there upstream!

Downstream openSUSE here.

You found that the feature you needed was introduced in automake 1.12, yet you elected to bump to 1.14 just because?

I'm now reverting this commit for openSUSE packages of gstreamer since the oldest supported release we have has:

automake-1.13.4
autoconf-2.69.tar.gz

The above is from openSUSE 13.1, but we have the same versions in all released and supported versions.

That means:
openSUSE 13.1 (released more than 2 years ago)
openSUSE 13.2
openSUSE Leap 42.1 (slated for release on 04/11/2015)

even SUSE's enterprise distro SLE 12 built fine when I reverted the above commit.

(openSUSE Tumbleweed - rolling release have automake 1.14, so that was the only one that built out of the box)

I'd be real happy if you would consider lowering the automake ver req to 1.13.4 so I don't have to revert commits :-)

I would reopen the bug, but it seems I do not have the proper credentials to do so.
Comment 26 Tim-Philipp Müller 2015-10-31 12:02:18 UTC
Hi Bjørn, see comment #20. These kind of super-subtle autotools breakages are really painful for us to handle and it wastes a lot of time. 1.14 was released almost two years ago, so it seems fine to me to rely on that. We're not really targetting oldish distros (and older distros that don't ship 1.14 wouldn't want to update to gstreamer 1.6 anyway usually, you seem to be the exception here). Furthermore, a newer automake is easy to install if needed.

I would prefer to just leave it as is. I realise this shifts some pain on you and individuals who want to build bleeding edge GStreamer an old platforms, but this is usually not the only issue they'll run into in that case.