May you add in the main download page of OpenCPN that Mageia offers packages of OpenCPN and its plugins

[filochard]

In https://opencpn.org/OpenCPN/info/downloadopencpn.html
there's not a big change to do :

in the bottom, after

[leamas]

Does this mean that you have packaged also the non-free closed-source oesenc and oerenc plugins in Mageia?

[mgrouch]

The license says:

This software is copyright (c) David Register 2021. It is distributed under the terms of the Gnu Public License version 2 or, at your option, any later version. See COPYING.gplv2.

The oeaserverd binary and libsgllnx64-2.29.02 libraries are closed source. Re-distribution of these items is allowed.
The oeserverd binary and libsgllnx64-2.29.02 libraries are closed source. Re-distribution of these items is allowed.

Most Linux distributions even major ones include proprietary closed source re-distributable code.

[leamas]

Now, my question was if oesenc et. al. is packaged in Mageia. Are they?

[filochard]

Hi
Indeed we couldn't package s63 nor oerenc before the license was clear... an issue had been opened in flyspray in 2016 but had never received any answer
https://opencpn.org/flyspray/index.php?do=details&task_id=2115&string=s63&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=
So we were stuck
(I could only build these packages for my own use)

Fortunately I asked bdbcat recently and the modification of the license has be done
bdbcat/oernc_pi#5
bdbcat/s63_pi#20

Now we can add these plugins as rpms for Mageia :
Besides its core repository (for the opensource gpl programs) Mageia has a non-free repository for this kind of packages (closed source but distributable) where s63 oesenc and oernc plugins will soon be available
(it's not so easy to add new packages in an already released distribution : it's not strictly an update but a backport, and they need to be verified by the QA team and the opencpn package needs a warning to tell where to find the three partly closed source plugins)

[leamas]

well, easiest might then be to wait until oesenc actually is available, it is such an important plugin for many users.

You should also probably also clarify the limitations w r t plugins compared to the flatpak version which I assume works just fine also on Mageia (?)

[filochard]

Hi
First I need to apologize about my English : sometimes I may be not clear when I write, sometimes I may misunderstand what I read
One example of possible misunderstanding concerns what you just wrote about comparing plugins in flatpak and Mageia :

I opened some issues about plugins that are OK when we package them for Mageia but don't work well inside flatpak
Thanks to you (developers) some of these issues inside flatpak have been corrected (watchdog, SAR, AISRadar...) some are on the way to be corrected (logbook..) some are not yet (radar)

Flatpak would be simpler indeed for all the linux distributions : no need to build packages for each one : one tar.gz fits all and the plugin manager is more simple to use than installing packaged plugins one by one
but it seems not mature enough compared to the packaged version

