If it's only in libhybris, then it's not device specific? Which exactly kernel options need to be turned on for it? Or I'm totally confused
On Sunday, 5 January 2020, rinigus wrote: > Hi, > > I think that the patch suggested for libhybris is a bugfix. So, I hope it > will be merged and distributed with one of the next SFOS updates. Assuming > that Jolla C is still getting updates, you should get it too. > > Now, libhybris bug is in the linker, as you can see from my PR. I don't > know how device-specific it is, hopefully knowledgeable porters can chip in > and comment on it. If its not device specific then we can just package the > linker and use the rest as it is on device. > > Let's see what the next few days bring. I presume many of developers are > back from holidays next week which could speed up the response. > > Cheers, > > Rinigus > > > > On Sun, Jan 5, 2020 at 10:52 PM <szo...@gmail.com> wrote: > > > 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....@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 > > > > > > > > > > > > > > > -- > > Sent from my Jolla > > _______________________________________________ > > 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
