This is mainly a wish, although it also is a "heads up" that I am looking into doing some of this myself. If and when I find the time (that being a big IF as I am a Graduate Research Assistant and constantly programming other stuff), and/or if someone else does the work, I would like to see Amateur (Ham) Radio applications added to the portage tree. While I recognize that probably 99% of Gentoo users likely will never touch the stuff, most other major Linux distributions have Amateur Radio applications/packages available either directly or as extras. Some top Linux people (for example Alan Cox, who wrote a lot of the base Linux AX.25 framework and applications) are into Amateur Radio as well. The issue then arises as to where Linux Amateur Radio apps go. Should existing portage directories be used, or new ones created? You need somewhere to put the library files (many apps utilize the libax25 package), somewhere to put the additional base network daemons and base utilities (ax25tools / ax25apps), and somewhere to put more-generic user applications (morse code tutors, etc.). My first guess would be app-ax25 and net-ax25 (or app-ham/net-ham or app-aradio/net-aradio) along with putting the base AX.25 libraries in sys-libs. But this might be construed as overkill; while a directory such as app-ax25 likely would contain dozens of applications, net-ax25 (daemons only?) likely would contain relatively few by comparison. And I do not know what Gentoo's standards are for justifing a new portage directory. I'd prefer to see someone settle what layout portage will have for Amateur Radio apps *before* someone actually creates ebuilds for them in order to prevent future headaches. This should be done even if just to ensure that more than one person can create Amateur Radio program ebuilds that reference each other. Unless someone is really up to it, this is NOT meant to be a Gentoo 1.4 item. It is something for future consideration. (AX.25 = Amateur Radio's transport protocol; another X.25 derivative like TCP/IP, except that AX.25 is designed for low-speed links and uses FCC & related issued callsigns instead of IP addresses. Not all Linux Amateur Radio applications use Linux's AX.25 implementation; some have their own, some don't do any network access, etc. Someone with at least some familiarity with these quirks as people have implemented them over the years is going to have to maintain this branch, as well as decide on the directory names.)
I would recommend a new directory, perhaps: app-radio, app-amateur. -Ryan KE6ZTD
I'm interested in getting xastir working. That requires a pile of applications and daemons to be there... So, has any progress been made on any apps/daemons? -Paul N2KIQ
I'll be happy to add an app-radio to the portage tree if packages are made.
I might start on these this weekend working from libax25 up if someone doesn't mind holding my hand when it comes to starting out writing ebuilds and I have a POC to give them to. The directions online are not the clearest. I have written crude ebuilds for libax25 in the past, but I am not sure if they are the most correct / how to verify nothing built outside the tree and everything built where it was supposed to / etc. My primary concern is that many Amateur Radio programs simply use makefiles (although libax25 and the base stuff is well behaved) and do not have any sort of configuration scheme for said files outside of the makefile. This might lead to having to do heavy patching, etc. to enforce CFLAGS utilization and similar. Work on such ebuilds might be better off for someone who really knows python and the ebuild system well. But given basic ebuild building techniques, I can handle the base cases.
from the alpha numerics you two splashed at each other, I take it you're into amateur radio, ryan, hence chucking this your way.
Created attachment 8022 [details] Ebuild for dev-libs/libax25 I'll do you one better.. :) I worked on these last night.
Created attachment 8023 [details, diff] Ebuild for libax25 I'll do you one better.. :) I worked on these last night.
Created attachment 8024 [details] Ebuild for app-radio/ax25-tools
Created attachment 8025 [details] Ebuild for app-radio/ax25-tools
Created attachment 8026 [details] Ebuild for dev-libs/libgeotiff Ebuild for library that xastir depends upon.
Created attachment 8027 [details] Ebuild for dev-libs/shapelib Another dependency for xastir.
Created attachment 8028 [details] Ebuild for app-radio/xastir The long awaited xastir. :)
Sorry for the plethora of email & stuff. These are functionally untested but they compile nicely.
Created attachment 8046 [details] First Cleanup dev-libs/libax25 (-0.0.10 tested) ebuild Cleanup on proposed dev-libs/libax25 (I'm not going to throw mine here since we are so close, and ebuilds are so simple). "pmake" replaced with "emake" (as per skel.ebuild). Homepage, description set properly. Keywords set to "~x86" since this package has not been formally released yet. Header line reset (I don't have CVS running locally to confirm if the first one was right). Note the current libax25 at sourceforge is 0.0.10; the ax25.sf.net webpage is stale. I can bring up a PPC (Dual G4/500) system with Gentoo to test for PPC, but I do not know the status of AX.25 support on PPC, nor have I installed Gentoo on it yet. Minor technical arguments: 1. Should it be dev-libs/libax25 or sys-libs/libax25 ? Gentoo seems split on this. Libusb is in dev-libs, while libieee1284, libchipcard, etc. are in sys-libs. 2. Should we create a ax25 USE flag so if someone sets USE="... ax25 ..." Gentoo pulls in libax25, ax25tools, and ax25apps? What about a virtual/libax25 (even though there is only really one, like libc)? 3. Libax25 assumes a /etc/ax25 path; but doesn't seem to have any /etc files of its own. Libax25 also does not install any obvious documents; do we want to copy its changelog and/or other items to /usr/share/doc manually? 4. Someone with a good C knowledge and lots of time should screen the libax25/ax25apps/ax25tools packages for obvious overflows. These packages have been historically known for issues. That is part of the reason after all these years the code still considers itself alpha status (see NEWS).
Comment on attachment 8046 [details] First Cleanup dev-libs/libax25 (-0.0.10 tested) ebuild (Attempt to add comments due to multipart-post failure with Netscape?) Cleanup on proposed dev-libs/libax25 (I'm not going to throw mine here since we are so close, and ebuilds are so simple). "pmake" replaced with "emake" (as per skel.ebuild). Homepage, description set properly. Keywords set to "~x86" since this package has not been formally released yet. Header line reset (I don't have CVS running locally to confirm if the first one was right). Note the current libax25 at sourceforge is 0.0.10; the ax25.sf.net webpage is stale. I can bring up a PPC (Dual G4/500) system with Gentoo to test for PPC, but I do not know the status of AX.25 support on PPC, nor have I installed Gentoo on it yet. Minor technical arguments: 1. Should it be dev-libs/libax25 or sys-libs/libax25 ? Gentoo seems split on this. Libusb is in dev-libs, while libieee1284, libchipcard, etc. are in sys-libs. 2. Should we create a ax25 USE flag so if someone sets USE="... ax25 ..." Gentoo pulls in libax25, ax25tools, and ax25apps? What about a virtual/libax25 (even though there is only really one, like libc)? 3. Libax25 assumes a /etc/ax25 path; but doesn't seem to have any /etc files of its own. Libax25 also does not install any obvious documents; do we want to copy its changelog and/or other items to /usr/share/doc manually? 4. Someone with a good C knowledge and lots of time should screen the libax25/ax25apps/ax25tools packages for obvious overflows. These packages have been historically known for issues. That is part of the reason after all these years the code still considers itself alpha status (see NEWS).
Created attachment 8048 [details] First cleanup app-radio/ax25-tools (-0.0.8 tested) ebuild See libax25 comments. app-radio/libax25 dependancy changed to ">=dev-libs/libax25-0.0.5" (if sys-libs is desired, change). Sys-libs/zlib dependancy added (it's in the INSTALL documentation). "make... installconf" added to install sample configuration files to /etc/ax25. Gentoo's configuration protection system still prevents overwrites of user provided settings. Known issues (app-radio/ax25-tools - this revision): 1. User documentation goes into "/usr/share/doc/ax25-tools". This is semi-contrary to what seems to be Gentoo's policy of using "/usr/share/doc/{product}-{product_revisions}-{ebuild_revision(if any)}. 2. The autoconf system in the source code package checks for X Windows. (Why?)
Created attachment 8052 [details] Initial Ebuild app-radio/ax25-apps (-0.0.6 tested) See libax25, ax25-tools comments. This one does not have a listed zlib requirement. ax25-tools is not believed to be a dependancy, but libax25 is. Known bugs: This also installs documentation into /usr/share/doc/ax25-apps without adding a revision.
Wonderful! Please also (someone?) consider the licenses that these are actually released under. I didn't pay too much attention to licenses while generating the ebuilds. -Paul N2KIQ
Libax25 is under the Lesser GPL 2.1. Ax25-apps and ax25-tools are under the GPL-2. Hence, whomever does the next change round will have to modify the libax25 ebuild to point to LGPL-2.1 ; the others are fine IIRC. (The only reason that wasn't fixed the first time was I misread libax25's license to be GPL-2 with a quick glance.) I found the X dependant program in ax25-tools. "smdiag" requires the base X11 headers. It is possible to compile ax25-tools "--with-x" and "--without-x" (and hence without smdiag); we may wish to take advantage of this since many ax25 boxes are headless routers and/or text-based. Implementation suggestions? Also of note is that the copyright headers need to be updated to 2003. I know I did one ebuild, but the others need correction. Is there any desired order of implementation of the app-radio ebuilds? Are we looking for a sampling, or do we want to attack a category Y of things first, etc. Not everything can be tested by us; some programs are quite specialized (i.e. remote control of radio X -- we can compile it and run it, but we don't have radio X to test). I'd be a bit careful working on Xastir; their own website talks about "ensure you compile A before B lest you run into problems."
FYI I started on /etc/init.d scripts for the -tools and -apps daemons. But my system is refusing to recongnize I have a BPQ interface (AX.25 over Ethernet) "active" for testing effectively to /dev/null, and hence I can't get them to all start/stop, or even base programs like "call" to work. (Yes, the callsign I placed in /etc/ax25/axports matches the one I configured on the BPQ interface, which is up (along with the corresponding ethernet interface). No, you cannot attach a KISS interface to /dev/null. I will see if this is a fluke, if BPQ goes hunting down other systems and needs one active, or "normal" behavior with a Slackware system tomorrow. Worse case is I attach a TNC and just leave the radio off.)
Created attachment 8182 [details] First cleanup dev-libs/libax25 (-0.0.10 tested) ebuild + axports file Updated dev-libs/libax25 ebuild; includes copying of default axports file. The ebuild has been modified slightly to copy libax25/files/axports.gentoo to /etc/ax25/axports . It is though that libax25 should create said file since it seems to consider it in the build process, and both ax25-tools and ax25-apps require it to map "interface names" (as defined in /etc/ax25/axports ; they may be arbitrary) to callsigns. Since they both depend on libax25, it makes sense to put it here. The tarball/Gzip archive is routed in the /usr/portage/dev-libs directory (i.e. it's internal filenames are prefixed with libax25/).
Created attachment 8184 [details] First modified app-radio/ax25-apps (-0.0.6 tested) - init.d files, alpha ax25rtd cache creation code First modified app-radio/ax25-apps. Includes init.d files for ax25ipd, ax25mond, and ax25rtd. Also includes alpha code to create the /var/lib/ax25/ax25rtd/ directory tree, and place two blank files there (ip_cache and ax25_cache), allowing ax25rtd to start. NOTES: 1. ax25ipd cannot start unless the TTY it points to for interfacing to a TTY or a serial port is pointed to a real devfs entry. But the Gentoo init system will think is has indeed started, and will have to be "zap"ped to allow start after fixing. The axports file really needs to be modified by the user before almost anything AX.25-ish can be used. In general, a user cannot set up a daemon without properly configuring it first (and since we cannot know their setup, I do not know what Gentoo wants for defaults). 2. ax25rtd supporting blank file insert code *has not been tested* beyond allowing the daemon to start. It has not been tested with live data, and then shutdown/forced to write said data out, etc. It is unknown what would occur if there is already a cache in existance; should we attempt to detect such? I have not figured out how to get ax25rtd to create its own initial cache, and that information is eluding me online. 3. All other older comments still stand (see libax25, etc.). This still installs documentation into /usr/share/doc/ax25-apps without adding a revision. 4. I forgot to modify the license for the libax25 ebuild before the previous submission. I have now set it to "LGPL-2.1" locally, but if you modify the libax25 ebuild yourself please copy said trivial modification. TGZ file is routed in /usr/portage/app-radio (contains ax25-apps/*).
Sorry about the delays; I just finished one college quarter, started another, and have been given a ton of work to do as a Graduate Research Assistant on short order. My college position is not exactly where I'd like to be, so I am trying to rectify that as well. I know I personally have not been able to work on this in over a month. But I will try to get at least the core stuff (libax25/ax25-tools/ax25-apps) done. Most of the work has already been completed. The main TODOs are what Gentoo offers for example files, the init files (for ax25-tools) and if we want to patch the apps so a failed startup causes a failure message with the init system instead of reporting "success." (I have not had a chance to look, but I think this may be due to the daemons forking and then checking their configuration files.) As said before, we really need to decide how to prioritize what packages go in what order, and I'm not quite sure what is popular in the Linux Amateur Radio world nowadays. Otherwise, we could create 100's of random packages that no one really uses.
Committed to media-radio
I tried to get my ebuild for 7plus into portage (http://bugs.gentoo.org/show_bug.cgi?id=21492), but it has not been included yet. It seems like nobody feels responsible ;-) I have written further ham radio ebuilds, but did not want to submit them before 7plus was included. They are at http://robsh.de/gentoo/index.html and were announced on linux-hams, but I got no feedback. Perhaps we can merge our versions. 73, Robert, DL1NC
I propose we hold some sort of inaugural chat for media-radio on Freenode. Keep in mind though that I am not a Gentoo Portage maintainer (IANAGPM). That way we can see who is interested in making/testing what ebuilds, come up with starting ground rules, see what USE flags we want (ax25? netrom?), and similar. I only have one class + PhD research during the summer, so I would like to bang out around one ebuild per week (with x86 and ppc testing) if reasonably possible. --- N2URO
