**** BEGIN LOGGING AT Mon Dec 22 02:59:58 2014 Dec 22 08:54:25 hi all Dec 22 08:56:42 i am facing an dependency issue while doing 'populate_sdk' Dec 22 08:57:13 GaneshP: what dependency issue? Dec 22 08:57:24 care to elaborate? Dec 22 09:00:29 while doing a populate_sdk it's not able to resolve dependencies related to nativesdk-perl , but the error doesn't come when building an image. Dec 22 09:01:09 Cannot satisfy the following dependencies for nativesdk-packagegroup-sdk-host: * nativesdk-perl-module-file-copy Dec 22 09:01:10 ... Dec 22 09:01:13 * opkg_install_cmd: Cannot install package nativesdk-packagegroup-sdk-host. Dec 22 09:01:29 so u got this when installing the package? Dec 22 09:01:53 but not when u manually bitbake it? Dec 22 09:26:14 anyone here has compiled a compiled? (i.e gcc or llvm) Dec 22 09:26:23 * a compiler Dec 22 09:42:41 morning all Dec 22 10:34:08 <_qwerty_> Hi All, I have to put some rules to udev configuration so I added an append udev-extra-rules_1.0.bbappend file Dec 22 10:34:30 <_qwerty_> Is the correct way? and I can apply to my custom image? Dec 22 11:03:15 Hi all, I tryed to create a recipe to compile "SDL2 ttf" but it crash with a libtool error (libtool: Version mismatch error. This is libtool 2.4.2, but the ...). So, I tried to add these lines in my recipe "add do_configure_prepend(){ autoreconf -Wcross --verbose --install --force }" without succes because new errors messages appears (ex: configure.in:126: error: possibly undefined macro: AM_PATH_SDL2). Dec 22 11:04:35 Has anyone encountered this problem ? Dec 22 11:05:11 Thanks in advance. Dec 22 11:06:13 dcyrille18: looks like an automake macro that should be delivered as part of SDL2 -dev package Dec 22 11:15:06 any ideas why PKGV might not be used when building a RPM? I use gitpkgver from meta-oe, and fill PKGV using GITPKGVTAG, although bitbake -e shows that PKGV is set correctly, the versin of RPM is as if PKGV would be ignored Dec 22 11:18:57 dcyrille18: can you please use pastebin to show me your recipe? Dec 22 11:19:27 _qwerty_: yes that is reasonable, and just add udev-extra-rules to IMAGE_INSTALL within your image recipe Dec 22 11:22:10 anyone knows how yocto configures cross compiled gcc to work in yocto? Dec 22 11:22:27 I checked gcc recipes but couldnt decipher anything Dec 22 11:23:21 duh, figured out, killed prserver, proper RPM version popped up Dec 22 11:24:49 chankit1: unfortunately the toolchain setup is fairly complicated Dec 22 11:25:02 chankit1: I don't know for sure, but this may be helpful to you - http://www.openembedded.org/wiki/Adding_a_secondary_toolchain Dec 22 11:31:21 <_qwerty_> bluelightning: it is not working... bitbake gets to me an error like install: cannot stat automount.rules : No such file or directory Dec 22 11:32:01 _qwerty_: try ${WORKDIR}/automount.rules instead of just automount.rules in the install command line Dec 22 11:32:26 bluelightning: thanks..so I guess I have to get the secondary toolchain configured properly in order to get LLVM to work then? Dec 22 11:34:33 <_qwerty_> bluelightning: automount.rules is not my rule this is my udev-extraconf_1.0.bbappend file http://pastebin.com/fpJxMQpP Dec 22 11:35:26 _qwerty_: right, you are overriding SRC_URI but just prepending do_install, thus you are preventing that file from being fetched but not it being installed Dec 22 11:35:39 _qwerty_: I would suggestg using SRC_URI += instead of = Dec 22 11:36:19 <_qwerty_> bluelightning: damn!!! I see!! Dec 22 11:36:38 chankit1: that is one way to do it, probably the preferable way given that you can't build the entire system using clang Dec 22 11:37:26 chankit1: btw though there have already been others who have attempted this; have you looked at previous work in this area? Dec 22 11:37:52 bluelightning: I dont intend to build yocto using clang..I just need clang to be working in yocto Dec 22 11:38:21 I got clang to work but my yocto image couldnt run the binary that is compiled by itslef Dec 22 11:40:46 chankit1: right, understood... but have you looked at e.g. https://github.com/mtahmed/meta-tc-llvm ? Dec 22 11:44:03 <_qwerty_> bluelightning: ERROR: udev-extra-rules not found in the base feeds Dec 22 11:44:16 <_qwerty_> bluelightning: now I get this error Dec 22 11:44:58 _qwerty_: then the package is ending up empty, which points to an error in do_install or packaging in the recipe Dec 22 11:46:04 _qwerty_: look in packages-split in the workdir for the recipe - what non-empty package directories are in there ? Dec 22 11:47:20 <_qwerty_> bluelightning: build-daisy/tmp/work/beaglebone-poky-linux-gnueabi/udev-extraconf/1.0-r16/udev-extraconf-1.0 is empty Dec 22 11:47:21 bluelightning: I think I have and I'm not sure if that fits my purpose..I found this instead https://lists.yoctoproject.org/pipermail/yocto/2014-June/020358.html which might be better..but the link that you gave me is very helpful as well. Dec 22 11:47:40 bluelightning: looks like it's trying build yocto using clang which is impressive Dec 22 11:54:03 <_qwerty_> bluelightning: maybe I don't understand your soggestion, but all folder are not empty Dec 22 11:56:07 _qwerty_: that's ${S}, for a recipe like this one that would be expected to be empty Dec 22 11:56:13 _qwerty_: it's packages-split I'm talking about Dec 22 12:03:45 <_qwerty_> bluelightning: I looked for packages-split folder in all package folder but I didn't found any Dec 22 12:04:22 _qwerty_: build-daisy/tmp/work/beaglebone-poky-linux-gnueabi/udev-extraconf/1.0-r16/packages-split should exist Dec 22 12:06:06 <_qwerty_> bluelightning: deploy-rpms pkgdata sstate-install-package_write_rpm sstate-install-populate_sysroot temp Dec 22 12:06:07 <_qwerty_> license-destdir sstate-install-packagedata sstate-install-populate_lic sysroot-destdir udev-extraconf-1.0 Dec 22 12:07:34 _qwerty_: hang on a sec, I thought you said your bbappend was for a recipe called udev-extra-rules - ? Dec 22 12:10:40 <_qwerty_> no Dec 22 12:11:04 <_qwerty_> udev-extraconf Dec 22 12:22:22 help needed for my initramfs problem!! Dec 22 12:22:44 any takers?? Dec 22 12:29:03 any experts for circular dependency loops :( Dec 22 12:35:23 Hi bluelightning, I've tried to modify my recipe (visible on pastebin here : http://pastebin.com/HEPwd9wx) by drawing on sdl2 recipe. The error is now : "fatal error: freetype/config/ftheader.h: No such file or directory" Dec 22 13:34:32 Re bluelightning, so I put my recipe code on pastebin as you ask me this morning Dec 22 13:34:39 The adress is http://pastebin.com/XDFGFrAK Dec 22 13:35:39 So, my problem is an error at compilation (fatal error: freetype/config/ftheader.h: No such file or directory). Dec 22 13:37:50 And I can not seem to resolve this error despite the inclusion of "freetype" dependency in my recipe. Dec 22 13:38:19 Someone has already encountered this problem? Dec 22 13:42:26 yes, newer freetype moved the include files IIRC Dec 22 13:43:28 dcyrille18: and isn't your recipe still trying to use freetype-config and then fallback to some default? It has to use pkg-config now Dec 22 13:46:38 I use the line "inherit autotools pkgconfig gettext" but make can not found file "freetype/config/ftheader.h" Dec 22 13:47:17 you need to look in configure script what it is doing Dec 22 13:49:22 dcyrille18: what JaMa says, and you'll almost certainly need to patch it to do the right thing Dec 22 13:50:29 Ok, I understand. Thanks :) Dec 22 13:55:54 I just discovered that the SDL TTF was already implemented in yocto (libsdl-ttf) ... Two hours lost ^^. Dec 22 13:57:54 dcyrille18: oops, sorry... both myself and JaMa missed that... Dec 22 13:58:23 dcyrille18: if you didn't already know, you can find existing recipes at http://layers.openembedded.org/layerindex/branch/master/recipes/ Dec 22 13:58:55 Lol, it's not your fault but mine. I should have a better look. Dec 22 13:59:49 Okay, I looked into http://packages.yoctoproject.org/. Dec 22 14:00:15 Thanks for the info ^^ Dec 22 14:04:08 heh, right I should read the pastebin before reply :) Dec 22 14:04:09 Author: Martin Jansa Dec 22 14:04:09 Date: Mon Jul 7 12:41:49 2014 +0200 Dec 22 14:04:09 libsdl-ttf: fix build without freetype-config Dec 22 14:07:30 hi bluelightning Dec 22 14:08:59 dcyrille18: right, packages.yoctoproject.org isn't particularly helpful; it's being reworked at the moment, but even when it's done, the OE layer index at layers.openembedded.org is the best reference since it includes layers from the wider community as well Dec 22 14:09:25 darkhorse__: hello Dec 22 14:10:32 darkhorse__: have you looked at http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-INITRAMFS_IMAGE ? Dec 22 14:11:07 bluelightning: yes I am using that variable Dec 22 14:12:20 bluelightning: basically that is how my kernel launches the INITRAMFS_TASK but then the image has some packages which need kernel sources Dec 22 14:13:01 darkhorse__: I could be wrong, but I don't think that's possible at the moment Dec 22 14:19:27 bluelightning: i came to the same conclusion. so I made my kernel's do_unpack a dependency of all packages that needed kernel sources and instead of using KERNEL_STAGING_DIR (which is not available until kernel is fully built) i use the kernel build directory ${D} Dec 22 14:20:19 darkhorse__: ${D} is not the build directory, it's the install directory; it'll only be populated after do_install Dec 22 14:20:38 bluelightning: sorry i meant ${S} Dec 22 14:21:13 darkhorse__: it's not good practice to refer to anything under ${WORKDIR} from another recipe, there's no guarantee it will always be present Dec 22 14:21:49 darkhorse__: can these other recipes look in ${STAGING_KERNEL_DIR} to find what they need? Dec 22 14:22:04 (which would need to be after do_populate_sysroot of the kernel) Dec 22 14:23:01 bluelightning: no because STAGING_KERNEL_DIR is populated by kernel's do_populate_sysroot which run much later Dec 22 14:23:55 well, what you are doing may work, but it may also break horribly Dec 22 14:24:55 FWIW a set of patches were sent just recently to break out the kernel source preparation to a separate step, but it is tied up with a number of other changes and may not be applicable on its own Dec 22 14:25:25 bluelightning: agreed. but this is a fairly common use case and people must have hit upon this before? Dec 22 14:25:53 darkhorse__: I would have thought so, unfortunately it's not an area I know much about I'm afraid Dec 22 14:26:29 the two people that I am aware of that might aren't here (probably on holiday) Dec 22 14:28:22 bluelighning: so the current situation is: kernel:do_configure( ) depends on INITRAMFS_IMAGE:do_rootfs( ) which in turn depend other packages, some of those packages depend on kernel:do_patch( ). Dec 22 14:29:14 bluelightning: it is horrible but i thought it should work. unfortunately, i get circular dependency loops and that is what i am struggling with right now Dec 22 14:32:33 bluelightning: also, can you please tell me the nicknames of the people who might be able to help? Dec 22 14:33:20 darkhorse__: zeddii (Bruce Ashfield) and ant_ (Andrea Adami) Dec 22 14:35:36 bluelightning: cool - thanks. BTW, i am investigating if we can completely replace our 'gnu make' based build system with yocto. do you think it is a good idea? Dec 22 14:36:12 darkhorse__: if you mean for building OS images & packages, you'll have a lot more flexibility using our system Dec 22 14:36:41 darkhorse__: but we do still rely on make, autotools, cmake et al to build individual bits of software, as you might appreciate Dec 22 14:38:07 bluelightning: sure i meant the packaging and image generation bit. but does it work well across a team of developers? Dec 22 14:47:50 darkhorse__: I wouldn't expect that aspect to be any different, unless you are relying on some specific functionality that you've implemented in your custom solution that you would have to rewrite ? Dec 22 16:35:00 bluelightning: hi again, can bitbake be recursively callled from a bitbake receipe? Dec 22 16:35:24 bluelightning: in my bsp layer, i have two machines defined. rootfs for one machine include the kernel for the other machine. so my rootfs has a dependency on the other machine's kernel. i would like to call bitbake from my image recipe passing it the other machine type and build its kernel Dec 22 16:36:02 anyone? for my last query? Dec 22 17:15:18 its unlikely that that will ever work Dec 22 17:25:17 everyone: can bitbake be recursively callled from a bitbake recipe? Dec 22 17:28:44 i just told you, its unlikely that will ever work Dec 22 17:30:24 kergoth: wouldn't the lockfile kinda not let you Dec 22 17:33:36 kergoth: oops! sorry missed your earlier message...that seems like a big limitation coming from gnu make's world Dec 22 17:34:27 yocto isn't intended to be a general purpose replacement to make. it operates at a level above the typical use of make, and it isnt' intended to recurse Dec 22 17:36:10 kergoth: fair enough. so how would you go about this situation: my rootfs image embeds a tiny kernel image for another machine defined in my bsp layer. so i would like to generate that kernel as part of my rootfs build. Dec 22 17:37:06 do the plumbing outside bitbake Dec 22 17:37:32 that's what we do, simple build.sh script which knows that before MACHINE X you want to always build kernel for MACHINE Y Dec 22 17:38:48 and MACHINE X will have recipe which just copies kernel from Y's DEPLOY_DIR Dec 22 17:39:21 JaMa: cheers! that's what i have done. but wasn't sure if this was the best option available Dec 22 17:41:26 JaMa: any exposure to circular dependencies when trying to build a ramdisk? Dec 22 20:15:18 RP: we should consider deprecating __anonymous at some point. just unnecessary ancient remnant :) Dec 22 20:17:24 kergoth: no argument from me Dec 22 20:17:45 * RP just found a bug in d.keys(), it lists deleted keys :/ Dec 22 20:17:55 ouch Dec 22 20:18:24 or in other words anything touched by d.expandKeys :/ Dec 22 20:25:04 hey kergoth congratulations! Dec 22 20:29:31 hey, thanks **** ENDING LOGGING AT Tue Dec 23 02:59:59 2014