Re: [Xastir] ATTENTION: Preparing for next release: Please thrash on the code
Totally your choice. The sooner the better as far as I'm concerned, unless bugs turn up between now and then. On Thu, May 23, 2019 at 12:06 PM Tom Russo wrote: > 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. > > 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 > > > > interfaces, messaging, bulletins, weather stations, tracking, > following > > > > stations, maps, etc. Anything you can think of. > > > > > > > > The latest code compiles much cleaner and a lot of fixes went in to > make > > > > that possible. We'd like this release to function well, so whatever > you > > > can > > > > do to exercise the code would be most appreciated. > > > > > > > > If you find a bug or odd operation, report it here: > > > > > > > > https://github.com/Xastir/Xastir/issues > > > > > > > > Thanks! > > > > > > > > -- > > > > Curt, WE7Uhttp://we7u.wetnet.net > > > > http://www.sarguydigital.com > > > > ___ > > > > Xastir mailing list > > > > Xastir@lists.xastir.org > > > > http://xastir.org/mailman/listinfo/xastir > > > > > > > ___ > > > Xastir mailing list > > > Xastir@lists.xastir.org > > > http://xastir.org/mailman/listinfo/xastir > > > > > > > > > -- > > Curt, WE7Uhttp://we7u.wetnet.net > http://www.sarguydigital.com > > ___ > > Xastir mailing list > > Xastir@lists.xastir.org > >
Re: [Xastir] ATTENTION: Preparing for next release: Please thrash on the code
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. 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 > > > interfaces, messaging, bulletins, weather stations, tracking, following > > > stations, maps, etc. Anything you can think of. > > > > > > The latest code compiles much cleaner and a lot of fixes went in to make > > > that possible. We'd like this release to function well, so whatever you > > can > > > do to exercise the code would be most appreciated. > > > > > > If you find a bug or odd operation, report it here: > > > > > > https://github.com/Xastir/Xastir/issues > > > > > > Thanks! > > > > > > -- > > > Curt, WE7Uhttp://we7u.wetnet.net > > > http://www.sarguydigital.com > > > ___ > > > Xastir mailing list > > > Xastir@lists.xastir.org > > > http://xastir.org/mailman/listinfo/xastir > > > > > ___ > > Xastir mailing list > > Xastir@lists.xastir.org > > http://xastir.org/mailman/listinfo/xastir > > > > > -- > Curt, WE7Uhttp://we7u.wetnet.nethttp://www.sarguydigital.com > ___ > Xastir mailing list > Xastir@lists.xastir.org > http://xastir.org/mailman/listinfo/xastir -- 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 mailing list Xastir@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
Re: [Xastir] ATTENTION: Preparing for next release: Please thrash on the code
I may have to resurrect my radar servers soon. On Thu, May 23, 2019 at 09:26 David A Aitcheson wrote: > The only irritation I am finding is the constantly changing file server > naming convention at the NWS part of NOAA. > > Just when I started to get a handle on the Radar links it all changed > again. > > Otherwise operators on the other end failing to "ACK" a message is out > of the programmers control. > > 73 > Dave > KB3EFS > > PS - I am now known as Dave "The Solar Dude" on some other groups.io > reflectors just to prevent confusion in a "Multi Dave" conversation. > > > > > On 5/23/19 10:15 AM, Curt Mills wrote: > > 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. > > > > > > 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 > >>> interfaces, messaging, bulletins, weather stations, tracking, following > >>> stations, maps, etc. Anything you can think of. > >>> > >>> The latest code compiles much cleaner and a lot of fixes went in to > make > >>> that possible. We'd like this release to function well, so whatever you > >> can > >>> do to exercise the code would be most appreciated. > >>> > >>> If you find a bug or odd operation, report it here: > >>> > >>> https://github.com/Xastir/Xastir/issues > >>> > >>> Thanks! > >>> > >>> -- > >>> Curt, WE7Uhttp://we7u.wetnet.net > >>> http://www.sarguydigital.com > >>> ___ > >>> Xastir mailing list > >>> Xastir@lists.xastir.org > >>> http://xastir.org/mailman/listinfo/xastir > >>> > >> ___ > >> Xastir mailing list > >> Xastir@lists.xastir.org > >> http://xastir.org/mailman/listinfo/xastir > >> > > > > ___ > Xastir mailing list > Xastir@lists.xastir.org > http://xastir.org/mailman/listinfo/xastir > -- Gerry Creager NSSL/CIMMS 405.325.6371 ++ *The way to get started is to quit talking and begin doing.* * Walt Disney* ___ Xastir mailing list Xastir@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
Re: [Xastir] ATTENTION: Preparing for next release: Please thrash on the code
The only irritation I am finding is the constantly changing file server naming convention at the NWS part of NOAA. Just when I started to get a handle on the Radar links it all changed again. Otherwise operators on the other end failing to "ACK" a message is out of the programmers control. 73 Dave KB3EFS PS - I am now known as Dave "The Solar Dude" on some other groups.io reflectors just to prevent confusion in a "Multi Dave" conversation. On 5/23/19 10:15 AM, Curt Mills wrote: > 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. > > > 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 >>> interfaces, messaging, bulletins, weather stations, tracking, following >>> stations, maps, etc. Anything you can think of. >>> >>> The latest code compiles much cleaner and a lot of fixes went in to make >>> that possible. We'd like this release to function well, so whatever you >> can >>> do to exercise the code would be most appreciated. >>> >>> If you find a bug or odd operation, report it here: >>> >>> https://github.com/Xastir/Xastir/issues >>> >>> Thanks! >>> >>> -- >>> Curt, WE7Uhttp://we7u.wetnet.net >>> http://www.sarguydigital.com >>> ___ >>> Xastir mailing list >>> Xastir@lists.xastir.org >>> http://xastir.org/mailman/listinfo/xastir >>> >> ___ >> Xastir mailing list >> Xastir@lists.xastir.org >> http://xastir.org/mailman/listinfo/xastir >> > ___ Xastir mailing list Xastir@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
Re: [Xastir] ATTENTION: Preparing for next release: Please thrash on the code
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. 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 > > interfaces, messaging, bulletins, weather stations, tracking, following > > stations, maps, etc. Anything you can think of. > > > > The latest code compiles much cleaner and a lot of fixes went in to make > > that possible. We'd like this release to function well, so whatever you > can > > do to exercise the code would be most appreciated. > > > > If you find a bug or odd operation, report it here: > > > > https://github.com/Xastir/Xastir/issues > > > > Thanks! > > > > -- > > Curt, WE7Uhttp://we7u.wetnet.net > > http://www.sarguydigital.com > > ___ > > Xastir mailing list > > Xastir@lists.xastir.org > > http://xastir.org/mailman/listinfo/xastir > > > ___ > Xastir mailing list > Xastir@lists.xastir.org > http://xastir.org/mailman/listinfo/xastir > -- Curt, WE7Uhttp://we7u.wetnet.nethttp://www.sarguydigital.com ___ Xastir mailing list Xastir@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
Re: [Xastir] ATTENTION: Preparing for next release: Please thrash on the code
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 > interfaces, messaging, bulletins, weather stations, tracking, following > stations, maps, etc. Anything you can think of. > > The latest code compiles much cleaner and a lot of fixes went in to make > that possible. We'd like this release to function well, so whatever you can > do to exercise the code would be most appreciated. > > If you find a bug or odd operation, report it here: > > https://github.com/Xastir/Xastir/issues > > Thanks! > > -- > Curt, WE7Uhttp://we7u.wetnet.net > http://www.sarguydigital.com > ___ > Xastir mailing list > Xastir@lists.xastir.org > http://xastir.org/mailman/listinfo/xastir > ___ Xastir mailing list Xastir@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
Re: [Xastir] ATTENTION: Preparing for next release: Please thrash on the code
Anyone playing with the Github master branch? We've heard nothing yet regarding bug reports or how stable/unstable it is. A new Xastir release is coming and we'd like it to be a good, stable one. On Thu, May 9, 2019 at 7:56 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 > interfaces, messaging, bulletins, weather stations, tracking, following > stations, maps, etc. Anything you can think of. > > The latest code compiles much cleaner and a lot of fixes went in to make > that possible. We'd like this release to function well, so whatever you can > do to exercise the code would be most appreciated. > > If you find a bug or odd operation, report it here: > > https://github.com/Xastir/Xastir/issues > > Thanks! > > -- > Curt, WE7Uhttp://we7u.wetnet.net > http://www.sarguydigital.com > -- Curt, WE7Uhttp://we7u.wetnet.nethttp://www.sarguydigital.com ___ Xastir mailing list Xastir@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
