**** BEGIN LOGGING AT Wed Sep 30 02:59:59 2015 Sep 30 07:13:59 morning all Sep 30 07:20:56 good morning Sep 30 07:21:23 morning all Sep 30 07:23:12 I have strange problem, I build ext4 image for beaglebone, when loaded to emmc kernel will start and mount rootfs but then it seems stuck after INIT: version 2.88 booting, when I press Enter on console it will continue with: Starting udev Sep 30 07:23:23 any idea what can cause such behavior? Sep 30 07:23:43 after booting will continue and I get login prompt Sep 30 07:32:54 hmm, bitbake -g -u depexp suddenly started failing with just «Command execution failed: » Sep 30 07:33:05 (doesn't show any error) Sep 30 07:33:59 sandsmark: that's annoying... if you just try to build that same target does it work? Sep 30 07:34:05 I'm trying that now Sep 30 07:34:16 ah, no Sep 30 07:34:20 but now it shows the actual error Sep 30 07:34:37 ok, I guess we have a bug in reporting errors there Sep 30 07:34:50 what was the error? Sep 30 07:35:07 I broke a recipe Sep 30 07:35:10 I'll pastebin it Sep 30 07:35:21 http://pastie.org/pastes/10451465/text Sep 30 07:35:35 (obvious error on my part) Sep 30 07:37:01 whatever sends the event doesn't set the event.error: https://github.com/openembedded/bitbake/blob/master/lib/bb/ui/depexp.py#L304 Sep 30 07:38:36 ah, ctrl+c-ing bitbake sometimes makes some python process go bananas eating all my ram (I suspect the bitbake server) Sep 30 07:44:30 sandsmark: yes, we've had other reports of that unfortunately :/ Sep 30 07:44:51 ok, I'll try to track down why it happens next time it happens Sep 30 07:45:54 SIGKILL all of them except one and then attach with gdb, I guess Sep 30 07:46:16 (as long as it isn't just something specific to my setup) Sep 30 07:47:26 but first try to figure out why the gles3 header is available in the sysroot that is used to build qt for the sdk, but not in the sysroot that the sdk installs Sep 30 08:40:40 For some reason my system keeps selecting a specific recipe version (not the latest version), the default_preference has been set to -1 in the recipe. When I hard define the preferred_version it selects the correct recipe version (latest version in oe-core). Anything explaining this behavior? Sep 30 08:41:18 RagBal: layer priorities perhaps? Sep 30 08:41:59 RagBal: if the priority of the layer in which the older recipe appears is higher, it will be picked in preference to the newer recipe Sep 30 08:42:00 bluelightning, yes the layer has a higher priority, but doesn't default_preference -1 solve this? Sep 30 08:42:04 nope Sep 30 08:42:18 DEFAULT_PREFERENCE is weak compared to layer priority Sep 30 08:43:02 I'm not entirely sure it always makes sense, but it is the way it's been designed Sep 30 08:43:35 Hmm, so the only way is to provide a preferred_version? =( Sep 30 08:45:06 isn't that better in a way? Sep 30 08:45:29 imho it is more consistant if everything in a high priority layer is prioritized Sep 30 08:45:53 Yes, but in this case I don't want that =) Sep 30 08:46:18 is there an issue with setting a PREFERRED_VERSION? Sep 30 08:46:55 Well, I have to change it every time oe-core updates it Sep 30 08:47:15 This is about libdrm in meta-ti fido branch Sep 30 08:49:17 is it possible to easily see which recipe a file in a sysroot comes from? Sep 30 08:50:36 sandsmark: yes - check the manifest files in tmp/sstate-control/ Sep 30 08:50:53 awesome, thanks Sep 30 08:51:33 RagBal: I guess the question is do they really need their own version? Sep 30 08:53:00 bluelightning, you're correct, I just bbappended the recipe so it doesn't support my machine Sep 30 08:53:53 bluelightning, for some reason they added my machine in the compatible_machine of the recipe Sep 30 08:54:00 ah, ok Sep 30 08:54:03 http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/recipes-graphics/drm?h=fido&id=51afff21120ae64f2807537ecde719556c19ec8b Sep 30 08:57:39 denix, could you have a look at that please? it seems that libgles-omap3 requires libdrm >= 2.4.59 (from oe-core) but since the older libdrm is provided by meta-ti it takes precedence over the oe-core layer one and fails to build the rootfs Sep 30 09:00:25 ok, if I understand this correctly; for some reason mesa builds gles3 and installs it in the sysroot used for building qtbase, but the qtbase used in the sdk doesn't depend on gles3, so it's not pulled into the sdk?: http://pastie.org/pastes/10451569/text?key=ollhu4gcvthbmhkpovassq Sep 30 09:18:48 Hi, I use a package linux-firmware-wl12xx in my image, but whenever I include it also linux-firmware-wl18xx is being installed and I can't find any dependency between those packages. Any hints? Sep 30 09:24:53 frsc: try «bitbake -g -u depexp imagename», and clicking around Sep 30 09:26:22 sandsmark: That was the first thing I tried, but the linux-firmware-wl18xx does not seem to be anywhere in the dep tree, but still the packages is installed in do_rootfs... Sep 30 09:26:45 huh Sep 30 09:27:10 yeah, depexp only shows bitbake's initial picture of runtime dependencies Sep 30 09:27:32 some runtime dependencies are only calculated at packaging time (because there's no way to know about them earlier) Sep 30 09:37:06 Ok. It's something about my bbappend to linux-firmware: pastebin.com/HNjFbgLq. Whenever I use the bbappend the unwanted package is installed Sep 30 09:42:26 frsc: so after building with the bbappend, what does tmp/sysroots//pkgdata/runtime/linux-firmware-wl12xx have to say about RDEPENDS ? Sep 30 09:45:46 bluelightning: Ok, I can see the dependency there: RDEPENDS_linux-firmware-wl12xx: linux-firmware-wl18xx. But where does it come from? Sep 30 09:46:31 frsc: if I had to guess, there's something silly happening with symlinks - the packaging code will automatically add dependencies where a symlink exists that crosses a package boundary Sep 30 09:47:04 the same sort of thing can happen with shared library dependencies but I can't see how that would be applicable in this case Sep 30 09:47:54 frsc: first thing to check anyway is that the contents of each package is what you think it should be - look in the packages-split directory in the workdir for linux-firmware Sep 30 09:50:57 bluelightning: I already checked the package contents: they seem to be what they should be Sep 30 09:54:01 khem: ping Sep 30 10:00:27 bluelightning: The problem is caused by overriding FILES_linux-firmware-wl12xx in the bbappend. But how can this add a runtime dependency? Sep 30 10:19:35 frsc: well, I notice at least out of the box there is the reverse dependency - wl18xx depends on wl12xx Sep 30 10:24:08 bluelightning: you're right, and upon overriding FILES_linux-firmware-wl12xx this dependency vanishes and the other one (wl12xx depends on wl18xx) appears Sep 30 10:29:58 frsc: can you pastebin ls -lR packages-split/*wl* ? Sep 30 10:37:43 bluelightning: I was looking in the wrong packages-split dir before, because I changed the package revision. I found out know that the packages-split do not change, but the dependency is reversed upon overriding the FILES variable. Sep 30 10:37:49 bluelightning: http://pastebin.com/y0VXSQwX Sep 30 10:38:41 frsc: is that the only contents of the wl18xx package ? Sep 30 10:38:59 bluelightning: yes, it seems so Sep 30 10:39:49 bluelightning: that's why it pulls in wl12xx for the rest Sep 30 10:40:00 er... so where are the targets of those symlinks ? Sep 30 10:41:23 bluelightning: yes, I think that is part of the problem. The targets exist in wl12xx... Sep 30 10:42:03 ok... unless you've changed your bbappend I can't see how those files are being moved though, the FILES value doesn't take the entire directory, just two files Sep 30 10:47:31 the default FILES values from the recipe aren't correct though, both are claiming the ti-connectivity directory Sep 30 10:48:04 bluelightning: I didn't change the bbappend. It doesn't seem to matter what I put in FILES (original content, or only the two added files), the packages are always split the same, only the dependency is being reversed Sep 30 10:49:22 hmm, well, that is definitely unexpected behaviour but if we fixed the FILES values for both packages it shouldn't happen Sep 30 10:57:54 bluelightning: I can set both FILES values and then the wl12xx package contains only the two expected files, while wl18xx still has only the 5 symlinks. And the dependency is still there and reversed... Sep 30 10:58:27 frsc: are you able to publish your changes somewhere because I think I need to try this here... Sep 30 10:58:28 ? Sep 30 11:01:05 bluelightning: Thanks for investigating. What do you need? I'm using a dizzy Sep 30 11:01:22 and then the bbappend I already posted Sep 30 11:01:28 the bbappend plus any files it adds Sep 30 11:01:39 Ok Sep 30 11:05:17 bluelightning: http://wikisend.com/download/170644/linux-firmware.tar.gz Sep 30 11:06:11 wikisend eh? not seen that one before Sep 30 11:06:13 thanks Sep 30 11:12:16 frsc: well, I can confirm the behaviour at least Sep 30 11:31:23 frsc: I think your symlinks are colliding with the ln command in the original recipe - did you look in the ti-connectivity directory for the wl12xx package? it's got a broken symlink in it Sep 30 11:38:21 frsc: actually I think what's happening is the original firmware symlinks wl1271-nvs.bin to wl127x-nvs.bin - by changing FILES as you are, that other file goes into the wl18xx package, hence the dependency Sep 30 11:39:07 frsc: additionally, I suspect by just using cp you are overwriting the wl127x-nvs.bin file via the symlink, instead of overwriting the symlink itself Sep 30 11:39:48 so there are two problems to fix Sep 30 11:40:56 additionally you didn't really fix the FILES value for the wl18xx package, it's still grabbing all of the files in that directory including ones meant for the wl12xx package (I guess ones that you don't need, but had you fixed that it all would have worked; by accident perhaps, but there we are) Sep 30 12:02:32 <_taw_> is there a way to tweak KBUILD_DEFCONFIG config Sep 30 12:03:14 <_taw_> want to to use the defconfig in the kernel source, but need to enable CONFIG_ARM_APPENDED_DTB Sep 30 12:03:40 <_taw_> which is not enabled in the linux source tree contained defconfig Sep 30 12:13:09 <_taw_> yup seems so, I retire the question Sep 30 12:50:30 bluelightning: Ok. Thanks for looking into this. I missed the symlinking problem. After fixing the symlink and the cp the dependency is gone and everything seems to be ok. Sep 30 12:56:00 frsc: great :) no problem Sep 30 13:30:29 anyone recalls a multiubi IMAGE_FSTYPE? Sep 30 13:32:25 nvm, it's in current master Sep 30 14:34:46 joshuagl: btw, we ran a fido build having updated the version to 1.8.1. I think we might put this through QA and hopefully call it good Sep 30 14:35:03 joshuagl: there were some build failures but it was runtime test suite issues, nothing actually wrong Sep 30 14:37:05 RP: okey dokey, sounds good to me Sep 30 14:59:37 what does a Yocto combo layer do, and why would I want to use it. Sep 30 15:20:01 hey does bitbake automatically compile the latest linux kernel version? Sep 30 15:25:01 it depends on your BSP, the recipes in oe-core are 3.14 / 3.19 / 4.1 (that's what is used by the qemu BSPs and the qa ones in meta-yocto-bsp) Sep 30 15:31:47 rburton: how can i get it to compile 3.8.7? :S Sep 30 16:14:10 dasabhi: write a recipe for 3.87 Sep 30 16:52:47 gotta love it: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=zeromq Sep 30 19:24:05 * challinan wonders why beaglebone black doesn't have SDCARD image type enabled Sep 30 19:34:23 to cause you pain Sep 30 19:35:39 heh. Not too painful for me, but ugly for lots of folks ;) Sep 30 19:35:57 see you next week Sep 30 21:31:26 RP: Am I correct in thinking that bitbake provides no guarantees on build order wrt argument order for the user specified targets? I wonder if we should do our best to obey that order, where possible (i.e. not impossible due to dependencies). Sep 30 21:37:23 that has certainly been my experience.. the order is not guaranteed Sep 30 21:37:35 kergoth: you mean "bitbake A B C" would try and do A then B then C? Sep 30 21:38:20 where possible, yeah Sep 30 21:38:26 kergoth: currently it just goes off the dependencies they all have, its down to whichever makes it higher up the tasklist Sep 30 21:38:35 i don't htink it'd affect performance much, since their dependencies would still be done efficiently Sep 30 21:38:37 * kergoth nods Sep 30 21:38:42 kergoth: I suspect trying to influence it like that would be hard :/ Sep 30 21:40:05 kergoth: you'd need a custom scheduler, the issue would then be getting the data the scheduler needs. The commandline args order isn't preserved and worse, is manipulated e.g. for world Sep 30 21:40:17 probably. it'd be nice, i think, but non-trivial to pull off. it'd be possible for them to run simultaneously, too, so it'd really only be a best effort, and you'd have to determine which of that recipe's tasks to prioritize relative to one another Sep 30 21:40:23 kergoth: or appended to e.g. with BBTARGETS (was BBPKGS) Sep 30 21:40:57 still, i suspect users might assume the order is obeyed, at least the folks without much understanding of how bitbake works Sep 30 21:41:01 kergoth: I can see the desire but there are probably other bigger issues... Sep 30 21:41:09 * kergoth adds a note to the someday/maybe list Sep 30 21:41:30 kergoth: I stopped maintaining one, too depressing :/ Sep 30 21:41:44 I was thinking the other day about trying to prioritize do_clean before everything else, so you could do bitbake foo:do_clean foo Sep 30 21:42:24 kergoth: I'm in two minds about whether we should actually have Sep 30 21:42:50 the manifest clean stuff got us closer to that model Sep 30 21:43:02 Ah, indeed, that seems like a reasonable approach Sep 30 21:46:48 kergoth: I've been thinking an overhaul of the bitbake debug messages would really be nice. Thinking through what is useful from a user perspective Sep 30 21:47:17 kergoth: I'm happy for example with the new virtual/xxx mapping debug messages compared to some of the other horrors in the output Sep 30 21:47:53 some are only intelligible when you have the source next to them :/ Sep 30 21:48:24 Yeah, I think we need to give careful thought to exactly what info is provided and for what purpose, and make sure there aren't better ways to get that information Sep 30 21:48:37 e.g. what's parsed, bitbake -e with parsing history is superior to parse log messages at the moment Sep 30 21:49:15 * kergoth ponders Sep 30 21:49:26 kergoth: totally agreed, the bitbake -e output is much better now Sep 30 21:50:14 a bitbake-query --var FOO is something I wondered about Sep 30 21:50:44 you could then add --with-history or something Sep 30 21:51:12 just thinking out loud. We at least have APIs and structure now where you could make this all work comparatively easily Sep 30 21:58:05 i've thought about that a lot, and it's part of why i threw 'bb' together, bitbake's lack of good inspection tools. what can we build, what vars can we set, what depends on what, etc. answer the user's questions without them having to dig into the docs. as you say, easy to improve that nowadays Sep 30 21:58:38 RP: +1 for bitbake-query --var FOO; most cases I actually look at bitbake -e output I'm interested in very few variables only Sep 30 21:58:58 Plus that would make it much easier to script stuff depending on bitbake config files Sep 30 21:59:50 neverpanic: https://github.com/kergoth/bb#examples - scroll down to 'bb show' Sep 30 21:59:55 unofficial, of course Sep 30 22:01:02 meh Sep 30 22:02:18 kergoth: thanks, will take a look Sep 30 22:06:08 hey all, I'm getting a bunch of these errors when generating my dev image Sep 30 22:06:19 WARNING: log_check: There is a warn message in the logfile Sep 30 22:06:19 WARNING: log_check: Matched keyword: [warn] Sep 30 22:06:19 WARNING: log_check: warning: gst-plugins-base-dev-0.10.36-r8@core2_32 is already installed Sep 30 22:06:44 any way to find out where the redundancies are? Sep 30 22:18:42 kergoth: bb was certainly ahead there Sep 30 22:19:50 not 100% happy with some of its behaviors, and of course before tinfoil switched to spawning a server, it ran things in the client directly, which wasn't ideal, but i think the sub-command based approach to a bitbake UI, which works either in a repl or directly on the commandline is a good direction to head in Sep 30 22:20:50 kergoth: agreed. I still have the bitbake shell in the back of my mind too Sep 30 22:21:24 kergoth: getting some feedback from people like belen on the usability side of this would be ideal if we could too Sep 30 23:01:14 which should be best place for defined a RPROVIDER variable in meta-core --context I'm editing initrdscripts files changing a dependency to busybox trying to look to to a virtual reference to be able to choose between multiple providers Oct 01 01:13:44 Is it possible to perform a .incappend as a .bbappend ? Oct 01 01:35:24 Hey folks Oct 01 01:35:56 I am new to yocto and am trying to patch a recipe for the intel edison. Oct 01 01:36:19 I am abusing yocto in a way, by building it on archlinux, which is not approved Oct 01 01:36:26 and the newest GCC won't build ncurses Oct 01 01:36:35 , although there is a patch, whcih I can apply Oct 01 01:37:00 I'm having issue building glic2 when running debian 8.2. the error seems to come from libc_pic.os' failed Oct 01 01:37:04 so my question is, how do I patch a recipe Oct 01 01:37:29 I can create a layer, right? And include a bbappend file that points to a patch, if I understand Oct 01 01:38:06 If anyone has link to step by step guidance on this, I would be appreciative - I've been looking at the developers guide, and am a little lost. Oct 01 01:38:17 ryansturmer: hi! Oct 01 01:39:02 ryansturmer: I gues you already when through this doc, https://www.yoctoproject.org/documentation Oct 01 01:39:48 ryansturmer: Otherwise, yeah you should be able to create a layer and then create a bbappend file to patch your recipe. Oct 01 01:40:18 ryansturmer: Keep in mind, if you create a new layer you need to includes it in your bblayer file Oct 01 01:41:17 build/conf/bblayers.conf Oct 01 01:41:46 any easy way/command to print the enabled DISTRO_FEATURES? Oct 01 01:59:19 So the distribution for the intel edison seems to be basically a couple of custom layers, plus a makefile and some scripts that they include to make things a little easier on folks Oct 01 02:01:55 so in order to create my custom layer, I've made a meta-mylayer directory Oct 01 02:02:13 with a conf/layer.conf Oct 01 02:02:36 and a recipes-core/ncurses Oct 01 02:03:01 with the ncurses core containing a ncurses_5.9.bbappend file Oct 01 02:03:15 and in the main image configuration, I've added the meta-mylayer layer Oct 01 02:04:00 ryansturmer: What's your questions exactly. Oct 01 02:04:44 Well my first question is, do those steps sound sane for ading a layer? Oct 01 02:04:50 next question would be: Oct 01 02:05:08 FILESEXTRAPATHS_prepend := "${THISDIR}/files:" Oct 01 02:05:08 SRC_URI += "file://work_around_changed_output_of_GNU_cpp_5.x.patch" Oct 01 02:05:24 that's the contents of my bbappend file, does that look on the right track? Oct 01 02:06:03 I'll start with your second question first. your bb append file seems goos. Oct 01 02:07:06 For you first question. I'm not sure what's the difference between the standards yocto release and the edion branch. I would have to verify. Oct 01 02:07:12 (implied: I have a 'files' directory in my layer that contains the referenced files) Oct 01 02:07:44 does the folder structure of my layer seem sane? Oct 01 02:08:43 hem, gimme a sec. Oct 01 02:12:10 I'm not sure to understand the layout of your layer but basicly Oct 01 02:12:53 you would normally have in your layer a conf/layers.conf file which kind of dictate where to look for bbappend file Oct 01 02:13:58 So let's say you want to bbappend the ncurse recipe. In your layer you would have the following my-layer/recipes-core/ncurse/ncurse_version.bbappend Oct 01 02:14:23 and your patch could be in the folder named files Oct 01 02:14:31 make sense? Oct 01 02:31:44 @clopez - try "bitbake -e > env.txt" Oct 01 02:32:03 then grep that output file for "DISTRO_FEATURES" Oct 01 02:33:28 you'll have to sift through some garbage, but you should see a section that shows all the operations performed on DISTRO_FEATURES with the final value Oct 01 02:33:31 $DISTRO_FEATURES [5 operations] Oct 01 02:33:31 # set? /home/ebolton/yocto/poky/meta-yocto/conf/distro/poky.conf:20 Oct 01 02:33:31 # "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC} ${POKY_DEFAULT_DISTRO_FEATURES}" Oct 01 02:33:31 # set? /home/ebolton/yocto/poky/meta/conf/distro/include/default-distrovars.inc:20 Oct 01 02:33:31 # "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC}" Oct 01 02:33:32 # set /home/ebolton/yocto/poky/meta/conf/documentation.conf:139 Oct 01 02:33:36 # [doc] "The features enabled for the distribution." Oct 01 02:33:38 # set? /home/ebolton/yocto/poky/meta/conf/bitbake.conf:714 Oct 01 02:33:40 # "" Oct 01 02:33:42 # append utils.py:105 [features_backfill] Oct 01 02:33:44 # " sysvinit" Oct 01 02:33:46 # pre-expansion value: Oct 01 02:33:48 # "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC} ${POKY_DEFAULT_DISTRO_FEATURES} sysvinit" Oct 01 02:33:49 do not spam the channel. Oct 01 02:33:50 something like that Oct 01 02:33:54 use a pastebin Oct 01 02:34:40 aj_c: no, you can only append a recipe file, and the append filename is based on the recipe filename. can't append arbitrary files, not .inc, not .conf, not bbclasses Oct 01 02:41:59 Ok well, that's essentially what I have @mtetreault Oct 01 02:42:20 kergoth: Yocto fails building glibc when I'm building with -j 8 but the build succeed when I build glibc alone and then continue building my image. Any idea how I could pin point the issue to patch this and submit a patch to the community? Oct 01 02:42:41 @ryansturmer: does your patch work? Oct 01 02:42:52 well, no Oct 01 02:44:39 @ryansturmer: you should be able to validate if your patch make it to the temp folder. build/tmp/work/(platform)/ncurses/version/ Oct 01 02:50:59 ebolton: I ended putting this on a recipe from the image Oct 01 02:51:04 python __anonymous() { Oct 01 02:51:04 bb.fatal ("DISTRO_FEATURES: %s" %d.getVar('DISTRO_FEATURES', True) ) Oct 01 02:51:04 } Oct 01 02:51:25 that would print the features, a bit hacky.. but not sure if your way is easier Oct 01 02:52:52 i wish there were a simpler/standard/non-hacky way of getting this info Oct 01 02:54:15 ? Oct 01 02:54:22 the whole point of bitbake -e is to examine the value of variables Oct 01 02:54:30 that's its purpose Oct 01 02:58:28 kergoth: that would be true if you are a machine.. but i'm an human, so i find a bit difficult to parse thousands of lines just to get the value of a variable. I just want to get the value of that variable printed to stdout **** ENDING LOGGING AT Thu Oct 01 02:59:58 2015