**** BEGIN LOGGING AT Tue Dec 16 02:59:57 2008 Dec 16 04:55:28 about: NOTE: Handling BitBake files: \ (2831/4977) [56 %]http://svn.projects.openmoko.org/svnroot/python-openmoko/python-gsmd: (Not a valid URL) Dec 16 04:55:35 I am using latest git as on Fedora 10 Dec 16 04:55:41 and bitbake 1.8.10 Dec 16 06:50:26 Bah Dec 16 06:50:34 Can't delete an old branch in our git :( Dec 16 06:50:39 $ git push origin :trini/canadian-sdk Dec 16 06:50:39 deleting 'refs/heads/trini/canadian-sdk' Dec 16 06:50:39 *** Deleting a branch is not allowed in this repository Dec 16 06:50:39 error: hooks/update exited with error code 1 Dec 16 06:50:39 error: hook declined to update refs/heads/trini/canadian-sdk Dec 16 06:50:40 ng refs/heads/trini/canadian-sdk hook declined Dec 16 06:50:42 error: failed to push to 'git@git.openembedded.net:openembedded' Dec 16 08:12:10 03Jeremy Lainé  07org.openembedded.dev * r6f6a8710f9 10openembedded.git/packages/librfid/librfid_svn.bb: librfid: mark PACKAGE_ARCH as "boc01" for boc01 Dec 16 08:42:08 03Stefan Schmidt  07org.openembedded.dev * r8547e72e87 10openembedded.git/packages/connman/ (connman_0.1.bb connman_0.2.bb): Dec 16 08:42:08 connman: Remove default -1 from connman 0.1 and 0.2 Dec 16 08:42:08 om-settings was the only customer of connman so far. Made sure that an update is Dec 16 08:42:08 fine with them. Dec 16 08:42:09 03Stefan Schmidt  07org.openembedded.dev * ra086801d72 10openembedded.git/ (conf/checksums.ini packages/connman/connman_0.4.bb): connman_0.4: Add neweset connman release Dec 16 08:42:13 03Stefan Schmidt  07org.openembedded.dev * r894656c664 10openembedded.git/ (conf/checksums.ini packages/connman/connman_0.2.bb): connman: Add 0.2 release Dec 16 08:42:16 03Stefan Schmidt  07org.openembedded.dev * r133c4a479c 10openembedded.git/conf/distro/include/preferred-om-2008-versions.inc: preferred-om-2008-versions.inc: Make connman 0.4 the preferred version Dec 16 08:42:19 03Stefan Schmidt  07org.openembedded.dev * rd4cc081669 10openembedded.git/packages/tasks/task-fso-compliance.bb: task-fso-compliance: Put connman in every image that likes to be fso-compliant Dec 16 08:47:46 03Koen Kooi  07org.openembedded.dev * r19d4137e9d 10openembedded.git/packages/apache2/ (apache2-native_2.2.3.bb apache2_2.2.3.bb): apache2-native: fix staging of pcre helper binaries Dec 16 08:47:47 03Koen Kooi  07org.openembedded.dev * rfde85c6fed 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev Dec 16 10:12:57 morning Dec 16 10:27:26 morning Dec 16 10:52:15 good morning Dec 16 11:37:09 Hi all. I keep seeing in some arm-assembly lowlevel_init.S lines like this: ldr r0, =SOME_MACRO. Should not this be done with mov r0, #SOME_MACRO, because preprocessor will change SOME_MACORO to some hex number anyway, for example 0x12345678? Dec 16 11:40:36 * hrw lack idea Dec 16 11:43:30 drasko: no Dec 16 11:43:50 pb__, no? Dec 16 11:44:03 indeed. Dec 16 11:44:06 :) Dec 16 11:44:21 ok, why Dec 16 11:44:29 "mov r0, #0x12345678" will fail: you can't load such wide constants as immediates Dec 16 11:44:47 and, for constants that are small enough to load as immediates, the assembler will convert "ldr r0, =MACRO" into "mov r0, #MACRO" automatically. Dec 16 11:45:17 so, that is the only reason why everybody is loading adresses in this form? Dec 16 11:45:46 I'm not sure about the only reason, but it is certainly one reason. Dec 16 11:46:14 pb__, thanks a lot! I was wondering for some time... Dec 16 11:47:27 maybe it also open way for future arm cores which will handle loading immediates such big Dec 16 11:47:30 etc Dec 16 11:48:03 it isn't really a core limitation, more to do with the instruction set. Dec 16 11:48:20 if your instructions are a fixed size (in this case, 32 bits) then there is only a finite amount of space available to encode the immediate operand. Dec 16 11:48:39 clearly it wouldn't be feasible to load a full 32 bit immediate since then there would be no room for any bits to indicate what type of instruction it was. Dec 16 11:50:47 ok Dec 16 11:50:52 also, I just found a nice explanation here : http://www.coranac.com/tonc/text/asm.htm Dec 16 11:51:01 but if one day we will get arm64.. Dec 16 11:51:12 under Restricted use of immediate values subchapter Dec 16 11:52:42 it says: This means that you can create values like 255 (n=255, r=0) and 0x06000000 (n=6, r=4 (remember, rotate-right)). However, 511 and 0x06010000 are still invalid because the bit-patterns can't fit into one byte. Dec 16 11:53:56 right Dec 16 11:54:13 so, it is not only about "how big the number is", but "how it looks like", because : Instead of just taking the 12 bits for a single integer, what the designers have done is split it into an 8bit number (n) and a 4bit rotation field (r). Dec 16 11:54:36 where v = n ror 2*r Dec 16 11:54:39 cool Dec 16 12:08:06 mickey|zzZZzz: wakeup! :D Dec 16 12:09:17 ~curse gentoo Dec 16 12:09:18 May you be reincarnated as a Windows XP administrator, gentoo ! Dec 16 13:24:59 03Koen Kooi  07org.openembedded.dev * r070a04a29a 10openembedded.git/packages/kexecboot/linux-kexecboot.inc: Dec 16 13:24:59 linux-kexecboot.inc: disable modules and debugging to make kernel smaller Dec 16 13:24:59 * most devices can reuse the defconfig of their 'proper' kernel now Dec 16 13:25:22 03Koen Kooi  07org.openembedded.dev * r3ce30387a6 10openembedded.git/packages/angstrom/angstrom-x11-base-depends.bb: angstrom-x11-base-depends: bump PR Dec 16 13:26:53 mickey|zzZZzz: wakeup Dec 16 13:27:47 mmmh Dec 16 13:27:48 whatsup Dec 16 13:30:40 03Koen Kooi  07org.openembedded.dev * r19fb84f81c 10openembedded.git/packages/linux/ (12 files in 3 dirs): linux-omap git: move to 2.6.28rc8, this makes usb OTG work properly (even cable detection works!) Dec 16 13:33:04 hi. I want to build opengl ES, how to do this? Dec 16 13:34:04 I mean build OpenGL ES in oe, in order to support qt opengl. Dec 16 13:35:39 for which device? Dec 16 13:36:00 there are many devices with opengl es and each of them use own version Dec 16 13:36:26 Hello Dec 16 13:36:49 beagle board !]thanks. Dec 16 13:36:57 I'm having problems with one of our (SHR) package Dec 16 13:37:39 Its bb recipe defines a pkg_postinst() but it seems not be executed at first image boot Dec 16 13:37:49 favor: search in packages/ Dec 16 13:38:17 Should the packages to be configured at the first boot of an image be specified somewhere or is it processed automatically by oe at image creation ? Dec 16 13:38:53 hrw: do you mean searching OpenGL ES bb file in packages? Dec 16 13:40:25 yees Dec 16 13:41:15 hrw: let me try on! Dec 16 13:41:48 ptitjes: postinst on boot depends on postinst at image creation time. if OE has been successfully processed the postinst at image creation time, it will be marked as installed. if not, it will be configured at runtime on first boot. you can blacklist image-creation-postinst by using the D hack, see some postinst for reference. Dec 16 13:45:52 mickeyl: postinst processed at image creation are executed in chroot ? Dec 16 13:48:15 mickeyl: http://pastebin.ca/1286838 is change to uicmoc4-native to build it on gentoo Dec 16 13:48:22 mickeyl: can you review? Dec 16 13:49:27 Dec 16 13:52:46 03Koen Kooi  07org.openembedded.dev * rb3a5d14572 10openembedded.git/ (conf/checksums.ini packages/i2c-tools/i2c-tools_3.0.2.bb): i2c-tools: update to 3.0.2 Dec 16 13:53:57 ptitjes: no, we're using ipkg parameters that can do it in offline mode (no chroot necessary) Dec 16 13:54:01 hrw: let me check Dec 16 13:56:06 mickeyl: so having a 'mkdir -p -m 755 /var/db' in a postinst could not work if that postinst is executed at image creation... am I right ? Dec 16 13:56:32 ptitjes: ${D}/var/db/ will work Dec 16 13:56:50 Much thank mickeyl! Dec 16 13:56:58 and hrw! Dec 16 14:05:08 hrw: looks ok Dec 16 14:06:14 fine Dec 16 14:06:34 will have to make build with it on debian/ubuntu and then push Dec 16 14:08:13 good Dec 16 14:08:16 bbiab, meeteing Dec 16 14:08:16 zecke: ping Dec 16 14:08:55 pong Dec 16 14:10:01 zecke: I didn't reliase you'd make release tarballs/tagged things :) Dec 16 14:10:18 zecke: I'd say release, although Koen's bug report about _ chars is puzzling Dec 16 14:13:52 RP: I did, I will send a mail then Dec 16 14:17:01 hi! Dec 16 14:22:25 anybody knows if exits any meta-toolchain.bb receipt ready to include kernel development (build folder) files into sdk tar.gz? I've tried to include kernel-dev package, however only .config and System.map files are included into the sdk Dec 16 14:23:36 Is anyone working on xulrunner ? I start to make a .bb based on firefox. I wonder If I am reinventing the wheel ... Dec 16 14:26:10 have I to modify kernel-dev package? Dec 16 14:29:12 starox: I build xulrunner with my xulrunner_1.8_1.3.bb (http://pastebin.ca/1286847) Dec 16 14:29:39 The one in bugs.oe.org ? Dec 16 14:30:02 no Dec 16 14:31:35 sarnoso: I builded 1.9.xxx for arm but I'm having QA problems. At least, the binaries works on arm. Dec 16 14:31:50 So I'll continue ... Dec 16 14:44:41 Re Dec 16 14:45:12 I still got my problem with pkg_postinst() Dec 16 14:45:40 Should I create directories with install in the install() function ? Dec 16 14:45:56 instead of doing it in postinst ? Dec 16 14:47:07 * * OE Bug 4938 has been created by david.hagood(AT)aeroflex.com Dec 16 14:47:08 * * build of git-native fails Dec 16 14:47:11 * * http://bugs.openembedded.net/show_bug.cgi?id=4938 Dec 16 15:21:25 03Stanislav Brabec  07org.openembedded.dev * r6c3031554f 10openembedded.git/packages/tcltk/ (tcl-native_8.4.11.bb tk-native_8.4.11.bb): tcl-native, tk-native: New packages. Needed for compilation of geda/pcb. Dec 16 15:21:34 03Stanislav Brabec  07org.openembedded.dev * r9096bdf34d 10openembedded.git/ (3 files in 2 dirs): geda/pcb: New package. Dec 16 15:25:27 don't suppose someone can change the devmem2 package url to http://www.lartmaker.nl/lartware/port/devmem2.c , since abcsinc.com probably won;t be hosting that much longer Dec 16 15:51:10 question: Dec 16 15:51:14 when I see this: http://pastebin.com/d58de7fa8 Dec 16 15:51:21 what is the first thing to check? Dec 16 15:51:27 I see no logging Dec 16 15:51:43 but running configure manualaly (with options from recipe) gives errors Dec 16 15:52:07 http://pastebin.com/d35fbd6b0 Dec 16 17:59:58 anyone else having problems with gpe-info segfaulting? Dec 16 18:04:19 udovdh: what is your host system Dec 16 18:04:48 I am on fedora 10 Dec 16 18:05:00 the build issue for navit has been solved in the mean time Dec 16 18:05:11 alright what was the problem Dec 16 18:05:15 had to clean out the downloads dir and svn for navit Dec 16 18:05:21 then stuff went better Dec 16 18:05:30 heh sometimes it does Dec 16 18:05:32 ok Dec 16 18:05:32 so maybe incomplete svn co Dec 16 18:05:34 enjoy Dec 16 18:05:37 thanks Dec 16 18:05:52 now I am trying to build navit on the host machine, but that is a #navit issue Dec 16 18:06:09 thank you for reading Dec 16 18:10:26 03Khem Raj  07org.openembedded.dev * r6598aacc23 10openembedded.git/packages/devmem2/devmem2.bb: devmem2.bb: Update URI to point to new location Dec 16 18:10:50 prpplague: I took care of it thanks for notifying it Dec 16 18:11:13 khem: thanks Dec 16 18:19:37 is oe repo fine? i've serious inflate inconsistency when i do git-pull and it's reproducible Dec 16 18:19:40 oops hello Dec 16 18:20:10 GNUtoo: has beeen ok for me Dec 16 18:20:21 ok i'll re-clone the repo Dec 16 18:20:46 thanks Dec 16 18:29:08 03Koen Kooi  07org.openembedded.dev * rc62f407f01 10openembedded.git/packages/ffmpeg/ffmpeg_git.bb: ffmpeg git: bump SRCREV, armv7a neon patches are now upstream Dec 16 18:29:09 03Koen Kooi  07org.openembedded.dev * r1108b299c0 10openembedded.git/packages/ffmpeg/omapfbplay_git.bb: omapfbplay: bump PR for ffmpeg change Dec 16 18:29:10 03Koen Kooi  07org.openembedded.dev * rf6174e94d2 10openembedded.git/packages/openmax/libomxil-bellagio_0.9.0.bb: libomxil-bellagio: bump PR for ffmpeg change Dec 16 18:29:14 03Koen Kooi  07org.openembedded.dev * r93bd3cf319 10openembedded.git/ (3 files in 3 dirs): gst-ffmpeg: add 0.10.6 for ffmpeg change Dec 16 18:42:52 03Koen Kooi  07org.openembedded.dev * r7499b55e8b 10openembedded.git/packages/ffmpeg/ffmpeg_svn.bb: ffmpeg: update svn version to match git build Dec 16 19:39:09 how can I override a SRCREV which is in sane-srcrev.inc ? Dec 16 19:39:38 all my efforts seem to be mulled by bitbake Dec 16 19:44:21 khem, go ahead on OSK Dec 16 19:44:27 did you boot that kernel? Dec 16 19:44:30 yes Dec 16 19:44:39 I have had that change for a while Dec 16 19:46:50 Can I change where OE dumps its final image and kernel files? Some environment variable I can set? Dec 16 19:48:07 03Khem Raj  07org.openembedded.dev * rd950bb7d72 10openembedded.git/conf/machine/omap5912osk.conf: omap5912osk.conf: Use linux-omap for PREFERRED_PROVIDER_virtual/kernel Dec 16 19:58:43 I want to change build/angstrom/deploy/glibc/images/x86/ to $PREFIX/images/ Dec 16 20:00:37 zta: worse comes to worse could you symlink Dec 16 20:01:17 not a bad idea =) Dec 16 20:04:26 I should too come to think... its a hassle to navigate Dec 16 20:20:31 I'm experimenting with a build environment that suites my needs better. Dec 16 20:21:24 like what Dec 16 20:21:31 though I'm not sure what I've acomplished so far. I wanted to keep the oe installation in /opt/oe/openembedded, but the build still goes to /opt/oe/build, which doesn't make /opt/ very "/opt'ish". Dec 16 20:21:49 Zta:Zta or change the DEPLOY_DIR_IMAGE vcariable Dec 16 20:22:23 nik0n, thanks Dec 16 20:22:29 check angstrom.inc for DEPLOY_DIR and DEPLOY_DIR_IMAGE Dec 16 20:22:38 super Dec 16 20:24:50 archae0pteryx, this is my setup: http://codepad.org/eIyprIOs Dec 16 20:25:45 the idea is first of all, that I have a separate project dir that I can commit into my own subversion repos. Secondly, I can add custom pacakges and images easily. Dec 16 20:26:46 The common tree is available to all my images, and the x86 tree is a x86-target image. Dec 16 20:27:20 Should I build to arm, would I simply make an arm directory, and run ". ./setup arm" and Dec 16 20:27:53 run bitbake =) Dec 16 20:28:04 without modifying any configuration files to change target Dec 16 20:28:21 i have something like that but its ./setup device distro Dec 16 20:28:50 it does all the config changing and fixes the tftproot Dec 16 20:28:55 yeah, "device" is a better term than "architecture"; "pc" instead of "x86" maybe. Dec 16 20:33:18 If only I could find a way to have openembedded' own packages build in /opt/oe/build and my own packages build in ~/oe/build.. Dec 16 20:36:41 Ok. I don't really have a problem with my user packages getting built to the same place, nor do I build for 2 different architectures Dec 16 20:36:59 I made a vendor branch of OE and put my stuff on top of that WRT version control Dec 16 20:37:12 I use stable not dev Dec 16 20:37:37 I think I use stable too (git clone git://git.openembedded.net/openembedded) Dec 16 20:38:10 Not familiar with git unfortunately Dec 16 20:38:10 * timtimred works out of a fork that consists of dev/old dev :) Dec 16 20:38:22 archae0pteryx, neither am I =) Dec 16 20:38:28 lol too bad Dec 16 20:38:49 well I bet git also has a concept of vendor branches, it's supposed to be better than subversion right Dec 16 20:39:10 I don't use git at home; I use svn. Dec 16 20:39:19 And I'm not changing =) Dec 16 20:39:43 Anyway; the version control system is not the issue. Dec 16 20:40:49 stable is the org.openembedded.stable branch Dec 16 20:40:53 if you aren't on that, you're on dev Dec 16 20:41:18 And, if you added some magic to your recipes only, you could have output go elsewhere Dec 16 20:41:29 Now, I'm not sure how well things like image recipes would deal with it Dec 16 20:41:47 But if you just want ipks elsewhere and you'll install live on the target later Dec 16 20:42:09 in each of your recipes, change DEPLOY_DIR Dec 16 20:42:30 (And again, these packages won't be available to images without further mucking around) Dec 16 20:42:35 hey Tartarus you had that mipsel build issue ...glibc/fini_array.... did you get that working? Dec 16 20:42:52 timtimred, yes, khem fixed that by disabling the hash=gnu stuff for mips Dec 16 20:43:03 oh where do i make that change? Dec 16 20:43:09 sec Dec 16 20:43:18 thanks!! Dec 16 20:43:30 http://gitweb.openembedded.net/?p=openembedded.git;a=commit;h=c4722a23469a7c5a3597671efb4003227266f977 Dec 16 20:43:38 most awesome. Dec 16 20:43:46 Tartarus, I think what I want is different TMPDIR for standard oe and my own build. Dec 16 20:44:02 and DEPLOY_DIR too. Dec 16 20:44:04 Zta, nope, tmpdir is where all build stuff is Dec 16 20:44:13 Tartarus, exactly. Dec 16 20:44:14 If you modify tmpdir you won't have a compiler Dec 16 20:44:44 isnt installing it in some other place covered? Dec 16 20:44:47 Really OE only supports source overlays, not build output overlays Dec 16 20:44:56 Ok. Dec 16 20:45:11 timtimred, I don't know. I hadn't seen anything implying that but i might have missed it Dec 16 20:45:47 I've installed elsewhere. Don't know if it'll bite me later. Dec 16 20:46:11 Wait, installing what? Dec 16 20:46:16 building Dec 16 20:46:17 OE sources and bitbake can live anywhere Dec 16 20:46:28 installing the toolchain Dec 16 20:46:29 you can build everything into one single dir, named whatever you want Dec 16 20:46:32 yes thats what i meant :) Dec 16 20:46:32 (I hate 'tmp') Dec 16 20:46:47 (tmp is misleading =) Dec 16 20:47:09 But you can't have everything from upstream OE go into say, tmp-upstream and everything from say myadditions into tmp-myadditions Dec 16 20:47:22 hm.. Dec 16 20:47:24 s/go into/build inside of/ Dec 16 20:47:36 unless you just have two different installs in the places you want them in? Dec 16 20:47:39 Which is what I mean by source overlays are supported, but build ones are not Dec 16 20:47:51 Tartarus, I understand what you mena. Dec 16 20:47:53 *mean Dec 16 20:47:55 ok Dec 16 20:48:01 thanks =) Dec 16 20:48:03 Now, you can kind-of fake it out Dec 16 20:48:10 By building all upstream stuff into an SDK Dec 16 20:48:31 then building your stuff, into a diff TMPDIR, with an external toolchain, of what you built as an SDK of just upstream stuff Dec 16 20:48:47 That will only build a small amount of upstream stuff into your TMPDIR Dec 16 20:50:03 That's what I want, I suppose. Dec 16 20:50:10 I'm trying it right now. Dec 16 20:53:19 Why didn't I try this earlier... Dec 16 20:56:25 03Koen Kooi  07org.openembedded.dev * rc6c9ec01e8 10openembedded.git/contrib/angstrom/build-feeds.sh: angstrom feed builder: add bluez-hcidump Dec 16 20:56:30 I didn't know you could do an SDK Dec 16 20:56:36 03Koen Kooi  07org.openembedded.dev * r72b39d002c 10openembedded.git/ (3 files in 2 dirs): Dec 16 20:56:36 libusb1: add 1.0.0 release, libusb is EOL Dec 16 20:56:36 * the libusb site says "As of December 2008, libusb-1.0 is the current stable branch. Developers are encouraged to port their applications." Dec 16 20:56:48 that's my whole point =) Dec 16 20:57:55 ..though it seems stuff is getting downloaded again now that I've changed my DEV's TMPDIR from my SDK's TMPDIR. Dec 16 20:58:32 automake is being downloaded. I consider this approach a failure =) Dec 16 21:00:38 Yes, you'll have to do more :) Dec 16 21:00:54 Like tell it to assume you have automake, and anything else you don't want built in that other TMPDIR Dec 16 21:01:04 Really, I'm not understanding why you want to do what you want to do :) Dec 16 21:01:05 my oe source dir is not related to tmpdir Dec 16 21:01:09 But I think it will be fairly painful Dec 16 21:01:38 Tartarus, ok. What I need is a true build overlay, but I'm not the one to make it =) Dec 16 21:01:44 thanks anyway. Dec 16 21:01:53 k Dec 16 21:02:42 But I want to do it because I like a clean separation between SDK and code -- between toolchains and your sources+output. Dec 16 21:03:37 Yeah Dec 16 21:03:46 gcc doens't live in my home dir either =) Dec 16 21:03:48 personally I'm OK with that just being distinct at the source level Dec 16 21:03:55 ie my OE sources, upstream OE sources Dec 16 21:04:10 yes. Dec 16 22:03:14 re Dec 16 22:46:20 03Koen Kooi  07org.openembedded.dev * r2f94ddc365 10openembedded.git/packages/efl1/ (evas.inc evas_svn.bb): evas: ARM_INSTRUCTION_SET = "arm" Dec 16 23:07:50 yay works thx Tartarus. Dec 16 23:08:09 damn now i have to worry about mipsel just for one ddevice again :) Dec 16 23:22:33 hi mickeyl Dec 16 23:22:45 hey flor Dec 16 23:22:47 ian Dec 16 23:31:51 03Koen Kooi  07org.openembedded.dev * rb1e4a92526 10openembedded.git/conf/checksums.ini: Dec 16 23:31:51 checksums.ini: add samba checksum Dec 16 23:31:51 * add the &#$*&*#$*# checksum when adding a new recipe, damnit Dec 16 23:33:20 03Michael 'Mickey' Lauer  07org.openembedded.dev * r02bd45e7ba 10openembedded.git/ (4 files in 2 dirs): vala: update to 0.5.3 Dec 16 23:35:55 mickeyl: you only needed 7 letters to represent that :) Dec 16 23:37:49 heh Dec 16 23:40:25 03Koen Kooi  07org.openembedded.dev * rd530720d06 10openembedded.git/packages/libffi/libffi_2.0+gcc4.3.2.bb: Dec 16 23:40:25 libffi: add hack to build libffi on softfp machines Dec 16 23:40:25 * see http://lists.o-hand.com/poky/0583.html for a problem description Dec 16 23:40:50 I have this little script which adds the new ones for me Dec 16 23:41:44 hello, if you were building for an x86 target, can you make oe use the hosts gcc instead of building a cross compiler? Dec 16 23:43:29 you could but might not be straight forward Dec 16 23:44:22 azeey: any particular reason to have that ? Dec 16 23:44:51 just to save time, i don't need to build gcc if I have it on my system since the target is also x86 Dec 16 23:45:34 people have used external toolchains you can look into that Dec 16 23:45:45 your problem falls into that category Dec 16 23:46:38 k Dec 16 23:46:41 thanks Dec 16 23:46:44 The toolchain isn't just the compiler - it also involves the C library and other such things - unless you are compiling on your target machine, it might be to your advantage to tune the toolchain specifically for your target hardware - not all x86s are created alike, you know Dec 16 23:47:07 03Koen Kooi  07org.openembedded.dev * r0dfe32f06e 10openembedded.git/packages/samba/samba.inc: samba.inc: 3.2.5 doesn't need the mv hack, so don't error out on failure Dec 16 23:48:36 ya, i understand, building gcc libc and binutils takes a long time, I just wanted to test OE and see if i can use it before i tune my system for production Dec 16 23:49:12 i will just have to wait Dec 16 23:50:07 CosmicPenguin: for x86 it really wont matter much Dec 16 23:52:07 well - if you want to use OE for x86 targets, then clearly you have a plan in mind - you could just use an existing distribution if you really wanted to\ Dec 16 23:54:20 actually, I am currently using a distribution, but I read suggestions that it would be better to use OE. http://bec-systems.com/web/content/view/63/9/ Dec 16 23:54:21 I would agree Dec 16 23:56:14 Depending on your situation, OE has its advantages for sure Dec 16 23:56:32 oe seemed to make things easier to maintain and support Dec 16 23:56:43 03Koen Kooi  07org.openembedded.dev * r285265c787 10openembedded.git/contrib/angstrom/build-feeds.sh: angstrom feed builder: add squeakvm Dec 16 23:56:45 it depends on how much work you want to do Dec 16 23:57:00 using, say debian has its advantages if you don't want to rebuild random packages Dec 16 23:57:24 but OE has the advantage when it comes to maintaining your own custom code Dec 16 23:57:39 ya but you will have to maintain the version of debian Dec 17 00:00:36 thanks for the input guys. **** ENDING LOGGING AT Wed Dec 17 02:59:57 2008