**** BEGIN LOGGING AT Mon Sep 13 02:59:57 2010 Sep 13 05:58:49 nar: is it arm ? and what version of gcc and eglibc Sep 13 06:10:36 gm Sep 13 06:18:19 khem how's your bitbake world going / mine seems to stop at 11453 of 71984 Sep 13 06:20:35 qte-mt_2.3.10 do_configure failed Sep 13 07:10:34 eFfeM_work, Running task 28106 of 80542 Sep 13 07:12:23 grg what distro/machine ? Sep 13 07:13:18 eFfeM_work, minimal/qemumipsel Sep 13 07:13:46 I'm using minimal/calamari (which is a power pc) Sep 13 07:14:08 what do you mean that it stops? Sep 13 07:14:28 still get these when it starts: ERROR: '['/home/hudson/jobs/FM_world/workspace/openembedded/recipes/moblin/nbtk_git.bb']' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'nbtk' but it wasn't found in any PACKAGE or RPROVIDES variables of any buildable targets Sep 13 07:14:39 thought ericben had provided a patch to fix it Sep 13 07:15:45 grg this is what I get: http://www.pastie.org/1155265 Sep 13 07:15:49 and I am using bitbake -k Sep 13 07:16:35 actually seems to be python-numpy unpack Sep 13 07:17:32 eFfeM_work, python-numpy is arm only Sep 13 07:17:45 it has a patch file that lives in an arm subdir Sep 13 07:18:13 or config.h file, to be precise Sep 13 07:19:05 hm, if it is arm only it should say so with COMPATIBLE_MACHINE Sep 13 07:19:06 interesting that it kills bitbake -k Sep 13 07:19:53 verified and I indeed started with -k Sep 13 07:20:06 tried it twice, at least it is reproducible Sep 13 07:22:12 it stops due to the FATAL in the last line of the pastie Sep 13 07:22:43 my world.log shows that python-numpy has already run do_unpack (and failed to do so). Sep 13 07:22:44 FATAL: Unable to start to 'None' UI due to exception: [Errno 2] No such file or directory: '/home/hudson/jobs/FM_world/workspace/tmp/work/ppce500v2-oe-linux-gnuspe/python-numpy-1.4.1-ml0/temp/log.base_do_unpack.4141' Sep 13 07:23:02 what bitbake are you using? Sep 13 07:23:10 did a git pull this morning Sep 13 07:23:10 I use 1.10 from the tarball Sep 13 07:23:36 good morning Sep 13 07:23:40 my bitbake is at c07cc08f7fd503ac3013ccc43c79198c4c3b7b29 Sep 13 07:23:43 mornin' Sep 13 07:24:04 hi mckoan Sep 13 07:24:15 grg might try that Sep 13 07:27:32 morning Sep 13 07:32:22 hi hrw Sep 13 07:36:02 hi hrw, eFfeM_work Sep 13 07:48:36 khem: ping Sep 13 07:49:40 anarsoul: I guess khem is asleep, it is 1 am in his tz Sep 13 07:49:52 oh Sep 13 07:50:34 eFfeM_work: maybe you can answer why startup-notification depends on evas? Sep 13 07:50:35 he's in california Sep 13 07:51:07 anarsoul: no idea, I never used evas Sep 13 07:51:08 * anarsoul wants to build x11-image with matchbox wm, but it pulls efl stuff :\ Sep 13 07:51:25 * eFfeM_work works on real embedded stuff Sep 13 07:51:28 khem added this dependency for some reason to startup-notification Sep 13 08:33:31 03Roger Monk  07org.openembedded.dev * r05058b715b 10openembedded.git/recipes/ti/ (ti-cgt6x_6.1.15.bb ti-cgt6x_6.1.16.bb ti-cgt6x_6.1.17.bb): Sep 13 08:33:31 ti-cgt6x: Add latest c6000 code generation tools versions (6.1.15/16/17) Sep 13 08:33:31 Signed-off-by: Roger Monk Sep 13 08:33:31 Signed-off-by: Koen Kooi Sep 13 08:33:52 03Brijesh Singh  07org.openembedded.dev * rfd464d61d5 10openembedded.git/recipes/ti/ti-xdais_6.26.00.02.bb: Sep 13 08:33:52 ti-xdais_6.26.00.02: add new xdais version. Sep 13 08:33:52 ti-xdais_6.26.00.02: add new xdais version. Sep 13 08:33:52 Signed-off-by: Brijesh Singh Sep 13 08:33:53 Signed-off-by: Denys Dmytriyenko Sep 13 08:33:53 Signed-off-by: Koen Kooi Sep 13 08:33:54 Signed-off-by: Roger Monk Sep 13 08:34:04 03Koen Kooi  07org.openembedded.dev * ra41ec19ad5 10openembedded.git/recipes/ti/ti-staging.inc: ti recipes: remove -sourcetree support Sep 13 08:34:13 03Roger Monk  07org.openembedded.dev * rca13f60f7d 10openembedded.git/recipes/ti/ (ti-xdctools_3.20.02.59.bb ti-xdctools_3.20.03.63.bb): Sep 13 08:34:13 ti-xdctools: Add Latest Versions 3.20.02/03 Sep 13 08:34:13 Signed-off-by: Roger Monk Sep 13 08:34:13 Signed-off-by: Koen Kooi Sep 13 08:34:43 03Roger Monk  07org.openembedded.dev * rf759133f9f 10openembedded.git/recipes/ti/ (ti-dspbios_5.41.06.21.bb ti-dspbios_5.41.07.24.bb): Sep 13 08:34:43 ti-dspbios: Add Latest versions 5.41.06/07 Sep 13 08:34:43 Signed-off-by: Roger Monk Sep 13 08:34:43 Signed-off-by: Koen Kooi Sep 13 08:34:44 03Roger Monk  07org.openembedded.dev * r5991c28678 10openembedded.git/recipes/ti/ti-codec-engine.inc: Sep 13 08:34:48 ti-codec-engine: Add space at end of SRC_URI to enable SRC_URI_append Sep 13 08:34:49 Signed-off-by: Roger Monk Sep 13 08:34:49 Signed-off-by: Koen Kooi Sep 13 08:34:49 03Brijesh Singh  07org.openembedded.dev * r6333a49f32 10openembedded.git/recipes/ti/ti-linuxutils_2.25.05.11.bb: Sep 13 08:34:49 ti-linuxutils_2.25.05.11: add new linux utils recipe Sep 13 08:34:49 ti-linuxutils_2.25.05.11: add new linux utils recipe Sep 13 08:34:50 Signed-off-by: Brijesh Singh Sep 13 08:34:50 Signed-off-by: Denys Dmytriyenko Sep 13 08:34:51 Signed-off-by: Koen Kooi Sep 13 08:34:51 Signed-off-by: Roger Monk Sep 13 08:34:52 03Roger Monk  07org.openembedded.dev * rf1c72066dc 10openembedded.git/recipes/ti/ (ti-cgt6x_7.0.1.bb ti-cgt6x_7.0.2.bb ti-cgt6x_7.0.3.bb): Sep 13 08:34:52 ti-cgt6x: Prepare for ELF/C6000 EABI - Add cgt v7 versions (7.0.1/2/3) Sep 13 08:34:53 Signed-off-by: Roger Monk Sep 13 08:34:54 Signed-off-by: Koen Kooi Sep 13 08:37:48 03Brijesh Singh  07org.openembedded.dev * r0dffc98ff4 10openembedded.git/recipes/ti/ti-framework-components_2.25.03.07.bb: Sep 13 08:37:49 ti-framework-components_2.25.03.07: add new framework components recipe Sep 13 08:37:49 ti-framework-components_2.25.03.07: add new framework components recipe Sep 13 08:37:49 Signed-off-by: Brijesh Singh Sep 13 08:37:49 Signed-off-by: Denys Dmytriyenko Sep 13 08:37:49 Signed-off-by: Roger Monk Sep 13 08:37:50 Signed-off-by: Koen Kooi Sep 13 09:00:05 mickey|office: good morning Sep 13 09:02:58 mornin' pb_ Sep 13 09:05:46 pb_: I'm needing some light about packaging of a *libc (specifically klibc) Sep 13 09:07:45 I'm unsure about the split of dev-package: shared lib / headers Sep 13 09:09:41 more in details, we mostly use the static klibc-utils so no need of shared libs, actually what we depends on is 'klibc-dev', intended as headers Sep 13 09:10:02 and from the same source an external klcc-cross Sep 13 09:11:18 the question is: in this case, should a third package depend on *libc-dev or finally just on *libc? Sep 13 09:12:22 by "depend", do you mean DEPENDS or Depends:? Sep 13 09:12:37 DEPENDS on buildtime Sep 13 09:12:44 probably *libc-dev then Sep 13 09:13:18 hm.. so theklibc recipe should PROVIDE both klibc and klibc-dev? Sep 13 09:14:19 oh, they come from the same recipe? in that case, you don't need a klibc-dev at all in that namespace, you can just DEPEND on klibc. Sep 13 09:14:36 he.. the packaging is 'custom' Sep 13 09:14:55 I suppose it could even be bogus :/ Sep 13 09:15:17 PACKAGES = "${PN}-dev ${PN}" Sep 13 09:15:27 ${PN}-dev was introduced to fix Sep 13 09:15:34 ERROR: QA Issue with klibc: non -dev package contains symlink .so: klibc Sep 13 09:15:42 '/klibc/lib/klibc.so' Sep 13 09:16:06 I somehow smell something is wrong... Sep 13 09:17:11 does the QA apply in the case of a *libc.so ? Sep 13 09:17:35 That PACKAGES is fine. Sep 13 09:18:07 It only applies to the output package side of things, though. This is a different world to that in which DEPENDS operates. Sep 13 09:18:19 FILES_${PN}-dev = "${base_libdir}/klibc.so" Sep 13 09:18:28 ^^ this is not enough to build against Sep 13 09:19:16 I'm a bit confused about what your issue is. Are you talking about on-target builds, or builds inside the OE tree (i.e. from sysroot)? Sep 13 09:19:53 I created a klibc.bbclass for the target recipes built statically against klibc Sep 13 09:20:29 this class adds DEPENDS =+ "klcc-cross" Sep 13 09:20:41 (of course you need the crosscompiler) Sep 13 09:21:03 now, should klcc-cross DEPEND on klibc or klibc-dev? Sep 13 09:21:19 as it is, it DEPENDS on klibc Sep 13 09:21:40 That's fine. If klibc and klibc-dev are going to be provided by the same recipe then it doesn't matter which one you DEPEND on. Sep 13 09:22:31 so it is fine to package the headers in the main package and not in the -dev? Sep 13 09:23:18 I'm tempted to 'swap' FILES_${PN} and FILES_${PN}-dev Sep 13 09:23:19 No, but that is irrelevant if you are talking about DEPENDS. Sep 13 09:23:25 DEPENDS operates on recipes, not on output packages. Sep 13 09:23:36 oh, right Sep 13 09:24:04 Did you mean RDEPENDS? Sep 13 09:24:10 he runtime is different Sep 13 09:24:22 If so then klcc-cross should RDEPEND on klibc-dev, and klibc-dev in turn should RDEPEND on klibc. Sep 13 09:24:28 (The latter should be automatic.) Sep 13 09:24:50 good morning pb_ Sep 13 09:24:53 seems a bit more elegant, isn't ? Sep 13 09:25:36 pb_: btw klcc-cross and klibc come from the same source Sep 13 09:27:25 it seems impossible to correctly package all in one recipe, 'cause klcc goes in ${TOOLCHAIN_PATH}/bin/${TARGET_PREFIX}klcc Sep 13 09:33:38 anyway, I'll try to play with FILES_${PN} and FILES_${PN}-dev and see if RDEPENDS_${PN} works Sep 13 09:33:45 pb_: thx Sep 13 09:34:14 ok, cool. I'm afraid I still don't quite understand what your actual issue is, so it is hard for me to say anything more useful about it. Sep 13 09:34:43 I don't know what FILES_${PN} is expected to contain... Sep 13 09:34:52 klibc.so ? Sep 13 09:35:08 the shared object Sep 13 09:35:17 that might be klibc.so itself, or it might be klibc.so.1 or some such Sep 13 09:35:28 that triggers the QA Sep 13 09:35:55 non -dev package contains symlink .so Sep 13 09:36:08 is klibc.so actually a symlink? Sep 13 09:36:14 if so then it is not the shared object Sep 13 09:36:34 hmm there is a longhash... Sep 13 09:37:09 (cd ${D}${base_libdir}; ln -s klibc-*.so klibc.so) Sep 13 09:37:41 okay, so that klibc-*.so is probably the shared object. Sep 13 09:37:48 (you can check with "file" to ensure that it really is.) Sep 13 09:40:26 the fact is, we basically never need that shared lib, being we need headers+crosscompiler-wrapper Sep 13 09:40:50 to build statically against klibc Sep 13 09:41:19 but I see, this is the 'main' package in caxse of a élibc Sep 13 09:41:37 err..but I see, this is the 'main' package in case of a *libc Sep 13 09:42:52 hi, I've seen a branch named "master" has now been created, is it tracking org.openembedded.dev ? Sep 13 09:45:02 pb_: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/klibc/klibc_1.5.20.bb Sep 13 09:45:20 I see now... FILES_${PN}-dev = "${base_libdir}/klibc.so" \ FILES_${PN} = "${base_libdir}/klibc-*.so \ Sep 13 09:45:46 empty symlink in packahe... Sep 13 09:45:59 that's the reason of the QA Sep 13 09:49:35 pb_: I finally could spot the error, thx again! Sep 13 09:50:23 the fact I used DEPENDS somehow did hide the packaging mistakes Sep 13 10:39:39 03Koen Kooi  07org.openembedded.dev * r84bfaa0536 10openembedded.git/recipes/gcc/ (22 files): (log message trimmed) Sep 13 10:39:39 gcc-package-cross.inc: install shlibs lists into target dir instead of host dir Sep 13 10:39:39 This fixes the "libstdc++ isn't installed into my rootfs anymore" type of problems after a full rebuild of all packages Sep 13 10:39:39 This bumps PR of gcc to force a rebuild, but that is *NOT* enough to fix the packages built before this fix, those still need rebuilding Sep 13 10:39:39 Acked-by: Khem Raj Sep 13 10:39:39 Acked-by: Dallas Foley Sep 13 10:39:40 Acked-by: Graeme Gregory Sep 13 10:39:51 03Koen Kooi  07org.openembedded.dev * re316623268 10openembedded.git/contrib/angstrom/sort.sh: angstrom feed sorter: add mini6410 Sep 13 11:15:44 03Eric Bénard  07org.openembedded.dev * rcf6bd7557d 10openembedded.git/recipes/util-linux-ng/util-linux-ng.inc: (log message trimmed) Sep 13 11:15:44 util-linux-ng: fix broken symlinks Sep 13 11:15:44 * # opkg files util-linux-ng | grep 'halt\|boot' | xargs file Sep 13 11:15:44 /usr/sbin/fastboot: broken symbolic link to `/usr/sbin/shutdown' Sep 13 11:15:44 /usr/sbin/halt: broken symbolic link to `shutdown' Sep 13 11:15:45 /usr/sbin/halt.util-linux-ng: broken symbolic link to `/usr/sbin/shutdown' Sep 13 11:15:45 /usr/sbin/fasthalt: broken symbolic link to `/usr/sbin/shutdown' Sep 13 11:15:53 03Eric Bénard  07org.openembedded.dev * r506634928d 10openembedded.git/recipes/util-linux-ng/util-linux-ng.inc: Sep 13 11:15:53 util-linux-ng: fix reset update-alternative vs busybox Sep 13 11:15:53 * we actually get the following log : Sep 13 11:15:53 update-alternatives: Error: cannot register alternative reset Sep 13 11:15:53 to /bin/reset since it is already registered to /usr/bin/reset Sep 13 11:15:54 * the fix is to have util-linux-ng install reset in /usr/bin Sep 13 11:15:55 Signed-off-by: Eric Bénard Sep 13 11:15:55 03Eric Bénard  07org.openembedded.dev * r79e96b708c 10openembedded.git/recipes/util-linux-ng/util-linux-ng.inc: (log message trimmed) Sep 13 11:15:56 util-linux-ng: add missing `update-alternatives --remove' in pkg_prerm Sep 13 11:15:56 * util-linux-ng installs alternative of hexdump, setsid and chrt in postinst, but Sep 13 11:15:57 doesn't remove them in prerm leading to broken simlinks Sep 13 11:15:57 * this patch closes bug 5476 Sep 13 11:15:58 http://bugs.openembedded.org/show_bug.cgi?id=5476 Sep 13 11:15:58 From: Korey Lu Sep 13 11:15:59 03Eric Bénard  07org.openembedded.dev * r1a2438b9c6 10openembedded.git/recipes/util-linux-ng/util-linux-ng.inc: Sep 13 11:15:59 util-linux-ng: increase PR Sep 13 11:49:50 er what's the best way to make a git server for my own use? Sep 13 11:50:04 ericben: is your virtual/egl patch supposed to fix this: Sep 13 11:50:24 ERROR: '['/home/hudson/jobs/FM_world/workspace/openembedded/recipes/moblin/nbtk_git.bb']' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'nbtk' but it wasn't found in any PACKAGE or RPROVIDES variables of any buildable targets. Sep 13 11:50:37 still gets lots of these Sep 13 11:51:43 Crofton http://tumblr.intranation.com/post/766290565/how-set-up-your-own-private-git-server-linux Sep 13 11:52:31 Crofton: gitosis, gitolite (newer) Sep 13 11:52:38 zecke, thanks Sep 13 11:52:57 zecke, do you have a template for a GA announcement? Sep 13 11:53:24 Crofton: I am afraid I don't. IIRC i stole it somewhere, let me check there Sep 13 11:53:33 ok Sep 13 11:53:50 also, email to the members is ok? Sep 13 11:56:04 Crofton: well, I didn't have a template for that one. :} Sep 13 11:56:10 eFfeM_work: is this log message related to egl ? Sep 13 11:56:27 I'll hack up the one you did for the extraordinary one Sep 13 11:56:51 ericben, i think i lost the message about no provider for virtual/egl, but let me check Sep 13 11:57:54 ericben: guess it is, I still *do* get the virtual/egl msg too Sep 13 11:57:55 ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'clutter' but it wasn't found in any PACKAGE or RPROVIDES variables ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'virtual/egl' but it wasn't found in any PACKAGE or RPROVIDES variables Sep 13 11:58:09 hm, linebreak didn't paste Sep 13 11:58:15 and i thought i was at git head Sep 13 11:58:18 for nbtk ? Sep 13 11:58:51 well this output came from bitbake world Sep 13 11:59:42 i have an egl.inc file with CM set to ompa3 Sep 13 12:00:18 omap3 Sep 13 12:00:24 all packages who had virtual/egl as DEPENDS should now have require egl.inc Sep 13 12:02:13 it may be powervr-drivers/omap3-sgx-modules*.bb Sep 13 12:02:22 no sorry Sep 13 12:03:19 Can't you find in the log which package triggers this log ? Sep 13 12:03:56 will try Sep 13 12:05:26 which target are you building for ? Sep 13 12:05:42 calamari (this is a powerpc), distro minimal Sep 13 12:06:08 could you try to see what it gives for you ? Sep 13 12:06:49 Do you get this at the start of bitbake or latter during the build ? Sep 13 12:07:06 at the start (before task 1) Sep 13 12:07:25 OK I've a bitbake -k world running for an armv5 and I don't get this Sep 13 12:07:37 hm, git head? Sep 13 12:07:43 which bb version? Sep 13 12:07:46 bitbake git head + OE git head Sep 13 12:07:53 the only log for egl are : Sep 13 12:07:55 NOTE: Runtime target 'virtual/egl' is unbuildable, removing... Sep 13 12:07:55 Missing or unbuildable dependency chain was: ['virtual/egl'] Sep 13 12:08:01 ok, i used the official 1.10 version Sep 13 12:08:02 ERROR: Nothing PROVIDES 'clutter' Sep 13 12:08:02 ERROR: Nothing PROVIDES 'virtual/egl' Sep 13 12:08:08 ERROR: Nothing RPROVIDES 'virtual/egl' Sep 13 12:08:25 and that's all Sep 13 12:08:34 distro minimal ? Sep 13 12:08:40 distro : angstrom Sep 13 12:09:18 hm, will try that Sep 13 12:10:38 starting an angstrom build, will tell the outcome in a few minutes Sep 13 12:12:22 ericben: with those errors bitbake still properly reports success/failure? saw it report success in hudson where I saw a fail Sep 13 12:13:30 I'm not running hudson on this machine Sep 13 12:13:43 Crofton: which version of fedora do you use? Sep 13 12:13:45 ah ok Sep 13 12:14:41 13 Sep 13 12:15:39 Crofton: and glibc-initial builds fine? Sep 13 12:15:47 yeah Sep 13 12:15:54 well, it did last week Sep 13 12:17:27 btw what's the purpose of the empty glibc-stage.inc? I was looking for examples for my klibc affairs and spotted that Sep 13 12:56:49 ericben: this is what I get with distro angstrom2008.1 machine calamari: http://pastie.org/1155669 Sep 13 12:58:56 Does anyone know the key word to append the -fno-strict-aliasing, when compiling for C++? Sep 13 12:58:57 I did try adding CFLAGS += "-fno-strict-aliasing" to my recipe, but the compiler does not seem to take the option. Sep 13 13:03:23 ah! got it, CXXFLAGS Sep 13 13:08:42 eFfeM_work: ok this seems to be fixed in head bitbake as I don't get it here (armv5 machine) Sep 13 13:09:18 ah ok Sep 13 13:09:21 can try that Sep 13 13:10:02 clutter has DEPENDS "virtual/libgl" Sep 13 13:10:44 but no libegl Sep 13 13:12:26 ok Sep 13 13:12:43 what machine were you building for ? Sep 13 13:12:45 but clutter.inc has compatible_machine set so it shouldn't build for you Sep 13 13:12:58 I4m buildingfor a armv5 machine which is in an overlay Sep 13 13:15:02 ok, will try to see what bb head gives me Sep 13 13:32:11 ericben: with bitbake head: same errors Sep 13 13:32:36 oh, see something, will retest Sep 13 13:44:07 hi ericben Sep 13 13:49:32 hi GNUtoo|laptop Sep 13 13:49:57 ericben, I'm back Sep 13 13:50:13 03Sebastian Krzyszkowiak  07org.openembedded.dev * r99c719e8ee 10openembedded.git/recipes/freesmartphone/cornucopia.inc: Sep 13 13:50:14 cornucopia: bump to get fsogsmd fix Sep 13 13:50:14 Signed-off-by: Klaus Kurzmann Sep 13 13:50:17 03Sebastian Krzyszkowiak  07org.openembedded.dev * rbd6758d4c2 10openembedded.git/recipes/shr/shr-splash-theme-logo_git.bb: Sep 13 13:50:17 shr-splash-theme-logo: support palmpre and htcdream machines Sep 13 13:50:17 Signed-off-by: Klaus Kurzmann Sep 13 13:50:59 you were not very lucky with weather last week, now we have a big sun ;-) Sep 13 13:51:12 ok Sep 13 13:51:42 did you start porting 2.6.36-rc on your i.MX ? Sep 13 13:52:36 ericben, not yet I didn't know where to start and had some quesitons: Sep 13 13:52:46 there is a board init Sep 13 13:52:56 if I have only serial is it ok? Sep 13 13:53:03 or do I need some other init things? Sep 13 13:55:03 GNUtoo|laptop: I can't check now but we can see this by thursday or friday Sep 13 13:55:32 ok Sep 13 13:55:33 thanks a lot Sep 13 14:00:35 ericben, bitbake head does not seem to help Sep 13 14:00:58 still lots of unbuildable dependency chains Sep 13 14:03:52 eFfeM_work: strange, here bitbake is at c07cc08f7fd503ac3013ccc43c79198c4c3b7b29 Sep 13 14:04:01 and OE at 0dffc98ff4538b890e48f91e33e1de1d037b67b7 Sep 13 14:04:50 i did a git pull of both, maybe this is because I am not using an arm target Sep 13 14:05:19 this should'nt make a difference I think Sep 13 14:08:49 trying some more things Sep 13 14:23:07 ericben well my bb version is the same as yours, oe is at 1a2438b9c6773eefe6732a651a4d28d41133ee42 which is your util-linux-ng increase PR patch Sep 13 15:07:37 03Koen Kooi  07org.openembedded.dev * r0bc18282c3 10openembedded.git/conf/distro/include/angstrom-2010-preferred-versions.inc: angstrom-next: switch to a newer busybox and cairo Sep 13 15:07:37 03Koen Kooi  07org.openembedded.dev * r1d4c650b1d 10openembedded.git/recipes/cairo/ (cairo.inc cairo_1.10.0.bb): cairo: add 1.10.0, latest stable release Sep 13 15:31:11 03Klaus Kurzmann  07org.openembedded.dev * rbfd4f01d2f 10openembedded.git/recipes/freesmartphone/libfreesmartphone-glib_git.bb: Sep 13 15:31:11 libfreesmartphone-glib: new recipe Sep 13 15:31:11 Signed-off-by: Klaus Kurzmann Sep 13 15:43:17 jo Sep 13 15:43:38 I am back Sep 13 15:43:55 woglinde: hey! Sep 13 15:43:59 eFfeM_work: Any reason you haven't nuked old versions in apr, before I take a stab at it? Sep 13 16:05:10 03Tom Rini  07org.openembedded.dev * rd0dece3a63 10openembedded.git/recipes/apr/ (apr-util_1.2.12.bb apr-util_1.3.4.bb): Sep 13 16:05:10 apr-util: Switch to getting libtool from PATH Sep 13 16:05:10 Signed-off-by: Tom Rini Sep 13 16:05:13 03Tom Rini  07org.openembedded.dev * rb25356083a 10openembedded.git/recipes/sg3-utils/sg3-utils_1.24.bb: Sep 13 16:05:13 sg3-utils: Switch to getting libtool from PATH Sep 13 16:05:13 Signed-off-by: Tom Rini Sep 13 16:05:26 03Tom Rini  07org.openembedded.dev * r6ce420a47b 10openembedded.git/recipes/jpeg/jpeg_6b.bb: Sep 13 16:05:27 jpeg 6b: Switch to getting libtool from PATH Sep 13 16:05:27 Signed-off-by: Tom Rini Sep 13 16:05:27 03Tom Rini  07org.openembedded.dev * r0e600292e2 10openembedded.git/recipes/apr/ (apr-1.3.5/cleanup.patch apr_1.3.5.bb): Sep 13 16:05:27 apr 1.3.5: Rework and re-apply the cleanup patch, so this builds. Sep 13 16:05:27 Signed-off-by: Tom Rini Sep 13 16:05:28 03Tom Rini  07org.openembedded.dev * rcadfaba4b5 10openembedded.git/recipes/xfsprogs/xfsdump_3.0.4.bb: Sep 13 16:05:28 xfsdump: Switch to getting libtool from PATH Sep 13 16:05:29 Signed-off-by: Tom Rini Sep 13 16:05:29 03Tom Rini  07org.openembedded.dev * r6ed4b0e2b6 10openembedded.git/recipes/ffmpeg/ (ffmpeg.inc ffmpeg_0.5.bb): Sep 13 16:05:48 ffmpeg: Pass along all of CCLDs flags, fix !Altivec PowerPC Sep 13 16:05:48 What's passed for --enable-ldflags is for ffmpeg using cc-as-ld but Sep 13 16:05:48 not just using CCLD, so pass in TOOLCHAIN_OPTIONS. For PowerPC, Sep 13 16:05:48 only pass --enable-altivec on ppce600 (only case of it we support) Sep 13 16:05:48 otherwise disable as ffmpeg defaults to enabled. Sep 13 16:05:49 Signed-off-by: Tom Rini Sep 13 16:05:49 03Tom Rini  07org.openembedded.dev * r62d29bd224 10openembedded.git/recipes/apr/apr_1.2.12.bb: Sep 13 16:05:50 apr 1.2.12: Switch to getting libtool from PATH Sep 13 16:05:50 Signed-off-by: Tom Rini Sep 13 16:05:51 03Tom Rini  07org.openembedded.dev * rf5d1842937 10openembedded.git/recipes/time/time.inc: Sep 13 16:05:51 time: Make /usr/bin/time use update-alternatives Sep 13 16:05:52 This is a little funny as we don't want u-a on the -native. Sep 13 16:05:54 Signed-off-by: Tom Rini Sep 13 16:05:54 03Tom Rini  07org.openembedded.dev * r5ef4b15299 10openembedded.git/recipes/xfsprogs/ (xfsprogs_2.8.16.bb xfsprogs_3.1.2.bb): Sep 13 16:05:55 xfsprogs: Switch to getting libtool from PATH Sep 13 16:05:55 Signed-off-by: Tom Rini Sep 13 16:05:56 03Tom Rini  07org.openembedded.dev * rf87759ae52 10openembedded.git/classes/packaged-staging.bbclass: Sep 13 16:05:56 packaged-staging: Fix libtool-cross staging Sep 13 16:05:57 libtool-cross must not inherit cross, so wasn't getting the right Sep 13 16:21:52 eFfeM: Any reason you haven't nuked old versions in apr, before I take a stab at it? Sep 13 16:27:15 Tartarus: no specific reason, I just started somewhere at random and at some point moved to recipes with many versions Sep 13 16:28:09 i never got to finishing the cleanup work, too much headwind :-) Sep 13 16:31:56 Tartarus: feel free to take action on it. I guess if I do it I will get neg feedback from someone. Actually I'm already used to it, but it is probably not the fastest way to make progress Sep 13 16:32:22 anyone who changes anything is subject to negative feedback, just about Sep 13 16:32:30 hi kergoth Sep 13 16:33:29 kergoth_: yeah but it is the only way to make progress Sep 13 16:34:04 anyone has positive or negative feedback concerning one of the 2 patches I proposed for reset in util-linux-ng ? ;-) Sep 13 16:36:41 ericben: i have a slight preference for depending on tools Sep 13 16:37:19 but actaully i'd even prefer a version of util-linux-ng that does not need ncurses at all (or a subset) Sep 13 16:37:50 btw seems asterisk patch is ok, see ML Sep 13 16:39:16 ericben: don't see a reason to have a dup Sep 13 16:41:27 oops, power fail due to user error :-( Sep 13 16:41:50 gm all Sep 13 16:41:54 hi khem Sep 13 16:41:58 good evening Sep 13 16:42:01 btw. Sep 13 16:42:03 *g* Sep 13 16:42:16 hi khem, all Sep 13 16:42:17 woglinde: hey you were off for a while vacationing ? Sep 13 16:42:35 khem thesis Sep 13 16:42:43 I reached in today Sep 13 16:44:44 i see all done now Sep 13 16:44:51 eFfeM: hello Sep 13 16:45:32 khem no 3 oral exam are left Sep 13 16:45:37 but then Sep 13 16:47:07 woglinde: gratz on completing the thesis and gl with the exams Sep 13 16:47:17 I see, I appeared for oral exams for my german class grundstufe II :) Sep 13 16:47:51 eFfeM: w.r.t bitbake world I am at same number as you Sep 13 16:47:56 approx Sep 13 16:48:03 but now there are real problems to fix Sep 13 16:50:38 khem, apparently that python module is arm only Sep 13 16:50:49 but i saw on #beagle that koen also had issues with it Sep 13 16:51:05 what I find weird is that it exits even if I do -k Sep 13 16:51:29 and even with ericben's patch I get warnings Sep 13 16:52:14 * [new branch] master -> origin/master Sep 13 16:52:17 hmmm Sep 13 16:52:28 btw there is no new testing branch yet, is it? Sep 13 16:52:37 no Sep 13 16:52:52 whats this master branch ? Sep 13 16:52:57 khem that was a rename that has been discussed before (at least i suspect it is, didn't see the patch yet Sep 13 16:53:09 if thats the one thats ok Sep 13 16:53:16 are you sure Sep 13 16:53:21 there was a discusson to rename our master branch from openembedded to master, guess that is the one Sep 13 16:53:44 I know Sep 13 16:53:57 was there a mail regarding this switch over the weekend Sep 13 16:54:23 not that i am aware of Sep 13 16:54:36 let me see who pushed it Sep 13 16:54:45 and actually switching over like this will cause a mess as some people will use one branch and others will use another Sep 13 16:55:03 can you see that? Sep 13 16:55:27 actually we should try to address all owners of old branches to find out if they are still useful Sep 13 16:55:48 as people cannot delete them themselves they tend to accumulate Sep 13 16:56:28 http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=f5d1842937314b643671ffc9215194d40699741d Sep 13 16:56:31 Tartarus: ? Sep 13 16:56:32 eFfeM: see email: "branch namespace clutter" Sep 13 16:57:20 I wonder if it makes more sense to put user branchs in another repo to keep the master from getting cluttered? Sep 13 16:57:45 khem? Sep 13 16:57:56 there is master branch Sep 13 16:58:01 you pushed to it last Sep 13 16:58:14 someone did something on the backend? Sep 13 16:58:16 is it oficially the master Sep 13 16:58:27 To git@git.openembedded.net:openembedded Sep 13 16:58:27 bfd4f01..f5d1842 org.openembedded.dev -> org.openembedded.dev Sep 13 16:58:28 hmm ok Sep 13 16:59:00 cbrake: has the renaming to master been done Sep 13 16:59:28 cbrake: I'd love something like kernel.org's setup, but I know that's not 0 effort Sep 13 16:59:35 cbrake: i know about the namespace clutter mail, but I fear the people that should be addressed by it are gone Sep 13 16:59:36 And I forget what the objection was to using github or whatever Sep 13 17:00:32 eFfeM: So, removal is posting to the ML and getting 2 more acks or what? I forget Sep 13 17:00:45 * Tartarus usually is just lazy and does things after testing Sep 13 17:01:10 Tartarus: removal of recipes ? Sep 13 17:01:15 old ones, yes Sep 13 17:01:22 yes better to send to ml Sep 13 17:01:23 apr 1.2.12 and apr-utils 1.2.12 don't even patch Sep 13 17:01:32 er, 1.2.7 on the util Sep 13 17:01:36 and make sure that its not pinned by any distro Sep 13 17:02:03 and also let people object to patch on ml Sep 13 17:02:12 for couple of days may be Sep 13 17:02:59 cbrake: there are 3 branches that have had their 4th year anniversary (or are about to have) Sep 13 17:04:07 Tartarus: wrt removal: depends on what you want to remove, if you are the maintainer of the recipe and the version is not pinned nor the last one, I feel it is within the maintainer powers to remove it Sep 13 17:04:53 if it is orphaned it is somewhat in limbo how to do, if it is core posting and acks are needed Sep 13 17:05:08 but e.g. if I move to a later version of a recipe I typically use git mv Sep 13 17:05:33 k, thanks Sep 13 17:06:09 eFfeM: sometime git assumes the moves too I have seen even if youd did cp rm and git add Sep 13 17:07:48 hmm Sep 13 17:07:59 Will git pull delete branches that have been nuked upstream? Sep 13 17:08:07 ah ok, git mv has the advantage that it preserves history over time Sep 13 17:08:20 Tartarus: no idea, suggest to consult #git Sep 13 17:08:26 or make a backup forst Sep 13 17:08:38 Tartarus, pretty sure you have to use git remote prune to drop the remote tracking branches for removed upstream branches Sep 13 17:08:47 of course that won't touch local branches that track the tracking branches :) Sep 13 17:08:53 at least, that's my understanding Sep 13 17:09:44 khem: I have never heard of renaming to master being done Sep 13 17:10:00 kergoth_: ah, thanks Sep 13 17:10:05 master will be renamed in a way that doesn't break anything Sep 13 17:10:06 * Tartarus does git remote prune origin Sep 13 17:10:16 for the time being it'll be a symbolic reference pointing at org.openembedded.dev Sep 13 17:11:04 kergoth_: ok Sep 13 17:11:11 kergoth_: so if I reclone Sep 13 17:11:16 will I get master Sep 13 17:11:20 that i'm not sure of Sep 13 17:11:23 as my master Sep 13 17:11:27 i think we might ahve to change the HEAD ref on the bare repo to change that Sep 13 17:11:32 separate step Sep 13 17:11:44 probably a good idea though, to start the transition Sep 13 17:11:48 yes Sep 13 17:12:02 I think best is that whoever clones he gets master/master Sep 13 17:12:08 i *think* the HEAD ref in the bare repo controls the default branch you get when you clone Sep 13 17:12:15 HEAD is just another symbolic ref Sep 13 17:12:21 * Tartarus adds to GitPhrasebook Sep 13 17:12:56 Tartarus, i have an alias that can be useful on occasion.. where is it.. Sep 13 17:12:59 kergoth_: let me try to clone for test Sep 13 17:13:10 {2010.2 system-builder} % cat ~/.gitconfig|grep prune Sep 13 17:13:10 61: # prune all tracking local branches that have been removed from remote: Sep 13 17:13:10 62: prune-all = !git remote | xargs -n 1 git remote prune Sep 13 17:14:06 meh Sep 13 17:14:27 helpful for using multiple remotes, yeah Sep 13 17:14:38 kergoth_: I do git remote prune origin Sep 13 17:14:41 'git remote update' is also useful for that Sep 13 17:14:49 it does a fetch on each of the remotes in one command Sep 13 17:17:35 kergoth_: I cloned fresh and HEAD points to master :) Sep 13 17:17:52 nice Sep 13 17:18:03 did zecke set up the symbolic ref recently then? Sep 13 17:18:07 * kergoth_ didn't realize it had been done Sep 13 17:18:11 or are you testing it lcoally? Sep 13 17:18:16 blah, can't type today Sep 13 17:18:17 it's been done, yes Sep 13 17:18:18 $ git branch Sep 13 17:18:18 * master Sep 13 17:18:29 hehe Sep 13 17:19:01 hmm. that creates an issue as the wiki is not updated yet Sep 13 17:19:48 kergoth_: I cloned the repo so anyone who clones are repo will get master as the default HEAD Sep 13 17:20:46 cool Sep 13 17:22:18 ah Sep 13 17:34:58 03Koen Kooi  07org.openembedded.dev * rd888b42cc4 10openembedded.git/recipes/gcc/gcc-package-target.inc: Sep 13 17:34:58 Revert "gcc: trade QA errors for broken runtime dependencies" Sep 13 17:34:58 This isn't needed anymore now the proper fix is in Sep 13 17:34:58 This reverts commit 241b8865f20b9e3c3beb334535e6cd8452cbf47d. Sep 13 17:40:15 03Andrea Adami  07org.openembedded.dev * reda06ec3dd 10openembedded.git/recipes/klibc/ (klibc.inc klibc_1.5.20.bb): Sep 13 17:40:15 klibc: fix packaging mismatch Sep 13 17:40:15 * introduced by mistake extending list of packaged files Sep 13 17:40:15 * (copy and paste is for the lazy...) Sep 13 17:40:15 * bump PR Sep 13 17:45:44 hm, another koen toolchain revert without PR bump, without any ack and without any review :-( Sep 13 18:04:00 bitbake head does not seem to take MACHINE from the env although MACHINE is in BB_ENV_EXTRAWHITE. this used to work; anyone an idea what is wrong or how to set MACHINE in env instead of in local.conf ? Sep 13 18:17:40 cbrake, ping Sep 13 18:18:36 cd '/otheros/wine/Programme/Rockstar Games/Grand Theft Auto San Andreas' Sep 13 18:18:40 ups Sep 13 18:18:54 woglinde, get back to work! Sep 13 18:28:37 Crofton|work: hello Sep 13 18:29:52 03Simon Busch  07org.openembedded.dev * r73f03f4d57 10openembedded.git/recipes/freesmartphone/fsogsmd_git.bb: Sep 13 18:29:52 fsogsmd: fix dependency chain for palmpre machine Sep 13 18:29:52 Through the last commit for fsogsmd the dependency chain for fsogsmd was broken. Sep 13 18:29:52 libgsm0710mux was never compiled as dependency as it was overwritten by the other Sep 13 18:29:52 dependencies necessary for the palmpre machine. Sep 13 18:29:53 Signed-off-by: Simon Busch Sep 13 18:30:30 cbrake, can you talk with Steffen aobut moving the website? Sep 13 18:30:44 eFfeM: export BB_ENV_EXTRAWHITE="MACHINE DISTRO" Sep 13 18:30:56 in your env Sep 13 18:31:27 then it should be able to see MACHINE and DISTRO e.g. Sep 13 18:33:12 Crofton: yes, is the wiki the last thing we have to move? Sep 13 18:33:19 I think so Sep 13 18:33:27 sounds like he is willing and has knowledge Sep 13 18:34:36 khem, in the env? or in the conf file Sep 13 18:34:46 i used to do taht in the .conf file Sep 13 18:35:50 and that works for 1.10 but not for bb git head Sep 13 18:37:31 hm testing branch Sep 13 18:40:12 cbrake, Crofton there are some issues with later Mediawiki's and libPHP so let me get those setup first. Sep 13 18:40:22 ok Sep 13 18:40:35 check with Steffen, he has been offering to help on the list Sep 13 18:40:51 saw taht. Sep 13 18:40:54 k Sep 13 18:40:54 okay Sep 13 18:41:12 03Koen Kooi  07org.openembedded.dev * r8662dc3a3f 10openembedded.git/conf/distro/include/angstrom-2010-preferred-versions.inc: angstrom-next: switch to perl 5.10.1 Sep 13 18:41:41 hi ka6sox Sep 13 18:41:49 hiya woglinde Sep 13 18:42:14 bbiaf..headed into office. Sep 13 19:22:54 hi woglinde Sep 13 19:23:11 woglinde, I've some devices with 800x480 screens Sep 13 19:23:24 that means that wesnoth can run without tynyGUI Sep 13 19:23:30 *tinyGUI Sep 13 19:23:32 hehe Sep 13 19:23:59 I shipped all the previous wesnoth with tinyGUI Sep 13 19:24:02 what should I do? Sep 13 19:24:11 because doing like supertux...hmmm Sep 13 19:24:15 that would break upgrades Sep 13 19:24:36 making 2 recipes? Sep 13 19:24:36 or should I do a wesnoth-bigscreen? Sep 13 19:24:46 one for big one for low? Sep 13 19:24:54 ah that would break upgrades Sep 13 19:25:00 I keep the one for low as wesnoth Sep 13 19:25:08 and put the one for big as bigscreen? Sep 13 19:30:53 basically I was unsure if -bigscreen was allowed Sep 13 19:31:00 I only saw -qvga Sep 13 19:31:01 or similar Sep 13 19:33:22 khem: I pushed a new efika mx kernel out that's based on 2.6.31.14 git of Genesi Sep 13 19:33:52 khem: based on the comments of Matt on the powdev website forum. Sep 13 19:34:29 khem: btw, did you test your kernel on your board yet? Sep 13 19:37:08 woglinde_, supertux-qvga doesn't conflicts with supertux...strange Sep 13 19:57:50 dear OE users! I have some little problem trying to build newest kernel with OE. It says "| arm-angstrom-linux-gnueabi-ld: no machine record defined| make: *** [.tmp_vmlinux1] Error 1 ". Can anybody point me right direction in this little question? Sep 13 20:01:05 dv__: what machine are you targetting ? Sep 13 20:01:34 AT91SAM9M10G45EK Sep 13 20:02:50 usually this means you don't have a platform selected in your kernel's config Sep 13 20:03:35 are you sure of your defconfig ? Sep 13 20:04:15 yes, I don't have sam9m10g45ek_default in my arch/arm/configs/ directory, but I have CONFIG_MACH_AT91SAM9M10G45EK=y in my .config Sep 13 20:04:40 are you building the kernel wih OpenEmbedded ? Sep 13 20:05:33 yes Sep 13 20:06:17 I modifyed the recipes, I replaced linux-2.6.30 with linux-2.6.34.5 Sep 13 20:06:23 so you created the board support and put your defconfig at the right place ? Sep 13 20:06:46 all seems to be fine except this message about "no machine record defined" Sep 13 20:07:12 yes. I see this defconfig as .config in linux source directory Sep 13 20:07:26 after the configure step Sep 13 20:08:09 then when it's building it build all binaries OK, except this one - .tmp_vmlinux1 Sep 13 20:09:02 I don't see any MACH_AT91SAM9M10G45EK in 2.6.34.5 Sep 13 20:10:33 [root@dvpc linux-2.6.35.4-r1]# grep -r "CONFIG_MACH_AT91SAM9M10" ./* Sep 13 20:10:34 ./defconfig:CONFIG_MACH_AT91SAM9M10G45EK=y Sep 13 20:10:35 ./linux-2.6.35.4/include/generated/mach-types.h:#ifdef CONFIG_MACH_AT91SAM9M10G45EK Sep 13 20:10:37 ./linux-2.6.35.4/include/generated/mach-types.h:#ifdef CONFIG_MACH_AT91SAM9M10EKES Sep 13 20:10:55 it's not enogth? Sep 13 20:10:57 no Sep 13 20:11:40 hmm...thank you Sep 13 20:11:46 you need to have the platform in arch/arm/mach-at91 and to have the came mahcine number in the structure MACHINE_START(XYZ Sep 13 20:11:59 khem: hi, are you here? Sep 13 20:12:08 then your cCONFIG_MACHIN in Kconfig and in Makefile to build your platform 's c file Sep 13 20:12:13 and then this may work :) Sep 13 20:12:45 but that's not a OE related problem as even out of OE you will meet the same problem Sep 13 20:13:04 thank you, ericben!!! Sep 13 20:13:29 anarsoul: yes I am now Sep 13 20:14:01 likewise: yes, I have booted efikamx with the kernel I put into OE Sep 13 20:14:19 only thing I did not try is u-boot Sep 13 20:14:22 khem: why did you add evas dependency to startup-notification? Sep 13 20:14:26 as I did not want to brick it Sep 13 20:14:28 :) Sep 13 20:14:43 anarsoul: it would not build without it Sep 13 20:14:52 khem: it builds Sep 13 20:14:56 khemm: can't you boot it on SDCard or USB ? the i.MX51 can do this if you have access to the bootmode jumpers Sep 13 20:15:14 ericben: you mean even u-boot Sep 13 20:15:32 khem: I removed evas and build it with no problem Sep 13 20:15:39 anarsoul: lemme see Sep 13 20:15:52 on gentoo it doesn't pull evas Sep 13 20:15:54 khem: yes, you can have one uboot on nand, one on sdcard and one on a SPI flash if you want + recover the board through Usb or serial using the ATK froom FSL (which runs under windows) Sep 13 20:16:13 ericben: oh nice Sep 13 20:16:29 the only thing is to have access to the few jumpers which configure these bootmodes Sep 13 20:16:40 ericben: I am more than happy in what I have I am more interested to get the system up with OE Sep 13 20:16:41 khem: thing is matchbox pulls startup-notification, and now it pulls efl Sep 13 20:16:53 and use it for some gcc hacking and uclibc thumb2 stuff Sep 13 20:17:00 anarsoul: I see that Sep 13 20:17:11 SRC_URI = "${SOURCEFORGE_MIRROR}/wesnoth/${BPN}-${PV}.tar.bz2" gives strange results Sep 13 20:17:23 NOTE: Task failed: Unknown fetch Error: [Errno 2] No such file or directory: '/home/gnutoo/embedded/oe/sources/wesnoth-wvga-1.8.4.tar.bz2' Sep 13 20:17:33 that was in wesnoth.inc not yet commited Sep 13 20:19:15 is BPN broken or am I wrong somewhere Sep 13 20:19:32 khem: so, will you remove this dep? :) Sep 13 20:19:50 basically wesnoth.inc : SRC_URI = "${SOURCEFORGE_MIRROR}/wesnoth/${BPN}-${PV}.tar.bz2" and wesnoth-wvga: require wesnoth.inc Sep 13 20:19:52 anarsoul: Yes I will Sep 13 20:19:58 khem: thanks :) Sep 13 20:20:06 but I have to test it Sep 13 20:20:12 anarsoul: you can do that do Sep 13 20:20:21 anarsoul: are you on latest master Sep 13 20:20:26 yep Sep 13 20:20:29 ok Sep 13 20:20:35 then remove it from DEPENDS Sep 13 20:20:38 khem: as I said before Sep 13 20:20:43 I removed it from DEPENDS Sep 13 20:20:45 and then do bitbake world Sep 13 20:20:48 and it builds with no pb Sep 13 20:20:52 does it parse ? Sep 13 20:21:05 I did bitbake matchbox-wm matchbox-keyboard Sep 13 20:21:10 I'll change BPN to wesnoth then Sep 13 20:21:10 it may build because you already have some files that it needs Sep 13 20:21:12 it pulls startup-notification Sep 13 20:21:19 I have lost my notes why I added it Sep 13 20:21:28 but there definitely was a reason Sep 13 20:22:17 anarsoul: couple of things 1. Try bitbake world and see if it parses you dont have to build once it starts doing tasks you can kill it Sep 13 20:22:17 khem: I have no evas in host system, and didn't build it via oe Sep 13 20:22:31 2. do bitbake startup-nortification from scratch Sep 13 20:22:40 i.e kill your tmpdir Sep 13 20:22:53 anarsoul: thats fine. Sep 13 20:23:15 anarsoul: it was some .pc file IIRC that it needed and it was coming from evas Sep 13 20:23:36 its possible that if there is a evas alternatives they may provide it too Sep 13 20:23:44 or something like that Sep 13 20:23:44 khem: btw, just look to other distros Sep 13 20:23:47 or build systems Sep 13 20:24:04 gentoo doesn't pull efl for startup-notification Sep 13 20:24:18 neither does ubuntu Sep 13 20:24:27 I know Sep 13 20:24:41 but would you be able to do these two things I said ? Sep 13 20:25:10 because these are two steps I would do to revert it Sep 13 20:25:14 well, I can test if bitbake world parses Sep 13 20:25:30 but building startup-notification from scratch will take some time Sep 13 20:25:41 my machine is not very fast Sep 13 20:25:58 ok Sep 13 20:26:59 khem: it parses, but can't resolve dependencies: ERROR: Required build target 'gnome-packagekit' has no buildable providers. Sep 13 20:30:58 khem: it will take night or so to build startup-notification from scratch, are you sure you need it? :) Sep 13 20:31:29 I'm sure I have no efl libs on my pc Sep 13 20:31:31 at all Sep 13 20:31:34 even sources Sep 13 20:31:37 03Roman I Khimov  07org.openembedded.dev * raeff4da290 10openembedded.git/recipes/quagga/ (quagga_0.99.16.bb quagga_0.99.17.bb): Sep 13 20:31:37 quagga: update 0.99.16 to 0.99.17 Sep 13 20:31:37 * fixes two DoS attacks in BGP implementation Sep 13 20:31:37 * fixes other bugs Sep 13 20:31:37 * considered as sage upgrade Sep 13 20:31:37 Signed-off-by: Roman I Khimov Sep 13 20:31:47 03Roman I Khimov  07org.openembedded.dev * raaa9c089af 10openembedded.git/recipes/squid/ (3 files in 2 dirs): Sep 13 20:31:47 squid: update 3.1.7 to 3.1.8 Sep 13 20:31:47 * fixes SQUID-2010:3 DoS (http://www.squid-cache.org/Advisories/SQUID-2010_3.txt) Sep 13 20:31:47 * hardenes DNS client Sep 13 20:31:47 * fixes other bugs Sep 13 20:31:47 * considered as safe upgrade Sep 13 20:31:48 Signed-off-by: Roman I Khimov Sep 13 20:31:48 03Roman I Khimov  07org.openembedded.dev * r36f96bf1d6 10openembedded.git/recipes/openssl/ (2 files in 2 dirs): Sep 13 20:31:49 openssl 1.0.0a: fix CVE-2010-2939 Sep 13 20:31:49 0.9.8 is also affected, please try the same patch if using that. Sep 13 20:31:50 Signed-off-by: Roman I Khimov Sep 13 20:47:12 anarsoul: dont worry you are set locally I will test it and fix it in today or tomorrow Sep 13 20:47:46 ok Sep 13 20:47:49 khem: one more thing Sep 13 20:48:05 what about this patch: http://patchwork.openembedded.org/patch/2923/ Sep 13 20:48:06 ? Sep 13 20:48:06 :) Sep 13 20:49:25 anarsoul: looks good. I will line it up in my staged brancg Sep 13 20:49:27 branch Sep 13 20:49:34 if all it ok it will be in Sep 13 20:49:48 ok, thanks Sep 13 20:49:49 btw. you should have bumped the PR Sep 13 20:50:07 hm, I can resend it Sep 13 20:50:07 :) Sep 13 20:50:12 with bumped PR Sep 13 20:50:12 ok Sep 13 20:50:25 mark the new patch as [PATCH v2] Sep 13 20:50:33 so it can be seen separately Sep 13 20:50:43 khem: yeah, I'm pretty familiar with patch submitting :) Sep 13 20:51:03 (but to kernel ml-s, not to oe) Sep 13 20:51:53 yes our process is very much lkml like Sep 13 21:16:52 hey khem Sep 13 21:17:05 Tartarus: yep Sep 13 21:17:05 If I wanted to add a different qemu ppc board, what should I call it? Just the real machine name? Sep 13 21:17:24 qemu Sep 13 21:17:29 which one are you adding Sep 13 21:18:23 mpc8544ds Sep 13 21:18:28 Assuming qemu really support it Sep 13 21:20:38 Tartarus: it wont :) Sep 13 21:20:50 Tartarus: qemu for ppc only works well if your host is ppc Sep 13 21:21:12 Tartarus: the one I added is the one that worked across x86 hosts Sep 13 21:21:28 Tartarus: I tried freescale ones but they did not work Sep 13 21:21:56 all info I could get was that it needs ppc host to emulate on Sep 13 21:22:34 ah Sep 13 21:22:43 so that really is kvm related Sep 13 21:23:06 yep Sep 13 21:23:39 I am adding mips64 soon which works so so thus far Sep 13 21:23:47 but I think I am close Sep 13 21:24:19 NOTE: package grep-native-2.6.3-r2: task do_package_stage: Succeeded Sep 13 21:24:19 *** glibc detected *** /home/kraj/work/oe/tmp/sysroots/x86_64-linux/usr/mips64/mips64-oe-linux/bin/ld: free(): invalid next size (fast): 0x00000000085c7460 *** Sep 13 21:24:26 ka6sox-work: ping Sep 13 21:24:41 ka6sox-work: garnet is pissing on me Sep 13 21:25:19 um...okay.... Sep 13 21:25:23 dunno what that means Sep 13 21:25:36 heh Sep 13 21:25:54 glibc on that machine is dying Sep 13 21:25:59 on my linker Sep 13 21:26:40 http://pastebin.com/3rxaPsBT Sep 13 21:27:16 ka6sox-work: it could be a problem in linker too not sure Sep 13 21:27:33 but may be we could try to reboot this and see if I hit it again Sep 13 21:27:48 okay lets do that first Sep 13 21:27:54 cool Sep 13 21:28:05 ld and glibc are up to date Sep 13 21:28:12 ok Sep 13 21:28:21 its the cross ld that I am building Sep 13 21:28:29 as part of OE Sep 13 21:28:29 okay... Sep 13 21:28:34 okay got it. Sep 13 21:28:38 rebooting Sep 13 21:28:43 cross ld uses the native glibc Sep 13 21:29:07 k Sep 13 21:30:00 khem, its back up Sep 13 21:30:01 try again Sep 13 21:30:09 ok Sep 13 21:30:40 if it fixes the problem I will be happy Sep 13 21:30:55 otherwise debugging these corruptions are not fun Sep 13 21:32:04 hmmm Sep 13 21:32:10 seems this needs to be debugged Sep 13 21:35:56 good nite Sep 13 21:37:09 Tartarus: ping about missing inherit gettext Sep 13 21:38:03 shoot Sep 13 21:38:19 * khem looks for the gun Sep 13 21:38:23 I unfortunately did launch a build just before your commits Sep 13 21:38:29 the log is huge... Sep 13 21:38:39 let me grep it Sep 13 21:43:18 http://pastebin.ca/1940031 Sep 13 21:44:55 Tartarus, ah, and before... Sep 13 21:44:57 NOTE: package stagemanager-native-0.0.1-r13: task do_install: Succeeded Sep 13 21:44:58 cp: cannot stat `/oe/build/tmp/work/i686-linux/stagemanager-native-0.0.1-r13/sysroot-destdir//oe/build/tmp/*': No such file or directory Sep 13 21:44:58 NOTE: Running task 26 of 5186 (ID: 1077, /oe/openembedded/recipes/stage-manager/stagemanager-native_0.0.1.bb, do_populate_sysroot) Sep 13 21:45:46 iirc stagemanager-native was fixed not long ago Sep 13 21:46:02 A problem there was fixed, and I think sometimes that's harmless, not sure Sep 13 21:46:05 re gettext Sep 13 21:46:22 yeah, libgpg-error-native might ahve been me, fine with a quick fix :) Sep 13 21:47:58 I'll rebuild in a few hours, new patches are welcome :) Sep 13 21:48:21 heh Sep 13 21:48:27 none of my changes should change that stuff :) Sep 13 21:49:05 I was hoping there is a generic approach to fix those NOTE: Gettext required but not in DEPEND Sep 13 21:49:17 S Sep 13 21:49:50 well, the hammer :) Sep 13 21:50:04 anybody can help with this:http://pastebin.com/Q4WLkF39 ? Sep 13 21:52:39 Tartarus, heh, grepping about cp: cannot: http://pastebin.ca/1940044 Sep 13 21:52:53 ant_: either remove gettext from the configure, or add DEPENDS "gettext"? Sep 13 21:55:08 ant_: what machine and image target? Sep 13 21:55:10 well, why should kexec-tools depend on gettext? Sep 13 21:55:26 see Gentoo and debian Sep 13 21:55:55 are you saying with me ? Sep 13 21:59:08 likewise: I havent been able to devote time to SPE stuff. I was out camping past 3 days Sep 13 22:01:32 likewise, sorry, I misread the logs Sep 13 22:01:47 it was gcc-cross :/ Sep 13 22:02:23 btw angstrom / c7x0 Sep 13 22:02:42 btw btw, about 'Midnight' issue, try to log on oestats Sep 13 22:02:54 I remember some strange log times Sep 13 22:02:54 khem: cool, camping is much better. :-) Sep 13 22:03:24 khem: you think making the buffers cache-aligned helps ? Sep 13 22:03:48 ant_: midnight angstrom version issue? Sep 13 22:03:49 I think it will Sep 13 22:04:02 khem: let me power the target Sep 13 22:04:16 likewise, yes Sep 13 22:04:19 khem: in a minute :-) Sep 13 22:04:27 sometimes I had to rebuild angstrom-version Sep 13 22:05:18 iirc launching a build after 00 UTC is ok Sep 13 22:05:30 ? Sep 13 22:05:32 read 1 o'clock here in CEST Sep 13 22:05:46 angelox_123, sorry, talking with likewise Sep 13 22:05:59 btw you posted a broken pastebin link :) Sep 13 22:06:38 no sir..works fine: http://pastebin.com/Q4WLkF39 Sep 13 22:06:51 doh, tur , now Sep 13 22:08:54 khem, any better? Sep 13 22:09:32 ka6sox-work: no Sep 13 22:09:40 it seems cross ld has issues Sep 13 22:09:42 hmmm.... Sep 13 22:09:46 okay Sep 13 22:10:08 I am going to try it on a system which has ubuntu 10.04 native Sep 13 22:10:20 that way I will make sure that its not an issue with glibc on the vm Sep 13 22:10:25 mipsel? Sep 13 22:10:50 its mips64 Sep 13 22:10:54 new target Sep 13 22:11:34 okay, I am building with 10.4 64-bit and don't have any problems with glibc there. Sep 13 22:11:50 (another VM) Sep 13 22:11:53 ok Sep 13 22:12:09 it could be a real issue in linker I dont know Sep 13 22:17:32 khem: again about klcc-cross: the recipes installs in TOOLSCHAIN_PATH and not in $D, thus the package is empty. The staging-package, though, does contain the ${TARGET_PREFIX}klcc so actually all is working...just wondering about this dummy package... Sep 13 22:17:59 any help ? Sep 13 22:18:19 angelox_123, sorry, no idea about shr tasks / changes Sep 13 22:18:28 ok thanks anyway Sep 13 22:18:37 you'd better ask JaMa Sep 13 22:18:51 JaMa ? Sep 13 22:19:16 probably next week Sep 13 22:19:39 who is JaMa ? Sep 13 22:20:09 look here for the active maintainers Sep 13 22:20:10 http://cgit.openembedded.org/cgit.cgi/openembedded/log/?qt=grep&q=shr Sep 13 22:22:21 ant_: thanks for the evidence gathering on the midnight ghost issue :-) Sep 13 22:23:12 np, I skip this building late overnight :) Sep 13 22:29:14 any shr channel ? Sep 13 22:48:59 khem: you won $37 already :-) Sep 13 22:49:25 khem: btw, how's the tooth behaving? Sep 13 22:51:38 likewise: tooth is ok Sep 13 22:51:50 it got scared when I started rock climbing Sep 13 22:51:56 and stopped aching Sep 13 22:52:08 there were bigger pains :) Sep 13 22:52:21 khem: lol, not gravity enforced I hope? Sep 13 22:52:32 likewise: haha only muscular Sep 13 22:52:53 actually it was not real rock climbing Sep 13 22:53:19 in yosemite national park there is a rocky peak called half dome Sep 13 22:53:44 there is sort of trail with steps etc. Sep 13 22:54:01 likewise: lemme see more to the example Sep 13 22:54:16 and see if I can add more to the kitty :) Sep 13 22:55:04 khem: kitty is watching over the efika: http://www.sidebranch.com/openembedded/efika_senna.jpg Sep 13 22:55:26 haha Sep 13 22:55:52 and also keeping an eye on credit card Sep 13 22:55:55 khem: that was before I blew my (legacy) efika by plugging a PCI card Sep 13 22:56:25 khem: haha, got a lot of remarks on the credit card, but's a dutch bank card, decyphering the numbers doesn't gain you anything Sep 13 22:57:14 Giropass Sep 13 22:57:24 khem: -s, yes Sep 13 23:03:10 likewise: what options are you using to compile this app Sep 13 23:03:18 lemme see the makefule Sep 13 23:03:43 likewise O2 right Sep 13 23:03:59 khem: i've aligned the buffers to the cache line size (32 bytes), anything better than that? Sep 13 23:04:02 yes Sep 13 23:04:22 ok Sep 13 23:04:25 use -O3 Sep 13 23:04:27 no other tuning flags actually besides -O2 (I also tried -Os, will try that again now) Sep 13 23:04:37 you are using lot of loops Sep 13 23:04:47 and O3 gcc will unroll them Sep 13 23:05:08 khem: I have thought about unrolling them myself Sep 13 23:05:36 or add -funroll-all-loops -funroll-loops Sep 13 23:05:47 heh gcc knows better than programmer ;) Sep 13 23:06:28 -O3 over -O2: less than 0.3% improvement Sep 13 23:06:54 hmm ok Sep 13 23:07:02 -O2 -funroll-all-loops -funroll-loops Sep 13 23:07:08 how about this set Sep 13 23:09:51 'nite Sep 13 23:10:09 likewise: try this option too -maltivec -ftree-vectorizer-verbose=2 Sep 13 23:10:17 and see if gcc can verctorize itself Sep 13 23:11:43 khem: unrolling brings it to $87 Sep 13 23:11:47 :) Sep 13 23:11:55 (cumulative gain since baseline) Sep 13 23:12:14 * khem feels better than being in Las Vegas Sep 13 23:12:46 khem: visited vegas? was there during the NAB show two years back Sep 13 23:13:14 its a nice city Sep 13 23:13:15 bad kitty: foo.c:1: error: AltiVec and E500 instructions cannot coexist Sep 13 23:13:22 I knew Sep 13 23:13:28 vegas: for a while, yes Sep 13 23:13:29 just thought of trying Sep 13 23:14:21 * likewise is looking up -ftree-vectorizer-verbose=2 Sep 13 23:14:31 didn't gain me anything btw Sep 13 23:15:24 -ftree-vectorize -ftree-vectorizer-verbose=2 maybe? Sep 13 23:15:42 likewise: ok use calloc insteah of malloc here average = malloc(NUM_BYTES); Sep 13 23:15:50 then remove this loop Sep 13 23:15:55 for (unsigned int sample = 0; sample < NUM_SAMPLES; sample++) Sep 13 23:15:55 { Sep 13 23:15:55 average[sample] = 0; Sep 13 23:15:55 } Sep 13 23:16:28 khem: I've replaced the malloc() with posix_memalign(..., 32, ...) already. Sep 13 23:16:47 ok Sep 13 23:17:02 khem: that loop is initialization, it's unmeasurable in my experiment Sep 13 23:17:04 is the sample on that box Sep 13 23:17:09 I can log in and peek Sep 13 23:17:14 khem: yup Sep 13 23:17:17 ok Sep 13 23:17:39 feel welcome, the kitty won't bite Sep 13 23:18:05 (actually, she does. my gf has been to immediate hospital care twice because the kitty attacked here...) Sep 13 23:18:10 here/her Sep 13 23:19:40 likewise: where is the uptodate srcs Sep 13 23:21:01 khem: should be on your account ~/average/ now) Sep 13 23:21:49 I dont have write perm on the directory Sep 13 23:22:19 fixed Sep 13 23:22:36 still Permission denied Sep 13 23:23:02 oh I cant execute the compiler Sep 13 23:23:10 powerpc-angstrom-linux-gnuspe-gcc: Permission denied Sep 13 23:23:19 make: execvp: Sep 13 23:24:25 khem: try now Sep 13 23:24:28 likewise: you need to give me read perms on sysroot Sep 13 23:24:36 make clean; make Sep 13 23:24:52 works ! Sep 13 23:25:10 hmm... i wonder if itd be useful to create a buildout.cfg in OE, along with bootstrap.py, and arrange it to pull down bitbake for you and symlink the script into bin/, and perhaps even emit a conf/bblayers.conf and a generic conf/local.conf if one doesn't exist Sep 13 23:25:11 khem: actually, I built oe in your account :-) Sep 13 23:25:27 could clone oe, python bootstrap.py, bin/buildout, bin/bitbake task-boot Sep 13 23:25:30 * kergoth thinks Sep 13 23:26:04 likewise: average = 0x1010b048 Sep 13 23:26:08 is that the benchmark Sep 13 23:26:23 khem: "time /foo" Sep 13 23:26:52 khem: real wall time currently is 5.40s Sep 13 23:26:56 user 0m 5.68s Sep 13 23:27:08 khem: real wall time currently is 5.70s (typo) Sep 13 23:27:11 yup Sep 13 23:27:35 guys we are testing an OE compiler, if you think this is off-topic :-) Sep 13 23:36:33 hmmm Sep 13 23:37:55 thinking it would be nicer to move the various bitbake UIs into separate scripts -- there's no need to have a single bitbake script run them all, and they all act differently and do different things, so it doesn't make a lot of sense Sep 13 23:37:59 thoughts? Sep 13 23:40:58 kergoth: central maintainability (just speaking out loud, my knowledge of bitbake is flaky at best) Sep 13 23:46:52 I don't really see that as an advantage. Using multiple repositories for modules of a large python package is quite common (and distributed as separate eggs), and gives advantages like more granular versioning and encourages less tight coupling among the modules Sep 13 23:46:58 but *shrug* Sep 13 23:47:06 I'm no expert at python packaging and distribution Sep 14 00:43:05 It's an advantage if the UIs inherit from a base UI class, then it makes hacking them easier if you've got a syntax error in your work version but you can then switch to a working UI in a seperate file Sep 14 00:43:13 vs. having a syntax error in a single script that breake everything Sep 14 00:44:21 I wouldn't say I'm an expert in Python, but I have created a couple distutil packages and think it's the best scripting language on my resume. So take my input with a grain of salt. Sep 14 00:46:20 khem, any luck? Sep 14 00:47:36 Hmm, looks like they are broken out into seperate files. yay for that. Sep 14 00:59:56 I've been thinking about a presentation filter for the output of bitbake -D -v such that task id's would be prepended before each line Sep 14 01:00:41 So that you could more easily explore results / pinpoint errors.. Even just parsing it through ansi colorizer to find errors has been beneficial, but it seems like there's a datamining component that would be useful to be able to 'drill down' into recipes regardless of success or fail. Sep 14 01:00:48 Unless there's a simpler way to do it Sep 14 01:14:51 I am back. Was watching the Vuelta de Espanga Sep 14 01:15:16 let me read what scrolled off **** ENDING LOGGING AT Tue Sep 14 02:59:57 2010