extra apps and locales

[Robert McQueen]

On 15/02/17 20:19, Bastien Nocera wrote:
> On Wed, 2017-02-15 at 18:35 +0000, Robert McQueen wrote:
>> Hi there,
>>
>> We have a Flatpak for VLC (https://github.com/endlessm/vlc-flatpak/)
>
> Added to the examples Wiki page:
> https://github.com/flatpak/flatpak/wiki/Examples

This Flatpak which relies on the Jessie .debs and the Endless OS runtime 
(made from our .deb derived ostree so is ~= ABI compatible with Jessie) 
is far from exemplar! The "upstream" repo at 
https://github.com/kinvolk/vlc-flatpak/ is a more normal sourceful 
build, so it's probably a lot better reference. Although we need to 
cherry pick a few things (we decided on the name org.videolan.VLC for 
instance) back so they remain comparable/interchangable.

> Would be great if you could convince the upstream to ship it!

We've not asked them recently so I guess we should - we and some others 
have had very limited success thus far:
  https://lists.freedesktop.org/archives/xdg-app/2016-June/000224.html

FWIW our experience with that flatpak is with --device=all, DVDs work 
fine... So I don't quite understand the concern.

> There are multiple ways to fix or work-around this problem:
> 1) Call bindtextdomain() again for those domains which don't live in
> /usr. From reading the man page, it seems to overwrite the existing
> directory configured. This is useful if you can modify the program, and
> all the libraries from which you need translations are init'ed at the
> same time

We can't modify the program source - in the general case this will 
always be true of apps obtained via extra data (otherwise why would you 
be doing this?).

> 2) Patch the binary. Easy to do if your locale path will be shorter
> than Debian's. Pretty sure that could be a 'sed' script.

/app/extra is longer than /usr - maybe we need /xtr or something? :P

> 3) Use LD_PRELOAD to intercept bindtextdomain() calls. Also pretty easy
> to do, especially if as you have the libc sources.

Possible but seems almost uglier/worse than patching glibc given we do 
control that.

> <snip>
>> In some other cases, we've patched some libraries like GStreamer in
>> the
>> Flatpak runtime, to eg have a different search path for plugins, but
>> patching glibc (in both the fd.o runtime & also in the Endless OS
>> runtime, where a large part is shared with the system's ostree)
>> seems
>> like a very large sledgehammer to crack this nut.
>
> Pretty sure GStreamer has envvar that will actually affect its search
> path, it's even set in jhbuild:
> $ export | grep GST
> declare -x GST_PLUGIN_PATH_1_0="/home/hadess/Projects/gnome-install/lib/gstreamer-1.0"
> declare -x GST_REGISTRY="/home/hadess/Projects/gnome-install/_jhbuild/gstreamer-0.10.registry"
> declare -x GST_REGISTRY_1_0="/home/hadess/Projects/gnome-install/_jhbuild/gstreamer-1.0.registry"

Oh you're right - I'm sure I remember digging out some kind of Endless 
patch to GStreamer for Alex to include during the hackfest last year, 
some kind of ostree friendliness - to make GStreamer codec extensions 
possible - but I can't remember what it was exactly and I can't find it 
now. Maybe it's gone upstream.

> Cheers

Cheers,
Rob

........................................................................

Robert McQueen  |  +1.415.413.4159  |  Endless <http://endlessm.com/>