After 'ebuild pidgin-2.6.5.ebuild unpack', in ${S} we have: -rw-r--r-- 1 portage portage 23K 2009-02-11 03:58 intltool-extract.in -rw-r--r-- 1 portage portage 39K 2009-02-11 03:58 intltool-merge.in -rw-r--r-- 1 portage portage 31K 2009-02-11 03:58 intltool-update.in ... however, after 'ebuild pidgin-2.6.5.ebuild prepare' we now have: -rw-r--r-- 1 portage portage 0 2010-03-03 18:35 intltool-extract.in -rw-r--r-- 1 portage portage 0 2010-03-03 18:35 intltool-merge.in -rw-r--r-- 1 portage portage 0 2010-03-03 18:35 intltool-update.in ... notice that the sizes are all zero. This doesn't manifest itself as a problem until src_install - by this time, the commands: LC_ALL=C ./intltool-merge -d -u -c ./po/.intltool-merge-cache ./po pidgin.desktop.in pidgin.desktop LC_ALL=C ../../intltool-merge -s -u -c ../../po/.intltool-merge-cache ../../po purple.schemas.in purple.schemas ... should have created pidgin.desktop and purple.schemas from pidgin.desktop.in and purple.schemas.in. However, since intltool-merge is also zero bytes in size, nothing is ever output. This causes 'install' to fail, and so causes src_install to fail. This same version of pidgin was installed previously on the same system, so this appears to be a problem with portage or autotools rather than in pidgin itself (or, at the very least, something odd about pidgin which portage/autotools didn't break previously).
FYI, Works for me on amd64-linux, just rebuilt it now. [ebuild R ] net-im/pidgin-2.6.5 USE="gstreamer gtk ncurses nls startup-notification xscreensaver (-aqua) -dbus -debug -doc -eds -gadu -gnutls -groupwise -idn -meanwhile -networkmanager -perl -prediction -qq -sasl -silc -spell -tcl -tk -zephyr -zeroconf" 0 kB
This seems to be due to a change in dev-util/intltool-0.41.0: --- /var/tmp/portage/dev-util/intltool-0.40.6-r1/image/usr/bin/intltoolize +++ /var/tmp/portage/dev-util/intltool-0.41.0/image/usr/bin/intltoolize @@ -33,7 +33,7 @@ # Constants. PROGRAM=intltoolize PACKAGE=intltool -VERSION=0.40.6 +VERSION=0.41.0 # Directory names. prefix=/usr @@ -213,8 +213,11 @@ fi # Touch script names for backward compatibility for script in intltool-extract.in intltool-merge.in intltool-update.in; do - if test -h $script; then rm -f $script; fi - touch $script + # Always remove the script files now + rm -f $script + if egrep $script Makefile.am >/dev/null 2>&1; then + touch $script + fi done done http://bazaar.launchpad.net/~intltool/intltool/trunk/revision/693.1.3 seems to be the corresponding upstrea commit. It claims that we don't use the intltool-foo.in scripts, but at least in the case of pidgin-2.6.5 it's wrong. This might be due to the fact that autoreconf hasn't been called after intltoolize, though. Gentoo calls intltoolize due to bug #282282. That bugs refers to pidgin-2.6.1 being generated with intltool-0.40.6. As far as I can tell, the intltool-*.in scripts in pidgin-2.6.5 were generated using intltool-0.37.1 which should be less broken. pidgin-2.6.6 does ship empty scripts in its tarball, but they have a different configure script which takes care of using intltool scripts installed on the system, and will complain if they aren't found. So I suggest you simply drop the intltoolize call from both pidgin-2.6.5 and pidgin-2.6.6, as bug #282282 shouldn't affect either.
pidgin-2.6.5 compiles successfully for me with the src_prepare() function commented out.
I don't see intltoolize any more in 2.7.8. Is this still an issue there?
