Re: [Announce] Native offline maps: OSM Scout Server
 

True - I'm tempted to create a local OBS, if I ever find something to guide me to do that.

OK, this is hard to do while all my maps are updating - all I can say is that I am getting a warning "Glyphs not found", I'm not sure how bad that is though.

Re: [Announce] Native offline maps: OSM Scout Server
 

Wait until all is updated.

Re: [Announce] Native offline maps: OSM Scout Server
 

For completeness, it all seems to be working. I missed offline maps/navigation/search in sfos 3.4 :)

Re: [Announce] Native offline maps: OSM Scout Server
 

As OBS target for 3.4. has been added, OSM Scout Server is available for testing at

http://repo.merproject.org/obs/home:....0.24_armv7hl/

As I don't have a way to test it yet, please let me know if it works.

Re: [Announce] Native offline maps: OSM Scout Server
 

I installed harbour-osmscout from the 3.4 OBS-Repo and did a (very) quick check - seems to work so far (tried map view, search, navigation)

Re: [Announce] Native offline maps: OSM Scout Server
 

Me too - updated maps, switched PureMaps to offline mode and tried a few searches and zooming in and out. It seemed to work fine.

Re: [Announce] Native offline maps: OSM Scout Server
 

The build is out at OpenRepos now - 1.17.1. It is for SFOS 3.4.0 users. The older SFOS users would have to use OBS for updates.

The released update includes updates to translations (thank you, translators!) and few packaging updates which are irrelevant for SFOS.

Re: [Announce] Native offline maps: OSM Scout Server
 

<ot>
I have always been wondering: isn't Openrepos clever enough to offer multiple versions and let your device pick the one matching your setup? Why do I bother defining version dependencies in my packages?
</ot>

Re: [Announce] Native offline maps: OSM Scout Server
 

pkcon || zypper are clever enough - hence uninstalling old OSM Scout Server on SFOS 3.4 update. It's just we don't have repos specific to SFOS versions. In principle, it is possible and make separate repos for different SFOS versions, but it would take extra time for me to keep it all in sync. If you are that advanced that choose SFOS versions (or have to due to the use of the port) then you should be able to configure pkcon/zypper to use OBS repo as well.

Re: [Announce] Native offline maps: OSM Scout Server
 

Not sure I understood the above correctly, but I uninstalled OSM Scout Server (through Storeman).

This completely locked up the system.
journalctl read:
This repeated ~50 times per second.
A reboot was tricky (stayed on red LED, had to hold VolUp+Power), but after that everything was OK.

After reinstallation everything seems to be working fine (SFOS 3.4).
Just thought I'd report this.

Re: [Announce] Native offline maps: OSM Scout Server
 

I presume you had an old version and Pure Maps was activating it via systemd sockets. Any tips on limiting the rate are welcome - corresponding PR as well!

Re: [Announce] Native offline maps: OSM Scout Server
 

... and all what is needed.

... which are not needed, anyway.

For example, the recent Storeman and crypto-sdcard RPMs are provided in SFOS-version specific releases in a single RPM-repository.

I documented how to handle this (primarily for myself) in crypto-sdcard's "Release version format, RPM dependencies and Git workflow". Suggestions, enhancements, constructive criticism, etc. are welcome, as always.

Re: [Announce] Native offline maps: OSM Scout Server
 

Sorry a naive question from an old geezer with only a shallow understanding of Linux and its distribution systems.

Does it need to be SFOS-version specific? If let's say a patch updates let's say the SMS app version x.yy.zzz, isn't it a bit of an overkill to make it depend on a specific version of SFOS, rather than, more logically, on a specific version of the SMS app? Will pkcon/zypper not work it out in such a case?

Re: [Announce] Native offline maps: OSM Scout Server
 

Strangely I don't think Pure Maps was running at that moment, I had only just booted the phone.
I gather from your comment that this is a known issue, maybe it was already mentioned elsewhere.

That wouldn't make it a OSM Scout server issue anymore, no?
Be that as it may, ~50 times a second seems too much, but otoh there might be a good reason for that.

Re: [Announce] Native offline maps: OSM Scout Server
 

3 * No

(10chars)

Re: [Announce] Native offline maps: OSM Scout Server
 

@olf: I must say it is fast becoming rather elaborate in terms of trying to support multiple SFOS versions with several packages. I prefer to offload this to the users and provide such support using OBS repos. There is limited time that has to be taken into account and, in this context, I prefer to distribute the workload instead of piling it all on myself.

