Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]
Then the git sha displayed in Xastir will be the git sha in your package repo. That is probably OK, though, and will accurately reflect its status in your package management system. If you want the About box to have the SHA-1 in our repo, you should just hack XastirGitStamp to display our SHA-1 instead of using git to probe for it, or have it return nothing at all. You're already patching our stuff to fit in with your choices, this should be no big deal. The feature is in place to allow our power users (all of whom build from source themselves and don't use packaged versions) to see what version of the code they're actually using based on their git SHAs. It's gonna stay there. On Sun, Feb 23, 2020 at 08:32:57PM +0100, we recorded a bogon-computron collision of the flavor, containing: > Re: Tom Russo 2020-02-23 <20200223182310.ga7...@bogodyn.org> > > The script looks in the top level of the Xastir source tree being built > > for the presence of a .git directory. The fact that the source tree is > > under > > a package directory that is itself in git should have no impact (there will > > then be a .git directory at a higher level, and our script will simply > > be unaware of it and return no SHA at all). > > In the packaging repo, xastir is in the top level directory. > > https://salsa.debian.org/debian-hamradio-team/xastir > > Christoph -- Tom RussoKM5VY Tijeras, NM echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]
Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]
Re: Tom Russo 2020-02-23 <20200223182310.ga7...@bogodyn.org> > The script looks in the top level of the Xastir source tree being built > for the presence of a .git directory. The fact that the source tree is under > a package directory that is itself in git should have no impact (there will > then be a .git directory at a higher level, and our script will simply > be unaware of it and return no SHA at all). In the packaging repo, xastir is in the top level directory. https://salsa.debian.org/debian-hamradio-team/xastir Christoph
Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]
BTW, since you have chosen to use a snapshot rather than a release, you might want a later snapshot than the commit bb66a77 you're using. Commit f89c610 (29 Dec 2019) fixed a serious bug in weather alert parsing that had been introduced in commit aafbc49 (9 May 2019) and which still exists in the one you're using. Without that fix, weather alerts were basically broken and were showing up scrambled in the weather alerts dialog. After that, commits c61e49b and 64890aa are recommended as well, as the former fixes broken builds under GCC 10, and the latter updates the get-nws script to cope with recent changes in the server from which NWS shapefiles are downloaded (the most frequent change we have at this point). These three commits are the only substantive changes to the development branch since the bb66a7 commit you're currently using, but there are other, less consequential changes. If you move to today's master branch, you're probably a lot better off than sticking to that earlier one. We had intended a 2.2.0 release some time ago, but all of the developers are pretty much committed to other things at the moment (ranging from "work for a living" to "recover from a serious accident"). Using the development snapshot might not be the ideal option, but it's all there is at the moment. If you're not going to use 2.1.4 for the package, you should probably use the most recent development branch state (which is, at the moment, stable and functional) and keep an eye on development for serious bug fixes that show up. On Sun, Feb 23, 2020 at 10:29:38AM -0800, we recorded a bogon-computron collision of the flavor, containing: > Hi Tom, > > My apologies for the issues the patch to AC_INIT caused with TOCALL and > thank you for the explanation of versioning semantics. It was a bad > assumption on my part, carried over from $dayjob, when I didn't see a > release tag for 2.1.5 in the repo. 100% my mistake. > > Also, thank you to Iain for the identifying and addressing the bug in > Debian source package, which will now report 2.1.5 in the Help->About > dialog. > > Regards, > tony > > On Sun, Feb 23, 2020 at 10:45:51AM -0700, Tom Russo wrote: > > This is a forwarded version of an email sent to the Xastir mailing list. > > I am forwarding to you because you followed up to a different message on > > that > > list. > > > > To answer your direct question, "Since we are > > building from a snapshot - i.e., a version somewhere between 2.1.4 and > > 2.1.5, is there a preference for which we use for configure?" > > > > This is mistaken. You are in fact using 2.1.5, which means > > "development version between 2.1.4. and whatever our next release will be > > called." Since this version number is used to construct the TOCALL, the > > version number in AC_INIT should just be left at 2.1.5. > > > > 2.1.5 will never be "released", and the presence of APX215 in the TOCALL > > is supposed to say "this user is using a bleeding-edge version pulled > > from git". Our next release will get a version number bump. > > > > The Xastir build system tries to construct a useful Version string to > > display > > in the Help->About and also to print when Xastir is invoked with "-V", but > > this trick only works if the code is being built from a git clone (it > > sticks > > the current SHA-1 into the version displayed in these places, but does NOT > > screw up the TOCALL). That won't work if you're building the Debian package > > out of a tarball (the trick involves looking for a .git directory, and if > > found, invoking a git log command to get the current SHA-1). > > > > - Forwarded message from Tom Russo - > > > > Date: Sun, 23 Feb 2020 10:26:41 -0700 > > From: Tom Russo > > To: Xastir - APRS client software discussion > > Subject: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to > > malformed TOCALL > > > > Xastir's versions are goofy. The history of this is ancient, and there has > > been no reason to ungoof it. > > > > Even numbers are releases, odd numbers are working development versions, > > and are generally not updated for every commit --- Xastir 2.1.5 just means > > "development branch after stable 2.1.4". > > > > The TOCALL for the current development version of Xastir should be APX215, > > and there should be no need for finer granularity to show which commit on > > every transmit. The ambiguity of "which commit of the dev branch am I > > using?" > > is resolved using the Help->About box. This can only matter to the user > > him/her > > self, and need not be transmitted in every packet. A TOCALL of APX215 > > should > > be enough for all interested parties on the receive end. > > > > If there is a need for a stable release so that distros can have a stable > > version, we should push one out. There is an open project on github for > > our > > next release with a number of required fixes before we do it. There was a > > flurry of activity on
Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]
Hi Tom, My apologies for the issues the patch to AC_INIT caused with TOCALL and thank you for the explanation of versioning semantics. It was a bad assumption on my part, carried over from $dayjob, when I didn't see a release tag for 2.1.5 in the repo. 100% my mistake. Also, thank you to Iain for the identifying and addressing the bug in Debian source package, which will now report 2.1.5 in the Help->About dialog. Regards, tony On Sun, Feb 23, 2020 at 10:45:51AM -0700, Tom Russo wrote: > This is a forwarded version of an email sent to the Xastir mailing list. > I am forwarding to you because you followed up to a different message on that > list. > > To answer your direct question, "Since we are > building from a snapshot - i.e., a version somewhere between 2.1.4 and > 2.1.5, is there a preference for which we use for configure?" > > This is mistaken. You are in fact using 2.1.5, which means > "development version between 2.1.4. and whatever our next release will be > called." Since this version number is used to construct the TOCALL, the > version number in AC_INIT should just be left at 2.1.5. > > 2.1.5 will never be "released", and the presence of APX215 in the TOCALL > is supposed to say "this user is using a bleeding-edge version pulled > from git". Our next release will get a version number bump. > > The Xastir build system tries to construct a useful Version string to display > in the Help->About and also to print when Xastir is invoked with "-V", but > this trick only works if the code is being built from a git clone (it sticks > the current SHA-1 into the version displayed in these places, but does NOT > screw up the TOCALL). That won't work if you're building the Debian package > out of a tarball (the trick involves looking for a .git directory, and if > found, invoking a git log command to get the current SHA-1). > > - Forwarded message from Tom Russo - > > Date: Sun, 23 Feb 2020 10:26:41 -0700 > From: Tom Russo > To: Xastir - APRS client software discussion > Subject: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to > malformed TOCALL > > Xastir's versions are goofy. The history of this is ancient, and there has > been no reason to ungoof it. > > Even numbers are releases, odd numbers are working development versions, > and are generally not updated for every commit --- Xastir 2.1.5 just means > "development branch after stable 2.1.4". > > The TOCALL for the current development version of Xastir should be APX215, > and there should be no need for finer granularity to show which commit on > every transmit. The ambiguity of "which commit of the dev branch am I using?" > is resolved using the Help->About box. This can only matter to the user > him/her > self, and need not be transmitted in every packet. A TOCALL of APX215 should > be enough for all interested parties on the receive end. > > If there is a need for a stable release so that distros can have a stable > version, we should push one out. There is an open project on github for our > next release with a number of required fixes before we do it. There was a > flurry of activity on some of those issues a while back, but between people > being injured, having other projects, and what not, nothing's been done for > quite a while. > > If there is a real need for a stable release, we could probably use a little > help. The open issues that we expected to have fixed for the next release > (nominally dubbed Xastir 2.2.0) can be seen at: > > https://github.com/Xastir/Xastir/projects/2 > > Some might need punting. > > On Sun, Feb 23, 2020 at 08:56:54AM -0800, we recorded a bogon-computron > collision of the flavor, containing: > > > > Hello Dave, > > > > The scenario here seems to be if you're running an intermediate release > > Xastir and not an official tagged release. > > > > Dave, yes, I see you on APRS-IS : https://aprs.fi/info/a/KB3EFS and it shows > > you're running v2.15 (APX215) per the "Last Path" line: > > > >KB3EFS>*APX215* via TCPIP*,qAC,T2ONTARIO > > > > > > The question here is if you're running a version of Xastir that's between > > v2.15 and v2.16, what should Xastir report as it's version to APRS-IS? It's > > not clear if it's illegal but maybe this would be legal: > > > >APX21G > > > > --David > > KI6ZHD > > > > > > > > > > On 02/23/2020 08:43 AM, David A Aitcheson wrote: > > > I did & was checking validity before making noise... > > > > > > Given that I only am able to be on APRS via an Internet connection > > > (read: no radio use allowed)... > > > > > > Given that I only build from source (read: I don't use a package from a > > > repository)... > > > > > > I think that it is not effecting me... > > > > > > David KI6ZHD - can you see me ( "KB3EFS" ) on the map in NY State? > > > > > > 73 > > > Dave > > > KB3EFS > > > > ___ > > Xastir mailing list > > xas...@lists.xastir.org > >
Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]
The script looks in the top level of the Xastir source tree being built for the presence of a .git directory. The fact that the source tree is under a package directory that is itself in git should have no impact (there will then be a .git directory at a higher level, and our script will simply be unaware of it and return no SHA at all). Our set up has been designed to work under the normal assumption that package maintainers aren't using snapshots, and only will use formal releases (an assumption that has held up for as long as Xastir has existed). It has always been assumed that anyone using the development branch is a power user building it themselves. On Sun, Feb 23, 2020 at 07:14:59PM +0100, we recorded a bogon-computron collision of the flavor, containing: > Re: Tom Russo 2020-02-23 <20200223174551.gd5...@bogodyn.org> > > That won't work if you're building the Debian package > > out of a tarball (the trick involves looking for a .git directory, and if > > found, invoking a git log command to get the current SHA-1). > > Fwiw, these tricks are often a PITA for package maintainers, because > we keep the packaging also in a git repository, but that one doesn't > have any (git) connection to the upstream xastir.git. > > In many cases, we have to patch the build system not to do these > tricks. (Generally, I didn't check if the variant used in xastir is > problematic.) > > Christoph -- Tom RussoKM5VY Tijeras, NM echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]
Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]
Re: Tom Russo 2020-02-23 <20200223174551.gd5...@bogodyn.org> > That won't work if you're building the Debian package > out of a tarball (the trick involves looking for a .git directory, and if > found, invoking a git log command to get the current SHA-1). Fwiw, these tricks are often a PITA for package maintainers, because we keep the packaging also in a git repository, but that one doesn't have any (git) connection to the upstream xastir.git. In many cases, we have to patch the build system not to do these tricks. (Generally, I didn't check if the variant used in xastir is problematic.) Christoph
Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]
This is a forwarded version of an email sent to the Xastir mailing list. I am forwarding to you because you followed up to a different message on that list. To answer your direct question, "Since we are building from a snapshot - i.e., a version somewhere between 2.1.4 and 2.1.5, is there a preference for which we use for configure?" This is mistaken. You are in fact using 2.1.5, which means "development version between 2.1.4. and whatever our next release will be called." Since this version number is used to construct the TOCALL, the version number in AC_INIT should just be left at 2.1.5. 2.1.5 will never be "released", and the presence of APX215 in the TOCALL is supposed to say "this user is using a bleeding-edge version pulled from git". Our next release will get a version number bump. The Xastir build system tries to construct a useful Version string to display in the Help->About and also to print when Xastir is invoked with "-V", but this trick only works if the code is being built from a git clone (it sticks the current SHA-1 into the version displayed in these places, but does NOT screw up the TOCALL). That won't work if you're building the Debian package out of a tarball (the trick involves looking for a .git directory, and if found, invoking a git log command to get the current SHA-1). - Forwarded message from Tom Russo - Date: Sun, 23 Feb 2020 10:26:41 -0700 From: Tom Russo To: Xastir - APRS client software discussion Subject: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL Xastir's versions are goofy. The history of this is ancient, and there has been no reason to ungoof it. Even numbers are releases, odd numbers are working development versions, and are generally not updated for every commit --- Xastir 2.1.5 just means "development branch after stable 2.1.4". The TOCALL for the current development version of Xastir should be APX215, and there should be no need for finer granularity to show which commit on every transmit. The ambiguity of "which commit of the dev branch am I using?" is resolved using the Help->About box. This can only matter to the user him/her self, and need not be transmitted in every packet. A TOCALL of APX215 should be enough for all interested parties on the receive end. If there is a need for a stable release so that distros can have a stable version, we should push one out. There is an open project on github for our next release with a number of required fixes before we do it. There was a flurry of activity on some of those issues a while back, but between people being injured, having other projects, and what not, nothing's been done for quite a while. If there is a real need for a stable release, we could probably use a little help. The open issues that we expected to have fixed for the next release (nominally dubbed Xastir 2.2.0) can be seen at: https://github.com/Xastir/Xastir/projects/2 Some might need punting. On Sun, Feb 23, 2020 at 08:56:54AM -0800, we recorded a bogon-computron collision of the flavor, containing: > > Hello Dave, > > The scenario here seems to be if you're running an intermediate release > Xastir and not an official tagged release. > > Dave, yes, I see you on APRS-IS : https://aprs.fi/info/a/KB3EFS and it shows > you're running v2.15 (APX215) per the "Last Path" line: > >KB3EFS>*APX215* via TCPIP*,qAC,T2ONTARIO > > > The question here is if you're running a version of Xastir that's between > v2.15 and v2.16, what should Xastir report as it's version to APRS-IS? It's > not clear if it's illegal but maybe this would be legal: > >APX21G > > --David > KI6ZHD > > > > > On 02/23/2020 08:43 AM, David A Aitcheson wrote: > > I did & was checking validity before making noise... > > > > Given that I only am able to be on APRS via an Internet connection > > (read: no radio use allowed)... > > > > Given that I only build from source (read: I don't use a package from a > > repository)... > > > > I think that it is not effecting me... > > > > David KI6ZHD - can you see me ( "KB3EFS" ) on the map in NY State? > > > > 73 > > Dave > > KB3EFS > > ___ > Xastir mailing list > xas...@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 xas...@lists.xastir.org http://xastir.org/mailman/listinfo/xastir - End forwarded message - -- Tom RussoKM5VY Tijeras, NM echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]
Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]
If there is a desire to build Xastir for debian from a tarball *AND* get the git sha into the Help->About box and "xastir -V" output, one could patch the script "scripts/XastirGitStamp.sh" so that it blindly inserts the SHA-1 you know to be relevant instead of asking Git to provide it. This would be safe to do in your packaging patches. XastirGitStamp.sh is run by src/Makefile to construct the "compiledate.c" file (which no longer contains the compile date, so that Xastir builds can be reproducible, another request we got a year or so ago). It takes a directory as argument, and in its current form looks top see if that directory has a .git directory. If so, it runs git log to get the sha. Simply rip out that logic and echo a fixed SHA-1 and you should be able to accomplish what you intended when you modified AC_INIT, but without breaking the TOCALL. On Sun, Feb 23, 2020 at 10:45:51AM -0700, we recorded a bogon-computron collision of the flavor, containing: > This is a forwarded version of an email sent to the Xastir mailing list. > I am forwarding to you because you followed up to a different message on that > list. > > To answer your direct question, "Since we are > building from a snapshot - i.e., a version somewhere between 2.1.4 and > 2.1.5, is there a preference for which we use for configure?" > > This is mistaken. You are in fact using 2.1.5, which means > "development version between 2.1.4. and whatever our next release will be > called." Since this version number is used to construct the TOCALL, the > version number in AC_INIT should just be left at 2.1.5. > > 2.1.5 will never be "released", and the presence of APX215 in the TOCALL > is supposed to say "this user is using a bleeding-edge version pulled > from git". Our next release will get a version number bump. > > The Xastir build system tries to construct a useful Version string to display > in the Help->About and also to print when Xastir is invoked with "-V", but > this trick only works if the code is being built from a git clone (it sticks > the current SHA-1 into the version displayed in these places, but does NOT > screw up the TOCALL). That won't work if you're building the Debian package > out of a tarball (the trick involves looking for a .git directory, and if > found, invoking a git log command to get the current SHA-1). > > - Forwarded message from Tom Russo - > > Date: Sun, 23 Feb 2020 10:26:41 -0700 > From: Tom Russo > To: Xastir - APRS client software discussion > Subject: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to > malformed TOCALL > > Xastir's versions are goofy. The history of this is ancient, and there has > been no reason to ungoof it. > > Even numbers are releases, odd numbers are working development versions, > and are generally not updated for every commit --- Xastir 2.1.5 just means > "development branch after stable 2.1.4". > > The TOCALL for the current development version of Xastir should be APX215, > and there should be no need for finer granularity to show which commit on > every transmit. The ambiguity of "which commit of the dev branch am I using?" > is resolved using the Help->About box. This can only matter to the user > him/her > self, and need not be transmitted in every packet. A TOCALL of APX215 should > be enough for all interested parties on the receive end. > > If there is a need for a stable release so that distros can have a stable > version, we should push one out. There is an open project on github for our > next release with a number of required fixes before we do it. There was a > flurry of activity on some of those issues a while back, but between people > being injured, having other projects, and what not, nothing's been done for > quite a while. > > If there is a real need for a stable release, we could probably use a little > help. The open issues that we expected to have fixed for the next release > (nominally dubbed Xastir 2.2.0) can be seen at: > > https://github.com/Xastir/Xastir/projects/2 > > Some might need punting. > > On Sun, Feb 23, 2020 at 08:56:54AM -0800, we recorded a bogon-computron > collision of the flavor, containing: > > > > Hello Dave, > > > > The scenario here seems to be if you're running an intermediate release > > Xastir and not an official tagged release. > > > > Dave, yes, I see you on APRS-IS : https://aprs.fi/info/a/KB3EFS and it shows > > you're running v2.15 (APX215) per the "Last Path" line: > > > >KB3EFS>*APX215* via TCPIP*,qAC,T2ONTARIO > > > > > > The question here is if you're running a version of Xastir that's between > > v2.15 and v2.16, what should Xastir report as it's version to APRS-IS? It's > > not clear if it's illegal but maybe this would be legal: > > > >APX21G > > > > --David > > KI6ZHD > > > > > > > > > > On 02/23/2020 08:43 AM, David A Aitcheson wrote: > > > I did & was checking validity before making noise... > > > > > > Given that I
