**** BEGIN LOGGING AT Mon Nov 14 02:59:57 2011 Nov 14 07:37:44 sgw: all thumb patches somehow lost the important part ARM_INSTRUCTION_SET = "arm" Nov 14 07:38:14 sgw: so your CONSOLIDATED PULL has only PR bumps while jansa/pull had ARM_INSTRUCTION_SET and PR bumps Nov 14 07:39:19 sgw: and subversion-native should work without adding it to ASSUME_PROVIDED :/ Nov 14 10:34:01 JaMa|off: The problem is that the alsa recipe has "libasound" hardcoded and nativesdk can't cope with that Nov 14 10:34:17 JaMa|off: We probably need to suffix the package like we do in libc :/ Nov 14 10:34:32 There is an open bug about using the way multilib works instead Nov 14 10:34:46 but that is a fairly big change nobody has had time for yet Nov 14 10:38:09 RP__: ok.. I know that if package has hardcoded PN in name then it's better to replace with ${PN} to make -nativesdk different package name, but wasn't sure about stuff like libasound Nov 14 10:38:41 RP__: so you want me to fix it in alsa recipe, not some bbclass generating suffixes to everypackage without one? Nov 14 10:41:25 something like http://paste.pocoo.org/show/507597/ Nov 14 10:50:39 JaMa|off: for now that is our only option Nov 14 10:50:58 JaMa|off: ultimately the multilib code will replace this Nov 14 11:47:32 heh not exactly like that :) multiple providers are available for runtime alsa-conf-base${PKGSUFFIX} (alsa-lib, alsa-lib-nativesdk) Nov 14 12:45:37 Is there I way for me to mangle rpath after binaries are buit? Nov 14 12:45:42 built, I meant Nov 14 12:45:56 I found relocable and this seems good for what I need Nov 14 12:46:06 but how I can call python code in do_install? Nov 14 13:37:40 RP__: ping Nov 14 13:59:50 dongxiao: pong Nov 14 14:00:19 otavio: you can't easily call bitbake python from shell Nov 14 14:00:41 RP__: I got it right; I fixed the chicken calls to the compiler Nov 14 14:00:44 RP__: :-) Nov 14 14:01:10 RP__: https://github.com/OSSystems/meta-chicken <= Up and running Nov 14 14:01:26 otavio: cool :) Nov 14 14:02:18 RP__: currently we calculate cache's validity from the time stamp of files. However if we support dynamically setting variable from GUI (HOB), we need other ways to validate cache. Nov 14 14:02:55 RP__: we're going to do some more tests and then we'll be annoucing it so others can use it as well Nov 14 14:03:03 RP__: thanks by your help :) Nov 14 14:03:12 dongxiao: the GUI (or better the access functions it would use) should take care of invalidating the appropriate pieces Nov 14 14:03:42 otavio: np, pleased you go it working :) Nov 14 14:04:16 RP__: one change I did onto our layer but I'd like to push is the support to BBCLASSEXTEND for cross class Nov 14 14:04:29 RP__: are you OK with me pushing a patch for review? Nov 14 14:04:51 RP__: same things as native ;) Nov 14 14:05:07 otavio: I can look at it certainly Nov 14 14:05:10 RP__: I need to use it a lot on chicken cross support Nov 14 14:05:13 RP__: good Nov 14 14:05:17 RP__: will post it soon Nov 14 14:05:24 otavio: changes like that to the core classes take longer to review though Nov 14 14:05:29 otavio: just by their nature Nov 14 14:05:51 RP__: can we use the approach of calculating configuration's key/value hash and add it to bb_cache.data? Then we can judge whether this cache file is associated with certain configurations. Nov 14 14:06:35 dongxiao: You mean just the key/values the UI is setting I assume? Nov 14 14:06:54 dongxiao: If so, yes, that would make a good key for the cache Nov 14 14:07:10 dongxiao: You could even inject that hash into the patch to the cache file Nov 14 14:07:15 like we do with MACHINE Nov 14 14:07:24 s/patch/path/ Nov 14 14:09:52 No, I mean all the key/value pairs of configuration, and calculate a whole hash value. My first implementation is to add the hash value as part of the cache file name, for example, bb_cache.dat.xxxxxxxxxx Nov 14 14:12:20 RP__: Even if users changed some variable configuration files, and the data cache associated with this kind of configuration does exist, then the parsing period can use the cache. Nov 14 14:13:18 dongxiao: I think its overcomplex to be honest Nov 14 14:13:44 dongxiao: The configuration data is not small and I think that hash computation will have too much overhead Nov 14 14:16:26 RP__: The data is about 250KB Nov 14 14:16:48 dongxiao: how long is it taking to iterate and checksum it? Nov 14 14:17:49 I didn't have the feeling for calculating the checksum, if you need the data, I can profile it. Nov 14 14:18:09 dongxiao: you already have the code for this? Nov 14 14:19:25 RP__: yes, an initial version Nov 14 14:20:19 RP__: I see but that specific change is harmless as no one uses it in core. But it would allow us to not duplicate the whole class. Besides it is the same thing done on other classes so seems to fit well. Nov 14 14:20:27 RP__: but I will send it. Np problem Nov 14 14:21:44 dongxiao: Thinking further, its probably a good idea Nov 14 14:22:02 dongxiao: I just worry about having two different ways of handling the cache validity Nov 14 14:22:50 (one for the base configuration and one for the recipes themselves) Nov 14 14:23:18 otavio: I don't like the fact we have so many cut and pastes of that code :( Nov 14 14:25:02 otavio: cross.bbclass is also very sensitive to ordering and the place its actually included (or always used to be) Nov 14 14:25:12 maybe as we've simplified things that has got better Nov 14 14:25:52 RP__: what I did is to add the bitbake handler, only. Nov 14 14:26:07 RP__: but this, without code duplication, I see no way to add Nov 14 14:26:34 RP__: only if we had a base handler that could accept parameters and we call it from the classes Nov 14 14:27:01 otavio: what makes you think we can't do that? Nov 14 14:27:32 RP__: we could have a base one, in base.bbclass, called by others Nov 14 14:27:41 otavio: yes, it will be harder but we probably need to do something like that before the code duplication gets out of control Nov 14 14:28:10 RP__: I can take a look on that after I finish the rest of product prototype Nov 14 14:28:19 otavio: ok Nov 14 14:28:29 RP__: probably will need your help for some details but I ask when need. np Nov 14 14:28:44 otavio: crosssdk is the one that could really use BBCLASSEXTEND support btw Nov 14 14:29:56 RP__: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dxu4/cache Nov 14 14:30:10 RP__: this is my initial implementation, not fully tested. Nov 14 14:30:49 RP__: this only implements the configuration's cache hash value. for bb file's cache, it still use the original validation method. Nov 14 14:31:20 dongxiao: right, you can't use any other approach for the bb file's cache :/ Nov 14 14:31:34 dongxiao: Please don't write to the file, then md5sum it Nov 14 14:32:25 dongxiao: See http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/tree/bitbake/lib/bb/siggen.py?h=dxu4/cache&id=e75206e6222a3e77dbab60be3a8ea5e394fc6742 _build_data for an example without a file Nov 14 14:33:25 RP__: Thanks, I will revise it. I am not satisfied with the get_hash() function myself. :( Nov 14 14:34:04 dongxiao: it also looks like you might be better off tweaking getCacheFile() to handle the hash internally Nov 14 14:36:08 dongxiao: I guess my only other worry about this is going to be an ever growing cache directory Nov 14 14:37:00 RP__: Yes, that's one defect potential... Nov 14 14:41:57 RP__: what about invalidating those caches that lives for a long time??? I can't think of other methods :( Nov 14 16:00:26 RP__: patch updated in http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dxu4/cache&id=98fa5d5887c93952cffd2906c0b235beb9636b16 Nov 14 16:29:32 dongxiao: much better than v1 :) Nov 14 16:29:42 dongxiao: I'm struggling to find a way to deal with old caches too :/ Nov 14 17:18:44 JaMa|off: ping Nov 14 17:25:29 sgw: pong Nov 14 17:26:15 JaMa|off: regarding the subversion changes, did you build a subversion-native? I also found problems with missing -native support. Nov 14 17:28:25 yes I'm always building subversion-native Nov 14 17:28:55 that's whole point of that base.bbclass change.. to make sure it's built soon enough before anything which is using svn:// Nov 14 17:29:35 because that was failing for people with subversion-1.6 on their hosts when I've switched buildhost to 1.7 and tarballed checkouts got incompatible with older svn Nov 14 17:30:28 and if you add it to ASSUME_PROVIDED then it will fail for them again (unless I revert such change in shr branch) Nov 14 17:32:19 -rw-r--r-- 1 bitbake bitbake 0 Nov 8 15:50 tmp-eglibc/stamps/x86_64-linux/subversion-native-1.7.0-r0.do_build Nov 14 17:32:51 JaMa|off: This is very strange then, when I build subversion-native, I am getting "Nothing PROVIDES" errors for libgcrypt-native from gnutls-native, not sure why we are not seeing this before. Nov 14 17:34:03 let me check if those are provided by meta-oe only Nov 14 17:34:43 hmm right ./meta-oe/recipes-support/libgcrypt/libgcrypt_1.5.0.bbappend Nov 14 17:34:50 BBCLASSEXTEND = "native" Nov 14 17:35:13 Ahh! I guess you did not test oe-core or poky? Nov 14 17:35:36 gnutls depends on libgcrypt Nov 14 17:35:48 so missing gnutls-native is probably because of that Nov 14 17:36:00 JaMa|off: I saw your email about your availability, but we need to have patches that are tested without meta-oe. Nov 14 17:36:26 and also libgpg-error possiby Nov 14 17:36:26 but gnutls has BBCLASSEXTEND = "native" in oe-core.. so I would expect that gnutls-native should work.. Nov 14 17:36:47 does it work for you if you try to build gnutls-native only? Nov 14 17:36:58 Yeah, that's what I was thinking also, need to see if it's pulled in truly by anything else. Nov 14 17:40:18 JaMa|off: it's pulled in a couple of different places as a native but I have not see this issue before, only with subversion. Nov 14 17:40:24 gnutls-native is there since Date: Thu Mar 24 10:36:12 2011 +0100 Nov 14 17:40:50 commit 073f162529e5b84f12d348ae49edccc377ec5f7e Nov 14 17:41:11 so I guess nobody tried to build gnutls-native without meta-oe since then Nov 14 17:42:08 JaMa|off: I guess, but gnutls gets pulled in by curl for rpm, so it would have had to be built unless we are getting some host contamination issues. Nov 14 17:43:20 curl: DEPENDS_virtclass-native = "zlib-native" Nov 14 17:43:39 CURLGNUTLS_virtclass-native = "--without-gnutls" Nov 14 17:43:43 so not pulled by curl Nov 14 17:44:46 can you please try to add native to BBCLASSEXTEND in libgcrypt and libgpg_error? Nov 14 17:44:52 JaMa|off: did not look deep enough obviously, surface level grep! So only neon then depends on native gnutls. Nov 14 17:45:03 both have it in meta-oe .bbappend and I guess it could be enought Nov 14 17:45:37 Yes, I will work that one. Nov 14 17:45:53 thanks Nov 14 17:57:31 sgw: btw if you end up with apr-util-native failing to find libtool you can try http://git.openembedded.org/openembedded-core-contrib/commit/?h=shr&id=601a1e9ea33b4ff0d87e9227d76c185701fcb068 Nov 14 17:58:07 sgw: but I don't know why some people doesn't have $(SHELL) prefix in LIBTOOL and some do.. Nov 14 17:58:20 so I didn't send this one yet Nov 14 18:01:01 Ok thanks. Nov 14 18:46:48 why does using the git fetcher require S = "${WORKDIR}/git" , but tarballs just unpack into the toplevel? Nov 14 18:47:06 hysterical raisins? Nov 14 18:48:58 hm, i guess in theory one can compose multiple tarballs that don't have conflicting files, but the .git directory can't be composed Nov 14 18:50:02 the two are entirely different. tarballs extract to WORKDIR because they create the S dir underneith it. that's the way it has to work, because as you say you can have any number of tarballs that unpack files directly or in any number of paths underneith it, it varies. we *should* provide a way to specify the destination dir of the git clone, though, or just be less stupid about the default destination. "git" is idiotic, at least use the bas Nov 14 18:50:08 heh Nov 14 18:51:44 ah, i see Nov 14 20:53:12 I've almost got everything working for sh4 that I need. I'm having a problem with 'meta-toolchain-sdk', though. Now that I've gotten all the packages to compile, I'm getting a wierd dependency error. http://pastebin.com/BT02UYk1 Nov 14 20:53:49 The libgupnp-1.0-3-0.16.1-r0.sh4 package is failing dependency checks on things like libc.so.6, which doesnt make any sense Nov 14 21:01:24 hi Nov 14 21:05:12 http://pastebin.com/BT02UYk1 <-- anybody have ideas why 'bitbake meta-toolchain-sdk' is failing with this? Nov 14 21:05:20 for sh4 port that I'm working on Nov 14 21:08:03 task-core-sdk works ok Nov 14 21:50:52 michael_e_brown, maybe it got built for the wrong architecture or something like that? Nov 14 22:14:27 walters, as far as I can tell, no Nov 14 22:14:36 file says that they are sh4 binaries Nov 14 22:18:34 ile usr/lib/libgupnp-1.0.so.3* Nov 14 22:18:34 usr/lib/libgupnp-1.0.so.3: symbolic link to `libgupnp-1.0.so.3.0.0' Nov 14 22:18:34 usr/lib/libgupnp-1.0.so.3.0.0: ELF 32-bit LSB shared object, Hitachi SH, version 1 (SYSV), stripped Nov 14 22:18:57 that's rpm2cpio of the libgupnp-1.0 rpm Nov 14 22:27:42 Can somebody tell me how I can disable GMAE from my builds? I dont need any of the gnome libraries, but anything above core pulls them in. Nov 14 22:37:58 zeddii, ping Nov 15 02:08:54 hm, does pseudo/bitbake have some magic to detect whether a task is writing files outside of where it should be? Nov 15 02:09:19 i'm trying to do something like what image.bbclass is, but i'm getting permission denied trying to write out to the deploy dir **** ENDING LOGGING AT Tue Nov 15 02:59:57 2011