Hi all I have been using opencpn to navigate using charts that were useable without licence but that become old (a navigation chart needs to be updated frequently !) Some countries (like USA) provide free charts created by national administrations (like NOAA for the USA) and easily downloadable and useable with opencpn But some other countries don't do this way : their national administration (SHOM in France for instance) sell the right to use their charts to private companies... Those companies create encrypted charts and you have to pay a licence or to buy a dungle to use those charts There are two kinds of charts : vectorial charts (same as those you have in a car GPS) raster charts (precise scans of paper charts) Depending of the provider of the charts opencpn needs a plugin to use those non-free charts For vectorial charts : Some years ago Mageia provided the opencpn-s63-plugin https://opencpn.org/OpenCPN/plugins/s63.html code source : https://github.com/bdbcat/s63_pi/ But stopped for a licence reason I don't understand well : this plugin is GPLv2 with a little part BSD and a little part MIT, and is ditributed by Fedora Debian Opensuse Ubuntu https://github.com/bdbcat/s63_pi/blob/master/data/license.txt This plugin allows to use proprietary charts with their own cryptography but is free by itself Same for opencpn-plugin-oesenc that allows to use vectorial chats for which a lower price as been negociated for opencpn users https://opencpn.org/OpenCPN/plugins/oesenc.html code source : https://github.com/bdbcat/oesenc_pi Same for opencpn-plugin-oerenc that allows to use raster charts https://opencpn.org/OpenCPN/plugins/oernc.html code source : https://github.com/bdbcat/oernc_pi (there's an error in the link from the html page) NB Barry Jackson created a script in the SRPM to download the sources for oesenc and s63 and had created a spec file for s63 (still in svn) There's another useful plugin : SAR (which means Search And Rescue) it organises the route to search something or someone that went overboard https://opencpn.org/OpenCPN/plugins/sar.html code source : https://github.com/Rasbats/sar_pi/releases/tag/v2.6.1-non-managed Barjac's script downloaded its source Beside this there's a new radar plugin that may replace the br24 plugin that is now obsolete : https://opencpn.org/OpenCPN/plugins/radarPI.html https://github.com/opencpn-radar-pi/radar_pi I may try to create specs for these plugins but don't know if there's really a license problem for the charts plugins... If Mageia can't provide them, opencpn will be useless to navigate in the whole Mediterranean sea, in Northern Sea, on the Atlantic coast of Spain and France... Out of topic: We have to pay twice for those charts, and it's a pity (once with our taxes that allow to finance a national oceanographic organism which creates the digitalised charts , and a second time when we buy the licence from a private society that got the exclusive right to sell them !) And a third time for paper charts that are obligatory (in case of electric problem on the boat : no more computer nor GPS you can use a bearing compass, a pencil and a Cras navigation ruler or any other plotter on the paper chart ) But no other choice for a safe navigation ! To conclude If those plugin rpms are created, might they be provided as updates or in backports If in updates, opencpn would need to be updated too with new recommends for them And the new radar plugin should obsolete br24 plugin PS : opencpn has now a new way to install plugins (called plugin manager) but it is only useable for Windows Mac or one version of Ubuntu : it fetches some of them directly from a secure cloud : you don't have to install a package manually or to compile it if no package exists Sar for instance is not yet "managed" (the reason of its name)
Thank you for all the detailed information. These plugins (some at least) seem necessary for the package to be useful. Do you know to what extent -if any - they existed in earlier Mageia versions? Since they are additions to an existing package/version, they might be done as normal core/updates - 'required' packages. OTOH If they are all themselves new packages, perhaps Backports might be better; except that does not have an 'update' repository. So if these new pkgs happen, and they need to be updateable - in core? > Some years ago Mageia provided the opencpn-s63-plugin > But stopped for a licence reason I don't understand well : > this plugin is GPLv2 with a little part BSD and a little part MIT, > and is ditributed by Fedora Debian Opensuse Ubuntu These distributions are fussy about licence conditions, so their endorsement should be good for Mageia. This is certainly a request for Barry, so assigning the bug to him.
Assignee: bugsquad => zen25000
Hi Lewis I had some email exchanges with Barry when opencpn was reimoprted into Mageia in the last months of 2015... and he did a huge work to add opencpn-plugins The updates went very fluently tor each upgrade of Mageia thanks to his work.. I used it during november 2019 with Mageia 7 on a little notebook with old Raster Charts... and it worked well with an external GPS (I prefer the use of raster charts that I find more precise and clear) Having a better knowledge of the use of the program, and a better comprehension of packaging I'm already trying to make some SPRMS for all the plugins (including the existing ones : some of them aren't built on the latest stable release but on github and it's not very safe to have a plugin still in development for this kind of software) I will soon attach these drafts with comments
Created attachment 12628 [details] spec file Here is the first plugin The ais-radar plugin that Mageia provided was built with a wrong source file !!! (radar instead of ais-radar...) I built this new version with the right source which works... But I need to manually uninstall the rpm provided by Mageia and to install the mine manually There's a problem to update from my local repo since the version of this corrected rpm is lower than the faulty one Some job for a good packager ! I wrote a bizarre spec file to mention the URL of the source : it's better to get a tagged release than a git clone with the get-plugins script that barjac wrote So that if you need to download the source : uncomment the line11 you will get the address
out of topic It's someway not so easy to maintain the whole stuff (opencpn and plugins) for each linux distribution The opencpn developpers propose to use flatpack ... What do you think of that ? The flatpack version won't need to package each plugin : they will be managed by the plugin manager of opencpn that will download and update them from a secure cloud
Created attachment 12629 [details] spec file for opencpn-climatology-plugin Here is a spec file for the cliamtology plugin This rpm is Ok for updating the previous version Same ugly way to mention the URL of the sources in the spec file (tagged releases better than a git clone ...) One previous patch (for gtk3) is useless now I simply commented it Thanks for a skilled packager who will take care of it
Created attachment 12631 [details] spec file for opencpn-iacfleet-plugin And a new one It works for updating (and after updating) Same ugly spec file with a commented line for the URL of the Source allowing to find the latest tagged release
Created attachment 12633 [details] spec file for opencpn-oernc-plugin Here is the spec file for the oernc plugin allowing to use encrypted raster charts (same for the other spec files there's a ugly commented line to get the URL of the source file) It works and can be added to opencpn
Created attachment 12634 [details] spec file for opencpn-s63-plugin And an other spec file to use navigation charts this one is opencpn-s63-plugin to display vectorial charts It builds and can be installed too
Created attachment 12635 [details] spec file for opencpn-oesenc-plugin and one other plugin to display vectorial charts this one is opencpn-oesenc-plugin It builds .... but there's a little problem which needs some skill from a good packager It can't be installed because a library is missing this library is libsgll-2.29.0.2.so Indeed this library is provided by the source file (3 flavors): when compiling we can find it here BUILD/oesenc_pi-4.0.10/buildlinux/oeserved/libsgll-2.29.0.1.so BUILD/oesenc_pi-4.0.10/buildlinux64/oeserved/libsgll-2.29.0.2.so BUILD/oesenc_pi-4.0.10/buildlinuxarm/oeserved/libsgll-2.30.0.0.so We must copy this file to the BUILDROOT in the right place with a condition %ifarch blabla and then add it in the %files part of the spec file And mention in the spec file that opencpn-oesenc-plugin provides it so that it can be installed I don't know how to do this kind of trick
Created attachment 12636 [details] spec file for opencpn-objsearch-plugin and now spec file for opencpn-objsearch-plugin which allows to easily find something on the vectorial charts (it creates a database with the geographical position of the objects of the charts...) Same ugly spec file with a commented line to get the URL of the source
Created attachment 12637 [details] spec file for opencpn-radar-plugin This is a spec file for the last radar plugin which replaces and obsoletes all the previous radar plugins (it involves now all the radars that were displayed by different plugins) Mageia provided only the BR24radar plugin so it is the only one to obsolete It builds and can be installed and so added to opencpn
Created attachment 12638 [details] spec file for opencpn-route-plugin spec file for opencpn-route-plugin Same kind of spec file as the others : it builds, can be installed and appears in opencpn
Created attachment 12640 [details] spec file for opencpn-sar-plugin And an another spec file to import a new plugin spec file for opencpn-sar-plugin it builds and can be installed and works
Created attachment 12641 [details] spec file for opencpn-watchdog-plugin spec file for opencpn-watchdog-plugin It builds and can update the previous one when installed it works
Created attachment 12642 [details] spec file for opencpn-weather-routing-plugin spec file for opencpn-weather-routing-plugin it builds it updates the previous one and it works
To good willing packagers... (perhaps Barry) Those specs are not perfect but they work as they are They certainly need some cleaning , but I made their sources easy to find (I selected only working tagged releases : it's a serious program that ensures safe navigation ) I already thank whom will have a look on this PS Some other spec files will come later (the adaptation to Mageia is sometimes tricky and the choice of the correct tag needs lots of tests)
Created attachment 12645 [details] spec file for opencpn-weatherfax-plugin spec file for opencpn-weatherfax-plugin It was a little complex because of the name of the tar file the spec is as ugly as the other but it allows to find the URL of the source of the latest release It built fine the update went well and the plugin works inside opencpn I modified a little the patch to adapt it to the new name of the tar file (next attachment to come)
Created attachment 12646 [details] patch to build opencpn-weatherfax-plugin patch to build opencpn-weatherfax-plugin
Hello Philippe I hope you are well. I will need to read all this a few times, however in the meantime please read these: https://bugs.mageia.org/show_bug.cgi?id=18819 https://github.com/OpenCPN/OpenCPN/issues/2075 (second half) I will try to look at this soon but I was intending to try to understand better our policy (if there is one) on flatpack before doing more work on continuing to package the plugins. From the comments in that second bug above it's probably no longer necessary? Barry
Hi Barry Sorry for this late answer (I have been far from my computer for some days) Thanks for having a look to these suggestions... For the link in bugzilla explaining why s63 is not accepted (https://bugs.mageia.org/show_bug.cgi?id=18819) And for the link to your exchanges on github with opencpn developpers In https://bugs.mageia.org/show_bug.cgi?id=28776#c4 I was, me too, thinking about flatpack for Mageia 9 It seems simpler than the use of Cloudsmith (apparently a little more tricky) I saw that you told that you could package oesenc I did too : ( https://bugs.mageia.org/show_bug.cgi?id=28776#c9 ) but the problem is that if we can build and package it, it can't be installed : to be installed it needs one prebuilt library ( libsgll-x.x.x.so) included in the source tarball perhaps non-free : same problem as for s63 For Mageia8 : I didn't use your get-plugins script because it uses github cloning (work in progress) and not the "latest release" tagged source that we can find on each URL for those plugins (besides this some plugins are now developped by new maintainers and the URL of the source has changed) I got some problems with versions of some plugins : (the "latest release" tag is lower that the one mageia provides based on the last github clone) For instance squiddio has 1.3.10.0 version in mageia but the "latest release" is 1.3.8.3 For ais-radar-plugin there's an other problem : the source tar was wrong : instead of "ais-radar" it was "radar" that had been used... The version number of my ais-plugin (v1.2)rpm is lower than the wromg rpm version (1.2.6) and I had to manually uninstall this wrong rpm to install the corrected one To summerize Opencpn misses some necessary plugins : s63 can't be provided because non-free, oensenc needs one prebuilt (non-free ?) library oernc doesn't exist for mageia8 (no licence problem for this one) sar is useful but doesn't exist Could these plugins be provided as updates or only in backports I created a specfile for opencpn adding suggests them but don't know if it may be used
Created attachment 12660 [details] spec file for opencpn new spec file for opencpn including suggests for extra plugins
Hi again I forgot to say that the BuildRequires in all my spec files may be not exhaustive : I have lots of devel packages already installed on the computer which I build packages on
(In reply to Philippe Didier from comment #9) > Created attachment 12635 [details] > spec file for opencpn-oesenc-plugin > > and one other plugin to display vectorial charts > this one is opencpn-oesenc-plugin > It builds .... > but there's a little problem which needs some skill from a good packager > > It can't be installed because a library is missing > this library is libsgll-2.29.0.2.so > > Indeed this library is provided by the source file (3 flavors): > when compiling we can find it here > BUILD/oesenc_pi-4.0.10/buildlinux/oeserved/libsgll-2.29.0.1.so > BUILD/oesenc_pi-4.0.10/buildlinux64/oeserved/libsgll-2.29.0.2.so > BUILD/oesenc_pi-4.0.10/buildlinuxarm/oeserved/libsgll-2.30.0.0.so > > We must copy this file to the BUILDROOT in the right place > with a condition %ifarch blabla > > and then add it in the %files part of the spec file > > And mention in the spec file that opencpn-oesenc-plugin provides it so that > it can be installed > > I don't know how to do this kind of trick Sorry there was a typo about the name of the libs to add : it's libsgllnx and not libsgll... for linux32 and linux64 and it's libsglarmhf32 for arm I think that it's not only that lib that needs to be added in the rpm (it can't be installed because a missing dependancy) but we need to add some other files from the three arch directories (buildlinux buildlinux64 buildlinuxarm) 98-sglock.rules oeserverd They seem to be needed to use the usb dongle that allows to download and uncrypt the charts
(In reply to Philippe Didier from comment #23) > Sorry there was a typo about the name of the libs to add : > it's libsgllnx and not libsgll... for linux32 and linux64 > and it's libsglarmhf32 for arm > > I think that it's not only that lib that needs to be added in the rpm (it > can't be installed because a missing dependancy) > but we need to add some other files from the three arch directories > (buildlinux buildlinux64 buildlinuxarm) > 98-sglock.rules > oeserverd > > They seem to be needed to use the usb dongle that allows to download and > uncrypt the charts Indeed oeserverd is in fact installed in /usr/bin and provided by the rpm the problem is that %cmake_install doesn't install neither /etc/udev/rules.d/98-sglock.rules nor libsgllnx for 64bits or 32bits arches nor libsglarmhf32 for arm arch
Created attachment 12674 [details] spec file for opencpn I modified the spec file of opencpn - 1° to really build and provide the now included chartdldr plugin (I had to remove this line from the previous spec file :" rm -rf plugins/chartdldr_pi " which prevented to build this plugin) - 2° I added 4 Provides : chartdldr dashboard grib and wmm (those 4 plugins are included) But BEFORE updating opencpn we need to uninstall the opencpn-chartdldr-plugin-1.2-12.mga8.rpm I don't know how to do this automatically (I added obsoletes: but this happens after the install ! and this doesn't protect from conflicts preventing the install of opencpn) Perhaps a %pre script would do this ? I added recommends but I commented 2 of them : s63 (licence problem ?) oesenc (the rpm can't yet be installed)
Attachment 12660 is obsolete: 0 => 1
Hi Barry I tried to use Flatpak : first I uninstalled all the rpms of opencpn and plugins (included the last I built) The opencpn version installed by flatpak includes the "plugin manager" : -it downloads the list of the plugins available and you only have to select the ones you want they are automatically downloaded and installed But not all of the plugins "installed" appear on the icons tray and so are not useable (they are not all ready for the new plugin manager ...) But the worst is here : normally we can add the directories where we store our own charts ... my charts are on an other hard drive than the one with my programs When running opencpn from flatpak there's only a very limited tree where to choose the directory containing them: no way to access my charts I tried to create a link in my home directory (flatpak version of opencpn has access to it) but it is useless No access at all to my own charts !!! Flatpak seems to work in its own eggshell (good idea to not pollute the system,but bad idea to access to it) For now it's more secure to use our rpms But the problem of the three plugins that contain a non-opensource part remains (s63, oernc, oesenc ) perhaps they need to be proposed in the non-free repo ?
Hi again Barry I finally found a workaround to use my own charts with opencpn in flatpak!!! To allow to flatpak version of Opencpn the access to some directory there's a little trick To launch opencpn instead of : flatpak run org.opencpn.OpenCPN I used : flatpak run --filesystem=/mnt/Seagate/cartes-marines/ org.opencpn.OpenCPN The scheme is : run --filesystem=/path-to-the-directory-you-want/ name-of-the-app So Flatpak may be a solution to use opencpn inside Mageia and to free you from maintaining it and its plugins... And it resolves the problem of the non-free plugins allowing to use paid charts (s63 oernc and oesenc) that Mageia can't propose
(In reply to Philippe Didier from comment #27) > > So Flatpak may be a solution to use opencpn inside Mageia and to free you > from maintaining it and its plugins... ...and maybe then you will become a packager and maintain it! :) :) > And it resolves the problem of the non-free plugins allowing to use paid > charts (s63 oernc and oesenc) that Mageia can't propose This is what I was hoping for. I am very short of time for packaging, so I am am trying to limit my packages to those that I have a direct interest in. Do we have any policy for the integration of flatpack'd software into Mageia? All I have seen is a package called Discover which has a meaningless description. Also do flatpacks work on SOCs like the RPi? I would imagine that the flatpack overhead may be too big. That may be academic though as I have yet to see a reliable Mageia GUI install on a RPi.
Hi Barry Indeed Mageia provides a flatpak rpm (and it's explained on flatpak site : https://flatpak.org/setup/ https://flatpak.org/setup/Mageia/ Only need to install it (it's quite secure because it doesn't have access to your system) When installed using a console you only have to fetch the list of packages flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo Then you can choose what to install https://flathub.org/home Then install opencpn flatpak install flathub org.opencpn.OpenCPN (first it installs lots of necessary stuff in the user directory because it doesn't use the system stuff !!! and indeed it's quite big) then you launch opencpn : flatpak run org.opencpn.OpenCPN And that's all... There's a plugin manager that download the needed plugins... But it's still Beta I hope it will soon be OK Some issues remains https://github.com/OpenCPN/OpenCPN/issues/2248
PS Flatpak works on raspberry but "it is recommended to use Raspberry Pi OS 64-bit" instead of the 32-bit version of Raspberry Pi OS.
Post PS I am not skilled enough to become an official packager and package maintainer for such a program that concerns (involves) life security on boats ! I build some of them for my own use and test them (that's my responsibility) but need to be overseen (that's what you did) and let a very skilled packager make safe rpms with correct spec files to submit to the BuildSystem
Post post PS I really don't know if it will be useful to provide rpms for Mageia9 ... The philosophy of flatpak seems interesting : preventing to spend lot of time in several distributions (debian, ubuntu, fedora, opensuse mageia etc...) to have the same up to date program The devs of opencpn and of its plugin provide the tar.gz of the last stable source... You only have to download it and update it
for flatpak version of the logbook > Some issues remains > https://github.com/OpenCPN/OpenCPN/issues/2248 https://github.com/rgleason/LogbookKonni_pi/issues/6
I did a little testing of the flatpak version in cauldron. I tried to use the weather fax plugin, but it segfaults on start of capture.
Hi Barry I tried weatherfax too (but I didn't use the capture menu option so I didn't saw the segfault) Besides this it works as intended using internet fax (for the audio you need a VHF radio connected to the computer) I used the NOAA or German weather source and selected an area and the forecast I wanted : the layers are correctly applied on the Atlantic ocean and west coast of the USA for NOAA and Europe for GermanWeather If the fax has been downloaded less than 180 minutes ago weatherfax use this cached fax NB the Flatpak version is still beta (not ready for use... better use our rpms now) I already sent some issues to the plugins devs
(In reply to Philippe Didier from comment #35) > Hi Barry > I tried weatherfax too > (but I didn't use the capture menu option so I didn't saw the segfault) > > Besides this it works as intended > using internet fax (for the audio you need a VHF radio connected to the > computer) I have always tested using HF equipment. > I used the NOAA or German weather source and selected an area and the > forecast I wanted : > the layers are correctly applied on the Atlantic ocean and west coast of the > USA for NOAA and Europe for GermanWeather > > If the fax has been downloaded less than 180 minutes ago weatherfax use this > cached fax I have never tested with internet, in fact I didn't realize it was available on other than HF radio. I guess times move on with satellite links these days. > > NB the Flatpak version is still beta (not ready for use... better use our > rpms now) Yes I was also in Cauldron. > > I already sent some issues to the plugins devs Can you please provide links here to these bug reports.
Hi Barry About weatherfax : I don't own a boat, I only rent sailing ships that have their own chartplotter and autopilot but there's no way to use grib or weatherfaxes on those inboard equipment So I use my own linux laptop (and OpenCpn) with a little GPS connected and tethering with my phone (not connected to a VHF equipment...) This way I can fetch grib files from local providers (https://openskiron.org/en/ for instance) or Weatherfaxes that I apply to my own charts That's the reason why I never used audio faxes but only internet faxes When I test the flatpak version I can't test audio faxes (no VHF connected) but there seems to be a problem with the audio part of flatpacked opencpn itself that may prevent to decode the audio signal and convert it into weather faxes Here are the upstream bugs reports for flatpaked opencpn : https://github.com/OpenCPN/OpenCPN/issues/2248 https://github.com/rgleason/LogbookKonni_pi/issues/6 The devs are very active ...
and another upstream bug for Opencpn itself now https://github.com/OpenCPN/OpenCPN/issues/2254 it's about the way to find oernc-plugin source (even if the rpm can't be in core... it may be useful if we may propose it in non-free unless opencpn is quite useless without being able to use paid official charts )
@ Barry I need some help to create the oernc-plugin rpm for my own use https://bugs.mageia.org/show_bug.cgi?id=28776#c23 It depends on a non-free lib that is provided prebuilt in the source in a way depending on the arch May I include this lib in the oernc-plugin rpm itself mentionning in the spec file that it provides it Or must I create an other libsgl rpm with the same spec file the problem is that the lib to provide depends on the arch I'm not very comfortable with conditional %ifarch %else %endif Thanks if you can help PS in flatpak this lbgsl is packed in /bin besides oeserverd ?!
If it's for your own use then you could simply use ExclusiveArch: x86_64 and remove the other files. Yes I queried the libs being installed to /bin when I packaged oesenc, which was when I realized it was not distributable by Mageia. If you want to build for various arches then: %files %ifarch armv7hl %{_bindir} file_for_armv7hl %endif %ifarch x86_64 %{_bindir} file_for_x86_64 %endif ...etc > Or must I create another libsgl rpm with the same spec file Is that lib used by any other plugins? If so then yes you should libify the spec so it provides a separate lib rpm that can be required by other plugins. Again only for your own use as I don't think there is any way that we could distribute a lib without sources.
Hi Barry Thanks for you help I will build my own rpm . But indeed opencpn will be useless for Mageia users if they can't add charts from countries that don't provide free nautical charts for their coasts (happy american sailors : the NOAA do provide these charts) I hoped the s63 oernc and oesenc rpms might be provided in the nonfree repo (like some micocodes, firmwares, or proprietary drivers) For sure they can't be opensource since they allow to use a dongle or a cryptation key to display paid charts only on the computer they have been bought for (the only way not to have illegal copies) For the land map you can use openstreetmap ... (it's easy to build with simple gps data uploaded from car drivers) for the sea there will never exist openseamap (needs the use of multibeam sounder aboard a ship following a grid pattern : out of reach for simple pleasure boaters) Flatpak will certainly be the only way to use opencpn inside Mageia !!! (it's nevertheless still beta for some plugins but oernc, oesenc et s63 are already useable) and it needs some tricks to give acces to some directories of the host system (already containing some charts for instance)
Hi Barry Some news about the flatpak installation of opencpn... inside Mageia It's still a work in progress, And the team is very active But It has to be entirely rebuilt for the freedesktop SDK 20.8 (it is still stuck on version 18.08 of this SDK... and that creates some display problems) Some plugins aren't ready at all (the radar plugin !! the logbook... ) I wrote some issues and the devs are working on them Some have already been corrected You need a workaround to use your own bsb or kap or mbtiles nautical charts (flatpak has not access to the computer whole file-system) but this is not documented and not available for a newbie Indeed Flatpak opencpn is not yet useable as it is for navigating ! We still need to have rpms for Mageia8 and perhaps Cauldron (as they still exist for Fedora, OpenSuse, Debian, Ubuntu...) But it's useless without charts ! Can oernc oesenc and s63 be provided as non-free rpms (the same way as firmwares or proprietary drivers for nVidia !) ?
(In reply to Philippe Didier from comment #42) > > We still need to have rpms for Mageia8 and perhaps Cauldron (as they still > exist for Fedora, OpenSuse, Debian, Ubuntu...) > But it's useless without charts ! > Can oernc oesenc and s63 be provided as non-free rpms (the same way as > firmwares or proprietary drivers for nVidia !) ? I think your last question is as much for upstream as for Mageia. I asked upstream about s63 years ago and have prodded them several times without any response. https://bugs.mageia.org/show_bug.cgi?id=18819#c4 If you are in contact with someone upstream who could get answers then maybe we could.
Hi Barry I'm gonna contact the dev of s63-plugin and oernc-plugin At least, for the oesenc-plugin we already got the answer in its README file : https://github.com/bdbcat/oesenc_pi#copyright-and-licensing : Copyright and licensing This software is copyright (c) David Register 2020. It is distributed under the terms of the Gnu Public License version 2 or, at your option, any later version. See COPYING.gplv2. The oeserverd binary and libsgllnx64-2.29.02 libraries are closed source. Re-distribution of these items is allowed. NB the whole project and the plugins are GPL It's meaningless without the use of nautical charts The dungle and cryptation to use bought charts are necessarily closed source... but it would be a real nonsense if they were not distributable
Here they are : https://github.com/bdbcat/oernc_pi/issues/5 https://github.com/bdbcat/s63_pi/issues/20
PS The s63-plugin and oernc-plugin are distributed for flatpak fedora opensuse even if they contain a necessary closed source part (these plugins work without any problem : it would have been reported quickly. I installed them with the plugin manager, and activated them)
Never saw so quick answer !!! https://github.com/bdbcat/s63_pi/issues/20 https://github.com/bdbcat/oernc_pi/issues/5 The dev added this line to the README file of these two codes 2. Copyright and licensing 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 sources also contains dependencies distributed under various open-source licenses including Expat, the Curl license, SGI-B, Zlib and Khronos. Refer to the source files for details. Now it's OK for the three plugins : oernc oesenc and s63 They contain closed source binary (necessary to use paid charts ) but are redistribuable.... Now what to do with them ? Should they be in non-free repo ? If yes, Opencpn needs a warning about that ! PS I knocked directly to the dev door, the bug triage on https://opencpn.org/flyspray/ let your report unconfirmed : it didn't prevent the s63-plugin to work... they didn't understand what was the license problem... the dev did immediately !!! Thanks to him
Maybe the place to store the three problematic rpms (core tainted or non-free ?) needs to be discussed with Pascal Terjan now that the license problem is corrected ?
(In reply to Philippe Didier from comment #48) > Maybe the place to store the three problematic rpms (core tainted or > non-free ?) needs to be discussed with Pascal Terjan now that the license > problem is corrected ? Core is for open source only. Nonfree is for closed source. Tainted is for packages using patented software. Patented closed source packages are not allowed. If the open source packages require closed source packages to work properly, then those open source packages along with the closed source packages all go together in the nonfree repositories. If the open source packages, even with limitations without the closed source packages then the open source packages go in core while the closed source ones go in nonfree.
CC: (none) => davidwhodgins
Thanks Dave for your quick and clear answer Indeed there are only three plugins rpms that will have to go in non-free repo It's better that the main OpenCpn rpm and all the other plugins remain in core so that anyone may find them (there are some shores and some countries where the nautical charts are freely downloadable) We will have to find a way to inform the user that he needs to enable the non-free repo where he may find the three plugins necessary to use encrypted nautical charts that he needs to buy, when he navigates near European countries :-(.
(In reply to Philippe Didier from comment #50) > We will have to find a way to inform the user that he needs to enable the > non-free repo where he may find the three plugins necessary to use encrypted > nautical charts that he needs to buy, when he navigates near European > countries :-(. Use a README.urpmi file in the main core package.
Created attachment 12720 [details] a proposal of README.urpmi for opencpn Here is a proposal of README.urpmi for opencpn, now that the distribution of the three problematic plugins is clearer (oesenc oernc and s63 which contain a closed source part but are freely distributable) By the way I propose that if this README.urpmi is right, we may close this too long bug And that I open a bug for each rpm (one for opencpn itself and one for each plugin) Or one new bug for all the rpms but cleaned from the multiple comments that are useless now
my two cents : I think that one new bug report for all the rpms would be better because there's one maintainer for all of them
Comment on attachment 12720 [details] a proposal of README.urpmi for opencpn Suggested changes ... OpenCPN and most of its plugins are open source, available in the Core repositories. OpenCPN may be used navigate in the parts of the world where nautical charts are freely available for download from the local oceanic administration (NOAA in USA, for instance). In some areas encrypted nautical charts and their licenses must be purchased from the local Hydrographic Offices. Closed source plugins allowing the storage and use of the appropriate encryption certificate, and the use of a USB dongle provided by the distributor are available in the nonfree repository. The nonfree packages to install are ... opencpn-oernc-plugin (for raster charts purchased from o-charts.org) opencpn-oesenc-plugin (for vector charts purchased from o-charts.org) opencpn-s63-plugin (for vector charts purchased from S-63 charts distributors)
Ask in the dev ml. I think the main opencpn package can use suggests (not requires) for the nonfree packages. If that's correct, then the README.urpmi won't be needed. The packages would be installed if the nonfree repos are enabled, and no errors would be generated if the nonfree repos have been disabled.
(In reply to Philippe Didier from comment #53) > my two cents : > I think that one new bug report for all the rpms would be better because > there's one maintainer for all of them One bug report for all of them is fine.
Created attachment 12721 [details] modified README.urpmi file Thanks Dave I modified this file following your advice (it's clearer) (English is not my language, and I'm not so familiar to packaging ... In the spec file for opencpn I used recommends for the plugins if suggests is better I will use it for the plugins from the nonfree repo Nevertheless I think it's better to inform the user that he have to enable the nonfree repo in rpmdrake for these plugins : some users don't enable this repo, wanting to use strictly opensource... but they must be warned to allow an exception if they want to navigate near the European coasts for instance
Attachment 12720 is obsolete: 0 => 1
Attachment 12721 mime type: application/x-urpmi => text/plain
That looks fine except for having two blank lines where only one should be used.
Created attachment 12722 [details] corrected README.urpmi file Thanks README.urpmi file corrected (one blank line suppressed Next step : I'm gonna write a new spec file for opencpn : Suggests instead of recommends for the 3 nonfree plugins add the README.urpmi It certainly will have to be corrected...
Attachment 12721 is obsolete: 0 => 1
I'm not sure what the difference is between suggests and recommends, so it would be best to ask in the dev ml.
If I'm reading https://rpm.org/user_doc/dependencies.html correctly, in this case recommends would be correct.
Hi Dave I tried to add a README.urpmi file following the Mageia wiki : Interaction with urpmi and rpmdrake Sometimes it is necessary to warn the user about some particular care that should be taken when upgrading or installing a specific version of a package. The following file name formats can be used: README.install.urpmi: displayed when the package is initially installed README.version.upgrade.urpmi and README.version.update.urpmi: displayed when the package is updated to version version or above, from a version that is less than version (version should be either a package version, epoch:version, version-release, or epoch:version-release, the shorter the better) Also supported are README.urpmi (displayed in all cases) and README.upgrade.urpmi/README.update.urpmi (always displayed when upgrading). These shouldn't be used as they cause the message to be shown in every subsequent update, even if the user has already seen the message many times. HOW TO DO (example with README.install.urpmi): put a README.install.urpmi in the SOURCES/ directory add it in the spec as SourceX: README.install.urpmi (replace X with an appropriate number) in %install section : install -m644 %{SOURCEX} README.install.urpmi (notice the absence of %buildroot prefix here) in %files section, add README.install.urpmi in a %doc macro, or add a %doc macro if there is none So I added the Source3: README.urpmi in the spec file: and one line in its %install part : %install %cmake_install install -m644 {Source3} README.urpmi But I get this message in the console at the end of the run of rpmbuild when it execute the %install (after having built everything) + install -m644 '{Source3}' README.urpmi install: cannot stat '{Source3}': No such file or directory I don't know what's wrong
missing % before {Source3}
Thanks Thomas for your quick answer But nothing changes with : install -m644 %{Source3} README.urpmi ending this way : + install -m644 '%{Source3}' README.urpmi install: cannot stat '%{Source3} README.urpmi': No such file or directory nor with : install -m644 %{Source3}: README.urpmi ending this way : + install -m644 '%{Source3}:' README.urpmi install: cannot stat '%{Source3}:': No such file or directory nor with : install -m644 %{Source3} ending this way : + install -m644 '%{Source3}' install: missing destination file operand after '%{Source3}' NB each time I had added in %files section %{_docdir}/README.urpmi But indeed the problem can't stay here : it appears before the rpm is written in the install section PS The Wiki doesn't mention to indicate a destination file operand
> > NB each time I had added in %files section > %{_docdir}/README.urpmi > But indeed the problem can't stay here : it appears before the rpm is > written in the install section > > PS The Wiki doesn't mention to indicate a destination file operand Sorry it was not clearly said I meant the problem doesn't stay in the %files section of the sepc file When rpmbuild is running, the problem appears before the rpms are written It's only caused by something wrong in the %install section Referring to the wiki it's said that we don't have to mention %{buildroot} (or anything else) as a target directory ... simply give a file name Where is the mistake ?
funny typo :-) I wanted to write spec file and not "sepc file " (that looks like sepsis... for a sick spec file)
I think we may close this too long bug report I've created a shorter bug report https://bugs.mageia.org/show_bug.cgi?id=28975 I let the bugsquad decide
What an enormous amount of work you have done.. Following your suggestion, closing this older bug as a duplicate of your new one. *** This bug has been marked as a duplicate of bug 28975 ***
Resolution: (none) => DUPLICATEStatus: NEW => RESOLVEDCC: (none) => lewyssmith