OpenCPN Version 5.1.620 RC1 Test

[Gilletarom]

Originally Posted by verkerkbr

....
However the Oesenc charts setup reports that the dongle cannot be found.

However if a look at lsusb. The dongle is certainly connected to the system.

It is the same Oesenc plugin version 4.2.12.

I get the same message as Gilleterom.

Bram

In fact, the difference in operation between oeSENC and oeRNC probably comes from oeRNC. A difference in design in oeRNC probably explains this difference.

[hreuver]

@bram I suspect something went wrong with the USB key initialization.

Does ''~/.local/bin/oeserverd -s'' yield 0 or 1?
Do you have a file /etc/udev/rules.d/98-sglock.rules (or something similar)?
Do you see the ID for you SGlock USB Key when you update the charts in the oeSENC menu?

Tested with Debian Bulseye/Sid + OpenCPN 5.1.619 (bdbcat) the USB Key dongle works. I suspect the 98-sglock.rules makes the difference. To test it you could try ''sudo chmod 666 /dev/hidraw0'' before starting OpenCPN to change the user permissions just once.

[verkerkbr]

oeserverd -s generates 0

no 98-sglock.rules

sudo chmod 666 /dev/hidraw0

Still dongle not detected.

Activate the SG-lock 64 oesenc plugin. It was off at first test.

I also do not see the latest Plugin Manager. But perhaps I'am wrong.


Bram

[bdbcat]

I think we should count on RaspiOS/64 migrating to focal/bullseye, and GTK3. The only question is timing.
Meanwhile, we will do our best to make OCPN work with RaspiOS/64 on buster/bionic, i.e. the current publicly available Beta. And wait for more developments from rPI on bullseye in the "fullness of time".


Thanks
Dave

[hreuver]

Originally Posted by verkerkbr

oeserverd -s generates 0

no 98-sglock.rules

sudo chmod 666 /dev/hidraw0

Still dongle not detected.

Activate the SG-lock 64 oesenc plugin. It was off at first test.

I also do not see the latest Plugin Manager. But perhaps I'am wrong.


Bram

@bram
Your problem: you need rights for the USB device.
To get the rights, you need the udev rule.
To write the udev rule you need (temporary) admin rights.

With the old method of installing adding the udev rules was no problem.

And now I look at @bdbcat to ask how it is supposed to work with downloadable plugins.
Are you considering adding the udev rule to the opencpn package?

[bdbcat]

hreuver...


This is admittedly a problem for managed plugins in user space.
Our position now is that new users will be recommended to install the legacy plugin from the PPA first, and then upgrade to the managed version.
A future version of OCPN will allow privilege elevation to install any needed system-level patches/drivers/etc without resort to "sudo".


An alternative for OCPN 5.2, soon releasing, is to do as you suggest. On linux systems, simply add the sglock udev rule at the installation of OCPN, while in sudo mode. Does no harm if the sglock dongle is not present.


I will consider the implications of this.....


Thanks for the idea.
Dave

[bdbcat]

Bram, et al...


Concerning RaspiOS/64:
There is a difference between locally built OCPN, and OCPN installed from PPA build. The difference affects the default operating system definition. On the Ubuntu PPA, we get "Ubuntu", as expected. If locally built from github on the RaspOS/64 Beta, we get "debian".


The managed plugins available for Ubuntu bionic expect "Ubuntu", reasonably. Thus, they are not found for local builds at runtime.


If you need/want to build locally, you may override the default system definition in the OCPN config file. This will do it:

[Settings]
CompatOS=Ubuntu
CompatOsVersion=18.04

But our canonical user should not need to do this.


And, just so we are all clear:
I appreciate feedback from local builds. It helps improve the code quality.
But for Production Release purposes, I focus attention mainly on what a casual user will encounter by following our simple instructions. Complicated steps requiring custom builds, scripts, dependent package installation, etc. are not friendly for the large majority of our user base. We should work to eliminate these gritty steps wherever possible.

And so, in this case, a simple installation of OCPN from the Ubuntu PPA will work for a large percentage of our RaspiOS/64 users. And that is our recommendation.


Thanks
Dave

[Hakan]

Dave..
- Object name circle

Win10, O 5.1.621, oeSENC 4.2.12, DK and SE charts.
A circle is drawn below LNDRGN Object name on oeSENC charts that I have not seen before. Kind of disturbing.
Is there anything you can do?
See attached pict.

