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 attachment 182389 [details] smuxi build log
Created attachment 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 attachment 184348 [details, diff] 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.
