**** BEGIN LOGGING AT Tue Nov 15 02:59:57 2011 Nov 15 06:22:15 I am cross compiling a celt-0.5.2 package for spice ,but during compilation it gives the following error Nov 15 06:22:18 http://pastebin.com/FtnayjSH Nov 15 06:22:48 i do not why it searches for /usr/lib/libogg.so Nov 15 07:19:23 iam getting an error during bitbake cyrus-sasl package .....here is my log http://pastebin.com/MbnkxiTE Nov 15 07:19:45 ERROR: Task 13 (/home/rahul/OEBASE/openembedded/recipes/cyrus-sasl/cyrus-sasl_2.1.19.bb, do_compile) failed with 256 Nov 15 07:19:45 ERROR: '/home/rahul/OEBASE/openembedded/recipes/cyrus-sasl/cyrus-sasl_2.1.19.bb' failed Nov 15 08:36:17 hi , is it possible to inject my own custom asm code inside pe exe ? i want a tool that will decompile code and dump as asm instructions and i add my custom instructions more to it and compile back.Possible? if yes any tool do it ? i ve seen some tools distorm but its just disassembler not assembling back ;( any idea? Nov 15 08:36:22 or for ASM codes? Nov 15 08:36:33 sry ARM Nov 15 08:58:19 good morning Nov 15 09:51:52 mornin Nov 15 10:08:00 gm Nov 15 10:21:36 hi all Nov 15 10:23:53 hi Nov 15 10:37:48 Good morning! Nov 15 10:41:14 mornin florian Nov 15 10:56:42 bluelightning: hi Nov 15 10:58:49 bluelightning: I see poky is still using own set of recipes instead of oe-core :/ Nov 15 10:59:07 ant_work: ??? Nov 15 10:59:11 we're using oe-core... Nov 15 10:59:16 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta?h=edison Nov 15 10:59:42 so, that's an integration of the metadata from oe-core; all changes go across Nov 15 10:59:50 maybe smthg not yet backported/cherry-picked Nov 15 10:59:51 in order that it's a single checkout Nov 15 11:00:17 hi ericben Nov 15 11:05:41 bluelightning: I see, edison was an older checkout Nov 15 11:06:35 ant_work: yes, edison is a branch from which the yocto 1.1 release came (and to which patches are being added for the next yocto point release) Nov 15 11:07:53 hi GNUtoo Nov 15 11:08:06 ok, I discovered how the layer around are solving the X11 issues I have... Nov 15 11:08:25 i.e. meta-intel deploys an older xorg_1.9.3 Nov 15 11:09:17 ericben, I'll ping you in PM Nov 15 11:09:26 *PM you Nov 15 11:10:52 am i on crack or did the linux-2.6.35.14 source go away? my recipe is failing and i cannot find the link its pointing too... Nov 15 11:13:20 from what i know only the major releases are back Nov 15 11:13:37 so yes this archive is likely to be missing Nov 15 11:13:57 doh... okay Nov 15 11:14:37 * geiseri hopes they people who hacked k.o are proud of themselves... Nov 15 11:18:34 btw does someone knows what to clean to get rid of libgtk-x11-2.0.so: undefined reference to `floorf@GLIBCXX_3.4.3' at compilation time (I already cleaned the toolchain that way: bitbake -c cleansstate gcc gcc-cross gcc-cross-initial gcc-cross-intermediate gcc-runtime binutils binutils-cross eglibc eglibc-initial) Nov 15 11:25:50 and of course -lm is passed Nov 15 11:32:14 GNUtoo: btw you didn't clean libgcc Nov 15 11:34:33 ahhh Nov 15 11:34:37 maybe that's it Nov 15 11:35:11 so I just add libgcc or there are variants of it too(cross,native etc..) Nov 15 11:37:07 hmm, there is openssl in openembedded-core and also in the meta-oe layer, why the duplication? Nov 15 11:37:39 meta-oe has newer Nov 15 11:38:03 I do see that, but why didn't it go straight to core? Nov 15 11:38:22 well, floorf@GLIBCXX_3.4.3 is just plain weird. firstly, I don't think that symbol should ever be getting exported with that version, and secondly I don't think gtk+ should ever be linking with a library that exports anything at all @GLIBCXX_3.4. Nov 15 11:38:29 see oe-core ML someone is planing to merge it later Nov 15 11:38:47 * Jin^eLD still finds this whole separation quite confusing... Nov 15 11:47:36 Jin^eLD: that's a very good question, if there's no explanation in the commit message perhaps it would be worth asking the person who committed it Nov 15 11:48:08 ah, indeed, I should look up the commit message first, somehow I did not think about that :P Nov 15 11:50:56 angstrom-layers: meta-openembedded: add openssl recipe from OE into recipes-connectivity Nov 15 11:51:01 commited by Koen Nov 15 11:51:25 so, no explanation, that's unfortunate :/ Nov 15 11:52:23 is there actually anyone who oversees all those repos? Nov 15 11:52:46 in order to prevent them from drifting apart or duplicating each other? Nov 15 11:53:34 bluelightning: .bbappends didn't work very well back then.. so I can imagine it was just to get -native working for other meta-oe stuff Nov 15 11:53:43 bluelightning: or something like that Nov 15 11:54:07 and we needed something working to test it before we could start sending patches for oe-core Nov 15 11:54:10 03Paul Eggleton  07master * re492eb4dc9 10bitbake.git/lib/bb/runqueue.py: (log message trimmed) Nov 15 11:54:10 lib/bb/runqueue: avoid marking runtime dependencies as covered Nov 15 11:54:10 The code which populates setscene_covered list was adding a task to the Nov 15 11:54:10 covered list if all of the tasks that depend upon it were also covered; Nov 15 11:54:10 however, this means that tasks that would have installed "runtime" Nov 15 11:54:11 dependencies were being marked as covered also, e.g. gmp-native and Nov 15 11:54:12 mpfr-native are needed by gcc-cross at runtime since they are shared Nov 15 12:09:03 Jin^eLD: it's a collective responsibility really Nov 15 12:09:43 JaMa: really? I thought bbappend functionality hadn't actually changed much Nov 15 12:09:45 bluelightning: that's a little dangerious, since nonoe might have the overall overview... some guidelines to prefent cluttering would be good Nov 15 12:09:58 s/nonoe/noone/g Nov 15 12:10:16 Jin^eLD: I'd love there to be guidelines, up until now I guess everyone's been too busy just trying to make things work Nov 15 12:10:23 bluelightning: there was problem that you have to touch original recipe to invalidate it's cache and .bbappend to apply Nov 15 12:10:46 JaMa: well, you're right on that one Nov 15 12:11:26 in any case, it looks like zenlinux might be addressing the openssl overlap, at least he brought it up on the mailing list the other day Nov 15 12:15:41 Jin^eLD: I am a bit pessimistic wrt overlap: the 2 cases I reported months ago are still duplicated Nov 15 12:15:55 ah, so you also noticed that already Nov 15 12:16:19 Jin^eLD: yes, we're all aware of the overlaps, it's just going to take someone's time to clean it up Nov 15 12:18:01 Jin^eLD: one was udev, nice, isn't ? Nov 15 12:18:19 yes indeed, udev is also duplicated Nov 15 12:18:42 seems that newer versions went to meta-oe and oe-core stayed with older recipes Nov 15 12:19:47 yes, while trying to support older kernels maybe. There are patches for the older kernels, in case Nov 15 12:20:07 it's funny Yocto spots kernel 3.x Nov 15 12:24:01 JaMa, still libgtk-x11-2.0.so: undefined reference to `floorf@GLIBCXX_3.4.3' Nov 15 12:24:08 should I rebuild from scratch at that point? Nov 15 12:24:32 I think it's the second or third time that I rebuild from scratch Nov 15 12:25:01 GNUtoo: dunno Nov 15 12:25:46 and khem is not there....hmmmm Nov 15 12:28:06 libm: 000277fc W floorf Nov 15 12:28:11 with nm Nov 15 12:28:32 I'll rebuild from scratch....again then Nov 15 12:33:33 ahh maybe I get it Nov 15 12:33:39 it link in a strange way Nov 15 12:33:59 (not that strange but anyway...) Nov 15 12:34:11 it link to the libs directly instead of autodetecting them Nov 15 12:34:25 like /home/..../foo.so Nov 15 12:34:31 *libfoo.so Nov 15 12:34:39 instead of -lfoo Nov 15 12:41:47 maybe adding -lm to LIBXFCE4UI_LIBS would fix? Nov 15 12:42:55 but there are so many packages to fix => better fixing the .pc instead or something like that Nov 15 12:50:42 still the same while linking manually Nov 15 12:52:14 GRRR I'll have to rebuild from scratch Nov 15 12:52:27 or maybe to rebuild gtk+ Nov 15 12:52:29 would be faster Nov 15 13:06:43 seem that cleansstating gtk+ did the trick Nov 15 13:06:48 thanks all for the help Nov 15 14:25:00 anyone have any more thoughts on why samba fails to build for me? Nov 15 14:25:09 the eror message is pretty useless Nov 15 14:29:26 well, the error message seems fairly self-explanatory. did you check for CROSS COMPILE Badnesses? Nov 15 14:38:10 the error messgae complians about a pth in staging Nov 15 14:39:25 I still struggle from the problem that each time I do bitbake myimage, then u-boot is being rebuilt; kergoth noticed a posible SRCREV problem yesterday, but my u-boot is built from a tarball, so that's not it; I was looking with bitbake -e but did not really find anything (or maybe did not know what to look for) Nov 15 14:39:43 any ideas what I could do to figure out why u-boot is rebuilt each time when I bitbake my image? Nov 15 14:39:45 which path in staging? Nov 15 14:40:01 if it's deciding that a staging path is a Badness then that sounds like a bug. Nov 15 14:41:43 http://pastebin.com/5PGX6MZr Nov 15 14:42:01 I don't see any staging path in that paste. Nov 15 14:42:11 urg work Nov 15 14:42:39 but why does it decide that using a path to wrok is a problem Nov 15 14:42:45 that's just the root of the tree it's trying to build. you need to inspect config.log to find the actual offending path. Nov 15 14:43:09 'll look again, but like I am saying this is not clear at all Nov 15 14:43:24 last time I looked i config.log it seemed ok Nov 15 14:43:29 and this worked a few days ago Nov 15 14:49:57 fishing through config.log and the output Makefile, nothing obvious Nov 15 14:50:47 so, no CROSS COMPILE Badness or "is unsafe for cross-compilation" kind of diagnostics? Nov 15 14:51:24 no Nov 15 14:51:34 I grepped temp/* for CROSS Nov 15 14:51:42 and the Makefile looks ok Nov 15 14:51:42 er, config.log isn't in temp/ Nov 15 14:51:51 I read config.log Nov 15 14:52:10 can you put it in a pastebin? Nov 15 14:52:29 sure Nov 15 14:53:32 what's the past way to upload afile to a pastebin ... Nov 15 14:54:07 there was one, but I forget Nov 15 14:57:08 pastebin.com needs a pro account Nov 15 14:57:16 ah Nov 15 14:58:29 try http://paste.debian.net though there is a size-limit Nov 15 15:01:00 greetings; i'm having a tough time building a gcc for arm cortex-a8 that properly does -mfloat-abi=hard -mfpu=neon (i'm getting the problem with the VFP register usage not matching). does the OE compiler support cortex-a8 and the hard floating point register usage? Nov 15 15:04:04 also, i'm trying to build arm-none-eabi-, not arm-linux-gnueabi-, because i have a couple projects that require to be run on bare metal. Nov 15 15:08:52 bother, config.log is 4.5M Nov 15 15:17:00 obi, Nov 15 15:19:26 Hi everybody Nov 15 15:19:37 I use dropbear in my image Nov 15 15:19:57 and I want to add a patch to init script of dropbear Nov 15 15:20:25 Crofton|work, i have a similar problem building tcpdump. When libpcap is installed on the host, it tries to link against that and it show the 'autoconf log indicates errors' message Nov 15 15:20:43 I want it to be available for my friends too. Nov 15 15:21:21 Is that a way to tell oe while handling dropbear generic bb, use a new task from a different file Nov 15 15:21:29 Crofton, grepping for CROSS is not enough, try 'unsafe for' Nov 15 15:21:50 I dont want to touch usual dropbear bb and sources, just want to add a patch to init script Nov 15 15:22:44 thanks, that got it Nov 15 15:23:48 Crofton, how can i fix such a problem, then? :) Nov 15 15:25:25 heh Nov 15 15:25:40 in my case, I think I will remove samba from gvfs :) Nov 15 15:26:09 :/ Nov 15 15:27:38 RP, was on the right track with python Nov 15 15:33:57 hi zecke Nov 15 16:58:45 hmm, I just disocvered sources in /usr/share/gettext/intl/ on my rootfs?! Nov 15 16:58:46 :> Nov 15 16:59:05 .c and .h files Nov 15 16:59:10 the -dev package for gettext should include some there.. Nov 15 16:59:21 I'm sure I am not installing dev packages Nov 15 16:59:29 if it came from something other then -dev it's likely a bug Nov 15 17:00:42 Jin^eLD: if you have a package system it should be able to tell you where the files came from... Nov 15 17:01:03 bluelightning: yes that'd be the next step, I unpacked the rootfs on the usb stick (using that as rootfs for quick testing) Nov 15 17:01:09 have to boot first to ask the package manager Nov 15 17:01:28 you can check Packages.filelist, assuming you're using ipk Nov 15 17:01:48 I am indeed Nov 15 17:02:14 dcgettext.c eglibc-dbg:armv5te:./usr/src/debug/eglibc-2.12-r27/eglibc-2_12/libc/intl/dcgettext.c,gettext:armv5te:./usr/share/gettext/intl/dcgettext.c Nov 15 17:02:35 hat's from filelist Nov 15 17:03:06 booting now to recheck Nov 15 17:04:55 http://pastebin.mozilla.org/1383284 Nov 15 17:05:23 the flies are part of gettext - 0.18.1.1-r4 Nov 15 17:05:32 which I did not modify, using whatever came with oe core Nov 15 17:06:34 are those source files really supposed to be there? Nov 15 17:12:11 1.1MB worth of stuff in there :P Nov 15 17:38:33 where do we generate task hashes? Nov 15 17:38:46 im trying to compare two hashes to see why they are different Nov 15 17:38:50 whats the actual content of the hashes? Nov 15 17:40:49 Jin^eLD: gettext is a development tool, so probably yes. Nov 15 17:41:10 I think the question you ought to be asking is "is gettext really supposed to be installed?" and the answer to that one is probably no. Nov 15 17:53:27 msm: I think it's in bitbake/lib/bb/siggen.py Nov 15 17:53:57 but you may find that bitbake-diffsigs will help answer your questions about what's different Nov 15 18:09:47 is there an ipk that installs all of the available python modules? Nov 15 18:27:09 bluelightning: i think its in _build_data Nov 15 18:27:18 bluelightning: but still parsing all this code =) Nov 15 18:27:31 bluelightning: _build_data in bitbake/lib/bb/siggen.py Nov 15 18:43:19 msm: did bitbake-diffsigs help at all? Nov 15 18:43:58 bluelightning: its not showing why the taskhash is different Nov 15 18:44:07 so not really for this Nov 15 18:44:47 if you have the sstate cache outputs for both runs it should be able to... Nov 15 18:44:57 pb_: but this package also provides the gettext binary... I use that to translate some shell/cgi scripts Nov 15 18:45:00 03Vita Preskovsky  07org.openembedded.dev * rbe7fc55acc 10openembedded.git/recipes/bluez/bluez4_4.95.bb: Nov 15 18:45:00 bluez4: Add version 4.95 Nov 15 18:45:00 Signed-off-by: Vita Preskovsky Nov 15 18:45:00 Signed-off-by: Koen Kooi Nov 15 18:45:15 so maybe the approach woul be to split up the gettext package into the sort-of-dev part and the utilities part Nov 15 18:48:30 bluelightning: i do… bitbake-diffsigs does not showw them currently Nov 15 18:48:48 because bitbake-diffsigs is only telling me the hashes are different =) Nov 15 18:48:59 msm: hmm, well I guess that must be a bug then... Nov 15 18:49:53 Jin^eLD: isn't that what the recent gettext-minimal change was about? Nov 15 18:51:22 bluelightning: are you sure htis data is in the siginfo? Nov 15 18:51:45 the code is explicitly avoid showing the differences for the taskhash Nov 15 18:51:50 bluelightning: I guess I missed that change then, thanks for the hint Nov 15 18:54:04 msm: which code are you looking at specifically? Nov 15 18:54:58 bluelightning: hmm, but I see only a gettext-minimal-native Nov 15 18:55:07 no minimal target version? Nov 15 18:55:13 hm or maybe I am not up to date Nov 15 18:55:37 Jin^eLD: right, that's correct... the recent change was just about speeding up the initial part of the build (or rather, reducing a bottleneck) Nov 15 18:56:19 bluelightning: ok so wat I need is still a tuned gettext package for my target then, I see.. Nov 15 18:57:49 bluelightning: dump_sigfile and compare_sigfile Nov 15 18:57:58 keep in mind im a python newbie Nov 15 19:00:47 msm: AFAICT, anything taken into account when computing the hash should also be part of the siginfo file Nov 15 19:03:45 bluelightning: ok - well i've got the build phase outputting the data at the moment to debug Nov 15 19:04:09 msm: ok, it would be interesting to hear what you find... Nov 15 19:05:17 bluelightning: my guess is so silly var that needs to be whitelisted Nov 15 19:05:20 is some* Nov 15 19:08:28 and i think i've found it Nov 15 19:08:32 PATCHRESOLVE Nov 15 19:18:51 err back Nov 15 19:56:04 msm: wow, nothing should depend on PATCHRESOLVE, that definitely sounds like a bug Nov 15 19:56:17 also, why did it not record that in the dependencies? Nov 15 20:07:22 its there Nov 15 20:07:31 bluelightning: it just does not show it in bitbake-diffsig Nov 15 20:07:36 also patch_do_patch Nov 15 20:10:30 msm: well if we can fix it so it does show up in bitbake-diffsigs that would be worthwhile Nov 15 20:11:00 * bluelightning -> home Nov 15 20:12:26 yea it only shows the hash if the filenames are the same Nov 15 20:12:40 which is a problem because the path to the bb recipes can easily be different Nov 15 20:12:44 then if the hashes are different Nov 15 20:12:53 it does not show the actualy values that are different Nov 15 20:13:17 he's gone =( Nov 15 20:44:51 evening all Nov 15 20:45:44 * pb_ needs a new laptop Nov 15 20:45:58 anybody used a thinkpad x121e and have a view on it? Nov 15 22:08:33 guile is broke in oe-core Nov 15 22:10:24 similar problem was sovled in native version by adding gettetxt to inherit Nov 15 22:56:49 bleh Nov 16 01:22:43 hey. what's the startup and kill order of daemons for angstrom? i've placed in my recipe INITSCRIPT_PARAMS="defaults 90" for my script to start late and be killed early during shudown, and it is started late, but it seems to be stopped at the end **** ENDING LOGGING AT Wed Nov 16 02:59:57 2011