**** BEGIN LOGGING AT Fri Oct 14 02:59:58 2016 Oct 14 07:12:12 I'm new to jenkins, After initiating the yocto job, i could see this "bitbake-worker decaf bad" Oct 14 07:12:18 I have no idea about this Oct 14 07:12:23 Can any one help on this? Oct 14 07:19:03 any idea about "bitbake-worker decaf bad' Oct 14 07:46:29 Kesav: that's the bitbake worker tasks, it forks as many as required to do multiple builds in parallel Oct 14 07:51:59 good morning Oct 14 08:03:04 Hi there. It's my first time with yocto and on embedded programing in general. Oct 14 08:03:57 I'm following the manual to setup an image. On the 2nd point, configuring the build Oct 14 08:05:36 I have the question on which directory I should be. Because I have downloaded the freescale BSP and also the poky release Oct 14 08:06:20 aVV: once you run bitbake the first time you have the build directoru magically created Oct 14 08:06:22 So I have: ~/fsl-release-bsp (it also has a poky folder) and ~/poky Oct 14 08:06:49 aVV: inside build you have conf directory Oct 14 08:07:25 I'm confused on which folder I must work on Oct 14 08:08:14 I want to create an image for my freescale board Oct 14 08:08:54 aVV: this doc should help you : http://wiki.kaeilos.com/index.php/Yocto_Project_my_own_quick_start Oct 14 08:09:12 aVV: it's a bit outdated but the principles are te same Oct 14 08:09:47 aVV: read Initializing the Build Environment Oct 14 08:11:08 mckoan, yeah, I already did the quick start tutorial Oct 14 08:11:18 now I am at the 2nd part Oct 14 08:12:53 I'm asking if I downloaded the freescale BSP, I must continue to work on that directory? Oct 14 08:13:56 it has: setup setup-environment.sh Oct 14 08:14:53 and source folder with: base; meta-fsl-..., poky Oct 14 08:15:55 aVV: you have to run bitbake from $HOME/yocto/poky directory only (as a gernel rule) Oct 14 08:16:22 aVV: read carefully the docs Oct 14 08:16:54 aVV: hm, i'd suggest to take a step back and leave the fsl stuff and your board out of the scope for some time. 1) do and understand the yocto quick start 2) add an own layer with some trivial recipe (the yocto-layer tool can help you with that) 3) then continue to use the fsl stuff Oct 14 08:17:10 rburton : When i ran a yoco job in jenkins, after sometime it stays one task (noexec) for long time Oct 14 08:17:28 aVV: that way you'll grasp the interconnections, and then be able to act on the fsl stuff accordingly Oct 14 08:19:27 aVV: its really essential to understand the trinity of 1) the base layer - in your case poky 2) the additional layer - the fsl stuff in your case and 3) the build directory Oct 14 08:20:30 ok, I understand. The base directory is the poky dir Oct 14 08:20:50 from there I add the fsl layer Oct 14 08:21:15 aVV: my usual suggestion is a dir layout like that: Oct 14 08:21:20 project Oct 14 08:21:26 |- poky Oct 14 08:21:30 |- meta-y Oct 14 08:21:37 |- meta-x Oct 14 08:21:42 |- meta-z Oct 14 08:21:45 |- build Oct 14 08:25:33 Kesav: that might be buildhistory writing, if you've enabled that Oct 14 08:27:05 aVV: I updated the wiki read it: http://wiki.kaeilos.com/index.php/Yocto_Project_my_own_quick_start Oct 14 08:28:47 mckoan, nice :D Oct 14 08:28:55 rburton : Is there any chance to see that? Oct 14 08:30:30 Kesav: see the buildhistory? the buildhistory directory under your build/ tree Oct 14 09:16:09 rburton : yes its writing some build history. But any idea why sometimes it takes more time? Oct 14 09:17:07 git gc? Oct 14 10:02:27 how do I know how to configure local.conf? I already downloaded the meta layers that I need Oct 14 10:04:35 aVV: read it throughly, its very well commented. and theres an even more exhaustive version in poky/meta-poky/conf/local.conf.sample.extended Oct 14 10:05:36 aVV: actually theres only one thing that you really should look at always: MACHINE. the rest is, read the comments and then decide for yourself Oct 14 10:05:38 I mean where I find the MACHINE name for my board? Oct 14 10:05:47 yeah Oct 14 10:06:03 aVV: look at your layer, and conf/machine in there Oct 14 10:06:11 ok Oct 14 10:07:11 got it, thx! Oct 14 11:17:36 How do I get a list of the possible images I can build with bitbake? Oct 14 11:26:18 aVV: there's no simple or standard way, usually a layer puts image recipes in an "images" directory (e.g. recipes-core/images, recipes-rt/images, recipes-graphics/images, etc) Oct 14 11:26:55 aVV: so doing a "find . -name images -print" from the point where your layers are located can find some, but isn't guaranteed to find all Oct 14 11:31:15 found this cmd Oct 14 11:31:32 bitbake-layers show-recipes "*-image-*" Oct 14 11:31:39 but it takes his time Oct 14 11:32:09 and relies on recipe writers naming their images with "image" in their name somewhere :-) Oct 14 11:32:28 you can list all recipes that inherit image Oct 14 11:32:34 using -i image to show-recipes Oct 14 11:34:23 rburton, thx Oct 14 11:35:47 rburton: nice! Oct 14 11:36:16 Hi all. Did anyone worked on meta-virtualization? I have an issue with docker. Oct 14 11:47:50 newguy_10, what's the issue ? It works quite well for all my use cases. Oct 14 11:50:07 zeddii:While running dockerd on qemux86-64, there is no docker bridge being created. Oct 14 11:51:05 that's specific to your board/setup. you need to arrange with systemd (networkd) or sysvinit to create whatever you need. you do that by bbapending the appropriate recipes that manage your network. Oct 14 11:51:26 the docker recipe itself stays out of that, the type of network you want is a policy set elsewhere. Oct 14 11:53:49 zeddii:I am new to this. Can you please tell me what are the recipes I need for that? Oct 14 11:54:23 here's how I do it in images that use docker, lxc, etc: https://github.com/OverC/meta-overc/blob/master/meta-cube/classes/builder-base.bbclass Oct 14 11:59:43 zeddii: when I run "dockerd -D" I am getting the following debug message: "INFO[0002] Graph migration to content-addressability took 0.00 seconds DEBU[0002] Option DefaultDriver: bridge DEBU[0002] Option DefaultNetwork: bridge DEBU[0003] libcontainerd: containerd connection state change: READY" Oct 14 12:01:19 zeddii:Yet when I give "ifconfig" I don't see any docker0 bridge. So you think I should try the solution u described? Oct 14 12:01:45 you don't need a bridge by that name, just connectivity, with the configuration I pointed at, I am running both lxc and containerd/runc/docker off the bridge (or OVS). Oct 14 12:02:45 zeddii:Thanks. I will try the method you suggested. Oct 14 12:03:59 you can also mail meta-virtualization mailing list if it doesn't work. I'll be off IRC later, but will always see a question on the list. Oct 14 12:04:32 zeddii:Ok.Got it. Oct 14 12:05:01 zeddii: are .dtb files for qemuarm new with the 4.8 kernel? apparently we're not publishing them on the AB Oct 14 12:05:27 it was actually 4.7, but yes, for 4.8 only in the yocto available kernels. Oct 14 12:06:14 thanks, just wasn't sure why we hadn't seen this before Oct 14 12:06:31 it's the only artefact generated for a qemuarm build which doesn't include qemuarm in the filename Oct 14 12:06:39 so it doesn't get matched by the current glob Oct 14 12:07:15 right. yah, it is a re-use/overload of 'real' boards dts, which I suffered with as well. Oct 14 12:08:19 re meson, ross has a prototype package Oct 14 12:08:32 kind of hard-coded to cross compile for arm, and doesn't do any more than hello world yet Oct 14 12:08:35 but its a start Oct 14 12:08:48 other channel rburton, though your patches were mentioned Oct 14 12:08:55 we already pointed Saur at them Oct 14 12:08:57 yeah just noticed wrong channel Oct 14 12:25:07 is the NetworkManager on 1.0 version in oe master on purpose or it's just that nobody has yet updated to 1.2? Oct 14 12:26:22 zeenix: likely because nobody cares enough to update it Oct 14 14:40:06 Hmm, I just noticed that bitbake ignores a task depending on a missing task. i.e. addtask something after do_nonexistent_task Oct 14 14:40:19 no errors Oct 14 14:40:49 that seems bad, could easily miss a typo or uninherited class there, particularly since we have an addtask api now, so conditional addtasks are doable Oct 14 14:41:06 That does seem like a misfeature. Oct 14 14:41:27 I think it was probably intended to allow for conditional, like "do X if Y exists-and-happens". Oct 14 14:43:12 yeah, thats what i figured too, a remnant of before we had addtask, to handle the task either being there or not depending on what classes are inherited Oct 14 14:43:24 but nowadays we should make it fatal, we can do a conditional addtask in anonymous python istead Oct 14 14:43:36 s/before we had addtask/before we had bb.build.addtask()/ Oct 14 15:20:38 Hello. I am attempting a Yocto Jethro build with systemd on my Variscite DART6UL SoM (Freescale imx6UL). systemd starts in the boot process, but then the boot fails Oct 14 15:20:44 Timed out waiting for device dev-ttymxc0.device Oct 14 15:21:07 So I don't even get the login prompt in the serial console. Oct 14 15:21:59 Any help you could provide to fix this would be greatly appreciated. Oct 14 15:22:38 eduardas_m: iirc there was some kernel feature that caused that when missing, but don't remember which Oct 14 15:25:30 https://lists.yoctoproject.org/pipermail/meta-freescale/2015-June/014276.html Oct 14 15:25:49 CONFIG_FHANDLE=y Oct 14 15:25:51 eduardas_m: CONFIG_FHANDLE Oct 14 15:25:54 yeah Oct 14 15:26:23 I wonder - is this fixed upstream? Oct 14 15:26:44 eduardas_m: what should be fixed where upstream? Oct 14 15:27:06 LetoThe2nd, in the later Yocto releases Oct 14 15:27:33 eduardas_m: why should yocto care about the kernel config of a specific board being suitable for systemd? Oct 14 15:28:28 eduardas_m: if the board by default should use systemd, then the board layer should take care of it, otherwise the layer that makes it use systemd Oct 14 15:29:23 LetoThe2nd, yeah, that might be correct... honestly, I am not even sure how widespread systemd in embedded actually is Oct 14 15:30:08 eduardas_m: lets say, it is not unheard of. but it entirely depends on your usecase Oct 14 15:30:59 LetoThe2nd, just as an interesting note... it actually built ok with Yocto Fido for that very same board with systemd Oct 14 15:31:41 so what I got now was quite unexpected Oct 14 15:32:13 eduardas_m: then i'd say check the differences between the layers. of course it might also be systemd changing behaviour, but as a first guess i'd rather look at your bsp layer. Oct 14 15:33:51 LetoThe2nd, I am somewhat hopeful that systemd can be used to optimize userspace bootup for my board... not sure how much sense that statement makes to experts Oct 14 15:34:41 eduardas_m: maybe the kernel config changed between the fido and the jethro state for your layer. i at least know that systemd has needed CONFIG_FHANDLE ever since i looked, and i think that is at least since dylan back then Oct 14 15:34:52 eduardas_m: it can help, but its a piece at most. Oct 14 15:35:47 eduardas_m: theres a lot of other points to boot time, the most important one being to find out where the time gets actually spent until the point where you are satisfied with the boot progress Oct 14 15:36:59 eduardas_m: then 1) rip out everything not needed 2) delay everything not needed immediately and 3) optimize those things really needed. in that order. and systemd certainly belongs to 3) Oct 14 15:38:02 LetoThe2nd, in my case (Fido with systemd) systemd-analyze blame gives the longest time for 5.810s dev-mmcblk0p2.device Oct 14 15:38:17 which is the rootfs partition of the SD card I use Oct 14 15:38:28 eduardas_m: but thats only userland. Oct 14 15:39:01 kernel takes 2.7 s Oct 14 15:39:11 eduardas_m: two of the simplest optimizations are: 1) turn everything not immediately needed inside the kernel into a module 2) disable the serial console Oct 14 15:39:16 userspace takes 6.9 total Oct 14 15:40:15 LetoThe2nd, what is the method of disabling serial console.. there is a parameter I can pass through u-boot? Oct 14 15:40:27 eduardas_m: then i'd say, focus on making your device boot without the sd. if mounting it is that slow Oct 14 15:40:47 eduardas_m: parameter "quiet", IIRC Oct 14 15:43:15 LetoThe2nd, I think I read somewhere that systemd allows prioritising mounting a specific folder first... is it possible to mount only the part of the rootfs with a statically linked GUI executable first? Oct 14 15:43:38 so that the GUI becomes available as quickly as possible Oct 14 15:43:50 eduardas_m: no idea, i would rather try to beat it into an initrd or such Oct 14 15:45:03 LetoThe2nd, wow, you have been of great help today... you know, this channel is actually really awesome Oct 14 15:45:37 eduardas_m: np, good luck then Oct 14 15:45:39 I am glad that Yocto actually has an active community around it :) Oct 14 17:49:31 hi guys Oct 14 17:49:47 I want to add a user to another group in a recipe of a package Oct 14 17:49:55 this user already exists Oct 14 17:50:06 so useradd class does not work to me Oct 14 17:50:16 anyone knows how to do that?; Oct 14 17:50:45 I saw the extrausers class, but it can be used only on image recipes Oct 14 17:50:50 or local.conf Oct 14 17:50:52 well, you can call adduser $user $group yourself Oct 14 17:51:22 but tbh given the complexity of sstate and sysroot handling useradd currently contains, I'd recommend not to attempt this and try to find a different solution Oct 14 17:51:31 e.g. bbappending the recipe the creates the user Oct 14 17:51:53 this user is default, is the www-data Oct 14 17:52:08 its came by default Oct 14 17:54:01 I will try extrausers, im asking just to organize in a different way, but extrausers can be used Oct 14 17:54:07 thank you neverpanic Oct 14 20:42:34 I wonder if there is a way to prune the sstate to just what the extensible SDK is going to use? Oct 14 20:55:46 To answer my own question. It appears one has to erase the tmp dir, build a second time from sstate and then do something like: sstate-cache-management.sh -y --cache-dir=../sstate-cache -v --stamps-dir=tmp/stamps **** ENDING LOGGING AT Sat Oct 15 02:59:58 2016