Thanks
Håkan

[hreuver]

Both seem viable options to me.

When you think about it, you will have to include one point in the scenario: When switching between oesenc-pi (PPA) and oesencpi (github) I needed to de-install the old version first since one package write to 1 file in /etc/udev/rules.

It's only a transitional problem, but still you can expect questions about it from users who upgrade and/or combine plugins form whichever source.

No real problem if you stick to either the ''clean up, before install'' or ''use a specific install order'' approach.

PS when playing with OpenPlotter I was surprised at first they use the kexec approach instead of sudo (at first I failed to see how they got access).

Just to for the record, sudo and kexec are just different methods of playing with fire (/etc/pam.d/sudo and /etc/pam.d/polkit-1). That might be something for OpenCPN 5.4 though.

[bdbcat]

Hakan...
I do not know what that circle is all about.
Is this new?
I will take a look...


Thanks
Dave

[bdbcat]

All...
IMPORTANT.


Getting ready to release another RC.
But....
One user reports trouble with legacy plugins on Win10. None of the plugs appear in the list.
Now, this could be a specific user/system problem, not related to OCPN. Or it could be more widespread.


So, has any Windows user experienced trouble with enabling and using legacy plugins as downloaded and installed from opencpn.org?


Thanks
Dave

[pinguino]

Originally Posted by bdbcat

Bram, et al...


Concerning RaspiOS/64:
There is a difference between locally built OCPN, and OCPN installed from PPA build. The difference affects the default operating system definition. On the Ubuntu PPA, we get "Ubuntu", as expected. If locally built from github on the RaspOS/64 Beta, we get "debian".


The managed plugins available for Ubuntu bionic expect "Ubuntu", reasonably. Thus, they are not found for local builds at runtime.


If you need/want to build locally, you may override the default system definition in the OCPN config file. This will do it:

[Settings]
CompatOS=Ubuntu
CompatOsVersion=18.04

But our canonical user should not need to do this.

Bingo! That do the trick. All the plugins appear in my Raspi-OS 64 finally.

Originally Posted by bdbcat

And, just so we are all clear:
I appreciate feedback from local builds. It helps improve the code quality.
But for Production Release purposes, I focus attention mainly on what a casual user will encounter by following our simple instructions. Complicated steps requiring custom builds, scripts, dependent package installation, etc. are not friendly for the large majority of our user base. We should work to eliminate these gritty steps wherever possible.

And so, in this case, a simple installation of OCPN from the Ubuntu PPA will work for a large percentage of our RaspiOS/64 users. And that is our recommendation.

Thanks
Dave

I totally agree with you. Only one detail and that is that in the case of installations for Raspberry pi and for years now none of the official builds is valid because they suffer from the bug regarding the malfunction of the sound alarms.

So for any user of Raspberry pi who wants to have all the potential of the alarms of openCpn there is only one way and is build directly from the sources by applying the correct parameters.

Just today they have asked about it in openmarine about this issue.

https://forum.openmarine.net/showthread.php?tid=2709

Most users simply conform or do not use the sound alarms but if you need them the PPA builds are not valid.

[vagspel]

Strange behavior when loading charts:
When stopping OpenCPN with a chartfolder containing oeSenc and CM-93 charts and having the oeSenc chart on display the CM-93 chart is always displayed when the program is restarted.
This is a bit unsafe for an operator that in a stressed situation does not directly see what chart he is using.
One way of getting around the problem is of course to make two folders, one with oeSenc charts and one with both oeSenc and CM-93 and always remember to end the program in the first chart folder.
I understand that this has something to do with computer speed and the way treads ar executed. Tested on a fast PC with no luck and it never works on a Raspberry

[cagney]

Originally Posted by bdbcat

Hakan...
I do not know what that circle is all about.
Is this new?
I will take a look...


Thanks
Dave

Dave/Håkan

The circle in itself is just a standard Chart 1: B 20-22

Position of an elevation
or control point

I do think that the implementation has changed. Look at this...


The circle for "Jonseskär" is situated in the water and not on the Islet.

The little headland Enudden is a split word with a circle under each part, both in the water.
Both the names above clearly indicates land features.

Perhaps the Swedish "SMA" have introduced these changes?
I have just upgraded my charts, and I suspect that Håkan has as well.

Thomas

[bdbcat]

vagspel....
Are you reporting for OA 5.1.620, or some other version?


More detail/versions, please.

Thanks
Dave