Current development versions of KBibTeX inspect the current source directory for information of a Git checkout and use the current Git revision and branch as additional information in the About box. As the ebuild for KBibTeX (in the case of app-text/kbibtex-0.8_pre20180222) gets its source code as a .tar.gz-ball downloaded from GitHub, no .git directory exists. On the other hand, it is not (yet) a stable release with a fixed version number. Therefore the version string looks like " (), near 0.7.90" instead of "32bf6595 (kbibtex/0.8), near 0.7.90". However, there is a simple solution: The CMake script assembling the version string from the Git repository can be told to use Git revision and branch information from environment variables instead. Thus, this issue can be easily fixed by introducing a dedicated src_compile function: src_compile() { GIT_REV=${COMMIT:0:8} GIT_BRANCH=${PN}/${PV%_pre*} kde5_src_compile } COMMIT is a variable set earlier in the ebuild file. GIT_REV shall be shorter, so only the first eight characters are used. GIT_BRANCH shall look like "kbibtex/0.8", so it takes the program name and the program version, but removes "_pre" and the following date.
This does not seem to work for me (with snapshot build from current 0.8 branch HEAD). I think a better approach, rather than using env vars, would be passing those to cmake.
(In reply to Andreas Sturmlechner from comment #1) > This does not seem to work for me (with snapshot build from current 0.8 > branch HEAD). I think a better approach, rather than using env vars, would > be passing those to cmake. Hello, I am KBibTeX upstream. I'll look into passing the Git information via CMake arguments. Until then, can you please provide some details on "this does not seem to work for me"? For example, what is your output from the cmake and make/ninja phase?
Imho as you are the upstream maintainer you should provide a final release version. Snapshots are only needed for unreleased and needed stuff downstream ;).
(In reply to Johannes Huber from comment #3) > Imho as you are the upstream maintainer you should provide a final release > version. Snapshots are only needed for unreleased and needed stuff > downstream ;). Updating a Gentoo package is far easier than making a release ... ;-) There is a KBibTeX 0.8-beta1 release (0.7.90) available by now. Have you created a package for that one already (haven't checked)? https://t-fischer.dreamwidth.org/6707.html
(In reply to Thomas Fischer from comment #4) > There is a KBibTeX 0.8-beta1 release (0.7.90) available by now. Have you > created a package for that one already (haven't checked)? > https://t-fischer.dreamwidth.org/6707.html Yes, 0.8_pre20180504 actually represents 0.7.90 (in order to be an upgrade to the existing snapshot). Do you have an ETA for 0.8 release?
> Do you have an ETA for 0.8 release? I just tagged 0.8-rc1 (0.7.95), now preparing tar-balls that shoud hit KDE's mirrors in a few hours/days. Then, depending on feedback, I plan to make the official release soon after, i.e. early June.
We have 0.8.1 in tree and considering the zero delta over the last snapshot already pending stabilisation: bug 658856 I think that a nice solution to the original issue in this bug would ideally go into extra-cmake-modules to be available to all KDE software. Maybe a short commit hash representation would even be useful to be displayed in the About dialog, if built from git or as a snapshot.
