https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: dev-lang/ruby-3.2.2-r2 uses portageq in ebuild scope. Discovered on: amd64 (internal ref: ci)
Created attachment 863331 [details] build.log build log and emerge --info
portageq is called indirectly via ruby.eselect: [[ $(portageq envvar FEATURES) =~ noman ]] || create_man_links ${version} The module should do something like this instead, using eselect's envvar function: inherit package-manager ... [[ $(envvar dev-lang/ruby FEATURES) =~ noman ]] || ...
*** Bug 907897 has been marked as a duplicate of this bug. ***
Created attachment 863426 [details, diff] ruby.eselect: Call envvar from eselect's package manager lib instead of portageq Attached patch should fix it. I have tested it without and with "noman" in FEATURES, and it seems to work as intended (i.e. creating or not creating the ruby.1 redirect page). Signed-off-by: Ulrich Müller <ulm@gentoo.org>
Created attachment 863530 [details, diff] ruby.eselect: Call create_man_links unconditionally Thinking about it, checking FEATURES=noman isn't even necessary, because create_man_links() will do nothing when the target man page doesn't exist. The empty loop will still be much faster than calling portageq. Updated patch attached (this time, properly formatted for proj/ruby-scripts.git).
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bbe1d7659a532854096624d4e2a529f47db5c7b9 commit bbe1d7659a532854096624d4e2a529f47db5c7b9 Author: Hans de Graaff <graaff@gentoo.org> AuthorDate: 2023-06-16 07:52:06 +0000 Commit: Hans de Graaff <graaff@gentoo.org> CommitDate: 2023-06-16 07:52:15 +0000 app-eselect/eselect-ruby: add 20230616 Fixes: https://bugs.gentoo.org/908052 Fixes: https://bugs.gentoo.org/907896 Signed-off-by: Hans de Graaff <graaff@gentoo.org> app-eselect/eselect-ruby/Manifest | 1 + .../eselect-ruby/eselect-ruby-20230616.ebuild | 22 ++++++++++++++++++++++ 2 files changed, 23 insertions(+)
