**** BEGIN LOGGING AT Thu Sep 15 02:59:57 2011 Sep 15 09:16:36 morning all Sep 15 09:18:56 morning Sep 15 10:19:13 morning all Sep 15 10:25:19 hi RP__ Sep 15 10:25:47 the mailing lists are back :) Sep 15 10:25:56 RP__: any news on your email? Sep 15 10:27:22 bluelightning: I'm getting it forwarded but I've lost my imap account with the history in it Sep 15 10:27:38 RP__: ah right Sep 15 10:27:43 :( Sep 15 14:07:28 fray: morning & ping! Sep 15 14:09:49 zeddii, poke Sep 15 14:27:46 zeddii, did you have any luck yesterday with building the beagleboard SPI patch in a layer with the bbappend method? Sep 15 14:33:14 any hint for "ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored." ? seems like even fetcher2 cannot use git-native properly now Sep 15 14:33:29 Snafflehog, yes. I'm rebooting my machine, but will send more details shortly .. Sep 15 14:36:01 whole log.do_unpack http://paste.pocoo.org/show/476493/ and rebuilding git-native doesn't help.. Sep 15 14:37:28 and rebuilding pseudo-native doesn't help too Sep 15 14:41:41 JaMa|Off: Whilst they look scary, those "errors" are not usually errors Sep 15 14:42:35 RP__: but git repo is not updated.. that's error Sep 15 14:43:05 RP__: I have to go to downloads/git2/foo/ and do git remote update to fetch new remote revisions Sep 15 14:43:16 JaMa|Off: ok, that is an unrelated problem by the sounds of it Sep 15 14:43:27 JaMa|Off: "fatal: reference is not a tree: cc39c6a9bbdebfcf1a7dee64d83bf302bc38d941" looks like the error Sep 15 14:43:44 RP__: and every image is failing in check_log because package_ipk.bbclass scans for ERR.. for keyword_die in "exit 1" "Collected errors" ERR Fail Sep 15 14:44:08 RP__: this revision is in tree.. if only fetcher2 does git remote update Sep 15 14:44:41 JaMa|Off: I'm missing too much context to be able to accurately comment I guess :/ Sep 15 14:45:51 JaMa|Off: FWIW I'm not seeing those pseudo errors here either :/ Sep 15 14:46:24 JaMa seems to be saying that that reference isn't a tree because that object hasn't been fetched, so while that's the error, it isn't the root cause? *shrug*, just jumping in mid conversation Sep 15 14:46:26 I do see them only in last few days (and few other users too) Sep 15 14:46:45 maybe it's after http://git.openembedded.org/cgit.cgi/openembedded-core/commit/?id=72252799e8c51a633a231a2cd1fe797b7faae713 Sep 15 14:47:15 * kergoth wanders off to get breakfast Sep 15 14:47:26 JaMa|Off: Just to confirm this is latest bitbake, latest oe-core ? Sep 15 14:47:47 yes and yes Sep 15 14:48:18 JaMa|Off: standard environment setup script? Sep 15 14:51:00 JaMa|Off: is it possible this is due to kernel.org being down? Sep 15 14:52:18 no, this is repo on github Sep 15 14:52:25 mmt added some debug code to fetcher2 Sep 15 14:55:09 5 if not os.path.exists(ud.clonedir): Sep 15 14:55:09 logging.debug("GIT repository for %s does not exist in %s. \ Sep 15 14:55:20 ^^ seems like there is typo logging/logger Sep 15 14:59:57 JaMa|Off: ouch. Does that fix the problem? Sep 15 15:00:27 no.. just noticed it Sep 15 15:02:54 pseudo is real problem Sep 15 15:03:30 RP__: here is patch I've used http://paste.pocoo.org/show/476500/ Sep 15 15:03:53 and here is debug output http://paste.pocoo.org/show/476501/ Sep 15 15:04:17 btw logger.debug(1, "test") isn't shown even with bitbake -v -v -D -D Sep 15 15:06:54 so it thinks that rev is already there and doesn't fetch at all Sep 15 15:09:28 hmm not sure why 2> /dev/null didn't filter it before wc -l Sep 15 15:26:51 JaMa|Off: keep in mind these messages may be coming from different processes so the ordering may not be accurate Sep 15 15:27:22 JaMa|Off: So the revision isn't there? Sep 15 15:30:49 * fray grumbles about his boiler not working this morning.... stupid mechanical systems... Sep 15 15:34:06 JaMa|Off: What does the command show when you run it? (git log --pretty=oneline -n 1 cc39c6a9bbdebfcf1a7dee64d83bf302bc38d941) Sep 15 15:36:27 RP__: but that all ends in "output" variable Sep 15 15:36:49 JaMa|Off: after being piped to wc Sep 15 15:36:57 JaMa|Off: I wonder what it actually said Sep 15 15:37:40 JaMa|Off: Just trying to work backwards... Sep 15 15:42:19 RP__: the problem is parsing output variable Sep 15 15:42:21 return output.split()[0] != "0" Sep 15 15:43:02 returns true when first line says "ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored." Sep 15 15:43:10 and second line says "0" Sep 15 15:44:10 JaMa|Off: ah, right. This is starting to make more sense Sep 15 15:44:19 so wc -l is working fine -> "0" but runfetchcmd doing stdout_handle = os.popen(cmd + " 2>&1", "r") forces this error in output variable Sep 15 15:48:05 JaMa|Off: ok, so back to the question of those pseudo messages Sep 15 15:48:20 JaMa|Off: I'm not seeing them here which is puzzling Sep 15 15:48:33 JaMa|Off: are you on a 32 or 64 bit system? Sep 15 15:48:44 can't preload messages means only a couple of things.. 1) you are running an suid binary, which prevents preload.. Sep 15 15:48:57 2) the item being preloaded is for a different architecture/ABI Sep 15 15:49:04 3) the item simply doesn't exist Sep 15 15:49:13 on an IA platform, it's usually 2 or 3.. Sep 15 15:49:30 RP__: 64bit Sep 15 15:49:51 JaMa|Off: when pseudo built, did it build a 32 bit version to or did you disable that? Sep 15 15:49:53 2 is common if you have a mix of 32-bit and 64-bit host applications, but one have one version of pseudo built Sep 15 15:50:16 JaMa|Off: and do you have any 32 bit apps around? Sep 15 15:51:28 RP__: whatever pseudo-native defaults to and no 32 bit apps arround afaik Sep 15 15:51:35 RP__: it's minimal chroot environment Sep 15 15:51:57 you can even checkout it from http://git.shr-project.org/git/?p=shr-chroot.git;a=summary Sep 15 15:52:29 JaMa|Off: You're running in a chroot? Sep 15 15:52:51 and only 64bit version is built http://paste.pocoo.org/show/476517/ Sep 15 15:52:52 that may be part of the issue... if the chroot is doing something "strange" it may be preventing the wrapper from loading Sep 15 15:53:02 RP__: yes for last few years :) Sep 15 15:53:36 JaMa|Off: I'm trying to figure out what is different about what you're doing that might cause this Sep 15 15:54:02 1) are you root? Sep 15 15:54:06 2) are you running from within sudo? Sep 15 15:54:39 running from within sudo may be enough to cause the failure, as sudo prevents some preloads from occuring to avoid people dicking with root privileges Sep 15 15:55:40 RP__: I'm just trying to say that my env didn't change and those pseudo error messages are "new" ~ 1 week Sep 15 15:55:50 fray: no I'm user bitbake Sep 15 15:56:19 fray: but root did call chroot and then su - bitbake.. Sep 15 15:56:46 only thing I can suggest.. figure out what LD_PRELOAD is set to, and figure out if what it's pointing to exists or not Sep 15 15:56:54 and likely LD_LIBRARY_PATH Sep 15 15:56:59 but again I'm doing the same since oe-core beginning Sep 15 15:57:29 JaMa|Off: can you fill me in on the message - I just got on Sep 15 15:57:57 JaMa|Off: We did just change how some of the environment stuff works so perhaps somehow this has adversely affected the chroot Sep 15 16:01:45 | LD_PRELOAD='libpseudo.so' Sep 15 16:01:45 | LD_LIBRARY_PRELOAD='' Sep 15 16:02:47 fray: ^ Sep 15 16:03:38 JaMa|Off: LD_LIBRARY_PATH ? Sep 15 16:03:46 ah :/ Sep 15 16:04:36 | LD_PRELOAD='libpseudo.so' Sep 15 16:04:37 | LD_LIBRARY_PATH='/OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib:/OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64' Sep 15 16:05:47 JaMa|Off: and I assume one of those paths doesn't exist and the other is what you looked at in the pastebin above? Sep 15 16:06:34 OE om-gta02@shr ~/shr-core $ ls /OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib /OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64 Sep 15 16:06:37 ls: cannot access /OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib: No such file or directory Sep 15 16:06:40 /OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64: Sep 15 16:06:43 libpseudo.so Sep 15 16:06:46 first doesn't, 2nd is right Sep 15 16:06:59 sorry gtg now Sep 15 16:18:58 * fray is back Sep 15 16:19:05 I don't see anything obvious.. Sep 15 16:19:22 nothing has changed with the way pseudo itself works in quite a while.. Sep 15 16:19:48 so it's got to be something peripherial to that.. setup scripts, bitbake, environmental issues in the chroot.. not sure Sep 15 16:28:05 JaMa|Off, are you still there? Sep 15 16:28:56 what is PRINC? is it for increasing the main PR by its number Sep 15 16:29:02 like for instance: Sep 15 16:29:29 tslib_git.bb is PR=0 then in another upper layer you have PRINC=1 so PR becomes 1? Sep 15 16:30:23 ok it seem to be that Sep 15 16:44:41 GNUtoo|work: that's exactly it yes Sep 15 16:44:54 ok thanks a lot Sep 15 16:58:38 sgw: sorry, I see I missed one reference to task-core, thanks for fixing that... Sep 15 17:27:08 JaMa|Off: If you have a chance, try adding PSEUDO_DISABLED to the list of variables in exportvars in bitbake/lib/bb/fetch2/__init__.py. If that helps it would be a useful data point Sep 15 17:28:20 JaMa|Off: I'm wondering if you build from a relocated sstate pseudo package Sep 15 17:29:51 fray: In a cleaned environment I'm wondering if pseudo is having trouble rebuilding its context Sep 15 17:30:14 no idea.. :( Sep 15 17:31:39 JaMa|Off: FWIW I downloaded shr and tried a build and it all seems to be working for me so far... Sep 15 17:32:34 thats why I'm wondering if something on the host side of the chroot (not in the chroot) is preventing preloads suddenly Sep 15 17:33:21 usually handled as a security precaution.. Sep 15 17:33:33 any changes to app armour, selinux, etc on the host side? Sep 15 17:59:46 something changed in the last 45 hours in git that is causing bitbake to no longer be able to process a specific recipe Sep 15 17:59:57 nothing looks like it should be having this effect Sep 15 18:08:09 it appears to be from http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=04c66de8abfd820380fcfc2882b84650ac0220d5 Sep 15 18:08:56 which makes sense becuase my fail to parse recipe is using this... Sep 15 18:20:13 anyone notice bitbake just stops after trying to build the first set up packages for psuedo-native? Sep 15 18:21:02 if I run a bitbake rpm… it builds pseudo-native the stops - i have to run bitbake rpm again Sep 15 18:21:19 odd, no I've not seen that Sep 15 18:21:26 did something change in the wrapper recently? Sep 15 18:21:59 not sure Sep 15 18:23:24 its added to my list for now Sep 15 18:40:32 RP__: I've tried PSEUDO_DISABLED in exportvars before (and also LD_PRELOAD and LD_LIBRARY_PATH but without any noticable change (that error was still there) Sep 15 18:41:16 RP__: and pseudo-native was rebuilt here after cleansstate and I'm not using sstate from other machines (if that's what you mean by relocated sstate pseudo package) Sep 15 18:44:07 RP__: can it be somehow related to LD_LIBRARY_PATH in BB_ENV_EXTRAWHITE? about a month ago I was experiencing weird issues with libstdc++ (ie gperf-native wasn't able to find it when executed in build environment while calling it from normal shell worked fine) Sep 15 18:44:11 OE om-gta02@shr ~/shr-core $ ldd tmp/sysroots/x86_64-linux/usr/bin/gperf linux-vdso.so.1 => (0x00007fff789c5000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/libstdc++.so.6 (0x00007fcdaf417000) Sep 15 18:44:43 ya.. LD_LIBRARY_PATH is used for sure to find the preload of pseudo Sep 15 18:44:44 hmm Sep 15 18:45:03 so to work around such issue I've used LD_LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1 to be able to execute gperf ie while building udev Sep 15 18:45:46 that would do it.. Sep 15 18:45:56 use LD_LIBRARY_PATH=$LD_LIBRARY_PATH:....your new path.... Sep 15 18:46:00 but it's not set anymore (for few weeks) and pseudo was rebuild ie today.. so just in case it could be some dependency of something pulling it? Sep 15 18:46:11 I don't know then.. Sep 15 18:46:35 you can try running with strace or something and see if it's loading it right or not Sep 15 18:46:44 the other thing you can do is manually run pseudo and see if it works or fails Sep 15 18:46:55 and /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1 is normally listed in /etc/ld.so.conf.. Sep 15 18:46:57 simply run build/tmp/sysroot/.../bin/pseudo bash Sep 15 18:47:14 JaMa|Off if it has to be in ld.so.conf, your system is broken Sep 15 18:47:29 your system should be fully functional w/ an empty ld.so.conf Sep 15 18:47:37 (there are a lot of broken distros out there) Sep 15 18:47:39 it just shows pseudo: Warning: PSEUDO_PREFIX unset, defaulting to /OE/shr-core/tmp/sysroots/x86_64-linux/usr. Sep 15 18:48:01 and starts bash.. Sep 15 18:48:37 build/tmp/sysroot/.../bin/pseudo bash .... then run something like /bin/ls (be sure to use the fullpath) Sep 15 18:48:38 fray: this is gentoo and ld.so.conf is used ie by gcc-config to select which libstdc++ should be used by default.. Sep 15 18:49:04 that is majorly broken.. Sep 15 18:49:08 fray: /bin/ls works Sep 15 18:49:13 maybe the way they do it, but it's still broken Sep 15 18:50:10 then pseudo isn't the issue.. it's something "else" Sep 15 18:51:25 I'll experiment with pseudo a bit more tomorrow, but that "return output.split()[0] != "0"" in git.py:_contains_ref should be imho improved to detect such invalid outputs Sep 15 18:51:55 fray: well in normal shell I don't have LD_PRELOAD set at all Sep 15 18:52:11 run env.. yo do.. ;) Sep 15 18:52:22 as soon as you execute "pseudo" it's added to the environment and used Sep 15 18:53:17 I know, but "normal shell" I mean shell without pseudo Sep 15 18:53:45 [mhatle@msp-mhatle-lx2 tmp-eglibc]$ ./sysroots/x86_64-linux/usr/bin/pseudo bash Sep 15 18:53:50 LD_LIBRARY_PATH=/home/mhatle/git/oss/oe-core/build-x86_64/tmp-eglibc/sysroots/x86_64-linux/usr/lib/pseudo/lib:/home/mhatle/git/oss/oe-core/build-x86_64/tmp-eglibc/sysroots/x86_64-linux/usr/lib/pseudo/lib64 Sep 15 18:53:50 LD_PRELOAD=libpseudo.so Sep 15 18:53:52 thats what I get Sep 15 18:57:44 fray: similar here, sorry gtg, thanks Sep 15 22:58:00 damnit, I keep running into builds where pseudo didn't do its job, inexplicably Sep 15 23:28:51 fray: ping **** ENDING LOGGING AT Fri Sep 16 02:59:56 2011