OS Linux specific

[sv_blackbird]

I have an apparent packaging error on OpenSUSE:


I'm running OpenCPN 5.0 on OpenSUSE (Leap 15.2). I've installed OpenCPN from the OpenSUSE repositories - for OpenCPN that means:

https://download.opensuse.org/reposi...SUSE_Leap_15.2

When I did that, most of the plugin libraries installed in /usr/lib/opencpn, but FOUR of them:

libchartdldr_pi.so
libdashboard_pi.so
libgrib_pi.so
libwmm_pi.so

installed in to /usr/lib64/opencpn. Note that these plugins are part of the "OpenCPN 5.x Base" package. As a result, those plugins were not accessible. All other plugins installed their libraries in /usr/lib/opencpn (even though they are 64-bit).

As soon as I made the appropriate soft links, those libraries loaded.

While I've solved the immediate problem, I'd like to know who "owns" the OpenSUSE packaging so that I can pass this on to them.


This was originally posted to the "main" forum before I realized that there was a Linux-specific thread; sorry!


Thanks!


Dan

[dominig]

Originally Posted by sv_blackbird

I have an apparent packaging error on OpenSUSE:


I'm running OpenCPN 5.0 on OpenSUSE (Leap 15.2). I've installed OpenCPN from the OpenSUSE repositories - for OpenCPN that means:

https://download.opensuse.org/reposi...SUSE_Leap_15.2

When I did that, most of the plugin libraries installed in /usr/lib/opencpn, but FOUR of them:

libchartdldr_pi.so
libdashboard_pi.so
libgrib_pi.so
libwmm_pi.so

installed in to /usr/lib64/opencpn. Note that these plugins are part of the "OpenCPN 5.x Base" package. As a result, those plugins were not accessible. All other plugins installed their libraries in /usr/lib/opencpn (even though they are 64-bit).

As soon as I made the appropriate soft links, those libraries loaded.

While I've solved the immediate problem, I'd like to know who "owns" the OpenSUSE packaging so that I can pass this on to them.


This was originally posted to the "main" forum before I realized that there was a Linux-specific thread; sorry!


Thanks!


Dan

Sorry for late reply, but I missed that message. I will look at it while I package the version 5.2 of OpenCPN.
For info it's faster to report bugs directly via OpenSUSE to the package owner (dominig).

[jak3b]

There is a new 1.0 version of Navigatrix, 64 and 32 bit available. navigatrix.net

[stelian]

Hi everybody,

I found a bug in how OpenCPN handles the numeric decimal point in navobj.xml: when set-up as fr_FR.UTF-8 (system default here), the decimal point is a comma, and the longitude/latitude coordinates are written like this:
<trkpt lat="48,823099465" lon="-3,400691644">

However, when OpenCPN restarts and re-reads navobj.xml, it fails to parse the comma and the coordinates become 48.0000 / -3.0000. So the line written into the navobj.xml will be, on the second run:
<trkpt lat="48.000000000" lon="-3,000000000">

So all the tracks/routes/waypoints will be lost on the second invocation. Better have backups !

Somewhere else, the same kind of bug is causing the world map to be shown at each startup (instead of the latest map and zoom level).

A simple workaround is to launch opencpn using:
$ LC_ALL=C opencpn

I'm pretty sure this bug was not in OpenCPN 5.0

Should I put this into FlySpray ?

Stelian.

[bdbcat]

Stelian...
" Should I put this into FlySpray ?"


Yes, please.


Thanks
Dave

[stelian]

Originally Posted by bdbcat

Stelian...
" Should I put this into FlySpray ?"

Yes, please.


Thanks
Dave

Done, FS#2701 : https://opencpn.org/flyspray/index.p...s&task_id=2701

Thanks,

Stelian.

[Roel Smidt]

Originally Posted by stelian

Hi everybody,

I found a bug in how OpenCPN handles the numeric decimal point in navobj.xml: when set-up as fr_FR.UTF-8 (system default here), the decimal point is a comma, and the longitude/latitude coordinates are written like this:
<trkpt lat="48,823099465" lon="-3,400691644">

