Bugzilla Bug 259434

Smuxi never finishes compiling.  It just goes into and infinite loop.

Reproducible: Always

Steps to Reproduce:
emerge smuxi

Actual Results:  
The following instructions repeat endlessly:

make[1]: Entering directory
`/tmp/portage/net-irc/smuxi-0.6.3/work/smuxi-0.6.3/po-Engine'
cd .. \
          && CONFIG_FILES=po-Engine/Makefile.in CONFIG_HEADERS= CONFIG_LINKS= \
               /bin/sh ./config.status
config.status: creating po-Engine/Makefile.in
config.status: executing depfiles commands
config.status: executing po-directories commands
config.status: creating po-Engine/POTFILES
config.status: creating po-Engine/Makefile
config.status: executing po/stamp-it commands
# INTLTOOL_MAKEFILE
make[1]: Leaving directory
`/tmp/portage/net-irc/smuxi-0.6.3/work/smuxi-0.6.3/po-Engine'


Expected Results:  
successful emerge of smuxi

Could you attach the build.log with a couple of iterations of this loop (
CTRL+C to stop it ) and emerge --info.

https://bugs.launchpad.net/ubuntu/+bug/259833 has a reproducer who's not using
gentoo.

Created an attachment (id=182389) [details]
smuxi build log

Created an attachment (id=182391) [details]
emerge --info

This is _quite_ an issue indeed. Masking?

Per IRC log pasted below, can all reproducers of this problem tell me if their
/tmp is tmpfs?

<meebey> loki_val: ping
<loki_val> meebey: pong
<meebey> loki_val: http://www.lucas-nussbaum.net/blog/?p=335
<meebey> loki_val: does that apply to you? /tmp being tmpfsß
<loki_val> I know it applies to one reporter. I haven't been able to reproduce
<meebey> do you use tmpfs?
<loki_val> No.
<meebey> k
<meebey> please ask the repoert
<meebey> reporter
<meebey> if his /tmp is tmpfs
<meebey> to check if this is triggering the issue
<meebey> I could temporarly make my /tmp tmpfs
<meebey> and build smuxi and check what happens
<meebey> to get a second sample
<loki_val> Can do.

[No need to CC me, I'm on qa@, otherwise I would have CCed me in the first
place ;)]

I just read Lucas's blog post myself. While I do know the problem of
granularity I did not think it would move stuff around between different
filesystems. Yes my system is configured with /tmp in tmpfs and $PORT_TMPDIR in
ext4.

I guess setting TMPDIR="${T}" could be a workaround, if it does respect that;
or try to rebuild with a newer autoconf?

Created an attachment (id=184348) [details]
eutoreconf comes to the rescue

Does this patch fix the problem?

The patch does not fix the issue for me.

/tmp is not tmpfs on my machine.

Have to test with the next tinderbox run.

Forgot to say earlier that the sub-second timestamp is also available on XFS,
and maybe other filesystems, not just tmpfs.

(In reply to comment #11)
> Have to test with the next tinderbox run.
> 
> Forgot to say earlier that the sub-second timestamp is also available on XFS,
> and maybe other filesystems, not just tmpfs.
> 

I am using XFS so that could be the issue.

Could someone try this:
<meebey> loki_val: apropros masked, can you reproduce the smuxi build issue?
<meebey> loki_val: I made some changes in the master branch and wonder if those
are fixing it
<loki_val> meebey: I can't reproduce but if you have a patch, I can poke
someone at our bug.
<meebey> loki_val: let them build git://git.qnetp.net/smuxi.git branch:
bug/autofool
You can get a snapshot here:
http://git.qnetp.net/?p=smuxi.git;a=shortlog;h=refs/heads/bug/autofool
It should be as simple as installing the dependencies for smuxi and doing
./autogen.sh
./configure
make

+  05 Apr 2009; Peter Alfredsen <loki_val@gentoo.org>
+  +files/smuxi-0.6.3-infinite-loop.patch, smuxi-0.6.3.ebuild:
+  Fix bug 259434, smuxi enters an infinite loop when compiling on
+  milli-second-precision FSes, suchs as tmpfs or XFS.
+

Upstream was able to reproduce. This should fix it.