**** BEGIN LOGGING AT Tue Nov 23 02:59:57 2010 Nov 23 03:52:43 is there a doc how to use distcc and oe? Nov 23 03:57:37 that is probably not going to be easy Nov 23 03:58:10 unless the build root is mounted over NFS Nov 23 03:58:56 j24: All of the machines would need to have the toolchain available Nov 23 04:00:06 you could easily use distcc for the -native biulds Nov 23 04:00:34 bgamari: yeah I known Nov 23 04:00:45 bgamari: but how configure oe to use it? Nov 23 04:01:27 would require some hacking i think Nov 23 04:02:42 I've in mind to use a codesourcery toolchians Nov 23 04:03:02 and ask oe to use an external toolchains if it can Nov 23 04:03:03 you could try building a meta-toolchain, distributing that to your compile nodes, then set it as a prebuilt toolchain using ASSUME_PROVIDED Nov 23 04:03:36 if things work with the external toolchain, there's no reason why you couldn't farm things out with distcc Nov 23 04:04:05 would be more a matter of reading distcc docs Nov 23 04:04:13 I known distcc Nov 23 04:04:24 but wonder how to do it with oe Nov 23 04:05:33 because I search an example how to configure oe to use my external toolchains Nov 23 04:06:05 havent tried using an external toolchain Nov 23 04:06:53 don't know if its currently working or not, i haven't heard anyone mention they are using it Nov 23 04:09:40 ok will try Nov 23 04:38:11 hmm, a number of failures for native-sdk-image with DISTRO=micro, must be more /bin vs /usr/bin issues Nov 23 04:43:02 i'm not sure that micro will be ready for release Nov 23 04:43:09 * grg shrugs Nov 23 04:53:20 agreed, doubtful Nov 23 04:53:25 * kergoth works through some of the issues Nov 23 07:05:39 ka6sox are you also managing patchwork.openembedded.org ? Nov 23 07:12:29 eFfeM_work, I don't acutally manage the content... Nov 23 07:13:55 ka6sox who manages the app, it does not seem to work and might need a restart Nov 23 07:19:37 again!... Nov 23 07:32:10 unless it has been restarted last few days Nov 23 07:46:07 eFfeM_work, I restarted it like 24hrs ago. Nov 23 07:47:12 hm there have been patches from grg about 4 hrs ago, and I do not see them in patchwork Nov 23 07:47:32 guess there is another issue that is not solved by restarting Nov 23 07:49:25 hmmm...ya, adding patches might be problematic currently Nov 23 08:10:29 good morning Nov 23 08:19:22 morning Nov 23 08:39:18 Hello all Nov 23 08:39:30 I was trying to build rpm package Nov 23 08:39:43 but it is failing at do_compiler task Nov 23 08:41:00 magic.mime, 672: Warning: no need to escape `#' Nov 23 08:41:38 file: could not find any magic files! Nov 23 08:41:52 this is the output of do_compile task Nov 23 08:42:03 any idea why rpm package is failing Nov 23 08:49:20 anyone has checked rpm package? Nov 23 08:49:55 heyho Nov 23 08:59:59 morning Nov 23 09:00:35 morning Nov 23 09:00:53 another happy shiney day in OE land Nov 23 09:00:57 :) Nov 23 09:01:17 hay anyone has any suggestion regarding the problem that I am facing while building rpm package Nov 23 09:01:46 Noor: check the recipe vs the Poky version Nov 23 09:01:53 I think rpm atually works in poky Nov 23 09:02:05 it was not so shiny for me yesterday, somehow I ended up with an unupgradable package :( same lib - after an update of the lib the package name was mangled in a different way and now I have troubles when I try to upgrade Nov 23 09:02:21 eeeeks how did that happen? Nov 23 09:02:41 i was building yocto Nov 23 09:02:48 it build fine over there Nov 23 09:03:08 yocto is poky Nov 23 09:03:14 yeah Nov 23 09:03:21 but see what difference there is Nov 23 09:03:28 but there is higher version Nov 23 09:03:30 I know rpm in OE got very little love Nov 23 09:03:43 the recipe is totally diff altogether Nov 23 09:04:09 then I suggest patching the poky one into OE Nov 23 09:04:22 in oe we have 4.4.2.3 and in poky 5.1.10 Nov 23 09:04:34 OK Nov 23 09:04:53 you then can claim your own little fame :-D Nov 23 09:05:24 :D Nov 23 09:05:54 XorA: to be honest, I am still not sure, currently rebuilding my whole OE tree... the recipe is called libdsm-api_git.bb, the library ended up in libdsm-api_0.0.0+gitrxxxx package, now for some reason the library ends up in libdsm-api-v2-1.0.0_0.0.0+gitrxxxx (the .so file is indeed called libdsm-api-v2.so.1.0.0, but that was also the case in the previous version) Nov 23 09:05:59 * XorA has actually wanted to move Angstrom to a real package manager for years Nov 23 09:06:41 looks like someone updated the SONAME in git Nov 23 09:06:42 so now when I try to upgrade there is a clash, because libdsm-api-v2-1.0.0 is seen as a different package and it conflicts with the old version which is named libdsm-api Nov 23 09:07:05 you can add a RREPLACES = "oldmangling" Nov 23 09:07:16 RREPLACES_${PN} Nov 23 09:07:45 I was trying that yesterday but I assume I ended up in some sort of overall mess, so rebuilding the whole image now and will try the RREPLACES thing again Nov 23 09:12:32 khem, the idea was to be able to _disable_ LFS, not enable it ;P Nov 23 09:12:43 khem, i'll have a look Nov 23 09:13:34 hi, im trying to build xkeyboard-config, but it fails with Nov 23 09:13:35 "configure.in:41: error: possibly undefined macro: AC_PROG_INTLTOOL and AM_GLIB_GNU_GETTEXT" Nov 23 09:14:04 do i have to compile glib-2.0 as well? or why it doesn't depend on that? Nov 23 09:24:31 03Martin Jansa 07master * r75a63e4b26 10openembedded.git/recipes/freesmartphone/msmcomm.inc: Nov 23 09:24:31 msmcomm: bump SRCREV, this version at least compiles with current fsogsmd Nov 23 09:24:31 Signed-off-by: Martin Jansa Nov 23 09:38:58 adding glib-2.0-native to DEPENDS in xkeyboard-config_1.8.bb fixes the problem ... Nov 23 10:36:43 hi micro distro seems broken : eglibc-initial fails at configure : http://tinderbox.openembedded.net/public/logs/task/10922821.txt Nov 23 10:37:13 ericben: you neeed newer binutils for arm Nov 23 10:38:07 JaMa: yes but micro doesn't select the right version by default Nov 23 10:38:23 I'll try to send a patch for this Nov 23 10:38:42 to align micro's toolchain to minimal distro Nov 23 10:39:25 ericben: I have same patch locally, because I expect it's pinned to older version ie because of mips support or something, I didn't send it Nov 23 10:39:46 ericben: as someone reported that micro+mips builds ok Nov 23 10:41:33 JaMa: shouln't PREFERED_BINUTILS_arm = 2.20.1 fix the problem ? Nov 23 10:45:34 03Koen Kooi 07org.openembedded.dev * radff932f0f 10openembedded.git/recipes/linux/ (2 files in 2 dirs): Nov 23 10:45:34 linux-omap-zoomsync 2.6.32: add back a modified version of rev.patch Nov 23 10:45:34 This fixes the omap3-sgx-modules build Nov 23 10:45:34 Signed-off-by: Koen Kooi Nov 23 10:47:27 ericben: yes, but someone is also trying to build micro with old glibc http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg02779.html Nov 23 10:48:08 ericben: but you're right that default should work (and eglibc-2.12 is default in micro) Nov 23 10:48:21 JaMa: ok in that case we can put ?= in the conf file so that the user can overide the version in it's machine or local conf Nov 23 10:52:14 03Koen Kooi 07org.openembedded.dev * ra0ece31cba 10openembedded.git/recipes/linux/ (9 files in 2 dirs): Nov 23 10:52:14 linux-omap 2.6.37rc2: add patch to add omap_rev_* macros Nov 23 10:52:14 Signed-off-by: Koen Kooi Nov 23 10:53:43 hi, could someone do a "s/icons/pixmaps" in http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/e17/e-wm_svn.bb line 50 please? Nov 23 10:54:24 and line 51 too Nov 23 10:58:07 pespin: please send a patch to the mailing list Nov 23 10:59:23 ok Nov 23 11:22:17 is autoconf broken atm? Nov 23 11:33:31 NOTE: package ffmpeg-2_0.6+r16.3+svnr24596-r16.3: task do_compile: Failed Nov 23 11:36:37 http://tinderbox.openembedded.net/packages/1052273/ Nov 23 11:36:46 Using busybox on an embedded device, does cat /xx.img >/dev/mtd takes care of bad blocks ? Nov 23 11:39:29 melchior: afaik, no Nov 23 11:39:31 melchior: use nandwrite Nov 23 11:40:27 Oh my god, i'm struggling since this mornig to make nandwrite work but i could not. Nov 23 11:41:05 even the flashcp functions does not work because of permission errors Nov 23 11:44:04 melchior: forgot to unlock mtd? Nov 23 11:45:24 Permission denied too for flash_unlock Nov 23 11:45:32 but 'cat' works Nov 23 11:46:02 i'm taking a break, back in 20 min... Nov 23 12:08:28 khem: release branch build of antstrom-gnome-image failed on ffmpeg-2_0.6+r16.3+svnr24596-r16.3 Nov 23 12:08:33 * Jay7 afk Nov 23 12:11:58 how can i see the number of tasks..? while oe is building ? Nov 23 12:13:17 vlrk i guess it will be equal to BB_NUMBER_THREADS Nov 23 12:16:39 fraxinas: in mtx-3a.conf of conf/machine it gives the comment as #@TYPE: Machine - the orange marvell box Nov 23 12:16:50 is it like we can use this for Marvell boards Nov 23 12:16:51 ..? Nov 23 12:18:14 i am not familiar with marvell boards, but i am sure there is a whole variety of them. you will need to have the exact board configuration Nov 23 12:19:38 can you point to the info where i can create my own distro and give my own toolchain to oe..? Nov 23 12:35:30 can any body point me to to the info where i can create my own distro and give my own toolchain to oe..? Nov 23 12:57:56 vlrk: I dont think anyone ever documented it, anything wrong with Angstrom? Nov 23 12:59:39 XorA: Nov 23 13:00:11 XorA:iam just trying to see if i need to give my own distro in case iam providing my own tool chain to oe Nov 23 13:01:07 OE has support for external toolchains, but Im not experienced at using that support Nov 23 13:01:14 autoconf fails for me with this do_compile log: http://pastebin.com/7bZdkiaG Nov 23 13:01:18 this a new architecture? Nov 23 13:29:20 XorA: old and new .bb recipe name is "libdsm-api", old mangling of the lib ipk is "libdsm-api", new mangling of the lib ipk is "libdsm-api-v2-1.0.0", what do I specify in RREPLACES in my recipe? RREPLACES_${PN} = "libdsm-api" or RREPLACES_libdsm-api-v2-1.0.0 = "libdsm-api" ? And will it work at all, since the recipe name from which the packages were generated is the same? Nov 23 13:32:39 Jin^eLD: I think youll just have to experiment with that one Nov 23 13:33:01 i think ACES_${PN} = "libdsm-api" is correct Nov 23 13:33:25 that produces the following in the control file Nov 23 13:33:26 Replaces: libdsm-api-v2-1.0.0 Nov 23 13:33:39 so it somehow mangled my line too? Nov 23 13:33:46 yes :-( Nov 23 13:34:14 not sure how to do it then Nov 23 13:34:19 might need to ask kergoth Nov 23 13:34:29 kergoth ping :) Nov 23 13:37:01 Jay7: did you remove the angstrom svn mirror? bitbake can't pin svn submodules, so ffmpeg fails when fetching directly from svn, because it only pins part of the source tree to r24596 Nov 23 13:38:51 what's the python's current required version for bitbake ? Nov 23 13:39:03 2.6 or 2.5 ? Nov 23 13:42:29 XorA: the function that does the renaming is in package.bbcclass, def runtime_mapping_rename (varname, d): Nov 23 13:42:54 can I override it in my recipe or append another function to it in order to reset the variable again? Nov 23 13:51:34 dj-death: it depends on the version of bitbake Nov 23 13:52:31 obi: 1.9 Nov 23 13:54:20 1.10 works with python 2.5, at least Nov 23 13:55:53 XorA: seems to work out with python package_mapping_rename_hook_append () { Nov 23 13:55:58 and resetting it there Nov 23 13:59:47 Jin^eLD: I think there has been work in this area since I last played with it, I am clueless Nov 23 13:59:50 aber falls er doch reinschaut... :) mtr: JFFS2 warning: (765) jffs2_sum_write_data: Not enough space for summary, padsize = -743 das kriege ich hin und wieder Nov 23 13:59:52 oops wrong window Nov 23 13:59:56 hehe Nov 23 14:00:07 I always forget to switch the split windows in the BitchX client ;) Nov 23 14:00:11 happens all the time Nov 23 14:00:12 hehe Nov 23 14:01:12 :-D Nov 23 14:01:44 this reminds me that I should finally patch BX for UTF-8 support... :> Nov 23 14:09:23 morning Nov 23 14:09:28 hi kergoth Nov 23 14:09:31 gm Nov 23 14:14:15 03Koen Kooi 07org.openembedded.dev * rdf3ebbe996 10openembedded.git/recipes/powervr-drivers/ (2 files in 2 dirs): Nov 23 14:14:15 omap3-sgx-modules 1.4.14.2616: start updating it for 2.6.37 Nov 23 14:14:15 Signed-off-by: Koen Kooi Nov 23 14:18:51 concerning micro distro + micro-image : it builds fine for i586-generic and i686-generic, it fails for arm with : http://tinderbox.openembedded.net/public/logs/task/10927261.txt because of old binutils, then with PREFERRED_BINUTILS_arm ?= "2.20.1 it fails on arm with : http://tinderbox.openembedded.net/public/logs/task/10935754.txt which is strange because libc6dev seems to be installed in the image Nov 23 14:19:06 huh Nov 23 14:19:46 I don't have time to fix this now, if someone has an idea, i can test it as the build host is free ;-) Nov 23 14:27:19 ericben: your first log seems to show some fixincludes problem. what makes you think this is due to binutils? Nov 23 14:27:57 that latter log does clearly show at least one packaging fail, maybe two. I can have a quick poke at that today. Nov 23 14:28:40 pb_: that's what JaMa told me here, I didn't dig further as aligning binutils to sane toolchain versions fixed the problem Nov 23 14:29:24 ericben: but you've included different error log now Nov 23 14:29:26 and as micro picks latest gcc + latests eglibc it seems normal to get latest binutils Nov 23 14:29:27 mm. seems rather weird that it would be caused by binutils. that said, setting 2.20.1 as the P_V for micro is probably a fine idea. Nov 23 14:29:55 but, if it appears to help with this problem, I would be inclined to put that down to coincidence rather than anything more concrete. Nov 23 14:29:55 JaMa: pb_ : oops this is not the gith log sorry Nov 23 14:30:03 the right log Nov 23 14:30:07 ah Nov 23 14:30:19 this one is when trying to build meta-toolchain Nov 23 14:30:21 using micro Nov 23 14:31:23 ericben, pb_ I was talking about this problem (solved with newer binutils) http://tinderbox.openembedded.org/packages/1001382/ Nov 23 14:31:34 http://tinderbox.openembedded.net/public/logs/task/10921718.txt Nov 23 14:31:37 this is the right log Nov 23 14:31:52 sorry for the mix, I also have a problem with meta-toolchain and micro distro ;-) Nov 23 14:32:09 so clearly micro distro seems quite broken for arm actually Nov 23 14:32:10 righto. that does look like a more plausible binutils failure. Nov 23 14:32:11 and that eglibc packaging problem should be fixed (as I replied on ML) Nov 23 14:32:45 ok, very good Nov 23 14:32:48 so, no action required then? Nov 23 14:32:55 JaMa: ok cool Nov 23 14:33:12 I'm launching a build now and will try meta-tooclhain also Nov 23 14:33:29 newer binutils are still needed Nov 23 14:33:36 pb_: seems so for the moment, I'll ping here once the build is finished Nov 23 14:33:47 JaMa: yes, once acked I'll push my patch Nov 23 14:34:16 JaMa: is you ebligc-dev patch into release branch ? Nov 23 14:35:00 iirc someone else cherry-picked it already Nov 23 14:35:56 JaMaOff: ok thanks, I'm cleaning and rebuilding from scratch as I was on yesterday's release branch Nov 23 14:37:19 urg Nov 23 14:37:28 I need to get a buidl starred Nov 23 14:37:30 * XorA coffees Crofton|road Nov 23 14:37:35 and Crofton|work Nov 23 14:37:38 ericben: ok, very good Nov 23 14:37:55 just got the coffee Nov 23 14:38:15 I had various technicall issues yesterday while travelling Nov 23 14:38:58 * XorA has new laptop for OE on the mpve Nov 23 14:39:10 unfortuneately linux support for it is a bit iffy Nov 23 14:39:23 * XorA dares not use Fn key Nov 23 14:39:52 XorA: Its not a thinkpad, right? ;) Nov 23 14:39:56 seems to be an xorg issue though, switching to console and back fixes it Nov 23 14:40:02 florian: no, samsung Nov 23 14:41:10 Hmm.. my only samsung device is a DVD recorder and this is a great example for a usability hell :-) Nov 23 14:41:20 hehe Nov 23 14:41:36 cheapest core i5 13" laptop I could find Nov 23 14:43:36 2I have several samsung devices here and they work fine. but not laptop Nov 23 14:44:15 I hope to not have to mvoe to laptop as main computer Nov 23 14:51:12 na endlich, OE problem geloest :) Nov 23 14:51:17 oops wrong window once again ;) Nov 23 15:19:20 Until now my install has had only a passwordless root user. I need to a couple more users, set some permissions, and have /etc/shadow and /etc/passwd generated on boot. Is there something in OE that can help me with this job? Nov 23 15:19:55 hmm, good question Nov 23 15:20:44 you might need a custom bb file with some script s to do that? Nov 23 15:21:33 use the past_image hook? Nov 23 15:22:09 not sure if the rootfs hook would be enough, probably want to run adduser, etc, which would have to be run on first boot Nov 23 15:22:15 a recipe for it would probably be better Nov 23 15:25:05 03Marco Cavallini 07master * rdee9e91986 10openembedded.git/conf/distro/kaeilos.conf: kaeilos.conf : version upgrade, bump pr Nov 23 15:25:11 hmm, i should compare parallel-parsing with BB_NUMBER_PARSE_THREADS=1 to master Nov 23 15:25:15 03Marco Cavallini 07master * ra4ed5c23a0 10openembedded.git/conf/distro/include/kaeilos-2009-preferred-versions.inc: kaeilos-2009-preferred-versions.inc : versiona upgrade Nov 23 15:25:42 Sounds like something it would be nice to have a recipe for, but I don't know enough about the users and shadows yet to know what it would have to do. My initial thought was to have a text file with the user names, and encrypted passwords, and have a script to generate what I need from that. Nov 23 15:28:25 he zecke Nov 23 15:52:44 wonder if we should use the cpu_count() for default BB_NUMBER_THREADS as well now, with master Nov 23 15:52:50 instead of defaulting to 1 Nov 23 15:54:48 no Nov 23 15:55:03 kergoth: I think that might be a bit unexpected/unpopular for folks with shared machines. Nov 23 15:55:08 can't always assume a user wants to consume the entire machine Nov 23 15:55:14 pb_, exactly Nov 23 15:55:16 true Nov 23 15:55:23 sometimes I share a machine with myself even Nov 23 15:56:15 * kergoth_ can't remember the last time he did a build without setting BB_NUMBER_THREADS to the # of cores, usually leave it in ~/.oe/site.conf or ~/.oe/conf/site/${HOSTNAME}.conf Nov 23 15:56:20 but fair point Nov 23 15:56:54 well, yeah, personally I always set it to a bit more than the number of cores, but I'm not sure I would necessarily want that to be the default. Nov 23 15:57:10 * kergoth_ nods Nov 23 15:57:18 same as gnu make, I almost always use "make -j20" or some such, but I wouldn't be too keen on make suddenly deciding to do that all on its own. Nov 23 15:57:38 here on i7 I use 4 BBTHREADS and -j16 Nov 23 15:57:56 but I think BBTHREADS could be increased again Nov 23 15:59:02 ericben: is this a i7 970 or 980? Nov 23 15:59:52 florian: 920 and 860 I think Nov 23 16:00:36 these are the values I found to get a decent system load as temperature is actually getting low :-D Nov 23 16:36:09 wonder if the 'Invalid cache found, rebuilding' etc messages should be debug -- most of the time i don't care about that, i just want to build. sometimes it parses faster, sometimes slower, but either way i have to trust that bitbake knows what its doing, and don't really need to know why unless i'm debugging Nov 23 16:39:33 mm, dunno. that message isn't exactly overwhelming, and it might be comforting for the user to know that there really is a reason that it goes slower sometimes. Nov 23 16:39:56 rather than just random capriciousness on bitbake's part. Nov 23 16:42:07 well, it does disrupt the progress display now, which is why i care about it at all Nov 23 16:42:08 :) Nov 23 16:42:38 ah, heh, fair enough Nov 23 16:42:52 in that case yeah, could be debug Nov 23 16:45:18 I probably wouldn't have noticed the bug without that just popping up Nov 23 16:47:53 * kergoth_ will give some thought to how to get it to show before the progress bar starts, not sure if it can be done now though Nov 23 16:49:20 kergoth_: you'd probably have to resort to even more states in parse_next. While you're there, add the necessary states so cache init can fire my events ;) Nov 23 16:50:37 foerster: hehe, indeed Nov 23 16:50:49 bah, would probably need to run cache init in a process, checking for cache-done Nov 23 16:50:53 foerster: i wonder if itd be easier to make the ui a thread rather than a process, but then we'd have to deal with locking Nov 23 16:50:58 heh Nov 23 16:51:10 meh Nov 23 16:51:23 using multiprocessing with queues would be good to separate ui/server Nov 23 16:51:37 * kergoth_ nods Nov 23 16:51:52 might be good to revamp the runqueue to use it for the worker processes too Nov 23 16:51:57 would certainly make that code less ugly Nov 23 16:52:21 everything is slightly bastardized wrt server/ui b/c of the none server. Nov 23 16:52:27 it cheats and makes things confusing Nov 23 16:52:34 maybe we should just drop it entirely Nov 23 16:52:41 if xmlrpc is slow, lets fix the damn thing Nov 23 16:52:52 it's nonfunctional at the moment though Nov 23 16:52:57 ah, right :\ Nov 23 16:53:19 i tried to resurrect it a bit, but it looked to be a PITA Nov 23 16:53:19 well, i say we get parallel parsing merged, *release* a bitbake with it, e.g. 1.12.1, then we start shaking some shit up more Nov 23 16:54:05 yea, parallel parsing is awesome. Anything else we do won't be so dramatic performance wise. Nov 23 16:54:36 I was looking through, there are a lot of unused imports, etc. Should all that stuff be cleaned up? Nov 23 16:54:59 i'd say so, yeah. clean code is important for maintainability Nov 23 16:55:29 i'm running up against end of year deadlines so I can't screw off too much, but I can probably squeeze some clean up work for bitbake in. Nov 23 16:56:40 foerster: i like your change to use multiple load/dump for the cache, thinking about merging that even without the actual progress pieces. now would be the time, so we don't have to bump the cache file version a second time Nov 23 16:57:02 kergoth_: Just test it to make sure it works ;) Nov 23 16:57:06 * kergoth_ nods Nov 23 16:57:09 seems to Nov 23 16:57:11 it looks like it should, but I didn't actually build anything. Nov 23 16:57:14 i just did a parse Nov 23 16:57:45 did you run it? It actually runs faster here by .3 - .4s Nov 23 16:58:11 must have to do with the sheer size of the single load otherwise. Nov 23 16:58:12 not sure if you noticed, but the event firing from worker to server in lib/bb/event.py -- it wraps the dumps()'d object with -- yet we already know pickle knows where its entries start/end, so that seems pretty pointless to me Nov 23 16:58:25 why not just do multiple load/store across that pipe without mangling Nov 23 16:58:47 that'd make sense, will test it here too Nov 23 17:02:08 kergoth_: Without knowing the history, I cannot say, but it seems like the wrapping of was probably in response to some issue? At least, that'd be my guess. Nov 23 17:02:27 good point, will dig through the history Nov 23 17:02:53 thats a possibility, but remember that much of this code was either written by me before i knew python worth a damn, or by RP before he knew python particularly well either :) Nov 23 17:03:33 ericben, do you have a pointer to the right binutils source? Nov 23 17:03:51 Right, so it could be 1) not knowing any better, or 2) pseudo-debugging remnants. Nov 23 17:03:58 * kergoth_ nods Nov 23 17:03:59 will see Nov 23 17:04:31 and I can't say I know python much. I did a little bit 4-5 years ago, not much since then. Nov 23 17:04:33 ka6sox: yes ftp://sourceware.org/pub/binutils/snapshots/binutils-2.19.51.tar.bz2 Nov 23 17:05:25 okay let me get the right one in our sources. Nov 23 17:06:40 eFfeM_work, is patchwork still "down" for you? Nov 23 17:12:48 * foerster is off to the gym Nov 23 17:13:10 florian ping Nov 23 17:13:30 woglinde_: pong Nov 23 17:13:50 florian can you check planet.linuxtogo.org Nov 23 17:14:13 woglinde_: worksforme Nov 23 17:14:30 hrms Nov 23 17:14:33 damn cache Nov 23 17:15:24 :-) Nov 23 17:16:30 I'm trying to build openembedded for beagle board, and having problems with omap3-sgx-modules_1.4.14.2514.bb. I get "No targets specified and no makefile found." Nov 23 17:16:30 Any Ideas Nov 23 17:16:35 ? Nov 23 17:21:19 tsahee hm did you read the readme inside the sgx-modules dir? Nov 23 17:23:39 I don't think I noticed one.. going to do that now.. thank you!\ Nov 23 17:26:21 kergoth did you solve all problems with multiprocess now? Nov 23 17:27:12 woglinde_: Didn't find it. Where is the readme file supposed to be? Nov 23 17:28:02 woglinde_: seems to be working fine for this Nov 23 17:28:31 ericben, please check that I have the right file and md5sum for binutils-2.19.51.tar.bz2 Nov 23 17:28:42 in our sourcemirror Nov 23 17:31:38 tsahee hm seems to be reomved Nov 23 17:33:28 ka6sox: the md5 seems good Nov 23 17:33:31 thanks Nov 23 17:33:50 yw Nov 23 17:36:52 woglinde_: do you happen to have a copy of it? or anything that might help? Nov 23 17:38:33 or even - can I remove this package? for now, I can live without sgx support Nov 23 17:43:32 03Simon Busch 07org.openembedded.dev * r94706f3c2b 10openembedded.git/recipes/lvm2/lvm2.inc: Nov 23 17:43:32 lvm2: remove dependency on device-mapper and bump PR Nov 23 17:43:32 lvm2 does not need the dependency on device-mapper anymore as lvm2 includes device-mapper Nov 23 17:43:32 since some releases. The only version we currently have in our repository even comes with Nov 23 17:43:32 device-mapper included so we can drop the dependency. Nov 23 17:43:33 Signed-off-by: Simon Busch Nov 23 17:45:22 khem: ping Nov 23 17:46:40 khem: I have some commit which should be in the release branch to fix some bug with the lvm2 recipes Nov 23 17:48:26 maybe this will help me: in my local.conf I specify DISTRO = "angstrom-2008.1". However, when bitbake starts it says: DISTRO_VERSION = "2010.7-test-20101123". Is that OK? If not - how do I fix it? Nov 23 17:50:36 khem: anyway ... I wrote it to the ml Nov 23 18:07:01 hi all Nov 23 18:07:38 Okay.. I'll try one last question: I want to compile my own code for the board running OE, without all the bitbake hussle (just a simple hello world, for starters). I understood that tmp should have a directory holding the cross-compilation version of gcc, make, etc. But I found no executable file named gcc in my tmp dir. This is what I try to follow: http://www.linuxtogo.org/gowiki/CompilingYourOwnCode. Nov 23 18:08:35 tsahee: CROSS_COMPILE=/home/stefan/Projekte/OpenEmbedded/build/dev/tmp/sysroots/x86_64-linux/usr/armv5te/bin/arm-angstrom-linux-gnueabi- Nov 23 18:08:51 thats what I use for kernel compiles with an OE toolchain Nov 23 18:09:25 the crosscompiler name for gcc is arm-angstrom-linux-gnueabi-gcc in this case Nov 23 18:09:29 should think about using meta-toolchain to build an sdk for that sort of thing Nov 23 18:13:39 kergoth_: what do you mean a meta-toolchain? Nov 23 18:14:29 kergoth_: yeah, the one above is the lazy way to use OE toolchains for kernel work :) Nov 23 18:25:13 deploy/glibc/sources/ does only contain ine MIT file and no other, anybody who recognizes this? Nov 23 18:50:22 good morning Nov 23 18:50:34 its quite a rainy day today here Nov 23 18:51:16 no rain here...yet Nov 23 18:51:21 but you are sending it my way. Nov 23 18:51:40 hmmmmm Nov 23 18:51:43 * kergoth_ ponders Nov 23 18:52:24 i wonder if there's a better solution for the progress bits.. koen makes a good point about the eta Nov 23 18:52:42 eta can't be accurate when the early recipes are fully cached and the others are parsed, the time it takes is too different Nov 23 18:53:39 hrm Nov 23 18:57:07 Its starts snowing over here. Still a mix between rain and snow but we will get there :) Nov 23 18:58:10 khem: I did some larger build tests on the release branch (minimal, console, meta-toolchain, native-sdk, openjdk-6) all looks good on 32 and 64 bit Nov 23 18:58:41 Is meta-toolchain building actually? Nov 23 18:58:50 It wasn't and nothing has gone in that could have changed that Nov 23 18:58:54 only one machine right now (bug20) might test some other after I did a big angstrom-x-image build Nov 23 18:59:22 Tartarus: i just build for me. armv7 and angstrom 2008.1 Nov 23 18:59:42 How? Nov 23 18:59:46 sec Nov 23 18:59:47 hmmmm Nov 23 18:59:57 hi, meta-toolchain builds fine for me on several config (see testing page) Nov 23 19:00:07 http://tinderbox.openembedded.net/public/logs/task/10788802.txt Nov 23 19:00:20 What bitbake are you guys using? Nov 23 19:00:40 10.1 Nov 23 19:00:44 Tartarus: 1.10.1 Nov 23 19:00:59 can you try minimal? Nov 23 19:01:06 for a distro Nov 23 19:01:35 can do Nov 23 19:02:02 i'll go try your combo out Nov 23 19:02:06 Tartarus: work fine for me Nov 23 19:03:18 meta-toolchain-qte was built for armv5/v6/v7 i586 & i686 for angstrom 2010.x and minimal distros Nov 23 19:03:33 Something is up... Nov 23 19:03:41 I've been getting the above error for a long time Nov 23 19:03:47 both master and I'd swear 1.10.1 Nov 23 19:04:07 I start from a clean dir to build Nov 23 19:04:42 same Nov 23 19:06:00 kergoth: I use wall clock not the ETA that bitbake shows me :) Nov 23 19:06:04 stefan_schmidt: good job Nov 23 19:06:12 strange, you can check my results here : http://tinderbox.openembedded.net/packages/meta-toolchain-qte/ Nov 23 19:06:43 http://tinderbox.openembedded.net/packages/meta-toolchain/ is wierd, yeah Nov 23 19:06:55 khem: I think we still have a problem with angstrom-2010.x and its libtool 2.4 usage Nov 23 19:07:06 Jay7 has the failure too Nov 23 19:07:09 khem: hehe. well, we could always drop the ETA part of the progress bar until we revamp that stuff Nov 23 19:07:13 might be best for the time being Nov 23 19:07:26 khem: The last time I tried this for openjdk-6 I had problems with Oe trying to use libz from the host Nov 23 19:07:47 Tartarus: this is maybe stupid but maybe you path is to long for one tool ? Nov 23 19:07:54 * kergoth_ thinks about potentially combining CookerParser, CacheData, and potentially Cache into a RecipeSet Nov 23 19:07:56 khem: Will try to start a build tomorrow and let you know when I have logs Nov 23 19:08:43 ericben: Shouldn't be that kind of issue, no Nov 23 19:08:54 I did some bitbake -g'ing and task-sdk-host just wasn't showing up as something we needed Nov 23 19:09:12 khem: I'm going to push the 3 patch I sent, if you can cherry pick them for release I'll launch a clean build after to verify everything is ok Nov 23 19:09:34 builds started now, will have more info soon :) Nov 23 19:09:56 morning again Nov 23 19:10:19 obi: failure was in do_compile, not in do_fetch Nov 23 19:11:15 yes, that's how it shows Nov 23 19:11:40 ericben: good seem ok. I was not sure about that linux/limits.h inclusion Nov 23 19:11:48 does kernel have limits.h too ? Nov 23 19:11:57 http://tinderbox.openembedded.net/public/logs/task/10898542.txt Nov 23 19:12:03 khem: without it old kernel font build with recent toolchains Nov 23 19:12:07 obi: error: libavutil/opt.h: No such file or directory Nov 23 19:12:17 i know Nov 23 19:12:28