Move ircDDBGateway to use GNU Autoconf

[mcdermj]

This is the second chunk of moving the entire repository over to GNU Autoconf for building on Linux. It provides configuration for ircDDBGateway. Like DStarRepeater, there is a --without-gui option to build only the command line utilities. Also, even if you enable the GUI pieces, the command line programs are only built with libwxbase.

Please note that commits 15d8842 and c53e103 both change .cpp files to add additional include files. These will need to be tested on Windows before this change is pulled as I do not have my MS development environment up yet. I do not anticipate there are any problems with these, but I never really know without washing it through the compiler.

[F4FXL]

Hi,

Before we had this set of *.mk files to configure various pathes (config, data ...). How is this achieved now using the autoconf stuff ? I have´none of my systems using the /home/opendv variant, and it seems that autoconf now defaults to this setup.

73 Geoffrey F4FXL / KC3FRA

[mcdermj]

On Mar 14, 2016, at 1:49 AM, Geoffrey Merck notifications@github.com wrote:

Hi,

Before we had this set of *.mk files to configure various pathes (config, data ...). How is this achieved now using the autoconf stuff ? I have´none of my systems using the /home/opendv variant, and it seems that autoconf now defaults to this setup.

I’m removing that in the next couple of days and it’ll default to the more standard /usr/share, /etc, and friends. The paths are changed by using the standard autoconf stuff. You can get help for configure by doing a ./configure —help. It’ll show you the paths changing stuff:

Installation directories: --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [PREFIX]

By default, make install' will install all the files in /usr/local/bin', /usr/local/lib' etc. You can specify an installation prefix other than/usr/local' using --prefix', for instance--prefix=$HOME'.

For better control, use the options below.

Fine tuning of the installation directories: --bindir=DIR user executables [EPREFIX/bin] --sbindir=DIR system admin executables [EPREFIX/sbin] --libexecdir=DIR program executables [EPREFIX/libexec] --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] --datarootdir=DIR read-only arch.-independent data root [PREFIX/share] --datadir=DIR read-only architecture-independent data [DATAROOTDIR] --infodir=DIR info documentation [DATAROOTDIR/info] --localedir=DIR locale-dependent data [DATAROOTDIR/locale] --mandir=DIR man documentation [DATAROOTDIR/man] --docdir=DIR documentation root [DATAROOTDIR/doc/dstarrepeater] --htmldir=DIR html documentation [DOCDIR] --dvidir=DIR dvi documentation [DOCDIR] --pdfdir=DIR pdf documentation [DOCDIR] --psdir=DIR ps documentation [DOCDIR]

I think I’ll end up changing it so that —prefix defaults to /usr and —sysconfdir defaults to /etc. For the OpenDV apps, CONF_DIR maps to —sysconfdir, DATA_DIR maps to —datadir. You can check out what all these variables get set to by inspecting config.log after running ./configure. There’s probably some fine tuning that needs to go on here too.

73 Geoffrey F4FXL / KC3FRA

— Reply to this email directly or view it on GitHub.

Jeremy McDermond (NH6Z) Xenotropic Systems mcdermj@xenotropic.com

[F4FXL]

Hi,

I changed the pathes and still it gets compiled with /home/opendv ..... I will do dome more testing

[F4FXL]

Nvermind I am stupid ....

[F4FXL]

Hi,

I noticed a small issue : make install does not create the log dir if it does not exist

73 Geoffrey F4FXL / KC3FRA

[vk4tux]

Why has remotecontrold been removed ?

[mcdermj]

Nothing has intentionally been removed.

