**** BEGIN LOGGING AT Tue Feb 05 03:00:01 2019 Feb 05 07:24:25 morning Feb 05 07:39:44 Morning! Feb 05 07:39:52 JaMa: Hi, how are things there? Feb 05 07:58:32 getting better :) sorry I wasn't online much Feb 05 08:02:39 JaMa: o/ Feb 05 08:03:05 JaMa: No worries, understand you had other things on your mind Feb 05 08:03:29 BTW new builder can do a full build from scratch in 53 mins :P Feb 05 08:04:27 Just need to setup tmpfs still, any links to instructions would be appreciated Feb 05 08:05:57 BTW there's a small PR in meta-smartphone pending I noticed yesterday when I was checking a few other things Feb 05 08:08:24 wow 53 mins is really nice :) Feb 05 08:12:35 JaMa: I guess with some more tweaking it could be a few mins faster, but not bad at all to start with Feb 05 08:19:54 Herrie|Laptop: what's the current bottleneck ? SSD ? CPU ? Feb 05 08:20:07 (there's always a bottleneck :p ) Feb 05 08:36:08 Tofe: I don't think there's a bottleneck anymore :P Feb 05 08:36:23 QtWebEngine compiling with a single thread :P Feb 05 08:36:29 For the rest I cannot think of much :P Feb 05 08:38:46 m.2 SSD, 128GB RAM, should be quick enough :P Feb 05 08:38:56 GitHub is the bottleneck now :P Feb 05 08:39:17 Or Yocto Git where it takes forever to download and it doesn't use the full speed of my 750/750 connection :P Feb 05 08:40:23 ok :) Feb 05 08:44:13 Let me see how quickly Mako builds Feb 05 08:44:35 Since it shouldn't have to download, but still needs to build quite a lot Feb 05 08:53:48 Herrie|Laptop: was the 53 mins clean without downloads as well? Feb 05 08:54:17 JaMa: 53 mins completely clean Tissot build, so without sstate and tmp-glibc ;) Feb 05 08:54:37 So it needed to download kernel, qtwebengine and all other bits ;) Feb 05 09:32:11 Seems build or Mako was about 50 mins Feb 05 09:32:24 QtWebEngine failed after 46 mins, restarted and image completed in 4 mins Feb 05 09:32:52 that was with populated sstate and tmp-glibc? Feb 05 09:33:15 any why did qtwebengine fail? Feb 05 09:33:23 too-fast-to-build-machine? :) Feb 05 09:37:10 JaMa: I don't have tmpfs setup yet Feb 05 09:37:13 No clue how to do that Feb 05 09:37:21 Internal compiler error I had a few times before Feb 05 09:38:25 JaMa: This was with sstate and tmp-glibc but not for ARMv7, only AARCH64 Feb 05 09:38:47 So it needed to rebuild quite some bits, just some minor packages not and the download wasn't needed anymore Feb 05 09:39:12 Herrie|Laptop: it's probably as simple as mounting a tmpfs for tmp-glibc or something like that, associated with a systematic rm_work task to avoid filling it too much Feb 05 09:39:46 Tofe: Just I have no clue how to do that :P Feb 05 09:40:02 I think the rm_work thing is in local.conf somewhere Feb 05 09:41:23 and mounting tmpfs should be as simple as a "mount -t tmpfs tmp-glibc/ tmp-glibc/", maybe with some options to set a max size Feb 05 09:41:58 you probably have some examples in your fstab Feb 05 09:42:24 Herrie|Laptop: it reused all -native, but they don't count for much, but I guess it would be a bit less if qtwebengine didn't fails and it did more in parallel Feb 05 09:43:33 Herrie|Laptop: if you have long commit interval for the fs used in tmp-glibc, then don't expect much better build time Feb 05 09:43:36 JaMa: I set https://github.com/webOS-ports/webos-ports-setup/commit/346f936b068212165049c7b24457a801ab725735 Feb 05 09:43:42 it's more about saving the SSD wear Feb 05 09:43:42 I guess it doesn't hurt to PR Feb 05 09:43:48 Comes directly from upstream Feb 05 09:44:28 except I don't agree with this as the default Feb 05 09:45:03 if you hit something which will trigger e.g. 64 x 64 gcc processes it will be slower than saner number of BB_NUMBER_THREADS Feb 05 09:45:42 try 8 BB_NUMBER_THREADS and you should get very similar build time, but with much more even load during the build Feb 05 09:46:04 which is useful if you want to be able to do something else while the build is running Feb 05 09:47:23 JaMa: I just took this from upstream, I saw when the patch was submitted there were various opinions on what would be "ideal" Feb 05 09:47:28 I guess it varies from case to case Feb 05 09:47:40 But yes 64 x 64 will not be a lot of fun :P Feb 05 09:48:50 even bitbake worker threads eat quite a lot of memory, so having 64 of them is not ideal when you can use the ram somewhere else (e.g. for 8 x 64 gccs) Feb 05 09:49:54 I have (had) some servers with many cores and only 64GB ram and they were causing OOMK during builds, when this silly default was used Feb 05 09:50:10 JaMa: OK Feb 05 09:50:13 Will reduce it to 8 then Feb 05 09:50:22 Might solve my build failures ;) Feb 05 09:50:23 your ICE during qtwebengine also isn't very healty sign Feb 05 09:50:26 yes Feb 05 09:50:33 did you test your ram already? Feb 05 09:51:10 well first check dmesg for OOMK (it might have killed that gcc resulting in ICE) Feb 05 09:51:24 if that was the case then great, problem solved :) Feb 05 09:51:41 otherwise I would check the ram at least, then temps etc Feb 05 09:51:59 Well CPU gets hot Feb 05 09:52:03 Up to 85c Feb 05 09:52:08 because gcc doesn't ICE randomly even on very beefy systems Feb 05 09:52:45 I guess the Noctua even thoug it's nice and quiet has difficulties handling the heavy loads Feb 05 09:52:51 I should run memtest one night Feb 05 09:53:06 Herrie|Laptop: what TPW has your cpu ? Feb 05 09:53:07 It's running at default speeds so I wouldn't really expect memory issues Feb 05 09:53:52 Tofe: "Default TDP / TDP 250W" Feb 05 09:54:21 that's quite high, but on the other side the 64 x 64 is close to temp torture test like Prime95 :) Feb 05 09:54:27 JaMa: It's proper A-brand 8*16GB kit, so I wouldn't expect issues, but you never know of course ;) Feb 05 09:54:27 TDP yes sorry Feb 05 09:54:35 250W, wow :) Feb 05 09:54:50 Got a 1000W Seasonic PSU just in case :P Feb 05 09:55:00 Fully modular, but comes with 7 years warranty Feb 05 09:55:18 Titanium so pretty good in terms of efficiency Feb 05 09:55:38 Herrie|Laptop: I was returning some faulty kits before (well few years back, but still) Feb 05 09:56:04 Still will have a nice power bill, but got a passively cooled video card and replaced 2 older PC's so I guess in the end the increase should be minimal ;) Feb 05 09:56:09 Maybe even some savings Feb 05 09:56:17 memtest might take more than 1 night for so much memory :) Feb 05 09:57:09 what are you using for virtualization in the end? Feb 05 09:57:24 or is this after reboot to Ubuntu? Feb 05 09:57:55 JaMa: Full time Kubuntu now Feb 05 09:58:01 Seeing how that works out Feb 05 09:58:01 ok Feb 05 09:58:10 18.04 Feb 05 09:59:19 OK trying a clean build now with BB_NUMBER_THREADS to 8 Feb 05 17:09:27 random quote from oe-core ML: "d) running with 256B memory is too low. This shows as the OOM killer" Feb 05 17:11:15 https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg119395.html Feb 05 17:52:07 JaMa: and here goes my ambition of building LuneOS directly on a RPi A... **** ENDING LOGGING AT Wed Feb 06 02:59:57 2019