bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#52375: webkitgtk page crashes on core-updates-frozen


From: Maxim Cournoyer
Subject: bug#52375: webkitgtk page crashes on core-updates-frozen
Date: Tue, 21 Dec 2021 11:39:05 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hello Jack,

Jack Hill <jackhill@jackhill.us> writes:

> I asked about this issue on #webkitgtk:gnome.org on IRC. It turns out
> that what's missing from my environment is gst-plugins-bad (most
> likely the fakevideosink plugin contained therein). If I install 
> gst-plugins-bad into an environment with a webgkitgtk browser, the
> crash I was seeing is resolved. Only adding gst-plugins-bad to the
> inputs of webkitgtk doesn't seem to be enough to solve the problem. I
> suppose some additional wrapping is needed somewhere (although
> gst-plugins-base shows up in the webkitgtk references).
>
> What's the best path forward here?
>
> Should leaf applications that use webkitgtk be wrapped to find the
> right gst-plugins? This seems suboptimal to me. If the plugins are
> really dependencies of webkitgtk then perhaps they should be encoded
> that way in Guix.

I think upstream should improve their software to display more
informative messages when a plugin is missing to play some content (a
tab crash is not very helpful!) :-).

> Should webkitgtk be wrapped somehow to find the plugins on its own?
> How would this wrapping be done? Do we want to force all webkitgtk
> applications to carry around these dependencies?

I think there's not much to do here other than document the availability
of plugins to extend the capabilities of webkitgtk.  It's won't be
obvious to leaf package users though, so fixing it upstream would still
have value.

As discussed on #guix, some reasons for not propagating them or even
wrapping them is the fact that they are *plugins*, that is, they exist
in that form so that users can compose them for runtime discovery as
they see fit.  Propagating the plugins would go against this, and is not
very "Guixy" :-).

Another reason is that adding the gst-plugins-good and gst-plugins-bad
would inflate the size of the webkitgtk package by more than 1 GiB!
(compare "guix size webkitgtk" vs "guix size webkitgtk gst-plugins-good
gst-plugins-bad").

I'm tempted to make this change to the description of 'webkitgtk':

--8<---------------cut here---------------start------------->8---
modified   gnu/packages/webkit.scm
@@ -350,7 +350,9 @@ (define-public webkitgtk
     (description
      "WebKitGTK+ is a full-featured port of the WebKit rendering engine,
 suitable for projects requiring any kind of web integration, from hybrid
-HTML/CSS applications to full-fledged web browsers.")
+HTML/CSS applications to full-fledged web browsers.  WebKitGTK+ can play
+various video content through the use of the GStreamer plugins (not propagated
+by default) such as @code{gst-plugins-good} and @code{gst-plugins-bad}.")
     ;; WebKit's JavaScriptCore and WebCore components are available under
     ;; the GNU LGPL, while the rest is available under a BSD-style license.
     (license (list license:lgpl2.0
--8<---------------cut here---------------end--------------->8---

and close this as 'notabug'.  What do you think?

Thanks,

Maxim





reply via email to

[Prev in Thread] Current Thread [Next in Thread]