[bug#38650] [PATCH] gnu: adds hackrf

[Christopher Howard <christopher@librehacker.com>]

Can those minor tweaks be added by whomever is applying the patch, or
do I need to submit a new patch?

-- 
Christopher Howard
p: +1 (907) 374-0257
w: https://librehacker.com
social: https://gnusocial.club/librehacker
gpg: ADDEAADE5D607C8D (keys.gnupg.net)

On Mon, 2020-04-27 at 17:33 +0200, Guillaume Le Vaillant wrote:
> Hi,
> 
> Christopher Howard <christopher.howard@qlfiles.net> skribis:
> 
> > I have asked many times about the new release over the last few
> > months,
> > and each time hackrf team says it is a week or so away. But their
> > last
> > git commit was in February. Requesting to please proceed with the
> > latest commit as represented in this patch. I have added
> > information to
> > the description as requested.
> > 
> > Using the old 2018 release would be unsatisfactory due to an
> > annoying
> > bug related to maintaining connections to hackrf devices.
> 
> I noticed that the package definition builds 'lib/libhackrf.a';
> installing static libraries is usually disabled for Guix packages.
> Also, some of the lines of the package definition are indented with
> tabs
> instead of spaces, and the commit message is missing the
> " * gnu/packages/radio.scm (hackrf): New variable." line.
> 
> > As an additional motivation for adding this, I believe you need
> > libhackrf installed to use hackrf with gnuradio, through the
> > osmocom
> > interface. (I'm not at the moment quite clear on what exactly you
> > have
> > to enable in the gnuradio package definitions to link those
> > together.)
> > E.g., https://packages.debian.org/stretch/gr-osmosdr
> 
> In theory, adding the hackrf package as input of the gnuradio-osmosdr
> package should be enough (the library should be auto-detected when
> compiling and the support activated).
> However, I don't have the hardware to test if it really works.