<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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). </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Sorry for long post, please see my previous ones on technical issues that we currently face.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">As for latest state:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Test browser that I can run is executed with:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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 <a href="http://together.jolla.com">together.jolla.com</a><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">libhybris compiled with specification of default hybris-ld-library-path, content of libexec/droid-hybris added with GL extension.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Cheers,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Rinigus</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 29, 2019 at 9:26 PM E.S. Rosenberg <<a href="mailto:es.rosenberg%2Bsailfishos.org@gmail.com">es.rosenberg+sailfishos.org@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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).</div><div>Flatpacks and snaps are security nightmares, instead of getting them lets work on moving the SFOS platform along.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op zo 29 dec. 2019 om 20:41 schreef rinigus <<a href="mailto:rinigus.git@gmail.com" target="_blank">rinigus.git@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi,<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If you refer to <a href="http://flatkill.org/" target="_blank">http://flatkill.org/</a> , 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?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Cheers,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Rinigus</div><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 29, 2019 at 8:26 PM E.S. Rosenberg <<a href="mailto:es.rosenberg%2Bsailfishos.org@gmail.com" target="_blank">es.rosenberg+sailfishos.org@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>No one is bothered by the serious (bad) security implications of running flatpacks?</div><div>Though I guess we are all tolerating the claim to "security" on ancient kernels so we have no right to blab about security now 🤔</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op za 28 dec. 2019 om 12:04 schreef rinigus <<a href="mailto:rinigus.git@gmail.com" target="_blank">rinigus.git@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi,<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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) </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[2294832.935] wl_pointer@8.motion(207667, 0.000000, 0.000000)<br>[2299966.213] qt_extended_surface@29.onscreen_visibility(1)<br>[2303645.301] qt_extended_surface@29.onscreen_visibility(0)<br>[2303647.486]  -> wl_surface@26.destroy()<br>[2303648.296]  -> wl_buffer@4278190080.destroy()<br>[2303648.395]  -> wl_buffer@4278190082.destroy()<br>[2303648.448]  -> wl_buffer@4278190081.destroy()<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">and the app window disappears from qxcomposer.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Same happens when running directly using SFOS composer:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[2614530.331] qt_extended_surface@29.onscreen_visibility(0)<br>[2614552.802]  -> wl_surface@26.destroy()<br>[2614555.653]  -> wl_buffer@4278190080.destroy()<br>[2614556.795]  -> wl_buffer@4278190082.destroy()<br>[2614557.099]  -> wl_buffer@4278190081.destroy()<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So, looks like the surface gets destroyed, but nothing really restores it.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">As such, some kind of wrapper, similar to qxcomposer, around Flatpak programs maybe handy. It could take few tasks, such as </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">- follow orientation of the screen</div><div class="gmail_default" style="font-size:small">- restore app after wl_buffer.destroy()</div><div class="gmail_default" style="font-size:small">- provide keyboard support</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Cheers,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Rinigus</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Dec 28, 2019 at 12:54 AM Damien Caliste <<a href="mailto:dcaliste@free.fr" target="_blank">dcaliste@free.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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 (<a href="https://git.sailfishos.org/mer-core/qtwayland/tree/mer-5.9" rel="noreferrer" target="_blank">https://git.sailfishos.org/mer-core/qtwayland/tree/mer-5.9</a>), 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.<br>
<br>
Damien. <br>
_______________________________________________<br>
SailfishOS.org Devel mailing list<br>
To unsubscribe, please send a mail to <a href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.sailfishos.org</a></blockquote></div>
_______________________________________________<br>
SailfishOS.org Devel mailing list<br>
To unsubscribe, please send a mail to <a href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.sailfishos.org</a></blockquote></div>
_______________________________________________<br>
SailfishOS.org Devel mailing list<br>
To unsubscribe, please send a mail to <a href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.sailfishos.org</a></blockquote></div>
_______________________________________________<br>
SailfishOS.org Devel mailing list<br>
To unsubscribe, please send a mail to <a href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.sailfishos.org</a></blockquote></div>
_______________________________________________<br>
SailfishOS.org Devel mailing list<br>
To unsubscribe, please send a mail to <a href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.sailfishos.org</a></blockquote></div>