[bug#70282,v2] gnu: gnome-shell: Wrap screencast service.

On 19.04.24 20:51, Liliana Marie Prikler wrote:
> Am Freitag, dem 12.04.2024 um 17:26 +0000 schrieb Dariqq:
>> The screencast service can now find typelibs and gstreamer plugins.
>>
>> * gnu/packages/linux.scm (gnome-shell)
>> [inputs]: Add gst-plugins-good and pipewire.
>> [#:phases]<'wrap-programs>: Create a wrapper for screencast service
>> and use it.
>>
>> Change-Id: I2c31bf1bd92e281b86c57b06988c6a3793a58d40
>> ---
>>
>> Hi,
>>
>> Here is v2 of the patch. The wrapper is now created manually as I was
>> unable to find a way to manipulate the gstreamer plugin load path
>> from within javascript. Importantly this leaves the original
>> javascript file untouched and therefore circumvents the argv[0]
>> problem in v1.
>> All the required gstreamer plugins (pipewire and gst-plugins-good)
>> are now inputs and are in the wrapper via GST_PLUGIN_SYSTEM_PATH.
> I'm not sure this fix is sounds.  It looks like it misses manual
> invocation from the command line, does it not?  (Well, it's gnome-
> shell, so if you have to invoke it from the command line, things are
> broken, but still…)

If only the typelib path is set the dbus service now longer greets you 
with an error but still fails to start without the gstreamer plugins. 
That's why in v1 I was propagating pipewire through gnome-essential-extras.

I am not sure what you mean by manual invocation. The screencast service 
should get started via dbus. Nothing manual should be required (other 
than enabling the pipewire home service).

   What keeps you from wrapping the environment
> variable in Javascript?

I was unable to find a way to manipulate the GST_PLUGIN_PATH or specify 
the gst search path from within javascript. There is 
Gst.Registry().scan_path but this creates a new registry and I don't 
think is what we want here. (but I don't know anything about gstreamer 
and javascript so I could be wrong here).

I guess the most simple patch for the typelibs would be something like


imports.gi.GIRepository.Repository."
+                                       "prepend_search_path(path));\n"
+                                       all))))
+                   '("org.gnome.Shell.Extensions" 
"org.gnome.Shell.Screencast"))
                    (for-each
                     (lambda (prog)
                       (wrap-program (string-append #$output "/bin/" prog)


and dealing with the gstreamer plugins in another way.

>> I've also left a comment for the required home-pipewire-service.
>> In gnome-shell 45+ the invocation has changed to 'gjs -m service'.
>> Should this also be a comment somewhere?
> Gnome-shell 45+ is currently irrelevant, but we might have to adapt
> things once we get there on gnome-team.  We do need a better gjs-
> patching strategy.
> 

It would be nice if something like wrap-script would work. But the 
problem is that the dbus services specify somehting like "Exec= gjs 
service" rather than executing a gjs-script directly. (which is the main 
purpose of the patch from nixos). And also gjs not being a valid 
interpreter for wrap-script (Changing that will rebuild everything)

> Cheers
> 

Have an nice day.

Am Samstag, dem 20.04.2024 um 10:11 +0000 schrieb Dariqq:
> 
> 
> On 19.04.24 20:51, Liliana Marie Prikler wrote:
> > Am Freitag, dem 12.04.2024 um 17:26 +0000 schrieb Dariqq:
> > > The screencast service can now find typelibs and gstreamer
> > > plugins.
> > > 
> > > * gnu/packages/linux.scm (gnome-shell)
> > > [inputs]: Add gst-plugins-good and pipewire.
> > > [#:phases]<'wrap-programs>: Create a wrapper for screencast
> > > service
> > > and use it.
> > > 
> > > Change-Id: I2c31bf1bd92e281b86c57b06988c6a3793a58d40
> > > ---
> > > 
> > > Hi,
> > > 
> > > Here is v2 of the patch. The wrapper is now created manually as I
> > > was unable to find a way to manipulate the gstreamer plugin load
> > > path from within javascript. Importantly this leaves the original
> > > javascript file untouched and therefore circumvents the argv[0]
> > > problem in v1.
> > > All the required gstreamer plugins (pipewire and gst-plugins-
> > > good) are now inputs and are in the wrapper via
> > > GST_PLUGIN_SYSTEM_PATH.
> > I'm not sure this fix is sounds.  It looks like it misses manual
> > invocation from the command line, does it not?  (Well, it's gnome-
> > shell, so if you have to invoke it from the command line, things
> > are broken, but still…)
> 
> If only the typelib path is set the dbus service now longer greets
> you with an error but still fails to start without the gstreamer
> plugins.  That's why in v1 I was propagating pipewire through
> gnome-essential-extras.
> 
> I am not sure what you mean by manual invocation. The screencast
> service  should get started via dbus. Nothing manual should be
> required (other than enabling the pipewire home service).
Just what it says on the tin, manually running the "binary" through the
command line.  It's not super useful with GNOME, but I think we should
make sure our services work whichever way they could be invoked.

>    What keeps you from wrapping the environment
> > variable in Javascript?
> 
> I was unable to find a way to manipulate the GST_PLUGIN_PATH or
> specify the gst search path from within javascript. There is 
> Gst.Registry().scan_path but this creates a new registry and I don't 
> think is what we want here. (but I don't know anything about
> gstreamer and javascript so I could be wrong here).
Instead of creating a new Gst.Registry – as per the () here – you could
use gst_registry_get() or whatever the according JS method is to access
the Registry singleton.

The Registry constructor ought to be protected, but idk how GJS handles
that.

> I guess the most simple patch for the typelibs would be something
> like
> 
> 
> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
> index fa6c566c75..28c4e540a6 100644
> --- a/gnu/packages/gnome.scm
> +++ b/gnu/packages/gnome.scm
> @@ -9404,13 +9404,15 @@ (define-public gnome-shell
>                        (wrap-program (string-append #$output "/bin/"
> prog)
>                          `("GI_TYPELIB_PATH" ":" prefix 
> (,gi-typelib-path))))
>                      '("gnome-shell" "gnome-extensions-app"))
> -                  (substitute* (string-append #$output 
> "/share/gnome-shell/"
> -                                             
> "org.gnome.Shell.Extensions")
> -                    (("imports\\.package\\.start" all)
> -                     (string-append "'" gi-typelib-path 
> "'.split(':').forEach("
> -                                    "path => 
> imports.gi.GIRepository.Repository."
> -                                    "prepend_search_path(path));\n"
> -                                    all)))
> +                  (for-each
> +                   (lambda (prog)
> +                     (substitute* (string-append #$output 
> "/share/gnome-shell/" prog)
> +                       (("imports\\.package\\.start" all)
> +                        (string-append "'" gi-typelib-path 
> "'.split(':').forEach("
> +                                       "path => 
> imports.gi.GIRepository.Repository."
> +                                      
> "prepend_search_path(path));\n"
> +                                       all))))
> +                   '("org.gnome.Shell.Extensions" 
> "org.gnome.Shell.Screencast"))
>                     (for-each
>                      (lambda (prog)
>                        (wrap-program (string-append #$output "/bin/"
> prog)
> 
> 
> and dealing with the gstreamer plugins in another way.
Hmm, could you add --gst-plugin-path on the command line?

> > > I've also left a comment for the required home-pipewire-service.
> > > In gnome-shell 45+ the invocation has changed to 'gjs -m
> > > service'.
> > > Should this also be a comment somewhere?
> > Gnome-shell 45+ is currently irrelevant, but we might have to adapt
> > things once we get there on gnome-team.  We do need a better gjs-
> > patching strategy.
> > 
> 
> It would be nice if something like wrap-script would work. But the 
> problem is that the dbus services specify somehting like "Exec= gjs 
> service" rather than executing a gjs-script directly. (which is the
> main purpose of the patch from nixos). And also gjs not being a valid
> interpreter for wrap-script (Changing that will rebuild everything)
You can redo the needed logic locally and add a "XXX: Use wrap-script
once it can handle gjs" for example.  That's no hard blocker, but it's
not the nicest option either, I admit.  Let's try our other options
first.

> 
Cheers

On 20.04.24 12:46, Liliana Marie Prikler wrote:
> Am Samstag, dem 20.04.2024 um 10:11 +0000 schrieb Dariqq:
>>
>>
>> On 19.04.24 20:51, Liliana Marie Prikler wrote:
>>> Am Freitag, dem 12.04.2024 um 17:26 +0000 schrieb Dariqq:
>>>> The screencast service can now find typelibs and gstreamer
>>>> plugins.
>>>>
>>>> * gnu/packages/linux.scm (gnome-shell)
>>>> [inputs]: Add gst-plugins-good and pipewire.
>>>> [#:phases]<'wrap-programs>: Create a wrapper for screencast
>>>> service
>>>> and use it.
>>>>
>>>> Change-Id: I2c31bf1bd92e281b86c57b06988c6a3793a58d40
>>>> ---
>>>>
>>>> Hi,
>>>>
>>>> Here is v2 of the patch. The wrapper is now created manually as I
>>>> was unable to find a way to manipulate the gstreamer plugin load
>>>> path from within javascript. Importantly this leaves the original
>>>> javascript file untouched and therefore circumvents the argv[0]
>>>> problem in v1.
>>>> All the required gstreamer plugins (pipewire and gst-plugins-
>>>> good) are now inputs and are in the wrapper via
>>>> GST_PLUGIN_SYSTEM_PATH.
>>> I'm not sure this fix is sounds.  It looks like it misses manual
>>> invocation from the command line, does it not?  (Well, it's gnome-
>>> shell, so if you have to invoke it from the command line, things
>>> are broken, but still…)
>>
>> If only the typelib path is set the dbus service now longer greets
>> you with an error but still fails to start without the gstreamer
>> plugins.  That's why in v1 I was propagating pipewire through
>> gnome-essential-extras.
>>
>> I am not sure what you mean by manual invocation. The screencast
>> service  should get started via dbus. Nothing manual should be
>> required (other than enabling the pipewire home service).
> Just what it says on the tin, manually running the "binary" through the
> command line.  It's not super useful with GNOME, but I think we should
> make sure our services work whichever way they could be invoked.
> 
>>     What keeps you from wrapping the environment
>>> variable in Javascript?
>>
>> I was unable to find a way to manipulate the GST_PLUGIN_PATH or
>> specify the gst search path from within javascript. There is
>> Gst.Registry().scan_path but this creates a new registry and I don't
>> think is what we want here. (but I don't know anything about
>> gstreamer and javascript so I could be wrong here).
> Instead of creating a new Gst.Registry – as per the () here – you could
> use gst_registry_get() or whatever the according JS method is to access
> the Registry singleton.
> 
> The Registry constructor ought to be protected, but idk how GJS handles
> that.
> 

I've tried adding Gst.Registry.get().scan_path() after the GI_TYPELIB 
expansion but I am not sure why it does not work. Stracing the 
invocation shows that the pipewire gstreamer plugin is accessed at the 
beginning but it is still not available somehow. Probably because of my 
lack of knowledge about gstreamer.

>> I guess the most simple patch for the typelibs would be something
>> like
>>
>>
>> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
>> index fa6c566c75..28c4e540a6 100644
>> --- a/gnu/packages/gnome.scm
>> +++ b/gnu/packages/gnome.scm
>> @@ -9404,13 +9404,15 @@ (define-public gnome-shell
>>                         (wrap-program (string-append #$output "/bin/"
>> prog)
>>                           `("GI_TYPELIB_PATH" ":" prefix
>> (,gi-typelib-path))))
>>                       '("gnome-shell" "gnome-extensions-app"))
>> -                  (substitute* (string-append #$output
>> "/share/gnome-shell/"
>> -
>> "org.gnome.Shell.Extensions")
>> -                    (("imports\\.package\\.start" all)
>> -                     (string-append "'" gi-typelib-path
>> "'.split(':').forEach("
>> -                                    "path =>
>> imports.gi.GIRepository.Repository."
>> -                                    "prepend_search_path(path));\n"
>> -                                    all)))
>> +                  (for-each
>> +                   (lambda (prog)
>> +                     (substitute* (string-append #$output
>> "/share/gnome-shell/" prog)
>> +                       (("imports\\.package\\.start" all)
>> +                        (string-append "'" gi-typelib-path
>> "'.split(':').forEach("
>> +                                       "path =>
>> imports.gi.GIRepository.Repository."
>> +
>> "prepend_search_path(path));\n"
>> +                                       all))))
>> +                   '("org.gnome.Shell.Extensions"
>> "org.gnome.Shell.Screencast"))
>>                      (for-each
>>                       (lambda (prog)
>>                         (wrap-program (string-append #$output "/bin/"
>> prog)
>>
>>
>> and dealing with the gstreamer plugins in another way.
> Hmm, could you add --gst-plugin-path on the command line?
> 
>>>> I've also left a comment for the required home-pipewire-service.
>>>> In gnome-shell 45+ the invocation has changed to 'gjs -m
>>>> service'.
>>>> Should this also be a comment somewhere?
>>> Gnome-shell 45+ is currently irrelevant, but we might have to adapt
>>> things once we get there on gnome-team.  We do need a better gjs-
>>> patching strategy.
>>>
>>
>> It would be nice if something like wrap-script would work. But the
>> problem is that the dbus services specify somehting like "Exec= gjs
>> service" rather than executing a gjs-script directly. (which is the
>> main purpose of the patch from nixos). And also gjs not being a valid
>> interpreter for wrap-script (Changing that will rebuild everything)
> You can redo the needed logic locally and add a "XXX: Use wrap-script
> once it can handle gjs" for example.  That's no hard blocker, but it's
> not the nicest option either, I admit.  Let's try our other options
> first.
> 

I've just found GLib.setenv() to set environment variables for the 
process directly from within gjs. The GLib typelib comes from the 
gobject-introspection package so this should be available.

 From my limited testing it seems to work (at least for the screencast 
service). What do you think?

> Cheers

Have a nice day.

Am Sonntag, dem 21.04.2024 um 12:37 +0000 schrieb Dariqq:
> > 
> [...]
> I've just found GLib.setenv() to set environment variables for the 
> process directly from within gjs. The GLib typelib comes from the 
> gobject-introspection package so this should be available.
> 
> From my limited testing it seems to work (at least for the screencast
> service). What do you think?
Yes, GLib.setenv is the function I had in mind to twiddle the
environment.  If you find the right location to do so at the start of
the program, please send a patch that does that.

Cheers