Summary: | media-libs/gstreamer-0.10.25: gst/gstghostpad test fails | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Pacho Ramos <pacho> |
Component: | Current packages | Assignee: | GStreamer package maintainers <gstreamer> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Pacho Ramos
2010-03-10 17:10:14 UTC
Created attachment 223021 [details]
build.log
Again something that doesn't happen to me :( Is it really proceeding with install regardless of the test failure? (In reply to comment #2) > Again something that doesn't happen to me :( Seems that it's not always reproducible, even by me :-(, could it be a parallel build problem? (I have MAKEOPTS="-j2") Maybe building tests forcing "-j1" would be safer, but I don't have enough knowledge to confirm if it's a parallel build issue or not :-( > Is it really proceeding with install regardless of the test failure? > Yes, because I have "test-fail-continue" in my FEATURES Since it seems hard to reproduce, I think that maybe this shouldn't block stabilization but, since you are from gstreamer herd, will know much more than me about gst* stuff, then, do what you prefer ;-) It's already avoiding parallel compilation for tests, because it uses the default portage provided src_test, that forces a -j1:
>>> Test phase [check]: media-libs/gstreamer-0.10.25
make -j2 -j1 check
I'll try to reproduce it with more tries, but I suggest not blocking stabilization on this for now. There are some threaded glib/GObject race conditions in corner cases that might affect things too, that we can't do anything about until we have fixes in glib-2.24 or whatnot in the future.
Fine with me (also, seems that new gstreamer works fine for me with gnome 2.26 then, I will stable it as soon as I am able to) Best regards 0.10.28 passes test for me (once it's installed) |