**** BEGIN LOGGING AT Fri Mar 25 02:59:56 2022 Mar 25 12:30:58 khem / rburton: I checked the bitbake-cookerdaemon.log but TBH I have troubles getting any valuable info out of it... I now ran the recipes that were hung one by one and now it seems to go further along for some reason *shrug* Mar 25 12:32:09 you'll need to do live debugging when it has hung Mar 25 12:32:29 as until you can say what recipe hangs, and where it hangs, you can't do anything Mar 25 12:33:30 I am now running into low disk space errors, as I have set TMP_DIR=/tmp (tempfs) @ 28G - which apparently still isn't enough. I have inherit rm_work in my local.conf but it doesnt seem to properly delete everything. Is there a way to manually clean up the TMP_DIR? Mar 25 12:35:10 much easier to create a new tmpfs Mar 25 12:35:26 28gb isn't much though Mar 25 12:35:44 u mean purge the tmp or give more size? Mar 25 12:35:56 both Mar 25 12:36:03 mount it somewhere that isn't /tmp, and make it bigger Mar 25 12:36:12 if you don't have the ram to spare, don't use tmpfs Mar 25 12:36:38 my old builder has 64GB so I had a 32GB tmpfs and that mostly worked with rm_work apart from when it wanted to build a kernel and webkit at the same time Mar 25 12:36:57 stuff like clang has to be built on its own as it uses too much disk Mar 25 12:37:16 rburton: hmm OK - how much should I aim for? I am basically building poky + qt + wayland. My last build with older sources ran through with only 16G tempfs and now its already at 28G x.0 Mar 25 12:37:35 how much ram do you have? Mar 25 12:37:45 64G Mar 25 12:38:11 try with 32gb, double check you have rm_work on, and make sure you only have one PACKAGE_CLASSES enabled Mar 25 12:38:50 but honestly the speed win is marginal Mar 25 12:39:09 to TMP @ NVME? Mar 25 12:39:14 yeah Mar 25 12:39:31 i benchmarked this on my old system Mar 25 12:39:35 cb5r, maybe worth a look: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13843 Mar 25 12:40:00 hmm ok... seemed to be quite a speed improvement to me (subjectively though) Mar 25 12:40:13 tmpfs+rm_work isn't a lot faster than a build on spinning rust with a high commit time (so writes can happen when otherwise idle) Mar 25 12:40:30 Couldn't run actual benchmarks yet coz the build just wont run through yet ^^ Mar 25 12:40:51 if you do lots of incremental builds rm_work is actively bad as it has to rebuild from scratch if you just need to repackage Mar 25 12:41:02 ie add a new RDEPENDS and it has to rebuild, it can't just re-package Mar 25 12:41:31 good point Mar 25 12:41:51 and if you only have 64gb you're throwing away 32gb of disk cache Mar 25 12:42:26 rburton: thats true as well 🙄 Mar 25 12:43:40 is it a good idea to share the TMP_DIR between different revisions or is that a stupid idea? Mar 25 12:50:25 "cb5r, maybe worth a look: https:..." <- Thanks for the link. I don't think it's related though, as my task gets "stuck" using 0% CPU. I can Ctrl+C and get a stacktrace. According to `ps` there is then always 1 bitbake task lingering that I have to kill manually Mar 25 12:52:55 cb5r, i dunno but maybe attaching with gdb and using "py_bt" will give a better clue than ctrl+c and stacktrace Mar 25 13:14:15 cb5r: i wouldn't share tmpdir Mar 25 13:14:54 mainly as tmpdir has a version so if you use different releases with different versions, bitbake will tell you to delete it Mar 25 13:23:35 OK - but going up a few revisions should be fine? It's always the same release, just changes in minor version Mar 25 13:29:21 sure should worl Mar 25 13:29:33 its cross versions which will be bad Mar 25 14:20:44 "its cross versions which will be..." <- you mean yocto release version? Mar 25 14:35:47 between branches, basically Mar 25 15:04:03 Is it not possible to have TMP_DIR on a SSHFS/...? I get errors regarding HOSTTOOLS_DIR now for some reason 🤔 Mar 25 15:23:34 yeah get a samsung EVO 970 Pro 1TB for couple of hundred dollars and your problems are solved Mar 25 15:24:45 build from scratch ( without rm-work) here is 39GB for a simple image ( ofcourse I have clang buidl tree in there ) but you get the idea Mar 25 15:33:47 cb5r: why would you do that? Mar 25 15:34:02 cb5r: you were just trying tmpfs for speed but sshfs will be insanely slow Mar 25 15:36:24 I'm getting like 600 MB/s via the SSHFS (its between VM<>Host) Mar 25 15:36:37 most containers give you a proper way to share Mar 25 15:36:56 insanefs would be better 🙂 Mar 25 15:37:10 I just cant get libvirt virtiofs passthrough to work - its driving me insane Mar 25 15:37:32 why are you building in a VM if you're on linux? Mar 25 15:37:41 coz host is arch Mar 25 15:37:46 see https://github.com/YoeDistro/yoe-distro/blob/master/envsetup.sh#L476-L541 Mar 25 15:37:55 1) plenty of people use arch 2) use a container and bind-mount Mar 25 15:38:12 oh VM not container ? Mar 25 15:39:13 using a VM is overkill, just use a container and save yourself so many problems Mar 25 15:41:35 perhaps take a look at schroot, I still do most of my local builds with it even now that it's less cool compared the newer container hotness Mar 25 15:45:49 I shall look into using docker for yocto then :d I'm pretty new to yocto and often feel completely overwhelmed. So thank you guys, again, for helping me out so much 🙂 Means a lot Mar 25 15:49:04 smurray: definitely less cool 🙂 I have used it occasionally for glibc work on native system, just to not hose my main rootfs Mar 25 15:49:23 with btrfs I might even not worry about that Mar 25 15:54:12 cb5r: yeah I hope keep ploughing along, its a bit daunting initially Mar 25 15:56:28 cb5r: if you're using a modern release of yocto then arch will likely just work Mar 25 15:56:45 What frustrates me the most is that I havent figured out how to "handle" the different directories (tmp, sstate, build, downloads) etc... Somehow I just keep on breaking everything and most of the time need much more time trying to fix it than to just rebuild everything from scratch 😕 Mar 25 15:57:34 keep DL_DIR and SSTATE_DIR somewhere persistent and shared Mar 25 15:57:38 dont worry, reminds me of opening my dad's radio and never being able to put it back 🙂 Mar 25 15:57:41 rburton: dunfell (3.1.7 ... 3.1.14) currently. Also have a project with thud -,- Mar 25 19:16:41 Are there any ARM-based boards available which have open firmware? **** ENDING LOGGING AT Sat Mar 26 02:59:56 2022