**** BEGIN LOGGING AT Thu Dec 05 02:59:58 2013 Dec 05 05:03:42 hi all i have been using poky with meta-atmel,i have given all proper parameters in /meta-atmel/conf/machine/at91sam9x5ek.conf to create a ubi when compiling rootfs,it was working fine,but it creates only ext3 and tar but not ubi,this is my http://pastebin.com/JTfjRJxm conf file can you tell me where i did mistakes? Dec 05 05:19:05 hi anybody can you help me to solve this issues? Dec 05 06:13:41 JaMa, have you seen my query? do you have any idea Dec 05 08:37:06 good morning Dec 05 09:08:45 hi, im using the bb of libsdl and modified it so far that it uses the 2.0.1version, but now i'd like to try using the developer version directly from mercurial. Can i modify the bb file to get it directly from there? Dec 05 09:22:08 rayo: there are git and svn fetchers, not sure about hg Dec 05 09:23:36 i tried to set SRC_URI to hg://hg.libsdl.org/SDL but yocto gives an error: URL '...' is missing the required parameter 'module' Dec 05 09:23:41 no idea what that means Dec 05 09:24:24 no hg module would be my guess... Dec 05 09:25:04 you could make your own local git repo Dec 05 09:26:01 never done hg2git but it works pretty well with svn Dec 05 09:27:26 i just did a workaround, checked out the current hg rev, made a tar.bz2 file and set SRC_URI to file://path-to-file Dec 05 09:27:29 seems to work Dec 05 09:35:39 even easier... Dec 05 10:15:32 rayo: sounds like the hg fetcher wants a ;module=xxx in the url. Not sure what that would be for the SDL repo in question Dec 05 10:16:46 morning all Dec 05 10:17:05 thanks, i've solved it with creating a file from hg revision. It's just a test if the i can solve my problems with the newest version of the library Dec 05 13:55:00 I tried exporting env variable from 'do_config' function inside a recipe, getting "export: `=': not a valid identifier" error Dec 05 13:56:13 however this works from outside of function Dec 05 13:57:04 * Xz concerned Dec 05 13:58:05 just a simple: export foo = "bar" Dec 05 14:13:09 Xz: valid shell syntax would be export foo="bar" (no spaces around =) Dec 05 14:13:54 Xz: it's different outside of a function because there you're setting a bitbake variable (as well as marking it for export) Dec 05 14:17:03 Hi! I'm trying to upgrade the linux kernel on my gumstix device to 3.10.22 due to problems with crashes on earlier kernels. I've configured the kernel and got my config file, and placed it as defconfig in a new recepie. When I run "bitbake -s | grep linux" I see that "linux-gumstix" is " 3.10.22". Yet, my build results in my old kernel 3.5.7. Any ideas what I might be missing? Regards Dec 05 14:19:21 bluelightning: yeah just figured it out, silly me Dec 05 14:19:56 bluelightning: I registered that name, Krz was already taken by someone Dec 05 14:20:03 bluelightning: anyway Dec 05 14:20:35 Xz: oh, hey krzysztof :) Dec 05 14:22:05 erija952_: I'd suggest doing bitbake -e | less and searching for PREFERRED_VERSION_linux-gumstix (assuming the 3.5.7 kernel is also linux-gumstix) Dec 05 14:31:06 bluelighttning: Thanks. "bitbake -e | less" did not give anything. Maybe the problem was that i've specified PREFERRED_VERSION_linux-gumstix = "3.10%" instead of PREFERRED_VERSION_linux-gumstix = "3.10.22". Building again now... Dec 05 14:38:22 What's the difference between 'require something' and 'include something' in a bb file ? Dec 05 14:42:10 eballetbo: include won't error if the file can't be found, require will Dec 05 14:43:26 bluelightning: thanks :) Dec 05 14:43:36 bluelightning: After editing my conf file, "bitbake -e " shows "PREFERRED_VERSION_linux-gumstix = "3.10.22"", yet I get 3.5.7 stuff in my kernel, (for example under /sysroot/overo/lib/modules). Any additional ideas? Dec 05 14:44:58 erija952_: what is PREFERRED_PROVIDER_virtual/kernel ? Dec 05 14:45:37 bluelightning: PREFERRED_PROVIDER_virtual/kernel="linux-gumstix" Dec 05 14:46:17 erija952_: when you say /sysroot/ what do you actually mean? Dec 05 14:47:51 bluelightning: I meant the stuff under the build directory: tmp/sysroots. But I've also let the build finish and when flashing my device, uname -r gives 3.5.7 aswell Dec 05 14:48:33 erija952_: I honestly don't know how that could happen... Dec 05 14:48:53 erija952_: are you getting any error telling you the preferred version you've set is unavailable? Dec 05 14:49:08 well, not an error, a warning Dec 05 14:49:55 No, no warnings. And then it builds it seems like it building 3.10.22-r1 like I want Dec 05 14:57:28 I built a qt4e-demo-image for beaglebone black and the lcd cape didn't work, I have to enable something for the cape? Dec 05 15:02:07 the app I'm trying to create recipe for, called xpra uses weird setup.py instead of Makefile. That setup.py uses pkg-config to figure out environment. However that pkg-config calls refer to -native env instead of cross-compiled env. Is there any way I can call 'pkg-config' to get cross-compiled env instead of native? Dec 05 15:02:49 Xz: try "inherit pkgconfig" Dec 05 15:03:01 bluelightning: is it that easy? cannot be :) Dec 05 15:03:31 well, if it's just running "pkg-config" it should be Dec 05 15:11:06 bluelightning_: strange, with or without 'inherit pkgconfig' apparently recipe uses proper one: tmp/sysroots/x86_64-linux/usr/bin/pkg-config; however still complains about missing pygtk-2.0 which is present under tmp/work/i586-poky-linux Dec 05 15:11:26 bluelightning_: maybe somehow python-gtk didn't register itself in pkg-config database? don't really know how pkg-config works Dec 05 15:11:33 Xz: it might be that Dec 05 15:11:49 Xz: you could always just hack the check out of setup.py, we've had to do that sometimes Dec 05 15:11:55 (using a patch) Dec 05 15:36:42 There is a python-cython recipe in meta-oe which is version 0.15. I created one in my layer targetting version 0.19. How do I prioritize my recipe over older one? Dec 05 15:38:54 Xz: if your layer has the same or higher layer priority it will take precedence Dec 05 15:39:57 bluelightning: that's the only place I can play with? Isn't there any per recipe variable to determine which version takes priority? Dec 05 15:40:24 Xz: yes, you can do PREFERRED_VERSION_python-cython = "0.19" in your distro config Dec 05 15:40:39 bluelightning: that sounds Dec 05 15:41:11 bluelightning: can I do bbappends to distro.conf files? Dec 05 15:41:14 bluelightning: :) Dec 05 15:41:18 Xz: you can't, no Dec 05 15:42:06 Xz: but why would you need to? Dec 05 15:54:50 bluelightning: to have 'PREFERRED_VERSION_' inside my layer only Dec 05 15:55:21 bluelightning: right now I'm using few layers, the config file comes from layer1 and python-cython recipe is in another Dec 05 15:55:56 if you want your layer to get its recipes used in preference to recipes from other layers, by default, you'll want to bump its priority Dec 05 15:55:59 * kergoth yawns Dec 05 15:58:38 Xz: really you should be controlling these things from your distro layer, which knows which layers it's expected to be used with Dec 05 16:04:07 bluelightning: that makes whole thing way more stiff. For me perfect scenario would be to let 'DEPENDS' variable contain version number, because then more less every recipe is self-contained, indepedent. If I control everything from one file in one layer then it gets less modular Dec 05 16:04:56 bluelightning: idea of Yocto and layers is to make it modular, why limit that feature? Dec 05 16:08:39 Xz: the distro config is where you set policy like this, that's the design of the system Dec 05 16:09:18 Xz: that doesn't remove modularity; if the recipe isn't present at all because you build it without the layer containing the recipe, that won't cause any problems Dec 05 16:12:35 bluelightning: The thing is that it's not the distro that requires specific version of specific package. It's the package requiring some version of other package. Logically that information should be hidden inside package recipe. I understand and totally agree of using distro.conf for global things like TCLIBC or pkg manager. Dec 05 16:13:07 bluelightning: or preferred libc version (still global thing) Dec 05 16:14:49 bluelightning: in case of changing layers information about PREFERRED_VERSION_packageA from distro.conf will silently disappear Dec 05 16:18:14 letting depends hold a version opens up a huge can of worms related to potentially conflicting version specific requirements, and bitbake wanting to build multiple versions in a single build directory, which isn't possible, and even if it was, would cause problems. it's doable, but non-trivial. patches to bitbake to add support for such a thing would almost certainly be welcome Dec 05 16:20:51 kergoth: let's take it from the other side. What if any recipe would be allowed to set PREFFERED_VERSION of a package and bitbake would just choose the highest one? Assumption here is that PREFFERED_VERSION is always used to increase number, never to decrease Dec 05 16:26:37 recipes aren't allowed to control one another by design. PREFERRED_VERSION is global configuration metadata, not recipe metadata. it's not a recipe's job to control what the system builds, only to specify what it needs Dec 05 16:29:39 kergoth: exactly, to specify what it needs. If recipe needs a package version 123 it needs that for a reason. Obviously it means recipe will not build with package version 122 Dec 05 16:30:12 as i already said, there would be value in such a thing, but it'd be decidedly non-trivial, you're welcome to implement it Dec 05 16:30:43 kergoth: I presume that would be kind of design change Dec 05 16:31:39 i guess it would "just" be allowing versioning in DEPENDS and then logic to filter out unbuildable recipes Dec 05 16:31:51 not necessarily. it'd just be expanding the capabilities of the build time dependency variables, enhancing the scheduler to make use of that information, and potentially enhancing the config variables to let you exert control in the case of a conflict Dec 05 16:31:57 with the trick being that you don't build the same library twice Dec 05 16:32:11 easy! patches welcome. :) Dec 05 16:33:00 we ahve utility functions that parse version specific deps out of the vars, we just throw that info on the floor today if we find it, iirc Dec 05 17:38:55 moin Dec 05 17:43:46 hi Dec 05 21:13:00 hmm shouldn't global "d" be always defined? Dec 05 21:13:17 this fails when called from shell task: expansion of get_tools threw ExpansionError: Failure expanding variable get_tools, expression was ICECC_CC="${@icc_get_and_check_tool_native(bb, d, 'gcc')}" Dec 05 21:13:25 which triggered exception NameError: global name 'd' is not defined Dec 05 21:13:35 but the same line works fine in different shell function Dec 05 21:17:46 whole patch here http://bpaste.net/show/155875/ Dec 05 21:20:05 JaMa: i've seen a couple cases where d is undefined when it should be defined, iirc when i tried to use it from an anonymous python block in a vardeps flag Dec 05 21:20:11 might be different than what you're seeing, though Dec 05 21:21:50 yes my case seems a bit simplier than that Dec 05 21:22:20 yeah, in that context it should absolutely be there, that's worrisome Dec 05 21:23:34 I've sent longer description to ML http://lists.openembedded.org/pipermail/openembedded-core/2013-December/087306.html Dec 05 21:23:58 interesting bit (IMHO) is that bitbake doesn't end with fatal error, but prints error only inside other bitbake -e output Dec 05 21:54:25 Hey guys ... can anyone answer a networkmanager question for me? Dec 05 21:55:01 you would probably need to ask the question first ;-) then maybe someone can answer it! Dec 05 21:55:08 Does anyone know if a recipe for network manager > 0.9.6 Dec 05 21:55:41 did you check the layer index? Dec 05 21:55:48 I did ask a question ;-) Dec 05 21:56:06 how do I check the layer index Dec 05 21:56:09 http://layers.openembedded.org/ Dec 05 21:57:07 cool thanks .. Dec 05 22:03:15 how do i get clone files in layers.openembedded.org Dec 05 22:03:24 "git" that is .. Dec 05 22:24:47 brm: the urls are all on the site.. Dec 05 22:38:57 we're going to classify them as work in progress.. rejected by the community (but we're going to maintain)... or stuff that should go in and hasn't yet Dec 05 22:39:02 oops Dec 06 00:21:02 hi guys, how do I get nmcli to assign eth0 a static address (using 0.9.8 version of NM) Dec 06 00:28:26 anyone help me with network manager nmcli? Dec 06 00:33:32 anyone help me with network manager nmcli? **** ENDING LOGGING AT Fri Dec 06 02:59:58 2013