Launchpad itself

Unsufficient memory for Qt packaging

Asked by Stephan Binner

I cannot package QtWebKit and Qt3D anymore as builds fail with "virtual memory exhausted: Cannot allocate memory", eg https://launchpad.net/~beineri/+archive/ubuntu/opt-qt55-trusty/+builds?build_text=&build_state=failed

I suspect you decreased available memory available to the build hosts in last months as previously successful building packages now also fail to build when retriggered without changes, see https://launchpad.net/~beineri/+archive/ubuntu/opt-qt541-trusty/+builds?build_text=wk54&build_state=all

So I would like to ask you to re-increase available memory to builds of at least my following projects:

  opt-qt542
  opt-qt542-trusty
  opt-qt55
  opt-qt55-trusty

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Solved by:
Stephan Binner
Solved:
Last query:
Last reply:
Revision history for this message
Colin Watson (cjwatson) said : 		#1

We don't currently have the ability to do this on a per-PPA basis, so more available memory would mean fewer builders for everyone. I'd like to explore other options first.

Looking at https://launchpadlibrarian.net/208613110/buildlog_ubuntu-trusty-amd64.wk54_5.4.1-1basyskom2_BUILDING.txt.gz, for example, there are 120 matches for "Killed" in the build log. This is very peculiar, as normally make would stop each of its job runners after a failure. 120 killed g++ processes implies that you're running with the equivalent of "make -j120" or greater, but that's many more CPUs than are available here and is a completely unreasonable amount of parallelism to attempt. That number of concurrent g++ processes would certainly explain running out of virtual memory and invoking the OOM killer.

Now, I do in fact know why this is happening here. It's a combination of a bug in launchpad-buildd and a bug in your build system. The first problem is that for a few weeks we've incorrectly not been passing DEB_BUILD_OPTIONS=parallel=* down to your package's build environment; I committed a fix for this a few days ago, and we'll be rolling it out soon. The second problem is that your package reacts extremely badly to not having DEB_BUILD_OPTIONS=parallel=* in its environment, due to this code in debian/rules:

override_dh_auto_build:
        make -j$(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) # CXX='g++ -g'

If DEB_BUILD_OPTIONS is missing, then this will degrade to "make -j": that is, unlimited parallelism. There's no way that will behave sensibly on just about any hardware. Instead, you should add the --parallel option to the end of the "dh" command in your "%" rule, and delete the override_dh_auto_build rule entirely. If you do that, it will work properly, albeit slower, even before we roll out the fixed buildd code.

Revision history for this message
Stephan Binner (beineri) said : 		#2

Thanks for quick response.