I think I see the silly mistake that is causing that behavior - I don't break out of the connect loop on success. I'll submit a fix, but it may be a few days.
- Jason On Tue, Jan 23, 2018 at 3:10 PM John Ronan <[email protected]> wrote: > > > On 23/01/18 20:26, Tom Russo wrote: > > We have not had an Xastir release since 2.0.8, prior to our move off of > > SourceForge and onto github. > > > > That means that any package managers out there are providing code that's > > nearly two years old, since most won't generate new packages without > release > > tarballs (and many won't do it even *with* new tarballs, but I > digress). And > > those old packages probably all have READMEs and other documentation that > > points people to SourceForge. > > > > I'm thinking we ought to get to a nice stable place (maybe after all the > IPv6 > > stuff is shaken out) and tag a new 2.1.0 release sometime soon. There > have > > been a few notable improvements lately, and we should share them with > people > > who aren't going to get all gitted up. > > > > I've already gone through the code and updated all the copyright dates, > and > > cleaned up some documentation files in preparation for that sort of > thing. > > > > Typically, a release under SourceForge meant Curt generated a > post-boostrap.sh > > tarball of the code (so it includes configure and all the Makefile.ins), > then > > just uploaded it. > > > > Generally, a release on Github is just a tag that makes it show up on the > > Releases tab, and then when a user clicks the ".zip" or ".tar.gz" link, > github > > just zips or tars that repository state for them. It is possible to > upload > > additional binary files to associate with release as well, but that's > not what > > we want here -- we actually want the tarballs to be ready to > configure/make, > > so the source tarball needs additional files. > > > > While it greatly simplifies the process of calling a repo state > "released," > > that approach to release tarball generation makes the post-bootstrap.sh > thing > > a little tricky. It has been proposed here before that we do it via a > release > > branch, where we commit and push the bootstrap artifacts to the release > branch, > > then just tag the head of that as the release, leaving master without > those > > files. In that way, the release branch could just be checked out and > built > > (without running bootstrap), as could any code taken out of a tarball of > the > > release branch. > > > > I think I like that idea, and intend to make the 2.1.0 release like > > that if there are no objections to the approach. > > > > Anyone holding on to new code they'd like to see in the 2.1.0 release? > > Is Dan's experience with IPv6 addressing something that Jason is going to > > have to fix, and so should block doing the 2.1.0 release for a while? > > > I noticed the same issue as Dan on an IPv6 native host but didn't > really want to comment until I had a chance to see if I knew what the > issue was or solution might be (which I haven't). Its been running fine > on my desktop in work since Last week. > > IMHO I wouldn't hold up a release because of it. > > Regards > John > EI7IG > > _______________________________________________ > Xastir-dev mailing list > [email protected] > http://xastir.org/mailman/listinfo/xastir-dev > _______________________________________________ Xastir-dev mailing list [email protected] http://xastir.org/mailman/listinfo/xastir-dev
