grilo @0.2.7 / grilo-plugins @0.2.9 new Portfiles

[juanrgar (Juan R. García Blanco)]

Grilo media framework. It's required by latest gnome-photos (see also {42254}). grilo-plugins is not included here (yet).

[cooljeanius (Eric Gallager)]

Cc Me!

[dbevans (David B. Evans)]

When submitting new GNOME ports for review, if you'll CC me on the ticket, that will ensure that I see it in a timely manner. Thanks for another submission!

[dbevans (David B. Evans)]

A few notes

• vala is disabled by default. This is becoming standard in GNOME and is probably necessary if dependents of grilo want to use vala as well. I would enable this by default (no variant) or at least mark the variant as default if you want to allow users to disable this functionality
• the port installs files in library ${prefix}/lib64 which violates the standard layout of the ports install tree. For MacPorts this should be ${prefix}/lib instead. Is this really necessary? If so, you need to use the destroot.violate_mtree statement in the Portfile to indicate this is intentional. See the ​guide for details. Better if you can avoid this.

[juanrgar (Juan R. García Blanco)]

Thank you very much.

Is it ok then if I CC you in the submissions I've requested but answer is pending?

As for the two points you mentioned:

• I've seen telepathy-glib has a vala variant, which is enabled by default. I guess that grilo and telepathy-glib are not that different, so taking your advice as well I'll keep the vala variant and make it default.
• I didn't notice. I've patched configure.ac to remove setting of libdir (I tried also remove setting of prefix and exec_prefix, since I guess they should be set to acceptable values). Apparently these variables let the grilo lib know where are plugins to load. I tried to launch the example program grilo-simple-playlist, and it failed because it couldn't find any grilo plugins. This is weird, so I'll try to install grilo-plugins and see if it works. Meanwhile grilo now installs libraries under ${prefix}/lib.

[juanrgar (Juan R. García Blanco)]

grilo Portfile and patches

[dbevans (David B. Evans)]

Replying to juanrgar@…:

Thank you very much.

Is it ok then if I CC you in the submissions I've requested but answer is pending?

Yes, that would be fine particularly if it is a GNOME related port.

As for the two points you mentioned:

• I've seen telepathy-glib has a vala variant, which is enabled by default. I guess that grilo and telepathy-glib are not that different, so taking your advice as well I'll keep the vala variant and make it default.

I'm embarrassed by this. Originally the telepathy-glib port provided the vala bindings as an 'experimental' option, hence the variant (not default). Later when other dependencies needed the vala support, I (lazily) just made it a default variant. I'll probably remove the variant at the next version update. Thanks for reminding me.

• I didn't notice. I've patched configure.ac to remove setting of libdir (I tried also remove setting of prefix and exec_prefix, since I guess they should be set to acceptable values). Apparently these variables let the grilo lib know where are plugins to load. I tried to launch the example program grilo-simple-playlist, and it failed because it couldn't find any grilo plugins. This is weird, so I'll try to install grilo-plugins and see if it works. Meanwhile grilo now installs libraries under ${prefix}/lib.

I agree. After testing a bit, it looks like grilo won't do anything interesting without the plug-ins and doesn't install any by default, so grilo-plugins seems to be a necessity rather than an add on as in some other ports (eog-plugins for instance).

[dbevans (David B. Evans)]

After testing your updated submission I found a few more things (see updated Portfile attached).

• The port is trying to install the expected plugins directory (an empty ${prefix}/lib/grilo-0.2) but MacPorts deletes any empty directories in destroot by default. I've added a destroot.keepdirs statement to override this behavior allowing the empty directory to be installed. This removes the first error message from grilo-simple-playlist and may be needed by grilo-plugins (guessing).
• I've added a post-patch phase that replaces the file m4/intltool.m4 with the patched version provided by MacPorts. This fixes a possible Perl configuration problem involving the INTLTOOL_PERL m4 macro. This manual operation is necessary because autoreconf doesn't run intltoolize.
• Added missing build dependency gnome-common (required when using autoreconf to supply GNOME specific m4 macros).

With these changes I think the port is ready to commit although as mentioned above it needs some plugins to do something useful. Let me know if you agree.

[dbevans (David B. Evans)]

Revised Portfile with a few more fixes

[dbevans (David B. Evans)]

Updated homepage in attached Portfile to avoid redirects.

[juanrgar (Juan R. García Blanco)]

