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....@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 <a...@piggz.co.uk> wrote: > >> Ill build it on mido and try it out, thanks! >> >> On Fri, 3 Jan 2020 at 22:45, rinigus <rinigus....@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....@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....@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 <szo...@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....@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 >>>>> >>>>> _______________________________________________ >>> 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