OpenCPN Version 5.1.620 RC1 Test

[bdbcat]

tedcoats...
Will you please post your OCPN logfile?


Thanks
Dave

[pinguino]

Dave, I have to do more research on the plug-in thing. If I install any of my builds from 609 to 621 the list of plugins for download remains empty. But if I install the bdbcat/opencpn 619 bionic then I do have plugins to download and update.

I'll have to try a new clone from scratch to see if the same thing happens because your builds don't work for me because the sound of the opencpn alarms doesn't work.

[SCarns]

Originally Posted by bcn

The icons for the installed plug-ins do show the status. Here for example there exists an update for VDR:

Yeah, I am aware of that, but I have a large number of plug ins to scroll through to look. I was just hoping there could’ve a short cut because I’m lazy.

[hreuver]

Originally Posted by pinguino

Dave, I have to do more research on the plug-in thing. If I install any of my builds from 609 to 621 the list of plugins for download remains empty. But if I install the bdbcat/opencpn 619 bionic then I do have plugins to download and update.

I'll have to try a new clone from scratch to see if the same thing happens because your builds don't work for me because the sound of the opencpn alarms doesn't work.

With 5.1.621 (github) and 5.1.619 (beta) it works on Ubuntu 18.04 / arm64 like it should.



When I say "it works like it should", I mean there are still a number of plugins one needs to install from other sources. My list is far from complete, but you will see a few not available from the PluginManager (yet).


You should expect to use plugins from multiple sources for a while with OpenCPN 5.2. Even then I think support for arm64 has progressed a lot in 6 months.


PS the arm64 plugins are currently is identified by "armh64" in the filename, wonder where that came from. I find it hardly an issue though.

[pinguino]

Originally Posted by hreuver

With 5.1.621 (github) and 5.1.619 (beta) it works on Ubuntu 18.04 / arm64 like it should.



When I say "it works like it should", I mean there are still a number of plugins one needs to install from other sources. My list is far from complete, but you will see a few not available from the PluginManager (yet).


You should expect to use plugins from multiple sources for a while with OpenCPN 5.2. Even then I think support for arm64 has progressed a lot in 6 months.


PS the arm64 plugins are currently is identified by "armh64" in the filename, wonder where that came from. I find it hardly an issue though.


Attachment 218573Attachment 218574

Well, in my case, it doesn't. I use Raspi-OS 64. I just cloned again from scratch and build from github and still no plugins appear in the list other than those built by default with OpenCpn.



The parameters with which I build to solve the problem of OpenCpn with the sound in Rpi are:

cmake -DOCPN_ENABLE_PORTAUDIO=OFF -DOCPN_ENABLE_SNDFILE=OFF -DOCPN_ENABLE_SYSTEM_CMD_SOUND=ON -DCMAKE_INSTALL_PREFIX=/usr ../

Although I doubt very much that they have anything to do with it. In fact I always use the same parameters and in previous versions of the beta yes... the plugins appeared for download.

Edited to add:

I just cloned from scratch and build 5.1.621 RC1 into Debian Buster on amd64 and I get the same thing as arm64 with no plugins to download at all.

[bdbcat]

penquino/hreuver...


Confusing apples and oranges here.


1. Ubuntu 18.04 for arm64 is supported, as built from github and distributed by PPA. Some managed plugins are available now. I'm running this on a Rock64 board.



2. RaspiOS/64 is not being built by our CI process at all. It can be built from github on a native RaspiOS system (rPI4), and it does run. No managed nor legacy plugins are are yet available, and will not be for some time. However, native locally built plugins may work. Also not widely tested.



AFAIK, the Ubuntu 18.04/arm64 build will NOT run on RaspiOS/64, although I have not tried it. No reason to expect that it will....


Anecdotal reports of OCPN behaviour on RaspiOS/64 are interesting. But we should not spend too much energy on this until things stabilize.


So, the official line is that OpenCPN is not supported on RaspiOS/64. Seems reasonable, since RaspiOS/64 is still in Beta....


Does this analysis agree with your observations?


Thanks
Dave

[bdbcat]

P_Deb...


Re:
"With 5.1.620 all is OK but not with 5.1.621."


Will you post your logfile, please?


Thanks
Dave

[pinguino]

Originally Posted by bdbcat

penquino/hreuver...


Confusing apples and oranges here.


1. Ubuntu 18.04 for arm64 is supported, as built from github and distributed by PPA. Some managed plugins are available now. I'm running this on a Rock64 board.



2. RaspiOS/64 is not being built by our CI process at all. It can be built from github on a native RaspiOS system (rPI4), and it does run. No managed nor legacy plugins are are yet available, and will not be for some time. However, native locally built plugins may work. Also not widely tested.



AFAIK, the Ubuntu 18.04/arm64 build will NOT run on RaspiOS/64, although I have not tried it. No reason to expect that it will....


Anecdotal reports of OCPN behaviour on RaspiOS/64 are interesting. But we should not spend too much energy on this until things stabilize.


So, the official line is that OpenCPN is not supported on RaspiOS/64. Seems reasonable, since RaspiOS/64 is still in Beta....


Does this analysis agree with your observations?


Thanks
Dave

Okay, I can agree. Although I suppose that the incompatibility of OpenCpn 5.1.621 is not only with Raspi-OS 64 but also with Debian in general since it does not work on amd64 either.

