**** BEGIN LOGGING AT Tue Jun 11 03:00:01 2019 Jun 11 05:42:57 * Tofe did ;) Jun 11 06:51:22 JaMa: this testing build being quite good, we could drop let's say all the previous testing images but one Jun 11 06:51:40 (the next testing build of course will be even better) Jun 11 11:21:52 morning Jun 11 11:22:06 jenkins is catching-up, pinephone should be in few hours :) Jun 11 11:23:17 JaMa: there's no hurry :) Jun 11 11:23:35 The testing image I uploaded contained already the nyx-module fix Jun 11 11:23:53 (that's the only difference) Jun 11 11:27:23 Tofe: I want to verify my jenkins-job changes :) Jun 11 11:27:44 that's pretty much the only reason why I care and hurry :) Jun 11 17:00:38 powermenu now works again Jun 11 17:01:16 for me, that testing build is elligible for next stable... of course there are still some LS2 errors, but I don't see the userside consequence so far Jun 11 17:01:32 Herrie: ^ any opinion? Jun 11 20:28:45 heh, lucky me OSError: [Errno 28] No space left on device Jun 11 20:28:51 http://jenkins.nas-admin.org/job/LuneOS/job/luneos-testing_pinephone/12/console Jun 11 20:29:51 I don't know what's so big, but qemux86, qemux86-64 and pinephone don't fit in the same 80G tmpfs (even when qemux86* builds were really small this time) Jun 11 20:32:26 not so long ago we were doing rpi2, rpi3, rpi3-64 in the same tmpfs just after qemu* builds Jun 11 20:32:46 I've moved it to it's own build group with rpi3-64 Jun 11 21:11:23 JaMa: none of the 3 share the same arch, like rpi2 and rpi3 did Jun 11 21:11:44 ==> 3x(mesa + llvm + qtbase + qtwebengine) Jun 11 21:12:33 though, this time, there was nearly nothing to rebuild Jun 11 21:15:10 but... I don't quite understand: why did it rebuild everything for pinephone? last time it succeeded, so we should have almost all sstate already Jun 11 21:16:56 it didn't succeed in the previous build, it failed due to disk space as well Jun 11 21:17:54 Tofe: before it did 4 archs (x86, x86_64, cortexa7, aarch64-rpi) in the same tmpfs, now it doesn't fit (x86, x86_64, aarch64-pine) Jun 11 21:18:43 mmh Jun 11 21:18:52 I was suspecting wic/wic.bmap, but it failed long before that, so either qemux86* builds are using more tmpfs with left-over files or something is really big in pine build Jun 11 21:19:22 actually it should show tmpfs space before the build was started, let me check Jun 11 21:19:22 and before, we already had llvm? Jun 11 21:19:58 in qemu yes Jun 11 21:20:09 none 80G 0G 80G 0% /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc Jun 11 21:20:13 none 80G 0G 80G 0% /home/jenkins/workspace/luneos-stable/webos-ports/tmp-glibc Jun 11 21:20:15 none 80G 28G 53G 35% /home/jenkins/workspace/luneos-testing/webos-ports/tmp-glibc Jun 11 21:20:24 there was 53G tmpfs free when it started, it should be enough Jun 11 21:20:59 definitely enough to build llvm+mesa (qtwebengine couldn't even start do_configure before it failed) Jun 11 21:21:20 I have a pinephone build locally; let me do a "du" Jun 11 21:21:52 (without any rm_work) Jun 11 21:24:49 https://bpaste.net/show/99e914c4f0a4 fwiw Jun 11 21:25:42 I'll try to have more detail per-recipe Jun 11 21:29:28 JaMa: https://bpaste.net/show/5de934d83856 tadaa Jun 11 21:30:10 llvm + llvm-native = 41G Jun 11 21:30:43 is llvm compile with -g, or what ?... Jun 11 21:30:47 compiled* Jun 11 21:33:43 4.9G ./packages-split/llvm-staticdev Jun 11 21:34:03 I wonder if that's really useful Jun 11 21:35:37 ok, that explains it, 80G should be enough in next run Jun 11 21:37:28 JaMa: and it's normal that just the compiler takes this big ? Jun 11 21:42:33 normal for llvm, yes **** ENDING LOGGING AT Wed Jun 12 03:00:27 2019