I think that it just slipped through the cracks because I’m not really sure what to do with it. It’s a misnomer. A program ending in ‘d’ isn’t a “command line equivalent”, it’s a daemon. Daemons are processes that run continuously and do background tasks for the system (see https://en.wikipedia.org/wiki/Daemon_(computing)). The ‘d’ stands for ‘daemon.’ remotecontrold isn’t a daemon. It’s a one-shot command line utility to get the ircDDBGateway daemon to do something. So, it really needs to NOT be remotecontrold, but something else. It can’t be remotecontrol, because this is the GUI utility. The reason it probably came up in my brain is that daemons live in /usr/sbin. Command line utilities live in /usr/bin. It would be awkward to put this in /usr/bin.

I think for now, I’ll submit a PR to at least build it and shove it in /usr/bin. But this is clearly wrong, and we need to come up with some other nomenclature on it. Maybe something like dstarctl?

On Apr 19, 2016, at 5:16 AM, vk4tux notifications@github.com wrote:

Why has remotecontrold been removed ?

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub

Jeremy McDermond (NH6Z) Xenotropic Systems mcdermj@xenotropic.com

[vk4tux]

Well, it s one of my main tools in various scripting for linking and interlock control on G2/ircddbgateway morph's ;

!/bin/bash

echo " U" >/dstar/tmp/link-c sleep 3

echo $1

if echo "$1" | grep " *unlink" then /usr/local/bin/remotecontrold zl2vh__c unlink

exit 0

else

/usr/local/bin/remotecontrold zl2vh__c link never $1

fi

You guys pulled my complete host files with gateways into the latest github release. remotecontrol GUI chokes on these and the scroll time is tiresome. using clinkto ref003-c etc is fast and easy on terminal.

On ssh access, non graphical systems, it is essential.

On 20/04/16 02:03, Jeremy McDermond wrote:

Nothing has intentionally been removed.

I think that it just slipped through the cracks because I’m not really sure what to do with it. It’s a misnomer. A program ending in ‘d’ isn’t a “command line equivalent”, it’s a daemon. Daemons are processes that run continuously and do background tasks for the system (see https://en.wikipedia.org/wiki/Daemon_(computing)). The ‘d’ stands for ‘daemon.’ remotecontrold isn’t a daemon. It’s a one-shot command line utility to get the ircDDBGateway daemon to do something. So, it really needs to NOT be remotecontrold, but something else. It can’t be remotecontrol, because this is the GUI utility. The reason it probably came up in my brain is that daemons live in /usr/sbin. Command line utilities live in /usr/bin. It would be awkward to put this in /usr/bin.

I think for now, I’ll submit a PR to at least build it and shove it in /usr/bin. But this is clearly wrong, and we need to come up with some other nomenclature on it. Maybe something like dstarctl?

On Apr 19, 2016, at 5:16 AM, vk4tux notifications@github.com wrote:

Why has remotecontrold been removed ?

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub

Jeremy McDermond (NH6Z) Xenotropic Systems mcdermj@xenotropic.com

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/dl5di/OpenDV/pull/74#issuecomment-211996229

[mcdermj]

I'm not saying it's not essential, and like I said, it's something that slipped through the cracks. And I'm also the guy that brought you all the command-line-ish tools that aren't linked with the GUI libraries so that you can have small ssh-only systems. I want the remotecontrold functionality to work because none of my Raspberry Pis have X-windows on them, and I don't want to put it there. Most of this stuff is working towards the goal of having a set of programs that are easier administrated on UNIX-like systems like Linux on the Pi.

The complaint isn't the functionality of "remotecontrold," it's the fact that it needs a new name because it's not a daemon.

I have the code written for a temporary fix that will at least build remotecontrold for you. As soon as it's passed my CI build server, it'll get a PR.

[johnhays]

maybe ircddbgwctl ?

On Tue, Apr 19, 2016 at 9:26 AM, Jeremy McDermond notifications@github.com wrote:

I'm not saying it's not essential, and like I said, it's something that slipped through the cracks. And I'm also the guy that brought you all the command-line-ish tools that aren't linked with the GUI libraries so that you can have small ssh-only systems. I want the remotecontrold functionality to work because none of my Raspberry Pis have X-windows on them, and I don't want to put it there. Most of this stuff is working towards the goal of having a set of programs that are easier administrated on UNIX-like systems like Linux on the Pi.

The complaint isn't the functionality of "remotecontrold," it's the fact that it needs a new name because it's not a daemon.

I have the code written for a temporary fix that will at least build remotecontrold for you. As soon as it's passed my CI build server, it'll get a PR.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/dl5di/OpenDV/pull/74#issuecomment-212004381

---

John D. Hays K7VE

PO Box 1223, Edmonds, WA 98020-1223 http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays

[phl0]

maybe ircddbgwctl ?

+1

[mcdermj]

I like that @johnhays. If we get a consensus, then I'll push another PR with the change.

[vk4tux]

i dont like it, rctl is much better

On 20/04/16 03:01, Jeremy McDermond wrote:

I like that John. If we get a consensus, then I'll push another PR with the change.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/dl5di/OpenDV/pull/74#issuecomment-212016835

[mcdermj]

On Apr 19, 2016, at 10:03 AM, vk4tux notifications@github.com wrote:

i dont like it, rctl is much better

My problem is that while rctl is nice, short and succinct, it’s pretty generic and likely to get stepped on by other packages down the road. Right now, I don’t see any files named rctl in packages.ubuntu.com or rpm.pbone.net, but that doesn’t mean there won’t be in the future, and we’re unlikely to be included in any standard distros any time soon.

Jeremy McDermond (NH6Z) Xenotropic Systems mcdermj@xenotropic.com

[mcdermj]

Some other, shorter possibilities are:

ircddbctl (I'm not sure we need the "gw" part)

or

ircddbc (This mirrors the ntpd/ntpdc style daemon/control pairs)

[phl0]

My problem is that while rctl is nice, short and succinct, it’s pretty generic and likely to get stepped on by other packages down the road. Right now, I don’t see any files named rctl in packages.ubuntu.com or rpm.pbone.net, but that doesn’t mean there won’t be in the future, and we’re unlikely to be included in any standard distros any time soon.

At least there is a binary on FreeBSD...

http://www.freebsd.org/cgi/man.cgi?query=rctl.conf&apropos=0&sektion=5&manpath=FreeBSD+11-current&format=html

I guess that would also be easily mixed up with something controlling the rc scripts of a Linux system.

[johnhays]

The reason I include gw is because that is what is being controlled. It is ircddbgateway, ircddb is the network infrastructure, ctl is kind of an emerging standard for these types of programs.

On Tue, Apr 19, 2016 at 10:13 AM, Florian (DF2ET) notifications@github.com wrote:

My problem is that while rctl is nice, short and succinct, it’s pretty generic and likely to get stepped on by other packages down the road. Right now, I don’t see any files named rctl in packages.ubuntu.com or rpm.pbone.net, but that doesn’t mean there won’t be in the future, and we’re unlikely to be included in any standard distros any time soon.

At least there is a binary on FreeBSD...

http://www.freebsd.org/cgi/man.cgi?query=rctl.conf&apropos=0&sektion=5&manpath=FreeBSD+11-current&format=html

I guess that would also be easily mixed up with something controlling the rc scripts of a Linux system.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/dl5di/OpenDV/pull/74#issuecomment-212022819

---

John D. Hays K7VE

PO Box 1223, Edmonds, WA 98020-1223 http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays

[vk4tux]

Joe, ok , yes i modified source code for Fran, and re-compiled on his.

That's unusual re using XLX, but ok on that.

Did you ask on the ircddbgateway group, so they can look at the code at github etc ?

Jeremy NH6Z, is doing most of it now. A polling parameter change may help Jeremy ?.

@ Jeremy,.. is there a wx2.8 master branch still in place to allow source update & older system compatibility ?

regards

Adrian

On 15/05/16 17:01, Joe wrote:

Our host files point to XLX026 to the correct IP. We us XLX to distinguish it as a XLX Multiprotocol reflector. We have the same issue, poll inactivity, when linking to DCS reflectors and any of the XRF reflectors. Fran W1FJM reported a similar issue last November. H said you helped him resolve the issue.

[F4FXL]

It seems like we missed to create a wx2.8 branch... Not good .... Anyway, a lots of improvements/bug fixes have been done since we moved away from 2.x sysops should consider whole system upgrades IMHO ....

[vk4tux]

I think it good to keep some compatibility, while those systems exist. I have many calls for help regarding relinking occurring due to polling issues, in 60 second cycles.

M: 2016-05-15 03:25:28: DExtra link to XRF026 C has failed (poll inactivity) M: 2016-05-15 03:25:28: DExtra link to XRF026 C has failed, relinking

On 15/05/16 22:44, Geoffrey Merck wrote:

It seems like we missed to create a wx2.8 branch... Not good .... Anyway, a lots of improvements/bug fixes have been done since we moved away from 2.x sysops should consider whole system upgrades IMHO ....

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/dl5di/OpenDV/pull/74#issuecomment-219283760

[mcdermj]

Okay. First, though, this isn't a general purpose thread for issues. If you have an issue, file an issue report in github and let me know about it. That allows me to track and remember things much better.

If we know what commit we moved off on to wx2.8, we can certainly make a branch off of there so that someone could cherry-pick commits from master. I, personally, am not going to spend a lot of time worrying about backports. I'm happy to assist other with the backporting bug fixes, but it may not be all that easy as we diverge. I'm doing some restructuring with the daemons that is affecting the threading and such that may not be easy to apply to older code.

Yes, @vk4tux, it's good to keep bug fixes and compatibility for a while, but at some point it has to stop. Otherwise you end up spending tons of time supporting ancient software. Microsoft doesn't support XP anymore, much as hams would like them to. Ubuntu doesn't even support their point releases past a year.

That being said, I'm not sure I completely understand the issue here. You think there's a bug in the code that's causing the polls to fail? What have you done in the past to remedy this?