**** BEGIN LOGGING AT Tue Nov 08 02:59:57 2011 Nov 08 08:23:55 good morning Nov 08 08:30:17 hm, before digging into it deeper, is it a known problem? http://pastebin.com/kEvze9ni Nov 08 08:30:33 seems like everything svn fails Nov 08 08:33:05 here is known problem with svn-1.7, but your case looks like incomplete branch_gcc.gnu.org_.svn.gcc.branches_178923_.tar.gz Nov 08 08:33:17 just remove it from downloads and retry Nov 08 08:33:42 did that Nov 08 08:34:17 so maybe wrong archive on angstrom premirror Nov 08 08:35:22 try to download and unpack manually and then report to angstrom ML Nov 08 08:36:25 mckoan: gm Nov 08 08:36:55 I've disabled that slow mirror also Nov 08 08:37:01 I'm not using it Nov 08 08:37:34 if I do bitbake -k then it fails on other svn stuff... Nov 08 08:37:53 but thanks, I'll dig deeper into it Nov 08 08:49:13 mornin Nov 08 09:23:16 hmm, assuming main package does PACKAGES += "something", can I get rid of this "something" in the .bbappend? like, not by redefining PACKAGES (because I may not know its full contents) Nov 08 09:23:18 but just by doing some python magic or whatever to remove the "something"? Nov 08 09:31:34 good morning Nov 08 09:31:52 hi florian Nov 08 10:33:40 Jin^eLD: you could use oe_filter_out Nov 08 10:34:33 I think you'd also need to use := in conjunction with that Nov 08 10:34:41 (to get immediate expansion) Nov 08 10:35:18 thanks for the hint Nov 08 10:38:10 btw, another question regarding the overall configuraion; with OE classic I was able to setup the environment in a way, that I could run bitbake from any directory; with OE core I somehow fail to do that, it always insists in looking for local.conf in `pwd`/conf instead of going through all dirs specified in BBPATH Nov 08 10:38:17 any idea why? or what I may be missing? Nov 08 10:40:13 Jin^eLD: I only remember this used to be the same with classic OE a looong time ago... Nov 08 10:41:42 so are you saying building from any dir (provided you sourced the environment) works for you with OE core? Nov 08 10:41:57 or did I get you wrong and the point is that support for this was dropped ages ago? :) Nov 08 10:43:08 I did not try this with OE core so far - I know it used to work with classic OE but from the early days of OE I know it was not working as expected. Nov 08 10:43:46 So what I'm saying is not really useful for answering your question :-) Nov 08 10:43:52 :) Nov 08 10:44:08 btw core is missing quite a few packages from classic Nov 08 10:44:53 indeed Nov 08 10:45:12 ... including all known layers Nov 08 10:46:05 Some OE-classic layer for OE core would be good... would make the transition way easier. Nov 08 10:46:24 I'm pretty sure quite a lot of our users suffer from this situation. Nov 08 10:46:43 I think I remember reading from the layer descriptions, that there is one layer that is supposed to provide the classic recipes, but that's not complete Nov 08 10:47:13 I would think so :P it caught me by surprise Nov 08 10:47:58 yet another question.. do you think a live update (via opkg) from a glibc based rootfs to a eglibc based rootfs is possible? Nov 08 10:48:33 this is the next thing that I encountered: angstrom in core dropped glibc support Nov 08 10:49:00 I guess so... they provide more or less the same functionality. Nov 08 10:49:27 but it seems I have to tune the recipes myself, I did not see any RREPLACES or RCONFLICTS in the eglibc recipes Nov 08 10:49:46 I hope that works out, we have an angstrom-2008 based system out in the field Nov 08 10:50:34 Debian uses eglibc per default now too iirc, so they had this transition in their upgrade path as well.... but packaging is another topic. Nov 08 10:51:08 Jin^eLD: I guess if you want to you should be able to define that replaces/conflicts at a distro level (e.g. RREPLACES_glibc = "eglibc") Nov 08 10:51:42 er, the other way around... Nov 08 10:51:45 uh... this is possible? ;) Nov 08 10:51:50 if it's corrected :) Nov 08 10:51:59 RREPLACES_eglibc = "glibc" Nov 08 10:52:25 that sounds interesting, I'll try that Nov 08 10:52:33 did not know that was possible on distro level :) Nov 08 10:53:29 We need a manual for distribution maintainers Nov 08 10:55:49 that would surely be a good thing Nov 08 10:57:04 indeed Nov 08 10:57:11 any volunteers to write one? ;) Nov 08 10:57:53 bluelightning: now you completely killed any further chatter on the channel :) Nov 08 10:58:39 this is the problem with documentation... everybody agrees when we need some, but few are prepared to sit down and write it... Nov 08 10:59:03 well, are you surprised? it's *documentation* :) Nov 08 10:59:21 I do not remember being on any project where ppl liked writing docs :) Nov 08 10:59:57 from the developers perspective that's understandable Nov 08 11:01:03 I don't mind writing docs, but I can't claim to be especially good at it Nov 08 12:01:24 otavio: ping Nov 08 12:04:10 otavio: connman RDEPENDS on systemd.. looks wrong and breaks every image with sysvinit.. Nov 08 12:04:13 SHR root@gjama / $ opkg info connman | grep Depends Nov 08 12:04:16 Depends: iptables (>= 1.4.12.1), systemd, update-rc.d, libdbus-1-3 (>= 1.4.12), libc6 (>= 2.14), libglib-2.0-0 (>= 2.30.0) Nov 08 12:28:53 JaMa: oh, right. will fix it Nov 08 12:30:20 otavio: patch on ML.. but please review Nov 08 12:30:40 otavio: I got depressed with oe-core and removed all tmpdirs.. so cannot test here.. Nov 08 12:31:47 JaMa: hahaha Nov 08 12:32:08 JaMa: I think the class ought to add the rdepends on each package it adds the postinsts Nov 08 12:37:18 JaMa: I got sick of meta-oe issues and built meta-handheld + oe-core whitout it (just xserver-xf86-xfbdev, xinput, xinput calibrator from meta-oe) Nov 08 12:37:35 at least I can see core-image-sato booting Nov 08 12:38:02 ant_work: I'm sick of sstate.. not metadata itself Nov 08 12:38:38 unfortunately there is more Nov 08 12:39:08 JaMa: I did it locally; testing Nov 08 12:40:01 JaMa: fixed the class Nov 08 12:40:03 JaMa: testing Nov 08 12:46:06 is there an easy way to do a rm_work after you run a build? Nov 08 12:47:29 Crofton|work: add it to INHERIT (ie in conf.local) Nov 08 12:49:53 this pseudo thing eats quite a lot of CPU.. and why would it be active during a do_compile stage? Nov 08 12:49:55 this is after the build has run Nov 08 12:50:10 recovering from an out of disk space situation :) Nov 08 12:50:24 Crofton|work: yes, after - if you add the inherit thing and rerun the build without cleaning it will just do the rm_work Nov 08 12:50:35 ok Nov 08 12:50:36 thanks Nov 08 12:51:39 anyone - a comment on pseudo? it eats up 30% CPU here which I think is quite a lot, especially during do_compile, why would it even kick in there? Nov 08 12:52:15 I do not remember fakeroot being so extensively present in the top list in OE classic Nov 08 12:52:25 mostly it was only around during rootfs generation Nov 08 12:53:46 Crofton|work: it will rm_work all already finished builds, and if you cannot finish any build now.. then run bitbake for something smaller already built (so it wont build anything just run rm_work) Nov 08 12:53:47 JaMa: https://github.com/OSSystems/meta-oe/commit/db24be4e6f001aae20b76249c499becc26ca1821 Nov 08 12:54:50 otavio: please bump connman's PR with that Nov 08 12:58:44 JaMa: mailed ml; ack them please Nov 08 12:59:36 cannot test.. so won't ack Nov 08 13:02:26 JaMa: ok Nov 08 13:04:29 have any decision been made on when oe-classic goes read-only? I'm working towards a release in march, and try to decide if classic or core is the way to go. Nov 08 13:05:36 tasslehoff: core Nov 08 13:05:53 tasslehoff: you avoid an update cycle for the product later Nov 08 13:06:21 tasslehoff: most work is on core now so as it is a new project, better to be based on that Nov 08 13:08:52 otavio: ok. I've successfully moved most of my stuff from classic to core. what remains is to compile an sdk and some power management issues in the kernel. Nov 08 13:09:01 and I like core :) Nov 08 13:10:46 tasslehoff: core is the way to go for new products, imo Nov 08 13:35:26 would be nice of jlime (for ben nanonote) was ported over to core Nov 08 13:35:32 or maybe it is and I missed it. Nov 08 14:05:01 hii oee Nov 08 14:14:47 Hi everyone Nov 08 14:15:26 How can I handle localization in a filesystem created with openembedded? Nov 08 14:15:54 Are there any packages that I must install? Nov 08 14:16:57 For example I'm missing files like en_US that should be placed in /usr/share/locale or something like that... Nov 08 14:18:41 mrAlmond: those should be generated as separate packages you can install automatically... unfortunately I don't know much about our i18n/l10n mechanisms beyond that Nov 08 14:20:17 bluelightning : thank you for the hint...I'm trying to understand what I'm missing Nov 08 14:21:33 mrAlmond: there are *-locale-* packages generated for those recipes that support it Nov 08 14:21:46 for example one like this : locale-base-gl-es+euro_2.12-r13_armv7a.ipk ? Nov 08 14:22:14 because I've also files like eglibc-localedata-tk-tm_2.12-r13_armv7a.ipk Nov 08 14:22:30 but I don't know which one of the two times I must install Nov 08 14:22:42 two types not "two times" Nov 08 14:24:30 mrAlmond: have you set IMAGE_LINGUAS? I wonder if that is meant to take care of that stuff automatically Nov 08 14:24:56 bluelightning : I don't know...I must check Nov 08 14:54:43 I've tried to enable GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 en_US.UTF-8" in my local.conf Nov 08 14:54:58 then I've rebuilt the image but I still can't find those files Nov 08 14:55:49 nou need to build libc again Nov 08 14:55:56 s/nou/you Nov 08 14:56:26 eglibc? Must I do a clean before? Nov 08 14:56:55 because I already had ENABLE_BINARY_LOCALE_GENERATION enabled but locales are not installed Nov 08 14:57:05 if you are using eglibc - yes. Nov 08 14:57:39 but shouldn't the ENABLE_BINARY_LOCALE_GENERATION = 1 install the locale files automatically when I built my image for the first time? Nov 08 14:58:12 because the ipk's are generated but they seems to be not installed Nov 08 14:59:40 okay... the ones that get installed depend on image and distribution Nov 08 15:01:11 florian : ok, so what must I enable in my image recipe? Nov 08 15:03:11 mrAlmond: usually its a distribution setting that decides... you can make sure all available translaton packages for a selected language get installed then. in theory you could pick them in an image file, but this is not really what you want usually Nov 08 15:04:24 Ok, let me explain, I'm using the yoctoproject, I've my own image recipe that inherits from poky-image-core Nov 08 15:04:42 Now I need the localizations files because they are missing Nov 08 15:04:48 in my rootfs Nov 08 15:14:04 I'm having problems adding my own recipes, if they make use of libjpeg, libpng and/or libz. The problem is programs spit this error while linking: "/usr/lib/libz.so: could not read symbols: File in wrong format" Nov 08 15:15:46 At first it looks like it's a problem with the paths (link is called with "/usr/lib/*" instead of "/path_to_cross_compiler/usr/lib/*", but the weird thing is the problem only happens with these libraries. The other ones have the right path Nov 08 15:18:09 This is the call to the library creation tool when compiling libleptonica: http://pastebin.com/eawQabju Nov 08 15:19:22 03Philip Balister  07master * r67f97975a9 10openembedded.git/recipes/uhd/uhd_git.bb: Nov 08 15:19:22 uhd : Update to version 3.3.1. Nov 08 15:19:22 Signed-off-by: Philip Balister Nov 08 15:19:27 03Philip Balister  07master * rcbdd0542f8 10openembedded.git/recipes/uhd/ (3 files): Nov 08 15:19:27 uhd-firmware : Update to 3.3.1. Nov 08 15:19:27 Signed-off-by: Philip Balister Nov 08 15:20:41 And this is the call when compiling tesseract 3.00: http://pastebin.com/mv3bBVVL Nov 08 15:21:53 In both cases, I have the same fail. In the long list of libraries, only libjpeg, libpng and libz are incorrectly called. Nov 08 15:23:13 I think this might be a problem with the toolchain. ANy clues? Nov 08 15:26:05 yes, grep Nov 08 15:27:38 grep what? I have spent about 3 hours searching for clues in the log files and run_* scripts, but found nothing. Nov 08 15:27:49 source dir Nov 08 15:28:04 how it's that Makefile generated? Nov 08 15:28:12 namely that offending link line Nov 08 15:28:45 something has to leak that host libs into the build Nov 08 15:28:59 maybe pkg-config or something other Nov 08 15:29:21 The Makefile is generated using a configure script. I have checked the call to the configure script and it looks ok to me. Nov 08 15:29:43 give me the src link for that library Nov 08 15:30:44 http://leptonica.googlecode.com/files/leptonica-1.68.tar.gz Nov 08 15:31:30 And I had the same problem with tesseract: http://tesseract-ocr.googlecode.com/files/tesseract-3.00.tar.gz Nov 08 15:35:15 I'm suspecting there's an error with the toolchain built by OE. I have tried to cross compile the packages outside OE (setting up the cross compiler built by OE and running configure and make by myself) and I have reproduced the problem. The strange thing is that tesseract worked before I updated the distro (I was using an old angstrom 2008.1 and updated yesterday to 2010.x). Nov 08 15:35:48 $(liblept_la_LINK) -rpath $(libdir) $(liblept_la_OBJECTS) $(liblept_la_LIBADD) $(LIBS) Nov 08 15:36:22 I wonder what sets your libdir to /usr/local/lib Nov 08 15:37:12 guys, how is that possible? http://pastebin.mozilla.org/1377289 the file://defconfig that it is looking for is in the files directory, as usual, I do not do anything fancy with the variables or whatever Nov 08 15:37:22 but it refuses to find the local files in the SRC_URI Nov 08 15:37:24 what am I missing? Nov 08 15:37:46 doragasu: just add some debug echo there and take a look if it's set correctly and then if it's mangled somewhere Nov 08 15:37:53 src/Makefile.in Nov 08 15:38:38 Jin^eLD: use bitbake -e and inspect FILESPATH. Nov 08 15:38:39 doragasu: and you did clean build from scratch? Nov 08 15:39:07 doragasu: I wouldn't recommend to jump from 2008.1 to 2010.x without a clean build :p Nov 08 15:39:26 doragasu: strange things could happen and those rpath issues should be solved Nov 08 15:39:42 Yes, I made a backup of the oe directory, deleted every single file and followed the "getting started" tutorial from the beginning Nov 08 15:39:48 anyway I wonder why it doesn't bombout on that Nov 08 15:40:18 there's insane bb class which should probably detect such weirdness Nov 08 15:40:26 The weird thing is that my tesseract recipe compiled flawlessly in 2008.1, and now I get that strange error. Nov 08 15:40:40 yes, that could happen :) Nov 08 15:41:14 Could it be a problem with bitbake? I didn't write down the version I was using. I can try to recover it from the backup... Nov 08 15:41:20 JaMa: heh, the biggest weakness of the sstate signature bits, in my opinion, is that it only tracks inputs, not outputs. If task A depends on B, and the metadata input to B changes, then A will be rebuilt, even if the *output* of B didn't change as a result of the change to its metadata. Nov 08 15:41:31 doragasu: so you're still on oe classic? or it's oe-core? Nov 08 15:41:44 doragasu: if you're upgrading, you should strongly consider oe-core Nov 08 15:41:58 I have never heard about oe-core... so I suppose it's oe classic :-S Nov 08 15:42:37 http://www.angstrom-distribution.org/building-angstrom Nov 08 15:43:04 follow that guide, it should be supported Nov 08 15:43:41 and BTW I've started slowly moving from 2010.x in oe classic to oe-core yesterday... Nov 08 15:44:11 Thanks a lot for help. I'll throw away the toolchain and I'll give that tutorial a try. Nov 08 15:45:39 I did tried that tutorial/scripts and build one image without any problems, so it might work for you also :p Nov 08 15:46:19 kergoth_: yes :/ without -depth limitation it is too strict imho :/ http://lists.linuxtogo.org/pipermail/openembedded-core/2011-November/012270.html and when it accidentaly works it causes troubles http://lists.linuxtogo.org/pipermail/openembedded-core/2011-November/012149.html Nov 08 15:47:06 kergoth_: unfortunately just removing sstate from INHERIT is not enought to turn it off completely :/ Nov 08 15:47:41 I'm reading this first (http://www.openembedded.org/wiki/OpenEmbedded-Core) to learn about the differences in oe-classic and oe-core. Nov 08 15:47:54 * JaMa wonders how much IO would be saved without sstate Nov 08 15:49:47 Do anybody know a detailed book/tutorial about OE? Nov 08 15:50:15 look at yocto Nov 08 15:50:46 http://www.yoctoproject.org/documentation Nov 08 15:51:24 The main problem I had with OE in the past, is I wasn't able to find a DETAILED tutorial. It's easy to follow the step by step tutorials and get things working, but when something fails... Nov 08 15:52:16 you've the source and #oe :p Nov 08 15:53:23 :-S That would be nice if I would be interested in learning python, autotools and had a whole lot of spare time to dig in the sources... Nov 08 15:54:25 (well, maybe I should to that...) Nov 08 16:01:19 It looks like sheevaplug is not supported by oe-core :-( Nov 08 16:01:36 supported = kernel Nov 08 16:02:00 just create layer for that = copy the bits from oe classic Nov 08 16:02:10 isn't it kernel + additional hardware + patches? Nov 08 16:02:17 and maybe modify the recipe Nov 08 16:02:30 additional hardware = kernel? Nov 08 16:02:51 OK (kernel = kernel + kernel modules) Nov 08 16:03:04 what other stuff do you need for sheeva Nov 08 16:03:12 maybe there's layer for sheeva already Nov 08 16:03:23 there's some index of layers on the wiki Nov 08 16:03:30 It's not in the Layer Index: http://www.openembedded.org/wiki/LayerIndex Nov 08 16:04:55 Is it possible in oe-core to use no board definition? (and compile the kernel outside OE)? Nov 08 16:05:40 yes, but you would need to use some compatible machine Nov 08 16:05:59 i.e. some with the same CPU? Nov 08 16:06:05 yes Nov 08 16:06:24 or similar arch and options Nov 08 16:07:09 but it's not that hard Nov 08 16:07:20 look at some layers for examples Nov 08 16:07:28 nslu2 etc. Nov 08 16:09:08 FYI I have done a build for sheevaplug just by bringing over the machine recipe from OE Nov 08 16:09:20 wasn't too difficult Nov 08 16:09:43 OK, thanks a lot. I'll try that then Nov 08 16:19:36 doh, pseudo is really annoying, constantly eating a way quite a lot of CPU Nov 08 16:19:45 did anyone notice this? Nov 08 16:20:47 Jin^eLD: no, but you can try newer version 1.2 Nov 08 16:21:08 JaMa: will do, thaks Nov 08 16:21:19 here it's eating <10% cpu Nov 08 16:21:35 acording to htop fwiw Nov 08 16:42:03 is there a way to bypass QA in one particular recipe? I have some software that uses mongoose, and mongoose does dynamic loading of ssl libs instead of linking vs them, it tries to open the .so (not .so.xx) files, however if I try to ship them I get ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so Nov 08 16:42:10 is there any way around this? Nov 08 16:43:09 Jin^eLD: see meta-oe/recipes-core/libcgroup/libcgroup_0.37.1.bb:ERROR_QA Nov 08 16:44:36 kergoth: the -e thing on my kernel recipe does list the linux/files directory, so I am still puzzled why it refuses to find defconfig Nov 08 16:45:25 JaMa: thanks! I see the QA thing Nov 08 16:45:55 Jin^eLD: didn't you use -b to build kernel? Nov 08 16:47:02 JaMa: actually I was doing bitbake myimage, kergoth suggested to have a look with -e because of this: http://pastebin.mozilla.org/1377289 Nov 08 16:47:21 Jin^eLD: ok.. just in case: http://bugzilla.pokylinux.org/show_bug.cgi?id=1465 Nov 08 16:47:22 but bitbake -e myimage spit out only stuff for myimage, so I did bitbake -e linux to get the dumb for the kernel recipe Nov 08 16:47:55 ok that sounds like it, just that I am not using -b Nov 08 16:48:14 and interestingly, it seems to work with other recipes Nov 08 16:48:43 I could not yet test if I do "bitbake linux", because it starts to build tons of other packages for some reason (even openssl, why would that be a dependency on the kernel?!) Nov 08 16:49:02 but when I do bitbake myimage it starts with the linux recipe and there I get the error like in my paste, which looks simialr to the one in bugzilla Nov 08 16:49:03 Jin^eLD: heh.. maybe that's caused by extra " you have there :P Nov 08 16:49:32 JaMa: I'm not seeing it, please help :)) which line? Nov 08 16:49:41 AH CRAP! Nov 08 16:49:42 :) Nov 08 16:49:44 thanks ;) Nov 08 16:49:45 never mind Nov 08 16:50:34 sometimes I'm realy blind :> Nov 08 17:15:02 03Marco Cavallini  07master * r6088224e5b 10openembedded.git/recipes/linux/linux-2.6.28/ronetix-pm9263/defconfig: ronetix-pm9263/defconfig: added PWM and BACKLIGHT options Nov 08 17:15:13 03Marco Cavallini  07master * r29c6d015c7 10openembedded.git/recipes/linux/linux_2.6.28.bb: Nov 08 17:15:13 linux_2.6.28.bb: added download of a patch for at91sam9263-ek, ronetix-pm9263, mh355 boards Nov 08 17:15:13 * Solve Xorg error message (EE) FBDEV(0): FBIOBLANK: Invalid argument Nov 08 17:15:13 * Bump PR Nov 08 17:15:13 03Marco Cavallini  07master * rba684b75ee 10openembedded.git/recipes/linux/linux-2.6.28/mh355/defconfig: mh355/defconfig: added PWM and BACKLIGHT options Nov 08 17:37:56 03Christopher Larson  07master * rd6c44fac18 10bitbake.git/lib/bb/codeparser.py: Nov 08 17:37:56 codeparser: merge the nested python parsing classes Nov 08 17:37:56 The split is even less necessary now that we use ast.walk rather than an Nov 08 17:37:56 actual NodeVisitor subclass. Nov 08 17:37:56 Signed-off-by: Christopher Larson Nov 08 17:37:57 03Christopher Larson  07master * r1060193ae4 10bitbake.git/lib/bb/ (codeparser.py data.py data_smart.py): (log message trimmed) Nov 08 17:37:57 codeparser: accept a name for better messages Nov 08 17:37:58 - If a name is passed to the parser, prepend the messages with "while Nov 08 17:37:58 parsing :". This gives a bit more context. Nov 08 17:37:59 - Tweak the warning messages slightly (they had to be altered anyway to Nov 08 17:38:00 inject the variable being parsed). Nov 08 17:38:00 Before: Nov 08 17:38:01 03Christopher Larson  07master * re724b9f417 10bitbake.git/lib/bb/ (codeparser.py data.py data_smart.py): Nov 08 17:38:01 codeparser: silence non-literal warnings for vardeps Nov 08 17:38:02 If the vardeps flag is not None, we now silence the warnings about Nov 08 17:38:02 non-literal usage for that variable. Nov 08 18:42:19 Hi Everyone, I have the O'Reilly programming embedded systems in C/C++ book but I would like to move on to something more challenging. Nov 08 18:42:30 Could anyone recommend something that would pick up were this book leaves off? Nov 08 18:49:08 Sorry everyone, this is not the right place for this hardware question Nov 08 19:15:30 Anyone seen this error? /bin/sh: symbol '__exidx_end': can't resolve symbol Nov 08 19:16:14 how can I tell if a bbappend is getting picked up? (it's not but i don't know why) Nov 08 19:18:09 msm: personally, i just add FOO = "1" and bitbake -e blah | grep \^FOO= Nov 08 19:18:22 but i'm sure you could inspect the logs.. they're just so damn verbose with -DDD that they're nearly useless Nov 08 19:18:26 heh Nov 08 19:18:28 right Nov 08 19:22:35 pb_: ping Nov 08 19:33:48 is there a way to make a bbappend apply to all recipes regardless of version? Nov 08 19:33:54 nope Nov 08 19:33:57 bbappend is by filename Nov 08 19:34:03 for example we have some udev rules we are install Nov 08 19:34:08 ok Nov 08 19:34:44 it's the biggest weakness of it, particularly versus the old amend.inc method, but the fact that its built into bitbake has other pluses, so mostly we just deal with it Nov 08 19:34:47 heh Nov 08 19:35:04 its not too bad Nov 08 19:35:08 debating just making anothe recipe Nov 08 20:57:20 Hi anybody else having issues with binutils-2.20.1? Do patch does not succeed as this patch seems to be outdated: recipes/binutils/binutils-2.20.1/libtool-rpath-fix.patch Nov 08 22:42:09 re **** ENDING LOGGING AT Wed Nov 09 02:59:57 2011