**** BEGIN LOGGING AT Mon Oct 13 03:00:00 2014 Oct 13 07:40:54 Does it make sense that changing SDK_VERSION triggers a rebuild of gcc-crosssdk-initial amongst others ? Oct 13 08:34:14 kroon: other sdk version == rebuild of whole toolchain Oct 13 08:35:16 yeah looks like that Oct 13 08:52:45 morning all Oct 13 08:55:38 hi bluelightning Oct 13 08:55:46 hi woglinde Oct 13 08:56:05 * woglinde waves from elce Oct 13 09:00:34 * hrw waves from home Oct 13 09:01:36 hrw not time? Oct 13 09:01:47 I meant no time this year? Oct 13 09:02:15 woglinde: no spare 600$ or whatever money was for registration Oct 13 09:02:25 and no talk idea as well Oct 13 09:04:00 hm yes Oct 13 09:04:42 and only the show room for 100 and no talks is not worth either Oct 13 09:06:46 woglinde: to Berlin I would go even just for Yocto Day. Dusseldorf is a bit too far Oct 13 09:09:04 woglinde: and already schedule conflict with my wife conference Oct 13 09:18:05 * LetoThe2nd also waves from elce Oct 13 09:20:25 LetoThe2nd PRU too? Oct 13 09:21:26 woglinde: no, mru on perf (next room) Oct 13 09:21:38 bah Oct 13 09:21:56 hrhr Oct 13 09:22:10 pru stuff any good so far? Oct 13 09:22:37 we are at what is real time Oct 13 09:23:12 real time = FASTFASTFAST!!1!one!ELEVEN!!FAST!!ZOMG Oct 13 14:19:19 if I want to use different busybox configs for different images, how should I manage my configs? I know I can create a .bbappend for busybox, and then use OVERRIDEs to append different configs to SRC_URI depending on machine, but is it possible to do something similar based on image being built? Oct 13 14:20:35 the only way to really do that is to have two separate busybox recipes (with different PN) producing separate busybox packages Oct 13 14:22:16 bluelightning, is this a common use-case? Oct 13 14:22:53 well, all I can say is occasionally people ask about this kind of thing but not often Oct 13 14:23:50 the thing is the image can only really select the list of packages it contains and tweak files in the rootfs after package installation, it can't trigger rebuilds of packages with different config (nor would it make sense to do so) Oct 13 14:25:38 i'm trying to setup an image that can be tested using LAVA. For some reason, LAVA requires busybox HTTP server to be enabled (and other config options), so if I try to feed it the standard image, LAVA won't be able to test it. My idea is to instead produce a test image that is similar to the production image, only it has busybox httpd etc enabled. Does this make sense? I guess you also run LAVA as a part of your QA bluelightning ? Oct 13 14:26:47 mago_: right, I can understand the use case Oct 13 14:27:22 still, it does not feel exactly right to test one image and then send some other (similar) image to production.. Oct 13 14:27:23 mago_: so, sort of... we have a plan to execute our tests and collect the data under LAVA, but we use the OE test suite not the LAVA ones Oct 13 14:27:42 bluelightning, there's a OE test suite? Oct 13 14:28:00 there is... http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#performing-automated-runtime-testing Oct 13 14:28:32 the runtime part of it is a little more complete in master / upcoming 1.7 Oct 13 14:29:29 very cool. and this would integrate well with LAVA? does it replace the dispatcher, or are tests being written in the YAML format? Oct 13 14:30:38 it does its own deployment and the tests use the python unittest framework Oct 13 14:31:13 the other quirk is that the tests run on a host and interact with the target remotely, rather than running on the target itself; LAVA doesn't really support that Oct 13 14:31:57 i thought that's what serverside tests are in LAVA? Oct 13 14:33:17 could be, I don't know if linking those up to our tests is possible or not Oct 13 14:33:57 in any case the way we currently handle things is LAVA hands off control (via a script) to our side and then the results are posted back Oct 13 14:36:12 FWIW, one other thing we're trying to do is allow you to do testing easily without having to install LAVA if you'd prefer not to - at the moment you can run the tests on a target with relatively little setup Oct 13 14:38:08 mago_: I jsut popped in (at ELCE) but you know about #linaro-lava also? Oct 13 14:40:17 Crofton, i've been nagging #linaro-lava for a week already :) sorry if I'm being a bit off-topic here, my original question was about how to customize the busybox config for different image recipes Oct 13 14:40:39 this is fine Oct 13 14:40:58 I want better intregation with lava :) Oct 13 14:41:06 good to see people working with it Oct 13 14:41:21 I'm paying attention to a talk here, bad multtaksing Oct 13 14:42:21 i've only used it for a week or so, set up my own instance and also enjoying it. It'd be cool if OE tests could co-exist like bluelightning mentions (use LAVA to gather data). I kind of like the way LAVA manages devices Oct 13 14:44:15 yep Oct 13 14:44:31 we need more people working on this :) Oct 13 14:44:55 Crofton: we generally need more people *working* at least Oct 13 14:45:09 ;-) Oct 13 14:45:13 :) Oct 13 14:45:22 not sitting around at conferences drinking beer Oct 13 14:45:38 ELCE is also work. I wish i could go, but my employer said no Oct 13 14:47:03 * LetoThe2nd is actually way too tired for beer drinking right now Oct 13 14:47:36 btw the OE/YP bof is at 1730 Oct 13 14:47:53 if the day goes on like that i'll just have the quickest dinner available and be room bound then. Oct 13 14:47:54 mago_: conferences are definitely work; I'm usually totally drained by the end of the day Oct 13 14:48:05 Crofton: ack on BoF Oct 13 14:51:31 bluelightning, so how exactly does the handover between LAVA and OE work right now (in your script)? lava_run_command on a OE script, and then have the script output test results? Oct 13 14:52:03 mago_: I'm not sure of the exact details, the implementation has been done by our QA folks Oct 13 14:52:19 i wish i had qa folks :/ Oct 13 14:52:28 it's something we fully intend to publish and document after the scripts are tidied up (they are full of IP addresses of our internal servers at the moment...) Oct 13 14:52:40 cool Oct 13 14:52:56 you work at Intel, right? Oct 13 14:53:00 I do yes Oct 13 14:53:25 so you are responsible for the hype Intel have created at my company about this Edison thing ;-) Oct 13 14:53:41 that would probably be a different department ;) Oct 13 14:54:30 I just got one the other day, haven't powered it up yet Oct 13 14:55:52 :) Oct 13 14:56:02 Intel is a very big place Oct 13 14:56:12 not everythig is bluelightning 's fault :) Oct 13 14:56:42 seems to be Yoctofied.. which is good, because when my boss comes and tells me we need to support the edison, i can just clone the appropriate layers into our oe-based distro Oct 13 14:56:51 as it happens, the LAVA scripts not being published is though, I drew the short straw to tidy them up ;) Oct 13 20:27:54 hello, I am using OE layer meta-multimedia in order to build GStreamer 1.4.0, build is sucessfull but I cannot find plugin mpegdemux created, I did search on gstreamer1.0-plugins-bad.inc but there is no --disable-mpegdemux Oct 13 20:28:13 anyone know why it is not created? **** ENDING LOGGING AT Tue Oct 14 02:59:59 2014