@nonsuch: something has to access it to make it happen. It could be any other client that you could have been running (modRana, sports app). Don't know what else could it be. I guess that you had somehow a server version installed which could not be launched. Why, no idea. And systemd tried to launch it - many times. Alternative is that socket activation script was left behind after uninstall. But I would expect systemd to check for availability of executable before starting it.

Please file it as an issue, so I would remember to look into it.

Re: [Announce] Native offline maps: OSM Scout Server
 

Just to give you a bit more context: each piece of software will probably have dependencies and certain requirements (like syscall availability and such), hence each OS/distribution will package such software according to what is available for each OS/distribution.

You are right that if the SMS app changes "a != null" for "null != a", it will not affect those dependencies/requirements, and thus all packagers will find it trivial to update it; however, if an upgrade now requires the availability of e.g., the library to access sqlite databases, each OS/distro will have to adjust accordingly. OS2/Warp (*wink* *wink*) would find it probably impossible, while others will have it provided already and perhaps something like Gentoo Linux will just add a build dependency.

So, it isn't possible to do what you ask unless everybody agrees on a ubiquitous packaging system that does all this for you and works everywhere. I could quote a couple of examples where this "kind of" works at a generic level, but it will a) spark a lot of debate and b) will be very off topic.

Lastly, the examples above (dependencies/sys requirements) don't cover everything that is to be taken into account, there are a lot more things :)

Re: [Announce] Native offline maps: OSM Scout Server
 

@nonsuch: I have opened an issue https://github.com/rinigus/osmscout-server/issues/343

Re dependencies: fortunately, RPM SPEC deps are frequently detected automatically. So, large part of it is done for us. But to support multiple SFOS version from single repo, I would have to have all RPMs with unique names and ensure that they don't clash (sometimes same RPM can be installed in multiple SFOS versions).

Re: [Announce] Native offline maps: OSM Scout Server
 

That is well understandable and IMO reasonable.

I just wanted to point out, that it is technically feasible (which was @pichlo's original question), used in practice at Openrepos, and does not need multiple RPM-repositories.

Re: [Announce] Native offline maps: OSM Scout Server
 

It was me who had an impression that you need multiple repos. Turned out to be wrong :). Thanks for educating!

Re: [Announce] Native offline maps: OSM Scout Server
 

I am confused :confused:. Your answer seems to be contradictory.

If I get you right,

• "Does it need to be SFOS-version specific?" NO
• "Isn't it an overkill to make [a patch] depend on a specific version of SFOS?" NO
• "Will pkcon/zypper not work it out in such a case?" NO

Clearly, a negative answer to items 2 and 3 contradicts a negative answer to item 1.

Re: [Announce] Native offline maps: OSM Scout Server
 

That's kinda obvious. But not what I was asking. I was asking about indirect dependencies. Is it absolutely necessary to spell out every brick or go out full-on desperate and specify an OS version dependency? Or can I just specify a dependency on a given package that I know includes all the bricks?

That way, if that specific package does not change on an OS update, then I am guaranteed that all the dependencies are still satisfied and my package does not need to do anything. Conversely, if the package I depend on changes without an OS update, then I know I need to update my package.

Re: [Announce] Native offline maps: OSM Scout Server
 

It's pretty common for package managers to make a hard dependency on the OS major version at times. Some programs needn't do this (e.g., Tidings has been unreleased for a long time and yet it "survived" many major OS upgrades) but others may benefit from this.
Depending on a specific package because you know it will have all the dependencies may not be possible on major OS upgrades as the repository may have changed and that package may not be there any more. Moreover, if you're a developer, it is simpler to set a baseline and just state that in your application - e.g., a SFOS 3.4 developer will probably not know what SFOS 1.0 had bundled, so it's just simpler to make the program compatible for a current version.
What you describe is a pattern used in OS's/distributions that support rolling upgrades, and even in those cases there are certain states where you won't be able to upgrade any more, one of the most popular reasons being that packages simply change or disappear from the repository. In practice, if you forget to upgrade such OS's/distributions for ten years, don't expect that the package manager will happily bring you to the present time.

Re: [Announce] Native offline maps: OSM Scout Server
 

Not AFAICS.

You do!

Re: [Announce] Native offline maps: OSM Scout Server
 

