The following ebuilds/eclasses are using the almost deprecated gnuconfig_update function from gnuconfig.eclass: ./dev-db/libpq/libpq-7.3.15.ebuild: gnuconfig_update ./dev-db/libpq/libpq-7.4.13.ebuild: gnuconfig_update ./dev-db/libpq/libpq-8.0.8.ebuild: gnuconfig_update ./dev-db/libpq/libpq-7.3.16.ebuild: gnuconfig_update ./dev-db/libpq/libpq-7.4.14.ebuild: gnuconfig_update ./dev-db/libpq/libpq-8.0.9.ebuild: gnuconfig_update ./dev-db/libpq/libpq-8.1.5.ebuild: gnuconfig_update This might be due by various reasons, and some of them cannot be worked around at the current time, so please find your case in the following list: * the ebuild does not use econf, but ./configure, because it uses a very old version of autoconf that does not support the parameters we pass; [1] * the software use config.{guess,sub} although not using autotools, thus econf cannot be used; [1] * the ebuild uses ./configure just for fun; [2] * the ebuild uses ../configure or variants thereof to run a different configure script than the one in the current directory; [3] * the ebuild uses an autogen script or some other autotools-rebuilding script that calls ./configure; [4] * the ebuild calls ./configure because it's doing an inline-build of another package. [1] Then see the procedure to handle this bug: [1] You cannot drop gnuconfig_update, so please leave the bug open, but set the status whiteboard to "Waiting autoepatch". [2] Fix the ebuild, use econf! [3] econf accepts a ECONF_SOURCE variable to tell it to run the configure found in another directory; to run ../configure just use ECONF_SOURCE=".." econf. [4] Fix your autotools with http://www.gentoo.org/proj/en/qa/autofailure.xml adnd then use econf. Once you're using econf, it will take care of updating gnuconfig by itself. Thanks from Diego and Mike
So....what's happening with this? Its almost a year now.
Looked into this a bit more. It looks like we have made some progress atleast :) libpq-7.3.19: Found libpq-7.3.21: Found libpq-7.4.17: Found libpq-7.4.19: Found libpq-8.0.13: Found libpq-8.0.15: Found libpq-8.1.11: Found libpq-8.1.9: Found libpq-8.2.4: Found libpq-8.2.6: One ebuild out of all of them in the tree doesn't have gnuconfig_update in it anymore. Could we go through this list and see what we could prune out (so we don't have as much to fix)? Do we need to keep around all of the older versions in other slots as well?
(In reply to comment #2) > Looked into this a bit more. It looks like we have made some progress atleast > :) > libpq-7.3.19: Found > libpq-7.3.21: Found > libpq-7.4.17: Found > libpq-7.4.19: Found > libpq-8.0.13: Found > libpq-8.0.15: Found > libpq-8.1.11: Found > libpq-8.1.9: Found > libpq-8.2.4: Found > libpq-8.2.6: > One ebuild out of all of them in the tree doesn't have gnuconfig_update in it > anymore. > Could we go through this list and see what we could prune out (so we don't have > as much to fix)? Do we need to keep around all of the older versions in other > slots as well? There is a series of nasty CVE's open against postgresql right now. We're dealing with them on #204760, which is why there's so much activity. 7.4.17, 7.3.19, 8.1.9, 8.2.4 and 8.0.13 are going to be removed as soon as the stabling is done for the sec bug. I've already promised that I'll go through the ebuilds and quench some repoman warnings; to answer your question the ebuilds are calling configure directly. I don't see why they can't use econf. When the GLSA is released for these ebuilds, I'll finish this stuff up too. Thanks, Marty
Done in postgresql-{base,server}
Please leave the bug open till the old ebuilds are gone.
Gone