However, when OpenCPN restarts and re-reads navobj.xml, it fails to parse the comma and the coordinates become 48.0000 / -3.0000. So the line written into the navobj.xml will be, on the second run:
<trkpt lat="48.000000000" lon="-3,000000000">

So all the tracks/routes/waypoints will be lost on the second invocation.
Stelian.

Thank you Stelian!
I have the exact same problem but I don't use fr_FR.UTF-8. Instead most of my settings are Dutch (nl_NL.UTF-8).

My settings for "locale" are as follows:
LANG=en_US.UTF-8
LANGUAGE=en_US
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=nl_NL.UTF-8
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=nl_NL.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=nl_NL.UTF-8
LC_NAME=nl_NL.UTF-8
LC_ADDRESS=nl_NL.UTF-8
LC_TELEPHONE=nl_NL.UTF-8
LC_MEASUREMENT=nl_NL.UTF-8
LC_IDENTIFICATION=nl_NL.UTF-8
LC_ALL=

I am relatively new to Linux, but maybe some (or all??) of my nl_NL.UTF-8-settings should be changed into "en_US.UTF-8"?

I have no idea but I would really like to know how to solve this. And of course I will vote for your entry in Flyspray.

Roel

[stelian]

Originally Posted by Roel Smidt

LC_NUMERIC=nl_NL.UTF-8

[...]

I am relatively new to Linux, but maybe some (or all??) of my nl_NL.UTF-8-settings should be changed into "en_US.UTF-8"?

I have no idea but I would really like to know how to solve this. And of course I will vote for your entry in Flyspray.

Roel

In your case, it's probably the LC_NUMERIC setting which triggers the problem.

Until this is fixed, you can either change your system wide LC_NUMERIC setting or launch OpenCPN through a shell script like:

#! /bin/sh
export LC_NUMERIC=en_US.UTF-8
exec /usr/bin/opencpn

Stelian.

[Roel Smidt]

Originally Posted by stelian

In your case, it's probably the LC_NUMERIC setting which triggers the problem.

Until this is fixed, you can either change your system wide LC_NUMERIC setting or launch OpenCPN through a shell script like:

#! /bin/sh
export LC_NUMERIC=en_US.UTF-8
exec /usr/bin/opencpn

Stelian.

Thank you again Stelian!

Entering sudo update-locale LC_NUMERIC=en_US.UTF-8 (in terminal) and then restarting the computer solved my problem. OpenCPN now saves my tracks and routes as they should be.

[rgleason]

Is it worthwhile putting a link to this in wiki FAQ until next release?
I wonder...

[Roel Smidt]

Originally Posted by rgleason

Is it worthwhile putting a link to this in wiki FAQ until next release?
I wonder...

Hi Rick,
If you want I can do that (as it's high time I did some editing again). But I could also make a note of this in the section about Linux

https://opencpn.org/wiki/dokuwiki/do...allation:linux


and/or in the section about the Route & Mark Manager (because the wrong Numeric-settings caused OpenCPN to mess up all the routes and tracks).
https://opencpn.org/wiki/dokuwiki/do...mark_manager&s[]=manager



Roel

[rgleason]

Roel, those are good locations I think, you can provide a link to the other location for the more detailed explanation. Most users would be confounded by this. Thank you!

[Roel Smidt]

Originally Posted by rgleason

Roel, those are good locations I think, you can provide a link to the other location for the more detailed explanation. Most users would be confounded by this. Thank you!

OK, have updated the manual.

[Roel Smidt]

Originally Posted by stelian

Hi everybody,

I found a bug in how OpenCPN handles the numeric decimal point in navobj.xml:

Hi Stelian,


I had the same problem but after updating to Version 5.2.4 Build 2020-10-14 everything works OK. To me it seems this bug is not present anymore in 5.2.4 Build 2020-10-14.

[banjoship]

I am doing a clean build of systems from scratch on a new (to me) computer. It is a dual boot Win 10/ Linux Mint 20 machine.


Linux Mint 20 was installed from scratch; OpenCPN installed from the standard opencpn/opencpn PPA; oesenc-pi installed using the plugin manager.


On running, oesenc-pi failed to recognise my dongle. After digging around it appeared that I was missing the package "opencpn-sglock-amd64". Installed the package and all is well.


Something for the team to note?


Lee