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....@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....@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....@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....@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@8.motion(207667, 0.000000, 0.000000) > >>>> [2299966.213] qt_extended_surface@29.onscreen_visibility(1) > >>>> [2303645.301] qt_extended_surface@29.onscreen_visibility(0) > >>>> [2303647.486] -> wl_surface@26.destroy() > >>>> [2303648.296] -> wl_buffer@4278190080.destroy() > >>>> [2303648.395] -> wl_buffer@4278190082.destroy() > >>>> [2303648.448] -> wl_buffer@4278190081.destroy() > >>>> > >>>> and the app window disappears from qxcomposer. > >>>> > >>>> Same happens when running directly using SFOS composer: > >>>> > >>>> [2614530.331] qt_extended_surface@29.onscreen_visibility(0) > >>>> [2614552.802] -> wl_surface@26.destroy() > >>>> [2614555.653] -> wl_buffer@4278190080.destroy() > >>>> [2614556.795] -> wl_buffer@4278190082.destroy() > >>>> [2614557.099] -> wl_buffer@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 <dcali...@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-unsubscr...@lists.sailfishos.org > >>>> > >>>> _______________________________________________ > >>>> SailfishOS.org Devel mailing list > >>>> To unsubscribe, please send a mail to > >>>> devel-unsubscr...@lists.sailfishos.org > >>> > >>> _______________________________________________ > >>> SailfishOS.org Devel mailing list > >>> To unsubscribe, please send a mail to > >>> devel-unsubscr...@lists.sailfishos.org > >> > >> _______________________________________________ > >> SailfishOS.org Devel mailing list > >> To unsubscribe, please send a mail to > >> devel-unsubscr...@lists.sailfishos.org > > > > _______________________________________________ > > SailfishOS.org Devel mailing list > > To unsubscribe, please send a mail to > > devel-unsubscr...@lists.sailfishos.org > -- Sent from my Jolla _______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
