Re: Packaging Linrad for Fedora
On Tue Apr 7 07:27:42 EDT 2015, Leif Asbrink wrote:
The first step in Fedora packaging is to check all the licensing issues. Iain has already done the important leg work of verifying that the license (MIT) is acceptable to Fedora, so that's an important hurdle that's been cleared. Hello John, There is a non-free library for Perseus that is available as source code on the Internet, a non-free rpm package for Elad FDM-S1. Linrad comes with the commands required to download and install them. There is also the Adlink PCIe-9842 for which one has to sign a non-disclosure agreement to get the source code. (It provides a real-time bandwidth of 100 MHz!)
Hi Leif, There would be some other "leg work" to do before packaging Linrad, namely packaging the software that it depends on. Some of the dependencies have already been packaged, some of them have not. (For example, I just checked and Fedora has nasm and svgalib already packaged). We would want to get the other dependencies with suitable license terms (like rtl-sdr, etc.) packaged first. As far as the dependencies you described above, they could not be packaged for Fedora. (Don't shoot the messenger. For every piece of software I have packaged, I have had to give up on 5 or 10 others because they didn't have licenses suitable for Fedora). The reviewers are very strict about this. It's the price we pay for living in a society that has become so litigious. There are two solutions to this problem. One would be to modify Linrad to look for shared libs with the needed device support at run time, using something like dlopen(). Another approach would be to provide instructions for users on how to get the non-freely licensed dependencies installed and then rebuild the Linrad rpm (the command "rpmbuild -ba linrad.spec" does that). There are already a few other Fedora packages that do this. One example is the Atlas linear algebra package. It optimizes itself to your hardware at compile time, so there is simply NO way to distribute Atlas packages that are optimized for all machines. If you want an optimized Atlas for your system, you must rebuild it yourself.
I don't think it would deter your changes of a Linrad package getting approved, but I did notice one thing that could use a little polish. Unix (and Linux) users often have an expectation that parameter files are always installed in a standard location (rather than the CWD). This would be a really bad idea. It is often a good idea to run several instances of Linrad in parallel and then they need different parameters. The implications of your suggestion is that there should be a layer on top of the parameter settings in which the user could browse a linrad directory for a certain set of parameters. Also functions to copy parameter sets would be needed. Actually the functions that the normal directory three supplies. This would make Linrad more difficult to use and would become an obstacle for users so if it is a requirement for a Fedora package I feel it is better to leave Linrad unpackaged.
As I mentioned, this probably would not get the package rejected. Just expressing a personal preference. I hope you are not too discouraged, packaging is a lengthy and often annoying and tedious process. 73, John -- John C. Peterson, KD6EKQ mailto:jcp@eskimo.com San Diego, CA U.S.A
Hello John,
There would be some other "leg work" to do before packaging Linrad, namely packaging the software that it depends on. Some of the dependencies have already been packaged, some of them have not. (For example, I just checked and Fedora has nasm and svgalib already packaged). We would want to get the other dependencies with suitable license terms (like rtl-sdr, etc.) packaged first. Yes, I understand and appreciate that. rtl-sdr is a special case however since osmocom has rejected some very important upgrades and there is an alternative package available which makes much better use ot the rtl-sdr dongles. Osmocom is however the leading maintainer that introduces new dongles. Someone would have to take the responsibility of merging osmpcom with the dl8aau version.
As far as the dependencies you described above, they could not be packaged for Fedora. (Don't shoot the messenger. For every piece of software I have packaged, I have had to give up on 5 or 10 others because they didn't have licenses suitable for Fedora). The reviewers are very strict about this. It's the price we pay for living in a society that has become so litigious.
There are two solutions to this problem. One would be to modify Linrad to look for shared libs with the needed device support at run time, using something like dlopen(). This is already implemented. Linrad uses dlopen on all hardware related libraries and would thell the uset what library is missing. It is then up to the user to search the Internet for libbladeRF.so or whatever is missing.
Another approach would be to provide instructions for users on how to get the non-freely licensed dependencies installed and then rebuild the Linrad rpm (the command "rpmbuild -ba linrad.spec" does that). There are already a few other Fedora packages that do this. One example is the Atlas linear algebra package. It optimizes itself to your hardware at compile time, so there is simply NO way to distribute Atlas packages that are optimized for all machines. If you want an optimized Atlas for your system, you must rebuild it yourself. Well, Linrad is easier. Users who install from source get complete instructions on how to install everything from the configure script by running it with the "--with-help" option.
I don't think it would deter your changes of a Linrad package getting approved, but I did notice one thing that could use a little polish. Unix (and Linux) users often have an expectation that parameter files are always installed in a standard location (rather than the CWD). This would be a really bad idea. It is often a good idea to run several instances of Linrad in parallel and then they need different parameters. The implications of your suggestion is that there should be a layer on top of the parameter settings in which the user could browse a linrad directory for a certain set of parameters. Also functions to copy parameter sets would be needed. Actually the functions that the normal directory three supplies. This would make Linrad more difficult to use and would become an obstacle for users so if it is a requirement for a Fedora package I feel it is better to leave Linrad unpackaged.
As I mentioned, this probably would not get the package rejected. Just expressing a personal preference. Hmmm, the complexity of using Linrad in full is beyond most amateur radio enthusiasts, but for those who understand enough of radio there are many VERY interesting possibilities by cascading instances of Linrad. One could monitor dozens of frequencies with the squelch. (An efficient squelch for SSB as well as other modes.) Activity on selected frequencies (One for each instance of Linrad) would be saved as a .wav file. Other usages of parallel instances of Linrad could involve removal of splatter from adjacent FM channels http://www.sm5bsz.com/lir/fm/fmqrm.htm Cascading SDR software opens new possibillities and a packaged Linrad should not close them.
I hope you are not too discouraged, packaging is a lengthy and often annoying and tedious process. OK. Maybe someone else would be interested in supplying a framework for users to select what Linrad installation they want to run. For me it is obvious and simple, run the installation defined by the currently logged directory. The coding required to change is (for me) of no interest. I do not understand in what way there would be any advantage. There are so many interesting problems (and many more less interesting ones in the form of bugs in established packages like bug-rich portaudio.) so I prefer to spend my time on things I think would really improve state of the art in SDR.
Leif
participants (2)
-
John C. Peterson -
Leif Asbrink