 @mitya57 Did you want to do something about QtWebEngine or should I?
 @tsimonq2, I don’t know a solution. But you can try of course, maybe what Lazy suggested.
 Fwd from mitya57: Ok, so our options are:
 Is this still valid?
 Still valid, but no promise it will work :)
 @mitya57, RPL_CONSUMER_TYPE_ERASED_ALWAYS ?
 This is what he suggested, but I never used that.
 I'll upload with `--no-parallel`
 @tsimonq2, that will finish building on ummmmm..... Friday?
 :P
 @acheronuk, Tuesday LO
 *:P
 I vaguely recall launchpad killing webengine builds that used —no-parallel as it thought builds had stalled?
 maybe I misremember, or that was fixed
 Just poked in #launchpad
 I wasn't total time if I recall, but that with only one process, certain parts of the build went so long between output, that LP thought the build had died
 @acheronuk, Yes, it was fixed in https://launchpad.net/ubuntu/+source/qtwebengine-opensource-src/5.9.5+dfsg-0ubuntu2
 @mitya57, 👍
 @tsimonq2, failed with same error
 😕
 @mitya57, odd. build times for amd64 and i386 were quicker, and the arm64 failure came around the same build time (in relative terms), so I wonder if the change Simon did actually had the intened effect?
 I have no experiance with builds that use ninja, so I shrug
 There are 5 commands printed after the failed one, so it is still parallel
 Looks like ninja defaults to parallel, so you need to pass -j1 explicitly to it.
 @mitya57, in export NINJAFLAGS ?
 Is there such a variable?
 @mitya57, that seems to think so? https://salsa.debian.org/qt-kde-team/qt/qtwebengine/blob/experimental/debian/rules#L6
 Oh, right, it is understood not by ninja itself but by `src/core/gn_run.pro` which adds them to ninja commandline
 So `export NINJAFLAGS=-v -j1` will make the build non-parallel, but there is still no promise that it helps.
 @mitya57, Can one of you do it? :)
 (I ask because the earliest I can is in six hours...)