[06:53] <tsimonq2> mitya57: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3291/+build/15121400 qtwebengine is FTBFS on arm64 in the PPA.
[07:21] <mitya57> Oh, internal compiler error :(
[07:21] <lubot> <tsimonq2> I retried, I'm hoping it's just a one time thing
[07:21] <lubot> <acheronuk> (Document) http://vps.tsimonq2.net//file_4032.gz
[07:21] <lubot> <tsimonq2> Rik has the log
[07:21] <lubot> <tsimonq2> You can see it in Telegram; I dunno if my bridge works with files anymore properly
[07:22] <lubot> <mitya57> I had the log too :)
[07:22] <lubot> <tsimonq2> Ah cool
[07:22] <lubot> <mitya57> But the bridge does not seem to work, http://vps.tsimonq2.net//file_4032.gz → 404
[07:23] <lubot> <acheronuk> I also set it rebuilding in a seperate PPA
[07:23] <lubot> <tsimonq2> @mitya57, Right
[07:23] <lubot> <acheronuk> A quick google seemed to suggest maybe out of memory/swap for similar errors, but google could be wrong
[07:24] <lubot> <acheronuk> and I don't know enough about building this to judge
[07:24] <lubot> <mitya57> Out of memory usually happens during linking phase, but here it died compiling a single C++ file (`render_frame_devtools_agent_host.cc`)
[07:26] <lubot> <acheronuk> https://medium.com/hi-z-labs/yocto-qt5-b2qt-build-fails-on-qtlocation-or-qtwebengine-with-cryptic-gcc-error-1051a7effe3a
[07:27] <lubot> <mitya57> OK :)
[07:27] <lubot> <acheronuk> that failed on compiling render_frame_host_manager.cc
[07:28] <lubot> <mitya57> If it is a memory issue then using --no-parallel may help.
[07:29] <lubot> <acheronuk> that would take how many days to build? :P
[07:30] <lubot> <tsimonq2> @mitya57, Let's see if it's erraneous and builds on this next go. If it doesn't build, then let's do that.
[07:31] <lubot> <acheronuk> you have it building in ci-train. I have a build going in a private ppa. so by this evening we should see the result of those
[07:31] <lubot> <tsimonq2> True.
[07:33] <lubot> <mitya57> [Normal build](https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3237-deletedppa/+build/14765245) (with -j4) took 12 hours, so -j1 would take just two days :)
[07:33] <lubot> <acheronuk> urgh
[12:35] <lubot> <acheronuk> @mitya57 FTBFS on same render_frame_devtools_agent_host again
[12:36] <lubot> <acheronuk> same on my other ppa build
[12:37] <lubot> <mitya57> Ok, so our options are:
[12:37] <lubot> - try --no-parallel / -j1
[12:37] <lubot> - force another compiler (older gcc?)
[12:37] <lubot> - try with different compiler options
[12:37] <lubot> - ask doko or on ubuntu-devel@
[12:37] <lubot> <acheronuk> either that is a real kill point on mem usage, or there as you suggested is more to it than just that
[12:44] <lubot> * acheronuk tries Neon's packaging for the hell of it
[12:45] <lubot> <acheronuk> more for curiosity than anything else, and on an out the way ppa
[14:06] <lubot> <Lazy B> (Photo, 477x71) https://i.imgur.com/DwbJcBl.jpg
[14:06] <lubot> <Lazy B> (Photo, 732x173) https://i.imgur.com/l0hgJZM.jpg
[14:07] <lubot> <Lazy B> RPL_CONSUMER_TYPE_ERASED_ALWAYS macro instructs gcc to use less memory
[14:07] <lubot> <Lazy B> Compilation time will be (almost) not affected
[14:17] <lubot> <Lazy B> It's also possible to use -g1 glag to generate less debuging information
[14:25] <lubot> <Lazy B> But rather to disable it if it's enabled
[16:59] <lubot> <mitya57> @Lazy B, I think our qtwebengine has all debugging disabled already.