I recently stumbled upon this bug when coreutils-5.2.1-r7 refused to install on my machine (see bug 120616). I have TIME_STYLE set to long-iso, as the american date representation seems really awkward to my non-american eyes. As a result of this, GNU ls now outputs something automake's mdate-sh script is not expecting, causing mdate-sh to go on an infinite loop, and the emerge process hanging on something like: make[1]: Entering directory `/var/tmp/portage/libtool-1.5.22/work/libtool-1.5.22/doc' with sh hogging 100% of cpu - you should see this happening if you do TIME_STYLE=long-iso emerge =sys-devel/libtool-1.5.22 The bug in automake is examined at http://lists.nongnu.org/archive/html/bug-findutils/2005-06/msg00031.html, and it seems to be fixed in the 1.9-branch of automake. As an easy workaround, doing a 'unset TIME_STYLE' before emerging resets ls's behaviour to the one expected by mdate-sh. There are still packages depending on older versions of automake, such as libtool-1.5.22 (the latest stable on x86), which now fail to build if someone happens to set TIME_STYLE for the user running portage. This is probably a rare case (or at least no-one else has filed a bug for this), so if you think the workaround should not be incorporated into portage, feel free to close this bug as a WONTFIX. At least now someone experiencing this bug can find the workaround here.
hmm, yet another excellent reason for autopatching autotool files ...
The same thing happens with a2ps. Again I wasted more time before I remembered this... This bug is really fun to identify as the build process simply stalls without any error messages or informative messages. Bumping severity to 'normal' because of this. Any news on getting this fixed? Can packages using old automake be modified to use a newer version, or should portage manually unset TIME_STYLE to the default setting?
A very old bug, and I've stumbled upon this several times! Just now I figured the right words for Google to find me this. I've been killing the mdate.sh *.texi processes, which usually allowed the emerge process to continue, but not when emerging automake:1.6. I have TIME_STYLE set because the default "locale" messes up whitespaces in output of 'ls -l'. The workaround, unsetting TIME_STYLE fixes this hanging indeed. Is a real fix planned? Cheers! - Ville
a real fix is already done: automake was long ago patched + released and newer packages regenerated with newer automake.
There may be fixes, but I'm still occasionally hit by this bug, probably because some packages depend on automake at an older version slot. Currently, for example sys-process/time-1.7-r1 is hit by this bug (this is not the only one, but don't remember currently which other packages I've encountered recently). The emerge hangs at process "mdate-sh ./time.texi" in an indefinite loop. To reproduce: TIME_STYLE=long-iso" emerge -1 sys-process/time. (as a workaround, remove the work dir as something has been misconfigured and set TIME_STYLE="locale"). Please reopen until the fix has been backported to all automake slot versions currently in use?
Hi! I'm still hit by this bug - on a new, fresh Gentoo x86_64 install while merging app-text/texi2html-5.0-r1! It's quite annoying to find your 400+ package merge has hanged in an indefinite loop because of this! The hanging script is mdate-sh; I'm not sure but in this case it might bundled by texi2html (although it is an automake script, so there's maybe the same hanging script but it might not be automake's bug... and an ebuild should not include external scripts in this way?). Should I file a bug against texi2html instead? To reproduce: 1) set locale to something with non-US style incompatible with the script, e.x. fi_FI.UTF-8 2) make sure TIME_STYLE=locale (I think it was the default since I don't recall changing it, but I could have) 3) merge texi2html To work around: `TIME_STYLE=long-iso merge -1 texi2html` (or another offending package if any exists)