Thank you so much.
I will add some comment there - but not tonight, it's been a long day, I'm just sortof winding down here on TMO... :cool:

Re: [Announce] Native offline maps: OSM Scout Server
 

Neither is "absolutely necessary".
While "spelling out" is the sensible way in general, on SFOS that basically makes no difference.

Yes, you can.
E.g., on a version of sailfish-version. ;)

P.S.: Man, you are asking strange questions, loaded with assumptions. Plus structurally always "Is A or B or C?". As most of these do not hold true, the answer is usually "no", "neither" or "none".

Re: [Announce] Native offline maps: OSM Scout Server
 

Am I? I thought I was asking pretty obvious question to eliminate assumptions!
And, for some strange reason, I am still not getting a straightforward answer :confused:

But OK, let's make assumptions explicit.

This is how I see it (simplified, with an explicit assumption that everyone understands that each library, application etc may have multiple versions):

Attachment 41347

My original question was, "isn't Openrepos clever enough to offer multiple versions and let your device pick the one matching your setup?"

(That is, assuming one uses a proper, rather than lazy dependency definition as per the diagram above.)

Re: [Announce] Native offline maps: OSM Scout Server
 

Which is not helpful, because some of these assumptions seem to be wrong ones, hence the whole diagram does not make much sense to me.

Look, all these things are publicly documented: Tools, typical workflows, and most importantly, how people practically use it. Plus what the package-resolver (e.g. libzypp) does on your device.
RTFMs and take look at this stuff, in the web (Openrepos.net, Git{hub|lab}.com) and on your device in practice.

See, it is the same here, once again:
The answer is "Yes".
Structurally an concatenation of two questions (here: per "and", instead of "or"), both spiced with wrong assumptions. Negating one of the concatenated questions makes it hard to correctly deduct the overall answer to the question logically, and almost impossible to decode this answer.
Thus this answer very likely (again) does not provide what you wanted to know.

Q1, "isn't Openrepos clever enough to offer multiple versions": Yes, it is not!
- What do you mean to address with "Openrepos": The site <openrepos.net> (spacial), the Openrepos-webfrontend (technical), something else?
- An RPM-repository (maybe you meant that, i.e. "something else" above) is not "clever", it is a directory (tree) published via http(s). It "offers" whatever you put into these directories.

Q2, "let your device pick the one matching your setup?": Yes, dependency resolution is performed by the package resolver locally; AFAIK (at least for rpm, libzypp, dpkg and any tools based on them, as pkcon, zypper, yum, apt etc.) always and solely.


P.S.: Following the three links I provided in my original reply to your original question, might be helpful for you.

P.P.S.:IMO, we shall end this sub-thread here, it is off-topic by far (Q&A for packaging basics).

Re: [Announce] Native offline maps: OSM Scout Server
 

Which is exactly why making assumptions explicit is helpful (not just in this discussion, but always!).
It clarifies where the two parties come from different angles and identifies the points that may need clarification.

I am sure I could find an answer to everything, if I could afford to devote years of studying and research. All I wanted was a simple, straightforward, "YES" or "NO" answer. If there isn't one, all I wanted was someone to say so. A single post would have done. Instead, we've had two pages of discussions going nowhere.

There you go again. That "answer" is absolutely useless to me. "Yes" and "no" are exact opposites. They are mutually exclusive. It's either-or, it cannot be both.

<snip the rest of your response that, YET AGAIN, did not answer my question>

I give up. It is all off topic anyway. Apologies to rinigus for accidentally hijacking the thread.

Re: [Announce] Native offline maps: OSM Scout Server
 

Maps updated and uploaded to modRana server, ready for distribution.

Re: [Announce] Native offline maps: OSM Scout Server
 

New maps are out.

This time, I am retiring libosmscout map datasets. There was an error during import and, as I use very old version of that lib, I decided not to fight it, but drop that dataset. As nobody volunteered to support libosmscout backend (I think I notified regarding dropping support for it years ago), libosmscout backend will be also disabled in the upcoming official builds. Code is still there, just commented out via MACROs.

Re: [Announce] Native offline maps: OSM Scout Server
 

As a simple user: what impact does this have on OSM Scout Server?
Is there something someone without programming skills can do on that side? As dropping functionality most time isn't a good thing.

Re: [Announce] Native offline maps: OSM Scout Server
 

Re impact: it is used in non-default profile and I suspect that nobody is really using it, or very few. I have no stats to back it up, though.

