Re: [Xastir-dev] Switching string length discussion to here

[km5vy Tom Russo]

On Sun, Dec 19, 2021 at 02:37:24PM -0800, we recorded a bogon-computron 
collision of the  flavor, containing:
> Ah, should have read everything more thoroughly... So by adding
> another library to Linux we might be able to use something better.

I disagree:  by adding another library, we're adding dependencies that could
just as easily be solved by using strncat correctly without any depedencies.

The operative comment is:  

> > >   strlcpy() and strlcat() are not standard, neither ISO C nor POSIX. So,
> > >   their use in portable programs is impossible.


The fact that one can expect it to work in SOME places just fine and on linux
with extra libraries doesn't make it portable.

Further on in that discussion are descriptions of multiple packages that
provide their own implementation of strlcat (just as we provide xastir_snprintf
to provide the non-standard snprintf function), all different, just to 
assure portability.

That's a mess, and with as little developer energy as we have I do not 
advocate adding an additional maintenance headache (either by tracking down
dependencies or providing our own implementation) if it can be avoided with
a little extra typing.

> On Sun, Dec 19, 2021 at 2:36 PM Curt Mills  wrote:
> >
> > Nope. I remember considering those before after a bunch of research. I
> > think they're on some BSD-derived systems but they're not on Linux.
> >
> > On Sun, Dec 19, 2021 at 2:33 PM Tom Russo  wrote:
> > >
> > > On Sun, Dec 19, 2021 at 03:27:07PM -0700, we recorded a bogon-computron 
> > > collision of the  flavor, containing:
> > > > On Sun, Dec 19, 2021 at 03:25:28PM -0700, we recorded a bogon-computron 
> > > > collision of the  flavor, containing:
> > > > > On Sun, Dec 19, 2021 at 03:12:50PM -0600, we recorded a 
> > > > > bogon-computron collision of the  flavor, 
> > > > > containing:
> > > > > > There is also strlcat.
> > > > >
> > > > > Are these in the C standard, snprintf?
> > > >
> > > > "unlike snprintf"
> > >
> > > It appears that they are not standard in either ISO or POSIX standards.
> > >
> > > From 
> > > https://stackoverflow.com/questions/2114896/why-are-strlcpy-and-strlcat-considered-insecure
> > >
> > >   strlcpy() and strlcat() are not standard, neither ISO C nor POSIX. So,
> > >   their use in portable programs is impossible. In fact, strlcat() has
> > >   two different variants: the Solaris implementation is different from
> > >   the others for edge cases involving length 0. This makes it even less 
> > > useful
> > >   than otherwise.
> > >
> > > From the same discussion:
> > >
> > >   This API has been adopted by most modern operating systems and many
> > >   standalone software packages, including OpenBSD (where it originated),
> > >   Sun Solaris, FreeBSD, NetBSD, the Linux kernel, rsync and the GNOME 
> > > project.
> > >   The notable exception is the GNU standard C library, glibc [12], whose
> > >   maintainer steadfastly refuses to include these improved APIs, labelling
> > >   them "horribly inefficient BSD crap" [4], despite prior evidence that 
> > > they
> > >   are faster is most cases than the APIs they replace [13].
> > >
> > >   That is why they are not available in glibc, but it is not true that 
> > > they
> > >   are not available on Linux. They are available on Linux in libbsd:
> > >
> > > https://libbsd.freedesktop.org/
> > >
> > >
> > > --
> > > Tom RussoKM5VY
> > > Tijeras, NM
> > >
> > >  echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] 
> > > [n-z][a-m]
> > >
> > > ___
> > > Xastir-dev mailing list
> > > Xastir-dev@lists.xastir.org
> > > http://xastir.org/mailman/listinfo/xastir-dev
> >
> >
> >
> > --
> > Curt, WE7Uhttp://xastir.orghttp://www.sarguydigital.com
> 
> 
> 
> -- 
> Curt, WE7Uhttp://xastir.orghttp://www.sarguydigital.com

-- 
Tom RussoKM5VY
Tijeras, NM  

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]

___
Xastir-dev mailing list
Xastir-dev@lists.xastir.org
http://xastir.org/mailman/listinfo/xastir-dev

Re: [Xastir-dev] Maybe it's time for a 2.1.8 release?

[km5vy Tom Russo]

I have created a pull request on github with the changes needed to documentation
to implement this simplified release process.

When you and Curt have reviewed it, please merge it and I'll move with actually
doing the point release.

Doing the point release this way is very little more than changing a version
number and tagging the repo, so it's very light weight.

I changed INSTALL to say that everyone needs to bootstrap.

I am NOT going to go through the uncountable infinity of distro-specific
install guides on the wiki to fix them all up, as they all have the same
information cut and pasted over and over again.  Maybe someone else can
take care of doing some of that?


