Created attachment 464340 [details] config.log Otherwise: checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/gmsgfmt checking for perl... /usr/bin/perl checking for perl >= 5.8.1... 5.22.3 checking for XML::Parser... ok checking for itstool... no configure: error: itstool not found !!! Please attach the following file when seeking support: !!! /var/tmp/portage/gnome-extra/gucharmap-9.0.2/work/gucharmap-9.0.2/config.log * ERROR: gnome-extra/gucharmap-9.0.2::gentoo failed (configure phase): May be true for other versions, too.
How did you manage to get into such a situation? gucharmap does depend on app-text/yelp-tools, which RDEPENDs on dev-utils/itstool. We might very well want to list both to be explicit (with no actual difference to the end result other than explicit maintenance of direct dependencies as itstool is checked for explicitly as well), but otherwise this is INVALID. As such removing the blocker from stabilization to have the stabilization bug show up for getatoms.py users again, and leaving this bug open for the explicit listing of deps and otherwise validating the build deps. I believe yelp-tools isn't necessary to depend on right now, UNLESS we eautoreconf (for yelp.m4), which we don't in current version. But need to re-familiarize myself with these tools and see if it makes sense to remove the deps when no eautoreconf is done. I wish we could just list eautoreconf build deps in a variable that autotools.eclass would pull into DEPEND if inherited for eautoreconf...
(In reply to Mart Raudsepp from comment #1) > How did you manage to get into such a situation? Stupidity when editing my testing scripts %-) --nodeps is a lovely pistol for one's feet.... Indeed invalid, sorry for the noise.
Downgraded full yelp-tools dep to just itstool in commit bb75a9b2c3ebbd55 as a routine check I do nowadays. Only found I had this bug open for this a bit later, so all fixed up now.
