Re: [SailfishDevel] QtLocation | Qt 5.6

[rinigus]

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
>> 
>> 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
>> 
>> > 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 

Re: [SailfishDevel] OBS questions

[rinigus]

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] OBS questions

[Tone Kastlunger]

Out of curiosity, are you running mapnik server on SFOS? :P

On Sat, Jul 29, 2017 at 6:58 PM, rinigus  wrote:

> 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.
>>
>> 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
>> >