https://wiki.gnuradio.org/api.php?action=feedcontributions&user=Willcode4&feedformat=atomGNU Radio - User contributions [en]2024-03-19T03:48:16ZUser contributionsMediaWiki 1.39.5https://wiki.gnuradio.org/index.php?title=ReleaseKey&diff=13725ReleaseKey2024-01-01T20:12:57Z<p>Willcode4: </p>
<hr />
<div>= ReleaseKey =<br />
<br />
GNU Radio software signing keys may be downloaded from the Release area on Github.<br />
<br />
Posted here '''for information only''' ... the wiki is not a secure place to obtain keys/fingerprints.<br />
<br />
Software is currently signed by gpg key<br />
E852461BC01D652724600054ABA21950443392F6<br />
which is issued by<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
<br />
-----BEGIN PGP PUBLIC KEY BLOCK-----<br />
mDMEYEK63BYJKwYBBAHaRw8BAQdADTdeCx8vG5iMDzSrjSkpUhalokrrLjLEKHed<br />
1Mveqy+0NEdOVSBSYWRpbyAoU29mdHdhcmUgU2lnbmluZyBLZXkpIDxpbmZvQGdu<br />
dXJhZGlvLm9yZz6IkAQTFggAOBYhBHI+w6K5BTPGuT37yO15d0P3lRQ1BQJgQrrc<br />
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEO15d0P3lRQ1dIUA/RC/shSi<br />
uO0iq0dfKOr6AVjb6Cf1TGHE0ODqvZNigipwAP4pL7XKz8Qm5SZOAnkKfK6qeeqj<br />
9TEclVsQ0l18sId/D7gzBGBCu1sWCSsGAQQB2kcPAQEHQO/EPuC+j4jMjdhokmZD<br />
lQfkZk32sY2Rny9ZCz7MWFXLiPUEGBYIACYWIQRyPsOiuQUzxrk9+8jteXdD95UU<br />
NQUCYEK7WwIbAgUJAY4lAACBCRDteXdD95UUNXYgBBkWCAAdFiEE6FJGG8AdZSck<br />
YABUq6IZUEQzkvYFAmBCu1sACgkQq6IZUEQzkvZ/fQEA7MnOrZ2MNhgPK1WNhiMM<br />
r83Sks/arMRPFioXT0DA/QcA/i6MyS4xTey2aViNyum8nP6cTQ6pKYiZv/yraKYf<br />
KcAKlw0BAIqjJtsfEoqK/2nLMrRlFYN0upEv8ca9N2gOGP83/I1PAQCTIzW5kWpx<br />
8GOVNIKJ78VewffKLBZ3Rcj07ZToyYFoB4j1BBgWCAAmAhsCFiEEcj7DorkFM8a5<br />
PfvI7Xl3Q/eVFDUFAmV3I9oFCQj2z38AgXYgBBkWCAAdFiEE6FJGG8AdZSckYABU<br />
q6IZUEQzkvYFAmBCu1sACgkQq6IZUEQzkvZ/fQEA7MnOrZ2MNhgPK1WNhiMMr83S<br />
ks/arMRPFioXT0DA/QcA/i6MyS4xTey2aViNyum8nP6cTQ6pKYiZv/yraKYfKcAK<br />
CRDteXdD95UUNT0gAQDvAcu8NM27cTfttsniGW2FmJFkY4R9c2bosZtGichWAgEA<br />
v3Dtissufv6gzwbRGoxYbXbZm9ctGBkjXYppD1RtMAE=<br />
=8pVF<br />
-----END PGP PUBLIC KEY BLOCK-----<br />
<br />
pub ed25519 2021-03-05 [SC]<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
uid GNU Radio (Software Signing Key) <info@gnuradio.org><br />
sub ed25519 2021-03-05 [S] [expires: 2025-12-10]<br />
E852461BC01D652724600054ABA21950443392F6</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseKey&diff=13724ReleaseKey2024-01-01T19:57:40Z<p>Willcode4: </p>
<hr />
<div>= ReleaseKey =<br />
<br />
GNU Radio software signing keys may be downloaded from the Release area on Github.<br />
<br />
Posted here '''for information only''' ... the wiki is not a secure place to obtain keys/fingerprints.<br />
<br />
Software is currently signed by gpg key<br />
E852461BC01D652724600054ABA21950443392F6<br />
which is issued by<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
<br />
-----BEGIN PGP PUBLIC KEY BLOCK-----<br />
mDMEYEK63BYJKwYBBAHaRw8BAQdADTdeCx8vG5iMDzSrjSkpUhalokrrLjLEKHed<br />
1Mveqy+0NEdOVSBSYWRpbyAoU29mdHdhcmUgU2lnbmluZyBLZXkpIDxpbmZvQGdu<br />
dXJhZGlvLm9yZz6IkAQTFggAOBYhBHI+w6K5BTPGuT37yO15d0P3lRQ1BQJgQrrc<br />
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEO15d0P3lRQ1dIUA/RC/shSi<br />
uO0iq0dfKOr6AVjb6Cf1TGHE0ODqvZNigipwAP4pL7XKz8Qm5SZOAnkKfK6qeeqj<br />
9TEclVsQ0l18sId/D7gzBGBCu1sWCSsGAQQB2kcPAQEHQO/EPuC+j4jMjdhokmZD<br />
lQfkZk32sY2Rny9ZCz7MWFXLiPUEGBYIACYWIQRyPsOiuQUzxrk9+8jteXdD95UU<br />
NQUCYEK7WwIbAgUJAY4lAACBCRDteXdD95UUNXYgBBkWCAAdFiEE6FJGG8AdZSck<br />
YABUq6IZUEQzkvYFAmBCu1sACgkQq6IZUEQzkvZ/fQEA7MnOrZ2MNhgPK1WNhiMM<br />
r83Sks/arMRPFioXT0DA/QcA/i6MyS4xTey2aViNyum8nP6cTQ6pKYiZv/yraKYf<br />
KcAKlw0BAIqjJtsfEoqK/2nLMrRlFYN0upEv8ca9N2gOGP83/I1PAQCTIzW5kWpx<br />
8GOVNIKJ78VewffKLBZ3Rcj07ZToyYFoB4j1BBgWCAAmAhsCFiEEcj7DorkFM8a5<br />
PfvI7Xl3Q/eVFDUFAmV3I9oFCQj2z38AgXYgBBkWCAAdFiEE6FJGG8AdZSckYABU<br />
q6IZUEQzkvYFAmBCu1sACgkQq6IZUEQzkvZ/fQEA7MnOrZ2MNhgPK1WNhiMMr83S<br />
ks/arMRPFioXT0DA/QcA/i6MyS4xTey2aViNyum8nP6cTQ6pKYiZv/yraKYfKcAK<br />
CRDteXdD95UUNT0gAQDvAcu8NM27cTfttsniGW2FmJFkY4R9c2bosZtGichWAgEA<br />
v3Dtissufv6gzwbRGoxYbXbZm9ctGBkjXYppD1RtMAE=<br />
=8pVF<br />
-----END PGP PUBLIC KEY BLOCK-----<br />
<br />
pub ed25519 2021-03-05 [SC]<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
uid GNU Radio (Software Signing Key) <info@gnuradio.org><br />
sub ed25519 2021-03-05 [S] [expires: 2025-12-10]<br />
E852461BC01D652724600054ABA21950443392F6</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseKey&diff=13723ReleaseKey2024-01-01T19:53:24Z<p>Willcode4: </p>
<hr />
<div>= ReleaseKey =<br />
<br />
GNU Radio software signing keys may be downloaded from the Release area on Github.<br />
<br />
Posted here '''for information only''' ... the wiki is not a secure place to obtain keys/fingerprints.<br />
<br />
Software is currently signed by gpg key<br />
E852461BC01D652724600054ABA21950443392F6<br />
which is issued by<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
<br />
-----BEGIN PGP PUBLIC KEY BLOCK-----<br />
<br />
mDMEYEK63BYJKwYBBAHaRw8BAQdADTdeCx8vG5iMDzSrjSkpUhalokrrLjLEKHed<br />
1Mveqy+0NEdOVSBSYWRpbyAoU29mdHdhcmUgU2lnbmluZyBLZXkpIDxpbmZvQGdu<br />
dXJhZGlvLm9yZz6IkAQTFggAOBYhBHI+w6K5BTPGuT37yO15d0P3lRQ1BQJgQrrc<br />
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEO15d0P3lRQ1dIUA/RC/shSi<br />
uO0iq0dfKOr6AVjb6Cf1TGHE0ODqvZNigipwAP4pL7XKz8Qm5SZOAnkKfK6qeeqj<br />
9TEclVsQ0l18sId/D7gzBGBCu1sWCSsGAQQB2kcPAQEHQO/EPuC+j4jMjdhokmZD<br />
lQfkZk32sY2Rny9ZCz7MWFXLiPUEGBYIACYWIQRyPsOiuQUzxrk9+8jteXdD95UU<br />
NQUCYEK7WwIbAgUJAY4lAACBCRDteXdD95UUNXYgBBkWCAAdFiEE6FJGG8AdZSck<br />
YABUq6IZUEQzkvYFAmBCu1sACgkQq6IZUEQzkvZ/fQEA7MnOrZ2MNhgPK1WNhiMM<br />
r83Sks/arMRPFioXT0DA/QcA/i6MyS4xTey2aViNyum8nP6cTQ6pKYiZv/yraKYf<br />
KcAKlw0BAIqjJtsfEoqK/2nLMrRlFYN0upEv8ca9N2gOGP83/I1PAQCTIzW5kWpx<br />
8GOVNIKJ78VewffKLBZ3Rcj07ZToyYFoB4j1BBgWCAAmAhsCFiEEcj7DorkFM8a5<br />
PfvI7Xl3Q/eVFDUFAmV3I9oFCQj2z38AgXYgBBkWCAAdFiEE6FJGG8AdZSckYABU<br />
q6IZUEQzkvYFAmBCu1sACgkQq6IZUEQzkvZ/fQEA7MnOrZ2MNhgPK1WNhiMMr83S<br />
ks/arMRPFioXT0DA/QcA/i6MyS4xTey2aViNyum8nP6cTQ6pKYiZv/yraKYfKcAK<br />
CRDteXdD95UUNT0gAQDvAcu8NM27cTfttsniGW2FmJFkY4R9c2bosZtGichWAgEA<br />
v3Dtissufv6gzwbRGoxYbXbZm9ctGBkjXYppD1RtMAE=<br />
=8pVF<br />
-----END PGP PUBLIC KEY BLOCK-----<br />
<br />
pub ed25519 2021-03-05 [SC]<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
uid GNU Radio (Software Signing Key) <info@gnuradio.org><br />
sub ed25519 2021-03-05 [S] [expires: 2025-12-10]<br />
E852461BC01D652724600054ABA21950443392F6</div>Willcode4https://wiki.gnuradio.org/index.php?title=YAML_Config&diff=13204YAML Config2023-06-20T14:12:56Z<p>Willcode4: </p>
<hr />
<div><!-- YAML_Config.mediawiki --><br />
This block represents a yaml config file that is read in as a dictionary.<br />
<br />
The values can be used directly when instantiating blocks. For example,<br />
Sample Rate: yaml_config["samp_rate"]<br />
<br />
Optionally, a JSON schema can be specified to validate the configuration. It may sound odd to use a json schema for a yaml file, but it works and jsonschema is a rich specification.<br />
<br />
For example, you could have a YAML file that contains:<br />
<br />
<nowiki><br />
samp_rate: 1e6</nowiki><br />
<br />
And a schema that contains<br />
<nowiki><br />
{<br />
"type": "object",<br />
"properties": {<br />
"samp_rate": {"type": "number", "exclusiveMinimum": 0}<br />
}<br />
}</nowiki><br />
<br />
If the id of this block is <code>yaml_config_0</code>, then you can access the samp rate<br />
in other blocks as <code>yaml_config_0["samp_rate"]</code>.<br />
<br />
== Parameters ==<br />
<br />
; Config File <br />
: File name of the YAML config file<br />
<br />
; Config Schema<br />
: (Optional) File name of the JSON schema file<br />
<br />
== Example Flowgraph ==<br />
<br />
The <code>fsk_params.yml</code> file contains:<br />
<pre><br />
samp_rate: 48000<br />
baud: 1200<br />
mark: 1200<br />
space: 2200<br />
reverse: -1<br />
thresh: 0<br />
</pre><br />
<br />
[[File:Yaml_test_fg.png|800px]]<br />
<br />
== Source Files ==<br />
<br />
; Block definition<br />
: [https://github.com/gnuradio/gnuradio/blob/main/grc/blocks/yaml_config.block.yml yaml_config.block.yml]<br />
<br />
[[Category:Block Docs]]</div>Willcode4https://wiki.gnuradio.org/index.php?title=Message_Pair_to_Var&diff=13112Message Pair to Var2023-05-05T12:33:43Z<p>Willcode4: </p>
<hr />
<div><p>This block converts an input message pair to the value of a gnuradio variable.</p><br />
<code>Added in 3.9</code><br />
<br />
== Parameters ==<br />
<b>(''R''):</b> <span class="plainlinks">[https://wiki.gnuradio.org/index.php/GNURadioCompanion#Variable_Controls ''Run-time adjustable'']</span><br />
<br />
; Variable<br />
: Name of the variable to be set. type: string; default: 'freq'<br />
<br />
== Messages ==<br />
<br />
Input message pairs are of the form (<name> . <value>). For this block, <name> is ignored. The variable to be set is specified as a block parameter. More information on PMTs in general can be found in [[Polymorphic_Types_(PMTs)#Pairs|PMT Pairs]].<br />
<br />
== Example Flowgraph ==<br />
<br />
In this flowgraph, the input message has the name 'value' and the value of 1 or 0. The Message Pair to Var Block Variable has the value "pressed", so it sets the variable "pressed" to 1. The [[QT_GUI_Label]] displays the value of "pressed".<br />
<br />
[[File:Msg_pair_to_var_fg.png]]<br />
<br />
== Example Output ==<br />
<br />
[[File:Msg_pair_to_var_out.png]]<br />
<br />
== Source Files ==<br />
<br />
; C++ files<br />
: [https://github.com/gnuradio/gnuradio TODO]<br />
<br />
; Header files<br />
: [https://github.com/gnuradio/gnuradio TODO]<br />
<br />
; Public header files<br />
: [https://github.com/gnuradio/gnuradio TODO]<br />
<br />
; Block definition<br />
: [https://github.com/gnuradio/gnuradio TODO]<br />
<br />
[[Category:Block Docs]]</div>Willcode4https://wiki.gnuradio.org/index.php?title=Correlate_Access_Code_-_Tag_Stream&diff=12605Correlate Access Code - Tag Stream2022-10-08T14:43:15Z<p>Willcode4: </p>
<hr />
<div>[[Category:Block Docs]]<br />
Examine input for specified access code, one bit at a time.<br />
<br />
input: stream of floats (generally, soft decisions)<br />
<br />
output: a tagged stream set of bits from the payload following the access code and header<br />
<br />
This block searches for the given access code by slicing the soft decision symbol inputs. Once found, it expects the following 32 samples to contain a header that includes the frame length (16 bits for the length, repeated). It decodes the header to get the frame length in order to set up the the tagged stream key information.<br />
<br />
The output of this block is appropriate for use with tagged stream blocks.<br />
<br />
== Parameters ==<br />
; Access Code<br />
: is represented with 1 byte per bit, e.g., <code>010101010111000100</code><br />
<br />
:It is important to choose an access code that is not "cyclical". A cyclical code contains a repetition of itself within the length of the code. This can cause false access code detections, and will cause byte boundaries (and hence valid packet length and payload recovery) to be recovered in error, with bizarre results!<br />
<br />
:For example, an access code of <code>11111111</code> is a poor choice because it is cyclical. Let's look at why this is. <br />
<br />
:The first eight <code>1</code> bits in a row from the block's input stream will correctly detect the first access code. The first packet (in standard form <code><access code> <length1> <length2> <payload></code>) will be recovered nominally. <br />
<br />
:However, when the correlate access code block's state machine goes back into scanning/detection mode after the first packet, the first bit of the NEXT access code (which forms the <code>11111111</code> preamble of the next packet) will cause an immediate access code detection. This is because the access code detection routine within the block always shifts the last detected access code one bit to the left, and ORs in the current input bit.<br />
<br />
:In our example, the valid bits <code>11111111</code> from the first access code detected will get shifted left one bit (to give <code>11111110</code>), and then the next input bit (the first bit after the end of the first packet) will be ORed into the value (<code>11111110 OR 1</code>, giving <code>11111111</code>) resulting in an erroneous detection of the next access code, because <code>11111111</code> will of course match the access code that the block is searching for. <br />
<br />
:This will falsely detect the start of the next packet (alignment off by 7 bits) and your flowgraph will explode with subsequent bad headers and invalid data. Not a pretty site.<br />
<br />
:So, when choosing an access code, select one that is not cyclical!<br />
<br />
:A possible (and historically interesting) non-cyclical 32-bit access code might be 0xe15ae893:<br />
<br />
:<code>11100001010110101110100010010011</code><br />
<br />
:which was the "unique word" used on several early communications satellites.<br />
<br />
; Threshold<br />
: maximum number of bits that may be wrong<br />
<br />
; Tag Name<br />
: key of the tag inserted into the tag stream<br />
<br />
== Example Flowgraph ==<br />
<br />
This flowgraph is taken from the [[Packet_Communications]] tutorial.<br />
<br />
[[File:Pkt_rcv_fg.png|800px]]<br />
<br />
== Source Files ==<br />
<br />
; C++ files<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/correlate_access_code_bb_ts_impl.cc]<br />
<br />
; Header files<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/correlate_access_code_bb_ts_impl.cc]<br />
<br />
; Public header files<br />
: [https://github.com/gnuradio/gnuradio TODO]<br />
<br />
; Block definition<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-digital/grc/digital_correlate_access_code_xx_ts.block.yml]</div>Willcode4https://wiki.gnuradio.org/index.php?title=Soapy&diff=12390Soapy2022-07-25T18:18:04Z<p>Willcode4: /* Versions */</p>
<hr />
<div>This functionality is available as an in-tree module in GNU Radio versions 3.10 and higher (TBD also in a future 3.9 release).<br />
== SoapySDR ==<br />
[https://github.com/pothosware/SoapySDR/wiki SoapySDR] is the driver subsystem in the [http://www.pothosware.com/ Pothosware] ecosystem. It provides a specification for drivers, and a management layer required to use them. Individual drivers are dynamically linked, discovered, and loaded, so they can be maintained independently of the SoapySDR user (GNU Radio in this case).<br />
<br />
== gr-soapy ==<br />
The gr-soapy module wraps SoapySDR, allowing it to be used in GNU Radio. The original version was developed by [https://libre.space/ Libre Space Foundation]. Note that the in-tree version provided with GNU Radio performs the same function as the Libre Space version, but the code has been revamped and is not API compatible. It should be straightforward to port existing applications.<br />
<br />
== Architecture ==<br />
=== User Application ===<br />
Your Python or C++ application, or one generated by GRC, uses the gr-soapy module built into GNU Radio. It specifies the name of the driver and a set of driver, stream and other option parameters. At runtime, some parameters (e.g., frequency, gains) can be adjusted via setters.<br />
=== GNU Radio gr-soapy ===<br />
The SoapySDR "wrapper" module built into GNU Radio, providing the soapy::source and soapy::sink blocks. These blocks are usable from Python or C++. If a recent enough version of SoapySDR is available on the build system when GNU Radio is configured, this module will be included by default.<br />
<br />
=== SoapySDR ===<br />
A specification and driver management [https://github.com/pothosware/SoapySDR/wiki layer], not part of GNU Radio. This package is SoapySDR-devel on RPM-based systems, or libsoapysdr-dev on DEB-based systems. It is also easy to build and install manually, and has a PyBOMBS recipe. See section on versions below.<br />
<br />
=== SoapySDR Driver ===<br />
Individual SoapySDR drivers, not part of GNU Radio, are dynamically loaded modules. There is one module for each type of hardware. These modules are typically built atop a vendor-supplied hardware support library. For example, [https://github.com/pothosware/SoapyRTLSDR SoapyRTLSDR]. These modules are available from distro repos, or can be built manually. Many have PyBOMBS recipes.<br />
<br />
=== Hardware Support Library ===<br />
A vendor or other developer provides the low-level package required to talk directly to hardware. For example, the rtl-sdr library. These libraries are usually in distro or vendor repos. Many have PyBOMBS recipes.<br />
<br />
== GRC YAML Blocks ==<br />
'''Deprecation Warning''': The original all-in-one GRC Soapy Source and Soapy Sink YAML blocks will likely be removed before 3.10.0 and 3.9.2.<br />
<br />
This stack is hardware-independent, from the GNU Radio point of view. In the underlying C++ code, there are only generic source and sink blocks. From the GRC (GUI/code generator) point of view, Source and Sink blocks are specified in YAML format. For example the rtlsdr source is specified in '''soapy_rtlsdr_source.block.yml'''. These GRC YAML blocks contain the logic needed to operate specific SDR hardware.<br />
<br />
A set of simple, single-channel source and sink GRC yml blocks is provided. These should be useful for many users.<br />
<br />
* Sources: AirspyHF, BladeRF, HackRF, LimeSDR, PLUTO, RTLSDR, SDRPlay<br />
* Sinks: BladeRF, HackRF, LimeSDR, PLUTO<br />
<br />
While there is a UHD driver for SoapySDR, GNU Radio's built-in gr-uhd is recommended and well maintained.<br />
<br />
All of these drivers have PyBOMBS recipes. LimeSDR support is part of LimeSuite. SoapySDRPlay requires prior manual installation of the vendor service (API v3).<br />
<br />
Generic source and sink GRC yml blocks from the original implementation are provided. These are a bit more complicated to use, but give access to additional parameters. It is likely that these GRC yml blocks will be removed in the future, as the device-specific blocks are fleshed out.<br />
<br />
Custom Source and Custom Sink GRC yml blocks allow the user to use any SoapySDR driver available on the system. These blocks support one- or two-channel modes.<br />
<br />
Users may create their own or modified GRC yml blocks (use a different name!) and put them in '''~/.grc_gnuradio'''. This allows for the addition of functionality or new driver modules. The yml block files are small, and fairly easy to write.<br />
<br />
== Messages ==<br />
Source and Sink blocks accept messages on the '''cmd''' port. Messages are in PMT dict format, and contain the following keys:<br />
* chan: specifies the channel to which the message applies. Omit to affect all channels or if there is only one channel (common case).<br />
* freq: tune frequency (double)<br />
* gain: overall gain setting (float)<br />
* antenna: antenna name (string)<br />
* rate: sample rate (double)<br />
* bandwidth: filter bandwidth (double)<br />
<br />
Multiple keys may be present in one message. Behavior is somewhat dependent on the driver.<br />
<br />
== Versions ==<br />
Currently, SoapySDR 0.7.2 or higher is required. Note that Ubuntu 18.04 and Debian 10 provide an older version. Recent Ubuntu and Fedora releases provide a new enough version.<br />
<br />
SoapySDR driver modules will be loaded only if the ABI version number (e.g., 0.7) matches. A change in API version may not result in a change in ABI version. In the 0.7.x series, the ABI version was always 0.7. Be aware, however, ABI versions on the v0.8 development branch have changed more frequently. For instance ABIs 0.8, 0.8-1 and 0.8-2 are not compatible.<br />
<br />
If building SoapySDR from source, especially for use with a pre-packaged GNU Radio release, use the SoapySDR `maint` branch.<br />
<br />
== Debugging ==<br />
<br />
The GNU Radio gr-soapy module depends on a working installation of SoapySDR and drivers. If something is not working, verify the following first:<br />
<br />
* Use '''SoapySDRUtil --info''' to see info on the SoapySDR installation. Version should match the one used to build GNU Radio. Driver modules (shared objects) and the associated factories (device types) are shown. Verify that the required modules are shown, and that the listed module directories match the expected installation paths for any modules built from source.<br />
<br />
* '''SoapySDRUtil --find''' will look for hardware matching the available drivers. The keywords shown can be used as device args in case there are multiple SDRs of the same type on the system.<br />
<br />
* '''SoapySDRUtil --probe=driver=rtlsdr''', or a similar command for other drivers, returns detailed information about a device. Valid sample rates, bandwidths, and gains are shown. Note that the GRC blocks may not use all of the features shown. For example, simple versions of GRC blocks may use single frequency or gain values instead of allowing control over specific tuning or gain elements.<br />
<br />
* Make sure that the SoapySDR device can be opened for use, using '''SoapySDRUtil --make=driver=rtlsdr'''. Solve any permission problems, e.g. with USB.<br />
<br />
* Check that '''gnuradio-config-info --enabled-components''' includes '''gr-soapy'''.<br />
<br />
== gr-osmosdr ==<br />
<br />
gr-osmosdr is a popular SDR abstraction layer, so why not bring that module in-tree?<br />
<br />
This has more to do with GNU Radio maintainability than it does with any technical capability. In the stack described above, SoapySDR modules are tightly coupled to hardware support libraries, but are runtime discoverable and loadable with respect to gr-soapy. In gr-osmosdr, the equivalent modules are built-in. Bringing gr-osmosdr in-tree would place a lot of hardware knowledge in the GNU Radio code base, adding additional maintenance work and making all of the hardware support libraries direct dependencies. We recommend both gr-soapy and gr-osmosdr, and users can chose the driver framework that best meets their needs.<br />
<br />
== soapy via gr-osmosdr ==<br />
<br />
gr-osmosdr provides a separate path to SoapySDR drivers. When devices are accessed through gr-osmosdr using a driver specification like:<br />
<br />
'''driver=hackrf,soapy=0'''<br />
<br />
the stack is:<br />
<br />
* GNU Radio runtime and GRC<br />
* gr-osmosdr out-of-tree module<br />
* SoapySDR framework<br />
* SoapySDR driver module<br />
* Hardware support library<br />
<br />
The SoapySDRUtil utility can still be used to determine whether SoapySDR drivers are installed and functional.</div>Willcode4https://wiki.gnuradio.org/index.php?title=Soapy&diff=12369Soapy2022-07-14T18:56:31Z<p>Willcode4: /* Versions */</p>
<hr />
<div>This functionality is available as an in-tree module in GNU Radio versions 3.10 and higher (TBD also in a future 3.9 release).<br />
== SoapySDR ==<br />
[https://github.com/pothosware/SoapySDR/wiki SoapySDR] is the driver subsystem in the [http://www.pothosware.com/ Pothosware] ecosystem. It provides a specification for drivers, and a management layer required to use them. Individual drivers are dynamically linked, discovered, and loaded, so they can be maintained independently of the SoapySDR user (GNU Radio in this case).<br />
<br />
== gr-soapy ==<br />
The gr-soapy module wraps SoapySDR, allowing it to be used in GNU Radio. The original version was developed by [https://libre.space/ Libre Space Foundation]. Note that the in-tree version provided with GNU Radio performs the same function as the Libre Space version, but the code has been revamped and is not API compatible. It should be straightforward to port existing applications.<br />
<br />
== Architecture ==<br />
=== User Application ===<br />
Your Python or C++ application, or one generated by GRC, uses the gr-soapy module built into GNU Radio. It specifies the name of the driver and a set of driver, stream and other option parameters. At runtime, some parameters (e.g., frequency, gains) can be adjusted via setters.<br />
=== GNU Radio gr-soapy ===<br />
The SoapySDR "wrapper" module built into GNU Radio, providing the soapy::source and soapy::sink blocks. These blocks are usable from Python or C++. If a recent enough version of SoapySDR is available on the build system when GNU Radio is configured, this module will be included by default.<br />
<br />
=== SoapySDR ===<br />
A specification and driver management [https://github.com/pothosware/SoapySDR/wiki layer], not part of GNU Radio. This package is SoapySDR-devel on RPM-based systems, or libsoapysdr-dev on DEB-based systems. It is also easy to build and install manually, and has a PyBOMBS recipe. See section on versions below.<br />
<br />
=== SoapySDR Driver ===<br />
Individual SoapySDR drivers, not part of GNU Radio, are dynamically loaded modules. There is one module for each type of hardware. These modules are typically built atop a vendor-supplied hardware support library. For example, [https://github.com/pothosware/SoapyRTLSDR SoapyRTLSDR]. These modules are available from distro repos, or can be built manually. Many have PyBOMBS recipes.<br />
<br />
=== Hardware Support Library ===<br />
A vendor or other developer provides the low-level package required to talk directly to hardware. For example, the rtl-sdr library. These libraries are usually in distro or vendor repos. Many have PyBOMBS recipes.<br />
<br />
== GRC YAML Blocks ==<br />
'''Deprecation Warning''': The original all-in-one GRC Soapy Source and Soapy Sink YAML blocks will likely be removed before 3.10.0 and 3.9.2.<br />
<br />
This stack is hardware-independent, from the GNU Radio point of view. In the underlying C++ code, there are only generic source and sink blocks. From the GRC (GUI/code generator) point of view, Source and Sink blocks are specified in YAML format. For example the rtlsdr source is specified in '''soapy_rtlsdr_source.block.yml'''. These GRC YAML blocks contain the logic needed to operate specific SDR hardware.<br />
<br />
A set of simple, single-channel source and sink GRC yml blocks is provided. These should be useful for many users.<br />
<br />
* Sources: AirspyHF, BladeRF, HackRF, LimeSDR, PLUTO, RTLSDR, SDRPlay<br />
* Sinks: BladeRF, HackRF, LimeSDR, PLUTO<br />
<br />
While there is a UHD driver for SoapySDR, GNU Radio's built-in gr-uhd is recommended and well maintained.<br />
<br />
All of these drivers have PyBOMBS recipes. LimeSDR support is part of LimeSuite. SoapySDRPlay requires prior manual installation of the vendor service (API v3).<br />
<br />
Generic source and sink GRC yml blocks from the original implementation are provided. These are a bit more complicated to use, but give access to additional parameters. It is likely that these GRC yml blocks will be removed in the future, as the device-specific blocks are fleshed out.<br />
<br />
Custom Source and Custom Sink GRC yml blocks allow the user to use any SoapySDR driver available on the system. These blocks support one- or two-channel modes.<br />
<br />
Users may create their own or modified GRC yml blocks (use a different name!) and put them in '''~/.grc_gnuradio'''. This allows for the addition of functionality or new driver modules. The yml block files are small, and fairly easy to write.<br />
<br />
== Messages ==<br />
Source and Sink blocks accept messages on the '''cmd''' port. Messages are in PMT dict format, and contain the following keys:<br />
* chan: specifies the channel to which the message applies. Omit to affect all channels or if there is only one channel (common case).<br />
* freq: tune frequency (double)<br />
* gain: overall gain setting (float)<br />
* antenna: antenna name (string)<br />
* rate: sample rate (double)<br />
* bandwidth: filter bandwidth (double)<br />
<br />
Multiple keys may be present in one message. Behavior is somewhat dependent on the driver.<br />
<br />
== Versions ==<br />
Currently, SoapySDR 0.7.2 or higher is required. Note that Ubuntu 18.04 and Debian 10 provide an older version. Recent Ubuntu and Fedora releases provide a new enough version.<br />
<br />
SoapySDR driver modules will be loaded only if the ABI version number (e.g., 0.7) matches. A change in API version may not result in a change in ABI version. In the 0.7.x series, the ABI version was always 0.7. Be aware, however, ABI versions on the v0.8 development branch have changed more frequently. For instance ABIs 0.8, 0.8-1 and 0.8-2 are not compatible.<br />
<br />
== Debugging ==<br />
<br />
The GNU Radio gr-soapy module depends on a working installation of SoapySDR and drivers. If something is not working, verify the following first:<br />
<br />
* Use '''SoapySDRUtil --info''' to see info on the SoapySDR installation. Version should match the one used to build GNU Radio. Driver modules (shared objects) and the associated factories (device types) are shown. Verify that the required modules are shown, and that the listed module directories match the expected installation paths for any modules built from source.<br />
<br />
* '''SoapySDRUtil --find''' will look for hardware matching the available drivers. The keywords shown can be used as device args in case there are multiple SDRs of the same type on the system.<br />
<br />
* '''SoapySDRUtil --probe=driver=rtlsdr''', or a similar command for other drivers, returns detailed information about a device. Valid sample rates, bandwidths, and gains are shown. Note that the GRC blocks may not use all of the features shown. For example, simple versions of GRC blocks may use single frequency or gain values instead of allowing control over specific tuning or gain elements.<br />
<br />
* Make sure that the SoapySDR device can be opened for use, using '''SoapySDRUtil --make=driver=rtlsdr'''. Solve any permission problems, e.g. with USB.<br />
<br />
* Check that '''gnuradio-config-info --enabled-components''' includes '''gr-soapy'''.<br />
<br />
== gr-osmosdr ==<br />
<br />
gr-osmosdr is a popular SDR abstraction layer, so why not bring that module in-tree?<br />
<br />
This has more to do with GNU Radio maintainability than it does with any technical capability. In the stack described above, SoapySDR modules are tightly coupled to hardware support libraries, but are runtime discoverable and loadable with respect to gr-soapy. In gr-osmosdr, the equivalent modules are built-in. Bringing gr-osmosdr in-tree would place a lot of hardware knowledge in the GNU Radio code base, adding additional maintenance work and making all of the hardware support libraries direct dependencies. We recommend both gr-soapy and gr-osmosdr, and users can chose the driver framework that best meets their needs.<br />
<br />
== soapy via gr-osmosdr ==<br />
<br />
gr-osmosdr provides a separate path to SoapySDR drivers. When devices are accessed through gr-osmosdr using a driver specification like:<br />
<br />
'''driver=hackrf,soapy=0'''<br />
<br />
the stack is:<br />
<br />
* GNU Radio runtime and GRC<br />
* gr-osmosdr out-of-tree module<br />
* SoapySDR framework<br />
* SoapySDR driver module<br />
* Hardware support library<br />
<br />
The SoapySDRUtil utility can still be used to determine whether SoapySDR drivers are installed and functional.</div>Willcode4https://wiki.gnuradio.org/index.php?title=Soapy&diff=12368Soapy2022-07-14T18:46:21Z<p>Willcode4: /* Versions */</p>
<hr />
<div>This functionality is available as an in-tree module in GNU Radio versions 3.10 and higher (TBD also in a future 3.9 release).<br />
== SoapySDR ==<br />
[https://github.com/pothosware/SoapySDR/wiki SoapySDR] is the driver subsystem in the [http://www.pothosware.com/ Pothosware] ecosystem. It provides a specification for drivers, and a management layer required to use them. Individual drivers are dynamically linked, discovered, and loaded, so they can be maintained independently of the SoapySDR user (GNU Radio in this case).<br />
<br />
== gr-soapy ==<br />
The gr-soapy module wraps SoapySDR, allowing it to be used in GNU Radio. The original version was developed by [https://libre.space/ Libre Space Foundation]. Note that the in-tree version provided with GNU Radio performs the same function as the Libre Space version, but the code has been revamped and is not API compatible. It should be straightforward to port existing applications.<br />
<br />
== Architecture ==<br />
=== User Application ===<br />
Your Python or C++ application, or one generated by GRC, uses the gr-soapy module built into GNU Radio. It specifies the name of the driver and a set of driver, stream and other option parameters. At runtime, some parameters (e.g., frequency, gains) can be adjusted via setters.<br />
=== GNU Radio gr-soapy ===<br />
The SoapySDR "wrapper" module built into GNU Radio, providing the soapy::source and soapy::sink blocks. These blocks are usable from Python or C++. If a recent enough version of SoapySDR is available on the build system when GNU Radio is configured, this module will be included by default.<br />
<br />
=== SoapySDR ===<br />
A specification and driver management [https://github.com/pothosware/SoapySDR/wiki layer], not part of GNU Radio. This package is SoapySDR-devel on RPM-based systems, or libsoapysdr-dev on DEB-based systems. It is also easy to build and install manually, and has a PyBOMBS recipe. See section on versions below.<br />
<br />
=== SoapySDR Driver ===<br />
Individual SoapySDR drivers, not part of GNU Radio, are dynamically loaded modules. There is one module for each type of hardware. These modules are typically built atop a vendor-supplied hardware support library. For example, [https://github.com/pothosware/SoapyRTLSDR SoapyRTLSDR]. These modules are available from distro repos, or can be built manually. Many have PyBOMBS recipes.<br />
<br />
=== Hardware Support Library ===<br />
A vendor or other developer provides the low-level package required to talk directly to hardware. For example, the rtl-sdr library. These libraries are usually in distro or vendor repos. Many have PyBOMBS recipes.<br />
<br />
== GRC YAML Blocks ==<br />
'''Deprecation Warning''': The original all-in-one GRC Soapy Source and Soapy Sink YAML blocks will likely be removed before 3.10.0 and 3.9.2.<br />
<br />
This stack is hardware-independent, from the GNU Radio point of view. In the underlying C++ code, there are only generic source and sink blocks. From the GRC (GUI/code generator) point of view, Source and Sink blocks are specified in YAML format. For example the rtlsdr source is specified in '''soapy_rtlsdr_source.block.yml'''. These GRC YAML blocks contain the logic needed to operate specific SDR hardware.<br />
<br />
A set of simple, single-channel source and sink GRC yml blocks is provided. These should be useful for many users.<br />
<br />
* Sources: AirspyHF, BladeRF, HackRF, LimeSDR, PLUTO, RTLSDR, SDRPlay<br />
* Sinks: BladeRF, HackRF, LimeSDR, PLUTO<br />
<br />
While there is a UHD driver for SoapySDR, GNU Radio's built-in gr-uhd is recommended and well maintained.<br />
<br />
All of these drivers have PyBOMBS recipes. LimeSDR support is part of LimeSuite. SoapySDRPlay requires prior manual installation of the vendor service (API v3).<br />
<br />
Generic source and sink GRC yml blocks from the original implementation are provided. These are a bit more complicated to use, but give access to additional parameters. It is likely that these GRC yml blocks will be removed in the future, as the device-specific blocks are fleshed out.<br />
<br />
Custom Source and Custom Sink GRC yml blocks allow the user to use any SoapySDR driver available on the system. These blocks support one- or two-channel modes.<br />
<br />
Users may create their own or modified GRC yml blocks (use a different name!) and put them in '''~/.grc_gnuradio'''. This allows for the addition of functionality or new driver modules. The yml block files are small, and fairly easy to write.<br />
<br />
== Messages ==<br />
Source and Sink blocks accept messages on the '''cmd''' port. Messages are in PMT dict format, and contain the following keys:<br />
* chan: specifies the channel to which the message applies. Omit to affect all channels or if there is only one channel (common case).<br />
* freq: tune frequency (double)<br />
* gain: overall gain setting (float)<br />
* antenna: antenna name (string)<br />
* rate: sample rate (double)<br />
* bandwidth: filter bandwidth (double)<br />
<br />
Multiple keys may be present in one message. Behavior is somewhat dependent on the driver.<br />
<br />
== Versions ==<br />
Currently, SoapySDR 0.7.2 or higher is required. Note that Ubuntu 18.04 and Debian 10 provide an older version. Recent Ubuntu and Fedora releases provide a new enough version.<br />
<br />
SoapySDR driver modules will be loaded only if the ABI version number (e.g., 0.7) matches. A change in API version may not result in a change in ABI version. In the 0.7.x series, the ABI version was always 0.7. However, in the 0.8.x series, ABI versions have changed more frequently. For instance ABI 0.8-1 and 0.8-2 are not compatible.<br />
<br />
== Debugging ==<br />
<br />
The GNU Radio gr-soapy module depends on a working installation of SoapySDR and drivers. If something is not working, verify the following first:<br />
<br />
* Use '''SoapySDRUtil --info''' to see info on the SoapySDR installation. Version should match the one used to build GNU Radio. Driver modules (shared objects) and the associated factories (device types) are shown. Verify that the required modules are shown, and that the listed module directories match the expected installation paths for any modules built from source.<br />
<br />
* '''SoapySDRUtil --find''' will look for hardware matching the available drivers. The keywords shown can be used as device args in case there are multiple SDRs of the same type on the system.<br />
<br />
* '''SoapySDRUtil --probe=driver=rtlsdr''', or a similar command for other drivers, returns detailed information about a device. Valid sample rates, bandwidths, and gains are shown. Note that the GRC blocks may not use all of the features shown. For example, simple versions of GRC blocks may use single frequency or gain values instead of allowing control over specific tuning or gain elements.<br />
<br />
* Make sure that the SoapySDR device can be opened for use, using '''SoapySDRUtil --make=driver=rtlsdr'''. Solve any permission problems, e.g. with USB.<br />
<br />
* Check that '''gnuradio-config-info --enabled-components''' includes '''gr-soapy'''.<br />
<br />
== gr-osmosdr ==<br />
<br />
gr-osmosdr is a popular SDR abstraction layer, so why not bring that module in-tree?<br />
<br />
This has more to do with GNU Radio maintainability than it does with any technical capability. In the stack described above, SoapySDR modules are tightly coupled to hardware support libraries, but are runtime discoverable and loadable with respect to gr-soapy. In gr-osmosdr, the equivalent modules are built-in. Bringing gr-osmosdr in-tree would place a lot of hardware knowledge in the GNU Radio code base, adding additional maintenance work and making all of the hardware support libraries direct dependencies. We recommend both gr-soapy and gr-osmosdr, and users can chose the driver framework that best meets their needs.<br />
<br />
== soapy via gr-osmosdr ==<br />
<br />
gr-osmosdr provides a separate path to SoapySDR drivers. When devices are accessed through gr-osmosdr using a driver specification like:<br />
<br />
'''driver=hackrf,soapy=0'''<br />
<br />
the stack is:<br />
<br />
* GNU Radio runtime and GRC<br />
* gr-osmosdr out-of-tree module<br />
* SoapySDR framework<br />
* SoapySDR driver module<br />
* Hardware support library<br />
<br />
The SoapySDRUtil utility can still be used to determine whether SoapySDR drivers are installed and functional.</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=12323ReleaseProcess2022-06-01T16:02:29Z<p>Willcode4: /* Release commit */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
Cherry picking, using the -xs flags, automatically adds a cross reference, for example<br />
<br />
commit bc21cf1f9ca25dd3efcbc9806cee4f6c1726a905<br />
Author: Marcus Müller <mmueller@gnuradio.org><br />
Date: Sun Aug 15 18:54:10 2021 +0200<br />
<br />
audio/jack: to_string is no longer part of boost:: NS, instead use std::<br />
<br />
Signed-off-by: Marcus Müller <mmueller@gnuradio.org><br />
(cherry picked from commit 883315208853121a8dfa68ae9c2f74400acd5ac5)<br />
Signed-off-by: Jeff Long <willcode4@gmail.com><br />
<br />
For other commits, add cross references to '''Git commits only''', not to PRs. The<br />
git repo should stand on its own. At the very least, explain how a commit relates to<br />
any work on the master branch.<br />
<br />
Backported PRs should reference the original PRs like this<br />
Backport #1234<br />
at the bottom of the description.<br />
<br />
== Change freeze ==<br />
About 2-3 weeks before release. This is informal. Accept only critical or very low risk<br />
changes at this point.<br />
<br />
=== Announce ===<br />
Mention on the Development and General Chat channels on Matrix.<br />
At this point, the mailing list is more for communicating with users than with core<br />
developers, so announcements there would not be useful, and could result in solicitation<br />
of extra PRs exactly when we are not going to consider them.<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
About 1 week before release.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Generate <code>.zenodo.json</code><br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `0-rc1` format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1" (*)<br />
* Merge release PR (*)<br />
* Sync local checkout for later comparison step<br />
<br />
(*) These steps can be replaced by directly pushing to the maint-X.Y branch without a PR (but with extra care required).<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
The GPG key includes a signing subkey, which is used to sign releases. The master key<br />
is used only for certifying subkeys.<br />
<br />
Currently, the signing subkey expiration date is extended a year at a time, as long as there<br />
are no personnel changes and the key remains secure.<br />
<br />
=== Download tar.gz and zip ===<br />
If not done in release step<br />
<br />
=== Verify archives ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign archives ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
Add articles to the news section on the wiki<br />
https://github.com/gnuradio/hugo-website#how-to-add-stuff-to-the-website<br />
<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=12322ReleaseProcess2022-06-01T16:01:52Z<p>Willcode4: /* Release commit */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
Cherry picking, using the -xs flags, automatically adds a cross reference, for example<br />
<br />
commit bc21cf1f9ca25dd3efcbc9806cee4f6c1726a905<br />
Author: Marcus Müller <mmueller@gnuradio.org><br />
Date: Sun Aug 15 18:54:10 2021 +0200<br />
<br />
audio/jack: to_string is no longer part of boost:: NS, instead use std::<br />
<br />
Signed-off-by: Marcus Müller <mmueller@gnuradio.org><br />
(cherry picked from commit 883315208853121a8dfa68ae9c2f74400acd5ac5)<br />
Signed-off-by: Jeff Long <willcode4@gmail.com><br />
<br />
For other commits, add cross references to '''Git commits only''', not to PRs. The<br />
git repo should stand on its own. At the very least, explain how a commit relates to<br />
any work on the master branch.<br />
<br />
Backported PRs should reference the original PRs like this<br />
Backport #1234<br />
at the bottom of the description.<br />
<br />
== Change freeze ==<br />
About 2-3 weeks before release. This is informal. Accept only critical or very low risk<br />
changes at this point.<br />
<br />
=== Announce ===<br />
Mention on the Development and General Chat channels on Matrix.<br />
At this point, the mailing list is more for communicating with users than with core<br />
developers, so announcements there would not be useful, and could result in solicitation<br />
of extra PRs exactly when we are not going to consider them.<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
About 1 week before release.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Generate <code>.zenodo.json<code><br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `0-rc1` format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1" (*)<br />
* Merge release PR (*)<br />
* Sync local checkout for later comparison step<br />
<br />
(*) These steps can be replaced by directly pushing to the maint-X.Y branch without a PR (but with extra care required).<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
The GPG key includes a signing subkey, which is used to sign releases. The master key<br />
is used only for certifying subkeys.<br />
<br />
Currently, the signing subkey expiration date is extended a year at a time, as long as there<br />
are no personnel changes and the key remains secure.<br />
<br />
=== Download tar.gz and zip ===<br />
If not done in release step<br />
<br />
=== Verify archives ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign archives ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
Add articles to the news section on the wiki<br />
https://github.com/gnuradio/hugo-website#how-to-add-stuff-to-the-website<br />
<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=12170ReleaseProcess2022-04-01T01:00:08Z<p>Willcode4: /* Release commit */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
Cherry picking, using the -xs flags, automatically adds a cross reference, for example<br />
<br />
commit bc21cf1f9ca25dd3efcbc9806cee4f6c1726a905<br />
Author: Marcus Müller <mmueller@gnuradio.org><br />
Date: Sun Aug 15 18:54:10 2021 +0200<br />
<br />
audio/jack: to_string is no longer part of boost:: NS, instead use std::<br />
<br />
Signed-off-by: Marcus Müller <mmueller@gnuradio.org><br />
(cherry picked from commit 883315208853121a8dfa68ae9c2f74400acd5ac5)<br />
Signed-off-by: Jeff Long <willcode4@gmail.com><br />
<br />
For other commits, add cross references to '''Git commits only''', not to PRs. The<br />
git repo should stand on its own. At the very least, explain how a commit relates to<br />
any work on the master branch.<br />
<br />
Backported PRs should reference the original PRs like this<br />
Backport #1234<br />
at the bottom of the description.<br />
<br />
== Change freeze ==<br />
About 2-3 weeks before release. This is informal. Accept only critical or very low risk<br />
changes at this point.<br />
<br />
=== Announce ===<br />
Mention on the Development and General Chat channels on Matrix.<br />
At this point, the mailing list is more for communicating with users than with core<br />
developers, so announcements there would not be useful, and could result in solicitation<br />
of extra PRs exactly when we are not going to consider them.<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
About 1 week before release.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `0-rc1` format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1" (*)<br />
* Merge release PR (*)<br />
* Sync local checkout for later comparison step<br />
<br />
(*) These steps can be replaced by directly pushing to the maint-X.Y branch without a PR (but with extra care required).<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
The GPG key includes a signing subkey, which is used to sign releases. The master key<br />
is used only for certifying subkeys.<br />
<br />
Currently, the signing subkey expiration date is extended a year at a time, as long as there<br />
are no personnel changes and the key remains secure.<br />
<br />
=== Download tar.gz and zip ===<br />
If not done in release step<br />
<br />
=== Verify archives ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign archives ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
Add articles to the news section on the wiki<br />
https://github.com/gnuradio/hugo-website#how-to-add-stuff-to-the-website<br />
<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=Threshold&diff=9336Threshold2021-12-18T13:37:51Z<p>Willcode4: /* Simple Example */</p>
<hr />
<div>[[Category:Block Docs]]<br />
Output a 1 or zero based on a threshold value.<br />
<br />
Test the incoming signal against a threshold. If the signal<br />
excedes the High value, it will change its output to 1, and if the signal<br />
falls below the Low value, it will change its output to 0.<br />
<br />
== Parameters ==<br />
(''R''): <span class="plainlinks">[https://wiki.gnuradio.org/index.php/GNURadioCompanion#Variable_Controls ''Run-time adjustable'']</span><br />
<br />
; Low (''R'')<br />
: Low threshold. Outputs 0 if input goes below it<br />
<br />
; High (''R'')<br />
: High threshold. Outputs 1 if input goes above it<br />
<br />
; Initial value<br />
: Value to output before the input reach one of the thresholds. Can be any value, not just 0 or 1.<br />
<br />
== Example Flowgraphs ==<br />
<br />
=== Simple Example ===<br />
<br />
This flowgraph can be found at [[Media:threshold_example.grc]]<br />
<br />
[[File:Threshold_Example.png|800px]]<br />
<br />
[[File:Threshold_Result.png]]<br />
<br />
=== Advanced Example ===<br />
<br />
This flowgraph can be found at [https://raw.githubusercontent.com/gnuradio/gnuradio/master/gr-pdu/examples/tags_to_pdu_example.grc]<br />
<br />
[[File:Tags_to_pdu_fg.png|800px]]<br />
<br />
== Source Files ==<br />
<br />
; C++ files<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/threshold_ff_impl.cc Here]<br />
<br />
; Header files<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/threshold_ff_impl.h Here]<br />
<br />
; Public header files<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/include/gnuradio/blocks/threshold_ff.h Here]<br />
<br />
; Block definition<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/grc/blocks_threshold_ff.block.yml Yaml]</div>Willcode4https://wiki.gnuradio.org/index.php?title=File:Threshold_Result.png&diff=9335File:Threshold Result.png2021-12-18T13:36:24Z<p>Willcode4: </p>
<hr />
<div></div>Willcode4https://wiki.gnuradio.org/index.php?title=Threshold&diff=9334Threshold2021-12-18T13:00:27Z<p>Willcode4: /* Simple Example */</p>
<hr />
<div>[[Category:Block Docs]]<br />
Output a 1 or zero based on a threshold value.<br />
<br />
Test the incoming signal against a threshold. If the signal<br />
excedes the High value, it will change its output to 1, and if the signal<br />
falls below the Low value, it will change its output to 0.<br />
<br />
== Parameters ==<br />
(''R''): <span class="plainlinks">[https://wiki.gnuradio.org/index.php/GNURadioCompanion#Variable_Controls ''Run-time adjustable'']</span><br />
<br />
; Low (''R'')<br />
: Low threshold. Outputs 0 if input goes below it<br />
<br />
; High (''R'')<br />
: High threshold. Outputs 1 if input goes above it<br />
<br />
; Initial value<br />
: Value to output before the input reach one of the thresholds. Can be any value, not just 0 or 1.<br />
<br />
== Example Flowgraphs ==<br />
<br />
=== Simple Example ===<br />
<br />
This flowgraph can be found at [[Media:threshold_example.grc]]<br />
<br />
[[File:Threshold_Example.png|800px]]<br />
<br />
=== Advanced Example ===<br />
<br />
This flowgraph can be found at [https://raw.githubusercontent.com/gnuradio/gnuradio/master/gr-pdu/examples/tags_to_pdu_example.grc]<br />
<br />
[[File:Tags_to_pdu_fg.png|800px]]<br />
<br />
== Source Files ==<br />
<br />
; C++ files<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/threshold_ff_impl.cc Here]<br />
<br />
; Header files<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/threshold_ff_impl.h Here]<br />
<br />
; Public header files<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/include/gnuradio/blocks/threshold_ff.h Here]<br />
<br />
; Block definition<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/grc/blocks_threshold_ff.block.yml Yaml]</div>Willcode4https://wiki.gnuradio.org/index.php?title=Threshold&diff=9333Threshold2021-12-18T12:59:45Z<p>Willcode4: /* Simple Example */</p>
<hr />
<div>[[Category:Block Docs]]<br />
Output a 1 or zero based on a threshold value.<br />
<br />
Test the incoming signal against a threshold. If the signal<br />
excedes the High value, it will change its output to 1, and if the signal<br />
falls below the Low value, it will change its output to 0.<br />
<br />
== Parameters ==<br />
(''R''): <span class="plainlinks">[https://wiki.gnuradio.org/index.php/GNURadioCompanion#Variable_Controls ''Run-time adjustable'']</span><br />
<br />
; Low (''R'')<br />
: Low threshold. Outputs 0 if input goes below it<br />
<br />
; High (''R'')<br />
: High threshold. Outputs 1 if input goes above it<br />
<br />
; Initial value<br />
: Value to output before the input reach one of the thresholds. Can be any value, not just 0 or 1.<br />
<br />
== Example Flowgraphs ==<br />
<br />
=== Simple Example ===<br />
<br />
This flowgraph can be found at [[File:threshold_example.grc]]<br />
<br />
[[Media:Threshold_Example.png|800px]]<br />
<br />
=== Advanced Example ===<br />
<br />
This flowgraph can be found at [https://raw.githubusercontent.com/gnuradio/gnuradio/master/gr-pdu/examples/tags_to_pdu_example.grc]<br />
<br />
[[File:Tags_to_pdu_fg.png|800px]]<br />
<br />
== Source Files ==<br />
<br />
; C++ files<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/threshold_ff_impl.cc Here]<br />
<br />
; Header files<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/threshold_ff_impl.h Here]<br />
<br />
; Public header files<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/include/gnuradio/blocks/threshold_ff.h Here]<br />
<br />
; Block definition<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/grc/blocks_threshold_ff.block.yml Yaml]</div>Willcode4https://wiki.gnuradio.org/index.php?title=Threshold&diff=9332Threshold2021-12-18T12:56:57Z<p>Willcode4: /* Example Flowgraph */</p>
<hr />
<div>[[Category:Block Docs]]<br />
Output a 1 or zero based on a threshold value.<br />
<br />
Test the incoming signal against a threshold. If the signal<br />
excedes the High value, it will change its output to 1, and if the signal<br />
falls below the Low value, it will change its output to 0.<br />
<br />
== Parameters ==<br />
(''R''): <span class="plainlinks">[https://wiki.gnuradio.org/index.php/GNURadioCompanion#Variable_Controls ''Run-time adjustable'']</span><br />
<br />
; Low (''R'')<br />
: Low threshold. Outputs 0 if input goes below it<br />
<br />
; High (''R'')<br />
: High threshold. Outputs 1 if input goes above it<br />
<br />
; Initial value<br />
: Value to output before the input reach one of the thresholds. Can be any value, not just 0 or 1.<br />
<br />
== Example Flowgraphs ==<br />
<br />
=== Simple Example ===<br />
<br />
This flowgraph can be found at [[File:threshold_example.grc]]<br />
<br />
[[File:Threshold_Example.png|800px]]<br />
<br />
<br />
=== Advanced Example ===<br />
<br />
This flowgraph can be found at [https://raw.githubusercontent.com/gnuradio/gnuradio/master/gr-pdu/examples/tags_to_pdu_example.grc]<br />
<br />
[[File:Tags_to_pdu_fg.png|800px]]<br />
<br />
== Source Files ==<br />
<br />
; C++ files<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/threshold_ff_impl.cc Here]<br />
<br />
; Header files<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/threshold_ff_impl.h Here]<br />
<br />
; Public header files<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/include/gnuradio/blocks/threshold_ff.h Here]<br />
<br />
; Block definition<br />
: [https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/grc/blocks_threshold_ff.block.yml Yaml]</div>Willcode4https://wiki.gnuradio.org/index.php?title=File:Threshold_example.grc&diff=9331File:Threshold example.grc2021-12-18T12:52:41Z<p>Willcode4: </p>
<hr />
<div></div>Willcode4https://wiki.gnuradio.org/index.php?title=File:Threshold_Example.png&diff=9330File:Threshold Example.png2021-12-18T12:52:08Z<p>Willcode4: </p>
<hr />
<div></div>Willcode4https://wiki.gnuradio.org/index.php?title=Understanding_XMLRPC_Blocks&diff=9236Understanding XMLRPC Blocks2021-12-05T00:07:55Z<p>Willcode4: </p>
<hr />
<div><!-- Understanding_XMLRPC_Blocks.mediawiki --><br />
This tutorial presents the GNU Radio XMLRPC blocks. There are two blocks in this collection: [[XMLRPC_Client|'''XMLRPC Client''']] and [[XMLRPC_Server|'''XMLRPC Server''']]. Both blocks have IP address/port fields while the Client block also has callback and variable fields. The blocks use the Python XMLRPC module and use a subset of the full XMLRPC specification.<br />
<br />
XMLRPC is an '''XML'''-based '''R'''emote '''P'''rotocol '''C'''ontrol mechanism that does just that. It uses HTTP transport and allows a client to use SET commands to change parameters on a server or use GET commands to obtain the value of parameters on the server. <br />
<br />
To understand better how GNURadio implements XMLRPC, look at the block documentation linked in the paragraph above. <br />
<br />
To understand the XMLRPC protocol and Python implementation in detail, the reference links below are a good starting point.<br />
<br />
==Reference Links==<br />
http://xmlrpc.com<br />
<br />
https://docs.python.org/3.8/library/xmlrpc.html<br />
<br />
==Prerequisites==<br />
* [[Guided_Tutorial_GRC|Intro to GR usage: GRC and flowgraphs]]<br />
<br />
* [[Understanding_ZMQ_Blocks|Understanding ZMQ Blocks]]<br />
<br />
==Introduction: ''What does XMLRPC do in GNURadio and Why Should I Care?''==<br />
'''WHAT''': In GNURadio placing the XMLRPC Server block in a flowgraph will create an XMLRPC server that exposes all the variables in the flowgraph on the specified IP Address and Port. This allows a client to change them at runtime. The XMLRPC Client block allows the user to create a flowgraph that can control any of the parameters in a flowgraph that has the XMLRPC Server block.<br />
<br />
'''WHY''': In many cases, we want to adjust the variables of a GNURadio flowgraph at runtime. We usually do this by adding QT GUI Widget block (range, push button, etc). But what if you want to have the same control interface, but in a different flowgraph? XMLRPC will allow you to control all of a flowgraph's variables from a second flowgraph using HTTP. In fact, the second flowgraph doesn't even have to be on the same computer! Therefore, XMLRPC can be used to add runtime control of any flowgraph running on a remote system like a Raspberry PI, headless server or otherwise.<br />
<br />
== Overview of Tutorial ==<br />
<br />
'''GNURadio XMLRPC Examples'''<br />
<br />
*We will start with running the basic client/server example flowgraphs from the GNU Radio source tree ([https://github.com/gnuradio/gnuradio/tree/maint-3.9/gr-blocks/examples/xmlrpc gr-blocks/examples/xmlrpc]).<br />
<br />
'''GNURadio XMLRPC Examples with added ZMQ Streaming Data Visualization'''<br />
<br />
*Here we will modify the examples to include ZMQ streaming so we can visualize the remote flowgraph's datastream in our XMLRPC Client flowgraph.<br />
<br />
'''GNURadio XMLRPC Remote Control Over IP Network'''<br />
<br />
*Next, we will run the server/client pair over an IP network using 2 separate computers. (Requires 2 hosts on the same network with GNURadio 3.9+ installed)<br />
<br />
'''GNURadio XMLRPC Server Automation using Standalone Python Code'''<br />
<br />
*This section demonstrates the ability to automate our server flowgraph using a standalone python application.<br />
<br />
'''GNURadio XMLRPC Advanced Usage Example (OPTIONAL)'''<br />
<br />
* As a bonus step we will run a project that implements a remote, headless wideband RF receiver and stream the data to a Remote Controller for control and visualization.<br />
<br />
==GNURadio XMLRPC Examples==<br />
<br />
In GNURadio Companion:<br />
<br />
Open the [https://raw.githubusercontent.com/gnuradio/gnuradio/maint-3.9/gr-blocks/examples/xmlrpc/siggen_xmlrpc_server.grc siggen_xmlrpc_server.grc] flowgraph. <br />
<br />
Shown here:<br />
<br />
[[File:Xmlrpc_server.png]]<br />
<br />
In GNURadio Companion:<br />
<br />
Open the [https://raw.githubusercontent.com/gnuradio/gnuradio/maint-3.9/gr-blocks/examples/xmlrpc/siggen_controller_xmlrpc_client.grc siggen_controller_xmlrpc_client.grc] flowgraph <br />
<br />
Shown here:<br />
<br />
[[File:Xmlrpc_client.png]]<br />
<br />
<br />
First, click on the tab in GRC that has the Siggen Server Flowgraph and start it by clicking the 'RUN' button.<br />
<br />
Your GUI window should look like this:<br />
<br />
[[File:Xmlrpc_server_before.png]]<br />
<br />
Next, click on the tab in GRC that has the tab for the the Siggen Controller flowgraph and start it by clicking the 'RUN' button.<br />
<br />
Your GUI window should look like this:<br />
<br />
[[File:Xmlrpc_freq_slider.png]]<br />
<br />
Arrange both GUI windows so you can see them at the same time.<br />
<br />
In the Siggen Controller Flowgraph Move the Frequency Slider slightly to the left and observe the Siggen Server time/frequency display. You should see the frequency changing as shown here:<br />
<br />
[[File:Xmlrpc_server_after.png]]<br />
<br />
That's it, you've just remote controlled a flowgraph over a network socket!<br />
<br />
Close both GUI windows and continue to the next section.<br />
<br />
==GNURadio XMLRPC Examples with ZMQ Streaming Data Visualization==<br />
Make sure you are familiar with ZMQ streaming from the [[Understanding_ZMQ_Blocks|ZMQ tutorials]].<br />
<br />
*Create a copy ('save as') of both XMLRPC example flowgraphs and name them:<br />
<br />
"siggen_xmlrpc_server_streaming.grc"<br />
"siggen_controller_xmlrpc_client_streaming.grc"<br />
<br />
(don't forget to change the names in the 'ID' of the 'Options' block to match the new .grc filenames)<br />
<br />
*In the Streaming Server Flowgraph, copy the throttle and GUI display blocks, then paste them into the Streaming Controller flowgraph. <br />
<br />
[[File:Xmlrpc_client_streaming_add_GUI.png]]<br />
<br />
*Now delete the GUI blocks from the Server Flowgraph and add a ZMQ Pub Sink block. Connect the output of the 'Throttle' block to the input of the ZMQ Pub Sink where the GUI blocks used to be connected.<br />
<br />
ZMQ PUB SINK PARAMETERS:<br />
'Address': tcp://127.0.0.1:5000<br />
'Pass Tags': 'Yes'<br />
All others default<br />
<br />
*Change the 'Generate Options' in the Server flowgraph to 'No GUI'. This will allow us to run the flowgraph on our localhost or a remote host as a 'headless' flowgraph.<br />
<br />
[[File:Xmlrpc_server_streaming_add_ZMQ.png]]<br />
<br />
<br />
*In the Streaming Client flowgraph. <br />
<br />
Change the sample rate to match the Streaming Server Flowgraph (32ksps)<br />
<br />
Add a ZMQ Sub Source block to the flowgraph and connect it to the input port of both the 'QT GUI Time Sink' and 'QT GUI Frequency Sink' GUI blocks.<br />
<br />
[[File:Xmlrpc_client_streaming_add_ZMQ.png]]<br />
<br />
ZMQ SUB SOURCE PARAMETERS:<br />
'Address': tcp://127.0.0.1:5000<br />
'Pass Tags': 'Yes'<br />
All others default<br />
<br />
*RUN IT!<br />
From GRC:<br />
Click the run button on the 'siggen_xmlrpc_server_streaming' flowgraph. A blank terminal window will open (don't worry its doing it's job).<br />
<br />
Click the run button on the 'siggen_xmlrpc_controller_client_streaming' flowgraph. A GUI window will open with the same time/frequency display as before, but in the same graph with the GUI Range 'frequency' slider. <br />
<br />
In the Controller GUI:<br />
Adjust the slider as before and observe the frequency changing. <br />
<br />
[[File:Xmlrpc_client_streaming_complete.png]]<br />
<br />
You are now both remote controlling and viewing streaming data over a network connection!<br />
<br />
==GNURadio XMLRPC Remote Control Over IP Network==<br />
<br />
<br />
*Extending this example to two hosts using one of two methods. <br />
Assume our Streaming Server machine is Host A and our Streaming Client machine is Host B.<br />
<br />
'''NOTE: These tutorials are focused on functionality not security. Understanding of the IP mechanisms used in this tutorial fall on the user. Know your network!'''<br />
<br />
*'''METHOD 1'''<br />
<br />
SSH Port Forwarding (more information can be found [https://www.ssh.com/academy/ssh/tunneling/example here]<br />
Using SSH Port Forwarding, a user can keep everything the same in the flowgraphs. We are using port 8000 for XMLRPC and Port 5000 for our ZMQ Streaming Data.<br />
Simply run the following command from Host B:<br />
ssh -L 8000:localhost:8000 -L 5000:localhost:5000 <username>@<IP Address of Host A><br />
<br />
This SSH command effectively shares any traffic on ports 8000 and 5000 between the two hosts.<br />
<br />
<br />
*'''METHOD 2'''<br />
<br />
Changing the IP Addresses in both flowgraphs:<br />
<br />
*Streaming Server Flowgraph (Host A)<br />
<br />
ZMQ Pub Sink<br />
Address <IP Address of Host B -OR- '0.0.0.0'><br />
<br />
XMLRPC Server <IP Address of Host A -OR- '0.0.0.0'><br />
<br />
*Streaming Client Flowgraph (Host B)<br />
<br />
ZMQ Sub Source<br />
Address <IP Address of host A><br />
<br />
XMLRPC Client Block (frequency)<br />
Address <IP Address of host A><br />
<br />
==GNURadio XMLRPC Server Automation using Standalone Python Code==<br />
<br />
XMLRPC is extremely simple to use in Python. The following section will give a simple example of this by changing the frequency of the server flowgraph from a list of frequencies in a python script.<br />
<br />
If we run our original siggen_xmlrpc_server.grc flowgraph. We should see the same gui window pop up again as in the first part of this tutorial.<br />
<br />
Now instead of running our client flowgraph to manually control the frequency, we will automate the frequency change with a python script.<br />
<br />
This script will change the frequency of the signal generator block every 2 seconds. The frequency is determined by a list which our script will iterate through.<br />
<br />
With the server running, simply paste this code into a script called 'flowgraph_automator.py'<br />
<br />
<pre><br />
#!/usr/bin/env python3<br />
# -*- coding: utf-8 -*-<br />
from xmlrpc.client import ServerProxy<br />
import time<br />
xmlrpc_control_client = ServerProxy('http://'+'localhost'+':8000')<br />
freq_steps = [6e3, 11e3, 2e3, 14e3, 4e3, 3.5e3]<br />
while True:<br />
for freq in freq_steps:<br />
print("retuning to:",freq/1000,"kHz")<br />
xmlrpc_control_client.set_rmt_freq(freq)<br />
time.sleep(2)<br />
</pre><br />
<br />
Open a terminal and run the script with <code>$ python3 flowgraph_automator.py</code><br />
As soon as you run the python script, you will see terminal output displaying the frequency change.<br />
If you look in the GUI window for the server, you will see the frequency shifting every 2 seconds!<br />
<br />
==GNURadio XMLRPC ZMQ Advanced Usage Example==<br />
'''Remote Spectrum Monitoring Example using Hardware'''<br />
<br />
This portion of the tutorial uses two open source projects that implement the concepts shown above to provide wideband remote spectrum monitoring over a low data rate IP connection.<br />
<br />
This tutorial assumes you have one of the following Software Defined Radios:<br />
*Ettus Research USRP<br />
*Lime Micro LimeSDR<br />
*RTL-SDR<br />
<br />
This tutorial can be run from the same computer, but is intended to be used on two separate machines. <br />
Both machines require GNURadio 3.9+ and the proper driver for the radio. In the case of the USRP, UHD is required. For either the LimeSDR or the RTLSDR, GNURadio 3.9+ includes SoapySDR drivers for both.<br />
<br />
Clone the following two repositories on the remote host:<br />
<br />
*https://github.com:muaddib1984/stillsuit<br />
<br />
*https://github.com:muaddib1984/arrakis<br />
<br />
Clone only the arrakis repository on the local host:<br />
<br />
*https://github.com:muaddib1984/arrakis<br />
<br />
<br />
'''REMOTE HOST'''<br />
*Attach one of the SDR's listed above to your remote host. Ensure your radio is connected to the host by running either:<br />
For USRP<br />
<pre>uhd_find_devices</pre><br />
For LimeSDR/RTLSDR<br />
<pre>SoapySDRUtil --find</pre><br />
<br />
*From your local host, open an SSH tunnel to the remote host with Local Port Forwarding:<br />
<code>ssh -L 5001:localhost:5001 -L 8001:localhost:8001 -L 8000:localhost:8000 <username>@<hostname(or IP Address)></code><br />
<br />
EXAMPLE:<br />
If my username on the remote host is 'user' and the remote host's ip address is 192.168.1.100, from my local host I would run:<br />
<code>ssh -L 5001:localhost:5001 -L 8001:localhost:8001 -L 8000:localhost:8000 user@192.168.1.100</code><br />
<br />
*Now you are connected via SSH to the remote terminal.<br />
<br />
*If you prefer to have only one terminal window open, from the SSH terminal, run:<br />
<code>cd path/to/stillsuit</code><br />
<code>./<uhd|lime|rtl>_stillsuit.py &</code> (this will allow you to run the second application from the same terminal)<br />
<br />
*If you prefer to have two terminals, you can open a second SSH session, but leave off the '-L' arguments since we already have the ports forwarded in the first shell. <br />
*With two terminals, you can also omit the "&" in the previous command.<br />
<br />
*Whether in one or two terminal windows run:<br />
<br />
<code>cd path/to/arakkis</code><br />
<br><code>space_folder.py</code> note: If you are using an RTLSDR, pass the -s argument to space_folder.py with a value of 2.5e6 like this <br><code>space_folder.py -s 2.5e6</code><br />
<br />
<br />
'''LOCAL HOST'''<br />
*Now open a terminal window on your local machine and run:<br />
<br />
<code>cd path/to/arrakis</code><br />
<br><code>./guild_navigator.py</code> note: If you are using an RTLSDR, pass the -s argument to guild_navigator.py with a value of 2.5e6 like this <br><code>guild_navigator.py -s 2.5e6</code><br />
<br />
*You should see a frequency plot updating at a fairly slow update rate. <br />
*To make the frequency plot update faster, change the vectors per second dropdown menu to 8. <br />
*To make the spectrum more stable visually, change the 'Average/Raw' dropdown to 'AVERAGED'. <br />
*If using a USRP/Lime, you can adjust the sampling rate to 40MHz (performance will be dependent on your remote host's processing power.)<br />
*Finally, tune the frequency to 98000000.0 Hz in the frequency window (FM Radio).<br />
<br />
Your plot should look something like this:<br />
<br />
[[File:guild_navigator_fm.png]]<br />
<br />
To measure the data usage from one host to another install an application like 'iftop' <br />
<br><code>sudo apt install iftop</code><br />
and run it like this:<br />
<br><code>sudo iftop -i lo -P</code><br />
Port 5000 will have the throughput usage and look similar to this with the above settings:<br />
<pre><br />
191Mb 381Mb 572Mb 763Mb 954Mb<br />
└────────────┴─────────────┴─────────────┴─────────────┴─────────────<br />
localhost:5001 => localhost:59814 2.01Mb 2.06Mb 2.01Mb<br />
</pre><br />
<br />
This is a powerful capability because we are getting a very human readable frequency plot of live RF Spectrum, while only using a small amount of network data to get it from the remote host!<br />
Furthermore, XMLRPC is allowing us to '''remotely''' adjust all of the parameters of the SDR at runtime!</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=8970ReleaseProcess2021-10-25T12:45:26Z<p>Willcode4: /* Release commit */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
Cherry picking, using the -xs flags, automatically adds a cross reference, for example<br />
<br />
commit bc21cf1f9ca25dd3efcbc9806cee4f6c1726a905<br />
Author: Marcus Müller <mmueller@gnuradio.org><br />
Date: Sun Aug 15 18:54:10 2021 +0200<br />
<br />
audio/jack: to_string is no longer part of boost:: NS, instead use std::<br />
<br />
Signed-off-by: Marcus Müller <mmueller@gnuradio.org><br />
(cherry picked from commit 883315208853121a8dfa68ae9c2f74400acd5ac5)<br />
Signed-off-by: Jeff Long <willcode4@gmail.com><br />
<br />
For other commits, add cross references to '''Git commits only''', not to PRs. The<br />
git repo should stand on its own. At the very least, explain how a commit relates to<br />
any work on the master branch.<br />
<br />
Backported PRs should reference the original PRs like this<br />
Backport #1234<br />
at the bottom of the description.<br />
<br />
== Change freeze ==<br />
About 2-3 weeks before release. This is informal. Accept only critical or very low risk<br />
changes at this point.<br />
<br />
=== Announce ===<br />
Mention on the Development and General Chat channels on Matrix.<br />
At this point, the mailing list is more for communicating with users than with core<br />
developers, so announcements there would not be useful, and could result in solicitation<br />
of extra PRs exactly when we are not going to consider them.<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
About 1 week before release.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `0-rc1` format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1"<br />
* Merge release PR<br />
* Sync local checkout for later comparison step<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
The GPG key includes a signing subkey, which is used to sign releases. The master key<br />
is used only for certifying subkeys.<br />
<br />
Currently, the signing subkey expiration date is extended a year at a time, as long as there<br />
are no personnel changes and the key remains secure.<br />
<br />
=== Download tar.gz and zip ===<br />
If not done in release step<br />
<br />
=== Verify archives ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign archives ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
Add articles to the news section on the wiki<br />
https://github.com/gnuradio/hugo-website#how-to-add-stuff-to-the-website<br />
<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=8969ReleaseProcess2021-10-25T12:44:48Z<p>Willcode4: /* Release commit */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
Cherry picking, using the -xs flags, automatically adds a cross reference, for example<br />
<br />
commit bc21cf1f9ca25dd3efcbc9806cee4f6c1726a905<br />
Author: Marcus Müller <mmueller@gnuradio.org><br />
Date: Sun Aug 15 18:54:10 2021 +0200<br />
<br />
audio/jack: to_string is no longer part of boost:: NS, instead use std::<br />
<br />
Signed-off-by: Marcus Müller <mmueller@gnuradio.org><br />
(cherry picked from commit 883315208853121a8dfa68ae9c2f74400acd5ac5)<br />
Signed-off-by: Jeff Long <willcode4@gmail.com><br />
<br />
For other commits, add cross references to '''Git commits only''', not to PRs. The<br />
git repo should stand on its own. At the very least, explain how a commit relates to<br />
any work on the master branch.<br />
<br />
Backported PRs should reference the original PRs like this<br />
Backport #1234<br />
at the bottom of the description.<br />
<br />
== Change freeze ==<br />
About 2-3 weeks before release. This is informal. Accept only critical or very low risk<br />
changes at this point.<br />
<br />
=== Announce ===<br />
Mention on the Development and General Chat channels on Matrix.<br />
At this point, the mailing list is more for communicating with users than with core<br />
developers, so announcements there would not be useful, and could result in solicitation<br />
of extra PRs exactly when we are not going to consider them.<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
About 1 week before release.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `0-rc1`format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1"<br />
* Merge release PR<br />
* Sync local checkout for later comparison step<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
The GPG key includes a signing subkey, which is used to sign releases. The master key<br />
is used only for certifying subkeys.<br />
<br />
Currently, the signing subkey expiration date is extended a year at a time, as long as there<br />
are no personnel changes and the key remains secure.<br />
<br />
=== Download tar.gz and zip ===<br />
If not done in release step<br />
<br />
=== Verify archives ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign archives ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
Add articles to the news section on the wiki<br />
https://github.com/gnuradio/hugo-website#how-to-add-stuff-to-the-website<br />
<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=8968ReleaseProcess2021-10-25T09:24:59Z<p>Willcode4: /* Cross-referencing */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
Cherry picking, using the -xs flags, automatically adds a cross reference, for example<br />
<br />
commit bc21cf1f9ca25dd3efcbc9806cee4f6c1726a905<br />
Author: Marcus Müller <mmueller@gnuradio.org><br />
Date: Sun Aug 15 18:54:10 2021 +0200<br />
<br />
audio/jack: to_string is no longer part of boost:: NS, instead use std::<br />
<br />
Signed-off-by: Marcus Müller <mmueller@gnuradio.org><br />
(cherry picked from commit 883315208853121a8dfa68ae9c2f74400acd5ac5)<br />
Signed-off-by: Jeff Long <willcode4@gmail.com><br />
<br />
For other commits, add cross references to '''Git commits only''', not to PRs. The<br />
git repo should stand on its own. At the very least, explain how a commit relates to<br />
any work on the master branch.<br />
<br />
Backported PRs should reference the original PRs like this<br />
Backport #1234<br />
at the bottom of the description.<br />
<br />
== Change freeze ==<br />
About 2-3 weeks before release. This is informal. Accept only critical or very low risk<br />
changes at this point.<br />
<br />
=== Announce ===<br />
Mention on the Development and General Chat channels on Matrix.<br />
At this point, the mailing list is more for communicating with users than with core<br />
developers, so announcements there would not be useful, and could result in solicitation<br />
of extra PRs exactly when we are not going to consider them.<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
About 1 week before release.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `-rc0`format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1"<br />
* Merge release PR<br />
* Sync local checkout for later comparison step<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
The GPG key includes a signing subkey, which is used to sign releases. The master key<br />
is used only for certifying subkeys.<br />
<br />
Currently, the signing subkey expiration date is extended a year at a time, as long as there<br />
are no personnel changes and the key remains secure.<br />
<br />
=== Download tar.gz and zip ===<br />
If not done in release step<br />
<br />
=== Verify archives ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign archives ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
Add articles to the news section on the wiki<br />
https://github.com/gnuradio/hugo-website#how-to-add-stuff-to-the-website<br />
<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=8767ReleaseProcess2021-08-23T17:22:39Z<p>Willcode4: /* Verify or create valid signing key */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
Cherry picking, using the -xs flags, automatically adds a cross reference, for example<br />
<br />
commit bc21cf1f9ca25dd3efcbc9806cee4f6c1726a905<br />
Author: Marcus Müller <mmueller@gnuradio.org><br />
Date: Sun Aug 15 18:54:10 2021 +0200<br />
<br />
audio/jack: to_string is no longer part of boost:: NS, instead use std::<br />
<br />
Signed-off-by: Marcus Müller <mmueller@gnuradio.org><br />
(cherry picked from commit 883315208853121a8dfa68ae9c2f74400acd5ac5)<br />
Signed-off-by: Jeff Long <willcode4@gmail.com><br />
<br />
For other commits, add cross references to '''Git commits only''', not to PRs. The<br />
git repo should stand on its own. At the very least, explain how a commit relates to<br />
any work on the master branch.<br />
<br />
== Change freeze ==<br />
About 2-3 weeks before release. This is informal. Accept only critical or very low risk<br />
changes at this point.<br />
<br />
=== Announce ===<br />
Mention on the Development and General Chat channels on Matrix.<br />
At this point, the mailing list is more for communicating with users than with core<br />
developers, so announcements there would not be useful, and could result in solicitation<br />
of extra PRs exactly when we are not going to consider them.<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
About 1 week before release.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `-rc0`format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1"<br />
* Merge release PR<br />
* Sync local checkout for later comparison step<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
The GPG key includes a signing subkey, which is used to sign releases. The master key<br />
is used only for certifying subkeys.<br />
<br />
Currently, the signing subkey expiration date is extended a year at a time, as long as there<br />
are no personnel changes and the key remains secure.<br />
<br />
=== Download tar.gz and zip ===<br />
If not done in release step<br />
<br />
=== Verify archives ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign archives ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
Add articles to the news section on the wiki<br />
https://github.com/gnuradio/hugo-website#how-to-add-stuff-to-the-website<br />
<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=8766ReleaseProcess2021-08-23T17:17:29Z<p>Willcode4: /* Change freeze */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
Cherry picking, using the -xs flags, automatically adds a cross reference, for example<br />
<br />
commit bc21cf1f9ca25dd3efcbc9806cee4f6c1726a905<br />
Author: Marcus Müller <mmueller@gnuradio.org><br />
Date: Sun Aug 15 18:54:10 2021 +0200<br />
<br />
audio/jack: to_string is no longer part of boost:: NS, instead use std::<br />
<br />
Signed-off-by: Marcus Müller <mmueller@gnuradio.org><br />
(cherry picked from commit 883315208853121a8dfa68ae9c2f74400acd5ac5)<br />
Signed-off-by: Jeff Long <willcode4@gmail.com><br />
<br />
For other commits, add cross references to '''Git commits only''', not to PRs. The<br />
git repo should stand on its own. At the very least, explain how a commit relates to<br />
any work on the master branch.<br />
<br />
== Change freeze ==<br />
About 2-3 weeks before release. This is informal. Accept only critical or very low risk<br />
changes at this point.<br />
<br />
=== Announce ===<br />
Mention on the Development and General Chat channels on Matrix.<br />
At this point, the mailing list is more for communicating with users than with core<br />
developers, so announcements there would not be useful, and could result in solicitation<br />
of extra PRs exactly when we are not going to consider them.<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
About 1 week before release.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `-rc0`format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1"<br />
* Merge release PR<br />
* Sync local checkout for later comparison step<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
<br />
=== Download tar.gz and zip ===<br />
If not done in release step<br />
<br />
=== Verify archives ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign archives ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
Add articles to the news section on the wiki<br />
https://github.com/gnuradio/hugo-website#how-to-add-stuff-to-the-website<br />
<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=8765ReleaseProcess2021-08-23T17:16:21Z<p>Willcode4: /* RC plan */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
Cherry picking, using the -xs flags, automatically adds a cross reference, for example<br />
<br />
commit bc21cf1f9ca25dd3efcbc9806cee4f6c1726a905<br />
Author: Marcus Müller <mmueller@gnuradio.org><br />
Date: Sun Aug 15 18:54:10 2021 +0200<br />
<br />
audio/jack: to_string is no longer part of boost:: NS, instead use std::<br />
<br />
Signed-off-by: Marcus Müller <mmueller@gnuradio.org><br />
(cherry picked from commit 883315208853121a8dfa68ae9c2f74400acd5ac5)<br />
Signed-off-by: Jeff Long <willcode4@gmail.com><br />
<br />
For other commits, add cross references to '''Git commits only''', not to PRs. The<br />
git repo should stand on its own. At the very least, explain how a commit relates to<br />
any work on the master branch.<br />
<br />
== Change freeze ==<br />
About 2-3 weeks before release.<br />
<br />
=== Announce ===<br />
This is informal. Mention on the Development and General Chat channels on Matrix.<br />
At this point, the mailing list is more for communicating with users than with core<br />
developers, so announcements there would not be useful, and could result in solicitation<br />
of extra PRs exactly when we are not going to consider them.<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
About 1 week before release.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `-rc0`format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1"<br />
* Merge release PR<br />
* Sync local checkout for later comparison step<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
<br />
=== Download tar.gz and zip ===<br />
If not done in release step<br />
<br />
=== Verify archives ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign archives ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
Add articles to the news section on the wiki<br />
https://github.com/gnuradio/hugo-website#how-to-add-stuff-to-the-website<br />
<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=8764ReleaseProcess2021-08-23T17:15:55Z<p>Willcode4: /* Change freeze */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
Cherry picking, using the -xs flags, automatically adds a cross reference, for example<br />
<br />
commit bc21cf1f9ca25dd3efcbc9806cee4f6c1726a905<br />
Author: Marcus Müller <mmueller@gnuradio.org><br />
Date: Sun Aug 15 18:54:10 2021 +0200<br />
<br />
audio/jack: to_string is no longer part of boost:: NS, instead use std::<br />
<br />
Signed-off-by: Marcus Müller <mmueller@gnuradio.org><br />
(cherry picked from commit 883315208853121a8dfa68ae9c2f74400acd5ac5)<br />
Signed-off-by: Jeff Long <willcode4@gmail.com><br />
<br />
For other commits, add cross references to '''Git commits only''', not to PRs. The<br />
git repo should stand on its own. At the very least, explain how a commit relates to<br />
any work on the master branch.<br />
<br />
== Change freeze ==<br />
About 2-3 weeks before release.<br />
<br />
=== Announce ===<br />
This is informal. Mention on the Development and General Chat channels on Matrix.<br />
At this point, the mailing list is more for communicating with users than with core<br />
developers, so announcements there would not be useful, and could result in solicitation<br />
of extra PRs exactly when we are not going to consider them.<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
Around one week unless problems are found.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `-rc0`format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1"<br />
* Merge release PR<br />
* Sync local checkout for later comparison step<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
<br />
=== Download tar.gz and zip ===<br />
If not done in release step<br />
<br />
=== Verify archives ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign archives ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
Add articles to the news section on the wiki<br />
https://github.com/gnuradio/hugo-website#how-to-add-stuff-to-the-website<br />
<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=8763ReleaseProcess2021-08-23T17:13:46Z<p>Willcode4: /* Announce */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
Cherry picking, using the -xs flags, automatically adds a cross reference, for example<br />
<br />
commit bc21cf1f9ca25dd3efcbc9806cee4f6c1726a905<br />
Author: Marcus Müller <mmueller@gnuradio.org><br />
Date: Sun Aug 15 18:54:10 2021 +0200<br />
<br />
audio/jack: to_string is no longer part of boost:: NS, instead use std::<br />
<br />
Signed-off-by: Marcus Müller <mmueller@gnuradio.org><br />
(cherry picked from commit 883315208853121a8dfa68ae9c2f74400acd5ac5)<br />
Signed-off-by: Jeff Long <willcode4@gmail.com><br />
<br />
For other commits, add cross references to '''Git commits only''', not to PRs. The<br />
git repo should stand on its own. At the very least, explain how a commit relates to<br />
any work on the master branch.<br />
<br />
== Change freeze ==<br />
<br />
=== Announce ===<br />
This is informal. Mention on the Development and General Chat channels on Matrix.<br />
At this point, the mailing list is more for communicating with users than with core<br />
developers, so announcements there would not be useful, and could result in solicitation<br />
of extra PRs exactly when we are not going to consider them.<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
Around one week unless problems are found.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `-rc0`format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1"<br />
* Merge release PR<br />
* Sync local checkout for later comparison step<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
<br />
=== Download tar.gz and zip ===<br />
If not done in release step<br />
<br />
=== Verify archives ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign archives ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
Add articles to the news section on the wiki<br />
https://github.com/gnuradio/hugo-website#how-to-add-stuff-to-the-website<br />
<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=8762ReleaseProcess2021-08-23T17:11:25Z<p>Willcode4: /* Cross-referencing */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
Cherry picking, using the -xs flags, automatically adds a cross reference, for example<br />
<br />
commit bc21cf1f9ca25dd3efcbc9806cee4f6c1726a905<br />
Author: Marcus Müller <mmueller@gnuradio.org><br />
Date: Sun Aug 15 18:54:10 2021 +0200<br />
<br />
audio/jack: to_string is no longer part of boost:: NS, instead use std::<br />
<br />
Signed-off-by: Marcus Müller <mmueller@gnuradio.org><br />
(cherry picked from commit 883315208853121a8dfa68ae9c2f74400acd5ac5)<br />
Signed-off-by: Jeff Long <willcode4@gmail.com><br />
<br />
For other commits, add cross references to '''Git commits only''', not to PRs. The<br />
git repo should stand on its own. At the very least, explain how a commit relates to<br />
any work on the master branch.<br />
<br />
== Change freeze ==<br />
<br />
=== Announce ===<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
Around one week unless problems are found.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `-rc0`format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1"<br />
* Merge release PR<br />
* Sync local checkout for later comparison step<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
<br />
=== Download tar.gz and zip ===<br />
If not done in release step<br />
<br />
=== Verify archives ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign archives ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
Add articles to the news section on the wiki<br />
https://github.com/gnuradio/hugo-website#how-to-add-stuff-to-the-website<br />
<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseKey&diff=8761ReleaseKey2021-08-23T16:36:36Z<p>Willcode4: </p>
<hr />
<div>= ReleaseKey =<br />
<br />
GNU Radio software signing keys may be downloaded from the Release area on Github.<br />
<br />
Posted here '''for information only''' ... the wiki is not a secure place to obtain keys/fingerprints.<br />
<br />
Software is currently signed by gpg key<br />
E852461BC01D652724600054ABA21950443392F6<br />
which is issued by<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
<br />
-----BEGIN PGP PUBLIC KEY BLOCK-----<br />
<br />
mDMEYEK63BYJKwYBBAHaRw8BAQdADTdeCx8vG5iMDzSrjSkpUhalokrrLjLEKHed<br />
1Mveqy+0NEdOVSBSYWRpbyAoU29mdHdhcmUgU2lnbmluZyBLZXkpIDxpbmZvQGdu<br />
dXJhZGlvLm9yZz6IkAQTFggAOBYhBHI+w6K5BTPGuT37yO15d0P3lRQ1BQJgQrrc<br />
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEO15d0P3lRQ1dIUA/RC/shSi<br />
uO0iq0dfKOr6AVjb6Cf1TGHE0ODqvZNigipwAP4pL7XKz8Qm5SZOAnkKfK6qeeqj<br />
9TEclVsQ0l18sId/D7gzBGBCu1sWCSsGAQQB2kcPAQEHQO/EPuC+j4jMjdhokmZD<br />
lQfkZk32sY2Rny9ZCz7MWFXLiPUEGBYIACYWIQRyPsOiuQUzxrk9+8jteXdD95UU<br />
NQUCYEK7WwIbAgUJAY4lAACBCRDteXdD95UUNXYgBBkWCAAdFiEE6FJGG8AdZSck<br />
YABUq6IZUEQzkvYFAmBCu1sACgkQq6IZUEQzkvZ/fQEA7MnOrZ2MNhgPK1WNhiMM<br />
r83Sks/arMRPFioXT0DA/QcA/i6MyS4xTey2aViNyum8nP6cTQ6pKYiZv/yraKYf<br />
KcAKlw0BAIqjJtsfEoqK/2nLMrRlFYN0upEv8ca9N2gOGP83/I1PAQCTIzW5kWpx<br />
8GOVNIKJ78VewffKLBZ3Rcj07ZToyYFoB4j1BBgWCAAmAhsCFiEEcj7DorkFM8a5<br />
PfvI7Xl3Q/eVFDUFAmEa3UEFCQN4fuYAgXYgBBkWCAAdFiEE6FJGG8AdZSckYABU<br />
q6IZUEQzkvYFAmBCu1sACgkQq6IZUEQzkvZ/fQEA7MnOrZ2MNhgPK1WNhiMMr83S<br />
ks/arMRPFioXT0DA/QcA/i6MyS4xTey2aViNyum8nP6cTQ6pKYiZv/yraKYfKcAK<br />
CRDteXdD95UUNRk2AQDfDsNlPZ8h+Ri1Vgi3mTcOIExiEsaS008HbgWkYThmygEA<br />
sQ+nkwpzzBv6ZmisyPqchrEGNqwzhvuclWO5ZU9Vmw4=<br />
=AiL+<br />
-----END PGP PUBLIC KEY BLOCK-----<br />
<br />
pub ed25519 2021-03-05 [SC]<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
uid GNU Radio (Software Signing Key) <info@gnuradio.org><br />
sub ed25519 2021-03-05 [S] [expires: 2023-01-08]<br />
E852461BC01D652724600054ABA21950443392F6<br />
The expiration date has been extended. The previous version was used through June 2021, and would read:<br />
pub ed25519 2021-03-05 [SC]<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
uid GNU Radio (Software Signing Key) <info@gnuradio.org><br />
sub ed25519 2021-03-05 [S] [expires: 2022-01-01]<br />
E852461BC01D652724600054ABA21950443392F6</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseKey&diff=8760ReleaseKey2021-08-23T16:34:22Z<p>Willcode4: </p>
<hr />
<div>= ReleaseKey =<br />
<br />
GNU Radio software signing keys may be downloaded from the Release area on Github.<br />
<br />
Posted here '''for information only''' ... the wiki is not a secure place to obtain keys/fingerprints.<br />
<br />
Software is currently signed by gpg key<br />
E852461BC01D652724600054ABA21950443392F6<br />
which is issued by<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
<br />
-----BEGIN PGP PUBLIC KEY BLOCK-----<br />
mDMEYEK63BYJKwYBBAHaRw8BAQdADTdeCx8vG5iMDzSrjSkpUhalokrrLjLEKHed<br />
1Mveqy+0NEdOVSBSYWRpbyAoU29mdHdhcmUgU2lnbmluZyBLZXkpIDxpbmZvQGdu<br />
dXJhZGlvLm9yZz6IkAQTFggAOBYhBHI+w6K5BTPGuT37yO15d0P3lRQ1BQJgQrrc<br />
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEO15d0P3lRQ1dIUA/RC/shSi<br />
uO0iq0dfKOr6AVjb6Cf1TGHE0ODqvZNigipwAP4pL7XKz8Qm5SZOAnkKfK6qeeqj<br />
9TEclVsQ0l18sId/D7gzBGBCu1sWCSsGAQQB2kcPAQEHQO/EPuC+j4jMjdhokmZD<br />
lQfkZk32sY2Rny9ZCz7MWFXLiPUEGBYIACYWIQRyPsOiuQUzxrk9+8jteXdD95UU<br />
NQUCYEK7WwIbAgUJAY4lAACBCRDteXdD95UUNXYgBBkWCAAdFiEE6FJGG8AdZSck<br />
YABUq6IZUEQzkvYFAmBCu1sACgkQq6IZUEQzkvZ/fQEA7MnOrZ2MNhgPK1WNhiMM<br />
r83Sks/arMRPFioXT0DA/QcA/i6MyS4xTey2aViNyum8nP6cTQ6pKYiZv/yraKYf<br />
KcAKlw0BAIqjJtsfEoqK/2nLMrRlFYN0upEv8ca9N2gOGP83/I1PAQCTIzW5kWpx<br />
8GOVNIKJ78VewffKLBZ3Rcj07ZToyYFoB4j1BBgWCAAmAhsCFiEEcj7DorkFM8a5<br />
PfvI7Xl3Q/eVFDUFAmEa3UEFCQN4fuYAgXYgBBkWCAAdFiEE6FJGG8AdZSckYABU<br />
q6IZUEQzkvYFAmBCu1sACgkQq6IZUEQzkvZ/fQEA7MnOrZ2MNhgPK1WNhiMMr83S<br />
ks/arMRPFioXT0DA/QcA/i6MyS4xTey2aViNyum8nP6cTQ6pKYiZv/yraKYfKcAK<br />
CRDteXdD95UUNRk2AQDfDsNlPZ8h+Ri1Vgi3mTcOIExiEsaS008HbgWkYThmygEA<br />
sQ+nkwpzzBv6ZmisyPqchrEGNqwzhvuclWO5ZU9Vmw4=<br />
=AiL+<br />
-----END PGP PUBLIC KEY BLOCK-----<br />
<br />
pub ed25519 2021-03-05 [SC]<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
uid GNU Radio (Software Signing Key) <info@gnuradio.org><br />
sub ed25519 2021-03-05 [S] [expires: 2023-01-08]<br />
E852461BC01D652724600054ABA21950443392F6<br />
The expiration date has been extended. The previous version was used through June 2021, and would read:<br />
pub ed25519 2021-03-05 [SC]<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
uid GNU Radio (Software Signing Key) <info@gnuradio.org><br />
sub ed25519 2021-03-05 [S] [expires: 2022-01-01]<br />
E852461BC01D652724600054ABA21950443392F6</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseKey&diff=8759ReleaseKey2021-08-23T16:24:50Z<p>Willcode4: </p>
<hr />
<div>= ReleaseKey =<br />
<br />
GNU Radio software signing keys may be downloaded from the Release area on Github.<br />
<br />
Posted here '''for information only''' ... the wiki is not a secure place to obtain keys/fingerprints.<br />
<br />
Software is currently signed by gpg key<br />
E852461BC01D652724600054ABA21950443392F6<br />
which is issued by<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
<br />
pub ed25519 2021-03-05 [SC]<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
uid [ unknown] GNU Radio (Software Signing Key) <info@gnuradio.org><br />
sub ed25519 2021-03-05 [S] [expires: 2023-01-08]<br />
E852461BC01D652724600054ABA21950443392F6<br />
The expiration date has been extended. The previous version was used through June 2021, and would read:<br />
pub ed25519 2021-03-05 [SC]<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
uid GNU Radio (Software Signing Key) <info@gnuradio.org><br />
sub ed25519 2021-03-05 [S] [expires: 2022-01-01]<br />
E852461BC01D652724600054ABA21950443392F6</div>Willcode4https://wiki.gnuradio.org/index.php?title=TutorialsWritePythonApplications&diff=8741TutorialsWritePythonApplications2021-08-17T13:53:24Z<p>Willcode4: /* What next? */</p>
<hr />
<div>== <b>NOTE:</b> This tutorial has been deprecated in GR 3.8. ==<br />
<br />
Welcome, GNU Radio beginners. If you are reading this tutorial, you probably already have some very basic knowledge about how GNU Radio works, what it is and what it can do - and now you want to enter this exciting world of Open Source digital signal processing (DSP) yourself.<br />
<br />
This is a tutorial on how to write applications for GNU Radio in Python using the version 3.7 API. It is no introduction to programming, software radio or signal processing, nor does it cover how to extend GNU Radio by creating new blocks or adding code to the source tree. If you have some background in the mentioned topics and are starting to work with GNU Radio, this probably is the correct tutorial for you. If you don't know what a Software Radio is or what a FIR filter does, you should probably go a few steps back and get a more solid background on signal processing theory. But don't let this discourage you - the best way to learn something is by trying it out.<br />
<br />
Although this tutorial is designed to make your introduction to GNU Radio as easy as possible, it is not a definitive guide. In fact, I might sometimes simply not tell the real truth to make explanations easier. I might even contradict myself in later chapters. Usage of brain power is still necessary to develop GNU Radio applications.<br />
<br />
== Preliminaries ==<br />
<br />
Before you get started with this tutorial, make sure your GNU Radio installation is ready and working. You don't necessarily need a USRP, but some kind of source and sink (USRP, audio or other hardware) is helpful, although not strictly required. If the GNU Radio examples work (such as dial_tone.py in gr-audio/examples/python), you're ready to go.<br />
<br />
You should also have some background in programming - but don't worry if you've never programmed Python, it is a very easy language to learn.<br />
<br />
== Understanding flow graphs ==<br />
<br />
Before we start banging out code, first we need to understand the most basic concepts about GNU Radio: flow graphs (as in graph theory) and blocks. Many GNU Radio applications contain nothing other than a flow graph. The nodes of such a graph are called blocks, and the data flows along the edges.<br />
<br />
Any actual signal processing is done in the blocks. Ideally, every block does exactly one job - this way GNU Radio stays modular and flexible. Blocks are written in C++; writing new blocks is not very difficult (but explained elsewhere).<br />
<br />
The data passing between blocks can be of any kind - practically any type of data you can define in C++ is possible. In practice, the most common data types are complex and real short or long integers and floating point values as most of the time, data passing from one block to the next will either be samples or bits.<br />
<br />
== Examples ==<br />
<br />
In order to illuminate this diffuse topic a little, let's start with some examples:<br />
<br />
'''Low-pass filtered audio recorder'''<br />
<br />
<pre> +-----+ +-----+ +----------------+<br />
| Mic +--+ LPF +--+ Record to file |<br />
+-----+ +-----+ +----------------+</pre><br />
First, an audio signal from a microphone is recorded by your PCs sound card and converted into a digital signal. The samples are streamed to the next block, the low pass filter (LPF), which could be implemented as an FIR filter. The filtered signal is passed on to the final block, which records the filtered audio signal into a file.<br />
<br />
This is a simple, yet complete flow graph. The first and last block serve a special purpose: they operate as source and sink. Every flow graph needs at least one source and sink to be able to function.<br />
<br />
'''Dial tone generator'''<br />
<br />
<pre> +------------------------+<br />
| Sine generator (350Hz) +---+<br />
+------------------------+ | +------------+<br />
+---+ |<br />
| Audio sink |<br />
+---+ |<br />
+------------------------+ | +------------+<br />
| Sine generator (440Hz) +---+<br />
+------------------------+</pre><br />
This simple example is often called the &quot;Hello World of GNU Radio&quot;. Other than the first example, it has two sources. The sink, on the other hand, has two inputs - in this case for the left and right channel of the sound card. Code for this example is available at gr-audio/examples/python/dial_tone.py.<br />
<br />
'''QPSK Demodulator'''<br />
<br />
<pre> +-------------+ +----------------+ +------------------+<br />
| USRP Source +--+ Frequency sync +--+ Matched filter |<br />
+-------------+ +----------------+ +-----------+------+<br />
| COMPLEX SAMPLES<br />
+-------------+------+<br />
| Symbol demodulator |<br />
+-------------+------+<br />
| COMPLEX SYMBOLS<br />
+-----------------+ +-----------------+ +------+------+<br />
| Source decoder +--+ Channel decoder +--+ Bit mapping |<br />
+--------+--------+ +-----------------+ +-------------+<br />
| BITS<br />
+--------+--------+<br />
| Application | DATA<br />
+-----------------+</pre><br />
This example is a bit more sophisticated, but should look quite familiar to RF engineers. In this case, the source is a USRP which is connected to an antenna. This kind of source sends complex samples to the following blocks.<br />
<br />
The interesting part about this kind of flow graph is that the data types change during the flow graph: at first, complex baseband samples are passed along. Then, complex symbols are gathered from the signal. Next, these symbols are turned into bits which again are processed further. Finally, the decoded bits are passed to some application which makes use of the data.<br />
<br />
'''Walkie Talkie'''<br />
<br />
<pre> +--------------+ +------------------+ +---------+ +------------+<br />
| USRP Source +--+ NBFM Demodulator +--+ Squelch +--+ Audio Sink |<br />
+--------------+ +------------------+ +---------+ +------------+<br />
+--------------+ +----------------+ +------------+<br />
| Audio Source +----------+ NBFM Modulator +---------+ USRP Sink |<br />
+--------------+ +----------------+ +------------+</pre><br />
This applications consists of two separate flow graphs, both running in parallel. One of them deals with the Tx path, the other with the Rx path. This kind of application would require some extra code (outside the flow graphs) to mute one path while the other is active. Both flow graphs still require at least one source and sink, each. You can find a GNU Radio application that does this (only a bit more sophisticated) at gr-uhd/examples/python/usrp_nbfm_ptt.py.<br />
<br />
== Summary ==<br />
<br />
This concludes the chapter about flow graphs. Here's a quick summary about the most vital points you really need to know:<br />
<br />
* All signal processing in GNU Radio is done through flow graphs.<br />
* A flow graph consists of blocks. A block does one signal processing operation, such as filtering, adding signals, transforming, decoding, hardware access or many others.<br />
* Data passes between blocks in various formats, complex or real integers, floats or basically any kind of data type you can define.<br />
* Every flow graph needs at least one sink and source.<br />
<br />
== A first working code example ==<br />
<br />
Next step is to find out how to write those flow graphs in real Python. Let's start by examining some code line-by-line. If you are familiar with Python, you can probably skip some of the explanations, but don't rush to the next section yet - the explanations are both for Python and GNU Radio beginners.<br />
<br />
The following code example represents the flow graph from example 2. It is actually a slightly modified version of the code example you can find in gr-audio/examples/python/dial_tone.py.<br />
<br />
<pre><br />
#!/usr/bin/env python3<br />
<br />
from gnuradio import gr<br />
from gnuradio import audio, analog<br />
<br />
class my_top_block(gr.top_block):<br />
def __init__(self):<br />
gr.top_block.__init__(self)<br />
<br />
sample_rate = 32000<br />
ampl = 0.1<br />
<br />
src0 = analog.sig_source_f(sample_rate, analog.GR_SIN_WAVE, 350, ampl)<br />
src1 = analog.sig_source_f(sample_rate, analog.GR_SIN_WAVE, 440, ampl)<br />
dst = audio.sink(sample_rate, &quot;&quot;)<br />
self.connect(src0, (dst, 0))<br />
self.connect(src1, (dst, 1))<br />
<br />
<br />
if __name__ == '__main__':<br />
try:<br />
my_top_block().run()<br />
except [[KeyboardInterrupt]]:<br />
pass</pre><br />
The first line should look familiar to anyone with some Unix or Linux background: It tells the shell that this file is a Python file and to use the Python interpreter to run this file. You need this line if you want to run this file directly from the command line.<br />
<br />
Lines 3 and 4 import necessary Python modules to run GNU Radio. The <code>import</code> command is similar to the <code>#include</code> directive in C/C++. Here, three modules from the gnuradio package are imported: <code>gr</code>, <code>audio</code>, and <code>analog</code>. The first module, <code>gr</code>, is the basic GNU Radio module. You will always have to import this to run a GNU Radio application. The second loads [http://gnuradio.org/doc/doxygen/page_audio.html audio device blocks], and the third is where the blocks related to [http://gnuradio.org/doc/doxygen/page_analog.html ''analog'' signal functionality and modulation] are located. There are many GNU Radio modules, a short list of modules will be presented later on.<br />
<br />
Lines 6-17 define a class called <code>my_top_block</code> which is derived from another class, <code>gr.top_block</code>. This class is basically a container for the flow graph. By deriving from <code>gr.top_block</code>, you get all the hooks and functions you need to add blocks and connect them.<br />
<br />
Only one member function is defined for this class: the function <code>__init__()</code>, which is the constructor of this class. In the first line of this function (line 8), the parent constructor is called (in Python, this needs to be done explicitly. Most things in Python need to be done explicitly; in fact, this is one main Python principle).<br /><br />
Next, two variables are defined: <code>sample_rate</code> and <code>ampl</code>. These will control sampling rate and amplitude of the signal generators.<br />
<br />
Before explaining the next lines, have another look at the sketched flow graph chart in the previous section: it consists of three blocks and two edges. The blocks are defined in lines 13-15: Two [http://gnuradio.org/doc/doxygen/classgr_1_1analog_1_1sig__source__f.html signal sources] are generated (called <code>src0</code> and <code>src1</code>). These sources continuously create sine waves at given frequencies (350 and 440Hz) and a given sampling rate (here 32kHz). The amplitude is controlled by the ampl variable and set to 0.1. The prefix &quot;f&quot; of the block type <code>analog.sig_source_f</code> indicates the output is of type <code>float</code>, which is a good thing because the audio sink accepts floating point samples in the range between 1 and +1. These kind of things must be taken care of by the programmer: although GNU Radio does some checks to make sure the connections make sense, there is still some things that must be taken care of manually. For example, if you wanted to feed integer samples to <code>audio.sink</code>, GNU Radio would throw an error but if you would set the amplitude in the above example to anything larger than 1, you would get a distorted signal without receiving an error.<br />
<br />
The signal sink is defined in line 15: <code>audio.sink()</code> returns a block which acts as a [http://gnuradio.org/doc/doxygen/classgr_1_1audio_1_1sink.html soundcard control] and plays back any samples piped into it. As in the blocks beforehand, the sampling rate needs to be set explicitly, even though this was set already for the signal sources. GNU Radio cannot guess the correct sampling rate from the context, as it is not part of the information flow between blocks.<br />
<br />
Lines 16 and 17 connect the blocks. The general syntax for connecting blocks is <code>self.connect(block1, block2, block3, ...)</code> which would connect the output of <code>block1</code> with the input of <code>block2</code>, the output of <code>block2</code> with the input of <code>block3</code> and so on. You can connect as many blocks as you wish with one <code>connect()</code> call. Here, a special syntax is necessary because we want to connect <code>src0</code> with the first input of <code>dst</code> and <code>src1</code> with the second one. <code>self.connect (src0, (dst, 0))</code> does exactly this: it specifically connects <code>src0</code> to port 0 of <code>dst</code>. <code>(dst, 0)</code> is called a &quot;tuple&quot; in Python jargon. In the <code>self.connect()</code> call it is used to specify the port number. When the port number is zero, the block may be used alone. An equivalent command to the one in line 16 would thus have been<br />
<br />
<pre><br />
self.connect((src0, 0), (dst, 0))</pre><br />
That's all there is to create a flow graph. The last 5 lines do nothing but start the flow graph (line 22). The <code>try</code> and <code>except</code> statements simply make sure the flow graph (which would otherwise run infinitely) are stopped when Ctrl+C is pressed (which triggers a <code>KeyboardInterrupt</code> Python exception).<br />
<br />
For Python-beginners, two more remarks should not be left out: As you might have noticed, the class my_top_block is run without creating an instance beforehand. In Python, this is a quite common thing to do, especially if you have a class which would only get one instance anyway. However, you could just as well create one or more instances of the class and then call the <code>run()</code> method on the instance(es).<br />
<br />
Second, the indenting is part of the code and not, like in C++, simply for the programmers convenience. If you try and modify this code, make sure you don't start mixing tabs and spaces. Every level must be consistently indented.<br /><br />
If you want to go on with this tutorial, you should first get a more solid Python background. Python documentation can be found at the Python web site http://www.python.org/, or a library of your choice. A good place to start for people with prior programming experience is http://wiki.python.org/moin/BeginnersGuide/Programmers .<br />
<br />
== Summary ==<br />
<br />
* You need to import required GNU Radio modules with the <code>from gnuradio import</code> command. You always need the module <code>gr</code>.<br />
* A flow graph is contained in a class which itself is derived from <code>gr.top_block</code>.<br />
* Blocks are created by calling functions such as <code>analog.sig_source_f()</code> and saving the return value to a variable.<br />
* Blocks are connected by calling <code>self.connect()</code> from within the flow graph class<br />
* If you don't feel comfortable writing some basic Python code now, have a break and go through some Python tutorials.<br />
<br />
The next section will give a more detailed overview about writing GNU Radio applications in Python.<br />
<br />
== Coding Python GNU Radio Applications ==<br />
<br />
The example above already covers quite a lot of how to write Python GNU Radio applications. This chapter and the next will try to show the possibilities of GNU Radio applications and how to use them. From now on, there is no need to linearly read these chapters section-for-section, it probably makes more sense to go over the titles and find out what you want to know.<br />
<br />
== GNU Radio Modules ==<br />
<br />
GNU Radio comes with quite a lot of libraries and modules. You will usually include modules with the following syntax:<br />
<br />
<pre><br />
from gnuradio import MODULENAME</pre><br />
Some modules work a bit differently, see the following list on the most common modules.<br />
<br />
{|<br />
|<br />
<br />
| gr<br />
|<br />
<br />
| The main GNU Radio library. You will nearly always need this.<br />
|<br />
<br />
|-<br />
|<br />
<br />
| analog<br />
|<br />
<br />
| Anything related to analog signals and analog modulation<br />
|<br />
<br />
|-<br />
|<br />
<br />
| audio<br />
|<br />
<br />
| Soundcard controls (sources, sinks). You can use this to send or receive audio to the sound cards, but you can also use your sound card as a narrow band receiver with an external RF frontend.<br />
|<br />
<br />
|-<br />
|<br />
<br />
| blocks<br />
|<br />
<br />
| Everything else. If it doesn't fit in another category, it's probably here.<br />
|<br />
<br />
|-<br />
|<br />
<br />
| channels<br />
|<br />
<br />
| Channel models for simulation.<br />
|<br />
<br />
|-<br />
|<br />
<br />
| digital<br />
|<br />
<br />
| Anything related to digital modulation.<br />
|<br />
<br />
|-<br />
|<br />
<br />
| fec<br />
|<br />
<br />
| Anything related to Forward Error Correction (FEC).<br />
|<br />
<br />
|-<br />
|<br />
<br />
| fft<br />
|<br />
<br />
| Anything related to FFTs.<br />
|<br />
<br />
|-<br />
|<br />
<br />
| filter<br />
|<br />
<br />
| Filter blocks and design tools like [http://gnuradio.org/doc/doxygen/classgr_1_1filter_1_1firdes.html firdes] and optfir.<br />
|<br />
<br />
|-<br />
|<br />
<br />
| plot_data<br />
|<br />
<br />
| Some functions to plot data with Matplotlib<br />
|<br />
<br />
|-<br />
|<br />
<br />
| qtgui<br />
|<br />
<br />
| Graphical tools to plot data (time, frequency, spectrogram, constellation, histogram, time raster) using the QT library.<br />
|<br />
<br />
|-<br />
|<br />
<br />
| trellis<br />
|<br />
<br />
| Blocks and tools for building trellis, trellis coded modulation, and other FSMs.<br />
|<br />
<br />
|-<br />
|<br />
<br />
| vocoder<br />
|<br />
<br />
| Anything dealing with voice coding/decoding.<br />
|<br />
<br />
|-<br />
|<br />
<br />
| wavelet<br />
|<br />
<br />
| Anything dealing with wavelets.<br />
|<br />
<br />
<br />
|-<br />
|<br />
<br />
| eng_notation<br />
|<br />
<br />
| Adds some functions to deals with numbers in engineering notation such as @100M' for 100 * 10^6'.<br />
|<br />
<br />
|-<br />
|<br />
<br />
| eng_options<br />
|<br />
<br />
| Use <code>from gnuradio.eng_options import eng_options</code> to import this feature. This module extends Pythons <code>optparse</code> module to understand engineering notation (see above).<br />
|<br />
<br />
|-<br />
|<br />
<br />
| gru<br />
|<br />
<br />
| Miscellaneous utilities, mathematical and others.<br />
|<br />
<br />
|}<br />
<br />
This is by far not a complete list, nor are the descriptions of the modules very useful by themselves. GNU Radio code changes a lot, so creating a static documentation would not be very sensible. GNU Radio uses [http://gnuradio.org/doc/doxygen/index.html Doxygen] and [http://gnuradio.org/doc/sphinx/index.html Sphinx] to dynamically create documentation of the APIs.<br />
<br />
Instead, you will have to use the good old Star Wars motto to delve further into the details of the modules: &quot;Use the source!&quot;. If you feel GNU Radio should really already have some functionality you want to use, either browse through the module directory Python uses or go through the source directory of GNU Radio. In particular, pay attention to the directories starting with <code>gr-</code> in the source directory, such as gr-trellis. These produce their own code and, consequently, their own modules.<br />
<br />
Of course, Python itself comes with a lot of modules, some of which are extremely useful - if not necessary - to write GNU Radio applications. Check the Python documentation and the SciPy website for more information.<br />
<br />
== Choosing, defining and configuring blocks ==<br />
<br />
GNU Radio comes with an abundance of pre-defined blocks, so for beginners, it is often quite confusing to find the correct blocks for their applications and set them up correctly. Doxygen and Sphinx are used to automatically generate documentation for the C++ and Python APIs ([http://gnuradio.org/doc/doxygen/index.html C++ Manual], [http://gnuradio.org/doc/sphinx/index.html) Python Manual].<br />
<br />
You can also generate this documentation locally so it always matches the version you have installed. If you have Doxygen and Sphinx installed, CMake takes care of this automatically.<br />
<br />
Learning how to use these documentations is a major part of learning how to use GNU Radio!<br />
<br />
Let's get practical. Here's the three lines from the previous example which define the blocks:<br />
<br />
<pre><br />
src0 = analog.sig_source_f (sample_rate, analog.GR_SIN_WAVE, 350, ampl)<br />
src1 = analog.sig_source_f (sample_rate, analog.GR_SIN_WAVE, 440, ampl)<br />
dst = audio.sink (sample_rate, &quot;&quot;)</pre><br />
Here's a simplified version of what happens when this code is executed: First, a function called <code>sig_source_f</code> in the module <code>analog</code> is executed. It receives four function arguments:<br />
<br />
* sample_rate, which is a Python variable,<br />
* analog.GR_SIN_WAVE, which is a constant defined in the <code>analog</code> module (defined [http://gnuradio.org/doc/doxygen/group__waveform__generators__blk.html#gac97c0f42ffb63f1265decceaaeab9177) here],<br />
* 350, a normal literal constant that's the frequency of the sine wave (relative to the sample rate),<br />
* ampl, another variable to set the amplitude of the sine wave.<br />
<br />
This function creates a class which is subsequently assigned to <code>src0</code>. The same happens on the other two lines, although the sink is fetched from a different module (<code>audio</code>).<br />
<br />
So how did I know which block to use and what to pass to <code>analog.sig_source_f()</code>? This is where the documentation comes in. If you use the Sphinx-generated docs, click on &quot;gnuradio.analog&quot;. Proceed to &quot;Signal Sources&quot;. You will find a list of signal generators, including the <code>sig_source_*</code> family. The suffix defines the data type at the output:<br />
<br />
* f = float<br />
* c = complex float<br />
* i = int<br />
* s = short int<br />
* b = bits (actually an integer type)<br />
<br />
These suffixes are used for all types of blocks, e.g. <code>filter.fir_filter_ccf()</code> will define an FIR filter with complex input, complex output and float taps, and <code>blocks.add_const_ss()</code> will define a block which adds incoming short values with another, constant, short int.<br />
<br />
Even if you don't want to touch C+'', it's worth having a look at the Doxygen-generated documentation as well, since most of the blocks are actually written in C''+ but then exported to Python.<br />
<br />
At this point, it is worth having a closer look behind the curtains of GNU Radio. The reason you can easily use the blocks - written in C++ - in your Python code is because GNU Radio uses a tool called [http://www.swig.org/ SWIG] to create an interface between Python and C+''. Every block in C''+ comes with a creating function, called <code>gr::component::block::make(***)</code> (<code>gr::analog::sig_source_f::make()</code> in the example mentioned above). This function is always documented on the same page as the matching class, and this function is what gets exported to Python, so <code>analog.sig_source_f()</code> in Python calls <code>gr::analog::sig_source_f::make()</code> in C++. For the same reason, it takes the same arguments - that's how you know how to initialize a block in Python.<br />
<br />
Once you're browsing the Doxygen documentation of the class <code>gr::analog::sig_source_f</code>, you might notice many other class methods, such as <code>set_frequency()</code>. These functions get exported to Python as well. So if you have created a signal source and want to change the frequency (say your application has a user frequency control) you can use this method on your Python defined block:<br />
<br />
<pre><br />
# We're in some cool application here<br />
<br />
src0 = analog.sig_source_f (sample_rate, analog.GR_SIN_WAVE, 350, ampl)<br />
# Other, fantastic things happen here<br />
<br />
src0.set_frequency(880) # Change frequency</pre><br />
will change the frequency of the first signal generator to 880Hz.<br />
<br />
Hopefully, GNU Radio documentation will grow and become more and more complete. But to completely understand the workings of blocks in detail, you will probably have to have a look at the code sooner or later, no matter how good the documentation gets.<br />
<br />
== Connecting blocks ==<br />
<br />
Use the <code>connect()</code> method of <code>gr.top_block</code> to connect blocks. Some things are worth mentioning:<br />
<br />
* You can only connect inputs and outputs if the data types match. If you try to connect a float output with a complex input, you will get an error.<br />
* One output can be connected to several inputs; you don't need an extra block to duplicate signal paths.<br />
<br />
These are basic rules for connecting blocks and they work in most cases. However, when mixing data types some more notes are worth mentioning.<br />
<br />
* GNU Radio checks if input and output types match by checking their size. If you happen to connect up ports with different types but the same size, you will most definitely get data junk.<br />
* When processing single bits, be careful. In some cases, you will work with binary data in a usual sense, in other cases you want to handle a specific number of bits at a time. Have a look at the <code>packed_to_unpacked*</code> and <code>unpacked_to_packed*</code> blocks for this.<br />
* Be careful with dynamic ranges. When you're using float or complex data types, you have a larger range than you'll ever need concerning the machine, but some sinks and sources have specific ranges you need to stick to. For example, audio sinks require samples within ''-1 and will clip anything outside this interval. The USRP sink on the other hand needs samples in the''-32767 range (signed 16 bit values) because that's the dynamic range of the DAC.<br />
<br />
== Hierarchical blocks ==<br />
<br />
Sometimes it makes sense to combine several blocks into a new block. Say you have several applications which all have a common signal processing component which consists of several blocks. These blocks can be combined into a new block, which in turn can be used in your applications is if it were a normal GNU Radio block.<br />
<br />
Example: Say you have two different flow graphs, FG1 and FG2. Both use - among others - the blocks B1 and B2. You want to combine them to a hierarchical block called <code>HierBlock</code>:<br />
<br />
<pre> +-------------------+<br />
| +-----+ +----+ |<br />
--+--+ B1 +--+ B2 +--+---<br />
| +-----+ +----+ |<br />
| HierBlock |<br />
+-------------------+</pre><br />
This is what you do: create a flow graph which derives from <code>gr.hier_block2</code> and use <code>self</code> as source and sink:<br />
<br />
<pre><br />
class HierBlock(gr.hier_block2):<br />
def __init__(self, audio_rate, if_rate):<br />
gr.hier_block2.__init__(self, &quot;HierBlock&quot;,<br />
gr.io_signature(1, 1, gr.sizeof_float),<br />
gr.io_signature(1, 2, gr.sizeof_gr_complex))<br />
<br />
B1 = blocks.block1(...) # Put in proper code here!<br />
B2 = blocks.block2(...)<br />
<br />
self.connect(self, B1, B2, self)</pre><br />
As you can see, creating a hierarchical block is very similar to creating a flow graph with <code>gr.top_block</code>. Apart from using <code>self</code> as source and sink, there is another difference: the constructor for the parent class (called in line 3) needs to receive additional information. The call to <code>gr.hier_block2.+init+()</code> takes four parameters:<br />
<br />
* self (which is always passed to the constructor as first argument),<br />
* a string with an identifier for the hierarchical block (change at your convenience),<br />
* an input signature and an<br />
* output signature.<br />
<br />
The last two require some extra explanation unless you have already written your own blocks in C++. GNU Radio needs to know what types of input and output the block uses. Creating an input/output signature can be done by calling <code>gr.io_signature()</code>, as is done here. This function call takes 3 arguments:<br />
<br />
* minimum number of ports,<br />
* maximum number of ports and<br />
* size of the input/output elements.<br />
<br />
For the hierarchical block <code>HierBlock</code>, you can see that it has exactly one input and one or two outputs. The incoming objects are of size <code>float</code>, so the block processes incoming real float values. Somewhere in B1 or B2, the data is converted to complex float values, so the output signature declares outgoing objects to be of size <code>gr.sizeof_gr_complex</code>. The 'gr.sizeof_float@ and <code>gr.sizeof_gr_complex</code> are equivalent to the C++ return values of the <code>sizeof()</code> call. Other predefined constants are<br />
<br />
* gr.sizeof_int<br />
* gr.sizeof_short<br />
* gr.sizeof_char<br />
<br />
Use gr.io_signature(0, 0, 0) to create a null IO signature, i.e. for defining hierarchical blocks as sources or sinks.<br />
<br />
That's all. You can now use <code>HierBlock</code> as you would use a regular block. For example, you could put this code in the same file:<br />
<br />
<pre><br />
class FG1(gr.top_block):<br />
def __init__(self):<br />
gr.top_block.__init__(self)<br />
<br />
<br />
... # Sources and other blocks are defined here<br />
other_block1 = blocks.other_block()<br />
hierblock = HierBlock()<br />
other_block2 = blocks.other_block()<br />
<br />
self.connect(other_block1, hierblock, other_block2)<br />
<br />
... # Define rest of FG1</pre><br />
Of course, to make use of Pythons modularity, you could also put the code for <code>HierBlock</code> in an extra file called <code>hier_block.py</code>. To use this block from another file, simply add an import directive to your code:<br />
<br />
<pre><br />
from hier_block import HierBlock</pre><br />
and you can use <code>HierBlock</code> as mentioned above.<br />
<br />
Examples for hierarchical blocks:<br />
<br />
<pre>gr-uhd/examples/python/fm_tx_2_daughterboards.py<br />
gr-uhd/examples/python/fm_tx4.py<br />
gr-digital/examples/narrowband/tx_voice.py</pre><br />
== Multiple flow graphs ==<br />
<br />
In some cases, you might want to have completely separate flow graphs, e.g. for receive and transmit paths (see the example 'Walkie-Talkie' above). Currently (June 2008), it is not possible to have multiple top_blocks running at the same time, but what you can do is create full flow graphs as hierarchical blocks using <code>gr.hier_block2</code> like in the section above. Then, create a top_block to hold the flow graphs.<br />
<br />
Example:<br />
<br />
<pre><br />
class transmit_path(gr.hier_block2):<br />
def __init__(self):<br />
gr.hier_block2.__init__(self, &quot;transmit_path&quot;,<br />
gr.io_signature(0, 0, 0), # Null signature<br />
gr.io_signature(0, 0, 0))<br />
<br />
source_block = blocks.source()<br />
signal_proc = blocks.other_block()<br />
sink_block = blocks.sink()<br />
<br />
self.connect(source_block, signal_proc, sink_block)<br />
<br />
<br />
class receive_path(gr.hier_block2):<br />
def __init__(self):<br />
gr.hier_block2.__init__(self, &quot;receive_path&quot;,<br />
gr.io_signature(0, 0, 0), # Null signature<br />
gr.io_signature(0, 0, 0))<br />
<br />
source_block = blocks.source()<br />
signal_proc = blocks.other_block()<br />
sink_block = blocks.sink()<br />
<br />
self.connect(source_block, signal_proc, sink_block)<br />
<br />
<br />
class my_top_block(gr.top_block):<br />
def __init__(self):<br />
gr.top_block.__init__(self)<br />
<br />
tx_path = transmit_path()<br />
<br />
rx_path = receive_path()<br />
<br />
self.connect(tx_path)<br />
self.connect(rx_path)</pre><br />
Now, when you start <code>my_top_block</code>, both flow graphs are started in parallel. Note that the hierarchical blocks have explicitly no inputs and outputs defined, they have a null IO signature. Consequently, they don't connect to <code>self</code> as source or sink; they rather define their own sources or sink (just as you would do when defining a hierarchical block as source or sink). The top block simply connects the hierarchical blocks to itself, but does not connect them up in any way.<br />
<br />
Examples for multiple flow graphs:<br />
<br />
<pre>gr-uhd/examples/python/usrp_nbfm_ptt.py</pre><br />
== GNU Radio extensions and tools ==<br />
<br />
GNU Radio is more than blocks and flow graphs - it comes with a lot of tools and code to help you write DSP applications.<br />
<br />
A collection of useful GNU Radio applications designed to aid you is in gr-utils/.<br /><br />
Browse the source code in gnuradio-runtime/python/gnuradio (and other gr-<component>/python directories) to find utilities you can use in your Python code such as filter design code, modulation utilities, and more.<br />
<br />
== Controlling flow graphs ==<br />
<br />
If you have followed the tutorial so far, you will have noticed that a flow graph has always been implemented as a class, derived from <code>gr.top_block</code>. The question remains on how to control one of these classes.<br />
<br />
As mentioned before, deriving the class from gr.top_block brings along all the functionality you might need. To run or stop an existing flow graph, use the following methods:<br />
<br />
{|<br />
|<br />
<br />
| <code>run()</code><br />
|<br />
<br />
| The simplest way to run a flow graph. Calls start(), then wait(). Used to run a flow graph that will stop on its own, or to run a flow graph indefinitely until SIGINT is received.<br />
|<br />
<br />
|-<br />
|<br />
<br />
| <code>start()</code><br />
|<br />
<br />
| Start the contained flow graph. Returns to the caller once the threads are created.<br />
|<br />
<br />
|-<br />
|<br />
<br />
| <code>stop()</code><br />
|<br />
<br />
| Stop the running flow graph. Notifies each thread created by the scheduler to shutdown, then returns to caller.<br />
|<br />
<br />
|-<br />
|<br />
<br />
| <code>wait()</code><br />
|<br />
<br />
| Wait for a flow graph to complete. Flowgraphs complete when either (1) all blocks indicate that they are done, or (2) after stop has been called to request shutdown.<br />
|<br />
<br />
|-<br />
|<br />
<br />
| <code>lock()</code><br />
|<br />
<br />
| Lock a flow graph in preparation for reconfiguration.<br />
|<br />
<br />
|-<br />
|<br />
<br />
| <code>unlock()</code><br />
|<br />
<br />
| Unlock a flow graph in preparation for reconfiguration. When an equal number of calls to lock() and unlock() have occurred, the flow graph will be restarted automatically.<br />
|<br />
<br />
|}<br />
<br />
See the documentation for [http://gnuradio.org/doc/doxygen/classgr_1_1top__block.html <code>gr::top_block</code>] for more details.<br />
<br />
Example:<br />
<br />
<pre><br />
class my_top_block(gr.top_block):<br />
def __init__(self):<br />
gr.top_block.__init__(self)<br />
... # Define blocks etc. here<br />
<br />
if __name__ == '__main__':<br />
my_top_block().start()<br />
sleep(5) # Wait 5 secs (assuming sleep was imported!)<br />
my_top_block().stop()<br />
my_top_block().wait() # If the graph is needed to run again, wait() must be called after stop<br />
... # Reconfigure the graph or modify it<br />
my_top_block().start() # start it again<br />
sleep(5) # Wait 5 secs (assuming sleep was imported!)<br />
my_top_block().stop() # since (assuming) the graph will not run again, no need for wait() to be called</pre><br />
These methods help you to control the flow graph from the outside. For many problems this might not be enough: you don't simply want to start or stop a flow graph, you want to reconfigure the way it behaves. For example, imagine your application has a volume control somewhere in your flow graph. This volume control is implemented by inserting a multiplier into the sample stream. This multiplier is of type <code>blocks.multiply_const_ff</code>. If you check the documentation for this kind of of block, you will find a function <code>blocks.multiply_const_ff.set_k()</code> which sets the multiplication factor.<br /><br />
You need to make the settings visible to the outside in order to control it. The simplest way is to make the block an attribute of the flow graph class.<br />
<br />
Example:<br />
<br />
<pre><br />
class my_top_block(gr.top_block):<br />
def __init__(self):<br />
gr.top_block.__init__(self)<br />
... # Define some blocks<br />
self.amp = blocks.multiply_const_ff(1) # Define multiplier block<br />
... # Define more blocks<br />
<br />
self.connect(..., self.amp, ...) # Connect all blocks<br />
<br />
def set_volume(self, volume):<br />
self.amp.set_k(volume)<br />
<br />
if __name__ == '__main__':<br />
my_top_block().start()<br />
sleep(2) # Wait 2 secs (assuming sleep was imported!)<br />
my_top_block.set_volume(2) # Pump up the volume (by factor 2)<br />
sleep(2) # Wait 2 secs (assuming sleep was imported!)<br />
my_top_block().stop()</pre><br />
This example runs the flow graph for 2 seconds and then doubles the volume by accessing the <code>amp</code> block through a member function called <code>set_volume()</code>. Of course, one could have accessed the <code>amp</code> attribute directly, omitting the member function.<br />
<br />
Hint: making blocks attributes of the flow graph is generally a good idea as it makes extending the flow graph with extra member functions easier.<br />
<br />
== Non-flow graph centered applications ==<br />
<br />
Up until now, GNU Radio applications in this tutorial have always been centered around the one class derived from <code>gr.top_block</code>. However, this is not necessarily how GNU Radio needs to be used. GNU Radio was designed to develop DSP applications from Python, so there's no reason to not use the full power of Python when using GNU Radio.<br />
<br />
Python is an extremely powerful language, and new libraries and functionalities are constantly being added. In a way, GNU Radio extends Python with a powerful, real-time-capable DSP library. By combining this with other libraries you have immense functionality right there at your fingertips. For example, by combining GNU Radio with SciPy, a collection of scientific Python libraries, you can record RF signals in real time and do extensive mathematical operations off line, save statistics to a database and so on - all in the same application. Even expensive engineering software such as Matlab might become unnecessary if you combine all these libraries.<br />
<br />
http://www.scipy.org/<br />
<br />
== Advanced Topics ==<br />
<br />
If you have really read the previous sections, you already know enough to write your first Python GNU Radio applications. This section will address some slightly more advanced functionalities for Python GNU Radio applications.<br />
<br />
== Dynamic flow graph creation ==<br />
<br />
For most cases, the aforementioned way to define flow graphs is completely adequate. If you need more flexibility in your application, you might want to have even more control over the flow graph from outside the class.<br /><br />
This can be achieved by taking the code out of the <code>+init+()</code> function and simply using <code>gr.top_block</code> as a container. Example:<br />
<br />
<pre><br />
... # We are inside some application<br />
tb = gr.top_block() # Define the container<br />
<br />
block1 = blocks.some_other_block()<br />
block2 = blocks.yet_another_block()<br />
<br />
tb.connect(block1, block2)<br />
<br />
... # The application does some wonderful things here<br />
<br />
tb.start() # Start the flow graph<br />
<br />
... # Do some more incredible and fascinating stuff here</pre><br />
If you are writing some application which needs to dynamically stop a flow graph (reconfigure it, re-start it and so) on this might be a more practical way to do it.<br />
<br />
Examples for this kind of flow graph setup:<br />
<br />
<pre>gr-uhd/apps/hf_explorer/hfx.py</pre><br />
== Command Line Options ==<br />
<br />
Python has its own libraries to parse command line options. See the documentation for the module <code>optparse</code> to find out how to use it.<br />
<br />
GNU Radio extends optparse by new command line option types. Use @from gnuradio.eng_option import eng_option' to import this extension. With eng_option, you have the following types:<br />
<br />
{|<br />
|<br />
<br />
| eng_float<br />
|<br />
<br />
| Like the original float option, but also accepts engineering notation like 101.8M<br />
|<br />
<br />
|-<br />
|<br />
<br />
| subdev<br />
|<br />
<br />
| Only accepts valid subdevice descriptors such as A:0 (To specify a daughterboard on a USRP)<br />
|<br />
<br />
|-<br />
|<br />
<br />
| intx<br />
|<br />
<br />
| Only accepts integers<br />
|<br />
<br />
|}<br />
<br />
If your application supports command line options, it would be ever so nice if you could stick to the GNU Radio conventions for command line options. You can find these (along with more hints for developers) in README.hacking.<br />
<br />
Nearly every GNU Radio example uses this feature. Try dial_tone.py for an easy example.<br />
<br />
== Graphical User Interfaces ==<br />
<br />
If you are a Python expert and also have some experience in writing GUIs for Python (using whatever GUI toolkit you like), you might not even need this section. As mentioned before, GNU Radio merely extends Python with DSP routines - so if you like, just go ahead and write a GUI application, add a GNU Radio flow graph to it and define some interfaces to carry GNU Radio information to your application and vice versa. If you want to plot your data, you could use Matplotlib or Qwt.<br />
<br />
However, sometimes you simply want to write a quick GUI application without bothering with setting up widgets, defining all the menus etc. GNU Radio comes with some predefined classes to help you write graphical GNU Radio applications.<br />
<br />
These modules are based on wxWidgets (or to be precise, wxPython), a platform-independent GUI toolkit. You will need some background in wxPython - but don't worry, it is not that complicated and there are several tutorials available on the net. Check the wxPython website for documentation (http://www.wxpython.org/).<br />
<br />
To use the GNU Radio wxWidgets tools, you need to import some modules:<br />
<br />
<pre><br />
from gnuradio.wxgui import stdgui2, fftsink2, slider, form</pre><br />
Here, 4 components were imported from the gnuradio.wxgui submodule. Here's a quick list of the modules (again, not necessarily complete. You will have to browse the modules or the source code in gr-wxgui/python).<br />
<br />
{|<br />
|<br />
<br />
| stdgui2<br />
|<br />
<br />
| Basic GUI stuff, you always need this<br />
|<br />
<br />
|-<br />
|<br />
<br />
| fftsink2<br />
|<br />
<br />
| Plot FFTs of your data to create spectrum analyzers or whatever<br />
|<br />
<br />
|-<br />
|<br />
<br />
| scopesink2<br />
|<br />
<br />
| Oscilloscope output<br />
|<br />
<br />
|-<br />
|<br />
<br />
| waterfallsink2<br />
|<br />
<br />
| Waterfall output<br />
|<br />
<br />
|-<br />
|<br />
<br />
| numbersink2<br />
|<br />
<br />
| Displays numerical values of incoming data<br />
|<br />
<br />
|-<br />
|<br />
<br />
| form<br />
|<br />
<br />
| Often used input forms (see below)<br />
|<br />
<br />
|}<br />
<br />
Next, we have to define a new flow graph. This time, we don't derive from <code>gr.top_block</code> but from <code>stdgui2.std_top_block</code>:<br />
<br />
<pre><br />
class my_gui_flow_graph(stdgui2.std_top_block):<br />
def __init__(self, frame, panel, vbox, argv):<br />
stdgui2.std_top_block.__init__ (self, frame, panel, vbox, argv)</pre><br />
As you can see, there's another difference: the constructor gets a couple of new parameters. This is because a <code>stdgui2.std_top_block</code> does not only include flow graph functionality (it is derived from gr.top_block itself), but also directly creates a window with some basic components (like a menu). This is good news for all of those who just want to quickly hack a graphical application: GNU Radio creates the window and everything, you just need to add the widgets. Here's a list of what you can do with these new objects (this probably won't mean much to you if you have no idea about GUI programming):<br />
<br />
{|<br />
|<br />
<br />
| frame<br />
|<br />
<br />
| The wx.Frame of your window. You can get at the predefined menu by using frame.GetMenuBar()<br />
|<br />
<br />
|-<br />
|<br />
<br />
| panel<br />
|<br />
<br />
| A panel, placed in @frame', to hold all your wxControl widgets<br />
|<br />
<br />
|-<br />
|<br />
<br />
| vbox<br />
|<br />
<br />
| A vertical box sizer (wx.BoxSizer(wx.VERTICAL) is how it is defined), used to align your widgets in the panel<br />
|<br />
<br />
|-<br />
|<br />
<br />
| argv<br />
|<br />
<br />
| The command line arguments<br />
|<br />
<br />
|}<br />
<br />
Now you have all you need to create your GUI. You can simply add new box sizers and widgets to vbox, change the menu or whatever. Some typical functions have been simplified further in the GNU Radio GUI library <code>form</code>.<br />
<br />
form has a great number of input widgets: <code>form.static_text_field()</code> for static text field (display only), <code>form.float_field()</code>, to input float values, <code>form.text_field()</code> to input text, <code>form.checkbox_field()</code> for checkboxes, <code>form.radiobox_field()</code> for radioboxes etc. Check the source code of gr-wxgui/python/form.py for the complete list. Most of these calls pass most of their arguments to the appropriate wxPython objects, so the function arguments are quite self-explanatory.<br /><br />
See one of the examples mentioned below on how to add widgets using form.<br />
<br />
Probably the most useful part of <code>gnuradio.wxgui</code> is the possibility to directly plot incoming data. To do this, you need one of the sinks that come with <code>gnuradio.wxgui</code>, such as <code>fftsink2</code>. These sinks work just as any other GNU Radio sink, but also have properties needed for use with wxPython. Example:<br />
<br />
<pre><br />
from gnuradio.wxgui import stdgui2, fftsink2<br />
<br />
<br />
# App gets defined here ...<br />
<br />
# FFT display (pseudo-spectrum analyzer)<br />
my_fft = fftsink2.fft_sink_f(panel, title=&quot;FFT of some Signal&quot;, fft_size=512,<br />
sample_rate=sample_rate, ref_level=0, y_per_div=20)<br />
self.connect(source_block, my_fft)<br />
vbox.Add(my_fft.win, 1, wx.EXPAND)</pre><br />
First, the block is defined (<code>fftsink2.fft_sink_f</code>). Apart from typical DSP parameters such as the sampling rate, it also needs the <code>panel</code> object which is passed to the constructor. Next, the block is connected to a source. Finally, the FFT window (<code>my_fft.win</code>) is placed inside the <code>vbox</code> BoxSizer to actually display it. Remember that a signal block output can be connected to any amount of inputs.<br />
<br />
Finally, the whole thing needs to be started. Because we need an <code>wx.App()</code> to run the GUI, the start-up code is a bit different from a regular flow graph:<br />
<br />
<pre><br />
if __name__ == '__main__':<br />
app = stdgui2.stdapp(my_gui_flow_graph, &quot;GUI GNU Radio Application&quot;)<br />
app.MainLoop()</pre><br />
<code>stdgui2.stdapp()</code> creates the <code>wx.App</code> with <code>my_gui_flow_graph</code> (the first argument). The window title is set to &quot;GUI GNU Radio Application&quot;.<br />
<br />
Examples for simple GNU Radio GUIs:<br />
<br />
<pre>gr-uhd/apps/uhd_fft<br />
gr-audio/examples/python/audio_fft.py<br />
./gr-uhd/examples/python/usrp_am_mw_rcv.py</pre><br />
And many more.<br />
<br />
== What next? ==<br />
<br />
Young Padawan, no more there is I can teach you. If you have any more questions on how to write GNU Radio applications in Python, there are still a number of resources you can use:<br />
<br />
* Use the source. Especially the examples in gr-<component>/examples/ and gr-utils/ can be very helpful.<br />
* Check the [https://wiki.gnuradio.org/index.php/MailingLists mailing list] archives. Chances are very high your problem has been asked before.<br />
<br />
[[Category:Tutorials]]</div>Willcode4https://wiki.gnuradio.org/index.php?title=Download&diff=8681Download2021-06-07T21:59:34Z<p>Willcode4: </p>
<hr />
<div>= Source Download instructions =<br />
<br />
=== Stable ===<br />
<br />
The '''latest stable release''', as well as older stable releases, of GNU Radio can be found here:<br />
<br />
* https://github.com/gnuradio/gnuradio/releases<br />
<br />
or here<br />
<br />
* http://gnuradio.org/releases/gnuradio/<br />
<br />
Also, check the news (in the box at the right) for announcements on the latest stable releases.<br />
<br />
Signing keys are available with the Github releases. Also see [[ReleaseKey]].<br />
<br />
=== Development ===<br />
<br />
If you prefer the '''latest development code''', wish to contribute to GNU Radio, or want to work with features that haven't yet made it into the stable branch, you can check out the source from the git repository:<br />
<br />
$ git clone https://github.com/gnuradio/gnuradio.git<br />
<br />
Later, to update your local repository you can run:<br />
<br />
$ git pull<br />
<br />
The following branches are under development:<br />
<br />
* master (future 3.10)<br />
* maint-3.9<br />
* maint-3.8.<br />
<br />
By default, the master branch will be checked out. To switch to a different branch:<br />
<br />
git checkout <branch><br />
<br />
=== cgit ===<br />
<br />
The major GNU Radio projects are also mirrored at https://www.gnuradio.org/cgit</div>Willcode4https://wiki.gnuradio.org/index.php?title=Download&diff=8680Download2021-06-07T20:55:24Z<p>Willcode4: </p>
<hr />
<div>= Source Download instructions =<br />
<br />
=== Stable ===<br />
<br />
The '''latest stable release''', as well as older stable releases, of GNU Radio can be found here:<br />
<br />
* https://github.com/gnuradio/gnuradio/releases<br />
<br />
or here<br />
<br />
* http://gnuradio.org/releases/gnuradio/<br />
<br />
Also, check the news (in the box at the right) for announcements on the latest stable releases.<br />
<br />
Signing keys are available with the Github releases. Also see [[ReleaseKey]].<br />
<br />
=== Development ===<br />
<br />
If you prefer the '''latest development code''', wish to contribute to GNU Radio, or want to work with features that haven't yet made it into the stable branch, you can check out the source from the git repository:<br />
<br />
$ git clone https://github.com/gnuradio/gnuradio.git<br />
<br />
Later, to update your local repository you can run:<br />
<br />
$ git pull<br />
<br />
The following branches are under development:<br />
<br />
* master (future 3.10)<br />
* maint-3.9<br />
* maint-3.8.<br />
<br />
By default, the master branch will be checked out. To switch to a different branch:<br />
<br />
git checkout <branch></div>Willcode4https://wiki.gnuradio.org/index.php?title=Download&diff=8679Download2021-06-07T20:50:04Z<p>Willcode4: Removed dead links to Jenkins, old Git info.</p>
<hr />
<div>= Source Download instructions =<br />
<br />
=== Stable ===<br />
<br />
The '''latest stable release''', as well as older stable releases, of GNU Radio can be found here:<br />
<br />
* https://github.com/gnuradio/gnuradio/releases<br />
<br />
or here<br />
<br />
* http://gnuradio.org/releases/gnuradio/<br />
<br />
Also, check the news (in the box at the right) for announcements on the latest stable releases.<br />
<br />
Signing keys are available with the Github releases. Also see [[ReleaseKey]].<br />
<br />
=== Development ===<br />
<br />
If you prefer the '''latest development code''', wish to contribute to GNU Radio, or want to work with features that haven't yet made it into the stable branch, you can check out the source from the git repository:<br />
<br />
$ git clone https://github.com/gnuradio/gnuradio.git<br />
<br />
Later, to update your local repository you can run:<br />
<br />
$ git pull<br />
<br />
The following branches are under development:<br />
<br />
* master (future 3.10)<br />
* maint-3.9<br />
* maint-3.8.<br />
<br />
By default, the master branch will be checked out. To switch to a different branch:<br />
<br />
git checkout <branch><br />
<br />
=== Even more bleeding-edge development code (Katana-edge) ===<br />
<br />
The next branch is too stale for your taste? Some of the developers have exposed their development repositories. If you want to check these out, we're assuming you know what you're doing, so no more explanations:<br />
<br />
* Tom's repos: https://github.com/trondeau</div>Willcode4https://wiki.gnuradio.org/index.php?title=Download&diff=8678Download2021-06-07T20:41:37Z<p>Willcode4: /* Stable */</p>
<hr />
<div>= Source Download instructions =<br />
<br />
=== Stable ===<br />
<br />
The '''latest stable release''', as well as older stable releases, of GNU Radio can be found here:<br />
<br />
* https://github.com/gnuradio/gnuradio/releases<br />
<br />
or here<br />
<br />
* http://gnuradio.org/releases/gnuradio/<br />
<br />
Also, check the news (in the box at the right) for announcements on the latest stable releases.<br />
<br />
Signing keys are available with the Github releases. Also see [[ReleaseKey]].<br />
<br />
=== Development ===<br />
<br />
Get the latest '''weekly development code''' as a tarball:<br />
<br />
* http://jenkins.gnuradio.org/builds/gnuradio-current.tar.gz<br /><br />
SHA1 Sum:<br />
* http://jenkins.gnuradio.org/builds/gnuradio-current.tar.gz.sha1<br />
<br />
If you prefer the '''latest development code''', wish to contribute to GNU Radio, or want to work with features that haven't yet made it into the stable branch, you can check out the source from the git repository:<br />
<br />
<pre>$ git clone --recursive http://git.gnuradio.org/git/gnuradio.git</pre><br />
If you are using a legacy version of git (pre-1.6), use this command '''instead''' of the above:<br />
<br />
<pre>$ git clone --recursive git://git.gnuradio.org/gnuradio</pre><br />
If you prefer a Github workflow, you can also fork or clone from our Github mirror. If you plan to merge your changes into the GNU Radio upstream, this is often the best method.<br />
<br />
<pre>$ git clone --recursive https://github.com/gnuradio/gnuradio.git</pre><br />
Later, to update your local repository you can run:<br />
<br />
<pre>$ git pull<br />
$ git submodule update --recursive</pre><br />
The development code comes in three flavours: master, maint and next (these are in fact the names of the git branches). master is the main branch, which will be the next stable release. next is where all the crazy stuff is happening, the most bleeding edge code out there. maint is a maintenance branch of the most current release, i.e. the latest stable release plus bugfixes.<br />
<br />
If you're using the git cloned code, you can switch between these three branches by going to your git-cloned repository and issuing the 'git checkout' command with the branch name desired. After a checkout, update submodules, like this:<br />
<br />
<pre>$ git checkout maint<br />
$ git submodule update --recursive</pre><br />
=== Even more bleeding-edge development code (Katana-edge) ===<br />
<br />
The next branch is too stale for your taste? Some of the developers have exposed their development repositories. If you want to check these out, we're assuming you know what you're doing, so no more explanations:<br />
<br />
* Tom's repos: https://github.com/trondeau</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=8677ReleaseProcess2021-06-07T20:40:43Z<p>Willcode4: </p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
<br />
== Change freeze ==<br />
<br />
=== Announce ===<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
Around one week unless problems are found.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `-rc0`format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1"<br />
* Merge release PR<br />
* Sync local checkout for later comparison step<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
<br />
=== Download tar.gz and zip ===<br />
If not done in release step<br />
<br />
=== Verify archives ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign archives ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
Add articles to the news section on the wiki<br />
https://github.com/gnuradio/hugo-website#how-to-add-stuff-to-the-website<br />
<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=Download&diff=8676Download2021-06-07T20:38:25Z<p>Willcode4: /* Stable */</p>
<hr />
<div>= Source Download instructions =<br />
<br />
=== Stable ===<br />
<br />
The '''latest stable release''', as well as older stable releases, of GNU Radio can be found here:<br />
<br />
* https://github.com/gnuradio/gnuradio/releases<br />
<br />
or here<br />
<br />
* http://gnuradio.org/releases/gnuradio/<br />
<br />
Also, check the news (in the box at the right) for announcements on the latest stable releases.<br />
<br />
=== Development ===<br />
<br />
Get the latest '''weekly development code''' as a tarball:<br />
<br />
* http://jenkins.gnuradio.org/builds/gnuradio-current.tar.gz<br /><br />
SHA1 Sum:<br />
* http://jenkins.gnuradio.org/builds/gnuradio-current.tar.gz.sha1<br />
<br />
If you prefer the '''latest development code''', wish to contribute to GNU Radio, or want to work with features that haven't yet made it into the stable branch, you can check out the source from the git repository:<br />
<br />
<pre>$ git clone --recursive http://git.gnuradio.org/git/gnuradio.git</pre><br />
If you are using a legacy version of git (pre-1.6), use this command '''instead''' of the above:<br />
<br />
<pre>$ git clone --recursive git://git.gnuradio.org/gnuradio</pre><br />
If you prefer a Github workflow, you can also fork or clone from our Github mirror. If you plan to merge your changes into the GNU Radio upstream, this is often the best method.<br />
<br />
<pre>$ git clone --recursive https://github.com/gnuradio/gnuradio.git</pre><br />
Later, to update your local repository you can run:<br />
<br />
<pre>$ git pull<br />
$ git submodule update --recursive</pre><br />
The development code comes in three flavours: master, maint and next (these are in fact the names of the git branches). master is the main branch, which will be the next stable release. next is where all the crazy stuff is happening, the most bleeding edge code out there. maint is a maintenance branch of the most current release, i.e. the latest stable release plus bugfixes.<br />
<br />
If you're using the git cloned code, you can switch between these three branches by going to your git-cloned repository and issuing the 'git checkout' command with the branch name desired. After a checkout, update submodules, like this:<br />
<br />
<pre>$ git checkout maint<br />
$ git submodule update --recursive</pre><br />
=== Even more bleeding-edge development code (Katana-edge) ===<br />
<br />
The next branch is too stale for your taste? Some of the developers have exposed their development repositories. If you want to check these out, we're assuming you know what you're doing, so no more explanations:<br />
<br />
* Tom's repos: https://github.com/trondeau</div>Willcode4https://wiki.gnuradio.org/index.php?title=Download&diff=8675Download2021-06-07T20:37:55Z<p>Willcode4: /* Stable */</p>
<hr />
<div>= Source Download instructions =<br />
<br />
=== Stable ===<br />
<br />
The '''latest stable release''', as well as older stable releases, of GNU Radio can be found here:<br />
<br />
- https://github.com/gnuradio/gnuradio/releases<br />
<br />
or here<br />
<br />
- http://gnuradio.org/releases/gnuradio/<br />
<br />
Also, check the news (in the box at the right) for announcements on the latest stable releases.<br />
<br />
=== Development ===<br />
<br />
Get the latest '''weekly development code''' as a tarball:<br />
<br />
* http://jenkins.gnuradio.org/builds/gnuradio-current.tar.gz<br /><br />
SHA1 Sum:<br />
* http://jenkins.gnuradio.org/builds/gnuradio-current.tar.gz.sha1<br />
<br />
If you prefer the '''latest development code''', wish to contribute to GNU Radio, or want to work with features that haven't yet made it into the stable branch, you can check out the source from the git repository:<br />
<br />
<pre>$ git clone --recursive http://git.gnuradio.org/git/gnuradio.git</pre><br />
If you are using a legacy version of git (pre-1.6), use this command '''instead''' of the above:<br />
<br />
<pre>$ git clone --recursive git://git.gnuradio.org/gnuradio</pre><br />
If you prefer a Github workflow, you can also fork or clone from our Github mirror. If you plan to merge your changes into the GNU Radio upstream, this is often the best method.<br />
<br />
<pre>$ git clone --recursive https://github.com/gnuradio/gnuradio.git</pre><br />
Later, to update your local repository you can run:<br />
<br />
<pre>$ git pull<br />
$ git submodule update --recursive</pre><br />
The development code comes in three flavours: master, maint and next (these are in fact the names of the git branches). master is the main branch, which will be the next stable release. next is where all the crazy stuff is happening, the most bleeding edge code out there. maint is a maintenance branch of the most current release, i.e. the latest stable release plus bugfixes.<br />
<br />
If you're using the git cloned code, you can switch between these three branches by going to your git-cloned repository and issuing the 'git checkout' command with the branch name desired. After a checkout, update submodules, like this:<br />
<br />
<pre>$ git checkout maint<br />
$ git submodule update --recursive</pre><br />
=== Even more bleeding-edge development code (Katana-edge) ===<br />
<br />
The next branch is too stale for your taste? Some of the developers have exposed their development repositories. If you want to check these out, we're assuming you know what you're doing, so no more explanations:<br />
<br />
* Tom's repos: https://github.com/trondeau</div>Willcode4https://wiki.gnuradio.org/index.php?title=Download&diff=8674Download2021-06-07T20:36:58Z<p>Willcode4: </p>
<hr />
<div>= Source Download instructions =<br />
<br />
=== Stable ===<br />
<br />
The '''latest stable release''', as well as older stable releases, of GNU Radio can be found here:<br /><br />
https://github.com/gnuradio/gnuradio/releases<br /><br />
or here<br /><br />
http://gnuradio.org/releases/gnuradio/<br />
<br />
Also, check the news (in the box at the right) for announcements on the latest stable releases.<br />
<br />
=== Development ===<br />
<br />
Get the latest '''weekly development code''' as a tarball:<br />
<br />
* http://jenkins.gnuradio.org/builds/gnuradio-current.tar.gz<br /><br />
SHA1 Sum:<br />
* http://jenkins.gnuradio.org/builds/gnuradio-current.tar.gz.sha1<br />
<br />
If you prefer the '''latest development code''', wish to contribute to GNU Radio, or want to work with features that haven't yet made it into the stable branch, you can check out the source from the git repository:<br />
<br />
<pre>$ git clone --recursive http://git.gnuradio.org/git/gnuradio.git</pre><br />
If you are using a legacy version of git (pre-1.6), use this command '''instead''' of the above:<br />
<br />
<pre>$ git clone --recursive git://git.gnuradio.org/gnuradio</pre><br />
If you prefer a Github workflow, you can also fork or clone from our Github mirror. If you plan to merge your changes into the GNU Radio upstream, this is often the best method.<br />
<br />
<pre>$ git clone --recursive https://github.com/gnuradio/gnuradio.git</pre><br />
Later, to update your local repository you can run:<br />
<br />
<pre>$ git pull<br />
$ git submodule update --recursive</pre><br />
The development code comes in three flavours: master, maint and next (these are in fact the names of the git branches). master is the main branch, which will be the next stable release. next is where all the crazy stuff is happening, the most bleeding edge code out there. maint is a maintenance branch of the most current release, i.e. the latest stable release plus bugfixes.<br />
<br />
If you're using the git cloned code, you can switch between these three branches by going to your git-cloned repository and issuing the 'git checkout' command with the branch name desired. After a checkout, update submodules, like this:<br />
<br />
<pre>$ git checkout maint<br />
$ git submodule update --recursive</pre><br />
=== Even more bleeding-edge development code (Katana-edge) ===<br />
<br />
The next branch is too stale for your taste? Some of the developers have exposed their development repositories. If you want to check these out, we're assuming you know what you're doing, so no more explanations:<br />
<br />
* Tom's repos: https://github.com/trondeau</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=8673ReleaseProcess2021-06-07T20:32:53Z<p>Willcode4: /* Wiki */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
<br />
== Change freeze ==<br />
<br />
=== Announce ===<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
Around one week unless problems are found.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `-rc0`format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1"<br />
* Merge release PR<br />
* Sync local checkout for later comparison step<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
<br />
=== Download tar.gz and zip ===<br />
If not done in release step<br />
<br />
=== Verify archives ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign archives ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
Add articles to the news section on the wiki<br />
https://github.com/gnuradio/hugo-website#how-to-add-stuff-to-the-website<br />
<br />
=== Web site ===<br />
TBD<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=8672ReleaseProcess2021-06-07T20:31:25Z<p>Willcode4: /* Download tarball and zip */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
<br />
== Change freeze ==<br />
<br />
=== Announce ===<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
Around one week unless problems are found.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `-rc0`format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1"<br />
* Merge release PR<br />
* Sync local checkout for later comparison step<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
<br />
=== Download tar.gz and zip ===<br />
If not done in release step<br />
<br />
=== Verify archives ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign archives ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
TBD<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=8671ReleaseProcess2021-06-07T20:31:05Z<p>Willcode4: /* Sign tarballs */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
<br />
== Change freeze ==<br />
<br />
=== Announce ===<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
Around one week unless problems are found.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `-rc0`format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1"<br />
* Merge release PR<br />
* Sync local checkout for later comparison step<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
<br />
=== Download tarball and zip ===<br />
If not done in release step<br />
<br />
=== Verify archives ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign archives ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
TBD<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=8670ReleaseProcess2021-06-07T20:30:49Z<p>Willcode4: /* Verify tarballs */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
<br />
== Change freeze ==<br />
<br />
=== Announce ===<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
Around one week unless problems are found.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `-rc0`format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1"<br />
* Merge release PR<br />
* Sync local checkout for later comparison step<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
<br />
=== Download tarball and zip ===<br />
If not done in release step<br />
<br />
=== Verify archives ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign tarballs ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
TBD<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=8669ReleaseProcess2021-06-07T20:14:54Z<p>Willcode4: /* Release */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
<br />
== Change freeze ==<br />
<br />
=== Announce ===<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
Around one week unless problems are found.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `-rc0`format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1"<br />
* Merge release PR<br />
* Sync local checkout for later comparison step<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create variants with a -with-volk-X.Y.Z suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
** Volk versions<br />
*** Previous to 3.8.3.0, it was included in all releases<br />
*** 3.8.3.0 -with-volk variant includes v2.0.0<br />
*** 3.8.3.1 and later include both v2.0.0 and latest-stable variants<br />
** Fedora requested we continue to include Volk for 3.8 to keep packaging consistent<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
<br />
=== Download tarball and zip ===<br />
If not done in release step<br />
<br />
=== Verify tarballs ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign tarballs ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
TBD<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseKey&diff=8668ReleaseKey2021-06-07T20:05:04Z<p>Willcode4: </p>
<hr />
<div>= ReleaseKey =<br />
<br />
GNU Radio software signing keys may be downloaded from the Release area on Github.<br />
<br />
Posted here '''for information only''' ... the wiki is not a secure place to obtain keys/fingerprints.<br />
<br />
Software is currently signed by gpg key<br />
E852461BC01D652724600054ABA21950443392F6<br />
which is issued by<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
<br />
pub ed25519 2021-03-05 [SC]<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
uid GNU Radio (Software Signing Key) <info@gnuradio.org><br />
sub ed25519 2021-03-05 [S] [expires: 2022-01-01]<br />
E852461BC01D652724600054ABA21950443392F6</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseKey&diff=8667ReleaseKey2021-06-07T20:04:42Z<p>Willcode4: </p>
<hr />
<div>= ReleaseKey =<br />
<br />
GNU Radio software signing keys may be downloaded in the Release area on Github.<br />
<br />
Posted here '''for information only''' ... the wiki is not a secure place to obtain keys/fingerprints.<br />
<br />
Software is currently signed by gpg key<br />
E852461BC01D652724600054ABA21950443392F6<br />
which is issued by<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
<br />
pub ed25519 2021-03-05 [SC]<br />
723EC3A2B90533C6B93DFBC8ED797743F7951435<br />
uid GNU Radio (Software Signing Key) <info@gnuradio.org><br />
sub ed25519 2021-03-05 [S] [expires: 2022-01-01]<br />
E852461BC01D652724600054ABA21950443392F6</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=8639ReleaseProcess2021-06-03T16:50:28Z<p>Willcode4: </p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
<br />
== Change freeze ==<br />
<br />
=== Announce ===<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
Around one week unless problems are found.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `-rc0`format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1"<br />
* Merge release PR<br />
* Sync local checkout for later comparison step<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create a variant with a -with-volk suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
<br />
=== Download tarball and zip ===<br />
If not done in release step<br />
<br />
=== Verify tarballs ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign tarballs ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
TBD<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4https://wiki.gnuradio.org/index.php?title=ReleaseProcess&diff=8638ReleaseProcess2021-06-03T11:09:11Z<p>Willcode4: /* Sign tag */</p>
<hr />
<div>This page is a work in progress.<br />
<br />
<br />
= Manual Release Process Notes =<br />
Documenting the steps taken todo a release manually, in hopes that it can be automated.<br />
<br />
== Backporting ==<br />
<br />
=== Criteria ===<br />
<br />
=== Cross-referencing ===<br />
<br />
== Change freeze ==<br />
<br />
=== Announce ===<br />
<br />
=== Slow down changes ===<br />
<br />
=== RC plan ===<br />
Around one week unless problems are found.<br />
<br />
== Changelog ==<br />
<br />
=== Maintain ===<br />
<br />
=== Sync/deconflict with other branches ===<br />
<br />
=== Author credits ===<br />
<br />
== Testing ==<br />
<br />
=== CI ===<br />
<br />
=== Manual ===<br />
<br />
== Version change for release ==<br />
<br />
=== Changelog ===<br />
Date and version<br />
<br />
=== Release commit ===<br />
* Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `-rc0`format to help with sort order. For final version, PATCH is `0`<br />
* Create PR with this change, title formatted like "Release v3.8.3.0-rc1"<br />
* Merge release PR<br />
* Sync local checkout for later comparison step<br />
<br />
== Version change for continuation ==<br />
Skip if this is a RC version. The branch will stay linear until the final version is released.<br />
<br />
=== CMakeLists.txt ===<br />
Change CMakeLists.txt to MAJOR.API.ABI.git<br />
<br />
=== Changelog ===<br />
Unreleased version number?<br />
<br />
== Github release ==<br />
<br />
=== Release ===<br />
<br />
* In Github, go to code, branch, and then release list (or tags, then hit releases)<br />
* Draft a new release<br />
* Select branch and enter release version from commit as a tag<br />
* Title same as commit: "Release v..."<br />
* Publish<br />
* Github creates a tar.gz and a zip<br />
* Download these files immediately<br />
* For 3.8, create a variant with a -with-volk suffix<br />
** Check out volk using <code>git submodule update --init</code><br />
** Create tar.gz and zip files<br />
<br />
=== Sign tag ===<br />
Tagging is done against a git clone of <code>git@github.com:gnuradio/gnuradio.git</code>. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.<br />
git checkout <branch_name><br />
git tag -u info@gnuradio.org <tag_name> -m '<tag_name>'<br />
git tag -v <tag_name><br />
git push origin <tag_name><br />
This will use the latest signing key associated with info@gnuradio.org.<br />
<br />
== Software signing ==<br />
<br />
=== Verify or create valid signing key ===<br />
<br />
=== Download tarball and zip ===<br />
If not done in release step<br />
<br />
=== Verify tarballs ===<br />
* Unpack each archive<br />
* Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)<br />
* Keep the tar and zip files locally for a little while in case something comes up<br />
<br />
=== Sign tarballs ===<br />
* Create detacted signatures: `gpg --detach-sign --armor -u info@gnuradio.org filename`<br />
* Verify signatures: `gpg --verify filename.asc`<br />
* Keep the signatures locally for a little while in case something comes up<br />
<br />
=== Upload signatures and public key ===<br />
* On Github release page, edit release<br />
* Click "attach binaries" or drag/drop files<br />
** ...tar.gz.asc<br />
** ...zip.asc<br />
** gnuradio-software-signing-key.asc<br />
* Note that the signing key should also be somewhere else where people can verify it<br />
<br />
== Notification ==<br />
<br />
=== Github ===<br />
Takes care of itself.<br />
<br />
=== Email ===<br />
Point to releases page, changelog page, ask for problem reports via email or issue tracker.<br />
<br />
=== Wiki ===<br />
TBD<br />
<br />
=== Web site ===<br />
TBD<br />
<br />
=== Distros and other packagers ===<br />
TBD</div>Willcode4