**** BEGIN LOGGING AT Mon Apr 18 02:59:58 2016 Apr 18 06:35:15 hi. is there any way to build a device tree (dts -> dtb) without fetching and rebuilding the entire kernel? Apr 18 06:36:00 i have a recipe with a custom device tree, and each time i do any changes the entire kernel is fetched and recompiled which takes several minutes Apr 18 06:46:55 ionte: you can always manually do it using the dtc tool that gets generated on the fly, but i think theres no proper way of taking that short cut within the OE build process. Apr 18 06:56:05 good morning Apr 18 06:56:51 hi guys Apr 18 07:06:54 i'd like to create a compressed .rootfs.ext3 by using mkzftree & mkisofs but i can't find the rootfs dir. i thought it was /path/to/yocto/build/tmp/work/arch/image/rootfs but this directory remains empty after the "do_rootfs" task. Apr 18 07:07:25 i could probably mount the rootfs.ext3 to a tmp directory but i don't want to run bitbake as root. do you guys have any suggestion? Apr 18 07:26:55 Any hints on how to install the eclipse ADT plugin? Tried it on a fresh CDT Mars.2 download of Eclipse and got a very unhelpful error. Apr 18 07:29:19 "The installation cannot be completed as requested" Apr 18 07:41:31 Is there a picture or something somewhere that shows the "description hierarchy" of a yocto-project - say, Poky? Apr 18 07:42:45 description hierarchy ? Apr 18 07:46:12 Well, I understood that the generation is based on description of which layers are included, then the descriptions of what the layers consist of. Apr 18 07:48:36 I see bblayers.conf, layer.conf and recipies as descriptors. Apr 18 07:49:03 (layer.conf-files) Apr 18 07:49:51 Maybe I got it all wrong? Apr 18 07:54:09 I think you got the idea, but it hasn't matured in your head yet :) Apr 18 07:54:37 moreover these are not the terms we use to describe it, so your description will confuse people on IRC which won't help as well as they could Apr 18 07:54:49 turboscrew: those files determine what can be built, how it's built and to some extent priority between them (layers have priorities for instance). You still specify what to actually build in your bitbake command. Apr 18 08:00:34 turboscrew: the closest to what you are asking for (IIUC) would be to run "bitbake -e" or "bitbake -e " Apr 18 08:01:25 yocto first parses a whole bunch of files (including the various layer.conf) to create an environement which is a big bunch of key=value pairs Apr 18 08:02:06 then it looks on the command line, and expand the environement with another big bunch of key=value comming from the recipe you are asking to build Apr 18 08:02:21 (the above is false, but it helps understanding) Apr 18 08:02:36 the first command will give you the "common" part of the environement Apr 18 08:02:48 the second part will give you the environement for a specific recipe Apr 18 08:04:03 Thanks, boucman_work. I'll try those. Apr 18 08:12:11 is there anything you can pass to local.conf to tell it to handle all git:// src uri with protocol=http append? Apr 18 08:20:05 CTtpollard: i did it for github ones, PREMIRRORS_append = "\n git://github.com/.* git://github.com/PATH;protocol=https" Apr 18 08:22:58 it's not for github, but I have a server that's having problems fetching over git Apr 18 08:23:06 but adding protocol=http is working Apr 18 08:23:13 wanted to temp fix it in local conf Apr 18 08:23:43 I wil try that out Apr 18 08:24:04 so it''s just for one recipe ? Apr 18 08:24:39 nope, multiple Apr 18 08:24:41 in that case, you can add SRC_URI-pn_= in your local.conf Apr 18 08:24:43 same server Apr 18 08:24:49 ah, ok, then it's more complicated :P Apr 18 08:29:49 CTtpollard: have you tried this: PREMIRRORS_append = "\n git://.* git://PATH;protocol=http" ? Apr 18 08:30:04 s54: about to try it now Apr 18 08:30:41 this will probably not work with SRC_URIs that already contain protocol=http or any other one. don't really know how bitbake will handle this Apr 18 08:32:21 s54: I've taken your github example and switch it to the server I need it for Apr 18 08:32:23 lets see **** BEGIN LOGGING AT Mon Apr 18 11:00:55 2016 Apr 18 11:32:44 Hi all Apr 18 11:34:57 I'm happy to contribute layerindex-web. Where do i contact the right person ? Apr 18 11:35:15 Right now I'm upgrading all packages to latest .. Apr 18 16:24:51 Hi everyone! This is my first time in the Yocto IRC chat room - exciting! Apr 18 16:25:00 Is anyone around to chat? Have a few questions I was hoping I could get direction on. Apr 18 16:25:33 I'm running into an issue that apparently has come up often on the mailing list. I've found several different instances of people asking about how to put conditionals into recipes. Often, the end goal of doing this is to bitbake, for example, "myImage" and also be able to bitbake "myImage-debug." Apr 18 16:25:40 The common response is to explain that conditionals in recipes based on the image recipe that is being built not supported. I've seen people say things along the lines of "recipes create packages and your image recipe then IMAGE_INSTALLs those packages in the final output image. Apr 18 16:25:55 This seems to work well for custom recipes. It's not a problem for me to make two recipes for a single custom program that I want to build in debug mode or release mode. Apr 18 16:26:04 But what is the prescribed way to do this for core components such ast u-boot or the kernel itself? Can someone point me to formal documentation for this? Apr 18 16:26:11 Currently I'm stuck on determining the best approach when trying to append to recipes that are provided by my SOM's vendor. For example, I need two different versions of u-boot. The debug version is unmodified from the vendor's BSP version but the release version needs a special patch to support SPL “Falcon” boot mode. Apr 18 16:26:38 What is the best way to “conditionally” bbappend the SOM vendor’s u-boot recipe? Apr 18 16:32:39 seems like you want to bbappend the u-boot recipe Apr 18 16:32:52 with a SRC_URI_append_your-machine Apr 18 16:33:32 Cool ok that makes sense but I only have 1 machine. Should I have a machine-debug and a machine-release? Is this what I'm missing? Apr 18 16:38:00 why do you need -debug and -release anyway, usually a build in yocto is release with debug symbols and the debug symbols are pacakged in the $PN-dbg package for later installation Apr 18 16:42:00 This issues is fundamentally coved by Paul's notes at the bottom of this mailing list message Apr 18 16:42:01 https://lists.yoctoproject.org/pipermail/yocto/2014-June/020248.html Apr 18 16:43:02 As I said before, what if I want to build an image with special patches to u-boot based on building an image recipe "myImage-release" vs "myImage-debug" Apr 18 16:43:36 that's not doable. the best you could do would be to have two u-boot recipes Apr 18 16:43:50 people always ask for this, but never think about whatw ould happen if they run 'bitbake myimage-release myimage-debug' Apr 18 16:43:55 It looks as though Paul claims this isn't possible in the link above. Apr 18 16:44:17 haha and that's exactly what everyone says Apr 18 16:44:45 so the question is - if what I'm asking for is so crazy, what is the "prescribed" way to accomplish it?? Apr 18 16:45:13 if you want both a release and debug at the same time (different uboot binaries) then they have to be placed into difference recipes/packages.. Apr 18 16:45:27 you can't have one recipe/package that produces conflicting binaries (for the same type of package) Apr 18 16:45:30 as we've said multiple times, either use separate builds or separate recipes Apr 18 16:45:38 it's a totally valid use case. I give the development image to my developers at their test benches and I give the release image with, for example u-boot patches that enable Falcon mode to the manufacturing team. Apr 18 16:46:46 kergoth, can you elaborate for me? I get that I could have several build folders, but I'm trying to avoid this... Apr 18 16:47:05 if I make two u-boot recipes I run into the error ERROR: Multiple .bb files are due to be built which each provide u-boot Apr 18 16:47:37 then remove u-boot from provides, and also change it so each recipe writes different files into the deploy dir, and makes ure they don't conflict int eh sysroot, and.. Apr 18 16:47:39 one provides u-boot-release and one provides u-boot-debug. Whatever the thing is htat 'requires' u-boot is modified to require either release or debug Apr 18 16:47:49 IMO the right answer is don't do this at all, use separate builds, but it's really your call Apr 18 16:47:51 and what kergoth said Apr 18 16:47:58 separate builds is MUCH cleaner Apr 18 16:48:55 ok cool. The fact that this line of thinking comes up so much makes me wonder if there should be a section in the bitbake manual describing this workflow. Apr 18 16:50:26 So if I do multiple builds, I just have two totally different sets of recipes and two seperate build folders. I'm version controlling my recipes so this effectively doubles the number of recipes in git doesn't... Apr 18 16:50:43 it* Apr 18 16:51:32 i don't see why you'd have to duplciate the recipes to have two build dirs Apr 18 16:51:38 that seems pretty pointless Apr 18 16:51:46 ah indeed. Apr 18 16:51:58 just use a var to control how the things build, and set it in one and not in the other Apr 18 16:52:32 but I will have a u-boot-debug and a u-boot-release recipe. Then just use one in each of my build folders Apr 18 16:52:57 if you use two build folders, you don't need to separate it into two recipes. you could, sure, but it's not needed Apr 18 16:53:12 thanks kergoth this has been really helpful Apr 18 16:53:20 so what do you mean use "var?" Apr 18 16:53:32 a variable.. Apr 18 16:54:10 you can modify the recipe to only apply this patch if this variable is set to this value, then set that in local.conf to change how it builds Apr 18 16:56:48 great, I would do something in my bbappend like: SRC_URI += ${@base_contains(...) correct? Is this what you mean? Apr 18 16:59:31 contains is specifically to check if a word is in a variable which contains a list of words, which is appropriate for variables like DISTRO_FEATURES, PACKAGECONFIG, etc. you could use a packageconfig for this, or just a regular variable, in which case you woudn't need contains Apr 18 17:00:06 i.e. ${@'foo' if bb.utils.to_boolean('${BAR}') else 'baz'} if you want to use a variable that you can set to e.g 0 or 1 to enable/disable Apr 18 17:00:12 but it depends on your needs Apr 18 17:00:36 ${@} is just inline python, so it's flexible Apr 18 17:01:04 ok perfect. I really appreciate your time. I think this sort of topic comes up enough that we should get some documentation on it in the formal documentation set. Apr 18 17:01:06 Thoughts? Apr 18 17:01:26 probably, yes. you could open a documentation bug in bugzilla Apr 18 17:02:47 I'm on it. It should cover things like - "When to configure a seperate build folder" "How to make release vs debug images" and either of those can cover the fundamental "static packages" concept. Apr 18 17:25:31 So say I have multiple build folders as siblings to my sources folder. Each build folder will have it's own bblayers and local.conf file - I'm fine with this but does this topology play nice with Toaster? Can Toaster track builds in multiple build folders? Seems like it should. Apr 18 17:33:16 any particular reason why some modules in my kernel deploy directory are not being packaged in my final image? Is there some sort of well known problem with packaging perhaps I am running into? Apr 18 17:33:47 ie. I see modules in my modules.tgz file but I don't see the modules on the target when I look in the /lib/modules/xxkernel tree Apr 18 17:35:43 davis: it's not a problem, it's by design. kernel modules are split off into independent binary packages, you can choose what to install or not. Apr 18 17:35:52 if you want them all, install the 'kernel-modules' package Apr 18 17:40:43 hmm. Apr 18 17:41:09 i'm doing a new build. Soon as its complete, i'll look for that recipe. Apr 18 17:41:21 i take it I need to download a recipe from someplace? Apr 18 17:43:42 it's not a recipe Apr 18 17:43:50 it's a binary package emitted by your kernel build Apr 18 17:43:56 add it to your image's IMAGE_INSTALL like any other package Apr 18 17:45:49 hmm. I should look in the kernel receipe to see what it has in IMAGE_INSTALL section? Apr 18 17:46:23 ? Apr 18 17:46:29 IMAGE_INSTALL is a variable in an image Apr 18 17:46:37 putting it in a kernel recipe won't do anything at all Apr 18 17:46:43 see the yocto project documentation on how to add packages to an image. Apr 18 17:53:40 hmm. googling that result gets me to the ref image. doing a search on install shows me 400+ hits. Any particular section? Apr 18 17:54:19 http://www.yoctoproject.org/docs/2.0.1/mega-manual/mega-manual.html#usingpoky-extend-customimage Apr 18 17:54:25 found in about 10 seconds by searching for IMAGE_INSTALL. Apr 18 18:10:48 thanks for the link, i was looking at it. To be honest, I don't know how this actuall sfimage is built. I'm doing a grep of all .conf files looking for IMAGE_INSTALL invocations Apr 18 18:11:29 just set IMAGE_INSTALL_append = " kernel-modules" in local.conf and move on Apr 18 18:11:37 that'll affect any image recipe being built Apr 18 18:15:28 many thanks. i'm trying now. Apr 18 18:32:19 kergoth: that worked. If you are getting paid to help support yocto, you deserve a raise. Apr 18 18:34:10 fwiw, all the modules are in the booted image, but that my setup still does not work. Apr 18 18:34:41 i think it might be related to installing modules though. Apr 18 18:36:28 for instance, I have /lib/modules/4.1.10JFD3/modules.dep file and I have all the .ko in the same subdir Apr 18 18:37:05 however, when I try to modprobe a driver, it.. nevermind Apr 18 18:37:35 i was going to say it could not find the .ko, but it appears the driver is loading, its just the driver can't find a device. not a file. Apr 18 18:37:47 i wonder if this is a /dev/xxx type file issue. Apr 18 18:46:59 hmm. this might be of no consquence but when I first got my kernel to boot, I made two mods. one was the version string and one was for the gadget usb ethernet driver Apr 18 18:47:35 I noticed the g_ether.ko driver was there. I thought it was working and it was there because I placed it there. Apr 18 18:48:16 however, when I enabled additional drivers as modules and I booted the image, I noticed the new drivers were not there. Apr 18 18:48:55 after I used kergoths technquie to add the kernel-modules to local.conf all of the modules show up in the booted image. Apr 18 18:50:17 so I wonder why some would show up but not all. Maybe some other recipe is building a driver and placing it there? Maybe its overwriting the one I am placing there in the kernel image build. Apr 18 18:51:13 So, I did a md5sum of the drivers on the target and the ones on the host and they don't match. Apr 18 18:51:42 even if you are arm on the target and x86_64 on the host, I would think the mdsum would match. Apr 18 20:02:19 hey kergoth earlier today you explained some really helpful things but after implementing them today I have a few more questions if you have a minute Apr 18 20:04:32 just ask, someone elkse might have ideas and kergoth can answer as he has time Apr 18 20:05:04 I can use inline python to change what is added to a SRC_URI in a bbappend file. You can define a variable in local.conf and use it to configure the behavior you want. Is there a way to also access this variable from the Shell scripts? For example, during do_configure_append for a recipe I would like to conditionally add data. I can get the variable with inline python but how can the shell get it? Apr 18 20:46:31 that was a dumb question. sometimes a guy can't see the forest through the trees... in shell just use ${MY_VAR_NAME} wowzer... sorry Apr 18 20:46:43 lol Apr 18 22:03:06 morning all **** ENDING LOGGING AT Tue Apr 19 02:59:59 2016