**** BEGIN LOGGING AT Wed Aug 01 02:59:59 2012 Aug 01 07:42:27 which is the best touch-based image in oe atm ? screen around 800x480 ? Aug 01 08:02:30 morning all Aug 01 08:04:03 g'morning Aug 01 08:14:53 As mension on the maillist I have problems compiling boost...... can anyone of you reproduce my error ? Aug 01 08:17:19 what are you error's Aug 01 09:14:32 alexhairyman: http://pastebin.com/eDRHiXXv Aug 01 09:16:27 ynezz: Re: ynezz [#oe] likewise: how do you handle sshd keys for example? --- You handle the volatile items outside of a read-only filesystem. The filesystem being read-only for purposes of reliability and determinism of field-deployed devices. Aug 01 09:18:20 ynezz: In other words, read-only rootfs is about more deterministic, reliable boot scenario's in headless, high availability devices. Program code (read-only), state (variables), configuration is seperated so that the effect of writing data will not influence the availability of the rootfs in any way (ideally). Aug 01 09:18:58 alexhairyman: I going offline now. I'll be back in about 1 hour Aug 01 09:18:59 seperated->separated likely Aug 01 09:23:48 and you've it working with oe? Aug 01 09:27:09 gnight all... it's 3:30 here Aug 01 09:59:51 JaMa: hi, are you around? Aug 01 10:54:28 bluelightning: yes Aug 01 10:56:27 JaMa: for your buildhistory feature (yocto bug 2787) would you be OK if PKG/PKGV/PKGR were not written to the file unless they were different from the standard value? Aug 01 10:57:25 (as we currently do for PE) Aug 01 10:57:44 bluelightning: standard as the same as PV or standard as default value? Aug 01 10:58:07 JaMa: same as PV for the package, yes Aug 01 10:58:35 probably fine if it's harder to write them everytime Aug 01 10:59:29 it's not harder, I'd just like to avoid noise Aug 01 11:00:38 ah ok.. I was thinking about checking diff between two builds that it's maybe easier to spot different values then value missing in next build because it became equal to PV Aug 01 11:01:51 but you're right those values will be standard in many cases and carefull eye should notice also missing/added lines Aug 01 11:01:57 not sure, I think that may depend on how you're viewing the diff Aug 01 11:02:38 buildhistory-diff will be updated to understand how to read/compare the values at least Aug 01 11:04:44 currently I'm usually checking git diff (many times on web - cgit) Aug 01 11:07:04 that's fine, the only trouble with doing that is that insignificant changes next to significant ones can be overlooked I think Aug 01 11:07:16 depends on how keen your eye is I guess ;) Aug 01 11:20:36 bluelightning: I cannot say without seeing "typical" diff, sorry Aug 01 12:05:48 Hello. Aug 01 12:09:40 So, I have strange question. Aug 01 12:10:25 Is this possible to set some variable when starting bitbake? Aug 01 12:11:31 For example: GIT_BRANCH=foo bitbake mytarget Aug 01 12:11:36 And in mytarget receipe" Aug 01 12:12:17 SRC_URI = "git://foo_bar.com/myproject;protocol=git;branch=${GIT_BRANCH}" Aug 01 12:12:22 Is this possible? Aug 01 12:24:38 hi all Aug 01 12:27:34 otwieracz: yep, you just need to add the variable to BB_ENV_EXTRAWHITE in your configuration Aug 01 12:28:26 hi silvio_ Aug 01 12:28:41 hi flo_lap Aug 01 12:28:45 Hmm. Aug 01 12:28:47 What does METADATA_BRANCH="dev" Aug 01 12:28:51 means? Aug 01 12:28:58 Isnt it a branch od Openembedded? Aug 01 12:31:07 otwieracz: if you use "git grep METADATA_BRANCH" you can see how it gets set Aug 01 12:31:47 You meant "bitbake -e | grep METADATA_BRANCH"? Aug 01 12:32:18 Oh, there's git grep command? Aug 01 12:32:40 otwieracz: yep, standard git command Aug 01 12:32:44 However: Aug 01 12:32:45 # METADATA_BRANCH=${@base_get_scm_branch(d)} Aug 01 12:32:46 otwieracz: only searches tracked files Aug 01 12:32:46 METADATA_BRANCH="dev" Aug 01 12:32:52 from "bitbake -e | grep METADATA_BRANCH" Aug 01 12:33:16 sure, so that means the variable is set to the return of the base_get_scm_branch function Aug 01 12:33:54 OK, I'll interest in BB_ENV_EXTRAWHITE. Aug 01 12:34:09 Where it is set? Aug 01 12:34:32 Ah, nevermind :) Aug 01 12:37:25 sstate cache is nice stuff Aug 01 12:53:36 hrw: are you using it in the "shared" sense? Aug 01 12:54:18 hrw: although I like the idea, from what I understand, I am not really using it's potential as I'm mostly rebuilding stuff on one machine. Aug 01 12:55:06 Would be great to have a build machine prepare 99% of the build for me in sstate, then on my development machine, re-use the sstate and work on the 1% tip of development. Aug 01 12:56:21 likewise: sure, that's perfectly possible... I've done something similar here Aug 01 12:57:32 morning all Aug 01 12:57:47 bluelightning: I just haven't found the time to setup for that use of sstate. Aug 01 12:57:54 pb_: Good morning Aug 01 12:57:57 hi pb_ Aug 01 12:59:08 hi likewise Aug 01 12:59:10 hi pb_ Aug 01 12:59:53 likewise: pretty easy, just share the sstate-cache dir from the server over http or some other method, then set SSTATE_MIRRORS = "file://.* http://server.name/path/" Aug 01 13:00:07 (latter in your local conf obviously) Aug 01 13:01:09 likewise: and this is how it works Aug 01 13:01:21 bluelightning: sounds like I do not have an excuse to postpone this any longer :) Aug 01 13:01:36 likewise: in out (Linaro) case it is a way to cut build time on ec2 machines (which costs us money) Aug 01 13:02:53 hrw: what does a single build cost you? Aug 01 13:03:23 likewise: no idea but cut from 8h to 2h means 25% of cost Aug 01 13:04:58 btw - my today's build does lot of *-nativesdk packages even when I am not building sdk - something wrong? Aug 01 13:05:55 hrw: that's odd... do "bitbake -g" graphs indicate what depends on those? Aug 01 13:06:49 NOTE: multiple providers are available for runtime dbus-x11 (dbus-nativesdk, dbus) Aug 01 13:06:54 thats why probably.. Aug 01 13:17:27 PREFERRED_PROVIDER_dbus-x11 = "dbus" Aug 01 13:17:33 but bitbake ignores it Aug 01 13:18:56 x11-common, qemu-config rdepend on dbus-x11 Aug 01 13:22:57 fixed Aug 01 13:25:43 fix sent to ML Aug 01 13:26:00 2913 tasks sounds better then 3242 Aug 01 13:28:43 finally i made my own image ;) Aug 01 13:29:05 thanks to all Aug 01 13:29:33 silvio_: made or built? Aug 01 13:29:54 hrw: http://lists.linuxtogo.org/pipermail/openembedded-core/2012-August/026947.html Aug 01 13:31:23 no made, was a birth Aug 01 13:33:32 JaMa: thanks Aug 01 13:34:43 silvio_: congratulations :) Aug 01 14:13:06 JaMa, fray, virtual/xserver is already set as a dependency in xorg-driver-common.inc. Aug 01 14:13:53 awsation: that's what I said Aug 01 14:14:09 but virtua/xserver can be defined to foo and foo doesn't provide what it needs Aug 01 14:15:42 going to rebuild that and see what happens. Aug 01 16:22:12 gm Aug 01 21:57:12 I'm having trouble booting an x86 (MACHINE='atom-pc') image when meta-oe is included in my layers. I think I've boiled it down to udev issue. With an oe-core/poky only build udevd and udevadm get put in the initrd /sbin directory, but the meta-oe initrd doesn't have either there. There is a udevd in /lib, but no udevadm to be found. Any ideas on how to go about fixing that? Aug 01 21:57:56 I'm guessing it's specific to x86 images since no one else probably uses the syslinux/initrd bootu Aug 01 22:09:54 I also see a couple of indicator comments in the recipes. The one for oe-core makes sense: Aug 01 22:09:54 # udevd/udevadm -> /sbin/, libudev.so.* -> /lib/ Aug 01 22:10:12 The one from meta-oe udev puzzles me... Aug 01 22:10:14 # udev installs binaries under $(udev_prefix)/lib/udev, even if ${libdir} # is ${prefix}/lib64 Aug 01 22:30:41 is there something I can put in a .bbappend to ignore the recipe altogether? Aug 01 22:39:37 the whole recipe or just the bbappend? I think BBMASK will ignore it Aug 01 22:40:53 you should be able to test it with something like 'BBMASK +="recipename.bbappend" bitbake whatever you want' Aug 01 22:41:30 coldsoup, hmm I'll have to check that out **** ENDING LOGGING AT Thu Aug 02 02:59:58 2012