On Thu, Oct 14, 2021 at 09:50:59AM -0500, we recorded a bogon-computron 
collision of the  flavor, containing:
> Hello.
> 
> I agree with a point release and simplifying the release process.
> 
> 73
> - Jason
> 
> On Thu, Oct 14, 2021 at 9:47 AM Tom Russo  wrote:
> 
> > Gang:
> >
> > It's been over a year since our last Xastir release, and there has been
> > very
> > little development since then -- mostly minor tweaks to the build system
> > necessary to keep Xastir building as compilers, libraries, and
> > autoconf/automake keep dropping support for old things we used to do.
> >
> > We just got a pull request to fix a dumb autoconf issue that broke Xastir
> > builds on gentoo when using the very latest autoconf/automake.  It was
> > utterly trivial to fix.
> >
> > Most of these things are hacks that are already being addressed by package
> > maintainers using local patches, but we've addressed them in the base
> > package
> > so it would simplify their processes if we just pushed out a new point
> > release.
> > The gcc10 fixes we did a while back were of this ilk, and our pushing out
> > the 2.1.6 release helped get those changes to everyone instead of every OS
> > having to patch them up themselves.
> >
> > It is also the case that some distros and non-linux operating systems don't
> > update Xastir except when we do official releases, so pushing out a new
> > release
> > would help those OSen stay up to date.
> >
> > We've had a "2.2.0" project on the github page for a really long time and
> > there has been no motion on the 6 "to do" or "in progress" items needed to
> > call
> > that release done.  So I do not propose we call our next release 2.2.0, but
> > just 2.1.8, capturing the state as it is right now.
> >
> > Does anyone have any objections to making such a release in short order?
> >
> > Also:  our current "release process" is a little antiquated and is designed
> > to minimize the "surprise" when transitioning from our old SourceForge/CVS
> > release process to our new github.  The big one is that we do this weird
> > thing so that the tarballs created for our releases are "pre-bootstrapped"
> > so they're ready to go upon being downloaded instead of requiring the user
> > to run bootstrap.
> >
> > It's years now since we moved to git, and maintaining clunky release
> > processes
> > to accomodate those who only know CVS seems long past its sell-by date.
> >
> > There are downsides to this clunky release approach, almost all on my end
> > ---
> > it makes it much harder to create a release, because we have to create a
> > branch, do funky things on that branch to make bootstrap artifacts no
> > longer
> > ignored, commit those things, and then tag the end of the branch as the
> > release (and the tag can then be used at github to create the tarballs for
> > the
> > release automatically).
> >
> > Doing this means our "release branch" is a dead end and is never merged
> > back
> > onto master, and our release tag is not reachable in git history from
> > master,
> > meaning "git describe" output is almost useless.
> >
> > I propose we discontinue this handholding approach that serves only to let
> > downloaders skip exactly one step of the build process (the bootstrap,
> > which
> > creates configure and all the Makefile.in files), and go to one where the
> > tarballs are literally just a snapshot out of the git repo, and built
> > exactly
> > the same way (bootstrap, configure, make).
> >
> > Changing this means simplifying the build instructions to remove "if you're
> > downloading a tarball, do this, if you're cloning git, do that"
> > conditionals
> > and replace them with "do that".  But in the long run it will make the
> > process simpler and might make deciding to make point releases less
> > weighty.
> >
> > It also means changing the document that describes how to do the release in
> > excruciating detail (README.developers.md).  I propose removing the
> > instructions for how to do "development snapshots", too, since this hasn't
> > been done in many years and is clearly no longer needed.
> >
> > If we agree that doing a point release makes sense, I also call on all to
> > take a quick look and see if there are any things that need immediate
> > update
> > (for example, get-NWSdata is frequently behind the times 

Re: [Xastir-dev] [Xastir] Fwd: Bug#957970: xastir: ftbfs with GCC-10

[km5vy Tom Russo]

On Fri, Apr 17, 2020 at 08:54:30AM -0700, we recorded a bogon-computron 
collision of the  flavor, containing:
> Sure.

I can do that tonight if we're all in accord.  It's a fairly lightweight
process anymore to push out a release on github.

> On Fri, Apr 17, 2020 at 8:33 AM Tom Russo  wrote:
> >
> > On Fri, Apr 17, 2020 at 08:31:34AM -0700, we recorded a bogon-computron 
> > collision of the  flavor, containing:
> > >
> > > Ah.. ok.  Seems like a good first step would be to tag a new Xastir 
> > > release
> > > and tell the Debian maintainer to start with that.
> >
> > Yes, a point release seems in order.
> >
> > > On 04/17/2020 08:27 AM, Tom Russo wrote:
> > > > On Fri, Apr 17, 2020 at 07:14:19AM -0700, we recorded a bogon-computron 
> > > > collision of the  flavor, containing:
> > > > > Just saw this notification on the Xastir list. Seems like GCC-10 is 
> > > > > going to
> > > > > require a lot of different Linux programs to do some clean ups.
> > > > It apppears they are trying to build release code, not the git head.  
> > > > Some
> > > > of this stuff is already fixed as a result of a github issue that was 
> > > > opened
> > > > back in Feb:  https://github.com/Xastir/Xastir/issues/164.
> > > >
> > > > See commit 9d0d1d9, which fixed those multiply defined variables (which
> > > > are all the result of "-fno-common" being made the default in gcc10.
> > > >
> > > > The snprintf stuff is a perenial issue, and we've been picking away at 
> > > > it.
> > > > There's a lot of messy use of snprintf.  But I believe this is just a 
> > > > warning.
> > > >
> > > > >  Forwarded Message 
> > > > > Subject:  Bug#957970: xastir: ftbfs with GCC-10
> > > > > Resent-Date:  Fri, 17 Apr 2020 11:38:07 +
> > > > > Resent-From:  Matthias Klose 
> > > > > Resent-To:Debian Hamradio Maintainers 
> > > > > 
> > > > > Date: Fri, 17 Apr 2020 11:13:49 +
> > > > > From: Matthias Klose 
> > > > > Reply-To: Matthias Klose ,
> > > > > 957970-mainto...@bugs.debian.org
> > > > > To:   mainto...@bugs.debian.org
> > > > >
> > > > >
> > > > >
> > > > > Package: src:xastir
> > > > > Version: 2.1.4+git20191127.bb66a77-3
> > > > > Severity: normal
> > > > > Tags: sid bullseye
> > > > > User: debian-...@lists.debian.org
> > > > > Usertags: ftbfs-gcc-10
> > > > >
> > > > > Please keep this issue open in the bug tracker for the package it
> > > > > was filed for.  If a fix in another package is required, please
> > > > > file a bug for the other package (or clone), and add a block in this
> > > > > package. Please keep the issue open until the package can be built in
> > > > > a follow-up test rebuild.
> > > > >
> > > > > The package fails to build in a test rebuild on at least amd64 with
> > > > > gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The
> > > > > severity of this report will be raised before the bullseye release,
> > > > > so nothing has to be done for the buster release.
> > > > >
> > > > > The full build log can be found at:
> > > > > http://people.debian.org/~doko/logs/gcc10-20200225/xastir_2.1.4+git20191127.bb66a77-3_unstable_gcc10.log
> > > > > The last lines of the build log are at the end of this report.
> > > > >
> > > > > To build with GCC 10, either set CC=gcc-10 CXX=g++-10 explicitly,
> > > > > or install the gcc, g++, gfortran, ... packages from experimental.
> > > > >
> > > > >apt-get -t=experimental install g++
> > > > >
> > > > > Common build failures are new warnings resulting in build failures 
> > > > > with
> > > > > -Werror turned on, or new/dropped symbols in Debian symbols files.
> > > > > For other C/C++ related build failures see the porting guide at
> > > > > http://gcc.gnu.org/gcc-10/porting_to.html
> > > > >
> > > > > [...]
> > > > >   3379 |   "%s",
> > > > >|^~
> > > > > In file included from /usr/include/stdio.h:867,
> > > > >   from snprintf.h:27,
> > > > >   from objects.c:29:
> > > > > /usr/include/x86_64-linux-gnu/bits/stdio2.h:67:10: note: 
> > > > > ???__builtin_snprintf??? output between 1 and 1993 bytes into a 
> > > > > destination of size 40
> > > > > 67 |   return __builtin___snprintf_chk (__s, __n, 
> > > > > __USE_FORTIFY_LEVEL - 1,
> > > > >|  
> > > > > ^~~~
> > > > > 68 |__bos (__s), __fmt, __va_arg_pack ());
> > > > >|~
> > > > > gcc -DHAVE_CONFIG_H -I. -I..   -I/usr/include/GraphicsMagick 
> > > > > -I/usr/local/include -I/usr/include/geotiff -Wdate-time 
> > > > > -D_FORTIFY_SOURCE=2 -DXASTIR_DATA_BASE=\"/usr/share/xastir\"  
> > > > > -fopenmp -g -O2 
> > > > > -fdebug-prefix-map=/build/graphicsmagick-wInnp7/graphicsmagick-1.4+really1.3.35=.
> > > > >  -fstack-protector-strong -Wformat -Werror=format-security -Wall 
> > > > > -pthread -fdebug-prefix-map=/<>=. -pipe -Wpointer-arith 
> 

Re: [Xastir-dev] [Xastir] ATTENTION: Preparing for next release: Please thrash on the code

[km5vy Tom Russo]

On Fri, May 31, 2019 at 04:05:19PM -0500, we recorded a bogon-computron 
collision of the  flavor, containing:
> Tom
> 
> Thanks for the expansion. Let me wrap my head around the current work
> environment, and I'll see if I can get some coding time at home at night...
> 
> As for the "less accurate Molodensky" transform... I recall writing those
> in F77 and F90 from scratch a long time ago. I went with Molodensky because
> it was simpler, and "good enough" for most of the geodesy I was doing at
> the time! I don't see how it's too bad for ham radio apps. A couple of cm
> error, even a meter or so, won't make much difference in most of what we do!

It isn't "too bad."  It's more likely "plenty good enough for APRS work."  
But it is indeed less accurate than using NADCON datum shift grids as PROJ.4
does.  At the moment, Xastir only knows about WGS84 lat/lon (native
APRS datum and coordinate system), WGS84/NAD83 UTM, and NAD27 UTM in normal 
operation.  Where it starts to be a problem is when folks try to use our 
geotiff code for geotiffs created by agencies other than USGS (even in North
America --- for example, FAA sectional charts in GeoTIFF format, which are
often in Lambert Conformal Conic).

Using gdal's raster warping capability (which relies on Proj) to handle
rasters in other datums and coordinate systems would be a Good Thing, but
at the moment it can only be done as a preprocessing step before telling
Xastir about the images (using GDAL command line tools).

> On Fri, May 31, 2019 at 2:43 PM km5vy Tom Russo  wrote:
> 
> > On Fri, May 31, 2019 at 02:29:36PM -0500, we recorded a bogon-computron
> > collision of the  flavor, containing:
> > > So, a question. I've been lurking, but this working thing has gotten in
> > the
> > > way of my ham and Xastir time.
> > >
> > > With gdal and proj support deprecated,
> >
> > Just a quick correction:  these are not "deprecated" (i.e. unsupported,
> > with
> > users encouraged not to use them), they're removed.
> >
> > GDAL support in Xastir was almost non-existent.  A few OGR vector data
> > types were supported with hard-coded rendering rules, but the full
> > flexibility
> > of OGR vector types with the sort of user-defined rendering control that
> > we
> > have for shapefiles was never implemented.
> >
> > Support for GDAL raster types was basically never done.
> >
> > So what we've actually removed was half-written, mostly unused code that
> > did nobody any good.
> >
> > PROJ support in Xastir was never real.  We only needed proj because
> > libgeotiff
> > needed it, and since we didn't get rid of libgeotiff support, we still do
> > require linking of proj libraries.  The only direct use in Xastir of proj
> > libraries was in a couple of functions that existed solely because
> > libgeotiff
> > and gdal provided identical functions, and therefore frequently caused
> > linking
> > or other runtime failure.  So a single function of libgeotiff was cut and
> > pasted into Xastir source code and renamed to eliminate the conflict, and
> > that
> > one function used proj directly.  Since we no longer link in gdal, the
> > conflict is no longer an issue so that cut/paste hack and direct use of
> > proj
> > is gone.
> >
> > Datum translation in Xastir is done via the less accurate Molodensky
> > transformations that are coded in datum.c and datum.h.  We have never used
> > proj for datum or coordinate system transformation directly.
> >
> > > any thought of incorporating some of
> > > the Python (3) approaches to proj and gdal, and incorporating cartopy? I
> > > realize the code is not python, and it could incorporate problems by
> > trying
> > > to shoe-horn it in. This is a request for information...
> >
> > > I'm thinking, though, that this could be a good way to snag WMS/WFS data,
> > > create static maps for future use, etc. Things that might be offloaded.
> >
> > Honestly, if someone wanted to expend the effort to incorporate gdal/ogr
> > and
> > proj usage into Xastir in a good, useful way, I would welcome it ---
> > done right, gdal and ogr can bring a lot of good support into Xastir.  But
> > I am
> > not sure who will do that, and I am sure that the old code wasn't where we
> > needed to start to get that done.
> >
> > If you want to implement such a thing and make a pull request, have at it.
> >
> > > Thanks. I'll go back in my cave now.
> > >
> > > AND, Congratulations on the new release!
> > > gerry
>

Re: [Xastir-dev] [Xastir] ATTENTION: Preparing for next release: Please thrash on the code

[km5vy Tom Russo]

On Fri, May 31, 2019 at 02:29:36PM -0500, we recorded a bogon-computron 
collision of the  flavor, containing:
> So, a question. I've been lurking, but this working thing has gotten in the
> way of my ham and Xastir time.
> 
> With gdal and proj support deprecated, 

Just a quick correction:  these are not "deprecated" (i.e. unsupported, with
users encouraged not to use them), they're removed.

GDAL support in Xastir was almost non-existent.  A few OGR vector data
types were supported with hard-coded rendering rules, but the full flexibility
of OGR vector types with the sort of user-defined rendering control that we 
have for shapefiles was never implemented.

Support for GDAL raster types was basically never done.  

So what we've actually removed was half-written, mostly unused code that 
did nobody any good.

PROJ support in Xastir was never real.  We only needed proj because libgeotiff
needed it, and since we didn't get rid of libgeotiff support, we still do 
require linking of proj libraries.  The only direct use in Xastir of proj 
libraries was in a couple of functions that existed solely because libgeotiff 
and gdal provided identical functions, and therefore frequently caused linking 
or other runtime failure.  So a single function of libgeotiff was cut and 
pasted into Xastir source code and renamed to eliminate the conflict, and that
one function used proj directly.  Since we no longer link in gdal, the 
conflict is no longer an issue so that cut/paste hack and direct use of proj
is gone.

Datum translation in Xastir is done via the less accurate Molodensky 
transformations that are coded in datum.c and datum.h.  We have never used
proj for datum or coordinate system transformation directly. 

> any thought of incorporating some of
> the Python (3) approaches to proj and gdal, and incorporating cartopy? I
> realize the code is not python, and it could incorporate problems by trying
> to shoe-horn it in. This is a request for information...

> I'm thinking, though, that this could be a good way to snag WMS/WFS data,
> create static maps for future use, etc. Things that might be offloaded.

Honestly, if someone wanted to expend the effort to incorporate gdal/ogr and
proj usage into Xastir in a good, useful way, I would welcome it ---
done right, gdal and ogr can bring a lot of good support into Xastir.  But I am 
not sure who will do that, and I am sure that the old code wasn't where we
needed to start to get that done.

If you want to implement such a thing and make a pull request, have at it.

> Thanks. I'll go back in my cave now.
> 
> AND, Congratulations on the new release!
> gerry
> 
> On Thu, May 30, 2019 at 12:38 PM Curt Mills  wrote:
> 
> > Rgr. Will post announcement today then.
> >
> > On Thu, May 30, 2019 at 10:33 AM km5vy Tom Russo 
> > wrote:
> >
> > > On Thu, May 30, 2019 at 11:12:03AM -0600, we recorded a bogon-computron
> > > collision of the  flavor, containing:
> > > > On Mon, May 27, 2019 at 11:52:53AM -0700, we recorded a bogon-computron
> > > collision of the  flavor, containing:
> > > > > Fine by me. I can do all the announcements.
> > > >
> > > > It is likely that I'll go ahead and walk through the git steps of doing
> > > > the release tonight instead of tomorrow.
> > >
> > > Or now.
> > >
> > > It is done.
> > >
> > > https://github.com/Xastir/Xastir/releases/tag/Release-2.1.2
> > >
> > > > My "friday off" turns out to be a
> > > > day of household chores.
> > > >
> > > > Actually stepping through the release process is only a few minutes,
> > and
> > > the
> > > > longest steps are those that verify that the easy steps were done
> > > correctly.
> > > >
> > > > I'll shoot a message to the lists when it's done, and then the proper
> > > announcing
> > > > can happen.
> > > >
> > > > > On Mon, May 27, 2019, 10:07 AM Tom Russo  wrote:
> > > > >
> > > > > > On Thu, May 23, 2019 at 01:05:53PM -0600, we recorded a
> > > bogon-computron
> > > > > > collision of the  flavor, containing:
> > > > > > > On Thu, May 23, 2019 at 07:15:52AM -0700, we recorded a
> > > bogon-computron
> > > > > > collision of the  flavor, containing:
> > > > > > > > Anyone else have any reports, good or bad?
> > > > > > > >
> > > > > > > > FWIW: For the types of things I do the latest code has been
> > > stable for
> > > > > > me.
> > > > > > > >
> > > > > >

Re: [Xastir-dev] [Xastir] ATTENTION: Preparing for next release: Please thrash on the code

[km5vy Tom Russo]

On Mon, May 27, 2019 at 11:52:53AM -0700, we recorded a bogon-computron 
collision of the  flavor, containing:
> Fine by me. I can do all the announcements.

It is likely that I'll go ahead and walk through the git steps of doing
the release tonight instead of tomorrow.  My "friday off" turns out to be a 
day of household chores.

Actually stepping through the release process is only a few minutes, and the
longest steps are those that verify that the easy steps were done correctly.

I'll shoot a message to the lists when it's done, and then the proper announcing
can happen.

> On Mon, May 27, 2019, 10:07 AM Tom Russo  wrote:
> 
> > On Thu, May 23, 2019 at 01:05:53PM -0600, we recorded a bogon-computron
> > collision of the  flavor, containing:
> > > On Thu, May 23, 2019 at 07:15:52AM -0700, we recorded a bogon-computron
> > collision of the  flavor, containing:
> > > > Anyone else have any reports, good or bad?
> > > >
> > > > FWIW: For the types of things I do the latest code has been stable for
> > me.
> > > >
> > > > We're getting close to a release and Tom will most likely be the one
> > doing
> > > > it. No target date has been mentioned. If we run into any nasty bugs
> > that
> > > > might delay.
> > >
> > > Let's set a date right now.  I can set aside the time to do the release
> > > on only a few days in the upcoming weeks (it doesn't take long, but it's
> > > a process that takes some attention, and is documented in
> > README.developers.md).
> > >
> > > The days I could do it are:
> > >   Friday, 31 May
> > >   Friday, 14 June
> > >   Sometime on the weekend of 21-23 June.
> >
> > Can we pick one?  I propose we just rip off the band-aid and do it
> > Friday 31 May.  I can take care of the git work if you'll handle doing all
> > the various announcements.
> >
> > > I think that we are already at a point where there has been sufficient
> > time
> > > to shake out the code on master, and we could release today if we wanted
> > > to.  Next friday is the earliest I have the opportunity to spend on it.
> > >
> > > If someone else wanted to try out the release process, it's all
> > documented
> > > in gory detail in README.developers.md, and if followed precisely would
> > > produce a new release that would be ready (down to file names of
> > tarballs)
> > > to slot into the package creation processes various distros use, just by
> > > changing the version number.  Or pick a date and I'll do it then.
> > >
> > > > On Fri, May 17, 2019 at 6:16 PM Lee Bengston 
> > wrote:
> > > >
> > > > > I've played with it some and and have not found any issues. I put
> > together
> > > > > a BPQ packet node in January, and I haven't fully back-filled what I
> > had
> > > > > "stolen" from aprs, so testing capability is fairly limited.  From
> > what I
> > > > > can tell, though, it's nice and stable.
> > > > >
> > > > > I do have a few questions about the source ( yeah, always one in the
> > crowd
> > > > > :-) )
> > > > >
> > > > > - In dlm.c noticed references to "curl-multi" and evidently the
> > capability
> > > > > to leverage parallel downloading of map tiles as supported by
> > libcurl. Is
> > > > > whether or not that is supported in our platform based on what
> > version of
> > > > > curl is installed?
> > > > >
> > > > > - now that dlm.c handles downloading tiles, is there anything left in
> > > > > tile_mgmnt.c that is still needed or could tile_mgmnt.h and
> > tile_mgmnt.c be
> > > > > removed?  It seems at a minimum the "getOneTile" portion of
> > tile_mgmnt.c is
> > > > > no longer needed.
> > > > >
> > > > > Looks like you guys are doing a lot of cleanup in this release, so
> > brought
> > > > > that up just in case there's some stuff there that could be
> > streamlined a
> > > > > bit.
> > > > >
> > > > > Fyi, my Odroid XU4 (arm based) beats the pants off my Intel Celeron
> > based
> > > > > laptop in terms of map download speed.  Both are on Ubuntu 18.04
> > with the
> > > > > MATE desktop. Am wondering if the fact that the XU4 has an octa-core
> > cpu
> > > > > makes a difference with respect to curl-multi.
> > > > >
> > > > > The cleaner compiling is very noticeable, and the earlier note about
> > newer
> > > > > compilers spitting out more warnings matches what I saw.  Compiling
> > is
> > > > > cleaner in Debian Stretch and Ubuntu 16.04 than it is in Ubuntu
> > 18.04, but
> > > > > it still builds fine.  (And even in Ubuntu 18.04 the new code still
> > > > > compiles a lot cleaner that the older code did)
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Lee
> > > > > K5DAT
> > > > >
> > > > >
> > > > > On Thu, May 9, 2019 at 9:57 AM Curt Mills 
> > wrote:
> > > > >
> > > > > > We're planning to do a release within a few weeks. It might be as
> > few as
> > > > > 2
> > > > > > weeks.
> > > > > >
> > > > > > Please check out / compile / thrash on the latest Github Xastir
> > code.
> > > > > Find
> > > > > > anything that broke with our latest code fixes. Exercise all types
> > of
> > > > > > 

Re: [Xastir-dev] Editor header in source files

[km5vy Tom Russo]

On Tue, Apr 30, 2019 at 12:41:50PM -0600, we recorded a bogon-computron 
collision of the  flavor, containing:
> On Tue, Apr 30, 2019 at 11:14:54AM -0700, we recorded a bogon-computron 
> collision of the  flavor, containing:
> > What do you think of this idea instead:  https://editorconfig.org/
> > It requires a plug-in for Emacs and VIM, but we could add that to the
> > coding standards.
> 
> I'm not particularly keen on having it depend on a plugin at all.
> 
> The suggestion of a per-directory emacs file is a better one.  The syntax
> is much ickier than it is for the file-specific setting, but making it
> global for the entire project directory (and ignored by everything but emacs) 
> is a benefit.

There is now a .dir-locals.el file in the top level directory, and the per-file
settings lines are gone.  emacs users will now have project indentation
standards enforced by emacs automatically.

I'll leave it to others to deal with the Vim settings.

> > It would avoid having to have a special config in each of our source files.
> > 
> > On Tue, Apr 30, 2019 at 11:00 AM Tom Russo  wrote:
> > 
> > > On Tue, Apr 30, 2019 at 10:23:20AM -0700, we recorded a bogon-computron
> > > collision of the  flavor, containing:
> > > > Thanks. Looks like the equivalent in Vim is Modelines:
> > > >
> > > > https://vim.fandom.com/wiki/Modeline_magic
> > > >
> > > > But a lot of the major distributions turn off modelines by default.
> > > >
> > > > We should either have the Emacs and VIM Modelines in all the source
> > > files,
> > > > or none of them.
> > >
> > > Then I vote for all of them.  If we take out those Emacs local vars
> > > settings,
> > > I would have to change my Emacs defaults every time I open it to edit
> > > Xastir code.  Either that, or every time I edit Xastir code I would have
> > > to manually fix its incorrect (for project standards) indentation choices.
> > >
> > > I would still advocate leaving the variable settings in the file, to
> > > override personal defaults and enforce project defaults.
> > >
> > > > Our source guidelines specify 4-spaces per tab, no embedded tab
> > > characters.
> > > > As I edit various files I sometimes get a 4-char space tab, sometimes a
> > > > regular 8-char tab, and that is with Vim so I don't know why it is
> > > changing
> > > > from file to file 'cuz I don't see modelines in there for Vim. I might 
> > > > be
> > > > missing them.
> > >
> > > There are no Vim modelines as far as I can tell.  I couldn't guess why
> > > Vim would edit different files with different defaults.  Must be something
> > > about specifics of your vim settings, though.  Can't help you there, I'm
> > > not a vim user.
> > >
> > > > On Tue, Apr 30, 2019 at 9:52 AM Hal Mueller  wrote:
> > > >
> > > > > That???s for Emacs. You can specify major mode and per-file variables.
> > > > >
> > > > >
> > > > >
> > > https://www.gnu.org/software/emacs/manual/html_node/emacs/Choosing-Modes.html
> > > > >
> > > > >
> > > > >
> > > https://www.gnu.org/software/emacs/manual/html_node/emacs/Specifying-File-Variables.html#Specifying-File-Variables
> > > > >
> > > > > Hal
> > > > > N3YX
> > > > >
> > > > > > On Apr 30, 2019, at 9:20 AM, Jason KG4WSV  wrote:
> > > > > >
> > > > > > I haven't seen this before, but it does make my emacs behave
> > > differently
> > > > > > (the file had 2 space tabs, this made it do 4) and does nothing to
> > > vi.
> > > > > >
> > > > > > RHEL 7
> > > > > >
> > > > > > -j
> > > > > >
> > > > > >
> > > > > >
> > > > > >> On Tue, Apr 30, 2019 at 11:06 AM Curt Mills 
> > > > > wrote:
> > > > > >>
> > > > > >> I see this header in _some_ of our source files:
> > > > > >>
> > > > > >>/* -*- c-basic-offset: 4; indent-tabs-mode: nil -*-
> > > > > >>
> > > > > >> Is that for VI -and- Emacs, or just one of them? I use Vim.
> > > > > >>
> > > > > >> I've noticed while editing files in the last couple of weeks that 
> > > > > >> my
> > > > > tab is
> > > > > >> not 4 chars sometimes. I have to manually space to indent properly.
> > > > > >>
> > > > > >> I thought at one point we needed two headers in our files, one for
> > > Emacs
> > > > > >> and one for VI. I didn't scan all the files but I saw a bunch of
> > > files
> > > > > with
> > > > > >> no header and a bunch with the header above.
> > > > > >>
> > > > > >> --
> > > > > >> Curt, WE7Uhttp://we7u.wetnet.net
> > > > > >> http://www.sarguydigital.com
> > > > > >> ___
> > > > > >> Xastir-dev mailing list
> > > > > >> Xastir-dev@lists.xastir.org
> > > > > >> http://xastir.org/mailman/listinfo/xastir-dev
> > > > > >
> > > > > >
> > > > > > --
> > > > > > -Jason
> > > > > > kg4wsv
> > > > > > ___
> > > > > > Xastir-dev mailing list
> > > > > > Xastir-dev@lists.xastir.org
> > > > > > http://xastir.org/mailman/listinfo/xastir-dev
> > > > > ___
> > > > > Xastir-dev mailing list
> > > > > 

Re: [Xastir-dev] Editor header in source files

[km5vy Tom Russo]

On Tue, Apr 30, 2019 at 11:14:54AM -0700, we recorded a bogon-computron 
collision of the  flavor, containing:
> What do you think of this idea instead:  https://editorconfig.org/
> It requires a plug-in for Emacs and VIM, but we could add that to the
> coding standards.

I'm not particularly keen on having it depend on a plugin at all.

The suggestion of a per-directory emacs file is a better one.  The syntax
is much ickier than it is for the file-specific setting, but making it
global for the entire project directory (and ignored by everything but emacs) 
is a benefit.

> It would avoid having to have a special config in each of our source files.
> 
> On Tue, Apr 30, 2019 at 11:00 AM Tom Russo  wrote:
> 
> > On Tue, Apr 30, 2019 at 10:23:20AM -0700, we recorded a bogon-computron
> > collision of the  flavor, containing:
> > > Thanks. Looks like the equivalent in Vim is Modelines:
> > >
> > > https://vim.fandom.com/wiki/Modeline_magic
> > >
> > > But a lot of the major distributions turn off modelines by default.
> > >
> > > We should either have the Emacs and VIM Modelines in all the source
> > files,
> > > or none of them.
> >
> > Then I vote for all of them.  If we take out those Emacs local vars
> > settings,
> > I would have to change my Emacs defaults every time I open it to edit
> > Xastir code.  Either that, or every time I edit Xastir code I would have
> > to manually fix its incorrect (for project standards) indentation choices.
> >
> > I would still advocate leaving the variable settings in the file, to
> > override personal defaults and enforce project defaults.
> >
> > > Our source guidelines specify 4-spaces per tab, no embedded tab
> > characters.
> > > As I edit various files I sometimes get a 4-char space tab, sometimes a
> > > regular 8-char tab, and that is with Vim so I don't know why it is
> > changing
> > > from file to file 'cuz I don't see modelines in there for Vim. I might be
> > > missing them.
> >
> > There are no Vim modelines as far as I can tell.  I couldn't guess why
> > Vim would edit different files with different defaults.  Must be something
> > about specifics of your vim settings, though.  Can't help you there, I'm
> > not a vim user.
> >
> > > On Tue, Apr 30, 2019 at 9:52 AM Hal Mueller  wrote:
> > >
> > > > That???s for Emacs. You can specify major mode and per-file variables.
> > > >
> > > >
> > > >
> > https://www.gnu.org/software/emacs/manual/html_node/emacs/Choosing-Modes.html
> > > >
> > > >
> > > >
> > https://www.gnu.org/software/emacs/manual/html_node/emacs/Specifying-File-Variables.html#Specifying-File-Variables
> > > >
> > > > Hal
> > > > N3YX
> > > >
> > > > > On Apr 30, 2019, at 9:20 AM, Jason KG4WSV  wrote:
> > > > >
> > > > > I haven't seen this before, but it does make my emacs behave
> > differently
> > > > > (the file had 2 space tabs, this made it do 4) and does nothing to
> > vi.
> > > > >
> > > > > RHEL 7
> > > > >
> > > > > -j
> > > > >
> > > > >
> > > > >
> > > > >> On Tue, Apr 30, 2019 at 11:06 AM Curt Mills 
> > > > wrote:
> > > > >>
> > > > >> I see this header in _some_ of our source files:
> > > > >>
> > > > >>/* -*- c-basic-offset: 4; indent-tabs-mode: nil -*-
> > > > >>
> > > > >> Is that for VI -and- Emacs, or just one of them? I use Vim.
> > > > >>
> > > > >> I've noticed while editing files in the last couple of weeks that my
> > > > tab is
> > > > >> not 4 chars sometimes. I have to manually space to indent properly.
> > > > >>
> > > > >> I thought at one point we needed two headers in our files, one for
> > Emacs
> > > > >> and one for VI. I didn't scan all the files but I saw a bunch of
> > files
> > > > with
> > > > >> no header and a bunch with the header above.
> > > > >>
> > > > >> --
> > > > >> Curt, WE7Uhttp://we7u.wetnet.net
> > > > >> http://www.sarguydigital.com
> > > > >> ___
> > > > >> Xastir-dev mailing list
> > > > >> Xastir-dev@lists.xastir.org
> > > > >> http://xastir.org/mailman/listinfo/xastir-dev
> > > > >
> > > > >
> > > > > --
> > > > > -Jason
> > > > > kg4wsv
> > > > > ___
> > > > > Xastir-dev mailing list
> > > > > Xastir-dev@lists.xastir.org
> > > > > http://xastir.org/mailman/listinfo/xastir-dev
> > > > ___
> > > > Xastir-dev mailing list
> > > > Xastir-dev@lists.xastir.org
> > > > http://xastir.org/mailman/listinfo/xastir-dev
> > > >
> > >
> > >
> > > --
> > > Curt, WE7Uhttp://we7u.wetnet.net
> > http://www.sarguydigital.com
> > > ___
> > > Xastir-dev mailing list
> > > Xastir-dev@lists.xastir.org
> > > http://xastir.org/mailman/listinfo/xastir-dev
> >
> > --
> > Tom RussoKM5VY
> > Tijeras, NM
> >
> >  echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z]
> > [n-z][a-m]
> >
> > ___
> > Xastir-dev mailing list
> > Xastir-dev@lists.xastir.org
> > 

Re: [Xastir-dev] Editor header in source files

[km5vy Tom Russo]

Seconded.

I think that the people who established the current standard for Xastir
are long gone, and maintaining consistency with that style for the sake
of consistency has gone on long enough.

I personally hate *both* the four-space indentation *and* the 
"egyptian brace"/K style, and prefer the 2-space indentation and
the brace style you say you prefer (with the left brace lining up with
the line before it, and the right brace lining up with the left).


On Tue, Apr 30, 2019 at 10:40:20AM -0700, we recorded a bogon-computron 
collision of the  flavor, containing:
> On Tue, Apr 30, 2019 at 10:10 AM Tom Russo  wrote:
> 
> > Four character indents are the Xastir coding standard.
> >
> > http://xastir.org/index.php/HowTo:Developer_Guidelines_and_Notes
> >
> > I personally hate it, but that's what this project has always required.
> >
> 
> Right. I don't like it either. We're probably at a point now where we could
> vote that out. Should probably do that vote on the developer's list.
> 
> FWIW: Other than the Xastir project I like to do 2-char indentation
> (spaces, not tabs) and bracing like this:
> 
> if (true)
> {
>   blah blah;
> }
> 
> While Xastir uses:
> 
> if (true) {
>   blah blah;
> }
> 
> I'm less concerned about changing the bracing standard than I am the
> indentation, but perhaps we could vote on both.
> 
> -- 
> Curt, WE7Uhttp://we7u.wetnet.nethttp://www.sarguydigital.com

-- 
Tom RussoKM5VY
Tijeras, NM  

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]

___
Xastir-dev mailing list
Xastir-dev@lists.xastir.org
http://xastir.org/mailman/listinfo/xastir-dev

Re: [Xastir-dev] Travis-CI: gcc 8?

[km5vy Tom Russo]

On Tue, Apr 23, 2019 at 08:35:12PM -0700, we recorded a bogon-computron 
collision of the  flavor, containing:
> Your thinking on distributions to drop is sound. It's what I would want as
> well.
> 
> For the gcc-8 build should we add those two flags as well?

Perhaps, unless you really want to change how we force
string truncations.  Most of the cases where we're doing strncpy or snprintf
for this purpose makes it look like overkill to be using the string functions,
and in one case I looked at it was like we were using strncpy in a place where
a simple "memcpy" would have been more appropriate.  But there were so many
of these warnings that I decided just to shut them up with compiler options.
"Fixing" them seemed the lowest priority, since it was warning us that C might 
do exactly what we asked it to do, fully expecting it to do so.

Then again, the whole point of this exercise was to quiet down the build by
making sure we were not making any egregious mistakes, and we have indeed found
some real (if not catastrophic) errors during this process.  So I guess my 
answer is "I dunno."

> On Tue, Apr 23, 2019 at 8:29 PM Tom Russo  wrote:
> 
> > On Tue, Apr 23, 2019 at 09:56:56PM -0500, we recorded a bogon-computron
> > collision of the  flavor, containing:
> > > I can integrate it. Which build were you thinking of swapping out, or
> > would
> > > this be an addition?
> >
> > We should probably just drop the Ubuntu 14.04 build altogether.  Ubuntu
> > 14.04
> > is past its end of life (as of March 31st), so we shouldn't have to waste
> > resources supporting it.
> >
> > Having a 16.04 lite with ImageMagick, 16.04 full with GraphicsMagick
> > (with stock compiler) and 16.04 full with gcc8 is probably adequate for
> > Linux testing.  That gets us tested with at least one Linux distro that
> > isn't
> > past EOL, and one compiler that is at least close to the cutting edge that
> > will
> > appear in Linux distros that aren't stodgy.
> >
> > If Travis ever starts supporting Ubuntu 18.04, I'd advocate dropping all
> > but
> > one Ubuntu 16.04 build, then transitioning everything else to the newer
> > distro.
> >
> > I really do agree with Curt that it is worthwhile to add a gcc-8 build, if
> > either of you have the time to incorporate it.  I don't have that time.
> >
> > I am building with GCC 8 regularly now, and yes, there are "lots" of
> > warnings,
> > but most of them are warning us about using strncat, strncpy, snprintf,
> > and
> > other such restricted string operators *deliberately* to truncate strings
> > down to a length required by the APRS spec --- these strings *could* be
> > longer
> > than the spec, but we truncate down to what we're allowed in a packet.
> >
> > GCC 8 warns that these operations "could" truncate the string.  But that's
> > why we're using them.
> >
> > I have taken to disabling the two types of warnings that are the result of
> > our
> > deliberate use of these operators *specifically* to perform truncation, by
> > adding "-Wno-format-truncation -Wno-stringop-truncation" to my CFLAGS.
> >
> > It may be reasonable to use some other technique than these operators to
> > copy, say, a maximum of three characters out of a four character string
> > into a
> > three character array, but I felt that this warning was OK to ignore for
> > now,
> > since it's warning us that the operator might do exactly what we wanted it
> > to.
> >
> > > On Tue, Apr 23, 2019 at 9:24 PM Curt Mills  wrote:
> > >
> > > > I have it building with gcc-8 on Xenial in my topic branch. Xenial is
> > > > Ubuntu-16.04. To get it to work I commented out the other builds and
> > just
> > > > build with the new one until I could make it work properly. Now I don't
> > > > know how to integrate what I've done with the earlier 4-build
> > .travis.yml
> > > > file we have on "master". Want to do the integration? If so I'll send
> > it
> > > > direct to you. BTW: It's showing LOTS of warnings! For the rest of you
> > out
> > > > there: That's actually what we want.
> > > >
> > > > On Tue, Apr 23, 2019 at 6:47 PM Jason Godfrey 
> > wrote:
> > > >
> > > > > Maybe swap the Ubuntu 14.04 max build to use gcc 8 if that is a valid
> > > > > combination? The travis-ci documentation has the comment "If you are
> > on
> > > > an
> > > > > open-source plan, please remember that Travis CI provides this
> > service
> > > > free
> > > > > of charge to the community. So please only specify the matrix you
> > > > *actually
> > > > > need*."
> > > > >
> > > > > On Tue, Apr 23, 2019 at 7:39 PM Curt Mills 
> > wrote:
> > > > >
> > > > > > We have Xastir building fairly cleanly on Travis-CI with three test
> > > > > cases:
> > > > > >
> > > > > > Ubuntu-14.04 max build
> > > > > > Ubuntu-14.04 min build
> > > > > > Ubuntu-16.04 max build
> > > > > >
> > > > > > Maybe what I should have said is that there aren't any Xastir code
> > > > > > errors/warnings being shown on those three, but a few warnings
> > appear
> > > > due
> > > > > > to 

Re: [Xastir-dev] Git question

[km5vy Tom Russo]

On Mon, Apr 22, 2019 at 09:37:09AM -0700, we recorded a bogon-computron 
collision of the  flavor, containing:
> $ git config -l
> push.default=simple
> user.name=Curt Mills, WE7U
> color.ui=auto
> core.whitespace=trailing-space,tab-in-indent,space-before-tab
> core.autocrlf=input
> branch.autosetuprebase=always
> branch.autosetupmerge=always
> merge.tool=tkdiff
> diff.tool=tkdiff
> difftool.prompt=false
> mergetool.prompt=false
> 
> I'm sure I put that in there 'cuz of one or another Git book I was reading
> early on. Good? Remove?

Good.  Leave it.

Just know what it does.

If you had done this same fork divergence and then just pulled without it,
instead of rebasing your master branch onto upstream, it'd have *merged*
upstream's changes into your master, and made a much more convoluted 
history.  Which you'd then want to discard anyway, since your commits
were mooted in upstream.

> On Mon, Apr 22, 2019 at 9:33 AM km5vy Tom Russo  wrote:
> 
> > On Mon, Apr 22, 2019 at 09:28:14AM -0700, we recorded a bogon-computron
> > collision of the  flavor, containing:
> > > However I didn't rebase. I only did "git pull upstream master". I shy
> > away
> > > from any rebasing now.
> >
> > OK, but you might have autorebase set in your git config file.   If
> > ~/.gitconfig has:
> >
> > [branch]
> >autosetuprebase = always
> >
> > then "git pull upstream master" did a rebase, even without your asking.
> >
> > If you had not had this, then the behavior would have been different, and
> > worse --- you'd have gotten an ugly merge commit.
> >
> > You should not be afraid of rebase.  You just need to do it carefully.
> >
> > > On Mon, Apr 22, 2019 at 9:19 AM Tom Russo  wrote:
> > >
> > > > Ok, I see what you have done.
> > > >
> > > > This is what I have (my "origin" remote is what you have as upstream:
> > > >
> > > > * 34f7373b (HEAD -> master, origin/master, origin/HEAD) Add dependent
> > > > package
> > > > * e7f47a88 Rename OSX build
> > > > * 1247152f Fix overlooked unused result warning
> > > > * 6e14f284 Silence used result warning
> > > > * da55007d Silence gcc warnings about unused fread return result
> > > > * cb509f0f Remove three "stringop-overflow" warnings
> > > > * 1545996b (topic-removewarnings3) Remove some strncat
> > stringop-overflow
> > > > warning
> > > >
> > > > Looks like you played around with the graphics magick issue by
> > > > tinkering on your clone's master branch, which you then pushed to your
> > > > fork to make Travis build it.
> > > >
> > > > It looks like you then did a "git pull --rebase" or somesuch after you
> > > > saw that I had committed and pushed to upstream/master.  By rebasing
> > your
> > > > two commits on top of mine, you changed their SHA-1 hashes --- and
> > > > therefore
> > > > you made your fork and the upstream repo diverge.
> > > >
> > > > So:  don't do that.  Leave your fork's master alone, always, so it
> > never
> > > > is anything but a copy of upstream's.  Do all work on your fork on side
> > > > branches, always.  If you stick to that, this won't happen.
> > > >
> > > > Now, how to fix it:
> > > >
> > > > I have already gotten upstream fixed for graphicsmagick, so your
> > additional
> > > > commits are now moot.  So if I were in your position I'd force my clone
> > > > back
> > > > to match upstream by discarding those commits altogether and force
> > pushing
> > > > upstream's master to origin:
> > > >
> > > > git checkout master
> > > > git reset --hard upstream/master
> > > > git push --force origin master
> > > >
> > > > This will discard your "work to add graphicsmagick properly" and
> > "second
> > > > try
> > > > to get graphicsmagick into the build" commits, which should be
> > unnecessary.
> > > >
> > > > If you hate to lose that work even though it's moot, and *really* want
> > to
> > > > save
> > > > those two commits, you can force them onto a side branch:
> > > >
> > > > git checkout master
> > > > git checkout -b topic-savemycommits
> > > > git checkout master
> > > > git reset --hard up

Re: [Xastir-dev] Github README

[km5vy Tom Russo]

On Tue, Apr 16, 2019 at 08:35:30AM -0700, we recorded a bogon-computron 
collision of the  flavor, containing:
> I was thinking about that github:xastir/Xastir page in terms of a
> first-time user: They want instructions for compiling and getting it
> running RIGHT NOW. They don't care about 95% of what's in README there. At
> least that's where my head is at when I'm hunting down a project and
> cloning it.
> 
> I've been to quite a few other Github sites where the README describes what
> the software is/does, then how to get it up and running. Maybe pointers to
> more detailed docs at the end. That's probably how ours should be as well.
> No extra cruft or side discussions.

I agree.  You should go back and read what was in README prior to our 
Git migration.  It was much, much larger, and 99% of it was irrelevant to
a first time user.  Now we're down to 95% irrelevant verbiage.

> Looking at the below link I'm left with questions. They talk more about the
> project than how to get it running RIGHT NOW. Perhaps putting compile/run
> instructions in the earlier part of it and then the project stuff later
> might work?
> 
> https://help.github.com/en/articles/about-readmes

We have a real documentation problem, and not just in README.md.  Not just 
missing quick-start info, but really detailed guidance that is just plain
obsolete.

The many README.* files in the Xastir source tree are generally just collections
of tidbits that have grown almost continually over the course of the project's
history, sometimes simply cutting-and-pasting from half-baked thoughts in 
email chains.  

The Wiki is nice, but it too suffers from bloat as people add the 
specific build commands for a distro-du-jour that are so tied to one particular
release of that distro that they are stale 6 months later and never updated.

A new user, encountering this project for the first time, will not have an
easy time figuring out what to do where.  What we really need to do is get
rid of a lot of the READMEs we have, and make a much more lean set of
guidance, probably on the wiki.

> On Tue, Apr 16, 2019 at 8:24 AM Tom Russo  wrote:
> 
> > On Tue, Apr 16, 2019 at 09:20:16AM -0600, we recorded a bogon-computron
> > collision of the  flavor, containing:
> > > On Tue, Apr 16, 2019 at 08:12:45AM -0700, we recorded a bogon-computron
> > collision of the  flavor, containing:
> > > > Looked at the README which displays at xastir/Xastir on Github
> > recently. It
> > > > doesn't say anything about building Xastir. Is it easy to put a link
> > into
> > > > the markdown there to point to the correct document? If not we could
> > put
> > > > some simple build instructions directly into that file with a pointer
> > to
> > > > more detailed instructions.
> > >
> > > The problem with the README is that it is was enormous and bloated, and
> > > was trimmed dramatically when we moved to Github (because it's displayed
> > > on the front page).  I think it really needs to be trimmed down even more
> > > to something that people will actually read.
> > >
> > > There is a reference to README.Getting-Started "for a relatively quick
> > > overview of how to build and use Xastir" and a link to the wiki for
> > > detailed guidance.  How much more does there need to be?
> > >
> > > It is not difficult to make the references to the other documents into
> > > links in markdown.  I'll get it done for that one link right now.
> >
> > I've done this, but now I see the README.Getting-Started is also bloated
> > (over 5000 words) and not even approximately a "relatively quick overview".
> >
> > A real quick-start guide would be good.  Or just point to the wiki and
> > leave
> > it at that.
> >
> > --
> > Tom RussoKM5VY
> > Tijeras, NM
> >
> >  echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z]
> > [n-z][a-m]
> >
> > ___
> > Xastir-dev mailing list
> > Xastir-dev@lists.xastir.org
> > http://xastir.org/mailman/listinfo/xastir-dev
> >
> 
> 
> -- 
> Curt, WE7Uhttp://we7u.wetnet.nethttp://www.sarguydigital.com

-- 
Tom RussoKM5VY
Tijeras, NM  

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]

___
Xastir-dev mailing list
Xastir-dev@lists.xastir.org
http://xastir.org/mailman/listinfo/xastir-dev

Re: [Xastir-dev] Compiling from "build" directory

[km5vy Tom Russo]

On Mon, Apr 15, 2019 at 12:51:01PM -0700, we recorded a bogon-computron 
collision of the  flavor, containing:
> On Mon, Apr 15, 2019 at 10:03 AM Tom Russo  wrote:
> >
> > On another note, I'd really like someday to do away with our "internal
> shapelib"
> > because it's an artifact of the bad old days when shapelib was not in very
> > many package management systems.
> 
> Standby on that one...

I've been standing by for a few years now.  I can stand by more.  But I really,
really dislike its presence.

-- 
Tom RussoKM5VY
Tijeras, NM  

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]

___
Xastir-dev mailing list
Xastir-dev@lists.xastir.org
http://xastir.org/mailman/listinfo/xastir-dev

Re: [Xastir-dev] [Xastir] Xastir development source now on github, sourceforge CVS now closed to new commits.

[km5vy Tom Russo]

On Thu, Jul 07, 2016 at 02:12:10PM -0500, we recorded a bogon-computron 
collision of the  flavor, containing:
> Just trying it out -- checked out the repo, bootstrap.sh, ./configure, make
> 
> Unfortunately:
> 
> make[2]: *** No rule to make target `README.CVS', needed by `all-am'.  Stop.

OOPS!  Thanks.  I'll fix that.

> On Thu, Jul 7, 2016 at 1:27 PM, Curt Mills  wrote:
> 
> > On Thu, Jul 7, 2016 at 9:31 AM, Tom Russo  wrote:
> >
> > > As announced a couple of months ago, Curt and I have been talking about
> > > moving
> > > Xastir version control over to github, and discontinuing use of
> > sourceforge
> > > and CVS for hosting the main repository.
> > >
> > > There wasn't much feedback from the group about that, and yesterday we
> > went
> > > ahead and did it.  The sourceforge CVS repository is still there, but all
> > > commit access has been locked down and we'll shut down the CVS repo
> > > altogether
> > > when we're sure this is all working properly.
> > >
> >  ...
> >
> > > The Xastir wiki and home page have NOT yet been updated to reflect this
> > > move of version control.  It will be.
> > >
> >
> > Note: By "we went ahead and did it", Tom really meant that he did the
> > work.  ;-)  Thanks Tom!
> >
> > The main Xastir Wiki page has been updated, as well as the main SourceForge
> > page. I also created a GitHub Wiki page and pointed it back to the
> > Xastir.org website.
> >
> > I encourage those who have created/updated Xastir Wiki pages in the past to
> > update those pages with the new Git commands.
> >
> > --
> > Curt, WE7U
> > http://we7u.wetnet.net
> > http://www.sarguydigital.com
> > ___
> > Xastir-dev mailing list
> > Xastir-dev@lists.xastir.org
> > http://xastir.org/mailman/listinfo/xastir-dev
> >
> 
> 
> 
> -- 
> J. Lance Cotton, KJ5O
> j...@lightningflash.net
> http://kj5o.lightningflash.net
> Three Step Plan: 1. Take over the world. 2. Get a lot of cookies. 3. Eat
> the cookies.

-- 
Tom RussoKM5VY   SAR502   DM64ux  http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236http://kevan.org/brain.cgi?DDTNM
 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]

 


___
Xastir-dev mailing list
Xastir-dev@lists.xastir.org
http://xastir.org/mailman/listinfo/xastir-dev