By the way I have just compiled on Raspbian, the classic one, the 32 bit one and it does not work either. In fact it goes worse since if I try to open the tab of plugins in the configuration directly it crashes with segmentation fault.

The real pattern I find is:

1 if I use one of your builds everything seems to be fine. Both in amd64 and armhf and Raspi-OS 64 too.

2 if I build from github none of them work.

[Gilletarom]

Hello Dave,

This post is rather off topic. It concerns the oeSENc and oeRNC plugins.

In the case of the oeSENC plugin, if I declared in OpenCPN, a set of nautical charts registered on my Dongle, and if I forget to put my Dongle in place, I have this message displayed:"
This chart cannot be loaded due to any of the following reasons: - You have made important hardware changes on your computer. - Your OS has been updated and your license has been suspended. - This chart set was prepared for another system. - This chart set was prepared for a USB key dongle, but dongle is not detected. - There are corrupted files due to errors during download or unzip. Please contact info@o-charts.org if the problem persists.
"

This is normal.

But in the case of an oeRNC nautical chart set, this same type of message is not displayed.

Is this a mistake on my part or is it normal?

[bdbcat]

penquino, et al...


Update/correction:
re:
AFAIK, the Ubuntu 18.04/arm64 build will NOT run on RaspiOS/64, although I have not tried it. No reason to expect that it will....

Tested now, and the Ubuntu Arm64 package from Beta PPA will indeed install and run on RaspiOS/64. It installs as 5.1.612, and shows managed plugins available from the master catalog. Plugins not well tested.


This is an interesting and unexpected result. Who knew that the RaspiOS/64 was based on debian 10, without significant modifications? And will it shift to debian 11 (bullseye) for production release? Anyone know?


Dave

[bcn]

From the official announcement:

Along with yesterday’s launch of the new 8GB Raspberry Pi 4, we launched a beta 64-bit ARM version of Debian with the Raspberry Pi Desktop, so you could use all those extra gigabytes.

base is Deb10/Buster


https://www.raspberrypi.org/forums/v...rt=50#p1669460

[hreuver]

Originally Posted by bdbcat

This is an interesting and unexpected result. Who knew that the RaspiOS/64 was based on debian 10, without significant modifications? And will it shift to debian 11 (bullseye) for production release? Anyone know?

Not really surprising.
Ubuntu LTS is forked from Sid every time.

And Sid is the only rolling release on the Debian/Ubuntu front. No debian developper would suggest auto-upgrading debian 9 to 10, etcetera.

Ubuntu           Debian   
20.04 focal      bullseye/ sid   - 11 
18.04 bionic     buster  / sid   - 10
16.04 xenial     stretch / sid   - 9

But still the packages are a slight bit different. The toolchains (the dev-packages) from Ubuntu and Debian differ. This causes the amount of effort to compile OpenCPN for each platform to differ.

[bdbcat]

hreuver...
Thanks for the info.
I am just wondering why RaspiOS/64 is based on buster, and not bullseye. That must be coming soon...
I suppose the rPI devs are just being conservative, and trying to debug the port, instead of the base OS.

[hreuver]

Originally Posted by bdbcat

hreuver...
Thanks for the info.
I am just wondering why RaspiOS/64 is based on buster, and not bullseye. That must be coming soon...
I suppose the rPI devs are just being conservative, and trying to debug the port, instead of the base OS.

Definately very conservative: the RPI3 was 64-bit with too little memory to profit, therefore there was never a serious arm64 port.

The RPI4 was introduced as RPI3 upgrade and therefore still aimed at armhf/32-bit. Main purpose of the Raspberry Pi always has been limited difficulty and large market. Target has always been education and hobbyists.

Platforms like Odroid, OrangePi, NanoPi and Pine64 were always aimed at power-users. They always had more support for main distributions like debian and ubuntu, but also a stronger drive for arm64 (since GPU support is better in arm64 thanks to android).

If you look for a complete replacement of the OpenPlotter functionality, buster works better:
GTK2 makes for an easier port of OpenCPN and QT4 makes the MPU9250 can still be used with the old RTIMULib.
Those dependencies break, leading to a loss of functionality with bullseye (a RPI4 is then literally nothing more than a pc replacement).

I think most other users face similar problems.

[verkerkbr]

Originally Posted by Gilletarom

Hello Dave,

This post is rather off topic. It concerns the oeSENc and oeRNC plugins.

In the case of the oeSENC plugin, if I declared in OpenCPN, a set of nautical charts registered on my Dongle, and if I forget to put my Dongle in place, I have this message displayed:"
This chart cannot be loaded due to any of the following reasons: - You have made important hardware changes on your computer. - Your OS has been updated and your license has been suspended. - This chart set was prepared for another system. - This chart set was prepared for a USB key dongle, but dongle is not detected. - There are corrupted files due to errors during download or unzip. Please contact info@o-charts.org if the problem persists.
"

This is normal.

But in the case of an oeRNC nautical chart set, this same type of message is not displayed.

Is this a mistake on my part or is it normal?

The oesenc charts with the dongle works very well on my 64 RaspiOS. Almost everything works on the the 64 RpiOS.

Now made an other test on my AMD64 system with the latest Linux Mint Focal version. Most of the OpenPlotter additions allready work.

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