**** BEGIN LOGGING AT Fri Jun 27 02:59:56 2008 Jun 27 05:49:24 morning Jun 27 05:50:05 morning hrw Jun 27 05:50:18 hrw: did you buy a phone yet? Jun 27 05:51:03 rwhitby: moved that to August - now too many things related to buying new flat Jun 27 05:51:30 hrw: did you ever see the white android phone with keyboard? Jun 27 05:51:52 rwhitby: phisycal not. emulated yes Jun 27 05:52:38 rwhitby: the problem with android is that it is still unknown for me what apps will be available. Jun 27 05:53:02 http://gizmodo.com/gadgets/android-hardware-in-the-wild/google-android-prototype-in-the-wild-334909.php would work for me Jun 27 05:53:30 (form-factor-wise0 Jun 27 05:54:41 I am planning toshiba g900 - n810 formfactor Jun 27 05:56:03 I've never found an email client better than chatter on the treo650 for pure ease of being able to quickly scroll through, read, delete, respond to, messages using one hand when driving on a bumpy road. Jun 27 05:56:40 (or standing on a bus holding onto a strap with the other hand) Jun 27 05:57:02 (or walking down the street holding a briefcase in the other hand) Jun 27 05:58:39 I need complex pim Jun 27 06:26:38 morning Jun 27 10:29:04 hi Jun 27 10:29:29 I have a few patch applied in my local database which I do not want to push upstream yet Jun 27 10:30:39 now I have seen I forgot to add a patch file from another package to the repo. is there a way that I only push the file addition back to OE and leave the other patches alone? Jun 27 10:36:51 rschuster1, mtn commit filename? Jun 27 10:40:10 Crofton|work: yeah, but when I 'mtn push' it will send my other patches, too. this is what I want to prevent Jun 27 10:40:20 ah Jun 27 10:40:29 I already committed other patches to my local db Jun 27 10:40:36 I wonder if push lets you only send sertiona certs Jun 27 10:40:39 hmmm Jun 27 10:41:29 I don't see how to do that either :( Jun 27 11:11:10 03thebohemian 07org.oe.dev * r45ae19dc... 10/ (47 files in 3 dirs): (log message trimmed) Jun 27 11:11:10 Removal of midpath 0.1, addition of midpath 0.3 rc1 Jun 27 11:11:10 midpath-alsa 0.1: Removed. Jun 27 11:11:10 midpath-cldc-native 0.1: Removed. Jun 27 11:11:10 midpath-cldc-sdl 0.1: Removed. Jun 27 11:11:11 midpath-cldc-x11 0.1: Removed. Jun 27 11:11:13 midpath-cldc 0.1: Removed. Jun 27 11:11:15 03thebohemian 07org.oe.dev * rbf2c0729... 10/ (3 files in 3 dirs): Jun 27 11:11:19 Remove uses of midpath 0.1 and replace with what is needed for 0.3. Jun 27 11:11:21 preferred-om-2008-versions: Updated to midpath 0.3 rc1 Jun 27 11:11:23 openmoko: Added midpath preference. Jun 27 11:11:25 03thebohemian 07org.oe.dev * ra41ea502... 10/ (3 files in 2 dirs): Jun 27 11:11:27 midpath-maemo 0.2+0.3rc1: Added pnum 0 to patch. Jun 27 11:11:29 midpath-openmoko 0.2+0.3rc1: Added pnum 0 to patch. Jun 27 11:11:31 03thebohemian 07org.oe.dev * rd288108d... 10/ (2 files in 2 dirs): cacao 0.99.1: Added missing patch file to repository. Jun 27 11:11:36 03thebohemian 07org.oe.dev * rbb13fad5... 10/ (1 conf/distro/chinook-compat.conf): chinook-compat: Added libsdl-mixer version preference to 1.2.6. Jun 27 11:11:39 03thebohemian 07org.oe.dev * r39dd9b91... 10/ (1 packages/midpath/files/midpath-launcher-j2se): midpath: Allow overriding the JAVA executable in start script Jun 27 11:11:44 03thebohemian 07org.oe.dev * r7bad576c... 10/ (5 files in 2 dirs): jamvm: Lowered update-alternatives to 5 (lesser than cacao). Jun 27 11:16:05 03thebohemian 07org.oe.dev * rd5ba7835... 10/ (1 packages/cacao/cacao_0.98+hg20080519.bb): cacao 0.98+hg20080519: Removed superfluous \ from SRC_URI. Jun 27 11:33:07 hi Jun 27 11:33:43 I am trying to compile gdal-1.5.2 but bitbake fails http://pastebin.ca/1057112 Jun 27 11:34:18 I had a look at config.log http://pastebin.ca/1057113 Jun 27 11:34:47 but nothing bad is jumping on me Jun 27 11:36:10 and that is log.do_configure: http://pastebin.ca/1057116 Jun 27 11:38:05 can anyone hint me what to look for? Jun 27 12:14:10 ah, the error message should read: "Found 'CROSS COMPILE Badness' in config.log'" Jun 27 12:14:32 that would point one to the problem directly ;) Jun 27 12:28:34 Hi folks! Jun 27 12:29:07 does anyone here have a copy of busybox with a stty applet that has line support ? Jun 27 12:29:17 (for arm) Jun 27 12:33:00 FYI, http://beagleboard.blogspot.com/2008/06/linuxtag-2008-winners.html Jun 27 12:33:08 Congrats rschuster1 and florian Jun 27 12:33:46 Crofton: thanks... Jun 27 12:33:50 Crofton: and shoragan Jun 27 12:33:52 * florian knew already Jun 27 12:34:05 * shoragan too :) Jun 27 12:34:12 can only match the easy nicks to names :) Jun 27 12:34:18 Crofton: Yippieh!! Jun 27 12:34:45 rschuster1, hehe Jun 27 12:34:52 yay for beagleboard :) Jun 27 12:34:56 #oe must have stuffed the ballot box :) Jun 27 12:35:14 Crofton|work: stopit with your hanging chad ways :-) Jun 27 12:36:05 * * OE Bug 4010 has been RESOLVED (FIXED) by thebohemian(AT)gmx.net Jun 27 12:36:07 * * midpath-gtk-0.1-autobuild Jun 27 12:36:09 * * http://bugs.openembedded.net/show_bug.cgi?id=4010 Jun 27 12:36:26 no more hanging chad, now they just pre-program the results in the voting machine Jun 27 12:36:40 Crofton|work: well at least that saves money Jun 27 12:36:42 Mugabe would have no problems if he used US voting machines Jun 27 12:37:30 * XorA wonders where his SD cards are Jun 27 12:37:59 wouldnt it be too obvious if Zimbabwe voted for a guy named "g.w. bush"? ;) Jun 27 12:42:30 thats jyst mugabes nick name :-) Jun 27 12:44:44 Crofton|work: I think we reached a vague consensus on the commit policy for git Jun 27 12:44:52 Crofton|work: looking back over emails Jun 27 12:52:35 XorA, yeah Jun 27 12:52:46 the problem is there is no strong consensus Jun 27 12:52:59 * XorA fetches his hammer Jun 27 12:53:15 creating policy in the absence of consensus won't work Jun 27 12:53:38 I am hopeful that people doing large changes can do more testing before commiting to .dev Jun 27 12:53:53 but, my opinion is we need to finda way to make that happen Jun 27 12:54:16 koen would prefer strict review, others prefer business as usual Jun 27 12:55:03 If you want to scare away new contributors then choose 'strict review' ;) Jun 27 12:55:18 florian, agreed Jun 27 12:55:58 florian: Well, I like review. The problem is that it sucks *a lot* resources from the devs Jun 27 12:56:17 That's like restricting write access to a few people... and the rest does the same like outsiders: submitting patches. Jun 27 12:56:25 the resource problem is key Jun 27 12:56:27 florian: For the XO support I'm working on a git branch right now and will send out a patchset for review.. Jun 27 12:56:35 at least u-boot has people almost paid to work on it Jun 27 12:56:47 Same for kernel Jun 27 12:56:54 stefan_schmidt: That's fine if there are intrusive changes, but in fact that's what we have .dev for. Jun 27 12:56:56 You want have the resources for this Jun 27 12:57:08 BUT, we need to keep a stable dev environemnt for people doing near bleeding edge work Jun 27 12:57:19 * Crofton|work knows that is a ridiculous statement Jun 27 12:57:32 florian: But people also use .dev for their daily stuff and it hurts when this breaks Jun 27 12:57:49 Crofton|work: I second this Jun 27 12:58:02 re Jun 27 12:58:03 the ridiculous statement :) Jun 27 12:58:15 Crofton|work: ;) Jun 27 12:58:25 * rschuster1 knows people are looking at me when it comes to big patches :| Jun 27 12:58:42 stefan_schmidt: That's why we need a branch where things go in we know not to break things. That is much easier than reviewing every piece that comes in. Jun 27 12:58:48 basically, we can only do beagle work in .dev, unless we backport a lot of stuff to .stable Jun 27 12:58:53 hrw: wb Jun 27 12:58:57 and we do not want to destabilize .stable Jun 27 12:59:20 florian: so the proposla XorA made about splitting. Jun 27 12:59:24 I'm hopeful we can set up an autobuilder you can submit beanches to Jun 27 12:59:47 and validate them against "know good, supported" distro/machine combinations Jun 27 12:59:51 Crofton|work: That would be quite nice indeed. Jun 27 12:59:55 this word take loads of cpu Jun 27 12:59:59 Crofton|work: yeah, testing every commit. :) Jun 27 13:00:06 build bot ...... Jun 27 13:00:15 stefan_schmidt, that would also be awesome Jun 27 13:00:15 Crofton|work: Still people need to *think* before they commit. And review helps here. Jun 27 13:00:34 I am thinking of something where you could submit proposed changes for automatic testing Jun 27 13:01:00 Crofton|work: hmm, why not test yourself? Jun 27 13:01:08 Crofton|work: Yes, but CPUs are cheap... and you can do this on arbitary cheap devices on a dsl line. No need for a computing center for this task. Jun 27 13:01:12 Crofton|work: Or do you mean for more sitros machines, etc..? Jun 27 13:01:19 stefan_schmidt, exactly Jun 27 13:01:22 ok Jun 27 13:01:45 People are a bit angstrom or openmoko centric, indeed. Jun 27 13:02:03 exactly Jun 27 13:02:21 The most important thing is to stay realistig: what can we do and what is going to fail. Jun 27 13:02:28 florian, for some CPU's are expensive Jun 27 13:02:32 florian: ack Jun 27 13:02:39 florian, that too :) Jun 27 13:02:45 Autobuilder: realistic, but maintenance work. Jun 27 13:02:55 Review every commit: Not going to happen. Jun 27 13:03:10 where can I find the configs used to build the downloadable angstrom images Jun 27 13:03:11 ? Jun 27 13:03:11 Test your own changes before comminting: Needed Jun 27 13:03:29 stefan_schmidt: right Jun 27 13:04:10 The fun start for stuff like bbclasses, glibc and gcc Jun 27 13:04:16 Who is able to review this? Jun 27 13:04:25 Only the people that commit anyway? Jun 27 13:04:39 where can I find the configs used to build the downloadable angstrom images ? Jun 27 13:04:54 Here *could* MAINTAINERS come into the game, but I fear OE does not have the power for this Jun 27 13:05:32 stefan_schmidt: That's a good question... these bits would be the most important for a review. But the people who do these bits are ususally the most busy ones. Jun 27 13:06:07 florian: Indeed, take RP as example. He will not have enough time to review stuff for the classes. Jun 27 13:06:17 Still he mostly is the one who commit there anyway. Jun 27 13:06:19 Spyro: Not sure if they are available, but that would bea question for the angstrom development mailinglist. Jun 27 13:06:31 k Jun 27 13:07:09 The idea of maintainership would be that people copuld commit to the stuff they maintain without review Jun 27 13:07:23 Hoping they would not break anything. Jun 27 13:08:06 If you like to commit to somewhere else, get a review from the maintainer. If you don't get any feedback within 8 days commit anyway. Jun 27 13:08:13 yes, good point... requesting a review for the maintainers own stuff would be nasty Jun 27 13:08:26 The last point is hard, but would help to keep the thing rolling Jun 27 13:08:52 But that are only ideas, no clue if that would fit together for a complete policy Jun 27 13:18:44 anyone ever manged to bitbake gdal? Jun 27 13:19:00 any suggestions on how to get a minimal python build? Jun 27 13:19:10 bitbake python seems to pull a lot of stuff (x11 related too) Jun 27 13:22:06 what's your problem with that? Jun 27 13:22:09 time to build? Jun 27 13:22:12 or packages itself? Jun 27 13:22:26 if the latter, don't worry, the packages are fine granular. Jun 27 13:29:46 what is the reason that do_rootfs failes because of "Cannot find package gdal." Jun 27 13:30:04 let me guess - this is library? Jun 27 13:30:10 why can't it find gdal? where does it look for? Jun 27 13:30:29 gdal is a tool chain with libs and apps Jun 27 13:31:23 DESCRIPTION = "GDAL is a translator library for raster geospatial data formats" Jun 27 13:31:25 that one? Jun 27 13:31:42 yes, but it has toll apps too Jun 27 13:32:01 morning Jun 27 13:32:06 hi thesing Jun 27 13:32:31 kiozen: but package is libgdal* - right? Jun 27 13:33:52 hrw: no just gdal_1.4.2.bb Jun 27 13:34:24 thats recipe Jun 27 13:34:35 what are results of building it? which packages? Jun 27 13:35:43 hrw: well it seems to build but creates some wired path in build/tmp/work/armv5te-angstrom-linux-uclibcgnueabi/gdal-1.4.2-r0/image Jun 27 13:36:16 the results are in build/tmp/work/armv5te-angstrom-linux-uclibcgnueabi/gdal-1.4.2-r0/image/home/oeichler/local/OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-uclibcgnueabi/gdal-1.4.2-r0/image/usr Jun 27 13:36:37 kiozen: which *packages* does it generate Jun 27 13:37:11 hrw: hm, no packages around :/ Jun 27 13:37:56 ah wait here is a package gdal-dev_1.4.2-r0_armv5te.ipk Jun 27 13:38:32 and gdal_1.4.2? Jun 27 13:38:52 nope Jun 27 13:39:17 second one is gdal-dbg_1.4.2-r0_armv5te.ipk Jun 27 13:39:36 let me guess - static library? Jun 27 13:40:19 shouldn't be Jun 27 13:40:48 but it is? Jun 27 13:41:42 those results in the length path aren't, currently have no tool availabel to look into the ipk Jun 27 13:43:28 no dpkg in system? Jun 27 13:44:30 find says no Jun 27 13:44:57 but I work on it, moment ... Jun 27 13:55:35 hrw: those ipk seem to be empty :( (only 682 bytes) Jun 27 13:57:09 getting gdal to work, will cause celebrations on #htc-linux Jun 27 13:57:17 this is an issue for month now Jun 27 14:03:09 ~seen rschuster Jun 27 14:03:12 rschuster was last seen on IRC in channel #oe, 4d 4h 24m 55s ago, saying: 'zecke: got my mail regarding the e.V. registration?'. Jun 27 14:03:47 mickeyl, a lot of the source URIs seem to point to extremely slow servers Jun 27 14:04:01 getting readline is ETA at 3:29 ;-) Jun 27 14:04:02 hrw: it lies he was here earlier :-) Jun 27 14:04:22 but I guess I'll just leave it to download the sources for the weekend, so it's not a biggie. will continue after the weekend. thanks mickeyl Jun 27 14:04:27 *nod* Jun 27 14:04:28 np Jun 27 14:04:36 once you have the sources, next time it'll be ok Jun 27 14:04:50 * czr_ nods Jun 27 14:05:36 someone here still builds software for os2008? Jun 27 14:06:15 btw, is anyone aware of a "burn-in" program suitable for embedded use? Jun 27 14:06:19 hrw: who was doing that? Jun 27 14:06:28 (other than while true; do : done Jun 27 14:08:37 gm Jun 27 14:09:00 Laibsch: ping Jun 27 14:10:42 * ant|work is trying to mark oebug 4393 as duplicate of oebug 1755...no way with IE6 Jun 27 14:10:46 keesj: there is DISTRO="chinook-compat" for it Jun 27 14:11:03 keesj: but it has some lack of maintaince so not build good packages anymore Jun 27 14:12:19 now diabolo is out I guess things will get more stable , less external repositories Jun 27 14:12:36 will see Jun 27 14:12:39 and maemo will be a more rewarding platform to create packages for Jun 27 14:13:07 keesj: I refuse to use maemo sdk Jun 27 14:13:18 I am going to help a little on MUD but really focus more on mamona/beagle for now Jun 27 14:13:31 ah right - you are one of beagle winners Jun 27 14:13:48 !!! Jun 27 14:14:07 keesj: ??? Jun 27 14:15:17 hrw: I gave up trying to build for os2008 Jun 27 14:15:29 hrw: the list of packages I had to hack got longer and longer Jun 27 14:15:47 hrw: so many naming differences and config differences :-( Jun 27 14:18:38 * ant|work is wondering which bug is to reopen (4393 dupes two closed bugs: 1755 and 1767) Jun 27 14:19:24 my fault I did not check the closed bugs too before submitting... Jun 27 14:19:37 yes, I am a happy winner . Jun 27 14:20:39 hrw: any other ideas on how to get this gdal thing working ? Jun 27 14:21:43 kiozen: nope - would have to build it and I do not have angstrom tree working now Jun 27 14:22:20 * ant|work sees new mysql related bugs...1866 and 2780, jeez, what a mess Jun 27 14:22:29 ok, thanks anyway :) Jun 27 14:26:04 Laibsch: qawanted for mysql: it looks like all these bugs have been solved in 4.1.22 (http://bugs.mysql.com/bug.php?id=18888) Jun 27 14:27:32 Last time I tried it did not build for me Jun 27 14:27:43 If you can get it to build, we can have it in OE Jun 27 14:27:52 ok Jun 27 14:28:37 strangely I cannot mark my own bugs as dupes...doh, will try later with firefox Jun 27 14:40:33 Are you sure that is a dupe? Jun 27 14:40:37 I don't think so Jun 27 14:40:48 The bugs that were marked as fixed were indeed fixed Jun 27 14:42:45 Laibsch: http://tinderbox.openembedded.net/packages/mysql/ Jun 27 14:46:14 so? Jun 27 14:46:30 Without even looking: The bugs were fixed before tinderbox even started Jun 27 14:46:56 on june 24th I got the same error Jun 27 14:46:57 If you can get 4.1.22 to compile, great Jun 27 14:47:50 BTW mysql is a "nasty" side effect of 'buildall' when you bitbake gpsdrive Jun 27 14:48:21 for my zaurus, no real reason to build it... Jun 27 14:50:44 and for anything with less than 256mb too (optimistic !) Jun 27 14:58:56 03hrw 07org.oe.dev * r77f81ea1... 10/ (1 conf/distro/chinook-compat.conf): chinook-compat: make it more Maemo compatible Jun 27 15:20:08 ant|work: I tried building 4.1.22 Jun 27 15:20:19 And as I remembered it was not a trivial upgrade Jun 27 15:20:26 Here is what I did Jun 27 15:20:41 cp 4.1.18.bb 4.1.22.bb Jun 27 15:20:55 remove two patches from SRC_URI that did not apply cleanly Jun 27 15:21:28 The build still fails and I neither have the time nor skill to troubleshoot it further Jun 27 15:21:50 4.1.18 was the latest trivial update to mysql Jun 27 15:21:57 I tried several others Jun 27 15:22:11 what about the autofoo.patch? Jun 27 15:23:48 I blindly removed it Jun 27 15:23:56 As I said, very simple Jun 27 15:24:13 It is probably not too complicated to get 4.1.22 working Jun 27 15:24:42 Patches very welcome Jun 27 15:25:30 strange that mysql-native builds... Jun 27 15:25:51 Why? Jun 27 15:26:00 4.1.18 or 4.1.22? Jun 27 15:26:06 4.1.18 Jun 27 15:26:17 so, then it is not strange at all Jun 27 15:26:38 DEPENDS += "ncurses mysql-native" Jun 27 15:27:08 and native: require mysql_${PV}.bb Jun 27 15:29:08 Laibsch: silly me....do_build 0.00 Succeeded Jun 27 16:08:11 03mickeyl 07org.oe.dev * r28c74aa2... 10/ (1 packages/freesmartphone/frameworkd_git.bb): frameworkd git needs python-shell now Jun 27 16:13:39 03hrw 07org.oe.dev * r2e1af81a... 10/ (1 packages/cmake/cmake-native_2.6.0.bb): cmake-native: added 2.6.0 (from Poky) Jun 27 16:13:44 03hrw 07org.oe.dev * r8eb2a350... 10/ (1 classes/cmake.bbclass): cmake.bbclass: use cross-compilation support with 2.6.0 (from Poky) Jun 27 16:38:40 CIA-48: flood... Jun 27 16:40:33 03hrw 07org.oe.dev * r637db793... 10/ (1 conf/checksums.ini): checksums.ini: sync with Poky Jun 27 16:40:38 03hrw 07org.oe.dev * r26df3657... 10/ (3 files in 2 dirs): libsyncml: added 0.4.6 (from Poky) Jun 27 16:40:44 03hrw 07org.oe.dev * re03c4a58... 10/ (12 files in 2 dirs): opensync: added 0.36 release (from Poky) Jun 27 16:40:50 03hrw 07org.oe.dev * rad2d314d... 10/ (1 packages/qemu/qemu_0.9.1.bb): qemu 0.9.1: fix SRC_URI (from Poky) Jun 27 16:40:55 03hrw 07org.oe.dev * r4d14289e... 10/ (8 files in 4 dirs): dbus-glib: added 0.76 (from Poky) Jun 27 16:41:00 03hrw 07org.oe.dev * r9c5de560... 10/ (1 classes/image.bbclass): image.bbclass: Make sure DEPLOY_DIR_IMAGE exists before running image generation (from Poky) Jun 27 16:41:05 03hrw 07org.oe.dev * r59450215... 10/ (3 files in 3 dirs): distcc: ship fixed desktop file to get QA happy (from Poky) Jun 27 17:12:17 anyone knows how to find out why a package ends in my build even though i am pretty sure it's not a dependency of anything else and i didn't explicitly request it ? Jun 27 17:15:31 nerochiaro: there should be a bitbake switch to print the dependency tree of Jun 27 17:16:03 nerochiaro: http://wiki.openembedded.net/index.php/Category:FAQ Jun 27 17:16:20 More specifically http://wiki.openembedded.net/index.php/Inspect_DEPENDS Jun 27 17:17:07 Laibsch: looking into that, thanks Jun 27 17:19:53 bye Jun 27 17:24:06 Laibsch: it's not exactly what i need. this will tell me the dependencies of $package, but i want to know what $package is dependency of Jun 27 17:24:47 ? Jun 27 17:25:10 You want to know why $package1 is being built although you say "bitbake $package2? Jun 27 17:25:11 i have package X, and what to know if there are other packages that depend on package X Jun 27 17:25:31 That is not your original question Jun 27 17:26:44 well, i need to know that because package X is being built as part of my image, and i don't know why. i suppose it's being built becuause it's a dependency of something else, and thus i wanted to know the above Jun 27 17:27:11 sorry if i wasn't clear initially Jun 27 17:43:04 Well, I figured that much Jun 27 17:43:11 and the answer remains as given Jun 27 17:43:23 "bitbake -g $nameofimageyouwantbuilt" Jun 27 17:43:38 then "less *.dot" Jun 27 18:23:09 03crofton 07org.oe.dev * r31de530b... 10/ (1 packages/images/beagleboard-demo-image.bb): Jun 27 18:23:09 beagleboard-demo-image : Temporarily remove irssi until we figure out why Jun 27 18:23:09 it is not building. Jun 27 18:43:28 03mickeyl 07org.oe.dev * rb9727041... 10/ (3 files in 2 dirs): linux-openmoko-devel git remove HXD8 which no longer compiles due to touchscreen fixes in s3c2410_ts.c Jun 27 20:18:14 03crofton 07org.oe.dev * rc7403af1... 10/ (1 packages/images/beagleboard-demo-image.bb): Jun 27 20:18:14 beagleboard-demo-image : Temporarily comment out gnumeric and gimp until they Jun 27 20:18:14 build. Jun 27 20:48:49 Wanna Play Fun RPG game ? /q me or join #HypeRPG] Jun 27 21:31:06 * * OE Bug 4150 has been RESOLVED (FIXED) by mdarland(AT)pager.net Jun 27 21:31:08 * * avahi-daemon needs user 'avahi' Jun 27 21:31:10 * * http://bugs.openembedded.net/show_bug.cgi?id=4150 Jun 27 21:33:05 * * OE Bug 4151 has been RESOLVED (FIXED) by mdarland(AT)pager.net Jun 27 21:33:07 * * dbus needs user 'messagebus' Jun 27 21:33:09 * * http://bugs.openembedded.net/show_bug.cgi?id=4151 Jun 27 23:06:02 if building for multiple machines should TMPDIR contain MACHINE to be safe? It seems like most dirs in build are split into machine's where needed, but not 'rootfs' **** ENDING LOGGING AT Sat Jun 28 02:59:57 2008