**** BEGIN LOGGING AT Thu Jun 02 02:59:58 2016 Jun 02 10:29:25 hi everybody. looking for help pls. I am trying to build 2 separate versions of single package - release and nightly. They differ (primary) by SRC_URI, but not only. So I created 2 packages - foo-release and foo-nightly. Both of them PROVIDES+="foo". Jun 02 10:29:46 but when I use IMAGE_INSTALL += "foo", it doesn't work Jun 02 10:29:49 what am I doing wrong? Jun 02 10:30:48 resp. I created 2 distro configs, release contains PREFERRED_PROVIDER_foo = "foo-nightly/release" and then I am installing package "foo" for specific distro Jun 02 10:32:26 I ends with "Required build target 'my-image' has no buildable providers. Missing or unbuildable dependency chain was: ['my-image', 'foo'] Jun 02 11:04:51 nevermind, I found workaround Jun 02 17:51:40 Hey I am currently working on an openembbeded project and when I run bitbake, I get an error saying "cannot parse gnome-vfs_2.24.4.bb" I also see there is a syntax error in that same file on the line "print d.getVar('FILES_gnome-vfs', 1)" Jun 02 17:51:47 Any advice? Jun 02 17:55:06 what version? Jun 02 17:55:39 paul_: most likely you updated to current master, which requires python 3, and not all layers have their inline python updated to 3 Jun 02 17:55:46 the print statement isn't valid in python 3, only the print function Jun 02 17:55:54 that is, print(d.getVar()) instead of print d.getVar() Jun 02 17:56:34 * kergoth fixes meta-sourcery & meta-mentor Jun 02 18:01:49 That makes sence kergoth, but how to I apply these fixes. I'm assuming they are seperate repositiories, so where do I include them in my directory tree? Jun 02 18:02:15 again, it's likely not all layers have been updated to fix this. python 3 was *just* merged in the past day Jun 02 18:02:22 there's always a delay as third party layers catch up to oe-core Jun 02 18:02:48 if after updating all your layers sto current master the problem remains, then either revert the switch to python 3 in oe-core/poky/bitbake, or wait for upstreams to fix their layers, or fix them yourself Jun 02 18:03:12 how you update your layers completely depends on how you got them in the first place. there are a ton of ways of managing repositories, manual clones/updates, repo, submodules, etc Jun 02 18:03:39 or if you want something more stable, use krogoth branches, whcih is the most recent stable release, rather than master Jun 02 18:04:20 okay, thanks. I'll look into this. Jun 02 18:06:29 personally, when developing mentor's product, i only pull updates from upstream on a weekly basis, and each time i do so i have to validate that the layers are in sync and nothing broke, and if an upstream layer is out of sync with oe-core i postpone the updates Jun 02 18:06:47 perils of tracking master with multiple repositories maintained by multiple people/companies. nature of the beast Jun 02 18:08:34 I guess thats just wht I get for syncing recklessly Jun 02 18:12:01 paul_: could always revert the update, either manually or by using ORIG_HEAD or the git reflog Jun 02 18:12:12 but yeah, never know if you'll hit breakage, always a possibility Jun 02 18:15:22 repo status Jun 02 22:50:47 OK, silly question Jun 02 22:50:50 https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/ifupdown/ifupdown_0.8.2.bb Jun 02 22:51:05 There's not actually an initscript in here 'tho, is there? Jun 02 22:51:10 Since it's all in the init-ifupdown package Jun 02 22:51:54 And when you build ifupdown the only "ifup" is the binary itself **** ENDING LOGGING AT Fri Jun 03 02:59:58 2016