<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 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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</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, Jan 5, 2020 at 10:52 PM <<a href="mailto:szopin@gmail.com">szopin@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">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?<br>
<br>
Thanks in advance,<br>
szopin<br>
<br>
On Sunday, 5 January 2020, rinigus wrote:<br>
> Hi,<br>
> <br>
> I have moved all repositories required for Flatpak support to<br>
> <a href="https://github.com/sailfishos-flatpak" rel="noreferrer" target="_blank">https://github.com/sailfishos-flatpak</a> . Documentation is available at<br>
> <a href="https://github.com/sailfishos-flatpak/main" rel="noreferrer" target="_blank">https://github.com/sailfishos-flatpak/main</a> describing how to install and<br>
> develop using this environment. Issues are expected to be filed fixed under<br>
> <a href="https://github.com/sailfishos-flatpak/main" rel="noreferrer" target="_blank">https://github.com/sailfishos-flatpak/main</a> and, when appropriate, under<br>
> <a href="https://github.com/sailfishos-flatpak/flatpak-runner" rel="noreferrer" target="_blank">https://github.com/sailfishos-flatpak/flatpak-runner</a>. I tried to list all<br>
> current issues under those repositories.<br>
> <br>
> I have also opened a thread at TMO (<br>
> <a href="http://talk.maemo.org/showthread.php?p=1564143" rel="noreferrer" target="_blank">http://talk.maemo.org/showthread.php?p=1564143</a>) for those who prefer that<br>
> way of communication.<br>
> <br>
> Cheers,<br>
> <br>
> Rinigus<br>
> <br>
> On Sat, Jan 4, 2020 at 10:22 AM rinigus <<a href="mailto:rinigus.git@gmail.com" target="_blank">rinigus.git@gmail.com</a>> wrote:<br>
> <br>
> > Excellent! If something in kernel config is missing, I expect that you<br>
> > could use Xperia 10 as a base to check the settings or for Xperia XZ2 used<br>
> > by me at<br>
> > <a href="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" rel="noreferrer" target="_blank">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</a><br>
> ><br>
> > Rinigus<br>
> ><br>
> > On Sat, Jan 4, 2020 at 12:47 AM Adam Pigg <<a href="mailto:adam@piggz.co.uk" target="_blank">adam@piggz.co.uk</a>> wrote:<br>
> ><br>
> >> Ill build it on mido and try it out, thanks!<br>
> >><br>
> >> On Fri, 3 Jan 2020 at 22:45, rinigus <<a href="mailto:rinigus.git@gmail.com" target="_blank">rinigus.git@gmail.com</a>> wrote:<br>
> >><br>
> >>> Hi,<br>
> >>><br>
> >>> I have submitted PR to libhybris allowing to use Flatpak on hybris<br>
> >>> devices with the same version serving its main purpose and inside Flatpak<br>
> >>> sandbox: <a href="https://github.com/libhybris/libhybris/pull/433" rel="noreferrer" target="_blank">https://github.com/libhybris/libhybris/pull/433</a>.<br>
> >>><br>
> >>> As soon as your device has such libhybris, you could<br>
> >>><br>
> >>> - use <a href="https://build.merproject.org/project/show/home:rinigus:flatpak" rel="noreferrer" target="_blank">https://build.merproject.org/project/show/home:rinigus:flatpak</a> to<br>
> >>> install flatpak, flatpak-runner<br>
> >>> - run flatpak-extension-hybris to generate Flatpah hybris extension at<br>
> >>> user nemo's home (run as nemo)<br>
> >>> - install flatpak apps, see instructions at Flathub on how to do it<br>
> >>> - run them using flatpak-runner<br>
> >>><br>
> >>> Many things don't work, but would be faster to get it fixed together<br>
> >>> with other devs.<br>
> >>><br>
> >>> Cheers.<br>
> >>><br>
> >>> Rinigus<br>
> >>><br>
> >>> On Fri, Jan 3, 2020 at 12:18 AM rinigus <<a href="mailto:rinigus.git@gmail.com" target="_blank">rinigus.git@gmail.com</a>> wrote:<br>
> >>><br>
> >>>> Hi,<br>
> >>>><br>
> >>>> just finished the first version of a wrapper for 'flatpak run' command<br>
> >>>> as well, available at <a href="https://github.com/rinigus/flatpak-runner" rel="noreferrer" target="_blank">https://github.com/rinigus/flatpak-runner</a> . Its<br>
> >>>> based on qxcompositor and it opens new Wayland server before running an<br>
> >>>> application, all explained in README. Device rotation is supported and<br>
> >>>> should be followed.<br>
> >>>><br>
> >>>> So, as it is:<br>
> >>>><br>
> >>>> - we have to resolve libhybris linker issue to make it possible to<br>
> >>>> distribute.<br>
> >>>> - keyboard is not supported currently. At present, app has to have<br>
> >>>> qtvirtualkeyboard support added as in<br>
> >>>> <a href="https://doc.qt.io/qt-5/qtvirtualkeyboard-deployment-guide.html#creating-inputpanel" rel="noreferrer" target="_blank">https://doc.qt.io/qt-5/qtvirtualkeyboard-deployment-guide.html#creating-inputpanel</a><br>
> >>>> .<br>
> >>>> - only single-window apps are working well, such as QML developed for<br>
> >>>> mobile<br>
> >>>> - no sound so far<br>
> >>>> - probably many other things are missing, haven't bumped into them.<br>
> >>>><br>
> >>>> Essentially, we will have access to the latest Qt, but would have to<br>
> >>>> write apps for this use. Fortunately, it all goes along SFOS programming<br>
> >>>> and should be simple to convert later to Silica, when/if it catches up with<br>
> >>>> Qt versions.<br>
> >>>><br>
> >>>> I guess we can get better integration after it will be simple to<br>
> >>>> install on other devices and start using it by others.<br>
> >>>><br>
> >>>> Cheers,<br>
> >>>><br>
> >>>> Rinigus<br>
> >>>><br>
> >>>> On Wed, Jan 1, 2020 at 5:25 PM rinigus <<a href="mailto:rinigus.git@gmail.com" target="_blank">rinigus.git@gmail.com</a>> wrote:<br>
> >>>><br>
> >>>>> Hi,<br>
> >>>>><br>
> >>>>> wait a bit, I may have a way to simplify setup. Few days ago, after<br>
> >>>>> discussion on IRC, I found a way around disappearance of the window when<br>
> >>>>> wrapped into qxcomposer. So, that blocker is over now. Which means that we<br>
> >>>>> will be able to craft apps using the latest Qt available in Flatpaks.<br>
> >>>>><br>
> >>>>> Currently, I am looking into<br>
> >>>>><br>
> >>>>> - how we can use regular hybris<br>
> >>>>> - making a wrapper similar to qxcomposer for Flatpaks.<br>
> >>>>><br>
> >>>>> Shouldn't take too long for an update on status.<br>
> >>>>><br>
> >>>>> Cheers,<br>
> >>>>><br>
> >>>>> Rinigus<br>
> >>>>><br>
> >>>>> On Wed, Jan 1, 2020 at 4:55 PM <<a href="mailto:szopin@gmail.com" target="_blank">szopin@gmail.com</a>> wrote:<br>
> >>>>><br>
> >>>>>> Could you elaborate on:<br>
> >>>>>> > libhybris compiled with specification of default<br>
> >>>>>> hybris-ld-library-path,<br>
> >>>>>> > content of libexec/droid-hybris added with GL extension.<br>
> >>>>>> Is that libhybris build available (and safe to run on main device, or<br>
> >>>>>> should I dig out my j1)?<br>
> >>>>>> Also not sure what added with GL extension means? Having a browser<br>
> >>>>>> that uses up to date webengine would be awesome.<br>
> >>>>>><br>
> >>>>>> Thanks and happy new year!<br>
> >>>>>> szopin<br>
> >>>>>><br>
> >>>>>> On Sunday, 29 December 2019, rinigus wrote:<br>
> >>>>>> > Hi,<br>
> >>>>>> ><br>
> >>>>>> > I would have preferred to stay away from discussion on why do we<br>
> >>>>>> need/not<br>
> >>>>>> > need Flatpak on SFOS. But I guess I have to take it as the one<br>
> >>>>>> working on<br>
> >>>>>> > making it possible.<br>
> >>>>>> ><br>
> >>>>>> > Native apps rely on the libs allowed in the Store and bundle the<br>
> >>>>>> rest of<br>
> >>>>>> > them. I presume OSM Scout Server and Pure Maps are exceptions, but<br>
> >>>>>> they are<br>
> >>>>>> > built around almost 20 libs bundled with the application and<br>
> >>>>>> compiled with<br>
> >>>>>> > newer gcc than the one on the platform. If I would have continued to<br>
> >>>>>> > provide OSM Scout Server via the official Store, I'd have to bundle<br>
> >>>>>> > libsystemd as well - something that I found was crossing a line for<br>
> >>>>>> me. So,<br>
> >>>>>> > any security issue in those bundled libs would be propagated the<br>
> >>>>>> same way<br>
> >>>>>> > as with the Flatpak. I admit that its way less libs than<br>
> >>>>>> distributed via<br>
> >>>>>> > Flatpak. However, in the case of Flatpak, apps are provided on the<br>
> >>>>>> top of<br>
> >>>>>> > "runtimes" with the app including everything which is extending the<br>
> >>>>>> runtime<br>
> >>>>>> > to make it work. So, in case of OSM Scout Server and Pure Maps,<br>
> >>>>>> their<br>
> >>>>>> > Flatpaks do include some libs as well. Those runtimes are updated.<br>
> >>>>>> Now, I<br>
> >>>>>> > am not in position to say whether its security updates are as fast<br>
> >>>>>> as of<br>
> >>>>>> > distros and have no idea how it compares to SFOS.<br>
> >>>>>> ><br>
> >>>>>> > However, I see mainly portability and up-to-date toolbox aspect of<br>
> >>>>>> Flatpak,<br>
> >>>>>> > not that much security in terms of sandbox. These are my<br>
> >>>>>> preferences and<br>
> >>>>>> > they could differ from yours.<br>
> >>>>>> ><br>
> >>>>>> > Looking at the speed of upcoming Qt update, I was considering<br>
> >>>>>> whether to<br>
> >>>>>> > make qt5.12 (or later) in /opt (/home/opt) and use it from there to<br>
> >>>>>> allow<br>
> >>>>>> > us to work on newer browser engine or make Flatpak available. The<br>
> >>>>>> both<br>
> >>>>>> > solutions would break look-and-feel of SFOS, but allow us to use<br>
> >>>>>> current<br>
> >>>>>> > libs, something that we have been missing for too long. And, in many<br>
> >>>>>> > aspects, we, as developers, waste lot of time to fight against. I<br>
> >>>>>> swayed<br>
> >>>>>> > towards Flatpaks as it has well developed tools around it, provides<br>
> >>>>>> > portability (you can run it on desktop), and will make sense to<br>
> >>>>>> have when<br>
> >>>>>> > other mobile Linux distros will start going as a way to use the<br>
> >>>>>> same app at<br>
> >>>>>> > all of them.<br>
> >>>>>> ><br>
> >>>>>> > Note that is we develop apps immediately with the reservation that<br>
> >>>>>> we could<br>
> >>>>>> > switch to a native version as soon as it is ready to receive it (in<br>
> >>>>>> terms<br>
> >>>>>> > of Qt version, for example), we can start working on things that are<br>
> >>>>>> > impossible right now on SFOS but may become available later (Qt<br>
> >>>>>> 5.12?). I<br>
> >>>>>> > would expect that this much better than using Android browser on<br>
> >>>>>> SFOS.<br>
> >>>>>> ><br>
> >>>>>> > Please note that it is not to criticize Jolla regarding the update<br>
> >>>>>> speed of<br>
> >>>>>> > Qt. Its probably a complex process and, as we have all built around<br>
> >>>>>> it, may<br>
> >>>>>> > break few things to put it mildly. But a large part of my work as a<br>
> >>>>>> > developer on SFOS is around incompatibilities imposed by old libs<br>
> >>>>>> and gcc.<br>
> >>>>>> > So, from developer POV, its important to prioritize Qt update as<br>
> >>>>>> much as<br>
> >>>>>> > possible. Not sure how much we can help with it, but that's probably<br>
> >>>>>> > separate discussion (please start it if you wish).<br>
> >>>>>> ><br>
> >>>>>> > Sorry for long post, please see my previous ones on technical<br>
> >>>>>> issues that<br>
> >>>>>> > we currently face.<br>
> >>>>>> ><br>
> >>>>>> > As for latest state:<br>
> >>>>>> ><br>
> >>>>>> > Test browser that I can run is executed with:<br>
> >>>>>> ><br>
> >>>>>> > QT_WAYLAND_FORCE_DPI=physical flatpak run --filesystem=host<br>
> >>>>>> --device=all<br>
> >>>>>> ><br>
> >>>>>> --env=HYBRIS_EGLPLATFORM_DIR=/usr/lib/arm-linux-gnueabihf/GL/default/lib/libhybris<br>
> >>>>>> ><br>
> >>>>>> --env=HYBRIS_LINKER_DIR=/usr/lib/arm-linux-gnueabihf/GL/default/lib/libhybris/linker<br>
> >>>>>> > org.qutebrowser.qutebrowser <a href="http://together.jolla.com" rel="noreferrer" target="_blank">together.jolla.com</a><br>
> >>>>>> ><br>
> >>>>>> > libhybris compiled with specification of default<br>
> >>>>>> hybris-ld-library-path,<br>
> >>>>>> > content of libexec/droid-hybris added with GL extension.<br>
> >>>>>> ><br>
> >>>>>> > Cheers,<br>
> >>>>>> ><br>
> >>>>>> > Rinigus<br>
> >>>>>> ><br>
> >>>>>> ><br>
> >>>>>> ><br>
> >>>>>> > On Sun, Dec 29, 2019 at 9:26 PM E.S. Rosenberg <<br>
> >>>>>> > <a href="mailto:es.rosenberg%2Bsailfishos.org@gmail.com" target="_blank">es.rosenberg+sailfishos.org@gmail.com</a>> wrote:<br>
> >>>>>> ><br>
> >>>>>> > > Native apps rely on the libs shipped with the OS, thus they don't<br>
> >>>>>> ship<br>
> >>>>>> > > with unsecure libs unless Jolla is shipping them and they become<br>
> >>>>>> secure the<br>
> >>>>>> > > moment Jolla updated the libs (and should the update break binary<br>
> >>>>>> > > compatibility will require a new release compiled against the new<br>
> >>>>>> libs).<br>
> >>>>>> > > Flatpacks and snaps are security nightmares, instead of getting<br>
> >>>>>> them lets<br>
> >>>>>> > > work on moving the SFOS platform along.<br>
> >>>>>> > ><br>
> >>>>>> > > Op zo 29 dec. 2019 om 20:41 schreef rinigus <<br>
> >>>>>> <a href="mailto:rinigus.git@gmail.com" target="_blank">rinigus.git@gmail.com</a>>:<br>
> >>>>>> > ><br>
> >>>>>> > >> Hi,<br>
> >>>>>> > >><br>
> >>>>>> > >> If you refer to <a href="http://flatkill.org/" rel="noreferrer" target="_blank">http://flatkill.org/</a> , it does have lot of good<br>
> >>>>>> points.<br>
> >>>>>> > >> In this respect, its similar to what we have with the native<br>
> >>>>>> apps, as soon<br>
> >>>>>> > >> as some security flaws are used. At the moment, I would prefer<br>
> >>>>>> to get<br>
> >>>>>> > >> access to the latest Qt and other recent software. But users are<br>
> >>>>>> still<br>
> >>>>>> > >> responsible for thinking before installing, as they are now.<br>
> >>>>>> Note that in<br>
> >>>>>> > >> many aspects our current packaging together with bundled libs is<br>
> >>>>>> similar to<br>
> >>>>>> > >> flatpak already. So, why not to make it with the recent libs as<br>
> >>>>>> well?<br>
> >>>>>> > >><br>
> >>>>>> > >> Cheers,<br>
> >>>>>> > >><br>
> >>>>>> > >> Rinigus<br>
> >>>>>> > >><br>
> >>>>>> > >><br>
> >>>>>> > >> On Sun, Dec 29, 2019 at 8:26 PM E.S. Rosenberg <<br>
> >>>>>> > >> <a href="mailto:es.rosenberg%2Bsailfishos.org@gmail.com" target="_blank">es.rosenberg+sailfishos.org@gmail.com</a>> wrote:<br>
> >>>>>> > >><br>
> >>>>>> > >>> No one is bothered by the serious (bad) security implications<br>
> >>>>>> of running<br>
> >>>>>> > >>> flatpacks?<br>
> >>>>>> > >>> Though I guess we are all tolerating the claim to "security" on<br>
> >>>>>> ancient<br>
> >>>>>> > >>> kernels so we have no right to blab about security now 🤔<br>
> >>>>>> > >>><br>
> >>>>>> > >>> Op za 28 dec. 2019 om 12:04 schreef rinigus <<br>
> >>>>>> <a href="mailto:rinigus.git@gmail.com" target="_blank">rinigus.git@gmail.com</a>>:<br>
> >>>>>> > >>><br>
> >>>>>> > >>>> Hi,<br>
> >>>>>> > >>>><br>
> >>>>>> > >>>> I am not 100% sure whether xdg-shell availability is the<br>
> >>>>>> blocker. There<br>
> >>>>>> > >>>> is something going on which I cannot explain yet - its as if<br>
> >>>>>> Wayland<br>
> >>>>>> > >>>> rendering disappears even when I use qxcomposer.<br>
> >>>>>> > >>>><br>
> >>>>>> > >>>> qxcomposer does allow me to minimize and then restore.<br>
> >>>>>> However, when<br>
> >>>>>> > >>>> keeping app minimized and switching to other apps, I do get<br>
> >>>>>> (with<br>
> >>>>>> > >>>> WAYLAND_DEBUG=1)<br>
> >>>>>> > >>>><br>
> >>>>>> > >>>> [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>
> >>>>>> > >>>><br>
> >>>>>> > >>>> and the app window disappears from qxcomposer.<br>
> >>>>>> > >>>><br>
> >>>>>> > >>>> Same happens when running directly using SFOS composer:<br>
> >>>>>> > >>>><br>
> >>>>>> > >>>> [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>
> >>>>>> > >>>><br>
> >>>>>> > >>>> So, looks like the surface gets destroyed, but nothing really<br>
> >>>>>> restores<br>
> >>>>>> > >>>> it.<br>
> >>>>>> > >>>><br>
> >>>>>> > >>>> As such, some kind of wrapper, similar to qxcomposer, around<br>
> >>>>>> Flatpak<br>
> >>>>>> > >>>> programs maybe handy. It could take few tasks, such as<br>
> >>>>>> > >>>><br>
> >>>>>> > >>>> - follow orientation of the screen<br>
> >>>>>> > >>>> - restore app after wl_buffer.destroy()<br>
> >>>>>> > >>>> - provide keyboard support<br>
> >>>>>> > >>>><br>
> >>>>>> > >>>> I don't know enough about Wayland to be efficient in working<br>
> >>>>>> on it. So,<br>
> >>>>>> > >>>> I wonder if someone would like to step in and help with this<br>
> >>>>>> part. If there<br>
> >>>>>> > >>>> is interest, I will work on packaging libhybris extension and<br>
> >>>>>> provide an<br>
> >>>>>> > >>>> example at OBS for Xperia Tama devices.<br>
> >>>>>> > >>>><br>
> >>>>>> > >>>> Cheers,<br>
> >>>>>> > >>>><br>
> >>>>>> > >>>> Rinigus<br>
> >>>>>> > >>>><br>
> >>>>>> > >>>> On Sat, Dec 28, 2019 at 12:54 AM Damien Caliste <<br>
> >>>>>> <a href="mailto:dcaliste@free.fr" target="_blank">dcaliste@free.fr</a>><br>
> >>>>>> > >>>> wrote:<br>
> >>>>>> > >>>><br>
> >>>>>> > >>>>> Thank you Rinigus for all of this. Indeed, the current main<br>
> >>>>>> blocker<br>
> >>>>>> > >>>>> seems to be the fact that xdg-shell is not available in<br>
> >>>>>> Lipstick. This is<br>
> >>>>>> > >>>>> linked to the ancient version of QtWayland, even not 5.6, but<br>
> >>>>>> still 5.4 !<br>
> >>>>>> > >>>>> They already have a 5.9 branch in SailfishOS git (<br>
> >>>>>> > >>>>> <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>),<br>
> >>>>>> but we<br>
> >>>>>> > >>>>> need to wait for Jolla to make the Qt switch. I don't think<br>
> >>>>>> it's something<br>
> >>>>>> > >>>>> community can change on device... I hope I can be proven<br>
> >>>>>> wrong though.<br>
> >>>>>> > >>>>><br>
> >>>>>> > >>>>> Damien.<br>
> >>>>>> > >>>>> _______________________________________________<br>
> >>>>>> > >>>>> SailfishOS.org Devel mailing list<br>
> >>>>>> > >>>>> To unsubscribe, please send a mail to<br>
> >>>>>> > >>>>> <a href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.sailfishos.org</a><br>
> >>>>>> > >>>><br>
> >>>>>> > >>>> _______________________________________________<br>
> >>>>>> > >>>> SailfishOS.org Devel mailing list<br>
> >>>>>> > >>>> To unsubscribe, please send a mail to<br>
> >>>>>> > >>>> <a href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.sailfishos.org</a><br>
> >>>>>> > >>><br>
> >>>>>> > >>> _______________________________________________<br>
> >>>>>> > >>> SailfishOS.org Devel mailing list<br>
> >>>>>> > >>> To unsubscribe, please send a mail to<br>
> >>>>>> > >>> <a href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.sailfishos.org</a><br>
> >>>>>> > >><br>
> >>>>>> > >> _______________________________________________<br>
> >>>>>> > >> SailfishOS.org Devel mailing list<br>
> >>>>>> > >> To unsubscribe, please send a mail to<br>
> >>>>>> > >> <a href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.sailfishos.org</a><br>
> >>>>>> > ><br>
> >>>>>> > > _______________________________________________<br>
> >>>>>> > > SailfishOS.org Devel mailing list<br>
> >>>>>> > > To unsubscribe, please send a mail to<br>
> >>>>>> > > <a href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.sailfishos.org</a><br>
> >>>>>> ><br>
> >>>>>><br>
> >>>>>> --<br>
> >>>>>> Sent from my Jolla<br>
> >>>>>> _______________________________________________<br>
> >>>>>> SailfishOS.org Devel mailing list<br>
> >>>>>> To unsubscribe, please send a mail to<br>
> >>>>>> <a href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.sailfishos.org</a><br>
> >>>>><br>
> >>>>> _______________________________________________<br>
> >>> SailfishOS.org Devel mailing list<br>
> >>> To unsubscribe, please send a mail to<br>
> >>> <a href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.sailfishos.org</a><br>
> >><br>
> >> _______________________________________________<br>
> >> SailfishOS.org Devel mailing list<br>
> >> To unsubscribe, please send a mail to<br>
> >> <a href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.sailfishos.org</a><br>
> ><br>
> ><br>
><br>
<br>
-- <br>
Sent from my Jolla<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>