[12:19] <shadeslayer> hey, can you tell me if Launchpad's arm64 builders are somehow specially configured for large memory allocations when building armhf packages?
[12:36] <cjwatson> shadeslayer: probably depends on exactly what you mean, but they have a modified kernel built with CONFIG_ARM64_VA_BITS=48: https://git.launchpad.net/~wgrant/ubuntu/+source/linux/log/?h=arm64-va-39
[12:37] <shadeslayer> cjwatson: well my cross build on a arm64 machine still fails when ld fails to allocate enough memory
[12:37] <shadeslayer> 00:29:28.719 /usr/bin/ld.gold: fatal error: libQt5WebEngineCore.so.5.7.1: mmap: failed to allocate 2226595652 bytes for output file: Cannot allocate memory
[12:37] <shadeslayer> which is a bit odd since the machine has 128 GB's of memory
[12:37] <cjwatson> don't know more, sorry
[12:37] <shadeslayer> ok :)
[12:37] <shadeslayer> perhaps someone else in the channel will :)
[12:38] <shadeslayer> someone suggested I bump nr_hugepages to 20
[12:38] <shadeslayer> which I've done now to see if it helps
[12:39] <cjwatson> we aren't doing anything like that AFAIK.  The only other specialised arm64ish thing I'm aware of is that we boot the VMs with compat_uts_machine=armv7l (modulo typos, I don't have the current config file to hand).
[12:42] <wgrant> shadeslayer: As Colin says, are kernels are stock xenial plus the patch to unbreak Qt (CONFIG_ARM64_VA_BITS=39, which also reduces the number of page table levels)
[12:42] <wgrant> We've done nothing special to increase address space sizes -- in fact we've shrunk the 64-bit ones.
[12:42] <shadeslayer> aha
[12:43] <shadeslayer> I have CONFIG_ARM64_VA_BITS=48
[12:43] <cjwatson> Yeah, 39, sorry, I misread the git log.
[12:43] <wgrant> That's the default, yeah. It breaks old Qts because they expect to tag their pointers up at like bit 42.
[12:43] <shadeslayer> I see
[12:44] <wgrant> It usually manifests as Qt apps segfaulting, not what you're seeing.
[12:44] <shadeslayer> old qt?
[12:44] <cjwatson> Apparently fixes for that are trickling through to things we might get in updates, so hopefully we can ditch that patch eventually.
[12:44] <wgrant> https://bugreports.qt.io/browse/QTBUG-54822
[12:44] <shadeslayer> tyvm :D
[12:44] <wgrant> But should be totally unrelated.
[12:45] <shadeslayer> right, that's at runtime, but good to know
[12:45] <shadeslayer> I'm more curious about the link failiure
[12:46] <cjwatson> I mean in a 32-bit address space it doesn't necessarily matter how much physical memory you have.
[12:46] <cjwatson> but I'm not sure exactly what you mean by "cross build".
[12:46] <cjwatson> LP doesn't do cross builds.
[12:47] <shadeslayer> oh this isn't on LP
[12:47] <shadeslayer> cjwatson: but then how do you build qtwebengine?
[12:47] <shadeslayer> because afaict https://launchpadlibrarian.net/308759960/buildlog_ubuntu-zesty-armhf.qtwebengine-opensource-src_5.7.1+dfsg-6build1_BUILDING.txt.gz
[12:47] <shadeslayer> https://launchpadlibrarian.net/308759960/buildlog_ubuntu-zesty-armhf.qtwebengine-opensource-src_5.7.1+dfsg-6build1_BUILDING.txt.gz
[12:47] <shadeslayer> er
[12:47] <shadeslayer> Kernel version: Linux bos01-arm64-005 4.4.0-64-generic #85+buildd1-Ubuntu SMP Wed Feb 22 12:26:21 UTC 2017 aarch64
[12:48] <cjwatson> we build in an armhf chroot rather than cross-building.
[12:49] <cjwatson> cross-building usually refers to building with tools from one architecture but generating code to run on another.
[12:49] <cjwatson> in this case we're using armhf throughout, but in a chroot running atop an arm64 base system (and kernel).
[12:50] <shadeslayer> ah ok, that's what I'm doing too, armhf docker container ontop of a arm64 one
[12:50] <shadeslayer> *arm64 host
[13:53] <shadeslayer> it's a bit odd that it compiles just fine on Launchpad but not on my machine
[14:34] <shadeslayer> cjwatson: wgrant JFYI apparently Debian ships the patch to Qt for this
[14:35] <shadeslayer> so maybe you don't need that anymore?
[14:35] <cjwatson> it's making progress, but it needs to be in all series etc.
[14:35] <shadeslayer> *that config option
[14:35] <cjwatson> I think Mirv is looking after that on our side
[14:36] <shadeslayer> ah ok :)
[16:54] <Mc> hi
[16:55] <Mc> just to signal that bots have started posting comments to bug reports that they did not open themselves (i don't recall that happening before in bugs.lp)
[16:55] <Mc> https://launchpad.net/~pop62
[17:00] <Guest949> Launchpad down?
[17:01] <cjwatson> Guest949: it looks OK from here and our graphs seem fine
[17:01] <Guest949> Just came back.
[17:02] <Guest949> I got several "Something went wrong, check twitter or freenode IRC" errors in a row before it came back.
[17:02] <Guest949> i.e., the problem clearly wasn't on my end with my network, given that I got the launchpad error page in my browser.
[17:05] <cjwatson> Mc: doing some cleanup, thanks
[17:08] <Mc> thanks :)
[18:35] <Mc> I'm losing the battle on lp answers spam
[18:36] <Mc> I can find no regexes for my procmailrc to filter out that new spam that asks questions similar to real ones
[18:36] <Mc> It's just too similar to real questions