Bug 12232 - WISH: AX.25/Amateur Radio ebuild files
|
Bug#:
12232
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P5
|
|
Resolution: FIXED
|
Assigned To: rphillips@gentoo.org
|
Reported By: n2uro@aol.com
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: WISH: AX.25/Amateur Radio ebuild files
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2002-12-16 01:10 0000
|
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.
Sorry for the plethora of email & stuff. These are functionally untested but
they compile nicely.
Created an attachment (id=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).
(From update of attachment 8046 [details])
(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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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.
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