**** BEGIN LOGGING AT Fri Feb 26 02:59:57 2010 Feb 26 06:08:24 hi,all Feb 26 06:15:49 I want use another compiler not default one in oe, how can I set it? Feb 26 08:06:01 Tartarus: saw your q on why calamari: answer is very simple: this is what already was there; likewise added this board and called it calamari, the pcb actually says "mpc8536 dev-sys-calamari" (btw the ppc boards on the denx website also seem to have names like e.g. canyonlands) Feb 26 08:08:41 personally I don't care too much about names, so I stayed with what there is (actually the MAINTAINERS file mentions likewise as maintainer for calamari, although i am pretty sure he does not have such a board any more, as the one he used to work with is now on my desk) Feb 26 08:11:57 i am getting the following error on bitbake powertop Feb 26 08:11:58 http://pastebin.com/TQt8wXWd Feb 26 08:12:08 kindly help me with this Feb 26 08:14:25 i am getting the following error on bitbake powertop Feb 26 08:14:31 http://pastebin.com/TQt8wXWd Feb 26 08:14:37 kindly help me with this Feb 26 08:17:23 repeating yourself won't get you more attention only lower your chances to get an answer. repeating yourself won't get you more attention only lower your chances to get an answer. Feb 26 08:34:28 Spyzer, this should probably read self.cooker.bb_cache.sync() Feb 26 08:34:54 Spyzer, (i.e. "self." is missing) Feb 26 08:35:40 Spyzer, which package did you try to build when you got that? Feb 26 08:36:24 so what should i do then, and sorry @dm8tbr, actually my internet connection is freaking out a bit so i thought that my original chat didn't reach u that's why i doubled it Feb 26 08:36:27 well i am getting that on anything like bitbake opie-image or bitbake powertop or bitbake brickout etc Feb 26 08:36:47 is my bitbake installation corrupt? Feb 26 08:38:58 Spyzer, no, it's not corrupt (cooker just isn't set in the second if in parse_next()) Feb 26 08:40:55 so pls tell me that how should i set it, should i go my openembedded directory structure and do something in there? Feb 26 08:52:24 03Klaus Kurzmann  07org.openembedded.dev * r17c4962b31 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: Feb 26 08:52:24 sane-srcrevs-fso.inc: bump revs for FSO2 and related stuff Feb 26 08:52:24 Signed-off-by: Klaus Kurzmann Feb 26 08:52:24 03Klaus Kurzmann  07org.openembedded.dev * r7e3f2b98f8 10openembedded.git/recipes/freesmartphone/fsodatad_git.bb: Feb 26 08:52:24 fsodatad_git.bb: sync PV with reality Feb 26 08:52:24 Signed-off-by: Klaus Kurzmann Feb 26 08:52:25 03Klaus Kurzmann  07org.openembedded.dev * rd035790daa 10openembedded.git/recipes/freesmartphone/libfsoframework_git.bb: Feb 26 08:52:25 libfsoframework_git.bb: sync PV with reality Feb 26 08:52:26 Signed-off-by: Klaus Kurzmann Feb 26 08:52:28 03Klaus Kurzmann  07org.openembedded.dev * r7f254d4a55 10openembedded.git/recipes/freesmartphone/libfsoresource_git.bb: Feb 26 08:52:28 libfsoresource_git.bb: sync PV with reality Feb 26 08:52:28 Signed-off-by: Klaus Kurzmann Feb 26 08:52:28 03Klaus Kurzmann  07org.openembedded.dev * rf069027968 10openembedded.git/recipes/freesmartphone/libfsobasics_git.bb: Feb 26 08:52:28 libfsobasics_git.bb: sync PV with reality Feb 26 08:52:29 Signed-off-by: Klaus Kurzmann Feb 26 08:52:31 03Klaus Kurzmann  07org.openembedded.dev * rdb9d481e50 10openembedded.git/recipes/freesmartphone/fsousaged_git.bb: Feb 26 08:52:31 fsousaged_git.bb: sync PV with reality Feb 26 08:52:31 Signed-off-by: Klaus Kurzmann Feb 26 08:52:47 03Klaus Kurzmann  07org.openembedded.dev * rf6a581d295 10openembedded.git/recipes/freesmartphone/fso-abyss_git.bb: Feb 26 08:52:48 fso-abyss_git.bb: sync PV with reality Feb 26 08:52:48 Signed-off-by: Klaus Kurzmann Feb 26 08:53:11 Spyzer, it's odd how you got there. What exactly did you do Feb 26 08:57:03 well actually i "copied" bitbake and my oe directory to some other system, changed the environment variables accordingly and then installed bitbake from the directory and then when i tried to do a bitbake opie-image in my build directory i got that Feb 26 08:57:03 error Feb 26 09:02:06 i was using an old version of bitbake, just now i installed a new one Feb 26 09:02:34 and am getting the folowing error on bitbake powertop Feb 26 09:02:54 http://pastebin.com/yHHBAgFq Feb 26 09:07:07 03Klaus Kurzmann  07org.openembedded.dev * rc0729ac69d 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: Feb 26 09:07:07 sane-srcrevs-fso.inc: actually really bump FSO2 and fix broken rev for libfso-glib Feb 26 09:07:07 Signed-off-by: Klaus Kurzmann Feb 26 09:09:24 good morning Feb 26 09:12:37 pls anyone help me Feb 26 09:12:40 TypeError: __init__() takes exactly 3 arguments (2 given) Feb 26 09:13:44 i am getting this on bitbake opie-image Feb 26 09:16:19 Spyzer: what do you mean 'installed bitbake from '? Feb 26 09:16:58 i mean i didn't use the binaries from a path but did ./setup install Feb 26 09:17:11 ah ha Feb 26 09:17:43 fyi, opie-image is today broken (new opkg / libopkg)...I'll have a look later Feb 26 09:18:03 http://tinderbox.openembedded.net/public/logs/task/5150048.txt Feb 26 09:20:34 Spyzer: try just untarring bitbake-1.8.18 , don't install it Feb 26 09:22:12 ok i'll try Feb 26 09:23:35 yes it worked Feb 26 09:25:08 re Feb 26 09:25:11 or rather morning Feb 26 09:25:38 someone remember name of tool which gives informations about input device capabilities? amount of keys, names of them etc Feb 26 09:26:20 florian: you may know Feb 26 09:26:25 florian: name of tool which gives informations about input device capabilities? amount of keys, names of them etc Feb 26 09:28:15 found: evtest Feb 26 09:39:21 good morning Feb 26 09:39:58 hrw: Thes are the tools you need less than once a year :) Feb 26 09:40:32 morning Feb 26 09:42:22 hi mlip Feb 26 09:42:27 hi mickey|office Feb 26 09:43:28 florian: yep Feb 26 09:44:43 hi RP Feb 26 10:11:52 morning florian , hi hrw Feb 26 10:14:06 hi mickey|office Feb 26 10:14:24 hi pb_ Feb 26 10:26:56 eh..bloody question: it seems *libc recipes need a custom do_stage, isn't? Feb 26 10:28:03 (I have hard time with klibc which is now using install_headers) Feb 26 10:29:06 ant_work: I don't think there's any reason why libc fundamentally needs a custom do_stage. Feb 26 10:31:05 well, glibc and eglibc have it in a a *stage.inc file Feb 26 10:31:25 yeah, I think that's more historical than anything else. Feb 26 10:31:55 glibc was one of the first recipes we had, and it's also one of the most complex so nobody has ever been very keen to refactor it. Feb 26 10:33:16 hm..for klibc cleaning would seem easier Feb 26 10:33:22 just twolines in do_stage Feb 26 10:33:26 oe_runmake install Feb 26 10:33:28 cp '${STAGING_DIR_TARGET}/bin/klcc' '${CROSS_DIR}/bin/${TARGET_PREFIX}klcc' Feb 26 10:34:28 ah, that klcc thing will be a pain. I think you might do better to put that in its own recipe. Feb 26 10:34:53 if you didn't have that, you could just convert the whole thing to new style staging. Feb 26 10:35:45 pb_: what's stopping me is that klibc still needs linux headers in do_configure. Now in .git there is a patch to use headers_install (the sanitized) but just in the install phase Feb 26 10:36:18 I don't know how difficult it would be to hack the build script in order to use those same sanitized headers Feb 26 10:37:55 finally, the issue I have compiling against klibc is that e.g. mtd-user.h and mtd-abi.h are not staged Feb 26 10:38:18 so I provide a copy of those in the sources Feb 26 10:39:07 but afaik headers_install should install these userspace headers, isn't? Feb 26 10:39:39 03Thomas Zimmermann  07org.openembedded.dev * r7d7cad11af 10openembedded.git/recipes/webkit/ (webkit-efl/fix-build-with-newer-evas.patch webkit-efl_git.bb): Feb 26 10:39:39 webkit-efl: fix build for evas > 46211 Feb 26 10:39:39 * Evas_Point is defined in Evas.h since EFL_SRCREV 46211 Feb 26 10:39:39 Signed-off-by: Thomas Zimmermann Feb 26 10:39:56 Dunno. How are they handled for the other libcs? Feb 26 10:42:25 hm..I had no-issues with uclibc and glibc Feb 26 10:42:39 juklibc just exposed mtd.h Feb 26 10:43:27 pb_: I fear Mr. Anvin has no more time for klibc... :/ Feb 26 10:53:43 Am I correct in assuming OE has no KDE bitbake recipies? Feb 26 10:54:06 pb_: I was wrong, hpa is alive! http://www.zytor.com/pipermail/klibc/2010-February/002481.html Feb 26 10:54:51 james_l: yes, you are correct Feb 26 10:57:26 KDE isn't really embedded, is it? :+ Feb 26 10:59:10 Romke: for some people atom+ion+4GBram+ssd is embedded Feb 26 11:01:34 Well, at least according to the image builder for angstrom there is x11 w/gnome, so I was curious. Feb 26 11:02:21 we would like kde recipes, no-one did them yet Feb 26 11:03:43 XorA: no wonder, who would want to mess with cmake? ;) Feb 26 11:06:18 morning pb_ Feb 26 11:07:02 Jin^eLD: not me ever again :-) Feb 26 11:07:10 =) Feb 26 11:07:26 hmkay Feb 26 11:07:39 well Feb 26 11:07:54 It looks like I have to add support for my SBC6020 to OE :( Feb 26 11:07:56 which means work Feb 26 11:08:06 work is good, it means $$$ Feb 26 11:08:18 yeah Feb 26 11:08:52 but it also means i need to find out how to change, for instance, the kernel version used by oe/angstrom Feb 26 11:09:38 and adding a new machine type, namely the at91sam9g20 Feb 26 11:10:32 Romke: not at91sam9g20 but sbc6020 Feb 26 11:10:40 Romke: machine names are device names not cpu names Feb 26 11:10:51 oh Feb 26 11:10:56 well, sbc6020 then Feb 26 11:11:09 Romke: and for kernel it is easy - linux_2.6.33.bb is what you want to run ;) Feb 26 11:11:18 mkay Feb 26 11:11:40 my to-find-out list gets bigger and bigger :) Feb 26 11:12:29 Romke: I think at91sam9g20ek.conf is in oe.dev already Feb 26 11:12:52 yes, it is Feb 26 11:13:30 nice Feb 26 11:13:38 which old version am I using then :+ Feb 26 11:14:12 stable/2009 does not have it, but you could take the few updates from the dev branch if you want to use stable Feb 26 11:14:20 that's what I am doing btw, for this machine actually Feb 26 11:14:25 oh Feb 26 11:14:28 nice :) Feb 26 11:14:45 it's been supported for quite some time Feb 26 11:15:08 at91 boards are usually easy to maintain Feb 26 11:15:14 hmm.. my local.conf states 'angstrom 2008.1' Feb 26 11:15:19 most of support stuff is in mainline Feb 26 11:16:05 so it's as easy as grabbing the machine config file and kernel recipe from the dev branch? Feb 26 11:16:36 Romke: ok, for sbc6020 you probably need some patches as .33 does not know it Feb 26 11:17:09 well, i'm only planning to use the CF card, serial ports and ethernet devices Feb 26 11:17:27 good morning Feb 26 11:17:53 i don't care about the gpio's and stuff Feb 26 11:17:56 Romke: http://www.kaeilos.com/?q=at91sam9g20 Feb 26 11:18:52 -> lunch Feb 26 11:18:55 yeah Feb 26 11:18:56 me too Feb 26 11:19:08 lots of things to find out after lunch :) Feb 26 11:19:22 much to read :P Feb 26 11:20:38 mckoan: hi, are you going to Nurembergh ? Feb 26 11:20:54 recalcati: yes on Monday morning Feb 26 11:21:11 recalcati: but now I'm going to lunch :-D Feb 26 11:21:46 good lunch Feb 26 11:23:08 mckoan: at91sam9g20 != sbc6020 Feb 26 11:51:26 i have a little question to git send-email. if i want to send a patch to the ml list what do i have to set --in-reply-to= ? Feb 26 11:51:42 if fresh thread then nothing Feb 26 11:51:49 ok thx Feb 26 11:51:50 leave it blank if you're not following up to a cover letter or something. Feb 26 11:51:57 if you are sending patch as reply to mail then message-id of that mail Feb 26 11:52:22 ok Feb 26 12:19:12 it would be handy to be able to go to http://git.openembedded.org/openembedded directly and not have to sprinkle cgit.cgi between dir and host. Could we perhaps have a Feb 26 12:19:18 RewriteRule ^/(openembedded|bitbake)$ /cgit.cgi/$1 [QSA,L] Feb 26 12:19:33 or something to that effect for the git.oe.org vhost? Feb 26 13:17:31 morning all Feb 26 13:17:37 hi RP Feb 26 13:21:45 * hrw|gone -> off Feb 26 13:24:40 ja Feb 26 13:24:43 oops wrong window Feb 26 13:43:03 03Koen Kooi  07org.openembedded.dev * r8b932e307a 10openembedded.git/recipes/u-boot/ (u-boot-git/Cortex-A8-erratum-725233.diff u-boot_git.bb): u-boot git: add patch to fix Cortex-A8 erratum 725233 for beagleboard Feb 26 13:43:17 * Romke kicks tsjsieb's ass Feb 26 13:43:26 angstrom is running :D Feb 26 13:43:56 :D very good! Feb 26 13:44:14 well, i still need to do some work Feb 26 13:44:21 only 1 ethernet port is working for instance Feb 26 13:44:33 which is enough for my purpose Feb 26 13:44:51 but it's nicer to have both working :) Feb 26 14:46:02 Would a latex (texlive really) .bb be welcome? Feb 26 14:47:36 recalcati: ping Feb 26 14:49:48 ehi Feb 26 14:49:56 I come to nurmerg Feb 26 14:50:06 I come to nurmberg Feb 26 14:50:29 I'm looking the map in order to remember where to sleep Feb 26 14:56:05 !seen hopsnbarley Feb 26 14:56:16 or what's the bot command for that? Feb 26 14:58:06 ~seen hopsnbarley Feb 26 14:58:07 hs anyone seen HopsNBarley lately? Feb 26 14:58:10 hopsnbarley was last seen on IRC in channel #edev, 77d 15h 11m 12s ago, saying: 'anybody know how to get the CE dev environment set up? i can't even get the VS2005 trial to install :('. Feb 26 14:58:28 77 days... Feb 26 14:58:31 hm Feb 26 15:07:37 are there any other openprotium guys besides him? Feb 26 15:19:53 03Koen Kooi  07org.openembedded.dev * r9bfbf7b8c4 10openembedded.git/recipes/hal/hal.inc: hal: add missing dep in consolekit Feb 26 15:21:34 bei welchem rootfs? Feb 26 15:22:20 oops wrong window Feb 26 15:22:21 :) Feb 26 15:38:48 I am sure this is something I am doing wrong but for some reason my recipe is using the system g++ instead of my arm cross compiler...all of the other recipes seem to work correct just this one is going this.. Feb 26 15:42:42 nevarrie: did you create the recipe yourself? Feb 26 15:43:04 yes... Feb 26 15:43:33 for what software is it btw? if you have something with a braindead make script, for example like poco, it could also get difficult Feb 26 15:44:03 what build scripts is your sw using? autotools or custom make files? Feb 26 15:45:12 it is for a qt4e app that has a special make process...it makes it through the qmake process just fine but the make pare is where it is blowing up on now such instructions...I thought it was an mthumb issue at first then I found it was using the wrong g++ Feb 26 15:49:14 I nevver had to mess with qmake, so just a wild guess Feb 26 15:49:21 did you do an inherit qmake in your recipe? Feb 26 15:49:54 not 'inherit qmake' but 'inherit qt4e' rather Feb 26 15:49:57 re Feb 26 15:50:33 I have inherit qmake2 qt4e Feb 26 15:59:18 should I know have inherit qt4e and not qmake or qmake2 on my inherit? Feb 26 16:14:48 qt4e already inherits proper qmake(2) class so no need to do it Feb 26 16:34:52 03Martin Jansa  07org.openembedded.dev * r1f412ddc30 10openembedded.git/recipes/xorg-xserver/ (6 files in 3 dirs): Feb 26 16:34:52 xserver-xorg: move older versions to obsolete (1.7.1 stays only because is used in preferred-xorg-versions-X11R7.5.inc, but it should move to 1.7.4 too) Feb 26 16:34:52 Signed-off-by: Martin Jansa Feb 26 16:34:53 03Martin Jansa  07org.openembedded.dev * r86d2251aef 10openembedded.git/recipes/mplayer/mplayer_svn.bb: Feb 26 16:34:53 mplayer_svn: increase DEFAULT_PREFERENCE for shr, om-gta02 will stay with mplayer_git because of glamo patches in that git repo Feb 26 16:34:53 Signed-off-by: Martin Jansa Feb 26 16:34:54 03Martin Jansa  07org.openembedded.dev * rd62366f71b 10openembedded.git/recipes/xorg-xserver/ (5 files): Feb 26 16:34:54 xserver-xorg: use INC_PR where I forget to add it Feb 26 16:34:55 Signed-off-by: Martin Jansa Feb 26 16:34:58 03Martin Jansa  07org.openembedded.dev * r8c23367968 10openembedded.git/recipes/xorg-xserver/ (3 files): Feb 26 16:34:58 xserver-xorg: move config manager logic to .inc, remove hal dependency where not specified by new DISTRO_XORG_CONFIG_MANAGER option Feb 26 16:34:58 * distribution can specify DISTRO_XORG_CONFIG_MANAGER to select between Feb 26 16:34:58 hal, udev, no dynamic input device detection (only xorg.conf) Feb 26 16:34:58 * fix RRECOMMENDS spelling and remove hal from it Feb 26 16:34:59 * use CONFIG_MANAGER_OPTION in 1.7.4 and 1.8 RC1 (git) version Feb 26 16:35:00 Signed-off-by: Martin Jansa Feb 26 16:35:00 03Martin Jansa  07org.openembedded.dev * r37e863e6a3 10openembedded.git/recipes/mesa/mesa-dri_git.bb: Feb 26 16:35:01 mesa-dri_git: disable gallium also for om-gta01 Feb 26 16:38:01 hrw thanks...I will try workign that way... Feb 26 16:55:39 JaMa: fetch mail Feb 26 16:58:59 * nevarrie just finally got qt-everywhere-opensource-src-4.6.2 build now i need to figure out how to get qt-everywhere-commercial-4.6. to work with OE... Feb 26 17:00:15 hrw: thanks.. but that's not really what I want.. I need that uImage in .tar.gz (and remove it only from other FSTYPES) Feb 26 17:00:38 so you need to hack Feb 26 17:01:11 hrw: something like that hack I sent? Feb 26 17:01:54 I would rather move just /boot/uImage outside and move it back - less copying Feb 26 17:02:33 hrw: I would use ROOTFS_POSTPROCESS_COMMAND for that ROOTFS-no-boot creation and then forgot to remove it after finish Feb 26 17:02:52 no, no Feb 26 17:02:57 JaMa: in you IMAGECMD hacks Feb 26 17:03:00 hrw: ah good point, thans.. if nobody comes with even better solution I'll use that Feb 26 17:03:14 s/thans/thanks/ Feb 26 17:03:30 consider moving those IMAGECMD to your image recipe and make them om-gta01 only Feb 26 17:03:36 should also work Feb 26 17:03:46 hrw: ok Feb 26 17:04:00 and my umbaumba-wonders-image will still have kernel in ubifs Feb 26 17:04:43 yes, I don't want to mess with your umbaumba Feb 26 17:05:34 ;dDD Feb 26 17:10:54 ERROR: Error, lockfile path does not exist!: /u/slug/slugos/tmp/work/armv5teb-linux-gnueabi/gpsd-2.39-r0/packages-split Feb 26 17:11:30 Any ideas where I should look to fix this? Feb 26 17:12:06 tmp/pkgdata Feb 26 17:12:52 mwester: I've seen this with recipes which changed ARCH (ie because they lost some machinge specific config) and something like this always helped find tmp/pkgdata/ -name gpsd\* -exec rm -rf {} \; Feb 26 17:13:21 odd - it built gpsd-2.90-r4.0, but now seems to want to grub about in the old version's work dir... Feb 26 17:14:21 mwester: strange, i updated the recipe and had no problems at all (using the commited one) Feb 26 17:14:59 :( it broke on both my build machines, I suspect it will build fine once I clean out the remnants of the old one. Feb 26 17:15:33 mb something distrospecific ? Feb 26 17:16:10 mlip2: imho some class/bitbake bug looking for wrong dir (seen that in angstrom as well as shr) Feb 26 17:16:20 Yeah, it looks like it. It moved from nslube-linux-gnueabi to armv5teb-linux-gnueabi Feb 26 17:16:51 The latter is where it probably should be, so let me clean out my pkgdata as hrw and JaMa suggest, and see it that resolves it. Feb 26 17:17:47 mwester: besides this, you are not using om-gta01 (hopefully) Feb 26 17:18:01 have a nice rest of day Feb 26 17:18:01 as i am still (now) working on some recipe the re-integrates the onboard gps Feb 26 17:18:41 No, not om-gta01 --- mine sit on the shelf here, gathering dust due to lack of time. :( Feb 26 17:18:44 mlip2: I'm not sure but imho om-gta01 gpsd is now hanlded by fso-gpsd as well as on om-gta02 Feb 26 17:19:06 mlip2: so maybe that stuff is not used anymore.. Feb 26 17:19:25 oh, so maybe i could stop creating a recipe for it ^ Feb 26 17:20:33 /me pops in over here too Feb 26 17:21:05 So, om-gta01 stuff Feb 26 17:21:08 Does it use uboot? Feb 26 17:22:43 yes Feb 26 17:23:48 OK, good Feb 26 17:23:51 so my suggestion could work :) Feb 26 17:32:48 Tartarus: Tom Rini? more info on list.. Feb 26 17:32:56 I'm going home, bye all Feb 26 17:36:51 Yes, that's me Feb 26 17:44:03 btw Feb 26 17:44:16 mwester: i hope you dont want to use python with gpsd 2.39 (and the new .inc file) Feb 26 17:45:14 i think the configuration flag is missing (which is not required by 2.90 anymore, as it is auto-detected) Feb 26 18:37:24 03Michael Lippautz  07org.openembedded.dev * r0da188d1ae 10openembedded.git/recipes/gpsd/gpsd-device-config_0.bb: Feb 26 18:37:24 gpsd-device-config: Adds new recipe Feb 26 18:37:24 * Reintegrates machine specific gps configuration using overrides Feb 26 18:37:24 (formerly specified in the main gpsd recipe) Feb 26 18:37:25 Signed-off-by: Koen Kooi Feb 26 18:37:25 03Michael Lippautz  07org.openembedded.dev * r2bc60c84b4 10openembedded.git/recipes/fastcgi/fastcgi_2.4.0.bb: Feb 26 18:37:26 fastcgi: Move to new staging Feb 26 18:37:26 Signed-off-by: Koen Kooi Feb 26 18:37:33 03Michael Lippautz  07org.openembedded.dev * r324d53b4b8 10openembedded.git/recipes/python/python-paste_1.7.2.bb: Feb 26 18:37:33 python-paste: Add new recipe Feb 26 18:37:34 Signed-off-by: Koen Kooi Feb 26 18:38:05 03Tom Rini  07org.openembedded.dev * r4372ec830a 10openembedded.git/recipes/busybox/busybox.inc: (log message trimmed) Feb 26 18:38:06 busybox: If FEATURE_SUID=y, ship a SUID busybox, bump PR Feb 26 18:38:06 A number of applets will select FEATURE_SUID, and then not work unless Feb 26 18:38:16 the busybox binary is SUID. We switch from a "let the users decide" to Feb 26 18:38:16 "let the users opt-out". Feb 26 18:38:16 Signed-off-by: Tom Rini Feb 26 18:38:16 Acked-by: Marcin Juszkiewicz Feb 26 18:56:21 denix ? Feb 26 18:56:54 yeah Feb 26 18:57:06 What is your magic for breaking pstaging outside of $TMPDIR? :) Feb 26 18:57:14 We use the everloving crap out of that Feb 26 18:57:18 kernels are fine Feb 26 18:57:42 Only issues have been do_deploy stuff that's not saved in pstaging, w/o a shellfile Feb 26 19:00:02 magic? :) Feb 26 19:00:31 heh Feb 26 19:01:16 consider this command: sed s#${TMPDIR}#${PSTAGE_TMPDIR_STAGE}# Feb 26 19:02:52 or actually, echo $srcfile | sed s#${TMPDIR}#${PSTAGE_TMPDIR_STAGE}# Feb 26 19:02:56 er? Feb 26 19:03:14 Talking about relocation stuff now? Feb 26 19:03:18 denix: still that damned bits ;P Feb 26 19:03:43 ant__: yeah Feb 26 19:04:49 to make it work before, I had to change TMPDIR to DEPLOY_DIR in the above sed command, since my DEPLOY_DIR is outside of TMPDIR and pstage is within DEPLOY_DIR Feb 26 19:04:58 Ah, hm Feb 26 19:04:58 sec Feb 26 19:05:29 it worked before for me, because all the stagefile_shell were called with the files in deploy/pstage Feb 26 19:05:59 denix: Nope, I don't have any changes for letting us do: Feb 26 19:06:07 DEPLOY_DIR_PSTAGE = "${OEDIR}/cached-builds" Feb 26 19:06:13 but recently Tartarus made a change to also call stagefile_shell with the files still in ${S}, i.e. TMPDIR and it doesn't work anymore Feb 26 19:06:17 And OEDIR is set to something in the shell and passed in via EXTRAWHITE Feb 26 19:06:56 Note that stagefile_shell does need to be called with a full path Feb 26 19:07:05 I found that out when fixing device trees Feb 26 19:07:35 ie stagefile_shell ${DEPLOY_DIR_IMAGES}/whatever Feb 26 19:08:01 right, but you also call stagefile_shell ${S}/whatever Feb 26 19:08:06 yeah Feb 26 19:08:08 that's also fine here Feb 26 19:08:34 what / how are you setting DEPLOY_DIR_PSTAGE ? Feb 26 19:09:04 03Bernhard Guillon  07org.openembedded.dev * r9ac4de8c01 10openembedded.git/recipes/linux/ (linux/atngw100/defconfig linux_2.6.29.bb): Feb 26 19:09:05 linux: atngw100 - add bridge module to defconfig, bump PR Feb 26 19:09:05 Signed-off-by: Bernhard Guillon Feb 26 19:09:05 Acked-by: Marcin Juszkiewicz Feb 26 19:09:05 and inside stagefile_shell it replaces TMPDIR portion of the filename with PSTAGE_TMPDIR_STAGE Feb 26 19:09:51 Yeah Feb 26 19:10:00 I think you've got something odd locally Feb 26 19:10:03 min.. Feb 26 19:10:23 I don't set DEPLOY_DIR_PSTAGE and it defaults to ${DEPLOY_DIR}/pstage Feb 26 19:10:31 Yeah Feb 26 19:10:38 And how are you getting that outside of TMPDIR? Feb 26 19:10:48 I do that by changing DEPLOY_DIR_PSTAGE to be outside of TMPDIR Feb 26 19:10:59 DEPLOY_DIR = /OE/deploy Feb 26 19:11:02 TMPDIR = /OE/tmp Feb 26 19:11:13 So you've got a different can of worms open Feb 26 19:11:48 It sounds like shellfile doesn't like DEPLOY_DIR outside of TMPDIR Feb 26 19:11:53 Not pstaging outside of tmpdir :) Feb 26 19:11:56 stagefile_shell was the only problem I ever had :) Feb 26 19:12:09 that's what I was saying all along! :) Feb 26 19:12:14 heh Feb 26 19:15:36 so, back to the issue - before I was "fixing" it by replacing TMPDIR with DEPLOY_DIR in the sed, as stagefile_shell was called only for the files already in deploy... now we want to stage a file, which is not deployed and still in tmp... Feb 26 19:17:03 I was thinking of putting there some crude if/then to detect if it's in deploy or tmp, but it doesn't look nice :) Feb 26 19:19:07 Well Feb 26 19:19:24 You're always given a full path to the file to care about Feb 26 19:20:11 hmmm.. in stable the GNU_HASH thing is not consideredfatal, but in oe.dev it is? how can I tell OE to ignore this "problem"? Feb 26 19:21:37 Jin^eLD: INSANE_SKIP_pkg = True for example Feb 26 19:21:47 thanks Feb 26 19:21:59 http://cgit.openembedded.org/cgit.cgi/openembedded/log/?qt=grep&q=GNU_HASH Feb 26 19:22:03 just fix it ? Feb 26 19:22:16 mlip2: it's the spidermonkey package ;) Feb 26 19:22:45 has a very messed up build system, so I rather not touch it Feb 26 19:22:46 but let me read the link you posted Feb 26 19:22:47 if you are packaging prebuilt binaries, you can't "fix" it, so skip it :) Feb 26 19:22:50 maybe it is easier than I think Feb 26 19:23:19 I'm not.. Feb 26 19:23:28 but I would really not want to mess with the js makefiles, had to patch them already to get 1.7 compiled Feb 26 19:23:52 Tartarus: go on... :) was that a pointer for me? coffee makes me sleepy, so I'm not following you :) Feb 26 19:23:54 any link ? Feb 26 19:24:05 hm? Feb 26 19:24:18 I was going to post our changes again, but they aren't relevant to your problem Feb 26 19:24:26 So i have time to clean 'em up more still before posting again :) Feb 26 19:24:34 ah Feb 26 19:25:33 So hm Feb 26 19:26:14 Tartarus: as I'm understanding it, you don't set DEPLOY_DIR separately, but rather DEPLOY_DIR_PSTAGE. and it works as is w/o problems... Feb 26 19:26:33 Yeah Feb 26 19:26:38 So looking at shellfile Feb 26 19:26:46 PSTAGE_TMPDIR_STAGE = "${WORKDIR}/staging-pkg" Feb 26 19:26:47 re Feb 26 19:26:52 I can try that as well, but I really need to have complete DEPLOY_DIR with images, ipks etc. outside of TMPDIR... Feb 26 19:27:26 I still don't see why this shouldn't work for you Feb 26 19:27:41 Is the source file not found? Feb 26 19:28:37 because sed fails to replace the pattern, i.e. the filename doesn't change and cp fails to copy file into itself Feb 26 19:29:12 That doesn't make sese Feb 26 19:29:14 *sense Feb 26 19:29:37 throw an 'env' in before the stagefile_shell call? Feb 26 19:31:20 In fact, I don't see how this is different for you at all, s#${TMPDIR}#${PSTAGE_TMPDIR_STAGE}# has boths parts of the path under TMPDIR, in my case, your case and the default case Feb 26 19:32:26 TMPDIR=/OE/tmp, DEPLOY_DIR=/OE/deploy, DEPLOY_DIR_PSTAGE=/OE/deploy/pstage, PSTAGE_TMPDIR_STAGE=/OE/tmp/work Feb 26 19:32:43 if the deploy dir isn't in tmp, that s### won't do anything to the path.. no? Feb 26 19:32:49 now, by default, sed /TMPDIR/PSTAGE_TMPDIR_STAGE/ works for files in /OE/tmp, but not /OE/deploy Feb 26 19:32:54 kergoth: bingo! Feb 26 19:33:03 But Feb 26 19:33:06 PSTAGE_TMPDIR_STAGE = "${WORKDIR}/staging-pkg" Feb 26 19:33:10 the path does not change and cp tries to copy file into itself Feb 26 19:33:34 that's the replacement, not the original. the repalcement is in tmpdir, the original path isnt Feb 26 19:33:41 Tartarus: stagefile_shell is called for already deployed files as well Feb 26 19:34:42 Well, lets think about this differently perhaps Feb 26 19:34:50 We get told the full path Feb 26 19:35:24 and we know we want to put a copy of $1 - ${TMPDIR} into our/special/place/($1 - $TMPDIR) Feb 26 19:35:35 We try and get that done in a magic regex on $1 Feb 26 19:36:03 But maybe we should instead regex tmpdir out of $1 and say copy to ${MAGICVAR}/${SRC with TMPDIR regexed out} Feb 26 19:36:36 if you do that, it'll not error, it'll just be largely useless instead Feb 26 19:36:37 that would be better, more flexible and not locked on TMPDIR Feb 26 19:36:54 kergoth: why? Feb 26 19:37:08 because then you have the full absolute path to the outside deploy_dir, which won't be the same for others using that prebuilt Feb 26 19:37:10 I must be having a dense morning Feb 26 19:37:22 but maybe I'm missing something Feb 26 19:37:46 kergoth: Yeah, that doesn't matter, we're just trying to save a file and it's contents Feb 26 19:37:53 eh? Feb 26 19:37:58 pstaging itself still needs to make the archive valid Feb 26 19:38:02 yes, it'll be saved, but what good is that if you can't restore it? Feb 26 19:38:18 Why wouldn't you be able to restore it? Feb 26 19:38:46 why would you think it would be able to? Feb 26 19:39:01 :) Feb 26 19:39:07 your ${SRC with TMPDIR regexed out} will be the full path to the original guy's deploy dir Feb 26 19:39:14 how is it going to magically put that in the current DEPLOY_DIR? Feb 26 19:39:34 Ah, i see Feb 26 19:39:45 yes, we'd also need to regex out the deploy dir Feb 26 19:39:51 well, leading path to it Feb 26 19:40:01 "leading path to it" means what, when its not in tmpdir? Feb 26 19:40:46 So DEPLOY_DIR outside of TMPDIR isn't valid? Feb 26 19:41:08 I'm just saying the current logic for saving/restoring files outside of staging isn't going to work for that case. Feb 26 19:41:13 should rethink the whole method Feb 26 19:41:25 Yeah Feb 26 19:41:39 I'm still not sure why it's not working for denix as is, so i'm gonna give up :) Feb 26 19:42:07 Or rather, why it fails on ${S} but not ${DEPLOY_DIR_IMAGES} Feb 26 19:42:15 I want to evaluate the idea of using OE on an Intel Atom Z530 device... Can anyone point me at a good tutorial that will step me though building a basic root filesystem so I can see what I am getting into? Feb 26 19:42:34 if the path is /my/tmp/deploy and you s#/my/tmp#something# for the dest of the copy, its fine. if the path is /my/foo and you try to s#/my/tmp#something#, the sed is a no-op, and the dest is the same as the source. boom. Feb 26 19:42:34 actually, it would fail the other way around by default Feb 26 19:42:44 * kergoth ponders how best to rework this Feb 26 19:44:08 maybe it should generate a relative path from staging to the destination of the file Feb 26 19:44:16 then store a map of that relative path to the actual path stored in the staging package Feb 26 19:44:19 before the recent change, we only called stagefile_shell for deployed files, so I replaced TMPDIR with DEPLOY_DIR in that function and it worked for me Feb 26 19:44:21 or something Feb 26 19:45:36 now, we also try to stage files from ${S} and my previous hack no longer works Feb 26 19:46:06 but I agree with kergoth that it needs to be done differently to work for all cases Feb 26 19:46:15 * kergoth ponders.. maybe it should be changed in a more fundamental way, or just reimplement pstage from scratch Feb 26 19:46:20 heh Feb 26 19:47:12 I'm still not clear about the purpose of this function... can someone explain it to me? :) Feb 26 19:47:24 mlip2: thanks again, for the link, fixing it was indeed much easier than I thought Feb 26 19:47:34 which function? Feb 26 19:47:37 why is it copying a file from one place to another? Feb 26 19:47:43 stagefile? Feb 26 19:47:44 kergoth: stagefile_shell Feb 26 19:47:57 staging normally only picks up files in staging, as installed by populate_staging Feb 26 19:48:17 that function copies them into a special area in the package and restores them later, for files that aren't there Feb 26 19:48:26 afaik, anyway Feb 26 19:48:30 * kergoth isn't 100% on this crap either Feb 26 19:49:01 what about stamps? Feb 26 19:49:21 those are copied in/out as a part of the pstage code, specially handled Feb 26 19:49:31 since it checks to see if the stamps match the tasks, iirc, to see if the packages are valid and all Feb 26 19:50:07 so, pstage is staging+stamps... Feb 26 19:50:18 the thing of it is Feb 26 19:50:23 the pstage pacakge isnt' actually installed into staging Feb 26 19:50:35 its installed into tmpdir, hence the eexistence of tmp/usr/lib/opkg Feb 26 19:50:54 that's how the stamps+staging+(other files pulled in by stagefile) show up Feb 26 19:52:12 maybe that relative path function could help Feb 26 19:53:09 kergoth: maybe it should generate a relative path from staging to the destination of the file Feb 26 19:53:09 kergoth: then store a map of that relative path to the actual path stored in the staging package Feb 26 19:53:12 still hacky, though Feb 26 19:53:19 * kergoth hmms Feb 26 19:54:21 I just checked my prev pstage dirs and I don't see and kernel staging packages... Feb 26 19:54:26 should there be any? Feb 26 19:55:28 I am looking for a tutorial that would describe how to use OE to build an OS for a device running a Z530 Atom based Intel chip... any pointers? Feb 26 19:59:50 OK, hard to build on unsupported technologies... I guess OpenEmbedded is not ready for prime time Feb 26 20:00:47 I love 'users' which go into channel, ask, wait few minutes, leave Feb 26 20:01:36 hrw|gone: and I love when you say something and then change to "gone" state... :-P Feb 26 20:03:17 heh Feb 26 20:03:57 hrw|gone: so many times people say good bye stay there for ack the departing greetings :) Feb 26 20:05:53 heh.. yeah, OE isn't ready for primetime.. never mind MVL6, and palm using it, and .. Feb 26 20:05:56 * kergoth chuckles Feb 26 20:06:59 kergoth: what is the context? Feb 26 20:07:10 03Tom Rini  07org.openembedded.dev * r1b5e7041ae 10openembedded.git/classes/package.bbclass: Feb 26 20:07:10 package.bbclass: when running 'file', be explicit about the path to the magic Feb 26 20:07:10 This works around one relocation issue. Feb 26 20:07:10 Signed-off-by: Tom Rini Feb 26 20:07:10 Signed-off-by: Chris Larson Feb 26 20:07:13 hi zecke, kergoth Feb 26 20:07:23 user joined, asked a quesiton, waited 4 minutes, then gave up, said oe must not be ready for primetime due to being "unsupported", then left Feb 26 20:07:27 it was amusing Feb 26 20:09:07 heh Feb 26 20:09:08 I wonder if RP ever built Poky for Atom... :) Feb 26 20:11:03 but in any case it's a regular OE build for x86 target, not sure what's so "unsupported" Feb 26 20:11:18 heh Feb 26 20:11:43 03Michael 'Mickey' Lauer  07org.openembedded.dev * r61b59fd777 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: sane-srcrevs-fso: bump libgsm0710 Feb 26 20:11:43 03Michael 'Mickey' Lauer  07org.openembedded.dev * r7b1386a2d5 10openembedded.git/recipes/freesmartphone/ (8 files in 7 dirs): libgsm0710mux: move configuration to fso-abyss; remove 3d7k which will never see the light of day Feb 26 20:11:44 03Michael 'Mickey' Lauer  07org.openembedded.dev * r49866f6c6a 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev Feb 26 20:12:37 kergoth: he might have meant supported by companies may be Feb 26 20:13:51 infact OE and debian are two who support so many arches out there Feb 26 20:36:58 wow... OE is so vulnerable.. :( Feb 26 20:39:44 zecke: what's up? Feb 26 20:40:57 mickeyl: wget http://portaudit.FreeBSD.org/auditfile.tbz; bzless auditfile.tbz Feb 26 20:41:41 mickeyl: so our expat, libtool, gzip, squid, wireshark, libvorbis, mono... and probably more is vulnerable. :( Feb 26 20:41:46 fun Feb 26 20:42:03 lets employ one guy that does nothing but applying security fixes Feb 26 20:42:09 ah wait... Feb 26 20:42:12 we have no money ;) Feb 26 20:42:17 yo dcordes Feb 26 20:42:33 mickeyl: one big advantage of Debian, Fedora. :) Feb 26 20:43:08 indeed Feb 26 20:43:18 i heard cross build system are obsolete Feb 26 20:43:30 wtf are we doing here... Feb 26 20:44:29 Well, according to the people in #ubuntu-arm, it'd take months to recompile that, so OE is ahead there. Feb 26 20:44:38 hehe Feb 26 20:45:30 * james_l doesn't think it'd take that long, just that the people there probably haven't ever compiled their whole distribution very often, or their build system is way more broken than one would think. Feb 26 20:45:49 mickeyl: well, if we can't give a user an image that is not remote exploitable as fast as windows95. we are obsolete. Feb 26 20:48:01 hmm, who can delete branches in the oe repo? Feb 26 20:49:06 kergoth: which one? Feb 26 20:49:23 org.openembedded.dev Feb 26 20:49:31 kergoth/*. moving them to a separate repo so i can actually rebase the things Feb 26 20:49:33 it's obsolete anyway... Feb 26 20:49:44 (and some are no longer needed, of course) Feb 26 20:50:28 kergoth: you can rebase them on git.oe.org too. :) Feb 26 20:50:28 kergoth: why can't you rebase your branches on oe git? Feb 26 20:50:45 you removed that from the hooks? Feb 26 20:50:47 huh Feb 26 20:51:01 denix: at one point at least, you couldn't push non-fast-forwards Feb 26 20:51:11 kergoth: really? Feb 26 20:51:14 we should put user branches into a seperate repo Feb 26 20:51:18 and then allow removals Feb 26 20:51:27 didn't we agree on that @ oedem? Feb 26 20:51:28 (aside: you *definitely* can't push non-fast-forwards on bitbake repo, but you *can* remove branches there, unlike the oe repo) Feb 26 20:51:33 thought so, yes Feb 26 20:51:37 mickeyl: indeed! Feb 26 20:51:49 good. then we should make that happen Feb 26 20:51:52 (finally) Feb 26 20:52:16 i think there was some disagreemtn about whether to use one big contrib repo or multiple user repos, but it sounds like the former would be easier to pull off, so that has my vote Feb 26 20:52:41 kergoth: your branches are gone Feb 26 20:52:49 thanks Feb 26 20:53:50 Yeah, w/o the kernel.org type admin, per user repo is too much work Feb 26 20:54:07 yep Feb 26 20:55:38 Even that still has underlying manual stuff like reminders to set your alternatives right Feb 26 21:00:53 03Koen Kooi  07org.openembedded.dev * rb6e82ec5da 10openembedded.git/recipes/xorg-lib/ (4 files in 2 dirs): pixman 0.17.8: update neon patches to also include BGRA Feb 26 21:09:28 kergoth: ??= commit looks good. I'm looking forward to playing with that Feb 26 21:12:52 Tartarus: yeah, arago git server is just a fracture of kernel.org size, but per user repos keep me busy... :) http://arago-project.org/git/people/ Feb 26 21:13:28 * RP__1 likes the idea of the gitosis replacement which allows branch restrictions Feb 26 21:14:22 per branch permissions would be nice... Feb 26 21:14:49 denix: There is a project which can do it who's name escapes me atm Feb 26 21:15:19 how hard is it to manage though? Feb 26 21:15:32 http://github.com/sitaramc/gitolite Feb 26 21:15:33 branches are more volatile than repos, supposedly Feb 26 21:15:40 denix: same as gitosis Feb 26 21:16:37 kergoth: interesting Feb 26 22:45:58 03Martin Jansa  07org.openembedded.dev * rf12dd3b743 10openembedded.git/recipes/ (3 files in 2 dirs): Feb 26 22:45:58 shr-image: add all needed deps to task-shr-minimal, remove /boot from jffs2/ubi/ubifs Feb 26 22:45:58 Signed-off-by: Martin Jansa Feb 26 22:46:01 03Martin Jansa  07org.openembedded.dev * r43b197ec24 10openembedded.git/recipes/klibc/ (klibc-1.5.15+1.5.16/socket.h.patch klibc_1.5.15+1.5.16.inc): Feb 26 22:46:01 klibc-1.5.16: add socket.h patch for build with 2.6.33 Feb 26 22:46:01 Signed-off-by: Martin Jansa Feb 26 22:46:01 03Martin Jansa  07org.openembedded.dev * r6b7f626234 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: Feb 26 22:46:02 fso: bump SRCREVs to latest Feb 26 22:46:02 Signed-off-by: Martin Jansa Feb 26 22:46:12 03Martin Jansa  07org.openembedded.dev * r19fd0d0727 10openembedded.git/conf/distro/include/fso-autorev.inc: Feb 26 22:46:12 fso-autorev: remove libeflvala as it's now set with other EFL stuff and it can even go backwards, because AUTOREV picks smaller rev in libeflvala directory than what we have in EFL_SRCREV Feb 26 22:46:12 Signed-off-by: Martin Jansa Feb 26 23:29:56 Anyone know what a "BOGUS urb flag" message on the console implies? I'm getting it from trying to attach a Canon G10 camera to USB on a Gumstix running Angstrom. "usb 2-2.3.3: BOGUS urb flags, 1 --> 0" Feb 27 00:01:06 robtow: some wrong input to the driver Feb 27 00:01:09 I would guess Feb 27 00:01:54 khem - The G10 works fine with Ubuntu on a laptop, and has also worked with a beagleboard running Koan's demo image Feb 27 00:03:18 sakoman - just the man I wanted to see :-) Feb 27 00:05:04 sakoman - downloaded from your repo, from the pointer on the Gumstix site.... getting usb errors trying to attach a Canon G10 camera to Gumstix Fire module. Feb 27 00:06:46 sakoman - any idea what "usb 2-2.3.3: BOGUS urb flags, 1 --> 0" implies? Feb 27 00:07:37 robtow: not a clue! Feb 27 00:07:44 ha! Feb 27 00:08:04 did you try both usb connections? Feb 27 00:08:31 Sakoman - only the A connection; I have a mini-a to mini-b cable on order. Feb 27 00:08:47 Those cables are hard to find. Feb 27 00:08:56 yeah, they are Feb 27 00:09:13 Perhaps when it gets here next week that might help :-( Feb 27 00:13:31 robtow: looks like that message comes from the usb driver (drivers/usb/core/urb.c) Feb 27 00:14:09 Hmm. Feb 27 00:15:05 Sakoman - I was hopeful that the Gumstix + gphoto2 would "just work", so I could point customers at it. Feb 27 00:15:30 it works with my camera ;-) Feb 27 00:16:27 What is your camera? I'm using a Canon G10 - which is quite stable with Ubuntu 9.04 running under VMware on my Macbook Pro; and which was a bit flaky under Angstrom on a beagleboard. Feb 27 00:17:09 robtow: Canon EOS Rebel XT Feb 27 00:17:53 sakoman - Interesting. A colleague here has that camera, I can ask him to bring it in Monday, for comparison. Feb 27 00:18:09 I tried it a few weeks ago with the Beagleboard and Ubuntu. Feb 27 00:19:41 Using uImage-overo-201002161027 on the Fire module. Feb 27 00:21:15 robtow: which rootfs? Feb 27 00:21:34 let me check... tied two, console and full desktop... Feb 27 00:21:57 omap3-desktop-image-overo-201002161027 Feb 27 00:22:12 omap3-console-image-overo-201002161027 Feb 27 00:22:59 got same behavior with both; also tried direct connection of camera versus through powered Belkin hub - no difference. Feb 27 00:23:28 robtow: I usually use my gnome image, it's been a while since I tried the desktop image Feb 27 00:23:34 Ah. Feb 27 00:23:37 Hmm. Feb 27 00:23:48 I could try the Gnome image, for comparison. Feb 27 00:24:08 offhand I don't know why that should be any better as far as gphoto2 is concerned, but you never know Feb 27 00:24:32 Indeed, one never knows until one knows :-) I'm happy to try it. What's the url? Feb 27 00:25:05 And you are doing it with a Gumstix Fire & Tobi? Feb 27 00:25:09 www.sakoman.com -- there's a link there Feb 27 00:25:29 I'll pull it down and try it right now. Feb 27 00:25:38 yeah, that is my typical setup, with powered hubs on both usb ports Feb 27 00:26:39 Excellent. Feb 27 00:29:02 sakoman - the download will take another 52 minutes. I'll report back the result. Thanks. Feb 27 00:29:33 robtow: good luck! Feb 27 01:37:05 Lets see Feb 27 01:37:14 wrong TZ for pb* I assume Feb 27 01:44:02 pb_, pb___, For your history I hope, dropping mpfr and gmp into gcc source dir seems to be pretty easy. I've got it working on, erm, gcc-canadian-sdk 4.3.3 which makes posting this harder (since i need to clean it up too) but I'll try and get a better / cleaner patch out, for linux gccs next week, or over the weekend, depending on what i need to do around the house **** ENDING LOGGING AT Sat Feb 27 02:59:56 2010