Besides this :
The flatpak version needs some workarounds to use your own charts (kap or mbtiles) polars or other stuff if they are in directories of your system whose flatpak has no access (for security reason)
Same limits about some system programs (such as LibreOffice Firefox which logbook can't access from flatpak for instance)

A packaged version doesn't need these workarounds, and works out of the box...

Perhaps may I discuss with Mageia people about the way to use the plugin manager (it would be a heavy job, but when it's done it's done, and the updates would be automatically downloaded from cloudsmith for instance...)
But !!! I know they don't like when a program downloads and installs library from outside without having been tested by the QA team.

[leamas]

The flatpak version needs some workarounds to use your own charts (kap or mbtiles) polars or other stuff if they are in directories of your system whose flatpak has no access (for security reason)

The flatpak'ed version has full access to $HOME. This should actually cover the large majority of use cases. And adding more directories isn't actually that hard. Are there any specifics for Mageia which means users are in need of using directories outside of $HOME?

Same limits about some system programs (such as LibreOffice Firefox which logbook can't access from flatpak for instance)

Hm.... this is one is interesting. Could you please file bug also for this? Flatpak'ed applications can open URLs, but have to do it in the correct way. See: flatpak/xdg-desktop-portal#519.

EDIT: An example: The Website button available in the core opencpn plugin manager interface. This works fine also on flatpak. Which means that possible problems with logbook seems to be bugs which should be fixed.

[filochard]

Hi
I confirm that adding more directories is not so hard but must be known
In my case there's not anything specific to Mageia : it is the fact that I use an external hard disk drive to store my own charts and I need to add this path when starting opencpn :
flatpak run --filesystem=/mnt/Seagate/CD_ISOS/cartes-marines/ org.opencpn.OpenCPN

I already filed a bug about the access to firefox or libreoffice from logbookkonni :
rgleason/LogbookKonni_pi#13 (comment)

<< Some settings are not possible : Inside flatpak we can't give logbookkonni a valid path to firefox or libreoffice or an html editor from the host system because these binaries are outside of the flatpak sandbox
If we want to modify the provided layouts this must be done outside of flatpak
-Because from flatpak we cannot access to firefox (or any html viewer) we can't display the logbookkonni help... >>

The only workaround would be to install a flatpak version of libreoffice, firefox, bluefish beside OpenCPN

[leamas]

@filochard: Let's continue this is in LogBookKonni bug above; we have got off-topic for the original issue here (my bad...)

[leamas]

Filed a new, more focused issue: rgleason/LogbookKonni_pi#30
EDIT: Fixed bad link

[rgleason]

Great idea Alec. Avoid the issue and put it somewhere else. It isn't going to be resolved by Logbook folks.

[leamas]

@rgleason: please read the complete bug description, whole of it and in particular the last line before posting

[leamas]

@filochard: The bug is resolved, sort of. Seems that displaying both LibreOffice document and HTML files using firefox will work after the update to the 20.08 runtime. If/when this is verified it would mean that the only remaining known advantage of the native Mageia plugins is the use of directories outside of $HOME

[filochard]

Hi
No unfortunately there are still remaining bugs in flatpak :
opencpn-radar-pi/radar_pi#169

[leamas]

Yepp, I noticed. I'm on it...

[filochard]

and
rgleason/celestial_navigation_pi#7

[leamas]

That one I might leave for now, doesn't seem like a high-priority one. The important message here is that we should focus on ironing out the flatpak bugs. Doing so, we serve the whole Linux community rather than a specific distro.

BTW: Many thanks for filing these bugs! most useful...

[filochard]

OK
Nevertheless, before everything is corrected in flatpak, and ported to 20.08... it's not so bad to have working rpms or deb in some distributions (the reason why I proposed to add Mageia in the download page)

[rgleason]

watchdog_pi v2.4.31.0 also has a "setpoint" undefined symbol and one other issue under flatpak and ubuntu 18.04. Windows is ok.

[filochard]

the flatpak version of Watchdog doesn't store its xml file in the right place :
there is no
/home/myusername/.var/app/org.opencpn.OpenCPN/config/opencpn/plugins/watchdog directory...

On my computer I have a Mageia rpm version of opencpn which has this path for the user's owned files
/home/myusername/.opencpn/plugins/watchdog/

And the surprise is that the flatpak version of watchdog creates its xml file in
/home/myusername/.opencpn/plugins/watchdog/ which is the directory for the linux installed opencpn

If there is no native version of opencpn on the hosting OS watchdog from flatpak doesn't find where to write and to find its xml file

It's a paradox ! but having both opencpn installed (Mageia and flatpak) allows watchdog from flatpak to work
It's a path problem : flatpak version uses the linux version's path...
(same problem as for logbookkonni it needs GetPrivateApplicationDataLocation somewhere )

[leamas]

This might be the starting point of a another issue. I opened a new, separate bug for this, see above. Can we continue there?

[leamas]

Bug resolved: this problem is fixed in latest version 2.4.31. However, this is yet not published.

[rgleason]

Alec would you mind taking a look at logbookkonni, master branch, I thought I had fixed that but flowchart says it has the same problem.

[leamas]

@rgleason: logbookkonni is such a mess... I looked on it once, and it seems that it's not a simple fix. First step: file a bug against the plugin and put a @leamas in it so I get a heads-up. Probably, I cannot do it in the near future.

[leamas]

@filochard: in reply to #2306 (comment):

and rgleason/celestial_navigation_pi#7

Now fixed in plugin source, just waiting for it to be published.

EDIT: as for radar_pi, there is opencpn-radar-pi/radar_pi#170. We need to wait for that to be merged and published.

[bdbcat]

Closing.
Original issue resolved, Mageia now listed on opencpn.org pages.

[filochard]

Thanks