**** BEGIN LOGGING AT Tue Aug 05 03:00:00 2014 Aug 05 06:43:02 good morning Aug 05 06:52:28 is it morning already? Aug 05 08:21:58 morning all Aug 05 08:22:04 morning Aug 05 08:31:26 koen: have you recently built valgrind for arm? Aug 05 08:31:47 there is a strange COMPATIBLE_HOST_armv7a = 'arm.*-linux' Aug 05 08:31:53 in the oe-core recipe Aug 05 08:32:01 ant_work: ah really? Aug 05 08:32:26 ant_work: i had it built some time ago (3.9) for armv7 and it seemed to work fine Aug 05 08:32:27 seems incompatible for older arm Aug 05 08:32:36 strange... Aug 05 08:32:56 maybe just untested? Aug 05 08:33:27 ant_work: yes i can confirm that. valgrind from 3.7(IIRC) explicitly supprts armv7 and newer, but not the olders. it also does not build for them Aug 05 08:34:25 at least not in the oe-environment, FWIW Aug 05 08:35:53 I see, thx Aug 05 08:35:58 but as i'm just building some stuff there, i can report about valgrind on armv7 in a bunch of hours if you like Aug 05 08:36:05 patches around..http://sourceforge.net/p/valgrind/mailman/message/31485465/ Aug 05 08:37:08 you know what? I'll verify the mips/x86 binaries instead Aug 05 08:37:10 ant_work: my memory is a bit cloudy there, but i think there also was some ugly ptest issues with arm intrinsics detection when building for cortex-a5 Aug 05 08:37:23 i think i had to disable ptest for that Aug 05 09:04:44 is it possible for a .bbappend to modify the inherits? e.g. remove ptest from it? Aug 05 09:23:51 LetoThe2nd: no Aug 05 09:24:01 ant_work: ok, i just verified: valgrind 3.9 r8 builds fine for armv7, but the ptest is broken for cortex a5, because of its stripped FPU Aug 05 09:24:05 bluelightning: dang. Aug 05 09:24:37 you can set variables to control the behaviour of the inherited class though Aug 05 09:25:01 LetoThe2nd: thx for having verified Aug 05 09:25:35 LetoThe2nd: perhaps you could set PTEST_ENABLED = "0" Aug 05 09:25:52 ant_work: when i first dug into this, i also did some trivial tests on the target. as "trivial" implies i didn't check too much, but valgrind seemed to be functional Aug 05 09:25:59 bluelightning: ah, let me check! Aug 05 09:30:21 BTW: IIRC the ARMv7 port of Valgrind was sponsored by Nokia. So it's not surprising they didn't target older ARM architectures, as at that time they were firmly in Cortex land. Aug 05 09:30:51 tbr: hey don't destroy my illusions that it just appeared out of thin air! Aug 05 09:31:11 ok, ok, it was *magic* all along! Aug 05 09:31:19 tbr: better. Aug 05 09:33:42 bluelightning: that did the trick, thanks Aug 05 09:34:02 LetoThe2nd: np Aug 05 09:51:59 the optimum would of course be to fix ptest for the a5-style fpu, but after having a short peek thats way beyond my expertise Aug 05 09:59:44 hm, are there issues known with ckermit and evtest in current meta-oe? ckermit seems to be not downloadable any more, and evtest hits a checksum mismatch Aug 05 10:00:08 LetoThe2nd: there's a patch out for evtest from otavio Aug 05 10:00:13 isn't 'evtest' in coreutils nowadays? Aug 05 10:00:50 bluelightning: hm. Aug 05 10:02:54 koen: will look that up.. $COWORKER added it to a build and now it broke Aug 05 10:10:35 ok, for ckermit it just looks like their ftp is somehow difunct today Aug 05 10:22:07 koen: doesn't look like its in coreutils, at least not for me Aug 05 14:14:23 I'd like to use "bitbake-whatchanged", but for the "-c populate_sdk" command for my image.. Can I do that ? Aug 05 15:15:28 I'm trying to get a setuid perl script to run as a cgi-bin. It seems like everything in the universe is fighting against that sort of thing these days. What's the right way to do this? Aug 05 15:15:47 setuid root Aug 05 16:19:12 hi. how can i run specific script in configure() phase with native enivronment? Aug 05 16:19:12 (i want to run ./bootstrap in xbmc under native environment) Aug 05 16:19:12 Aug 05 16:34:27 hi! i have noticed that in my builds tmp-eglibc/deploy/ipk/Packages is empty (size is 0). i am not sure what this file is supposed to contain actually. Aug 05 16:34:51 my problem is that I am trying to use PACKAGE_FEED_URIS which by default seems to expect that tmp-eglibc/deploy/ipk/Packages.gz, and it doesn't in my case. Aug 05 16:34:59 does that make any sense? Aug 05 16:38:21 the packages file shouldn't be empty if you've built an image, or package-index, but otherwise who knows :) Aug 05 16:45:23 kergoth: well it is. i have proper Packages files in subfolder. Aug 05 16:45:34 ahh, that makes sense Aug 05 16:45:59 what is the top level Packages file supposed to contain? Aug 05 16:46:12 btw, opkg commands work fine Aug 05 16:46:55 ndec: I would doubt the top-level file is used at all Aug 05 16:47:10 the code which constructs images uses a feed per package architecture Aug 05 16:47:12 it's just that if I use PACKAGE_FEED_URIS is automatically adds: Aug 05 16:47:12 src/gz url-0 http://10.42.0.0/opkg/bbb/ipk Aug 05 16:47:12 in the base feed Aug 05 16:49:40 which is explictely what the features does in package_manager.py: Aug 05 16:49:40 config_file.write("src/gz url-%d %s/ipk\n" % (uri_iterator, uri)) Aug 05 20:27:36 all, i'm having an odd build issue: Aug 05 20:27:46 update-alternatives: Error: not linking /home/justin/development/tc3-detos/detos/builds/tmp-detos-7.3.0-devonit-tc3-eglibc/work/devonit_tc3-oe-linux-gnueabi/detos-squashfs-image/1.0-r12/rootfs//usr/bin/resize to /bin/busybox.nosuid since /home/justin/development/tc3-detos/detos/builds/tmp-detos-7.3.0-devonit-tc3-eglibc/work/devonit_tc3-oe-linux-gnueabi/detos-squashfs-image/1.0-r12/rootfs//usr/bin/resize exists and is not a link Aug 05 20:27:56 This happens occasionally, and I usually have to clean out my build directory completely to resolve it. I'm hoping someone here might have some insight on a less invasive solution! **** ENDING LOGGING AT Wed Aug 06 02:59:59 2014