[SailfishDevel] Flatpak for Sailfish

Sun Jan 5 20:52:33 UTC 2020

It's device specific? Shame, doubt jolla C can help then. Still hopeful the eventual cosmo communicator edition will support it. Any hints what needs to be enabled in kernel?

Thanks in advance,
szopin

On Sunday, 5 January 2020, rinigus wrote:
> 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
> >
> >
>

-- 
Sent from my Jolla