Notices

Yes, mapnik requires updated compilers. If I push it to non-free, then people without thumb will not be able to install it and the package manager will complain about the missing dependency. I don't really like the solution, it introduces mess, but we don't have extras-thumb and I don't like the other solutions. [1] Alternatively we can combine 2&3 - gcc 4.6 version in extras-devel and thumb version in my repo

[1] http://talk.maemo.org/showpost.php?p...postcount=1531

Btw. great!

I prefer depends gcc >= 4.6

I became fully convinced to gcc >= 4.6 in the repos and thumb in my repo. Pushing thumb to extras isn't elegant, is it?

Depending if you want to add functionality location2sms being OSS could have those parts snipped out and added to modRana if you would like. They have not built it for fremantle but it would be very cool to be able to send and receive easily from my N900 via email or SMS(no server BS) and quickly import, especially since their format and app is being rolled out for every OS from Symbian, to Android and IOS, BB10, and WinCE in the future.
http://location2sms.anavi.org/

So, with gcc 4.6 is silently fails: https://garage.maemo.org/builder/fre...log.FAILED.txt

When the failing command was executed manually, it succeeded

I'll stick with the thumb build on my server (not yet in the repo) for the time beng. Does anyone have any idea why it can happen?

It seems to be impossible to switch off track log in the current version in the repo. Even if I push the stop button, the timer keeps counting up and the stop button never changes to a record button.

Also it doesn't seem to honour options set for the track feature, such as how often to calculate track and how often to save track.

Could endless tracking be a factor in Modrana crashing?

It does, if you bash it maniacally for a while. At least it my case, where I have tracking disabled on startup, and I start it manually. It looks like tracking is so occupying for ModRana, that it delays/ignore clicks, requiring you to spam them a little.

As for other issue you mentioned, their seem valid.
---

I noticed new version in -devel - out of curiosity, was something re cairo-crashing bugs done? Asking, as I haven't found any info about that in changelog, and I'm not sure if doing extensive re-testing have any sense, if that particular thing wasn't touched yet.

/Estel

I've checked out the location2sms source code repository and it is all C++ (Harmattan version) or Android Java (Android version), so source code drag & drop is not really doable as modRana is written in Python. On the other hand having the source code available could be definitely helpful for implementing the functionality as you can see how the other application is doing it, if it is handling any quirks and edge cases, etc.

While I agree this could be a nice addition to modRana and I'll definitely add it to the TODO pile, I must point out there are already quite a lot of feature requests and bugs in need of fixing, so I can't really say when I might get to actually working on this. But as always - patches are welcome! Actually, sending a working patch is the best way getting a feature you are interested in to modRana quickly.

Yeah, looks like that would be the best, at least for the time being. I can implement any functionality depending on the Mapnik packages optional so that if the packages are no installed modRana will run with reduced functionality but won't crash, etc.

This is the place where it fails, right ?
When Googling the error, I found this:
GCC previous to 4.3.x does not implement inclass member initialization
So maybe it is still using the old GCC 4.3 and not 4.6 ? Or the 4.6 is faulty ?

BTW, I've tried the Mapnik build from your repository (BTW, can it be added to the repository list ? I've just downloaded the debs manually but having it automated would be handy ). Unfortunately I haven't got very far yet as the libmapnik_2.2.0-ubuntu1~fremantle1_armel.deb package depends on the ttf-unifont package that doesn't seem to be available anywhere. Any ideas what to do about this ?

What version of modRana do you have ? I've tried with 0.47.3 (latest in Extras-Devel) and I have no issues with starting & stopping (or pausing logging).
Could you try to run modRana from the terminal (just run "modrana") and send me the log when this happens ?

Oh right, this indeed does not work. I see what can be done about it.

ModRana does not restart logging after you close it and start it again, so it could only happen if you started logging in the same run it crashed. If it crashed and logging was not started in the same run, the cause would be something else.

By tracking, do you mean track logging or tracking current position ?

Track logging is pretty lightweight - modRana just saves the current position to a list in memory every second and flushes the list to persistent storage every 10 seconds.

Position tracking on the other hand can be indeed quite demanding. The worst case being map rotation & centering shift & overlay & high zoom level & high movement speed. This makes modRana fetch & draw & rotate a boatload of tiles all the time which is pretty occupying.

You mean the new version of modRana in Extras-Devel ? Yeah, it basically had just a single fix (for logging stopping to log after a few minutes in some cases) and it looks like I forgot to properly announce it. Regarding the changelog - the modRana package page on packages.maemo.org has the changelog entries for the the most recent packages and is updated automatically once a new package is uploaded.

BTW, I'm aware of your earlier RFE post and plan to write an answer once I can get to it.

modRana 0.48.1 has been released!

The main highlight of this release is the map layer overlay support added to the Qt 5 GUI (used mainly on Sailfish at the moment) and the GTK GUI also got batch tile download size estimation.

As for bug fixes the Qt 5 GUI now properly remembers zoom level, the track logging page shows the actual logging interval configuration (the configuration was already used properly, just not shown as used) and a fixed URL for the Map1.eu map layer.

Changelog:

thanks, MartinK - now, is 0.48.2 a not-worth-mentioning bug fix?