[SailfishDevel] Flatpak for Sailfish

rinigus rinigus.git at gmail.com
Fri Jan 3 22:45:20 UTC 2020


Hi,

I have submitted PR to libhybris allowing to use Flatpak on hybris devices
with the same version serving its main purpose and inside Flatpak sandbox:
https://github.com/libhybris/libhybris/pull/433.

As soon as your device has such libhybris, you could

- use https://build.merproject.org/project/show/home:rinigus:flatpak to
install flatpak, flatpak-runner
- run flatpak-extension-hybris to generate Flatpah hybris extension at user
nemo's home (run as nemo)
- install flatpak apps, see instructions at Flathub on how to do it
- run them using flatpak-runner

Many things don't work, but would be faster to get it fixed together with
other devs.

Cheers.

Rinigus

On Fri, Jan 3, 2020 at 12:18 AM rinigus <rinigus.git at gmail.com> wrote:

> Hi,
>
> just finished the first version of a wrapper for 'flatpak run' command as
> well, available at https://github.com/rinigus/flatpak-runner . Its based
> on qxcompositor and it opens new Wayland server before running an
> application, all explained in README. Device rotation is supported and
> should be followed.
>
> So, as it is:
>
> - we have to resolve libhybris linker issue to make it possible to
> distribute.
> - keyboard is not supported currently. At present, app has to have
> qtvirtualkeyboard support added as in
> https://doc.qt.io/qt-5/qtvirtualkeyboard-deployment-guide.html#creating-inputpanel
> .
> - only single-window apps are working well, such as QML developed for
> mobile
> - no sound so far
> - probably many other things are missing, haven't bumped into them.
>
> Essentially, we will have access to the latest Qt, but would have to write
> apps for this use. Fortunately, it all goes along SFOS programming and
> should be simple to convert later to Silica, when/if it catches up with Qt
> versions.
>
> I guess we can get better integration after it will be simple to install
> on other devices and start using it by others.
>
> Cheers,
>
> Rinigus
>
> On Wed, Jan 1, 2020 at 5:25 PM rinigus <rinigus.git at gmail.com> wrote:
>
>> Hi,
>>
>> wait a bit, I may have a way to simplify setup. Few days ago, after
>> discussion on IRC, I found a way around disappearance of the window when
>> wrapped into qxcomposer. So, that blocker is over now. Which means that we
>> will be able to craft apps using the latest Qt available in Flatpaks.
>>
>> Currently, I am looking into
>>
>> - how we can use regular hybris
>> - making a wrapper similar to qxcomposer for Flatpaks.
>>
>> Shouldn't take too long for an update on status.
>>
>> Cheers,
>>
>> Rinigus
>>
>> On Wed, Jan 1, 2020 at 4:55 PM <szopin at gmail.com> wrote:
>>
>>> Could you elaborate on:
>>> > libhybris compiled with specification of default
>>> hybris-ld-library-path,
>>> > content of libexec/droid-hybris added with GL extension.
>>> Is that libhybris build available (and safe to run on main device, or
>>> should I dig out my j1)?
>>> Also not sure what added with GL extension means? Having a browser that
>>> uses up to date webengine would be awesome.
>>>
>>> Thanks and happy new year!
>>> szopin
>>>
>>> On Sunday, 29 December 2019, rinigus wrote:
>>> > Hi,
>>> >
>>> > I would have preferred to stay away from discussion on why do we
>>> need/not
>>> > need Flatpak on SFOS. But I guess I have to take it as the one working
>>> on
>>> > making it possible.
>>> >
>>> > Native apps rely on the libs allowed in the Store and bundle the rest
>>> of
>>> > them. I presume OSM Scout Server and Pure Maps are exceptions, but
>>> they are
>>> > built around almost 20 libs bundled with the application and compiled
>>> with
>>> > newer gcc than the one on the platform. If I would have continued to
>>> > provide OSM Scout Server via the official Store, I'd have to bundle
>>> > libsystemd as well - something that I found was crossing a line for
>>> me. So,
>>> > any security issue in those bundled libs would be propagated the same
>>> way
>>> > as with the Flatpak. I admit that its way less libs than distributed
>>> via
>>> > Flatpak. However, in the case of Flatpak, apps are provided on the top
>>> of
>>> > "runtimes" with the app including everything which is extending the
>>> runtime
>>> > to make it work. So, in case of OSM Scout Server and Pure Maps, their
>>> > Flatpaks do include some libs as well. Those runtimes are updated.
>>> Now, I
>>> > am not in position to say whether its security updates are as fast as
>>> of
>>> > distros and have no idea how it compares to SFOS.
>>> >
>>> > However, I see mainly portability and up-to-date toolbox aspect of
>>> Flatpak,
>>> > not that much security in terms of sandbox. These are my preferences
>>> and
>>> > they could differ from yours.
>>> >
>>> > Looking at the speed of upcoming Qt update, I was considering whether
>>> to
>>> > make qt5.12 (or later) in /opt (/home/opt) and use it from there to
>>> allow
>>> > us to work on newer browser engine or make Flatpak available. The both
>>> > solutions would break look-and-feel of SFOS, but allow us to use
>>> current
>>> > libs, something that we have been missing for too long. And, in many
>>> > aspects, we, as developers, waste lot of time to fight against. I
>>> swayed
>>> > towards Flatpaks as it has well developed tools around it, provides
>>> > portability (you can run it on desktop), and will make sense to have
>>> when
>>> > other mobile Linux distros will start going as a way to use the same
>>> app at
>>> > all of them.
>>> >
>>> > Note that is we develop apps immediately with the reservation that we
>>> could
>>> > switch to a native version as soon as it is ready to receive it (in
>>> terms
>>> > of Qt version, for example), we can start working on things that are
>>> > impossible right now on SFOS but may become available later (Qt
>>> 5.12?). I
>>> > would expect that this much better than using Android browser on SFOS.
>>> >
>>> > Please note that it is not to criticize Jolla regarding the update
>>> speed of
>>> > Qt. Its probably a complex process and, as we have all built around
>>> it, may
>>> > break few things to put it mildly. But a large part of my work as a
>>> > developer on SFOS is around incompatibilities imposed by old libs and
>>> gcc.
>>> > So, from developer POV, its important to prioritize Qt update as much
>>> as
>>> > possible. Not sure how much we can help with it, but that's probably
>>> > separate discussion (please start it if you wish).
>>> >
>>> > Sorry for long post, please see my previous ones on technical issues
>>> that
>>> > we currently face.
>>> >
>>> > As for latest state:
>>> >
>>> > Test browser that I can run is executed with:
>>> >
>>> > QT_WAYLAND_FORCE_DPI=physical flatpak run --filesystem=host
>>> --device=all
>>> >
>>> --env=HYBRIS_EGLPLATFORM_DIR=/usr/lib/arm-linux-gnueabihf/GL/default/lib/libhybris
>>> >
>>> --env=HYBRIS_LINKER_DIR=/usr/lib/arm-linux-gnueabihf/GL/default/lib/libhybris/linker
>>> > org.qutebrowser.qutebrowser together.jolla.com
>>> >
>>> > libhybris compiled with specification of default
>>> hybris-ld-library-path,
>>> > content of libexec/droid-hybris added with GL extension.
>>> >
>>> > Cheers,
>>> >
>>> > Rinigus
>>> >
>>> >
>>> >
>>> > On Sun, Dec 29, 2019 at 9:26 PM E.S. Rosenberg <
>>> > es.rosenberg+sailfishos.org at gmail.com> wrote:
>>> >
>>> > > Native apps rely on the libs shipped with the OS, thus they don't
>>> ship
>>> > > with unsecure libs unless Jolla is shipping them and they become
>>> secure the
>>> > > moment Jolla updated the libs (and should the update break binary
>>> > > compatibility will require a new release compiled against the new
>>> libs).
>>> > > Flatpacks and snaps are security nightmares, instead of getting them
>>> lets
>>> > > work on moving the SFOS platform along.
>>> > >
>>> > > Op zo 29 dec. 2019 om 20:41 schreef rinigus <rinigus.git at gmail.com>:
>>> > >
>>> > >> Hi,
>>> > >>
>>> > >> If you refer to http://flatkill.org/ , it does have lot of good
>>> points.
>>> > >> In this respect, its similar to what we have with the native apps,
>>> as soon
>>> > >> as some security flaws are used. At the moment, I would prefer to
>>> get
>>> > >> access to the latest Qt and other recent software. But users are
>>> still
>>> > >> responsible for thinking before installing, as they are now. Note
>>> that in
>>> > >> many aspects our current packaging together with bundled libs is
>>> similar to
>>> > >> flatpak already. So, why not to make it with the recent libs as
>>> well?
>>> > >>
>>> > >> Cheers,
>>> > >>
>>> > >> Rinigus
>>> > >>
>>> > >>
>>> > >> On Sun, Dec 29, 2019 at 8:26 PM E.S. Rosenberg <
>>> > >> es.rosenberg+sailfishos.org at gmail.com> wrote:
>>> > >>
>>> > >>> No one is bothered by the serious (bad) security implications of
>>> running
>>> > >>> flatpacks?
>>> > >>> Though I guess we are all tolerating the claim to "security" on
>>> ancient
>>> > >>> kernels so we have no right to blab about security now 🤔
>>> > >>>
>>> > >>> Op za 28 dec. 2019 om 12:04 schreef rinigus <rinigus.git at gmail.com
>>> >:
>>> > >>>
>>> > >>>> Hi,
>>> > >>>>
>>> > >>>> I am not 100% sure whether xdg-shell availability is the blocker.
>>> There
>>> > >>>> is something going on which I cannot explain yet - its as if
>>> Wayland
>>> > >>>> rendering disappears even when I use qxcomposer.
>>> > >>>>
>>> > >>>> qxcomposer does allow me to minimize and then restore. However,
>>> when
>>> > >>>> keeping app minimized and switching to other apps, I do get (with
>>> > >>>> WAYLAND_DEBUG=1)
>>> > >>>>
>>> > >>>> [2294832.935] wl_pointer at 8.motion(207667, 0.000000, 0.000000)
>>> > >>>> [2299966.213] qt_extended_surface at 29.onscreen_visibility(1)
>>> > >>>> [2303645.301] qt_extended_surface at 29.onscreen_visibility(0)
>>> > >>>> [2303647.486]  -> wl_surface at 26.destroy()
>>> > >>>> [2303648.296]  -> wl_buffer at 4278190080.destroy()
>>> > >>>> [2303648.395]  -> wl_buffer at 4278190082.destroy()
>>> > >>>> [2303648.448]  -> wl_buffer at 4278190081.destroy()
>>> > >>>>
>>> > >>>> and the app window disappears from qxcomposer.
>>> > >>>>
>>> > >>>> Same happens when running directly using SFOS composer:
>>> > >>>>
>>> > >>>> [2614530.331] qt_extended_surface at 29.onscreen_visibility(0)
>>> > >>>> [2614552.802]  -> wl_surface at 26.destroy()
>>> > >>>> [2614555.653]  -> wl_buffer at 4278190080.destroy()
>>> > >>>> [2614556.795]  -> wl_buffer at 4278190082.destroy()
>>> > >>>> [2614557.099]  -> wl_buffer at 4278190081.destroy()
>>> > >>>>
>>> > >>>> So, looks like the surface gets destroyed, but nothing really
>>> restores
>>> > >>>> it.
>>> > >>>>
>>> > >>>> As such, some kind of wrapper, similar to qxcomposer, around
>>> Flatpak
>>> > >>>> programs maybe handy. It could take few tasks, such as
>>> > >>>>
>>> > >>>> - follow orientation of the screen
>>> > >>>> - restore app after wl_buffer.destroy()
>>> > >>>> - provide keyboard support
>>> > >>>>
>>> > >>>> I don't know enough about Wayland to be efficient in working on
>>> it. So,
>>> > >>>> I wonder if someone would like to step in and help with this
>>> part. If there
>>> > >>>> is interest, I will work on packaging libhybris extension and
>>> provide an
>>> > >>>> example at OBS for Xperia Tama devices.
>>> > >>>>
>>> > >>>> Cheers,
>>> > >>>>
>>> > >>>> Rinigus
>>> > >>>>
>>> > >>>> On Sat, Dec 28, 2019 at 12:54 AM Damien Caliste <dcaliste at free.fr
>>> >
>>> > >>>> wrote:
>>> > >>>>
>>> > >>>>> Thank you Rinigus for all of this. Indeed, the current main
>>> blocker
>>> > >>>>> seems to be the fact that xdg-shell is not available in
>>> Lipstick. This is
>>> > >>>>> linked to the ancient version of QtWayland, even not 5.6, but
>>> still 5.4 !
>>> > >>>>> They already have a 5.9 branch in SailfishOS git (
>>> > >>>>> https://git.sailfishos.org/mer-core/qtwayland/tree/mer-5.9),
>>> but we
>>> > >>>>> need to wait for Jolla to make the Qt switch. I don't think it's
>>> something
>>> > >>>>> community can change on device... I hope I can be proven wrong
>>> though.
>>> > >>>>>
>>> > >>>>> Damien.
>>> > >>>>> _______________________________________________
>>> > >>>>> SailfishOS.org Devel mailing list
>>> > >>>>> To unsubscribe, please send a mail to
>>> > >>>>> devel-unsubscribe at lists.sailfishos.org
>>> > >>>>
>>> > >>>> _______________________________________________
>>> > >>>> SailfishOS.org Devel mailing list
>>> > >>>> To unsubscribe, please send a mail to
>>> > >>>> devel-unsubscribe at lists.sailfishos.org
>>> > >>>
>>> > >>> _______________________________________________
>>> > >>> SailfishOS.org Devel mailing list
>>> > >>> To unsubscribe, please send a mail to
>>> > >>> devel-unsubscribe at lists.sailfishos.org
>>> > >>
>>> > >> _______________________________________________
>>> > >> SailfishOS.org Devel mailing list
>>> > >> To unsubscribe, please send a mail to
>>> > >> devel-unsubscribe at lists.sailfishos.org
>>> > >
>>> > > _______________________________________________
>>> > > SailfishOS.org Devel mailing list
>>> > > To unsubscribe, please send a mail to
>>> > > devel-unsubscribe at lists.sailfishos.org
>>> >
>>>
>>> --
>>> Sent from my Jolla
>>> _______________________________________________
>>> SailfishOS.org Devel mailing list
>>> To unsubscribe, please send a mail to
>>> devel-unsubscribe at lists.sailfishos.org
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20200104/9a80c294/attachment-0001.html>


More information about the Devel mailing list