Bug 744790 - FTBFS jack-audio-connection-kit-1.9.7-2.fc17
Summary: FTBFS jack-audio-connection-kit-1.9.7-2.fc17
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: jack-audio-connection-kit
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Orcan Ogetbil
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-10 13:18 UTC by Kamil Dudka
Modified: 2011-12-25 21:59 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-25 21:59:26 UTC
Type: ---


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.