**** BEGIN LOGGING AT Sun Jul 25 02:59:57 2010 **** ENDING LOGGING AT Sun Jul 25 05:13:48 2010 **** BEGIN LOGGING AT Sun Jul 25 05:16:15 2010 **** BEGIN LOGGING AT Sun Jul 25 10:36:14 2010 Jul 25 10:45:06 jay7 lol yes Jul 25 10:45:26 didnt you know that? Jul 25 10:45:42 poky is rp baby Jul 25 10:46:15 woglinde_: hm.. that is good :) Jul 25 10:46:56 I know about poky but didn't look in o-hand's svn before Jul 25 10:47:15 hm isn't git now? Jul 25 10:47:27 and o-hand was bought by intel some times agao Jul 25 10:47:35 at least psplash is in svn Jul 25 11:34:48 is there any way to check if my QT app (based on qt4x11 class) was build using debug or relase mode? I am not very good in tracking what OE really does with it... Jul 25 11:35:37 the problem is, that it performs quite shitty, and I hope it is because of not using -o2 switch Jul 25 11:35:48 but i can not proove it :] Jul 25 12:15:51 ok. i helped myself out with "-v -DD", and it seems, that it is compiled as i want it - with -O2, and without debugs. it seems that i'll have to rethink my application, to make it perform better ;] Jul 25 13:51:32 03Michael Kurz  07org.openembedded.dev * r7b5228d350 10openembedded.git/recipes/freesmartphone/ (10 files): Jul 25 13:51:32 freesmartphone: bump SRCREV and sync PVs with upstream Jul 25 13:51:32 Signed-off-by: Michael Kurz Jul 25 14:43:40 nazgee: you can also look into your workdir for the recipe and in temp/ it stores logs of bitbake passes Jul 25 14:50:27 03Khem Raj  07org.openembedded.dev * r48724742e8 10openembedded.git/recipes/proxy-libintl/ (2 files in 2 dirs): Jul 25 14:50:27 proxy-libintl: Eliminate the compile rule in makefile Jul 25 14:50:27 * This rule is not needed because we do not pass correct Jul 25 14:50:27 CFLAGS so on architectures where PIC really matters it Jul 25 14:50:27 does not work. Therefore make is more consistent and let Jul 25 14:50:27 -shared decide what flag to use for PIC'ness Jul 25 14:50:28 Signed-off-by: Khem Raj Jul 25 14:50:36 03Khem Raj  07org.openembedded.dev * re895bc3e7f 10openembedded.git/conf/bitbake.conf: Jul 25 14:50:36 bitbake.conf: Add thumb-interwork to DISTRO_FEATURES if machine supports it. Jul 25 14:50:36 Signed-off-by: Khem Raj Jul 25 15:23:55 morning all Jul 25 15:25:16 hi RP Jul 25 15:29:50 RP: hi Jul 25 15:55:41 re Jul 25 16:05:01 RP, I was peeking at poky cpan.bbclass to see how it differs from what I cooked up for oe; I saw that you changed oe_runmake install_vendor and added DESTDIR=${D} to make it oe_runmake DESTDIR="${D}" install_vendor Jul 25 16:05:21 why is this? was this an omission on the original line? Jul 25 16:05:50 (actually I didn't add that DESTDIR line, and all seems to work nicely) Jul 25 16:35:01 Disconnecting: Timeout, server not responding.B | 1.77 MiB/s Jul 25 16:35:02 fatal: The remote end hung up unexpectedly Jul 25 16:35:02 fatal: early EOF Jul 25 16:35:02 fatal: index-pack failed Jul 25 16:35:04 hmm. Jul 25 16:35:20 still problems on the git server? Jul 25 16:35:27 uh I hope not again Jul 25 16:35:47 * kergoth checks from a different box Jul 25 16:36:04 okay, fine there, guess its just that machine Jul 25 16:36:05 weird. Jul 25 16:46:14 okay Jul 25 17:03:15 03Chris Larson  07org.openembedded.dev * r8b36d25b13 10openembedded.git/recipes/ncurses/ncurses.inc: Jul 25 17:03:15 ncurses: don't rely on bitbake's expansion of undefined variables behavior Jul 25 17:03:15 Signed-off-by: Chris Larson Jul 25 17:03:26 03Chris Larson  07org.openembedded.dev * r8df384ecb0 10openembedded.git/recipes/ncurses/ncurses.inc: Jul 25 17:03:26 ncurses: make certain that the rxvt-unicode dir exists Jul 25 17:03:26 Signed-off-by: Chris Larson Jul 25 17:03:27 03Chris Larson  07org.openembedded.dev * rda26c362b6 10openembedded.git/recipes/ (ncurses/ncurses.inc ncurses/ncurses_5.4.bb zlib/zlib.inc): Jul 25 17:03:27 Work around ncurses-sdk & zlib-sdk build failures on CentOS 5.4 Jul 25 17:03:28 The issue here is that we're building ncurses with HOST==BUILD!=TARGET, Jul 25 17:03:28 aka 'cross', yet we're applying a CFLAGS override based on the target, not Jul 25 17:03:29 the host, which results in passing -fforward-propagate to the build Jul 25 17:03:38 machine's gcc, which isn't supported in older versions. Jul 25 17:03:38 Signed-off-by: Chris Larson Jul 25 17:37:11 can someone explain the purpose of ncurses-sdk? Jul 25 17:37:21 no Jul 25 17:37:23 it's being built for the build machine, not the target Jul 25 17:37:25 which is pointless Jul 25 17:37:31 ncurses-native only exists to provide 'tic' to ncurses Jul 25 17:37:35 for the cross build Jul 25 17:56:32 huhu Jul 25 17:57:08 hi Jin^eLD> Jul 25 17:57:59 playing around with gettext on an OE based image... gettext seems to ignore TEXTDOMAINDIR variable setting completely, any clues? anything I maybe missed to install? Jul 25 17:58:42 03Khem Raj  07org.openembedded.dev * rfd0c0ca6d5 10openembedded.git/recipes/proxy-libintl/ (2 files in 2 dirs): Jul 25 17:58:42 proxy-libintl: Fix soname.patch to include the funtions from libintl.c Jul 25 17:58:42 Signed-off-by: Khem Raj Jul 25 18:05:26 RP: hey Jul 25 18:17:16 kergoth: around ? Jul 25 18:17:45 kergoth: need to brainstorm this triplet stuff Jul 25 18:18:11 kergoth: we have so much confusion in bitbake.conf and cross*.bbclasses Jul 25 18:20:15 I understand cross.bbclass and its purpose but not so much about cross-canadian.bbclass anf crosssdk.bbclass Jul 25 18:21:03 isn't crosssdk just cross+sdk? same for nativesdk.. they need to be in one class for use with BBCLASSEXTEND Jul 25 18:21:18 no idea on teh canadian stuff, i haven't looked at that at all Jul 25 18:21:23 * kergoth shrugs Jul 25 18:21:37 and then MULTIMACH stuff Jul 25 18:22:17 MULTIMACH was added after I left the project for those years Jul 25 18:22:21 heh Jul 25 18:22:59 kergoth: crosssdk means we want to build a SDK on build sys say x86 and it will run on say x86 and produce code for arm Jul 25 18:23:34 right Jul 25 18:23:41 it's a cross tool installed into the sdk Jul 25 18:23:44 whtat is SDK_ARCH Jul 25 18:23:57 no idea :) Jul 25 18:24:07 we have so many arches Jul 25 18:24:24 where we should only have had BUILD HOST and TARGET Jul 25 18:24:31 there is no end to these Jul 25 18:24:57 TARGET_ARCH = "${SDK_ARCH}" Jul 25 18:24:59 that's all we had in the beginning, plus the list of package archs for opkg Jul 25 18:25:04 is crosssdk.bbclass Jul 25 18:25:21 so I guess SDK_ARCH is some sort of TARGET Jul 25 18:25:32 maybe someone builds canadian toolchains in the sdk? I dunno Jul 25 18:25:36 kergoth: seriously we need to clean it up Jul 25 18:25:49 well, we need to go back and re-discover why each was added Jul 25 18:26:05 its too easy to start removing things and get bitten later by complexities we didn't anticipate Jul 25 18:26:30 right Jul 25 18:26:30 I mean, the stuff wasn't added for no reason, we just need to examine the reasoning Jul 25 18:26:37 see if its really needed or not Jul 25 18:28:22 in cross-canadian.bbclass HOST_ARCH = "${SDK_ARCH}" Jul 25 18:28:45 when doing canadian, build!=host!=target, which hurts my head :) Jul 25 18:29:07 I think that if someone wants to build a toolchain/SDK on x86 which would run on x86_64 and produce code for arm Jul 25 18:29:44 it's a valid thing to want to do, particularly if you wanted to use OE to produce a mingw32->arm sdk or something Jul 25 18:29:55 yes I agree Jul 25 18:30:14 but its can be less convoluted Jul 25 18:30:17 to have it Jul 25 18:30:39 kergoth: nativesdk means SDK on device ? Jul 25 18:30:51 no Jul 25 18:31:00 it's for adding build machine binaries to the sdk you're producing Jul 25 18:31:06 i.e. native.bbclass -> sdk Jul 25 18:31:12 afaik, anyway Jul 25 18:31:22 nativesdk, crosssdk, sdk covers all 3 types of builds into your sdk Jul 25 18:31:45 oh so you mean you want to say package your own version of gmp-native with SDK Jul 25 18:31:51 then you would use nativesdk Jul 25 18:31:55 right Jul 25 18:32:28 in that case itd likely only be pulled in because you want to supply some native tool that depends on gmp, and don't want to rely on the user having it Jul 25 18:32:40 or whatever Jul 25 18:32:45 and some recipes are called *-sdk Jul 25 18:33:05 they should be replaced with BBCLASSEXTEB = "nativesdk" then right Jul 25 18:33:30 not sure, think it depends Jul 25 18:33:43 on why its wanted in the sdk Jul 25 18:34:28 we have libtool = thats for target, libtool-cross= thats clear Jul 25 18:34:54 then we have libtool-native = thats for lame build machines which dont have good libtool Jul 25 18:35:00 then we have libtool-sdk Jul 25 18:35:36 in that case yeah there'd be no point having the target one in the sdk, what good would that do :) Jul 25 18:35:41 so I guess libtool-sdk is libtool-cross shipping with SDK Jul 25 18:35:46 * kergoth nods Jul 25 18:35:57 so that should be replaced iwth crosssdk usage i'd guess Jul 25 18:36:24 I assume this is some sort of a transition that hasn't been completed Jul 25 18:36:29 ah crosssdk = crosstools shipped in SDK and nativesdk= native tools shipped with SDK Jul 25 18:36:33 right Jul 25 18:36:40 thats my understanding of it anyway Jul 25 18:36:53 so just 'sdk' should be target in the sdk, which only really makes sense for libraries Jul 25 18:36:59 for they can link their apps against it Jul 25 18:37:01 s/^fo/so/ Jul 25 18:37:07 s/^sor/so/ Jul 25 18:37:10 hehe Jul 25 18:37:23 but targetsdk is redundant isnt it Jul 25 18:37:46 we can simply add those libraries in task dependencies Jul 25 18:37:56 would think just 'sdk' would be that, but I guess its arguable what you want to name it, in concept its target sdk Jul 25 18:37:58 for say meta-toolchain Jul 25 18:38:12 true Jul 25 18:38:14 right sdk = targetsdk Jul 25 18:38:20 as of now isnt it ? Jul 25 18:38:54 I think so. You're right though in that its likely unnecessary, no reason you can't just take target packages and shove them into the sdk... I dunno, I haven't read up on how meta-toolchain & co work Jul 25 18:39:06 I assume it just does a bunch of opkg installs and creates the env setup script Jul 25 18:39:24 did crosssdk and nativesdk come from poky? Jul 25 18:39:29 yeah Jul 25 18:39:42 we also have sdk.bbclass Jul 25 18:39:45 so they got pulled over, but we haven't switched to really using them yet Jul 25 18:39:56 entirely, anyway Jul 25 18:40:19 * kergoth thinks the number of classes in classes/ is getting crazy Jul 25 18:40:41 yeah some of the classes are not used anymore Jul 25 18:41:10 We should really create / enhance bitdoc to generate docs from comments like doxygen from metadata Jul 25 18:41:16 make it a lot easier to make sense of them Jul 25 18:41:20 comment the files Jul 25 18:41:24 heh Jul 25 18:42:05 so I wonder if sdk.bbclass can go away eventually then, if its just a remnant of the old way, or what Jul 25 18:42:19 hmmm sdk.bbclass does a lot more Jul 25 18:42:27 hmm Jul 25 18:42:48 maybe check poky's commits Jul 25 18:42:53 it appends -sdk to couple of other variables Jul 25 18:44:08 * kergoth wanders off for a while, not feeling well Jul 25 19:09:05 kergoth: khem, there are also some classes that seem to be used by only one package (e.g. chicken.bbclass is only included by chicken.inc) Jul 25 19:09:29 I'd say that something should be a class if it applies to more than one package Jul 25 19:13:05 well, if its a type of buildsystem that's used by multiple projects, even if only one of those projects is in OE, i'd say keep it as a class, but in the case you describe yeah that sounds silly Jul 25 19:39:48 btw do_setscene gives me a page full of paths when the package was not installed before Jul 25 19:41:08 khem, short Q: I've been working at doing the Makefile.in patch in gcc for TARGET_INCLUDES (for crtstuff to eliminate ${GMPINC} for gcc 4.[2345]*, issue I have is that 4.2.1 does not have an INC_PR Jul 25 19:41:28 ok add it Jul 25 19:41:35 ok, will do Jul 25 19:43:25 khem should INC_PR start with the highest value that PR has ? otherwise I guess PR will win from INC_PR.0 Jul 25 19:45:48 yes Jul 25 19:48:35 ok Jul 25 19:59:17 khem, hi Jul 25 19:59:21 I've a working build Jul 25 19:59:26 shr-image built with success Jul 25 19:59:30 ok nice Jul 25 19:59:54 fighting with PSM on the dream...again... Jul 25 20:03:59 PSM? Jul 25 20:10:52 hi all Jul 25 20:16:30 Physic Spaghetti Monster? Jul 25 20:19:48 khem, pushed for patches with the Makefile.in fix (for gcc 4.2* 4.3* 4.4* and 4.5) Jul 25 20:20:12 * Jay7 have merged new kexecboot GUI to master branch.. Jul 25 20:20:47 khem, all tested with bitbake -c configure except 4.5 where I only could do -c patch (which succeeded) (configure failed there because some libs on my system were too old for 4.5) Jul 25 20:22:10 k Jul 25 20:27:27 khem, sorry, misphrased it, didn't push, did send to the ML, please have a look and ack if ok (or push yourself, whatever you prefer) Jul 25 20:28:20 gone for today Jul 25 20:28:43 re Jul 25 20:31:58 florian: good evening Jul 25 22:24:35 khem: fwiw I built for armv5te and armv4 with no apparent build-issues Jul 25 22:25:24 with the patches *before* 0001-machines-Add-new-variable-TARGET_SUB_ARCH.patch Jul 25 22:25:58 I just built console-image, opie-image and x11-image Jul 26 00:22:41 hmm, anyone else having libwmf build issues? **** ENDING LOGGING AT Mon Jul 26 00:24:03 2010 **** BEGIN LOGGING AT Mon Jul 26 00:26:16 2010 **** ENDING LOGGING AT Mon Jul 26 00:26:22 2010 **** BEGIN LOGGING AT Mon Jul 26 00:28:15 2010 **** ENDING LOGGING AT Mon Jul 26 02:59:57 2010