Please remove all 'use' calls from global scope, they will be banned in Portage completely soon. Disclaimer: I have no clue where the call is coming from. Maybe it's the eclass but I'm not up to reading another toolchain.eclass. WARNING: 'use' function invoked by net-p2p/bitcoin-qt-0.10.2-r1 during metadata regeneration. WARNING: Please ensure upstream is aware of it and working to remove it. WARNING: 'use' function invoked by net-p2p/bitcoin-qt-0.10.2 during metadata regeneration. WARNING: Please ensure upstream is aware of it and working to remove it. WARNING: 'use' function invoked by net-p2p/bitcoin-qt-0.11.0 during metadata regeneration. WARNING: Please ensure upstream is aware of it and working to remove it. WARNING: 'use' function invoked by net-p2p/bitcoin-qt-0.11.1 during metadata regeneration. WARNING: Please ensure upstream is aware of it and working to remove it. WARNING: 'use' function invoked by net-p2p/bitcoin-qt-0.11.2 during metadata regeneration. WARNING: Please ensure upstream is aware of it and working to remove it. WARNING: 'use' function invoked by net-p2p/bitcoin-qt-0.12.0 during metadata regeneration. WARNING: Please ensure upstream is aware of it and working to remove it. WARNING: 'use' function invoked by net-p2p/bitcoin-qt-9999 during metadata regeneration. WARNING: Please ensure upstream is aware of it and working to remove it. WARNING: 'use' function invoked by net-p2p/bitcoind-0.10.2-r1 during metadata regeneration. WARNING: Please ensure upstream is aware of it and working to remove it. WARNING: 'use' function invoked by net-p2p/bitcoind-0.10.2 during metadata regeneration. WARNING: Please ensure upstream is aware of it and working to remove it. WARNING: 'use' function invoked by net-p2p/bitcoind-0.11.0 during metadata regeneration. WARNING: Please ensure upstream is aware of it and working to remove it. WARNING: 'use' function invoked by net-p2p/bitcoind-0.11.1 during metadata regeneration. WARNING: Please ensure upstream is aware of it and working to remove it. WARNING: 'use' function invoked by net-p2p/bitcoind-0.11.2 during metadata regeneration. WARNING: Please ensure upstream is aware of it and working to remove it. WARNING: 'use' function invoked by net-p2p/bitcoind-0.12.0 during metadata regeneration. WARNING: Please ensure upstream is aware of it and working to remove it. WARNING: 'use' function invoked by net-p2p/bitcoind-9999 during metadata regeneration. WARNING: Please ensure upstream is aware of it and working to remove it.
@luke-jr the problem is in the bitcoincore.eclass and its probably coming in at least from the use_if_iuse functions, but maybe elsewhere too @mgorny what utility are you using to check? i think i see where its coming in and i can see how to code around it, but i need a utility for feedback.
(In reply to Anthony Basile from comment #1) > @luke-jr the problem is in the bitcoincore.eclass and its probably coming > in at least from the use_if_iuse functions, but maybe elsewhere too > > @mgorny what utility are you using to check? i think i see where its coming > in and i can see how to code around it, but i need a utility for feedback. It's pkgcore. However, you can also take Portage and apply the latest patch I sent to the gentoo-portage-dev ml (which isn't showing up in archive for some reason, so I've forwarded it to you).
Anthony, any chance you would be able to put some urgency on this one? Git versions of Portage already ban this.
(In reply to Michał Górny from comment #3) > Anthony, any chance you would be able to put some urgency on this one? Git > versions of Portage already ban this. I'll look at it tomorrow. I don't understand why luke-jr hasn't responded, its his package. I'm just proxying. What's the alternative? Mask its consumers and yank?
I don't think that's an alternative since metadata cache generation will still fail. I think this will also stop rsync when it is released and Infra upgrades portage.
Okay I looked at this and the following fixes the issue. It looks to me salvageable provided we drop the `! use_if_iuse test` I'll give luke-jr a day or so to answer, and if not, I'll go conservative and assume `! use_if_iuse test` returns true since then we expand the commen depend atoms. At worst its overkill, but shouldn't break. diff --git a/eclass/bitcoincore.eclass b/eclass/bitcoincore.eclass index 5661cb0..be8911e 100644 --- a/eclass/bitcoincore.eclass +++ b/eclass/bitcoincore.eclass @@ -198,12 +198,6 @@ fi if [ "${BITCOINCORE_NEED_LIBSECP256K1}" = "1" ]; then BITCOINCORE_COMMON_DEPEND="${BITCOINCORE_COMMON_DEPEND} $LIBSECP256K1_DEPEND" fi -if [ "${PN}" != "libbitcoinconsensus" ] && ! use_if_iuse test; then - BITCOINCORE_COMMON_DEPEND="${BITCOINCORE_COMMON_DEPEND} - ${UNIVALUE_DEPEND} - >=dev-libs/boost-1.52.0[threads(+)] - " -fi bitcoincore_common_depend_use() { in_bcc_iuse "$1" || return BITCOINCORE_COMMON_DEPEND="${BITCOINCORE_COMMON_DEPEND} $1? ( $2 )"
That appears it will remove dependencies - not sure how that could be safe. Seems like the solution would be to turn the use_if_iuse into an in_iuse and wrap to the dep additions in test? ( ... ), but I don't really have a reasonable way to test if that silences it unless repoman is updated. (Correct me if I'm wrong, but the urgency here appears artificial, so I have prioritised it below things which are unavoidably urgent thus far...)
(In reply to Luke-Jr from comment #7) > Seems like the solution would be to turn the use_if_iuse into an in_iuse and > wrap to the dep additions in test? ( ... ), but I don't really have a > reasonable way to test if that silences it unless repoman is updated. in_iuse() cannot be used in global scope either.
(In reply to Ulrich Müller from comment #8) > (In reply to Luke-Jr from comment #7) > > Seems like the solution would be to turn the use_if_iuse into an in_iuse and > > wrap to the dep additions in test? ( ... ), but I don't really have a > > reasonable way to test if that silences it unless repoman is updated. > > in_iuse() cannot be used in global scope either. for the records, pkgcore doesn't catch this. we really need a QA check for this. @luke-jr, comment #7. How will it remove dependencies? assuming everything after the && is true errors on the side of caution. Suggest something which elimitates the use_if_iuse().
(In reply to Anthony Basile from comment #9) > @luke-jr, comment #7. How will it remove dependencies? assuming everything > after the && is true errors on the side of caution. Suggest something which > elimitates the use_if_iuse(). The patch literally removes the part where univalue/boost get added to the depends. If we can't use in_iuse, then I guess the only solution is to have a BITCOINCORE_IUSE which we test and copy to IUSE...
(In reply to Luke-Jr from comment #10) > (In reply to Anthony Basile from comment #9) > > @luke-jr, comment #7. How will it remove dependencies? assuming everything > > after the && is true errors on the side of caution. Suggest something which > > elimitates the use_if_iuse(). > > The patch literally removes the part where univalue/boost get added to the > depends. > > If we can't use in_iuse, then I guess the only solution is to have a > BITCOINCORE_IUSE which we test and copy to IUSE... No you misunderstood what I'm saying. Read the first line of comment #6. Here's what I'm proposing: diff --git a/eclass/bitcoincore.eclass b/eclass/bitcoincore.eclass index 5661cb0..c040c34 100644 --- a/eclass/bitcoincore.eclass +++ b/eclass/bitcoincore.eclass @@ -198,7 +198,7 @@ fi if [ "${BITCOINCORE_NEED_LIBSECP256K1}" = "1" ]; then BITCOINCORE_COMMON_DEPEND="${BITCOINCORE_COMMON_DEPEND} $LIBSECP256K1_DEPEND" fi -if [ "${PN}" != "libbitcoinconsensus" ] && ! use_if_iuse test; then +if [ "${PN}" != "libbitcoinconsensus" ]; then BITCOINCORE_COMMON_DEPEND="${BITCOINCORE_COMMON_DEPEND} ${UNIVALUE_DEPEND} >=dev-libs/boost-1.52.0[threads(+)]
(In reply to Anthony Basile from comment #11) > (In reply to Luke-Jr from comment #10) > > (In reply to Anthony Basile from comment #9) > > > @luke-jr, comment #7. How will it remove dependencies? assuming everything > > > after the && is true errors on the side of caution. Suggest something which > > > elimitates the use_if_iuse(). > > > > The patch literally removes the part where univalue/boost get added to the > > depends. > > > > If we can't use in_iuse, then I guess the only solution is to have a > > BITCOINCORE_IUSE which we test and copy to IUSE... > > No you misunderstood what I'm saying. Read the first line of comment #6. > Here's what I'm proposing: > > diff --git a/eclass/bitcoincore.eclass b/eclass/bitcoincore.eclass > index 5661cb0..c040c34 100644 > --- a/eclass/bitcoincore.eclass > +++ b/eclass/bitcoincore.eclass > @@ -198,7 +198,7 @@ fi > if [ "${BITCOINCORE_NEED_LIBSECP256K1}" = "1" ]; then > BITCOINCORE_COMMON_DEPEND="${BITCOINCORE_COMMON_DEPEND} > $LIBSECP256K1_DEPEND" > fi > -if [ "${PN}" != "libbitcoinconsensus" ] && ! use_if_iuse test; then > +if [ "${PN}" != "libbitcoinconsensus" ]; then > BITCOINCORE_COMMON_DEPEND="${BITCOINCORE_COMMON_DEPEND} > ${UNIVALUE_DEPEND} > >=dev-libs/boost-1.52.0[threads(+)] Ok, the only problem here is the unnecessary dependencies for some ebuilds. Maybe acceptable as a temporary hack.
I would go for eclass variable that's set in ebuild and causes the eclass to add IUSE and dependencies.
(In reply to Michał Górny from comment #13) > I would go for eclass variable that's set in ebuild and causes the eclass to > add IUSE and dependencies. Yeah, but its annoying that one has to manually put in a calculable logic. @luke-jr, if you want to do this then please provide a patch else I'll proceed with the patch comment #11.
(In reply to Anthony Basile from comment #14) > @luke-jr, if you want to do this then please provide a patch else I'll > proceed with the patch comment #11. okay i've pushed this and pkgcore is no longer complaining about use_if_iuse() in the global scope. if you want a better fix propose it in a patch, otherwise this bug is done.
Included a proper fix in https://github.com/gentoo/gentoo/pull/1813
