**** BEGIN LOGGING AT Wed Nov 23 02:59:57 2011 Nov 23 07:23:07 evening all Nov 23 07:23:39 does anyone know, is there a way to get at the real TARGET_ARCH when building a -native recipe? Nov 23 07:24:09 eg, I'm building a recipe that generates a file for my i586 target, but I need to build that recipe natively Nov 23 08:24:22 dvhart: seems like you want something like what gcc-cross does Nov 23 08:24:40 its an x86 binary - but it lives in the TARGET_ARCH sysroot Nov 23 08:45:41 dvhart: in fact I think there is an issue with gcc-cross Nov 23 08:45:51 because it lives as a TARGET package Nov 23 08:46:10 attempts will be made to run a x86_64 on an x86 (32bit) Nov 23 10:26:02 sgw: pong Nov 23 10:26:11 sgw: I was out, sorry Nov 23 13:54:35 RP__: ping Nov 23 13:58:23 dongxiao: pong Nov 23 14:00:51 RP__: for the current hob, we could only launch the GUI after pseudo is built out. Do you have idea if we could also build pseudo in hob and use pseudo wrapper to build the following image in hob? Nov 23 14:01:29 dongxiao: ouch, that is a nasty dependency :/ Nov 23 14:01:46 dongxiao: The trouble is we have to have the preload around the bitbake server Nov 23 14:02:28 dongxiao: I think that is going to be a very hard problem to solve :( Nov 23 14:02:37 hmm...so it seems that it is a must to build pseudo-native before hob launch... Nov 23 14:02:55 dongxiao: or already have it in the environment prebuilt Nov 23 14:03:18 dongxiao: The UI itself doesn't require pseduo present but the server does Nov 23 14:05:08 dongxiao: If you were to code the UI to start the server itself and it was able to restart the server it could work Nov 23 14:05:36 RP__: yes, currently the GUI is launched by bitbake server Nov 23 14:07:01 RP__: I can investigate if we can launch the server in GUI. In that way, GUI is launched by its own command, not bitbake. Nov 23 14:07:02 dongxiao: it does mean when you restart the server, it loses all context though :/ Nov 23 14:07:44 dongxiao: I've wondered whether we could have bitbake "restart" itself internally before but the problem is all the lost context data Nov 23 14:09:25 RP__: the context lost issue may not be a big problem, and we can remember the local setting in GUI. Nov 23 14:14:43 RP__: also to split the frontend and backend, it is better to launch bitbake server via GUI, right? Nov 23 14:39:35 dongxiao: I don't quite follow your last question Nov 23 14:40:39 RP__: I mean currently the GUI is initiated by the bitbake command, but later, we may put the GUI in a different machine Nov 23 14:41:17 dongxiao: the multiple machine part is an additional set of complexity Nov 23 14:42:44 dongxiao: This all points to the pseudo problem being something we should solve in the server itself :/ Nov 23 14:43:21 RP__: so we need a bitbake "restart" mechanism? Nov 23 14:43:46 dongxiao: and/or some exec call within bitbake Nov 23 14:44:28 dongxiao: effectively between cooker and runqueue Nov 23 14:47:57 RP__: our hob is initiated by "bitbake -u" without pseudo wrapper, but later it will restart and launch with pseudo wrapper, so hob application will accordingly exit? Nov 23 15:04:38 dongxiao: doesn't it use the wrapper? Nov 23 16:48:07 bluelightning: are you available now? Nov 23 16:49:06 sgw: yep Nov 23 17:17:51 RP__: did you see my bitbake patch? Nov 23 17:18:31 RP__: i think it might help out with the overall goodness of the sstate-cache Nov 23 17:18:35 regarding the autobuilder issues Nov 23 17:20:52 msm: the siggen.py one? Nov 23 17:21:40 yea Nov 23 17:22:06 RP__: ^ Nov 23 17:23:36 msm: They look good to me, I'll merge them Nov 23 17:23:46 msm: not sure about the rpm xy fix though Nov 23 17:24:40 msm: Shouldn't we just disable xy in rpm? Nov 23 17:24:48 RP__: seems reasonable too Nov 23 17:24:59 RP__: can go that route - just reply to the patch Nov 23 17:25:07 and i'll resubmit Nov 23 17:25:09 msm: will do Nov 23 17:25:26 msm: was really just wondering if I was missing something Nov 23 18:01:12 sgw: wanted to talk to me? Nov 23 18:03:46 otavio: hi, just a ping on that debian script or a pointer or ... Nov 23 18:03:58 sgw: oh, right ... hold Nov 23 18:08:30 sgw: http://qa.debian.org/watch/sf.php/freerdp Nov 23 18:08:40 sgw: use http://qa.debian.org/watch/sf.php/ Nov 23 18:08:43 sgw: ;-) Nov 23 18:09:01 otavio: thanks! Nov 23 18:09:27 sgw: it has a pointer to the source code of it but I think you can just call it Nov 23 18:13:14 sgw: RP__: did you see the xorg fix? Nov 23 18:20:30 otavio: yes, we have been playing catchup, there is also Phil's comment, and changing common.inc affects both the core and -lite features, as you noted it used to be disabled in -lite, so you are changing the -lite behavior also Nov 23 18:25:53 sgw: I can send a new patch disabling it to lite then Nov 23 18:26:00 sgw: works for you? Nov 23 18:31:25 otavio: Let's see the overall patch. Nov 23 18:52:58 sgw: sent to ml Nov 23 19:03:12 otavio: got it Nov 23 19:14:44 sgw: good Nov 23 19:35:10 I have a patch here that makes file use binreloc to find the magic file relative to the libmagic location on linux systems, is this something someone would be interested in? it'd avoid the need to be passing -m to our file-native all the time Nov 23 19:35:24 if it'd be useful i'll prep it for oe-core Nov 23 19:36:26 (interestingly, they find it relative to the dll on windows systems in recent file versions, which is cool) Nov 23 20:12:32 kergoth: what would be extra requirement for this to work ? Nov 23 20:12:42 kergoth: would it work with all sort of distros Nov 23 20:13:18 no extra requirements, it patches the self contained .h/.c from binreloc in and links it into libmagic on linux systems Nov 23 20:13:38 uses proc maps for lib or proc/self/exe for apps to locate itself Nov 23 20:22:51 wont work on bsd and macos Nov 23 20:23:17 yep, its disabled there Nov 23 20:23:39 also uses $ORIGIN for linux, wasn't sure about its portability to the bsds Nov 23 20:28:19 its a start. I personally like the idea of getting more apps relocatable on their own, without use of wrapper scripts or a ton of exported env vars or the like Nov 23 20:28:36 somewhere I have patches for some of the autoconf/automake bits to do that Nov 23 21:24:54 kergoth: I agree we could do with getting better about the relocatability of binaries. I'm not familiar with binreloc but I'd be interested in understanding it Nov 23 21:30:16 RP__: it was created by the folks working on autopackage, back when that project existed Nov 23 21:30:19 heh Nov 23 21:32:52 https://github.com/shish/kuri2d/blob/master/src/binreloc.c - the one real downside to it is it doesn't handle non-standard paths. that is, it has hardcoded the relative paths between components (e.g. bin to lib) rather than calculating the relative paths. of course, the vast majority of the time that's okey Nov 23 22:25:44 kergoth: Looks interesting. Just thinking through how we could get upstreams to consider using something like this... Nov 23 23:00:37 * kergoth_ nods **** ENDING LOGGING AT Thu Nov 24 02:59:58 2011