**** BEGIN LOGGING AT Fri Jun 01 03:00:10 2018 Jun 01 08:20:17 cc int matrix[10][10]; matrix[3] = 3; Jun 01 08:20:43 wrong channel Jun 01 08:50:07 problem: after a few months, my CI machine ran out of space Jun 01 08:50:55 reasons: the shared sstate cache dir has grown to 300 GB (hard to justify) + all the packages have accumulated hundreds of logslogs Jun 01 08:51:23 question 1: how can I configure a maximum disk space for the sstate cache? Jun 01 08:51:57 question 2: how can I configure bitbake to automatically remove old logs? Jun 01 08:52:25 s/logslogs/logs/ Jun 01 11:29:16 Hey all! I started playing with yocto with meta-raspberrypi yesterday. What is the proper place to store things like ENABLE_UART or VIDEO_CAMERA when using my own local layer with derived recipes-core/images/core-image-*.bb? IMAGE_INSTALL is taken up from there properly, but these only work when put into build/conf/local.conf... Jun 01 11:31:41 also, am i correct, that, in theory, bitbake should detect changes in these configuration variables and rebuild everything that's needed on the go? right now i need to do `bitbake -c clean rpi-config bcm2835-bootfiles core-image-myproject` first for these to properly rebuild config.txt file in resulting .rpi-sdimg Jun 01 11:33:10 (so far i've only had some experience on buildroot, and i heard some anecdotes, that yocto/bitbake handles rebuilds better :P) Jun 01 11:33:28 s/ on / with / Jun 01 11:34:24 inf: In theory bitbake supports that, if your variable dependencies are set up correctly (or automatically detected correctly) Jun 01 11:39:11 I can live with that, i guess. Maybe sometime later, if i get to learn more about bitbake/yocto, i'd try researching into this further. I'm more concerned about my first issue, though. Jun 01 12:00:02 inf: I guess you're looking for a distro.conf Jun 01 12:10:56 neverpanic: thanks! i'll try that later today Jun 01 13:38:13 lucaceresoli: I use a pretty low-tech solution for sstate: There is a cron job on the server that hosts the sstate cache that deletes it all every friday at 9:30 PM :) Jun 01 13:42:46 JPEW: I see, thanks. I was starting to suspect there sstate has no space-limiter mechanism... Jun 01 13:43:07 JPEW: and I equally suspecting about the deletion of old logs Jun 01 13:43:56 lucaceresoli: Are you using rm_work: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-rm-work ? Jun 01 13:45:19 JPEW: no, I'm not using it. I want to be able to inspect logs and whatever goes wrong, and avoid rebuilding stuff without need Jun 01 13:46:04 rm_work won't affect whether a rebuild happes or not.... but it does make it harder to inspect logs Jun 01 13:47:47 If a build step fails, the main build log contains the output from the step that failed, so as long as you are capturing that, the individual build logs aren't quite as necessary Jun 01 13:49:05 IMHO, it's almost always faster to try and reproduce what a job CI is doing locally than try to debug it "on the server".... Making it easy to reproduce the CI environment is probably much more useful that saving all the build logs Jun 01 13:49:40 Argh, need more coffee, can't type straight Jun 01 13:50:23 JPEW: yup, I could try to enable rm_work on the CI server only -- so far workstations have the same config as the CI server, but perhaps I can make an exception for rm_work Jun 01 13:50:53 Ya, thats what we do. The CI has it's own site.conf that it sets up Jun 01 13:51:20 JPEW: actually I do the same: see the Ci server fail, reproduce locally Jun 01 13:51:33 I would also recommend adding: BB_SCHEDULER = "completion" Jun 01 13:52:12 JPEW: but I don't want to introduce other differences between CI and workstation, unless I'm very sure they won't affect the build result Jun 01 13:52:23 It theortically makes the CI jobs a little slower (which is usually irrelvent), but helps limit the maximum amount of disk space it uses at any one time Jun 01 13:52:23 Sure Jun 01 13:52:55 That makes sense. "rm_work" is probably all you really need Jun 01 13:53:54 JPEW: I can't find BB_SCHEDULER in the docs... :-? Jun 01 13:55:04 https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#var-BB_SCHEDULER Jun 01 13:55:14 The bitbake manual isn't part of the mega-manual Jun 01 14:01:29 JPEW: oh, I thought the mega-manual did. thanks for all the hints. Jun 01 14:01:39 no problem Jun 01 14:08:12 Hello guys ! Jun 01 14:08:45 I'0m building a module which makefile is: https://github.com/emlid/rcio-dkms/blob/master/Makefile Jun 01 14:09:13 while building it searches for KERNEL_SOURCE ?= /lib/modules/$(KVERSION)/build Jun 01 14:09:36 how can I make it point to the right directory ? Jun 01 14:10:43 bitbake exits with the following error: make[1]: *** /lib/modules/4.9.45/build: No such file or directory. Stop. Jun 01 15:30:53 khem: I'm sending patch for that systemd gcc8 issue in a minute https://github.com/systemd/systemd/pull/9156 Jun 01 16:28:56 JaMa: ok, although you might want to call out for it being signed char Jun 01 16:29:04 since char is arch specific Jun 01 22:16:04 New news from stackoverflow: Disable a standard systemd service in Yocto build **** ENDING LOGGING AT Sat Jun 02 03:00:08 2018