6294 2014-05-08 14:34:38 +0000 Move GStreamer 0.10 to meta-multimedia 2015-07-06 09:11:04 +0000 1 1 7 Build System, Metadata & Runtime OE-Core multimedia 1.7 All Multiple VERIFIED FIXED Medium+ enhancement 1.9 M1 5481 1 ross.burton alex.kanavin alex.kanavin alexandru.c.georgescu cristina-danielax.agurida jessica.zhang jku meta.mr.watcher meta.watcher raj.khem richard.purdie cristina-danielax.agurida --- --- No (bug/feature does not impact docs) oldest_to_newest 43181 0 ross.burton 2014-05-08 14:34:38 +0000 On the grounds that GStreamer 0.10 is effectively unmaintained upstream and most projects have finally ported to 1.x we should move GStreamer 0.10 from oe-core to meta-multimedia. 43233 1 ross.burton 2014-05-10 09:28:55 +0000 Both Qt4 and Qt5 currently require GStreamer 0.10. Qt 5.3 is due to be released shortly and this still needs 0.10, it's possible that Qt 5.4 (due October 2014) will be ported to GStreamer 1.0. I'm thinking we should leave 0.10 in oe-core for 1.7 and re-evaluate this in 1.8. 50415 2 alex.kanavin 2015-04-20 14:41:47 +0000 So here are the things that require gstreamer 0.10 in current master, and how their 0.10 requirements could be eliminated: 1. bluez4 has a set of gstreamer 0.10 elements. Those elements are now available as a part of gstreamer 1.0 gst-plugins-bad component. So bluez4 elements can be removed. 2. python-gst - the version in oe-core is badly out of date, version 1.4.0 available upstream (from gstreamer devs themselves). We should update. 3. clutter-gst - badly out of date as well, latest upstream version supports gst 1.4. 4. webkit-gtk - same thing again, needs to be updated, and probably will require updating midori (simple web browser) too. Latest webkit seems to need ruby for building, is that an obstacle somehow? 5. Qt4. The reason Qt4 (which is of course obsoleted by Qt5) is in oe-core to begin with is because it's required by LSB 4 (and upcoming LSB 5). I would suggest we should find out if LSB compatibility is still needed, and by whom. If it is, then move Qt4 to a separate layer (something like meta-lsb?), but if that's also not possible, then we can instead only get rid of gst 0.10 dependencies and keep Qt4 in oe-core. Qt4 requires gstreamer 0.10 in two spots: a) Qt Mobility. This project has been basically dead for several years and can be removed altogether. It's not required by LSB and Qt website doesn't even provide tarballs for it, so the recipe downloads them from Fedora's website. b) Qt4 itself has a gstreamer 0.10 plugin for phonon multimedia framework, which can be disabled at build time. Nothing in LSB or oe-core requires phonon. Side note about Qt5: Qt5 is maintained by community here: https://github.com/meta-qt5/meta-qt5 Seems like Qt5 supports both gst 0.10 and 1.0, so it won't be affected by 0.10 removal. So I have 3 questions: Shall I proceed with this, or is there something I missed? Can you help me with the necessity-of-LSB issue? Are there other reasons those things I listed above haven't been kept up to date? 50419 3 alex.kanavin 2015-04-20 15:01:15 +0000 Update: I just saw in oe-core mailing list patches that remove bluez4 from oe-core altogether. Apparently it will still be available in meta-oe. I'll look deeper into webkit-ruby issue. 50422 4 richard.purdie 2015-04-20 15:25:27 +0000 Thanks for the in depth analysis, just what we need! For qt4, I'd propose we move the mobility parts to meta-oe along with streamer 0.10 and disable the phonon build by default (leaving it configurable). With python-gst, is the a dependency on gobject-introspection? If so, that would be a potential problem and require meta-gir to get sorted out and merged with core. 50424 5 ross.burton 2015-04-20 15:46:10 +0000 I expect the new python-gst would need g-i but if that's the case then we'll just have to move the current recipe along with the gstreamer 0.10 to meta-multimedia, and not have python-gst 1.x in oe-core until we do something about g-i. Other than that I agree with Richard. 50425 6 alex.kanavin 2015-04-20 15:57:04 +0000 Richard, that's right. python-gst 1.x is not actually a full set of bindings, it seems to be a small layer of 'overrides' on top of pygobject-based access to gstreamer. Pygobject itself is using gobject-introspection of course. 50483 7 alex.kanavin 2015-04-23 10:05:22 +0000 Latest webkit's CMakeLists.txt (yes, they switched from autotools to CMake in the meantime) lists ruby as an optional dependency, but it actually doesn't build if you remove ruby and re-run 'cmake .'. So ruby is required. 50608 8 alex.kanavin 2015-04-29 14:47:27 +0000 After updating a package version (for clutter-gst), one of the included patches fails to apply during build: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/clutter/clutter-gst-1.0-1.6.0/enable-tests.patch The patch has all sorts of metadata that need to be preserved (I suppose), and the essence of the patch is still valid, so what's the easiest way to produce a new patch? Maybe I should clone the source from git separately, and apply the patch there? I can of course edit the patch manually, because it's small, but in general case that wouldn't really work. 50629 9 jku 2015-04-30 10:14:09 +0000 (In reply to comment #8) > After updating a package version (for clutter-gst), one of the included > patches fails to apply during build: > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/ > clutter/clutter-gst-1.0-1.6.0/enable-tests.patch > > The patch has all sorts of metadata that need to be preserved (I suppose), > and the essence of the patch is still valid, so what's the easiest way to > produce a new patch? Maybe I should clone the source from git separately, > and apply the patch there? I can of course edit the patch manually, because > it's small, but in general case that wouldn't really work. There may be better ways but the process I've used is: * unpack the source with bitbake, possibly apply other patches * do "git init .", "git add *", "git commit -m 'unpacked source'" in the source dir to create a baseline * apply the patch by hand, fix what didn't apply. * commit to git, possibly with an expanded comment if needed and sign-off-by * do "git format-patch -1", copy patch to meta/recipes-... It's a bit of work for a single small patch but still quite fast and it scales well to bigger patches and many patches. 50630 10 ross.burton 2015-04-30 10:18:39 +0000 That's certainly how I used to update patches, and devtool should handle this if it doesn't already. Ideally, I'd see devtool failing to apply a patch and giving you a prompt to update the patch, where you can use git mergetool. I'll file a bug for Paul. :) 50917 11 alex.kanavin 2015-05-12 13:22:51 +0000 I've reviewed the patches for webkit-gtk; the good news is that almost all of them can be dropped; the bad news is that updating webkitgtk is otherwise quite involved, because they have switched from autotools to cmake, added a ton of dependencies, and all of the build options have changed or disappeared. This is the price to pay for allowing recipes go stale. Working on making the latest version (at least) build right now... 50965 12 alex.kanavin 2015-05-13 12:55:58 +0000 Ross made a comment on otcchat: "is gstreamer optional in the webkit we ship? if so to stop the series stalling we could disable it by default (with packageconfig) without upgrading webkit now, and then re-enable when new webkit is integrated" Gstreamer is optional in webkit, but disabling it means that HTML5 video and Web Audio would no longer be supported in midori or any other browser that's using it. If you (and/or Richard) are ok with it, I can do it, and submit the full patchset for this bug very shortly afterwards. 51214 13 ross.burton 2015-05-22 00:00:59 +0000 Done in oe-core as of fe44ac167a2a76531af3519f3889fce92024567b 51216 14 raj.khem 2015-05-22 05:38:15 +0000 is patch to add them posted for meta-multimedia ? 51218 15 ross.burton 2015-05-22 07:36:36 +0000 Yes, it's been posted to oe-devel. 52141 16 cristina-danielax.agurida 2015-07-06 09:11:04 +0000 Verified on master: b78b1a6bb82fb864f1f857bf7259908d0ed930b5