https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: dev-vcs/mercurial-6.8 fails to compile. Discovered on: amd64 (internal ref: ci) Info about the issue: https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#CF0014
Created attachment 899618 [details] build.log build log and emerge --info
*** This bug has been marked as a duplicate of bug 937554 ***
Hello James, not a duplicate, see the build log and the portage timestamp @@@@@ PLEASE PAY ATTENTION HERE!!! @@@@@ This information may help you to understand if this is a duplicate or if this bug exists after you pushed a fix; This ebuild was merged at the following commit: https://github.com/gentoo/gentoo/commit/b1f29637d0d61a0999ac192c88d27e89c5e48aa6 (Thu Aug 8 14:48:06 UTC 2024) @@@@@ END @@@@@ @@@@@ PLEASE PAY ATTENTION HERE!!! @@@@@ This ebuild was merged (directly or as a dependency) because of the following commit: https://github.com/gentoo/gentoo/commit/b1f29637d0d61a0999ac192c88d27e89c5e48aa6 @@@@@ END @@@@@
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7b6ceeb3e8245f1314bfee469d942613613cd4c2 commit 7b6ceeb3e8245f1314bfee469d942613613cd4c2 Author: Cédric Krier <cedk@gentoo.org> AuthorDate: 2024-08-09 07:29:20 +0000 Commit: Cédric Krier <cedk@gentoo.org> CommitDate: 2024-08-09 07:29:20 +0000 dev-vcs/mercurial: call cargo_gen_config even when rust is not active Since 9b2def86a9c7fd8821a5b83df7d250fc4c73540f distutils-r1 installs under cargo_env when cargo eclass is inherited even if the rust flag is not set. But cargo_env fails if cargo_gen_config was not run prior. Closes: https://bugs.gentoo.org/937578 Signed-off-by: Cédric Krier <cedk@gentoo.org> dev-vcs/mercurial/mercurial-6.5.3.ebuild | 3 +++ dev-vcs/mercurial/mercurial-6.6.2.ebuild | 3 +++ dev-vcs/mercurial/mercurial-6.7.4.ebuild | 3 +++ dev-vcs/mercurial/mercurial-6.8.ebuild | 3 +++ dev-vcs/mercurial/mercurial-9999.ebuild | 3 +++ 5 files changed, 15 insertions(+)
Apologies, there was a lot of firefighting yesterday, so I missed the slightly different nature of this one. Thanks to Cédric for fixing. I feel like this should be fixed in the eclass, but the eclass doesn't know what the ebuild does to activate Cargo, so it doesn't seem possible. There are other packages that set CARGO_OPTIONAL=1 and use distutils, but they all call cargo_src_unpack unconditionally, so that's another way around it. At least maintainers will immediately spot this issue from now on.
