**** BEGIN LOGGING AT Mon Mar 18 02:59:58 2013 Mar 18 09:05:09 good morning Mar 18 10:55:20 in my core-image-sato generated fs /var/volatile isn't populated, is this a normal behaviour? Mar 18 14:00:14 hi : http://linuxgizmos.com/using-uefi-and-yocto-on-atom/ Mar 18 14:00:37 "Book helps Windows Embedded developers transition to Linux" Mar 18 14:00:39 :-) Mar 18 14:04:56 can I got pip/virtualenv etc on yocto and have nearly all python modules on yocto? Mar 18 14:05:09 e.g. pip install python-whatever? Mar 18 14:06:37 not talking about sdk here, i mean to install a full-blown python on the target system, e.g. django etc Mar 18 19:10:42 The package_rpm.bbclass seems to generate specfiles with BuildRequires lines for the virtual providers listed in DEPENDS. Mar 18 19:10:53 But I don't see matching Provides lines in the specfiles of the packages that provide those capabilities. Mar 18 19:10:56 Is this perhaps something that may be missing in package_rpm.bbclass? Mar 18 20:55:26 kergoth: have you / anybody else considered getting the vim syntax stuff merged upstream? :) Mar 18 20:56:58 not sure what you mean by that. the vim syntax files are both in bitbake proper and in a separate repo i have for use with pathogen/vundle. if there's any commits from one that aren't in the other, that's just an oversight on my part Mar 18 20:57:32 kergoth: sorry, i wasn't clear. merged to vim Mar 18 20:58:03 ah, no, I doubt anyone has considered it. that's something to consider Mar 18 20:59:37 kergoth: anyways, it's really nice to have. thanks :) Mar 18 21:01:00 zibri: if you'd like to ensure that it doesn't get forgotten, you could open a bug in the yocto bugzilla regarding an attempted submission to the upstream vim runtime Mar 18 21:02:43 I really want to figure out how to address the behavior where it highlights use of bitbake variable references within python/shell functions as errors. since it passes off that handling to the sh and python syntax files, they're not allowed to have anything that's not valid sh or python in them Mar 18 21:03:26 so e.g. ${@foo} is seen highlighted as an error in a shell function Mar 18 21:03:43 s/seen // Mar 18 21:04:15 Hmm, guess could create new syntax files for bitbake-sh and bitbake-python which pull in the base ones,a nd have the bitbake syntax use those instead Mar 18 21:04:19 might have to try that Mar 18 21:08:12 kergoth: yeah, sounds good. i could open a ticket tomorrow or so. *adding to mental todo*. thanks Mar 18 21:08:50 does your mental todo actually work? I think mine has room for about 2 items before they start falling off into the ether :) Mar 18 21:12:59 kergoth: heh, i hope if i keep just this item on it, it may actually work :) Mar 18 21:13:04 :) Mar 18 21:25:53 takes a long time to run 1250 setscene tasks Mar 18 21:27:32 i wish there was a way to tell bitbake it's okay if these bbappends are missing their recipes, but only if this layer isn't included, or something Mar 18 21:27:47 bb warn appendonly is clumsy Mar 18 21:39:06 kergoth: I was just talking to zeddii about that last week. If you come up with something we'd happily use it. Mar 18 21:41:32 whenever you want a layer to alter recipes from multiple bsps, or e.g. want to append to meta-oe recipes if meta-oe is included, but still work without it, things get a bit painful Mar 18 21:41:46 it's way too easy to miss a *real* fatal missing recipe amongst all the other missing recipe warnings Mar 18 21:42:15 Exactly, like when something in oe gets an uprev etc... Mar 18 22:01:10 Hi folks. I'm try to build a distro on a different machine and one of my recipes is failing with 'ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored.' I've seen some stuff online that this might have something to do with security "features" of the machine on which I'm building. Does any have any details WRT what specifically might cause it? Mar 18 22:09:01 oddly, if I do: LD_PRELOAD=.../libpseudo.so ls I don't get the error, I just get pseudo: You must set the PSEUDO_PREFIX environment variable to run pseudo. Mar 18 22:09:22 so it seems at least possible to preload the lib Mar 18 22:09:42 I'm not quite sure what would cause the failure, I'm getting it when running a shell script from my recipe Mar 18 22:10:20 jwessel: I have an idea for a possible fix for this, testing now, will let you know how it goes Mar 18 22:32:57 gah, i can't believe how many layers still have the horrid overuse of :=. that's been unnecessary for a heck of a long time now Mar 18 22:33:04 copying and pasting, no doubt Mar 18 22:40:33 jwessel: I have a solution. It's actually pretty clean, even, but it's conditional on fixing all these layer.conf files to avoid premature expansion of BBFILES (make them use += for BBFILES and .= for BBPATH instead of :=). Mar 18 22:40:44 doing further verification now, though Mar 18 22:44:55 jwessel: https://gist.github.com/kergoth/5191547 - if all the layer.confs are fixed, then this will add per-layername bbappend paths for the current layer to BBFILES, meaning you can move recipes-kernel/linux/linux-imx_3.0.35.bbappend into, say, fsl-arm/recipes-kernel/linux/linux-imx_3.0.35.bbappend for example, and that would only be applied when meta-fsl-arm is included in the config Mar 18 22:45:21 with this, we should be able to stop seeing BB_DANGLINGAPPENDS_WARNONLY entirely for this case Mar 18 22:45:27 s/seeing/setting/ Mar 18 22:46:12 the layer processing does an early expansion of LAYERDIR there, so the function gets passed the correct full path to the current layer, but the BBFILE_COLLECTIONS reference isn't expanded until BBFILES is used, at the end of the layer processing when it goes to parse the files Mar 18 22:47:11 * kergoth fixes it to avoid the function definition, as we don't want it defined more than once for all the layers using the .inc Mar 18 22:51:09 halstead: ping Mar 18 22:51:36 halstead: is there some weird networking foo going on on the ab cluster? http://autobuilder.yoctoproject.org:8011/builders/eclipse-plugin/builds/11/steps/Building%20Eclipse%20Plugin/logs/stdio Mar 18 22:58:51 pidge: I can check in about fifteen minutes. Mar 18 23:01:34 halstead: ty Mar 18 23:19:47 jwessel: confirmed, this solution works great once we get all the layer.confs fixed. I have a local test environment set up with BB_DANGLINGAPPENDS_WARNONLY disabled. Mar 18 23:29:13 pidge, It was an issue with the default route. Mar 18 23:30:01 pidge, Downloading from download.yp.org will work on ab06 now. Mar 18 23:32:03 haltead: ty! Mar 18 23:33:11 halstead: was that on the entire cluster or just one machine? Mar 18 23:33:25 pidge, Only ab06 was different. Mar 18 23:33:59 pidge, We have two gateways. One used by public machines like ab01 and the other for backend machines like the other builders. Mar 18 23:34:18 pidge, ab06 was using the public one when it shouldn't have been/ Mar 18 23:34:41 pidge, I must have made the mistake when setting it up at the end of Feb. Mar 18 23:36:10 yow. there are 56 layer.conf files with unnecessary uses of :=, 25 of which cause forced early expansion of BBPATH/BBFILES Mar 18 23:36:38 (checked all layers in LayerIndex and those hosted on git.yoctoproject.org) Mar 18 23:36:41 halstead: ok. Mar 18 23:37:06 kergoth: This seems reasonable, I do wonder a bit about the case where the a package is scoped in by a layer but the version has changed. Mar 18 23:37:46 For example let us say the external layer had tmux 1.5, and I had a bbappend. Mar 18 23:37:57 Clearly the patch you created works for that. Mar 18 23:38:00 jwessel: works fine. the append for the now missing version ends up in bbfiles, and without warnonly defined, it exits with a fatal error the way we'd want it to Mar 18 23:38:18 Works for me. Mar 18 23:39:20 * kergoth will start pushing fixes for layer.confs to various upstreams today Mar 18 23:40:45 So in theory I can try this right away for the places I have these problems. Mar 18 23:40:52 * jwessel goes to try it out. Mar 18 23:41:32 the problem is, if you have any layer.confs which use := on BBFILES, it'll force early expansion of BBFILE_COLLECTIONS, and you can end up with some layer specific appends missing from your bbfiles, depending on the order the layer.conf files were parsed in (BBLAYERS order) Mar 18 23:42:03 locally, it caused mentor's layer to not include the fsl-arm appends even when meta-fsl-arm was in bblayers Mar 18 23:42:21 so it depends :) Mar 18 23:42:29 if you fix those, it'll work for sure, otherwise it might Mar 18 23:51:37 We have some other strangeness going on that fray was looking into in this area where he managed to get a variable not overriden for the case where the original and the bbappend both exist. Mar 18 23:53:25 the issue there didn't have anything tod o with use of a bbappend, it just had to do with use of varaible references in variable names Mar 18 23:53:42 bitbake treats them as two independent varaible names until the names get expanded at the end of the parsing Mar 18 23:53:48 I wasn't aware he fixed it or got more info. Mar 18 23:54:06 he sent a post to bitbake-devel about it today Mar 18 23:54:08 Almost done modifying all those layer files. Mar 18 23:55:51 sed -i -e 's,BBPATH := "\${BBPATH}:,BBPATH .= ":,; s,BBPATH := "\(.*\):\${BBPATH}",BBPATH =. "\1:",; s,BBFILES := "\${BBFILES} ,BBFILES += ",' **/conf/layer.conf Mar 18 23:55:56 should take care of most of it Mar 18 23:56:41 I was automating it but we have a slightly odd setup where all the layers get checked out. Mar 18 23:56:42 the other uses of := that aren't causing problems at this time (mostly unnecessary := on definitions of BBFILE_PATTERN), sed -i -e '/:= "\^\${LAYERDIR}/s/:=/=/' Mar 18 23:58:49 Either I missed one, or something didn't work. Mar 18 23:59:08 WARNING: No recipes available for: Mar 18 23:59:08 /space/jw/5/tt/layers/wr-bsps/intel-xeon-core/recipes-amt/lms/lms_7.1.20.bbappend Mar 18 23:59:53 note that it expects the structure to go based on the layer names added to BBFILE_COLLECTIONS, not the directory names Mar 18 23:59:56 afk, errands Mar 19 00:00:12 Thanks for the ideas on resolving it Mar 19 00:00:16 * jwessel bolts for the day too. Mar 19 01:38:02 Hmm, anyone know where contributions to meta-oracle-java are supposed to go? It's hosed on git.yoctoproject, so I'm tempted to send it either to one of the two main devs directly or to yocto@ with an appropriate subject line Mar 19 01:38:11 nitink: ping Mar 19 01:41:08 after i finish with all of these, i should go find and yell at people who prepend to bbpath in their layer.conf files Mar 19 01:41:14 :) **** ENDING LOGGING AT Tue Mar 19 02:59:58 2013