Bug#580824: jack-audio-connection-kit: FTBFS on hppa (multiple issues)
On Sun, May 9, 2010 01:05, Dmitrijs Ledkovs wrote: On 9 May 2010 00:44, Adam D. Barratt a...@adam-barratt.org.uk wrote: - waf's parallel building and hppa don't mix; I've stolen a patch which Jakub Wilk provided for xmms2 and applied it to j-a-c-k. It will break if anything causes the .waf.-* directory to be renamed, but that seems like another reason not to use waf ;-) Running waf with -j1 flag should stop all paralelism. e.g. ./waf configure build -j1 Is this not enough to make waf behave on hppa? From what I could see from reading the code, the number of jobs should automatically default to the number of available CPUs in any case, so should automatically be 1 at least on the porter box. However, assuming that adding the following to debian/rules would implement your suggestion, then sadly no it does not appear to be enough: waf-configure-options += $(if $(filter hppa,$(DEB_HOST_ARCH)),-j1) Even with this change, the ./waf configure call hangs after outputting Checking for dbus-1 = 1.0.0 : ok Checking for dbus-1 flags: ok Checking for header expat.h : ok I killed it after 15 minutes of inactivity; the build output shows that -j1 was passed to the configure call. If I add the Runner.py patch instead, it gets past that point with ease (and later fails with the second error I mentioned, which is trivially fixable by adding !defined(__hppa__) to an existing patch). Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580824: jack-audio-connection-kit: FTBFS on hppa (multiple issues)
On 9 May 2010 08:05, Adam D. Barratt a...@adam-barratt.org.uk wrote: On Sun, May 9, 2010 01:05, Dmitrijs Ledkovs wrote: On 9 May 2010 00:44, Adam D. Barratt a...@adam-barratt.org.uk wrote: - waf's parallel building and hppa don't mix; I've stolen a patch which Jakub Wilk provided for xmms2 and applied it to j-a-c-k. It will break if anything causes the .waf.-* directory to be renamed, but that seems like another reason not to use waf ;-) Running waf with -j1 flag should stop all paralelism. e.g. ./waf configure build -j1 Is this not enough to make waf behave on hppa? From what I could see from reading the code, the number of jobs should automatically default to the number of available CPUs in any case, so should automatically be 1 at least on the porter box. However, assuming that adding the following to debian/rules would implement your suggestion, then sadly no it does not appear to be enough: waf-configure-options += $(if $(filter hppa,$(DEB_HOST_ARCH)),-j1) Even with this change, the ./waf configure call hangs after outputting Checking for dbus-1 = 1.0.0 : ok Checking for dbus-1 flags : ok Checking for header expat.h : ok I killed it after 15 minutes of inactivity; the build output shows that -j1 was passed to the configure call. If I add the Runner.py patch instead, it gets past that point with ease (and later fails with the second error I mentioned, which is trivially fixable by adding !defined(__hppa__) to an existing patch). Regards, Adam Can you please run it as (without any patches) ./waf -vvv -j1 And send me buildlog please? This is quite disturbing. I'm a waf lover =) and have submitted a few patches upstream. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580824: jack-audio-connection-kit: FTBFS on hppa (multiple issues)
Package: jack-audio-connection-kit
Version: 1.9.5~dfsg-12
Severity: serious
Tags: patch
Hi,
j-a-c-k FTBFS on hppa. While some of the issues may be buildd related,
some of them aren't; the good news is that I believe I've fixed them. :-)
(at least, I've successfully built j-a-c-k on the hppa porter box)
There are two issues:
- waf's parallel building and hppa don't mix; I've stolen a patch which
Jakub Wilk provided for xmms2 and applied it to j-a-c-k. It will break if
anything causes the .waf.-* directory to be renamed, but that seems like
another reason not to use waf ;-)
- the alpha/ia64 segv fix patch also needs to include hppa in its
growing list of architectures on which not to execute the relevant code;
the patch probably also wants renaming :-)
I've attached a new patch to fix the first; I assume the second is trivial
enough not to need a patch.
I'd appreciate an upload containing these changes so that we can hopefully
finally get j-a-c-k built on all architectures which are relevant for
testing migration.
Regards,
AdamDescription: Disable parallel build on hppa architecture.
Origin: http://code.google.com/p/waf/source/browse/tags/waf-1.5.0/playground/serial.py
--- a/.waf-1.5.0-8e39a4c1c16303c1e8f010bf330305f6/wafadmin/Runner.py
+++ b/.waf-1.5.0-8e39a4c1c16303c1e8f010bf330305f6/wafadmin/Runner.py
@@ -143,3 +143,100 @@ class Parallel(object):
self.consumers=[TaskConsumer(self)for i in xrange(self.numjobs)]
assert(self.count==0 or self.stop)
+class Serial(object):
+
+ def __init__(self, bld, j=1):
+ self.manager = bld.task_manager
+ self.outstanding = []
+
+ # progress bar
+ self.total = self.manager.total()
+ self.processed = 0
+ self.error = 0
+
+ self.switchflag = 1 # postpone
+
+ self.consumers = None
+
+ # warning, this one is recursive ..
+ def get_next(self):
+ if self.outstanding:
+ t = self.outstanding.pop(0)
+ self.processed += 1
+ return t
+
+ # handle case where only one wscript exist
+ # that only install files
+ if not self.manager.groups:
+ return None
+
+ (_, self.outstanding) = self.manager.get_next_set()
+ if not self.outstanding: return None
+
+ return self.get_next()
+
+ def postpone(self, tsk):
+ self.processed -= 1
+ self.switchflag *= -1
+ # this actually shuffle the list
+ if self.switchflag0: self.outstanding.insert(0, tsk)
+ else: self.outstanding.append(tsk)
+
+ def start(self):
+ debug('runner: Serial start called')
+ while 1:
+ # get next Task
+ tsk = self.get_next()
+ if tsk is None: break
+
+ if Logs.verbose: debug('runner: retrieving %r' % tsk)
+
+ st = tsk.runnable_status()
+ if st == ASK_LATER:
+debug('runner: postponing %r' % tsk)
+self.postpone(tsk)
+continue
+
+ #continue
+ if st == SKIP_ME:
+tsk.hasrun = SKIPPED
+self.manager.add_finished(tsk)
+continue
+
+ tsk.position = (self.processed, self.total)
+
+ # display the command that we are about to run
+ tsk.generator.bld.printout(tsk.display())
+
+ # run the command
+ if tsk.__class__.stat: ret = tsk.__class__.stat(tsk)
+ else: ret = tsk.run()
+ self.manager.add_finished(tsk)
+
+ # non-zero means something went wrong
+ if ret:
+self.error = 1
+tsk.hasrun = CRASHED
+tsk.err_code = ret
+if Options.options.keep: continue
+else: return -1
+
+ try:
+tsk.post_run()
+ except OSError:
+self.error = 1
+tsk.hasrun = MISSING
+if Options.options.keep: continue
+else: return -1
+ else:
+tsk.hasrun = SUCCESS
+
+ if self.error:
+ return -1
+
+import subprocess
+p = subprocess.Popen(['dpkg', '--print-architecture'], stdout=subprocess.PIPE)
+arch = p.stdout.read().strip()
+p.wait()
+if arch == 'hppa':
+ Parallel = Serial
Bug#580824: jack-audio-connection-kit: FTBFS on hppa (multiple issues)
On 9 May 2010 00:44, Adam D. Barratt a...@adam-barratt.org.uk wrote: - waf's parallel building and hppa don't mix; I've stolen a patch which Jakub Wilk provided for xmms2 and applied it to j-a-c-k. It will break if anything causes the .waf.-* directory to be renamed, but that seems like another reason not to use waf ;-) Running waf with -j1 flag should stop all paralelism. e.g. ./waf configure build -j1 Is this not enough to make waf behave on hppa? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
