This bug report replaces the https://bugs.mageia.org/show_bug.cgi?id=28776 which became too long (out of topic comments and explanations) even if it allowed to clarify some problems It will only contain the spec files proposed to correct some errors, and the spec files for missing plugins
Created attachment 12725 [details] spec file for opencpn An enhanced spec file for opencpn : - modify description - add udev rule for the chart decrypt dongle eventually used - add suggests for plugins allowing chart decryption - add warning to inform that these decryption plugins are in nonfree repo NB line 106 and 137 are commented following the wiki and even with the help of Thomas Backlund I couldn't add a README.urpmi https://bugs.mageia.org/show_bug.cgi?id=28776#c62 https://bugs.mageia.org/show_bug.cgi?id=28776#c63 https://bugs.mageia.org/show_bug.cgi?id=28776#c64 https://bugs.mageia.org/show_bug.cgi?id=28776#c65 That remains TODO by a skilled packager I will add the patches and text files in next comments
Created attachment 12726 [details] patch to build opencpn 1st patch
Created attachment 12727 [details] 2nd patch to build opencpn 2nd patch to build opencpn
Created attachment 12728 [details] opencpn-5.0.0-mga-missing_glx_include.patch 1st patch with its name
Attachment 12726 is obsolete: 0 => 1
Created attachment 12729 [details] opencpn-5.0.2-mga-cmaklists.txt_wkgtk_version.patch 2nd patch for opencpn with its name
Attachment 12727 is obsolete: 0 => 1
Created attachment 12730 [details] opencpn-5.2.4-mga-cmakelists.txt_wxgtk_test.patch 3rd patch to build opencpn
Created attachment 12731 [details] README_packaging.txt Warning for opencpn packagers
Created attachment 12732 [details] README.urpmi README.urpmi file to add in the %install part of the spec file That remains TODO
Created attachment 12733 [details] spec file for opencpn-ais-radar-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 (v1.2-1) is lower than the faulty one (1.2.6.0-2) I tried to obsoletes the previous but that doesn't work 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 This way if you need to download the source : uncomment the line11 you will get the address
Created attachment 12734 [details] spec file for opencpn-climatology-plugin spec file for he climatology plugin it allows to update from the previous version i will attach the needed patch
Created attachment 12735 [details] climatology_pi-1.4.1-add-missing-gl-include.patch patch to build the climatology plugin
Created attachment 12736 [details] spec file for opencpn-iacfleet-plugin spec file for opencpn-iacfleet-plugin it works to update from the previous version
Created attachment 12737 [details] spec file for opencpn-objsearch-plugin spec file for opencpn-objsearch-plugin cosmetic change for the url of the source file
Created attachment 12738 [details] spec file for opencpn-radar-plugin 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 No problem with the fact that previously its source was erroneously used for the AIS-radar-plugin...
Created attachment 12739 [details] spec file for opencpn-route-plugin spec file for opencpn-route-plugin a new rpm allowing to plot circle routes Perhaps to add in backports repo for Mageia8 And in Core repo for Cauldron
Created attachment 12740 [details] spec file for opencpn-sar-plugin spec file for opencpn-sar-plugin A new rpm to add to Mageia8 backport repo and to Cauldron Core repo It's a safety plugin (Search And Rescue) creating a route pattern to search a Man or Object Over Board
Created attachment 12741 [details] spec file for opencpn-watchdog-plugin spec file for opencpn-watchdog-plugin allows to update the rpm May be in Mageia8 updates repo
Created attachment 12742 [details] spec file for opencpn-weather-routing-plugin spec file for opencpn-weather-routing-plugin allowing to update the installed rpm May be proposed in Mageia8 updates repo
Created attachment 12743 [details] spec file for opencpn-weatherfax-plugin spec file for opencpn-weatherfax-plugin allows to update from the present rpm may be provided in Mageia8 updates repo needs a patch
Created attachment 12744 [details] weatherfax_pi-system-audiofile.patch patch to build weatherfax
Created attachment 12745 [details] spec file for opencpn-s63-plugin spec file for opencpn-s63-plugin This plugin allows to display encrypted nautical charts bought from a charts distributor It contains a closed source binary but is freely distributable It may and must be in the non-free repo
Created attachment 12746 [details] spec file for opencpn-oernc-plugin spec file for opencpn-oernc-plugin A new rpm plugin allowing to use encrypted raster charts bought from charts distributors It contains a closed source binary but may be freely distributable It may and must be in the non-free repo
Created attachment 12747 [details] draft of a spec file for opencpn-oesenc-plugin draft of a spec file for opencpn-oesenc-plugin This plugin allows to display encrypted vector charts bought from distributors It contains closed source binary and lib that are freely distributable It may and must be in the non-free repo NB it's a draft ! It's a little complex to write since there are different versions of the binaries depending on the arch It needs to be corrected by a skilled packager
Created attachment 12748 [details] spec file for logbookkonni plugin spec file for logbookkonni plugin It's a very useful plugin : the logbook automatically gets data from the nmea-connected modules (GPS, anemometer etc...) The description has been modified to explain where to find the Layouts.zip file required by the plugin to work after installation (the dev are working to automatize this step but it seems to be tricky to modify the code)
PS The Flatpack version of opencpn is not ready for use (even if it seems interesting due to the fact that it proposes a "plugin manager" freeing from the need of packaging each plugin by downloading ready to use tar.gz files from a secure cloud) : 1) There are still some bugs to correct for the flatpack plugins 2) Running opencpn inside the flatpack sandbox needs workaround to access to the charts in the computer file system 3) Running opencpn inside the flatpack sandbox prevents the use of the programs installed in the hosting system such as LibreOffice or Firefox (to view or print the logbook for instance) Perhaps the future will be to allow the mageia version of opencpn to use the "plugin manager" but that needs lots of work on the opencpn github for each plugin : I) Set up CI build chains which build the plugins for Mageia, one for each plugin/platform/arch combination II) The CI build chains also produces an xml metadata file, one for each plugin build. Metadata is similar to packaging metadata but also includes an URL where the plugin build is available III) Store the built artifacts on a public server (usually cloudsmith.io) IV) Make a PR against the github.com/OpenCPN/plugins with the metadata included. When accepted, this makes the Mageia plugins visible in the plugin manager GUI.
> 2) Running opencpn inside the flatpack sandbox needs workaround to access to > the charts in the computer file system > I meant 2) Running opencpn inside the flatpack sandbox needs a workaround to access to the already installed charts in the computer file system
*** Bug 28776 has been marked as a duplicate of this bug. ***
It is essential to peruse quickly bug 28776 to give the background to this one, which effectively replaces it. It looks as if 'opencpn' will soon have to be Flatpacked only, but that is not yet up to scratch; and has functional disadvantages. I take it that all the spec file contained herein are to enable the various plugins involved to be offered as Mageia packages. Philippe, you said in the previous bug that you are not up to becoming a packager - if only for this application. https://wiki.mageia.org/en/Becoming_a_Mageia_Packager The huge amount of work that you have put into this shows the contrary. Any new packager *is* supervised. Hopefully Barry would mentor you. In the meantime, assigning this bug to Barry.
Assignee: bugsquad => zen25000
Hi Philippe, You did a lot of work on this! I finally managed to start looking at this monster! In the spec for the main package, 'Suggests' are gone and are now 'Recommends'. Since this package provides opencpn-chartdldr-plugin then it needs to Obsolete the old separate package. Obsoletes: opencpn-chartdldr-plugin < 1.2-13 (just add 1 and use <) You can use %{buildroot}%{_udevrulesdir} and we don't own %{_udevrulesdir} so miss out the %dir line and just use %{_udevrulesdir}/* in the %files section. I will see how that builds tomorrow for cauldron and check out the new plugins etc. as I get chance. @Lewis I have tried to get Philippe to become a packager and was mentoring him about 5 years ago but it never happened. :(
Hi Barry I indeed was trying to become a packager some years ago, but some events made me busy elsewhere away from this project... I have now more time free for this The work I did for these spec files is someway a new start but you can see I'm far from being skilled and that some of these spec files need to be corrected, and that some are too complex for me... Besides this I am interested by the project of the opencpn devs to port opencpn to flatpak (that would free the linux distributions to package each plugin) And the Plugin Manager of the last OpenCPN will allow to download from a secure cloud the plugin you choose in a catalog. I test it : the well working Mageia packages are a good basis to compare and find the flatpak bugs !!! :) Lots of issues : some have been corrected, some not yet Flatpak version of OpenCPN is still a work in progress... and Mageia Packages are really more useable and safe for the moment. So we still need to update the Mageia rpms...
Hi Philippe, I have now built and installed opencpn main package using --no-recommends and it looks OK. I fixed the README.urpmi which now works, also changed it to use the system jasper rather than the bundled one and fixed some file ownership issues - old errors of mine maybe. ;) Note also that %description lines must be no longer than 80 characters. I have started to look at ais-radar and fixed a few minor things. It can't obsolete itself so we have two options: 1. Change it's name, maybe ocpn-ais-radar-plugin or opencpn-aisradar-plugin OR opencpn-AIS-radar-plugin which could then obsolete the original. Capital letters are not normally allowed except in special circumstances (which we have here I guess). 2. Use epoch: which would then allow the drop in version. However that is usually left as a last resort. Bed - more anon.
Created attachment 12775 [details] opencpn.spec Latest updated version.
Hi Barry Thanks to correct and improve what I tried to do About opencpn I have downgraded the rpms of opencpn and its plugins from the ones I had built to the ones that are in the core repo Then I built the opencpn rpm with your spec file and installed it as an update It's OK : - it uninstalls the chartdldr-plugin - the warning explaining where to find the three partly closed-source appears after it has been installed (it is not well explained in the wiki how to install this README.urpmi) - the udev rule is in the right place (it will be useful for the non-free plugins allowing to use encrypted charts...) NB I didn't use --no-recommends and it's OK too : if a recommended package is not present in the repo that doesn't prevent to install (or update) the main opencpn rpm About the opencpn-ais-radar-plugin I think you found a part of the answer by renaming it opencpn-aisradar-plugin that my obsolete the previous... but this won't work as an update of the wrongly sourced rpm That needs too to modify the recommend from opencpn-ais-radar-plugin to opencpn-aisradar-plugin in the spec of opencpn itself Besides this the radar-plugin might obsolete the wrong opencpn-ais-radar-plugin, and recommend opencpn-aisradar-plugin but this new rpm would be provided in backports repo only I don't know anything about epoch but if it allows to keep the same name and to obsolete the wrong-sourced rpm it will be more simple to propose it as a simple update without having to modify the opencpn spec file
Post Scriptum I think that the new opencpn must not only obsolete opencpn-chartdldr-plugin, but conflicts with it ... For instance, in the CCM when you look for packages with the word opencpn you will find that opencpn-chartdldr-plugin is not installed if you try to reinstall it you may have some problem with the lib provided by it and the opencpn main rpm
(In reply to Barry Jackson from comment #31) > I have started to look at ais-radar and fixed a few minor things. > > It can't obsolete itself so we have two options: Why do you want it to obsolete itself ? and technically a new version always obsoletes the older version so what are you trying to solve ? if there is a "version downgrade" you want/have to do in an update, you simply add: Epoch: 1 to the spec (usually near the version row to not forget its using epoch) and it will keep working on updates.
Hi Thomas Thanks for overseeing what we try to do And thanks for your advice and your helpful wide knowledge I thought there was an aporia since the corrected version of the rpm had a lower version number than the rpm it updates (if we respect the source version numbering): https://bugs.mageia.org/show_bug.cgi?id=28975#c9 It's very far from my capability ... (the reason why I can't be a packager and only may propose changes to a skilled packager such as Barry) Indeed Barry already thought about epoch as a last solution, thanks to confirm it's the best one
then something like this against spec in comment 9: (dont stick "v" in version, keep it numerical" --- opencpn-ais-radar-plugin.spec.old 2021-06-16 19:04:41.688960219 +0300 +++ opencpn-ais-radar-plugin.spec 2021-06-16 19:04:17.068805707 +0300 @@ -3,13 +3,13 @@ Name: opencpn-ais-radar-plugin Summary: AIS radar view plugin for OpenCpn -Version: v1.2 +Epoch: 1 +Version: 1.2 Release: %mkrel 1 License: GPLv2 Group: Geography URL: https://opencpn.org/OpenCPN/plugins/aisradarview.html -#Source0: https://github.com/Verezano/%{uname}/archive/refs/tags/%{piname}%{version}.tar.gz -Source0: %{uname}-%{piname}%{version}.tar.gz +Source0: https://github.com/Verezano/%{uname}/archive/refs/tags/%{piname}v%{version}.tar.gz BuildRequires: cmake @@ -24,7 +24,6 @@ Requires: opencpn Provides: %{piname} = %{version} -Obsoletes: opencpn-ais-radar-plugin = 1.2.6.0-2 %description AIS RADAR is a plugin that allows you to display AIS targets in the way ships are displayed on a radar screen. @@ -32,7 +31,7 @@ North up, course up displays. Includes the "Anchor" branch from TransmitterDan, which shows a black ball on all AIS Class A vessels that are anchored or moored. %prep -%setup -n %{uname}-%{piname}%{version} +%setup -n %{uname}-%{piname}v%{version}
Hi Thomas, Thanks for confirming that Epoch would be the way to go. Philippe, I have spent all this evening trying to understand the issue you have with the current version of opencpn-ais-radar-plugin that is in both Mageia 8 and Cauldron. It is version 1.2.6.0. You say this is from the wrong upstream sources, but the CMakeLists.txt in the sources we are using says: -------------snip------------- # define plugin name, owner and versions set(VERBOSE_NAME "AISradar") set(COMMON_NAME "AIS Radar view") set(TITLE_NAME "AISradar") set(PACKAGE_CONTACT "Johan Sman") set(PACKAGE "aisradar") set(SHORT_DESCRIPTION "AIS Radar view Plugin") set(LONG_DESCRIPTION "Radar PlugIn for OpenCPN Shows AIS targets in a radar style view.") set(VERSION_MAJOR "1") set(VERSION_MINOR "2") set(VERSION_PATCH "6") set(VERSION_TWEAK "0") set(VERSION_DATE "2020-10-08") set(OCPN_MIN_VERSION "ov50") set(OCPN_API_VERSION_MAJOR "1") set(OCPN_API_VERSION_MINOR "16") set(TP_COMMENT " * Release for O5 using CI") set(PARENT "opencpn") --------------snip---------------- The above is where my script gets the version from: "major.minor.patch.tweak". It also says: set(SHORT_DESCRIPTION "AIS Radar view Plugin") The CMakLists.txt in the source for 1.2 that you want to use seems to just be older: -----------snip---------- PROJECT(aisradar_pi) SET(CMAKE_MACOSX_RPATH "ON") SET(PACKAGE_NAME aisradar_pi) SET(VERBOSE_NAME AISRadar) SET(TITLE_NAME AISRadar) SET(CPACK_PACKAGE_CONTACT "Johan Sman") SET(VERSION_MAJOR "1") SET(VERSION_MINOR "2") SET(VERSION_PATCH "1") SET(VERSION_DATE "2020-07-12") SET(OCPN_VERSION "ov42") #SET(CMAKE_BUILD_TYPE Debug) INCLUDE("cmake/PluginConfigure.cmake") -----------snip--------- SET(TITLE_NAME AISRadar) is the same in both, as is the upstream contact. What am I missing? Cheers, Barry
Created attachment 12776 [details] flatpack opencpn with ais plugin With the flatpak install of opencpn and using the in-app catalogue to install the ais plugin, the version is the same as our rpm. rpm -qa|grep opencpn ...returns nothing. All media is disabled on this Mga8 machine.
Hi Barry Sorry for the confusion Indeed there is no problem with your AIS-radar-plugin... I have been disturbed by the beginning of your spec file !!! %define piname aisradar_pi 2 %define uname radar_pi 3 4 Name: opencpn-ais-radar-plugin 5 Summary: AIS radar view plugin for OpenCpn 6 Version: 1.2.6.0 7 Release: %mkrel 2 8 License: GPLv2 9 Group: Geography 10 URL: https://github.com/Verezano/%{uname} 11 # See opencpn spec for obtaining the versioned tarball. 12 Source0: %{uname}-%{version}.tar.gz here is the beginning of mine (I have updated each plugin to the last tagged release, so I rewrote the URL of the source for each of them) : %define piname aisradar_pi %define uname AISradar_pi Name: opencpn-ais-radar-plugin Summary: AIS radar view plugin for OpenCpn Version: v1.2 Release: %mkrel 1 License: GPLv2 Group: Geography URL: https://opencpn.org/OpenCPN/plugins/aisradarview.html #Source0: https://github.com/Verezano/%{uname}/archive/refs/tags/%{piname}%{version}.tar.gz Source0: %{uname}-%{piname}%{version}.tar.gz As you can see the uname of your source0 is radar_pi, and not AISradar-pi That's the reason why I thought there was a mistake (besides this I was preparing the spec file for the radar-plugin to import whose the uname is radar_pi !!!) But in fact the source you provided to the build system seems to be the good one Your plugin is really the aisradar-plugin and not the radar_plugin !!! Sorry for the noise nothing to change nor epoch nor anything else you may let this rpm as it is
PS As you may see in the spec files that I propose : I didn't use your get-plugins script to "git-clone" the sources As much as I could, I have prefered to use the last tagged release source better than a work in progress in github (that's too the reason why for AIS-radar I used the last tagged release : v1.2 better than the git clone : the last modifications in github are only being done to allow the use of the plugin manager and create tarballs for cloudsmith... useless for building rpms) NB Since you created the get-plugins script the URL of the sources have been modified (the developer in charge of some of them has changed... but it's not yet updated in the download page of opencpn)
On 17/06/2021 12:15, Philippe Didier wrote: > https://bugs.mageia.org/show_bug.cgi?id=28975 > > --- Comment #41 from Philippe Didier <philippedidier@laposte.net> --- > PS > As you may see in the spec files that I propose : > I didn't use your get-plugins script to "git-clone" the sources > As much as I could, I have prefered to use the last tagged release source > better than a work in progress in github But it's hardly a WIP if it has been the same since last summer. > (that's too the reason why for AIS-radar I used the last tagged release : v1.2 ...which is even older > better than the git clone : the last modifications in github are only being > done to allow the use of the plugin manager and create tarballs for > cloudsmith... useless for building rpms) I have no idea about their changes, but they are no reason to not use them. > NB > Since you created the get-plugins script the URL of the sources have been > modified Yes I noticed some changes, I will update it where needed. > (the developer in charge of some of them has changed... but it's not yet > updated in the download page of opencpn) > If git snapshots are stable enough for upstream to use for their catalogue downloads, then I see no reason for us not to use them as well. If we don't we will probably have to add Epoch to all the plugins and be months out of date on some packages at next release. We should be in step with the versions they are supplying directly or it will simply appear that we are out of date and not offering current packages, and also possibly miss critical fixes. Maybe upstream should be encouraged to issue tarball releases that match version for version with what they offer in the in-app catalogue? Unless they do this I really think we are better as we are for now at least.
(In reply to Barry Jackson from comment #42) > > If git snapshots are stable enough for upstream to use for their catalogue > downloads, then I see no reason for us not to use them as well. > that's not really the way it works On github, after a new release of the plugin is validated , it is tagged as latest and you can directly download this tagged tarball from github (without having to clone) besides this several tarballs are built for the "Plugin Manager" (one for each architecture of flatpak, ubuntu, etc...) and are then added into the cloud and into the catalogue for the Plugin Manager After this is done, developpers may add new commits and snapshots are regularly used to upload to the cloud alpha or beta tar.gz to be tested : these tarballs don't appear in the catalogue and are not tagged as new release and may be buggy... Look at the way the cloud is organized : https://cloudsmith.io/~opencpn/repos/ And just take a look at this : https://github.com/rgleason/AISradar_pi/network You will see that depending on the moment you clone the git you may download a buggy intermediate version
It seems that Rick Gleason's github is where plugin releases are now being maintained. He has ais-radar-1.2.7.0 and most updates are recent. Thanks for drawing my attention to him. I appreciate that random snapshots can be unreliable but when there is little activity and previous full releases are ancient there is sometimes no alternative. Also when projects fork in all directions it's not easy to decide which to follow. Maybe you could update a few plugin specs to test using releases from his github? I will work from A-Z and maybe you could try Z-A and see how it goes, so we don't duplicate?
Indeed Rick Gleason, Alec Leamas and bdbcat are the most active and reactive nowadays on the project Good idea to start from Z to A for me I will start with weather-routing I use this tagged release : https://github.com/rgleason/weather_routing_pi/archive/refs/tags/v1.13.22.0.tar.gz It has corrected some problems with svg icons It builds well and updates smoothly the previous rpm I will add the spec file
Created attachment 12778 [details] spec file for opencpn-weather-routing-plugin spec file for opencpn-weather-routing-plugin last version : 1.13.22.0
Attachment 12742 is obsolete: 0 => 1
What is the status on getting confirmation from upstream about distribution of the 'nonfree' plugins? Do we have anything we can add to the packages to link to an upstream confirmation of this? My request fell on deaf ears. I have locally fixed oesenc and ais-radar plugins now and will initially push to cauldron. In order to sync directly from Rick's github in the specs you can use this format: Source0: https://github.com/rgleason/%{uname}/archive/v%{version}/%{piname}-%{version}.tar.gz
Comment on attachment 12778 [details] spec file for opencpn-weather-routing-plugin Don't use %setup use %autosetup -p1 -n ..... Try to use new cmake macros that don't need -C build etc: %cmake_build %cmake_install remove changelogs Not sure whether we really need the Provides: ?
and now weatherfax I use this tagged release https://github.com/rgleason/weatherfax_pi/archive/refs/tags/v1.9.16.0.tar.gz The spec has been simplified (no more patch needed) no sed line needed It corrects some URLs for internet fax providers
%description line over 80 chars and mixed use of spaces and tabs. Use rpmlint on the src.rpm to check for things like that. :) Adding a blank line between paragraphs will make them appear in rpmdrake as distinct paragraphs. If you don't do that they will all run together. https://bugs.mageia.org/show_bug.cgi?id=27274#c15 The mixed use error was because you had a double space between two words in the description line that was too long. Builds fine now for cauldron. Thanks, I will try to work down from the top over the weekend if I get chance ;)
(In reply to Barry Jackson from comment #47) > What is the status on getting confirmation from upstream about distribution > of the 'nonfree' plugins? > Do we have anything we can add to the packages to link to an upstream > confirmation of this? My request fell on deaf ears. It is clear now since the copyright and licensing part of the sources has been rewritten by the dev https://bugs.mageia.org/show_bug.cgi?id=28776#c44 https://bugs.mageia.org/show_bug.cgi?id=28776#c45 https://bugs.mageia.org/show_bug.cgi?id=28776#c47 oesenc oernc and s63 may and can be now proposed in the Mageia's non free repo > > I have locally fixed oesenc and ais-radar plugins now and will initially > push to cauldron. > > In order to sync directly from Rick's github in the specs you can use this > format: > > Source0: > https://github.com/rgleason/%{uname}/archive/v%{version}/%{piname}- > %{version}.tar.gz
(In reply to Philippe Didier from comment #49) > and now weatherfax > I use this tagged release > https://github.com/rgleason/weatherfax_pi/archive/refs/tags/v1.9.16.0.tar.gz > > The spec has been simplified (no more patch needed) no sed line needed > > It corrects some URLs for internet fax providers Sounds good! Check your Source0: lines with wget to be sure they will sync from the spec. (obviously replace the %{piname} and %{version} manually. Generally from Rick's repo they should all be the same: https://github.com/rgleason/%{piname}/archive/v%{version}/%{piname}-%{version}.tar.gz Cheers and have a good weekend!
Created attachment 12779 [details] spec file for opencpn-weatherfax version 1.9.16.0 spec file for weatherfax plugin 1.9.16.0 no more patch needed no sed line needed It corrects some URLs of internet providers of weather faxes It builds and update correctly
Attachment 12743 is obsolete: 0 => 1
Created attachment 12780 [details] specfile for weatherfax plugin spec file for weatherfax correcting a typo in the url of the source I let the url of the source greyed the v in the version creates some problems when I use the url as Source0
Attachment 12779 is obsolete: 0 => 1
Created attachment 12781 [details] cleaner spec file for weatherfax plugin
Attachment 12780 is obsolete: 0 => 1
Created attachment 12782 [details] short spec file for weather-routing-plugin spec file for weather routing plugin I tried with %cmake_build instead of %make -C build but it didn't work (perhaps a typo anywhere
Attachment 12778 is obsolete: 0 => 1
Created attachment 12783 [details] Correction diff to weather routing Apply this patch to your spec and try it.
Created attachment 12784 [details] corrected spec file for opencpn-weather-routing-plugin last and not least spec file for weather-routing-plugin corrected shortened and working
Attachment 12782 is obsolete: 0 => 1
Created attachment 12785 [details] corrected spec file for opencpn-weatherfax last spec file for weatherfax-plugin corrected shortened working
Attachment 12781 is obsolete: 0 => 1
Created attachment 12786 [details] spec file for the wtachdog-plugin spec file for the watchdog-plugin corrected shortened working
Attachment 12741 is obsolete: 0 => 1
sorry for the typo it's watchdog-plugin
Created attachment 12787 [details] specfile for the sar-plugin corrected and shortened spec file for the opencpn-sar-plugin It's a new rpm ! It's useful for security : SAR means Search And Rescue The source is called non managed because it has not be modified to be installed by the "Plugin Manager" from the last version of opencpn The more recent sources have the same basis but include the stuff necessary to build tarballs for the cloud from where the Plugin Manager download them
Attachment 12740 is obsolete: 0 => 1
Barry no need to rebuild opencpn-statusbar-plugin opencpn-squiddio-plugin they are up to date
Created attachment 12788 [details] spec file for opencpn-weatherfax version 1.9.16.0 spec file for opencpn-weatherfax version 1.9.16.0 (Source0 URL corrected)
Attachment 12785 is obsolete: 0 => 1
Created attachment 12789 [details] spec file for opencpn-weather-routing-plugin version 1.13.22.0 corrected spec file for opencpn-weather-routing-plugin version 1.13.22.0 Source0 URL corrected
Attachment 12784 is obsolete: 0 => 1
Created attachment 12790 [details] spec file for opencpn-watchdog-plugin 2.4.30.2 corrected spec file for opencpn-watchdog-plugin 2.4.30.2 Source0 URL corrected
Attachment 12786 is obsolete: 0 => 1
Created attachment 12791 [details] spec file for opencpn-sar-plugin version 2.6.1 corrected spec file for opencpn-sar-plugin version 2.6.1 Source0 URL corrected
Attachment 12787 is obsolete: 0 => 1
Created attachment 12792 [details] spec file for opencpn-route-plugin version 1.2 spec file for opencpn-route-plugin version 1.2 Source0 URL corrected
Attachment 12739 is obsolete: 0 => 1
Created attachment 12793 [details] spec file for opencpn-radar-plugin version 5.0.4 spec file for opencpn-radar-plugin version 5.0.4 corrected shortened Source0 URL corrected @ Barry I couldn't build more recent versions 5.1.2 5.1.4 5.2.0 strange errors...
Attachment 12738 is obsolete: 0 => 1
@ Barry I let you rewrite the spec files for s63 oernc oesenc These rpms are only for the non-free repo I will upload drafts for their spec files
Created attachment 12794 [details] draft of the spec file for opencpn-s63-plugin
Attachment 12745 is obsolete: 0 => 1
Created attachment 12795 [details] draft of a spec file for opencpn-oesenc-plugin draft of a spec file for opencpn-oesenc-plugin NB It's a rpm that must be built only for the non-free repo There are 4 versions of the closed source binary and of the closed source library depending on the arch The licensing part of the source has been clarified but you need to git clone the code and not use the tagged version
Attachment 12747 is obsolete: 0 => 1
Created attachment 12796 [details] draft of spec file for opencpn-oernc-plugin draft of spec file for opencpn-oernc-plugin NB This rpm is for the non free repo this plugin has the same closed source libraries and binaries as opencpn-oesenc-plugin (with different versions for each arch) I don't know what to do : we can't package them twice !!! Perhaps package those libraries only in opencpn-oesenc-plugin and create a strict require for it in opencpn-oernc-plugin We don't need to package the udev rule neither for opencpn-oernc-plugin nor for the opencpn-oesenc-plugin (it is now in opencpn main package)
Attachment 12746 is obsolete: 0 => 1
Created attachment 12797 [details] better draft of the spec file for opencpn-s63-plugin this is a better draft I forgot to package the closed source binary one version for each arch
Attachment 12794 is obsolete: 0 => 1
Created attachment 12798 [details] spec file for opencpn-objsearch-plugin corrected spec file for opencpn-objsearch-plugin
Attachment 12737 is obsolete: 0 => 1
Created attachment 12799 [details] spec file for opencpn-radar-plugin version 5.1.2 spec file for opencpn-radar-plugin version 5.1.2 (same as 5.0.5) I finally built it (improving radar detection on linux) but no way to build version 5.2.0 : It seems that developpers are centering their efforts to port to flatpak or to create tarballs for the plugin Manager (for windows, MacOS, debian) the last changes in the source cmake files seem to prevent to build a rpm
Attachment 12793 is obsolete: 0 => 1
(In reply to Philippe Didier from comment #73) > Created attachment 12796 [details] > draft of spec file for opencpn-oernc-plugin > > draft of spec file for opencpn-oernc-plugin > > NB > This rpm is for the non free repo > > this plugin has the same closed source libraries and binaries as > opencpn-oesenc-plugin (with different versions for each arch) > I don't know what to do : we can't package them twice !!! > > Perhaps package those libraries only in opencpn-oesenc-plugin and create a > strict require for it in opencpn-oernc-plugin Yes I agree. > > We don't need to package the udev rule neither for opencpn-oernc-plugin nor > for the opencpn-oesenc-plugin (it is now in opencpn main package) OK thanks. You don't need any of that %ifarch complication. The builds only install the correct ones for the current %arch into %{buildroot}. You still seem to be using the wrong path for Source0 in some specs by leaving in "/refs/tags" which is not needed (and does not work ;). Thanks for your work - we are getting there...
Created attachment 12800 [details] corrected spec file for opencpn-iacfleet-plugin corrected spec file for opencpn-iacfleet-plugin (corrected Source0 URL)
Attachment 12736 is obsolete: 0 => 1
Created attachment 12801 [details] spec file for opencpn-climatology-plugin spec file for the opencpn-climatology-plugin corrected cleaned and Source0 and Source1 URL corrected @ Barry NB the CL-DATA-1.0.tar.xz file that we use as Source1 was made by Sean De Pagnier in 2015... Now more recent data may be found here : https://github.com/seandepagnier/climatology_pi_data/tree/b2f26b6935712665eefd1652e4a70384a645b526 But they have not been tared in one file Maybe we may git clone this source and find a way to uncompress and add these more recent data in %{_datadir}/opencpn/plugins/%{piname}/data/* It's a little far from what I know doing
Attachment 12734 is obsolete: 0 => 1
(In reply to Philippe Didier from comment #78) > Created attachment 12800 [details] > corrected spec file for opencpn-iacfleet-plugin > > corrected spec file for opencpn-iacfleet-plugin > > (corrected Source0 URL) No that's still wrong. It should be: Source0: https://github.com/nohal/%{piname}/archive/v%{version}/%{piname}-%{version}.tar.gz If you have checked out an existing package from svn, then you can test a Source0 by re-naming or deleting the tarball and using 'mgarepo sync -d --dry-run' which will download the tarball locally if the Source0 is correct. Also you have: %setup -q -n %{piname}-%{version} which should now be: %autosetup -p1 -n %{piname}-%{version} I missed that when I pushed it to cauldron :( You still have commit rights I assume? Maybe you could correct that %autosetup to test?
(In reply to Philippe Didier from comment #63) > Barry > no need to rebuild > opencpn-statusbar-plugin > opencpn-squiddio-plugin > they are up to date If we are switching to upstream full releases then they may need some attention. I have not checked yet. I don't see any reference to distribution of the nonfree binaries in the oernc tarball, there is the GPLv2 in the data dir but that is not really enough. I did consider putting it in core since we are removing those binaries from this package and using the ones from Required oesenc, but that did not feel right. I will put it in nonfree and add a note to the spec and description to point to the README.md in oesenc. since the files are the same. I see no other option. Do you have a cauldron test machine or VM? It would be good if you could test the packages as they appear in cauldron, you are accustomed to using them and can test much better than I could. If not I can point you to my local Mga8 repo where I have the same builds for Mga8.
(In reply to Philippe Didier from comment #79) > Created attachment 12801 [details] > spec file for opencpn-climatology-plugin > > spec file for the opencpn-climatology-plugin > corrected cleaned and Source0 and Source1 URL corrected Nope, Source0 still not right! Why do you keep including tags, refs, and a tar.gz in them all? All it needs is: Source0: https://github.com/rgleason/%{piname}/archive/v%{version}/%{piname}-%{version}.tar.gz Which produces: climatology_pi-1.4.23.0.tar.gz Also you don't need to untar Source1 manually in the spec. %autosetup will do it for you: %autosetup -p1 -a1 -n %{piname} The -a1 unpacks Source1 > > @ Barry > > NB the CL-DATA-1.0.tar.xz file that we use as Source1 was made by Sean De > Pagnier in 2015... > > Now more recent data may be found here : > https://github.com/seandepagnier/climatology_pi_data/tree/ > b2f26b6935712665eefd1652e4a70384a645b526 > > But they have not been tared in one file > > Maybe we may git clone this source and find a way to uncompress and add > these more recent data in %{_datadir}/opencpn/plugins/%{piname}/data/* I will look at that. > > It's a little far from what I know doing
(In reply to Barry Jackson from comment #80) > No that's still wrong. It should be: > Source0: > https://github.com/nohal/%{piname}/archive/v%{version}/%{piname}-%{version}. > tar.gz Sorry I did the same mistake for every Source0 URL Indeed I started from here https://github.com/nohal/iacfleet_pi/tags then I opened this following link for the right tag in a new tab : https://github.com/nohal/iacfleet_pi/archive/refs/tags/v0.21.1.tar.gz And I thought it was the subdirectory from where to download the source as iacfleet_pi-0.21.1.tar.gz was proposed... > You still have commit rights I assume? Maybe you could correct that > %autosetup to test? I never add commit right... I have had to stop to learn to become a true packager (I had some friends and family members that needed me to care for them... and beside my work I was not sure to be able to maintain any package)
(In reply to Barry Jackson from comment #81) > > I don't see any reference to distribution of the nonfree binaries in the > oernc tarball, there is the GPLv2 in the data dir but that is not really > enough. > Yes indeed bdbcat modified the README file in the code on May 21st https://github.com/bdbcat/oernc_pi https://github.com/bdbcat/oernc_pi/blob/master/README "The oeaserverd binary and libsgllnx64-2.29.02 libraries are closed source. Re-distribution of these items is allowed."
(In reply to Barry Jackson from comment #82) > Nope, Source0 still not right! > Why do you keep including tags, refs, and a tar.gz in them all? All it needs > is: > Source0: > https://github.com/rgleason/%{piname}/archive/v%{version}/%{piname}- > %{version}.tar.gz > Which produces: climatology_pi-1.4.23.0.tar.gz > Sorry same mistake as for iacfleet and for all the spec files > Also you don't need to untar Source1 manually in the spec. %autosetup will > do it for you: > %autosetup -p1 -a1 -n %{piname} > The -a1 unpacks Source1 sorry I didn't know that improvement that %autosetup have brought I started with the previous spec file which included %setup and the need to ask to tar the source > > @ Barry > > > > NB the CL-DATA-1.0.tar.xz file that we use as Source1 was made by Sean De > > Pagnier in 2015... > > > > Now more recent data may be found here : > > https://github.com/seandepagnier/climatology_pi_data/tree/ > > b2f26b6935712665eefd1652e4a70384a645b526 > > > > But they have not been tared in one file > > > > Maybe we may git clone this source and find a way to uncompress and add > > these more recent data in %{_datadir}/opencpn/plugins/%{piname}/data/* > > I will look at that. > Thanks
(In reply to Barry Jackson from comment #77) > (In reply to Philippe Didier from comment #73) > > draft of spec file for opencpn-oernc-plugin > > You don't need any of that %ifarch complication. The builds only install the > correct ones for the current %arch into %{buildroot}. > I was not sure that %cmake_install may find the right closed source libs and binaries for each arch And couldn't verify for each arch if the right version was in the built rpm (I have only a x86-64 system and only build packages for this arch) I have already had a bad experience with the opencpn-watchdog-plugin that needs : %ifarch x86_64 aarch64 mkdir -p %{buildroot}%{_libdir}/opencpn mv %{buildroot}/usr/lib/opencpn/* %{buildroot}%{_libdir}/opencpn/ %endif If I don't add these lines rpmbuild won't find the lib to add in : %{_libdir}/opencpn/lib%{piname}.so for a x86_64 package...
Seems s63 (1.17.1 from bdbcat) and oernc (1.1.0 from bdbcat) are both incompatible with opencpn-5.2.4. Testing in Mga8 :(
Hi Barry I just sent you a private message I built local rpms for mga8 from your specs from svn (http://svnweb.mageia.org/packages/cauldron/) I saw some problems I think I have corrected most of them May I attach new corrected spec files in this bug report that becomes too long and drafty Or may I open a new bug for each of the plugin I installed s63 and oernc and they work for me (your spec files seem not to allow to install the arch dependant binaries and libraries)
PS you found the trick for climatology database it's OK Thanks and congratulations
oernc from bdbcat git (1.2.5) seems OK so will update. @Philippe updated version 1.2.5 is now in my repo for testing.
(In reply to Philippe Didier from comment #88) > Hi Barry > I just sent you a private message > I built local rpms for mga8 from your specs from svn > (http://svnweb.mageia.org/packages/cauldron/) > I saw some problems > I think I have corrected most of them > > May I attach new corrected spec files in this bug report that becomes too > long and drafty > Or may I open a new bug for each of the plugin No continue here - it's less searching around, just attach them. > > I installed s63 and oernc and they work for me (your spec files seem not to > allow to install the arch dependant binaries and libraries) Don't forget that we don't install the oernc binaries, we use those from oesenc don't we?
(In reply to Barry Jackson from comment #91) > Don't forget that we don't install the oernc binaries, we use those from > oesenc don't we? The last git of Oesenc (with the up to date README file) is not easy to build I changed the priority : add the binaries and libs to oernc and create a require for it in oesenc....
Created attachment 12804 [details] corrected spec file for opencpn-ais-radar-plugin typo in ais-radar spec file Source0: https://github.com/rgleason/%{uname}/archive/v%{version}/%{piname}-%{version}.tar.gz and it must be Source0: https://github.com/rgleason/%{uname}/archive/v%{version}/%{uname}-%{version}.tar.gz (the downloaded tar is called AISradar_pi and not aisradar_pi)
Attachment 12733 is obsolete: 0 => 1
Created attachment 12805 [details] corrected spec file for opencpn-celestial-navigation-plugin typo I must have %prep %autosetup -p1 -n %{piname}-%{version} and not %autosetup -p1 -n %{piname} With your spec file I get an error when trying to rpmbuild
Created attachment 12806 [details] corrected spec file for opencpn-climatology-plugin Just one line added to know what to do with the mk-data script
Attachment 12801 is obsolete: 0 => 1
Created attachment 12807 [details] corrected spec file for opencpn-logbookkonni-plugin a new version of logbookkonni (I worked some time with Rick Gleason and Alec Leamas to improve it) It's not perfect but someway better : Now the Layouts.zip is in the data directory of the source Source0 URL modified
Created attachment 12808 [details] corrected spec file for opencpn-radar-plugin Source0 URL corrected : It must be Source0: https://github.com/opencpn-radar-pi/%{piname}/archive/v%{version}/%{piname}-%{version}.tar.gz and not Source0: https://github.com/opencpn-radar-pi/%{piname}/archive/v%{version}.tar.gz/%{name}-%{version}.tar.gz
Attachment 12799 is obsolete: 0 => 1
Created attachment 12809 [details] spec file for opencpn-s63-plugin I downloaded the rpms for the four arches and explored their content with Ark There's a problem for the closed source binary in the rpm for i586 the OCPNsenc binary is 2,4Mo it's 2,4 Mo in the BUILD/s63_pi/buildlinux/OCPNsenc that's alright in the rpm for x86_64 the OCPNsenc binary is 2,6Mo it's 2,6 Mo in the BUILD/s63_pi/buildlinux64/OCPNsenc that's alright too BUT... in the rpm for armv7hl the OCPNsenc binary is 2,4Mo it's 2,0 Mo in the BUILD/s63_pi/buildlinuxarm/OCPNsenc that's not good in the rpm for aarch64 the OCPNsenc binary is 2,6Mo it's 2,5 Mo in the BUILD/s63_pi/buildlinuxarm64/OCPNsenc that's not good I thought there would be a problem and that's the reason why the draft spec I had proposed previously asked to copy the binaries depending on the arches : %ifarch x86_64 cp -r %{_builddir}/%{piname}-%{version}/buildlinux64/OCPNsenc/OCPNsenc \ %{buildroot}/%{_bindir} %endif %ifarch i586 cp -r %{_builddir}/%{piname}-%{version}/buildlinux/OCPNsenc/OCPNsenc \ %{buildroot}/%{_bindir} %endif %ifarch armv7hl cp -r %{_builddir}/%{piname}-%{version}/buildlinuxarm/OCPNsenc/OCPNsenc \ %{buildroot}/%{_bindir} %endif %ifarch aarch64 cp -r %{_builddir}/%{piname}-%{version}/buildlinuxarm64/OCPNsenc/OCPNsenc \ %{buildroot}/%{_bindir} %endif By the way I renamed mk_tar-s63 not to confuse with other script if the /rpmbuild/SOURCES/ directory is not empty
Attachment 12797 is obsolete: 0 => 1
Created attachment 12810 [details] script to download the s63 source code from github renamed script to download the s63 source code from github according to the new corrected spec file
OK I read your test results. 1. OPENCPN As you say it does not matter about the patch name. 2. AISRADAR It does not matter what we call the downloaded tarball. 3. CELESTIAL Puzzling - http://pkgsubmit.mageia.org/uploads/done/cauldron/core/release/20210621222725.barjac.duvel.36167 It built on BS for all arches last night! However its failing here in iurt now, so something changed in cauldron. 4. RADAR One of yours that I missed ;) I will correct it in svn 5. S63 Interesting - looks like an issue in the upstream CMakeLists.txt We can use the %ifarch way unless we can see what's wrong. 6. OERNC Yes I already did that. 7. OESENC I will look at that 8. LOGBOOKKONNI I have not yet looked at this one ;(
Created attachment 12811 [details] corrected spec file for opencpn-oernc-plugin I modified the priority between oernc and oesenc Now the binaries and libraries are provided by oernc And oesenc will have a require for it I build it withe the source from bdbcat who is the main developer (he updated the the README file to allow distribution of closed source binaries) I used a mk-tar-oernc to create the tar.gz (inspired by your mk-tar for s63
Attachment 12796 is obsolete: 0 => 1
Created attachment 12812 [details] script to download the oernc source code from github here the script for oernc-plugin
Created attachment 12813 [details] spec file for the problematic opencpn-oesenc-plugin Your spec file has a source (version 4.2.15) that was created before the README file was modified allowing distribution of closed source binaries I tried to update it using mk_tar-oesenc (next attachment) but I can't build it (bdbcat is modifying the code to allow the plugin manager to install it, but seems to have broken something for legacy rpm installation)
Attachment 12795 is obsolete: 0 => 1
Created attachment 12814 [details] script to download the oesenc source code from github I created this script because the mk_tar that you use (found here http://svnweb.mageia.org/packages/cauldron/opencpn-oesenc-plugin/releases/4.2.15/1.mga9.nonfree/SOURCES/mk-tar?revision=1731545&view=co) doesn't download the good source : mk_tar oesenc_pi https://github.com/rgleason/oesenc_pi/ tar.gz opencpn-oesenc-plugin it's not the same at all as the one you give in the spec file : Source0: https://github.com/bdbcat/%{piname}/archive/v%{version}/%{piname}-%{version}.tar.gz That's perhaps the reason why it doesn't work for opencpn 5.2.4
Nevertheless The source code of opencpn-oernc-plugin has been updated by bdbcat on 2021 may 21st the closed source binaries and libs seem OK So we may keep them better than using the ones from oesenc That will allow us to use the rgleason code source without the closed source binaries
Created attachment 12815 [details] spec file for the problematic opencpn-oesenc-plugin I forgot to suppress one line in %files : no need for %{_bindir}/* if we use the one provided by oernc
Attachment 12813 is obsolete: 0 => 1
Created attachment 12816 [details] corrected spec file for opencpn-sar-plugin version 2.6.1 I corrected the Source0 URL version 2.6.1 is the one to use (newer have only changes for flatpak)
Attachment 12791 is obsolete: 0 => 1
Created attachment 12817 [details] corrected spec file for opencpn-weatherfax-plugin version 1.9.16.0 the Source0 URL is now correct Rick Gleason have updated the list of URLs of internet fax providers
Attachment 12788 is obsolete: 0 => 1
Created attachment 12818 [details] corrected spec file for opencpn-route-plugin version 1.2 corrected spec file for opencpn-route-plugin version 1.2 it's a new plugin rpm for Mageia
Attachment 12792 is obsolete: 0 => 1
Created attachment 12819 [details] spec file for opencpn-objsearch-plugin just a Source0 URL corrected
Remain 3 plugins they are more than up to date because having been built from a git clone instead of tagged source version polar squddio statusbar we can't update them to the last tagged release since this one is lower than the git clone version You may leave them as they are We may change their Source0 URl (instead of using the get-plugin script) when a new tag appear higher than the actual version polar rpm version is 1.1.17.1 (from the git clone of rgleason) but the last tagged release is 1.1.17.0 in https://github.com/rgleason/polar_pi/ squiddio rpm version is 1.3.10.0 (from the git clone of mauroc) but the last tagged release is 1.3.8.3 in https://github.com/mauroc/squiddio_pi statusbar rpm version is 0.8 (from the git clone of seandepanier) but the last tagged release is 0.7.9 in https://github.com/rgleason/statusbar_pi Let's see it later (I have already spec file prepared for this)
(In reply to Philippe Didier from comment #106) > Created attachment 12815 [details] > spec file for the problematic opencpn-oesenc-plugin What is problematic about it? > > I forgot to suppress one line in %files : > no need for > %{_bindir}/* > if we use the one provided by oernc Why? All that is missing in oesenc-4.2.15 in cauldron is: %files -f opencpn-%{piname}.lang +%doc README.md I was and am tired. (In reply to Philippe Didier from comment #101) > Created attachment 12811 [details] > corrected spec file for opencpn-oernc-plugin > > I modified the priority between oernc and oesenc > Now the binaries and libraries are provided by oernc > And oesenc will have a require for it Why? If you do this it will involve conflicts. (They are already in cauldron) If they are identical, which they have to be, then what is the point? > > I build it withe the source from bdbcat who is the main developer (he > updated the the README file to allow distribution of closed source binaries) > The README.md in 4.2.15 from rgleason has that. > I used a mk-tar-oernc to create the tar.gz > (inspired by your mk-tar for s63 I thought we were talking about oesenc - this is getting crazy! I won't change the mk-tar name(s), there is no way that they can be confused as they are in different packages in their own SOURCES/. There is no version information in that bdbcat git repo for oesenc. Where were you intending to find a version for it? I have added the missing README.md to oesenc in cauldron and rebuilt it.
Sorry if I create confusion (from comments 101 to 106) indeed I got problems with oernc-plugin And oesenc-plugin That started when I used your spec files from http://svnweb.mageia.org/packages/cauldron/ to build locally rpms for Mga8 _______________ beginning of your spec file for oesenc ## NOTE nonfree only # %define debug_package %{nil} %define piname oesenc_pi Name: opencpn-oesenc-plugin Summary: Provides support for encrypted charts available from o-charts.org Version: 4.2.15 Release: %mkrel 2 License: GPLv3+ # See README.md for distribution permission for pre-built binary Group: Geography URL: https://github.com/bdbcat/oesenc_pi Source0: %{piname}-%{version}.tar.gz Source1: mk-tar _____________________ end of your mk_tar for oesenc 97 # Main routine ----------- 98 # Check we are in SOURCES 99 [[ $(pwd|rev|cut -d/ -f1|rev) = "SOURCES" ]] || { echo "Not in SOURCES directory - aborting!"; exit 1; } 100 wkdir=$(pwd) 101 rm -f chklist.txt 102 rm -rf git 103 mk_tar oesenc_pi https://github.com/rgleason/oesenc_pi/ tar.gz opencpn-oesenc-plugin 104 rm -rf git 105 __________________ As you can see, you mention 2 different sources URL 1) in the spec : bdbcat (which is the main developer of s63 oernc and oesenc and who modified the README to allow distribution of the closed source binaries and libraries when I asked him a month ago ) 2) in the mk_tar : rgleason looking at rgleason code I saw that his last commit on README.md was 16 months old ! So I tried to build an rpm with the bdbcat code (with an updated README) I git-cloned it (with a modified mk_tar) and obtained a 4.2.19 version... (the version is here https://github.com/bdbcat/oesenc_pi/blob/master/VERSION.cmake) I couldn't build an rpm with this source : cmake aborts and I don't understand why (that's why I said it is problematic) Exploring the code I saw that in oesenc https://github.com/bdbcat/oesenc_pi/tree/master/libs/oeserverd we cand find the same versions of the closed source libraries and binaries as in oernc https://github.com/bdbcat/oernc_pi in both of them we find different prebuilt for different arches That's the reason why I proposed to inverse the priority : oesenc will Require oernc which will provide the closed source binaries and oesenc may wait until we can really build it If you want to try to build a opencpn-oesenc-plugin rpm with the bdbcat source https://github.com/bdbcat/oesenc_pi You may perhaps understand why we can't build this rpm
TL;DR Please don't add anything more to this bug for now. Take some time to fully test any changes that you make and then *email* to me ONLY patches [1] against cauldron (as it is current at the time). Keep all emails related to one package titled with just the name of the package. Also please make sure to not break threading on messages related to one package, by using 'reply'. I think this way we can be more productive. (and less confused) I will continue to update in cauldron as time allows until we have it sorted. Then we can consider which packages to backport to Mga8. Cheers, Barry [1] Use mgarepo co packagename to get the current source tree from Mageia svn, then cd into 'packagename' and make any changes, then use svn diff > svndiff.patch to create the patch. Don't reply here ... quiet please! Take a deep breath :)
Nevertheless for the moment you can let this staff as you built it don't modify your actual oernc and oesenc rpms nevermind with my last comments about them I think that soon bdbcat will provide a new version of the oesenc code and we can use then an updated rpm with his code (I know that bdbcat is now struggling with the oesenc code ....)
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=29309
this bug has been resolved in Cauldron Thanks to Barry Jackson for his skill, patience availability and perseverance ;) A new an very shorter bug report has been created and replace it for Mageia8 https://bugs.mageia.org/show_bug.cgi?id=29309 This far too long bug report may be closed now
Resolution: (none) => FIXEDStatus: NEW => RESOLVED