Created attachment 533340 [details, diff] Fix proposal In the spirv-tools-9999.ebuild, the build commit hash is generated like this: multilib_src_install() { default # create a header file with the commit hash of the current revision # vulkan-tools needs this to build local revision="$(git-r3_peek_remote_ref)" &> /dev/null echo "${revision}" > "${D}/usr/include/${PN}/${PN}-commit.h" || die } This fails for two reasons: 1. It doesn't work at all when using FEATURES="network-sandbox", since it tries peeking at the remote commit at the upstream github.com repository. 2. It generates the wrong commit ID when using EGIT_ features to override the commit/branch/url. (For example, `spirv_tools_LIVE_COMMIT` in make.conf) I suggest solving both of these issues by replacing it with: multilib_src_install() { default # create a header file with the commit hash of the current revision # vulkan-tools needs this to build echo "${EGIT_VERSION}" > "${D}/usr/include/${PN}/${PN}-commit.h" || die } Not only is this code simpler and more efficient, it's also more correct.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=464653ba2a37e4735b8e80fa0860f53a628367af commit 464653ba2a37e4735b8e80fa0860f53a628367af Author: Niklas Haas <bgo@nand.wakku.to> AuthorDate: 2018-05-26 17:08:36 +0000 Commit: Nick Sarnie <sarnex@gentoo.org> CommitDate: 2018-05-26 17:10:16 +0000 dev-util/spirv-tools: Fix SHA1 hash generation for 9999 git-r3 already does exactly what we want Fixes: https://bugs.gentoo.org/656560 Package-Manager: Portage-2.3.40, Repoman-2.3.9 dev-util/spirv-tools/spirv-tools-9999.ebuild | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)