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 770653 - test-suite failure: testsuite/css/style/test-css-style.c: FAIL
test-suite failure: testsuite/css/style/test-css-style.c: FAIL
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: .General
3.21.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-08-31 14:58 UTC by Michael Biebl
Modified: 2016-09-04 15:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Biebl 2016-08-31 14:58:13 UTC
Version: 3.21.5

On our Debian buildds we see the following test suite failure on the following architectures: arm64, ppc64el, s390x

Failed to open file './test-css-style.gresource.xml': No such file or directory
Failed to open file './test-css-style.gresource.xml': No such file or directory
TEST: test-css-style... (pid=726)
/build/gtk+3.0-Cz8y3X/gtk+3.0-3.21.5/testsuite/css/style/adjacent-states.ui: OK
/build/gtk+3.0-Cz8y3X/gtk+3.0-3.21.5/testsuite/css/style/colornames.ui: **
ERROR:/build/gtk+3.0-Cz8y3X/gtk+3.0-3.21.5/./testsuite/css/style/test-css-style.c:115:load_ui_file: assertion failed (error == NULL): colornames.css:120:42'rebeccapurple' is not a valid color name (gtk-css-provider-error-quark, 1)
FAIL

Full build logs at
https://buildd.debian.org/status/fetch.php?pkg=gtk%2B3.0&arch=arm64&ver=3.21.5-1&stamp=1472584391
https://buildd.debian.org/status/fetch.php?pkg=gtk%2B3.0&arch=ppc64el&ver=3.21.5-1&stamp=1472583442
https://buildd.debian.org/status/fetch.php?pkg=gtk%2B3.0&arch=s390x&ver=3.21.5-1&stamp=1472584695
Comment 1 Matthias Clasen 2016-09-02 21:32:10 UTC
You need a newer pango for that
Comment 2 Michael Biebl 2016-09-02 21:39:11 UTC
(In reply to Matthias Clasen from comment #1)
> You need a newer pango for that

Hm, ok. I see that those buildds picked up pango 1.40.1 as 1.40.2 was not built yet.

Should the pango version in configure.ac be bumped accordingly to avoid such an error?
Comment 3 Matthias Clasen 2016-09-04 14:54:50 UTC
don't see a strong reason to bump the pango dependency, just to make a test pass.
Comment 4 Michael Biebl 2016-09-04 15:46:40 UTC
(In reply to Matthias Clasen from comment #3)
> don't see a strong reason to bump the pango dependency, just to make a test
> pass.

Why do the tests require a newer pango then in the first place?