**** BEGIN LOGGING AT Tue Aug 04 02:59:58 2015 Aug 04 05:28:18 hello, so if I find a file under sysroots// , can I expect to find that file under the resulting final image? Aug 04 05:29:08 for some reason, i915_dri.so is missing from the final image although I can clearly see the library in /tmp/sysroots/intel-corei7-64 Aug 04 05:29:35 nope. sysroots are directory hierarchies which hold files for recipes to share with one another, e.g. libs an dheaders to satisfy dependencies Aug 04 05:29:52 recipes can emit any number of binary packages, whereas sysroots are monolithic, everything the recipe installed to certain paths Aug 04 05:30:05 packages listed in IMAGE_INSTALL in the image are installed into the image Aug 04 05:30:11 see the yocto documentation on that Aug 04 05:32:11 ok. So if I want to see the list of packages installed i can simply refer to the manifest file right? Aug 04 05:35:56 hi guys Aug 04 05:39:15 i'd like to have my keyboard layout as azerty & qwerty but i'm not able to do it. Aug 04 05:39:48 Here is what I have when I ran the bitbake -e command : IMAGE_LINGUAS="fr-fr en-us" Aug 04 05:40:20 not sure if it's the appropriate variable Aug 04 08:07:34 morning all Aug 04 08:07:48 morning bluelightning Aug 04 08:11:52 hi all Aug 04 08:12:20 is there some example hot to add external binary kernel module to final image? Aug 04 08:12:25 *how Aug 04 08:15:08 marek__: binary, no, not really... however it would be a fairly straightforward recipe, just copy the files into the appropriate place and ensure they get packaged Aug 04 08:15:31 yes this was also my idea but what if kernel version will change Aug 04 08:15:55 bluelightning: I want to keep /lib/modules/xxx/ to be extracted somehow Aug 04 08:20:18 marek__: your recipe can inherit linux-kernel-base then set KERNEL_VERSION = "${@get_kernelversion_file("${STAGING_KERNEL_BUILDDIR}")}" and then install the files within do install to ${D}/lib/modules/${KERNEL_VERSION} Aug 04 08:20:53 bluelightning: many thanks Aug 04 08:21:19 oh, you should also have DEPENDS = "virtual/kernel" Aug 04 08:21:20 how can I change this line to use http protocol? : SRC_URI = "git://github.com/mygit/mygit.git;branch=2" Aug 04 08:21:32 miandonmenmian_: add ;protocol=http Aug 04 08:26:34 bluelightning: unparsed line: 'KERNEL_VERSION = "${@get_kernelversion_file("${STAGING_KERNEL_BUILDDIR}" (I have poky daisy) Aug 04 08:28:10 marek__: ah, I see Aug 04 08:28:17 marek__: in which case try KERNEL_VERSION = "${@base_read_file('${STAGING_KERNEL_DIR}/kernel-abiversion')}" Aug 04 08:52:04 bluelightning: second version works fine, many thanks again Aug 04 09:05:30 marek__: np Aug 04 09:19:33 that hit the spot, thanks Aug 04 11:28:29 Does yocto have/do any tests for the generated sdk's? Aug 04 11:32:35 michaelw_: ping Aug 04 11:38:39 mcfrisk: yes, IIRC bitbake -c testsdk Aug 04 11:47:48 bluelightning: thanks! is there any documentation to go with that? e.g. how to execute and write tests for the sdk packages. Aug 04 11:56:38 michaelw_: May I know if I am missing anything in my modified code ( which I have posted in mailing list)? When I tried to check request.POST ( in toastergui/views.py), the dictionary was empty. Aug 04 12:37:47 Hello together. I have a question concerning the package management. We are using an image based on core-image-x11. We have defined all packages needed on the image via "IMAGE_INSTALL" variable. Updates are handled over the air, installed via "opkg update / upgrade". But we didn Aug 04 12:38:06 * Is there a way to install new packages over this mechanism? Aug 04 12:38:30 Without doing it manually Aug 04 12:40:33 Hi, I wonder when aclocals end up in sysroot and where they're coming from? From a recipe or the host system? Aug 04 12:49:07 mcfrisk: I don't believe we do have any documentation on testsdk, no, but see meta/lib/oeqa/sdk/ for the current tests which should serve as examples Aug 04 12:50:14 sujith_h: yep, let me reply on the email thread Aug 04 12:50:33 zwerch: you mean as part of an upgrade? wouldn't you just make them a dependency of some already-installed package? Aug 04 12:52:08 bluelightning: yes, I read meta/lib/oeqa/sdk/ but am failing to execute them on dizzy. tried to backport the gcc tests for example but something is wrong in my config since they fail with "Test ping specified in TEST_SUITES could not be found in lib/oeqa/runtime under BBPATH" Aug 04 12:52:13 sujith_h: what is the 'json' for in " client.post(reverse('xhr_importlayer'),data,'json' " Aug 04 12:53:05 mcfrisk: strange, that sounds like testimage rather than testsdk Aug 04 12:54:37 bluelightning: Yes. We need a mechanism that upgrades the whole system with one command / small failsafe-script, not via images but via intelligent incremental upgrades (and opkg does this very well, but not with new packages). So in this case it wouldn't be bad practice to use all packages as a dependency of a virtual package instead of installing them via "IMAGE_INSTALL"? Aug 04 12:55:18 michaelw_: I assume it sets the content-type header to "application/json" Aug 04 12:55:37 zwerch: I don't see a problem with that... but you need not add all packages as dependencies, in fact you could install a packagegroup and have no dependencies initially, just adding them as needed as time goes on Aug 04 12:57:26 i can use hob to build custom targets, but how can I get a list of targets available at bitbake prompt? Aug 04 12:58:19 davis: bitbake -s or bitbake-layers show-recipes perhaps Aug 04 12:58:43 bluelightning: okay, thanks so far. How do I define runtime dependencies? And what is a packagegroup? Aug 04 12:59:11 bluelightning: many thanks. Aug 04 12:59:17 zwerch: RDEPENDS_ (RDEPENDS_${PN} for the main package of a recipe) Aug 04 12:59:53 zwerch: a packagegroup is a way of grouping together packages as the name suggests; but fundamentally on the runtime end it's just a package with no contents and a list of dependencies on other packages Aug 04 13:00:05 zwerch: on the recipe end it's a recipe that inherits packagegroup Aug 04 13:00:26 zwerch: loads of examples in meta/recipes-core/packagegroups/ Aug 04 13:00:39 michaelw_: If I have: response = client.post(reverse('xhr_importlayer'), data, HTTP_X_REQUESTED_WITH='XMLHttpRequest'). I am getting same error. Aug 04 13:00:56 bluelightning: awesome, thanks! Aug 04 13:04:26 hmm, how to run bitbake python snippets things like run.do_testsdk in a devshell? Aug 04 13:04:43 mcfrisk: I don't think you can Aug 04 13:07:09 sigh, then I'll debug this in some other way... Aug 04 13:08:04 mcfrisk: to be honest I almost never use devshell myself, I just insert bb.warn() calls in where I need to see what is happening Aug 04 13:08:08 crude, but effective# Aug 04 13:13:18 sujith_h: hmm odd it works here Aug 04 13:13:21 bluelightning: thanks, I saw that TEST_SUITES wasn't defined in my local.conf and ping was a default. Now I need to fix those tests for our setup... Aug 04 13:15:27 bluelightning: that reminds me of when people are asking how to debug the kernel, my only answer is pr_err Aug 04 13:15:41 they are always disappointed :) Aug 04 13:16:02 sujith_h: http://pastebin.com/bkLAwtjm Aug 04 13:22:58 mcfrisk: the error would suggest that it's looking in the wrong place, perhaps the error is simply incorrect for testsdk Aug 04 13:23:05 abelloni: indeed Aug 04 13:26:47 i read someplace that mods done in hob do not take affect bitbake cmdline builds. Is that correct? I see changes in my local.conf files and it does seem to affect my bitbake builds. Aug 04 13:31:22 * paulg_ wonders how accepting folks would be of patches that turn tar based pkgs into git based... Aug 04 13:31:45 bisecting within a pkg within yocto is a heck of a lot easier if the pkg is already git based. Aug 04 13:32:11 at the cost of a slightly larger download. Aug 04 13:34:45 davis: that might have been true in older versions of Hob Aug 04 13:35:32 bluelightning: that makes sense. thanks Aug 04 13:35:53 paulg_: across the board, I think we would prefer not to make that change Aug 04 13:36:40 bluelightning, ok, then my next suggestion would be to somehow have it there, but off by default then. Aug 04 13:36:59 fwiw, i learned you can do "bitbake -c menuconfig virtual/kernel" and it will pull up make menuconfig for the virtual kernel. Is there a way to run menuconfig for the specific kernel I am using? ie. Not edit generic/virtual kernel config but arm/beaglebone kernel. Aug 04 13:37:09 not sure the implementation specifics of how best to make that work... Aug 04 13:37:47 davis: you can use the kernel recipe name instead of virtual/kernel, no? Aug 04 13:38:02 paulg_: it may be something to open up a discussion on on the OE-Core mailing list - the topic of git vs. tarballs has come up in a couple of threads lately but we haven't had a proper discussion about it Aug 04 13:38:38 davis: virtual/kernel should be the kernel for your machine if MACHINE has been set Aug 04 13:38:48 ndec, got me. I'm not sure how to specify the particular name. Is there a way to list the different kernels available? Aug 04 13:39:20 bluelightning: hmm. I don't see any arm specific options. When this build finishes. I'll try again. Aug 04 13:39:28 virtual/kernel isn't a "generic" kernel, it just points to the selected kernel for your configuration Aug 04 13:40:28 bluelightning, yeah - it just seems fresh on my mind since I had to bisect both libdrm and xf86-video-intel to solve that latest X11 segfault mess. Aug 04 13:40:43 http://thread.gmane.org/gmane.comp.handhelds.openembedded.core Aug 04 13:42:42 paulg_: in order to bisect easily though wouldn't you need to be pointing to a local source tree? in which case "devtool modify" would be the recommended way to set that up for almost any recipe Aug 04 13:43:28 although that still provides no shortcut to the upstream git for a recipe that fetches from a tarball instead, admittedly Aug 04 13:45:10 bluelightning, in this case, I wanted to be sure of what libdrm was putting in the sysroot, so while I ran the bisect commands on a local tree, I used the output of those commands in a SRCREV in the bb to ensure I wasn't changing two things at once. Aug 04 13:45:56 and of course put the git repo in the SRC_URI and put S="${WORKDIR}/git" Aug 04 13:46:44 * paulg_ has never used "devtool modify" Aug 04 13:47:39 Is there a recipe that should provide cc and c++ symlinks? I would expect GCC to use update-alternatives to do that, but it doesn't seem to be happening for me... Aug 04 13:47:40 bluelightning: what is the name I need to use in IMAGE_INSTALL if my packagegroup-recipe is "packagegroup-core-mystuff.bb"? Aug 04 13:47:52 zwerch: packagegroup-core-mystuff Aug 04 13:48:01 bluelightning: ok, thanks Aug 04 13:48:10 zwerch: also, it should not be named including "core" - it's not a core recipe if it's not in OE-Core ;) Aug 04 13:48:11 bluelightning: you are correct. I must have been using qemu before. It indeed shows arm config. cool. Aug 04 13:48:15 bluelightning: many thanks Aug 04 13:48:23 davis: no worries Aug 04 13:48:26 bluelightning: ok 😄 Aug 04 13:48:46 paulg_: it's new as of the last release... if you get a chance, give it a try Aug 04 13:48:52 * paulg_ reads Aug 04 13:50:39 does it matter what the order is when you add layers? I have built a bootable rootfs with the stock layers. I would like to add the meta-ti layer since it has the cape manager. supposedly it modifies the kernel config as well. Aug 04 13:51:02 owuld I add this to BBLAYERS at end or beginning or does it matter? Aug 04 13:51:41 bluelightning: so if I install "packagegroup-mystuff", it automatically installs all packages defined in there? :O Aug 04 13:52:07 davis: it doesn't have the cape manager Aug 04 13:52:07 zwerch: yes Aug 04 13:52:26 bluelightning: cool! Aug 04 13:52:32 denix: the ti kernel or the stock one? Aug 04 13:52:37 davis: but the order is important when you have overlapping configs Aug 04 13:52:51 when I boot the stock one, and I do the grep config.gz I don't see it. Aug 04 13:53:01 zwerch: well, it'll install all the packages defined as dependencies in RDEPENDS_${PN} in that recipe, to be specific Aug 04 13:53:40 denix: I figured, the meta-ti one would since I found the cape-manager user space tools in the meta-ti layer via some tool Aug 04 13:53:51 nevermind, c++ and cc are in gcc/g++-symlinks, I just need to install them Aug 04 13:54:03 davis: neither Aug 04 13:54:27 hmm. Aug 04 13:56:00 on the kernel i am running, this fails zcat /proc/config.gz | grep CONFIG_BONE_CAPEMGR Aug 04 13:56:15 this is from https://github.com/beagleboard/bb.org-overlays readme Aug 04 13:56:17 davis: as of the order - meta-yocto-bsp provides beaglebone.conf as well as meta-ti, so depending on the order, you get one machine definition or another. best to remove meta-yocto-bsp reference bsp when switching to real bsp Aug 04 13:57:29 denix, sorry pal I am so new to this I don't know what I am doing. So I should remove the meta-yocto-bsp and add meta-ti. Aug 04 13:57:36 i'll try that and see what happens. Aug 04 13:59:18 i removed the meta-yocto-bsp and only have the meta-ti one. Any idea where in menuconfig the cape manager would be? under what heading? Aug 04 14:04:25 bluelightning: I must've done something wrong, I'm getting " * opkg_install_cmd: Cannot install package packagegroup-mystuff", what could cause this? Aug 04 14:05:49 zwerch: your recipe does "inherit packagegroup" right ? Aug 04 14:06:01 bluelightning: yep Aug 04 14:06:23 zwerch: then you should not see that... what that indicates is the recipe claimed to produce that package and in the end didn't Aug 04 14:09:06 bluelightning: https://gist.github.com/zwerch/d797d5ce3e411d6f39fc Aug 04 14:09:53 zwerch: having set PACKAGES to what you have set, you have stopped it providing the main package Aug 04 14:10:04 zwerch: which is probably not what you want Aug 04 14:11:00 bluelightning: so deleting the PACKAGES part fixes it? Aug 04 14:11:38 zwerch: well, decide what you want - do you need more than one packagegroup package defined by the recipe or not? Aug 04 14:13:09 denix: this seems to be important. I added ti before and it simply busted my build. Now that I removed meta-yocto-bsp it is at least fetching new sources or so it seems. that appears to be an improvment. Aug 04 14:14:21 bluelightning: I need a "dynamic" packagegroup that also allows me to add a new group if necessary with new packages but is installed via one IMAGE_INSTALL (so new packages are automatically added via opkg upgrade) Aug 04 14:15:27 zwerch: you can comfortably add new packagegroups to that recipe as dependencies of the main package, but when you do that, use PACKAGES += not PACKAGES = Aug 04 14:20:43 bluelightning: it seems to have worked, thanks again! Aug 04 14:20:49 zwerch: np Aug 04 14:21:13 zwerch: congratualtions! Aug 04 14:23:40 haha, thanks Aug 04 14:33:04 Hi all! I am getting "WARNING: Inode check for /srv/yocto-dl-dir is unavaliable, will remove it from disk monitor". "df -i" shows Aug 04 14:33:04 Filesystem Inodes IUsed IFree IUse% Mounted on Aug 04 14:33:04 rootfs 0 0 0 - / Aug 04 14:33:05 am I missing a dependency? Aug 04 14:33:45 hsychla: what fs is in use there? Aug 04 14:33:56 bluelightning: btrfs Aug 04 14:34:18 hsychla: I suspect you can ignore the warning, it probably shouldn't be shown Aug 04 14:34:52 it's not only dl-dir but sstate-cache etc as well. and it want's to build all packages from scratch which I guess is related Aug 04 14:35:21 hsychla: I doubt that that's related, the disk monitor is unconnected to sstate Aug 04 14:35:34 ah ok Aug 04 14:37:05 we moved the buildroot from a VM into a docker container. did it before without problems but this time bitbake want to rebuild everything Aug 04 14:37:26 michaelw_: Thanks for help. But I still not getting "error": "hint-layer-version-exists". Instead what I am getting is http://pastebin.com/JMhTP0p5 Aug 04 14:38:30 hsychla: you would have to do comparisons of siginfo/sigdata files with bitbake-diffsigs to determine for sure what changed, but something must have Aug 04 14:42:06 bluelightning: is that always for one package or can I check the diffsigs for a whole core-image Aug 04 14:42:07 ? Aug 04 14:42:43 hsychla: one task at a time I'm afraid, though -t is supposed to allow you to trace back in practice it doesn't work as well as it should Aug 04 14:43:01 ok, thanks. this helped a lot Aug 04 14:43:19 hsychla: simplest thing is to do it for the earliest task that ran; you can look at the latest log under tmp/log/cooker/ to find what that was Aug 04 14:44:30 already found a difference Aug 04 14:57:52 YPTM: Ready-Access Number: 8007302996 Access Code: 2705751 Aug 04 14:57:58 YPTM: Stephen Joined Aug 04 15:00:14 YPTM: belen joined Aug 04 15:00:37 YPTM: Michael present. Aug 04 15:03:07 hi, sona here ! Aug 04 15:03:59 Ovidiu Poncea @ windriver Aug 04 15:10:57 Musat, George L - QA contact. Aug 04 15:12:35 YPTM is over. Aug 04 15:13:49 sujith_h: Does the layer you're adding actually already exist? Remember that the unit tests run on a clean database, the only layers the system knows about are the ones added in the setUp function Aug 04 15:17:05 michaelw_: yes it does exist in location : /home/sujith/MEL/toaster_work/meta-oe Aug 04 15:20:00 sujith_h: is that in the database then? Aug 04 15:22:46 michaelw_: give me a min Aug 04 15:22:52 michaelw_: checking Aug 04 15:34:12 RP: did you look at mesa fixes? Aug 04 15:37:04 there is this git repot https://github.com/beagleboard/meta-beagleboard Aug 04 15:38:41 if I download all these sub repots, and replace the ones I'm using in yocto now. meta-yocto-bsp with meta-beagleboard, openembedded-core, etc. Will I be able to build the beaglebone reference or will it break yocto and I need to do this from openembedded instead? Aug 04 15:45:07 michaelw_: Is it orm_layer table which has the info? Aug 04 15:47:31 davis: that should work fine Aug 04 15:50:25 bluelightning: somehow, I think i'm going to fsck it up though Aug 04 15:50:27 michaelw_: I couldn't find it in orm_layer table. In orm_layersource, I have only 3 entries Aug 04 15:51:18 i pulled the layers referenced here https://github.com/beagleboard/meta-beagleboard Aug 04 15:51:36 which is meta-beagleboard meta-openembedded and openembedded-core Aug 04 15:52:12 and then in poky/build/conf/bblayers.conf I have the following layers set: Aug 04 15:52:22 "/home/davis/progs/poky/meta /home/davis/progs/poky/meta-yocto /home/davis/progs/beagle-ref/meta-beagleboard /home/davis/progs/beagle-ref/meta-openembedded /home/davis/progs/beagle-ref/openembedded-core" Aug 04 15:53:03 but I notice that openembedded-core has its own oe-init-build-env which looks like a script similar to the one I source in yocto Aug 04 15:53:47 the poky repository is an integration of bitbake, oe-core, and meta-yocto Aug 04 15:54:02 so yes, the oe-init-build-env from oe-core is exactly the same as the one you source from poky Aug 04 15:54:15 thats good Aug 04 15:55:17 sadly bitbake -c menuconfig virtual/kernel no longer works though. Aug 04 15:57:17 if I cc ~/progs/poky and then source oe-init-build-env and then bitbake -c menuconfig virtual/kernel it fails. it is looking for a meta-beagleboard/conf/layer.conf file Aug 04 16:02:58 im totally confused Aug 04 16:04:09 if you read https://github.com/beagleboard/meta-beagleboard#introduction, you'll see that the meta-beagleboard repository includes two layers, it itself isn't a layer Aug 04 16:04:42 assuming you want the beaglebone machine, you'd want common-bsp, see https://github.com/beagleboard/meta-beagleboard/tree/master/common-bsp/conf/machine Aug 04 16:05:00 ok one sec, let me read that. Aug 04 16:06:48 i'm not sure how you know it includes two layers and is not itself a layer Aug 04 16:07:28 are you looking at the list of files and see that it has two subdirs? common-bsp and meta-beagleboard-extras? Aug 04 16:09:22 so https://github.com/beagleboard/meta-beagleboard/tree/master/common-bsp/conf/machine that beaglebone.conf should be put where the missing config file was mentioned by bitbake? Aug 04 16:16:20 sigh, sdk installer shell script is quite crappy. full of non-quoted variables, non-checked return values... A run with shellcheck would be in order, as would 'set -euxo pipefail'. Are there any standards for shell scripts in yocto? Aug 04 16:26:16 davis: just add meta-beaglebone/common-bsp/ to bblayers, not meta-beagleboard. Aug 04 16:31:04 kergoth: ok. i'll try that. I appreciate your expertise. I'm really lost in this whole layer thing. Aug 04 16:32:29 i belive this is the change you suggest Aug 04 16:32:31 BBLAYERS = "/home/davis/progs/poky/meta /home/davis/progs/poky/meta-yocto /home/davis/progs/beagle-ref/meta-beagleboard/common-bsp /home/davis/progs/beagle-ref/meta-openembedded /home/davis/progs/beagle-ref/openembedded-core" Aug 04 16:33:19 nope. fails again. Aug 04 16:35:25 'fails again' tells us nothing Aug 04 16:36:51 its the same error. ERROR: Unable to parse /home/davis/progs/beagle-ref/meta-openembedded/conf/layer.conf: file /home/davis/progs/beagle-ref/meta-openembedded/conf/layer.conf not found Aug 04 16:37:17 meta-openembedded is the same thing. it's multiple layers, not one. Aug 04 16:37:20 i'm thinking i need to revert the layers Aug 04 16:37:22 which of its layers are you wanting? Aug 04 16:37:28 most likely it's meta-oe Aug 04 16:37:36 so add meta-openembedded/meta-oe Aug 04 16:37:52 all i'm trying to do is get the LCD cape working on this beaglebone with a custom build. Aug 04 16:38:31 I know that the build which I downloaded in binary form has it, but the one I built as a result of pulling down poky does not. Aug 04 16:38:51 i asked around and found that git repot which I am trying to use. Aug 04 16:39:38 this one worked for building java but no lcd Aug 04 16:39:42 #BBLAYERS = "/home/davis/progs/poky/meta /home/davis/progs/poky/meta-yocto /home/davis/progs/poky/meta-yocto-bsp /home/davis/progs/meta-oracle-java " Aug 04 16:41:40 adding the meta-openembedded/meta-oe as you suggests gives the same error Aug 04 16:41:42 BBLAYERS = "/home/davis/progs/poky/meta /home/davis/progs/poky/meta-yocto /home/davis/progs/beagle-ref/meta-beagleboard/common-bsp /home/davis/progs/beagle-ref/meta-openembedded /home/davis/progs/beagle-ref/openembedded-core /ho Aug 04 16:41:46 me/davis/progs/beagle-ref/meta-openembedded/meta-oe" Aug 04 16:42:03 you didn't remove the old non-existant meta-openembedded Aug 04 16:42:07 as i said, it's not a layer Aug 04 16:48:15 kergoth: sorry man. I don't really know how to determine if something is a layer. I just saw on that git repot it said it depended on it. so every thing it depened upon I pulled and then added to the layers. Aug 04 16:48:36 BBLAYERS = "/home/davis/progs/poky/meta /home/davis/progs/poky/meta-yocto /home/davis/progs/beagle-ref/meta-beagleboard/common-bsp /home/davis/progs/beagle-ref/openembedded-core /home/davis/progs/beagle-ref/meta-openembedded/met Aug 04 16:48:41 a-oe" Aug 04 16:48:46 that still fails with the same error. Aug 04 16:49:00 you'll note bitbake complains if /conf/layer.conf doesn't exist. if a path has no conf/layer.conf, it's not a layer. now you know Aug 04 16:49:19 at a minimum a layer includes a 'conf' directory containing the file 'layer.conf' Aug 04 16:50:06 in beaglebone-ref, the meta-beagleboneboard does not have a layer.conf in top dir Aug 04 16:50:27 layer.conf is in the 'conf' directory of a layer.. Aug 04 16:50:38 ditto for the other two dirs, meta-openembedded and openembedded-core Aug 04 16:50:44 if there is no conf directory and a conf/layer.conf, they're not layers Aug 04 16:51:07 layers in the openembedded-core are in the 'meta', 'meta-selftest' and 'meta-skeleton' directories.. Aug 04 16:51:25 Note, your first BBLAYERS= value is your 'meta' directory.. Aug 04 16:51:45 well, none of these things that I pulled are layers then Aug 04 16:51:54 poky is based on OpenEmbedded-core.. so including both 'poky' and 'openembedded-core' is going to also cause problems Aug 04 16:51:56 none have a conf/layer.conf file Aug 04 16:52:04 they're directories that may contain layers, but they are not layers themselves Aug 04 16:52:31 ok this is frustrating. i should go back to buildroot Aug 04 16:53:10 i just dont have the expertise for this Aug 04 16:53:21 davis: you just need to get the paths correct... you're like two steps away now Aug 04 16:54:06 if I revert back to what I started with, at least I can do the make menuconfig ok Aug 04 16:54:17 BBLAYERS = "/home/davis/progs/poky/meta /home/davis/progs/poky/meta-yocto /home/davis/progs/poky/meta-yocto-bsp /home/davis/progs/meta-oracle-java " Aug 04 16:54:37 that is a correct bblayers configuration Aug 04 16:54:43 all four of those are layers AFAIK Aug 04 16:54:47 and Robert Nelson made this for me Aug 04 16:54:58 https://github.com/RobertCNelson/meta-beagleboard-kernel Aug 04 16:57:23 i'm going to try and see if I can build core-image-sato with the original layer. If that finishes, i'll try this agian. Aug 04 16:57:28 i appreciate the help Aug 04 17:58:50 hmm. After i reverted my bblayers variable, bitbake of core-image-sato and the other image I built jfd-image-recipe fails at the last task. Aug 04 17:59:10 Error: min. I/O unit was not specified (use -h for help) Aug 04 18:20:44 so what is the yocto way of solving this problem? I look at the create_image.ubifs script and I don't see any path wrong at the end where it invokes mkfs.ubifs, but I do see some .lock files around. Aug 04 18:21:06 ie. in the dir where rootfs is located, there is a rootfs.lock file. Aug 04 18:21:39 perhaps its an error where a lockfile has kept something from being used Aug 04 18:22:19 i read something about cleaning a build results using the term sane. i can't remember where I saw it though. Aug 04 18:22:32 I'm unfamiliar with that error message. I'd suggest a quick google search or look in the docs specific about building a ubifs under OE Aug 04 18:22:57 But my suspicion is that the machine you choose does not have UBIFS support enabled or configured properly Aug 04 18:23:45 hmm. i remember when I was using hob there was a button you could press which would bring up a config for those tyupe of things Aug 04 18:23:57 that would be the toaster in modern items.. Aug 04 18:23:58 i don't remember adjusting it though. Aug 04 18:24:23 i tried to use toaster. I played with it sunday in analyze and build mode Aug 04 18:24:43 docs explain how to start the toaster and how to conncet to it with your web browser.. I don't know if those configuration settings are available or not. The docs on the Yocto Project site should explain the various configuration parameters.. otherwise look in meta/conf/documentation.conf Aug 04 18:24:55 if there is a setting needed and it's not listed, then it's likely a bug in the docs Aug 04 18:25:09 i could start it. I think I even used it to do a build. Aug 04 18:25:43 when I used it, I was able to find the layer for pulling in capes. When I added the layer, it would fetch things for me. Aug 04 18:25:57 do you use toaster or use the command line? Aug 04 18:25:59 yes.. that is what toaster allows you to do.. Aug 04 18:26:07 I use command line mostly.. but rarely need ubifs Aug 04 18:26:39 i don't have a clue where that would be specified in command line Aug 04 18:26:47 i imaging its a conf file Aug 04 18:27:17 in my local.conf there is this Aug 04 18:27:18 #added by hob Aug 04 18:27:18 IMAGE_FSTYPES = "jffs2 ext4 ubi tar.gz tar.bz2" Aug 04 18:28:13 that would lead me to think I have ubi specified Aug 04 18:28:48 yes, but you or your MACHINE need to configure the filesystem.. Aug 04 18:28:53 thus the error from the mkfs ubifs Aug 04 18:29:03 it sounds like something is not configured and doesn't have a default value Aug 04 18:30:43 i did a diff of my tree and the only thing I see is meta-yocto-bsp/recipes-bsp/formfacotor/beagleboard/machconfig has an entry for HAVE_TOUCHSCREEN=1 instead of 0 Aug 04 18:31:07 but that does not sound like a ubi file system issue Aug 04 18:34:36 is there a command for bitbake which does a check to see if files are valid? Aug 04 18:34:38 OT, quick prototype of prefixing task log messages with the recipe/task they came from: https://gist.github.com/kergoth/50af1ca12692d39f0338 - haven't decided if that'd be better in a subclass of the log formatter rather than directly modifying the message in the ui main loop, though Aug 04 18:35:48 or at least removes the .lock files? maybe they are stale and causing a problem. i don't know but it seems odd that it no longer would work. Aug 04 18:36:02 if the lock file was stale, the build wouldn't even begin Aug 04 18:37:02 ahh Aug 04 18:37:52 i opened a new terminal, reran the init script and I'm trying to build it again. its on task 5039 of 5041 Aug 04 18:40:10 looking at ps, it seems to be building various archives. at first i saw jffs, then tar Aug 04 18:40:47 then it failed again on create_image.ubifs Aug 04 18:41:08 what is ubifs used for? Aug 04 18:41:10 uboot? Aug 04 18:42:04 if I take it out of the conf/local.conf file maybe it will work Aug 04 18:53:38 interesting. I removed the ubi specification from local.conf and my old custom image built Aug 04 18:53:48 so i'm back where i started. Aug 04 18:54:37 since the whole oe versions rabbit hole did not work. How would a newbie go at enabling the lcd on a beagleboard? Aug 04 18:57:19 i have this meta-beagleboard-kernel from Robert. it has a recipes-kernel with a .bb file and a defconfig but no conf/layer.conf. Aug 04 18:57:41 could I stick this in my recipes-kernel dir and enable it? Aug 04 18:59:12 https://github.com/beagleboard/meta-beagleboard Aug 04 18:59:21 in the original meta-beagleboard.. the 'common-bsp- was the layer Aug 04 18:59:38 I haven't used a beagleboard in a long time though, so I have no idea what is correct or current Aug 04 19:01:01 hmm. i don't understand. Aug 04 19:01:28 the git repository 'meta-beagleboard' has a directory in it called 'common-bsp'. That is the layer that would be added to yoru bblayers entry.. Aug 04 19:01:33 i see that meta and meta-yocto-bsp both have a recipes-kernel Aug 04 19:01:44 I don't know of any other beagleboard layers, but that one is fairly old.. so it's likely not correct Aug 04 19:02:43 this guy Robert, seems like he is a guy who is knowledable was kind enough to give me a recipes-kernel tree Aug 04 19:02:56 I don't know anything about that work.. sorry Aug 04 19:03:02 i think he was assuming I would know how to plug it in to my existing tree Aug 04 19:03:56 i'm thinking if I add the tree in my tree under meta-yocto-bsp perhaps I can select it via a prefered version sting or something Aug 04 19:04:10 that really isn't the right way, but it might work.. I don't know.. Aug 04 19:04:20 hmm. ok lets not do that then Aug 04 19:04:23 this is why the layer mechanism was created so you -never- had to hack on a repository.. Aug 04 19:04:37 you always just add to it, and the addition allows you to replace or amend existing work Aug 04 19:04:38 i'm trying to understand the layer idea Aug 04 19:05:02 he gave me a .bb and defconfig Aug 04 19:05:28 but since its not a layer, I know now I can not add it to my BBLAYERS variable Aug 04 19:05:33 At a minimum, a Yocto Project compliant layer has three things.. a README file, something (might be in the readme) that explains how to use it and contribute back fixes, and a 'conf/layer.conf' file Aug 04 19:05:55 For something that "works" w/ OE, you can skip the readme and contribution info.. Aug 04 19:05:58 this does not have a readme or a conf Aug 04 19:06:33 the conf/layer.conf is quite simple... look at meta-skeleton in your install for an exmaple.. Aug 04 19:06:49 simply copy that.. and change references to 'skeleton' to whatever you want to name your layer Aug 04 19:07:03 so if i copy it, where do I copy it too? Aug 04 19:07:06 the BBFILES entry is the set of wildcards used to find the recipes and bbappends Aug 04 19:07:08 conf/layer.conf Aug 04 19:07:25 mkdir my-new-layer Aug 04 19:07:38 mkdir my-new-layer/conf Aug 04 19:07:52 cp meta-skeleton/conf/layer.conf my-new-layer/conf/. Aug 04 19:07:59 are you saying mkdir at top level? As a peer to meta, meta-yocto and meta-skeleton? Aug 04 19:08:03 my-new-layer/conf/layer.conf Aug 04 19:08:17 swap references to skeleton to "my-new-layer" Aug 04 19:08:32 make sure BBFILES path matches the layer and directory structure you have choosen for your layer.. Aug 04 19:08:36 thats it Aug 04 19:08:42 you can put it anywhere you want Aug 04 19:08:51 the BBLAYERS= has the path to the layer Aug 04 19:08:51 fray you are my hero Aug 04 19:09:54 (this is all in the Yocto Project manual on creating a layer BTW).. Aug 04 19:10:24 which one? the meta manual? Aug 04 19:11:27 mega manual, Chapter 5. "Common Tasks".. 5.1 Understandign and Creating Layers Aug 04 19:11:31 http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html Aug 04 19:11:44 http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#understanding-and-creating-layers Aug 04 19:12:22 'meta-' is a convention BTW for layer names, but not required.. a layer can be called anything that the filesystem allows.. Aug 04 19:12:34 fwiw, that layers.conf has BBFILE_COLLECTIONS +="skeleton" so that should be "my-new-layers" but it also has BBFILE_PATTERN_skeleton would that be BBFILE_PATTERN_my? Aug 04 19:13:29 all of them have to match Aug 04 19:13:36 and be unique within your configuration.. Aug 04 19:13:42 you can't have two layers with the same 'collections' name Aug 04 19:14:16 would you mind looking at a pastebin? Aug 04 19:14:37 I can Aug 04 19:15:17 http://pastebin.com/V8MiDmJt Aug 04 19:16:19 ya, as a minimum that works.. Aug 04 19:16:36 the BBFILES says that your new recipes will be installed into the layerdir/recipes-*/* Aug 04 19:16:42 and be called *.bb and *.bbappend Aug 04 19:16:58 if that is correct you are good.. if you want a different path breakup, you can change the wild cards.. Aug 04 19:18:10 the only other thing you might want to change: Aug 04 19:18:11 The BBFILE_PRIORITY variable then assigns a priority to the layer. Applying priorities is useful in situations where the same recipe might appear in multiple layers and allows you to choose the layer that takes precedence. Aug 04 19:18:21 the higher the number the higher the priority.. Aug 04 19:18:33 so if you want to force your layer to have precedence, put it at 100 Aug 04 19:18:37 (or higher) Aug 04 19:18:53 sounds good, i made it 100 Aug 04 19:19:06 the priority only matters say if you have two recipes with the same name in multiple layers.. Aug 04 19:19:10 give me a second to catch up on your instructions Aug 04 19:19:28 (I'm always a little sketchy when it comes to the BBFILE_PRIORITY field.. it's not used all that often in reality) Aug 04 19:21:33 ok so i a tree which looks possibly correct Aug 04 19:21:38 * kergoth has setup scripts that reorder his BBLAYERS by BBFILE_PRIORITY so his recipe priority is aligned with bbclass/conf priority.. need to add a new sub-command to bitbake-layers to do that Aug 04 19:22:32 http://pastebin.com/WVW386Qr Aug 04 19:23:58 and I've added it to my BBLAYERS variable Aug 04 19:24:16 layer format looks fine Aug 04 19:24:37 kergoth, honestly I'm surprised we still have a BBFILE_PRIORITY.. and don't just use the BBLAYERS order Aug 04 19:24:52 i imagine, I need to edit that recipe I used which just completed building to specify the linux-beagleboard.org-4.1 kernel Aug 04 19:25:14 ie vi recipes/images/custom/jfd-image-recipe.bb Aug 04 19:25:17 this is where I don't know.. I don't do many kernel builds Aug 04 19:25:38 but I suspect there is only one 'linux-beagleboard.org' recipe on your system Aug 04 19:25:59 so either it needs to be formatted properly (having the right virtual provide) or you'll have to manually trigger it Aug 04 19:26:49 if I edit that file, it has a bunch of packages which I could enable/disable in hob. ie. kernel-module-libcrc32c, xauth, kernel-module-ppp-generic etc. Aug 04 19:26:49 fray: that's what i wanted when i responded to richard's original bblayers implementation, but he strongly felt it should be a variable, iirc. my original "collections" implementation controlled all priority via the order in the COLLECTIONS variable. Aug 04 19:27:18 http://git.openembedded.org/openembedded/tree/conf/collections.inc Aug 04 19:27:41 ya, and I'd rather it only be controlled by inclusion order.. ;) Aug 04 19:27:43 doing a search. nothing pops up as beaglebone Aug 04 19:27:47 I don't really like the priority value at all Aug 04 19:28:04 I could see a few cases where we automate the priority during including, and only specify it when necessary Aug 04 19:28:25 it was a matter of who owned the knowledge, he thought the layer owner would know better than the user on that, iirc Aug 04 19:28:56 but the problem with that is, they don't always know best, and priorities are only useful in context Aug 04 19:28:58 here is not the whole line, but here is where I just added it Aug 04 19:29:00 IMAGE_INSTALL = "linux-beagleboard.org-4.1 kernel-module-nf-conntrack-ipv4 ke Aug 04 19:29:05 kergoth, yup Aug 04 19:29:08 i end up overriding the meta-oe priority so it never overrides oe-core Aug 04 19:29:22 IMAGE_INSTALL requires package names, -not- recipe names.. Aug 04 19:29:32 there likely won't be a package named 'linux-beagleboard.org-4.1' Aug 04 19:30:00 cry Aug 04 19:30:12 it did not even get that far Aug 04 19:30:15 ERROR: Unable to parse /home/davis/progs/my-new-layer/conf/layer.conf: file /home/davis/progs/my-new-layer/conf/layer.conf not found Aug 04 19:30:46 verify the file is there at that exact path.. if not.. correct the BBLAYERS Aug 04 19:31:35 yeah, that was a typo Aug 04 19:32:06 so its not a package name not a recipe name. but maybe with priority it will be used? Aug 04 19:33:13 i imaing this will fail but I can edit the jfd-image-recipe2 and remove it. I'm afraid to kill it while its trying to build since I'm afraid it might leave behind files Aug 04 19:33:36 interrupting a build is harmless. it'll pick up where it left off Aug 04 19:33:43 ahh, very good Aug 04 19:33:46 WARNING: No bb files matched BBFILE_PATTERN_my-new-layer '^/home/davis/progs/poky/my-new-layer/' Aug 04 19:33:49 NOTE: Resolving any missing task queue dependencies Aug 04 19:35:10 the the pattern listed in BBFILE_PATTERN is wrong.. make sure the pattern works using something like 'ls' and returns files Aug 04 19:35:22 i removed the entry from recipes/images/custom/jfd-image-recipe2.bb and the warning comes back no bb files matched BFILE_PATTERN_MY-new-layer Aug 04 19:36:03 cat your layer.conf.. and from the head of the directory specified in 'bblayers =' verify the pattern Aug 04 19:36:23 ls my-new-layer/recipes-kernel/linux/linux-beagleboard.org_4.1.bb Aug 04 19:36:26 is that what you mean? Aug 04 19:36:33 cd my-new-layer Aug 04 19:36:40 ls recipes-*/*/*.bb Aug 04 19:36:43 did you get a result? Aug 04 19:36:48 ls /recipes-*/*/*.bbappend Aug 04 19:36:53 again get a result? if not fix it Aug 04 19:36:56 yeah, that ls above is what I just did Aug 04 19:37:01 (second one remove leading '/' Aug 04 19:37:08 i just used tab completion Aug 04 19:37:26 kergoth both patterns don't have to match right, just one of them? Aug 04 19:38:02 BBLAYES has /home/davis/progs/poky/my-new-layer Aug 04 19:38:19 yeah, as long as anything matches it'll shut it up Aug 04 19:38:28 so something si wrong.. Aug 04 19:38:41 ls /home/davis/progs/poky/my-new-layer/recipes-*/*/*.bb Aug 04 19:38:50 ls /home/davis/progs/poky/my-new-layer/recipes-*/*/*.bbappend Aug 04 19:38:58 one of those needs a match.. if it matches, I don't know Aug 04 19:39:18 i only have one bb file Aug 04 19:39:39 doesn't matter.. the pattern has to match.. it's globbed.. so a simple 'ls' with the path should show you if the glob is right or not Aug 04 19:39:45 it is my-new-layer/recipes-kernel/linux/linux-beagleboard.org_4.1.bb Aug 04 19:40:08 that appears to match to me Aug 04 19:40:12 well, the error is saying that the system didn't find anything matching the glob Aug 04 19:40:17 you'll have to figure out why Aug 04 19:41:01 i think this is key Aug 04 19:41:03 No bb files matched BBFILE_PATTERN_my-new-layer Aug 04 19:41:09 yes.. Aug 04 19:41:17 the original was of the form BBFILE_PATTERN_skeleton Aug 04 19:41:23 the system collections everything from BBFILES into a big list (or pathnames based on globs) Aug 04 19:41:27 yet it was meta-skeleton Aug 04 19:41:38 it then looks at BBFILE_PATTERN_ and matches that pattern against the overall file list Aug 04 19:41:45 "^${LAYERDIR}/" Aug 04 19:42:07 that says that at least ONE file found must start with the path to the layer directory'/' Aug 04 19:42:24 the error is saying that no files were found that match that pattern.. Aug 04 19:43:01 LAYERDIR is the immediate directory of the layer as specified by BBLAYERS = when processing.. it's evaluated immediately not not stored as "LAYERDIR", but as the evaluated value Aug 04 19:43:13 if I take the error message and copy and paste it, it shows the conf and recipes-kernel dir Aug 04 19:43:32 pastebin it then Aug 04 19:43:34 the error says no bb file matched Aug 04 19:43:49 the bb file is in the recipes-kernel subdir and not at that level Aug 04 19:43:55 i'll pastebin it Aug 04 19:44:54 http://pastebin.com/kWb5uRAW Aug 04 19:45:33 that doesn't show the error Aug 04 19:46:04 one sec ill generate it again Aug 04 19:47:05 http://pastebin.com/3m2TyE7Y Aug 04 19:48:12 the warning is saying.. that after processing BBFILES, the pattern listed (regex) was NOT found Aug 04 19:48:27 thus no bb files from your "/home/davis/progs/poky/my-new-layer/" were foiund by the system Aug 04 19:48:35 they're found by the globbing in BBFILES Aug 04 19:49:16 you can try bitbake -e , then search the result for 'BBFILES' and see what it was looking for, and verify that something starting with that shows up when you look for globs. Aug 04 19:49:28 i.e. Aug 04 19:49:31 BBFILES=" /home/mhatle/git/oss/oe-core/meta/recipes-*/*/*.bb" Aug 04 19:49:44 [mhatle@msp-dhcp23 build]$ ls /home/mhatle/git/oss/oe-core/meta/recipes-*/*/*.bb | wc -l Aug 04 19:49:44 883 Aug 04 19:50:02 BBFILE_PATTERN_core="^/home/mhatle/git/oss/oe-core/meta/" Aug 04 19:50:13 so we have 883 items that match the 'core' layer pattern.. so I don't get a warning Aug 04 19:50:48 ok Aug 04 19:51:31 lol, i am so lost. omg Aug 04 19:51:47 bitbake -e is like typing 'env' in a shell.. you get everything that is set in the environment.. Aug 04 19:51:57 just pipe it to less and search for 'BBFILES=' Aug 04 19:52:35 you will see all of the BBFILES += ... lines from your layers conf/layer.conf expanded there.. Aug 04 19:52:39 ok bitbake -e | less and then search for my Aug 04 19:53:00 i see /all the .conf files in that tree Aug 04 19:53:43 ignore the lines starting with '#'. These are debug info on how the variable was constructed Aug 04 19:53:50 i see this /home/davis/progs/poky/my-new-layer/recipes-*/*/*.bb Aug 04 19:54:16 and if I use that at prompt like so, ls /home/davis/progs/poky/my-new-layer/recipes-*/*/*.bb Aug 04 19:54:17 that is glob that you should be able to check if it expect Aug 04 19:54:27 i see the linux-beagleboard.orgxxxx.bb file Aug 04 19:54:50 I don't know then.. Aug 04 19:55:02 same here Aug 04 19:55:18 the system it telling you it didn't find it.. Aug 04 19:55:38 bitbake -DDDDDD might show you way more then you want Aug 04 19:56:03 you should be able to watch it evaluate everything Aug 04 19:57:08 do i need to resource the script? Aug 04 19:57:21 no.. just add -DDDDD to your bitbake call Aug 04 19:57:33 (each -D adds more debugging) Aug 04 19:58:01 it wouldn't surprise me if it was something like the '.' in the name that wasn't allowed.. Aug 04 19:59:36 hmm. it says debug:exclude form world a bunch of times and then parsing complete and then warning, no bb files matched BBFILE_PATTERN_my-new-layer Aug 04 20:00:22 at top it says DEBUG: Adding layer /home/davis/progs/poky/my-new-layer Aug 04 20:01:47 it seems to be it wants a .bb file in the root of my-new-layer Aug 04 20:01:50 add -s Aug 04 20:02:15 but poky/meta does not ahve a .bb file Aug 04 20:02:28 doesn't matter.. you are providing your own Aug 04 20:02:49 adding -s will also show you everything it did find Aug 04 20:05:53 same thing. WARNING: No bb files matched BBFILE_PATTERN_my-new-layer '^/home/davis/progs/poky/my-new-layer/' Aug 04 20:07:48 that message means its literally not finding the dir, right? Aug 04 20:08:07 yes Aug 04 20:08:27 but since your conf/layer.conf was loaded it found the dir, but not the recipe(s) inside the dir.. Aug 04 20:08:50 im comparing the my-new-layer and meta-skeleton Aug 04 20:09:01 just on a wild change, rename the recipe and get rid of the beagleboard.org piece.. call it something like linux-beagleboard_4.1.bb Aug 04 20:09:04 both have a conf/layer.conf Aug 04 20:09:29 but have a recipes-kernel Aug 04 20:09:39 as a peer to conf dir Aug 04 20:10:41 only diff is in that recipes-kernel the dirs/filenames inside differ in form Aug 04 20:11:26 linux/linux-yocto-cutom and linux/linux-yocot-custom.bb vs linux-beagleboard.org_4.1 Aug 04 20:11:55 maybe I sould rename it to linux-beagleboard.bb Aug 04 20:12:20 recipe filenaems are: _.bb Aug 04 20:12:25 the _ is optional Aug 04 20:12:46 so the way it's currently named "linux-beagleboard.org" is the name.. and I'm wondering if the '.' isn't allowed.. Aug 04 20:13:32 the one with custom.bb has a . in it Aug 04 20:15:22 i wonder if the recipe name must have my-new-layer in it Aug 04 20:17:04 no it shouldn't Aug 04 20:20:32 hmm Aug 04 20:20:40 i noticed a naming convention error Aug 04 20:21:43 arc linux-beagleboard.org-4.1 linux-beagleboard.org-4.1.bb Aug 04 20:21:56 i made it so that the .bb file had the same pattern as the dir Aug 04 20:22:11 the original had a _ in one and a - in the other Aug 04 20:22:18 however that did not fix the problem Aug 04 20:22:30 WARNING: No bb files matched BBFILE_PATTERN_my-new-layer '^/home/davis/progs/poky/my-new-layer/' Aug 04 20:22:56 i don't get it. i can literraly copy and paste that string excluding the leading ^ and I see the layer Aug 04 20:23:18 and the subdir pattern matches the meta-skeleton path Aug 04 20:34:13 I've replicated your problem here.. Aug 04 20:44:08 ok.. I've verified inside of bitbake, it never loaded the recipe.. Aug 04 20:44:15 now to figure out why Aug 04 20:48:31 BINGO Aug 04 20:48:50 I know what the problem was! the item (I was testing with) was broken.. so the system was ignoring it intentionally Aug 04 20:49:01 when I did 'bitbake linux-yocto-custom' I get a reasonable eror: Aug 04 20:49:08 ERROR: Nothing PROVIDES 'linux-yocto-custom' Aug 04 20:49:08 ERROR: linux-yocto-custom was skipped: We shouldn't have multilib variants for the kernel Aug 04 20:49:08 ERROR: linux-yocto-custom was skipped: incompatible with machine qemumips64 (not in COMPATIBLE_MACHINE) Aug 04 20:49:08 ERROR: linux-yocto-custom was skipped: We shouldn't have multilib variants for the kernel Aug 04 20:49:27 on your system try bitbake linux-beagleboard.org Aug 04 20:49:36 see if you get an error like above.. Aug 04 20:49:48 if so, the recipe doesn't work, so it was being ignored.. which is why the warning was being issued.. Aug 04 20:50:06 (I'd say there is a bug in the warning then.. it shouldn't kick the warning if it loaded something, even if it was disabled) Aug 04 20:50:28 huh, interesting Aug 04 20:50:38 ya.. that explains the problem.. but confusing as hell Aug 04 20:56:13 yep Aug 04 20:58:37 sorry i was in a meeting Aug 04 20:58:39 i'm back Aug 04 20:59:45 Hmmm, not sure if I'll be able to implement shallow clones without enhancing the fetcher core, since I want to try fetching a shallow tarball and then fall back to trying to fetch a normal git tarball, and there's only one field of the urldata for the tarball filename/path, not a list of them Aug 04 20:59:52 * kergoth ponders Aug 04 20:59:52 davis@yoshi:~/progs/poky/build$ bitbake linux-beaglebone.org Aug 04 21:00:00 gives same error as before Aug 04 21:00:01 WARNING: No bb files matched BBFILE_PATTERN_my-new-layer '^/home/davis/progs/poky/my-new-layer/' Aug 04 21:00:01 and then Aug 04 21:00:02 ERROR: Nothing PROVIDES 'linux-beaglebone.org'. Close matches: Aug 04 21:00:39 ahh, typo Aug 04 21:01:10 ERROR: linux-beagleboard.org-4.1 was skipped: incompatible with machine beaglebone (not in COMPATIBLE_MACHINE) Aug 04 21:01:18 davis no there ya go.. Aug 04 21:01:27 beagleboard not beaglebone Aug 04 21:01:30 it DID read it.. the recipe is missing stuff.. so the item was skipped because it was broken Aug 04 21:01:35 so same thing I found here.. Aug 04 21:01:37 ahh Aug 04 21:01:50 so there is likely a bug (or something) in the WARNING.. but the recipe was loaded and the layer was generated properly Aug 04 21:03:35 compatible machine in the new .bb file is ti33x|ti43x|omap.. etc Aug 04 21:03:56 ya, I have no idea at this point.. I don't do kernel work normally Aug 04 21:03:58 but at top level, my layers.conf is beaglebone Aug 04 21:04:03 so is that the problem? Aug 04 21:04:24 probably.. the MACHINE setting in layers.conf and the kernel recipe must match as to what is supported, or it will disable the configuration Aug 04 21:04:51 i just added beaglebone to the list of ORs Aug 04 21:05:09 and it went to next step which failed for parsing the hit Aug 04 21:06:33 Invalid protocol - if you wish to fetch from a git repository using http, you need to instead use the git:// prefix with protocol=http Aug 04 21:10:19 i tweaked that up a bit. at least it seems to be doing a pull Aug 04 21:13:51 fray, what is your address? i'll send you a postcard. I appreciate your help immensely **** ENDING LOGGING AT Wed Aug 05 02:59:58 2015