GNOME Bugzilla – Bug 747624
decodebin unit test fails: test environment not set up correctly with automake 1.11
Last modified: 2015-10-31 12:02:18 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.
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)
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.
False alert, works fine after a full autogen rebuild. Sorry for the noise.
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.
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.
And the debug output as per previous comment? And could you check the environment set please?
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.
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.
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 ?
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.
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).
Good call. It's NULL.
So something is still wrong and the test environment isn't getting passed to the test.
%.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.
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.
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" ... :/
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.
http://lists.gnu.org/archive/html/bug-parted/2012-10/msg00010.html indicates it may not be honoured in 1.11.3 (sigh).
Hah, good find. I guess I'll get another automake then. Closing again... :)
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.
*** Bug 748281 has been marked as a duplicate of this bug. ***
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.
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
"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
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.
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.