**** BEGIN LOGGING AT Fri Nov 12 02:59:57 2010 Nov 12 03:16:10 03Tom Rini  07org.openembedded.dev * rc1c7ff8f44 10openembedded.git/recipes/console-tools/console-tools_0.3.2.bb: Nov 12 03:16:10 console-tools: Add fgconsole to u-a Nov 12 03:16:10 Signed-off-by: Tom Rini Nov 12 03:16:14 03Tom Rini  07org.openembedded.dev * r13fbe7253c 10openembedded.git/recipes/bind/bind_9.3.6.bb: Nov 12 03:16:14 bind 9.3.6: Drop nslookup Nov 12 03:16:14 All other versions have been removing this, so sync up. Nov 12 03:16:14 Signed-off-by: Tom Rini Nov 12 03:16:17 03Tom Rini  07org.openembedded.dev * r8e9b64410d 10openembedded.git/recipes/ifupdown/ (ifupdown-ubuntu_0.6.8.bb ifupdown_0.6.10.bb): Nov 12 03:16:17 ifupdown: Add update-alternatives Nov 12 03:16:17 Signed-off-by: Tom Rini Nov 12 03:16:18 03Tom Rini  07org.openembedded.dev * r14c2ce14d5 10openembedded.git/recipes/bc/bc_1.06.bb: Nov 12 03:16:18 bc: Use u-a on 'dc' Nov 12 03:16:18 Signed-off-by: Tom Rini Nov 12 03:16:27 03Tom Rini  07org.openembedded.dev * r902b98f32f 10openembedded.git/recipes/unzip/unzip_552.bb: Nov 12 03:16:27 unzip: Add update-alternatives to unzip Nov 12 03:16:27 Signed-off-by: Tom Rini Nov 12 03:16:29 03Tom Rini  07org.openembedded.dev * rc711c4c655 10openembedded.git/recipes/realpath/ (realpath_1.10.bb realpath_1.15.bb): Nov 12 03:16:29 realpath: Add update-alternatives Nov 12 03:16:29 Signed-off-by: Tom Rini Nov 12 03:16:30 03Tom Rini  07org.openembedded.dev * r899c44c3fc 10openembedded.git/recipes/start-stop-daemon/start-stop-daemon_1.9.18.bb: Nov 12 03:16:30 start-stop-daemon: Add update-alternatives Nov 12 03:16:30 Signed-off-by: Tom Rini Nov 12 03:17:29 Tartarus: heh, working on proper-tools? Nov 12 03:17:35 native-sdk-image :) Nov 12 03:18:01 * kergoth nods Nov 12 03:27:35 so Nov 12 03:27:39 I need some help Nov 12 03:27:48 parts of build need gcc Nov 12 03:27:57 but gcc doesn't exist for some reason Nov 12 03:28:02 so install it. Nov 12 03:28:15 oe builds native tools, it won't work without a functional development environment on your build machine Nov 12 03:28:16 no as in cross compile type Nov 12 03:28:23 well, it builds that itself, when necessary Nov 12 03:28:38 sysdeps/unix/make-syscalls.sh: line 84: arm-angstrom-linux-gnueabi-gcc: command not found Nov 12 03:28:43 thats glibc building Nov 12 03:30:13 aditya@aditya-buildpc:~/oe-dev/openembedded/tmp/sysroots/i686-linux/usr/armv7a/bin Nov 12 03:30:20 has a bunch of tools Nov 12 03:30:22 but no gcc Nov 12 03:30:33 would think glibc would trigger something that builds gcc? Nov 12 03:30:37 it does. Nov 12 03:30:49 you must be doing something wrong, or using an unsupported distro or something Nov 12 03:30:58 pssh Nov 12 03:31:07 just doing oe-dev under ubuntu Nov 12 03:31:28 first time I've had this problem ... tried building ti-dsplink Nov 12 03:32:38 * kergoth builds oe-dev under ubuntu every day Nov 12 03:33:17 I know Nov 12 03:33:21 I am not blaming anyone Nov 12 03:33:26 was just looking for some guidance Nov 12 03:33:30 as to possible troubleshooting Nov 12 03:33:54 maybe I can just call gcc by itself Nov 12 03:34:57 the crosscompiler build process is nontrivial, with multiple steps. 2+ glibc builds and 2+ gcc builds Nov 12 03:35:04 you could try building them one by one Nov 12 03:36:04 hmm Nov 12 03:37:06 would you know what the recipe is of the top of yer head? Nov 12 03:37:09 for cross-gcc that s Nov 12 03:37:32 look in recipes/gcc/. Nov 12 03:37:56 there's -initial and -intermediate for parts 1 and 2, then the regular, for glibc and gcc-cross Nov 12 03:38:15 yeah the build went through gcc-initial and gcc-intermediate Nov 12 03:38:23 dont see any errors hmmm Nov 12 03:38:58 if gcc-intermediate was built, the compiler should be in sysroots. do a find of tmp/sysroots for the cross gcc binary Nov 12 03:39:39 yeah did that, it puts gcc in a lot of different places Nov 12 03:39:42 just not in the ... right one Nov 12 03:40:08 http://pastebin.com/smTnzuFi Nov 12 03:40:38 I mean I could put one of those in my path, but I'd rather figure out what's borken Nov 12 03:52:45 aditya_10101: i assume other recipes build fine? nano, whatever? Nov 12 03:56:15 yeah Nov 12 03:56:21 I have x11-image built fine Nov 12 03:56:28 using it right now on my XM Nov 12 03:56:40 just wanted to move away from compiling my own DSPlink to using w/e OE has Nov 12 03:56:50 so tried compiling ti-dsplink Nov 12 04:04:59 well copying the gcc from those other directories did not help Nov 12 04:05:01 bleh Nov 12 05:06:08 aditya_10101: it could be try to rebuild just gcc-cross-* Nov 12 05:06:21 aditya_10101: you need to rebuild the whole toolchain deps Nov 12 05:06:24 try this Nov 12 05:07:01 btibake -c clean gcc-cross gcc-cross-intermediate gcc-cross-initial eglibc eglibc-initial glibc glibc-initial; bitbake gcc-cross Nov 12 05:07:10 and now you should have a good cross compiler Nov 12 05:08:08 kergoth: Is there a way to say unstage/clean another recipe B if recipe A is to be rebuilt Nov 12 05:08:39 not as far as i know Nov 12 05:08:54 kergoth: I was lookin at OBS Nov 12 05:09:01 and they have a cool feature that we dont Nov 12 05:09:10 they rebuild all dependencies Nov 12 05:09:50 say if libc has changed then everything that depends on glibc will be rebuilt Nov 12 05:09:55 kind of cool I think Nov 12 05:10:26 kergoth: what are some cool features of OE in your eyes Nov 12 05:11:53 khem: thanks, gonna try that Nov 12 05:12:25 * khem needs to write an OE praise Nov 12 05:12:39 khem: well, there is the stamp policy where if B depends on A and A's stamps change, B's stamps are invalidated, and it'll be rebuilt Nov 12 05:12:44 but i'm not sure if thats sufficient. Nov 12 05:13:19 kergoth: is it controlled by BB_STAMP_POLICY ? Nov 12 05:13:22 yep Nov 12 05:13:28 ah hmm Nov 12 05:13:51 i've also created a more explicit version of that in the past, where you'd set an abi version variable, and when that changed, anything that depended on it would get rebuilt Nov 12 05:13:53 what should it be set to Nov 12 05:14:01 but that never went into oe Nov 12 05:14:11 it was entirely in the metadata Nov 12 05:16:22 hmm thats nice too but I think if we know the dep graph and would be cool if we could figure out rebuild stuff automagically Nov 12 05:16:26 wud be nice to have Nov 12 05:18:00 yes it would be, would have saved my bacon many times while mucking around with recipes Nov 12 05:21:08 90% of the time rebuilding A if B changes and A deps on B is unnecessary, but build times aren't exactly huge for individual recipes, and better safe than sorry Nov 12 05:21:14 i think e2factory always rebuilds too Nov 12 05:23:08 kergoth: I agree but its always better to rebuild if you can Nov 12 05:26:37 * kergoth nods, better to take a cautious approach Nov 12 05:33:21 who admins http://www.linuxtogo.org/ Nov 12 05:34:35 http://planet.linuxtogo.org/ Nov 12 05:34:42 seems to be AWOL Nov 12 05:34:43 Faure Gnassingbé? Nov 12 05:34:50 http://en.wikipedia.org/wiki/Togo Nov 12 05:34:59 * mrj101 is sorry, but he couldn't resist Nov 12 06:35:36 mmm Friday Nov 12 08:21:45 good morning Nov 12 08:46:45 morning Nov 12 09:55:35 oh.. new testing already Nov 12 10:11:02 03Dmitry Eremin-Solenikov  07master * rd377aa1bc5 10openembedded.git/recipes/gdb/gdb-cross-sdk.inc: Nov 12 10:11:02 gdb-cross-sdk: really fix gdb-cross-sdk building in non-sim-enabled case Nov 12 10:11:02 Signed-off-by: Dmitry Eremin-Solenikov Nov 12 10:11:04 03Dmitry Eremin-Solenikov  07master * r5362cf07de 10openembedded.git/contrib/angstrom/sort.sh: Nov 12 10:11:04 angstrom feed sorter: replace find + grep with just find Nov 12 10:11:04 This removes any requirements for the order of archiectures to be Nov 12 10:11:04 sorted. Nov 12 10:11:04 Signed-off-by: Dmitry Eremin-Solenikov Nov 12 11:06:17 is it possible to just supply pre-generated locales for all supported arch'es? Nov 12 11:06:37 * Jay7 is looking on locale generation by qemu-arm.. Nov 12 13:33:06 Question: what do to If I get message that there is wrong identation in script. Nov 12 13:33:14 I mean in task Nov 12 13:33:35 Can we mix Python tasks with Bash code? Nov 12 13:52:23 Depends on how you do it, yes Nov 12 14:02:04 davidlt: nope, you can't append python to shell or vice versa in a bitbake function, bitbake isn't smart about it yet. ideally, it'd maintain an internal list of functions for those cases, and run the chunks independently where appropriate. and yes, when appending python to python, you have to use the same indentation as what you're appending to, also annoying, and also would be fixed by what i mentioned :| Nov 12 14:03:06 But you can have both in the same file, yes? Nov 12 14:03:39 It looks like I have both. Nov 12 14:03:57 Use pastebin and let us see what you're up to? Nov 12 14:04:02 I can append anything to do_populate_staging, but I can to others Nov 12 14:04:26 Can't do that right now, I am on different machine Nov 12 14:05:27 I just remembered that I had some files I wanted to stage, wanted to added few lines to copy files, but couldn't Nov 12 14:08:26 Tartarus: what do you mean? the problem is with appending/prepending to functions, whether things are in separate files is irrelevant Nov 12 14:08:40 davidlt: you shouldn't be touching populate_staging or populate_sysroot, ever. Nov 12 14:08:53 davidlt: if you're legacy, you should be usng do_stage. if you're not legacy staging, you should be using do_install. Nov 12 14:09:36 kergoth: His first question was can you mix python and bash. Now we have python funcs and bash funcs in the same file in some cases Nov 12 14:10:02 I am working with mid-April version of OE Nov 12 14:10:20 davidlt: doesn't matter. Nov 12 14:10:28 even then you should be using do_stage to stage Nov 12 14:10:41 Ok, thanks Nov 12 15:32:41 trying to install oe again for beagleboard Nov 12 15:33:00 following this tutorial: http://www.angstrom-distribution.org/building-angstrom Nov 12 15:33:22 when i try to setup the installation (sh oebb config beagleboard) Nov 12 15:33:35 it says "sh cannot be opened" Nov 12 15:33:51 any help would bve appreciated Nov 12 15:33:53 cbrake: ping Nov 12 15:34:15 alkopop79: what kind of machine are you trying this on? Nov 12 15:34:21 alkopop79: Try #angstrom Nov 12 15:34:52 ubuntu on mac os x (virtualbox) Nov 12 15:35:10 ubuntu should have /bin/sh? Nov 12 15:36:13 since i just installed ubuntu Nov 12 15:36:29 and have not updated yet Nov 12 15:36:42 probably that's causing the pain Nov 12 15:37:07 thx tartarus Nov 12 15:37:11 will try Nov 12 15:40:18 Crofton|road: yes Nov 12 15:47:25 cbrake: I couldn't push yesterday Nov 12 15:47:35 ka6sox said there might be a gitsosis issue Nov 12 15:47:41 but he has no access Nov 12 15:49:35 Crofton|road: checking Nov 12 15:50:35 Crofton|road: there is a gitosis issue, but it only affects new users Nov 12 15:50:42 Crofton|road: your key looks fine on the server Nov 12 15:51:02 Crofton|road: I was able to push last night. Can you try again? Nov 12 15:51:22 I'll poke around more later Nov 12 15:51:33 I am on west coast, not at work yet Nov 12 15:54:00 morning Nov 12 16:11:45 hi ka6sox Nov 12 16:15:25 morning florian Nov 12 16:54:33 heyo. my bitebake virtual/kernel failes at glibc. http://pastebin.com/L1sGvxKs - any ideas? Nov 12 16:59:11 hi, the supertux-qvga recipe has a configure issue that I'm trying to fix Nov 12 16:59:25 while I was trying to fix I looked in the supertux-qvga recipe and found: Nov 12 16:59:35 require supertux_${PV}.bb Nov 12 16:59:48 without any inc.PR Nov 12 16:59:58 here's are my options: Nov 12 17:00:00 strange, I can't see a patch posted to maillist for http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?id=4dbe8edc6375b1856dd512349c58d936e4ab446b - I suppose people with commit access can commit without review? Nov 12 17:00:19 *add inc-pr to supertux-qvga_0.1.3 Nov 12 17:00:30 *transform supertux_0.1.3 in an inc Nov 12 17:00:56 I believe the do_install_append in that patch should install vimrc from WORKDIR Nov 12 17:00:58 tharvey, they can but the fact that they should or not depend on how core is it Nov 12 17:01:30 indeed Nov 12 17:02:12 does Philip hang out here? Nov 12 17:02:35 tharvey, maybe ask in the mailing list? Nov 12 17:02:42 because if he's not there.... Nov 12 17:02:46 you would wait very long Nov 12 17:02:57 I'll post a patch to the maillist Nov 12 17:03:14 ok good idea Nov 12 17:10:21 morning Nov 12 17:10:30 tharvey: yes some easy patches go in like that Nov 12 17:10:35 kergoth: gm Nov 12 17:14:44 hi khem I've to fix supertux-qvga and then I'll look at libsdl again if time permits it Nov 12 17:15:28 hmmmmmmm what to do.. Nov 12 17:17:14 kergoth, about what? Nov 12 17:17:33 in general :) Nov 12 17:17:35 GNUtoo|laptop: cool Nov 12 17:17:54 btw will there be a game bblayer? Nov 12 17:17:58 kergoth_: think about refactoring metadata into layers Nov 12 17:18:06 khem: meh Nov 12 17:18:13 i don't know if i'm up to that at the moment :) Nov 12 17:18:15 * kergoth_ ponders Nov 12 17:18:17 kergoth_: immediately after release we should try to break it apart Nov 12 17:18:31 because I'm often lost in the tons of oe metadata while looking for cool games to show on my target devices Nov 12 17:18:42 GNUtoo|laptop: don't see any reason why not Nov 12 17:18:45 ok Nov 12 17:18:45 GNUtoo|laptop: would make sense Nov 12 17:18:48 kergoth: the we need that override issue fixed too Nov 12 17:18:57 btw about layers, how would PR be handleds? Nov 12 17:19:02 khem: guh, that one is so ugly Nov 12 17:19:10 because PR can't go backward Nov 12 17:19:27 else you need to bump PE Nov 12 17:19:38 GNUtoo|laptop: the case where a given recipe is in multiple official layers is likely to be quite rare. Nov 12 17:19:43 ok Nov 12 17:19:52 and in those cases, they should be using bbappend/amend.inc, imo, and use PR .= ".1" or whatever in the modification Nov 12 17:19:52 that's what was mentioned in the thread too Nov 12 17:19:58 ok Nov 12 17:20:03 nice Nov 12 17:21:17 khem: I've been giving more thought to sharing source trees / srctree / etc lately, and i was thinking that a first step could be to, for any recipe that supports it, unpack/patch into a cache outside of WORKDIR, perhaps even outside of TMPDIR Nov 12 17:21:48 for recipes that support ${B}, that is Nov 12 17:22:47 anyone have any thoughts on this Nov 12 17:22:48 http://pastebin.com/47uKMGKC Nov 12 17:22:57 built with angstrom-2010 Nov 12 17:24:19 damnit, did I send anyone a copy of newcollection.inc while i was at MV? I know I talked about it, and i could have sworn it went upstream, but it seems it did not Nov 12 17:24:22 hrmph Nov 12 17:24:30 not that it was that terribly complex, but still Nov 12 17:28:58 | configure.in:8: version mismatch. This is Automake 1.7.9, Nov 12 17:28:59 | configure.in:8: but the definition used by this AM_INIT_AUTOMAKE Nov 12 17:28:59 | configure.in:8: comes from Automake 1.11.1. You should recreate Nov 12 17:28:59 | configure.in:8: aclocal.m4 with aclocal and run automake again. Nov 12 17:29:00 nag Nov 12 17:29:05 is this an easy fix? Nov 12 17:30:16 recipe overrides do_configure .. Nov 12 17:32:49 Crofton: I think I fixed it Nov 12 17:32:53 some time ago Nov 12 17:35:57 Crofton: call gnu-configize before libtoolize Nov 12 17:39:27 03Tim Harvey  07master * rb2e8382c20 10openembedded.git/recipes/vim/vim_7.2.bb: Nov 12 17:39:27 vim: fix do_install for those using FILESPATH* overrides Nov 12 17:39:27 WORKDIR should be used for the source directory of vimrc. This fixes breakage Nov 12 17:39:27 for those using FILESPATHBASE/FILESPATHPKG/FILESPATH overrides Nov 12 17:39:27 Signed-off-by: Tim Harvey Nov 12 17:39:27 Signed-off-by: Khem Raj Nov 12 17:39:44 Hmmm... I am building modphp and on do_configure I have yes running with 100% CPU, pretty much stuck Nov 12 17:40:19 khem, thx Nov 12 17:43:50 Yeah, something went wrong... Nov 12 17:45:26 davidlt, inspect the logs Nov 12 17:46:31 03Chris Larson  07master * refeaa588b5 10openembedded.git/classes/newcollection.bbclass: Nov 12 17:46:31 newcollection.bbclass: add, courtesy MontaVista Software, Inc. Nov 12 17:46:31 Signed-off-by: Chris Larson Nov 12 17:46:47 Got out of space, log -> 25G Nov 12 17:47:01 khem: this might prove useful for trimming down while splitting Nov 12 17:48:21 It's some checks from configure file and always "command not found" Nov 12 17:48:32 After that, bunch of "y" Nov 12 17:48:37 I am missing something probably Nov 12 17:48:39 INHERIT += "newcollection"; NEWCOLLECTION = "${TOPDIR}/stuff"; bitbake -c newcollection_all gcc-cross Nov 12 17:48:47 * kergoth_ tests to make sure it still works Nov 12 17:50:44 khem, is the fix pushed? Nov 12 17:54:44 Darn, probably it requires earlier version of autoconf Nov 12 17:55:12 khem, no luc Nov 12 17:55:35 damnit, being bitten in the ass by configure/compile tasks modifying files in ${S} (as opposed to ${B}). wonder how best to resolve that Nov 12 17:57:16 hmm, idea, there could be a PREPTASKS or PREPAREFUNCS or somesuch, any functions listed there are run to prepare the workdir / source tree, and part of the prep is fetch/unpack (either we keep the tasks as is and have unpack run the prepare funcs, or add a prepare task after unpack and fetch, or have fetch/unpack as PREPAREFUNCS Nov 12 17:57:22 * kergoth_ ponders Nov 12 17:59:37 hmm Nov 12 17:59:41 I can push from home Nov 12 18:00:16 hopefully those commits I forgot to push are ok :) Nov 12 18:00:17 §quit Nov 12 18:00:24 * Crofton waits for cia Nov 12 18:00:26 oops :) Nov 12 18:00:54 03Philip Balister  07org.openembedded.dev * r7d71b69aad 10openembedded.git/recipes/uhd/uhd.inc: uhd : Add git-native to DEPENDS. Needed to check the repo version. Nov 12 18:00:54 03Philip Balister  07org.openembedded.dev * rf2744e7e75 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev Nov 12 18:01:16 wew Nov 12 18:01:43 heh Nov 12 18:02:44 heh Nov 12 18:02:48 my brain is going Nov 12 18:03:01 03Philip Balister  07org.openembedded.dev * r752733779a 10openembedded.git/: Merge branch 'org.openembedded.dev' of git://git.openembedded.net/openembedded into org.openembedded.dev Nov 12 18:03:09 my commit problem was I was commiting from somehting I checked out via http :) Nov 12 18:03:14 fixed :) Nov 12 18:03:23 i wonder if it would be worthwhile to write some code to scan a SRC_URI and determine which of the urls feed into S{S}, vs WORKDIR bits Nov 12 18:03:35 03Philip Balister  07org.openembedded.dev * r4138991b3d 10openembedded.git/recipes/images/ossie-image.bb: ossie-image : Obsolete image. Nov 12 18:03:39 Crofton: heh, you know you can set a different push url than pull url, if you want anonymous read but ssh write Nov 12 18:03:59 03Philip Balister  07org.openembedded.dev * r2b98a07adb 10openembedded.git/recipes/tasks/task-sdk-gnuradio-native.bb: task-sdk-gnuradio-native.bb : Add python-xml so gnuradio make check runs. Nov 12 18:04:01 I'll push a supertux/supertux-qvga fix Nov 12 18:04:14 03Philip Balister  07org.openembedded.dev * r86925741fc 10openembedded.git/recipes/ifupdown/ (ifupdown-0.6.10/init ifupdown_0.6.10.bb): Nov 12 18:04:14 ifupdown : Fix path to ifstate file. Nov 12 18:04:14 Fix reported to gumstix list by Mike Stock. Nov 12 18:04:24 no, but maybe I will worry about it sometime Nov 12 18:04:26 thanks Nov 12 18:04:38 03Philip Balister  07org.openembedded.dev * r07105d2c3d 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev Nov 12 18:04:43 that ifupdown thing had been driving me crazy Nov 12 18:04:44 nice!!! thanks Philip Balister for the fix for ifupdown Nov 12 18:05:01 I just committed Nov 12 18:05:13 based email from sakoman_ copied form gumstix Nov 12 18:05:19 I know Nov 12 18:05:26 I read that mail and planed to test it Nov 12 18:05:26 :) Nov 12 18:05:33 jsut want to make sure everyone knows Nov 12 18:05:42 that had been biting me hard Nov 12 18:05:50 me too Nov 12 18:05:54 for the bug device Nov 12 18:06:57 thanks Crofton! Nov 12 18:07:03 thank you Nov 12 18:07:15 sakoman_, you need commit access :) Nov 12 18:07:26 * kergoth_ is surprised sakoman_ doesn't have it Nov 12 18:07:36 I could cause a lot of damage if I did :-) Nov 12 18:07:45 no worse than the rest of us Nov 12 18:07:52 heh, thats what i was going to say Nov 12 18:07:54 damage? why? Nov 12 18:07:58 anyone working on mplayer recipe update? Nov 12 18:08:13 for new recipes is it recommended now to put localfiles in a subdir named same as PN or still named 'files'? Nov 12 18:08:27 GNUtoo|laptop: I could screw up all OE users rather than just Gumstix :-) Nov 12 18:08:59 sakoman_, I mean do you do something special for doing damages, such as beeing too tired, commiting when drunk or something similar? Nov 12 18:09:06 tharvey: same as pn nowadays Nov 12 18:09:09 03Denis 'GNUtoo' Carikli  07org.openembedded.dev * r9a97090b98 10openembedded.git/recipes/supertux/ (supertux-qvga_0.1.3.bb supertux.inc supertux_0.1.3.bb): (log message trimmed) Nov 12 18:09:09 supertux/supertux-qvga : migrate to inc file, and fix supertux-qvga configure Nov 12 18:09:09 supertux_0.1.3 and supertux-qvga_0.1.3 were doing that: Nov 12 18:09:09 supertux_0.1.3: PR = "r6" Nov 12 18:09:09 supertux-qvga_0.1.3: require supertux_${PV}.bb Nov 12 18:09:10 And supertux-qvga didn't redefine PR Nov 12 18:09:11 So I had to convert move supertux_0.1.3 to supertux.inc Nov 12 18:09:18 sakoman_, because else I don't see why you could do damages Nov 12 18:09:21 ok Nov 12 18:09:25 sakoman_: nah, just regular supidity :-) Nov 12 18:09:29 we all break shit from time to time, it happens Nov 12 18:09:36 ok Nov 12 18:09:41 so there is no issues I bet Nov 12 18:09:57 sakoman_, that can be fixed, create a checklist Nov 12 18:10:04 and read the checklist before commiting Nov 12 18:10:06 such as: Nov 12 18:10:08 bump PR Nov 12 18:10:30 the command you need for pushing(so no mistakes) Nov 12 18:10:33 etc... Nov 12 18:10:46 yeah I know :-) Nov 12 18:11:00 I had that at the beginning Nov 12 18:11:09 now I only need the push command Nov 12 18:11:15 I push to other git repos dozens of times per day Nov 12 18:11:28 (because I've too many repos) Nov 12 18:11:38 ok Nov 12 18:11:44 and do you do a lot of damages? Nov 12 18:12:11 no Nov 12 18:12:23 so why would you do a lot of damages for oe Nov 12 18:12:25 hooks can help for that too. could easily write a pre-push hook to check for recipe changes without PR bump Nov 12 18:12:33 though it woudln't be full proof, due to .inc vs .bb, etc Nov 12 18:12:33 ok Nov 12 18:12:37 but still might be worth doing Nov 12 18:12:51 JaMa|Off, supertux-qvga fixed Nov 12 18:13:00 pre-commit hook might be better, actually Nov 12 18:13:04 sometimes pushed without PR bumps are OK :) Nov 12 18:13:05 can easily bypass with git commit -n Nov 12 18:13:09 indeed Nov 12 18:13:15 yeah, but you can quickly disable the hooks Nov 12 18:13:18 (for no bump PR ok) Nov 12 18:13:23 i have a pre commit hook that watches for trailing whitespace, etc Nov 12 18:13:34 but it yells at me about patches with whitespace too, so i just -n for that Nov 12 18:13:40 (though i relaly need to make the hook smarter) Nov 12 18:13:53 check out http://github.com/icefox/git-hooks Nov 12 18:14:07 manage global, per user, per repo hooks, sets up the symlinking for you Nov 12 18:15:36 http://kergoth.pastey.net/142797 Nov 12 18:16:33 for one of my projects, i have the 'nose' hook set up, to automatically unit test when committing, which is handy Nov 12 18:21:14 Crofton: I have a few patches/new recipes "aging" in my working branch. Let me know if there are any you think should be posted to the OE list: Nov 12 18:21:19 http://www.sakoman.com/cgi-bin/gitweb.cgi?p=openembedded.git;a=shortlog;h=refs/heads/sakoman Nov 12 18:21:29 heyho Nov 12 18:23:51 we should remind people to look there during patchwork days Nov 12 18:24:17 although some may not be suitable for general consumption Nov 12 18:24:25 aka the -sakoman recipes :) Nov 12 18:24:49 Crofton: yes, some are just for me :-) Nov 12 18:25:11 I try to be quite clear by including sakoman in the names Nov 12 18:25:35 the ones that are generic, usually are Nov 12 18:26:24 It would be even better if you could post a branch just for upstream patches Nov 12 18:26:53 khem: I'll do that, and call it something obvious, like upstream :-) Nov 12 18:26:59 yeah Nov 12 18:27:16 because you know better than anybody phishing them out of your repo Nov 12 18:28:33 I'll create that branch later today and cherry-pick stuff that has been in use for quite some time and thus relatively safe Nov 12 18:29:29 that would be great Nov 12 18:30:46 can anybody tell me whats the "-2_" for in "eet-2_1.3.2+svnr53914-r3.0" is for (it's not the recipe name)? Nov 12 18:31:06 I read that gumstix boards come with OE, which distro is OE most similar to? I use gentoo Nov 12 18:31:09 ah found it Nov 12 18:31:16 PE = "2" in efl.bbclass Nov 12 18:31:43 if anyone wants to help update mplayer to the current head, I have a recipe posted in the repo above Nov 12 18:31:45 oh, OE is not a distro Nov 12 18:31:47 coppermine, OE is a build system for multiple distros - most common is likely 'angstrtom' (what the OE fork uses) Nov 12 18:31:57 which is most like debian I would say Nov 12 18:32:16 tharvey: right, and is angstrom like gentoo with its own package system? or like debian with apt-get, etc? or are they not that advanced Nov 12 18:32:21 i hope its not like busybox Nov 12 18:32:34 the mplayer recipe will build and seems to mostly work -- main issue is a segfault with mp4 files Nov 12 18:32:34 anyone here working on recipes/ti/* ? Nov 12 18:32:36 debian cool Nov 12 18:32:52 tharvey, denix may know about them Nov 12 18:33:01 tharvey: does it have full command set? or reduced? i mean can i run top, gcc, etc Nov 12 18:33:03 coppermine, angstrom inherits debian class naming - but uses opkg for packaging Nov 12 18:33:32 tharvey: what's wrong with recipes/ti? Nov 12 18:33:55 coppermine, you should boot an image and play around with it - you have options to use busybox tools or install task-proper-tools Nov 12 18:34:18 denix, nothing wrong - I wanted to add a recipe for ddompe's branch of gstreamer-ti is all - I have a patch I can post Nov 12 18:34:30 tharvey can i do that in virtualbox ? Nov 12 18:34:41 I've found that there are some really nice features in ddompe's branch that are not in upstream gstreamer-ti Nov 12 18:35:05 denix: recipes under ti/ also get included into non ti machine builds Nov 12 18:35:08 coppermine, that I don't know... I figured you had a gumstix board to try - answer is you have all kinds of flexibility Nov 12 18:35:16 tharvey, so by deduction ,if gumstix boards use OE, and angstrom can be installed using OE, then gumstix can run the angstrom distro? Nov 12 18:35:19 I think that may not be what is wanted Nov 12 18:35:38 coppermine, yes, the 'default' firmware shipped on gumstix (overo at least) is angstrom Nov 12 18:35:46 khem: that's not intended Nov 12 18:35:46 tharvey: fair enough Nov 12 18:37:30 denix, just was curious as to your thoughts on gstreamer-ti-ddompe Nov 12 18:37:31 denix, obviously those recipes need to be in a layer :) Nov 12 18:37:39 * Crofton admits to not looking at them L( Nov 12 18:37:42 er :) Nov 12 18:38:11 Crofton: they are in the layer - arago-project.org :) Nov 12 18:38:20 heh Nov 12 18:38:23 tharvey: feel free Nov 12 18:38:32 too many damn forks of OE out there... Nov 12 18:39:09 tharvey: don't confuse forks with overlays Nov 12 18:39:36 one can say there too many damn kernel trees out there... Nov 12 18:39:56 true... Nov 12 18:39:58 where can I download angstrom for i386 Nov 12 18:40:02 so i can test it Nov 12 18:40:45 coppermine, http://www.angstrom-distribution.org/ ? there is an #angstrom channel also Nov 12 18:41:03 tharvey: checked allready, there's no intel arch in the drop down Nov 12 18:41:05 coppermine: can you build one yourself? Nov 12 18:41:18 angstrom does not target x86 by default Nov 12 18:41:33 right thats why im looking for it Nov 12 18:41:36 to see what it looks like Nov 12 18:41:43 it looks good ;P Nov 12 18:41:51 tharvey: as of ddompe's gstreamer branch - how do you think to do that? as a separate recipe, or by modifying the existing one? Nov 12 18:41:52 it looks like any other linux distro Nov 12 18:42:11 can i ssh in a gumstix board? Nov 12 18:42:24 like to any other linux distro :) Nov 12 18:42:26 denix, I have a sep recipe for it... pretty clean really. The only thing I don't like is that I have to create a fake dir to keep gstreamer-ti.inc happy (for the demos) Nov 12 18:42:27 sounds good Nov 12 18:42:29 i'll stop asking Nov 12 18:44:53 denix, http://pastebin.com/ghW3XpQ3 - may be a better way to deal with line 52 and linke 37 is the 'hack' Nov 12 18:45:09 coppermine: cheer up! :) Nov 12 18:45:18 I still need to test it with recent pull though, when I do I'll post it unless you have any immediate recommendations Nov 12 18:45:59 denix: trying to find the best embedded plaftform for my project Nov 12 18:46:02 denix: I must say that lot of TI specific files should be aware of their arch/machine but they are not Nov 12 18:46:09 i really like embeddedarm.com so far Nov 12 18:46:29 coppermine, of course you can ssh in - are you contemplating buying an overo? Its a great board to get your feet wet with embedded linux Nov 12 18:46:43 tharvey: howa bout the embeededarm boards Nov 12 18:46:51 they are nice too, TS-SOCKET s Nov 12 18:47:20 qemu is good enough to go knee deep into embedded lnx Nov 12 18:47:54 coppermine, don't know about them... TI processors are kind of in a class of their own - I highly recommend an OMAP/DM if you need an ARM core 'and' a generic DSP - if you don't need the DSP then I'm sure there are better options (although in that case I would go with a TI w/o DSP ;P) Nov 12 18:47:58 khem: do you think adding COMPATIBLE_MACHINE to all the recipes is a way to go? Nov 12 18:48:22 COMPATIBLE_MACHINE sounds bad - what about something that uses SOC_FAMILY? Nov 12 18:48:41 qeum is a board emulator Nov 12 18:48:49 it will emulator an ARM9 ? Nov 12 18:48:51 tharvey: that's why we added support for SOC_FAMILY in COMPATIBLE_MACHINE... :) Nov 12 18:49:05 was quite controversial change though... Nov 12 18:49:17 denix, ah... good to know - then that seems fair - do the DM's define an SOC_FAMILY? Nov 12 18:49:24 then i can use angstrom in qmeu Nov 12 18:49:36 I know and its not being used well so whats the use Nov 12 18:50:25 tharvey: unfortunately, there is no one "ti" SOC_FAMILY, there are several eight now - omap3, ti816x, omapl137, omapl138 and bunch of DaVincis... Nov 12 18:50:30 denix: I think when we have layers then there could be a ti layer and people can opt it in or opt out Nov 12 18:51:06 for now, if you know it works with TI parts only then add appropriate classification Nov 12 18:51:08 SOC_FAMILY seems reasonable currently.... looks to me all the omap/dm machines end up defining it to the CPU family Nov 12 18:51:09 would be ok. Nov 12 18:51:14 khem: as I said before - there is already a layer. arago is an overlay on top of OE Nov 12 18:51:48 denix: thats fine. I am talking about the recipes in recipes/ti dir in OE metadata Nov 12 18:51:51 I view arago as a fork of OE - not clear to me how often it merges back and forth Nov 12 18:52:17 I opted to use upstream OE because I not only need current ti support but current x86 support Nov 12 18:52:50 tharvey: yes sometimes in such cases you might fetch and merge two different branches Nov 12 18:53:00 same with gumstix oe tree- not clear to me how it merges back and forth - I don't have the time to even track oe upstream commits, let alone track arago and gumstix-oe trees Nov 12 18:54:09 tharvey: unless there are infra changes which poky kind of does its not a big problem if distro's dont merge back its not really a fork Nov 12 18:54:54 khem, well if for example arago has 'improved' kernel or ti/* recipes, I would like to see them merged back to oe upstream - which I know happens, just not clear who/when Nov 12 18:55:25 the various oe based projects I think adds a ton of confusion to what OE really is Nov 12 18:55:56 I think many of them occur because they want to lock down a stable version - hopefully the stable releases will help that Nov 12 18:56:18 emerge qemu taking a long time :) Nov 12 18:56:39 has to translate machine code translations for all architecture Nov 12 18:57:54 khem: Was qemuppc booting w/ .34? Nov 12 18:59:21 Tartarus: yes Nov 12 18:59:21 it looks like the latest version of gcc-4.5 doesn't take the patch to configure and configure.ac to add ARCH_FLAGS_FOR_TARGET Nov 12 19:00:35 khem, hmm, ok, retrying w/ .34 then :( Nov 12 19:00:39 http://pastebin.com/mFjfpLgG Nov 12 19:00:46 can anyone see why this does not work Nov 12 19:00:58 as in I do not think the scp runs Nov 12 19:05:24 tharvey, khem: yes, part of the problem is to stabilize the OE snapshot to be used for internal products. arago pulls OE every 1-2 weeks and stabilizes it. new recipes/changes from arago being pushed to OE periodically, but there maybe slight delay... Nov 12 19:06:42 khem: there was a proposal couple years ago as to host arago overlay on OE git server - never happened Nov 12 19:07:24 khem, tharvey: I still don't think it's correct to call it a fork. think about other distros outside of the the tree - SHR for example Nov 12 19:07:28 I think OE will not be that much of an issue with layered arch soon Nov 12 19:07:38 merging back may be easier than today Nov 12 19:07:44 we all know arago exists and where to look :) Nov 12 19:08:13 03Michael Smith  07master * r3a06d26504 10openembedded.git/recipes/usbutils/usbutils_0.86.bb: Nov 12 19:08:13 usbutils 0.86: delete usb.ids if gzipped version is installed Nov 12 19:08:13 Also split update-usbids.sh to a separate package, and allow building Nov 12 19:08:13 when sbindir != /sbin. Nov 12 19:08:13 Signed-off-by: Michael Smith Nov 12 19:08:17 welll as long as bees return to hive its ok :) Nov 12 19:08:41 03Michael Smith  07master * r36a01ad197 10openembedded.git/recipes/usbutils/ (usbutils_0.70.bb usbutils_0.73.bb): Nov 12 19:08:41 usbutils 0.70 & 0.73: don't set DEFAULT_PREFERENCE = "1" Nov 12 19:08:41 I think it may be leftover from earlier. Let 0.86 build by default. Nov 12 19:08:41 Most distros already prefer it. Nov 12 19:08:41 Signed-off-by: Michael Smith Nov 12 19:08:43 khem: the point is, OE already has layers/overlays :) nobody inside OE uses layers, only people outside the tree use them, but then they are immediately blamed for forking OE... :) Nov 12 19:08:50 Crofton: :-P Nov 12 19:09:32 any one tried to compile x86 driver for other devices such as mips ? Nov 12 19:10:09 reactor16: device drivers are usually hardware specific... Nov 12 19:10:39 unless you are talking about the driver using a standard bus Nov 12 19:13:07 i have a wifi usb and i want to compile driver to use it on my dreambox Nov 12 19:13:39 is this possible ? Nov 12 19:20:56 hi all... sry to bother Nov 12 19:21:45 i was wondering if anyone knows the best way to replace an OE generated image with a new one "on the fly" (jffs2 image) Nov 12 19:21:51 or where to get more info Nov 12 19:22:20 As a rule of thumb, if you don't have a two partition setup, you write flash images from the bootloader Nov 12 19:23:06 denix: no what I think is that we need layers within OE too Nov 12 19:23:13 then it wont be of so much of a blame Nov 12 19:26:57 i have several partition... i guess the best way is then to mount one an then copy it to the default partition? Nov 12 19:28:58 marenas, if you can boot from either partition, yes, that works too Nov 12 19:29:05 It depens on your flash setup Nov 12 19:29:37 is it more recomendable to do it from the fs or from the bootloader ? Nov 12 19:29:43 (updating) Nov 12 19:29:53 it all depends on your setup really, sorry Nov 12 19:30:04 If you're comfortable with doing it in the bootloader, that's fine Nov 12 19:30:17 If you aren't and you can boot from something else (nfs, sd, another flash) that's fine too Nov 12 19:30:50 im confortable with it, but i would like to do it from the FS directly Nov 12 19:31:13 like "take this image and update yourself" Nov 12 19:31:58 Yeah, if you have the space, go for it :) Nov 12 19:32:34 can I use a shell if in a recipe? Nov 12 19:32:45 is there a way to do it without creating another mountable partition?? Nov 12 19:32:47 Question: Why is that my path files are unpacked to ${WORKDIR}, but not applied? Nov 12 19:33:46 davidlt: do u have any message while building ? Nov 12 19:33:47 marenas, Are you asking for doing something for youself, or designing a system for others to use? Nov 12 19:34:16 its for others to use Nov 12 19:34:37 that's why i want it to be the simplest way possible Nov 12 19:35:02 Well, the simplest way is to script things from the bootloader Nov 12 19:35:27 marenas, I just copied my recipe from late-August to mid-April release. And when there should be patching done is nothing printed. Instead they are written as "unpacking" and copied to my working directory. Nov 12 19:37:25 did u clean everything up ? Nov 12 19:37:39 It's like that: NOTE: Unpacking user.collection/recipes/modphp/modphp-5.2.13/acinclude-xml2-config.patch to tmp/work/armv7a-angstrom-linux-gnueabi/modphp-5.2.13-r0/ Nov 12 19:37:51 What do you mean? Nov 12 19:38:41 bitbake "name_of_app" -c clean before trying to build Nov 12 19:38:53 Of course Nov 12 19:38:54 or bitbake -b recipe.bb -c clean Nov 12 19:39:18 What's the difference if files are in modphp-.. folder or 'files' folder? Nov 12 19:41:09 files folder is where all extra files you need for building should be Nov 12 19:41:25 so patches should go into it? Nov 12 19:41:28 yes Nov 12 19:42:08 i dont know exactly how it works, but it probably looks there for patches to apply Nov 12 19:42:19 testing right now Nov 12 19:42:32 Same problem, only unpacking Nov 12 19:43:55 Can't get why they are not applied Nov 12 19:44:48 Trying php recipe Nov 12 19:45:17 It works Nov 12 19:46:02 cool Nov 12 19:46:41 That's not good, I don't get why modphp doesn't work Nov 12 19:46:47 aaa Nov 12 19:48:06 are u building modphp directly or a particular recipe ? Nov 12 19:48:51 I used modphp and php recipies and wrote modphp 5.2.13 recipe, which works on my late-August setup. Nov 12 19:49:29 It's pretty much the same as PHP Nov 12 19:53:15 just copied folder from mid-April to late-August to the same location. Nov 12 19:53:20 Worked. Nov 12 19:53:29 So why it doesn't work on mid-April. Nov 12 19:54:23 I have working directory modphp_5.2.13-r0/php-5.2.13 Nov 12 19:54:41 All files from modphp-5.2.13 are copied to modphp_5.2.13 folder Nov 12 19:55:46 maybe it's a change in another recipe or conf file that is causing problems Nov 12 20:00:15 ok, back to system_tools_backends Nov 12 20:02:04 I think I get this... Nov 12 20:02:17 Before there was ;patch=1 not apply=yes Nov 12 20:04:56 legacy stuff Nov 12 20:08:47 khem, got any more ideas for system-tools-backends? Nov 12 20:22:22 Could someone point me at an explanation of *-meta packages? In particular trying to understand the use case of gst-plugins-base-meta. Nov 12 20:22:42 meta packages are just recipes that depend on other recipes Nov 12 20:22:48 that's all. they don't produce packages, or do anything Nov 12 20:23:17 tasks, on the other hand, are recipes that don't build anything, but which do emit empty packages that depend on other packages Nov 12 20:34:23 Hmm. I use tasks a bit with the purpose of collapsing a bunch of packages into a single target. But don't immediately see the benefit of *meta packages.. Nov 12 20:35:41 E.g. there is task-arago-gst which has RDPENDS with gst-plugins-base and gst-plugins-base-meta. What extra things does the meta add? Nov 12 20:55:35 AFAICT, in this case of gst, the meta recipe creates an ipk file which only contains a control file with all of the plugins in the depends field. Moreover there is no remnants in the work or sysroots. I think this is what kergoth means by "empty packages" above. On the surface this then seems to be a side-effect of split packaging used for gst-plugins since the base control file has an empty depends field. In other words the purpo Nov 12 20:55:35 of the meta recipes in this case is for documentation in the control file and, possibly, for use with opkg installs/updates. Nov 12 21:01:54 afaik, there's no clear difference between tasks and meta-packages... Nov 12 21:04:56 martinambrose: while meta-recipes don't produce actual packages, according to kergoth, there are no control files and nothing to feed to opkg Nov 12 21:06:25 kergoth: is the main difference that meta DEPENDS on other packages, while task RDEPENDS? Nov 12 21:06:43 yeah, as far as i know that's the case. Nov 12 21:07:36 What I see in gst-plugins.inc is that the metapkg is defined using RDEPENDS. Nov 12 21:07:56 An ipk is then created, e.g., here deploy/ipk/armv5te/gst-plugins-base-meta_0.10.25-r8.3.5_armv5te.ipk Nov 12 21:08:22 oh, that's different than a normal meta recipe (recipes/meta/*) Nov 12 21:08:27 that's just confusing naming. Nov 12 21:10:34 hello, is there any arm gcc specialist ? Nov 12 21:13:29 who is the maintainer of gcc ? Nov 12 21:13:57 if you have a question, ask it. Nov 12 21:14:43 kergoth: why does webkit-efl not compile under x86 host ? Nov 12 21:15:07 kergoth: compiling under amd64 works Nov 12 21:15:34 and you were looking for arm gcc specialist for that? Nov 12 21:16:03 denix: yes Nov 12 21:16:06 i'm assuming x86 host, arm target :P Nov 12 21:16:28 nschle85: i said *ask it* Nov 12 21:16:30 not *ask me* Nov 12 21:16:32 mrj10: yoz are right Nov 12 21:16:33 just spit it out already Nov 12 21:16:41 :) Nov 12 21:17:12 oh boy, newbie's life on irc is so hard... :) Nov 12 21:17:40 hehe Nov 12 21:17:59 denix this is mild Nov 12 21:18:19 well.. build with speed scheduler was finished Nov 12 21:18:24 anyone had problems building the latest version of gcc-4.5 due to libstdc++ PCH? Nov 12 21:18:39 I'll publish results in a hour Nov 12 21:18:59 sorry, got no answer yet Nov 12 21:19:35 http://pastebin.com/zAmegie5 Nov 12 21:19:42 i have a gcc 4.5 AMD64 to ARM cross-compiler working fine, but i get most of the way through building the native ARM compiler using it and get a bunch of "::fe has not been declared in libstdc++-v3/include/tr1_impl/cfenv Nov 12 21:19:59 this is for the package gcc-4.5-r19.1+svnr166342 Nov 12 21:20:32 mrj10: amd64 is working ! thank you Nov 12 21:20:51 mrj10: i386 seeems not work ! Nov 12 21:21:01 nschle85: i am talking about my own problem. Nov 12 21:22:33 denix: can you help me ? Nov 12 21:23:52 nschle85: try asking khem, I haven't seen anything like that before... Nov 12 21:26:48 denix: sorry for my mistakes on irc, for me irc is one media to get in contact with developers, not to earn bat comments Nov 12 21:31:05 khem: hello, i am using shr-image.bb but there is a problem compiling webkit-efl, i think its a general problem under i386 architecture (under amd64 all is fine) Nov 12 21:31:29 khem: can you help me please ? Nov 12 21:31:55 nschle85, wait for it...he is in and out. Nov 12 21:32:45 ka6sox: do you mean he will read this thread later ? Nov 12 21:34:28 yes Nov 12 21:34:47 ka6sox: ok, i understood Nov 12 21:35:06 lt 1 Nov 12 21:35:11 aq 2 Nov 12 21:36:02 ka6sox: do you know anybody else who can helpm me ? Nov 12 21:37:29 everyone here is a volunteer...so patience is the best thing. Nov 12 21:40:45 rahhh Nov 12 21:40:52 I don't know what happens Nov 12 21:41:03 I sent a patch twice Nov 12 21:41:07 and no patch arrived Nov 12 21:41:26 are you subscribed to the developer's list? Nov 12 21:41:31 of course Nov 12 21:41:34 if so, wait a few hours, sometimes the server hiccups Nov 12 21:41:38 happened a few days ago in fact Nov 12 21:41:46 my patches showed up about 3 hours after i sent them Nov 12 21:41:58 ah ok Nov 12 21:42:06 basically here's what I did Nov 12 21:42:10 I sent a message Nov 12 21:42:15 with a patch following it Nov 12 21:42:20 then the patch didn't arrive Nov 12 21:42:29 so I sent the patch as response to the message Nov 12 21:42:34 and still didn't arrive Nov 12 21:42:49 well, i have 2 emails from you Nov 12 21:42:54 ok Nov 12 21:42:57 but neither of them actually has a patch in it Nov 12 21:43:00 indeed Nov 12 21:43:10 I've also sent a response mail Nov 12 21:43:20 basically here's the output: Nov 12 21:43:39 http://pastebin.com/y6BqLC0y Nov 12 21:43:58 it says 250 OK Nov 12 21:44:11 and before the messages arrived Nov 12 21:44:13 but not the patch Nov 12 21:46:29 mrj10, any ideas? Nov 12 21:48:30 i am not a git-send-email expert, i just copied the tutorial here http://wiki.openembedded.org/index.php/How_to_submit_a_patch_to_OpenEmbedded to the letter Nov 12 21:48:58 the strange thing is that it worked before Nov 12 21:50:23 that is strange. wish i could help more. Nov 12 21:50:30 ok Nov 12 21:50:36 maybe I'll ask #git Nov 12 21:50:40 thanks anyway Nov 12 22:53:59 nschle85 around ? Nov 12 22:54:25 khem, m9ving gnu-configize in front of libtool Nov 12 22:54:30 well he left Nov 12 22:54:33 did not help Nov 12 22:54:39 Crofton: ok Nov 12 22:54:40 hmm Nov 12 22:54:54 I hate seeing do_configure that has that much stuff in it Nov 12 22:55:10 I know but upstream maintainers are lame sometimes Nov 12 22:55:18 and we have to tie the band aids Nov 12 22:55:34 let me see if I have a system root somewhere Nov 12 22:55:42 I can quickly churn Nov 12 22:55:54 Crofton: can you post the error for me once again plz Nov 12 22:56:03 its using angstrom 2010 right ? Nov 12 22:56:07 right Nov 12 22:56:14 ok Nov 12 22:57:21 http://pastebin.com/PVCuRNi1 Nov 12 22:58:16 hmmm my laptop is in car Nov 12 23:03:07 if I am building ti stuff Nov 12 23:03:24 and its looking for 6.1.17 for something Nov 12 23:03:33 how would I make it look at 6.1.9 instead for example Nov 12 23:11:06 oh wait Nov 12 23:11:08 I am retarded Nov 12 23:11:11 on many levels Nov 12 23:11:16 9 < 17 Nov 12 23:13:33 Crofton: I will look into this issue once I get home tonight Nov 12 23:13:44 thanks Nov 12 23:13:49 I am stuk on something else atm Nov 12 23:13:59 right now I am trying it on a hopeless machine which is damn slow and it wants to rebuild gcc Nov 12 23:14:05 which means like 3 hours Nov 12 23:14:12 heh Nov 12 23:14:19 yeah, I am stuck on other things Nov 12 23:14:52 Crofton: ok Nov 12 23:15:01 how is release coming up ? Nov 12 23:15:17 I hope your software will not become a bottleneck Nov 12 23:17:10 Crofton can you push? Nov 12 23:17:17 ka6sox, yes Nov 12 23:17:25 it involved me being an iodiot Nov 12 23:17:41 well, atm there is a weird sw/hw issue Nov 12 23:17:41 somehow mailing list rejected one of my message Nov 12 23:17:47 I wonder what pissed it off Nov 12 23:17:56 heh Nov 12 23:18:02 that is how I feel about this board Nov 12 23:18:11 hmm Nov 12 23:18:17 is it overo based ? Nov 12 23:18:24 yeah Nov 12 23:18:31 k Nov 12 23:18:56 the problem occured after we tried to re setup the clock gen chip for the fpga Nov 12 23:19:06 EB/N0 = 13.0 Nov 12 23:19:16 heh Nov 12 23:19:56 03Chris Larson  07master * rdf3fe2bf89 10openembedded.git/classes/newcollection.bbclass: Nov 12 23:19:57 newcollection: clean up, and work for those not using collections.inc Nov 12 23:19:57 Signed-off-by: Chris Larson Nov 12 23:20:06 03Chris Larson  07master * r81a5067e56 10openembedded.git/classes/newcollection.bbclass: Nov 12 23:20:06 newcollection: handle globs in file: uris Nov 12 23:20:06 Signed-off-by: Chris Larson Nov 12 23:20:07 03Chris Larson  07master * re0bcb3741e 10openembedded.git/classes/newcollection.bbclass: Nov 12 23:20:07 newcollection: fix host/path issue Nov 12 23:20:07 Signed-off-by: Chris Larson Nov 12 23:20:39 there, now it seems to work great again Nov 12 23:20:59 Crofton, at least they aren't illuminating 2 birds anymore Nov 12 23:22:37 hm.. interesting data with speed scheduler.. Nov 12 23:22:57 https://spreadsheets.google.com/a/jay-tech.ru/ccc?key=0AhY8lmfkCabTdGZRSGZ0eXg5cWhkV2k1c0Jvd0lvVnc&authkey=CLeK150N#gid=3 Nov 12 23:23:35 peak disk usage is about 40Gb Nov 12 23:23:46 compare with sheet Chart 3 Nov 12 23:24:58 but build was slightly faster Nov 12 23:25:02 about 40 min Nov 12 23:25:03 ya, is that building minimal or something else? Nov 12 23:25:19 angstrom Nov 12 23:25:27 ah. Nov 12 23:25:31 how much more was that disk usage than the completion one? Nov 12 23:25:34 angstrom-2008.1 Nov 12 23:26:33 jay7 is there any way for you to get metrics on I/O BW? Nov 12 23:26:53 specifically HD bandwidth used during different parts of the build. Nov 12 23:26:58 min free space - completion: 24317Mb; speed: 18803Mb Nov 12 23:27:18 total partition size is 64Gb Nov 12 23:27:35 i was really wanting to determine I/O bandwidth on a per task basis, but thats slightly nontrivial Nov 12 23:27:59 ka6sox: it should depend on number of bb and make threads Nov 12 23:28:01 ya, that would be very helpful. Nov 12 23:28:17 so I'm not sure that it will be really helpful Nov 12 23:28:25 i was putting a lot of work into the bitbake scheduler, wrote like 5 different alternatives to speed and completion Nov 12 23:28:45 Jay7, right. based on my testing I believe as the number of build threads goes up the amount of indyividual task I/O wait time increases considerabl Nov 12 23:28:48 kergoth_: I can test'em all, but let's after release :) Nov 12 23:28:52 my most recent one profiles a build and uses the cpu time for each task to weight them in subsequent builds :) Nov 12 23:29:08 but the results weren't fantastic, sadly Nov 12 23:29:18 i think we might need to move to a dynamic rather than static scheduler at some point Nov 12 23:29:47 kergoth_: I think we should split building from fetch/unpack Nov 12 23:30:01 it is very different patterns Nov 12 23:30:20 I think we need to do something to make fetch/unpack fully cached. its really stupid to be having to re-unpack/re-patch source trees, particularly iyf the recipe supports separate objdir Nov 12 23:30:23 heh Nov 12 23:30:28 yeah, true Nov 12 23:30:42 what we need is a scheduler that takes into account I/O waits too. Nov 12 23:31:05 so it doesn't start so many threads that its waiting for I/O to happen and getting bottlenecked that way. Nov 12 23:31:08 then we can fine-tune builders and fetchers Nov 12 23:31:10 i have one that marks tasks with a resource class (e.g. i/o, cpu, network) and sets the max # of threads per resource Nov 12 23:31:21 then you can crank up the overall maximum higher than you could otherwise Nov 12 23:31:25 but the results were inconclusive Nov 12 23:32:13 * kergoth_ put way too much time into those Nov 12 23:32:24 well.. do we have other tests pending with same pattern? Nov 12 23:32:27 see, we arent' coming anywhere near fully using the resources of machines with like 8 cores Nov 12 23:32:35 ah, yes, I have one Nov 12 23:32:37 which sucks, and we need to figure out why Nov 12 23:32:40 but its a pain int he ass Nov 12 23:33:18 kergoth_: I can show you graph of my 6 cores load Nov 12 23:33:25 it is about 80% Nov 12 23:33:42 disk I/O is bottleneck this time Nov 12 23:34:16 kergoth: which kind of parallelism gain woul you expect form a command like 'bitbake x-image y-image' wrt sequential build of the two images? Nov 12 23:34:21 ah.. no, I can't show full time load Nov 12 23:34:25 only partial Nov 12 23:34:29 ant__: depends :) Nov 12 23:34:47 I should setup something that will save rrd data from snmp :) Nov 12 23:34:53 iirc both waiting for glibc locales Nov 12 23:34:59 I have to retry Nov 12 23:35:01 Jay7: i think we really need to measure per task i/o to get a handle on this, wihtout per task numbers, its hard to isolate other parts of the system from the bitbake build Nov 12 23:35:06 ant__: this is my next test for this night :) Nov 12 23:35:06 kergoth_: multiple targets for bitbake will spawn parallel tasks ? Nov 12 23:35:20 khem: yep, it produces a single list of tasks in the end Nov 12 23:35:24 and operates based on that Nov 12 23:35:33 kergoth: cool so it will sort of combine both Nov 12 23:35:49 kergoth_: with new logger it should be easy to measure space usage at least Nov 12 23:36:03 or will it have two queues Nov 12 23:36:14 i.e. add vfstat output to log messages too Nov 12 23:36:22 combine this fetch and unpack seriouslt Nov 12 23:36:32 I can even do again one-thread build :) Nov 12 23:36:40 but it take about 19 hours Nov 12 23:36:53 but I can reduce count of machines/images Nov 12 23:37:10 don't forget about release ;) Nov 12 23:37:16 i started reading up on disk scheduling algorithms and stuff, but my head hurt after that Nov 12 23:37:25 :P Nov 12 23:37:27 so, write all your ideas for next month ;) Nov 12 23:38:11 what i dislike about the scheduling thing is, i don't know enough to say what the optimal algorithm is, so i'm just flying blind. hypothesize about possible improvement, create scheduler for it, test it, rinse, repeat Nov 12 23:38:17 btw, dunno why but Gentoo moved from gitosis to gitolite http://idl0r.qasl.de/blog/index.php/2010/11/07/migrating-from-gitosis-to-gitolite Nov 12 23:38:32 ant__: gitolite has a number of features gitosis doesn't Nov 12 23:38:41 including access control within a repo Nov 12 23:38:48 would be nice for us to move to it as well Nov 12 23:38:48 I see Nov 12 23:39:23 maybe someone in here has more experience with scheduling and has better ideas to improve bitbake's, i'd love to see that Nov 12 23:39:26 :\ Nov 12 23:40:41 kergoth_: your way is like to genetic algorythm :) Nov 12 23:40:51 hehe Nov 12 23:41:05 create idea, code it, test it, improve it and so on :) Nov 12 23:41:40 I can test it :) Nov 12 23:41:47 the problem isn't the method, persay, its how the idea was derived. the rest is common to any method, really, but i'm pulling ideas out of my ass, rather than from actual proven theory Nov 12 23:41:52 :) Nov 12 23:41:52 so, code and improve :) Nov 12 23:42:20 it all goes back to the dependency tree..hm Nov 12 23:42:41 well.. I'll post results to ML again Nov 12 23:43:21 http://kergoth.pastey.net/142813 Nov 12 23:43:44 kergoth: have you tlooked at Gentoo's package-order in case of rebuilds? Nov 12 23:44:08 i haven't looked at gentoo since we originally started based on portage. Nov 12 23:44:23 there could still be a common algorithm Nov 12 23:44:43 he..potentialy susceptible of adoption... Nov 12 23:44:49 can't hurt to investigate Nov 12 23:45:11 sadly my python is 0+ Nov 12 23:45:48 well, I can somehow read it ;) Nov 12 23:47:03 that pastey is of a class that shows per task and overall build cpu usage and time elapsed Nov 12 23:47:11 just needs I/O Nov 12 23:47:24 and network, ideally.. Nov 12 23:47:29 Jay7, I was watching the I/O loading go up exponentially as the number of -j threads were increased...until you reach the point where the builder is totaly I/O bound. Nov 12 23:48:05 logging uptime? Nov 12 23:48:21 and the 2*(number of cores) didn't scale correctly when you got to beyond 3 cores. Nov 12 23:48:33 vmstat can give io Nov 12 23:48:36 but not per tasks Nov 12 23:48:44 so.. merge by time again :( Nov 12 23:48:59 and again building in one thread then Nov 12 23:49:01 yes, I didn't look @ by task, I was only looking @ vmstat. Nov 12 23:49:06 but this will break all numbers Nov 12 23:49:09 vmstat is helpful for overall Nov 12 23:49:19 but i donj't like that its the whole system Nov 12 23:49:25 for all i know you had an updatedb going ;) Nov 12 23:49:39 kergoth_ I killed that. Nov 12 23:49:40 :D Nov 12 23:49:42 hehe Nov 12 23:50:05 the machine was ONLY building... Nov 12 23:50:22 should be pretty close to right numbers then, yeah Nov 12 23:50:30 I was pretty careful not to allow even cronjobs to be running (except for log stuff) Nov 12 23:50:35 nice Nov 12 23:50:37 btw, I wish to know separate disk usage by workdir and staging dir.. Nov 12 23:50:57 ya, du is brutal Nov 12 23:51:00 I'm pretty sure its possible to capture per task i/o usage via netlink, but i think you have to be root to do it Nov 12 23:51:04 unless you have separate partitions. Nov 12 23:51:13 I can produce almost the same env here if it will be useful Nov 12 23:51:30 and I'm root ;) Nov 12 23:51:39 you are building as root? Nov 12 23:51:44 no :) Nov 12 23:51:47 ka6sox: i was trying to time builds one time in a VM .. not smart ;) other vms kept stealing my cpu and making the results vary wildly. hehe Nov 12 23:51:54 * kergoth_ = moron sometimes Nov 12 23:52:03 dont worry Nov 12 23:52:06 about 20 minutes ago Nov 12 23:52:14 I thought 9 was > 17 Nov 12 23:52:20 kergoth_ I was doing the same.. Nov 12 23:52:22 brb Nov 13 00:06:14 I'll run test of "bitbake console-image x11-image opie-image" vs "bitbake console-image; bitbake x11-image; bitbake opie-image" Nov 13 00:06:28 what scheduler better to use for this run? Nov 13 00:07:13 i.e. I'll run only second part (separate bitbake run for every image) Nov 13 00:07:13 Jay7, you have 6 cores? Nov 13 00:07:17 ka6sox: yes Nov 13 00:07:34 phenom II x6 1055T Nov 13 00:07:39 speed is definitely the faster scheduler, i'd stick to that if you're measuring build time stuff Nov 13 00:07:53 I'm measuring disk usage :) Nov 13 00:07:56 what needs to happen is to find the saturation point of the I/O BW (for the entire machine) Nov 13 00:08:18 oh, speaking of hardware... i can't decide whether i should build/buy a new fast dedicated buil dmachine, or upgrade my workstation and build there, or neither Nov 13 00:08:21 so.. to find lower usage better to use completion then, imho Nov 13 00:08:37 how does task-proper-tools know to build the recipes it needs? Nov 13 00:08:40 hard to say. rm_work will reduce disk *usage* Nov 13 00:08:45 as in, gigabytes Nov 13 00:08:45 kergoth_: Opteron with 12 cores ;) Nov 13 00:08:53 but rm_work is spawning an rm -rf of workdir Nov 13 00:08:57 which is actually more i/o work Nov 13 00:09:00 so.. :) Nov 13 00:09:03 * kergoth_ shrugs Nov 13 00:09:14 well.. let's run with completion Nov 13 00:09:14 dunno which would be better in this case Nov 13 00:09:23 I'd rather build then clean up afterwards. Nov 13 00:09:29 Crofton: what do you mean? Nov 13 00:09:39 it eats less space and is default with rm_work Nov 13 00:09:46 Crofton: bitbake always obeys RDEPENDS* Nov 13 00:10:01 ie: do a full run and then rm_work after everything is finished. Nov 13 00:10:11 my understanding is that will define with pkgs are needed Nov 13 00:10:12 by bet is Nov 13 00:10:15 if A rdepends on B, it knows about it, and certain tasks are marked as running against runtime deps Nov 13 00:10:23 but DEPENDS is needed to make sure they get built Nov 13 00:10:26 nope Nov 13 00:10:42 all DEPENDS does is sets a flag on a task Nov 13 00:10:45 *my bet is that separate bb runs will use even less disk space Nov 13 00:10:54 it makes it so configure requires populate_staging of everything it depends on Nov 13 00:11:08 but its possible to flag tasks as depending on other things, or as depending on its runtime deps Nov 13 00:11:21 Jay7, staging takes a bit of space too...so we need that. Nov 13 00:11:47 and are we still using ccache as the default? Nov 13 00:11:56 any task marked with rdeptask or recrdeptask will run against both its deps and its rdeps Nov 13 00:12:28 so the only time you need a DEPENDS is if the RDEPENDS does not force something to build? Nov 13 00:12:41 ka6sox: afaik, ccache is used when it is found in PATH Nov 13 00:12:54 *generally*, we prefer setting DEPENDS to setting RDEPENDS, and letting bitbake set RDEPENDS based on shlibs, etc Nov 13 00:12:58 but it doesn't *have* to be that way Nov 13 00:13:09 Crofton: classes/image.bbclass:do_rootfs[recrdeptask] += "do_deploy do_populate_sysroot" Nov 13 00:13:24 this menas when you build an image, it ensures that everything in the dep tree, both build and runtime, gets deployed and sysrooted Nov 13 00:13:34 hence, follows the rdeps in the task-proper-tools recipes Nov 13 00:13:36 s/s$// Nov 13 00:13:40 ok Nov 13 00:13:50 I have been erring on the side of caution .... Nov 13 00:14:06 the rootfs classes also arrange for the package writing tasks to be run for all deps and rdeps Nov 13 00:14:53 now, if you're building a task that doesn't have any rdeptasks anywhere, it'll only obey DEPENDS, because DEPENDS is basically the deptask of do_configure, and the task you run depends on that Nov 13 00:15:07 I have a feeling that last time I asked, I got a simplied answer (several years ago) Nov 13 00:15:08 if you run a task that doesn't end up depending on do_configure, then even DEPENDS wonj't be obeyed, and it just runs that one task Nov 13 00:15:08 :) Nov 13 00:15:25 well, bitbake didn't schedule at a task level in the past Nov 13 00:15:34 richard added that while i was away from the project Nov 13 00:15:42 ah Nov 13 00:15:43 ok Nov 13 00:15:48 I don't feel so bad :) Nov 13 00:16:34 thanks for explaining that Nov 13 00:16:38 the only reason bitbake needs to have any real knowledge of depends/rdepends/etc directly is because of PREFERRED_PROVIDER and all Nov 13 00:16:59 otherwise the metadata itself could do DEPENDS -> do_configure[depends] Nov 13 00:17:31 right now bitbake knows about DEPENDS, PACKAGES< RDPENEDS< RDEPENDS_*, etc, because provider preferences apply to both build time and runtime dillemmas Nov 13 00:18:27 anyway.. methinks the bitbake docs need a rewrite :P Nov 13 00:18:40 i don't think any of this is written down, but i could be mistaken Nov 13 00:19:04 liek I said, I suspect I have been working on dated info for quite some time :) Nov 13 00:19:16 * kergoth_ nods Nov 13 00:19:38 note: base.bbclass:do_configure[deptask] = "do_populate_sysroot" Nov 13 00:19:43 this one line is the magic behind the majority of the build Nov 13 00:19:56 the magic is very dense Nov 13 00:19:58 thats how it knows to make do_configure depend on populate_sysroot for all DEPENDS Nov 13 00:20:12 that it is Nov 13 00:20:58 took me quite a while to get back up to speed after coming back, particularly on the bitbake internals Nov 13 00:21:01 heh Nov 13 00:21:21 * Jay7 should connect server and gate to UPS Nov 13 00:21:28 so offline for some time Nov 13 00:22:09 Jay7, next runs Nov 13 00:22:17 it would be nice to limit -j number Nov 13 00:22:27 to minimize build times Nov 13 00:22:46 ie: get it out of being I/O bound. Nov 13 00:23:34 hmm, so the problem with overloading the disk is that it affects non-disk bound tasks too, for what little disk they have to use, correct? cpu is simpler, running two tasks at 50% the final run time is the same as running one then the other at 100% each.. Nov 13 00:23:38 heh Nov 13 00:24:44 Kergoth_ that is what I am surmising based on watching build times drop till we reached I/O saturation and then go up significantly when you get beyond that. Nov 13 00:24:52 * kergoth_ nods Nov 13 00:24:57 ie: thrashing the disks Nov 13 00:24:58 interesting Nov 13 00:25:55 makes sense. the main danger to watch for with the cpu is underloading it, and with disk overloading it :) Nov 13 00:26:04 at least in this context Nov 13 00:26:21 exactly Nov 13 00:27:06 if thats the case, the scheduler i did that can limit the max # of threads for a given resource might be beneficial for the i/o bound tasks, at least only allow, N # of unpack+patch Nov 13 00:27:13 * kergoth_ might drag it back from the grave Nov 13 00:27:20 if i can figure out where i put it, anyway Nov 13 00:28:05 kk...that sounds like a good way to begin optimizing builds for the hardware available. Nov 13 00:28:38 I suspect that narcissus builds on the 16core machine are I/O bound and thrashing. Nov 13 00:29:11 i'll see if i can dig this one back up and send it your way in the next day or two, to test the theory Nov 13 00:29:28 Yeah Nov 13 00:29:33 We tried doing that, like kergoth is saying Nov 13 00:29:37 And it just didn't help Nov 13 00:29:40 kk... Nov 13 00:29:51 It was quite frustrating Nov 13 00:30:02 Tartarus, what class of machine? Nov 13 00:30:02 very, i was getting really pissed off Nov 13 00:30:12 by the 5th scheduler test i was ready to break something Nov 13 00:30:35 ka6sox, virtualized on quite beefy HW quadcore Nov 13 00:31:51 i think part of the issue with these theories is they're rather one dimensional -- tasks might use *more* of a resource than another, but they all use both cpu and disk, maybe it needs more complex weights for both for each task to be more intelligent about it. alternatively, its possible a dynamic scheduler could be smarter about what its doing, actually check the available system resources when spawning a task Nov 13 00:33:48 * Jay7 is back Nov 13 00:33:59 gate will be reconnected at morning Nov 13 00:34:58 kergoth: if we will have reliable way to determine disk bandwidth and CPU usage stats we can add BB threads until get overloaded Nov 13 00:35:16 -j can be fixed on 2 or 3 e.g. Nov 13 00:36:08 and next idea Nov 13 00:36:35 you can use tmpfs to remove disk I/O bw limit Nov 13 00:36:55 to check how to better load CPUs Nov 13 00:37:57 virtualised hardware for build systems is not ideal Nov 13 00:38:11 well, not everybody has 32GB ram... Nov 13 00:38:54 I mean how to check CPU loading only Nov 13 00:39:03 w/o be affected by IO Nov 13 00:39:17 Jay7: your tests indicate that building in tmpfs is out of question for the masses Nov 13 00:39:56 tonight's test will close this question :) Nov 13 00:40:01 still it was possible months ago... Nov 13 00:40:15 khem: I don't know, honestly Nov 13 00:40:25 There's something to be said for teardown/bringup Nov 13 00:40:29 and a lack of magic systems Nov 13 00:40:39 That said, not all VM solutions are created equal Nov 13 00:40:40 anyway 24Gb is minimal from my current tests Nov 13 00:40:52 internally, we have something pretty fancy and fast Nov 13 00:41:35 Just throwing stuff into virtualbox/kvm/vmware workstation||player/etc can indeed be a loss, always Nov 13 00:43:10 24GB of RAM Jay7 ? Nov 13 00:43:30 khem: So, yay! .34 fails for qemuppc currently too :) Nov 13 00:43:58 Tartarus: ah with gcc 4.5 ? Nov 13 00:44:28 Tartarus: last time I booted was a while back and it booted fine with gcc 4.5 Nov 13 00:44:38 ka6sox: I have only 4Gb now Nov 13 00:44:40 but since then linaro patches have kicked in Nov 13 00:44:46 other 4Gb are in repair/change Nov 13 00:45:42 but according to charts you can build e.g. console-image+x11-image+opie-image for collie in 24Gb Nov 13 00:46:12 Tartarus: for running a webserver email server virtual box is fine Nov 13 00:46:15 my motherboard can have only 16Gb according to spec.. :( Nov 13 00:46:19 but not for building OE Nov 13 00:46:30 I think thats a waste of compute power IMO Nov 13 00:46:44 unless the same box is used for something else non build purpose Nov 13 00:46:50 * Jay7 is building inside LXC-container Nov 13 00:47:02 but this container is unlimited mostly Nov 13 00:47:57 well.. testbuilder is ready to run Nov 13 00:48:59 I would use a farm Nov 13 00:49:07 khem, like i say Nov 13 00:49:11 like identical i7 machines and use icecc Nov 13 00:49:16 It works well here, but we've got high end HW behind it Nov 13 00:49:27 I wanna play with farming stuff out from time to time Nov 13 00:49:30 Tartarus: are you using virtualised boxes ? Nov 13 00:49:46 Yes, virtualized hw Nov 13 00:49:50 ok Nov 13 00:49:51 vCenter / Lab Manager Nov 13 00:49:57 hmm ok Nov 13 00:50:50 We haven't been able to get CPU bound trying to build Nov 13 00:51:03 Hence kergoths attempts at new schedulers Nov 13 00:51:47 And from some other talk, we're +/- some other beefy boxes on raw HW Nov 13 00:53:13 Tartarus, farming is what I'm thinking about for narcissus Nov 13 00:57:03 well.. build started Nov 13 00:57:22 should be a bit longer imho.. Nov 13 00:58:10 Jay7, I suspect it will take some time to optimize Nov 13 00:58:29 separate bitbake runs should eat some time Nov 13 00:58:41 e.g. parsing and preparing runqueue Nov 13 00:58:51 but I hope this will reduce peaks Nov 13 01:02:55 Jay7, yep..smoothing it out and keeping it from thrashing will help Nov 13 01:03:34 I've not changed number of threads Nov 13 01:04:46 but I should play with it too one time Nov 13 01:06:05 well, I'll save vmstat 10 output for build time too then Nov 13 01:06:18 will look on max io Nov 13 01:08:32 okay good..I think that we need to get some real numbers on I/O performance and crank them into the scheduler. Nov 13 01:16:00 well, I've added vmstat to testbuilder and re-run test :) Nov 13 01:16:32 I hope it will finish in 10-12 hours Nov 13 01:17:36 Jay7, I look forward to seeing the results. Nov 13 01:18:47 see you tomorrow :) Nov 13 01:18:50 time to sleep Nov 13 01:22:21 nn Jay7 Nov 13 01:57:51 interesting message: *** %n in writable segment detected *** Nov 13 02:22:20 hmm **** ENDING LOGGING AT Sat Nov 13 02:59:57 2010