[08:24] <lubot> <tsimonq2> @mitya57 Did you want to do something about QtWebEngine or should I?
[09:39] <lubot> <mitya57> @tsimonq2, I don’t know a solution. But you can try of course, maybe what Lazy suggested.
[09:39] <lubot> <tsimonq2> Fwd from mitya57: Ok, so our options are:
[09:39] <lubot> - try --no-parallel / -j1
[09:39] <lubot> - force another compiler (older gcc?)
[09:39] <lubot> - try with different compiler options
[09:39] <lubot> - ask doko or on ubuntu-devel@
[09:39] <lubot> <tsimonq2> Is this still valid?
[09:40] <lubot> <mitya57> Still valid, but no promise it will work :)
[09:47] <lubot> <acheronuk> @mitya57, RPL_CONSUMER_TYPE_ERASED_ALWAYS ?
[10:00] <lubot> <mitya57> This is what he suggested, but I never used that.
[10:00] <lubot> <tsimonq2> I'll upload with `--no-parallel`
[10:14] <lubot> <acheronuk> @tsimonq2, that will finish building on ummmmm..... Friday?
[10:14] <lubot> <acheronuk> :P
[10:15] <lubot> <tsimonq2> @acheronuk, Tuesday LO
[10:15] <lubot> <tsimonq2> *:P
[10:16] <lubot> <acheronuk> I vaguely recall launchpad killing webengine builds that used —no-parallel as it thought builds had stalled?
[10:17] <lubot> <acheronuk> maybe I misremember, or that was fixed
[10:17] <lubot> <tsimonq2> Just poked in #launchpad
[10:18] <lubot> <acheronuk> 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
[10:26] <lubot> <mitya57> @acheronuk, Yes, it was fixed in https://launchpad.net/ubuntu/+source/qtwebengine-opensource-src/5.9.5+dfsg-0ubuntu2
[10:27] <lubot> <acheronuk> @mitya57, 👍
[15:34] <lubot> <acheronuk> @tsimonq2, failed with same error
[15:34] <lubot> @mitya57
[15:48] <lubot> <mitya57> 😕
[15:52] <lubot> <acheronuk> @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?
[15:54] <lubot> <acheronuk> I have no experiance with builds that use ninja, so I shrug
[16:06] <lubot> <mitya57> There are 5 commands printed after the failed one, so it is still parallel
[16:07] <lubot> <mitya57> Looks like ninja defaults to parallel, so you need to pass -j1 explicitly to it.
[16:18] <lubot> <acheronuk> @mitya57, in export NINJAFLAGS ?
[16:20] <lubot> <mitya57> Is there such a variable?
[16:21] <lubot> <acheronuk> @mitya57, that seems to think so? https://salsa.debian.org/qt-kde-team/qt/qtwebengine/blob/experimental/debian/rules#L6
[16:21] <lubot> <mitya57> Oh, right, it is understood not by ninja itself but by `src/core/gn_run.pro` which adds them to ninja commandline
[16:22] <lubot> <mitya57> So `export NINJAFLAGS=-v -j1` will make the build non-parallel, but there is still no promise that it helps.
[20:03] <lubot> <tsimonq2> @mitya57, Can one of you do it? :)
[20:07] <lubot> <tsimonq2> (I ask because the earliest I can is in six hours...)