**** BEGIN LOGGING AT Mon Mar 14 02:59:58 2016 Mar 14 07:54:44 morning Mar 14 08:17:12 morning Mar 14 14:08:03 Herrie: ping Mar 14 14:08:37 Andolamin: pong Mar 14 14:11:12 Herrie|Veer: There's something odd going on with the Pi 3 builds. I'm going to open a PR to webos-ports-setup to add support for Pi 2 but it might take a bit to figure out the Pi 3 Mar 14 14:13:11 ok Mar 14 14:13:40 Well once you have a device that means more incentive right :P Mar 14 14:14:54 Heh. Hoping it comes in today, as it's Pi day and all. Ran like 20 builds this weekend trying to get it working and couldn't get it to build right. Mar 14 14:19:13 Hmmz any clues as to what's the problem? Mar 14 14:21:28 No good ones. I'm starting to think it's the kernel. Going to try bumping to 4.4 to see if that fixes anything Mar 14 14:24:15 OK Mar 14 15:40:14 Herrie|Veer: Which branch should I open the PR against? testing? Mar 14 15:41:32 Andolamin: Which repo? Mar 14 15:41:42 webos-ports-setup Mar 14 15:45:25 fido Mar 14 15:46:52 JaMa: Thanks! Mar 14 15:47:34 JaMa: When that's PR-ed and merged we can start a test build right? I got all the Jenkins stuff lined up. Mar 14 15:48:24 Herrie|Veer: you'll need to rebase testing branch on top of fido and update the Build-Flow jobs to include rpi builds Mar 14 15:48:29 but in theory yes :) Mar 14 15:50:58 JaMa: With Build-Flow jobs you mean the params of the Jenkins testing job right, so it builds the pi2 machine? Mar 14 15:51:41 no, I meant luneos-testing_build jobs Mar 14 15:52:10 Yeah we're talking the same thing ;) Mar 14 15:54:06 Herrie|Veer: https://github.com/webOS-ports/webos-ports-setup/pull/6 - Also, did you already get the job updated to include https://github.com/Andolamin/webos-ports-setup/blob/alan/raspberrypi/conf/local.conf#L1-L7 in the environment for the raspberrypi2 builds? Mar 14 15:54:39 Andolamin: rpi layers should be bellow meta-lune* in BBLAYERS Mar 14 15:55:34 JaMa: I'll try moving it. I had to have it above meta-lune* at one point because I was overriding files, but I *think* all of those have been merged into meta-lune* already. Mar 14 15:57:22 BSP layers shouldn't do it. meta-luneos on the other hand should be able to override any files anywhere, so needs to stay on top Mar 14 15:57:23 Herrie|Veer: And also DISABLE_SPLASH ?= "1" Mar 14 15:58:15 Andolamin: These look odd to me in a local.conf that would apply to all targets? Mar 14 15:59:25 Herrie|Veer: Hasn't impacted my builds for other targets, but that's why I didn't PR that bit, so they'll need to be environment variables for just the Pi2 builds Mar 14 15:59:51 I think so? Mar 14 15:59:57 JaMa: ^ Mar 14 16:17:47 I don't see this variable used in any layers I currently have, so it's probably specific to rpi? Mar 14 16:19:10 JaMa: Yes seems so. Therefore to me they shouldn't be in generic local.conf file Mar 14 16:20:14 right Mar 14 16:21:04 Where should this be according to your experience? Mar 14 16:21:53 meta-rpi-luneos (all of these local.conf additions) Mar 14 16:22:44 https://github.com/Andolamin/meta-rpi-luneos/blob/master/recipes-bsp/bootfiles/rpi-config_git.bbappend uses DISABLE_SPLASH Mar 14 16:23:02 Andolamin: ^ Mar 14 16:23:23 Can you move them and also test the change of the order of the layers as per JaMa's comments? Mar 14 16:25:19 Herrie|Veer: Testing that change right now Mar 14 16:26:06 I knew that local.conf was a horrendously bad place to put them, but why is meta-rpi-luneos and not just env variables? Mar 14 16:26:59 I'm not even sure how to add those to meta-rpi-luneos Mar 14 16:27:24 Especially since the values will be different for Pi2 and Pi3 Mar 14 16:29:18 Andolamin: you can put them in .conf, no? Mar 14 16:29:58 Andolamin: local.conf and env variables should be used only for local/temporary changes, the layers should define some reasonable working configuration without additional tweaks in local.conf Mar 14 16:31:35 I'll move them there and run a new build. Mar 14 16:40:10 Andolamin: The Pi's are a bit of a different duck compared to our "normal" targets, hence the need for some tweaks :) Mar 14 16:41:51 Indeed Mar 14 16:43:45 But it also might pave the way for some other targets :) Mar 14 16:52:16 Build is still running, but I updated the PR Mar 14 16:52:48 qtwebengine is wrapping up right now, so build should be done in just a few minutes. Mar 14 16:52:59 :) Mar 14 17:10:28 Build failed - but I think it's because my tmp-glibc got messed up. rm -rf, then trying again. Mar 14 17:12:32 ok Mar 14 17:15:14 do_rootfs couldn't satisfy dependencies for packagegroup-luneos-extended Mar 14 17:37:06 Nope - failed again. Mar 14 17:37:12 JaMa: https://gist.github.com/Andolamin/b4d3a77b49b9a4b09daa ideas? Mar 14 17:38:13 Should I rm -rf sstate-cache as well? Mar 14 17:44:58 Andolamin: did rpi change the TUNE_PKGARCH in last build or something like that? Mar 14 17:45:41 Andolamin: removing whole sstate is big hammer, bitbake -c cleansstate luneos-components libqofono nemo-qml-plugin-dbus should be enough and faster to rebuild Mar 14 17:45:52 maybe these aren't right providers for those packages Mar 14 17:45:54 Not that I know of. Was working on getting Pi3 working, though, that could have done something Mar 14 17:47:42 I'll try bitbake -c Mar 14 17:52:03 Might have done the trick... do_rootfs is still working but the three components rebuilt just fine Mar 14 17:52:23 And do_rootfs was failing much more quickly than this Mar 14 17:54:47 Andolamin: :) Mar 14 17:55:09 We'll need a PR for the local.conf as well ;) Mar 14 17:55:21 Wherever you placed it now ;) Mar 14 17:58:05 Herrie|Veer: It's in meta-rpi-luneos, so it should be good to go. Mar 14 17:58:26 layers.txt points to meta-rpi-luneos,master,HEAD Mar 14 17:59:15 you should use "fido" branch Mar 14 17:59:34 OK this is your fork right? Might be good to send stuff upstream so we don't need your fork in future? Mar 14 17:59:37 "master" and "jethro" branches should be available for Yocto 2.0 and 2.1 compatiblity Mar 14 18:04:46 I created fido and jethro branches and updated the PR to use fido. They're all identical branches anyway. Mar 14 19:10:09 Herrie: Flashed the build to my Pi2 but it doesn't boot :( Mar 14 19:10:17 Going to see if I can figure out why Mar 14 20:21:55 Andolamin: Hmmmz bummer, let us know when you find something! Mar 14 20:22:29 Will do! Mar 14 20:30:03 Maliit runtime dependency issue. Hoping that it was another sstate issue. I cleaned the sstate for qtbase and did a rebuild, flashing and testing that now. Mar 14 20:51:27 No luck :( Mar 14 23:53:27 Took the big hammer approach (rm -rf sstate-cache tmp-glibc) and rebuild. Just finished. Flashing, hopefully this will work, otherwise I'll need to see what recipe (likely in meta-raspberrpy) isn't working correctly after I moved the layers. Mar 15 00:16:43 Didn't work :( Mar 15 00:49:29 anyone seen DougReeder? Mar 15 01:12:47 ka6sox: Not in the last couple days, no. Mar 15 01:13:34 okay I invited him into the project...but haven't seen him accept (on GitHub) Mar 15 01:13:36 My client logs everything, last logged in 7:59pm on the 12th. Mar 15 01:13:47 okay so maybe tonight Mar 15 01:13:49 My IRC client, that is Mar 15 01:14:03 Andolamin, are you on PDT now? Mar 15 01:15:46 Yes **** ENDING LOGGING AT Tue Mar 15 02:59:58 2016