The toxic-0.8.0.tar.gz isn't quite at 0.8.0 -- at least the version numbers in it are still set to the previous 0.7.2 release (eg. in the file ./cfg/global_vars.mk). I think this tarball does contain most of the commits for the 0.8.0 release, except a final version number update commit, which will confuse users as the new program's stated version doesn't match the ebuild.
upstream looks fine https://github.com/JFreegman/toxic/commits/master/cfg/global_vars.mk
I know. It's gentoo's tarball that is slightly old / misversioned.
The ebuild currently (and correctly) points to the GitHub Release that was pushed. The version string wasn't corrected by upstream until the commit *after* that, explaining why our version was mismatched. Here's a sed line I put together for it in src_prepare: sed -i \ -e 's/^\(TOXIC_VERSION =\).*$/\1 0.8.0/' \ cfg/global_vars.mk || die "Version string correction failed." Using 's/0.7.2/0.8.0/' works as well; is my more precise version the better one? I'd rather not invoke the ire of someone by committing without at least an ack.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=675810158cfecff172c501b898ff379db0051af3 commit 675810158cfecff172c501b898ff379db0051af3 Author: Daniel Campbell <zlg@gentoo.org> AuthorDate: 2017-09-28 22:07:43 +0000 Commit: Daniel Campbell <zlg@gentoo.org> CommitDate: 2017-09-28 22:07:43 +0000 net-im/toxic: correct version string in package Upstream's first commit after the Release fixes this. This is a quick fix that will need to be removed for the next version bump, assuming upstream remembers to update the string before tagging a release. No input or review was received for over two weeks, leaving me with little choice but to push, as it works for me. Thanks to Dennis New for reporting. Closes: https://bugs.gentoo.org/630370 Package-Manager: Portage-2.3.8, Repoman-2.3.3 net-im/toxic/toxic-0.8.0.ebuild | 9 +++++++++ 1 file changed, 9 insertions(+)
