**** BEGIN LOGGING AT Wed Feb 20 02:59:58 2013 Feb 20 08:06:29 good morning Feb 20 08:34:41 (moin|good morning|goede morgen|dobro jutro) Feb 20 09:18:09 morning all Feb 20 12:00:54 Hi need som tips on how to change version of linux-yocto package. From a clean project I add PREFERRED_VERSION_linux-yocto = "3.0%" to conf/local.conf but it don't work. Also tried setting the PREFERRED_VERSION_linux-yocto_qemux86-64 variable but still no dice. Where do I specify this? I have the 3.0 bb file and can see it with bitbake-layers show-recipes Feb 20 12:03:51 neg: where are you adding this? Feb 20 12:10:08 bluelightning: conf/local.conf bottom of file Feb 20 12:10:46 is a clean workspace created fresh by sourcing oe-init-build-env script Feb 20 12:12:12 then before I build I try to check what version will be build using bitbake -s core-image-minimal but it's stuck at 3.4 Feb 20 12:50:08 anyone an idea which layer will give me an ffmpeg recipe ? Feb 20 12:51:10 eFfeM_work: libav is in meta-oe Feb 20 12:51:24 hrw, thanks Feb 20 12:51:34 actually gogole also gave me a recipe in meta-baryon Feb 20 12:51:37 google Feb 20 12:51:45 enough to ge tme started Feb 20 12:52:34 eFfeM_work: if you would move to libav 9.1 then ping me Feb 20 12:58:15 hrw: personally I won't; a grad student here was looking for that recipe, I knew it was in oe-classic but could not find it in yocto; not too sure what he actually wanted, might be he also wants the ffmpeg exe Feb 20 12:59:20 hrw, thanks for your help Feb 20 13:23:18 eFfeM_work: that one is kind of old though Feb 20 13:49:54 bluelightning: yeah, the student will probably update it (actually I am not his supervisor, just the local oe wiz they bother for all kind of questions) Feb 20 13:50:28 (guess they need to find a new wiz) Feb 20 13:56:12 I need to remove a directory and all its content from a .bbclass Feb 20 13:56:21 but I need to do it safely Feb 20 13:56:42 eFfeM_work: I had 9.1 somewhere Feb 20 13:56:56 I don't want to use something like "removeall(path)" because "removeall(/)" would be dangerous Feb 20 13:57:13 but update of libav means also checking of everything what uses it so I skipped due to other things to do Feb 20 13:57:15 any tips? :) Feb 20 14:00:49 hrw: i'll leave it to the student, actually I told him about #yocto and gave him your nick so he can contact you if he wants 9.1 Feb 20 14:01:09 as I'll be gone here next tuesday Feb 20 14:01:15 ok Feb 20 15:02:34 When I add: BBCLASSEXTEND = "native nativesdk" to the util-linux.inc file I start to get all sorts of warnings like: Feb 20 15:02:34 NOTE: multiple providers are available for runtime util-linux-umount (util-linux, util-linux-nativesdk) Feb 20 15:02:34 NOTE: consider defining a PREFERRED_PROVIDER entry to match util-linux-umount Feb 20 15:02:57 Anyone have a suggestion about resolving that problem? Feb 20 15:03:47 It seems to imply the nativesdk util-linux-umount is a suitable replacement, when obviously it isn't. :-) Feb 20 15:04:52 jwessel: I think it's because the recipe is adding util-linux-* instead of ${PN}-* to PACKAGES Feb 20 15:05:03 it should really be doing the latter Feb 20 15:05:12 Ah... That makes sense Feb 20 15:05:33 I hadn't seen this problem before, so I wasn't exactly sure what it was trying to tell me. Feb 20 15:05:36 I'll try that first. Feb 20 15:08:22 bluelightning: That was it. Once again you have worked miracles. Thanks. Feb 20 15:08:35 jwessel: no worries Feb 20 15:57:33 g'day folks. I'm trying to wrap some bitbake operations with a script where I'd like to conditionally add a layer. Is there a way to affect BBLAYERS w/o modifying conf/bblayer.conf ? Feb 20 15:58:38 I tried an environment variable with that name, but it didn't work Feb 20 15:59:40 Garibald1: environment variable may work if you add the variable name to BB_ENV_EXTRAWHITE Feb 20 16:00:18 is BB_ENV_EXTRAWHITE itself an environment variable, or something in a conf file? Feb 20 16:03:12 ah, an env variable :_ Feb 20 16:03:29 bluelightning: thanks, that seems to have worked Feb 20 16:38:38 Ok, new question. Suppose I have an SDK and a yocto install. It's there a way to get yocto to use the existing toolchain from the SDK? Feb 20 16:38:52 s/It's/Is/ Feb 20 16:40:00 Garibald1: we don't support that Feb 20 16:40:19 (i.e., after sourcing 'oe-init-build-env' for a new build tree, can I then do something to get bitbake to use the toolchain from the SDK rather than downloading/installing the toolchain again) Feb 20 16:40:24 ok Feb 20 16:40:31 Garibald1: if you're doing that to avoid rebuilds the solution is to use the shared state cache instead Feb 20 16:40:51 or rather, if you're wanting to do that to avoid rebuilds Feb 20 16:41:40 is a shared state cache intended to be used for "formal builds"? or should formal builds be full source builds? Feb 20 16:42:50 so when I build the SDK, I can save the sstate-cache from that, provide it with the SDK, and get a copy when I start the build? Feb 20 16:43:04 kmacleod: there's no reason it can't be used for "formal builds" Feb 20 16:43:24 (i.e., cp -R /path/to/sdk/sstate-cache .) Feb 20 16:43:50 from a configuration management perspective, people usually do full from scratch tests for official builds to avoid potential risk, but in theory it doesn't matter Feb 20 16:43:58 * kergoth gets food Feb 20 16:44:30 kergoth, thx, that's probably what we'd do. Feb 20 16:44:43 bluelightning: does that make sense? Feb 20 16:45:12 Garibald1: the sstate-cache is always written out to the same location (as defined by SSTATE_DIR) Feb 20 16:46:33 yeah, but I'm thinking about a scenario where I've built and SDK and given it to a third-party who also uses yocto Feb 20 16:46:51 s/and/an/ Feb 20 16:47:56 so if I include a copy of the sstate-cache from the SDK build in what I give the third party, could they then set SSTATE_DIR to point to that and avoid the rebuild? Feb 20 16:50:02 meh, won't hurt to try I guess :) Feb 20 16:50:35 yes, that can work, though the native/cross sstates wont be reused if the build distro isn't the same as reported by lsb_release Feb 20 16:50:46 yeah, that makes sense Feb 20 16:51:41 there is a way to get around that too though, if you work at it. at mentor, we build on centos 5.x and trust that any distro we support is at least that new, so know those binaries will run everywhere, then arrange for the sstate mirror handling to fall back to the files for that distro Feb 20 16:53:17 I'll ultimately be targeting a VM; I'll just build the SDK on the same VM and I should be good to go Feb 20 16:54:14 * kergoth nods Feb 20 16:54:16 even better Feb 20 16:54:29 there's a lot to be said for knowing the sanity of the environment you'll be buliding in :) Feb 20 17:07:17 rp: bitbake-selftest passes for me in my environment... :s Feb 20 17:08:38 zibri: hmm. There is something odd going on then... Feb 20 17:09:41 * kergoth wonders how exceptions are getting into 'results' in the parsing Feb 20 17:10:28 (for reference, my env is debian wheezy, python 2.7) Feb 20 17:13:32 zibri: I'm not seeing the same issues I did last night :/ Feb 20 17:16:30 rp: on debian squeeze i see failures on bb.tests.fetch.FetcherTest: test_gitfetch, test_gitfetch_premirror, test_gitfetch_premirror2, test_gitfetch_premirror3 Feb 20 17:16:42 but that's on current master Feb 20 17:17:58 and same errors before the revert Feb 20 17:22:01 Hi... is someone facing problems recently with arago-project.org ??? (/meta-ti/recipes-bsp/u-boot/u-boot_2013.01.bb fetch error) Feb 20 17:26:51 zibri: why are those failing on squeeze? Feb 20 17:27:12 zibri: those are the ones I saw fail... Feb 20 17:27:22 AttributeError: 'module' object has no attribute 'check_output' Feb 20 17:27:46 subprocess.check_output <-- Feb 20 17:28:04 so... changes in the subprocess module between 2.6 and 2.7? Feb 20 17:28:43 http://docs.python.org/2/whatsnew/2.7.html yep Feb 20 17:29:29 zibri: right, I wasn't seeing that Feb 20 17:30:05 hum, ok. Feb 20 17:43:39 we should just pull check_output into bb.compat. with that, we could probably drop most, if not all, of bb.process Feb 20 18:46:57 <_Lucretia__> anyone know why I would get this error by adding in meta-ti (denzil)? http://pastebin.com/zNgHqRWr Feb 20 18:48:02 RP, we should change the channel name to "Yocto Project" :) Feb 20 18:54:21 <_Lucretia__> the only other thing I have done it build denzil for gumstix using linux-sakoman-3.2 Feb 20 18:56:37 <_Lucretia__> er, weird, now it's working Feb 20 18:57:34 rp: yeah, i see what was happening with the emgd-driver-bin_1.14.bb; it has both a query string and params Feb 20 19:28:32 Crofton: gah ;-) Feb 20 19:28:55 zibri: ah, yes, that makes sense :/ Feb 20 23:51:45 Hmm, can anyone remember if we have recipes for testing of the unpack code and patch class? Feb 20 23:51:51 i swear we had something at one point Feb 20 23:52:19 Hmm, I thin kI did something like that, a layer for it, from when i reworked the unpack bits in base.bbclass before it got moved to bitbake, but i have no idea where that went Feb 20 23:52:22 * kergoth scratches head Feb 20 23:58:35 * kergoth does a curl+sed bit on git.yoctoproject.org to clone every meta-* repo from there to see what's missing from LayerIndex :P Feb 21 00:14:15 hi kergoth Feb 21 00:14:32 + hollisb Feb 21 00:14:51 hey mranostay Feb 21 00:19:11 kergoth: not here at ELC i'm guessing? Feb 21 00:23:40 mranostay: sadly not, missed it this year. procrastinated myself out of going, never even talked to work about it :) Feb 21 00:23:43 * kergoth rolls eyes Feb 21 00:26:48 heh Feb 21 00:27:10 i've only seen darknighte_afk here Feb 21 00:28:31 any other mentor guys? Feb 21 00:29:09 probably? :) i'd think so, but not sure **** ENDING LOGGING AT Thu Feb 21 02:59:59 2013