**** BEGIN LOGGING AT Tue May 13 02:59:59 2014 May 13 06:48:41 morning May 13 06:56:04 morning May 13 07:00:03 good morning May 13 07:00:31 volker: hi May 13 07:19:27 Could I lowercase a variable inside a bb recipe? May 13 08:20:06 akS: AFAIK lower() May 13 08:22:00 hi guys, I was wondering how you compile an old yocto on a newer hw (with a newer linux distro that is not supported) May 13 08:31:53 is it possible to not use virtual machine and create some chroot jail? May 13 08:32:31 syncbq: do you run into some problem building, or are you only worried about the warning? May 13 08:32:50 fedora 20 will fail to compile yocto1.2 May 13 08:33:09 it is not in the supported distro May 13 08:33:25 but on newer hw I can't run old distros May 13 08:33:59 maybe ubuntu 12.04 LTS but it has some problems too with newer laptops May 13 08:35:08 morning all May 13 08:35:12 syncbq: if the build issue you're seeing is due to newer GCC maybe you can just install and use an older version of that. Otherwise I guess a VM or to chroot into an older version will work. May 13 08:35:16 morning May 13 08:35:43 aha so chroot is an option May 13 08:35:45 thanks May 13 08:36:07 I am trying to avoid VM May 13 08:36:07 I think, I have never tried it. But can't really think of a reason why it wouldn't work :) May 13 08:36:36 I am trying to avoid VM due to time wasted May 13 08:37:09 thanks erbo May 13 13:40:35 exit May 13 14:56:29 YPTM: Participant passcode: 42001078 Dial-in number: 1.972.995.7777 US Toll Free number: 1.877.561.6828 BlackBerry users, click this link to join your conference as a participant: 1.972.995.7777x42001078# May 13 14:59:13 YPTM: ross joined. May 13 14:59:34 YPTM: Stephen has joined May 13 14:59:44 YPTM: Sean Hudson has joined May 13 14:59:45 YPTM: tom Z here May 13 15:01:05 YPTM: Richard is here May 13 15:01:06 YPTM: Scott Rifenbark joined the call. May 13 15:01:11 * darknighte yawns May 13 15:01:16 YPTM: belen joined the call May 13 15:01:33 cristian joined May 13 15:01:46 YPTM: Paul Eggleton is on May 13 15:01:59 YPTM: AlexG on IRC only May 13 15:02:09 Cristiana on the call May 13 15:02:43 YPTM: Cristiana on the call May 13 15:03:39 YPTM: nitin is on the call May 13 15:04:01 YPTM Michael is on the call. May 13 15:05:14 YPTM: Saul is on May 13 15:07:36 sgw_: sjolley: will there be any other changes in 1.4.4? May 13 15:08:30 No features or upgrades beyond patches open against 1.4.x May 13 15:12:04 darknighte: that machine file is like something out the dark ages, you can kill GLIBC_ADDONS = "nptl" ;-) May 13 15:12:34 RP: there are a *lot* of rough edges. May 13 15:13:45 halstead: I just noticed that there don't appear to be any messages in the archive for meta-amd May 13 15:14:02 would you take a look? there should be the initial announcment at least. May 13 15:16:12 Sure. May 13 15:16:52 darknighte, https://lists.yoctoproject.org/pipermail/meta-amd/2014-May/000000.html is the only one I see. May 13 15:18:12 halstead: https://lists.yoctoproject.org/pipermail/meta-amd/ doesn't show that message May 13 15:18:53 RP: I just opened in internal issue to address it though. May 13 15:20:49 darknighte, It does show in my browser. Are you behind a caching proxy perhaps? May 13 15:21:14 not that I know of.... May 13 15:21:48 I wonder if my provider is doing somthing shady May 13 15:22:14 weird. I think it may be a chrome thing. May 13 15:22:23 I just forced a reload and there it is. May 13 15:23:23 Hello, Is there a simple way to create a receipe to add a custom device tree (dts file) in the linux-yocto (3.14, Daisy version) ? I'm working on beaglebone machine. I want to have the devicetree-uImage-am335x-boneblack.dtb + devicetree-uImage-am335x-custom.dtb. May 13 15:23:37 darknighte, Sounds like all is well now. May 13 15:24:11 halstead: for the most part, except that I *know* I refreshed that page a few times without seeing the message. May 13 15:24:27 now, I'm going to develop a nervous tic of reloading pages. ;) May 13 15:26:35 darknighte, I can force a shorter expires header for the list archives. I think it's five minutes at the moment. May 13 15:27:00 halstead: nah. sounds like a local issue for me. May 13 16:24:01 darknighte, people that do BSP's need to recall that we may build with multiple BSP's in our layer stack May 13 16:43:39 Crofton|work: any specific suggestions of things to fix? May 13 16:43:47 Crofton|work: at mentor, we use setup scripts which accept the machine as an argument, and pull in just hte layers needed for that machine, but we realize that most don't do that, most just include all, so in general we do try to make sure our layers are well behaved, but it's easy to miss something since we aren't always set up that way May 13 16:44:17 darknighte: https://github.com/kergoth/oe-test-scripts/blob/master/leaky-layer-tests may be of interest, though it won't help with the machine .conf badness May 13 16:44:23 I suspect you need to watch for setting preferred versions of things that are not machine specific May 13 16:44:32 this at least makes sure that all the bbappends use overrides properly to avoid breaking things when you aren't configuring for that machine May 13 16:44:51 kergoth: thx for the link. I'll take a look. May 13 16:45:09 Crofton|work: RP pointed out something similar and it's on the todo soon list May 13 16:46:00 it takes a build without that layer, takes a list of the appends in the layer, then uses bitbake -S to emit the information about those recipes, then it adds that layer to the build and uses bitbake-whatchanged (or, in the future, bitbake -S printdiff) to compare before and after and watch for changes that occurred solely as a result of including the layer, without opt-ing in to its machines May 13 16:46:12 I would comment where you have specific version deps so distro people have good guidance and others can set locl.conf May 13 16:46:19 kergoth: We should make that part of YP Compatible May 13 16:46:52 That's a good idea, particularly for BSP layers May 13 16:50:42 RP I agree.. May 13 16:50:52 BSP layers should be careful to only affect the BSP.. May 13 16:51:57 I think koen screams anytime he notices a bsp with issues, but I'd like to not use that as the primary QC test :) May 13 16:52:49 * kergoth wonders if bitbake -S printdiff or bitbake-whatchanged spots changes to file-checksums, or to selection of override-specific file:// files May 13 16:52:54 Crofton|work: hehe May 13 16:59:33 kergoth: the file checksums are included so it should May 13 17:00:24 cool May 13 17:05:56 RP: kergoth: that check sounds like a good idea to add to YP compatible May 13 17:57:33 seebs: I'm seeing inexplicably changing ownership on some files in the rootfs. Any suggestions on how I'd determine if pseudo is to blame, or if something else is going on? May 13 17:57:42 seebs: changing from one b uild to the next, that is May 13 17:57:54 Well, that's quite *likely* a pseudo thing. May 13 17:58:03 seebs: we're seeing random files in the rootfs owned by xuser, and then possibly back to root the next time May 13 17:58:06 First thing I'd look for would be non-zero-size pseudo.log files. May 13 17:58:14 the build before this i saw a bunch of files go g+s on the dirs, totally weird May 13 17:58:18 That's the sort of thing that happens if files escape. May 13 17:58:26 okay, where are those located? May 13 17:58:33 never had a need to debug pseudo before :) May 13 17:58:43 /var/pseudo, next to the files.db files. May 13 17:58:51 I think every work dir gets its own. May 13 17:58:52 ah May 13 17:59:21 going to also do some comparison between packages-split in pseudo context, ipk contents, and rootfs contents, to see if they're all the same as they should be May 13 17:59:29 thanks for the pointer May 13 17:59:37 this is an annoying one :) May 13 19:06:28 damn it, missed th TSC meeting May 13 19:06:31 reading the log May 13 19:06:38 in between boat tasks May 13 19:31:44 akbennett May 13 20:43:34 seebs: hmm, seeing lots of path and inode mismatches. i'm guessing the path mismatch isn't harmful due to hard links, but the inode mismatch sounds slightly more concerning May 13 20:43:48 hmm May 13 20:43:55 If it doesn't have a link count of 2 or higher, a path mismatch is also concerning. May 13 20:44:28 And in general, an inode mismatch means that pseudo previously saw a file with some inode X, and is now seeing it with a different inode not-X, and this means that something shuffled files outside of pseudo, and can result in Weird Stuff. May 13 20:44:51 huh May 13 20:44:51 there's at least one 1 link path mismatch May 13 20:46:04 I'm doing rm -rf tmp cache; bitbake —no-setscene core-image-base; in a loop, and watching the changes to buildhistory from build to build. so far i've seen busybox.suid go from non-setuid to setuid, a library go from 0644 to 0755, and the ownership on the opkg package feed change from my uid to root/root or back again May 13 20:47:36 Yeah, that is definitely Not Right. May 13 20:47:56 That worries me, because obviously this has been stable for a pretty long time, and while I've done some pseudo work recently, none of it's gone in-tree that I know of. May 13 20:48:00 will try a pure poky build without any mentor layers to see if its reproducible there as well, or if there's possibly something odd in our builds May 13 20:48:10 though what would do *this* i haven't the foggiest :) May 13 22:14:48 Does someone uses external shell variables in Yocto? I tried BB_ENV_EXTRAWHITE (which does not seem to be documented anymore) without success May 13 22:31:29 volker: i do, what's the issue? May 13 22:31:41 kergoth: how do you get the variables in? May 13 22:32:12 kergoth: I try BB_ENV_EXTRAWHITE = "$BB_ENV_EXTRAWHITE BUILD_TAG BUILD_NUMBER BUILD_NAME BUILD_URL" in local.conf without success May 13 22:32:30 add the variable name to BB_ENV_EXTRAWHITE. that will get it into the metadata (you can verify this with bitbake -e), but it won't automatically re-export them into child processes of the build, you'd have to add 'export FOO' for each var in the metadata for that May 13 22:32:40 "without success" is pretty useless. how did you verify it? May 13 22:32:43 need mor edetail than that May 13 22:33:15 also, if you source the oe-init-build-env after you set BB_ENV_EXTRAWHITE, the setup script will overwrite your value May 13 22:33:18 it doesn't append to it May 13 22:33:24 so you have to set that after sorucing May 13 22:33:29 kergoth: If I run export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE BUILD_TAG BUILD_NUMBER BUILD_NAME BUILD_URL" before the bitbake command it works May 13 22:33:34 otherwise $BB_ENV_EXTRAWHITE wont be what you think it is May 13 22:33:42 right, so, problem solved May 13 22:33:50 so I can't set it in local.conf? May 13 22:34:06 kergoth: actually I don't need to do an extra export in the recipe May 13 22:34:30 by the time local.conf is parsed, bitbake is long past the env filtering May 13 22:34:36 and its already removed those things May 13 22:34:41 so no, you can't May 13 22:34:44 it has to be in the shell environment May 13 22:34:45 ok May 13 22:35:18 something else, is there a way to set the variable if it is not set? In the common shells this would be ${VARIABLE:-value_if_not_set}, but doesn't work in yocto May 13 22:37:39 that's what ?= is May 13 22:37:43 it's used all over May 13 22:37:51 same as in a makefile May 13 22:37:57 kergoth: it works in the recipe? May 13 22:38:02 ? May 13 22:38:06 i don't understand theq uestion May 13 22:38:11 ?= in bitbake metadata is set if not already set May 13 22:38:17 it doesn't care where it happens to be May 13 22:38:28 confijg file or recipe or bbclass, irrelevent May 13 22:38:47 kergoth: I want to overwrite the variable in the recipe if it is not set May 13 22:39:00 I really don't know how many more times you want me to repeat this May 13 22:39:07 FOO ?= "bar" sets FOO to bar if FOO wasn't already set May 13 22:39:26 kergoth: sorry, was a response to you "don't understand the question" May 13 22:39:48 i know, what confused me was where else you thought i was talking about other than in the recipe May 13 22:39:53 ?= isn't valid shell syntax May 13 22:40:01 local.conf etc. May 13 22:40:02 so its obviously bitbake May 13 22:40:12 recipe file format is the config file format + other stuff May 13 22:40:18 anything valid in a config file is valid in a recipe May 13 22:40:30 just not vice versa May 13 22:40:41 kk, thanks :) May 13 22:40:43 np May 13 22:43:17 seebs: FYI, in case you want to try to repro, I'm doing this: while true; do rm -rf tmp cache; bitbake --no-setscene core-image-base && buildhistory-diff | mail -s "Build completed: $(date)" kergoth@gmail.com; done May 13 22:43:30 then the deltas just keep showing up in the inbox May 13 22:48:55 that's interesting. Never heared about buildhistory-diff :) May 13 22:49:25 kergoth: do you use some kind of scripts for your different builds? Or do you just throw the few commands into your build system? May 13 22:55:15 it depends on what i'm doing, and also which setup / which setup scripts i'm using. the mentor setup scripts accept a machine, and arguments for additional layers, which is more convenient than scripting edits to bblayers.conf, for example May 14 02:04:04 * mr_science waiting for burgers **** ENDING LOGGING AT Wed May 14 02:59:59 2014