I totally agree with you. Just uploaded a Portfile that enables vala by default and has the vala variant removed.

As for grilo-plugins, I've taken a look at it, and it'll take me some time to have something ready, mainly because it contains many plugins.

[dbevans (David B. Evans)]

grilo committed in r116723.
added missing vala dependency in r116725.

Looking forward to the plugins.

[juanrgar (Juan R. García Blanco)]

Thank you.

For grilo-plugins I'm taking the following approach:

• Disable all plugins by default
• Create a variant for each plugin
• Activate a reasonable set of variants by default

Is this ok?

[dbevans (David B. Evans)]

I'm not enthusiastic about it. :-)

I'm thinking that the point of grilo is to create a uniform API that allows other apps to access a large variety of content providers without having to worry about the provider specific details. So I would enable all the working plugins by default and only use a variant if a plugin has problems or could be considered experimental by the upstream developers (not ready for prime time as it were) or if they conflict with one another.

Minimizing the number of variants is usually the best policy since in the current state of things, MacPorts doesn't allow dependents to request a particular variant so you have to be sure that all functionality required by them is built in the default configuration. Having a default variant only makes sense in the conflict situation (e.g. +x11 vs +quartz, +python26 vs +python27) or there is a reason that you want to allow the user to disable the variant for some reason.

Simple is better, IMHO.

[juanrgar (Juan R. García Blanco)]

Understood. It makes perfect sense. But then, after looking at grilo-plugins dependency list, I will ask you to modify the grilo Portfile to remove the net variant so grill-net is always built. There are a few plugins that depend on grilo-net, and I'm not aware of any that only depends on grilo.

[juanrgar (Juan R. García Blanco)]

Remove net variant

[dbevans (David B. Evans)]

Committed in r116746 with modification (vala dependency is required).

[juanrgar (Juan R. García Blanco)]

grilo-plugins Portfile

[juanrgar (Juan R. García Blanco)]

Thank you, and sorry about the gala dependency.

Just uploaded a basic Portfile for grilo-plugins. I left out tracker as currently it isn't present in the repo. I can see grilo-plugins installing a shared library for each plugin under ${prefix}/lib/grilo-0.2; however I haven't been able to run grilo-simple-playlist, even specifying a path to plugins repo.

[dbevans (David B. Evans)]

grilo has been updated to 0.2.8.

[dbevans (David B. Evans)]

I think that the grilo-plugins are working, it's just grilo-simple-playlist that seems to be broken (or I don't know how to use it). Perhaps there are some fixes in grilo 0.2.8.

