**** BEGIN LOGGING AT Fri Apr 04 02:59:59 2014 Apr 04 06:55:06 <_valle_> Using the layer meta-qt5, master branch. Trying to build a Qt Quick application. When starting the application it outputs: module "QtQuick" is not installed. If I set qtquick under DEPENDS variable the output is Nothing PROVIDES 'qtquick'. Close matches: qtquick1 Apr 04 06:55:32 <_valle_> What am I missing here? Apr 04 06:57:30 <_valle_> What shall I set in the recipe to build a Qt Quick 2 application? Apr 04 07:35:41 good morning Apr 04 07:38:38 <_valle_> good morning Apr 04 07:40:33 <_valle_> What shall I set in a recipe to build a Qt Quick 2 application? Apr 04 07:42:21 <_valle_> Using the layer meta-qt5, master branch. Trying to build a Qt Quick application. When starting the application it outputs: module "QtQuick" is not installed. If I set qtquick under DEPENDS variable the output is Nothing PROVIDES 'qtquick'. Close matches: qtquick1 Apr 04 07:42:47 _valle_: no clues sorry Apr 04 07:52:18 We've included X server in our image build, and we get a terminal window with sh when the device boots. Now how can we get an application to autostart *in that X terminal* ? Apr 04 07:52:45 I've tried editing .profile, .Xsession etc Apr 04 07:53:05 I can get the application to autostart, but not in the X window Apr 04 08:32:34 morning all Apr 04 09:09:39 <_valle_> Hi I can't get qtdeclarative-examples to run from meta-qt5, master branch. Apr 04 09:10:00 <_valle_> The error given is module "QtQuick" is not installed Apr 04 11:19:45 very interesting finding: pastebin.com/0Ku6FEHn Apr 04 11:20:25 I did in Yocto 'CFLAGS_append_class-target += "-Xassembler -MYFLAG=yes"' Apr 04 11:20:44 and some stuff was inserted between 'Xassembler' and 'MYFLAG' Apr 04 11:21:00 that looks insane Apr 04 11:21:19 it's on dylan though, I know I'm oldtimer Apr 04 11:24:26 maybe it's because of not really valid syntax 'append' and += on one line Apr 04 11:31:26 Xz: well, append with += isn't going to do anything other than adding a space; it wouldn't explain anything going between those values though Apr 04 11:39:26 i wrote a kernel module. i took the hello-mod as the example. this worked great, but the module isnt loaded automatically. after booting the system i have to perform a modprobe mudulname, and its loaded. what did i miss? Apr 04 11:51:29 ahhh, i think that i missed then RDEPENDS_${PN} = “ modulename” ? right? Apr 04 12:17:20 that doesn't effect module loading Apr 04 12:17:46 if its for hardware then you autoprobing is broken, if its just a module that you need to load then you need to ask the kernel to load it on boot Apr 04 12:17:47 yes i found out, that i have to integrate some parts to the machine conf Apr 04 12:17:56 like module_autoload Apr 04 12:18:08 but that isnt what i really wanted to do … Apr 04 12:21:12 just edit a file in /etc/modprobe.d Apr 04 12:26:33 Hi folks Apr 04 12:27:43 hi otavio Apr 04 12:28:14 ah, that sounds even better Apr 04 12:28:19 i’ll give it a try Apr 04 12:47:58 bluelightning: I have exactly same result with CFLAGS_append_class-target = " -Xassembler -MYFLAG=yes" :( Apr 04 12:48:27 bluelightning: meaning something gets inserted between 'Xassembler and MYFLAG' Apr 04 12:49:55 -Xassembler -feliminate-unused-debug-types -fmerge-all-constants -frounding-math -g -MYFLAG=yes Apr 04 12:50:05 Xz: right, I didn't think that would be causing that Apr 04 12:50:31 -Xassembler -feliminate-unused-debug-types does not make any sense, since -feliminate-unused-debug-types is gcc flag, not gas Apr 04 12:50:57 my point is it cannot come from any Makefile, since that construction would never work Apr 04 12:51:11 Xz: well this is CFLAGS so you'd expect these to go to gcc... Apr 04 12:51:30 yes, but Xassembler passes whatever next argument into as Apr 04 12:51:46 right, ok Apr 04 12:52:31 Xz: which recipe is it where you're seeing this? Apr 04 12:54:30 eglibc-initial Apr 04 13:00:00 Xz: I think maybe you should be using TARGET_CFLAGS_append = ... Apr 04 13:00:08 that may not help this though Apr 04 13:00:48 it could be that eglibc's build is doing its own mangling on the CFLAGS value Apr 04 13:01:31 bluelightning: you are right, I should take a look what eglibc does to CFLAGS Apr 04 13:01:44 bluelightning: it definately overwrites SELECTED_OPTIMIZATION Apr 04 13:36:32 hi, can somebody tell me how to log which commands are executed when doing run_patch with bitbake? run.do_patch says: bb.build.exec_func('patch_do_patch', d) but should this be something like patch -Np1 ... ? Apr 04 13:39:31 yenal: do_patch is a python function and is defined from patch_do_patch in meta/classes/patch.bbclass - I don't think there's an easy way to get the log of commands from it but you may find looking at the class helps Apr 04 13:39:49 yenal: what's the problem you're having? Apr 04 13:41:26 I'm trying to port some wandboard drivers from yocto to archlinxu arm, e.g for mesa is try to use the patches from yocto but I got some Hunks Apr 04 13:42:00 I think I just entered a wrong patch command Apr 04 13:44:30 yenal: check the pnum or striplevel specified in the recipe, that's what should be specified for -p Apr 04 13:44:35 there shouldn't be much more to it Apr 04 13:44:51 (if it's not specified it defaults to 1) Apr 04 13:47:20 with 1 i got Hunks Apr 04 13:48:41 is pnum/strip the DEFAULT_PREFERENCE in the recipe? Apr 04 13:50:20 _valle_, do you have "qtquickcontrols-qmlplugins" package installed in your image ? Apr 04 13:50:38 can someone help guide me a little bit on adding a layer to patch a ti kernel? I think I'm close but must be missing something Apr 04 13:52:07 my later is called "spin1" Apr 04 13:52:13 details: http://pastebin.com/5P1ppWEt Apr 04 13:56:54 yenal: no, DEFAULT_PREFERENCE is something completely unrelated Apr 04 13:57:39 yenal: if some hunks fail to apply that means the source you're patching is not the same as the source we're patching, you'll have to fix up the patches so they apply Apr 04 13:58:38 ripperD: is that not working? Apr 04 14:00:34 I see, okay thank you bluelightning Apr 04 14:01:17 _valle_, or actually, "qtdeclarative-qmlplugins" Apr 04 14:02:33 bluelightning: I didn't see it recompile the kernel after I ran bitbake core-image-minimal Apr 04 14:03:55 ripperD: is it really under recipies-kernel or recipes-kernel ? Apr 04 14:04:03 if the former, that would prevent it being picked up Apr 04 14:05:08 bluelightning: *facepalm* yes I copy pasted my real path. So hopefully its just a spelling error. Will rename! Apr 04 14:07:45 ripperD, maybe you should file a bug about bitbake not complaining when given odd looking paths ? :-) Apr 04 14:08:56 kroon: well that's the thing, bitbake is designed to be super-flexible but it makes detecting things like this a bit difficult Apr 04 14:09:30 i.e. recipes are found via BBFILES, and we pretty much set that to ${LAYERDIR}/recipes-*/*/*.bb Apr 04 14:10:25 could be that we need to think about simplifying some of this going forward to make it easier to use though... Apr 04 14:13:23 bluelightning, right Apr 04 14:13:57 ok, its actually re-doing the kernel now, we'll see if my patch works! Apr 04 14:16:35 bye all Apr 04 14:24:22 Question: I'm going through the "Hello World" example from the OpenEmbedded User Manual, but I'm not able to get the executable installed in the image. I can get an Autotools "Hello World" program to install in the image, but not one that just uses a Makefile. I'm wondering if I need to do something extra besides a do_install() in the recipe? Apr 04 14:25:08 Should I use IMAGE_INSTALL_append or is that a "use at your own risk sort of thing?" So far that hasn't helped, but I was putting it in the recipe. Apr 04 14:29:32 daren: do you mean the OpenEmbedded user manual or the Yocto Project manuals? the OE manual is very out-of-date Apr 04 14:30:03 The OpenEmbedded manual. I have discovered a few places where it was out of date, yes. Apr 04 14:30:30 I'd honestly recommend not referring to it at all, these days I don't think there's much in it we don't cover in our manuals Apr 04 14:31:01 if your issue is dependent on the type of build system the recipe is using (autotools vs. make) it sounds like maybe you aren't properly defining a do_install for the make case Apr 04 14:31:21 Is there a place in the Yocto manuals that goes into more depth about Makefile-only projects? The Autotools examples are great, but the code I'm working with would be a lot of work to switch over Apr 04 14:31:49 daren: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-addpkg-makefile Apr 04 14:32:54 Okay, that's a very different do_install function Apr 04 14:32:57 your do_install could be as simple as running oe_runmake install (perhaps supplying DESTDIR=${D} or similar), but it does need to be defined Apr 04 14:33:13 it's going to be specific to how whatever you're building needs to be installed Apr 04 14:33:32 right now it's just helloworld and a Readme.txt :) Apr 04 14:34:21 I'll give this a try and see what happens. Apr 04 14:34:25 Thank you Apr 04 14:35:09 By the way, is the use of IMAGE_INSTALL_append recommended or is it a "use with caution" type of thing? Apr 04 14:42:22 daren: it's mostly OK; there is a caveat though in that if you set it from local.conf rather than an image recipe, it affects all recipes; if you're building an initramfs image that is of course also included, and that's usually not desirable Apr 04 14:43:42 what distinguishes between an image recipe and a package recipe? Apr 04 14:45:12 an image recipe is what specifies what goes into the image Apr 04 14:45:34 so if you do bitbake core-image-minimal, that corresponds to meta/recipes-core/images/core-image-minimal.bb Apr 04 14:45:57 mostly image recipes just set IMAGE_INSTALL and inherit image or core-image Apr 04 14:46:21 bluelightning, Okay, so I'm writing a package recipe in most cases Apr 04 14:46:40 right, you tend to only have one or a few image recipes as needed Apr 04 14:48:04 Now I have created my own meta layer for my hello world examples. At one point I added IMAGE_INSTALL_append = " hello" to the layer.conf file. Is that an image recipe change or more along the lines of local.conf? Apr 04 14:48:43 I'd recommend you create your own image recipe instead Apr 04 14:49:05 (and put that in your meta-layer as well) Apr 04 14:49:23 in a bb file or bbappend or does it matter? Apr 04 14:52:30 I generally recommend just creating recipe .bb files (copy and modify an existing one if you wish) - they're normally so trivial it's not worth bbappending an existing one Apr 04 14:58:45 when my image boots, I get an X server and a window named "Terminal" running sh. But I can't find the binary xterm anywhere. (anywhere being /usr/bin). Isn't xterm included if X server is? And if not, what am I seeing on the screen? Apr 04 15:00:01 xerent: matchbox-terminal I would think Apr 04 15:01:01 ah, you don't happen to know which config/script passes arguments to that? I want to run stuff in that window on boot. thanks Apr 04 15:03:16 bluelightning: Interesting, I pulled the IMAGE_INSTALL_append from my layer.conf file (for the Autotools "Hello World") so that it was only in the recipe, and now that doesn't get installed in the image either. Hmmmm Apr 04 15:03:53 daren: modifying IMAGE_INSTALL in a recipe that isn't the image recipe you're building won't do anything Apr 04 15:04:15 one recipe cannot affect another recipes' variable values Apr 04 15:05:09 Okay, so if meta-daren has hello.bb, do I need a..... meta-daren.bb file? Apr 04 15:07:23 daren: probably you'd have a daren-image.bb or similar Apr 04 16:03:15 bluelightning: I am just not having any luck. I created a "daren-image.bb" recipe with 'IMAGE_INSTALL += " hello hello2"' in it, but neither version of "Hello World" gets installed now. Unless I add the install line to the layers.conf file, the images just aren't installed. That doesn't seem right. Apr 04 16:03:44 daren: are you doing "bitbake daren-image" ? Apr 04 16:04:13 no, I'm baking another image... my meta layer is part of it though Apr 04 16:04:36 so you need to be building this image Apr 04 16:05:00 just a change in the bitbake command line you use Apr 04 16:06:15 Okay, but that's not what I'm trying to do. I'm adding my layer to another image and trying to install executables from my layer into that image. Does that make sense? Maybe I'm confused Apr 04 16:08:02 daren: perhaps, because you don't really add a layer to an image, you add a layer to your build (by adding it to bblayers.conf) and then add packages to an image Apr 04 16:08:33 yes, I did add the layer through bblayers.conf Apr 04 16:08:49 it's the packages to an image part I can't seem to get Apr 04 16:09:28 well, touching all images by adding to IMAGE_INSTALL in layer.conf isn't the right thing to be doing Apr 04 16:09:56 the proper thing if you want to have a custom image with your packages in it is to create an image recipe as you have done, and build that Apr 04 16:10:49 In this case I'm trying to add my stuff to the image.... not necessarily customize it per say Apr 04 16:11:11 good to know that editing the layer.conf file was not right, I didn't think it was Apr 04 16:13:20 daren, you remembered to inherit one of the image classes in your daren-image.bb recipe ? Apr 04 16:13:40 kroon: if that's not the recipe being built it's a moot point ;) Apr 04 16:15:13 bluelightning, amen to that Apr 04 16:21:45 daren, in case you havent seen it, http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#usingpoky-extend-customimage Apr 04 16:23:42 kroon: I've seen that, but haven't fully understood it yet. Does this mean I should have a local.conf file in the conf dir of my layer that does the image_install_append? Apr 04 16:24:58 daren, as bluelightning said, it is your image recipe that should do the image_install_append thing Apr 04 16:26:14 daren: you wouldn't add conf/local.conf to your layer, no Apr 04 16:26:41 daren: if you're just testing something, by all means add IMAGE_INSTALL_append = ... to your conf/local.conf in your build directory Apr 04 16:26:45 the image recipe I'm working with pulls from many different layers. I"m just trying to be another cog in the system though. Doesn't seem like I should have to touch the image's files. Just say "hey, I've included my layer and here's my stuff too" Apr 04 16:27:04 I'm testing the process now, but this will be long term Apr 04 16:27:48 daren: in which case you wouldn't normally try to insert packages into all images like that, you'd have your custom image(s) and put whatever packages you want into that Apr 04 16:27:56 thought I would start with something simple before bringing in all the rest of my code Apr 04 16:28:22 daren: it doesn't matter which layer the recipes producing the packages come from, if that's what's concerning you Apr 04 16:28:54 daren: right, and you have complete control over the packages you include in the image either way Apr 04 16:29:29 I guess I don't understand how the packages are included..... I don't see one giant list somewhere that's missing my new additions Apr 04 16:30:45 daren: IMAGE_INSTALL is that list Apr 04 16:31:06 well, it's the list of packages that go into the image Apr 04 16:35:38 bluelightning, I'll try that again. I'll put IMAGE_INSTALL += " hello" in a daren-image.bb file in my meta-daren/recipes-daren directory and see what happens Apr 04 16:44:33 bluelightning: Nope, that didn't work. I'm confused now. Apr 04 16:44:45 daren: what image did you build? Apr 04 16:45:12 same one I've been building. It's a custom one from somebody else Apr 04 16:45:35 so, we're going down the wrong path Apr 04 16:45:47 if that's the image you must build, that is the one you must modify Apr 04 16:46:05 I did modify it enough to include my layer Apr 04 16:46:06 or you create another image and build that Apr 04 16:46:25 basically I want my stuff to be part of that image, not create a new one Apr 04 16:46:40 right, and that's fine Apr 04 16:47:17 but the image doesn't include a layer - it may include packages produced by recipes from a layer, yes Apr 04 16:47:23 So in the bblayers file for that image, I added my layer. Thought that was it. Apr 04 16:47:36 It has several layers Apr 04 16:47:49 yes, right, but that's not the image, that's for your build Apr 04 16:47:56 oh Apr 04 16:48:34 there are two separate steps - add the layer to the build, then add appropriate packages to an image Apr 04 16:49:02 adding the layer alone just makes the recipes contained within it available to be built, and not much more Apr 04 16:49:16 okay, so there's another file to edit? Apr 04 16:49:29 the custom image you just referred to, yes Apr 04 16:49:35 the one you're building Apr 04 16:56:50 That file uses package-management.... not sure what to do with that, so I might have to wait until Monday. Thanks for all of your help. Sorry for the trouble. Apr 04 17:08:02 daren: that doesn't make a difference Apr 04 17:08:49 daren: i.e. you'd add the same thing to IMAGE_INSTALL in the same way regardless of whether package-management is in IMAGE_FEATURES Apr 04 17:53:33 I have my own yocto layer with my own *image.bb. I changed the PREFERRED_VERSION for a package (PREFERRED_VERSION_gstreamer1.0-plugins-base = "git"), but nothing was rebuilt when I did a "bitbake *image.bb". Do I have to "bitbake cleansstate" or something? Apr 04 17:54:30 it's highly unlikely that there's a version of that recipe whose version is 'git' Apr 04 17:56:33 I do have meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_git.bb here.. Apr 04 17:56:52 yes, but the real PV isn't 'git' Apr 04 17:57:04 aha Apr 04 17:57:45 see PV = in the recipe, then use a % pattern in the PREFERRED_VERSION. e.g. PREFERRED_VERSION_u-boot-sabre-sd = "2013.01+gitr%" Apr 04 17:59:37 It looks like it is working now: I had to move the PREFERRED_VERSION lines from my *image.bb file to my local.conf file. Looks like it is "working" simply with "git", but I don't yet know exactly what it is doing. I was following the recommendations here: https://github.com/dv1/meta-gstreamer1.0 Apr 04 18:32:23 Jefro, We could look into booking Food trucks for OEDAM Apr 04 18:32:43 http://roaminghunger.com/sjc Apr 04 18:39:49 santa clara, california... Apr 04 18:40:07 lucky americans Apr 04 19:16:11 gah, i have a ton of failing setscenes due to tarballs that don't exist... okay, fine, but why did it think the setscenes were runnable at all, then? :) Apr 04 19:29:05 is there an easy way to enable kernel modules? The only way I found was by creating and own kernel config Apr 04 19:39:47 volker-: you can use config fragments to change just the kernel config options you're interested in Apr 04 19:40:20 bluelightning: can you please be more specific? Apr 04 19:41:02 bluelightning: here is my goal: the x86 kernel does not come with any modules, e.g. modules for the network cards Apr 04 19:44:22 volker-: this may be helpful: http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#changing-the-configuration Apr 04 19:45:51 bluelightning: that seems to be kinda complex and leads to using menuconfig to figure it out Apr 04 19:48:08 volker-: it's really not that complicated; but in any case you have the option of launching menuconfig, changing it there and supplying the full config that that saves out Apr 04 19:48:39 bluelightning: looking into the meta-intel/meta-nuc folder it seems that I have to touch every kernel an Apr 04 19:49:27 and looking in this meta-nuc config I still do not understand how it is really working Apr 04 20:57:29 Hi Apr 04 20:57:50 I'm having minor trouble with kernel features on 'master' Apr 04 20:58:47 It seems like aufs is not standard in the 'master' kernel - it was on dora. So waht I'm doing is to add this to my local linux-yocto_3.14.bbappend Apr 04 20:58:53 KERNEL_EXTRA_FEATURES_append = " features/aufs/aufs.scc" Apr 04 20:59:47 But it does not work. .config is not changed to include the CONFIG_AUFS_* flags. The kernel is patched with the aufs sources though..... Apr 04 21:00:08 Any ideas/hint would be very much appreciated. Apr 04 21:10:33 zeddii: ^ is that expected? Apr 04 22:10:47 is it save to put kernel-module-xxxx in IMAGE_INSTALL_append? Apr 04 22:13:16 yes Apr 04 22:13:47 I saw it so far only in MACHINE_EXTRA_RRECOMMENDS Apr 04 22:14:40 you can put it anywhere, it's just another package Apr 04 22:14:51 kk. thank you :) Apr 04 22:14:52 often they're machine specific which is why they go there **** ENDING LOGGING AT Sat Apr 05 02:59:58 2014