[SailfishDevel] Flatpak for Sailfish

rinigus rinigus.git at gmail.com
Sat Jan 4 08:22:42 UTC 2020


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/20200104/044efd22/attachment-0001.html>


More information about the Devel mailing list