Packaging Linrad for Fedora

Leif Asbrink leif at sm5bsz.com
Tue Apr 7 22:52:38 EDT 2015


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



More information about the Fedora-hams mailing list