Bug 744790

Summary:	FTBFS jack-audio-connection-kit-1.9.7-2.fc17
Product:	[Fedora] Fedora	Reporter:	Kamil Dudka <kdudka>
Component:	jack-audio-connection-kit	Assignee:	Orcan Ogetbil <oget.fedora>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	brendan.jones.it, green, oget.fedora
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-12-25 21:59:26 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Kamil Dudka 2011-10-10 13:18:34 UTC

Description of problem:
The build tends to hang on executing the following step:
+ ./waf configure --mandir=/share/man/man1 --libdir=/lib64 --doxygen --dbus --classic --firewire --freebob --alsa


Version-Release number of selected component (if applicable):
jack-audio-connection-kit-1.9.7-2.fc17


Steps to Reproduce:
1. koji build --scratch f17 'git://pkgs.fedoraproject.org/jack-audio-connection-kit?#HEAD'

  
Actual results:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3419311

Comment 1 Orcan Ogetbil 2011-10-11 00:57:25 UTC

Are we sure this is a bug in the package but not in the compiler? It seems to hang in the tests run by the configuration script. Moreover, it seems to not hang on x86_64. I have to take a closer look though.

Comment 2 Kamil Dudka 2011-10-11 04:57:57 UTC

(In reply to comment #1)
> Are we sure this is a bug in the package but not in the compiler?

Which compiler?  The only processes I can see in the tree are controlled by python.  None of the is actually using the CPU.

> Moreover, it seems to not hang on x86_64.

I tried it 8 times on x86_64 and it always ended up hanging.  The fact that it passed on x86_64 in Koji must have been an accident.

Comment 3 Orcan Ogetbil 2011-10-11 11:43:52 UTC

(In reply to comment #2)
> (In reply to comment #1)
> > Are we sure this is a bug in the package but not in the compiler?
> 
> Which compiler?  The only processes I can see in the tree are controlled by
> python.  None of the is actually using the CPU.
> 

Okay thank you for the information. That was my initial guess since it hangs in the beginning of the waf commmand. It most probably invokes the compiler (gcc) for its tests the same way when you the "configure" scripts do in autotools projects.

I'll take a look when I get a chance. So far, the only difference that I know between F-15 (where it doesn't hang) and F-17 (where it hangs) is
- python-2.7.1 -> 2.7.2
Is there any other significant change that you know?


> > Moreover, it seems to not hang on x86_64.
> 
> I tried it 8 times on x86_64 and it always ended up hanging.  The fact that it
> passed on x86_64 in Koji must have been an accident.

Interesting. Here on my computer I am lucky enough to have accidents whenever I try then.

Comment 4 Kamil Dudka 2011-10-11 13:14:31 UTC

(In reply to comment #3)
> Interesting. Here on my computer I am lucky enough to have accidents whenever I
> try then.

Good point.  If I run the build in mock on a Fedora host, it passes.  If I run the build in mock on a RHEL-6 host using the same mock profile, it hangs.  I wonder if the problem is triggered by the difference in kernels being used.

Comment 5 Orcan Ogetbil 2011-12-25 21:59:06 UTC

After some F-16 update, I started observing the hang on my box too. 

I tried passing a '-j1' argument to 'waf configure' and it stopped the hanging on my side, also on koji. I am marking this workaround as a fix. Please reopen if you find a better fix.