**** BEGIN LOGGING AT Fri Oct 15 02:59:57 2010 Oct 15 03:40:35 okay, there's the overrides patch, comments welcome Oct 15 03:40:39 * kergoth_ finally gets around to it Oct 15 04:10:53 kergoth_: acked we have to document MACHINE_OVERRIDES though Oct 15 04:40:57 khem: good point, thanks, i always forget about the docs :) Oct 15 04:41:00 will do a v2 Oct 15 04:44:50 yeah or you can commit the doc patch separately too that fine Oct 15 04:46:14 kergoth_: is MACHINE_OVERRIDE for replacing MACHINE_CLASS or SOC_FAMILY ? Oct 15 05:47:45 gm Oct 15 06:09:36 morning Oct 15 06:14:58 I thought I'd try to update apr and apr-util while I'm at it. Any suggestions what to do about this error: /bin/sh /arm-angstrom-linux-gnueabi-libtool: No such file or directory? Oct 15 07:08:16 gm Oct 15 07:18:56 tasslehoff: there seems to be a prefix missing before /arm-angstrom-linux-gnueabi-libtool Oct 15 07:19:44 but actually i suggest going to lighttpd if you can Oct 15 07:22:16 gm Oct 15 07:23:04 eFfeM_work: it's for log4cxx I'm doing this, but I have almost decided to give it up. Oct 15 07:23:47 I think libqxt would be useful though, so now I'm focusing on that one instead. Oct 15 07:23:59 * tasslehoff hit the wall there as well Oct 15 07:24:16 tasslehoff: i don't know log4cxx, but have been fighthing with apache+php about a year ago, and after spending quite some time on it, I decided to take the advise I got and move to lighty Oct 15 07:27:26 eFfeM_work: yeah. it seems a bit too much right now. libqxt should really be simple. on my host it was a clean "./configure && make && make install", but I haven't worked with qmake in OE before. Oct 15 07:28:02 Right now I'm at "Failure to read QMAKESPEC conf file" Oct 15 07:28:56 hello Oct 15 07:29:25 good morning. Oct 15 07:30:37 Any hints or pointer for changing the uImage name label? Oct 15 07:31:13 I cannot find where it is set in OE recipies. Oct 15 07:31:30 hi Oct 15 07:31:39 label? Oct 15 07:32:10 yes, for example: "Image Name: Angstrom/2.6.28/mini6410" in u-boot startup display. Oct 15 07:34:12 I know it is set by mkimage in the kernel tree. But can't find where it gets the name value. Oct 15 07:34:52 hi mickeyl Oct 15 07:36:49 It looks like the name is auto composed as distro/kernel/machine by OE. Oct 15 07:37:07 But can't find where... Oct 15 07:41:06 Sorry the lame question: how can I make OE to generate an uImage instead of a zImage Oct 15 07:41:26 look at the kernel recipes Oct 15 07:43:49 TheNoise: KERNEL_IMAGETYPE="uImage" iirc Oct 15 07:46:38 I'm searching the kernel recipe used by angstrom with mx27ads machine... Oct 15 07:46:57 the most similar is mx21ads-kernel_2.6.19rc6.bb Oct 15 07:49:26 one day someone should kill all those old not maintained kernel recipes Oct 15 07:49:42 TheNoise: what is wrong with linux_2.6.35.bb for your target? Oct 15 07:50:28 TheNoise: most of linux-MACHINE or MACHINE-linux or MACHINE-kernel or *MACHINE* named kernel recipes are old and should be forgotten Oct 15 07:52:17 hrw, nothing wrong with that kernel :D.... thanks for the information! Oct 15 08:07:07 hrw, agree on killing non-maintained kernel recipes, but who defines non-maintained Oct 15 08:07:40 gm zecke Oct 15 08:08:58 eFfeM_work: anything <2.6.20 for start Oct 15 08:10:58 hrw, let's get rid of 2.4 first but colinuxoe and sharprom-compatible dirstro's sill pin 2.4 kernels Oct 15 08:11:30 eFfeM_work: "git tag last-moment-with-2.4-kernels"? Oct 15 08:11:39 and don't ask me what linux-xxs1500_2.4.21.bb is for Oct 15 08:12:10 xxs1500 is dead Oct 15 08:12:39 hrw, fine with me, i'm even ok to keep the two versions that are pinned Oct 15 08:13:02 actually recipes/linux is somewhat messy; 235 recipes in it Oct 15 08:13:18 effem yes :( Oct 15 08:13:51 hrw, can you post a patch or write a proposal or so, guess it will generate less controversy if it comes from you Oct 15 08:14:38 eFfeM_work: problem is that I do not use OE in any project now Oct 15 08:15:02 * eFfeM_work sometimes feels that someone has an automated nak generator that is triggered by my email address (if you get what I mean) Oct 15 08:15:09 ;DD Oct 15 08:16:20 03Martin Jansa  07master * rc6eeb6c740 10openembedded.git/recipes/libsdl/libsdl-ttf_2.0.10.bb: Oct 15 08:16:20 libsdl-ttf_2.0.10: add DEFAULT_PREFERENCE -1 as it doesn't build with default libtool-2.2.6b Oct 15 08:16:20 * there is patch only for libtool-2.4 Oct 15 08:16:20 * it expects libtool-2.2.6 Oct 15 08:17:09 jama!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Oct 15 08:17:21 remove libtool m4 macros Oct 15 08:17:24 and it will build Oct 15 08:18:17 cannot try on libtool-2.2.6b anymore.. Oct 15 08:19:42 JaMa|Wrk: were you the one that raised removing sharprom Oct 15 08:19:57 no Oct 15 08:20:41 ok, do you have an opinion on the 2.4 kernels ? Oct 15 08:21:25 I don't use 2.4 on any of my targets so OK for me Oct 15 08:23:11 hrw if xxs1500 is dead, should it be retired? whi is the machine owner Oct 15 08:23:19 no one Oct 15 08:23:41 Author: Bruno Randolf Oct 15 08:23:42 Date: Sat Oct 9 19:04:01 2004 +0000 Oct 15 08:24:00 wuahahahahahaha who pachted an m4 macro Oct 15 08:24:39 *g* Oct 15 08:24:42 ~blame jama Oct 15 08:24:43 * ibot blames jama (and Canada) for all the evil in the world Oct 15 08:25:00 * JaMa|Wrk hides Oct 15 08:27:05 lol, Canada Oct 15 08:27:25 hrw there is a commit in the machien file form 2008 from paul skolovsky Oct 15 08:27:32 woglinde_: see affcbbc1f73e9115a0c18d7701a28c9054198c7d 13d105b3921ca9838dd7740acef0a8a188bf3cb9 Oct 15 08:27:54 afk for a while Oct 15 08:32:06 eFfeM_work: when he changed lot of things in many machines Oct 15 08:33:39 Any advice for a good recipe to look at if I want to do a simple qmake recipe? Oct 15 08:34:39 jama sure I will fix it Oct 15 08:34:52 .o(conditonal libtool.m4 macro fixing) Oct 15 08:38:16 woglinde_: thx Oct 15 08:39:09 tasslehoff, do you want to build a qt4 app? (This what I'm tring to accomplish...) Oct 15 08:40:32 TheNoise: no, I want to create a recipe for QxtLib to get more powerful logging in Qt4. Oct 15 08:40:39 ~blame sdl developer Oct 15 08:40:39 * ibot blames sdl developer (and Canada) for all the evil in the world Oct 15 08:41:58 eFfeM_work: sent Oct 15 08:43:09 I started by creating a simple recipe with a SRC_URI, checksums and "inherit autotools qmake2". Is that correct? Oct 15 08:44:28 should be Oct 15 08:45:00 woglinde_: btw does new directfb build for you ok? Oct 15 08:46:07 woglinde_: I see your success in tinderbox, are you using gcc-4.5? Oct 15 08:46:31 yes Oct 15 08:47:21 I have same issue as mkdfiff.patch is fixing but in mkdgifft.cpp (but there is already include in extern "C" {) Oct 15 08:47:30 uh? Oct 15 08:47:51 jama tested it here Oct 15 08:47:54 and it compiled Oct 15 08:48:37 http://tinderbox.openembedded.org/packages/?name=directfb see error log Oct 15 08:49:35 * JaMa|Wrk rebuilding it atm Oct 15 08:50:29 * woglinde_ scratches head Oct 15 08:52:03 03Koen Kooi  07org.openembedded.dev * rc9ac99f13f 10openembedded.git/recipes/python/python-pygobject_2.20.0.bb: Oct 15 08:52:03 python-pygobject: forcefully disable introspection Oct 15 08:52:03 It will pick up the .pc from the native sysroot and then fail to build since we don't have target introspection libs to link against Oct 15 08:52:09 03Koen Kooi  07org.openembedded.dev * raeb537c64e 10openembedded.git/recipes/xst/xst_0.15.bb: xst: bump PR for pkgconfig changes in bitbake.conf Oct 15 08:52:39 woglinde_: I have patch now.. Oct 15 08:52:50 sure push it Oct 15 08:52:57 woglinde_: it needs include for sys/stat.h not unistd.h Oct 15 08:53:02 no Oct 15 08:53:03 check Oct 15 08:53:08 man fstat Oct 15 08:53:14 maybe because I'm using eglibc_2.12 Oct 15 08:53:18 #include Oct 15 08:53:18 #include Oct 15 08:53:18 #include Oct 15 08:53:26 ah okay Oct 15 08:53:28 woglinde_: I'm checking sysroots /usr/include Oct 15 08:53:31 I am on uclibc Oct 15 08:53:50 extra include won't hurt anybody right? Oct 15 08:54:06 jama if the manpages say include all three Oct 15 08:54:08 do it Oct 15 08:55:17 jama and yes there are guards Oct 15 08:55:27 so no header got include doubled Oct 15 08:55:41 at preprocessor time Oct 15 08:56:20 hm the libtool macro remove line should got into autotools.class Oct 15 08:56:21 seems like directfb needs a bit more packaging love Oct 15 08:56:39 probably Oct 15 09:09:23 good morning Oct 15 09:11:01 03Daniele Ricci  07master * ra9df044f70 10openembedded.git/recipes/openmoko-3rdparty/mokosuite2_git.bb: Oct 15 09:11:01 mokosuite2: bump SRCREV, many bugs fixed and a test version of mokomessages Oct 15 09:11:01 Signed-off-by: Daniele Ricci Oct 15 09:11:01 Signed-off-by: Martin Jansa Oct 15 09:11:01 03Martin Jansa  07master * ra524a74b9b 10openembedded.git/recipes/directfb/ (directfb-1.4.6/mkdfiff.patch directfb_1.4.6.bb): Oct 15 09:11:01 directfb_1.4.6: update mkdfiff.patch to fix building with newer eglibc Oct 15 09:11:02 Signed-off-by: Martin Jansa Oct 15 09:11:37 jama wher can I upload my sdl-tff fix so you can test it? Oct 15 09:11:44 hm I will just mail it Oct 15 09:12:56 It will take long for me.. rebuilding from scratch now, but can it test it later.. Oct 15 09:13:20 sure Oct 15 09:13:27 but now it builds Oct 15 09:14:02 hm I think thats not necassary to anymore EXTRA_OECONF += "SDL_CONFIG=${STAGING_BINDIR_CROSS}/sdl-config " Oct 15 09:14:12 because it uses pkg-conf Oct 15 09:14:29 woglinde_: even for libtool-2.4? because I got strange issues without those macros Oct 15 09:15:24 they get coppied Oct 15 09:15:28 thats the trick Oct 15 09:15:33 jo kgilmer Oct 15 09:15:57 the problem is when there are already some macros Oct 15 09:16:08 the mixing of the copied one is bad Oct 15 09:17:05 jama but you need to tell autoconf the right dir where to copy the macro Oct 15 09:17:06 s Oct 15 09:17:42 I hope for m4-v2.0 to come soon Oct 15 09:17:53 so the dir hacks can go away Oct 15 09:18:01 and aclocal too Oct 15 09:21:32 hi woglinde_ :) Oct 15 09:22:42 kgilmer I updated java stuff yesterday to get the sceurity fixes included Oct 15 09:22:48 but its only for -dev now Oct 15 09:22:50 to remove shark/llvm openjdk i was not successful in fixing the llvm compile error by setting the preferred version of gcc. but i was able to just edit the common.inc to remove shark and llvm. Oct 15 09:23:00 maybee stefan can update them to -stable Oct 15 09:23:38 ok Oct 15 09:24:24 to remove shark/llvm openjdk -> to fix shark/llvm openjdk Oct 15 09:25:11 i would like to provide a recipe to build openjdk without shark/llvm Oct 15 09:25:29 but as they are written now the opts passed to the openjdk build are defined in the common inc file Oct 15 09:25:37 i can just override that in my new recipe i guess. Oct 15 09:25:50 it's been awhile since i've done much recipe hacking, i'm rusty :) Oct 15 09:26:54 kgilmer hm I little tought about it and maybee will come with a solution where I let the distro decide which openjdk variants it will include Oct 15 09:27:21 hm but wasnt the problems at runtime? Oct 15 09:27:33 so dont install the shark stuff Oct 15 09:28:01 not for MACHINE="bug" llvm does not compile. you found the issue seemed to be with gcc versoin. i went with that but was never able to move forward. Oct 15 09:28:08 ah right Oct 15 09:28:10 sorry Oct 15 09:28:55 i tried setting the preferred version in the recipe and in my local.conf. it didn't seem like bitbake was picking up my version when building but i could not be totally sure. Oct 15 09:29:22 but then i just saw in the recipe the "--build-shark" and "depends llvm" lines and removed them and *poof* it worked. Oct 15 09:29:30 i wonder tho about the thumb2jit Oct 15 09:29:37 woglinde_: any hint for new icedtea-native do_configure failure? http://tinderbox.openembedded.org/public/logs/task/8743848.txt Oct 15 09:29:46 i did some quick benchmarkings and it does not appear to be running Oct 15 09:31:13 in any case woglinde_ i provided some binaries so that customers can get openjdk for existing bug devices Oct 15 09:31:16 what the hell Oct 15 09:31:20 and will post the patch to the inc file to make that work Oct 15 09:31:24 http://community.buglabs.net/kgilmer/posts/213-OpenJDK-on-BUG-1-3-Devices Oct 15 09:33:30 jama I will test here Oct 15 09:34:55 kgilmer: hi Oct 15 09:35:05 hey hrw Oct 15 09:35:56 kgilmer: how goes bug2.0? Oct 15 09:36:16 still intrigued by the debian arm bootstrapping process that creates the universe hrw. Oct 15 09:36:22 bug20 is chugging along Oct 15 09:36:39 jama hm maybee openjdk isnt unpacked at your side Oct 15 09:36:47 can you clean and try again Oct 15 09:36:53 i have two on my desk hrw, they are nice :) Oct 15 09:36:58 kgilmer: want to bootstrap? ubuntu has packages to bootstrap armel Oct 15 09:37:43 hrw, no i'm just interested in the process of getting a self hosting linux on a new cpu architecture. must have been some fun :) Oct 15 09:37:43 kgilmer: in cases? Oct 15 09:37:54 yes hrw Oct 15 09:38:01 photos? Oct 15 09:38:41 i don't have any at the moment hrw Oct 15 09:38:49 looks much nicer than old bugs though :) Oct 15 09:43:00 there are renderings on the bl product page Oct 15 09:45:11 jama args Oct 15 09:45:16 but I tested it here Oct 15 09:50:08 woglinde_: NOTE: Unpacking downloads/openjdk-6-src-b17-14_oct_2009.tar.gz to tmp/work/x86_64-linux/icedtea6-native-1.7.5-r2.0/openjdk-src-dir/ and the dir is empty then Oct 15 09:50:16 yes Oct 15 09:50:21 what the hell Oct 15 09:51:35 where the hell its unpacking then? Oct 15 09:53:44 hm is the subdir= ignored? Oct 15 09:53:48 maybee an bitbake error? Oct 15 09:54:20 woglinde_: looks like directly to icedtea6-native-1.7.5-r2.0 Oct 15 09:54:46 kergoth awake!!!!!!!!!!!!!!!!!!!!!!!!! Oct 15 09:56:05 jama can you try a another package which has subdir? Oct 15 09:56:13 args recipe Oct 15 09:56:30 no faulty ${S} ? Oct 15 09:56:45 effem the line worked before Oct 15 09:57:13 and the last I remeber kergoth worked on the fetcher/unpack code Oct 15 09:57:44 greping for such recipe.. Oct 15 10:00:44 woglinde_: seems like only icedtea-native, openjdk and webkit-efl is using subdir (webkit-efl for svn fetcher) Oct 15 10:00:48 hm only webkit-gtk Oct 15 10:00:50 yes Oct 15 10:00:52 damn Oct 15 10:01:35 lunch, bbl Oct 15 10:01:42 hm jo Oct 15 10:01:46 I try to find out Oct 15 10:01:53 if there is somehting new for subdir Oct 15 10:08:58 hm so is not my fault Oct 15 10:10:17 how could I create my own branch in OE ? Oct 15 10:10:47 mckoan read the git wiki side Oct 15 10:11:03 woglinde_: do I have to ask someone? Oct 15 10:11:15 if you have ssh access no Oct 15 10:11:26 woglinde_: fine thx Oct 15 10:13:41 mckoan: please use your name as first part (see other branches) that way it is clear who made it Oct 15 10:13:47 (not sure if that info is in the wiki) Oct 15 10:17:34 whahaha Oct 15 10:17:37 kergoth Oct 15 10:17:40 broke subdir Oct 15 10:20:43 hm but I think its easy to fix Oct 15 10:21:58 eFfeM_work: thx Oct 15 10:22:10 yw Oct 15 10:26:05 okay it seems to work Oct 15 10:26:08 poor kergoth Oct 15 10:26:19 -win 86 Oct 15 10:26:31 * dm8tbr grabs a new bag of / Oct 15 10:27:05 * eFfeM_work throws dm8tbr with some \ Oct 15 10:27:22 so dm8tbr can make a \/ Oct 15 10:27:48 woglinde_: can happen Oct 15 10:27:59 /win 86 - the /say command works nice too :) Oct 15 10:29:07 effem good it was no failure in bitbake Oct 15 10:29:48 03Henning Heinold  07org.openembedded.dev * re96d72a1ce 10openembedded.git/lib/oe/unpack.py: oe.unpack: fix subdir-feature Oct 15 11:21:11 woglinde_: thanks for quick unpack fix.. now it segfaults for me :/ but will try to rebuild again | /home/shr/shr-unstable/tmp/sysroots/x86_64-linux/usr/bin/ecj-bootstrap: line 4: 4546 Segmentation fault ${RUNTIME} -Xmx512m -cp ${ECJ_JAR} org.eclipse.jdt.internal.compiler.batch.Main ${1+"$@"} Oct 15 11:23:27 jama ah right Oct 15 11:23:31 this damn error Oct 15 11:25:45 jama -> http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTimqQrV9qMBmBnh2BD9RHSzmRPcBCb-M9ot2G%3Dm9%40mail.gmail.com&forum_name=jamvm-general Oct 15 11:50:47 woglinde_: yup I'm aware of this problem, that's why I just tried to rebuild again and if it doesn't build then again.. Oct 15 11:52:06 jama hm for oe we should try the proposed fix Oct 15 11:59:42 * ynezz wonders who's the SamyGO_arris69 samygoT-TDT5DEUC spammer on tinderbox Oct 15 12:00:00 heh, 1089 pages of builds Oct 15 12:01:53 Does anyone know of an existing program -- besides dd -- that can be used to create BIOS-partitioned disk images? Oct 15 12:04:44 I'm trying to get OE to output dd-able disk images, and I'd rather not need to resort to the old dd conv=notrunc with manually-calculated offsets. Oct 15 12:31:43 woglinde_: built ok on 2nd try Oct 15 12:37:17 jama sdl-ttf? Oct 15 12:40:07 ...guess it's time to write one then. Oct 15 12:43:38 woglinde_: no that icedtea6-native-1.7.5 Oct 15 12:47:52 jama yes Oct 15 12:48:02 I olny wanted to remind you Oct 15 12:49:50 woglinde_: I didn't forget.. but still rebuilding NOTE: Running task 3907 of 9503 Oct 15 12:50:55 03Koen Kooi  07org.openembedded.dev * r62340d73f0 10openembedded.git/recipes/angstrom/ (angstrom-version.bb angstrom-version/lsb_release): angstrom-version: make lsb_release work with GNOME Oct 15 13:37:07 What do I need to build to get qt4-embedded-plugin-gfxdriver-gfxpvregl? Oct 15 13:43:31 ~seen zecke Oct 15 13:43:34 zecke <~ich@91-64-127-39-dynip.superkabel.de> was last seen on IRC in channel #oe, 20h 41m 57s ago, saying: 'woglinde: just basic one'. Oct 15 13:53:24 woglinde_: bah! thanks for the fix. I swear, recently I can't do anything without breaking something else. neeeeeed unit tests :) Oct 15 13:53:32 * kergoth_ should start adding some for the lib/oe/ stuff Oct 15 14:00:13 kergoth he Oct 15 14:00:19 I break enough stuff too Oct 15 14:26:43 nice to see my old friend obi makes so much patches for oe Oct 15 14:27:56 wgagagagaaa but not a libtool.m4 patch again Oct 15 15:26:46 bye guys, have a nice we Oct 15 15:49:34 have a nice weekend people Oct 15 16:01:43 03Chase Maupin  07org.openembedded.dev * r5657d5ed59 10openembedded.git/recipes/ti/ (matrix-gui.inc matrix-gui_1.1.bb matrix-gui_1.2.bb): (log message trimmed) Oct 15 16:01:43 matrix-gui: use INC_PR in versioned recipes Oct 15 16:01:43 * Added an INC_PR to the matrix-gui.inc file to be used Oct 15 16:01:43 by the individual version recipes. Oct 15 16:01:43 * Modified the version recipes to use INC_PR in their PR setting. Oct 15 16:01:44 Signed-off-by: Chase Maupin Oct 15 16:01:44 Acked-by: Denys Dmytriyenko Oct 15 16:01:50 03Chase Maupin  07org.openembedded.dev * r25d57b6ecb 10openembedded.git/recipes/ti/ (matrix-gui-e.inc matrix-gui-e_1.1.bb matrix-gui-e_1.2.bb): (log message trimmed) Oct 15 16:01:50 matrix-gui-e: use INC_PR in versioned recipes Oct 15 16:01:50 * Added an INC_PR to the matrix-gui-e.inc file to be used Oct 15 16:01:50 by the individual version recipes. Oct 15 16:01:50 * Modified the version recipes to use INC_PR in their PR setting. Oct 15 16:01:50 Signed-off-by: Chase Maupin Oct 15 16:01:51 Acked-by: Denys Dmytriyenko Oct 15 16:01:52 03Chase Maupin  07org.openembedded.dev * r273e8ea3d7 10openembedded.git/recipes/ti/ (3 files): (log message trimmed) Oct 15 16:01:53 matrix-gui-common: use INC_PR in versioned recipes Oct 15 16:01:53 * Added an INC_PR to the matrix-gui-common.inc file to be used Oct 15 16:01:54 by the individual version recipes. Oct 15 16:01:54 * Modified the version recipes to use INC_PR in their PR setting. Oct 15 16:01:55 Signed-off-by: Chase Maupin Oct 15 16:01:55 Acked-by: Denys Dmytriyenko Oct 15 16:01:58 03Chase Maupin  07org.openembedded.dev * r04824cee38 10openembedded.git/recipes/ti/ (matrix-tui.inc matrix-tui_1.0.bb): (log message trimmed) Oct 15 16:01:58 matrix-tui: use INC_PR in versioned recipe Oct 15 16:01:58 * Added an INC_PR to the matrix-tui.inc file to be used Oct 15 16:01:58 by the individual version recipes. Oct 15 16:09:15 kergoth_, where does tinderbox get its 'distro' from? I don't understand why 'angstrom' is listed as a distro there when its not a distro (angstrom-2008.1, angstrom-2008.1-legacy, and angstrom-2010.x are) Oct 15 16:11:44 "DISTRO" : data.getVar('DISTRO', d, True) or "Unknown" Oct 15 16:12:03 in tinderclient.bbclass Oct 15 16:12:20 how can it be showing 'angstrom' then? Oct 15 16:12:29 look into DISTRO and USERDISTRO Oct 15 16:12:35 bitbake -e | grep DISTRO= Oct 15 16:13:22 is there some facility that allows you to specify DISTRO=angstrom and it picks the 'preferred' version like recipes do? Oct 15 16:13:32 it isn't magic Oct 15 16:13:46 you specify angstrom-foo, the angstrom-foo config file sets DISTRO to angstrom, iirc Oct 15 16:14:20 thats very misleading - you can't tell the diff between angstrom-foo and angstrom-bar then Oct 15 16:14:32 re Oct 15 16:14:33 gm Oct 15 16:14:45 yes, youc an Oct 15 16:15:04 using USER_DISTRO Oct 15 16:15:27 maybe it would be better to change the oe-stats client to use USERDISTRO Oct 15 16:15:33 tharvey: had you run the command i gave you above, or looked into USERDISTRO the way i suggested, you'd realize this Oct 15 16:15:34 so it shows right version Oct 15 16:15:42 perhaps, yeah Oct 15 16:15:51 no, I'm saying in tinderbox Oct 15 16:15:55 you can't tell the diff Oct 15 16:16:04 * kergoth_ points at what ynezz just said Oct 15 16:16:08 tinderbox = oe-stats Oct 15 16:16:09 agrees Oct 15 16:16:23 I second the motion to use USERDISTRO in oe-stats :) Oct 15 16:16:40 * ynezz is waiting for the tharvey's patch :) Oct 15 16:16:54 does anyone have an idea why 'PARALLEL_MAKE = "-j 6"' would not be used for building the kernel? Oct 15 16:17:15 shoragan: use bitbake -e on the recipe Oct 15 16:17:25 hi shoragan Oct 15 16:17:56 can someone kick that tinderbox spammer? Oct 15 16:18:04 it's SamyGO_arris69 Oct 15 16:18:23 I'm still not really seeing where DISTRO gets set though outside of env or local.conf - bitbake -e | grep DISTRO= shows USERDISTRO="angstrom-2008.1" but only a commented out DISTRO=angstrom Oct 15 16:18:30 hi zecke and woglinde_ :) Oct 15 16:18:46 tharvey: conf/distro/include/angstrom.inc Oct 15 16:19:08 hi, ynezz, isn't samyGO a firmware for samsung tvs Oct 15 16:19:09 git grep USERDISTRO Oct 15 16:19:13 apparently tharvey's never heard of "grep" Oct 15 16:19:18 ynezz, ah yes thx Oct 15 16:19:20 git grep DISTRO\ = conf/distro Oct 15 16:19:37 GNUtoo|laptop: ah, so Oct 15 16:19:40 kergoth_, well, expected to see it from bitbake -e | grep DISTRO= and did not Oct 15 16:20:18 Is there a way to find the work source dir of a recipe from a recipe that DEPENDS on it Oct 15 16:20:28 tharvey: you can't see it there :) Oct 15 16:20:29 yes, you did. the commented version is the unexpanded version of the variable Oct 15 16:20:33 that doesn't mean it isn't set Oct 15 16:20:48 ya, I understand... was missing what bitbake -e did - thx Oct 15 16:21:26 lovely, we have SRC_URI and SRCREV Oct 15 16:21:36 hm, it might be better to add some filtering option to the build reports Oct 15 16:21:43 it just took me a couple of attempts to figure out it is not SRC_REV Oct 15 16:21:52 :D Oct 15 16:21:54 pfft, consistency Oct 15 16:22:05 who needs Oct 15 16:22:06 it Oct 15 16:22:26 zecke, bitbake -e has the PARALLEL_MAKE variable just fine Oct 15 16:22:48 shoragan: he said use bitbake -e on the recipe. bitbake -e virtual/kernel | grep \^PARALLEL_MAKE Oct 15 16:22:50 you did that? Oct 15 16:23:04 bitbake -e with no arguments shows the global configuration metadata, not the recipe Oct 15 16:23:05 yep Oct 15 16:23:14 bitbake -e linux in this case Oct 15 16:23:34 no, virtual/kernel would have been just fine in your case too. it always points to the current machine's kernel Oct 15 16:23:38 but regardless, no idea then :) Oct 15 16:24:35 morning kergoth Oct 15 16:24:41 hey pb_ Oct 15 16:25:39 he stefan Oct 15 16:25:49 hi woglinde_ Oct 15 16:25:57 woglinde_: you are fast :) Oct 15 16:25:59 hi all Oct 15 16:26:12 woglinde_: will you make it to OEDEM this year? Oct 15 16:26:15 no Oct 15 16:26:27 but robert will be there Oct 15 16:26:54 ok Oct 15 16:27:25 ts, ts, not on the list yet Oct 15 16:27:36 woglinde_: Will we see us at 27C3 this year then? Oct 15 16:27:44 m maybee Oct 15 16:27:52 dont know yet Oct 15 16:28:05 depends on family too Oct 15 16:28:05 ok Oct 15 16:28:19 yeah, more difficult Oct 15 16:30:22 wow, I hope I can finish testing-next angstrom-2008.1 till next friday :p 950K .......... .......... .......... .......... .......... 2% 8.08K 1h49m Oct 15 16:31:31 ah! conf/bitbake.conf only uses PARALLEL_MAKE for do_compile, not do_compile_kernelmodules Oct 15 16:31:47 ynezz if you dont build openjdk Oct 15 16:31:51 shoragan: yeah, Koon did post some patches to the ml about it Oct 15 16:31:55 shoragan: hi, btw Oct 15 16:31:59 hi stefan_schmidt Oct 15 16:32:21 question about tinderbox: how come if I search build reports for distro=angstrom machine=beagleboard the most recent one is 2010-10-14 08:02:40 but if I look at builders/ec2build I see there is a more recent one matching distro and machine? Oct 15 16:33:29 maybe wrong sql select :) Oct 15 16:33:50 woglinde_: now, the downloading from the mirrors is so slow Oct 15 16:33:56 s/now/no/ Oct 15 16:34:14 shoragan: aha, good catch Oct 15 16:34:32 im not sure where we should fix that Oct 15 16:35:01 woglinde_: looks like angstrom.org is broken Oct 15 16:35:42 is there some easy and fast way to disable the mirrors? just need to leave, but would like to build testing-next until I return Oct 15 16:37:18 hm no idea Oct 15 16:38:01 kergoth, should i just add $PARALLEL_MAKE to the oe_runmake parameters? Oct 15 16:39:17 heyho Oct 15 16:39:35 hi morphis Oct 15 16:50:02 GPLV3 or later is GPLV3+ in the license field? Oct 15 16:56:19 03Tom Rini  07org.openembedded.dev * rfd40911b32 10openembedded.git/recipes/openswan/ (5 files in 2 dirs): Oct 15 16:56:19 openswan: Update to 2.6.29 Oct 15 16:56:19 openswan 2.4.7 has a large number of security defects and was not Oct 15 16:56:19 pinned by any users, so remove. Oct 15 16:56:19 Signed-off-by: Tom Rini Oct 15 17:22:58 gm Oct 15 17:23:26 gm Oct 15 17:38:21 woglinde_: The openjdk updates you where talking about with kgilmer are the security updates? Or anything else I missed? Oct 15 17:38:39 woglinde_: Will have a look at the sec updates for stable on monday Oct 15 17:40:07 hmm, why doesn't RDEPENDS cause a build of the dependancy? Oct 15 17:40:52 use DEPNDS for that Oct 15 17:41:08 REDEPENDS is based on packges and is for package management Oct 15 17:44:14 i thought it would look for packages providing those in RDEPENDS and build them, too Oct 15 17:45:07 so in all cases, i need to add the recipes for all RDEPENDS to DEPENDS? Oct 15 17:49:25 what would be preferred gdb 7.1 moved to 7.2 or both recipes coexist Oct 15 17:49:43 I have gdb 7.2 recipes replace gdb 7.1 Oct 15 17:49:48 atm Oct 15 17:49:58 gm all Oct 15 17:51:36 shoragan, I don't think RDEPENDs is smart enough to actually build the recipes :) Oct 15 17:51:41 khem, gm Oct 15 17:51:50 hmm Oct 15 17:52:21 also perl 5.10 provides libmodule-build-perl, which was separate before Oct 15 17:52:34 but we use 5.8 by default Oct 15 17:52:53 Crofton: I have some fixes for gnuradio Oct 15 17:53:02 and it seems bitbake thinks libmodule-build-perl satisfied by perl Oct 15 17:53:08 mainly QA errors where .so was outside -dev packages Oct 15 17:53:15 bitbake does handle rdepends for recipe building just fine Oct 15 17:53:22 heh Oct 15 17:53:28 it determines what recipes have those in their PACKAGES and builds them as appropriate Oct 15 17:53:28 can you email me a pactch Oct 15 17:53:43 also obeys PREFERRED_PROVIDER information for runtime, not just build Oct 15 17:53:44 although I am in the processing of dramatically changing the recipe Oct 15 17:53:55 libtool 2.4 is going to bring a whole new breed for OE Oct 15 17:54:07 breed of what? Oct 15 17:54:07 the packages which dont libtoolize need updates Oct 15 17:54:35 Crofton: should do it one by one Oct 15 17:55:07 I am in the process of checking my new recipe against dev Oct 15 17:55:09 gah, i'm really falling behind on my email, particularly the oe ones.. so much for inbox zero Oct 15 17:55:13 hrmph Oct 15 17:55:21 yeah Oct 15 17:55:28 that has been happening to me to Oct 15 17:55:30 kergoth, if something depends on libmodule-build-perl and perl 5.8 is used, shouldn't it then build the separate libmodule-build-perl Oct 15 17:55:44 I just found out we will have hw to ship 6 weeks b4 I was expecting it Oct 15 17:56:03 shoragan: only if you specify a preference than you'd rather have separate rather than 5.10, otherwise it'll go ahead and build both, i suspect Oct 15 17:56:14 s/than/that/ Oct 15 17:56:15 oh Oct 15 17:56:20 * kergoth_ checks Oct 15 17:56:37 it depends on whether 5.8 and 5.10 are only versions, or are part of the recipe names -- i don't know how perl is managed Oct 15 17:57:35 Crofton: here is gnuradio patch http://pastebin.com/qNUiaNSS Oct 15 17:57:40 as far as i can see, only 5.8.8 gets built Oct 15 17:57:45 Crofton: do u see any issues ? Oct 15 17:57:56 they are only versions Oct 15 17:58:24 no Oct 15 17:58:28 perl_5.10.1.bb (with default pref -1) and perl_5.8.8.bb Oct 15 17:58:35 if something rdepends on libmodule-build-perl, bitbake will find something that packages it and ensure it builds that.. it doesn't have a great deal of intelligence when selecting which of multiple recipes package it, only user specified with preferences Oct 15 17:58:36 I want to simplify the packages anyway Oct 15 17:58:49 it is overspecialized atm Oct 15 17:58:58 but, that said, it will only build one version of a given package unless something explictly pulls both in Oct 15 17:59:07 I am trying to remember why we added dist-utils ... Oct 15 17:59:49 all the usb stuff is gone since we now build it for uhd, which replace the libusrp, which depended on old libusb internals :) Oct 15 18:00:43 * kergoth_ thinks about doing a prototype of a class to dynamically adjust ASSUME_PROVIDED based on what's actually available in the machine Oct 15 18:00:53 * kergoth_ keeps thinking about it, but keeps putting it off Oct 15 18:01:08 kergoth, do you know a good bblayers/bbappend tutorial? Oct 15 18:01:27 kergoth, that is the road to insanity :) Oct 15 18:02:24 Crofton: read my blog on bbappend and bblayers Oct 15 18:02:31 its a start Oct 15 18:02:38 there are a couple blog posts about them floating around -- beyond that, not really. bbappend is really simple, its entirely filename based, not path. if .bb and .bbappend are both in bbfiles, it appends the latter to the former Oct 15 18:02:48 Crofton: http:/sakrah.dontexist.org Oct 15 18:03:03 ah Oct 15 18:03:12 I see that one Oct 15 18:03:26 can you replace the TOPDITR with an actual directory? Oct 15 18:03:38 http://github.com/kergoth/OE-BBLayers is also a very simple sample Oct 15 18:04:37 hmmm coming to libtool -rpath /usr/lib from relink is converted into -L/usr/lib which is a killer Oct 15 18:04:48 for cross compilation Oct 15 18:04:51 didn't we patch it to remove that? Oct 15 18:04:56 thought we did Oct 15 18:04:57 no Oct 15 18:05:04 this is 2.4 Oct 15 18:05:07 well, i know i had a patch for it, at one point.. Oct 15 18:05:18 not against 2.4, but pull it forward Oct 15 18:05:34 can we feed that back to the libtool guys Oct 15 18:05:38 though, i guess its code must be quite different now Oct 15 18:05:42 * kergoth_ should peruse 2.4 Oct 15 18:05:44 I think there is hostory there though Oct 15 18:07:13 * chouimat bangs head on desk Oct 15 18:10:04 how can i find out which providers was selected when i see NOTE: multiple providers are available for libmodule-build-perl (libmodule-build-perl, perl) Oct 15 18:12:52 kergoth, the TOPDIR line just sets TOPDIR to pwd when you run bitbake Oct 15 18:13:09 I assume you do this to move between different source trees easily? Oct 15 18:14:35 kergoth_: with sysroot it should be easier now Oct 15 18:15:14 Crofton: what do you mean? Oct 15 18:15:22 Crofton: the one in that repo does not do what you describe.. Oct 15 18:15:34 it sets it to the top of the dir that contains conf/bblayers.conf Oct 15 18:15:47 as long as i'm underneith that, at any depth, in any dir, it'll work fine Oct 15 18:16:38 can I just hardcode the path? Oct 15 18:16:46 of course, why would bitbake care? Oct 15 18:16:54 good :) Oct 15 18:16:54 default is always pwd if you don't set it Oct 15 18:17:05 it makes it easier to explain to other people Oct 15 18:17:31 i'm not sure how that would be the case Oct 15 18:17:33 but suit yourself Oct 15 18:17:56 people who do not understand d.getVar .... Oct 15 18:18:02 this way is more like a "project" area. i cd into the project, anywhere underneith it, it builds there and puts tmpdir at toplevel of the project Oct 15 18:18:19 so document it. i don't see how hardcoding something is an improvement Oct 15 18:18:26 but again, up to you Oct 15 18:18:31 * kergoth_ goes back to real work Oct 15 18:21:04 gah, i hate computers at times Oct 15 18:25:05 Crofton: probably worth noting that you can avoid getVar at aleast Oct 15 18:25:19 TOPDIR := "${@os.path.dirname(os.path.dirname('${FILE}'))}" Oct 15 18:25:26 still not exactly pretty though :) Oct 15 18:25:58 :) Oct 15 18:26:34 Someone defined ${FILE} ... Oct 15 18:27:01 I jsut need to set it up Oct 15 18:27:10 I suspect after I am done I will understand Oct 15 18:28:05 FILE is set by bitbake, it's always set to the current file by the parser Oct 15 18:28:21 * kergoth_ sighs, work laptop is keeling over Oct 15 18:41:23 kergoth_: infact I am thinking libtool should append sysroot to rpath Oct 15 18:41:27 when converting Oct 15 18:41:40 that way if sysroot is set it will append otherwise it will be as it is Oct 15 18:41:48 so the functionality wont change Oct 15 18:42:16 now the daunting task is to locate that in libtool sources Oct 15 18:42:36 more I want to go away from scripting more I get dragged into it Oct 15 19:03:35 kergoth_: my inbox zero approach: use a backup account, forwards all emails there, then on a lucky day, delete all emails in my inbox :-) Oct 15 19:03:45 hehe Oct 15 19:03:58 with fingers crossed Oct 15 19:05:41 rofl Oct 15 19:05:50 likewise, you will be in Cambridge? Oct 15 19:23:31 khem, ping Oct 15 19:33:20 http://pastebin.com/3T2Rbv3S Oct 15 19:38:44 03Chris Larson  07master * r5b485324c2 10openembedded.git/ (17 files in 9 dirs): (log message trimmed) Oct 15 19:38:44 Reverse the order of OVERRIDES Oct 15 19:38:44 Given the current implementation of OVERRIDES in bitbake, the variable is Oct 15 19:38:44 expected to contain elements in the order least specific to most specific, Oct 15 19:38:44 however, our current usage of it does not match that. As one example, "local" Oct 15 19:38:45 is supposed to always be the most specific override, yet currently it's the Oct 15 19:38:46 least specific. As another example, currently the target architecture is seen Oct 15 19:41:01 Crofton: yup Oct 15 19:41:08 good Oct 15 19:41:11 I should be there Oct 15 19:41:23 although I might have to lift a badge from someone in a pub Oct 15 19:41:52 Crofton|work: good, a badge for what? Oct 15 19:42:05 elce Oct 15 19:42:21 Crofton|work: ah :-) Oct 15 19:43:48 Crofton|work: fetch_badge() DEPENDS apply_beer()? Oct 15 19:43:58 yes Oct 15 19:44:20 or compile the BDK (badge development kit) Oct 15 19:44:41 maybe we can have a badge hacking session Oct 15 19:45:06 ah, sold out... Oct 15 19:45:17 wow Oct 15 19:45:57 I am wait listed, but already have ticket Oct 15 20:01:14 hm, I seem to have an issue on our autobuilder with bitbake 1.10.1 while 1.10.0 works Oct 15 20:01:20 see http://www.pastebin.ca/1963333 Oct 15 20:01:41 this is under ubuntu 10.04, cannot reproduce it manually on my opensuse 11.2 system at home yet Oct 15 20:02:34 very strange Oct 15 20:02:42 hmm, thats odd, the only changes between them should be bugfixes which shouldn't affect expansion or parsing at all Oct 15 20:02:51 if at all possible, repro it and bisect, pleaes Oct 15 20:03:46 kergoth_: the issue is on our autobuilder which makes it a little bit harder to debug, that is why I am trying to reproduce it locally Oct 15 20:03:53 ah Oct 15 20:06:06 and another system (on my system at home with bitbake head): my image builds almost fine but near the end when it is about to make the rootfs things stall, and I have 4 dangling tee processes; see http://www.pastebin.ca/1963337 Oct 15 20:07:00 which is also odd as it worked before (guess one or two weeks ago); bitbake -cclean lirc; bitbake lirc does not help Oct 15 20:08:25 note that all these 4 have empty run scripts Oct 15 20:15:42 03Tom Rini  07org.openembedded.dev * rbed8795f36 10openembedded.git/recipes/cups/ (cups14.inc cups_1.4.3.bb cups_1.4.4.bb): Oct 15 20:15:42 cups14: Drop legacy bits, correct libusb dep Oct 15 20:15:42 We don't need do_stage for target stuff, drop. We don't need Oct 15 20:15:42 name=foo on SRC_URIs in this case, drop. We want virtual/libusb0 Oct 15 20:15:42 for a dep here. Oct 15 20:15:43 Signed-off-by: Tom Rini Oct 15 20:18:31 eFfeM: weird. Oct 15 20:23:23 kergoth_: trying an older version, meanwhile peeking at lib/bb/build.py, i'm not too good in python but i'm wondering what happens in exec_func when there is an exception after the popen Oct 15 20:25:18 can't seem to do a git reset --hard to an earlier commit and retain a working bitbake Oct 15 20:26:03 btw is there an easy way to add a message print in the python code ? Oct 15 20:34:18 you mean like bb.note? Oct 15 20:35:12 Crofton: you ok with my gnuradio patch ? Oct 15 20:35:24 well Oct 15 20:35:25 kergoth_: will peek at the 1.10.1 thing tomorrow or so, might be something at my side; need to investigate. Oct 15 20:35:34 I changed everything around :) Oct 15 20:35:55 and ran into Oct 15 20:36:00 http://pastebin.com/3T2Rbv3S Oct 15 20:36:05 Crofton|work: ok. that makes my patch not needed ? in that case its fine Oct 15 20:36:14 kergoth_: yeah, can I use bb.note without having to make any other change? I'm a fairly python n00b, can read it but not too good in modifying Oct 15 20:36:23 yeah Oct 15 20:36:31 but it doesn't buid; Oct 15 20:36:32 Crofton|work: thats fixed with my latest gcc patches Oct 15 20:36:36 I posted to ml Oct 15 20:36:38 bb.note works fine, yes Oct 15 20:36:40 ah Oct 15 20:36:41 ok Oct 15 20:37:02 everything the metadat can use in the bb python package canb e used from inside of bitbake, generally Oct 15 20:37:04 I had to add distutils-base back to get python stuff working Oct 15 20:37:12 Crofton|work: you can git am those two patches but you have to rebuild gcc-cross Oct 15 20:37:21 Crofton|work: ok Oct 15 20:37:31 when do you think think yu will push those Oct 15 20:37:41 Crofton|work: that error you get is with libtool 2.4? Oct 15 20:37:50 yes Oct 15 20:37:59 current checkout Oct 15 20:38:02 I can push them anytime but I need to get a libtool fix also tested Oct 15 20:38:08 with angstrom 2010 Oct 15 20:38:09 so may be tonight Oct 15 20:38:10 k Oct 15 20:38:14 re Oct 15 20:38:17 I can look at layers for a bit :) Oct 15 20:38:19 kergoth_: trying, will keep you posted Oct 15 20:38:27 k, thanks Oct 15 20:38:34 Crofton|work: ok Oct 15 20:38:43 I just found out we will have shippable hw in early Nov Oct 15 20:38:52 which is about 6 weeks before I expected it Oct 15 20:38:56 Crofton|work: thats cool Oct 15 20:38:58 yeah Oct 15 20:39:06 its like couple of weeks ? Oct 15 20:39:14 basically yes Oct 15 20:41:16 Im getting a slew of QA Issues from packages today that I didn't see previously (MACHINE=overo): ERROR: QA Issue with staging: gtkmathview-libxml2-reader.pc failed sanity test (tmpdir) in path /home/tharvey/oe/commonOS-sync/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/pkgconfig Oct 15 20:41:32 something obvious to look for? Oct 15 20:41:41 tharvey: hmmm thats something with pkg-config Oct 15 20:42:05 tharvey inherit pkgconfig Oct 15 20:42:13 than the .pc get fixed Oct 15 20:42:16 no changes in pkgconfig.bbclass? Oct 15 20:42:23 woglinde: hey again Oct 15 20:42:25 e.g. accidently got an old version Oct 15 20:42:27 latelty the autotools.bbclass dont do it anymore Oct 15 20:42:41 jo zecke Oct 15 20:42:49 I watched golden compass with tobi Oct 15 20:42:52 hi zecke Oct 15 20:43:05 no back to once brothers Oct 15 20:43:13 args now Oct 15 20:44:14 woglinde: golden compass nocole kidman and the new bond guy movie ? Oct 15 20:44:17 woglinde, ah so perhaps the distros (angstrom-2010.x in my case) have not caught up and added the inherit pkgconfig? Oct 15 20:44:25 khem yes Oct 15 20:44:45 tharvey: hrmm angstrom 2010 uses libtool 2.4 Oct 15 20:45:08 khem yes but this have nothing to do with libtool Oct 15 20:45:09 we should rename it angstrom 2011 Oct 15 20:45:16 on one hand it is a good thing that you are using it but on the other hand you can run into some road blocks Oct 15 20:45:30 MACHINE=overo DISTRO=angstrom-2010.x bitbake x11-image - thats what I was using Oct 15 20:45:49 woglinde: right but it was FYI Oct 15 20:46:13 tharvey: yeah x11-image should be buildable with libtool 2.4 I think Oct 15 20:46:25 well... its not apparently Oct 15 20:46:39 all built just a few days (week?) ago :( Oct 15 20:46:59 tharvey: 2010 is not yet hardened Oct 15 20:47:01 my tree is two days behind - pulled on Oct 13 Oct 15 20:47:38 khem, really? grr... I'm not able to find out what 'angstrom' distro people are using - is it 2008.1 then thats more 'stable'? (this is why it kills me that tinderbox just shows 'angstrom') Oct 15 20:48:03 yes 2008.1 should be stable Oct 15 20:48:44 if you use 2010 thats ok too but then you will run into some issues like those and we have to fix them Oct 15 20:48:55 but if you are in absolute hurry then use 2008.1 Oct 15 20:50:12 * tharvey kicks off another 5hour build and sulks Oct 15 20:50:22 5 hr Oct 15 20:50:35 well, I guess 3 hours for just 1 machine type Oct 15 20:50:36 i thought you had a new system Oct 15 20:50:41 ok Oct 15 20:51:13 I do... thats the really depressing part, of course a build for me is console-image and meta-toolchain for two machines Oct 15 20:51:21 an x86 deriv and an OMAP3 deriv Oct 15 20:52:55 oh man... I'm sorry, I 'am' using angstrom-2008.1 on that build I'm having the: failed sanity test (tmpdir) in path issues Oct 15 20:53:31 getting confused with trials across 4 different build systems Oct 15 20:54:37 03Chase Maupin  07org.openembedded.dev * rfb8697d9df 10openembedded.git/classes/ (native.bbclass nativesdk.bbclass sdk.bbclass): Oct 15 20:54:37 Fix class OVERRIDES order Oct 15 20:54:37 * Changed the OVERRIDES settings in the classes to use the new Oct 15 20:54:37 ordering. Oct 15 20:54:37 Signed-off-by: Chase Maupin Oct 15 20:54:37 Acked-by: Chris Larson Oct 15 20:54:37 Signed-off-by: Koen Kooi Oct 15 20:54:39 03Chase Maupin  07org.openembedded.dev * r7f1535cef3 10openembedded.git/conf/distro/include/ (6 files): (log message trimmed) Oct 15 20:54:39 Fix Angstrom OVERRIDES settings Oct 15 20:54:39 * Use the new MACHINE_OVERRIDES variable in angstrom.inc to Oct 15 20:54:40 set the FEED_ARCH and SOC_FAMILY OVERRIDES Oct 15 20:54:40 * NOTE: These were left in their orignal order which will Oct 15 20:54:41 result in the SOC_FAMILY being more specific than Oct 15 20:54:41 the FEED_ARCH. This was done on purpose as the Oct 15 20:55:32 kergoth_: apparently in better_exec, the exec call ( exec(code, _context, context) Oct 15 20:55:32 ) does not seem to return Oct 15 20:55:38 when fed an empty file Oct 15 20:56:17 thats.. odd.. Oct 15 20:56:52 no idea how to further debug this Oct 15 20:57:10 khem, you were telling me you build DISTRO=minimal minimal-image often right? looks like you build for a variety of machines: I'm seeing many failures with that combo on 65ae48d1c7299e300d53e6df6ecac128a10288a0 pulled Oct 13 as well Oct 15 20:57:28 which I kicked off to compare build times with yours Oct 15 20:57:58 eFfeM: can you email that info to me, so i remember to look into it? can't do it right now Oct 15 20:58:19 :kergoth yes Oct 15 21:07:55 For an i7 with 4 cores / 8 threads, what would be a sensible setting for PARALLELL_MAKE/BB_NUMBER_THREADS? Oct 15 21:09:02 kergoth_: mail sent Oct 15 21:09:48 8 Oct 15 21:10:11 tasslehoff, I believe 3 and 5 is what I was told Oct 15 21:11:17 kergoth_: the odd thing is that it seemed to work about a week ago (guess oct 9) and the last commit in the bitbake master is 9 days ago Oct 15 21:11:20 * eFfeM scratches hea Oct 15 21:11:21 head Oct 15 21:12:01 * eFfeM considers nuking tmp and pstage Oct 15 21:12:38 tharvey: I`ll try that then :) Oct 15 21:13:30 kergoth_: btw: is exec a python builtin ? exec(code, _context, context) Oct 15 21:13:59 * eFfeM already found out; googled it Oct 15 21:27:23 I'm thinking my ussue working bblayers is my local.conf is in conf/build Oct 15 21:31:40 Crofton|work, the other day I took a look at the bblayers feature and found that it 'only' looked in conf/build and not conf within BBPATH Oct 15 21:31:52 calling it a day, cya Oct 15 21:32:12 although I still can't figure out what bblayers.conf adds that we didn't have already Oct 15 21:35:56 tharvey: huh? Oct 15 21:36:35 bblayers is just a config file, it's not magic, and it doesn't change how bitbake works. it's just a convenient way to simplify the way bbpath, etc are set Oct 15 21:36:48 it lets us avoid having to set any environment variables at all Oct 15 21:36:55 you can just cd into your build and start building Oct 15 21:37:10 so normally, I set BBPATH in the env Oct 15 21:37:26 and it uses BBPATH to find local.conf Oct 15 21:38:41 bitbake still uses bbpath to find local.conf Oct 15 21:39:11 ok Oct 15 21:39:26 then it ges set again in bblayers Oct 15 21:39:32 this is what I find confusing Oct 15 21:39:35 what do you mean? Oct 15 21:39:39 looking at khems page Oct 15 21:39:40 it doesn't use bbpath to find bblayers.conf Oct 15 21:40:02 bblayers sets BBLAYERS, layer.conf in each layer sets up the BBPATH and BBFILES for that layer Oct 15 21:40:09 and bitbake uses BBPATH and BBFILES as usual after that Oct 15 21:40:18 ok Oct 15 21:40:21 so set layers Oct 15 21:40:22 i normally set the "build" dir part of bbpath in my bblayers.conf, since its not part of a layer Oct 15 21:40:40 ok Oct 15 21:40:48 but I can just set layers there Oct 15 21:40:48 but of course you could certainly do it some other way, its up to you Oct 15 21:41:05 I use a fiel I source to setup stuff Oct 15 21:41:19 so I drop the BBPATH to the oe stuff Oct 15 21:41:27 with this, you shouldn't need to use a sourced file at all, you can point BBLAYERS at all your collections no matter where they are Oct 15 21:41:33 well Oct 15 21:41:38 it sets my path for bitbake Oct 15 21:41:41 or, you could just make it use env vars that you set Oct 15 21:41:47 personally, my .bashrc sets my bitbake path now Oct 15 21:41:56 and i rely on bblayers for everything else Oct 15 21:42:01 but it depends on what you're trying to do, of course Oct 15 21:42:04 yeah Oct 15 21:42:15 you could certainly make bblayers.conf use variables that you set in the environment Oct 15 21:42:23 like, you could set your *base* bbpath, just the path to the build dir, in the env Oct 15 21:42:27 and let each layer add to that Oct 15 21:42:35 ah Oct 15 21:42:42 conf/layers exists :) Oct 15 21:42:42 so that way your bblayers is independent of the build dir Oct 15 21:43:30 personally, i use a single bblayers.conf and local.conf in the same place, with my collections under that, but i also don't need to rapidly switch between builds, i just manually adjust local.conf each time, at least when building oe stuff Oct 15 21:43:48 i'm sure in your case you'd rather have multiple build dirs Oct 15 21:44:27 at any rate, avoid duplicating any information -- do the bare minimum in the environment, and let bblayers and each layer add to your configuration from there Oct 15 21:44:34 yeah Oct 15 21:44:49 it will take me a couple goes to get it right :) Oct 15 21:44:50 maybe i should write something up, with some common use cases Oct 15 21:44:55 and multiple xamples, not just the one i have in github Oct 15 21:45:58 yeah Oct 15 21:46:04 let me work through it Oct 15 21:46:07 kergoth_, right bblayers is just a conf file, so I have always just put the same stuff in my local.conf - not clear how adding another hard-coded conf file helps do anything but add more configuration confusion Oct 15 21:46:10 at least I can start answering questions Oct 15 21:46:16 what do you mean? Oct 15 21:46:26 tharvey: i really don't think you're understanding the purpose of this Oct 15 21:46:31 it isn't a replacement for local.conf Oct 15 21:46:35 from what I saw bitbake did not use bbpath to find it... Oct 15 21:46:40 its a replacement for environment based setup Oct 15 21:46:45 it doesn't, but its not hardcoded either Oct 15 21:46:45 how is it different from collections? Oct 15 21:46:49 it searches *up* the path to / Oct 15 21:47:01 as long as you're somewhere under the dir with conf/bblayers.conf, it'll find it Oct 15 21:47:18 what i really like about collections is its simplicity Oct 15 21:47:23 this is what i argued with RP about Oct 15 21:47:25 kergoth_, not when I tested, perhaps some changes were made. I had it in build/conf/bblayers.conf and build was in my BBPATH Oct 15 21:47:39 no changes were made, you're just doing it wrong Oct 15 21:48:02 as i already told crofton, if you're only using one build dir, you don't need to set BBPATH in your environment *or* bblayers.conf *at all* Oct 15 21:48:10 BBPATH can be mucked with in your local.conf as well, so I still don't see the point Oct 15 21:48:16 what? Oct 15 21:48:18 that's way too late Oct 15 21:48:24 90% of the config files are already parsed by that time Oct 15 21:48:34 are you going to magically go back and re-parse bitbkae.conf? Oct 15 21:48:47 in order for collections to do it, i had to *re-execute* bitbake Oct 15 21:48:49 from within itself Oct 15 21:48:56 fork+exec itself again, to use the new BBPATH Oct 15 21:48:59 its *not* pretty Oct 15 21:49:23 is LAYERDIR a magic variable? Oct 15 21:49:30 ok perhaps my confusion came from this post: http://sakrah.dontexist.org/node/2 Oct 15 21:49:33 all you need to set to use bblayers, assuming your layers have layer.conf files, which oe aleady does, is: BBLAYERS in conf/bblayers.conf Oct 15 21:49:45 that's it. no env vars other than adding bitbake to the path Oct 15 21:49:45 where BBPATH is appended to in various layer conf files Oct 15 21:49:48 yes Oct 15 21:49:52 i don't see how that's confusing Oct 15 21:50:08 OE knows what its layout is, so its in the best position to know how to add itself to bbfiles, etc Oct 15 21:50:18 OE already has one, you don't need to create it.. Oct 15 21:50:20 how does bitbake find conf/bblayers.conf? Oct 15 21:50:27 it searches up from the current path to / Oct 15 21:50:39 so instead of layers.conf I would always just include mylayer/layer.conf from local.conf Oct 15 21:50:48 no Oct 15 21:50:57 once again, once local.conf is parsed, its too late to change bbpath Oct 15 21:51:57 local.conf is included by bitbake.conf, and bitbake.conf is found via bbpath Oct 15 21:52:00 I see... well before I never changed BBPATH and instead set it in my env, so like you say I had 'two' things and yes, I had to touch env. I guess if that post explained that the purpose was to avoid setting anything in env I would have understood Oct 15 21:52:19 the 'only' documentation I found on it was that post and it made it sounds like there was some new magic that wasn't apparent to me Oct 15 21:52:41 yeah, i can see that Oct 15 21:52:51 that post is more beginner level, i'd say Oct 15 21:52:55 "look, you too can have a layer!" Oct 15 21:52:58 perhaps this is a stupid question but you have to set BBPATH in your env 'anyway' so who cares if you have to tweak it for your layers? Oct 15 21:53:01 not "here's how this differs from how you'd do this today" Oct 15 21:53:08 you do NOT have to set BBPATH in your env at all. Oct 15 21:53:12 I mean, you either add it to your env, or you add it to layer.conf - you still have to add it somewhere Oct 15 21:53:32 i really don't see why this is so difficult for you to grasp. Oct 15 21:53:36 OE already has a layer.conf Oct 15 21:53:39 *YOU* aren't adding shit Oct 15 21:54:44 I've always set BBPATH="/foo/org.openembedded.dev"? Oct 15 21:55:01 perhaps the issue is there are a million 'getting started' guides that have you do so that are invalid? Oct 15 21:55:44 sorry for reading 'beginner level' posts - guess I haven't come across the advanced OE documentation yet :P Oct 15 21:56:22 though I consider myself a true noob Oct 15 21:56:53 tharvey: the point is, if you add oe to bblayers, you don't need to add oe to bbpath. its a one time, one variable proposition and its now in your bbpath, bbfiles, etc. the maintainer of the layer maintains the layer.conf to ensure it matches the layout of the layer Oct 15 21:57:10 consider: someone could create a layer with 12 different categorized recipe dirs, and you don't have to care Oct 15 21:57:33 all you have to add to bbpath yourself is your build directory, either via the bblayers.conf or environment, depending on your needs Oct 15 21:58:01 heh, oe docs need a lot of work in all areas, advanced and others :\ Oct 15 21:58:09 ok... thats a pretty good explanation. It should get documented somewhere - I guess in bitbake manual? Oct 15 21:58:19 YES... docs is useless Oct 15 21:58:24 what sucks about the bitbake manual is, its only reference material Oct 15 21:58:26 syntax, etc Oct 15 21:58:36 thats nowhere near sufficient for really using the thing Oct 15 21:58:44 agreed - is so configurable you need to really understand OE not bitbake Oct 15 21:58:50 we need 1) conceptual / architectural docs, 2) tutorials, 3) reference material, 4) debugging Oct 15 21:59:16 (summarized from jeff osier-mixon's presentation on embedded documentation :) Oct 15 21:59:37 the conceptual/architectural I think is what I'm missing constantly... I see examples that make me derive my own opinion on how something works and b/c I dont' understand the underlying details I make wrong assumptions Oct 15 22:00:10 you're not alone in that, i think its the biggest hole in our docs right now Oct 15 22:00:16 people have a really really hard time with the big picture Oct 15 22:00:40 and just reading the source doesn't help unless you understand the whole picture Oct 15 22:00:45 the problem with this is, in addition to the other things, is some people just can't work with a tool without understanding the big picture - its not a bad thing, just some are more concept oriented, others are fine going step by step Oct 15 22:00:57 those folks are likely scared off entirely before they realize how useful the tool is Oct 15 22:00:58 tasslehoff one sensible option is to ship it to me :) Oct 15 22:01:17 (heh, i say "those folks" as though i'm not one of them, which i clearly am) Oct 15 22:01:34 * kergoth_ mulls over ideas for how best to document the concepts Oct 15 22:02:07 at the package/recipe end I felt like I understood OE well and have been workign well in that capacity for a couple of years, just taking a snapshot of OE perhaps every 6 mos. Lately trying to get that stable snapshot has proved a futile effort for me Oct 15 22:02:45 tharvey: what errors do u get Oct 15 22:02:48 I think there are several of you experts all working on key areas right now perhaps colliding with each other and causing constant breakage. The breakage may be fixed in a day or so in one area but then something else breaks in another... its freaking crazy Oct 15 22:02:50 I think testing is really helping to get things stabilized, but i think a release cycle would really add to that -- along with more regular automated builds Oct 15 22:03:18 * khem waves at mickeyl Oct 15 22:03:35 khem, DISTRO=minimal minimal-image MACHINE=overo I was getting u-boot failure, so I'm guessing its a machine specific recent breakage Oct 15 22:04:05 tharvey: yes definitrely Oct 15 22:04:40 so now that I had a stable snapshot for meta-toolchain I have to hunt down recent breakage and fixes for u-boot :( (MACHINE=overo) Oct 15 22:04:52 and pray that meta-toolchain doesn't break by the time I find them Oct 15 22:05:34 i'm planning on adding some actual unit tests for the python code in lib/oe, and move more of the common python bits from the classes into there, which should help that end of the universe stay stable anyway -- won't help the metadata, but there's just so many combinations there only a shitload of builds can confirm stability, no unit test can help Oct 15 22:05:53 there's one class that people probably dont' know about, which is useful for making big changes Oct 15 22:05:56 it's called emit_data Oct 15 22:06:18 it dumps a recipe's metadata to a file, and when you run it a second time, it displays a diff of the two, with things that change all the time excluded (e.g. DATE, TIME) Oct 15 22:06:34 so you can do an emit_data_all of some recipes, make a big change, then do the emit_data_all again Oct 15 22:06:35 and compare Oct 15 22:07:15 tharvey: you are super paranoid dont worry just go for it Oct 15 22:07:23 things break and mend Oct 15 22:07:47 e.g. fixing uboot should be easy Oct 15 22:07:50 no, I'm not paranoid - I do just go for it. I just haven't landed on a stable snapshot in weeks Oct 15 22:07:51 :) Oct 15 22:08:20 tharvey: in such cases best is post errors and leverage the community Oct 15 22:08:21 help Oct 15 22:08:32 I'm 'trying' to help but I can't keep up Oct 15 22:08:38 well, you're clearly not the only one, the testing branch hasn't been tagged due to the recent instabilities. can always stick to the last tag from that until a new one comes along Oct 15 22:08:44 I can't get repeatability Oct 15 22:09:04 yeah thats a good suggestion infact the tags are kept for that purpose Oct 15 22:09:19 good nite Oct 15 22:09:20 tharvey: and you can also join in on the testers club Oct 15 22:09:26 woglinde: gn Oct 15 22:09:28 didn't even know that testing was tagged occasionally Oct 15 22:09:29 also, builds in a chroot are probably a good route, to avoid issues with extra crap installed on the build machine influencing the build Oct 15 22:09:51 tharvey: http://wiki.openembedded.org/index.php/Testing Oct 15 22:09:56 "for all tested combinations, we list the last known-good-build tag so that users can always start with something that will build" Oct 15 22:10:05 kergoth_: yeah minimizing native packages should be the a goal for OE too Oct 15 22:10:40 honestly I welcome something like a 6mo stable cycle - I'm likely not competent enough to contribute to OE other than adding/updating package recipes - the lower levels are a bit beyond my expertise, so what I would kill for is a stable platform to build off of while the lower level internals thrash around in between stable cycles Oct 15 22:11:15 tharvey: a release cycle is on the agenda for oedem, i think -- or should be. khem and i have talked about it in here a few times now Oct 15 22:11:22 would be reall nice to see Oct 15 22:11:32 kergoth_: during git bisect if the given bisect is bad then to go to next bucket I do git bisect bad right ? Oct 15 22:12:02 kergoth_: yeah we should call them summer and winter releases :) Oct 15 22:12:09 ah... I haven't looked at the Testing page in a while... looks like some great progress Oct 15 22:12:31 there are three states for a given commit -- good, bad, and skip -- bad is if it is the problem you're isolating, skip is if its an unrelated problem, and good is if it doesn't have the problem you'er isolating Oct 15 22:13:22 don't see anyone testing any sort of meta-toolchain recipes... and yet I'm unclear what 'native-sdk-image' is. Is that self-hosted toolchain? Oct 15 22:13:24 ah cool Oct 15 22:14:05 wondering if me wanting to use meta-toolchain is lack of understanding something 'better' that exists Oct 15 22:14:12 tharvey: native-sdk-image generates an image with toolchain bits for target Oct 15 22:14:19 skip wasn't around originally, iirc, i was so happy when it showed up -- its so common to hit some other issue blocking you from even knowing if that commit is good or bad wrt the problem you care about Oct 15 22:14:35 so once you install it on target you can do gcc hello.c and it should compile nativey on target Oct 15 22:14:45 tharvey: don't think so, probably just need more testers to volunteer to test meta-toolchain (hint, hint ;) Oct 15 22:14:55 * kergoth_ should start doing testing builds at some point Oct 15 22:15:09 ya, I can certainly start testing branches for meta-toolchain - are users individually editing that wiki? Oct 15 22:15:19 kergoth_: I am going to add a lot more combos to testting soon Oct 15 22:15:30 I want to make it like 10 to 15 machines Oct 15 22:15:34 wow, nice Oct 15 22:15:39 kergoth_, right... I don't see your name there either :) Oct 15 22:15:58 tharvey: depends on resources Oct 15 22:16:04 kergoth may not have Oct 15 22:16:12 most of my machines tend to be tied up in builds of things i have to build for work Oct 15 22:16:18 heh Oct 15 22:16:31 * kergoth_ keeps debating buying a nice dedicated build machine Oct 15 22:16:42 heh most of my machines are busy failing on pulls from the last few days Oct 15 22:16:46 ERROR: Unable to determine endianness for architecture 'INVALID' Oct 15 22:16:48 hmmm Oct 15 22:17:00 I put a machine file in my overlay and said to use it Oct 15 22:17:07 and got this Oct 15 22:17:18 bitbake -e, confirm MACHINE and BBPATH are set the way you think they area Oct 15 22:17:21 s/a$// Oct 15 22:17:45 kergoth_: I have a one liner fix for libtool to fix the -rpath to -L conversion Oct 15 22:17:52 and it works !! Oct 15 22:18:15 now it basically also considers lt_sysroot Oct 15 22:18:20 which is the right thing to do Oct 15 22:19:04 khem: sweet Oct 15 22:19:10 nicely done Oct 15 22:21:37 kergoth_: http://pastebin.com/sHj8sEfG Oct 15 22:22:05 ok Oct 15 22:22:10 slowly Oct 15 22:22:21 how does bibtake find bblayer.conf Oct 15 22:22:23 khem: nice. Oct 15 22:22:34 let's say you're in /foo/bar/baz/ Oct 15 22:22:42 first it checks for /foo/bar/baz/conf/bblayers.conf Oct 15 22:22:47 then it checks for /foo/bar/conf/bblayers.conf Oct 15 22:22:52 then /foo/conf/bblayers.conf Oct 15 22:22:55 then /conf/bblayers.conf Oct 15 22:23:13 but not build/conf Oct 15 22:23:22 bitbake has no knowledge of "build" Oct 15 22:23:30 unless you're cd'd into the build dir Oct 15 22:23:36 right Oct 15 22:23:43 which I just did :) Oct 15 22:23:49 so either bblayers should be in a dir above the build dir, or you should cd into the build dir Oct 15 22:23:51 * kergoth_ nods Oct 15 22:24:09 * khem hugs git Oct 15 22:24:34 it can find a commit in 12 steps btween gcc 4.5 release and current top of tree Oct 15 22:24:38 its amazing Oct 15 22:24:43 nice Oct 15 22:24:48 <3 binary search Oct 15 22:25:25 most annoying part is nfs Oct 15 22:31:47 is some braveheart planning to upgrade python to 2.6.7 Oct 15 22:33:59 ok I moved bblayers.conf and local.conf to ./oe/conf Oct 15 22:34:06 and run bitbake from oe Oct 15 22:34:13 now it can't find MACHINE Oct 15 22:34:28 MACHINE is a var you should set isnt it Oct 15 22:34:44 it set it in local.conf Oct 15 22:34:53 Crofton|work: btw you are using git master of bitbake Oct 15 22:35:01 where are you adding the oe dir to your BBPATH? in the env, or bblayers.conf? Oct 15 22:35:03 1.10 Oct 15 22:35:13 bblayers.conf Oct 15 22:35:15 well better use master Oct 15 22:35:19 heh Oct 15 22:35:21 check -e, makes ure its there Oct 15 22:35:30 it should work with 1.10, as far as i know Oct 15 22:35:40 yes it should Oct 15 22:35:53 ok Oct 15 22:36:00 added the oe dir Oct 15 22:36:22 ok, so local.conf is found using BBPATH from bblayers Oct 15 22:36:28 yes Oct 15 22:36:53 and you can put a layer.conf in earch layer/conf dir Oct 15 22:37:00 yeah Oct 15 22:37:02 I ahve that Oct 15 22:38:08 Crofton|work: what does your bblayer.conf look like Oct 15 22:38:21 I think I have it goign now Oct 15 22:38:23 local.conf is found from BBPATH, period Oct 15 22:38:42 yes, but I set it in bblayers Oct 15 22:38:43 each layer only generally adds itself, not your build dir, so someone still has to add the dir where conf/local.conf lives Oct 15 22:38:49 overwrting whatever is in env Oct 15 22:38:57 ah Oct 15 22:39:02 kergoth_: right I have my BBPATH set in conf/bblayers.conf which is parallel to openembedded dir Oct 15 22:39:46 yeah, i set my BBPATH in bblayers.conf to ${TOPDIR}, and hard set TOPDIR to the dir where both openembedded and conf/bblayers.conf live Oct 15 22:40:00 this is why oe is so damn confusing. we try to be so flexible, but end up *too* flexible Oct 15 22:40:02 right Oct 15 22:40:03 too many ways to do.. everything Oct 15 22:40:16 heh right Oct 15 22:40:43 TOPDIR := "${@os.path.dirname(os.path.dirname(d.getVar('FILE', True)))}" Oct 15 22:40:50 BBPATH = "${TOPDIR}" Oct 15 22:40:57 BBLAYERS = "${TOPDIR}/openembedded ${TOPDIR}/layers" Oct 15 22:41:06 hmm Oct 15 22:41:06 thats what I have in bblayers.conf Oct 15 22:41:22 wonder if itd be useful to support globs in bblayers :) Oct 15 22:41:29 BBLAYERS = "${TOPDIR}/layers/*/" Oct 15 22:41:32 the ultimate in laziness Oct 15 22:41:48 :) Oct 15 22:41:52 hah I am happy by specifying each one Oct 15 22:42:10 space separated Oct 15 22:42:11 thats the nice thing about being explicit rather than implicit Oct 15 22:42:14 much less likely to be surprised Oct 15 22:42:28 yes and I hardly change that file Oct 15 22:42:37 so its wasted effort to make it more cryptic Oct 15 22:42:41 * kergoth_ nods Oct 15 22:42:58 i still like COLLECTIONS in some ways more than the new stuff Oct 15 22:43:08 having *one* var that controlled everything, even collection priority, was nice Oct 15 22:43:16 now the layer.conf stuff is rather boilerplate, copy/pasted from layer to layer Oct 15 22:46:46 next problem .. Oct 15 22:46:59 I have a kernel recipe in my layer Oct 15 22:47:10 and it uses linux.inc Oct 15 22:47:19 but it can't find it Oct 15 22:47:30 ERROR: Could not include required file linux.inc while parsing /home/balister/oe/ettus-oe/recipes/linux/linux-usrp-embedded_git.bb Oct 15 22:48:42 what is weird is the machine also includes a file from openembeddded, and that is ok Oct 15 22:49:29 it won't find it. Oct 15 22:49:37 unless linux.inc is also in that same dir Oct 15 22:49:43 hmm Oct 15 22:49:46 otherwise you probably want it to include recipes/linux/linux.inc Oct 15 22:49:52 but it does in the machine dir? Oct 15 22:49:52 so it finds it via BBPATH that way Oct 15 22:50:01 not sure what you mean by that Oct 15 22:50:18 I have a file in my layer that is the machine definition Oct 15 22:50:38 and it includes omap3.inc from the oe layer Oct 15 22:50:45 just 'omap3.inc'? Oct 15 22:50:50 or more likely, conf/whatever/? Oct 15 22:51:02 require conf/machine/include/omap3.inc Oct 15 22:51:05 remember, include/require use BBPATH too Oct 15 22:51:08 so yes, that'll work fine Oct 15 22:51:16 that's the correct path from the root of the path in bbpath Oct 15 22:51:30 got it Oct 15 22:51:32 there is no 'linux.inc' in the root of any of hte dirs in bbpath, so that wont work Oct 15 22:51:52 (the dir where the including file is is a special case, bbpath is adjusted to include it -- but that doesn't include the corresponding location in the other layers..) Oct 15 22:52:23 hmm Oct 15 22:52:37 I wonder if we should worry about that in the oe metadata Oct 15 22:52:57 it wouldn't hurt to change to the fuller paths, but you'd have to change them if you reorganize the repository, woudl be the only downside Oct 15 22:53:12 not that we reorg very often :) Oct 15 22:53:19 just something to keep in mind Oct 15 22:53:49 of course, it could be considered a good thing. if a kernel includes recipes/linux/linux.inc, then that recipe can be moved outside of recipes/linux/ without having to change the recipe Oct 15 22:53:57 * kergoth_ shrugs :) Oct 15 22:55:37 right Oct 15 22:55:47 whish is what just happened to me Oct 15 22:56:19 i expect including the full path is probably a good idea when you don't "own" the .inc Oct 15 22:56:26 e.g. nano including 'nano.inc' is probably fine Oct 15 22:56:35 kernel foo including linux.inc, probably better off using recipes/linux/ Oct 15 23:01:32 ok Oct 15 23:01:46 I think I get most of what I need to get started Oct 15 23:02:15 * kergoth_ still rather dislikes the bblayers way of doing things, but sees it as an improvement over the old way at least Oct 15 23:03:25 yes, a lot less mucking with config files Oct 15 23:05:05 so still getting a lot of QA issues with DISTRO=angstrom-2008.1 MACHINE=overo - inherit pkgconfig as suggested previously caused worse issues (KeyError msgs stalling bitbake): ERROR: QA Issue with staging: mathview-frontend-libxml2.pc failed sanity test (tmpdir) in path /home/tharvey/oe//tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/pkgconfig Oct 15 23:42:58 03Khem Raj  07master * rb10441991f 10openembedded.git/recipes/gcc/gcc-package-cross.inc: Oct 15 23:42:58 gcc-package-cross.inc: Edit the libdir enties in libstdc++.la and libsupc++.la Oct 15 23:42:58 We manually move libstdc++ to staging sysroot from default install Oct 15 23:42:58 location where gcc-cross installed it. During this process we have Oct 15 23:42:58 to make sure that .la files are edited to contain proper libdir Oct 15 23:42:59 entry pointing relative to sysroot. Oct 15 23:43:00 Signed-off-by: Khem Raj Oct 15 23:43:09 03Khem Raj  07master * rdf2f9a5553 10openembedded.git/recipes/gcc/gcc-cross-intermediate.inc: Oct 15 23:43:09 gcc-cross-intermediate.inc: Move libgcc from cross dir to target sysroot Oct 15 23:43:09 shared version of libgcc is also installed by gcc-cross-intermediate Oct 15 23:43:09 which we did not move to staging as a result cross gcc found this libgcc Oct 15 23:43:09 and used it compailing about missing libc.so stuff. Oct 15 23:43:10 Signed-off-by: Khem Raj Oct 15 23:43:11 03Khem Raj  07master * r3740dea7ec 10openembedded.git/recipes/libtool/ (9 files in 2 dirs): Oct 15 23:43:11 libtool-2.4: Append lt_sysroot to libdir Oct 15 23:43:12 Remove cross.patch which is not needed now. Oct 15 23:43:12 Fix PR setting. Oct 15 23:43:13 Signed-off-by: Khem Raj Oct 15 23:43:27 Crofton|work: I have pushed my changes w.r.t libtool 2.4 and gcc/libstc++ please do a clean build and see if it fixes your gnuradio build issue Oct 15 23:43:31 k Oct 15 23:43:44 Crofton|work: and then you can push your gnuradio rework Oct 15 23:43:56 yes Oct 15 23:44:29 I did a bitbake gnuradio it came close enough and failed in QA errors Oct 15 23:44:44 urg Oct 15 23:44:45 the reason was the included libusb was adding paths into workdir Oct 15 23:44:48 clean build Oct 15 23:44:48 into .la files Oct 15 23:44:56 yes clean builld plz Oct 15 23:45:07 ah Oct 15 23:45:11 oh well you can also do a non clean one Oct 15 23:45:18 I'll do clean Oct 15 23:45:25 I need to quit working soon Oct 15 23:45:36 yeah so let it bake stuff Oct 15 23:45:45 for tomorrow :) Oct 15 23:48:03 right Oct 16 00:06:12 ok Oct 16 00:06:14 it is running Oct 16 00:22:46 stupid git user question: to checkout a tag is it not just 'git checkout testing_2010-10-08'? Oct 16 00:23:56 That works, but causes compliants Oct 16 00:24:12 you should do git checkout -b local-testing_... testing_... Oct 16 00:24:42 that makes it not a detached head right? Oct 16 00:27:42 Right Oct 16 00:27:51 detached heads aren't fatal Oct 16 00:27:59 It just means hey, don't do any dev Oct 16 00:28:08 right... ok thx Oct 16 00:28:26 * tharvey kicks off 3 weekend builds, crosses his fingers and runs home to the kids - good weekend all Oct 16 00:37:02 you can do dev on a detached head, just there's no way to get back to it after checking something else out later, other than looking through reflog :) **** ENDING LOGGING AT Sat Oct 16 02:59:58 2010