[SailfishDevel] Flatpak for Sailfish

Sun Jan 5 10:46:35 UTC 2020

Hi,

I have moved all repositories required for Flatpak support to
https://github.com/sailfishos-flatpak . Documentation is available at
https://github.com/sailfishos-flatpak/main describing how to install and
develop using this environment. Issues are expected to be filed fixed under
https://github.com/sailfishos-flatpak/main and, when appropriate, under
https://github.com/sailfishos-flatpak/flatpak-runner. I tried to list all
current issues under those repositories.

I have also opened a thread at TMO (
http://talk.maemo.org/showthread.php?p=1564143) for those who prefer that
way of communication.

Cheers,

Rinigus

On Sat, Jan 4, 2020 at 10:22 AM rinigus <rinigus.git at gmail.com> wrote:

> Excellent! If something in kernel config is missing, I expect that you
> could use Xperia 10 as a base to check the settings or for Xperia XZ2 used
> by me at
> https://github.com/sailfishos-sony-tama/android_kernel_sony_msm/blob/hybris-sony-aosp-9.0.0-4.9-tama-sony/arch/arm64/configs/aosp_tama_akari_defconfig
>
> Rinigus
>
> On Sat, Jan 4, 2020 at 12:47 AM Adam Pigg <adam at piggz.co.uk> wrote:
>
>> Ill build it on mido and try it out, thanks!
>>
>> On Fri, 3 Jan 2020 at 22:45, rinigus <rinigus.git at gmail.com> wrote:
>>
>>> 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
>>>>>
>>>>> _______________________________________________
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20200105/7e804dd6/attachment-0001.html>