**** BEGIN LOGGING AT Thu Apr 07 02:59:59 2011 Apr 07 03:26:22 kergoth: tried oe master with bitbake master lately ? Apr 07 03:26:26 I am getting Apr 07 03:26:35 ERROR: Error parsing /home/kraj/work/oe/openembedded/recipes/sensmon/libsensmon_git.bb: Failure expanding variable SRCPV, expression was ${@bb.fetch.get_srcrev(d)} which triggered exception KeyError: 'git:gitorious.org.sensor-monitor.libsensmon.gitmaster-libsensmon_rev' Apr 07 03:27:04 hmm Apr 07 03:27:07 it worked ok until 278fb41793343eb7c4c801242e6a0dda5aebbbaf Apr 07 03:27:19 i thought i fixed all the references Apr 07 03:27:22 guess i must have missed one Apr 07 03:27:29 * kergoth_ pines for unit tests Apr 07 03:30:16 yeah, i'm not seeing how that could be happening Apr 07 03:30:30 all the code that accesses the persist data checks for keyerror, at least in __init__.py Apr 07 03:30:32 * kergoth_ pokes around Apr 07 03:30:38 kergoth: Let me bisect it Apr 07 03:30:38 * kergoth_ checks git.py Apr 07 03:30:42 no need Apr 07 03:30:45 i know what commit did it Apr 07 03:30:54 i just don't know where the reference is coming from in the code Apr 07 03:30:58 since our parser doesn't give us useful tracebacks Apr 07 03:30:59 28958cd55e592853c68f5f2ba79381d1b8dcfb8f Apr 07 03:31:11 this one a4f62433845c29f98c6a9746d5d2847bf9506ea5 Apr 07 03:33:24 libsensmon_git.bb looks normal Apr 07 03:36:02 khem: see if that takes care of it Apr 07 03:36:05 (pull) Apr 07 03:36:18 03Christopher Larson  07master * r7492233f52 10bitbake.git/lib/bb/fetch/git.py: Apr 07 03:36:18 fetch.git: fix a remnant wrt persist + keyerror Apr 07 03:36:18 Signed-off-by: Christopher Larson Apr 07 03:37:13 kergoth: localcounts is dict now ? Apr 07 03:37:28 persist_data api changed a while back Apr 07 03:37:44 the whole addDomain, etc was lame Apr 07 03:37:59 now it gives you a python mapping to the sql table Apr 07 03:38:16 recently made it raise keyerror when the key isn't there, so it now passes the upstream python mapping unit tests Apr 07 03:38:27 (cpython/Lib/Test/mapping_tests.py, iirc) Apr 07 03:38:38 nice Apr 07 03:38:43 btw. the fix worked Apr 07 03:38:46 great Apr 07 03:39:25 I wonder why it did not barf on oe-core Apr 07 03:39:32 fetch2 vs fetch Apr 07 03:39:49 dont' think fetch2 duplicated that particular code between __init__.py and git.py the way fetch does Apr 07 03:39:54 which is likely why i missed it in fetch Apr 07 03:40:21 i see makes sense Apr 07 03:53:13 i'm *trying* to start adding unit tests to bitbake, but you can't do that worth a damn without isolating the module, and ours are so tightly intertwined its crazy. persist_data was already pretty separate, so it was easy.. Apr 07 03:53:14 heh Apr 07 07:00:52 fyi: linuxdevices writeup on yocto 1.0: http://www.linuxfordevices.com/c/a/News/Yocto-1-released/ Apr 07 07:15:00 good morning Apr 07 07:15:13 eFfeM_work1: thx, looks like is time to test it Apr 07 07:21:21 mckoan: let us know your results Apr 07 08:11:12 boyaka Apr 07 08:24:24 XorA|gone: D Apr 07 09:40:01 03Siddharth Heroor  07org.openembedded.dev * r9fc160a781 10openembedded.git/recipes/ti/ti-sysbios.inc: (log message trimmed) Apr 07 09:40:01 ti-sysbios: Update Installer unpack commands. Apr 07 09:40:01 * New versions of TI Sys/Bios use a different installer unpack Apr 07 09:40:01 command. Apr 07 09:40:01 * Bump PR. Apr 07 09:40:01 Signed-off-by: Siddharth Heroor Apr 07 09:40:01 Acked-by: Denys Dmytriyenko Apr 07 09:40:17 03Siddharth Heroor  07org.openembedded.dev * r2fa7fa0295 10openembedded.git/recipes/ti/ti-sysbios_6.31.04.27.bb: Apr 07 09:40:17 ti-sysbios: Add version 6.31.04.27. Apr 07 09:40:17 Signed-off-by: Siddharth Heroor Apr 07 09:40:17 Signed-off-by: Koen Kooi Apr 07 09:40:18 03Siddharth Heroor  07org.openembedded.dev * r44fe49b1d3 10openembedded.git/recipes/ti/ (ti-sysbios_6.21.01.16.bb ti-sysbios_6.31.00.18.bb): (log message trimmed) Apr 07 09:40:24 ti-sysbios: Copy installer unpack to recipe versions. Apr 07 09:40:24 * Newer versions of Sys/Bios have a different unpack sequence. Apr 07 09:40:24 This patch is in preparation for a new versions that use the Apr 07 09:40:24 new unpack sequence. Apr 07 09:40:24 Signed-off-by: Siddharth Heroor Apr 07 09:40:25 Acked-by: Denys Dmytriyenko Apr 07 09:40:25 03Siddharth Heroor  07org.openembedded.dev * r4c66835f2d 10openembedded.git/recipes/ti/ti-sysbios.inc: Apr 07 09:40:26 ti-sysbios: Add missing License field. Apr 07 09:40:26 * Sys/Bios is released under a BSD license. Apr 07 09:40:27 Signed-off-by: Siddharth Heroor Apr 07 09:40:27 Acked-by: Denys Dmytriyenko Apr 07 09:40:34 Signed-off-by: Koen Kooi Apr 07 09:40:34 03Michael Jones  07org.openembedded.dev * r2aa7296faa 10openembedded.git/recipes/base-files/base-files/angstrom/ (issue issue.net): Apr 07 09:40:34 base-files: write Angstrom as Ångström in the issue file. Apr 07 09:40:34 spice up the ASCII art a bit Apr 07 09:40:35 Signed-off-by: Michael Jones Apr 07 09:40:35 Signed-off-by: Koen Kooi Apr 07 09:40:36 03Siddharth Heroor  07org.openembedded.dev * r77aa9f6a74 10openembedded.git/recipes/u-boot/u-boot_2010.06-psp04.00.00.10.bb: Apr 07 09:40:36 u-boot: Add PSP version for ti816x devices. Apr 07 09:40:37 * Add TI PSP u-boot version for dm816x/c6a816x/am389x devices. Apr 07 09:40:37 * Based on PSP release 4.00.00.10. Apr 07 09:40:38 (9 lines omitted) Apr 07 10:00:04 Hi. anyone have an example meta-toolchain/task-toolchain recipe where they successfully added imagemagick? so that imagemagick headers show up in the angstrom-*toolchain tarball? Apr 07 10:27:21 htns: nope, meta-toolchain creates a toolchain, imagemagick is a separate package Apr 07 10:28:54 mckoan, i guess i'm trying to figure out how i can create a sdk that includes imagemagick headers and libraries , i currently unpack the angstrom-*toolchain and use that as the sdk Apr 07 10:29:16 and that works, i can build helloworld and run that on the target Apr 07 10:32:02 htns: afaik angstrom is using custom script to assemble SDKs https://gitorious.org/angstrom/narcissus/blobs/master/scripts/assemble-sdk.sh Apr 07 11:25:22 03Frans Meulenbroeks  07org.openembedded.dev * r0d0f77aa63 10openembedded.git/recipes/gcc/ (3 files in 2 dirs): Apr 07 11:25:22 gcc 4.1.2: updated nios patches Apr 07 11:25:22 This is strictly nios2 Apr 07 11:25:22 nios2 specific patches are updated to match the latest version Apr 07 11:25:22 of the toolchain as made available by Altera Apr 07 11:25:23 Signed-off-by: Frans Meulenbroeks Apr 07 12:22:28 03Chase Maupin  07org.openembedded.dev * r15ef9da53c 10openembedded.git/recipes/alsa/alsa-state/am45x-evm/asound.conf: Apr 07 12:22:28 alsa-state: Add support for am45x-evm machine type Apr 07 12:22:28 * Added asound.conf file for am45x-evm machine type based on Apr 07 12:22:28 the omap4430-panda asound.conf file. Apr 07 12:22:28 Signed-off-by: Chase Maupin Apr 07 12:22:29 Signed-off-by: Koen Kooi Apr 07 12:22:33 03chase maupin  07org.openembedded.dev * r5d11a20e17 10openembedded.git/recipes/linux/ (linux-omap4/am45x-evm/defconfig linux-omap4_2.6.35.3.bb): (log message trimmed) Apr 07 12:22:34 linux-omap4: Add support for am45x-evm machine Apr 07 12:22:34 * Add the am45x-evm machine type to the COMPATIBLE_MACHINEs Apr 07 12:22:34 for this kernel version. Apr 07 12:22:34 * Add the defconfig file for am45x-evm machine type Apr 07 12:22:34 Signed-off-by: Chase Maupin Apr 07 12:22:35 Acked-by: Denys Dmytriyenko Apr 07 12:22:42 03chase maupin  07org.openembedded.dev * re30746f58f 10openembedded.git/recipes/u-boot/u-boot_git.bb: Apr 07 12:22:42 u-boot: Add support for am45x-evm machine Apr 07 12:22:42 * Added support for the am45x-evm machine type Apr 07 12:22:42 Signed-off-by: Chase Maupin Apr 07 12:22:43 Acked-by: Denys Dmytriyenko Apr 07 12:22:43 Signed-off-by: Koen Kooi Apr 07 12:22:47 03chase maupin  07org.openembedded.dev * rc0b9a47eb3 10openembedded.git/contrib/angstrom/sort.sh: Apr 07 12:22:47 sort: Add support for am45x-evm machine type Apr 07 12:22:47 Signed-off-by: Chase Maupin Apr 07 12:22:47 Acked-by: Denys Dmytriyenko Apr 07 12:22:47 Signed-off-by: Koen Kooi Apr 07 12:22:54 03chase maupin  07org.openembedded.dev * r2ac568b98e 10openembedded.git/conf/machine/am45x-evm.conf: (log message trimmed) Apr 07 12:22:54 am45x-evm: Add am45x-evm machine configuration Apr 07 12:22:54 * Added a new machine configuration for the am45x-evm device. Apr 07 12:22:54 * This machine currently mimics the omap4430-panda configuration Apr 07 12:22:55 during the prototyping phase but is expected to change as the Apr 07 12:22:55 hardware and software evolves. Apr 07 12:22:56 * The am45x-evm machine type is used to allow differentiating Apr 07 12:52:25 I'd like to build my program and export "includes" as separate package, available for all archs. after it I'd like to get this "includes" package and use it in different machine to connect ot this program. what recipt can I look as an example? Apr 07 12:54:52 PACKAGES += "${PN}-includes" Apr 07 12:55:06 FILES_${PN}-includes = "/random/files" Apr 07 12:55:21 PACKAGE_ARCH_${PN}-includes = "all" Apr 07 13:16:00 XorA|gone, .${PN}-dev is wrong name for such a package ? Apr 07 13:16:48 dv: traditionally -dev has included things like static libraries which are not so portable Apr 07 13:17:03 dv: you know your exact use best Apr 07 13:19:56 XorA|gone, I did it and I see my include there: tmp/sysroots/armv5te-angstrom-linux-gnueabi/usr/include/exported_defs.h Apr 07 13:20:57 it's ok, But I'd like to get it in tmp/deploy/glibc/images/at91sam9m10g45ek/exported_defs.h also Apr 07 13:21:15 you would need to add a do_deploy() then Apr 07 13:22:18 Could someone look at the patches I just sent to ml? Apr 07 13:24:39 XorA|gone, you rocks! :) Apr 07 14:38:47 03Tom Rini  07master * r11a15aa133 10openembedded.git/conf/machine/qemux86.conf: Apr 07 14:38:47 qemux86: Switch to xorg-xserver for X11 Apr 07 14:38:47 Tested with x11-image Apr 07 14:38:47 Signed-off-by: Tom Rini Apr 07 14:38:50 03Tom Rini  07master * rf434a51a7d 10openembedded.git/recipes/xorg-xserver/xorg-xserver-common.inc: Apr 07 14:38:50 xorg-xserver-common.inc: Add libgcrypt to DEPENDS Apr 07 14:38:50 This is checked for at configure time as an optional thing so Apr 07 14:38:50 we add it to DEPENDS for consistency. Apr 07 14:38:50 Signed-off-by: Tom Rini Apr 07 14:39:00 03Tom Rini  07master * r09401edbe0 10openembedded.git/recipes/klibc/klcc-cross_1.5.21.bb: Apr 07 14:39:00 klcc-cross: Fixup paths for external toolchains Apr 07 14:39:00 Signed-off-by: Tom Rini Apr 07 14:39:02 03Tom Rini  07master * r8280f2812a 10openembedded.git/recipes/busybox/ (busybox-1.18.4/fix-iptunnel-location.patch busybox_1.18.4.bb): Apr 07 14:39:02 busybox: Add a patch to fix the location of iptunnel Apr 07 14:39:02 Signed-off-by: Tom Rini Apr 07 15:17:31 anyone here know cython? it appears to hate me, and i'm not entirely sure why Apr 07 15:19:30 urg Apr 07 15:19:42 must crawl across the street to a yocto meeting :) Apr 07 15:20:01 lol...its 11am!!! Apr 07 15:20:24 * kergoth_ chuckles Apr 07 15:20:28 heh Apr 07 15:20:31 0820 Apr 07 15:20:41 need breakfast and coffee Apr 07 15:20:54 * mwester-laptop admires the courage of one so exhausted so early in the AM, yet willing to attend a meeting... Apr 07 15:20:58 :p Apr 07 15:23:19 hrm Apr 07 15:23:28 ~seen grg Apr 07 15:23:41 grg <~grg@eth7090.sa.adsl.internode.on.net> was last seen on IRC in channel #oe, 6d 15h 12m 48s ago, saying: 'Pffft... Freenode doesn't love me. Its just using me for sex.'. Apr 07 15:24:18 mmmmk Apr 07 15:27:54 * Crofton just complains a lot Apr 07 15:52:06 damnit Apr 07 15:52:07 opkg hates me Apr 07 15:52:09 on the plus side Apr 07 15:52:14 it hates me equally via cython or c Apr 07 16:00:15 what are you cooking? Apr 07 16:02:01 ideally, i want python bindings Apr 07 16:02:08 but it doesn't appear to like me much Apr 07 16:02:38 ah Apr 07 16:04:20 03Tom Rini  07master * rfc65614bf2 10openembedded.git/recipes/rng-tools/rng-tools_2.bb: Apr 07 16:04:20 rng-tools: Fixup install to ensure executablity Apr 07 16:04:20 Signed-off-by: Tom Rini Apr 07 16:46:47 kergoth_: are you available to look at my pending patches? Apr 07 16:52:31 kergoth, or anyone else, INGUAS_INSTALL_linux = "${@base_ifelse(d.getVar('IMAGE_LINGUAS', True), ....}" is always going to be true because even empty vars are set Apr 07 16:52:39 So it should be some test for non-empty Apr 07 17:09:24 Tartarus: no, that's not the case. Apr 07 17:09:31 an empty string is evaluated as False in boolean context by python Apr 07 17:09:58 k Apr 07 17:13:52 yep. that allows for nice shortcuts when you have default values, such as mystring = otherstring or "my default string" Apr 07 17:33:22 03Carlos Hernandez  07master * rce5c4621a5 10openembedded.git/recipes/lmbench/ (lmbench/rename-line-binary.patch lmbench_3.0-a9.bb): (log message trimmed) Apr 07 17:33:22 lmbench: rename 'line' binary as 'lm_line' Apr 07 17:33:22 Both lmbench and util-linux-ng packages provide own /usr/bin/line binaries. Apr 07 17:33:22 Even though the binaries name is the same, their functionality is different. Apr 07 17:33:22 This patch renames lmbench's line binary as lm_line to avoid conflicts with Apr 07 17:33:22 util-linux-ng. script/config-run is also modified (patch) to call lm_line Apr 07 17:33:23 instead of line. Apr 07 17:34:48 ugh Apr 07 17:35:13 opkg_get_option will happily run off into the weeds, past the end of its options table, if you pass it an option that doesn't exist Apr 07 17:35:16 * kergoth_ twitches Apr 07 17:42:41 03Tom Rini  07master * r443bcc0785 10openembedded.git/recipes/xorg-app/xinit_1.3.0.bb: Apr 07 17:42:41 xinit: Fix mcookie / util-linux-ng dependency Apr 07 17:42:41 xinit just needs to know the runtime path of mcookie so we need to Apr 07 17:42:41 RDEPEND on util-linux-ng and pass the runtime path in via EXTRA_OECONF Apr 07 17:42:41 Signed-off-by: Tom Rini Apr 07 18:43:35 is there a way for me to know which kernel version an image will use at build time? Apr 07 18:46:00 bitbake -g virtual/kernel will have the version in the .dot files, bitbake -n will show you the task execution messages for the kernel, bitbake -s will list it if you know the recipe it's using, etc.. Apr 07 18:51:52 kergoth_: but I'd need to know it at image build time Apr 07 18:52:03 kergoth_: so it would need to be on the database no? Apr 07 18:52:17 ? Apr 07 18:52:35 you said build time, i gave you build commands. Apr 07 18:52:40 kergoth_: I need to be able to know the filename (not the symlink) that will be the kernel Apr 07 18:52:45 if you want to know via inspection after the fact, it's an entirely different question Apr 07 18:52:48 kergoth_: sorry; did it wrong Apr 07 18:53:04 i'd say enable testlab and look at its list of installed packages, etc Apr 07 18:53:13 then you know exactly what it installed in the image, at least.. Apr 07 18:58:13 echo "${KERNEL_VERSION}" >$kerneldir/kernel-abiversion Apr 07 18:58:13 + echo "${EXTENDPV}" >$kerneldir/kernel-extendpv Apr 07 18:58:13 echo "${S}" >$kerneldir/kernel-source Apr 07 18:58:23 kergoth_: seems logical? ^ Apr 07 18:59:10 seems reasonable. still not really seeing the need, but it doesn't hurt anything, and is consistent with what it already does Apr 07 18:59:40 there are a lot of things we should really do to make it easier to inspect a build after a fact and find out exactly what was built, what errors happened, if any, what was output by what recipes, .. Apr 07 19:00:19 brb, reboot Apr 07 20:34:31 khem: hi, do you have sec? Apr 07 20:36:15 khem: tested that armv4t build with oe-core again, this time with eglibc taken from oe.dev and it still fails http://paste.pocoo.org/show/367465/ Apr 07 20:55:31 someone has a clue about why KERNEL_PACKAGE_VERSION = "${@oe.utils.read_file('${STAGING_KERNEL_DIR}/kernel-extendpv')}" Apr 07 20:55:37 doesn't work inside the image? Apr 07 20:55:51 (I added this file on the kernel.bbclass) Apr 07 20:56:08 checking -e it seems it is not expanded Apr 07 20:56:11 dunno why Apr 07 21:03:38 otavio: don't '' prevent expansion in this context? Apr 07 21:04:04 mario-goulart: supposely not since it is inside of double quoted string Apr 07 21:06:44 has anyone else seen a problem building the xf86-video-omapfb recipe? I am getting a QA configure failure saying its pulling in host includes. I found this when i removed a patch from my xserver-xorg recipe that was suppose to strip out host includes. has anyone seen this in the 2011.3 branch? Apr 07 21:06:48 I honestly don't know what actually evaluates those toplevel expressions in recipe files. So it's just a wild guess. Apr 07 21:08:03 what is also strange is this only appears on my beagleboard build and not qemux86 Apr 07 21:16:01 JaMa: so the build fails in cross-gcc-intermediate right ? Apr 07 21:16:38 I dont build armv4 or armv4t usually Apr 07 21:16:49 I will try it out and see if I can reproduce it Apr 07 21:17:48 khem: the path shows cross-gcc-intermediate, but it's eglibc build Apr 07 21:17:59 hmm Apr 07 21:18:50 I see its the temp staging Apr 07 21:18:53 thats fine Apr 07 21:19:45 JaMa: its not using thumb to build eglibc right ? Apr 07 21:21:32 khem: -march=armv4t -mtune=arm920t -mthumb-interwork -mno-thumb, I've tried it with forced ARM arch and got same error Apr 07 21:22:19 JaMa: can you dump libgcc and see if __gnu_thumb1_case_uqi is there ? Apr 07 21:22:46 thats /OE/shr-core/tmp/sysroots/x86_64-linux/usr/lib/armv4t-oe-linux-gnueabi.gcc-cross-intermediate/gcc/arm-oe-linux-gnueabi/4.5.3/libgcc.a or .so Apr 07 21:26:32 khem: I'll try tomorrow, I cleaned it few minutes ago to try to build spitz with it Apr 07 21:26:44 ok Apr 07 21:26:53 which machine do you try Apr 07 21:26:59 to repdouce it Apr 07 21:27:12 I have it with om-gta02 Apr 07 21:27:28 nokia900 works fine with same layers Apr 07 21:27:38 not added spitz just to try armv5 too Apr 07 21:27:50 ok Apr 07 21:27:55 I use qemuarm Apr 07 21:28:03 and efikamx both work well Apr 07 21:28:10 but they are v5 and v7 Apr 07 21:45:29 khem: same error with spitz (armv5te0 Apr 07 21:47:04 bitbake@jama ~ $ nm /OE/shr-core/tmp/sysroots/x86_64-linux/usr/lib/armv5te-oe-linux-gnueabi.gcc-cross-intermediate/gcc/arm-oe-linux-gnueabi/4.5.3/libgcc.a | grep __gnu_thumb1_case_uqi Apr 07 21:47:07 00000001 T __gnu_thumb1_case_uqi Apr 07 22:02:12 JaMa: hmm Apr 07 22:02:29 Show me your layer mods Apr 07 22:02:37 JaMa: are you using sane-toolchain stuff Apr 07 22:03:17 yes Apr 07 22:03:34 ok Apr 07 22:03:41 meta-shr layer is here http://git.shr-project.org/git/?p=meta-shr.git;a=summary Apr 07 22:04:03 trying without PREFERRED_ARM_INSTRUCTION_SET_armv4t = "thumb" now Apr 07 22:05:30 get rid of this PREFERRED_ARM_INSTRUCTION_SET_armv5te = "thumb" Apr 07 22:05:37 ok Apr 07 22:05:42 I am sure this is the problem Apr 07 22:06:08 oe-core has not been tested with thumb Apr 07 22:06:10 so far Apr 07 22:06:59 that said it should be fixed if thats the case Apr 07 22:07:09 yup Apr 07 22:09:32 I think the problem is libgcc Apr 07 22:09:40 is built with thumb mode Apr 07 22:09:43 can you check Apr 07 22:10:41 JaMa: ok I see the problem Apr 07 22:11:07 khem: ARM_INSTRUCTION_SET = "arm" is in all OE gcc Apr 07 22:11:18 and only in ./gcc-csl-arm-2008q1.inc for oe-core Apr 07 22:11:24 yes Apr 07 22:11:29 thats the real problem Apr 07 22:13:03 JaMa: try this patch http://paste.ubuntu.com/590993/ Apr 07 22:13:08 against meta-oe Apr 07 22:13:36 ideally we should propose the same to recipes-devtools/gcc/gcc-common.inc in oe-core Apr 07 22:14:08 already trying :) Apr 07 22:14:19 ok Apr 07 22:14:43 but now you can clean each stage of gcc bootstrap Apr 07 22:14:48 isnt it nice Apr 07 22:16:06 I'm still cleaning all at once to be sure :) Apr 07 22:16:17 you dont even have to clean Apr 07 22:16:23 it will notice automatically Apr 07 22:16:30 and rebuild required deps too Apr 07 22:16:45 just edit and bitbake eglibc Apr 07 22:17:20 I'm short of tmpdir space.. so I had to clean it after building spitz to have enough space :) Apr 07 22:17:34 dont you use rm_work? Apr 07 22:17:37 I use that all the time Apr 07 22:17:43 its bit harsh on disk Apr 07 22:17:52 but seems to accomodate more builds Apr 07 22:18:45 I'm but in this case a lot is in tmpwork dir unfinished when eglibc fails and cannot continue to let rm_work run Apr 07 22:19:04 I've also disabled src_distribute for now until it's sstate enabled Apr 07 22:19:07 k Apr 07 22:19:37 because with rm_work it was fetching all recipes from deptree again and again, even when they were already built and rm_worked Apr 07 22:20:21 hmm Apr 07 22:23:15 hrm Apr 07 22:25:38 khem: eglibc compiled fine now, thanks Apr 07 22:25:47 ok enjoy Apr 07 22:27:31 fsck load average: 47.49, 14.89, 6.22 Apr 07 22:29:08 and better load average: 88.50, 29.52, 11.80 Apr 07 22:29:36 hope it wont be smoky soon Apr 07 22:29:46 JaMa|Zzz: btw. I have sent a patch for meta-oe Apr 07 22:29:50 with your Tested-by Apr 07 22:30:13 Hope you have a LOT of cores, there, JaMa|Zzz Apr 07 22:30:19 this happens with /OE/shr-core/openembedded-core/scripts twice in PATH :/ Apr 07 22:30:28 bitbake wrapper is fork bombing me.. Apr 07 22:31:25 good build is sanely going (again) time to go to bed Apr 07 22:31:53 heh, i've had that happen too Apr 07 22:32:06 it just gets the next bitbake down the line, doesnt' check to see its really bitbake Apr 07 22:32:24 oh recursion Apr 07 22:32:51 kergoth_: it's also a bit picky about removing his own path from $PATH Apr 07 22:33:12 kergoth_: when I had scripts with trailing / it didn't remove it because expects scripts: iirc Apr 07 22:33:39 kergoth_: so it was recursing too, but iirc failed before such load :) Apr 07 22:33:56 * kergoth_ chuckles Apr 07 22:34:18 i think i have a snippet of good shell code somewhere for doing that sort of wrapper path handling, bit less error prone, but i'd have to figure out where it went Apr 07 22:34:31 * mwester-laptop used a horrible hack to fix a similar problem; the wrapper passed a special flag that was accepted only by the real tool, thus preventing recursion. Apr 07 22:34:56 * JaMa|Zzz likes mwester-laptop solution Apr 07 22:35:42 or why not rename wrapper name or real bitbake? Apr 07 22:35:56 we were using bb alias for a while Apr 07 22:36:11 JaMa|Zzz: you mean the name of script ? Apr 07 22:36:35 its better to rename it I guess Apr 07 22:37:14 yes name of wrapper script or name of bitbake script itself Apr 07 22:37:37 bitbake should be called bitbake imo Apr 07 22:37:51 since there is a possibility that not oe-core folks will also use it Apr 07 22:37:51 pseudobitbake sounds nice but is long :) and shorter pb would give pb__ too much credit everytime we build something :) Apr 07 22:38:17 just bb should be nice Apr 07 22:38:23 agreed Apr 07 22:38:37 or bbit ;) Apr 07 22:38:58 now really sleep(), 6h remaining Apr 07 22:39:11 i don't think renaming it would be a very good idea, personally. bb/bbit are short enough that its unclear what they are, and all the info people find all over the net talk about bitbake, not bb/bbit, they're bound to try using the wrong command Apr 07 22:39:27 which will explode (admittedly with a message saying to use the wrapper) Apr 07 22:40:08 kergoth_: what about installing symlink bitbake.real -> bitbake with real bitbake and calling bitbake.real not bitbake from wrapper? Apr 07 22:41:00 that's reasonable, but then you're modifying your bitbake tree, and screwing up the 'git status' info if the tree is in git.. Apr 07 22:42:06 kergoth_: ah.. good catch.. I'm installing bitbake to system (with gentoo .ebuild) Apr 07 22:42:51 kergoth_: but still you can create such link in upstream repo and everybody will get it with clean tree Apr 07 22:44:30 which will break checking it out onto a system that doesn't support symlinks, not to mention just cluttering up the source tree with stuff that has nothing to do with bitbake and everything to do with oe-core.. Apr 07 22:44:31 heh Apr 07 22:49:30 bitbake --real Apr 07 22:50:50 doesn't solve the problem this was about in the first place Apr 07 22:59:30 well.. wrapper should know where real bitbake live Apr 07 22:59:35 then call it with full path Apr 07 23:00:04 or just rename wrapper script Apr 07 23:00:15 (oebb.sh) Apr 07 23:02:44 scroll up. Apr 07 23:02:50 that's exactly what we were just debating Apr 07 23:08:24 I just don't know where and when bitbake wrapper was introduced Apr 07 23:10:53 it's in poky and oe-core. scripts/bitbake. scripts gets prepended to the path, and it removes its own location from the path and runs the next one in line Apr 07 23:16:48 looking as self-made problem :) Apr 07 23:17:07 call it poky-build or something alike Apr 07 23:17:10 well, bitbake in that context is *useless* without the wrapper script Apr 07 23:17:30 your builds *will* fail Apr 07 23:17:52 hm.. Apr 07 23:18:30 the entire build runs under psuedo, rather than running individual tasks under fakeroot. it means we get proper permissions carried between install and packaging and all Apr 07 23:18:32 well.. I'm out of ideas for now then :) Apr 07 23:18:55 (its not enabled for everything though, its enabled at particular points using env vars) Apr 07 23:20:06 * Jay7 -> sleep Apr 07 23:58:36 JaMa|Zzz: fyi: eval `bitbake -e foo|grep \^WORKDIR=` should be the correct way to extract vars. we need to add a bitbake arg to request a specific var, not everything Apr 08 00:04:38 hrm, i have a bbappend file in another layer where i add a file in the SRC_URI, but now it seems to not find the files from the orignal recipe layer. Is there some magic im forgetting to get it to search that path? Apr 08 00:05:44 wtf... okay i found the answer, but it confuses me. instead of SRC_URI_append i used SRC_URI +=. am i missing a symantic here? Apr 08 00:06:44 kergoth: bitbak -e could be time consuming Apr 08 00:06:55 why not test some cmdline option of bb Apr 08 00:07:19 geiseri: SRC_URI_append should have done it Apr 08 00:07:36 geiseri: =. is similar to append Apr 08 00:07:55 oh... what is the difference between =. and +=? Apr 08 00:08:51 * geiseri wanders off for the bitbake manual Apr 08 00:11:14 khem: found the answer. if i use =. i need to insert a space around the text, but += i do not. Apr 08 00:56:42 khem: what do you mean by test some cmdline option? Apr 08 00:57:11 geiseri: yeah, the + operations are conceptually more about list-like variables, as opposed to concatenation **** ENDING LOGGING AT Fri Apr 08 02:59:58 2011