**** BEGIN LOGGING AT Tue Nov 29 02:59:57 2011 Nov 29 08:36:31 sgw: ping Nov 29 08:37:11 JaMa: Good morning! Nov 29 08:37:20 sgw: morning :) I see you've included mesa split patches Nov 29 08:37:28 sgw: you probably want this one too http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/pull&id=7177305276dacba92ee4974d1b8dcb6224916ff1 Nov 29 08:37:43 sgw: as it fixes the issue you reported with it before Nov 29 08:37:56 JaMa: I am fading fast, been coughing and struggling all day. Nov 29 08:38:11 Can you send a followup to my PULL for RP. Nov 29 08:38:18 yup Nov 29 08:38:36 I must have been going off an older patchset, which is why I asked for an update SDL patch set. Nov 29 08:38:42 sorry I missed that mesa one. Nov 29 08:38:51 We are trying to get all caught up. Nov 29 08:39:24 I will get the SDL stuff in the next round if it looks good and deals with the opengl issue well. Nov 29 08:40:11 it's keeping opengl as it was, because introducing PACKAGECONFIG opengl (even with virtclass-nativesdk would change the output package and I don't want that) Nov 29 08:41:04 JaMa: OK. Please resend a complete updated patch set. It bedtime here as I have an early call later. Nov 29 08:41:17 * sgw fades away Zzzz Nov 29 08:42:21 sgw: ok, I'll wait for RP if he takes mesa changes and then send v2 with only libsdl changes Nov 29 08:42:37 thanks and gnight Nov 29 10:37:57 morning all Nov 29 11:09:56 are BSPs being hosted out of the yocto tree? Nov 29 11:48:16 RP__: ping Nov 29 12:18:23 dongxiao: pong Nov 29 12:20:03 RP__: more commits in your queue to push? because mesa changes are incomplete.. Nov 29 12:24:15 RP__: I saw in meta/lib/oe, there is an packagedata.py. is it acceptable to put it in bitbake's folder? like bitbake/lib/bb/. Nov 29 12:25:04 RP__: in hob2's second step (integrates packages into final image), HOB GUI need to get the full package list and their dependencies (from pkgdata). So bitbake server need to handle pkgdata things... Nov 29 12:28:26 Hi, how do I set bitbake to an extremly verbose debuglevel ? BB_DEBUG = "1" does nothing for me ... Nov 29 12:34:19 dongxiao: hmm, good question. That code is very "OE" specific rather than generic like bitbake usually uses Nov 29 12:34:47 dongxiao: it might be we need to import lib/oe from hob Nov 29 12:35:02 dongxiao: is it hob that needs the dependency or the bitbake server itself? Nov 29 12:35:12 dany: bitbake -DDD Nov 29 12:35:20 RP__: ping Nov 29 12:35:24 lianhao: pong Nov 29 12:36:06 RP__: thanks, having some issues with the generation of ext2.tar.gz.ubbot format I need to debug... Nov 29 12:39:11 RP__: just want to double check that the exported PKGR of the PRservice should contain the ${PRAUTO}, right? Nov 29 12:40:22 RP__: so the user should first enable the PRservice, and let the service generated the PRAUTO, then he can export that PKGR into a file for lockdown? Nov 29 12:40:43 Hi All, -DDD is not the type of debug I'm looking for, I want to see the outputs of configure/make/make install CMDs. Any flag for this ? Nov 29 12:40:53 RP__: It is the HOB that needs the dependency. However, Hob just executes a certain runCommand to get the available packages and their dependencies, and cooker will calculate them and send back to GUI. Nov 29 12:41:09 dany: have a look at the log files in the temp directory of the recipe? Nov 29 12:41:57 lianhao: I think so, I'm having trouble context switching to that subject :/ Nov 29 12:42:57 dongxiao: so can't the UI then suppliment the info from bitbake with some direct queries not using runCommand? Nov 29 12:45:23 RP__: I'll put my question in the email with the "context". :) Nov 29 12:45:56 dongxiao: it might be for the second stage of the UI, we use a query directly calling lib/oe rather than use runqueue Nov 29 12:46:14 dongxiao: then when ready to build the image we only then call runqueue once we know what we want to build Nov 29 12:46:22 lianhao: I think that would help, thanks! Nov 29 12:52:21 RP__: hmm, so Hob GUI need to query the "data" from bitbake server Nov 29 12:54:01 RP__: then HOB use the "data" to call lib/oe's packagedata handling logic? Nov 29 12:55:29 RP__: here "data" means the parsed data for a certain fn Nov 29 13:00:21 RP__: or do you mean HOB query bitbake server for the content of pkgdata file, and then HOB GUI handle the pkgdata by meta/lib/oe? Nov 29 13:50:34 RP__: libsdl alsa patch updated in jansa/pull, thanks for spotting it somehow I've lost it between V1.5 and V2 :/ Nov 29 13:53:54 JaMa: I've merged it thanks Nov 29 13:56:13 RP__: btw that PRINC trick didn't work (int type didn't like expresion :/) Nov 29 13:56:53 RP__: you missed a PR bump on qt-free-x11.inc Nov 29 13:57:15 RP__: ericben patch were not in sync with master Nov 29 14:16:34 JaMa: ah, try PRINC := "${int(PRINC) + 1}" Nov 29 14:17:36 otavio: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=4f408de16bedeab1ffe4fa80100bb60d5335bf97 - are you sure? Nov 29 14:18:55 RP__: sorry; I did the change here and missed it on the pushed patch Nov 29 14:19:02 RP__: thanks by confirming it Nov 29 14:19:14 otavio: I fixed up the conflict manually Nov 29 14:19:20 RP__: ah ok Nov 29 14:24:34 RP__: still ValueError: invalid literal for int() with base 10: '${int(PRINC) + 1}' Nov 29 14:24:44 with added PRINC := 0 to bitbake.conf Nov 29 14:25:18 PRINC := "${int(d.getVar(PRINC)) + 1}" ? :/ Nov 29 14:25:30 whole log http://paste.pocoo.org/show/514437/ Nov 29 14:25:47 * RP__ was trying to be too clever I suspect Nov 29 14:26:10 ValueError: invalid literal for int() with base 10: '${int(d.getVar(PRINC)) + 1}' Nov 29 14:28:04 gtg, bb 1,5 hour Nov 29 14:44:19 PRINC is unquoted there, so it tries to get a value for a key of None Nov 29 15:27:20 kergoth: right, trying to do too many things at once :/ Nov 29 15:27:55 kergoth: any thoughts on that knotty change to add the footer? Nov 29 16:08:53 kergoth: something like this? ValueError: invalid literal for int() with base 10: "${int(d.getVar('PRINC')) + 1}" Nov 29 18:31:32 khem: ping Nov 29 19:01:59 I'm having wierd issues trying to add a DEPENDS to non-native recipes so I can run a new QA test in insane.bbclass: http://pastebin.com/4sCk8pNw Nov 29 19:02:22 The code addition snippet and error messages are in the pastebin Nov 29 19:05:09 hmmm...seems like doing a DEPENDS_append at all in insane.bbclass isn't possible. Nov 29 19:06:27 ah, nm...I've resolved the problem Nov 29 19:33:03 sgw: yes Nov 29 19:51:52 Hi Khem, would you review the patches that are part of uclibc and eglibc and add Upstream-Status info? Or if you could summarize the status and I will add it to the patches Nov 29 19:55:02 sgw: ok. I will take a look Nov 29 19:58:24 khem: Thanks Nov 29 20:09:22 khem: on a different / similar subject, you had a patch for alsa-lib, is there an updated patch based on comments coming? Nov 29 20:25:49 sgw: hmm now that you mentioned it. no Nov 29 20:25:56 sgw: I have forgotter about that Nov 29 20:26:24 since the general solution needs more testing, let me see if I can cook up something Nov 29 22:53:24 ppl += appends, can I remove ie, is there a -= ? Nov 29 22:53:36 sgw: for alsa-lib issue, I have posted a new more intrusive patch here http://patches.openembedded.org/patch/15653/ Nov 29 22:53:53 s0undt3ch, there is not a remove operation Nov 29 22:54:03 or do I have to declare all the rdepends without the ones I need in order to tweak the rdeps? Nov 29 22:54:08 sgw: please try it in your automated builds. I have done little testing on it. but it impacts basic Nov 29 22:54:20 dvhart: so, I have to copy paste what I actualy need right=? Nov 29 22:54:40 s0undt3ch, that's one way to go about it. Probably the simplest. Nov 29 22:54:49 s0undt3ch: use oe_filter_out function if you need to remove something Nov 29 22:55:01 khem: k Thanks! Nov 29 22:55:08 ah, see that, learn something knew every day. Nov 29 22:55:10 thanks khem Nov 29 22:55:13 khem: is that documented somewere? Nov 29 22:55:15 new even Nov 29 22:55:35 for sample code look at meta/recipes-devtools/gcc/gcc-configure-runtime.inc Nov 29 22:55:47 it does not appear to be documented in the bitbake manual Nov 29 22:56:01 dvhart: its an oe function not bb Nov 29 22:56:12 khem, ok Nov 29 22:56:33 dvhart: and yes they need documentation :) infact whole of classes/ dir needs documentation Nov 29 22:57:05 khem, sure, and we're all actively working on that Nov 29 22:57:13 definitely a work in progress Nov 29 22:57:34 * dvhart watches do_patch sit there and do nothing Nov 29 22:57:37 grmble Nov 29 22:59:09 khem: where does that d come from? Nov 29 22:59:13 ah, screen terminal :) Nov 29 22:59:58 dvhart: yeah, file that bug - we tell people about the screen session for devshell but not for patch Nov 29 23:00:16 incandescant, what's the bug? Nov 29 23:00:28 incandescant, just to display that it has happened? Nov 29 23:01:13 dvhart: yeah. If you do a bitbake foo -c devshell you'll see a log message telling you to connect to the screen session, but not if you have a do_patch awaiting attention Nov 29 23:04:27 s0undt3ch: its anonymous python d is supplied as datastore Nov 29 23:05:03 dvhart: I just do PATCHRESOLVE = "noop" Nov 29 23:05:08 in local.conf Nov 29 23:05:21 khem, and does that continue or fail ? Nov 29 23:06:37 dvhart: it barfs at me instead of sitting there silently if some patching fails Nov 29 23:06:48 nice Nov 29 23:06:53 * dvhart adds to local.conf template Nov 29 23:06:56 dvhart: I usually access machine remotely Nov 29 23:07:04 me too... always Nov 29 23:45:08 RP__: around? Nov 29 23:51:28 msm: anything I can help with? Nov 30 00:02:54 i was just gonna ask how to do multilib Nov 30 00:03:02 when PACKAGE_ARCH=$MACHINE Nov 30 00:03:56 i've hacked together a u-boot recipe that builds all the multilib deps, then done some major bad stuff to get u-boot to use the multilib compiler Nov 30 00:04:05 it just feels wrong Nov 30 00:04:35 when lib32-u-boot should achieve the same thing, if only the multilib would let me build that Nov 30 00:06:28 sgw: ^ Nov 30 00:08:21 msm: Nope, that definitely an RP__ question, sorry can't help with multilib (yet, maybe someday in the future). Nov 30 00:09:51 msm: multi-arch patch does not help you Nov 30 00:10:38 msm: how to "do" multilib - you need a BBCLASSEXTEND, see meta/conf/multilib.conf Nov 30 00:10:59 or did you need more than that? Nov 30 00:11:26 incandescant: all recipes are multilib-able Nov 30 00:11:31 if they are TARGET_ARCH Nov 30 00:11:40 like rpm or git, etc Nov 30 00:11:47 u-boot is special because its MACHINE specific Nov 30 00:12:16 im pretty sure I can just turn off that bit Nov 30 00:12:26 make u-boot be TARGET_ARCH and everything would just work Nov 30 00:12:33 but then i'd have conflicting u-boot recipes Nov 30 00:12:38 well Nov 30 00:12:51 not recipes, but u-boot would be different per machine Nov 30 00:12:54 khem: what patch? Nov 30 00:18:02 http://patches.openembedded.org/patch/15425/ Nov 30 00:24:30 msm I (clearly) don't know anything about our multilib support - but I found this page: https://wiki.yoctoproject.org/wiki/Multilib Nov 30 01:02:34 incandescant: hehe thanks, i think i need to add some things there =) Nov 30 01:03:00 khem: ah, kehm im matthew mcclintock… i've been commenting on that thread Nov 30 01:03:12 khem: i need libgcc for u-boot so that doesnt help us Nov 30 01:03:24 gcc for powerpc64 is always able to produce 32bit code anyways Nov 30 01:19:29 msm: heh ok. I think yes if we need libgcc that means we need multilib Nov 30 01:20:17 msm: so you just want u-boot-32 recipe which just needs gcc-runtime-32 I guess Nov 30 01:22:11 well our 64 bit parts still use a 32 bit bootloader Nov 30 01:22:18 khem: thats the main issue at play right now Nov 30 01:23:35 msm: ok. I think multilib right now aims more at providing compatible libraries for legacy code Nov 30 01:24:02 why do u want 32 bit u-boot btw. Nov 30 01:26:34 its all we have to boot our part =) Nov 30 01:27:17 msm: hmmm then use ppc32 toolchain Nov 30 01:31:42 khem: yea but thats not available in a powerpc64 build Nov 30 01:31:49 it only builds the 64bit stuff Nov 30 01:32:04 it can compile the code, but we are missing libgcc Nov 30 01:34:05 msm: I wonder why dont you add a 32 bit machine Nov 30 01:34:25 or is it that you just need u-boot to be 32bit and rest of it is 64bit Nov 30 02:31:40 khem: we have a 32 machine for the 32bit rfs Nov 30 02:31:59 khem: but for the 64bit rfs we need a 32bit u-boot still **** ENDING LOGGING AT Wed Nov 30 02:59:57 2011