**** BEGIN LOGGING AT Fri Sep 06 02:59:59 2013 Sep 06 06:52:13 how to remove debug package creation in bb file? Sep 06 07:14:04 good morning Sep 06 07:40:05 any idea guys? Sep 06 07:45:05 vicky: check the class how it works. Sep 06 07:57:49 lpapp: Sorry for ask this question? Hw to check the class? Sep 06 08:06:06 vicky: meta/classes Sep 06 08:25:59 adding "uboot" to IMAGE_FSTYPES did not have the effect I had hoped: packaging my rootfs.cpio (core-image-minimal/poky-tiny) image with mkimage... any pointers on how to achieve what I'm trying to do? Sep 06 08:41:39 magthe: i think you want "cpio.u-boot" as the IMAGE_FSTYPES value Sep 06 08:41:59 magthe and "cpio.gz.u-boot" if you want it gzipped Sep 06 08:43:21 vicky: i think setting INHIBIT_PACKAGE_DEBUG_SPLIT="1" in your recipe will do that for a single recipe Sep 06 08:43:25 vicky: assuming that's what you want Sep 06 08:44:53 nrossi: yes indeed, that sorted it, thanks! Sep 06 08:45:35 rburton: i think "INHIBIT_PACKAGE_DEBUG_SPLIT" only inhibits the spliting the of elf files into pkg and pkg-dbg, it wont prevent the creation of pkg-dbg if there are FILES set to be added to the dbg package Sep 06 08:46:29 nrossi: damn. i can never remember how to control the debug stuff. Sep 06 08:47:29 rburton: I think its dependent on how the inherit classes will distribute the debug files. Some recipes manually specific debug files and others rely on things like autotools.bbclass Sep 06 08:48:56 another question about IMAGE_FSTYPES: where in my build setup should I set it? Sep 06 08:49:45 in most examples it's set/modified in the machine config, but that is read before the distro config and poky-tiny sets IMAGE_FSTYPES using '=' Sep 06 08:50:39 magthe: You can override/append it whereever you wish. using "IMAGE_FSTYPES_append =" or "IMAGE_FSTYPES +=" Sep 06 08:51:11 magthe: normally its in the distro.conf or machine.conf, but you can also override it from your local.conf Sep 06 08:53:29 magthe: Also poky-tiny should probably be setting it using a lazy set "?=" Sep 06 08:53:37 nrossi: I did put it in my machine.conf first, but that was overwritten by the poky-tiny.conf (at least according to bitbake -e) Sep 06 08:53:53 nrossi: ah, yes... that would make more sense indeed Sep 06 08:54:59 nrossi: currently I'm overriding the strictness in poky-tiny.conf by using a derived distro of my own Sep 06 08:56:08 magthe: have you tried an immediate variable set? "IMAGE_FSTYPES := ..." cant remember if that will resolve poky-tiny being strict Sep 06 08:56:47 nrossi: no... I'll try it right away Sep 06 08:58:00 magthe: alternatively you can always just make it override specific. e.g. "IMAGE_FSTYPES_machinename = ..." Sep 06 09:00:54 nrossi: nope, immediate set won't override it... I'll try the specific override instead to see what happens Sep 06 09:04:00 nrossi: yes, a specific override works fine... that's nicer than introducing a dummy distro Sep 06 09:05:20 magthe: if you want to be tricking you can make the override for the distro "_poky-tiny" i think the distro name gets populated into the "OVERRIDES" variable Sep 06 09:05:35 afaik we stil lhave the _local override Sep 06 09:09:07 vicky: DEBUG_FLAGS = "" (or in local.conf DEBUG_FLAGS_pn- = "") Sep 06 09:09:39 magthe: and for cpio's and stuff (initramfs) maybe you should use that in your image: IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}" Sep 06 09:11:11 RP: hi there Sep 06 09:27:35 hi ant_work Sep 06 09:31:03 RP: I'm very dubious about the klcc-cross recipe. It works but I'm sure it is machine-specific as it is because its prefix relates to target_sysroot :/ Sep 06 09:35:00 ant_work: cross recipes are usually tune specific Sep 06 09:35:19 ant_work: does it end up in the TUNE_PKGARCH workdir? Sep 06 09:35:38 ant_work: biggest issue is the one I mentioned, the need for a relative symlink Sep 06 09:35:42 RP: the point to build against libc-headers insted of kernel was to have arch-specific Sep 06 09:35:44 ant_work: did you fix that? Sep 06 09:36:05 yes but there are hardcodes in the klcc.cross script Sep 06 09:36:42 ant_work: aren't they relocated by the sstate code? Sep 06 09:36:51 what's scary, tools are referring to ii686 and the libs to qemuarm sysroot Sep 06 09:37:07 hmm, that sound odd Sep 06 09:37:16 RP: it's surely my bad ;) Sep 06 09:37:40 ant_work: I really don't know it well enough to comment :( Sep 06 09:37:42 if youhave 2 mins I'll fwd an e-mail I sent to Khem Sep 06 09:41:01 ant_work: the fact it is installing binaries into i686 makes sense, all cross recipes do that so don't worry Sep 06 09:41:20 ant_work: Equally, paths in scripts should be found and relocate automagically by the sstate code Sep 06 09:42:17 ant_work: To test, build something with klcc on machine A, then switch to a different machine, "Bitbake klcc-cross" there and see if klcc works in its new location Sep 06 09:43:16 I guess a full test would be MACHINE=A bitbake klcc-cross; ; MACHINE=A bitbake klcc-cross -c clean; repeat for MACHINE=B Sep 06 09:46:45 ant_work: thanks for the tip... that does make more sense Sep 06 09:52:55 RP: I'm afk here but I did the test, even for machine of the same arch. klibc is not rebuilt, klcc is Sep 06 09:53:47 RP: and the klcc-cross in sstate-cache does contains the hardcodes (it's a perl script, I just inspect it) Sep 06 09:54:41 ant_work: hmm, that doesn't sound so good then Sep 06 09:56:27 RP: what I then did was to verify with readelf the produced klcc-shared binaries and these were ok Sep 06 09:57:04 RP: linking to exec_prefix/lib/klibc on target Sep 06 10:01:59 RP: I feel I'm in the 'preverted' kind of setups blamed here ;) Sep 06 10:02:01 http://www.zytor.com/pipermail/klibc/2013-August/003463.html Sep 06 10:02:02 ant_work: so its at least partially working ok Sep 06 10:02:15 RP: yep, no autobuilder failures Sep 06 10:02:36 RP: and good binaries Sep 06 10:02:50 ..but it is machine-specific as it is :/ Sep 06 10:03:17 I feel there must be a way to use a single copy of the linux-libc-headers Sep 06 10:03:56 ant_work: I told you how to do that, you need to use a relative symlink Sep 06 10:04:14 is done Sep 06 10:04:23 but is relative to target sysroot Sep 06 10:05:04 ant_work: that doesn't make sense Sep 06 10:05:08 http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-devtools/klibc/klibc-2.0.2/klibc-linux-libc-dev.patch Sep 06 10:05:35 Does anyone know about a problem with , e.g., ${DATETIME} having different values depending on whether a task is running fakerooted or not? Sep 06 10:06:18 ant_work: so that will work both at build time and on the target. What is the problem? Sep 06 10:06:31 ant_work: there is only one copy of linux-libc-headers? Sep 06 10:06:34 the problem are the vars in klcc-cross Sep 06 10:07:34 RP: one each sysroot Sep 06 10:07:38 ant_work: ok, what do those look like? Sep 06 10:08:07 ... /qemuarm/... Sep 06 10:08:15 The problem we experienced what that a task that we added (do_kimage) which uses the rootfs image ouput from the do_rootfs failed because it couldn't find the image. This was due to do_rootfs being fakerooted and do_kimage not being it. Sep 06 10:08:43 Saur: I can guess that is due to the bitbake-worker changes Sep 06 10:08:44 RP. the variable controlling those is INSTALLDIR Sep 06 10:08:59 Saur: the fakeroot env will have a different time to the non-fakeroot one :/ Sep 06 10:09:12 ant_work: so can't you make these relative too? Sep 06 10:09:18 RP: I assumed something like that. It seems a bit troublesome though that variables have different values like that... Sep 06 10:09:42 The workaround in this casewas easy by making do_kimage fakerooted as well, but it seems wrong somehow... Sep 06 10:10:46 Saur: The only answer I can think of offhand is to special case DATETIME in bitbake... Sep 06 10:11:08 Saur: a bit like http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=e63c5775732055a32b417c01fb68711f33ff4ac3 Sep 06 10:11:19 RP: ${DATE} and ${TIME} I guess is more appropriate, but yes Sep 06 10:11:31 Saur: right Sep 06 10:11:56 RP: Sounds about right Sep 06 10:12:18 Saur: I'll take a patch... Sep 06 10:12:36 RP: I'll see if I can figure it out. ;) Sep 06 10:12:41 JaMa: hi, where should uthash go inside meta-oe, which recipe group? Sep 06 10:14:56 lpapp: what depends on it? looks like something for -support or -extended Sep 06 10:15:24 RP: Hmm, seems ${DATE} and ${TIME} get their values from time.gmtime() in bitbake.conf today. How would that need to change for this to work for the new worker setup? Sep 06 10:15:51 Saur: I'd just read the value of them from the cooker configuration and pass that into the workers Sep 06 10:16:02 Saur: i.e. just do what BUILDNAME does Sep 06 10:16:21 RP: Ok, sounds simple enough. Will try that... Sep 06 10:16:55 RP: FYI: that pseudo/procps issue looks like race-condition in runstrip calls Sep 06 10:18:34 JaMa: oh, interesting. I'm not sure how that happens but it sounds possible Sep 06 10:19:23 JaMa: our software. :-) Sep 06 10:20:14 JaMa: IMO, linked list and hash with C macros are pretty useless... but people use it for some reason. Sep 06 10:23:31 RP: hopefully I'll know more after next rebuild is finished Sep 06 10:23:59 JaMa: I will push it to recipes-support, then. Sep 06 10:24:12 lpapp: ok Sep 06 10:24:52 JaMa: thanks. Sep 06 10:29:00 I m really struggling with this dbg package. Sep 06 10:29:05 Here is my story Sep 06 10:29:26 i dont need the dbg package of my custom qt application Sep 06 10:29:56 how to avoid the dbg package of the qt app in bb file? Sep 06 10:30:13 vicky: have you checked the class? Sep 06 10:30:18 and how FILES works? Sep 06 10:31:08 yes Sep 06 10:31:15 vicky: did you try DEBUG_FLAGS ? Sep 06 10:31:30 vicky: the -dbg package will still be there but should become near empty Sep 06 10:31:46 PACKAGES = "${PN}-staticdev ${PN}-dev ${PN}-dbg ${PN}-doc ${PN}" Sep 06 10:31:55 you should probably modify that variable. Sep 06 10:32:43 but what is your use case, anyway? Sep 06 10:32:51 i will post the bb file Sep 06 10:33:13 why? Sep 06 10:35:53 I already tried with PACKAGES = "${PN}-staticdev ${PN}-dev ${PN}-dbg ${PN}-doc ${PN}" Sep 06 10:36:17 but it says " rdepends on dbg" Sep 06 10:38:52 why don't you start with what you tried? Sep 06 10:38:58 what else have you tried? Sep 06 10:59:46 hi all. I have put a number of recipes in the dir recipes-test in my meta-test dir. How can I now force all these recipes to be compiled? Sep 06 11:00:37 For example, I have iperf in meta-test/recipes-test, nad I can see it compiling when I say : bitbake iperf. Sep 06 11:01:03 But I have other tools in the same recipes dir, and I want to compile them all in one go Sep 06 11:01:08 How to achieve that? Sep 06 11:01:19 vicky: Did you try DEBUG_FLAGS? Sep 06 11:01:58 drasko: you can make a meta-recipe that depends on all the other recipes Sep 06 11:02:36 so, there is no an instruction to bitbake to compile all from one dir? Sep 06 11:02:50 like bitbake recipes-test/* Sep 06 11:03:43 drasko: you can be using -b Sep 06 11:04:02 but you still need to supply recipes rather than folders, though, so you need to align your pattern. Sep 06 11:04:21 the caveat there is that -b ignores dependencies Sep 06 11:04:39 lpapp, normally I have a metarecipe Sep 06 11:05:05 drasko: bitbake metarecipe then. Sep 06 11:05:07 BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb Sep 06 11:05:14 I have thios in my layer.conf Sep 06 11:05:25 I thought abot this Sep 06 11:05:43 and normally it compiles all other recipe-* folders in this meta layer Sep 06 11:05:49 except the one I just added Sep 06 11:05:59 maybe somethig has to be forced for recompilation? Sep 06 11:06:10 Or I have to do clean of the project? Sep 06 11:06:21 if there's no need to rebuild, it won't rebuild Sep 06 11:06:38 drasko: you could write a python script for doing this with os.walk, pretty quickly. Sep 06 11:07:14 What I do not understand is how it does all other recipe-* dirs Sep 06 11:07:24 and this one that I just added stays untouched Sep 06 11:07:37 even when in layer.conf of this layer Sep 06 11:07:45 I have BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb Sep 06 11:09:10 Any ideas why this folder is avoided? I think that it is because it is last added, and noclean was done... Sep 06 11:09:38 if you've already built them, then asking them to be rebuilt won't do anything. is that what's happening? Sep 06 11:09:53 you can prove that by picking one that it's not building, do bitbake [the package] -ccleansstate, and trying again Sep 06 11:09:57 rburton, they were neve built Sep 06 11:10:31 how are you depending on them in your meta-package? Sep 06 11:10:37 they have been added to meta layer after the project has been completely built Sep 06 11:10:39 BBFILES just controls what files bitbake parses Sep 06 11:11:18 rburton, where to find this? Sep 06 11:12:43 drasko: i suspect your meta-recipe needs updating Sep 06 11:13:04 rburton, probably... How to do this? Sep 06 11:14:14 well if you have a meta-recipe that builds everything, you need to add more dependencies to it Sep 06 11:14:26 No I do not have metarecipe Sep 06 11:14:33 I have only lines in layer.conf Sep 06 11:14:42 that build every other recipe-* folders Sep 06 11:14:48 except the one I just added Sep 06 11:14:48 no it doesn't Sep 06 11:15:02 what do you ask bitbake to build? Sep 06 11:15:13 rburton, you mean - packages that are build from these folders are defined elsewhere? Sep 06 11:15:31 no, i mean when you ask bitbake to build something, it will build just what it needs Sep 06 11:15:49 unless you do bitbake world, which will build *everything* Sep 06 11:20:11 rburton, could it be that the list of packages is given in IMAGE_INSTALL and only these are compiled? Since non of packages from the dir meta-test I added to the layer is not in the IMAGE_INSTALL variable, none of them is compiled. Is this correct? Sep 06 11:20:21 drasko: yes Sep 06 11:20:40 if your asking it to build an image it will compile everyhting needed to build that image Sep 06 11:20:45 it won't build stuff that isn't required Sep 06 11:40:33 Hi Sep 06 11:41:14 What is the best way to do this? I need to sign the linux uImage and dtb files and uboot files.. Sep 06 11:42:33 bluelightning : do you have any ideas Sep 06 11:43:07 can it be done by creating a class that addsa function to the image? Sep 06 11:47:14 rburton : do you have any idea on this? Sep 06 11:47:26 Guest49245: not my area of expertise I'm afraid, but someone else here should be able to help with that Sep 06 11:48:06 bluelightning : ok np Sep 06 11:49:06 bluelightning : do you have any suggestions whom would know..? Sep 06 11:49:46 Guest42914, Do you mean signing the image so it would be accepted by a "HAB" system or something? Sep 06 11:54:24 Stygia : I don't know what HAB system is. Basically certain files e.g. uImage, *.dtb . uboot files need to be signed . So I have a exe that run over them and create new file with new extension Sep 06 11:55:39 I am wondering what is best approach to do this Sep 06 11:55:48 Guest42914: A class adding a function or appending to an existing function would seem like a good way to start Sep 06 11:56:15 there are varios POSTPROCESS type variables Sep 06 11:57:08 HAB = Highly Assured Boot. Sep 06 11:57:13 Guest42914, Signed by PGP, then? Sep 06 11:58:10 Stygia : its not pgp but something similar I guess Sep 06 11:59:15 Guest42914, Well if you have the program locally, and you know which files to sign, do something like do_install_append and then manually sign the files there? Sep 06 11:59:32 RP: Atm I have a class which adds a function . The class is then included to the uboot , linux recipes. and it takes the files in the deploydir and does the operation. dont think that is best way though Sep 06 11:59:59 Guest49245: what is the problem? Sep 06 12:00:39 RP: If I need to sign something executables that are in a recipe then it won't work. Sep 06 12:01:17 RP: I am wondering if I can do it somehow in the image recipe itself. Sep 06 12:01:34 Guest49245: well, you can globally inherit the class (INHERIT += "xxx" from conf) and then do_install_append() of whatever Sep 06 12:01:46 Guest49245: or modify PACKAGEFUNCS Sep 06 12:01:56 Guest49245: lots of options Sep 06 12:02:25 Guest49245: See the various image class hooks. You can modify the image contents Sep 06 12:06:14 RP : where does do_install install . Its the variable common to all recipes? Sep 06 12:06:43 RP: and what do you mean by image class hooks? Sep 06 12:12:09 RP: did you get that last question? Sep 06 12:21:26 Guest42914: I guess not Sep 06 12:21:42 RP : where does do_install install . Its the variable common to all recipes? Sep 06 12:21:59 RP: and what do you mean by image class hooks? Sep 06 12:24:48 guys, with a linux-yocto-custom can I use a SRC_URI on http:// ? Sep 06 12:38:19 Guest42914: yes, it is common, to ${D} Sep 06 12:38:58 Guest42914: if you look at image.bbclass and the other classes that get included there are references to things like ROOTFS_POSTPROCESS or something like that and similar Sep 06 12:39:37 alright I take a look. thanks RP Sep 06 12:41:55 RP: about my doubt inheriting cross in the recipe after one include: the evaluation is postponed isn't? Sep 06 12:42:43 ant_work: order does matter with include Sep 06 12:42:51 ant_work: but its unlikely to be an issue Sep 06 12:43:31 so after the line include I have to expect the vars are mangled for cross. only after that Sep 06 12:43:56 kergoth, thanks for you help yesterday, I applied "echo 'TOOLCHAIN_TARGET_TASK_append_pn-meta-toolchain-qte = " console-image"' >>conf/local.conf" and bit baked the image using -c populate_sdk. Unforunately, it didn't work as expected. It did not add the Qt specific exports to the generated environment-setup... file Sep 06 12:44:25 you see, the recipe is a split-off of the main one just to install the klcc as crosscompiler and not for compiling on target Sep 06 12:46:05 kergoth, no big deal, I'll merge the files together for now. I just wanted to bring it to your attention so whoever takes care of those things can be notified. Sep 06 12:48:46 RP: probably I have to verify prefix=${exec_prefix} in the recipe after inheriting cross Sep 06 12:49:26 RP: I'd say even better to redeclare it Sep 06 13:16:05 kergoth, I spoke too soon. It didn't add the meta-toolchain-qte excecutables (qmake, moc, etc.) to sysroots/x86_64-angstromsdk-linux/usr/bin either. I think I'll work with my original plan and just merge the directories together. Sep 06 13:29:54 HI all, I am comming to the probelm I mentioned : I added the recipe in my meta layer, but it is not seen by bitbake Sep 06 13:30:25 drasko: did you add your layer to conf/bblayers.conf? Sep 06 13:30:26 In my meta layer I have local.conf line like this : BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb Sep 06 13:31:04 layer is present in conf/bblayers.conf Sep 06 13:31:12 The project has been built before Sep 06 13:31:22 then I added some more recipes Sep 06 13:31:27 now they are not seen Sep 06 13:31:39 in which folder did you put it? Sep 06 13:31:52 I have an impression that clean must be donem but I would like to avoid this Sep 06 13:32:16 recipe parsing should not have anything to do with Sep 06 13:32:19 cleaning Sep 06 13:32:24 ndec, yocto/meta-test Sep 06 13:32:41 how do you know it is not parsed? Sep 06 13:32:54 the packets are not being built Sep 06 13:33:14 that's different ;-) Sep 06 13:33:21 bitbake cpuburn -v Sep 06 13:33:27 ERROR: Nothing PROVIDES 'cpuburn' Sep 06 13:33:31 ok Sep 06 13:33:43 Hi guys, I'm using dylan-9.0.1, uclibc. Have no idea, why it produces sth like that under work/: 0.9.33+gitAUTOINC+946799cd0ce0c6c803c9cb173a84f4d607bde350-r8.4 Sep 06 13:33:44 what the full path of your recipe? Sep 06 13:34:05 shouldn't this just be 'uclibc-versionABC' ? instead of git SHA? Sep 06 13:34:20 yocto/meta-test/recipes-benchmark/cpuburn/ Sep 06 13:34:37 Krz: if the recipe uses git, no Sep 06 13:35:15 do you see meta-test when you run bitbake-layers show-layers Sep 06 13:35:50 ndec, yes Sep 06 13:36:03 I do see it Sep 06 13:37:35 hmm. any chance you can share the content of the .bb file? Sep 06 13:37:37 Trying to give .bb file directly to bitbake -b gives : ERROR: Nothing PROVIDES ... Sep 06 13:37:59 ndec: doesnn't AUTOINC mean the latest and greatest commit? Sep 06 13:38:29 it is actually this folder : https://github.com/dirtybit/gumstix-yocto/tree/master/meta-openembedded/meta-oe/recipes-benchmark Sep 06 13:38:40 I took it whole and I put it in my meta-test layer Sep 06 13:38:58 so I want to build all these benchmarking tools and include them in my image Sep 06 13:39:23 drasko: you build for which host? Sep 06 13:39:34 ARM Sep 06 13:40:01 what does COMPATIBLE_HOST mean, actually? Sep 06 13:40:28 I have no idea Sep 06 13:40:38 anyway, other packages do not have this Sep 06 13:40:43 but still they do not build Sep 06 13:40:52 ndec, I don't know, as such, but it looks like it would indicate which HOST's are compatible with the recipe/ Sep 06 13:40:53 ? Sep 06 13:41:19 If the naming is name I'd say that answer was obvious. But it might not be. Sep 06 13:41:23 *is sane Sep 06 13:41:43 yeah, i was wondering that. Sep 06 13:43:04 Don't take my word for it, though, I don't actually know. :) Sep 06 13:43:04 ndec, my excuse, looks like other tools do build Sep 06 13:43:09 Just seemed like a qualified guess. Sep 06 13:43:13 Then it must be this COMPATIBLE_HOST Sep 06 13:43:24 drasko: try removing the COMPATIBLE_HOST? honestly, i don't quite undestand what it does. Sep 06 13:43:25 https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html Sep 06 13:43:34 i read that. but still i don't understand ;-) Sep 06 13:43:35 Search "COMPATIBLE_HOST" Sep 06 13:43:45 Ah, heh. Sep 06 13:43:50 Then, I'm right, how about that? :) Sep 06 13:43:56 That's how I read the explaination anyway. Sep 06 13:44:04 Seems like a whitelist of known hosts supported by the recipe. Sep 06 13:44:14 Yup. Sep 06 13:44:31 Unless I truly suck at English that's exactly what COMPATIBLE_HOST is -> A list of hosts with which the recipe is compatible Sep 06 13:45:16 the part i don't get is " one or more targets (when the recipe is non-native)" Sep 06 13:45:34 i guess the recipe is non-native in drasko case. Sep 06 13:46:29 That means AFAIK that the RE matches one or more possible architectures the recipe can be compiled on when it is not being cross-complied. Sep 06 13:46:36 *compiled Sep 06 13:46:38 Make sense? Sep 06 13:48:14 Krz: no, AUTOINC, means that you used SRCREV with a commit. Sep 06 13:48:46 looking at dylan, looks like you are using uclibc_git.bb, which has a DEFAULT_PREFERENCE='-1'. so something must be changing it. Sep 06 13:49:22 that you used SRVREV in PV, i meant. Sep 06 14:21:21 khem: do you have a good reason to install the systemd rpm macros? Sep 06 14:21:29 otherwise i'll delete them whilst i'm working on that recipe Sep 06 14:30:14 The following line shows up in a bb file and I don't understand how to interpret it PACKAGECONFIG[gles2] = "-opengl es2 -eglfs,,virtual/libgles2 virtual/egl" Sep 06 14:31:28 gjohnson: see PACKAGECONFIG under http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-P Sep 06 14:34:47 rburton: Thanks for the link, I figured that is what was happening. How do I enable the virtual/libgles2 and virtual/egl features? Should these features be enabled based on other packages I have added to my image? Sep 06 14:35:08 those are virtual packages which should be provided by your GL library Sep 06 14:35:11 mesa is the default Sep 06 14:37:04 rburton: so I am using the imx6 and the gpu library has PROVIDES += "virtual/wayland-egl virtual/libgl virtual/libgal-x11 virtual/egl virtual/libgles1 virtual/libgles2" but for some reason that PACKAGECONFIG[gles2] is not being set. Sep 06 14:37:40 you'll need to ensure that gles2 is in the main PACKAGECONFIG= statement Sep 06 14:37:41 you might need to do PACKAGECONFIG_ += "gles2", i suspect. Sep 06 14:39:18 or even PACKAGECONFIG-pn_ Sep 06 14:40:33 Ah, ok I think I understand. So if my recipe is qtbase I should set PACKAGECONFIG_qtbase += "gles2"? Also where is the best place to put that? Sep 06 14:41:07 or you could have a .bbappend file for qtbase and add PACKAGECONFIG += 'gles2' Sep 06 14:42:08 i did it with a .bbappend for qt5 , for our layers. Sep 06 14:42:39 if not in a .bbappend, i think the right syntax would be PACKAGECONFIG_pn-qtbase Sep 06 14:43:43 ndec: That sounds like a good plan for me too then. I created my own layer for my company so it should be easy to add the bbappend. Just so I understand where would the PACKAGECONFIG_pn-qtbase assignment go? Also what does the pn stand for? Sep 06 14:44:03 pn for package name Sep 06 14:44:31 i believe the best place for PACKAGECONFIG_pn-qtbase would be in a distro or machine .conf file Sep 06 14:44:56 it cannot be in a .bb file in fact, as it's used in qtbase recipe. Sep 06 14:45:21 so, either .conf with pn_qtbase, or without and in qtbase_xxx.bbappend Sep 06 14:45:49 ndec: so the _pn part indicates that the following text is the package name? Sep 06 14:45:56 yes Sep 06 14:47:02 ndec: Another question since you are also using the qt5 layer, my opengl libraries aren't being installed before qtbase is built. did you see this same issue? Sep 06 14:47:29 isn't that becase you were missing this PACKAGECONFIG? Sep 06 14:48:08 that line Sep 06 14:48:08 PACKAGECONFIG[gles2] = "-opengl es2 -eglfs,,virtual/libgles2 virtual/egl" Sep 06 14:48:19 probably, I will try getting that set and see if it solves my issue. Thank you for the help. Sep 06 14:48:21 will do 2 things: 1) add -opengl es2 -eglfs to the configure options. Sep 06 14:48:30 2) add virtual/libgles2 virtual/egl to DEPENDS Sep 06 14:48:43 ok, that will for sure fix my issue then Sep 06 14:48:52 you should check the documentation for PACKAGECONFIG, this is there. Sep 06 14:49:36 you can even do something when it's not defined (the flag). that's that the 2nd argument is for (empty in this example) Sep 06 14:49:55 but for example, here Sep 06 14:49:55 PACKAGECONFIG[tslib] = "-tslib,-no-tslib,tslib" Sep 06 14:50:01 thanks, I did but I think I read it backwards. I thought you need to have the depends then it will add the configure option Sep 06 14:50:10 you see that it would set -no-tslib to configure when NOT set. Sep 06 14:50:54 yeah, that makes sense to me now. Thanks again for the explanation. Sep 06 16:41:14 after doing bitbake -c populate_sdk I have .sh script - toolchain Sep 06 16:41:26 how can I obtain the tarball which is inside? Sep 06 16:41:41 I think there is some recipe creating this .sh script from tarball (I need this tarball) Sep 06 16:43:31 krz, why don't you want to use the script, since the script handles installing it correctly and deals with some path relocation? Sep 06 16:44:28 sgw_: are you telling me, that tarball will not be usefull at all without relocation? Sep 06 16:44:45 Krz: yes Sep 06 16:46:46 Krz: I don't remember everything the script does, it's possible that tarball *might* work if installed in the /opt/poky dir (assuming your doing a poky distro build), but I won't guarantee it. Sep 06 16:47:30 sgw_: why do we need path relocations? what for exactly? Sep 06 16:48:17 sgw_: basically my background is - we have a zip with IDE inside and xCompiler toolchain will be part of that. So far there is no installation process involved. That's why I need just a tarball Sep 06 16:49:08 wow, i really thought that was going to need some kind of hairy-ass autotools patch... Sep 06 16:49:44 * mr_science thanks the GNU devs for providing useful configure options Sep 06 16:52:00 Krz: there are a number of things the script does to setup the environment correctly and tweak binaries to have the right dynamic library patch, you can see the python script in scripts/relocate_sdk.py Sep 06 16:52:23 Krz: this allows it to be installed as non-root user Sep 06 16:53:27 sgw_: but at the end of the day xCompiler is just bunch of binaries. I should be able to just untar them and using proper flags (e.g. gcc sysroot=/abc/def). That's my understanding of xCompiler Sep 06 16:53:37 sgw_: will take a look at relocate_sdk.py Sep 06 16:55:36 heh, we should really start a project to improve path relocatability of software in general so we can stop having to do such hacks Sep 06 17:02:40 * mr_science wonders where's the meta-ribs layer to go with meta-chicken... Sep 06 17:05:28 mr_science: :) Sep 06 17:07:00 finally found the layer index Sep 06 17:07:42 Krz: see the trick I played in meta-mingw Sep 06 17:08:35 Krz: SDK_PACKAGING_FUNC = "do_compile" from http://git.yoctoproject.org/cgit.cgi/meta-mingw/tree/conf/machine-sdk/x86_64-mingw32.conf Sep 06 17:08:51 Reading that back, I really should have better documented why/how that works :/ Sep 06 17:09:59 Krz: if you just want binaries you can untar, you might need to stop using our own dynamic linker and libc Sep 06 17:10:38 kergoth: i'm looking at your external-sourcery-toolchain.bb recipe Sep 06 17:11:08 RP: poky already creates tarball in the meantime and later removes that, am I right? Sep 06 17:11:15 Krz: instead you'd need to build them against the lowest common denominator you want them to run on, a bit like the osx sysroot Sep 06 17:11:30 if i set CSL_VER_MAIN to the old version we're using for classic builds, i should be able to build a hardfloat version? Sep 06 17:11:31 Krz: right, and that variable stops the tarball being turned into the script Sep 06 17:11:54 RP: will try that for Linux Sep 06 17:12:14 Krz: well, see above, I can tell you right now you will have the problem I mention Sep 06 17:12:37 RP: what do you mean by 'the lowest common denominator' ? Sep 06 17:13:03 Krz: sysroot needs to have the oldest libc and dynamic loader you want to support Sep 06 17:13:32 a binary linked against libc X may not work with libc X-1 Sep 06 17:14:00 RP: right, I get your point now Sep 06 17:15:32 Krz: this is why we ship our own loader and libc, then we truly can run on near enough anything Sep 06 17:15:44 Krz: the cost is having to run the script at unpack time Sep 06 17:16:14 there is no way to do the dynamic loader path dynamically Sep 06 17:16:30 RP: where do I find/change libc version for sysroot? Sep 06 17:16:53 Krz: you'd have to provide a sysroot of the thing you want to compile against Sep 06 17:17:16 Krz: there isn't a simple way to do this, you're trying to do something the system isn't setup to do atm Sep 06 17:21:41 mr_science: it extracts the versions from the toolchain, it doesn't build one, or use that as input for anything Sep 06 17:39:55 Is there any reason my binaries generated by meta-toolchain-qte have '/usr/local/oecore-x86_64' harcoded in them? http://pastebin.com/jYxFuT3m I'm wondering if that's not part of my Qt in Netbeans problem. I didn't install the toolkit to the default location: Sep 06 17:40:30 ...which is /usr/local/oecore-x86_64 Sep 06 17:40:56 I have mine installed in ~/opt/angstrom-qte. Sep 06 17:45:31 use the defaults Luke :) Sep 06 17:45:32 bbl Sep 06 17:55:00 Crofton|work, sure, I'll go with that. Sep 06 17:55:40 worth a try Sep 06 17:55:54 I thought the toolchains were supposed to be relocatable Sep 06 18:14:10 Crofton|work, Nope.. Still not finding the -I (includes) that should have come from the QMAKESPEC file. I think the environment variables in the files aren't being parsed properly by Netbeans. Oh, well, back to the drawing board. Sep 06 18:15:29 Crofton|work. The reason I know this is because if I create a Makefile using qmake from the shell, make is very happy. Sep 06 18:16:26 Crofton|work, so ians, same problem as before when I installed into my own folders... Sep 06 18:19:07 ok Sep 06 18:19:27 looking at my build log in Netbeans, the culprit is ' "/usr/bin/gmake" -f nbproject/Makefile-Debug.mk QMAKE=/usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/qmake SUBPROJECTS= .clean-conf ' which generates the Makefile for the Netbeans project. Sep 06 18:21:34 actually that's reading the files... been a long day. the automagically get created by netbeans. Sep 06 19:59:21 A followup on yesterday's experiments: BBFILES and BBPATH both work only with fairly simple variable expansions. Sep 06 20:00:10 So if you do something like FOO_mips = "1.2" FOO_i586 = "1.3", you can't use ${FOO} in BBFILES/BBPATH, and it also won't work using hyphens and ${FOO-${TARGET_ARCH}}. Sep 06 20:00:41 So I have to either modify recipes to make the right ones show up, or change bblayers.conf to pick up only the version of a particular layer I want, so that'll have to be a configuration-time thing. Sep 06 20:13:23 kergoth: I figured out the problem with _remove btw Sep 06 20:13:30 kergoth: processing unexpanded data :/ Sep 06 20:13:55 heh, oops Sep 06 20:16:01 kergoth: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip76&id=50b4ecbdface9a76ffe260a383009093c702d3b1 Sep 06 20:16:15 gah, ignore the other bits Sep 06 20:17:27 http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip76&id=28b56920f3f1ac84bf01747522c71515532d8233 is better :) Sep 06 21:12:57 somebody needed an extra espresso this afternoon... Sep 06 21:17:10 mr_science: its beer time Sep 06 21:20:05 khem: not on the west coast Sep 06 21:20:09 yet... Sep 06 21:20:45 I am on west coast Sep 06 21:20:53 and its about the time :) TGIF Sep 06 21:20:57 depends on the company :) Sep 06 21:21:01 tearly shift? Sep 06 21:21:09 *early even Sep 06 21:21:33 it starts at 3 so got some time to empty tanks :) Sep 06 21:22:01 khem: what organization? Sep 06 21:22:27 Juniper Networks ? looking for a change ? let me know :) Sep 06 21:42:56 now you're making me want a guinness... Sep 06 21:56:00 uh-huh, now we're cookin' with gas... Sep 06 21:56:35 got a buildable sdk target with gnutls3 Sep 06 22:44:42 * mr_science goes to get a face trim... Sep 07 00:39:08 anyone here get yocto running well on a wandboard? Sep 07 00:39:28 with opengl working perhaps **** ENDING LOGGING AT Sat Sep 07 02:59:59 2013