maemo.org - Talk

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Applications (https://talk.maemo.org/forumdisplay.php?f=41)
-   -   [SFOS] [Announce] Native offline maps: OSM Scout Server (https://talk.maemo.org/showthread.php?t=97823)

rinigus 2020-11-22 11:52

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

Originally Posted by nonsuch (Post 1570246)
Not sure I understood the above correctly, but I uninstalled OSM Scout Server (through Storeman).

This completely locked up the system.
journalctl read:
Code:

Nov 22 12:12:54 XperiaXA2-DualSIM systemd[32240]: osmscout-server.service: Failed at step EXEC spawning /usr/bin/harbour-osmscout-server: No such file or directory
Nov 22 12:12:54 XperiaXA2-DualSIM systemd[4808]: osmscout-server.service: Main process exited, code=exited, status=203/EXEC
Nov 22 12:12:54 XperiaXA2-DualSIM systemd[4808]: osmscout-server.service: Unit entered failed state.
Nov 22 12:12:54 XperiaXA2-DualSIM systemd[4808]: osmscout-server.service: Failed with result 'exit-code'.
Nov 22 12:12:54 XperiaXA2-DualSIM systemd[4808]: Started OSM Scout Server.

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.

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!

olf 2020-11-22 13:41

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

Originally Posted by pichlo (Post 1570241)
<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>

Quote:

Originally Posted by rinigus (Post 1570242)
pkcon || zypper are clever enough - [...]

... and all what is needed.

Quote:

Originally Posted by rinigus (Post 1570242)
It's just we don't have repos specific to SFOS versions.

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

pichlo 2020-11-22 23:06

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?

nonsuch 2020-11-23 07:53

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

Originally Posted by rinigus (Post 1570248)
I presume you had an old version and Pure Maps was activating it via systemd sockets.

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.

Quote:

Any tips on limiting the rate are welcome - corresponding PR as well!
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.

olf 2020-11-23 16:11

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

Originally Posted by pichlo (Post 1570255)
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?

3 * No

(10chars)

rinigus 2020-11-23 16:35

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.

ggabriel 2020-11-23 17:20

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

Originally Posted by pichlo (Post 1570255)
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?

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

rinigus 2020-11-23 19:38

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

olf 2020-11-23 19:42

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

Originally Posted by rinigus (Post 1570269)
@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.

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.

rinigus 2020-11-23 20:05

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

Originally Posted by olf (Post 1570273)
That is well understandable and IMO reasonable.

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

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


All times are GMT. The time now is 11:13.

vBulletin® Version 3.8.8