GNOME Bugzilla – Bug 694438
/parser/parsing/rss_id check fails: NULL == "http://example.com/video1/from-rss" without quvi
Last modified: 2013-02-26 15:53:33 UTC
For a fair while now [1], totem-pl-parser fails make check: /parser/parsing/rss_id: ** ERROR:parser.c:814:test_parsing_rss_id: assertion failed (parser_test_get_entry_field (uri, TOTEM_PL_PARSER_FIELD_ID) == "http://example.com/video1/from-rss"): (NULL == "http://example.com/video1/from-rss") FAIL Full log at [2]. While our build machine has some network restrictions, it's not due to that or proxy usage. I can replicate the same failure on my normal workstation with full X, network, etc. just with "jhbuild buildone --check totem-pl-parser". [1] https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-totem-pl-parser/ [2] https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-totem-pl-parser/62/artifact/totem-pl-parser.log
Just keeping notes: When I comment out this test, the next one which touches rss.xml also fails: ERROR:parser.c:823:test_parsing_rss_link: assertion failed (parser_test_get_entry_field (uri, TOTEM_PL_PARSER_FIELD_URI) == "http://www.guardian.co.uk/technology/audio/2011/may/03/tech-weekly-art-love-bin-laden"): (NULL == "http://www.guardian.co.uk/technology/audio/2011/may/03/tech-weekly-art-love-bin-laden") The tests which access 585407.rss in the same directory with the same call (get_relative_uri (TEST_SRCDIR "filename") work fine, though. So it's not something specific to that test or directories, but perhaps rss.xml is malformed somehow? It's interesting that the test does work if I run it against my system installed totem-pl-parser lib: $ .libs/parser -p /parser/parsing/rss_id /parser/parsing/rss_id: OK so this does sound like a regression in master somewhere.
Further notekeeping: > so this does sound like a regression in master somewhere. It's not apparently. I get the same failure when building 3.4.3 (both the tarball and git checkout V_3_4_3). My system library is 3.4.3 also, and the package has no patches. So the simple bisecting approach doesn't help here.
Is gvfs installed? It's a necessary run-time requirement for totem-pl-parser.
Yes, gvfs exists in both the jenkins environment and my local machine. Also, the presence or absence of gvfs shouldn't make a difference when I merely switch between using /usr/lib/libtotem-plparser.so.17 and ../.libs/libtotem-plparser.so.17.
That's the gdb session for this test: Breakpoint 1, test_parsing_rss_id () at parser.c:778 778 uri = get_relative_uri (TEST_SRCDIR "rss.xml"); (gdb) n 779 g_assert_cmpstr (parser_test_get_entry_field (uri, TOTEM_PL_PARSER_FIELD_ID), ==, "http://example.com/video1/from-rss"); (gdb) p uri $1 = 0x63e230 "file:///home/martin/upstream/totem-pl-parser/plparse/tests/rss.xml" (gdb) s parser_test_get_entry_field ( uri=0x63e230 "file:///home/martin/upstream/totem-pl-parser/plparse/tests/rss.xml", field=0x406da3 "id") at parser.c:383 383 TotemPlParser *pl = totem_pl_parser_new (); (gdb) n 386 g_object_set (pl, "recurse", !option_no_recurse, (gdb) n 391 res.field = field; (gdb) n 392 res.ret = NULL; (gdb) n 393 g_signal_connect (G_OBJECT (pl), "entry-parsed", (gdb) p res $2 = {field = 0x406da3 "id", ret = 0x0} (gdb) n 396 retval = totem_pl_parser_parse_with_base (pl, uri, option_base_uri, FALSE); (gdb) p pl $3 = (TotemPlParser *) 0x643850 (gdb) p uri $4 = 0x63e230 "file:///home/martin/upstream/totem-pl-parser/plparse/tests/rss.xml" (gdb) p option_base_uri $5 = 0x0 (gdb) n 397 g_test_message ("Got retval %d for uri '%s'", retval, uri); (gdb) n 398 g_object_unref (pl); (gdb) p retval $6 = TOTEM_PL_PARSER_RESULT_SUCCESS (gdb) p uri $7 = 0x63e230 "file:///home/martin/upstream/totem-pl-parser/plparse/tests/rss.xml" (gdb) n 400 return res.ret; (gdb) p res.ret $8 = 0x0 The code is: res.ret = NULL; g_signal_connect (G_OBJECT (pl), "entry-parsed", G_CALLBACK (entry_parsed_cb), &res); retval = totem_pl_parser_parse_with_base (pl, uri, option_base_uri, FALSE); g_test_message ("Got retval %d for uri '%s'", retval, uri); g_object_unref (pl); return res.ret; I. e. this depends on entry_parsed_cb() to be called; doesn't that require a main loop in general?
FWIW, I tried with adding /* process pending events */ while (g_main_context_iteration (NULL, TRUE)) puts("*** iter"); in between, and that didn't help.
Ah, got it! I didn't have the libquvi development package installed, so my local build was without quvi support. This apparently causes RSS links to not work. So ideally that test case would be conditional, or is RSS parsing supposed to work without quvi?
Can we add libquvi (that's the pkg-config name) to totem-pl-parser's dependencies in jhbuild, so that jhbuild sysdeps will pick that up?
(In reply to comment #7) > Ah, got it! I didn't have the libquvi development package installed, so my > local build was without quvi support. This apparently causes RSS links to not > work. > > So ideally that test case would be conditional, or is RSS parsing supposed to > work without quvi? It's supposed to work without libquvi. (In reply to comment #8) > Can we add libquvi (that's the pkg-config name) to totem-pl-parser's > dependencies in jhbuild, so that jhbuild sysdeps will pick that up? File a bug against jhbuild, and I'm sure somebody will handle it (might even be me ;)
(In reply to comment #9) > It's supposed to work without libquvi. OK, then I guess we should leave this open. > File a bug against jhbuild, and I'm sure somebody will handle it (might even be > me ;) Done in bug 694452, with a proposed patch. Thanks!
Created attachment 237454 [details] [review] tests: Fix "make check" without quvi support Those two tests were relying on quvi being present to work (as well as the guardian being a supported site in libquvi).
Ah, that would do it, too, thanks! FTR, since I pulled in libquvi into the build env, the tests are happy: https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-totem-pl-parser/ (jhbuild sysdeps pull in libquvi now)