[SailfishDevel] Flatpak for Sailfish

szopin at gmail.com szopin at gmail.com
Wed Jan 1 14:55:44 UTC 2020


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


More information about the Devel mailing list