**** BEGIN LOGGING AT Sat Mar 06 02:59:57 2010 Mar 06 05:46:41 james_l: what did you do? Mar 06 05:46:58 james_l: last commit was to remove it from gtk+-native Mar 06 05:47:09 james_l: and commit before that was to enable it for all gtk+ Mar 06 05:47:43 james_l: it still fails for me, so I'm curious how you fixed that Mar 06 11:45:21 mickeyl: good morning Mar 06 11:47:37 good morning pb__ Mar 06 12:16:52 is it possible to get a list of the packages which can be installed using bitbake? Mar 06 12:17:17 ls recipes/ Mar 06 12:18:22 ah, thanks! Mar 06 12:26:57 pb__: could you take a look at JaMa's gtk problem, please? Mar 06 12:27:07 it's bailing out here as well Mar 06 12:27:32 | no --raw --build-list \ Mar 06 12:27:32 | apple_red ./apple-red.png \ Mar 06 12:27:32 | gnome_foot ./gnome-foot.png \ Mar 06 12:27:32 | > test-inline-pixbufs.h \ Mar 06 12:27:32 | || (rm -f test-inline-pixbufs.h && false) Mar 06 12:27:33 | /bin/sh: no: command not found Mar 06 12:27:35 | make[2]: *** [test-inline-pixbufs.h] Error 1 Mar 06 12:33:57 yeah, I'll have a look at that in a moment. clearly "no" is not a sensible setting for gdk-pixbuf-csource. :-} Mar 06 12:35:59 mickeyl: does it work if you build gdk-pixbuf-csource-native first? might be that it just needs an extra DEPENDS. Mar 06 12:36:27 let me check Mar 06 12:37:14 it seems to be using /usr/bin/gdk-pixbuf-csource for me, doh. Mar 06 12:37:20 hehe Mar 06 12:37:23 pb__: if gdk-pixbuf-csource-native is built before than it fails that .png is unknown format.. Mar 06 12:37:49 ah, so gdk-pixbuf-csource-native is just broken? Mar 06 12:37:58 that is a bit sad, but I guess it wouldn't be that hard to fix Mar 06 12:38:57 pb__: gdk-pixbuf-csource-native overwrites ie gtk-2.0.pc in staging and breaks everything depending on gtk+-native (old bug #5405) Mar 06 12:39:31 pb__: when it's built in different order, than gtk+-native overwrites .so files for image loaders Mar 06 12:39:48 pb__: and then gdk-pixbuf-csource-native fails with unrecognized format Mar 06 12:41:17 pb__: that's why I proposed to add "find ${D}${libdir} -name "libpixbufloader-*.so" -exec rm \{\} \; " in gtk+-native.. but I know very litle about gtk/gdk.. so I don't see why cannot be gdk-pixbuf-csource-native replaced with gtk+-native Mar 06 12:41:24 so, does gtk+-native ship a copy of gdk-pixbuf-csource? Mar 06 12:41:31 if it does then it might be easiest to simply use that. Mar 06 12:41:56 yeah, gtk+-native should become the new provider Mar 06 12:42:01 from what you have said, the gdk-pixbuf-csource-native recipe clearly is just broken and it might be easier to delete it than fix it. Mar 06 12:43:04 it is possibly a bit of a shame to have to build the whole of gtk+ and its own dependency stack in order to generate pixbuf sources, but I guess this is not the end of the world. Mar 06 12:43:49 pb__: yes it ships and then it removes compiled binary in do_install_virtclass-native Mar 06 12:44:50 so I expected that you or koen or someone knows the reason why it was removed in first place :) Mar 06 12:45:08 ah. that just seems silly. Mar 06 12:45:30 I think that whole do_install_virtclass-native() is bogus and should be deleted. Mar 06 12:45:37 I suspect gtk+-native just needs to not --disable-modules and gdk-pixbuf-csource can die Mar 06 12:47:28 hmm Mar 06 12:47:52 as the author of gdk-pixbuf-csource-native i recall that there was a special reason for me not just depending on gtk-native Mar 06 12:48:03 mickeyl: it didnt exist Mar 06 12:48:03 but as a matter of fact, this is a couple of years ago and I can no longer recall Mar 06 12:48:41 mickeyl: gtk+-native is fairly new, it could be that you just didn't have it then, and/or viewed (correctly) the prospect of building the entirety of gtk+ just for one tiny program with fear and loathing Mar 06 12:49:45 pb__: ok, XorA is correct then Mar 06 12:50:08 i don't mind building a lot of native stuff Mar 06 12:50:22 i often build a whole X stack without needing it ;) Mar 06 12:50:23 gtk+-native was needed when gnome because recursive Mar 06 12:50:29 yeah, I think it probably is the right answer in this case. Mar 06 12:50:42 s/bacause/became/ Mar 06 12:50:50 it looks like disentangling gdk-pixbuf-csource reliably from gtk+ will be more hassle than it is worth. Mar 06 12:51:03 and doubly so if we end up with different behaviour for native and non-native. Mar 06 12:51:48 yeah Mar 06 12:52:06 I think the only two reasonable approaches are either: (a) make gdk-pixbuf-csource a first class recipe, i.e. build it for both target and native, and patch gtk+ (again for both target and native) to use it rather than building another copy; or (b) ditch gdk-pixbuf-source as a standalone recipe, and just let gtk+ ship it as it evidently wants to do. Mar 06 12:52:18 of those, (b) seems like it must be the path of least resistance Mar 06 12:54:06 * XorA laughs that (b) is a beer in his client Mar 06 12:55:57 :) Mar 06 12:56:09 I guess thats the MSN smileys invading Mar 06 12:57:57 heh Mar 06 12:58:34 hm, what's going on here? I did "bitbake gtk+-native" and all of a sudden it is building eglibc Mar 06 12:58:37 * pb__ stabs bitbake Mar 06 12:59:31 * mwester watches bitbake bleed on the floor :( Mar 06 12:59:53 actually, that was a bit harsh, I don't suppose it is bitbake's fault Mar 06 13:00:22 still seems a bit undesirable, but I guess I will let it run Mar 06 13:01:01 something seems to have gone wrong with the virtual/libc providers, mine is trying to build external-toolchain-csl Mar 06 13:01:11 on a completely unrelated subject, does anybody have experience with the NXP LPC17xx range of cortex-m3 microcontrollers, Mar 06 13:01:15 ? Mar 06 13:01:41 * mwester goes off to start a clean build to see if things are still working this week. :) Mar 06 13:47:44 hrmm, the bitrot in gtk+ runs deep Mar 06 13:53:15 ERROR: 'STAMP' while parsing /home/pb/oe/org.openembedded.dev/recipes/ntop/ntop_3.0.bb Mar 06 13:53:17 eh, what? Mar 06 13:53:22 * pb__ stabs bitbake again Mar 06 13:53:47 * mwester steals bitbake's wallet while it writhes on the sidewalk Mar 06 13:54:01 Sorry - been in Chicago too long, I fear... :( Mar 06 14:02:08 ahah Mar 06 14:02:28 JaMa: if I send you a diff could you clean and verify for gtk+? Mar 06 14:02:41 * XorA needs to get on with server configuring Mar 06 15:29:36 re-morn Mar 06 15:47:00 XorA: I can clean/verify patch if the offer is still valid :) Mar 06 15:47:11 JaMa: it is, otherwise it will be days Mar 06 15:47:23 JaMa: where can I mail it Mar 06 16:57:09 morning kergoth Mar 06 17:09:03 hi pb Mar 06 17:19:06 hi woglinde_ Mar 06 17:19:26 XorA, JaMa|Off: did you sort out the gtk+ thing, or do you want me to look at it? Mar 06 17:19:35 hi pb_ Mar 06 17:20:01 hi ant__ Mar 06 17:21:23 pb_: I sent patch that works for me to Jama, its quite simple I think, I just need to work on IT stuff today/tomorrow Mar 06 17:21:39 righto Mar 06 17:21:54 maybe you would like to send your patch to the list as well in case anybody else is having the same problem Mar 06 17:22:10 *g* Mar 06 17:22:29 pb__: was hoping JaMa|Off could verify, Im working remotely to my build box and not really concentrating at moment Mar 06 17:22:40 enterprise Java stuff that earns my $$$ going on Mar 06 17:23:52 okay, fair enough Mar 06 17:24:08 java breaks my brain :-( Mar 06 17:28:04 and with that I give up and go home Mar 06 17:29:23 xora should use spring Mar 06 17:29:26 *g* Mar 06 18:06:45 Question: Can OE in some way help me to compile a list/document of the GPL:d projects used in my product? Mar 06 18:22:12 where/how is virtual mapping done: I get Mar 06 18:22:13 ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'virtual/arm-oe-linux-gnueabi-gcc-3.3.3' but it wasn't found in any PACKAGE or RPROVIDES variables Mar 06 18:22:13 NOTE: Runtime target 'virtual/arm-oe-linux-gnueabi-gcc-3.3.3' is unbuildable, removing... Mar 06 18:22:13 Missing or unbuildable dependency chain was: ['virtual/arm-oe-linux-gnueabi-gcc-3.3.3'] Mar 06 18:23:03 but a grep -r of 3.3.3 in my tree does not reveal anything (I've removed gcc-3.3.3 as being legacy) Mar 06 18:23:39 So Mar 06 18:23:45 That sounds like KERNEL_CC_SUFFIX or so Mar 06 18:25:42 evening Mar 06 18:26:09 ah, yea, saw a KERNEL_CC_SUFFIX didn't realize it was gcc related until you mentioned it Mar 06 18:26:12 Tartarus: thansk Mar 06 18:26:20 I'm having some issues with narcissus. Yeah, it looks fool-resistant, but still :) Mar 06 18:27:32 zub: narcissus != oe Mar 06 18:27:37 uh, ok Mar 06 18:27:56 zub suggest #angstrom or #beagle (if you have a beagleboard) Mar 06 18:28:02 thanks Mar 06 18:28:07 yw Mar 06 19:23:09 can't test this myself right now, but if I were to start with a fresh build, what would be the first package build; guess it is a native package and that it is is independent of distro etc (eg. stagemanager-native) Mar 06 19:24:34 sha256sum-native I beleive Mar 06 19:25:27 XorA: thanks, will give it a try, i get a crash in bitbake seems there is something odd with dependency handling Mar 06 19:25:53 guess it is shasum-native, sha265sum-native does not exist Mar 06 19:27:11 possibly Mar 06 19:27:17 * XorA is tired Mar 06 19:27:42 debug says: DEBUG: Task 1 (/home/frans/oe/openembedded/recipes/stage-manager/stagemanager-native_0.0.1.bb, do_setscene) is not buildable Mar 06 19:28:08 DEBUG: (Complete marker was False and the remaining dependency count was 1) Mar 06 19:29:18 * XorA watches bitbake message fly over his head into the stratosphere Mar 06 19:29:35 :-) Mar 06 19:29:46 * eFfeM1 is not a bb wiz either Mar 06 19:30:08 eFfeM1: BTW was there a problem with koens compromise suggestion the the glib cleaning situation? Mar 06 19:30:26 eh, i don't think i saw it Mar 06 19:30:52 eFfeM: keep 2.X.Y where Y is highest and convert it to new staging/bbclassextend Mar 06 19:31:16 eFfeM: delete the rest Mar 06 19:31:35 XorA: seems a good start :-) did he send it to the ML ? Mar 06 19:31:39 so the latest release of each X Mar 06 19:31:47 eFfeM1: yes quite early on in the thread Mar 06 19:33:03 ah ok, found it; np with that Mar 06 19:33:18 eFfeM1: I would ack that one as well Mar 06 19:33:19 btw did a grep for do_deploy and almost everyone is using the new staging Mar 06 19:33:31 do_stage is the old staging Mar 06 19:33:34 not do_deploy Mar 06 19:33:35 eFfeM: er, do_deploy doesn't have much to do with staging Mar 06 19:33:38 ooops Mar 06 19:33:43 wrong grep Mar 06 19:34:17 * XorA noticed today that cross.bbclass still uses legacy staging Mar 06 19:34:22 ouch Mar 06 19:34:34 anyway, will ack the suggestion of koen Mar 06 19:34:52 it just needs a s/do_stage/do_install/ I think Mar 06 19:35:24 although I think kergoth had some ideas to kill cross altogether Mar 06 19:36:09 cross is gone already on the toolchain-desuck branch Mar 06 19:36:09 yeah read the thread, do not understand all of the details though, I'm definitely not an expert in our build system and classes Mar 06 19:36:48 mail sent Mar 06 19:36:59 pb__: ah good to know I will not "fix" cross.bbclass then Mar 06 19:38:38 yeah, probably no point trying to patch up the existing cross.bbclass at the moment. Mar 06 19:39:22 pb__: gtk+ patch on its way to oe-devel Mar 06 19:39:39 very good Mar 06 19:40:45 * XorA only has sepultura keeping him awake so wont guarantee its right Mar 06 19:41:38 It's early still, even in gmt Mar 06 19:43:28 looks good to me, except for Mar 06 19:43:29 +RRECOMMENDS_${PN}_libc-uclibc = " ${NEATSTUFF} " Mar 06 19:43:32 which seems a bit weird Mar 06 19:52:32 Literally, NEATSTUFF ??? Mar 06 20:06:41 mwester: literally, though that isn't especially weird as variable names go Mar 06 20:07:27 it was more the libc-uclibc bit which seemed strange; I can't quite figure out why that should be needed. Mar 06 20:08:05 hi Mar 06 20:09:22 hi hrw Mar 06 20:11:52 when going to BBCLASSEXTEND what should be done with something like Mar 06 20:11:53 DEPENDS = "ncurses-native" Mar 06 20:11:58 pb__: to not pull in gconv which build glibc when you using uclibc Mar 06 20:12:06 this seems to create a circular dependency Mar 06 20:12:30 XorA: how would it be getting pulled in otherwise, though? the "default" case is not to have it. Mar 06 20:12:34 this DEPENDS is in ncurses Mar 06 20:13:03 RRECOMMENDS_${PN}_linux must be matching or something, but it was trying to build glibc :-( Mar 06 20:13:07 eFfeM: you'll have to add a virtclass-native override to stop it Mar 06 20:13:10 or in other workds, is there a way when goign to BBCLASSEXTEND to say that a package depends on its -native package Mar 06 20:13:10 good evening, do you know an easy way to use xterm instead of gnome-terminal as console when making kernel menuconfig? Mar 06 20:13:20 pb, ah ok Mar 06 20:13:29 XorA: that's odd. it shouldn't, since you should have TARGET_OS=linux-uclibc on a uclibc build Mar 06 20:13:44 pb__: I its insane Mar 06 20:14:29 one of the reasons I didnt want to just push the patch Mar 06 20:16:49 very weird. I just checked in my uclibc build tree and it seems to be working fine (without your patch) Mar 06 20:16:54 gtk+ recipes look a bit of a mess, could do with a hoover Mar 06 20:17:26 yeah Mar 06 20:20:30 pb_ so I need to add as in this: Mar 06 20:20:31 DEPENDS = "ncurses-native" Mar 06 20:20:31 DEPENDS_virtclass-native = "" Mar 06 20:20:33 correct ? Mar 06 20:21:23 yeah, that should do the trick Mar 06 20:22:01 testing it now, ty Mar 06 20:23:02 worked, great Mar 06 22:07:43 hmm Mar 06 22:15:40 so, now I have angstrom running on the SBC6020, and now I would like to submit the patches to OpenEmbedded.. Mar 06 22:15:47 are there any procedures? Mar 06 22:16:47 Romke, git format-patch then use git send-email to mail to the mailing list Mar 06 22:16:53 nite lall Mar 06 22:17:13 ah, i have to use git for that? Mar 06 22:18:01 I am trying to add a new kernel to my OE target. I added a new kernel in my local directory, and also a new linux-libc-headers recipe. Mar 06 22:18:53 when I issue the command bitbake console-image -s, it lists my new kernel and linux-libc-headers as the preferred versions Mar 06 22:19:08 however, when I issue the command bitbake console-image, it builds the old versions. What am I missing? **** ENDING LOGGING AT Sun Mar 07 02:59:57 2010