Summary: | [Flatpak] Update to GNOME master runtime | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> | ||||
Component: | WebKitGTK | Assignee: | Michael Catanzaro <mcatanzaro> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | bugs-noreply, mcatanzaro, pnormand, tsaunier | ||||
Priority: | P2 | ||||||
Version: | Other | ||||||
Hardware: | PC | ||||||
OS: | Linux | ||||||
Attachments: |
|
Description
Michael Catanzaro
2018-08-19 10:11:27 PDT
(In reply to Michael Catanzaro from comment #0) > Since everything is built from git master, it's a simple matter to change the SDK hashes whenever we need new versions. BTW, I hope this will help encourage us to maintain our upstream first policy for GStreamer patches. It should only take a day or two for upstream changes to land in the master runtime, so I don't think this will be much inconvenience. If there are exceptional circumstances, we can always reverse course and add some GStreamer stuff back, but hopefully we can avoid that. BTW #2: the upstream ffmpeg extension has been broken for several months now. I think that's https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/306 but maybe there are other issues too. Again, I think it's desirable to expose issues like this that are currently hidden by us building our own custom GStreamer. Created attachment 347458 [details]
Patch
Interesting approach to just upgrade to master, but thinking about it, it does make sense. Checked the patch and I add an informal r+ for it. > * Freedesktop 1.8 base, instead of Freedesktop 1.6. Huge improvements, e.g. it's now multiarch. fwiw, 3.28 was already multi arch, I am working on a branch where I am building targeting aarch64 and arm simply using binfmt and qemu-user. it works like a charm (patch yet to be finalized: https://github.com/thiblahute/webkit/commit/29d20bd9251507578d4bbd87054e8954aff8339c) and makes the worflow to target embedded devices very neat as I simply have a flatpak repo on the desktop and update org.webkit.WPE on the RPI :-) (In reply to Thibault Saunier from comment #4) > > * Freedesktop 1.8 base, instead of Freedesktop 1.6. Huge improvements, e.g. it's now multiarch. > > fwiw, 3.28 was already multi arch, I am working on a branch where I am > building targeting aarch64 and arm simply using binfmt and qemu-user. it > works like a charm (patch yet to be finalized: > https://github.com/thiblahute/webkit/commit/ > 29d20bd9251507578d4bbd87054e8954aff8339c) and makes the worflow to target > embedded devices very neat as I simply have a flatpak repo on the desktop > and update org.webkit.WPE on the RPI :-) "multiarch" has a very specific meaning: it means Debian-style libdirs, e.g. /usr/lib/x86_64-linux-gnu and /usr/lib/i386-linux-gnu, as opposed to "multilib" which is the /usr/lib64 and /usr/lib (or sometimes /usr/lib32) used everywhere else. multiarch is a bit nicer. The 1.6/3.28 SDKs weren't even multilib, they just put everything under /usr/lib. (Note that /app/lib is still not multiarch, and probably never will be, because apps are built for just one architecture.) So when I see this problem: (gst-plugin-scanner:16): CRITICAL **: 12:00:00.438: Couldn't g_module_open libpython. Reason: /usr/lib/libpython3.7m.so: cannot open shared object file: No such file or directory. I wonder why gst-plugin-scanner is looking in the old location, rather than the new multiarch location. Comment on attachment 347458 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=347458&action=review > Tools/flatpak/org.webkit.WebKit.yaml:-114 > - - name: libvpx Isn't this needed for WebRTC? > Tools/flatpak/org.webkit.WebKit.yaml:-187 > - - name: gst-libav Without this you loose another chance to run layout tests, quite a few use h264 files. (In reply to Philippe Normand from comment #6) > Comment on attachment 347458 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=347458&action=review > > > Tools/flatpak/org.webkit.WebKit.yaml:-114 > > - - name: libvpx > > Isn't this needed for WebRTC? It is in the gnome master Sdk. > > Tools/flatpak/org.webkit.WebKit.yaml:-187 > > - - name: gst-libav > > Without this you loose another chance to run layout tests, quite a few use > h264 files. The flatpak FFMPEG extension should work, afaiu it doesn't right now, so I maybe we want to workaround that for now? (In reply to Thibault Saunier from comment #7) > The flatpak FFMPEG extension should work, afaiu it doesn't right now, so I > maybe we want to workaround that for now? Instead of working around it, I would rather we fix it. The extension was renamed, btw, to html5-codecs. But I do not seem to have it installed, which is concerning. The old extension org.freedesktop.Platform.ffmpeg/x86_64/1.6 was installed automatically somehow; not sure how. The other problem is that gstreamer-libav is currently not being built by freedesktop SDK, so not sure how the extension could work. Another question is how overlaps work: the GNOME runtime builds its own gstreamer-libav which gets installed after (overlaps on disk) the freedesktop one, and that's not in any extension. So theoretically, I would expect it to already work. Not sure why it doesn't; it will need debugging by GStreamer experts. (When we switch the GNOME runtime generation to gnome-build-meta, the freedesktop version will no longer be installed, eliminating the overlap.) Anyway, how the extension is supposed to work when we rebuild all the gstreamer elements is beyond me. The final problem is that if we do fix it, I am going to start complaining about autoplay video again. :P I'm tired of being the only browser that still allows autoplay videos. But that is a separate bug; let's not block on that. Committed r235114: <https://trac.webkit.org/changeset/235114> I think the commits I had tagged were pruned from the server, so perhaps master is going to be a no-go. We'll probably need to revert this or switch to 3.30? Reverted r235114 for reason: ostree server deleted our commits? Committed r235500: <https://trac.webkit.org/changeset/235500> It looks like the same happened on the 3.28 branch :| Should we check with GNOME sysadmins how for how long they keep history in the ostree repo? Maybe ask them to keep them for more time? fmpov it should try to keep as much of history as possible so we can bisect! (In reply to Thibault Saunier from comment #12) > It looks like the same happened on the 3.28 branch :| Then I don't know what we can do, I guess our flatpak build scripts are just not usable right now. Good thing we failed to switch over the bots.... The GNOME sysadmins won't be able to answer this. Please ask Alex; he runs sdk.gnome.org. Reverted r235500 for reason: Time to switch back to master runtime Committed r236195: <https://trac.webkit.org/changeset/236195> |