I would expect that most are using default profile (Mapbox tiles, Valhalla routing, and GeocoderNLP search).

Without programming skills, not much can be done here.

Re: [Announce] Native offline maps: OSM Scout Server
 

Thanx for the explanation and many thanx for your ongoing support! My last donations (not just for you) are way to long ago. I have to make a donation round on the coming weekend, to honor the work you guys do.

Re: [Announce] Native offline maps: OSM Scout Server
 

Can you please keep the last successfully imported libosmscout map datasets accessible, at least for a while.

Side note: While I am primarily asking to have a chance to download them (I have not updated my map data for over a year on multiple OSM Scout Server installations), they might be of interest for any user of a OSM Scout Server version, which still includes the libosmcout backend (as I am, because of mainily using slightly older SFOS releases).

Re: [Announce] Native offline maps: OSM Scout Server
 

Dear Olf, unfortunately, it is impossible to provide the old imports in the infrastructure that we have. I have not designed my scripts, nor distribution path, nor OSM Scout Server with that in mind. As a result, we can provide one set of maps and that set has to be imported in one go. There is a handling of switch over from one set to another, but nothing more fancy. So, to start mixing imports, some new development has to be undertaken.

In retrospect, maybe I should have looked further when implementing maps distribution and used some packaging format for it. However, again, that requires some serious time investment. Something I am not planning as a priority, when you look into long least of issues to resolve.

Supporting old SFOS versions is not super easy due to changing names of dependencies, improvement of the tools (gcc and friends) and so on. Right now there are no changes in database formats, but at some it may come as well, which would make use of old server impossible with new maps. So, even with OBS builds, you should expect sunset for older SFOS versions in terms of support. But that, I believe, has been discussed earlier as well.

As for libosmscout library support, if you do prefer to use that, it is possible to switch to Karry's OSM Scout application. It surely is better than use of libosmscout backend on OSM Scout Server. Don't know how it supports old SFOS versions, but maybe grabbing older version would work.

Re: [Announce] Native offline maps: OSM Scout Server
 

OSM Scout Server new release is out: 2.0.0

Changelog at https://github.com/rinigus/osmscout-...ases/tag/2.0.0

In this release, the server is split into two applications: server itself and GUI. While GUI helps you to configure the server and instruct it to manage maps, main work is done in separate server. Through this separation, it is possible now to have server running without interruptions due to GUI process launch. It also makes it easier to support different forms of automatic activation (DBus and network).

The both applications are packaged together, so not much changes for users. As a side effect of the split into two applications, Jolla Store seems to be further away.

The server supports DBus activation now, which simplifies access by Pure Maps (and other clients when they will implement it) to map matching (snap-to-road) functionality. As DBus service names changed, I will release soon a version of Pure Maps that is compatible with this release. Other APIs were kept the same.

The server supports now network activation that is similar to what is provided by systemd via socket activation. This will be used in Linux distributions lacking systemd (as postmarketOS and Ubuntu Touch) or if you wish to run server from Flatpak. For that, server runs in low-memory mode where it just listens to new connections to its port. On activity, full server is launched which will later exit when idle. On SFOS, systemd would take care of it, as before.

Valhalla version on SFOS has been updated to 3.1.0. That should be compatible with the current maps.

As mentioned before, libosmscout is now disabled in the distributed builds.

Updates in translations (thank you translators!) were incorporated few minutes ago.

Other changes include updates in Ubuntu Touch packaging (jonnius), support for SFOS My Backup (atlochowski), support for newer microhttpd by Thra11 during packaging for NixOS, addition of missing regions and some changes in docs shown via https://rinigus.github.io/osmscout-server/en/ .

Re: [Announce] Native offline maps: OSM Scout Server
 

Dear Rinigus,

that is unfortunate (at the moment), but sure O.K.

The software aspects were not the point here; one has to deal with them, if on an older SFOS release.

Side note:
While I just stopped updating my Jolla 1 beyond SFOS 2.2.1, my "production" phone is at SFOS 3.2.1, because all newer releases (i.e., 3.3.0, 3.4.0, 4.0.1) exhibit flaws, which make them unsuitable for my production use.
But that is a quality assurance issue Jolla has, and nothing independent software developers should have to care about.

Re: [Announce] Native offline maps: OSM Scout Server
 

Very delayed maps update - new maps are out