After some problems with libdmapsharing (#42402), I was able to build grilo-plugins.

grilo-simple-playlist gives

$ grilo-simple-playlist

(grilo-simple-playlist:50868): GLib-WARNING **: poll(2) failed due to: Bad file descriptor.
Query parameter missing

but using grl-inspect-0.2 gives

$ grl-inspect-0.2

(grl-inspect-0.2:50885): GLib-WARNING **: poll(2) failed due to: Bad file descriptor.

** (grl-inspect-0.2:50885): WARNING **: Error sending SSDP packet to 239.255.255.250: Error sending message: Network is unreachable

** (grl-inspect-0.2:50885): WARNING **: Error sending SSDP packet to 239.255.255.250: Error sending message: Network is unreachable

** (grl-inspect-0.2:50885): WARNING **: Error sending SSDP packet to 239.255.255.250: Error sending message: Network is unreachable
grl-apple-trailers:  grl-apple-trailers
grl-bliptv:  grl-bliptv
grl-bookmarks:  grl-bookmarks
grl-filesystem:  grl-filesystem
grl-gravatar:  grl-gravatar
grl-jamendo:  grl-jamendo
grl-lastfm-albumart:  grl-lastfm-albumart
grl-local-metadata:  grl-local-metadata
grl-magnatune:  grl-magnatune
grl-metadata-store:  grl-metadata-store
grl-optical-media:  grl-optical-media
grl-podcasts:  grl-podcasts
grl-raitv:  grl-raitv
grl-upnp:  grl-upnp-uuid:785279bc-4bc7-4215-a1ef-d49a043fb891  grl-upnp-uuid:8f14eb44-1e77-45c8-98e6-9f88a285542f

Note that grl-upnp-uuid:8f14eb44-1e77-45c8-98e6-9f88a285542f is an instance of Coherence media server running on another Mac and grl-upnp-uuid:785279bc-4bc7-4215-a1ef-d49a043fb891 is an instance of Windows Media Server running on a PC, both on my local network.

I then configured grilo to build with --enable-test-ui which allows grilo-test-ui-0.2 to be built. Running grilo-test-ui-0.2 allows me to see all the sources listed above and search and browse through them including the local filesystem (grl-filesystem).

Finally, I modified totem to build with its grilo plugin and was able to see these same resources and search and browse through them there. I was not able to actually play any selections in totem but I think that is another totem issue having to do with gvfs not a problem with grilo.

I'm attaching a patch for grilo-plugins that deals with intltool.m4 configuration issues and another with the changes I made to grilo to get the grilo-test-ui program.

[dbevans (David B. Evans)]

Proposed patch to grilo-plugins to fix intltool configuration.

[dbevans (David B. Evans)]

Trivial patch to grilo to enable grilo-test-ui app

[juanrgar (Juan R. García Blanco)]

Just updated grilo to latest 0.2.8, and added your patch to enable grilo-test-ui app. Please note that the vala patch is not needed anymore and can be removed.

[juanrgar (Juan R. García Blanco)]

grilo-plugins 0.2.10 includes a new pocket plugin depends on a newer version of gnome-online-accounts; at least that prevents updating.

[dbevans (David B. Evans)]

Replying to juanrgar@…:

Just updated grilo to latest 0.2.8, and added your patch to enable grilo-test-ui app. Please note that the vala patch is not needed anymore and can be removed.

Patch committed in r117048 with modifications, enabled grilo-test-ui, realign patch to configure.ac, move copy of intltool.m4 from post-patch to pre-configure to ensure that intltool has been activated before this command is attempted (my error).

[dbevans (David B. Evans)]

Replying to juanrgar@…:

grilo-plugins 0.2.10 includes a new pocket plugin depends on a newer version of gnome-online-accounts; at least that prevents updating.

I think you need to commit grilo-plugins to make grilo useful as we have discussed.

Two possibilities:

• commit older grilo-plugins-0.2.9
• commit the newer 0.2.10 but disable the plugins that require the newer version of gnome-online-accounts

The problem with upgrading gnome-online-accounts is that the newer versions require webkit-gtk3 >= 2.1.90 which only builds on 10.9 and not on 10.8 and earlier and this doesn't look like it's going to change any time soon.

[juanrgar (Juan R. García Blanco)]

I chose the second option. I updated the original grilo-plugins Portfile with your patch and bumped it to 0.2.10 (disabling the plugin that does not work yet).

[dbevans (David B. Evans)]

Some testing results

• upgrading to grilo 0.2.8 fixed the problems I was having playing grilo provided selections in totem
• after installing grilo-plugins 0.2.10, grl-inspect-0.2 fails as follows, reverting to 0.2.9 fixes the segmentation fault. The avahi warning is obnoxious but apparently harmless.

$grl-inspect-0.2

(grl-inspect-0.2:43648): GLib-WARNING **: poll(2) failed due to: Bad file descriptor.
*** WARNING *** The program 'grl-inspect-0.2' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/avahi-compat?s=libdns_sd&e=grl-inspect-0.2>
Segmentation fault: 11

Do you want to commit grilo-plugins-0.2.9 until the issues with 0.2.10 are ironed out?

[dbevans (David B. Evans)]

Patch attached for grilo-plugins-0.2.10. This doesn't help with the segfault I just reported but updates intltool configuration relative to 0.2.9. In 0.2.9 the tarball contained no in-tree copy of intltool.m4 so just using autoreconf was enough to re-generate configure using our version of the file. Version 0.2.10 has a copy of the file in directory m4 which over-rides our version so it has to be replaced before using autoreconf. Added a few extra build deps that are needed as well.

[dbevans (David B. Evans)]

Additional patch to update intltool configuration for latest grilo-plugins 0.2.10.

[juanrgar (Juan R. García Blanco)]

Thank you very much. I'd like to give a try to fix grilo-plugins-0.2.0. However, I guess that since grilo is committed we could commit also grilo-plugins-0.2.9, so that grilo can be usable. Thank you.

[dbevans (David B. Evans)]

grilo-plugins 0.2.9 committed in r117093.

I will close this ticket for now as it is technically complete and getting a bit long. You can open a new upgrade ticket when you have 0.2.10 working.