- fedora-hams@kernelnewbies.org - Kernelnewbies Mailing Lists

Update libax25 ax25-tool, ax25-apps packages to use active fork?
by Richard Shaw Oct. 2, 2015

Oct. 2, 2015

I'm not sure how many people are on this list, and the number of those that use the ax25 stuff on Fedora but I recently took ownership of the packages. I have been trying to address the bug reports first but I have been asked to switch to the active fork of the projects over the official upstream due to lack of activity. Does anyone on the list have a strong opinion on this? Thanks, Richard KF5OIM

2 2

Retiring From Package Maintainer (for a while at least)
by Randy Berry June 14, 2015

June 14, 2015

I'll be setting aside package maintaining for a while. I've been inactive for a while now anyway. Below are the packages I own and will orphan as soon as a primary maintainer is found to pick them up. LinLog -- A ham radio logbook for Linux ( master f22 f21 f20 ) aldo -- A morse tutor ( master f22 f21 f20 ) ax25-apps -- AX.25 ham radio applications ( master f22 f21 f20 ) ax25-tools -- Tools used to configure an ax.25 enabled computer ( master f22 f21 f20 ) callgit -- A tool for Ham Radio Operators to look up call-signs on the web ( master f22 f21 f20 ) chirp -- A tool for programming two-way radio equipment ( master f22 f21 f20 ) colrdx -- DX-cluster client with curses color support ( master f22 f21 f20 ) dxcc -- Small utility which determines the ARRL DXCC entity of a ham radio callsign ( master f22 f21 f20 ) fldigi -- Digital modem program for Linux ( master f22 f21 f20 ) klog -- A Ham radio logging program for KDE ( master f22 f21 f20 ) libax25 -- AX.25 library for hamradio applications ( master f22 f21 f20 ) lpsk31 -- A ncurses application for ham radio communications using PSK31 digital mode ( master f22 f21 f20 ) orc -- The Oil Run-time Compiler ( el6 ) splat -- Analyze point-to-point terrestrial RF communication links ( master f22 f21 f20 ) twlog -- Records basic ham radio log information ( master f22 f21 f20 ) unixcw -- Shared library for Morse programs ( master f22 f21 f20 ) wxapt -- Console application for decoding and saving weather images ( master f22 f21 f20 ) xconvers -- Ham radio convers client similar to IRC for X/GTK ( master f22 f21 f20 ) xfhell -- GTK based Ham Radio application for the Hellschreiber communications mode ( master f22 f21 f20 ) xgridloc -- A GTK+ application for the calculation of Maidenhead QRA Locators ( master f22 f21 f20 ) xnec2c -- GTK based graphical wrapper for nec2c ( master f22 f21 f20 ) xwxapt -- GTK+ graphical application for decoding and saving weather images ( master f22 f21 f20 ) Some packages already have co-maintainers. Many packages are already in need of updating. Please let me know if you are interested in owning any of these packages. Thanks!

1 0

Another Introduction
by Jerry DeLisle April 10, 2015

April 10, 2015

On 04/05/2015 12:52 PM, Iain R. Learmonth wrote:> Hi, > > I understand that as a prospective package maintainer for Fedora I'm > encouraged to send an email to introduce myself to devel. As I plan to be > working on amateur radio software, I've copied the fedora-hams mailing list > too. > Hi All, I am currently a GCC Gnu Fortran compiler maintainer. Since I am also a Ham Radio Operator I am interested in assisting others with the ham software. So if any developers/users have need of coding assistance, debugging, or testing, please let me know and I will see if I can help. I do 95% of my work on F21. I am in a "portable" situation right now so do not have my full station set up yet. I do desire to get up to speed on the ham software though. 73 Jerry KF7RCC

1 0

Re: Packaging Linrad for Fedora
by John C. Peterson April 8, 2015

April 8, 2015

On Tue Apr 7 22:52:38 EDT 2015, Leif Asbrink wrote: > > There are two solutions to this problem. One would be to modify > > Linrad to look for shared libs with the needed device support at > > run time, using something like dlopen(). > This is already implemented. Linrad uses dlopen on all hardware > related libraries and would thell the uset what library is missing. > It is then up to the user to search the Internet for libbladeRF.so > or whatever is missing. Hej Leif, I did a quick (and uneventful) build of Linrad last night to refresh my memory of what all is involved. As you noted, the configure script informs you about any missing 3-rd party software for SDR device support. I have a question that I didn't have time to dig into and answer myself. If a device support library is missing (e.g. libperseus-sdr.so) at compile time, can the Linrad executable (via your dlopen() code) still find that library at runtime? Or must the support library and any associated header files for that device be installed at compile time for it to find it at runtime? 73, John -- John C. Peterson, KD6EKQ mailto:jcp@eskimo.com San Diego, CA U.S.A

