digifuzzy Posted January 11, 2015 Report Share Posted January 11, 2015 Need a little clarification, please? FL-1949 was closed with a workaround. However the outstanding question is why giflib is looking for automake-1.13 and 1.15, but not 1.14? Is 1.14 being masked as well? (see other post changes to automake with last emerge Link to comment Share on other sites More sharing options...
0 digifuzzy Posted January 12, 2015 Author Report Share Posted January 12, 2015 I think I got a partial answer... I was having issues not related to bug report. I was emerging a non-bin version of firefox when I got the error message: * Done with patching * Running eautoreconf in '/var/tmp/portage/www-client/firefox-34.0.5-r1/work/mozilla-release' ... * This package has a configure.in file which has long been deprecated. Please * update it to use configure.ac instead as newer versions of autotools will die * when it finds this file. See https://bugs.gentoo.org/426262 for details. A quick look at the bug autotools/autotools-utils eclasses should rename configure.in to configure.ac internally (automake-1.14 compatibility) leads me to believe that automake-1.14 changes things...but it was working for me? Why 1.14 was downgrade is beyond me and I really wish someone could explain this, please? automake 1.14 is still available in the tree, but packages are expressly not looking for it? (see link to post above) Link to comment Share on other sites More sharing options...
Question
digifuzzy
Need a little clarification, please?
FL-1949 was closed with a workaround.
However the outstanding question is why giflib is looking for automake-1.13 and 1.15, but not 1.14?
Is 1.14 being masked as well? (see other post changes to automake with last emerge
Link to comment
Share on other sites
1 answer to this question
Recommended Posts