**** BEGIN LOGGING AT Mon Sep 19 02:59:57 2011 Sep 19 08:09:41 morning all Sep 19 11:16:36 JaMa: ping? Sep 19 11:18:15 pong Sep 19 11:20:40 JaMa: Did exporting LD_LIBRARY_PATH in bitbake resolve your pseudo problem? Sep 19 11:21:10 yes Sep 19 11:21:34 JaMa: Interesting. Where is your system setting LD_LIBRARY_PATH? Sep 19 11:21:47 nowhere it's empty Sep 19 11:21:51 shell .profile or something like that? Sep 19 11:22:12 What is puzzling me is that nobody else sees those issues Sep 19 11:23:52 I'm less worried about the fix and more worried about why you see something different to everyone else :/ Sep 19 11:25:21 I'm not alone.. I know at least about 2 more people with same issues (both using shr-chroot afaik) Sep 19 11:26:08 and koen has it too (when not using shr-chroot), iirc I've seen it in one of his emails in log snippet about something else Sep 19 11:26:56 ah, here http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-September/035098.html Sep 19 11:27:56 and the problem started few days ago (1-2 weeks max) Sep 19 11:28:47 JaMa: I don't doubt it, I just don't understand why it should only happen for some people either : Sep 19 11:29:08 JaMa: I get nervous merging fixes when we don't understand the problem Sep 19 11:29:36 then apply only the first 2/3 to make it fail for people with same problem Sep 19 11:29:39 JaMa: e.g. Koen's error is in do_patch which your fix won't have any effect on Sep 19 11:30:16 instead of failing it later without any clue why it didn't fetch git repo Sep 19 11:30:26 JaMa: agreed, I'll merge that Sep 19 11:32:16 RP__: and is there any documentation how to set bitbake params to see ie debug from fetcher (multiple -v -D and -l settins didn't work for me) Sep 19 11:32:58 JaMa: bitbake -DDD should do so Sep 19 11:33:20 JaMa: debug should also always be written to the log files even if its not on stdout Sep 19 11:34:55 thanks Sep 19 11:35:32 I'll try to remove PATCH 3/3 from bitbake shiped in shr-chroot to see if every shr-chroot user will see it or no Sep 19 11:35:34 JaMa: Are you just seeing that error message on fetch commands or is in in other logs too (e.g. patch logs or unpack?) Sep 19 11:35:52 RP__: ie do_rootfs for sure Sep 19 11:36:20 JaMa: and 3/3 doesn't change that, right? Sep 19 11:36:21 RP__: because package_ipk.bbclass checks that log and rootfs fails because of those errors in log Sep 19 11:36:47 mmt I'll check, because now I have this removed from check_log (to get new images..) Sep 19 11:39:32 JaMa: and you're sure LD_LIBRAR_PATH is empty in your environment (no special gentoo libc++ search path or anything)? Sep 19 11:40:07 yes, before calling setup-env and after setup-env it's still empty Sep 19 11:41:04 and it seems that those errors are gone also from do_rootfs.. (after sep 16th) http://paste.pocoo.org/show/478452/ Sep 19 11:44:58 JaMa: When you say they're gone, you mean 3/3 removes them or they're just no longer there? Sep 19 11:47:14 I mean that they are gone since I'm using 3/3, but I'll recheck now without 3/3 Sep 19 12:05:54 JaMa: Failing all this could you try something that gives that error message with PSEUDO_DEBUG=4 set in the environment and also 'export PSEUDO_DEBUG=4' in local.con Sep 19 12:08:21 I'm trying to apply a patch to the linux-yocto kernel without success, could someone check that my patch is in the correct format? Sep 19 12:09:11 http://pastebin.archlinux.fr/434080 Sep 19 12:11:46 Snafflehog: at a quick glance nothing jumps out at me Sep 19 12:12:27 RP__: ok, will try Sep 19 12:12:28 ok, as I have had it confirmed that the patch works, however I cannot successfully apply it to the kernel using a custom layer Sep 19 12:12:39 RP__: do I need to add PSEUDO_DEBUG to BB_ENV_EXTRAWHITE ? Sep 19 12:14:52 it copies it to the work directory so it's picking up the layer and the bbappend, but it does not patch the kernel, so I was wondering if it was in the wrong format and patch was silently failing Sep 19 12:16:51 RP__: http://paste.pocoo.org/show/478472/ Sep 19 12:18:41 zeddii: Any comments for Snafflehog Sep 19 12:18:42 ? Sep 19 12:19:37 I've actually spoken to zeddii regarding this and he managed to get it working I believe, but I don't think he will be on for another hour or two due to time differences...? Sep 19 12:20:08 Snafflehog: Offhand I'm not sure whats needed there so you need to talk to zeddii, tomz1 or dvhart Sep 19 12:20:11 so I thought I would have another shot at it and see if I was doing something blatently wrong :/ Sep 19 12:20:20 Snafflehog: He should be around in an hour or two... Sep 19 12:20:26 RP__: and if I add LD_LIBRARY_PATH to BB_ENV_EXTRAWHITE then I get same error again: http://paste.pocoo.org/show/478473/ Sep 19 12:20:43 ok, i'll hold on and ping him when he emerges :) Sep 19 12:23:25 RP__: and with LD_LIBRARY_PATH in BB_ENV_EXTRAWHITE and also exported from fetcher I have both debug from pseudo and that ERROR message too, but this time not in output variable http://paste.pocoo.org/show/478475/ Sep 19 12:28:10 JaMa: I'm having trouble figuring this out :/. If you look in pseudo, there is pseudo_util.c which contains pseudo_setupenvp(). That is the one place LD_LIBRARY_PATH is manipulated. It might be worth adding some debug into that function and instrumenting why setting LD_LIBRBARY_PATH makes a difference Sep 19 12:28:50 (#define PRELINK_PATH "LD_LIBRARY_PATH") Sep 19 12:29:54 RP__: seems like adding LD_LIBRARY_PATH to BB_ENV_EXTRAWHITE is the easiest way to reproduce it Sep 19 12:33:07 RP__: strangly this also fails http://paste.pocoo.org/show/478480/ Sep 19 12:40:18 JaMa: I added LD_LIBRARY_PATH to BB_ENV_EXTRAWHITE here and it was fine :/ Sep 19 12:43:24 RP__: here it is with LD_DEBUG=all http://paste.pocoo.org/show/478484/ Sep 19 12:47:50 JaMa: That makes it pretty clear that its not got the right LD_LIBRARY_PATH set Sep 19 12:47:53 JaMa: search path=/lib64/tls/x86_64:/lib64/tls:/lib64/x86_64:/lib64:/usr/lib64/tls/x86_64:/usr/lib64/tls:/usr/lib64/x86_64:/usr/lib64 (system search path) Sep 19 12:48:16 pseudo is meant to add this back to the environment if it goes missing... Sep 19 12:49:58 yup.. I've 3 more logs with white/nowhite exported/not-exported if you want Sep 19 12:50:40 JaMa: do they all show the same thing - missing the pseudo paths in LD's search path? Sep 19 12:50:55 isn't bitbake overwritting LD_LIBRARY_PATH set by pseudo by "empty" value from env when LD_LIBRARY_PATH is in BB_ENV_EXTRAWHITE? Sep 19 12:51:30 RP__: except when it's exported by fetcher and when it's not in BB_ENV_EXTRAWHITE Sep 19 12:51:44 JaMa: If you look at the code in pseudo_util.c, it should append the right values to the end Sep 19 12:53:58 * zeddii is here. Sep 19 12:54:18 Snafflehog, I took your patch and your layer and it worked out of the box. so I can't reproduce your issue at the moment. Sep 19 12:55:08 RP__: ah and when it's white and also exported for fetche it shows this error, but not because of git or wc in that fetcher line, but because of "sh" Sep 19 12:55:24 I don't know what I'm doing wrong, how did you test for the availability of SPI? Sep 19 12:55:43 JaMa: could you run one of these logs under strace -f -s 2048 please? Sep 19 12:55:54 * RP__ is wondering what kind of exec call is being made Sep 19 12:56:02 I only did a basic boot test, but you were saying that the kernel wasn't even patching, so until you see the patch being applied there, I didn't go any further. Sep 19 12:56:02 RP__: log.ld.white.exported http://paste.pocoo.org/show/478489/, that's why I've seen this error, but not in output variable for fetcher Sep 19 12:56:12 I checked my kernel build and the patch is applied as I tried to patch it manually and it said it could because it was already applied Sep 19 12:56:43 aha. I thought you were still at the patching phase. you are talking runtime issues now. Sep 19 12:56:47 ah ok, well I'm pretty sure it is patching now but the /dev/spi nodes aren't being created Sep 19 12:57:16 sorry, I was having patching issues and now I'm past those, I misunderstood and thought you had seen the SPI device nodes registered Sep 19 12:57:45 now I can look deeper :) We Sep 19 12:57:55 We've got some gents around here I'll ping as well. Sep 19 12:58:05 ok, thank you :) Sep 19 13:00:54 RP__: 21M and uploading somewhere, mmt Sep 19 13:01:24 JaMa: Is that compressed? Sep 19 13:01:59 JaMa: I'm in China behind the firewall on hotel wifi so if not, I'd appreciate it if it was please :) Sep 19 13:05:50 RP__: 4MB gziped http://build.shr-project.org/tests/jama/log.strace.ld.white.not-exported.gz , enjoy China Sep 19 13:11:32 RP__: just noticed line: read(255, "export PATH=$OLDPATH\nif [ $needpseudo = \"1\" ]; then\n export PSEUDO_BUILD=2\n PSEUDOBINDIR=`cat $BUILDDIR/pseudodone`\n PSEUDO_BINDIR=$PSEUDOBINDIR PSEUDO_LIBDIR=$PSEUDOBINDIR/../lib/pseudo/lib PSEUDO_PREFIX=$PSEUDOBINDIR/../../ PSEUDO_DISABLED=1 $PSEUDOBINDIR/pseudo $BITBAKE $@\nelse\n export PSEUDO_BUILD=0\n $BITBAKE $@\nfi\nret=$?\nexit $ret\n", 2666) = 353 Sep 19 13:11:55 but in my case it should be lib64 Sep 19 13:12:04 http://paste.pocoo.org/show/478499/ Sep 19 13:12:18 JaMa: looks like its reading in from the environment scriot Sep 19 13:14:40 but even when I change PSEUDO_LIBDIR to point to existing lib64 it's the same error Sep 19 13:15:03 this line is from openembedded-core/scripts/bitbake Sep 19 13:15:36 JaMa: If I remember rightly pseudo can figure out the 64 bit for itself Sep 19 13:18:12 zeddii: looking a bit deeper it seems as though some of the pins may need to be altered in u-boot Sep 19 13:20:08 it seems these values need to be added to beagle.h : http://pastebin.com/VrT1XXYM Sep 19 13:20:21 aha. fairly typical with the handoff between uboot -> kernel Sep 19 13:20:31 * zeddii peeks Sep 19 13:21:35 aha. yes. We ended up with a mainline uboot tag for the beagleboard, worth digging to see if any version has that, or we really need to carry a patch for it. Sep 19 13:24:14 where would I start delving in uboot to find these alterations.. Sep 19 13:26:29 ah ok, maybe in u-boot-git/ Sep 19 13:27:15 Snafflehog, yes. we just build a u-boot tag. Sep 19 13:28:58 zeddii: so pull the u-boot git and then make a beagleboard-spi tag for example and with this apply certain settings? I'm not very experienced in all this :/ Sep 19 13:30:20 'depends'. I'm checking now. dvhart did the uboot leg work, so I'm finding the tag we used right now. If there was a newer uboot that had what you need, you'd just update the SRCREV in the recipes. if there isn't one, we can add a patch to the SRC_URI for the beagleboard. Sep 19 13:31:47 * zeddii fetches a coffee before he reads more code Sep 19 13:36:06 zeddii: http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=board/ti/beagle/beagle.h;h=18bfaa8deccecaa39d9ec104786772c87bbf31a1;hb=master Sep 19 13:37:07 that is the beagle.h file in u-boot git, the only reference I can find to the SPI pins are on line 273 & 236 Sep 19 13:38:11 ignore ^^ that was a blatent lie, there are loads of references to MCBSP* Sep 19 13:45:14 line 459 has the exact same pin config as the one in the pastebin - it looks like an fpga daughterboard uses SPI to talk to an FPGA, are each of those defines a tag as you call it? Sep 19 13:46:17 JaMa: Thanks for the logs. Reading through them I can't really make sense of why this is failing. I think some debug into pseudo itself is going to be needed. I am starting to suspect this is some whole in pseudo's wrapping of exec type syscalls though Sep 19 13:47:54 RP__: ok, thanks Sep 19 13:48:05 Snafflehog. the tag is just picking a git hash that is new enough (or old enough) to have the source changes that you need. if you are seeing what looks right in master (of uboot), then we should check that against the tag specified for the beagleboard. I'm having a peek at that shortly. Sep 19 13:49:48 zeddii: Well, it has a define on that part of code as #define MUX_KBADC_BEAGLEFPGA() so is there a way to call that in u-boot to set the pins using that define? Sep 19 13:56:47 not 100% sure. I'm only a medium grade uboot hacker. Checking upstream/ti references is where I start (and what I'm doing now, if only my external access wasn't so slow at the moment) Sep 19 14:00:10 right ok, I think I understand. The defines get attempted when a command line parameter is passed to u-boot. The define I pointed to was inreference to this add-on board: http://members.cox.net/ebrombaugh1/embedded/beagle/beagle_fpga.html which uses the spi4 device to control the FPGA Sep 19 14:00:41 the spi4 device is initialised in the patch that we were applying along with spi3.0 and spi3.1 Sep 19 14:02:01 the command line parameter is apparently 'buddy=beaglefpga' Sep 19 14:03:46 so 'supposedly' I would imagine applying the earlier patch and u-boot parameter buddy=beaglefpga would initialise the SPI4 device node, assuming that our git tag is recent enough to include the beaglefpga hash define Sep 19 14:07:33 * zeddii nods. it does look that way. the addon boards are always 'interesting' Sep 19 14:11:15 it is boot.scr which manages the uBoot parameters is it not? and that is not generated automatically is it? Sep 19 14:12:28 so to patch to enable SPI using a yocto feature we would need to patch in the SPI pin config to a define which is being called by default such as MUX_BEAGLE_XM()... Sep 19 14:18:37 we should ping dvhart if he ran into this. It is generated, and if we have conditional/optional addons, we somewhat need to get them properly generated. Sep 19 14:37:13 * dvhart looks up Sep 19 14:38:05 Snafflehog, instructions to generating boot.scr are in the README.hardware document under Beagleboard Sep 19 14:39:39 dvhart, yes I am currently trying a few methods to manually compile in the pin configuration to get the SPI output on the beagle working Sep 19 14:40:18 the u-boot command line parameter method is a touch dirty so I am looking at patching u-boot from a layer but with limited success Sep 19 14:40:31 I may just try and get it going with the u-boot parameter and work from there... Sep 19 14:51:52 dvhart: have you ever managed to get a beagle-xm to boot with an SPI interface even with my new modifications I cannot seems to get it going Sep 19 14:53:38 Snafflehog, I have not ever toyed with the SPI Sep 19 15:16:50 I'm trying to add a patch in for u-boot however it always complains it cannot find the patch, what directory should the patch be in, it currently resides in meta-custom/recipes-bsp/uboot/files Sep 19 15:17:09 Snafflehog, are you using bbappend? Sep 19 15:17:13 yes Sep 19 15:17:16 if so lean about that variable: Sep 19 15:18:40 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}" Sep 19 15:18:44 or somthing like that Sep 19 15:19:57 I've got FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}" and I've tried putting it in a folder called u-boot but it still doesn't pick it up, ${PN} refers to Package Name, right... Sep 19 15:20:57 my bad, my .bbappend had ILESEXTRAPATHS_prepend - missed off the F - no wonder I was getting confused! Sep 19 15:22:28 lol ok Sep 19 15:22:35 np Sep 19 15:54:54 to add a kernel config, I can just add a CONFIG_FOO_BAR=y to a .bbappend file right? Sep 19 16:16:55 Snafflehog: if that line appears in a .cfg file that you append to SRC_URI, yes Sep 19 16:17:12 yep, thats how I've done, cheers Sep 19 16:17:12 (I mean, append to SRC_URI within the bbappend) Sep 19 16:17:18 ^^ :) Sep 19 16:17:23 cool Sep 19 18:54:12 do rpm's get packaged up in sstate cache? Sep 19 18:55:28 should, yes Sep 19 18:56:39 yes they do.. sstatecache caches all of the deploy formats, the package data, and sysroot data.. Sep 19 18:56:45 (among other things) Sep 19 19:00:43 so if im seeing do_package_write_rpm tasks it's not hitting cache Sep 19 19:01:10 either it's not in the cache, somethign changed and it's decided the cache version isn't "correct".. or... Sep 19 19:01:27 you can look at your sstate directory, you should see things ending in "deploy-rpm...." Sep 19 19:03:46 well i see two copies in a lot of cases Sep 19 19:03:50 so it seems im not reusing Sep 19 19:04:40 does the autobuilder to any reporting on sstate cache? Sep 19 19:04:44 do any* Sep 19 19:07:23 I'm working on stuff right now using the sstate and rpm cache.. it is definitely reusing it here.. Sep 19 19:07:35 bitbake python resulted in: Sep 19 19:07:40 NOTE: Running task 821 of 822 (ID: 3, /home/mhatle/git/oss/oe-core/meta/recipes-devtools/python/python_2.6.6.bb, do_populate_sysroot) Sep 19 19:07:40 NOTE: package python-2.6.6-r2.9: task do_populate_sysroot: Started Sep 19 19:07:40 NOTE: package python-2.6.6-r2.9: task do_populate_sysroot: Succeeded Sep 19 19:07:40 NOTE: Running noexec task 822 of 822 (ID: 5, /home/mhatle/git/oss/oe-core/meta/recipes-devtools/python/python_2.6.6.bb, do_build) Sep 19 19:07:40 NOTE: Tasks Summary: Attempted 822 tasks of which 820 didn't need to be rerun and 0 failed. Sep 19 19:08:12 wait.. wrong window.. damn Sep 19 19:09:51 fray: im not surprised mine's not being used per say Sep 19 19:10:28 fray: i switched from ubuntu 10.04 to 11.04 - just trying to determine what's being reused Sep 19 19:10:48 that shouldn't affect the target package usage.. but would the sdk usage Sep 19 19:11:13 are you testing that specifically? Sep 19 19:11:33 no.. I'm working through some dependency problems.. so I keep erasing my tmp-eglibc directory... Sep 19 19:11:51 when this set is done, I can do that quick and capture the right log Sep 19 19:12:04 right now I'm regenerating all of the packages.. Sep 19 19:12:08 which is the right log? Sep 19 19:12:19 screen output for what it looks like when things are reused.. Sep 19 19:12:34 I'm not reusing them in the build thats taking allo fmy CPU time currently Sep 19 19:12:35 im in the process of doing some automated builds to test reusage Sep 19 19:12:55 which my method will probably be to scan sscache for multiple entries Sep 19 19:12:59 or changes from the original build Sep 19 19:14:25 im also trying to get sstate cache copied to a ubuntu-11.04 vm and it's taking a *long* time on a normal machine Sep 19 19:14:30 to do a build Sep 19 19:16:22 usually when that has happened to me it means I pointed the sstate directory to the wrong place.. Sep 19 19:16:27 I've done the same w/ the downloads directory.. ;) Sep 19 19:16:44 (BTW the downloads directory needs to be copied as well or it takes a long time to refetch everything to verify the checksums and such) Sep 19 19:16:59 im using the same sstate-cache and sources folder for all my builds Sep 19 19:19:54 and we def started off using them, because some things went lots faster Sep 19 19:23:44 generally if the compiler or libc change.. then everything else gets rebuilt.. Sep 19 19:24:02 we don't have a general way of saying "this change won't affect other packages" and "this change will affect all depenents" Sep 19 19:24:31 like the rpm-native change I made.. it affects the production of -all- packages.. but I have no way of signalling that dependency.. so I had to manually work on fixing sstate-cache Sep 19 19:29:00 fray: i was at least using the same version of poky Sep 19 19:29:14 :) Sep 19 20:00:41 so, git fetch is failing to fetch branches that are non fast-forwared causing -c fetch to fail once - but the second time it works Sep 19 20:00:58 i think we need a -f on the FETCHCMD_git Sep 19 20:25:38 ARGH.. baselib != baselib when multilib.conf is loaded on oe-core.. ARG Sep 19 20:25:42 now I have to rebuild everthing Sep 19 20:52:02 does anyone know if GIT_PROXY_IGNORE is working? **** ENDING LOGGING AT Tue Sep 20 02:59:56 2011