2 1

Re: Packaging Linrad for Fedora
by John C. Peterson April 8, 2015

April 8, 2015

On Tue Apr 7 07:27:42 EDT 2015, Leif Asbrink wrote: > > The first step in Fedora packaging is to check all the licensing > > issues. Iain has already done the important leg work of verifying that > > the license (MIT) is acceptable to Fedora, so that's an important hurdle > > that's been cleared. > Hello John, > There is a non-free library for Perseus that is available as source > code on the Internet, a non-free rpm package for Elad FDM-S1. > Linrad comes with the commands required to download and install them. > There is also the Adlink PCIe-9842 for which one has to sign > a non-disclosure agreement to get the source code. (It provides > a real-time bandwidth of 100 MHz!) Hi Leif, There would be some other "leg work" to do before packaging Linrad, namely packaging the software that it depends on. Some of the dependencies have already been packaged, some of them have not. (For example, I just checked and Fedora has nasm and svgalib already packaged). We would want to get the other dependencies with suitable license terms (like rtl-sdr, etc.) packaged first. As far as the dependencies you described above, they could not be packaged for Fedora. (Don't shoot the messenger. For every piece of software I have packaged, I have had to give up on 5 or 10 others because they didn't have licenses suitable for Fedora). The reviewers are very strict about this. It's the price we pay for living in a society that has become so litigious. There are two solutions to this problem. One would be to modify Linrad to look for shared libs with the needed device support at run time, using something like dlopen(). Another approach would be to provide instructions for users on how to get the non-freely licensed dependencies installed and then rebuild the Linrad rpm (the command "rpmbuild -ba linrad.spec" does that). There are already a few other Fedora packages that do this. One example is the Atlas linear algebra package. It optimizes itself to your hardware at compile time, so there is simply NO way to distribute Atlas packages that are optimized for all machines. If you want an optimized Atlas for your system, you must rebuild it yourself. > > > I don't think it would deter your changes of a Linrad package getting > > approved, but I did notice one thing that could use a little polish. Unix > > (and Linux) users often have an expectation that parameter files are > > always installed in a standard location (rather than the CWD). > This would be a really bad idea. It is often a good idea to run > several instances of Linrad in parallel and then they need different > parameters. The implications of your suggestion is that there should > be a layer on top of the parameter settings in which the user could > browse a linrad directory for a certain set of parameters. Also functions > to copy parameter sets would be needed. Actually the functions > that the normal directory three supplies. This would make Linrad more > difficult to use and would become an obstacle for users so if it is > a requirement for a Fedora package I feel it is better to leave > Linrad unpackaged. As I mentioned, this probably would not get the package rejected. Just expressing a personal preference. I hope you are not too discouraged, packaging is a lengthy and often annoying and tedious process. 73, John -- John C. Peterson, KD6EKQ mailto:jcp@eskimo.com San Diego, CA U.S.A

2 1

Re: Self Introduction: Iain R. Learmonth
by John C. Peterson April 7, 2015

April 7, 2015

On Tue, 7 Apr 2015 11:09:51 +0100, Iain R. Learmonth wrote: > On Mon, Apr 06, 2015 at 11:56:34PM -0700, John C. Peterson wrote: > > Welcome to the Fedora development community. I took a quick look at > > your package submission and it indicates you need a sponsor. Do you > > have someone lined up to sponsor you yet? > Hi John, > > I do not have a sponsor lined up. If you have the time I would appreciate it > if you could take that role. Hello Iain, I have never sponsored someone, so I will need to check to see if I meet the requirements for that role. If I don't meet the requirements, I can help you locate a qualified person to sponsor you instead. > This is not a large package, it's a simple Python application, so hopefully > would be quite easy to review. > > Thanks, Iain It looks like you have done your homework, but I'll just reiterate that you should check out any (serious) problems identified by the rpmlint and fedora-review scripts. They often flags many things that are not really an issue, so don't worry about eliminating every warning. 73, John -- John C. Peterson, KD6EKQ mailto:jcp@eskimo.com San Diego, CA U.S.A

2 1

Re: linrad (was: Self Introduction: Iain R. Learmonth)
by John C. Peterson April 7, 2015

April 7, 2015

