**** BEGIN LOGGING AT Wed Oct 16 02:59:58 2013 Oct 16 09:03:02 morning all Oct 16 10:00:10 hi to all! running "su - user -c 'env'" I get "PATH=/bin:/usr/bin". When running "su - user" and then "env" (as user) I get "PATH=/usr/local/bin:/usr/bin:/bin:/opt/java/bin" (which is the one setted in /etc/profile)... Oct 16 10:00:15 Reading about login-shell I cannot figure the reason of this difference..it may be a bug? Oct 16 10:00:20 thanks! Oct 16 11:21:27 hi guys, looking for unistd.h header for my uclibc distro. Any idea what I have to add to my image to have that header? I have DISTRO_FEATURES_LIBC = "libc-posix-clang-wchar libc-posix-wchar-io" and I have libiconv installed Oct 16 11:29:15 Krz-: are you sure you don't already have it? I have a meta-clanton build here and its installed... Oct 16 11:29:46 Krz-: when you say "image", do you mean on target or in the sysroot? Oct 16 11:43:13 RP: found a bug wrt JFFS2 Oct 16 11:46:17 hi guys Oct 16 11:46:24 quick question Oct 16 11:46:34 I've build yocto image fox imx6 Oct 16 11:46:51 I'm running some tests and setlocale function fails Oct 16 11:47:10 not sure how yocto support locale (or it's part of busybox or glibc??) Oct 16 11:53:41 mbelisko: is the locale installed? Oct 16 11:53:49 ant_work: congrats ;-) Oct 16 11:54:05 :p Oct 16 11:54:10 yes, was my bad Oct 16 12:00:02 RP: not Oct 16 12:00:12 RP: *no Oct 16 12:01:44 RP: MACHINE_FEATURE += "norflash" or "nandflash" ?ù Oct 16 12:06:55 ant_work: I don't follow Oct 16 12:07:21 mbelisko: installing a locale would probably be a good first step then Oct 16 12:07:30 RP: I've sent the obserbvations on the ML Oct 16 12:07:53 on oe-core where it belongs Oct 16 12:07:58 mbelisko: see the IMAGE_LIGUAS variable Oct 16 12:08:03 ant_work: ok Oct 16 12:11:42 RP: ok thanks Oct 16 12:16:27 RP: I mean target, I try to compile on target Oct 16 12:16:52 Krz-: is that not in the libc-dev package? Oct 16 12:17:33 RP: would be, I think that's the answer Oct 16 12:17:35 Krz-: uclibc-dev package Oct 16 12:25:30 do sstate-cache mirroring work best when the machines use the same OS-version? I have a build machine that builds nightly and then export sstate-cache over nfs to my workstation, but it seems like it rebuilds most stuff anyway. Oct 16 12:26:39 I can understand that the -native packages are rebuilt, but kernel etc I would expect to be used from sstate-cache Oct 16 12:28:52 erbo: is your configuration identical? annoyingly stuff like inherit+="buildhistory" causes the stamps to change. Oct 16 12:29:39 you figure this out by doing "bitbake -S foo" on both machines, and comparing the stamp files that are generated with bitbake-diffsigs Oct 16 12:31:21 rburton: I think they should be identical, but I'll take an extra look.. thanks for the tip on bitbake -S Oct 16 13:02:08 rburton: it is indeed annoying if buildhistory gets into the stamps... is that really on purpose? shouldn't that be filtered? Oct 16 13:04:16 ndec: afaik its not on purpose. no idea if it can be ignored - need paul for that Oct 16 13:11:27 the trouble is it basically modifies do_package (by inserting itself into PACKAGEFUNCS) Oct 16 13:11:41 there's no way to whitelist modification of that variable Oct 16 13:11:50 we could move to a postfunc Oct 16 13:12:20 I'm also wondering if we should try to base buildhistory's package info on pkgdata, which would handily also make it work in conjunction with sstate Oct 16 13:16:18 bluelightning: well, in my personal case it is always enabled, so that's fine. but i can clearly understand why it is a problem for buildhistory to mess up with sstate.. so anything to improve that would be nice. Oct 16 13:20:51 I'm entering a bug now Oct 16 13:21:45 bluelightning: I somewhere lost your advice what to add to image to have full gcc working, I tried adding just gcc, but it doesn't add everything (e.g. as, nm, ld are missing) Oct 16 13:23:22 https://bugzilla.yoctoproject.org/show_bug.cgi?id=5358 Oct 16 13:23:23 Bug 5358: enhancement, Undecided, ---, paul.eggleton, NEW , Avoid buildhistory changing do_package checksums Oct 16 13:23:55 Krz-: some of those are from binutils Oct 16 13:24:21 in fact I think they all are Oct 16 13:24:47 Krz-: you'll also need gcc-symlinks and binutils-symlinks I think Oct 16 14:12:55 has anyone done any docs on using adt to check a project out of a git repo and build it using cmake? Oct 16 14:31:09 Matthew Weigel on the line Oct 16 14:35:38 https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.5_Status"https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.5_Status#Milestone_5.2C_1.5_release Oct 16 14:36:04 https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.5_Status#Milestone_5.2C_1.5_release Oct 16 14:48:31 I am trying to package up libraries in a separate package but I keep getting a qa warning that it "found library in wrong location", how do I get ride of this error? Oct 16 14:51:34 gjohnson: where is it picking up the libraries it's complaining about? Oct 16 14:52:53 bluelightning: /usr/qml/QtQuick/Layouts/libqquicklayoutsplugin.so Oct 16 14:53:18 gjohnson: hmm ok Oct 16 14:53:36 4072/4662 Oct 16 14:53:57 gjohnson: you can do INSANE_SKIP_ = "libdir" Oct 16 14:55:32 bluelightning: Ok, I will try that. Does INSANCE_SKIP tell the qa class to ignore libdir errors for the specific package? Oct 16 14:55:49 gjohnson: INSANE_SKIP Oct 16 14:55:51 gjohnson: yes Oct 16 15:00:48 bluelightning: It looks like the qt4 does use INSANE_SKIP for some of its example packages but it looks like it has libraries located other than libdir and they don't use to use INSANE_SKIP. Do you know why that would be? Oct 16 15:06:47 https://wiki.yoctoproject.org/wiki/WW41_-_2013-10-08_-_Full_Pass_Release_1.5_M5.rc8 Oct 16 15:18:58 gjohnson: I'm not completely sure, no Oct 16 15:19:07 I feel like I should know since I maintain that recipe... Oct 16 15:28:23 bluelightning: I am sure you don't look at it very often so it is easy to forget :) Oct 16 15:57:39 so I have gcc with all additional stuff on my image Oct 16 15:57:56 bare gcc works fine, but when I use configure scripts - they complain about missing pkg-config Oct 16 15:58:44 there is pkgconfig in poky/, but just adding it to IMAGE_INSTALL makes build failing, 'do_rootfs' says 'unknown package pkgconfig' Oct 16 16:03:44 Krz-: the package is definitely called "pkgconfig" so that should work... Oct 16 16:04:51 pkgconfig recipe says: DEPENDS = "glib-2.0 popt" Oct 16 16:04:54 and I'm using uclibc Oct 16 16:04:56 :( Oct 16 16:06:08 Krz-: glib != glibc Oct 16 16:06:19 just figured it out ... Oct 16 16:12:52 maybe just opkg doesn't like it. grep for pkgconfig and ipk doesnt find anything but nativesdk-pkgconfig Oct 16 16:13:28 that doesn't make sense. any package listed in IMAGE_INSTALL gets added to RDEPENDS, so bitbake knows to build it, and if bitbake builds it, an ipk gets emitted. what does 'bitbake pkgconfig' do? Oct 16 16:13:54 and where are you setting IMAGE_INSTALL? in the iamge, i hope? :) Oct 16 16:20:12 bitbake pkgconfig does: Oct 16 16:20:15 NOTE: Tasks Summary: Attempted 0 tasks of which 0 didn't need to be rerun and all succeeded. Oct 16 16:20:27 and yes I'm setting IMAGE_INSTALL inside my image recipe Oct 16 16:21:03 if I do 'bitbake pkgconfig -c cleanall' and then bitbake once again from scratch - the same thing Oct 16 16:21:04 0 tasks Oct 16 16:21:15 nothing gets actually built Oct 16 16:39:20 Krz-: er... you haven't by any chance modified the default value of ASSUME_PROVIDED have you? Oct 16 16:41:02 brb Oct 16 16:51:44 bluelightning: inside pkgconfig recipe? no, I didn't touch any of poky stuff Oct 16 16:51:56 Krz-: no, I mean in your configuration Oct 16 16:52:23 ASSUME_PROVIDED="bzip2-native chrpath-native git-native grep-native diffstat-native patch-native perl-native-runtime python-native-runtime tar-native virtual/libintl-native pkgconfig$" Oct 16 16:52:31 looks like I did, hmm Oct 16 16:55:10 meta-yocto/conf/distro/poky-tiny.conf:ASSUME_PROVIDED += "pkgconfig$" Oct 16 16:55:18 that's it :| Oct 16 16:55:55 I inherit poky-tiny Oct 16 17:03:35 Krz-: hmm, that is indeed in the default file Oct 16 17:03:37 I wonder why? Oct 16 17:04:35 Krz-: ok, see the comments above that line Oct 16 17:11:36 bluelightning: yeah... what I just did - copied pkg-config tarball from tmp/downloads and installed it on my uclibc target Oct 16 17:26:56 damn, i see your nick and it reminds me i haven't sent my updated recipe yet... Oct 16 17:34:49 howdy galak Oct 16 17:36:43 can anyone help with an issue loading module c_can_platform using MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-c_can_platform"? Oct 16 17:37:06 mr_science: no problem :) Oct 16 17:37:09 bbl Oct 16 18:00:40 can anyone help with an issue loading module c_can_platform using MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-c_can_platform"? Oct 16 18:20:26 * kergoth sighs, keep hitting sstate reuse issues Oct 16 18:27:47 kergoth I had kmscherer join, he's having similar issues Oct 16 18:28:21 I am working with only sstate files for native packages. Oct 16 18:28:57 kergoth: Did you have any answer for my question of yesterday? Oct 16 18:28:57 I'm hitting a wide variety of problems. Just a moment ago I saw the external toolchain setscene run, with no errors, and yet it ended up re-running tasks anyway Oct 16 18:29:25 The debug log shows that the sstate file is found, but the native package gets rebuilt anyways. Oct 16 18:29:53 The sigs for the rebuilt file is identical to the one in the cache Oct 16 18:30:23 brm: not offhand, no. your best bet is likely to just examine tmp/deploy/ipk/ to see what kernel-module- packages exist, or to use find on the packages-split subdir of the kernel's WORKDIR, to see what went where. bitbake -e virtual/kernel | grep WORKDIR= Oct 16 18:30:31 kmscherer: that sounds familiar, indeed :| Oct 16 18:30:56 Any ideas about how to debug? Oct 16 18:31:03 would instrumenting the function(s) of sstate cache make sense? Oct 16 18:31:21 other than sprinkling bb.warn()s around bitbake or sstate.bbclass, not sure Oct 16 18:31:25 perhaps Oct 16 18:33:02 thats what I'm wondering bb.warns and such Oct 16 18:33:21 I was able to narrow it down to one package that triggers the rebuild. In this case base-passwd. Oct 16 18:33:59 If I added INHIBIT_AUTOTOOLS_DEP=1 then the packages were properly retrieved from cache Oct 16 18:34:21 i'm still trying to narrow our latest issues down, here Oct 16 18:35:52 I know one thing, I really need to nail down this bitbake bug where it doesn't always regenerate the mirror tarballs when the scm repo is updated Oct 16 18:57:41 How can I regenerate the sysroots? Oct 16 19:06:34 Crazy thought strikes. Oct 16 19:07:44 Imagine, if you will, a subtle change, which is a way that you can define a "multilib" which is actually your default tune. Oct 16 19:08:00 So for instance, for a 32-bit x86, you could refer to "lib32-busybox" and get, well, plain old busybox. Oct 16 19:08:45 This would make some aspects of my life a lot easier, because sometimes I want to express "I need a 32-bit version of package X", and that means I have to determine whether the default build is already 32-bits ("X") or whether it's not ("lib32-X"). Oct 16 19:09:03 And if the name lib32-X could just be a synonym for X in cases where lib32 is already the default, life would be simpler. Oct 16 19:19:52 problem is.. what is 'lib32' on a non-multilib system? Oct 16 19:20:18 do we always have to define a multilib name? if so, I'm not sure that will fly in the community (I personally don't have a problem with it.. but multilib work has been thorny) Oct 16 19:24:26 anybody got any special tips on what to do with developers who won't listen? Oct 16 19:25:31 cluebat Oct 16 19:26:26 i'd prefer not to get thrown out of the build and/or arrested... Oct 16 19:27:37 but yeah, that's pretty much the first/only thing that pops into my head Oct 16 19:28:54 *building even Oct 16 20:02:37 * kergoth thinks about ways to improve bitbake-whatchanged Oct 16 20:04:19 how is it in kergoth-world? Oct 16 20:05:09 kergoth, http://www.azcentral.com/community/gilbert/articles/20131015tempe-artist-picked-gilbert-public-artwork.html?nclick_check=1 Oct 16 20:34:20 * mr_science goes to the dentist Oct 17 00:39:26 im working on an with an am335x-evm board, i've built some images using yocto/poky, and meta-ti. currently using the dylan branches. however when i build, i dont get a dtb file generated? Oct 17 00:39:31 is this file neccessary? Oct 17 00:40:05 because at the moment, i cant get the board to boot the kernel. it runs u-boot, then gets stuck at "Starting Kernel" Oct 17 02:19:15 GusBricker: your problem is in the order of bblayers.conf - you can search the meta-ti mailing list archive... Oct 17 02:19:50 denis: for what exactly? ive been trying to figure this out for days now :( Oct 17 02:20:23 GusBricker: http://thread.gmane.org/gmane.linux.embedded.yocto.meta-ti/2726/focus=2744 Oct 17 02:20:57 ah Oct 17 02:20:59 thanks Oct 17 02:21:43 think ive read this thread already tho Oct 17 02:22:23 this is my layer order: Oct 17 02:22:27 /home/dtc-dev/projects/dtc-oe/meta \ Oct 17 02:22:27 /home/dtc-dev/projects/dtc-oe/meta-ti \ Oct 17 02:22:27 /home/dtc-dev/projects/dtc-oe/meta-yocto-bsp \ Oct 17 02:22:28 /home/dtc-dev/projects/dtc-oe/meta-yocto \ Oct 17 02:22:30 /home/dtc-dev/projects/dtc-oe/meta-oe/meta-oe \ Oct 17 02:23:28 hence the problem Oct 17 02:23:58 at minimum, swap the top 2 around Oct 17 02:24:12 at maximum, move "meta" to the very bottom Oct 17 02:24:36 doh, it is wrong! i thought i had changed it Oct 17 02:24:38 ive got this now Oct 17 02:24:42 /home/dtc-dev/projects/dtc-oe/meta-yocto \ Oct 17 02:24:43 /home/dtc-dev/projects/dtc-oe/meta-ti \ Oct 17 02:24:43 /home/dtc-dev/projects/dtc-oe/meta-yocto-bsp \ Oct 17 02:24:44 /home/dtc-dev/projects/dtc-oe/meta \ Oct 17 02:24:46 /home/dtc-dev/projects/dtc-oe/meta-oe/meta-oe \ Oct 17 02:26:08 should be fine now Oct 17 02:26:20 cheers! will give it a shot **** ENDING LOGGING AT Thu Oct 17 02:59:58 2013