[SailfishDevel] File Picker
Hi! I am looking for a File Selection dialog that would be * Able to select a directory or a file (specified on call) * Jolla-store compatible * LGPL compatible Maybe someone has recommendations for it? It seems to be a frequent request (https://together.jolla.com/question/321/file-picker-needed/), but I have not seen yet the one that would comply with the requirements (either license is not clear or Qt.labs are used). I probably just missed a decent picker... cheers, rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] File Picker
Андрей, thank you! Would you mind to specify a license on https://github.com/CODeRUS/splashscreen-changer ? At present, there is no license specified, unfortunately. cheers, rinigus On Tue, Nov 29, 2016 at 12:43 PM, Андрей Кожевников wrote: > Hello, for now you can compile and bundle nemo-filemanager plugin: > https://git.merproject.org/mer-core/nemo-qml-plugin-filemanager. I hope > later it will be added to allowed imports. > You can use https://github.com/CODeRUS/splashscreen-changer/blob/ > master/settings/SecondPage.qml as sample of usage. > > 29 нояб. 2016 г. 12:48 пользователь "rinigus" > написал: > >> Hi! >> >> I am looking for a File Selection dialog that would be >> >> * Able to select a directory or a file (specified on call) >> * Jolla-store compatible >> * LGPL compatible >> >> Maybe someone has recommendations for it? It seems to be a frequent >> request (https://together.jolla.com/question/321/file-picker-needed/), >> but I have not seen yet the one that would comply with the requirements >> (either license is not clear or Qt.labs are used). I probably just missed a >> decent picker... >> >> cheers, >> >> rinigus >> >> >> ___ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi >> shos.org >> > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] File Picker
Thank you, good to know. Just would be great to specify it in LICENSE file. Note that RPM spec specifies that mysterious LICENSE at https://github.com/CODeRUS/splashscreen-changer/blob/master/rpm/splashscreen-changer.spec#L12 :) But back to the subject: Andrey, thank you very much for a tip and example code! I'll look into your interface and that would simplify advancing my projects as well. Best wishes, rinigus On Tue, Nov 29, 2016 at 5:59 PM, Andrey Kozhevnikov wrote: > i am using WTFPL for my projects. > > > 29.11.2016 14:26, rinigus пишет: > > Андрей, > > thank you! Would you mind to specify a license on > https://github.com/CODeRUS/splashscreen-changer ? At present, there is no > license specified, unfortunately. > > cheers, > > rinigus > > On Tue, Nov 29, 2016 at 12:43 PM, Андрей Кожевников > wrote: >> >> Hello, for now you can compile and bundle nemo-filemanager plugin: >> https://git.merproject.org/mer-core/nemo-qml-plugin-filemanager. I hope >> later it will be added to allowed imports. >> You can use >> https://github.com/CODeRUS/splashscreen-changer/blob/master/settings/SecondPage.qml >> as sample of usage. >> >> >> 29 нояб. 2016 г. 12:48 пользователь "rinigus" >> написал: >>> >>> Hi! >>> >>> I am looking for a File Selection dialog that would be >>> >>> * Able to select a directory or a file (specified on call) >>> * Jolla-store compatible >>> * LGPL compatible >>> >>> Maybe someone has recommendations for it? It seems to be a frequent >>> request (https://together.jolla.com/question/321/file-picker-needed/), but I >>> have not seen yet the one that would comply with the requirements (either >>> license is not clear or Qt.labs are used). I probably just missed a decent >>> picker... >>> >>> cheers, >>> >>> rinigus >>> >>> >>> ___ >>> 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
Re: [SailfishDevel] File Picker
Andrey, which branch of https://git.merproject.org/mer-core/nemo-qml-plugin-filemanager/ did you use in your project? It seems that the default one (jb5771) does not compile and the "master" branch has a daemon (bit excessive for a dialogue, I think). cheers, rinigus On Tue, Nov 29, 2016 at 7:56 PM, rinigus wrote: > Thank you, good to know. Just would be great to specify it in LICENSE > file. Note that RPM spec specifies that mysterious LICENSE at > https://github.com/CODeRUS/splashscreen-changer/blob/ > master/rpm/splashscreen-changer.spec#L12 > :) > > But back to the subject: Andrey, thank you very much for a tip and > example code! I'll look into your interface and that would simplify > advancing my projects as well. > > Best wishes, > > rinigus > > On Tue, Nov 29, 2016 at 5:59 PM, Andrey Kozhevnikov > wrote: > > i am using WTFPL for my projects. > > > > > > 29.11.2016 14:26, rinigus пишет: > > > > Андрей, > > > > thank you! Would you mind to specify a license on > > https://github.com/CODeRUS/splashscreen-changer ? At present, there is > no > > license specified, unfortunately. > > > > cheers, > > > > rinigus > > > > On Tue, Nov 29, 2016 at 12:43 PM, Андрей Кожевников < > coderusin...@gmail.com> > > wrote: > >> > >> Hello, for now you can compile and bundle nemo-filemanager plugin: > >> https://git.merproject.org/mer-core/nemo-qml-plugin-filemanager. I hope > >> later it will be added to allowed imports. > >> You can use > >> https://github.com/CODeRUS/splashscreen-changer/blob/ > master/settings/SecondPage.qml > >> as sample of usage. > >> > >> > >> 29 нояб. 2016 г. 12:48 пользователь "rinigus" > >> написал: > >>> > >>> Hi! > >>> > >>> I am looking for a File Selection dialog that would be > >>> > >>> * Able to select a directory or a file (specified on call) > >>> * Jolla-store compatible > >>> * LGPL compatible > >>> > >>> Maybe someone has recommendations for it? It seems to be a frequent > >>> request (https://together.jolla.com/question/321/file-picker-needed/), > but I > >>> have not seen yet the one that would comply with the requirements > (either > >>> license is not clear or Qt.labs are used). I probably just missed a > decent > >>> picker... > >>> > >>> cheers, > >>> > >>> rinigus > >>> > >>> > >>> ___ > >>> 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-unsubscribe@lists. > sailfishos.org > > > > > > > > ___ > > SailfishOS.org Devel mailing list > > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] File Picker
Andrey and Matt, I'll look into it - thank you very much for the pointers. Best wishes, rinigus On Thu, Dec 1, 2016 at 11:19 PM, Matthew Vogt wrote: > Hi rinigus. > > I'm not sure why jb5771 is marked as the default, 'master' is the primary > development branch, and the one from which Jolla releases are derived. > > The master branch includes code to delegate modification operations to a > daemon, but this is already present in the system, so you do not need to > incorporate it. If you're only reading directories for a file picker, then > the daemon will not be activated. > > Thanks, > Matt > > -- > *From:* Devel [devel-boun...@lists.sailfishos.org] on behalf of rinigus [ > rinigus@gmail.com] > *Sent:* Friday, December 02, 2016 2:00 AM > *To:* Sailfish OS Developers > *Subject:* Re: [SailfishDevel] File Picker > > Andrey, > > which branch of https://git.merproject.org/mer-core/nemo-qml-plugin- > filemanager/ > <http://redir.aspx?REF=Sp-y-z2gQe_hMkS8hMcH1k6tYbASFqOcf3YRtvasgI2vLt4-LxrUCAFodHRwczovL2dpdC5tZXJwcm9qZWN0Lm9yZy9tZXItY29yZS9uZW1vLXFtbC1wbHVnaW4tZmlsZW1hbmFnZXIv> > did > you use in your project? It seems that the default one (jb5771) does not > compile and the "master" branch has a daemon (bit excessive for a dialogue, > I think). > > cheers, > > rinigus > > > On Tue, Nov 29, 2016 at 7:56 PM, rinigus <http://redir.aspx?REF=sgR_r4rC3lfblZBk8SJKLCw4tS2v7N8Gfnw08UiDfaivLt4-LxrUCAFtYWlsdG86cmluaWd1cy5naXRAZ21haWwuY29t> > > wrote: > >> Thank you, good to know. Just would be great to specify it in LICENSE >> file. Note that RPM spec specifies that mysterious LICENSE at >> https://github.com/CODeRUS/splashscreen-changer/blob/master/ >> rpm/splashscreen-changer.spec#L12 >> <http://redir.aspx?REF=54JmETr4UiCaLP-8kJlZ6_UOIMfNAewQ0dYlXFcRJ6WvLt4-LxrUCAFodHRwczovL2dpdGh1Yi5jb20vQ09EZVJVUy9zcGxhc2hzY3JlZW4tY2hhbmdlci9ibG9iL21hc3Rlci9ycG0vc3BsYXNoc2NyZWVuLWNoYW5nZXIuc3BlYyNMMTI.> >> :) >> >> But back to the subject: Andrey, thank you very much for a tip and >> example code! I'll look into your interface and that would simplify >> advancing my projects as well. >> >> Best wishes, >> >> rinigus >> >> On Tue, Nov 29, 2016 at 5:59 PM, Andrey Kozhevnikov >> > <http://redir.aspx?REF=E3Iwcte0hbisLMDHWFtSQVmXFAw1rVAWst0ppjljR3uvLt4-LxrUCAFtYWlsdG86Y29kZXJ1c2luYm94QGdtYWlsLmNvbQ..>> >> wrote: >> > i am using WTFPL for my projects. >> > >> > >> > 29.11.2016 14:26, rinigus пишет: >> > >> > Андрей, >> > >> > thank you! Would you mind to specify a license on >> > https://github.com/CODeRUS/splashscreen-changer >> <http://redir.aspx?REF=KoBMd-z1ickDUBuvt1_CfppQpYlOhgxJ9oqEddV67OavLt4-LxrUCAFodHRwczovL2dpdGh1Yi5jb20vQ09EZVJVUy9zcGxhc2hzY3JlZW4tY2hhbmdlcg..> >> ? At present, there is no >> > license specified, unfortunately. >> > >> > cheers, >> > >> > rinigus >> > >> > On Tue, Nov 29, 2016 at 12:43 PM, Андрей Кожевников < >> coderusin...@gmail.com >> <http://redir.aspx?REF=E3Iwcte0hbisLMDHWFtSQVmXFAw1rVAWst0ppjljR3uvLt4-LxrUCAFtYWlsdG86Y29kZXJ1c2luYm94QGdtYWlsLmNvbQ..> >> > >> > wrote: >> >> >> >> Hello, for now you can compile and bundle nemo-filemanager plugin: >> >> https://git.merproject.org/mer-core/nemo-qml-plugin-filemanager >> <http://redir.aspx?REF=QhxCC8lrof_dCuV5EhM4Q1XPfRrviQenX2jwLC7-tl6vLt4-LxrUCAFodHRwczovL2dpdC5tZXJwcm9qZWN0Lm9yZy9tZXItY29yZS9uZW1vLXFtbC1wbHVnaW4tZmlsZW1hbmFnZXI.>. >> I hope >> >> later it will be added to allowed imports. >> >> You can use >> >> https://github.com/CODeRUS/splashscreen-changer/blob/master/ >> settings/SecondPage.qml >> <http://redir.aspx?REF=9VRjwuAlimuqHRmNyXIq7GGoqdW-0TZ71F-w6dZiTXevLt4-LxrUCAFodHRwczovL2dpdGh1Yi5jb20vQ09EZVJVUy9zcGxhc2hzY3JlZW4tY2hhbmdlci9ibG9iL21hc3Rlci9zZXR0aW5ncy9TZWNvbmRQYWdlLnFtbA..> >> >> as sample of usage. >> >> >> >> >> >> 29 нояб. 2016 г. 12:48 пользователь "rinigus" > <http://redir.aspx?REF=sgR_r4rC3lfblZBk8SJKLCw4tS2v7N8Gfnw08UiDfaivLt4-LxrUCAFtYWlsdG86cmluaWd1cy5naXRAZ21haWwuY29t> >> > >> >> написал: >> >>> >> >>> Hi! >> >>> >> >>> I am looking for a File Selection dialog that would be >> >>> >> >>> * Able to select a directory or a file (specified on call) >> >>> * Jolla-store compatible >> >>
Re: [SailfishDevel] QtLocation | Qt 5.6
Morning, Slava, would you mind to check out which licensing terms prevent QtLocation specifically? Or maybe someone else knows specifics? Is there any hope that the situation would change in future? I wonder whether all platforms are hit by it or whether Ubuntu Touch complies with the new terms and, as a result, has an advantage when compared to SFOS in this case. Best wishes, Rinigus On Tue Jan 3 10:20:55 2017 GMT+0100, Slava Monich wrote: > As far as I understand, QtLocation license terms have changed and that > prevents it from being upgraded to 5.6 which is its first stable > release. That's why it's not allowed and won't be allowed even after the > rest of Qt is upgraded to 5.6. > > Qt 5.6 is coming with the next update. Those modules that can't be > upgraded due to licensing restrictions will stay at 5.2. > > Cheers, > -Slava > > > > Hello Sailors! > > > > As I already told you, I am working on the Berlin Vegan guide for > > SailfishOS: > > > > <https://github.com/micuintus/harbour-Berlin-Vegan/tree/development> > > <https://openrepos.net/content/micuintus/berlin-vegan> > > > > Recently, I added a map feature to the app: > > > > <https://github.com/micuintus/harbour-Berlin-Vegan/issues/41> > > > > But to my astonishment, I realized that using QtLocation is currently > > rejected > > by the Harbour RPM validator: > > > >> Requires > >> > >> ERROR [libQt5Location.so.5] Cannot require shared library: > >> 'libQt5Location.so.5' ERROR [qt5-plugin-geoservices-osm] Dependency not > >> allowed > >> ERROR [qt5-qtdeclarative-import-location] Dependency not allowed > >> ERROR [qt5-qtlocation] Dependency not allowed > > Can you tell me why? > > > > QtLocation is listed to be available here > > > > <https://sailfishos.org/wiki/Qt> > > > > and, apart from that, AFAIK Jolla was one of the main contributors to the > > QtLocation module. > > > > > > > > Furthermore, I noticed that some features of the QML Map object seem to be > > broken or missing at the moment: > > > > * fitViewportToMapItems() does not have an effect > > * 'preventStealing' is not available > > * etc. > > > > Will these features be available and work once Qt is updated to 5.6? > > Will QtLocation be allowed for harbour store apps > > once Qt 5.6 is (officially) available for Sailfish? > > > > And when can I expect Qt 5.6 to be released for SailfishOS? ;) > > > > Cheers, > > micu > > > > PS: Happy new year to everyone! > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.or ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] QtLocation | Qt 5.6
Hi,
from reading the meeting transcript it seems that we still don't have
straight answer regarding QtLocation 5.6 ("checking at the moment").
However, I don't see the changes in the source code indicating exclusive
role of LGPLv3 among LGPL licenses. The LGPLv2.1 license is still there for
QtLocation module (see https://github.com/qt/qtlocation). By going through
branches, LGPLv2.1 is present in all of them, as far as I can see and the
change to LGPLv3 has not been fully done yet. I am not even sure its
possible to simply drop a license, unless they had such an agreement with
all the contributors to the project. [Note that I haven't read the license
text fully, mainly looked on the headers].
In addition, according to the official blog
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
, move to LGPLv3 comes only after 5.6 (see section "No changes to Qt 5.6
and Qt for Device Creation" in the blog post).
Taking together, it does not seem to me that 5.6 has exclusively LGPLv3 but
includes LGPLv2.1 in QtLocation. As such, it should not be a problem to
include it into the upcoming update.
rinigus
On Sun, Jan 8, 2017 at 8:05 PM, micu wrote:
> Hello Slava,
>
> On Dienstag, 3. Januar 2017 12:20:55 CET Slava Monich wrote:
> > Qt 5.6 is coming with the next update. Those modules that can't be
> > upgraded due to licensing restrictions will stay at 5.2.
>
> Oh, that sounds frustrating.
> Is that an official Jolla information?
>
> Best,
> micu
> --
> OpenPGP / GnuPG:0xE4CB4E80
> Fingerprint:1A15 A480 1F8B 07F6 9D12 3426 CEFE 7455 E4CB 4E80
>
> <<>
>
> http://www.micuintus.de
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscribe@lists.
> sailfishos.org
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] SQLite linking
Hi! I wonder what is the best practice concerning linking to sqlite3? It's probably always installed on devices/emulators and there is no problem with deployment of an app requiring it. However, its a bit odd to just cancel off the requirement in RPM SPEC, as I am supposed to do to get it through automatic checker. Alternatively, I could embed sqlite into my compiled code. The app is huge already anyway since it needs several specialized libraries and even larger datasets, so having sqlite embedded would probably be not a biggest concern anyway (well, haven't tested it though). So, to summarize, what would be recommended practice in this case? cheers, Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SQLite linking
> > > Is the automatic checker not allowing it through with sqlite3 as a > requirement? Are you sure that you used the packagename used on jolla > systems for the requirement? > During deployment as RPM, the specific error is Requires ERROR [libsqlite3.so.0] Cannot require shared library: 'libsqlite3.so.0' INFO [harbour-osmscout-server] Please see our FAQ here: https://harbour.jolla.com/faq#2.6.0 how to use '__provides_exclude_from' and '__requires_exclude' .spec file to avoid that FAILED earlier versions of this app were published in the store without any issues. Its a part of the app evolution to require sqlite3 for its function, at least for a time being. I agree that static linking of sqlite3 is not necessary and can be considered as a bloat. Hence my question :) rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SQLite linking
Slava, thank you for this constructive suggestion. I submitted PR https://github.com/sailfish-sdk/sdk-harbour-rpmvalidator/pull/86 to add sqlite into the list of allowed libraries. Hopefully, it will be accepted. Best wishes, Rinigus On Wed, Jan 18, 2017 at 3:29 PM, Slava Monich wrote: > I believe rpm automatically detects the dependencies, even if they are not > in the spec. Removing the dependency from the spec might not help. There > may be some hackish ways of removing a dependency from the rpm headers but > I don't think that it would be a good idea. Better to spend time on hacking > something more useful than that. > > Another approach is to load the library with dlopen, e.g. > > https://github.com/monich/harbour-books/blob/master/app/stubs/libmagic.c > > This allows you to get around the harbour limitations and yet in every > other respect it's as good as linking with the system library. Of course by > doing so you assume the risk of using the unsupported api. Obviously, this > kind of trick should only be done to very stable libraries that are > extremely unlikely to disappear from the system and have a proven track > record of evolving in a backward compatible manner. > > I think the best solution is to add sqlite3 to allowed_libraries.conf and > submit a pull request: > > https://github.com/sailfish-sdk/sdk-harbour-rpmvalidator/ > blob/master/allowed_libraries.conf > > Cheers, > > -Slava > > >> Is the automatic checker not allowing it through with sqlite3 as a >> requirement? Are you sure that you used the packagename used on jolla >> systems for the requirement? >> > > During deployment as RPM, the specific error is > > Requires > > > > ERROR [libsqlite3.so.0] Cannot require shared library: 'libsqlite3.so.0' > > INFO [harbour-osmscout-server] Please see our FAQ here: > <https://harbour.jolla.com/faq#2.6.0>https://harbour.jolla.com/faq#2.6.0 > how to use '__provides_exclude_from' and '__requires_exclude' .spec file to > avoid that > > FAILED > > > earlier versions of this app were published in the store without any > issues. Its a part of the app evolution to require sqlite3 for its > function, at least for a time being. > > I agree that static linking of sqlite3 is not necessary and can be > considered as a bloat. Hence my question :) > > rinigus > > > ___ > 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-unsubscribe@lists. > sailfishos.org > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SQLite linking
Hi, one month + 10 days later - no response for PR nor SQLite linking from Harbour / Jolla devs. Already had to ship few versions with SQLite bundled with application as well. I'd say its rather poor response times already now (with the response time not reached yet). Rinigus On Wed, Jan 18, 2017 at 4:30 PM, rinigus wrote: > Slava, > > thank you for this constructive suggestion. I submitted PR > https://github.com/sailfish-sdk/sdk-harbour-rpmvalidator/pull/86 to add > sqlite into the list of allowed libraries. Hopefully, it will be accepted. > > Best wishes, > > Rinigus > > On Wed, Jan 18, 2017 at 3:29 PM, Slava Monich > wrote: > >> I believe rpm automatically detects the dependencies, even if they are >> not in the spec. Removing the dependency from the spec might not help. >> There may be some hackish ways of removing a dependency from the rpm >> headers but I don't think that it would be a good idea. Better to spend >> time on hacking something more useful than that. >> >> Another approach is to load the library with dlopen, e.g. >> >> https://github.com/monich/harbour-books/blob/master/app/stubs/libmagic.c >> >> This allows you to get around the harbour limitations and yet in every >> other respect it's as good as linking with the system library. Of course by >> doing so you assume the risk of using the unsupported api. Obviously, this >> kind of trick should only be done to very stable libraries that are >> extremely unlikely to disappear from the system and have a proven track >> record of evolving in a backward compatible manner. >> >> I think the best solution is to add sqlite3 to allowed_libraries.conf and >> submit a pull request: >> >> https://github.com/sailfish-sdk/sdk-harbour-rpmvalidator/blo >> b/master/allowed_libraries.conf >> >> Cheers, >> >> -Slava >> >> >>> Is the automatic checker not allowing it through with sqlite3 as a >>> requirement? Are you sure that you used the packagename used on jolla >>> systems for the requirement? >>> >> >> During deployment as RPM, the specific error is >> >> Requires >> >> >> >> ERROR [libsqlite3.so.0] Cannot require shared library: 'libsqlite3.so.0' >> >> INFO [harbour-osmscout-server] Please see our FAQ here: >> <https://harbour.jolla.com/faq#2.6.0>https://harbour.jolla.com/faq#2.6.0 >> how to use '__provides_exclude_from' and '__requires_exclude' .spec file to >> avoid that >> >> FAILED >> >> >> earlier versions of this app were published in the store without any >> issues. Its a part of the app evolution to require sqlite3 for its >> function, at least for a time being. >> >> I agree that static linking of sqlite3 is not necessary and can be >> considered as a bloat. Hence my question :) >> >> rinigus >> >> >> ___ >> 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-unsubscribe@lists.sailfi >> shos.org >> > > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SQLite linking
Hi Damien, agreed, the topic of adding allowed libraries seems to be a sensitive one. Which, in many cases, leads to inhibited development and wasting of time. While I understand the limitations imposed on rather infrequently used libraries due to inability to ensure Q&A, sqlite is probably used at many parts of SFOS and, as a result, passes Q&A anyway. So, by not letting us to link to it directly and forcing to bundle it with the app, Jolla is just introducing an additional source for non-patched software (I can just miss some bugfix on that lib). As for goodness of IRC, the meetings are, by definition, arranged at some time. So far, its for me at the time when I am busy with my job and just cannot commit myself to hobby-related issues. I would have thought that this mailing list and github issues/PRs should be sufficient channels to get a feedback. In the end, Jolla employees are posting over here and are reading messages over here as well (I think its reasonable to expect it from anyone posting over here). cheers, Rinigus On Sat, Mar 4, 2017 at 12:27 PM, Caliste Damien wrote: > Hello, > > Le samedi 04 mars 2017, rinigus a écrit : > > one month + 10 days later - no response for PR nor SQLite linking from > > Harbour / Jolla devs. > Well, the topic of adding allowed libraries seems to be a sensitive > one, without easy answering. You may propose this discussion for a > coming community IRC meeting. Next one is next Monday, you may add a > topic, or prefer to wait for the next one, announcing your topic early > so Jaymz may arrange to get answers (at least a negative one). > > You may try to ask on IRC directly who you may ping to get a review or > a discussion of your PR, sometimes they don't see them. > > Good luck, > > Damien. > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SQLite linking
Re OpenRepos: Sure, and I do. And through bundling I am publishing @Harbour. But the main issue is the lack of response for a rather simple request. Even a negative response is a response. Sorry for complains. Enjoy the weekend and let's see if Jolla devs would respond during the work hours :) rinigus On Sat, Mar 4, 2017 at 2:22 PM, Marcin Mielniczuk wrote: > You can always use OpenRepos... > > > On March 4, 2017 8:50:37 AM GMT+01:00, rinigus > wrote: >> >> Hi, >> >> one month + 10 days later - no response for PR nor SQLite linking from >> Harbour / Jolla devs. Already had to ship few versions with SQLite bundled >> with application as well. I'd say its rather poor response times already >> now (with the response time not reached yet). >> >> Rinigus >> >> >> On Wed, Jan 18, 2017 at 4:30 PM, rinigus wrote: >> >>> Slava, >>> >>> thank you for this constructive suggestion. I submitted PR >>> https://github.com/sailfish-sdk/sdk-harbour-rpmvalidator/pull/86 to add >>> sqlite into the list of allowed libraries. Hopefully, it will be accepted. >>> >>> Best wishes, >>> >>> Rinigus >>> >>> On Wed, Jan 18, 2017 at 3:29 PM, Slava Monich >>> wrote: >>> >>>> I believe rpm automatically detects the dependencies, even if they are >>>> not in the spec. Removing the dependency from the spec might not help. >>>> There may be some hackish ways of removing a dependency from the rpm >>>> headers but I don't think that it would be a good idea. Better to spend >>>> time on hacking something more useful than that. >>>> >>>> Another approach is to load the library with dlopen, e.g. >>>> >>>> https://github.com/monich/harbour-books/blob/master/app/stub >>>> s/libmagic.c >>>> >>>> This allows you to get around the harbour limitations and yet in every >>>> other respect it's as good as linking with the system library. Of course by >>>> doing so you assume the risk of using the unsupported api. Obviously, this >>>> kind of trick should only be done to very stable libraries that are >>>> extremely unlikely to disappear from the system and have a proven track >>>> record of evolving in a backward compatible manner. >>>> >>>> I think the best solution is to add sqlite3 to allowed_libraries.conf >>>> and submit a pull request: >>>> >>>> https://github.com/sailfish-sdk/sdk-harbour-rpmvalidator/blo >>>> b/master/allowed_libraries.conf >>>> >>>> Cheers, >>>> >>>> -Slava >>>> >>>> >>>>> Is the automatic checker not allowing it through with sqlite3 as a >>>>> requirement? Are you sure that you used the packagename used on jolla >>>>> systems for the requirement? >>>>> >>>> >>>> During deployment as RPM, the specific error is >>>> >>>> Requires >>>> >>>> >>>> >>>> ERROR [libsqlite3.so.0] Cannot require shared library: >>>> 'libsqlite3.so.0' >>>> >>>> INFO [harbour-osmscout-server] Please see our FAQ here: >>>> <https://harbour.jolla.com/faq#2.6.0>https://harbour.jolla.com/faq# >>>> 2.6.0 how to use '__provides_exclude_from' and '__requires_exclude' >>>> .spec file to avoid that >>>> >>>> FAILED >>>> >>>> >>>> earlier versions of this app were published in the store without any >>>> issues. Its a part of the app evolution to require sqlite3 for its >>>> function, at least for a time being. >>>> >>>> I agree that static linking of sqlite3 is not necessary and can be >>>> considered as a bloat. Hence my question :) >>>> >>>> rinigus >>>> >>>> >>>> ___ >>>> 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-unsubscribe@lists.sailfi >>>> shos.org >>>> >>> >>> >> > -- > Sent from my mobile. Please excuse my brevity. > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SQLite linking
Hi, thank you very much for the response and explanation. Looking forward to see the new whitelist / harbour rules. Its fine to take time to do it properly, thanks for the feedback. Best wishes, Rinigus On Sat, Mar 4, 2017 at 3:15 PM, Andrew Branson wrote: > Hi, > > I've had a look internally about this, and it's caught up in a larger > overhaul of the whitelist and harbour rules aiming to make development more > attractive to developers while remaining maintainable. This is part of the > reason you haven't had any feedback yet, but also everyone's got caught up > in the huge amount of work lately that you've now seen some news about. > > It's not great when external PRs and bugs on the merproject bugzilla > appear to look dead because they're blocked internally but not visibly, > especially when someone's taken the time and trouble to investigate and > submit something. Sorry about that. Even if the internal progress on such > things can't be made public, an acknowledgement would be nice. The apparent > silence doesn't mean your efforts aren't appreciated nor influential. > > Hope that helps a bit, > > Andrew > > On Saturday, 4 March 2017, rinigus wrote: > > Re OpenRepos: Sure, and I do. And through bundling I am publishing > @Harbour. But the main issue is the lack of response for a rather simple > request. Even a negative response is a response. > > > > > > Sorry for complains. Enjoy the weekend and let's see if Jolla devs would > respond during the work hours :) > > > > > > rinigus > > > > > > On Sat, Mar 4, 2017 at 2:22 PM, Marcin Mielniczuk < > marmistrz...@gmail.com> wrote: > > > > You can always use OpenRepos... > > > > > > > > On March 4, 2017 8:50:37 AM GMT+01:00, rinigus > wrote: > > Hi, > > > > > > one month + 10 days later - no response for PR nor SQLite linking from > Harbour / Jolla devs. Already had to ship few versions with SQLite bundled > with application as well. I'd say its rather poor response times already > now (with the response time not reached yet). > > > > > > Rinigus > > > > > > > > > > On Wed, Jan 18, 2017 at 4:30 PM, rinigus wrote: > > > > Slava, > > > > > > thank you for this constructive suggestion. I submitted PR > https://github.com/sailfish-sdk/sdk-harbour-rpmvalidator/pull/86 to add > sqlite into the list of allowed libraries. Hopefully, it will be accepted. > > > > > > Best wishes, > > > > > > Rinigus > > > > > > On Wed, Jan 18, 2017 at 3:29 PM, Slava Monich > wrote: > > > > I believe rpm automatically detects the dependencies, even if they are > not in the spec. Removing the dependency from the spec might not help. > There may be some hackish ways of removing a dependency from the rpm > headers but I don't think that it would be a good idea. Better to spend > time on hacking something more useful than that. > > > > Another approach is to load the library with dlopen, e.g. > > https://github.com/monich/harbour-books/blob/master/app/stubs/libmagic.c > > This allows you to get around the harbour limitations and yet in every > other respect it's as good as linking with the system library. Of course by > doing so you assume the risk of using the unsupported api. Obviously, this > kind of trick should only be done to very stable libraries that are > extremely unlikely to disappear from the system and have a proven track > record of evolving in a backward compatible manner. > > I think the best solution is to add sqlite3 to allowed_libraries.conf > and submit a pull request: > > https://github.com/sailfish-sdk/sdk-harbour-rpmvalidator/ > blob/master/allowed_libraries.conf > > > > Cheers, > > > > -Slava > > > > > > > > > > > > Is the automatic checker not allowing it through with sqlite3 as a > requirement? Are you sure that you used the packagename used on jolla > systems for the requirement? > > > > > > During deployment as RPM, the specific error is > > > > > > Requires > > ==== > > ERROR [libsqlite3.so.0] Cannot require shared library: 'libsqlite3.so.0' > > INFO [harbour-osmscout-server] Please see our FAQ here: > https://harbour.jolla.com/faq#2.6.0 how to use '__provides_exclude_from' > and '__requires_exclude' .spec file to avoid that > > FAILED > > > > > > earlier versions of this app were published in the store without any > issues. Its a part of the app evolution to require s
Re: [SailfishDevel] SQLite linking
Hi Martin
Did you consider this recommendation?
>
> "To simplify matters, SQLite is also available as a pre-packaged
> amalgamation source code file: sqlite3.c. The amalgamation is a single file
> of ANSI-C code that implements the entire SQLite library. The amalgamation
> is much easier to deal with. Everything is contained within a single code
> file, so it is easy to drop into the source tree of a larger C or C++
> program. [...] *For these reasons, the amalgamation source file
> ("sqlite3.c") is recommended for all applications*."[1]
>
> What are the reasons that prevent you from using the upstream recommended
> approach? Are they worth your time and effort?
>
That's exactly what I am doing right now and have a linked sqlite3.c as
an amalgamation source file in the project. Project in question is an
offline maps server and it has been distributed via OpenRepos and Harbour
already with sqlite bundled into application. In that sense, I haven't
wasted much time on it, with the following exceptions:
* had to figure out that sqlite is banned
* had to add sqlite.c into the application
* treat SFOS build differently from normal Linux distributions (the server
supports Linux in addition to SFOS)
I would like not to waste my time by following SQLite releases and keeping
up with the bugfixes. For that, it would be better to use system-provided
library. Hence the request.
> Thinking out loud: If an application (in its packaged form) is to be
> supported on a variety of devices and (future) OS releases all its
> dependencies must be satisfied in these environments. In order to make both
> the OS/devices vendors' and app developers' life easier in this respect a
> minimal *necessary* subset of all the APIs provided by the OS (at
> particular time) is defined that is guaranteed to be universally available
> in some time frame. Feel free (encouraged!) to use any other dependencies,
> even those completely missing in the OS (yet), bundling these together with
> your application! Only where this is not possible and/or implies an
> excessive effort and/or adds dozens of megabytes etc. it is worth to wait
> for Harbour rules to change.
>
In essence, it boils down to the difference in approaches: either we have
a distribution of libraries that developers can rely upon (debian, fedora,
gentoo) or we have a host with almost no support for development and each
app ensures its environment by itself (virtual machine, chroot, new fancy
packaging proposed by ubuntu or others?). The problem is that the packaging
tools used on SFOS are developed for the first approach. I am expected to
just specify in RPM spec my dependencies and all should be fine. If we
stick to package-all-you-need-in-an-app, then its probably better to have
tools developed for it.
There is of course the third way - roll out a distribution on the top of
SFOS. So, skipping Harbour and establishing an alternative approach that is
in line with the common Linux practice and allows developers to use Linux
tools to their full potential and focus on developing. As far as I can see,
it would need a decent GUI, policy agreement and enforcement, and could be
rolled out through OBS or dedicated OpenRepos channel. I probably forget
many details, but it should be possible. The more I hear about difficulties
with different Qt modules (QtLocation) the more I am inclined towards it.
But as usual, lack of time and other priorities take a preference. So,
don't take this too seriously.
In my case, the application has so many dependencies covering many aspects
of maps functionality that adding sqlite is not too bad. With the exception
of keeping track on sqlite bug fixes that I can predict I will forget to do
in any decent time interval. Which is a shame since someone @Jolla is doing
it.
Best wishes,
Rinigus
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SQLite linking
FYI: sqlite is going to be allowed in the future versions - the PR was
accepted and this library should be available for linking in future. Thank
you all who made it happen!
Rinigus
On Mon, Mar 6, 2017 at 1:18 PM, rinigus wrote:
> Hi Martin
>
> Did you consider this recommendation?
>>
>> "To simplify matters, SQLite is also available as a pre-packaged
>> amalgamation source code file: sqlite3.c. The amalgamation is a single file
>> of ANSI-C code that implements the entire SQLite library. The amalgamation
>> is much easier to deal with. Everything is contained within a single code
>> file, so it is easy to drop into the source tree of a larger C or C++
>> program. [...] *For these reasons, the amalgamation source file
>> ("sqlite3.c") is recommended for all applications*."[1]
>>
>> What are the reasons that prevent you from using the upstream recommended
>> approach? Are they worth your time and effort?
>>
>
> That's exactly what I am doing right now and have a linked sqlite3.c as
> an amalgamation source file in the project. Project in question is an
> offline maps server and it has been distributed via OpenRepos and Harbour
> already with sqlite bundled into application. In that sense, I haven't
> wasted much time on it, with the following exceptions:
>
> * had to figure out that sqlite is banned
> * had to add sqlite.c into the application
> * treat SFOS build differently from normal Linux distributions (the server
> supports Linux in addition to SFOS)
>
> I would like not to waste my time by following SQLite releases and keeping
> up with the bugfixes. For that, it would be better to use system-provided
> library. Hence the request.
>
>
>
>> Thinking out loud: If an application (in its packaged form) is to be
>> supported on a variety of devices and (future) OS releases all its
>> dependencies must be satisfied in these environments. In order to make both
>> the OS/devices vendors' and app developers' life easier in this respect a
>> minimal *necessary* subset of all the APIs provided by the OS (at
>> particular time) is defined that is guaranteed to be universally available
>> in some time frame. Feel free (encouraged!) to use any other dependencies,
>> even those completely missing in the OS (yet), bundling these together with
>> your application! Only where this is not possible and/or implies an
>> excessive effort and/or adds dozens of megabytes etc. it is worth to wait
>> for Harbour rules to change.
>>
>
> In essence, it boils down to the difference in approaches: either we have
> a distribution of libraries that developers can rely upon (debian, fedora,
> gentoo) or we have a host with almost no support for development and each
> app ensures its environment by itself (virtual machine, chroot, new fancy
> packaging proposed by ubuntu or others?). The problem is that the packaging
> tools used on SFOS are developed for the first approach. I am expected to
> just specify in RPM spec my dependencies and all should be fine. If we
> stick to package-all-you-need-in-an-app, then its probably better to have
> tools developed for it.
>
> There is of course the third way - roll out a distribution on the top of
> SFOS. So, skipping Harbour and establishing an alternative approach that is
> in line with the common Linux practice and allows developers to use Linux
> tools to their full potential and focus on developing. As far as I can see,
> it would need a decent GUI, policy agreement and enforcement, and could be
> rolled out through OBS or dedicated OpenRepos channel. I probably forget
> many details, but it should be possible. The more I hear about difficulties
> with different Qt modules (QtLocation) the more I am inclined towards it.
> But as usual, lack of time and other priorities take a preference. So,
> don't take this too seriously.
>
> In my case, the application has so many dependencies covering many aspects
> of maps functionality that adding sqlite is not too bad. With the exception
> of keeping track on sqlite bug fixes that I can predict I will forget to do
> in any decent time interval. Which is a shame since someone @Jolla is doing
> it.
>
> Best wishes,
>
> Rinigus
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Geoclue status
Hi Dylan, to my knowledge its not available. See https://bugs.merproject.org/show_bug.cgi?id=1629 Cheers, Rinigus On Wed, Mar 29, 2017 at 9:08 PM, Dylan Van Assche via Devel < devel@lists.sailfishos.org> wrote: > Hi devs, > > We can read the status of our network connections (WiFi, cellular, ...) > through Connman in "/run/state/providers/connman/Internet" > > But I am searching for the same to read out the status of the user his > location (position fix, accuracy, position provider, ...) > > Cheers, > Dylan > > > > > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] Odd issues with SDK - shared libraries not recognized as such
Hi,
I have been struggling with an odd issue which is present in current stable
and EA SDKs. Namely, several libraries are not recognized as dynamic
libraries on i486 target. For example:
sb2 -t SailfishOS-i486 -m sdk-install ldd /usr/lib/libboost_regex.so.1.51.0
not a dynamic executable
Messages from sb2:
(WARNING) ldd{bash}[6959] Executing statically linked native binary
/srv/mer/targets/SailfishOS-i486/lib/ld-2.19.so
(WARNING) ldd{bash}[6960] Executing statically linked native binary
/srv/mer/targets/SailfishOS-i486/lib/ld-2.19.so
# exit 1 (1)
Probably most libraries are fine, like
sb2 -t SailfishOS-i486 -m sdk-install ldd
/usr/lib/libboost_filesystem.so.1.51.0
linux-gate.so.1 => (0x6f79c000)
libsb2.so.1 => /usr/lib/libsb2/libsb2.so.1 (0x6f721000)
libboost_system.so.1.51.0 => /usr/lib/libboost_system.so.1.51.0 (0x6f719000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x6f631000)
libm.so.6 => /lib/libm.so.6 (0x6f5ea000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x6f5d)
libc.so.6 => /lib/libc.so.6 (0x6f409000)
libdl.so.2 => /lib/libdl.so.2 (0x6f403000)
/lib/ld-linux.so.2 (0x6f79d000)
Messages from sb2:
(WARNING) ldd{bash}[6829] Executing statically linked native binary
/srv/mer/targets/SailfishOS-i486/lib/ld-2.19.so
(WARNING) ldd{bash}[6830] Executing statically linked native binary
/srv/mer/targets/SailfishOS-i486/lib/ld-2.19.so
(WARNING) ldd{bash}[6833] Executing statically linked native binary
/srv/mer/targets/SailfishOS-i486/lib/ld-2.19.so
# exit 0 (0)
This issue does not appear on ARM target:
sb2 -t SailfishOS-armv7hl -m sdk-install ldd
/usr/lib/libboost_regex.so.1.51.0
libicuuc.so.52 => /usr/lib/libicuuc.so.52 (0x488cc000)
libicui18n.so.52 => /usr/lib/libicui18n.so.52 (0x489d)
libicudata.so.52 => /usr/lib/libicudata.so.52 (0x48b28000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x4a1a4000)
libm.so.6 => /lib/libm.so.6 (0x4a256000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4a2cb000)
libc.so.6 => /lib/libc.so.6 (0x4a2e3000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4a3e8000)
libdl.so.2 => /lib/libdl.so.2 (0x4a40b000)
/lib/ld-linux-armhf.so.3 (0x40801000)
The libraries in question that I stumbled upon are libboost_regex
and libharfbuzz. I tried to recompile harfbuzz to see if something went
wrong on its generation, but got the same issue - its not recognized as a
shared library by ldd.
Note that you can compile and link against these libraries. Don't know if
the compiled code would run on the tablet, but it refuses to run under
mb2/sb2. Which is a major problem preventing using libraries/code that has
configure scripts to check for these libraries.
I have found some logs on sfos-porters #irc channel (2013 & 2014) with the
similar issue, but there was no solution as far as I could tell.
Does anyone know how to fix it? Apart from skipping i486 or hacking
configure scripts...
Cheers,
Rinigus
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Odd issues with SDK - shared libraries not recognized as such
Hi Martin,
thank you for the tip, it worked nicely! There were several other libraries
affected: boost-program-options, libtiff, and libjpeg-turbo to name in
addition to the ones I mentioned earlier.
As for using sdk-mode - I actually didn't find (relatively fast google
search) on what does it do. In all examples on how to build packages
manually, I could see "-m sdk-install" option given. So, if you can give me
URL with description or tell what does it do and whether I should omit it,
please do so.
Ideally, I don't want to mess with sb2, all I wanted to run was
mb2 -t SailfishOS-i486 -s package.spec build
which failed due to the configuration error. Taking into account this bug,
maybe all packages specified in spec files as build-dep should be installed
in addition by zypper outside sb2?
Best wishes,
Rinigus
On Wed, Apr 5, 2017 at 8:03 AM, Martin Kampas
wrote:
> Hi Rinigus,
>
> Fix this by installing boost-regex also outside sb2
>
> [mersdk@SailfishSDK ~]$ sb2 -t SailfishOS-i486 ldd
> /usr/lib/libboost_regex.so.1.51.0
> not a dynamic executable
> [...]
> [mersdk@SailfishSDK ~]$ sudo zypper in boost-regex
> [mersdk@SailfishSDK ~]$ sb2 -t SailfishOS-i486 ldd
> /usr/lib/libboost_regex.so.1.51.0
> linux-gate.so.1 => (0x6f758000)
> libsb2.so.1 => /usr/lib/libsb2/libsb2.so.1 (0x6f5fb000)
> libicuuc.so.52 => /usr/lib/libicuuc.so.52 (0x6f48b000)
> libicui18n.so.52 => /usr/lib/libicui18n.so.52 (0x6f282000)
> libicudata.so.52 => /usr/lib/libicudata.so.52 (0x6dc16000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x6db2e000)
> libm.so.6 => /lib/libm.so.6 (0x6dae6000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x6dacd000)
> libc.so.6 => /lib/libc.so.6 (0x6d907000)
> libdl.so.2 => /lib/libdl.so.2 (0x6d902000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x6d8e6000)
> /lib/ld-linux.so.2 (0x6f759000)
> [...]
>
> Applies to other packages as well.
>
> Apart from that are you sure you want to use sb2's sdk-install mode?
>
> BR,
> Martin
>
> --
> *From:* Devel [devel-boun...@lists.sailfishos.org] on behalf of rinigus [
> rinigus@gmail.com]
> *Sent:* Monday, April 03, 2017 9:52 PM
> *To:* Sailfish OS Developers
> *Subject:* [SailfishDevel] Odd issues with SDK - shared libraries not
> recognized as such
>
> Hi,
>
> I have been struggling with an odd issue which is present in current
> stable and EA SDKs. Namely, several libraries are not recognized as dynamic
> libraries on i486 target. For example:
>
> sb2 -t SailfishOS-i486 -m sdk-install ldd /usr/lib/libboost_regex.so.1.
> 51.0
> not a dynamic executable
> Messages from sb2:
> (WARNING) ldd{bash}[6959] Executing statically linked native binary
> /srv/mer/targets/SailfishOS-i486/lib/ld-2.19.so
> <http://redir.aspx?REF=4Ku1BMEwE5PiBqmtivuRJFYpUHEvdT-rbiaVv2xdvZCxglMw4HvUCAFodHRwOi8vbGQtMi4xOS5zbw..>
> (WARNING) ldd{bash}[6960] Executing statically linked native binary
> /srv/mer/targets/SailfishOS-i486/lib/ld-2.19.so
> <http://redir.aspx?REF=4Ku1BMEwE5PiBqmtivuRJFYpUHEvdT-rbiaVv2xdvZCxglMw4HvUCAFodHRwOi8vbGQtMi4xOS5zbw..>
> # exit 1 (1)
>
> Probably most libraries are fine, like
>
> sb2 -t SailfishOS-i486 -m sdk-install ldd /usr/lib/libboost_filesystem.
> so.1.51.0
> linux-gate.so.1 => (0x6f79c000)
> libsb2.so.1 => /usr/lib/libsb2/libsb2.so.1 (0x6f721000)
> libboost_system.so.1.51.0 => /usr/lib/libboost_system.so.1.51.0
> (0x6f719000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x6f631000)
> libm.so.6 => /lib/libm.so.6 (0x6f5ea000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x6f5d)
> libc.so.6 => /lib/libc.so.6 (0x6f409000)
> libdl.so.2 => /lib/libdl.so.2 (0x6f403000)
> /lib/ld-linux.so.2 (0x6f79d000)
> Messages from sb2:
> (WARNING) ldd{bash}[6829] Executing statically linked native binary
> /srv/mer/targets/SailfishOS-i486/lib/ld-2.19.so
> <http://redir.aspx?REF=4Ku1BMEwE5PiBqmtivuRJFYpUHEvdT-rbiaVv2xdvZCxglMw4HvUCAFodHRwOi8vbGQtMi4xOS5zbw..>
> (WARNING) ldd{bash}[6830] Executing statically linked native binary
> /srv/mer/targets/SailfishOS-i486/lib/ld-2.19.so
> <http://redir.aspx?REF=4Ku1BMEwE5PiBqmtivuRJFYpUHEvdT-rbiaVv2xdvZCxglMw4HvUCAFodHRwOi8vbGQtMi4xOS5zbw..>
> (WARNING) ldd{bash}[6833] Executing statically linked native binary
> /srv/mer/targets/SailfishOS-i486/lib/ld-2.19.so
> <http://redir.aspx?REF=4Ku1BMEwE5PiBqmtivuRJFYpUHEvdT-rbiaVv2xdvZCxglMw4HvUCAFodHRwOi8vbGQtMi4xOS5zbw..>
> # exit 0 (0)
>
> This issue does not appear on ARM target:
>
> sb2 -t SailfishOS-armv7hl -m sdk-install ldd /usr/lib/libboost_regex.so.1.
> 51.0
> libicuuc.so.52 =&
[SailfishDevel] fonts in Sailfish
Hi, I am developing an application that has to have an access to the fonts covering all languages. While coverage of the fonts distributed with SFOS has improved in 2.1, I still get failure with rendering Sinhala in QML. Probably some other scripts are missing as well. For technical reasons, I need to specify the fonts used for rendering in the program or accompanying style files. Changing that would be far from trivial and I would prefer to specify font paths and names for now when compiling program/generating styles. Hence my questions: * Do we have somewhere a list of fonts that are always available on SFOS and their path (directories)? I could see a bunch of fonts under /usr/share/fonts, I presume that's all we have for now. * Probably correct way to tackle the font rendering issue would be to include Noto fonts (or something similar). Ideally, it should be done via a separate package. I can include all the required fonts in RPM, but that would blow up the package probably by ~40MB in size (uncompressed 52MB, zip compressed 42MB). Sounds a bit like a waste of bandwidth, but probably the only way to do that in agreement with the Harbour policies. Jolla, any plans to include Noto (or similar) fonts into SFOS distribution? Or changes in policies allowing us to push fonts to the devices? Best wishes, Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] fonts in Sailfish
Pekka, thank you for a fast reply! I guess I'll bundle then the required subset of Noto fonts for the time being. Rinigus On Fri, May 5, 2017 at 3:09 PM, Pekka Vuorela wrote: > On pe, 2017-05-05 at 13:43 +0300, rinigus wrote: > > Hi, > > > > I am developing an application that has to have an access to the > > fonts covering all languages. While coverage of the fonts distributed > > with SFOS has improved in 2.1, I still get failure with rendering > > Sinhala in QML. Probably some other scripts are missing as well. > > > > For technical reasons, I need to specify the fonts used for rendering > > in the program or accompanying style files. Changing that would be > > far from trivial and I would prefer to specify font paths and names > > for now when compiling program/generating styles. > > > > Hence my questions: > > > > * Do we have somewhere a list of fonts that are always available on > > SFOS and their path (directories)? I could see a bunch of fonts under > > /usr/share/fonts, I presume that's all we have for now. > > Yea, that's what we have. > > > * Probably correct way to tackle the font rendering issue would be to > > include Noto fonts (or something similar). Ideally, it should be done > > via a separate package. I can include all the required fonts in RPM, > > but that would blow up the package probably by ~40MB in size > > (uncompressed 52MB, zip compressed 42MB). Sounds a bit like a waste > > of bandwidth, but probably the only way to do that in agreement with > > the Harbour policies. Jolla, any plans to include Noto (or similar) > > fonts into SFOS distribution? Or changes in policies allowing us to > > push fonts to the devices? > > While font coverage is slowly getting better, there are unfortunately > still lot of scripts missing. What we've added has been done with the > aim to have it mixing nicely with existing fonts, sometimes making > small adjustments here and there. > > Including a big set of Noto fonts or similar is not in the plans right > now, would require quite a bunch of fonts. The best thing for you could > be just including custom fonts in the application if those are needed. > > If there are certain scripts people would really like to have, would be > good to have votes on together.jolla.com. > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] sub-processes as separate binary executables
Dear Harbour Admins and Developers: I would like to incorporate one executable binary as a part of RPM package that would be called by the main application. There are technical reasons for preferring such approach including long-term maintenance. At present, Harbour rules prevent you from including ELF executable. We are allowed to ship data and libraries. So, as far as I can see, its simple to go around no-executable rule by zipping executable while shipping, unpack it into /home/nemo/.cache/..., change permissions, and call it from there. Unfortunately, that's probably not the best design for multiple reasons (security comes to mind). So, I would like to ask for relaxing the Harbour rules and allow us to ship required binaries under /usr/share/ as we do with the libraries already. Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] QtLocation | Qt 5.6
Hi,
it has been rather quiet regarding QtLocation 5.6 during the "first quarter
of 2017" (see earlier emails in this thread). I would like to continue my
work on navigation/mapping solutions for SFOS and the uncertainty regarding
QtLocation is just slowing everything down and lead to major inefficiency
in the development of this important aspect of SFOS.
I would like to know what is the state of QtLocation and its future in
SFOS. From the activity in
https://git.merproject.org/mer-core/qtlocation/activity I conclude that the
developers working on it are @chriadam, @pvuorela, @xfade, Slava Monich,
and @msmirnov. Maybe some of you can take time and reply. In particular:
* Has any work started on upgrading QtLocation to 5.6?
* Has Jolla decided whether they want to work on QtLocation/5.6?
* If its decided that its impossible to include QtLocation due to licensing
issues, can the community help to provide the QtLocation via our packages?
* If you just haven't had time for working on QtLocation 5.6, how can we
help and where should we start?
It looks to me that QtLocation is the component that is pushed for map
applications development. I presume that it would be wise to use it as well
and not waste time to re-invent something similar. Or is there anything
considerably better and we should work on that instead?
Since it is developers channel, its an appropriate place to ask, I believe.
Best wishes,
Rinigus
On Tue, Jan 10, 2017 at 10:49 PM, Tone Kastlunger wrote:
> I'd support this, not enough has been coming through at the meeting IMO to
> have a clear yes/no answer.
>
> Best,
> tortoisedoc
>
> On Mon, Jan 9, 2017 at 11:32 PM, Adam Pigg wrote:
>
>> I guess we need to wait for the internal review that was mentioned in the
>> meeting, however it would be interesting to understand the issues jolla
>> have with particular licenses for software included in sfos.
>>
>> On Mon, 9 Jan 2017 at 21:29 Osmo Salomaa wrote:
>>
>>> On 09.01.2017 13:01, rinigus wrote:
>>> > from reading the meeting transcript it seems that we still don't have
>>> > straight answer regarding QtLocation 5.6 ("checking at the moment").
>>>
>>> They were not wordy, but my interpretation is that nothing has changed
>>> regarding QtLocation being allowed in store apps once it's upgraded to a
>>> stable release, i.e. >= 5.6. "Aiming to have solution for it in the first
>>> quarter of 2017" doesn't sound too bad, I was worried we were at a dead end.
>>>
>>> > However, I don't see the changes in the source code indicating
>>> exclusive
>>> > role of LGPLv3 among LGPL licenses. The LGPLv2.1 license is still
>>> there for
>>> > QtLocation module (see https://github.com/qt/qtlocation).
>>>
>>> Indeed. There's a license change commit in the source 2016-01-20, but
>>> that's saying it would be from 5.7 onwards. And that commit is not in the
>>> 5.6 branch.
>>>
>>> https://github.com/qt/qtlocation/commit/71dabb5dc330a47d91ee
>>> 917ca60c871a88e8a42a
>>>
>>> Reading various other unclear sources, I see 5.5, 5.6 and 5.7 all
>>> mentioned for the change -- maybe it was pushed back a few times? I have
>>> found no web page that would actually list the licenses under which Qt
>>> modules are available. Can anyone from Jolla comment? Do you have better
>>> information?
>>>
>>> --
>>> Osmo Salomaa
>>> ___
>>> SailfishOS.org Devel mailing list
>>> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi
>>> shos.org
>>
>>
>> ___
>> SailfishOS.org Devel mailing list
>> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi
>> shos.org
>>
>
>
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscribe@lists.
> sailfishos.org
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] QtLocation | Qt 5.6
Hi Chris,
thank you very much for an update. Looking forward for veskuh's reply and,
hopefully, we can move forward with this API as well.
Cheers,
Rinigus
On Thu, Jul 13, 2017 at 3:40 AM, Chris Adams wrote:
> Hi,
>
> I think veskuh will be the best to answer these questions.
>
> Currently, I don't think any work has gone toward upgrading QtLocation to
> version 5.6 yet, as we're busy with other projects. Originally the
> decision to not take QtLocation 5.6 into use along with the rest of the Qt
> 5.6 libs was, I believe, because of the different licensing of QtLocation.
> I think veskuh would be the best person to describe our intent going
> forward, and possible roadmap for updating.
>
> Best regards,
> Chris.
>
>
> --
> *From:* Devel [devel-boun...@lists.sailfishos.org] on behalf of rinigus [
> rinigus@gmail.com]
> *Sent:* Friday, July 07, 2017 6:04 PM
> *To:* Sailfish OS Developers
> *Subject:* Re: [SailfishDevel] QtLocation | Qt 5.6
>
> Hi,
>
> it has been rather quiet regarding QtLocation 5.6 during the "first
> quarter of 2017" (see earlier emails in this thread). I would like to
> continue my work on navigation/mapping solutions for SFOS and the
> uncertainty regarding QtLocation is just slowing everything down and lead
> to major inefficiency in the development of this important aspect of SFOS.
>
> I would like to know what is the state of QtLocation and its future in
> SFOS. From the activity in https://git.merproject.org/
> mer-core/qtlocation/activity
> <http://redir.aspx?REF=zWm_Sf04kBkJblyUyNjvCqS4mOnF1wFPhx6A68AtZy0LC5Moh8nUCAFodHRwczovL2dpdC5tZXJwcm9qZWN0Lm9yZy9tZXItY29yZS9xdGxvY2F0aW9uL2FjdGl2aXR5>
> I conclude that the developers working on it are @chriadam, @pvuorela,
> @xfade, Slava Monich, and @msmirnov. Maybe some of you can take time and
> reply. In particular:
>
> * Has any work started on upgrading QtLocation to 5.6?
>
> * Has Jolla decided whether they want to work on QtLocation/5.6?
>
> * If its decided that its impossible to include QtLocation due to
> licensing issues, can the community help to provide the QtLocation via our
> packages?
>
> * If you just haven't had time for working on QtLocation 5.6, how can we
> help and where should we start?
>
> It looks to me that QtLocation is the component that is pushed for map
> applications development. I presume that it would be wise to use it as well
> and not waste time to re-invent something similar. Or is there anything
> considerably better and we should work on that instead?
>
> Since it is developers channel, its an appropriate place to ask, I
> believe.
>
> Best wishes,
>
> Rinigus
>
> On Tue, Jan 10, 2017 at 10:49 PM, Tone Kastlunger <
> users.giulie...@gmail.com
> <http://redir.aspx?REF=EUOWHvr5jEnv6pxp6JMfdOvXxr5kUYRUWfZnQJrvFZ4LC5Moh8nUCAFtYWlsdG86dXNlcnMuZ2l1bGlldHRhQGdtYWlsLmNvbQ..>
> > wrote:
>
>> I'd support this, not enough has been coming through at the meeting IMO
>> to have a clear yes/no answer.
>>
>> Best,
>> tortoisedoc
>>
>> On Mon, Jan 9, 2017 at 11:32 PM, Adam Pigg > <http://redir.aspx?REF=Ty7ixpUauyWMAaPdQIs5VwKyAP15fbqxGVH7-4nRse0LC5Moh8nUCAFtYWlsdG86YWRhbUBwaWdnei5jby51aw..>
>> > wrote:
>>
>>> I guess we need to wait for the internal review that was mentioned in
>>> the meeting, however it would be interesting to understand the issues jolla
>>> have with particular licenses for software included in sfos.
>>>
>>> On Mon, 9 Jan 2017 at 21:29 Osmo Salomaa >> <http://redir.aspx?REF=t28cqNItUuzUjyoP1dTK_fgFVhzqnX8cRi9ZMXZxvl0LC5Moh8nUCAFtYWlsdG86b3RzYWxvbWFAaWtpLmZp>>
>>> wrote:
>>>
>>>> On 09.01.2017 13:01, rinigus wrote:
>>>> > from reading the meeting transcript it seems that we still don't have
>>>> > straight answer regarding QtLocation 5.6 ("checking at the moment").
>>>>
>>>> They were not wordy, but my interpretation is that nothing has changed
>>>> regarding QtLocation being allowed in store apps once it's upgraded to a
>>>> stable release, i.e. >= 5.6. "Aiming to have solution for it in the first
>>>> quarter of 2017" doesn't sound too bad, I was worried we were at a dead
>>>> end.
>>>>
>>>> > However, I don't see the changes in the source code indicating
>>>> exclusive
>>>> > role of LGPLv3 among LGPL licenses. The LGPLv2.1 license is still
>>>> there for
>>>> > QtLocation module (see https://github.com/qt/qtlocation
>>>> <h
Re: [SailfishDevel] Ship a sqlite dabase with an app
Hi Pablo, if its 0.1 MB it should be no issue to include the database into the RPM with the app. Just add it into data directory (/usr/share/appname/) and load it from there. Note that it will be read-only in this case. If you need to write into the database, make a copy under /home/nemo/.local in an app-assigned directory (.cache if its more appropriate). Cheers, Rinigus On Thu, Jul 20, 2017 at 10:29 PM, J Pablo Navarro wrote: > Hi SFOS devs! > > I think this is my first email over here and I don't have too much experice > with apps, so please be kind :) > > I want to ship an sqlite database with the app. The main reason is that > generating this database takes around 15 minutes... and it weights 104 > KiB, so > I think the best solution would be to shipt it as part of the app instead > of > download it from somewhere (I don't have a server, so that would be a > problem) > or generate it the first time the app is opened. > > My question is, what's the best way to do this? > > Thank you, > Pablo. > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] OBS questions
Hi,
I am working on getting ported packages to OBS and facing few problems, as
probably most of the beginners do. Maybe someone here can help me out?
Problem 1: I have a bunch of packages that have external source and rpm
spec written in a small separate project. Let's take rrdtool as an example
with my github repo https://github.com/rinigus/pkg-rrdtool . Its spec
contains source as a full URL. Now, I would like to download it from that
URL by OBS either during building or as a part of its _service.
Unfortunately, unlike in several other CI servers, network seems to be
disabled. So, the snippet in RPM as
%setup -q -n %{name}-%{version}
curl -O %{REMSOURCE0}
tar zxvf rrdtool-1.5.6.tar.gz --strip-components=1
doesn't work (ifconfig returns only loopback device). We also don't have
download_files among allowed _service APIs, as returned by osc api /service.
Maybe this can be enabled on OBS? As far as I understand, it should
download all sources specified in the spec file. Personally, I find it
rather disturbing putting .tar.gz into github project and would prefer
getting the upstream package from the upstream source.
Problem 2: When creating package from github source (like for proj.4 in my
case), I get as a version of packaged RPM the version that I specified
together with (what looks like) git's latest commit signature together with
the corresponding branch name leading to package names like
proj-4.9.3+sailfish.20170726042718.6.ge9a0f09-10.20.1.jolla.armv7hl.rpm .
How can I make it shorter to proj-4.9.3.armv7hl.rpm ?
Best wishes,
Rinigus
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] OBS questions
Андрей and Andrew,
thank you for the tips! I think I can manage now (or will be back with the
questions).
Cheers,
Rinigus
On Wed, Jul 26, 2017 at 10:36 AM, Andrew Branson <
andrew.bran...@jollamobile.com> wrote:
> Hi,
>
> On 26/07/17 09:24, rinigus wrote:
> > Hi,
> >
> > I am working on getting ported packages to OBS and facing few problems,
> > as probably most of the beginners do. Maybe someone here can help me out?
> >
> > Problem 1: I have a bunch of packages that have external source and rpm
> > spec written in a small separate project. Let's take rrdtool as an
> > example with my github repo https://github.com/rinigus/pkg-rrdtool . Its
> > spec contains source as a full URL. Now, I would like to download it
> > from that URL by OBS either during building or as a part of its
> > _service. Unfortunately, unlike in several other CI servers, network
> > seems to be disabled. So, the snippet in RPM as
> >
> > %setup -q -n %{name}-%{version}
> > curl -O %{REMSOURCE0}
> > tar zxvf rrdtool-1.5.6.tar.gz --strip-components=1
> >
> > doesn't work (ifconfig returns only loopback device). We also don't have
> > download_files among allowed _service APIs, as returned by osc api
> > /service. Maybe this can be enabled on OBS? As far as I understand, it
> > should download all sources specified in the spec file. Personally, I
> > find it rather disturbing putting .tar.gz into github project and would
> > prefer getting the upstream package from the upstream source.
>
> We reference external sources as git submodules. The 'tar_git' service
> will clone those along with your main repo. Our basic pattern is this plus
> patch files in the rpm folder to apply any specific changes we need.
>
> Here's an example: https://git.merproject.org/mer-core/augeas
> And the _service file:
> https://build.merproject.org/package/show/mer-core:devel/augeas
>
> > Problem 2: When creating package from github source (like for proj.4 in
> > my case), I get as a version of packaged RPM the version that I
> > specified together with (what looks like) git's latest commit signature
> > together with the corresponding branch name leading to package names
> > like
> > proj-4.9.3+sailfish.20170726042718.6.ge9a0f09-10.20.1.jolla.armv7hl.rpm
> . How can I make it shorter to proj-4.9.3.armv7hl.rpm ?
>
> OBS takes the version string from the latest git tag. Create a tag with
> your desired version string, e.g. '4.9.3'. You can copy this behaviour in
> mb2 with the '-x' switch.
>
> Hope that helps,
>
> Andrew
>
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi
> shos.org
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] OBS questions
Hi,
I have been able to follow your advice and all worked quite nicely.
However, one particular package - mapnik - has issues with fetching the
sources. The _service is configured to fetch package using tar_git from
https://github.com/rinigus/pkg-mapnik . I presume its due to the size of
the submoduled repo (160MB). Anyway, I am getting *Sources could not be
expanded: service daemon error: rpc timeout *from the friendly OBS
builders. Do I hit some preconfigured OBS limits? Would love to avoid
dumping Mapnik code in particular version to some additional repo for
avoiding the limits (as well as uploading mapnik separately in tar.gz).
Maybe someone next to OBS tuning knobs can help me out?
Additional question, what's max RAM consumption on compiling nodes? Mapnik
has required me to increase SDK virtual machine RAM allocation
significantly.
Best wishes,
Rinigus
On Wed, Jul 26, 2017 at 10:54 AM, rinigus wrote:
> Андрей and Andrew,
>
> thank you for the tips! I think I can manage now (or will be back with the
> questions).
>
> Cheers,
>
> Rinigus
>
> On Wed, Jul 26, 2017 at 10:36 AM, Andrew Branson <
> andrew.bran...@jollamobile.com> wrote:
>
>> Hi,
>>
>> On 26/07/17 09:24, rinigus wrote:
>> > Hi,
>> >
>> > I am working on getting ported packages to OBS and facing few problems,
>> > as probably most of the beginners do. Maybe someone here can help me
>> out?
>> >
>> > Problem 1: I have a bunch of packages that have external source and rpm
>> > spec written in a small separate project. Let's take rrdtool as an
>> > example with my github repo https://github.com/rinigus/pkg-rrdtool .
>> Its
>> > spec contains source as a full URL. Now, I would like to download it
>> > from that URL by OBS either during building or as a part of its
>> > _service. Unfortunately, unlike in several other CI servers, network
>> > seems to be disabled. So, the snippet in RPM as
>> >
>> > %setup -q -n %{name}-%{version}
>> > curl -O %{REMSOURCE0}
>> > tar zxvf rrdtool-1.5.6.tar.gz --strip-components=1
>> >
>> > doesn't work (ifconfig returns only loopback device). We also don't have
>> > download_files among allowed _service APIs, as returned by osc api
>> > /service. Maybe this can be enabled on OBS? As far as I understand, it
>> > should download all sources specified in the spec file. Personally, I
>> > find it rather disturbing putting .tar.gz into github project and would
>> > prefer getting the upstream package from the upstream source.
>>
>> We reference external sources as git submodules. The 'tar_git' service
>> will clone those along with your main repo. Our basic pattern is this plus
>> patch files in the rpm folder to apply any specific changes we need.
>>
>> Here's an example: https://git.merproject.org/mer-core/augeas
>> And the _service file:
>> https://build.merproject.org/package/show/mer-core:devel/augeas
>>
>> > Problem 2: When creating package from github source (like for proj.4 in
>> > my case), I get as a version of packaged RPM the version that I
>> > specified together with (what looks like) git's latest commit signature
>> > together with the corresponding branch name leading to package names
>> > like
>> > proj-4.9.3+sailfish.2017072604 <(201)%20707-2604>
>> 2718.6.ge9a0f09-10.20.1.jolla.armv7hl.rpm . How can I make it shorter to
>> proj-4.9.3.armv7hl.rpm ?
>>
>> OBS takes the version string from the latest git tag. Create a tag with
>> your desired version string, e.g. '4.9.3'. You can copy this behaviour in
>> mb2 with the '-x' switch.
>>
>> Hope that helps,
>>
>> Andrew
>>
>> ___
>> SailfishOS.org Devel mailing list
>> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi
>> shos.org
>>
>
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] OBS questions
Hi,
looks like Mapnik issue is induced by a bug in tar_git script and I hope it
will be resolved.
I have a next issue while compiling one of the programs. Namely, to comply
with Jolla Store rules, I include all required "non-standard" libraries
into /usr/share of the program. This seems to upset rpmlint a great deal,
as in
harbour-osmscout-server-module-route.i486: E:
library-without-ldconfig-postun (Badness: 300)
/usr/share/harbour-osmscout-server-module-route/lib/libicuuc.so.52
Any idea how to get rpmlint skip those "errors" and publish the package?
Best wishes,
Rinigus
On Thu, Jul 27, 2017 at 11:57 PM, rinigus wrote:
> Hi,
>
> I have been able to follow your advice and all worked quite nicely.
> However, one particular package - mapnik - has issues with fetching the
> sources. The _service is configured to fetch package using tar_git from
> https://github.com/rinigus/pkg-mapnik . I presume its due to the size of
> the submoduled repo (160MB). Anyway, I am getting *Sources could not be
> expanded: service daemon error: rpc timeout *from the friendly OBS
> builders. Do I hit some preconfigured OBS limits? Would love to avoid
> dumping Mapnik code in particular version to some additional repo for
> avoiding the limits (as well as uploading mapnik separately in tar.gz).
>
> Maybe someone next to OBS tuning knobs can help me out?
>
> Additional question, what's max RAM consumption on compiling nodes? Mapnik
> has required me to increase SDK virtual machine RAM allocation
> significantly.
>
> Best wishes,
>
> Rinigus
>
> On Wed, Jul 26, 2017 at 10:54 AM, rinigus wrote:
>
>> Андрей and Andrew,
>>
>> thank you for the tips! I think I can manage now (or will be back with
>> the questions).
>>
>> Cheers,
>>
>> Rinigus
>>
>> On Wed, Jul 26, 2017 at 10:36 AM, Andrew Branson <
>> andrew.bran...@jollamobile.com> wrote:
>>
>>> Hi,
>>>
>>> On 26/07/17 09:24, rinigus wrote:
>>> > Hi,
>>> >
>>> > I am working on getting ported packages to OBS and facing few problems,
>>> > as probably most of the beginners do. Maybe someone here can help me
>>> out?
>>> >
>>> > Problem 1: I have a bunch of packages that have external source and rpm
>>> > spec written in a small separate project. Let's take rrdtool as an
>>> > example with my github repo https://github.com/rinigus/pkg-rrdtool .
>>> Its
>>> > spec contains source as a full URL. Now, I would like to download it
>>> > from that URL by OBS either during building or as a part of its
>>> > _service. Unfortunately, unlike in several other CI servers, network
>>> > seems to be disabled. So, the snippet in RPM as
>>> >
>>> > %setup -q -n %{name}-%{version}
>>> > curl -O %{REMSOURCE0}
>>> > tar zxvf rrdtool-1.5.6.tar.gz --strip-components=1
>>> >
>>> > doesn't work (ifconfig returns only loopback device). We also don't
>>> have
>>> > download_files among allowed _service APIs, as returned by osc api
>>> > /service. Maybe this can be enabled on OBS? As far as I understand, it
>>> > should download all sources specified in the spec file. Personally, I
>>> > find it rather disturbing putting .tar.gz into github project and would
>>> > prefer getting the upstream package from the upstream source.
>>>
>>> We reference external sources as git submodules. The 'tar_git' service
>>> will clone those along with your main repo. Our basic pattern is this plus
>>> patch files in the rpm folder to apply any specific changes we need.
>>>
>>> Here's an example: https://git.merproject.org/mer-core/augeas
>>> And the _service file:
>>> https://build.merproject.org/package/show/mer-core:devel/augeas
>>>
>>> > Problem 2: When creating package from github source (like for proj.4 in
>>> > my case), I get as a version of packaged RPM the version that I
>>> > specified together with (what looks like) git's latest commit signature
>>> > together with the corresponding branch name leading to package names
>>> > like
>>> > proj-4.9.3+sailfish.2017072604 <(201)%20707-2604>
>>> 2718.6.ge9a0f09-10.20.1.jolla.armv7hl.rpm . How can I make it shorter
>>> to proj-4.9.3.armv7hl.rpm ?
>>>
>>> OBS takes the version string from the latest git tag. Create a tag with
>>> your desired version string, e.g. '4.9.3'. You can copy this behaviour in
>>> mb2 with the '-x' switch.
>>>
>>> Hope that helps,
>>>
>>> Andrew
>>>
>>> ___
>>> SailfishOS.org Devel mailing list
>>> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi
>>> shos.org
>>>
>>
>>
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] OBS questions
Sorry, the corresponding error was
harbour-osmscout-server-module-route.i486: E:
arch-dependent-file-in-usr-share (Badness: 590)
/usr/share/harbour-osmscout-server-module-route/lib/libicuuc.so.52
Rinigus
On Sat, Jul 29, 2017 at 3:00 PM, rinigus wrote:
> Hi,
>
> looks like Mapnik issue is induced by a bug in tar_git script and I hope
> it will be resolved.
>
> I have a next issue while compiling one of the programs. Namely, to comply
> with Jolla Store rules, I include all required "non-standard" libraries
> into /usr/share of the program. This seems to upset rpmlint a great deal,
> as in
>
> harbour-osmscout-server-module-route.i486: E: library-without-ldconfig-postun
> (Badness: 300)
> /usr/share/harbour-osmscout-server-module-route/lib/libicuuc.so.52
>
> Any idea how to get rpmlint skip those "errors" and publish the package?
>
> Best wishes,
>
> Rinigus
>
> On Thu, Jul 27, 2017 at 11:57 PM, rinigus wrote:
>
>> Hi,
>>
>> I have been able to follow your advice and all worked quite nicely.
>> However, one particular package - mapnik - has issues with fetching the
>> sources. The _service is configured to fetch package using tar_git from
>> https://github.com/rinigus/pkg-mapnik . I presume its due to the size of
>> the submoduled repo (160MB). Anyway, I am getting *Sources could not be
>> expanded: service daemon error: rpc timeout *from the friendly OBS
>> builders. Do I hit some preconfigured OBS limits? Would love to avoid
>> dumping Mapnik code in particular version to some additional repo for
>> avoiding the limits (as well as uploading mapnik separately in tar.gz).
>>
>> Maybe someone next to OBS tuning knobs can help me out?
>>
>> Additional question, what's max RAM consumption on compiling nodes?
>> Mapnik has required me to increase SDK virtual machine RAM allocation
>> significantly.
>>
>> Best wishes,
>>
>> Rinigus
>>
>> On Wed, Jul 26, 2017 at 10:54 AM, rinigus wrote:
>>
>>> Андрей and Andrew,
>>>
>>> thank you for the tips! I think I can manage now (or will be back with
>>> the questions).
>>>
>>> Cheers,
>>>
>>> Rinigus
>>>
>>> On Wed, Jul 26, 2017 at 10:36 AM, Andrew Branson <
>>> andrew.bran...@jollamobile.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 26/07/17 09:24, rinigus wrote:
>>>> > Hi,
>>>> >
>>>> > I am working on getting ported packages to OBS and facing few
>>>> problems,
>>>> > as probably most of the beginners do. Maybe someone here can help me
>>>> out?
>>>> >
>>>> > Problem 1: I have a bunch of packages that have external source and
>>>> rpm
>>>> > spec written in a small separate project. Let's take rrdtool as an
>>>> > example with my github repo https://github.com/rinigus/pkg-rrdtool .
>>>> Its
>>>> > spec contains source as a full URL. Now, I would like to download it
>>>> > from that URL by OBS either during building or as a part of its
>>>> > _service. Unfortunately, unlike in several other CI servers, network
>>>> > seems to be disabled. So, the snippet in RPM as
>>>> >
>>>> > %setup -q -n %{name}-%{version}
>>>> > curl -O %{REMSOURCE0}
>>>> > tar zxvf rrdtool-1.5.6.tar.gz --strip-components=1
>>>> >
>>>> > doesn't work (ifconfig returns only loopback device). We also don't
>>>> have
>>>> > download_files among allowed _service APIs, as returned by osc api
>>>> > /service. Maybe this can be enabled on OBS? As far as I understand, it
>>>> > should download all sources specified in the spec file. Personally, I
>>>> > find it rather disturbing putting .tar.gz into github project and
>>>> would
>>>> > prefer getting the upstream package from the upstream source.
>>>>
>>>> We reference external sources as git submodules. The 'tar_git' service
>>>> will clone those along with your main repo. Our basic pattern is this plus
>>>> patch files in the rpm folder to apply any specific changes we need.
>>>>
>>>> Here's an example: https://git.merproject.org/mer-core/augeas
>>>> And the _service file:
>>>> https://build.merproject.org/package/show/mer-core:devel/augeas
>>>>
>>>> > Problem 2: When creating package from github source (like for pro
Re: [SailfishDevel] OBS questions
Looks like I found the solution for rpmlint errors using RpmLintIgnore.
Sorry for the noise and enjoy the weekend,
Rinigus
On Sat, Jul 29, 2017 at 4:43 PM, rinigus wrote:
> Sorry, the corresponding error was
>
> harbour-osmscout-server-module-route.i486: E:
> arch-dependent-file-in-usr-share (Badness: 590)
> /usr/share/harbour-osmscout-server-module-route/lib/libicuuc.so.52
>
>
> Rinigus
>
> On Sat, Jul 29, 2017 at 3:00 PM, rinigus wrote:
>
>> Hi,
>>
>> looks like Mapnik issue is induced by a bug in tar_git script and I hope
>> it will be resolved.
>>
>> I have a next issue while compiling one of the programs. Namely, to
>> comply with Jolla Store rules, I include all required "non-standard"
>> libraries into /usr/share of the program. This seems to upset rpmlint a
>> great deal, as in
>>
>> harbour-osmscout-server-module-route.i486: E:
>> library-without-ldconfig-postun (Badness: 300)
>> /usr/share/harbour-osmscout-server-module-route/lib/libicuuc.so.52
>>
>> Any idea how to get rpmlint skip those "errors" and publish the package?
>>
>> Best wishes,
>>
>> Rinigus
>>
>> On Thu, Jul 27, 2017 at 11:57 PM, rinigus wrote:
>>
>>> Hi,
>>>
>>> I have been able to follow your advice and all worked quite nicely.
>>> However, one particular package - mapnik - has issues with fetching the
>>> sources. The _service is configured to fetch package using tar_git from
>>> https://github.com/rinigus/pkg-mapnik . I presume its due to the size
>>> of the submoduled repo (160MB). Anyway, I am getting *Sources could not
>>> be expanded: service daemon error: rpc timeout *from the friendly OBS
>>> builders. Do I hit some preconfigured OBS limits? Would love to avoid
>>> dumping Mapnik code in particular version to some additional repo for
>>> avoiding the limits (as well as uploading mapnik separately in tar.gz).
>>>
>>> Maybe someone next to OBS tuning knobs can help me out?
>>>
>>> Additional question, what's max RAM consumption on compiling nodes?
>>> Mapnik has required me to increase SDK virtual machine RAM allocation
>>> significantly.
>>>
>>> Best wishes,
>>>
>>> Rinigus
>>>
>>> On Wed, Jul 26, 2017 at 10:54 AM, rinigus wrote:
>>>
>>>> Андрей and Andrew,
>>>>
>>>> thank you for the tips! I think I can manage now (or will be back with
>>>> the questions).
>>>>
>>>> Cheers,
>>>>
>>>> Rinigus
>>>>
>>>> On Wed, Jul 26, 2017 at 10:36 AM, Andrew Branson <
>>>> andrew.bran...@jollamobile.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On 26/07/17 09:24, rinigus wrote:
>>>>> > Hi,
>>>>> >
>>>>> > I am working on getting ported packages to OBS and facing few
>>>>> problems,
>>>>> > as probably most of the beginners do. Maybe someone here can help me
>>>>> out?
>>>>> >
>>>>> > Problem 1: I have a bunch of packages that have external source and
>>>>> rpm
>>>>> > spec written in a small separate project. Let's take rrdtool as an
>>>>> > example with my github repo https://github.com/rinigus/pkg-rrdtool
>>>>> . Its
>>>>> > spec contains source as a full URL. Now, I would like to download it
>>>>> > from that URL by OBS either during building or as a part of its
>>>>> > _service. Unfortunately, unlike in several other CI servers, network
>>>>> > seems to be disabled. So, the snippet in RPM as
>>>>> >
>>>>> > %setup -q -n %{name}-%{version}
>>>>> > curl -O %{REMSOURCE0}
>>>>> > tar zxvf rrdtool-1.5.6.tar.gz --strip-components=1
>>>>> >
>>>>> > doesn't work (ifconfig returns only loopback device). We also don't
>>>>> have
>>>>> > download_files among allowed _service APIs, as returned by osc api
>>>>> > /service. Maybe this can be enabled on OBS? As far as I understand,
>>>>> it
>>>>> > should download all sources specified in the spec file. Personally, I
>>>>> > find it rather disturbing putting .tar.gz into github project and
>>>>> would
>>>>> > prefer getting the upstream package from the upstream source.
>>&
Re: [SailfishDevel] OBS questions
On Wed, Aug 2, 2017 at 12:54 PM, Tone Kastlunger wrote: > Out of curiosity, are you running mapnik server on SFOS? :P > > Yes, I do. However, note that Mapnik is not a server by itself - its C++ library for map rendering and few other things. So, at present, Mapnik is used a default map rendering backend by OSM Scout Server. When compared to usual Mapnik usage - PostGIS + apache2 - there are differences: * The data is read from SQLite databases that are stored on device together with few shapefiles. This required to make few import scripts and adaptation//development mapnik styles * Server API is exposed via libmicrohttpd But as a result, it works quite well on SFOS devices. Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] QtLocation | Qt 5.6
Morning,
this is to bump the thread with the hope of getting a reply regarding
QtLocation status and plans.
Cheers,
Rinigus
On Thu, Jul 13, 2017 at 9:08 AM, rinigus wrote:
> Hi Chris,
>
> thank you very much for an update. Looking forward for veskuh's reply and,
> hopefully, we can move forward with this API as well.
>
> Cheers,
>
> Rinigus
>
> On Thu, Jul 13, 2017 at 3:40 AM, Chris Adams
> wrote:
>
>> Hi,
>>
>> I think veskuh will be the best to answer these questions.
>>
>> Currently, I don't think any work has gone toward upgrading QtLocation to
>> version 5.6 yet, as we're busy with other projects. Originally the
>> decision to not take QtLocation 5.6 into use along with the rest of the Qt
>> 5.6 libs was, I believe, because of the different licensing of QtLocation.
>> I think veskuh would be the best person to describe our intent going
>> forward, and possible roadmap for updating.
>>
>> Best regards,
>> Chris.
>>
>>
>> --
>> *From:* Devel [devel-boun...@lists.sailfishos.org] on behalf of rinigus [
>> rinigus@gmail.com]
>> *Sent:* Friday, July 07, 2017 6:04 PM
>> *To:* Sailfish OS Developers
>> *Subject:* Re: [SailfishDevel] QtLocation | Qt 5.6
>>
>> Hi,
>>
>> it has been rather quiet regarding QtLocation 5.6 during the "first
>> quarter of 2017" (see earlier emails in this thread). I would like to
>> continue my work on navigation/mapping solutions for SFOS and the
>> uncertainty regarding QtLocation is just slowing everything down and lead
>> to major inefficiency in the development of this important aspect of SFOS.
>>
>> I would like to know what is the state of QtLocation and its future in
>> SFOS. From the activity in https://git.merproject.org/mer
>> -core/qtlocation/activity
>> <http://redir.aspx?REF=zWm_Sf04kBkJblyUyNjvCqS4mOnF1wFPhx6A68AtZy0LC5Moh8nUCAFodHRwczovL2dpdC5tZXJwcm9qZWN0Lm9yZy9tZXItY29yZS9xdGxvY2F0aW9uL2FjdGl2aXR5>
>> I conclude that the developers working on it are @chriadam, @pvuorela,
>> @xfade, Slava Monich, and @msmirnov. Maybe some of you can take time and
>> reply. In particular:
>>
>> * Has any work started on upgrading QtLocation to 5.6?
>>
>> * Has Jolla decided whether they want to work on QtLocation/5.6?
>>
>> * If its decided that its impossible to include QtLocation due to
>> licensing issues, can the community help to provide the QtLocation via our
>> packages?
>>
>> * If you just haven't had time for working on QtLocation 5.6, how can we
>> help and where should we start?
>>
>> It looks to me that QtLocation is the component that is pushed for map
>> applications development. I presume that it would be wise to use it as well
>> and not waste time to re-invent something similar. Or is there anything
>> considerably better and we should work on that instead?
>>
>> Since it is developers channel, its an appropriate place to ask, I
>> believe.
>>
>> Best wishes,
>>
>> Rinigus
>>
>> On Tue, Jan 10, 2017 at 10:49 PM, Tone Kastlunger <
>> users.giulie...@gmail.com
>> <http://redir.aspx?REF=EUOWHvr5jEnv6pxp6JMfdOvXxr5kUYRUWfZnQJrvFZ4LC5Moh8nUCAFtYWlsdG86dXNlcnMuZ2l1bGlldHRhQGdtYWlsLmNvbQ..>
>> > wrote:
>>
>>> I'd support this, not enough has been coming through at the meeting IMO
>>> to have a clear yes/no answer.
>>>
>>> Best,
>>> tortoisedoc
>>>
>>> On Mon, Jan 9, 2017 at 11:32 PM, Adam Pigg >> <http://redir.aspx?REF=Ty7ixpUauyWMAaPdQIs5VwKyAP15fbqxGVH7-4nRse0LC5Moh8nUCAFtYWlsdG86YWRhbUBwaWdnei5jby51aw..>
>>> > wrote:
>>>
>>>> I guess we need to wait for the internal review that was mentioned in
>>>> the meeting, however it would be interesting to understand the issues jolla
>>>> have with particular licenses for software included in sfos.
>>>>
>>>> On Mon, 9 Jan 2017 at 21:29 Osmo Salomaa >>> <http://redir.aspx?REF=t28cqNItUuzUjyoP1dTK_fgFVhzqnX8cRi9ZMXZxvl0LC5Moh8nUCAFtYWlsdG86b3RzYWxvbWFAaWtpLmZp>>
>>>> wrote:
>>>>
>>>>> On 09.01.2017 13:01, rinigus wrote:
>>>>> > from reading the meeting transcript it seems that we still don't have
>>>>> > straight answer regarding QtLocation 5.6 ("checking at the moment").
>>>>>
>>>>> They were not wordy, but my interpretation is that nothing has changed
>>>>> regarding QtLocation being allowed in store apps
Re: [SailfishDevel] QtLocation | Qt 5.6
Hi, it would be great to get update on the state of QtLocation 5.6. As suggested by Chris, *"veskuh would be the best person to describe our intent going forward, and possible roadmap for updating"*. In particular, for people working on map and navigation apps, would be good to know * Has Jolla decided whether they want to work on QtLocation/5.6? * If its decided that its impossible to include QtLocation due to licensing issues, can the community help to provide the QtLocation via our packages? * If you just haven't had time for working on QtLocation 5.6, how can we help and where should we start? One of the questions posted earlier (Jul 7) on whether Jolla started working on it was already replied by Chris (No). Best wishes, Rinigus On Thu, Aug 3, 2017 at 8:39 AM, rinigus wrote: > Morning, > > this is to bump the thread with the hope of getting a reply regarding > QtLocation status and plans. > > Cheers, > > Rinigus > > On Thu, Jul 13, 2017 at 9:08 AM, rinigus wrote: > >> Hi Chris, >> >> thank you very much for an update. Looking forward for veskuh's reply >> and, hopefully, we can move forward with this API as well. >> >> Cheers, >> >> Rinigus >> >> On Thu, Jul 13, 2017 at 3:40 AM, Chris Adams >> wrote: >> >>> Hi, >>> >>> I think veskuh will be the best to answer these questions. >>> >>> Currently, I don't think any work has gone toward upgrading QtLocation >>> to version 5.6 yet, as we're busy with other projects. Originally the >>> decision to not take QtLocation 5.6 into use along with the rest of the Qt >>> 5.6 libs was, I believe, because of the different licensing of QtLocation. >>> I think veskuh would be the best person to describe our intent going >>> forward, and possible roadmap for updating. >>> >>> Best regards, >>> Chris. >>> >>> >>> -- >>> *From:* Devel [devel-boun...@lists.sailfishos.org] on behalf of rinigus >>> [rinigus@gmail.com] >>> *Sent:* Friday, July 07, 2017 6:04 PM >>> *To:* Sailfish OS Developers >>> *Subject:* Re: [SailfishDevel] QtLocation | Qt 5.6 >>> >>> Hi, >>> >>> it has been rather quiet regarding QtLocation 5.6 during the "first >>> quarter of 2017" (see earlier emails in this thread). I would like to >>> continue my work on navigation/mapping solutions for SFOS and the >>> uncertainty regarding QtLocation is just slowing everything down and lead >>> to major inefficiency in the development of this important aspect of SFOS. >>> >>> I would like to know what is the state of QtLocation and its future in >>> SFOS. From the activity in https://git.merproject.org/mer >>> -core/qtlocation/activity >>> <http://redir.aspx?REF=zWm_Sf04kBkJblyUyNjvCqS4mOnF1wFPhx6A68AtZy0LC5Moh8nUCAFodHRwczovL2dpdC5tZXJwcm9qZWN0Lm9yZy9tZXItY29yZS9xdGxvY2F0aW9uL2FjdGl2aXR5> >>> I conclude that the developers working on it are @chriadam, @pvuorela, >>> @xfade, Slava Monich, and @msmirnov. Maybe some of you can take time and >>> reply. In particular: >>> >>> * Has any work started on upgrading QtLocation to 5.6? >>> >>> * Has Jolla decided whether they want to work on QtLocation/5.6? >>> >>> * If its decided that its impossible to include QtLocation due to >>> licensing issues, can the community help to provide the QtLocation via our >>> packages? >>> >>> * If you just haven't had time for working on QtLocation 5.6, how can we >>> help and where should we start? >>> >>> It looks to me that QtLocation is the component that is pushed for map >>> applications development. I presume that it would be wise to use it as well >>> and not waste time to re-invent something similar. Or is there anything >>> considerably better and we should work on that instead? >>> >>> Since it is developers channel, its an appropriate place to ask, I >>> believe. >>> >>> Best wishes, >>> >>> Rinigus >>> >>> On Tue, Jan 10, 2017 at 10:49 PM, Tone Kastlunger < >>> users.giulie...@gmail.com >>> <http://redir.aspx?REF=EUOWHvr5jEnv6pxp6JMfdOvXxr5kUYRUWfZnQJrvFZ4LC5Moh8nUCAFtYWlsdG86dXNlcnMuZ2l1bGlldHRhQGdtYWlsLmNvbQ..> >>> > wrote: >>> >>>> I'd support this, not enough has been coming through at the meeting IMO >>>> to have a clear yes/no answer. >>>> >>>> Best, >>>&
Re: [SailfishDevel] QtLocation | Qt 5.6
Tone, while IRC is great for direct communication, I prefer not to allocate my work time for it. Many of us have jobs that are not related to SFOS and it seems to me that the developer's mailing list is appropriate place to ask API-related questions. By sending questions via email, it allows the others to reply at their convenience. I sincerely hope that veskuh will find time to reply to them. Cheers, Rinigus On Wed, Aug 23, 2017 at 10:40 AM, Tone Kastlunger wrote: > @rinigus, drop it as a topic in the meeting thread > > https://together.jolla.com/question/54157/sailfishos- > open-source-collaboration-meeting-planning/ > > On Wed, Aug 23, 2017 at 9:56 AM, rinigus wrote: > >> Hi, >> >> it would be great to get update on the state of QtLocation 5.6. As >> suggested by Chris, *"veskuh would be the best person to describe our >> intent going forward, and possible roadmap for updating"*. In >> particular, for people working on map and navigation apps, would be good to >> know >> >> * Has Jolla decided whether they want to work on QtLocation/5.6? >> >> * If its decided that its impossible to include QtLocation due to >> licensing issues, can the community help to provide the QtLocation via our >> packages? >> >> * If you just haven't had time for working on QtLocation 5.6, how can we >> help and where should we start? >> >> One of the questions posted earlier (Jul 7) on whether Jolla started >> working on it was already replied by Chris (No). >> >> Best wishes, >> >> Rinigus >> >> >> On Thu, Aug 3, 2017 at 8:39 AM, rinigus wrote: >> >>> Morning, >>> >>> this is to bump the thread with the hope of getting a reply regarding >>> QtLocation status and plans. >>> >>> Cheers, >>> >>> Rinigus >>> >>> On Thu, Jul 13, 2017 at 9:08 AM, rinigus wrote: >>> >>>> Hi Chris, >>>> >>>> thank you very much for an update. Looking forward for veskuh's reply >>>> and, hopefully, we can move forward with this API as well. >>>> >>>> Cheers, >>>> >>>> Rinigus >>>> >>>> On Thu, Jul 13, 2017 at 3:40 AM, Chris Adams >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I think veskuh will be the best to answer these questions. >>>>> >>>>> Currently, I don't think any work has gone toward upgrading QtLocation >>>>> to version 5.6 yet, as we're busy with other projects. Originally the >>>>> decision to not take QtLocation 5.6 into use along with the rest of the Qt >>>>> 5.6 libs was, I believe, because of the different licensing of QtLocation. >>>>> I think veskuh would be the best person to describe our intent going >>>>> forward, and possible roadmap for updating. >>>>> >>>>> Best regards, >>>>> Chris. >>>>> >>>>> >>>>> -- >>>>> *From:* Devel [devel-boun...@lists.sailfishos.org] on behalf of >>>>> rinigus [rinigus@gmail.com] >>>>> *Sent:* Friday, July 07, 2017 6:04 PM >>>>> *To:* Sailfish OS Developers >>>>> *Subject:* Re: [SailfishDevel] QtLocation | Qt 5.6 >>>>> >>>>> Hi, >>>>> >>>>> it has been rather quiet regarding QtLocation 5.6 during the "first >>>>> quarter of 2017" (see earlier emails in this thread). I would like to >>>>> continue my work on navigation/mapping solutions for SFOS and the >>>>> uncertainty regarding QtLocation is just slowing everything down and lead >>>>> to major inefficiency in the development of this important aspect of SFOS. >>>>> >>>>> I would like to know what is the state of QtLocation and its future in >>>>> SFOS. From the activity in https://git.merproject.org/mer >>>>> -core/qtlocation/activity >>>>> <http://redir.aspx?REF=zWm_Sf04kBkJblyUyNjvCqS4mOnF1wFPhx6A68AtZy0LC5Moh8nUCAFodHRwczovL2dpdC5tZXJwcm9qZWN0Lm9yZy9tZXItY29yZS9xdGxvY2F0aW9uL2FjdGl2aXR5> >>>>> I conclude that the developers working on it are @chriadam, @pvuorela, >>>>> @xfade, Slava Monich, and @msmirnov. Maybe some of you can take time and >>>>> reply. In particular: >>>>> >>>>> * Has any work started on upgrading QtLocation to 5.6? >>>>> >>>&g
[SailfishDevel] booster loading wrong libstdc++
Hi, I am using gcc-6.4.0 ( https://build.merproject.org/package/show/home:rinigus:toolbox/opt-gcc) for porting/developing C++14 application. Since gcc is compiled with the compatibility switches, it all works quite nicely except that the application does not start from the application grid - I have to launch it from the terminal. Namely, since I use gcc-6.4.0 provided libstdc++, my application has this library under /usr/shared/appname/lib directory. Unfortunately, when I launch the app in the grid, it gets "boosted" with the booster that uses /usr/lib/stdc++.so.6 library. From emulating this launch in terminal (wisdom of @coderus TJC): xdg-open /usr/share/applications/some-application.desktop Failed to invoke: Booster: Loading invoked application failed: '/usr/lib/stdc++.so.6: version `CXXABI_1.3.8` not found (required by ...)' Hence the question: how can I disable the booster in xdg-open launch of my application? Or any other workaround? Best wishes, Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] booster loading wrong libstdc++
Thank you very much - worked as requested! Rinigus On Mon, Sep 11, 2017 at 11:26 AM, Andrew Penkrat wrote: > Hi Rinigus, > > It's possible to disable the booster with > X-Nemo-Application-Type=no-invoker > line in your .desktop file. > > Hope this helps, > Andrew > > On Mon, 11 Sep 2017 at 10:48 rinigus wrote: > >> Hi, >> >> I am using gcc-6.4.0 (https://build.merproject.org/ >> package/show/home:rinigus:toolbox/opt-gcc) for porting/developing C++14 >> application. Since gcc is compiled with the compatibility switches, it all >> works quite nicely except that the application does not start from the >> application grid - I have to launch it from the terminal. Namely, since I >> use gcc-6.4.0 provided libstdc++, my application has this library under >> /usr/shared/appname/lib directory. Unfortunately, when I launch the app in >> the grid, it gets "boosted" with the booster that uses /usr/lib/stdc++.so.6 >> library. From emulating this launch in terminal (wisdom of @coderus TJC): >> >> xdg-open /usr/share/applications/some-application.desktop >> >> Failed to invoke: Booster: Loading invoked application failed: >> '/usr/lib/stdc++.so.6: version `CXXABI_1.3.8` not found (required by ...)' >> >> Hence the question: how can I disable the booster in xdg-open launch of >> my application? Or any other workaround? >> >> Best wishes, >> >> Rinigus >> ___ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to devel-unsubscribe@lists. >> sailfishos.org > > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] booster loading wrong libstdc++
That's what I thought I did already by using "-fabi-version=8 --with-default-libstdcxx-abi=gcc4-compatible" while compiling gcc. Obviously, something is still off. Maybe linking with /usr/bin/g++ would help as well. Would have to look into it in future. Rinigus On Mon, Sep 11, 2017 at 12:43 PM, Timur Kristóf wrote: > You could also try to use the older ABI with your version of GCC and > see if the booster works with that. > > On Mon, Sep 11, 2017 at 9:48 AM, rinigus wrote: > > Hi, > > > > I am using gcc-6.4.0 > > (https://build.merproject.org/package/show/home:rinigus:toolbox/opt-gcc) > for > > porting/developing C++14 application. Since gcc is compiled with the > > compatibility switches, it all works quite nicely except that the > > application does not start from the application grid - I have to launch > it > > from the terminal. Namely, since I use gcc-6.4.0 provided libstdc++, my > > application has this library under /usr/shared/appname/lib directory. > > Unfortunately, when I launch the app in the grid, it gets "boosted" with > the > > booster that uses /usr/lib/stdc++.so.6 library. From emulating this > launch > > in terminal (wisdom of @coderus TJC): > > > > xdg-open /usr/share/applications/some-application.desktop > > > > Failed to invoke: Booster: Loading invoked application failed: > > '/usr/lib/stdc++.so.6: version `CXXABI_1.3.8` not found (required by > ...)' > > > > Hence the question: how can I disable the booster in xdg-open launch of > my > > application? Or any other workaround? > > > > Best wishes, > > > > Rinigus > > > > ___ > > SailfishOS.org Devel mailing list > > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] exclude requires from rpm: libstdc++
Hi,
I have a trouble with excluding libstdc++ requirements from RPM. In my
case, I compile the code with gcc-6.4 and include libstdc++ as an
app-shipped library through /usr/share/appname/lib . Maybe someone could
help to construct exclude define - I didn't managed to cure the
requirements in spec using macro section
%define __provides_exclude_from ^%{_datadir}/.*$
%define __requires_exclude ^libstdc*$
Not sure what I am doing wrong in this case. It would really speed me up if
I can get over this bump. RPM checker errors are:
ERROR [libstdc++.so.6(CXXABI_1.3.8)] Cannot require shared library:
'libstdc++.so.6(CXXABI_1.3.8)'
ERROR [libstdc++.so.6(CXXABI_1.3.9)] Cannot require shared library:
'libstdc++.so.6(CXXABI_1.3.9)'
ERROR [libstdc++.so.6(GLIBCXX_3.4.20)] Cannot require shared library:
'libstdc++.so.6(GLIBCXX_3.4.20)'
ERROR [libstdc++.so.6(GLIBCXX_3.4.21)] Cannot require shared library:
'libstdc++.so.6(GLIBCXX_3.4.21)'
ERROR [libstdc++.so.6(GLIBCXX_3.4.22)] Cannot require shared library:
'libstdc++.so.6(GLIBCXX_3.4.22)'
Please note that, at this stage, I would prefer to ship libstdc++ lib
version with the application.
Cheers,
Rinigus
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] exclude requires from rpm: libstdc++
Bump. Any takers (see below)? Would really help me out with mess induced by
https://build.merproject.org/package/show/home:rinigus:maps/mapbox-demo-sfos
at the corresponding repo.
Rinigus
On Sat, Sep 16, 2017 at 10:17 AM, rinigus wrote:
> Hi,
>
> I have a trouble with excluding libstdc++ requirements from RPM. In my
> case, I compile the code with gcc-6.4 and include libstdc++ as an
> app-shipped library through /usr/share/appname/lib . Maybe someone could
> help to construct exclude define - I didn't managed to cure the
> requirements in spec using macro section
>
>
> %define __provides_exclude_from ^%{_datadir}/.*$
>
> %define __requires_exclude ^libstdc*$
>
>
> Not sure what I am doing wrong in this case. It would really speed me up
> if I can get over this bump. RPM checker errors are:
>
>
> ERROR [libstdc++.so.6(CXXABI_1.3.8)] Cannot require shared library:
> 'libstdc++.so.6(CXXABI_1.3.8)'
>
> ERROR [libstdc++.so.6(CXXABI_1.3.9)] Cannot require shared library:
> 'libstdc++.so.6(CXXABI_1.3.9)'
>
> ERROR [libstdc++.so.6(GLIBCXX_3.4.20)] Cannot require shared library:
> 'libstdc++.so.6(GLIBCXX_3.4.20)'
>
> ERROR [libstdc++.so.6(GLIBCXX_3.4.21)] Cannot require shared library:
> 'libstdc++.so.6(GLIBCXX_3.4.21)'
>
> ERROR [libstdc++.so.6(GLIBCXX_3.4.22)] Cannot require shared library:
> 'libstdc++.so.6(GLIBCXX_3.4.22)'
>
>
> Please note that, at this stage, I would prefer to ship libstdc++ lib
> version with the application.
>
>
> Cheers,
>
>
> Rinigus
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] exclude requires from rpm: libstdc++
Thank you for reply! Yes, I have multiple compilers in use (regular g++ and
6.4.0) for different components. At this stage, optimization of compilers
would be rather difficult and I would prefer to specify corresponding
exclude define. I did try to specify full names, but that did not help. Not
sure whether the library name + extra in brackets play a role over here.
Someone better than me in regex-fu and spec-fu is needed.
Rinigus
On Mon, Sep 18, 2017 at 5:54 PM, Tone Kastlunger
wrote:
> It seems you have 5 different std lib's.
> Find out what is linking them (my guess is different
> components/libraries), change all to one and compile.
> If that is not possible, specify all the libs one by one with full names
> in the spec file.
>
> That's my 2cents
>
> On Mon, Sep 18, 2017 at 12:10 PM, rinigus wrote:
>
>> Bump. Any takers (see below)? Would really help me out with mess induced
>> by https://build.merproject.org/package/show/home:rinigus:ma
>> ps/mapbox-demo-sfos at the corresponding repo.
>>
>> Rinigus
>>
>> On Sat, Sep 16, 2017 at 10:17 AM, rinigus wrote:
>>
>>> Hi,
>>>
>>> I have a trouble with excluding libstdc++ requirements from RPM. In my
>>> case, I compile the code with gcc-6.4 and include libstdc++ as an
>>> app-shipped library through /usr/share/appname/lib . Maybe someone could
>>> help to construct exclude define - I didn't managed to cure the
>>> requirements in spec using macro section
>>>
>>>
>>> %define __provides_exclude_from ^%{_datadir}/.*$
>>>
>>> %define __requires_exclude ^libstdc*$
>>>
>>>
>>> Not sure what I am doing wrong in this case. It would really speed me up
>>> if I can get over this bump. RPM checker errors are:
>>>
>>>
>>> ERROR [libstdc++.so.6(CXXABI_1.3.8)] Cannot require shared library:
>>> 'libstdc++.so.6(CXXABI_1.3.8)'
>>>
>>> ERROR [libstdc++.so.6(CXXABI_1.3.9)] Cannot require shared library:
>>> 'libstdc++.so.6(CXXABI_1.3.9)'
>>>
>>> ERROR [libstdc++.so.6(GLIBCXX_3.4.20)] Cannot require shared library:
>>> 'libstdc++.so.6(GLIBCXX_3.4.20)'
>>>
>>> ERROR [libstdc++.so.6(GLIBCXX_3.4.21)] Cannot require shared library:
>>> 'libstdc++.so.6(GLIBCXX_3.4.21)'
>>>
>>> ERROR [libstdc++.so.6(GLIBCXX_3.4.22)] Cannot require shared library:
>>> 'libstdc++.so.6(GLIBCXX_3.4.22)'
>>>
>>>
>>> Please note that, at this stage, I would prefer to ship libstdc++ lib
>>> version with the application.
>>>
>>>
>>> Cheers,
>>>
>>>
>>> Rinigus
>>>
>>
>>
>> ___
>> SailfishOS.org Devel mailing list
>> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi
>> shos.org
>>
>
>
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscribe@lists.
> sailfishos.org
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] exclude requires from rpm: libstdc++
That helped - thank you very much!
Rinigus
On Mon, Sep 18, 2017 at 6:47 PM, wrote:
> I think the regexp is wrong. You miss a . before the start. ^libstdc.*$
>
> Hope it helps.
>
> Damien.
>
> Le Lundi 18 septembre 2017, rinigus a écrit :
> > Bump. Any takers (see below)? Would really help me out with mess induced
> by
> > https://build.merproject.org/package/show/home:rinigus:
> maps/mapbox-demo-sfos
> > at the corresponding repo.
> >
> > Rinigus
> >
> > On Sat, Sep 16, 2017 at 10:17 AM, rinigus wrote:
> >
> > > Hi,
> > >
> > > I have a trouble with excluding libstdc++ requirements from RPM. In my
> > > case, I compile the code with gcc-6.4 and include libstdc++ as an
> > > app-shipped library through /usr/share/appname/lib . Maybe someone
> could
> > > help to construct exclude define - I didn't managed to cure the
> > > requirements in spec using macro section
> > >
> > >
> > > %define __provides_exclude_from ^%{_datadir}/.*$
> > >
> > > %define __requires_exclude ^libstdc*$
> > >
> > >
> > > Not sure what I am doing wrong in this case. It would really speed me
> up
> > > if I can get over this bump. RPM checker errors are:
> > >
> > >
> > > ERROR [libstdc++.so.6(CXXABI_1.3.8)] Cannot require shared library:
> > > 'libstdc++.so.6(CXXABI_1.3.8)'
> > >
> > > ERROR [libstdc++.so.6(CXXABI_1.3.9)] Cannot require shared library:
> > > 'libstdc++.so.6(CXXABI_1.3.9)'
> > >
> > > ERROR [libstdc++.so.6(GLIBCXX_3.4.20)] Cannot require shared library:
> > > 'libstdc++.so.6(GLIBCXX_3.4.20)'
> > >
> > > ERROR [libstdc++.so.6(GLIBCXX_3.4.21)] Cannot require shared library:
> > > 'libstdc++.so.6(GLIBCXX_3.4.21)'
> > >
> > > ERROR [libstdc++.so.6(GLIBCXX_3.4.22)] Cannot require shared library:
> > > 'libstdc++.so.6(GLIBCXX_3.4.22)'
> > >
> > >
> > > Please note that, at this stage, I would prefer to ship libstdc++ lib
> > > version with the application.
> > >
> > >
> > > Cheers,
> > >
> > >
> > > Rinigus
> > >
> >
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscribe@lists.
> sailfishos.org
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] conventions for distribution of QML plugins
Hi, I am preparing QML plugin that I would like to distribute. Since this plugin will be used by QML+Python applications, its probably the best to install it into /usr/lib/qt5/qml/PluginName directory. As far as I could see, several plugins are installed like that (QtLocation, for example), while others are using subdirectories to build the hierarchy of plugins. Hence the question: do we have any convention that should be followed in SFOS? Mer? I am aware that Jolla Store does not accept third-party plugins at this moment. Hopefully, this will change in future. Best wishes, Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] conventions for distribution of QML plugins
Hi Richard, thank you very much for this link to TJC! I do tend to forget about TJC as a source of useful information. However, in the example for plugin distribution ( https://together.jolla.com/question/10713/create-the-example-of-including-your-own-library-and-standard-qt-module-in-a-harbour-compatible-way/), the path for QML imports has been altered in C++ main ( https://github.com/d0b3rm4n/harbour-simpletorch/blob/6c1e36513269cc6f13921fd65ee7c5c222184fa8/src/harbour-simpletorch.cpp#L49). That probably doesn't work for Python-based apps which are expected to be rather prominent users for my plugin. Any idea on how to alter QML import path for Python? While we would be probably fine outside the harbour, some devs may publish there as soon as QtLocation debacle is resolved. Best wishes, Rinigus On Fri, Sep 29, 2017 at 11:20 AM, richard grooff wrote: > Hi, > > There's some info on this topic in this question on tjc > <https://together.jolla.com/question/10713/create-the-example-of-including-your-own-library-and-standard-qt-module-in-a-harbour-compatible-way/> > (in > case you are not aware of it). > > Create the example of including your own library and standard Qt module ... > > Harbour rules let you use only few QML modules and libraries. You can ship > libraries and modules together with y... > > <https://together.jolla.com/question/10713/create-the-example-of-including-your-own-library-and-standard-qt-module-in-a-harbour-compatible-way/> > > Best regards, Richard > > On Thursday, September 28, 2017, 1:13:55 PM GMT+2, rinigus < > rinigus@gmail.com> wrote: > > > Hi, > > I am preparing QML plugin that I would like to distribute. Since this > plugin will be used by QML+Python applications, its probably the best to > install it into /usr/lib/qt5/qml/PluginName directory. As far as I could > see, several plugins are installed like that (QtLocation, for example), > while others are using subdirectories to build the hierarchy of plugins. > Hence the question: do we have any convention that should be followed in > SFOS? Mer? > > I am aware that Jolla Store does not accept third-party plugins at this > moment. Hopefully, this will change in future. > > Best wishes, > > Rinigus > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Harbour compatible background apps?
Hi, actually, systemd daemons are also compatible with Jolla Harbour. There are limitations that you have to follow, but its possible to make and publish Jolla Harbour app that can be used as a daemon. The example of published app/daemon is OSM Scout Server. While it can be used as an app, it can be configured to run as a socket activated systemd daemon (systemd, thank you for this excellent way to provide such service!). All configuration works from the app as well, no additional scripts need to be run by users. The limitations that you have to follow: * all systemd interaction should be done as an ordinary user (nemo in our case). Hence, you could run your daemon as a user's own daemon. Not a limitation in my case * you can provide only one executable in RPM which has to be an app. In my case, its resolved by running as a regular QML app normally and as a service only if specific command line options are given. If you want to provide it as a background service, I would suggest to make enabling / disabling from the app. That would make it easier for users to use it. Cheers, Rinigus On Sat, Nov 25, 2017 at 2:26 PM, Андрей Кожевников wrote: > Battery overlay also. > > 25 нояб. 2017 г. 15:24 пользователь "Dylan Van Assche" < > dylan.van.ass...@protonmail.com> написал: > > Hi CODeRUS, > > Oh I didn't know that Screentapshot used this approach, thanks a lot! > > Cheers, > Dylan Van Assche > > > > Original Message > Subject: Re: [SailfishDevel] Harbour compatible background apps? > Local Time: 25 November 2017 10:41 AM > UTC Time: 25 November 2017 09:41 > From: coderusin...@gmail.com > To: Dylan Van Assche , Sailfish OS > Developers > > Hello, yes this is harbour-compatible. > For example i have this app published in store: https://github.com/CODe > RUS/harbour-screentapshot > > 2017-11-25 12:34 GMT+03:00 Dylan Van Assche via Devel < > devel@lists.sailfishos.org>: > >> Hi Devs, >> >> I found a repo from CODeRUS with an example of a background app: >> https://github.com/CODeRUS/background-application-example/tree/master/src >> >> Is this Harbour compatible? The Harbour FAQ allows this AFAIK since it's >> not a real daemon, it just hides the UI from the screen while that the C++ >> backend still runs. >> If so, this would be great to send notifications in the background and >> when the user clicks on the notification, we can show the UI by calling >> it's DBus endpoint. >> >> Kind regards, >> Dylan Van Assche >> >> >> >> >> ___ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi >> shos.org >> > > > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] PreventStealing (against the page stack navigation) for a horizontal ListView || QtLocation 5.6?
> > BTW: We have the exact same issue with our map page. The 'Map' component > *is* > derived from 'MouseArea', but its still on version 5.0/5.2, where > 'preventStealing' wasn't available yet. I know, I asked this before, but > can > we expect QtLoction 5.6 to enter the Sailfish SDK and be officially allowed > for harbour apps --- an when? :) > If you can accept two tiny-tiny limitations - not compatible with Harbour and doesn't work with Jolla 1 due to what seems to be hardware limitation - there is a new map component that exposes Mapbox GL Native to QML: https://github.com/rinigus/mapbox-gl-qml . Its compiled for 5.6, easy to work with, documented, and gives you access to hardware accelerated map rendering. See examples at http://talk.maemo.org/showthread.php?t=99953 . I plan to publish the package for this map component as soon as I finish the work on offline support for Mapbox GL (rather major undertaking) at OpenRepos. Right now you could grab it at OBS. Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] libicu
Hi, when using non-Qt libraries, its sometimes required to link to libicu with its friends. When distributing applications linking to it, you end up with 25MB of library data that is also provided in the system. On my device, there are three apps using it (2 mine). With many complaining about Sony X root partition size, I wonder how standard this library is in SFOS installations. I would expect its always there. If it is standard, shouldn't we get it into permitted libs list for Jolla Harbour? Cheers, Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] libicu
Well, in my case, I am surely not going to drop it since its used by Mapbox and Valhalla. But making such specific-tailored libicu is not high enough on priority either - there are so many other things to do first. So, Pekka, I hope you'll succeed with libicu optimization that we could just link to it and add as dependency to our applications. Best wishes, Rinigus On Sat, Dec 23, 2017 at 9:16 AM, Tone Kastlunger wrote: > One would question at this point, whats the benefit of this library if > such complex scenario needs to be considered > each time you need to use it :) > > On Fri, Dec 22, 2017 at 11:11 AM, Pekka Vuorela > wrote: > >> On Thu, 2017-12-21 at 21:33 +0200, rinigus wrote: >> > Hi, >> > >> > when using non-Qt libraries, its sometimes required to link to libicu >> > with its friends. When distributing applications linking to it, you >> > end up with 25MB of library data that is also provided in the system. >> > On my device, there are three apps using it (2 mine). With many >> > complaining about Sony X root partition size, I wonder how standard >> > this library is in SFOS installations. I would expect its always >> > there. If it is standard, shouldn't we get it into permitted libs >> > list for Jolla Harbour? >> >> Sorry, but not that simple: >> http://userguide.icu-project.org/design#TOC-ICU-Binary-Compatibility:-U >> sing-ICU-as-an-Operating-System-Level-Library >> <http://userguide.icu-project.org/design#TOC-ICU-Binary-Compatibility:-Using-ICU-as-an-Operating-System-Level-Library> >> >> I've long hoped for getting icu updated too (which isn't too simple >> either). Guess there could be hope in having some day support with the >> rules set in above link, we already do build with --disable-renaming. >> >> In the meanwhile, it's also possible to strip away a lot of data from >> icu builds: >> http://userguide.icu-project.org/icudata#TOC-Customizing-ICU-s-Data-Lib >> rary >> >> ___ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi >> shos.org > > > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] libicu
Correction: Mapnik and Valhalla - Mapbox is OpenGL/Qt based. Rinigus On Sat, Dec 23, 2017 at 5:36 PM, rinigus wrote: > Well, in my case, I am surely not going to drop it since its used by > Mapbox and Valhalla. But making such specific-tailored libicu is not high > enough on priority either - there are so many other things to do first. So, > Pekka, I hope you'll succeed with libicu optimization that we could just > link to it and add as dependency to our applications. > > Best wishes, > > Rinigus > > On Sat, Dec 23, 2017 at 9:16 AM, Tone Kastlunger < > users.giulie...@gmail.com> wrote: > >> One would question at this point, whats the benefit of this library if >> such complex scenario needs to be considered >> each time you need to use it :) >> >> On Fri, Dec 22, 2017 at 11:11 AM, Pekka Vuorela >> wrote: >> >>> On Thu, 2017-12-21 at 21:33 +0200, rinigus wrote: >>> > Hi, >>> > >>> > when using non-Qt libraries, its sometimes required to link to libicu >>> > with its friends. When distributing applications linking to it, you >>> > end up with 25MB of library data that is also provided in the system. >>> > On my device, there are three apps using it (2 mine). With many >>> > complaining about Sony X root partition size, I wonder how standard >>> > this library is in SFOS installations. I would expect its always >>> > there. If it is standard, shouldn't we get it into permitted libs >>> > list for Jolla Harbour? >>> >>> Sorry, but not that simple: >>> http://userguide.icu-project.org/design#TOC-ICU-Binary-Compatibility:-U >>> sing-ICU-as-an-Operating-System-Level-Library >>> <http://userguide.icu-project.org/design#TOC-ICU-Binary-Compatibility:-Using-ICU-as-an-Operating-System-Level-Library> >>> >>> I've long hoped for getting icu updated too (which isn't too simple >>> either). Guess there could be hope in having some day support with the >>> rules set in above link, we already do build with --disable-renaming. >>> >>> In the meanwhile, it's also possible to strip away a lot of data from >>> icu builds: >>> http://userguide.icu-project.org/icudata#TOC-Customizing-ICU-s-Data-Lib >>> rary >>> >>> ___ >>> SailfishOS.org Devel mailing list >>> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi >>> shos.org >> >> >> >> ___ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi >> shos.org >> > > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Mer PIM build questions
Hi Liukas, I suspect you'll be hitting the closed source components: https://together.jolla.com/question/167645/open-source-roadmap-from-the-community-point-of-view/?answer=167780#post-id-167780 https://together.jolla.com/question/167645/open-source-roadmap-from-the-community-point-of-view/?answer=167658#post-id-167658 For some reason, there are no Jolla-backed replies regarding plans nor timeline in opening them. As for buteo, I think you should be able to compile it (as much as you can) on regular SDK. At least, as far as I remember, carddav/caldav could be done there. As for `iodata-qt5-type-to-c++` tool - no idea. Good luck, Rinigus On Thu, Jan 18, 2018 at 1:57 PM, Lukáš Karas wrote: > Hi all. > > I am little bit frustrated from the state of PIM on SFOS. > It is painful to use Sailfish on primary phone when you are using google > services for managing contacts and calendars. From rare activity > in buteo-sync-plugins-social repository [1] seems to me that noone > is activelly developing it right now. > > Fot that reason, I want to resolve some bugs [2] myself and create merge > request. Before any programming I need environment for build and testing. > I want to create docker environment (x86_64) for testing [3]. I am really > the > first one who is trying it? I don't find any existing docker image with Mer > components... It is possibly that I am going to wrong direction, but I have > good experince with developign inside docker and it was my first choice... > > Now the main question - when I try to build mer-core/timed, there are few > `*.type` files that should be compiled by `iodata-qt5-type-to-c++` tool. > But how this should be done in the build? In src/server/server.pro:17 > is defined IODATA_TYPES with list of these files, but there is nothing > about > it in generated Makefile. There is some qmake plugin or preparison step > that I overlook? > > Regards, Lukas > > 1) https://git.merproject.org/mer-core/buteo-sync-plugins-social > 2) https://together.jolla.com/question/162657/google- > calendar-not-syncing-new-events/?sort=votes&page=1 > 3) https://github.com/Karry/mer-devel > 4) https://git.merproject.org/mer-core/timed/blob/master/src/server/ > server.pro#L17 > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Keep an application running without keeping the window open
Hi, the obvious solution is to run service that is 24/7 on and separate client for GUI. That's what stock messaging is doing. I would recommend it and use some simple messaging API for communicating between them. There are probably many APIs to choose that will allow you to set it up simply. If you can withstand short shutdown of the service then you can combine it into the same application. It would require that application will start in GUI or server mode depending on command line option. If started in GUI mode, you would have to * shut down service via systemd * establish new connections and on GUI exit you would have to * drop all connections * start service via systemd The latter is the way OSM Scout Server works with the adjustment that its using systemd sockets to keep it switched off when user is not accessing it. Note that it was done for historical reasons (signaling between parts was implemented via Qt) and since its mostly used as a service anyway (users don't need to access GUI for weeks). I would still recommend splitting service/GUI parts and use some messaging protocol in between. Myself I would have used zeromq, but you could choose probably many others. Cheers, Rinigus On Mon, Feb 5, 2018 at 11:17 AM, Marcin Mielniczuk wrote: > Hi, > > When creating SFOS applications which should run 24/7 (e.g. IMs) we > would like to achieve similar behavior as the stock applications, e.g. > the stock e-mail client: the sync (*) runs in the background, even > though the application is closed. A window staying open just to make > sure the sync goes on clutters the open app view and makes it more > difficult to manage the open applications. > > On a desktop DE one would simply minimize the application to tray. > Alternatively, one could create a daemon which the client app would > communicate with using UNIX sockets, but it greatly increases the > complexity of the application and slows down the development. > > What's the easiest way to keep the sync process in the background > without keeping the window open? > > Regards, > Marcin > > (*) when speaking sync, I mean any kind of waiting for a remote event, > no matter if it's done by idle TCP (which is good) or HTTP polling > (which is not good) > > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Keep an application running without keeping the window open
Hi, from the point of view of portability, having a split GUI and backend should be nicely portable. Even focusing on systemd would cover large portion of Linux distributions, but you don't have to include any systemd dependencies as such. On desktop, it would allow you to move the backend into dedicated hardware, if you wish. Also, it would survive X11 crashes as a bonus. So, if you plan to run it 24x7, service running on the background is a good way of doing it. But maybe someone has better idea. Cheers, Rinigus On Sat, Feb 17, 2018 at 9:16 PM, Marcin Mielniczuk wrote: > I'm not sure if that's a good choice when trying to achieve portability. > Usually on desktop you'd rather have a monolithic application with just > minimize to tray. > > Any other options? > > On 05.02.2018 10:33, rinigus wrote: > > Hi, > > the obvious solution is to run service that is 24/7 on and separate client > for GUI. That's what stock messaging is doing. I would recommend it and use > some simple messaging API for communicating between them. There are > probably many APIs to choose that will allow you to set it up simply. > > If you can withstand short shutdown of the service then you can combine it > into the same application. It would require that application will start in > GUI or server mode depending on command line option. If started in GUI > mode, you would have to > > * shut down service via systemd > * establish new connections > > and on GUI exit you would have to > > * drop all connections > * start service via systemd > > The latter is the way OSM Scout Server works with the adjustment that its > using systemd sockets to keep it switched off when user is not accessing > it. Note that it was done for historical reasons (signaling between parts > was implemented via Qt) and since its mostly used as a service anyway > (users don't need to access GUI for weeks). > > I would still recommend splitting service/GUI parts and use some messaging > protocol in between. Myself I would have used zeromq, but you could choose > probably many others. > > Cheers, > > Rinigus > > On Mon, Feb 5, 2018 at 11:17 AM, Marcin Mielniczuk > wrote: > >> Hi, >> >> When creating SFOS applications which should run 24/7 (e.g. IMs) we >> would like to achieve similar behavior as the stock applications, e.g. >> the stock e-mail client: the sync (*) runs in the background, even >> though the application is closed. A window staying open just to make >> sure the sync goes on clutters the open app view and makes it more >> difficult to manage the open applications. >> >> On a desktop DE one would simply minimize the application to tray. >> Alternatively, one could create a daemon which the client app would >> communicate with using UNIX sockets, but it greatly increases the >> complexity of the application and slows down the development. >> >> What's the easiest way to keep the sync process in the background >> without keeping the window open? >> >> Regards, >> Marcin >> >> (*) when speaking sync, I mean any kind of waiting for a remote event, >> no matter if it's done by idle TCP (which is good) or HTTP polling >> (which is not good) >> >> >> ___ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi >> shos.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
[SailfishDevel] linking to systemd
Hi, I have been linking my app to -lsystemd-daemon for about 6 month. This is to allow usage of systemd sockets suggested by several smart users. Such integration with systemd made it possible to have the application running in the background and provide the expected "invisible" service. As many of us, I added one more shared library into the forest of libraries shipped with the application: libsystemd-daemon. Unfortunately, it looks like new SDK 1710 requires me to extend -lsystemd-daemon "private shared lib" also by adding -lsystemd, libresolv, and libcap into the pool of shared libraries shipped with an app. Which, I think, is getting somewhat out of hand. So, I am asking to whitelist systemd libraries in https://github.com/sailfishos/sdk-harbour-rpmvalidator/issues/102 Best wishes, Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] hunspell
Hi, I wonder whether anyone has packaged more recent version of hunspell than the one available at https://git.merproject.org/mer-core/hunspell and on our devices? Also, it looks like mer repo contains source dump of hunspell. If I remember other repos correctly, it seems to be the way for other packages as well. Any reasons for preferring such model instead of git submodules? Looks to be more difficult to update it to the current version. Best wishes, Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] hunspell
For those who are interested in up-to-date hunspell, I have packaged it under https://github.com/rinigus/pkg-hunspell with the builds available at https://build.merproject.org/package/show/home:rinigus:keyboard/hunspell . Packaging script is based on https://git.merproject.org/mer-core/hunspell with the further split of development and tools packages for hunspell. That allows to get hunspell as a static library and build against it. Cheers, Rinigus On Mon, Feb 26, 2018 at 9:15 AM, rinigus wrote: > Hi, > > I wonder whether anyone has packaged more recent version of hunspell than > the one available at https://git.merproject.org/mer-core/hunspell and on > our devices? > > Also, it looks like mer repo contains source dump of hunspell. If I > remember other repos correctly, it seems to be the way for other packages > as well. Any reasons for preferring such model instead of git submodules? > Looks to be more difficult to update it to the current version. > > Best wishes, > > Rinigus > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] keyboard development
Hi, I have a question regarding the longer term plans for keyboard development in SFOS. Namely, @martonmiklos has brought over Presage predictor to SFOS and already published keyboard using this library. I think its a great development and together with @ljo we have been helping @martonmiklos to make this plugin better. Please note that below, I speak for myself and I haven't checked whether these questions even make sense with others. At present, the released plugin has been enhanced by making it fast through using different language model storage/query mechanism, using relatively small size of n-gram database (English 5MB, Estonian 10MB), made asynchronous to ensure that the user's input is not lagging behind, and just extended with Hunspell speller as an additional "predictor". All is in the testing / bugfixing stage. In longer term, with the right effort, we could get very well working open-source predictive engine and keyboard. I am trying to understand how the pieces fall together and I am not sure 100% whether I do. I can see that SFOS uses proprietary jolla-keyboard and the developed Presage input handler extends it. Which is fine, but maybe we could go deeper and do better. >From looking around, Maliit has adopted keyboard developed by Ubuntu Touch as a reference, corresponding Maliit repo https://github.com/maliit/keyboard . In addition to UBPorts, the same keyboard is used by LuneOS. This design already supports Presage and Hunspell, also done in asynchronous manner as we are testing for SFOS now. It has support for quite a few number of languages, pinyin, and emoji. I do not know how this design compares to the internals of jolla-keyboard and maybe someone can share their knowledge regarding it. I would expect that it was developed on the top of Maliit available at the time of J1 and kept as it is after that. Now, I do wonder what is the long term plan with the keyboard development? >From the outside of Jolla, it seems to me that it would be wise to join forces with the others and develop this component together. Each OS in question has their own styling, but that seems to be possible to apply on top. Its not trivial to compile the latest Maliit on SFOS (they switched to CMake based builds and few cmake configs are missing in SFOS right now), but I expect that its possible with some effort. Just don't want to spend too much time if it's gonna be without any use. So, to summarize, I would like to hear what's an opinion on the raised issues by those who know. Would be great to know plans and comparison of jolla-keyboard with the current Maliit UBPorts/LuneOS versions. Best wishes, Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] keyboard development
Hi Mike, great to hear from you! I don't have many specific questions yet, but thanks for reply and giving heads up. As I mentioned in the mail, we have extended Presage with the new language model that maybe of interest to your keyboard implementation as well. Speedup is of the order of 10x, maybe more in addition to the significant reduction on database size. We are discussing also Unicode support by Presage to properly support case-insensitive n-gram search, not via `tolower` as done now. It will probably change the database format to implement properly, but then should stabilize. If there is anyone from UBPorts interested in joining Presage development - we would be happy to get any help :) We could surely share n-gram databases between the platforms. It takes some effort to generate them, including hunting down good corpora and processing them. Would be wise to keep the generated databases in a form that would allow simple re-use of them. Few general questions though: * If I want to test the keyboard, is there VirtualBox (or some other similar) emulator for Ubuntu Touch / UBPorts? * Do you have some mailing list or some other means where we could discuss joint projects with UBPorts developers? * If we would like to port UBPorts keyboard, would it mainly require changes in https://github.com/ubports/keyboard-component/tree/master/qml , icons and schema. Or would you expect some other parts require adaptation? Just an estimate would be fine at this stage. I would expect that the keyboard performs its own tokenization to split between the text on the left and the last word that needs prediction. Later, when Presage is called, strings are put back together and Presage is splitting it to words again. Which, in addition to double effort, can be source of confusion if the split to words doesn't match. From the brief look into the code with the help of grep, it looks like tokens are split by spaces and few other similar chars (\n) with the exception of plugins/ko. Do you happen to have some API that could be used to plugin different tokenization library, same Presage for example? But before going into major porting of the keyboard, would be good to know what Jolla's plans are regarding their keyboard. They should be back in the office now after a great time in Spain, hopefully we can hear back. Best wishes, Rinigus On Mon, Mar 5, 2018 at 4:18 PM, Mike Sheldon wrote: > Hey Rinigus, > > I've been out of the Jolla ecosystem for a while (since my phone was lost > a couple of years ago), so can't say anything much about the Jolla > keyboard; but I was the lead developer on the Ubuntu Keyboard at Canonical > so am happy to answer any specific questions you have about that. > > Cheers, > Mike > > On Wed, Feb 28, 2018 at 7:14 PM, rinigus wrote: > >> Hi, >> >> I have a question regarding the longer term plans for keyboard >> development in SFOS. Namely, @martonmiklos has brought over Presage >> predictor to SFOS and already published keyboard using this library. I >> think its a great development and together with @ljo we have been >> helping @martonmiklos to make this plugin better. Please note that below, I >> speak for myself and I haven't checked whether these questions even make >> sense with others. >> >> At present, the released plugin has been enhanced by making it fast >> through using different language model storage/query mechanism, using >> relatively small size of n-gram database (English 5MB, Estonian 10MB), made >> asynchronous to ensure that the user's input is not lagging behind, and >> just extended with Hunspell speller as an additional "predictor". All is in >> the testing / bugfixing stage. In longer term, with the right effort, we >> could get very well working open-source predictive engine and keyboard. >> >> I am trying to understand how the pieces fall together and I am not sure >> 100% whether I do. I can see that SFOS uses proprietary jolla-keyboard and >> the developed Presage input handler extends it. Which is fine, but maybe we >> could go deeper and do better. >> >> From looking around, Maliit has adopted keyboard developed by Ubuntu >> Touch as a reference, corresponding Maliit repo https://github.com/maliit >> /keyboard . In addition to UBPorts, the same keyboard is used by LuneOS. >> This design already supports Presage and Hunspell, also done in >> asynchronous manner as we are testing for SFOS now. It has support for >> quite a few number of languages, pinyin, and emoji. I do not know how this >> design compares to the internals of jolla-keyboard and maybe someone can >> share their knowledge regarding it. I would expect that it was developed on >> the top of Maliit available at the time of J1 an
Re: [SailfishDevel] hunspell
Yes, I did and I followed the new standard by using git submodules. Packaging is somewhat different from the previous version in a sense that it adds static library in devel package. This would allow developers to choose whether to link statically or dynamically in response to the current Harbour rules. Rinigus On Tue, Mar 6, 2018 at 3:41 PM, Pekka Vuorela wrote: > On Tue, 2018-02-27 at 15:35 +0200, rinigus wrote: > > For those who are interested in up-to-date hunspell, I have packaged > > it under https://github.com/rinigus/pkg-hunspell with the builds > > available at https://build.merproject.org/package/show/home:rinigus:k > > eyboard/hunspell . > > > > Packaging script is based on https://git.merproject.org/mer-core/huns > > pell with the further split of development and tools packages for > > hunspell. That allows to get hunspell as a static library and build > > against it. > > > > I wonder whether anyone has packaged more recent version of > > > hunspell than the one available at https://git.merproject.org/mer-c > > > ore/hunspell and on our devices? > > > > > > Also, it looks like mer repo contains source dump of hunspell. If I > > > remember other repos correctly, it seems to be the way for other > > > packages as well. Any reasons for preferring such model instead of > > > git submodules? Looks to be more difficult to update it to the > > > current version. > > Looks like you made a PR for the update. Nice, we'll look into that. > > For the record, some older packages are having source code dumps. Those > have been gradually migrated for git submodule setup for easier > maintenance and usage. > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] keyboard development
> > > That's interesting, you might also be interested in taking a look at my > (unfinished) Skeyer branch: > > https://code.launchpad.net/~michael-sheldon/ubuntu-keyboard/ > skeyer-prototype > > That uses saidinesh's libskeyer to provide auto-correction (and eventually > swipe style input), this provides spatially aware corrections (i.e. it > knows that 'b' is next to 'n' on an English keyboard so would suggest 'and' > as a correction for 'abd' instead of Presage's prediction of 'abdicate'). I > think the strongest approach would involve a combination of the two, using > Skeyer for correction and Presage for prediction. > Interesting, we'll surely think about it. On SFOS, we have OKboard that has implementation of swipe style input, but its probably good to think about using keyboard-aware correction. However, as @ljo described, we don't have such issue with `abd` in the presage version that has hunspell added as a dictionary predictor. It would depend on corpora used for training, but in our case we get "bad", "and", "abd" as the three first suggestions. Mike, thanks for the tips regarding the keyboard internals, they are very helpful. I'll register at UBPorts forums to get into some discussions (not using telegram). Cheers, Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] keyboard development
Hi Pekka Thank you very much for the reply. I have inserted my replies below. > Short recap on history. Original Maliit reference plugin was developed > for Nokia N9, I was the lead developer for that. On Jolla I wanted to > do more QML centric one, based on lessons learned on original Maliit > keyboard and another virtual keyboard at Nokia. Ubuntu keyboard went > another way and continued from the old code base, think it was also > made public after Jolla keyboard had proceeded a lot. > OK, so we now where the development diverged and the branch between Jolla and Ubuntu (now Maliit default). > Now, I do wonder what is the long term plan with the keyboard > > development? From the outside of Jolla, it seems to me that it would > > be wise to join forces with the others and develop this component > > together. Each OS in question has their own styling, but that seems > > to be possible to apply on top. > > Not sure if it would be worth much redoing Jolla UI on top of another > plugin. Would make the base more complex by requiring extendability of > different things. > It will surely require time and, in ideal world, is a needless duplication of an effort in a small OS which has many other components that would need more attention. I agree with that aspect. What matters more is ability to reuse different input method engines on > different keyboards. While not being too familiar with the current > state of maliit-keyboard project, I'd expect it to be somewhat easy > anyway. Qml can reuse list model regardless of api elsewhere. For > integrating input to jolla-keyboard it's mostly just implementing > handler functions for key press/release/click. For general western > input that is currently little over 100 lines, some more for updating > layout geometry to the prediction engine. > Indeed, we have now the input method that links presage to jolla-keyboard written by @martonmiklos. We could probably go a long way by expanding Presage with correct handling of Unicode string, implementing tokenization in Presage to support more languages and exposing this functionality to the plugin. This work can be reused then by any keyboard, not even limited to Maliit. > Its not trivial to compile the latest Maliit on SFOS (they switched > > to CMake based builds and few cmake configs are missing in SFOS right > > now), but I expect that its possible with some effort. Just don't > > want to spend too much time if it's gonna be without any use. > > Guess it depends on what you're up to. If CMake modules make sense on > other projects then PRs welcome (some already packaged). If for > keyboard you want to have ability to tinker and use a different one > then just go ahead :) Maliit framework supports also having multiple > plugins, but on Sailfish we've relied on just using the single one that > is found, multiple ones might trigger code that hasn't been much tested > for a while. Indeed, it depends on the priorities. Personally, I am interested in developing open-source prediction/correction engine since I am using a ported device and want to have good and working solution without Xt9. Throw in the fact that Estonian probably doesn't have Xt9 support and you have my main interest formulated. However, in the background, I also like our approach since we rely on open-source libraries and this is transparent to the users community as well as gives us an ability to reuse the components elsewhere. When talking about one of the main user-interacting component in the OS, such as keyboard, the transparency does become an important part of the discussion. Large fraction of jolla-keyboard code is in QML and we can see what QML is doing, if we wish. However, there is a library blob which I have no way of knowing what's going on there. All I can see is that its linked to all kinds of other libraries through its dependencies, including network libraries as well. So, its essentially comes down to the trust that the version that I have installed on my device doesn't call somewhere with something. The trust that I do have at this moment. But I do find the situation far from ideal and would prefer to have open stack for myself and all other end users in the core components of the OS. In particular, the parts which are used for communication and user input. So, when we talk talk about longer-term plans with the keyboard, it would be important to know whether jolla-keyboard is scheduled to become open-source component in foreseeable future or not. If it is not then I presume we should have a discussion within the community on what to do about it and whether anyone wants to work on adapting open-source components. Which, in the end, is the burden for the community that would lead to investment of time and effort that would come at expense
Re: [SailfishDevel] keyboard development
Hi Eekkelund, great to hear from you! As, I am sure, many others in the community, I look on what you guys are doing over IRC. I did look a bit into nemomobile-ux/plugins. Its based on original Maliit plugin, as far as I understood and its not developed upstream anymore. From the lack of response regarding open-sourcing Jolla's keyboard, I presume that the status is the same - we are committed to the eventual release, but don't have anyone to commit to it. Which is fair enough, but, on our side, maybe not the best strategy to wait indefinitely. As for qtvirtuakeyboard, I don't know much. From grepping the source, it looks like prediction is limited to hunspell, t9, and Asian languages. I don't know about its architecture and how it compares to Maliit. The prediction engine that we develop is OSS and has minimal dependencies, as far as I understand, on Jolla's keyboard. Presage is developed as separate library, so its easy to plugin it to the other keyboards. So, it should be easy to integrate into whatever keyboard you will choose. Also the plugin that we work on can be probably reused in the other keyboards, at least partially, if needed. It looks to me that Ubuntu's keyboard has more developers behind and it maybe good for us to join them to get fully OSS option. I would be interested in switching over to fully OSS predictive keyboard. Don't know how Nemo / SFOS will mix and whether SFOS users would need to have Silica based one. But that we can probably learn later. Best wishes, Rinigus On Sun, Mar 18, 2018 at 10:54 AM, eetu wrote: > Hi Rinigus, > > I just wanted to bring to your attention the Nemo Mobile maliit-plugin > keyboard (https://github.com/nemomobile-ux/plugins). It is fully > open-source and it can run on SailfishOS devices. > > Only thing that we are lacking is the prediction support and some small > features. We are considering about moving to new maliit keyboard(based on > ubuntu maliit) or then qtvirtuakeyboard(https://github.com/qt/ > qtvirtualkeyboard). > > I am really interested in your keyboard project and would like to > contribute to it so that Nemo would also have updated keyboard! > > > BR, > -eekkelund :) > > > > > On 03/07/18 12:11, rinigus wrote: > > Hi Pekka > > Thank you very much for the reply. I have inserted my replies below. > > >> Short recap on history. Original Maliit reference plugin was developed >> for Nokia N9, I was the lead developer for that. On Jolla I wanted to >> do more QML centric one, based on lessons learned on original Maliit >> keyboard and another virtual keyboard at Nokia. Ubuntu keyboard went >> another way and continued from the old code base, think it was also >> made public after Jolla keyboard had proceeded a lot. >> > > OK, so we now where the development diverged and the branch between Jolla > and Ubuntu (now Maliit default). > > > > Now, I do wonder what is the long term plan with the keyboard >> > development? From the outside of Jolla, it seems to me that it would >> > be wise to join forces with the others and develop this component >> > together. Each OS in question has their own styling, but that seems >> > to be possible to apply on top. >> >> Not sure if it would be worth much redoing Jolla UI on top of another >> plugin. Would make the base more complex by requiring extendability of >> different things. >> > > It will surely require time and, in ideal world, is a needless duplication > of an effort in a small OS which has many other components that would need > more attention. I agree with that aspect. > > > What matters more is ability to reuse different input method engines on >> different keyboards. While not being too familiar with the current >> state of maliit-keyboard project, I'd expect it to be somewhat easy >> anyway. Qml can reuse list model regardless of api elsewhere. For >> integrating input to jolla-keyboard it's mostly just implementing >> handler functions for key press/release/click. For general western >> input that is currently little over 100 lines, some more for updating >> layout geometry to the prediction engine. >> > > Indeed, we have now the input method that links presage to jolla-keyboard > written by @martonmiklos. We could probably go a long way by expanding > Presage with correct handling of Unicode string, implementing tokenization > in Presage to support more languages and exposing this functionality to the > plugin. This work can be reused then by any keyboard, not even limited to > Maliit. > > > > Its not trivial to compile the latest Maliit on SFOS (they switched >> > to CMake based builds and few cmake configs are missing in S
[SailfishDevel] Map applications in Harbour
Hi, reading through this week community meeting, I saw that Jolla is planning to have internal discussions regarding map apps and the open-source predictive keyboard. While keyboard is somewhat simpler case (in terms of dependencies), I would like to save Jolla's time and list the dependencies required for inclusion of such mapping applications as WhoGo Maps. This internal discussion is very much welcome and I would like to stress that such incorporation is actually relatively simple. 1: It may sound surprising, but we need ability to use QtPositioning and QtLocation. In this sense, application developers have much faster response time than Jolla and I am sure we'll be able to adapt to transition from QtPositioning/QtLocation 5.2 to 5.6 in a blink of an eye, comparing to soon^TM. 2: WhoGo Maps (and sports app Laufhelden) use Mapbox GL for showing maps. This is done via QML plugin https://github.com/rinigus/mapbox-gl-qml . The plugin is based on recent QtLocation code and my own development on the basis of it. Its API has been designed to make it simple to access Mapbox GL functionality from pure QML applications and was shaped while I was porting Poor Maps to this widget. Since API is in our own hands, we could keep it as stable as we please. To compile the plugin, Mapbox GL branch specifically developed for QtLocation inclusion is used. This requires newer gcc; SFOS version is compiled with gcc 6.4 ( https://build.merproject.org/package/show/home:rinigus:toolbox/opt-gcc). Plugin license is LGPLv3 since some of the code comes from newer QtLocation. Plugin and corresponding QMapboxGL are packaged and compiled at OBS. I don't know Mer's licensing policy and who is deciding it (community or Jolla), but it seems to me that this QML maybe incorporated into it. Alternative would be to have it in some separate repository. 3: For voice instructions, we need TTS engines. Two of them (mimic, flite based; picoTTS) are available and packaged at OBS. I would suggest to incorporate them into Mer Finally, regarding online/offline maps and EU network charges. The privacy, network coverage redundancy, and requirements for OSM Scout Server have been addressed during the meeting by community members. However, while network access is much cheaper in EU, don't forget that online maps require a server on the other side. There are few commercial solutions, but, they are not cheap. @otsaloma had to install his own server to go around these costs. So, with incorporation of maps software and distribution of it among many users (many is relative) may lead to a requirement of setting up the server(s) or paying for it. Offline maps are cheaper due to the local processing of requests, but may require larger network bandwidth to get maps on devices. So far, @MartinK and @bomo are distributing maps prepared by me via their servers (thank you!). I hope that I didn't forget anything. Have a nice weekend, Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Map applications in Harbour
> > Also, it seems that the Qt version of Mapbox GL native is fairly new and > has seen significant updates and fixes in new versions, so there's a > significant benefit in having a separate package for this as getting it via > a Qt LTS release means quite a long delay. Do you have a list of the Mapbox > GL version you package vs. in Qt 5.9 and 5.12? > It looks like this is not that bad - they update QMapboxGL with the updates withing 5.9 and 5.11 branches. The submodule commit referenced in https://github.com/qt/qtlocation/tree/5.9.4/src/3rdparty is the one that is from the end of Nov 2017 ( https://github.com/qt/qtlocation-mapboxgl/commits/upstream/qt-staging), so, previous version (qt-v1.2.0). Although, that version I skipped since it had rather annoying bug which made symbols that were changing position blink on every change. We are now on qt-v1.3.0, released in March 8 and which had many enhancements and bug fixes. So, by having it separate from Qt, we can test it on our devices and see if, in practice, this version works. There is one more difference between SFOS and upstream version. We use libcurl internally, since otherwise, offline communication was impossible ( https://together.jolla.com/question/175944/network-access-to-localhost-disabled-for-qt-when-network-interfaces-are-down/ ) > > > Finally, regarding online/offline maps and EU network charges. The > privacy, > > network coverage redundancy, and requirements for OSM Scout Server have > > been addressed during the meeting by community members. However, while > > network access is much cheaper in EU, don't forget that online maps > require > > a server on the other side. There are few commercial solutions, but, they > > are not cheap. @otsaloma had to install his own server to go around these > > costs. > > And still my custom solution is not even close to the quality of Mapbox's > maps, in part due to my lack of design skills, in part due the low detail > level of tiles from OpenMapTiles.com. It would be best to have some kind of > a platform solution as Mapbox's maps are unreasonably expensive for a hobby > project once past the free plan. It's likely worth asking if Mapbox would > be interested in some kind of a deal, getting some exposure and testing for > their Qt version. > Due to OpenMapTiles licensing and limitations, I worked through the whole pipeline of the import. But, I agree, work on map import and styling is difficult and, if possible, it would be great to agree some deal with Mapbox. Even if each user could pay for a service separately, that would be of advantage. Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Harbour compatibility - including multiple executables in a single RPM
Hi David, the rules regarding single executable haven't changed, to my knowledge. That particular problem was solved for my case by writing a wrapper and called either QML main or the main I wanted to use from Valhalla ( https://github.com/rinigus/osmscout-server-route/blob/master/src/harbour-osmscout-server-module-route.cpp#L19). This solution would work, but its a touch harder to maintain. In the end, its up to you whether you want to have the app in the harbour or not. After all, its your decision. However, I would suggest to consider distribution via OpenRepos and not waste too much time for working around Harbour rules. Best wishes, Rinigus PS: Ironically, few month later, I had to pull out of Harbour anyway due to the changes in systemd API On Mon, May 14, 2018 at 4:12 PM, David Llewellyn-Jones wrote: > Hi, > > The Harbour rpmvalidator is currently highlighting problems with my app > because it has more than one executable packaged with it. I get errors > like this: > > ERROR [/usr/share/harbour-getiplay/lib/bin/rtmpdump] ELF binary in wrong > location (must be /usr/bin/harbour-getiplay) > > ERROR [/usr/share/harbour-getiplay/lib/bin/rtmpdump] File must not be > executable (current permissions: 755) > > Is there any way to create a Harbour-compatible package that includes > more than one executable? From the validator, it looks to be impossible, > but the FAQ doesn't say anything about it, so I'm still hopeful :) > > For context, my app is just a UI wrapper around a separate executable > that I call using QProcess. Since the underlying executable isn't > written by me (and itself calls several other executables), integrating > them into a single executable would be hard. > > David > > P.S. I checked the mailing list archives and together.jolla.com, and > although this has come up before (e.g. > https://lists.sailfishos.org/pipermail/devel/2017-May/007898.html) I > didn't see any clear solutions or conclusions. > -- > Website: http://www.flypig.co.uk > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Harbour compatibility - including multiple executables in a single RPM
Hi David, > the rules regarding single executable haven't changed, to my knowledge. > > I actually can't see anything in the rules that states you can't have > multiple executables, but it is a requirement to pass through the > rpmvalidator. If it's a requirement, I'm thinking it would be helpful to > make this explicit in the FAQ (which is the closest thing I'm aware of > to a stated set of rules). > You are probably right, but I haven't checked the text of the rules recently. They may "hide" it behind that you are expected to have your exe be called harbour-something and only that way. > That particular problem was solved for my case by writing a wrapper and > > called either QML main or the main I wanted to use from Valhalla > > (https://github.com/rinigus/osmscout-server-route/blob/ > master/src/harbour-osmscout-server-module-route.cpp#L19). > > Just so I'm clear, for your workaround you joined the two code bases at > compile time? > Yes, exactly this way Unfortunately that won't work in my case, because I have my programme > (C++) calling a Perl programme, which then calls another (C-complied) > executable. It's possible using Perl would be reason enough to reject > from Harbour, but one step at a time! The issue of multiple executables > seems more fundamental to me. > > > This solution would work, but its a touch harder to maintain. In the > > end, its up to you whether you want to have the app in the harbour or > > not. After all, its your decision. However, I would suggest to consider > > distribution via OpenRepos and not waste too much time for working > > around Harbour rules. > > Ultimately, I agree it's much simpler to release through OpenRepos (I'm > already doing this in fact), and I can appreciate the frustration for > you of having to pull your app later. At least you achieved it, even f > just temporarily. Getting something into Harbour is an important life > goal for me ;) > I understand, its a sport in the beginning. There is a simpler solution - you can always release a fart app for getting into the store :) Cheers, Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] exposing map matching as a geoposition service
Hi, Since Valhlalla's routing engine is available on SFOS in offline mode, I am working on exposing its functionality to the mapping applications. I am focused now on bringing just-in-time navigation information via map matching (https://github.com/valhalla/valhalla/blob/master/docs/api/ map-matching/api-reference.md). In particular, on demand, snapping the recorded GPS positions to the road network (modes for car, bicycle, walking) and obtaining information regarding the current position (street name, speed limit, direction of motion). There are more data available, but let's try with something simpler. I looked into whether its possible to write Qt QGeoPositionInfoSource that would offer such data. Unfortunately, QGeoPositionInfo seems to have fixed structure and cannot be extended. So, a custom solution is needed. [I am sure we can propose to extend it to Qt, but that would take a while to get it on SFOS via Qt upgrade]. For the developers of the applications, I would like to write QML type that can be used as a replacement for QML PositionSource and, in addition to classical QML PositionSource, offer data via map matched results. So, in addition to position property, there would be additional properties describing current map matched results. To make it possible, I am considering extending OSM Scout Server with D-Bus service that would emit a signal with updated data once per `updateInterval` of the position source. Instead of response-reply, such approach would allow to push the data from the source to the client which should be more efficient and allow the data reuse by different applications. As usual, devil is in the details. Since I haven't used D-Bus earlier in my programs, there are several questions that I would like to ask. * In general, does the approach via D-Bus make sense? Or am I missing something better? * When the map matched results are of interest, its OSM Scout Server that will start GPS communication via Qt C++ API and will emit the signal once per each position change. It will have to stop GPS as soon as there are no more interested clients. So, what's the common practice in this use case? Ask client to start/stop (set `active`)? How I am expected to shutdown GPS access when the clients crashed? * I would like to enable automatic service start when someone tries to access it via D-Bus. As far as I have seen, its possible via .service file in /usr/share/dbus-1/services. However, the server runs as nemo-owned process and, if possible, I would prefer to keep the configuration files installed by RPM in nemo's home. This would give me an option to publish the server via store iff systemd-service activation will be allowed in future. Is there some way to make it? * What's the recommended way to communicate with D-Bus in Qt C++? D-Bus Adaptors (https://doc.qt.io/qt-5/usingadaptors.html)? * Any good example compatible with LGPL3 and doing something similar to what I am after? B est wishes, Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] exposing map matching as a geoposition service
Dear List, I think I managed to resolve most of the questions myself. The one that stands still is * I would like to enable automatic service start when someone tries to access it via D-Bus. As far as I have seen, its possible via .service file in /usr/share/dbus-1/services. However, the server runs as nemo-owned process and, if possible, I would prefer to keep the configuration files installed by RPM in nemo's home. This would give me an option to publish the server via store iff systemd-service activation will be allowed in future. Is there some way to make it? So, if someone knows it from the top of the head, would be great to hear it. Cheers, Rinigus On Mon, Jul 16, 2018 at 10:31 AM, rinigus wrote: > Hi, > > Since Valhlalla's routing engine is available on SFOS in offline mode, I > am working on exposing its functionality to the mapping applications. I am > focused now on bringing just-in-time navigation information via map > matching (https://github.com/valhalla/valhalla/blob/master/docs/api/m > ap-matching/api-reference.md). In particular, on demand, snapping the > recorded GPS positions to the road network (modes for car, bicycle, > walking) and obtaining information regarding the current position (street > name, speed limit, direction of motion). There are more data available, but > let's try with something simpler. > > I looked into whether its possible to write Qt QGeoPositionInfoSource that > would offer such data. Unfortunately, QGeoPositionInfo seems to have fixed > structure and cannot be extended. So, a custom solution is needed. [I am > sure we can propose to extend it to Qt, but that would take a while to get > it on SFOS via Qt upgrade]. > > For the developers of the applications, I would like to write QML type > that can be used as a replacement for QML PositionSource and, in addition > to classical QML PositionSource, offer data via map matched results. So, > in addition to position property, there would be additional properties > describing current map matched results. > > To make it possible, I am considering extending OSM Scout Server with > D-Bus service that would emit a signal with updated data once per > `updateInterval` of the position source. Instead of response-reply, such > approach would allow to push the data from the source to the client which > should be more efficient and allow the data reuse by different > applications. > > As usual, devil is in the details. Since I haven't used D-Bus earlier in > my programs, there are several questions that I would like to ask. > > * In general, does the approach via D-Bus make sense? Or am I missing > something better? > > * When the map matched results are of interest, its OSM Scout Server that > will start GPS communication via Qt C++ API and will emit the signal once > per each position change. It will have to stop GPS as soon as there are no > more interested clients. So, what's the common practice in this use case? > Ask client to start/stop (set `active`)? How I am expected to shutdown GPS > access when the clients crashed? > > * I would like to enable automatic service start when someone tries to > access > it via > D-Bus. As far as I have seen, its possible via .service file in > /usr/share/dbus-1/services. However, the server runs as nemo-owned process > and, if possible, I would prefer to keep the configuration files > installed by RPM > in nemo's home. > This would give me an option to publish the server via store iff > systemd-service activation will be allowed in future. Is there some way to > make it? > > * What's the recommended way to communicate with D-Bus in Qt C++? > D-Bus Adaptors > (https://doc.qt.io/qt-5/usingadaptors.html)? > > > * > Any good example compatible with LGPL3 and doing something similar to > what I am after? > > B > est wishes, > > > Rinigus > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] exposing map matching as a geoposition service
> > > my 5cent > best unix practice says you install the configuration globally > (/usr/share/) and the application should create a user copy when > first run. > A server can run as nemo process and despite of this read /usr/share. In > fact this is how it is intended to work. User can not write to /usr/share > but this is also more than OK. > Agreed. That's the way systemd socket activation of the server works already. On the first run, user is asked whether (s)he wants to have autostart of the service and, on agreement, systemd socket and server files are written into ~/.local/share/systemd and corresponding socket activation is enabled. So, I wonder, if there is something similar for D-Bus. Something that would allow me to configure its autostart. I can as well trigger autostart via systemd inet port, but would be nice to have it transparent on D-Bus as well. Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] exposing map matching as a geoposition service
Hi Deloptes, sorry for confusing request. In my case, I want to autostart my application which can work in service (behind the scenes) or GUI mode. Which is relatively rare on SFOS, but has a great use in the case of map services provider, as it is in this case. But OK, unless I get some good idea, I will 'bump' my application to autostart through systemd socket by contacting it via HTTP and then contact my application via DBus. Rinigus On Fri, Jul 20, 2018 at 1:14 AM, deloptes wrote: > rinigus wrote: > > > So, I wonder, if there is something similar for D-Bus. Something that > > would allow me to configure its autostart. I can as well trigger > autostart > > via systemd inet port, but would be nice to have it transparent on D-Bus > > as well. > > > > Well DBus is just a message bus and you can use it what it is good for. For > example you can let user process communicate with a process with higher > privileges. As of autostarting dbus, it is done with the user session, so > you already have it. > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] app hangs on shutdown
Hi, I am working on Pure Maps - a fork of @otsaloma's map applications. As a background: Its a Python app, with pyotherside used for QML/Python interaction. Its also using Mapbox GL widget that I wrote on the basis of Mapbox GL QtLocation plugin. I am facing a problem which I don't know how to solve, hence asking for help. Namely, Pure Maps sometimes does not shutdown cleanly after closure by the user. Namely, when app is closed in GUI (I presume close guesture or touching X in SFOS overview mode), the process stays. Same if the app is started from terminal - if the shutdown was unsuccessful, terminal prompt does not return after closing the program. And here were the mystery starts. With the suspicion that maybe some python call is hanging, the printouts were added before and after Python calls (through QML Python wrapper). Regardless to whether the app was shutdown cleanly or was left hanging, the calls (sync or async) always returned. I have added printout statements in Component.onDestruction for key QML items in the app and could see that, when the app hangs, none of the onDestruction handlers were called. Hence the question, what could cause Silica app to refuse starting destruction cascade? This issue is mainly reported by J1 users and I had a great help from @pichlo with debugging it. Sometimes, we observed OOM killing of other app during the navigation. So, I presume, the device is under significant RAM pressure. But still, I am rather blank on where to debug it further and what could cause such behavior. For the record, haven't seen this on my device (onyx). Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] app hangs on shutdown
We debugged a failure to initiate destruction further. As suggested
by @wdehoog, I added
Connections {
target: __quickWindow
onClosing: console.log("")
}
to ApplicationWindow. This one does get called during app closure, without
further propagation over to destruction of items.
Any ideas on how to debug it further?
Rinigus
On Sat, Sep 8, 2018 at 4:24 PM rinigus wrote:
> Hi,
>
> I am working on Pure Maps - a fork of @otsaloma's map applications. As a
> background: Its a Python app, with pyotherside used for QML/Python
> interaction. Its also using Mapbox GL widget that I wrote on the basis of
> Mapbox GL QtLocation plugin.
>
> I am facing a problem which I don't know how to solve, hence asking for
> help. Namely, Pure Maps sometimes does not shutdown cleanly after closure
> by the user. Namely, when app is closed in GUI (I presume close guesture or
> touching X in SFOS overview mode), the process stays. Same if the app is
> started from terminal - if the shutdown was unsuccessful, terminal prompt
> does not return after closing the program.
>
> And here were the mystery starts. With the suspicion that maybe some
> python call is hanging, the printouts were added before and after Python
> calls (through QML Python wrapper). Regardless to whether the app was
> shutdown cleanly or was left hanging, the calls (sync or async) always
> returned.
>
> I have added printout statements in Component.onDestruction for key QML
> items in the app and could see that, when the app hangs, none of the
> onDestruction handlers were called.
>
> Hence the question, what could cause Silica app to refuse starting
> destruction cascade?
>
> This issue is mainly reported by J1 users and I had a great help
> from @pichlo with debugging it. Sometimes, we observed OOM killing of other
> app during the navigation. So, I presume, the device is under significant
> RAM pressure. But still, I am rather blank on where to debug it further and
> what could cause such behavior.
>
> For the record, haven't seen this on my device (onyx).
>
> Rinigus
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] app hangs on shutdown
No, I didn't. Its QML/Python app, so it is not clear what I should attach
the debugger to. sailfish-qml?
Rinigus
On Sun, Sep 9, 2018 at 12:35 PM Slava Monich wrote:
> Have you tried debugging with a debugger (run the app under gdb and
> examine the backtrace when it gets stuck)? That seems to be the obvious
> first step to me.
> Cheers,
> -Slava
>
> We debugged a failure to initiate destruction further. As suggested
> by @wdehoog, I added
>
>Connections {
> target: __quickWindow
> onClosing: console.log("")
> }
>
>
> to ApplicationWindow. This one does get called during app closure, without
> further propagation over to destruction of items.
>
> Any ideas on how to debug it further?
>
> Rinigus
>
>
>
> On Sat, Sep 8, 2018 at 4:24 PM rinigus wrote:
>
>> Hi,
>>
>> I am working on Pure Maps - a fork of @otsaloma's map applications. As a
>> background: Its a Python app, with pyotherside used for QML/Python
>> interaction. Its also using Mapbox GL widget that I wrote on the basis of
>> Mapbox GL QtLocation plugin.
>>
>> I am facing a problem which I don't know how to solve, hence asking for
>> help. Namely, Pure Maps sometimes does not shutdown cleanly after closure
>> by the user. Namely, when app is closed in GUI (I presume close guesture or
>> touching X in SFOS overview mode), the process stays. Same if the app is
>> started from terminal - if the shutdown was unsuccessful, terminal prompt
>> does not return after closing the program.
>>
>> And here were the mystery starts. With the suspicion that maybe some
>> python call is hanging, the printouts were added before and after Python
>> calls (through QML Python wrapper). Regardless to whether the app was
>> shutdown cleanly or was left hanging, the calls (sync or async) always
>> returned.
>>
>> I have added printout statements in Component.onDestruction for key QML
>> items in the app and could see that, when the app hangs, none of the
>> onDestruction handlers were called.
>>
>> Hence the question, what could cause Silica app to refuse starting
>> destruction cascade?
>>
>> This issue is mainly reported by J1 users and I had a great help
>> from @pichlo with debugging it. Sometimes, we observed OOM killing of other
>> app during the navigation. So, I presume, the device is under significant
>> RAM pressure. But still, I am rather blank on where to debug it further and
>> what could cause such behavior.
>>
>> For the record, haven't seen this on my device (onyx).
>>
>> Rinigus
>>
>
>
> ___
> 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
[SailfishDevel] Command line arguments and DBus integration for QML/Python apps
Hi, I would like to add geo: handling into Pure Maps. While command line arguments can be used through Qt.application.arguments in QML, its not very clear how to take into account already running instance. Namely, we are expected to have only one instance of application running and as a result, if some other application calls geo: handler, it is expected that the map application will become active and show corresponding location. If I would have full control over application start, as in C++ applications, I would probably made: * DBus interface * on start checked whether such interface is active/available. * If active DBus interface is there, would have called corresponding DBus method and exited * If not, started full application QML/Python apps, such as Pure Maps, are started using sailfish-qml. This arrangement, as far as I can see, prevents such handling. It looks to me that I should write some kind of launcher (Python probably) that could be used to either communicate with the main application via DBus or start the full application. Or am I wrong? Maybe there is some better idea for implementation of such functionality? Cheers, Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Command line arguments and DBus integration for QML/Python apps
Martin and Martin, thank you! Re libcontentaction: maybe. I will have to look into it. There are no docs regarding it, right? Looks like it supports QML via plugin, now just would have to make sense of it. From a brief look into the source, it may cover the needed geo: handling quite well. Re sailfish-qml & comand line arguments: I tested reading fom Python and QML. Python didn't work (sys.argv), QML worked well. So, it seems to be well hooked on QML side. Re python launcher: From reading your reply, if libcontentaction will not work, I've got an idea that we could also make shell scripts (harbour-pure-maps, harbour-modrana) that would use dbus-send command and bash magic to figure out whether to communicate via dbus or exec new instance. It maybe even Jolla Harbour compatible, not sure whether they test for what's in executable (although its none of my problem by being outside of the store). Re delay: (assuming that libcontentaction is not helping us) starting script could be avoided when using the launcher by having the same launcher as we have now. That way all the boosting will stay the same and additional delay (if any) will be visible only when started from some other application. Cheers, Rinigus On Mon, Dec 10, 2018 at 10:07 AM Martin Kampas wrote: > Hi Rinigus, > > > > libcontentaction might be what you are looking for > https://git.merproject.org/mer-core/libcontentaction > > > > BR, > > Martin > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] qt upgrade
Hi, sounds like there are porting and licensing issues on the way of getting qt 5.9 for SFOS (see logs from the last #mer-meeting). Its all understandable, but it would be great to get a way forward. Not sure whether it has been considered by others and I wonder whether we can make a separate Qt 5.12 packages for /opt/qt512? >From a quick test, it is possible to run non-silica applications as well (tested with qmlscene and QML with plain Window). In that test, even keyboard worked as expected. Look was non-native, but let it be for now. So, I wonder, whether its possible to get Qt 5.12 compiled with /opt/qt512 prefix and then use it for development using the latest libs (new web browser?) and collaborate with other mobile Linux'es out there. As far as I remember, Wayland was rather old and, maybe, it will preclude Qt 5.12 compilation. @mal, though, had a newer version around and it may serve a purpose for such project. Is there anything else that should be considered? Cheers, Rinigus PS: Please consider it as request-for-comment and not as any kind of statement nor call-for-action :) ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] qt upgrade
Morning, suggestion to consider Qt 5.12 in /opt comes from the following: * newer web engine * we can use and contribute to the code written for Plasma with its Kirigami It will not bring native new applications, we don't have Silica for it. However, I personally think it makes more sense to use and help out with the development of Linux-based solutions than to use Android-provided web browsers through SFOS Android compatibility layer. This would not to be intended to be installed in /usr and having platform supporting multiple Qt versions at once. I have no idea whether its possible and no desire to get into messing up the system layer. Dmitriy: I don't know whether you can mix different Qt versions in the same application. In this respect, yes, you could probably ship Qt 512 stack fully, but would probably have to stay away from the system-provided Qt. Leszek: fragmentation is to be considered, indeed. But, as far as I understood, it makes sense to develop browser against the last version of Qt. In some aspect, using Qt59 on SFOS contributes to fragmentation in a way that we, on SFOS, will be using the version that is slowly phased out already. At present, Kirigami is developed using Qt512, with Qt511 version having at least one bug that will never be fixed. Not sure whether Kirigami runs against Qt59. So, if we would like to run Kirigami apps, Qt 5.12 is most probably needed. Cheers, Rinigus On Sun, Feb 10, 2019 at 8:55 AM Dmitriy Purgin wrote: > Hi all, > > if there are some parts of the newer Qt you need in your app, you can > always compile it yourself, link your app against the newer version and > ship these libraries with your app. > > Cheers > Dmitriy > > On Sat, Feb 9, 2019 at 6:44 PM rinigus wrote: > >> Hi, >> >> sounds like there are porting and licensing issues on the way of getting >> qt 5.9 for SFOS (see logs from the last #mer-meeting). Its all >> understandable, but it would be great to get a way forward. Not sure >> whether it has been considered by others and I wonder whether we can make a >> separate Qt 5.12 packages for /opt/qt512? >> >> From a quick test, it is possible to run non-silica applications as well >> (tested with qmlscene and QML with plain Window). In that test, even >> keyboard worked as expected. Look was non-native, but let it be for now. >> >> So, I wonder, whether its possible to get Qt 5.12 compiled with >> /opt/qt512 prefix and then use it for development using the latest libs >> (new web browser?) and collaborate with other mobile Linux'es out there. As >> far as I remember, Wayland was rather old and, maybe, it will preclude Qt >> 5.12 compilation. @mal, though, had a newer version around and it may serve >> a purpose for such project. Is there anything else that should be >> considered? >> >> Cheers, >> >> Rinigus >> >> PS: Please consider it as request-for-comment and not as any kind of >> statement nor call-for-action :) >> ___ >> 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
Re: [SailfishDevel] qt upgrade
Nice work, so, there is already something similar done. Can't find where do you define _qt_prefix for your SPEC ( https://git.merproject.org/Kaffeine/qtbase/blob/sailfish-platform-5.9/rpm/qtbase.spec). There are also bunch of conflicts defined there, no idea whether they interfere. Which issues did you have with Wayland and keyboard (which of them, maliit or qtvirtualkeyboard?). @tortoisedoc: Sounds like this upgrade (5.6->5.9) is as much political as it is technical. As for 5.12, I don't know if there are some bugs there that have to be fixed. When using flatpak platform with 5.12, I have issues with QML Audio and some strange scaling of the map (latter could be also my bug in mapbox gl qml plugin). On 5.11, all performed as it was expected. So, either flatpak platform has still some issues at 5.12 or 5.12 itself has some bugs. To sum up, no idea how much we can help with 5.9 transition and what's holding it back specifically. Rinigus On Sun, Feb 10, 2019 at 11:17 AM Alexander Akulich < akulichalexan...@gmail.com> wrote: > Hi, > > I experimented with a build in prefix in March 2018. I changed MER Qt > build configuration to make it trivial to install an arbitrary number > of versions simultaneously. I'll make PRs on git.merproject.org once > Qt-5.9 support will be merged to master. > There are two issues — wayland and virtual keyboard. I posted > instruction in Sailfish OS Fan Club group in Telegram, here it is: > > >// Qt 5.9 for Sailfish OS (installed to /usr/lib/qt5.9 simultaneously to > the system Qt) > >// To install (root or privileged): > >ssu ar qt-prefix-5.9 > http://repo.merproject.org/obs/home:/Kaffeine:/qt:/prefix:/5.9/latest_armv7hl > >zypper ref qt-prefix-5.9 > >zypper in qt5.9-qtquickcontrols2-examples qt5.9-qtwayland > > > >// To remove (root or privileged): > >zypper rm qt5.9* > > > >// To try out (nemo): > >QT_SCALE_FACTOR=2 LD_LIBRARY_PATH=/usr/lib/qt5.9/lib > /usr/lib/qt5.9/examples/quickcontrols2/gallery/gallery > > > >This is a very first success build, please do not expect much :). > > > >P.S.: Select Material style in the settings at the right top corner to > make the demo a bit nicer. > > I also mostly built Qt-5.11, but it is not an LTS and IMO not as big > step forward as 5.9, so I didn't evolve it. > > On Sat, Feb 9, 2019 at 8:44 PM rinigus wrote: > > > > Hi, > > > > sounds like there are porting and licensing issues on the way of getting > qt 5.9 for SFOS (see logs from the last #mer-meeting). Its all > understandable, but it would be great to get a way forward. Not sure > whether it has been considered by others and I wonder whether we can make a > separate Qt 5.12 packages for /opt/qt512? > > > > From a quick test, it is possible to run non-silica applications as well > (tested with qmlscene and QML with plain Window). In that test, even > keyboard worked as expected. Look was non-native, but let it be for now. > > > > So, I wonder, whether its possible to get Qt 5.12 compiled with > /opt/qt512 prefix and then use it for development using the latest libs > (new web browser?) and collaborate with other mobile Linux'es out there. As > far as I remember, Wayland was rather old and, maybe, it will preclude Qt > 5.12 compilation. @mal, though, had a newer version around and it may serve > a purpose for such project. Is there anything else that should be > considered? > > > > Cheers, > > > > Rinigus > > > > PS: Please consider it as request-for-comment and not as any kind of > statement nor call-for-action :) > > ___ > > 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
Re: [SailfishDevel] qt upgrade
No go, file conflicts appeared for several packages trying to overwrite qt56 installation. For example, qt5.9-qtdeclarative-qtquick was trying to write /usr/lib/libQt5Quick.so.5 . I presume something changed in OBS and your prefix path wasn't picked up. Rinigus On Sun, Feb 10, 2019 at 1:01 PM Alexander Akulich < akulichalexan...@gmail.com> wrote: > The keypoints of the build: > - upstream Qt-5.9.6 > - Q_OS_SAILFISH platform [1] > - Sailfish Theme added as a plugin instead of direct > QGenericUnixTheme patching [2] > - _qt5_version re-defined in the OBS project config [3] (default value > defined in qt5 macros). > - qt5 macros [4] extended and moved to own repository [5]. The added > macros fix installations conflicts, improve compatibility with fedora > specs and let us flexibly define Qt installation layout from the > outside of qtbase. > - qtchooser-config is built as a part of qtbase. > > [1] > https://git.merproject.org/Kaffeine/qtbase/commit/7b8850fc9df17384a8cf53dc8b1d1e435e806794 > [2] > https://git.merproject.org/Kaffeine/qtbase/commit/816d9f7fe4fac0208d672086ae910cae772dcd32 > [3] > https://build.merproject.org/project/prjconf/home:Kaffeine:qt:prefix:5.9 > [4] > https://git.merproject.org/mer-core/qtbase/blob/mer-5.6/rpm/macros.qt5-default > [5] > https://git.merproject.org/Kaffeine/qt5-rpm-macros/blob/master/macros.qt5 > > Just try quickcontrols2/gallery and you'll see what's the problem > (maliit keyboard doesn't show up and the window doesn't appear in > lipstick home screen). > > On Sun, Feb 10, 2019 at 1:07 PM rinigus wrote: > > > > Nice work, > > > > so, there is already something similar done. Can't find where do you > define _qt_prefix for your SPEC ( > https://git.merproject.org/Kaffeine/qtbase/blob/sailfish-platform-5.9/rpm/qtbase.spec). > There are also bunch of conflicts defined there, no idea whether they > interfere. > > > > Which issues did you have with Wayland and keyboard (which of them, > maliit or qtvirtualkeyboard?). > > > > @tortoisedoc: Sounds like this upgrade (5.6->5.9) is as much political > as it is technical. As for 5.12, I don't know if there are some bugs there > that have to be fixed. When using flatpak platform with 5.12, I have issues > with QML Audio and some strange scaling of the map (latter could be also my > bug in mapbox gl qml plugin). On 5.11, all performed as it was expected. > So, either flatpak platform has still some issues at 5.12 or 5.12 itself > has some bugs. > > > > To sum up, no idea how much we can help with 5.9 transition and what's > holding it back specifically. > > > > Rinigus > > > > On Sun, Feb 10, 2019 at 11:17 AM Alexander Akulich < > akulichalexan...@gmail.com> wrote: > >> > >> Hi, > >> > >> I experimented with a build in prefix in March 2018. I changed MER Qt > >> build configuration to make it trivial to install an arbitrary number > >> of versions simultaneously. I'll make PRs on git.merproject.org once > >> Qt-5.9 support will be merged to master. > >> There are two issues — wayland and virtual keyboard. I posted > >> instruction in Sailfish OS Fan Club group in Telegram, here it is: > >> > >> >// Qt 5.9 for Sailfish OS (installed to /usr/lib/qt5.9 simultaneously > to the system Qt) > >> >// To install (root or privileged): > >> >ssu ar qt-prefix-5.9 > http://repo.merproject.org/obs/home:/Kaffeine:/qt:/prefix:/5.9/latest_armv7hl > >> >zypper ref qt-prefix-5.9 > >> >zypper in qt5.9-qtquickcontrols2-examples qt5.9-qtwayland > >> > > >> >// To remove (root or privileged): > >> >zypper rm qt5.9* > >> > > >> >// To try out (nemo): > >> >QT_SCALE_FACTOR=2 LD_LIBRARY_PATH=/usr/lib/qt5.9/lib > /usr/lib/qt5.9/examples/quickcontrols2/gallery/gallery > >> > > >> >This is a very first success build, please do not expect much :). > >> > > >> >P.S.: Select Material style in the settings at the right top corner to > make the demo a bit nicer. > >> > >> I also mostly built Qt-5.11, but it is not an LTS and IMO not as big > >> step forward as 5.9, so I didn't evolve it. > >> > >> On Sat, Feb 9, 2019 at 8:44 PM rinigus wrote: > >> > > >> > Hi, > >> > > >> > sounds like there are porting and licensing issues on the way of > getting qt 5.9 for SFOS (see logs from the last #mer-meeting). Its all > understandable, but it would be great to get a way forward. Not sure > whether it has been cons
Re: [SailfishDevel] qt upgrade
I have the mapping applications distributed via Flathub and the experience has been very good so far. In some aspects its similar to what we have now - you rely on the runtime (Platform in flatpak lingo) and have to bundle all extra libs with it. Libs are described using via build scripts and archive/git (hash, commit id). In my case, its quite a few. As for overall experience - you get support with packaging through review of the corresponding pull request and the packages are build on their servers (kind of OBS as a frontend for the store). Worked quite well and got help there as well. Would be good to have flatpak support, but I am not sure what are the kernel requirements for it. Back to the original question, Alexander: thanks for sorting it out, I'll try tomorrow. I do wonder why the keyboard doesn't get activated, though. Any tips regarding it? Thanks for the feedback and discussion, Rinigus On Sun, Feb 10, 2019 at 11:16 PM Martin Kolman wrote: > Sun, 10 Feb 2019 23:05:28 +0200 E.s. Rosenberg > > : > > Flatpak would make our phones so much more insecure - instead of Jolla > updating bad/insecure libraries (which also happens at a pace that leaves > to be desired) you become dependent on the devs of the application you are > using doing that. > > I don't think this is correct. Unlike for example App image where > developers AFAIK *do* have to bundle everything, Flatpak has a concept of > shared application runtimes. As long an application uses sensitive > libraries (mainly crypto related) from the runtime, it's not really > different from the current system with shared system libraries - as long as > the runtime is being properly maintained. > > Also both main app distribution channels in Sailfish OS are taking binary > RPMs only and there is nothing really preventing developers from bundling > about anything already. > > > Since Jolla tries to have one of its' claims to fame be security it seems > that flatpak support should be just about the last thing they should > support. > > Looks like the Purism Librem 5 open hardware phone project aims to use > Flatpaks for third party application distribution: > > > https://www.phoronix.com/scan.php?page=news_item&px=Purism-PureOS-Store-Flatpaks > > > Just my 2c > > Op zo 10 feb. 2019 om 22:56 schreef Martin Kolman >: > >> Sun, 10 Feb 2019 09:56:06 +0200 Rinigus >> : >> >> Morning, >> >> suggestion to consider Qt 5.12 in /opt comes from the following: >> >> * newer web engine >> * we can use and contribute to the code written for Plasma with its >> Kirigami >> >> It will not bring native new applications, we don't have Silica for it. >> However, I personally think it makes more sense to use and help out with >> the development of Linux-based solutions than to use Android-provided web >> browsers through SFOS Android compatibility layer. >> >> This would not to be intended to be installed in /usr and having platform >> supporting multiple Qt versions at once. I have no idea whether its >> possible and no desire to get into messing up the system layer. >> >> Dmitriy: I don't know whether you can mix different Qt versions in the >> same application. In this respect, yes, you could probably ship Qt 512 >> stack fully, but would probably have to stay away from the system-provided >> Qt. >> >> Leszek: fragmentation is to be considered, indeed. But, as far as I >> understood, it makes sense to develop browser against the last version of >> Qt. In some aspect, using Qt59 on SFOS contributes to fragmentation in a >> way that we, on SFOS, will be using the version that is slowly phased out >> already. At present, Kirigami is developed using Qt512, with Qt511 version >> having at least one bug that will never be fixed. Not sure whether Kirigami >> runs against Qt59. So, if we would like to run Kirigami apps, Qt 5.12 is >> most probably needed. >> >> I hope eventually support for using Flatpak for package distribution is >> added to Sailfish OS, as that would make it possible to decouple the >> "system" Qt version from the "application" Qt version. Updating the system >> version would not longer risk breakage in third party applications and >> could be done on it's own, likely slower, pace. On the other hand updating >> the "application" Qt would mean just releasing a new Flatpak runtime with >> the updated Qt version. Old application would continue working with old >> runtime/-s while new apps would be able to use all the new goodies >> available via the new runtime. IIRC this is already being done for Qt on >>
[SailfishDevel] Boolean dependencies in RPM SPEC
Hi, with SFOS 3.0.3.x, we have new ICU version which is packaged into libicu and libicu-devel. As a result, name of the package is different from the earlier one (had icu52 in the names) and RPM SPEC files need to change the dependency accordingly. I tried to use `or` in the SPEC without any success, as in BuildRequires: (libicu52-devel or libicu-devel) as in https://github.com/rinigus/pkg-mapnik/blob/da5b6a11667b286c89bbee93eb57e2d4d52d5902/rpm/mapnik.spec#L16 It seems to me that I followed syntax on https://rpm.org/user_doc/boolean_dependencies.html . Unfortunately, it didn't work out since it seemed to result in adding dependency on 3 packages: libicu52-devel, or, and libicu-devel Hence the question - how can I add support for 3.0.2.x and 3.0.3.x using the same SPEC file? On device, RPM has version 4.14, if its of any importance. Cheers, Rinigus PS: asked the same yesterday on IRC, expanding to mailing list ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Boolean dependencies in RPM SPEC
Hi, the problem is while building at OBS: https://build.merproject.org/package/show/home:rinigus:maps/mapnik Rinigus On Sat, May 11, 2019 at 4:30 PM David Llewellyn-Jones wrote: > On 11/05/2019 16:12, rinigus wrote: > [snip] > > BuildRequires: (libicu52-devel or libicu-devel) > > > > as in > > > https://github.com/rinigus/pkg-mapnik/blob/da5b6a11667b286c89bbee93eb57e2d4d52d5902/rpm/mapnik.spec#L16 > > [snip] > > Hence the question - how can I add support for 3.0.2.x and 3.0.3.x using > > the same SPEC file? On device, RPM has version 4.14, if its of any > > importance. > > For 'BuildRequires', it's presumably the versioning in your SDK tooling > which is important, rather than the RPM version on your device. It may > be worth checking that too. > > Or is the problem you're experiencing happening at install time (i.e. in > relation to the 'Requires' on line 36 of that file)? I can't see any > difference between your version and the examples in the spec you posted. > > David > -- > Website: http://www.flypig.co.uk > ___ > 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
Re: [SailfishDevel] Boolean dependencies in RPM SPEC
Summary from IRC chat on the topic: David spotted that BuildRequires is not mentioned in the list of boolean dependencies (thank you!). So, next question: which condition could I use in %if expansion of SPEC to distinguish SFOS 3.0.3.x from the earlier versions? Maybe there is some variable defined at OBS build env that can be used? Rinigus On Sat, May 11, 2019 at 4:38 PM rinigus wrote: > Hi, > > the problem is while building at OBS: > https://build.merproject.org/package/show/home:rinigus:maps/mapnik > > Rinigus > > On Sat, May 11, 2019 at 4:30 PM David Llewellyn-Jones > wrote: > >> On 11/05/2019 16:12, rinigus wrote: >> [snip] >> > BuildRequires: (libicu52-devel or libicu-devel) >> > >> > as in >> > >> https://github.com/rinigus/pkg-mapnik/blob/da5b6a11667b286c89bbee93eb57e2d4d52d5902/rpm/mapnik.spec#L16 >> >> [snip] >> > Hence the question - how can I add support for 3.0.2.x and 3.0.3.x using >> > the same SPEC file? On device, RPM has version 4.14, if its of any >> > importance. >> >> For 'BuildRequires', it's presumably the versioning in your SDK tooling >> which is important, rather than the RPM version on your device. It may >> be worth checking that too. >> >> Or is the problem you're experiencing happening at install time (i.e. in >> relation to the 'Requires' on line 36 of that file)? I can't see any >> difference between your version and the examples in the spec you posted. >> >> David >> -- >> Website: http://www.flypig.co.uk >> ___ >> 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
Re: [SailfishDevel] Boolean dependencies in RPM SPEC
Martin,
thanks for pointing in this direction. I added %dump in SPEC and the only
reasonable macro that I could see was _repository. So, I added the
following to differentiate the dependencies:
%if %{_repository} == "sailfish_3.0.2.8_armv7hl"
BuildRequires: libicu52-devel
%else
BuildRequires: libicu-devel
%endif
Not the prettiest of the solutions, but seem to work.
Rinigus
On Sun, May 12, 2019 at 3:53 PM Martin Kolman
wrote:
> Sat, 11 May 2019 17:53:27 +0300 Rinigus
> :
>
> Summary from IRC chat on the topic: David spotted that BuildRequires is
> not mentioned in the list of boolean dependencies (thank you!).
>
> So, next question: which condition could I use in %if expansion of SPEC to
> distinguish SFOS 3.0.3.x from the earlier versions? Maybe there is some
> variable defined at OBS build env that can be used?
>
> I know that Fedora/RHEL/CentOS/OpenSUSE and RPM based distros in general
> usually have some RPM macro[0] defined that can be used to check on which
> "target" the package is being built and then behave accordingly. That way
> people can use the same spec file across multiple Fedora and even RHEL
> releases. I would assume Sailfish OS might have something similar and if
> not it definitely should be added.
>
> But if no such mechanism is available at the moment, there might still be
> a way to share a common spec file the way modRana does it. I didn't want to
> maintain three spec files for modRana (one for Open Repos, one for Harbour,
> one for Fedora) so I've added conditions to the single shared spec file
> based on custom RPM variables. The variables are then set at build time
> based on custom config for the given Mer OBS project.
>
> The condition can be seen for example here:
>
> https://github.com/M4rtinK/modrana/blob/master/packaging/modrana.spec#L33
>
>
> The custom repo configs can be seen here:
>
> https://build.merproject.org/project/prjconf/home:MartinK:sailfish:modrana
>
>
> https://build.merproject.org/project/prjconf/home:MartinK:sailfish:modrana-harbour
>
>
> Note that the modRana project has just %with_sailfish set while
> modrana-harbour has also %with_harbour set.
>
> I think you could use something similar, eq. %with_old_icu or %sfos_303 on
> two separate OBS projects sharing the same spec file
>
> with the respective conditions set.
>
>
> Best Wishes
>
> Martin Kolman
>
>
> [0] https://docs.fedoraproject.org/en-US/packaging-guidelines/DistTag/
>
>
> Rinigus
>
>
>
> On Sat, May 11, 2019 at 4:38 PM rinigus wrote:
>
>> Hi,
>>
>> the problem is while building at OBS:
>> https://build.merproject.org/package/show/home:rinigus:maps/mapnik
>>
>> Rinigus
>>
>> On Sat, May 11, 2019 at 4:30 PM David Llewellyn-Jones
>> wrote:
>>
>>> On 11/05/2019 16:12, rinigus wrote:
>>> [snip]
>>> > BuildRequires: (libicu52-devel or libicu-devel)
>>> >
>>> > as in
>>> >
>>> https://github.com/rinigus/pkg-mapnik/blob/da5b6a11667b286c89bbee93eb57e2d4d52d5902/rpm/mapnik.spec#L16
>>>
>>> [snip]
>>> > Hence the question - how can I add support for 3.0.2.x and 3.0.3.x
>>> using
>>> > the same SPEC file? On device, RPM has version 4.14, if its of any
>>> > importance.
>>>
>>> For 'BuildRequires', it's presumably the versioning in your SDK tooling
>>> which is important, rather than the RPM version on your device. It may
>>> be worth checking that too.
>>>
>>> Or is the problem you're experiencing happening at install time (i.e. in
>>> relation to the 'Requires' on line 36 of that file)? I can't see any
>>> difference between your version and the examples in the spec you posted.
>>>
>>> David
>>> --
>>> Website: http://www.flypig.co.uk
>>> ___
>>> 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
Re: [SailfishDevel] Boolean dependencies in RPM SPEC
PS: And it failed on 3.0.2 - back to the drawing board...
On Sun, May 12, 2019 at 8:47 PM rinigus wrote:
> Martin,
>
> thanks for pointing in this direction. I added %dump in SPEC and the only
> reasonable macro that I could see was _repository. So, I added the
> following to differentiate the dependencies:
>
> %if %{_repository} == "sailfish_3.0.2.8_armv7hl"
> BuildRequires: libicu52-devel
> %else
> BuildRequires: libicu-devel
> %endif
>
> Not the prettiest of the solutions, but seem to work.
>
> Rinigus
>
> On Sun, May 12, 2019 at 3:53 PM Martin Kolman
> wrote:
>
>> Sat, 11 May 2019 17:53:27 +0300 Rinigus
>> :
>>
>> Summary from IRC chat on the topic: David spotted that BuildRequires is
>> not mentioned in the list of boolean dependencies (thank you!).
>>
>> So, next question: which condition could I use in %if expansion of SPEC
>> to distinguish SFOS 3.0.3.x from the earlier versions? Maybe there is some
>> variable defined at OBS build env that can be used?
>>
>> I know that Fedora/RHEL/CentOS/OpenSUSE and RPM based distros in general
>> usually have some RPM macro[0] defined that can be used to check on which
>> "target" the package is being built and then behave accordingly. That way
>> people can use the same spec file across multiple Fedora and even RHEL
>> releases. I would assume Sailfish OS might have something similar and if
>> not it definitely should be added.
>>
>> But if no such mechanism is available at the moment, there might still be
>> a way to share a common spec file the way modRana does it. I didn't want to
>> maintain three spec files for modRana (one for Open Repos, one for Harbour,
>> one for Fedora) so I've added conditions to the single shared spec file
>> based on custom RPM variables. The variables are then set at build time
>> based on custom config for the given Mer OBS project.
>>
>> The condition can be seen for example here:
>>
>> https://github.com/M4rtinK/modrana/blob/master/packaging/modrana.spec#L33
>>
>>
>> The custom repo configs can be seen here:
>>
>> https://build.merproject.org/project/prjconf/home:MartinK:sailfish:modrana
>>
>>
>> https://build.merproject.org/project/prjconf/home:MartinK:sailfish:modrana-harbour
>>
>>
>> Note that the modRana project has just %with_sailfish set while
>> modrana-harbour has also %with_harbour set.
>>
>> I think you could use something similar, eq. %with_old_icu or %sfos_303
>> on two separate OBS projects sharing the same spec file
>>
>> with the respective conditions set.
>>
>>
>> Best Wishes
>>
>> Martin Kolman
>>
>>
>> [0] https://docs.fedoraproject.org/en-US/packaging-guidelines/DistTag/
>>
>>
>> Rinigus
>>
>>
>>
>> On Sat, May 11, 2019 at 4:38 PM rinigus wrote:
>>
>>> Hi,
>>>
>>> the problem is while building at OBS:
>>> https://build.merproject.org/package/show/home:rinigus:maps/mapnik
>>>
>>> Rinigus
>>>
>>> On Sat, May 11, 2019 at 4:30 PM David Llewellyn-Jones <
>>> da...@flypig.co.uk> wrote:
>>>
>>>> On 11/05/2019 16:12, rinigus wrote:
>>>> [snip]
>>>> > BuildRequires: (libicu52-devel or libicu-devel)
>>>> >
>>>> > as in
>>>> >
>>>> https://github.com/rinigus/pkg-mapnik/blob/da5b6a11667b286c89bbee93eb57e2d4d52d5902/rpm/mapnik.spec#L16
>>>>
>>>> [snip]
>>>> > Hence the question - how can I add support for 3.0.2.x and 3.0.3.x
>>>> using
>>>> > the same SPEC file? On device, RPM has version 4.14, if its of any
>>>> > importance.
>>>>
>>>> For 'BuildRequires', it's presumably the versioning in your SDK tooling
>>>> which is important, rather than the RPM version on your device. It may
>>>> be worth checking that too.
>>>>
>>>> Or is the problem you're experiencing happening at install time (i.e. in
>>>> relation to the 'Requires' on line 36 of that file)? I can't see any
>>>> difference between your version and the examples in the spec you posted.
>>>>
>>>> David
>>>> --
>>>> Website: http://www.flypig.co.uk
>>>> ___
>>>> 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
Re: [SailfishDevel] Boolean dependencies in RPM SPEC
All worked as soon as %{_repository} is as in
%if "%{_repository}" == "sailfish_3.0.2.8_armv7hl"
BuildRequires: libicu52-devel
%else
BuildRequires: libicu-devel
%endif
Rinigus
On Sun, May 12, 2019 at 8:56 PM rinigus wrote:
> PS: And it failed on 3.0.2 - back to the drawing board...
>
> On Sun, May 12, 2019 at 8:47 PM rinigus wrote:
>
>> Martin,
>>
>> thanks for pointing in this direction. I added %dump in SPEC and the only
>> reasonable macro that I could see was _repository. So, I added the
>> following to differentiate the dependencies:
>>
>> %if %{_repository} == "sailfish_3.0.2.8_armv7hl"
>> BuildRequires: libicu52-devel
>> %else
>> BuildRequires: libicu-devel
>> %endif
>>
>> Not the prettiest of the solutions, but seem to work.
>>
>> Rinigus
>>
>> On Sun, May 12, 2019 at 3:53 PM Martin Kolman
>> wrote:
>>
>>> Sat, 11 May 2019 17:53:27 +0300 Rinigus
>>> :
>>>
>>> Summary from IRC chat on the topic: David spotted that BuildRequires is
>>> not mentioned in the list of boolean dependencies (thank you!).
>>>
>>> So, next question: which condition could I use in %if expansion of SPEC
>>> to distinguish SFOS 3.0.3.x from the earlier versions? Maybe there is some
>>> variable defined at OBS build env that can be used?
>>>
>>> I know that Fedora/RHEL/CentOS/OpenSUSE and RPM based distros in general
>>> usually have some RPM macro[0] defined that can be used to check on which
>>> "target" the package is being built and then behave accordingly. That way
>>> people can use the same spec file across multiple Fedora and even RHEL
>>> releases. I would assume Sailfish OS might have something similar and if
>>> not it definitely should be added.
>>>
>>> But if no such mechanism is available at the moment, there might still
>>> be a way to share a common spec file the way modRana does it. I didn't want
>>> to maintain three spec files for modRana (one for Open Repos, one for
>>> Harbour, one for Fedora) so I've added conditions to the single shared spec
>>> file based on custom RPM variables. The variables are then set at build
>>> time based on custom config for the given Mer OBS project.
>>>
>>> The condition can be seen for example here:
>>>
>>> https://github.com/M4rtinK/modrana/blob/master/packaging/modrana.spec#L33
>>>
>>>
>>> The custom repo configs can be seen here:
>>>
>>>
>>> https://build.merproject.org/project/prjconf/home:MartinK:sailfish:modrana
>>>
>>>
>>> https://build.merproject.org/project/prjconf/home:MartinK:sailfish:modrana-harbour
>>>
>>>
>>> Note that the modRana project has just %with_sailfish set while
>>> modrana-harbour has also %with_harbour set.
>>>
>>> I think you could use something similar, eq. %with_old_icu or %sfos_303
>>> on two separate OBS projects sharing the same spec file
>>>
>>> with the respective conditions set.
>>>
>>>
>>> Best Wishes
>>>
>>> Martin Kolman
>>>
>>>
>>> [0] https://docs.fedoraproject.org/en-US/packaging-guidelines/DistTag/
>>>
>>>
>>> Rinigus
>>>
>>>
>>>
>>> On Sat, May 11, 2019 at 4:38 PM rinigus wrote:
>>>
>>>> Hi,
>>>>
>>>> the problem is while building at OBS:
>>>> https://build.merproject.org/package/show/home:rinigus:maps/mapnik
>>>>
>>>> Rinigus
>>>>
>>>> On Sat, May 11, 2019 at 4:30 PM David Llewellyn-Jones <
>>>> da...@flypig.co.uk> wrote:
>>>>
>>>>> On 11/05/2019 16:12, rinigus wrote:
>>>>> [snip]
>>>>> > BuildRequires: (libicu52-devel or libicu-devel)
>>>>> >
>>>>> > as in
>>>>> >
>>>>> https://github.com/rinigus/pkg-mapnik/blob/da5b6a11667b286c89bbee93eb57e2d4d52d5902/rpm/mapnik.spec#L16
>>>>>
>>>>> [snip]
>>>>> > Hence the question - how can I add support for 3.0.2.x and 3.0.3.x
>>>>> using
>>>>> > the same SPEC file? On device, RPM has version 4.14, if its of any
>>>>> > importance.
>>>>>
>>>>> For 'BuildRequires', it's presumably the versioning in your SDK tooling
>>>>> which is important, rather than the RPM version on your device. It may
>>>>> be worth checking that too.
>>>>>
>>>>> Or is the problem you're experiencing happening at install time (i.e.
>>>>> in
>>>>> relation to the 'Requires' on line 36 of that file)? I can't see any
>>>>> difference between your version and the examples in the spec you
>>>>> posted.
>>>>>
>>>>> David
>>>>> --
>>>>> Website: http://www.flypig.co.uk
>>>>> ___
>>>>> 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
Re: [SailfishDevel] Boolean dependencies in RPM SPEC
Dear Pekka,
thank you very much - its way better to use it through pkgconfig. Didn't
find this option a while ago when I was writing original SPEC files and
didn't look for it either.
Cheers,
Rinigus
On Mon, May 13, 2019 at 10:24 AM Pekka Vuorela
wrote:
> On Sun, 2019-05-12 at 20:47 +0300, rinigus wrote:
> > Martin,
> >
> > thanks for pointing in this direction. I added %dump in SPEC and the
> > only reasonable macro that I could see was _repository. So, I added
> > the following to differentiate the dependencies:
> >
> > %if %{_repository} == "sailfish_3.0.2.8_armv7hl"
> > BuildRequires: libicu52-devel
> > %else
> > BuildRequires: libicu-devel
> > %endif
> >
> > Not the prettiest of the solutions, but seem to work.
>
> Suppose you might want to also try just:
>
> BuildRequires: pkgconfig(icu-uc)
>
>
> ___
> 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
Re: [SailfishDevel] SDK versioning
Slava, In theory, and for most SFOS updates, you are right. But there are cases when you have to target specific versions due to incompatibilities between them. Latest update (EA right now) enforces icon button coloring by default and you can opt out only if you specify option which would be incompatible with earlier Sfos versions (issue filed at TJC). Before last, we've got changes in ICU that resulted in separate builds for current and older Sfos versions (not sure its SFOS to blame here, though). So, targeting older versions of Sfos will not work if you hit these cases. Cheers, Rinigus On Friday, 26 July 2019, Slava Monich wrote: > Even though it's not directly related to the original question but IMO > there's isn't much sense in building Harbour apps against the latest > available SDK. That would almost certainly make your app incompatible > with older releases of SFOS. I build my Harbour (and OpenRepos) apps > against the oldest SDK that I could find in Mer OBS (1.something!), and > I'm quite happy about it because they work on more or less all devices > where they could possibly work. > > I wouldn't assume that all users have upgraded their devices to the > latest release of SFOS, and as the author I'm interested in my apps > being compatible with as many releases of the OS as reasonably possible. > An alternative would be to maintain different versions of the app for > different versions of the OS which would make even less sense. > > Cheers, > > -Slava > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.or ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] QML IconButton in SFOS 3.1
Hi, due to the changes in handling of icon coloring of IconButton in SFOS 3.1, I am getting a steady stream of EA users complaining about the absence of icons in Pure Maps - as in http://talk.maemo.org/showpost.php?p=1558483&postcount=773 . The issue has been described well in https://together.jolla.com/question/209315/bug-31011-qml-iconbutton-problems/ without any response from Jolla devs. Let's see if we can get this response over here. In Pure Maps, icons are expected to be drawn according to the styling given by map, not by ambience. I was told that I can set icon.color: undefined as a property. However, when doing it for SFOS versions <3.1, this leads to lots of warning messages on stdout. What's an official way that I am expected to use when I want to support earlier SFOS versions as well? Cheers, Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] QML IconButton in SFOS 3.1
Slava,
unfortunately, it doesn't work. IconButton property icon has color
subpropery defined in earlier SFOS versions as well. So,
IconButton {
id: image
[...]
Component.onCompleted: {
if ("color" in image.icon)
image.icon.color = undefined;
}
}
results in lots of warnings (Cannot assigned [undefined] to QColor).
Maybe there is some var I can check in QML to state that SFOS version is >=
3.1.0.0?
Rinigus
On Sat, Aug 3, 2019 at 5:33 PM Slava Monich wrote:
> I don't think there's an "official" way of maintaining backward
> compatibility but I'd humbly suggest something like if ("color" in icon) ...
>
> e.g. I do this kind of thing to notifications:
>
> Notification {
> id: clipboardNotification
> previewBody: "Copied to clipboard"
> Component.onCompleted: {
> if ("icon" in clipboardNotification) {
> clipboardNotification.icon = "icon-s-clipboard"
> }
> }
> }
>
> Cheers,
>
> -Slava
>
> Hi,
>
> due to the changes in handling of icon coloring of IconButton in SFOS 3.1,
> I am getting a steady stream of EA users complaining about the absence of
> icons in Pure Maps - as in
> http://talk.maemo.org/showpost.php?p=1558483&postcount=773 . The issue
> has been described well in
> https://together.jolla.com/question/209315/bug-31011-qml-iconbutton-problems/
> without any response from Jolla devs. Let's see if we can get this response
> over here.
>
> In Pure Maps, icons are expected to be drawn according to the styling
> given by map, not by ambience. I was told that I can set icon.color:
> undefined as a property. However, when doing it for SFOS versions <3.1,
> this leads to lots of warning messages on stdout. What's an official way
> that I am expected to use when I want to support earlier SFOS versions as
> well?
>
> Cheers,
>
> Rinigus
>
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] QML IconButton in SFOS 3.1
Hi,
any ideas on how to fix this IconButton issue? Is there a way to query SFOS
version and make an ugly fix on the basis of that...
Cheers,
Rinigus
On Sat, Aug 3, 2019 at 6:06 PM rinigus wrote:
> Slava,
>
> unfortunately, it doesn't work. IconButton property icon has color
> subpropery defined in earlier SFOS versions as well. So,
>
> IconButton {
>
> id: image
>
> [...]
>
> Component.onCompleted: {
>
> if ("color" in image.icon)
>
> image.icon.color = undefined;
>
> }
>
> }
>
>
> results in lots of warnings (Cannot assigned [undefined] to QColor).
>
> Maybe there is some var I can check in QML to state that SFOS version is
> >= 3.1.0.0?
>
> Rinigus
>
> On Sat, Aug 3, 2019 at 5:33 PM Slava Monich
> wrote:
>
>> I don't think there's an "official" way of maintaining backward
>> compatibility but I'd humbly suggest something like if ("color" in icon) ...
>>
>> e.g. I do this kind of thing to notifications:
>>
>> Notification {
>> id: clipboardNotification
>> previewBody: "Copied to clipboard"
>> Component.onCompleted: {
>> if ("icon" in clipboardNotification) {
>> clipboardNotification.icon = "icon-s-clipboard"
>> }
>> }
>> }
>>
>> Cheers,
>>
>> -Slava
>>
>> Hi,
>>
>> due to the changes in handling of icon coloring of IconButton in SFOS
>> 3.1, I am getting a steady stream of EA users complaining about the absence
>> of icons in Pure Maps - as in
>> http://talk.maemo.org/showpost.php?p=1558483&postcount=773 . The issue
>> has been described well in
>> https://together.jolla.com/question/209315/bug-31011-qml-iconbutton-problems/
>> without any response from Jolla devs. Let's see if we can get this response
>> over here.
>>
>> In Pure Maps, icons are expected to be drawn according to the styling
>> given by map, not by ambience. I was told that I can set icon.color:
>> undefined as a property. However, when doing it for SFOS versions <3.1,
>> this leads to lots of warning messages on stdout. What's an official way
>> that I am expected to use when I want to support earlier SFOS versions as
>> well?
>>
>> Cheers,
>>
>> Rinigus
>>
>>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] QML IconButton in SFOS 3.1
Hi,
it would be good to get some kind of official position on QML IconButton
issue. Is it considered for fixing or it will stay as it is? Slava's
suggestion didn't work since color member is available on older versions of
SFOS as well.
Rinigus
On Wed, Aug 7, 2019 at 2:29 PM rinigus wrote:
> Hi,
>
> any ideas on how to fix this IconButton issue? Is there a way to query
> SFOS version and make an ugly fix on the basis of that...
>
> Cheers,
>
> Rinigus
>
> On Sat, Aug 3, 2019 at 6:06 PM rinigus wrote:
>
>> Slava,
>>
>> unfortunately, it doesn't work. IconButton property icon has color
>> subpropery defined in earlier SFOS versions as well. So,
>>
>> IconButton {
>>
>> id: image
>>
>> [...]
>>
>> Component.onCompleted: {
>>
>> if ("color" in image.icon)
>>
>> image.icon.color = undefined;
>>
>> }
>>
>> }
>>
>>
>> results in lots of warnings (Cannot assigned [undefined] to QColor).
>>
>> Maybe there is some var I can check in QML to state that SFOS version is
>> >= 3.1.0.0?
>>
>> Rinigus
>>
>> On Sat, Aug 3, 2019 at 5:33 PM Slava Monich
>> wrote:
>>
>>> I don't think there's an "official" way of maintaining backward
>>> compatibility but I'd humbly suggest something like if ("color" in icon) ...
>>>
>>> e.g. I do this kind of thing to notifications:
>>>
>>> Notification {
>>> id: clipboardNotification
>>> previewBody: "Copied to clipboard"
>>> Component.onCompleted: {
>>> if ("icon" in clipboardNotification) {
>>> clipboardNotification.icon = "icon-s-clipboard"
>>> }
>>> }
>>> }
>>>
>>> Cheers,
>>>
>>> -Slava
>>>
>>> Hi,
>>>
>>> due to the changes in handling of icon coloring of IconButton in SFOS
>>> 3.1, I am getting a steady stream of EA users complaining about the absence
>>> of icons in Pure Maps - as in
>>> http://talk.maemo.org/showpost.php?p=1558483&postcount=773 . The issue
>>> has been described well in
>>> https://together.jolla.com/question/209315/bug-31011-qml-iconbutton-problems/
>>> without any response from Jolla devs. Let's see if we can get this response
>>> over here.
>>>
>>> In Pure Maps, icons are expected to be drawn according to the styling
>>> given by map, not by ambience. I was told that I can set icon.color:
>>> undefined as a property. However, when doing it for SFOS versions <3.1,
>>> this leads to lots of warning messages on stdout. What's an official way
>>> that I am expected to use when I want to support earlier SFOS versions as
>>> well?
>>>
>>> Cheers,
>>>
>>> Rinigus
>>>
>>>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] QML IconButton in SFOS 3.1
Hi Slava,
my code, corresponding snippet:
IconButton {
id: image
anchors.centerIn: parent
down: pressed || parent.pressed
icon.opacity: iconOpacity
icon.source: iconName || iconSource
icon.sourceSize.height: iconHeight
icon.sourceSize.width: iconWidth
onClicked: item.clicked()
Component.onCompleted: {
if ("color" in icon) {
icon.color = undefined
}
}
}
On SFOS 3.0.3.9 (ported to OnePlus X), I get errors for a line with
icon.color = undefined :
file:///... Error: Cannot assign [undefined] to QColor
So, it seems that this property was introduced before 3.1.x, but not used
in 3.0.3.
Rinigus
On Wed, Aug 14, 2019 at 1:07 PM Slava Monich wrote:
> Hi Rinigus,
>
> AFAICT icon.color appeared in 3.1 and it wasn't there before.
>
> This piece of QML seems to work for me without any warnings on both
> 2.0.1.7 (no icon.color) and 3.1.1.xxx (latest devel, has icon.color):
>
> IconButton {
> icon.source: "image://theme/icon-m-refresh"
> Component.onCompleted: {
> if ("color" in icon) {
> icon.color = undefined
> }
> }
> }
>
> I'm not sure if it does what you want it to do, but it doesn't produce any
> warnings!
>
> And no, I'm not in a position to formulate the official position :)
>
> Cheers,
>
> -Slava
>
> Hi,
>
> it would be good to get some kind of official position on QML IconButton
> issue. Is it considered for fixing or it will stay as it is? Slava's
> suggestion didn't work since color member is available on older versions of
> SFOS as well.
>
> Rinigus
>
> On Wed, Aug 7, 2019 at 2:29 PM rinigus wrote:
>
>> Hi,
>>
>> any ideas on how to fix this IconButton issue? Is there a way to query
>> SFOS version and make an ugly fix on the basis of that...
>>
>> Cheers,
>>
>> Rinigus
>>
>> On Sat, Aug 3, 2019 at 6:06 PM rinigus wrote:
>>
>>> Slava,
>>>
>>> unfortunately, it doesn't work. IconButton property icon has color
>>> subpropery defined in earlier SFOS versions as well. So,
>>>
>>> IconButton {
>>>
>>> id: image
>>>
>>> [...]
>>>
>>> Component.onCompleted: {
>>>
>>> if ("color" in image.icon)
>>>
>>> image.icon.color = undefined;
>>>
>>> }
>>>
>>> }
>>>
>>> results in lots of warnings (Cannot assigned [undefined] to QColor).
>>>
>>> Maybe there is some var I can check in QML to state that SFOS version is
>>> >= 3.1.0.0?
>>>
>>> Rinigus
>>>
>>> On Sat, Aug 3, 2019 at 5:33 PM Slava Monich
>>> wrote:
>>>
>>>> I don't think there's an "official" way of maintaining backward
>>>> compatibility but I'd humbly suggest something like if ("color" in icon)
>>>> ...
>>>>
>>>> e.g. I do this kind of thing to notifications:
>>>>
>>>> Notification {
>>>> id: clipboardNotification
>>>> previewBody: "Copied to clipboard"
>>>> Component.onCompleted: {
>>>> if ("icon" in clipboardNotification) {
>>>> clipboardNotification.icon = "icon-s-clipboard"
>>>> }
>>>> }
>>>> }
>>>>
>>>> Cheers,
>>>>
>>>> -Slava
>>>>
>>>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] QML IconButton in SFOS 3.1
Thank you for suggestion! On my install, I get black icons ok, but the white on
black background get to black on black. Whether its 0s or Fs.
Rinigus
On Wednesday, 14 August 2019, Slava Monich wrote:
> Apparently properties of type color don't want to be undefined (now I
> don't understand why I'm not getting the warning) - have you tried
> something like "#" instead of undefined?
>
> -S.
>
> > Hi Slava,
> >
> > my code, corresponding snippet:
> >
> > IconButton {
> > id: image
> > anchors.centerIn: parent
> > down: pressed || parent.pressed
> > icon.opacity: iconOpacity
> > icon.source: iconName || iconSource
> > icon.sourceSize.height: iconHeight
> > icon.sourceSize.width: iconWidth
> > onClicked: item.clicked()
> >
> > Component.onCompleted: {
> > if ("color" in icon) {
> > icon.color = undefined
> > }
> > }
> > }
> >
> > On SFOS 3.0.3.9 (ported to OnePlus X), I get errors for a line with
> > icon.color = undefined :
> >
> > file:///... Error: Cannot assign [undefined] to QColor
> >
> > So, it seems that this property was introduced before 3.1.x, but not
> > used in 3.0.3.
> >
> > Rinigus
> >
> >
> >
> > On Wed, Aug 14, 2019 at 1:07 PM Slava Monich > <mailto:slava.mon...@jolla.com>> wrote:
> >
> > Hi Rinigus,
> >
> > AFAICT icon.color appeared in 3.1 and it wasn't there before.
> >
> > This piece of QML seems to work for me without any warnings on
> > both 2.0.1.7 (no icon.color) and 3.1.1.xxx (latest devel, has
> > icon.color):
> >
> > IconButton {
> > icon.source: "image://theme/icon-m-refresh"
> > Component.onCompleted: {
> > if ("color" in icon) {
> > icon.color = undefined
> > }
> > }
> > }
> >
> > I'm not sure if it does what you want it to do, but it doesn't
> > produce any warnings!
> >
> > And no, I'm not in a position to formulate the official position :)
> >
> > Cheers,
> >
> > -Slava
> >
> >
> >> Hi,
> >>
> >> it would be good to get some kind of official position on QML
> >> IconButton issue. Is it considered for fixing or it will stay as
> >> it is? Slava's suggestion didn't work since color member is
> >> available on older versions of SFOS as well.
> >>
> >> Rinigus
> >>
> >> On Wed, Aug 7, 2019 at 2:29 PM rinigus >> <mailto:rinigus@gmail.com>> wrote:
> >>
> >> Hi,
> >>
> >> any ideas on how to fix this IconButton issue? Is there a way
> >> to query SFOS version and make an ugly fix on the basis of
> >> that...
> >>
> >> Cheers,
> >>
> >> Rinigus
> >>
> >> On Sat, Aug 3, 2019 at 6:06 PM rinigus >> <mailto:rinigus@gmail.com>> wrote:
> >>
> >> Slava,
> >>
> >> unfortunately, it doesn't work. IconButton property icon
> >> has color subpropery defined in earlier SFOS versions as
> >> well. So,
> >>
> >> IconButton{
> >>
> >> id:image
> >>
> >> [...]
> >>
> >> Component.onCompleted:{
> >>
> >> if("color"inimage.icon)
> >>
> >> image.icon.color=undefined;
> >>
> >> }
> >>
> >> }
> >>
> >> results in lots of warnings (Cannot assigned [undefined]
> >> to QColor).
> >>
> >> Maybe there is some var I can check in QML to state that
> >> SFOS version is >= 3.1.0.0?
> >>
> >> Rinigus
> >>
> >> On Sat, Aug 3, 2019 at 5:33 PM Slava Monich
> >> mailto:slava.mon...@jolla.com>>
> >> wrote:
> >>
> >> I don't think there's an "official" way of
> >> maintaining backward compatibility but I'd humbly
> >> suggest something like if ("color" in icon) ...
> >>
> >> e.g. I do this kind of thing to notifications:
> >>
> >> Notification {
> >> id: clipboardNotification
> >> previewBody: "Copied to clipboard"
> >> Component.onCompleted: {
> >> if ("icon" in clipboardNotification) {
> >> clipboardNotification.icon =
> >> "icon-s-clipboard"
> >> }
> >> }
> >> }
> >>
> >> Cheers,
> >>
> >> -Slava
> >>
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] Flatpak for Sailfish
Hi,
I have been working on getting Flatpak on Sailfish device. It doesn't work
yet, but let me give a short overview of the status.
Why: Flatpak would allow us to get latest Qt base, 5.12 and 5.13 are
available already. There are other advantages, as collaboration between
Linux mobile communities via the same app format, for example. Although, we
do loose native feel until Silica can be packaged as a part of an app.
Current longer-term limitations: As Lipstick (?) supports wl-shell only,
Gdk apps as distributed in Flatpak don't support that older standard, they
refuse to start.
Status:
Packages are available at
https://build.merproject.org/project/show/home:rinigus:flatpak. By
installing `flatpak` you will pull the dependencies as well. For me it was
The following 11 NEW packages are going to be installed:
flatpak flatpak-session-helper gdk-pixbuf json-glib libappstream-glib
libcroco librsvg libseccomp ostree-libs
xdg-dbus-proxy xdg-desktop-portal
After installation, set /usr/libexec/flatpak-bwrap to setuid. Without it
we get issues with /proc mounting in flatpak (bwrap: Can't mount proc on
/newroot/proc: Device or resource busy).
To use, reboot the device. While running commands leading to download of an
app/platform/sdk, I am getting gpg-connect-agent error messages. Seems like
we can ignore them for now.
Just install and running fails, probably due to OpenGLES in Qt case. For
Gnome apps, I am getting error with "Wayland compositor does not provide
any supported shell interface", so those are out (for now, at least).
For Qt, I have added manually an extension (as in
https://blog.tingping.se/2018/08/26/flatpak-host-extensions.html and
https://gitlab.com/debian-pm/halium/flatpak-extension-libhybris). Right
now, I have
made /var/lib/flatpak/extension/org.freedesktop.Platform.GL.default/arm/1.4/lib
and added content similar to the one generated by
https://gitlab.com/debian-pm/halium/flatpak-extension-libhybris/blob/master/debian/flatpak-extension-libhybris.postinst.in
with few additions, such as linker/o.so. Applications are installed using
--user and run with several environment variables to help hybris out, as
shown in strace run below:
flatpak run --devel --command=strace
--env=LD_LIBRARY_PATH=/usr/lib/arm-linux-gnueabihf/GL/default/lib
--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.kde.falkon /app/bin/falkon
While I can get into Flatpak sandbox (using command sh), GUI has opened
only once on a qtdemo app, but without hybris extension. In case of Falkon,
strace ends on
fstatat64(AT_FDCWD, "/dev/__properties__", 0xffef3fa8, 0) = -1 ENOENT (No
such file or directory)
openat(AT_FDCWD, "/dev/__properties__",
O_RDONLY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x684} ---
which is missing in the flatpak sandbox, indeed. For few other apps, it
ended earlier on failing to find libhardware.so (curiously, found by falkon
sandbox).
That's pretty much it at this moment. All being tested on SFOS
3.2.1.20/AOSP9 based port. Did not work in emulator with what looked to be
missing kernel config options.
As far as I read, Plasma Mobile has hybris/flatpak working and I will try
to get in touch with them. Would be great to get help - maybe someone would
like to join and try to make it work together. At this moment I have spent
few nights to get it packaged and haven't poked it too much.
Cheers,
Rinigus
PS: Full range of portals (GUI for requesting file access and such) needs
to be written. But that can wait till it gets working first.
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
>From comparing logs of normal apps and the app in Flatpak sasndbox, looks
like sandboxed app does not find /usr/libexec/droid-hybris. Is there a way
to let it search under
>
/usr/lib/arm-linux-gnueabihf/GL/default/libexec/droid-hybris
instead? Any env variable to tune? Seems like HYBRIS_LD_LIBRARY_PATH is
ignored while AT_SECURE is zero.
Corresponding part of strace:
openat(AT_FDCWD,
"/usr/lib/arm-linux-gnueabihf/GL/default/lib/libhybris/linker/o.so",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3,
"\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0|\370\0\0004\0\0\0"..., 512)
= 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=221216, ...}) = 0
mmap2(NULL, 306916, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xe2f9f000
mprotect(0xe2fd4000, 61440, PROT_NONE) = 0
mmap2(0xe2fe3000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x34000) = 0xe2fe3000
mmap2(0xe2fe5000, 20196, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xe2fe5000
close(3)= 0
mprotect(0xe2fe3000, 4096, PROT_READ) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) =
0xeae5e000
prctl(PR_SET_VMA, 0, 0xeae5e000, 0x1000, 0xe2fcd60c) = 0
lstat64("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/usr/libexec", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/usr/libexec/droid-hybris", 0xfff54d18) = -1 ENOENT (No such file
or directory)
lstat64("/vendor", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/vendor/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
Cheers,
Rinigus
PS:
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
I have a breakthrough. Had to compile libhybris with --with-default-hybris-ld-library-path=/usr/lib/arm-linux-gnueabihf/GL/default/libexec/droid-hybris/system/lib:/vendor/lib:/system/lib:/odm/lib and enable "--filesystem=host --device=all" in "flatpak run". As a result, I have some Qt flatpak apps running. While Falkon does crash on init, qutebrowser started. Few issues: Keyboard: Enabling Qt Virtual Keyboard with QT_IM_MODULE=qtvirtualkeyboard makes it crash though, with a message 19:48:20 WARNING: requestActivate() called for QtVirtualKeyboard::InputView(0xe9150998) which has Qt::WindowDoesNotAcceptFocus set. and flashing virtual keyboard on screen for a moment. I guess, we will have to use QML InputPanel to make it work for now. Minimizing: When you minimize an application, you get the application minimized into small live icon and you get a message in terminal 20:25:39 WARNING: Minimizing is not supported on wl-shell. Consider using xdg-shell instead. 20:25:39 WARNING: Wayland does not support QWindow::requestActivate() You can restore application immediately from small representation of it. However, if you had lockscreen or some other app over it, the icon disappears and its impossible to get the window back. At the same time, the application keeps running. qxcompositor does help, as apps are not minimized when staying on Wayland screen over there. So, to summarize: 1. Flatpak applications can run on SFOS. 2. We need to move away from wl-shell and get to the non-deprecated composer option (fixing minimizing and restoring applications). That will enable Gdk apps as well. 3. Ideally, libhybris should allow to specify hybris-ld-library-path during runtime. Otherwise, we have to compile separate versions of hybris - one for device and one for flatpaks. On device, two copies are needed anyway (probably hardlinking will work as well). 4. Keyboard will need some work. I presume that by moving to supported composer we could get around it with qt virtual keyboard. There is a workaround for our apps, if needed. For native look, if possible, someone will have to comment. Looks like #2 is a breaker right now and I don't know if it is possible to fix anytime soon. Cheers, Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
That was exactly the thought behind it. There will be work to do, such as writing portals, but we need to get compositor issue fixed first. Or use some separate one... Rinigus On Fri, Dec 27, 2019 at 9:17 PM wrote: > This is amazing, if there is something I can do to help please let me > know, not being tied to os version of qt is awesome, we could maybe get a > proper browser with this? Hope leszek is on the list > > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Yes, pretty much GUI allowing access to files and other sandboxed functions. See https://github.com/flatpak/flatpak/wiki/Portals Rinigus On Fri, Dec 27, 2019 at 9:43 PM wrote: > 'writing portals' would mean? Like qml files to handle i/o? > > > On Friday, 27 December 2019, rinigus wrote: > > That was exactly the thought behind it. There will be work to do, such as > > writing portals, but we need to get compositor issue fixed first. Or use > > some separate one... > > > > Rinigus > > > > On Fri, Dec 27, 2019 at 9:17 PM wrote: > > > > > This is amazing, if there is something I can do to help please let me > > > know, not being tied to os version of qt is awesome, we could maybe > get a > > > proper browser with this? Hope leszek is on the list > > > > > > > > > > -- > 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
Re: [SailfishDevel] Flatpak for Sailfish
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.00, 0.00) [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 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
Re: [SailfishDevel] Flatpak for Sailfish
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 : > >> 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.00, 0.00) >> [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 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
