**** BEGIN LOGGING AT Fri Jul 17 02:59:58 2015 Jul 17 07:31:47 nerdboy: but in the termninal conf.c compiled by system toolchain (not for arm) and after that it is lanuched for configuration. If I do it in the recipe it compiled for arm, and ofcourse it cannot be launched, because my host system it x86_64. Jul 17 07:38:03 no Jul 17 07:38:43 you run make menuconfig with your cross toolchain manually Jul 17 07:39:04 get the config the way you want it and save Jul 17 07:39:27 copy .config to your custom defconfig and use it in the recipe Jul 17 07:39:54 as long as the kernel version dosen't change too much you're fine Jul 17 07:41:01 sometimes you have to force what you want until you figure out a better way Jul 17 07:42:35 i still don't see why a normal module recipe won't work, but that's your thing to figure out... Jul 17 07:48:38 nerdboy: I wrote you in PM Jul 17 07:49:48 no i can't do it for you i'm way too busy Jul 17 07:50:11 just follow your instructions and save the .config file Jul 17 07:50:46 use it as your recipe .config and "make oldconfig" should be clean Jul 17 07:53:19 ok, I will try Jul 17 07:53:23 thank you for the support Jul 17 08:17:36 nerdboy: is there a way to set host toolchaing for building some files in the recipe? Jul 17 08:25:28 hello everybody Jul 17 08:27:50 hi Jul 17 08:30:18 morning all Jul 17 08:33:43 gutten tag Jul 17 08:36:07 bluelightning: maybe you know Jul 17 08:36:44 bluelightning: is there a way to compile particular sources by host toolchain? Jul 17 08:38:18 and could somebody take a look http://dpaste.com/2K48M9C ? Jul 17 08:38:49 unrecognized option '-Wl,-O1' Jul 17 08:38:51 interesting Jul 17 08:42:13 how to enter a bitbake devshell on a remote server when connected using ssh? OE_TERMINAL=screen isn't working, none neither, or any of the X shells. Why can't I just enter a simple bash on the same console... Jul 17 08:42:34 ld options fixed Jul 17 08:43:50 but as I expected I have another problem :) Jul 17 08:44:53 here it is http://dpaste.com/0XAQKB2 Jul 17 08:45:03 permission denied? why? Jul 17 08:50:04 How to check that fcgi_stdio.h is provided in lighttpd package ? (and I am not sure it is the case...) Jul 17 08:51:03 Ox4: does the recipe you are using inherit module ? (assuming it's a module you're still building) Jul 17 08:53:05 Ox4: seems like DESTDIR is ignored when installing some of the files in the install target of the package Jul 17 08:53:06 mcfrisk: it doesn't work that way, it has to use an actual terminal Jul 17 08:53:55 mcfrisk: if the value you set isn't working it's either because it couldn't launch the specified terminal, or the variable value isn't actually set to what you think you set it to Jul 17 08:55:16 bluelightning: well I'm sshing to remote server, into an lxc container, and trying to debug a libgcc build failure in do configure. How should I debug that if devshell isn't working at all and logs don't show what went wrong? Jul 17 08:58:36 mcfrisk: nothing in log.do_devshell for libgcc ? Jul 17 08:59:07 also are any "Unsupported terminal" warnings printed? Jul 17 09:00:17 bluelightning: yes, it does Jul 17 09:00:23 it seems screen is in a loop trying to do something in the container.. I don't get it why getting a shell into bitbake build env is this hard or requires external shell utilities in X... Jul 17 09:00:29 bboozzoo: but why? Jul 17 09:01:15 mcfrisk: I don't know the details off the top of my head, but it is the way it is, and X is not required (screen works perfectly here) Jul 17 09:01:38 Ox4: I'm guessig that it's just not there, the files that are installed there are not the usual file that a module would install, my money is on someone adding them to install but forgetting to append ${DESTDIR} Jul 17 09:01:56 bboozzoo: prepend ;) Jul 17 09:02:15 bboozzoo: Ox4: that would be my assumption as well though Jul 17 09:02:16 Ox4: not the recipe, but the Makefile within the package Jul 17 09:02:19 right Jul 17 09:02:47 hm, thank you Jul 17 09:03:17 Hi there.. If I have a recipe in one layer, eg. myrecipe_1.0.bb, and I wish to put a newer version into another layer.. is that possible? No matter what I do, it takes the version from the first layer. Must all recipes be in the same layer, for different versions of the same recipe? I have tried adding PREFERRED_VERSION, without luck. Jul 17 09:03:42 Don't want interfer your speaking, need some help about adding package... I try to test lighttpd with simple example that works in desktop, but it cannot be compiled due to fcgi_stdio.h inclusion. Problem is I cannot find it in my sdk path after adding lighttpd package in recipe, generate ROOTFS and populate sdk... Jul 17 09:03:54 bboozzoo: bluelightning: but I perform oe_runmake DEPMOD=echo DESTDIR="${D}" INSTALL_MOD_PATH="${D}" LDFLAGS="" install-modules V=1 in do_install function Jul 17 09:04:11 take this, make tries to install this file `/etc/udev/rules.d/50-compat_firmware.rules`, but the location is within your system, normally you'd expect ${DESTDIR}/, the same DESTDIR that was passed with oe_runmake Jul 17 09:05:01 I'd start by looking at install target in the Makefile within the package :) Jul 17 09:05:29 understood, thanks Jul 17 09:06:18 kspr: not positive but it sounds like PREFERRED_VERSION may already be set for the recipe such that your setting is being overridden - can you check bitbake -e | less and search for PREFERRED_VERSION_ ? Jul 17 09:06:57 nice Jul 17 09:07:01 http://dpaste.com/2X7SMG6 Jul 17 09:07:06 bluelightning: ok, it's an lxc container issue: https://github.com/lxc/lxc/issues/554 Jul 17 09:07:29 it bitbake isn't run in a shell which is a tty, then devshell doesn't work at all Jul 17 09:07:57 but this file contains the following: http://dpaste.com/2ZPDS6X Jul 17 09:08:02 and with workaround of 'screen /dev/null' I now get a direct shell into env without screen or anything.. Jul 17 09:08:30 mcfrisk: that's unfortunate... if there is genuinely a way we could work around that (and preserve all the functionality we currently have, such as running the shell under pseudo) then it may be that we should have a workaround on our side Jul 17 09:08:34 ah I see Jul 17 09:08:56 mcfrisk: depends on the likelihood of it getting fixed there I guess Jul 17 09:10:22 vincenet: I don't think that's a header that lighttpd is meant to install, it's nowhere under the workdir for lighttpd here after I just built it Jul 17 09:10:53 bluelightning, Hmm, I think I'm doing it wrong - I have set PREFERRED_VERSION_recipe in my image recipe - is that the correct place? bitbake -e does not mention the recipe. Jul 17 09:10:53 vincenet: google suggests it may be something from fastcgi instead Jul 17 09:11:21 kspr: right, that will not work I'm afraid - that kind of setting must be set at the configuration level Jul 17 09:11:36 kspr: i.e. local.conf or more appropriately a custom distro config Jul 17 09:11:38 bluelightning, ok, so in conf/local.conf Jul 17 09:11:40 so I need to find corresponding package in yocto to the fastcgi lib, right ? Jul 17 09:11:47 bluelightning, alright. Jul 17 09:12:07 vincenet: right, and http://layers.openembedded.org/layerindex/branch/master/recipes/?q=fastcgi says you will find a fcgi recipe in meta-webserver Jul 17 09:12:33 Ox4: you can take the easy route and set KLIB=${DESTDIR} in OEMAKE_EXTRA or be creative and sed KLIB -> DESTDIR in the script in do_build_prepend Jul 17 09:12:49 uh, do_install_prepend Jul 17 09:13:05 bluelightning, it works - thank you very much! :) Jul 17 09:13:11 kspr: np :) Jul 17 09:13:23 bboozzoo: I just modified the script :) Jul 17 09:15:10 I usually try to avoid modifying the source code by either working around issues in task appends/prepends for tasks or adding patches in the layer Jul 17 09:15:57 bboozzoo: http://dpaste.com/2YXA8VG here is the onther one problem :-( Jul 17 09:17:58 ERROR: QA Issue: wireless-mod: Files/directories were installed but not shipped in any package: Jul 17 09:19:17 Ox4: yeah, it's trying to run depmod on your system, IIRC module class already sets DEPMOD when running oe_make, but it seems that either the Makefile or some other script in the package ignores that :) Jul 17 09:20:03 bboozzoo: http://dpaste.com/3RRKF9X Jul 17 09:20:20 I think the recipe is correct and I have to modify the sources instead Jul 17 09:20:45 that's right Jul 17 09:22:18 or I can just ignore that message Jul 17 09:23:14 bluelightning : Thank you for this point. I am familiar only with adding packages like those referenced there : http://recipes.yoctoproject.org/rrs/recipes/ What's the difference with this new source ? I used to work with IMAGE_INSTALL no more :-( Jul 17 09:24:06 vincenet: you need to fetch the additional layer (to be precise, the repository it is in), then add the path to it to BBLAYERS in your bblayers.conf Jul 17 09:24:31 vincenet: once you do that, the build system will see it and you can include it into your image through IMAGE_INSTALL in the same way as you have been up to now Jul 17 09:25:14 ok thanks ! Jul 17 09:27:03 bboozzoo: strange thing. I see only cfg80211.ko module in the image/lib/modules/2.6.37/updates/net/wireless, but there shoud be mac80211.ko. And in the image/lib/modules/2.6.37/updates should be drivers/net/wireless/ath with ath.ko and ath10k/ath10k_core.ko and ath10k_pci.ko, but there is nothing :-( Jul 17 09:29:43 vincenet: note that meta-webserver also requires meta-oe that's alongside it in the same repository, so you'd need to be adding two paths to your bblayers.conf Jul 17 09:30:22 those seems already in BASELAYERS var Jul 17 09:31:22 bluelightning : BASELAYERS ?= " \ ${TOPDIR}/sources/meta-openembedded/meta-oe \ ... ${TOPDIR}/sources/meta-openembedded/meta-webserver \ Jul 17 09:32:26 however fcgi not found as package when making the image Jul 17 09:32:53 vincenet: ah, I guess you are using something that's been preconfigured with those layers in it Jul 17 09:33:10 vincenet: not sure but I assume those layers are at a version before fcgi was added Jul 17 09:33:54 vincenet: probably you could just download the recipe and add it separately, it doesn't look like it has any extra dependencies Jul 17 09:34:34 (or alternatively upgrade, if you can) Jul 17 09:35:44 I am using daisy, here is exact error : http://dpaste.com/0Y772SB Jul 17 09:36:11 vincenet: right, and you'd get that error if there is no fcgi recipe Jul 17 09:36:43 vincenet: and it was added after daisy, which is an old release (and about to be unsupported fairly soon, FYI) Jul 17 09:39:47 Ox4: did you see these modules installed when you looked at bitbake -v ? Jul 17 09:40:10 bboozzoo: nope :-( Jul 17 09:41:07 bboozzoo: here is the full log http://paste.pound-python.org/show/NWgIci5K2f4qBf5H2YMq/ Jul 17 09:42:19 bluelightning: ok thanks. I think I can upgrade it without difficulties. How do you know it is not in daisy and from which version it is included ? Is there package search engine I can use ? I think I already use one but I cannot find again the link. Jul 17 09:45:41 bluelightning understood it is not in daisy http://layers.openembedded.org/layerindex/branch/daisy/layer/meta-webserver/ Jul 17 09:45:53 Ox4: are you sure that the modules were enabled in config? Jul 17 09:53:11 hello, I've created a recipe which has to be modified before the do_configure stage(CMAKELIST.txt) Jul 17 09:53:20 I already have a patch for that Jul 17 09:53:35 i placed it in a subfolder of the recipe Jul 17 09:53:52 but how can i tell the recipe, that it should apply it? Jul 17 09:54:10 bboozzoo: http://dpaste.com/2DWWNN8 Jul 17 09:57:15 try checking if the kernel config (/home/vadimi/leantegra_yocto/poky-4.5.1/build/tmp/work-shared/powerbeacon/kernel-build-artifacts/.config ?) contains your setttings Jul 17 10:12:11 hm Jul 17 10:12:16 | ERROR: S is not set to the linux source directory. Check Jul 17 10:12:32 but when I print S it shows me S: /home/vadimi/leantegra_yocto/poky-4.5.1/build/tmp/work-shared/powerbeacon/kernel-source Jul 17 10:13:33 and there are no any files there :-( Jul 17 10:15:27 ah, I am an idiot Jul 17 10:21:52 mordeng: just add file://yourpatchname.patch to SRC_URI in the recipe Jul 17 10:22:30 mordeng: the subdirectory name is important too, it should be either the name of the recipe, or "files" (and you _don't_ include this subdirectory name in the SRC_URI entry) Jul 17 10:24:47 kk Jul 17 10:24:49 thank you Jul 17 10:24:55 i'l try Jul 17 10:24:57 l Jul 17 10:27:08 worked :D Jul 17 10:28:50 Hi all. Yocto noob here, I'm building a poky rootfs and have my own package that provides OpenGL but mesa is being built. What's the correct way to exclude mesa from the build? Jul 17 10:31:39 eligreen: basically, find out why it's being built (i.e. what depends upon it) and stop that from requiring it Jul 17 10:32:04 probably one of the many PROVIDES in mesa, I expect you'll need to set some entries like PREFERRED_PROVIDER_virtual/libgl = "my-own-package" Jul 17 10:32:29 and also set my-own-package to PROVIDES = "virtual/libgl" Jul 17 10:32:42 etc. Jul 17 10:32:44 guys, I am stucked a bit again Jul 17 10:33:14 here is the recipe of the kernel: http://dpaste.com/06XRMGV and here is an error: http://dpaste.com/3SN1DH6 Jul 17 10:33:52 joshuagl: so I could do that in the .bb file for my image? Or would it have to be in local.conf? Jul 17 10:34:46 eligreen: mesa provides virtual/libgl, virtual/libgles1, virtual/libgles2, and virtual/egl - if you have something depending on one of those that your opengl implementation recipe does not provide, then mesa will end up being built in order to satisfy that dependency Jul 17 11:29:15 hi, I am trying to build an executable using the Yocto-generated toolchain, but some reason and other, I am getting this issue: /opt/foo/2.0/sysroots/armv5te-foo-linux-gnueabi/usr/lib/crt1.o: In function `_start': Jul 17 11:29:19 /home/lpapp/Projects/foo/Yocto-daisy-32/src/build/tmp/work/armv5te-foo-linux-gnueabi/eglibc/2.19-r0/eglibc-2.19/libc/csu/../ports/sysdeps/arm/start.S:119: undefined reference to `main' Jul 17 11:30:06 which is surprising. First of all, I do not have that /home/lpapp thing, but moreover, why would the SDK confuse such things into the build? It is also possible that it is not the SDK doing this, but I am lost for now either way. I will appreciate any feedback. Jul 17 11:33:34 ok, I am finished with this fcking modules Jul 17 11:33:42 but I don't see them in the image Jul 17 11:38:45 lpapp: are you building inside a recipe or outside of Yocto? Jul 17 11:40:22 outside of Yocto Jul 17 11:41:57 ok, I'm doing this with a large app. What I did was take the run.do_compile from some recipe and used that as the basis for my Makefile. The key thing is that you need to have the SYSROOT defined in your Makefile + the names of the CC, LD, etc. as defined in that original recipe. Jul 17 11:42:57 lpapp: there is a lot of cruft that you can remove from that run.do_compile, you don't need all of it. Jul 17 11:45:31 lpapp: http://pastebin.com/KUxuwymr Jul 17 11:47:41 lpapp: that is the current 'Makefile.inc' that I'm using. I just place 'include Makefile.inc' near the top of my Makefile(s) and it will cross-build my apps. Jul 17 11:55:54 lpapp: my mistake, that paste has definitions peculiar to my project, here is one that is stripped down to essentials: http://pastebin.com/ZZ9vy7W5 Jul 17 11:59:04 guys, how to install kernel modules in the image? Jul 17 12:00:08 T0mW: I am not building my own software Jul 17 12:00:14 T0mW: so I would like to avoid modifying that. Jul 17 12:00:35 ? Jul 17 12:01:04 lpapp: you are trying to build some other application that you want to run on your target? Jul 17 12:01:35 Ox4: why do you think that is different from installing anything else? Jul 17 12:01:46 T0mW: well, a library, but yes, sure. Jul 17 12:02:23 lpapp: you have three choices: SYSROOT the build, build inside a recipe, or compile it on the target. Jul 17 12:02:43 this is nothing to do with recipe, I am afraid Jul 17 12:02:48 this is building with the Yocto SDK Jul 17 12:02:56 it is not in the build environment, ergo not dealing with recipes. Jul 17 12:03:06 lpapp: okay, not familiar with the "SDK" Jul 17 12:03:21 * T0mW uses vim + make Jul 17 12:03:50 vim and make is not enough to cross-build software Jul 17 12:04:06 you may need lots of libraries, the proper toolchain, etc. Jul 17 12:04:16 I also do use vim and make, but this is not about those. Jul 17 12:04:46 Ox4: put this in your conf/machine: IMAGE_INSTALL_append += " kernel-modules linux-extra linux-dtb" Jul 17 12:04:55 Ox4: put this in your conf/machine: IMAGE_INSTALL_append += " kernel-modules " Jul 17 12:06:17 Ox4: btw, http://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#working-with-out-of-tree-modules Jul 17 12:06:30 or you have an in-tree module? Jul 17 12:06:45 either way, that documentation might be useful for kernel developers :-) Jul 17 12:07:14 T0mW: I've made modules via backports like standalone package Jul 17 12:07:33 lpapp: I've read this document Jul 17 12:07:55 btw, where can I read about firmware? Jul 17 12:08:08 then re-read it :) Jul 17 12:08:14 I need to install firmware bin files which there are no in yocto Jul 17 12:08:21 I think it documents with an example how to install, et al, the out-of-tree module. Jul 17 12:08:33 lpapp: ok :) Jul 17 12:08:47 we followed that section for our gpib module. Jul 17 12:08:58 (which was not incorporated in the Linux tree) Jul 17 12:10:40 lpapp: I've set MACHINE_EXTRA_RRECOMMENDS but nothing happens Jul 17 12:11:04 so I just added the modules package to IMAGE_INSTALL :) Jul 17 12:41:43 does anyone here have experience with meta-erlang? Can I reliably get erl_nif from there into my own SDK? Jul 17 13:07:27 Anyone else notice that the image manifest is totally useless for anything other than internal use by OE? I mean, it has the package name, the arch and the version, but no release (rXX) number. Jul 17 13:09:54 I need to have a base release manifest, then generate an upgrade blob containing packages that have been changed: e.g. base-files-4.0.0-r7 --> base-files-4.0.0-r8 Jul 17 13:11:48 the only way I can see how to do this is to use the manifest to see what package names it contains, then createrepo and parse the primary.xml list to see if anything changed. Jul 17 13:13:03 We have a product that goes into high-security installations where we have no access to the cloud, thus, no way to upgrade the system via smart into a repo. Jul 17 13:14:55 In fact, running 'rpm -qa' on the target system gives more info than the manifest. Jul 17 13:20:08 T0mW: that does not make it totally useless Jul 17 13:20:27 bluelightning: true Jul 17 13:20:28 T0mW: use buildhistory if you want that level of detail Jul 17 13:20:40 it has a separate list with the full package name in it Jul 17 13:20:47 and makes a commit for every build Jul 17 13:22:17 I'm seriously considering mounting the image, then run 'rpm --dpath' to check the actual installed. Jul 17 13:22:30 why, when buildhistory gives you the list already? Jul 17 13:23:03 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality Jul 17 13:24:02 heya, somehow openembedded core(core-image-minmal) hast included qt4 by default Jul 17 13:24:05 i now added IMAGE_INSTALL_append = " qt4" Jul 17 13:24:09 at the local.conf Jul 17 13:24:19 but it says there is no qt4? Jul 17 13:24:30 although there is yocto/openembedded-core/meta/recipes-qt/qt4 Jul 17 13:24:34 mordeng: you need to specify qt4-x11-free or qt4-embedded Jul 17 13:24:42 depending on which one you want Jul 17 13:24:51 ah k Jul 17 13:24:55 good question.. Jul 17 13:25:07 meta/recipes-qt/qt4 is just a directory, not a package (what you specify in IMAGE_INSTALL are package names) Jul 17 13:26:23 thank you Jul 17 13:26:25 i'll try it Jul 17 13:43:07 bluelightning: better, thanks. installed-packages.txt gives the info I need. Jul 17 13:43:17 T0mW: great Jul 17 13:43:43 bluelightning: basically, we need to build "service packs" Jul 17 13:46:44 T0mW: consisting of all the packages needed to upgrade to the next release? Jul 17 13:47:52 bluelightning: yeah, we have an O/S base release, then distribute upgrade bundles to upload into the unit, then it will self-upgrade the necessary packages Jul 17 13:48:11 I hope one day we have a good image-level upgrade story that doesn't need to involve packages, at least not on the target itself Jul 17 15:29:47 Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install. [installed-vs-shipped] Jul 17 15:29:52 what does it mean? Jul 17 15:32:13 see the yocto project documentation, search for FILES Jul 17 15:42:50 kergoth: is it correct: http://dpaste.com/1AT4NVW ? Jul 17 19:56:19 So apparently pseudo 1.6.6 had the undocumented feature that mkfifo() would, on success, close fd 0 for no good reason. Jul 17 19:56:55 I am very proud of that, because that is not the kind of bug any ordinary idiot could introduce. No, that took skill, planning, and a really poorly chosen test case. Jul 17 20:00:08 is it normal that the rootfs created by Yocto contain /boot/zImage, but I don't have any .dtb file on it Jul 17 20:00:19 or any fdt file Jul 17 20:02:20 Maybe? That kind of thing is usually BSP-specific. Jul 17 20:02:42 this would explain that, I'm creating my own bsp Jul 17 20:02:53 ok, now I need to find how to automatically include this file too Jul 17 20:09:07 http://git.yoctoproject.org/cgit.cgi/poky/tree/README.hardware#n258 Jul 17 20:09:08 mmm Jul 17 20:09:22 so core-image-minimal doesn't copy the DTB file Jul 17 20:09:32 anyone know who's copying this file into /boot/ ? Jul 17 20:09:33 :) Jul 17 20:12:02 if you want the device tree files in your image, add the linux-devicetree package to your IMAGE_INSTALL (e.g. via MACHINE_ESSENTIAL_RDEPENDS), iirc Jul 17 20:12:28 oh yeah, thank you ! Jul 17 20:13:22 its either linux-devicetree or kernel-devicetree, something like that, see also linux-dtb.inc in oe-core or poky Jul 17 20:15:18 great thank you Jul 17 20:15:21 Ill check them Jul 17 20:17:21 the name is kernel-devicetree Jul 17 20:21:36 kergoth, thank you, it worked well Jul 17 20:22:46 np Jul 17 21:15:32 bitbake -e hangs Jul 17 21:15:41 is anyne seeing same Jul 17 21:15:44 on master Jul 17 21:20:16 i've been seeing random parse hangs for a while, sometimes with -e, sometimes with buidls **** ENDING LOGGING AT Sat Jul 18 02:59:59 2015