On Mon Apr 6 15:30:05 EDT 2015, Leif Asbrink, leif at sm5bsz.com wrote; > Dear Iain, if you find the Linrad project interesting and if you > or someone you know is interested in helping to make it fit to > become a Fedora (or Debian or whatever) package, please have > a look at the repo and tell me what would have to be done. > I have built Linrad several times and don't recall having any trouble. I don't think there is anything to worry about there. The first step in Fedora packaging is to check all the licensing issues. Iain has already done the important leg work of verifying that the license (MIT) is acceptable to Fedora, so that's an important hurdle that's been cleared. I can appreciate the time you spent getting Linrad to run fast. I have an inexpensive dual core Celeron laptop and it runs Linrad comfortably, at only about 50% loading. That's with one of the inexpensive Realtek rtl2832u DVB dongles, running at the maximum of 2.5 MSPS. (Had that running the weekend of the recent ARRL contest, and the waterfall on 10m was quite a sight). I don't think it would deter your changes of a Linrad package getting approved, but I did notice one thing that could use a little polish. Unix (and Linux) users often have an expectation that parameter files are always installed in a standard location (rather than the CWD). You could leave things as they are on Windows and Macintosh, but under Linux have your *.par parameter files be located in the $HOME/.linrad/ directory. You could always check an appropriately named environment variable to accomodate the user that wants it somewhere else. (Maybe even allow sub-directories of $HOME/.linrad/ that contain *.par files for different radios). Anyhow, thanks Leif for all your work on Linrad, it's a great program. -- John C. Peterson, KD6EKQ mailto:jcp@eskimo.com San Diego, CA U.S.A

2 1

Re: Self Introduction: Iain R. Learmonth
by John C. Peterson April 7, 2015

April 7, 2015

On Sun Apr 5 15:52:50 EDT 2015, Iain R. Learmonth wrote: > I have packaged pyqso, a logging tool for radio amateurs, and have submitted > this for review. If you have some time, I would appreciate it if you could > take a look. > > https://bugzilla.redhat.com/show_bug.cgi?id=1209054 Hello Iain, Welcome to the Fedora development community. I took a quick look at your package submission and it indicates you need a sponsor. Do you have someone lined up to sponsor you yet? 73, John -- John C. Peterson, KD6EKQ mailto:jcp@eskimo.com San Diego, CA U.S.A

2 1

Self Introduction: Iain R. Learmonth
by Iain R. Learmonth April 6, 2015

April 6, 2015

Hi, I understand that as a prospective package maintainer for Fedora I'm encouraged to send an email to introduce myself to devel. As I plan to be working on amateur radio software, I've copied the fedora-hams mailing list too. I've been contributing to Debian as a packager, amongst other things, since January 2014. I am involved in the Debian Hamradio Maintainers team and you can see a list of the packages I've worked on here: https://qa.debian.org/developer.php?login=irl%40fsfe.org I am also working on a Debian Hamradio Blend. Blends in Debian are based entirely on packages that exist in Debian and aim to provide easy methods of getting the right software, and configuring it, to perform certain tasks. This concept seems similar to the Fedora Spins concept. More information about the Debian Hamradio Blend can be found here: http://blends.debian.org/hamradio/ While there are a couple of packages I have plans to package for Fedora, I think my main contribution to Fedora will be through collaboration the the Fedora Amateur Radio SIG, sharing information about bugs and patches, discovering new software to package and working to resolve upstream issues. I have packaged pyqso, a logging tool for radio amateurs, and have submitted this for review. If you have some time, I would appreciate it if you could take a look. https://bugzilla.redhat.com/show_bug.cgi?id=1209054 I am in #fedora-hams on Freenode (nick is irl) if you would like to contact me. You can also email me at irl(a)fsfe.org (0xE9846C49). Thanks, Iain. -- e: irl(a)fsfe.org w: iain.learmonth.me x: irl(a)jabber.fsfe.org t: EPVPN 2105 c: 2M0STB g: IO87we p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49

2 4

Hamlib 3 pre-release package (and others)
by Richard Shaw Nov. 2, 2014

Nov. 2, 2014

I've been working on packaging the wsjt suite of programs in my COPR repository: http://copr.fedoraproject.org/coprs/hobbes1069/WSJT/ Because wsjtx required hamlib3 which is not yet released I developed a parallel installable package, all the basenames have "3" appended to them (binaries, libraries, include dir, etc). Along those lines, I will hopefully have a working wsjtx package here shortly. I've also built the required package chain to get the wsjt suite of programs working on EPEL 7... Thanks, Richard

1 0