**** BEGIN LOGGING AT Thu Aug 11 02:59:56 2011 Aug 11 07:26:36 morning Aug 11 07:41:11 hi Aug 11 07:41:35 hey guys, is there a way to have a .config and bbappend the kernel package telling it to compile the kernel using this given .config? Aug 11 08:22:45 dorileo: you dont even need to do that normally, just put your .config as defconfig in the machine dir of your machine Aug 11 08:23:38 morning XorA Aug 11 08:23:46 hey ka6sox Aug 11 08:23:52 hows it going in over there land? Aug 11 08:27:11 living on the edge here.... Aug 11 08:27:25 hopefully things are quiet where you are? Aug 11 08:27:45 300 miles from nearest riot :-) Aug 11 08:28:03 good... Aug 11 08:28:16 all seems to be a bit exagerated by over eager press anyway Aug 11 08:28:30 Hadrian's Wall I hope will keep the Maurading hoard out. Aug 11 08:29:48 think the Scottish chavs are too busy on the buckfast to riot Aug 11 08:30:01 Good Aug 11 08:35:48 XorA, ok, thank you Aug 11 08:39:44 XorA, the kernel-yocto uses kernel_configme and it calls configme but I could not find configme anywhere, do you know where it's defined? Aug 11 08:40:10 kernel.bbclass maybe? Aug 11 08:40:16 * XorA doesnt have a yocto checkout handy Aug 11 08:40:46 XorA, it's within oe-core Aug 11 09:16:17 hi all Aug 11 09:21:06 hello I had builded a qt4-x11-demo-image for mini2440 .... but when I ported on my board I m getting ... QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv failed for BOM: Bad file descriptor Aug 11 09:21:06 QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv_open failed Aug 11 09:21:06 QIconvCodec::convertToUnicode: using Latin-1 for conversion, iconv_open failed Aug 11 09:21:06 qtdemo: cannot connect to X server Aug 11 09:21:33 can anyone help me....what this error is? Aug 11 09:38:19 sanket_: the first three lines can be ignored Aug 11 09:38:38 your X server is either not running, broken, or DISPLAY is not set Aug 11 09:39:16 bluelightning, then how can I set the display Aug 11 09:39:38 DISPLAY is an environment variable Aug 11 09:39:44 it should be ":0" Aug 11 09:39:58 for the local machine Aug 11 09:40:11 is X even running? Aug 11 09:40:31 bluelightning, but I m getting now qtdemo: cannot connect to X server :0 Aug 11 09:40:48 is the X server running? Aug 11 09:42:06 bluelightning, how can I check the X server is running.... I had tested with X11 session using "Xorg :1 -once -query " .... it is working fine... Aug 11 09:43:51 ps aux | grep X Aug 11 09:44:09 but you can see if it's running because of what's shown on the display Aug 11 09:46:02 bluelightning, X is not working.... Aug 11 09:46:51 so, then it's obvious why qtdemo is complaining it can't start Aug 11 09:47:01 or rather that it can't connect to the X server Aug 11 09:48:07 bluelightning, I had created a shellscript with X :0 & and run qtdemo.... it is working... Aug 11 09:51:42 right Aug 11 09:52:04 maybe the qt4-demo-image scripts need fixing Aug 11 10:59:01 morning all Aug 11 11:03:42 hi pb_ Aug 11 11:10:50 hey pb_ Aug 11 11:14:15 pb_: btw regarding our last talks I'm happy to see both klibc and kexec-tools have accepted our OE patchset Aug 11 11:14:43 very good Aug 11 11:17:57 I posted klibc for review ([meta-oe]. There is one point to clarify. We reset CC, LD & co. in klibc.bbclass. Aug 11 11:18:33 this seems necessary at least for kexec-tools. other binaries do not complain if we use standard flags. Aug 11 11:21:57 ehmm I meant we set CFLAGS, CPPFLAGS, LDFLAGS to empty string Aug 11 11:28:26 I think that's probably okay. Aug 11 14:12:13 pb_: I started to investigate the "__KLIBC__ not defined" by diffing the do_configure logs but have been stopped by the fact CCACHE decided to strike again so the logs are too different :/ Aug 11 14:12:54 I don't see yet why setting CCACHE = "" in local.conf is not enough Aug 11 14:13:24 the file is parsed after bitbake.conf, where the initial setting is done Aug 11 15:17:32 morning kergoth Aug 11 15:20:13 hey Aug 11 15:35:53 RP__1: around? Aug 11 15:36:06 khem: around? Aug 11 15:36:07 galak: yes Aug 11 15:39:19 RP__: what do we need to do to close on SOCKS5_{USER, PASSWD} to BB_ENV_EXTRAWHITE patch Aug 11 15:39:51 galak: We need to figure out if it needs to be excluded from sstate checksums Aug 11 15:40:35 right, and how do we do that? Aug 11 15:40:47 galak: Since I'm busy trying to fix other problems like the fact x86 -64 is broken, I don't have time right now to check, or document how to check since it amounts to the same amount of work Aug 11 15:41:11 ok, can you point me in a direction here? Aug 11 15:42:50 galak: ok, let me stop what I'm doing and figure this out... Aug 11 15:43:24 thanks, didn't mean to be a pester Aug 11 15:43:55 galak: perhaps you can fix x86-64 instead ;-) Aug 11 15:47:04 perhaps, what's broken on x86-64? Aug 11 15:47:20 galak: The baselib change we're discussing on the mailing list Aug 11 15:47:55 galak: I realise we can't revert your patch but breaking x86 isn't an option and neither is gcc ignoring baselib Aug 11 15:50:46 galak: Is BB_ENV_EXTRAWHITE the only place you need to add those variables? Aug 11 15:50:57 yes Aug 11 15:51:12 galak: what uses them from there? Doesn't bitbake clear them from the environment anyway? Aug 11 15:52:04 so our socks server requires a username/password to do things like git protocol clones through firewall Aug 11 15:52:22 so my git-proxy setup uses ssh socks Aug 11 15:52:43 galak: But how does that variable remain in the environment for that script to use it? Aug 11 15:53:08 galak: e.g. are you also doing something like "export SOCKS5_USER" in local.conf? Aug 11 15:53:27 is in my shell environment not local.conf Aug 11 15:54:05 my understanding was that having it listed in BB_ENV_EXTRAWHITE meant bitbake wouldn't clear it out and import it from shell environment Aug 11 15:56:06 galak: Well, it will but it will only place it in the internal data store Aug 11 15:56:28 galak: there isn't anything to say "also export this from the data store into the environment that bitbake uses" Aug 11 15:56:53 galak: So you can understand my puzzlement about how your testing this or how it has any effect Aug 11 15:57:22 RP__: yes, and my puzzlement on how this does seem to address my issue ;) Aug 11 15:57:52 RP__: let me see if I can get a case to reproduce this Aug 11 15:58:06 RP__: go back to focus on the x86-64 issue Aug 11 15:58:29 RP__: I do have a multilib question, as I feel like I'm missing something on that front Aug 11 15:59:38 RP__: I build a base 32-bit ppc, with 64-bit multilib. however I don't see anything different from the base 32-bit build Aug 11 16:00:10 RP__: as an example I'd have expected to also have /lib64 in rootfs image (in addition to /lib) Aug 11 16:03:02 galak: I've documented the process in email Aug 11 16:04:55 galak: You have to create a multilib image which would include elements of both Aug 11 16:06:34 (the process I've documented is the hash issue one) Aug 11 16:09:44 hash issue? Aug 11 16:10:20 oh Aug 11 16:10:50 RP__: is there an example on x86 that creates a multilib image with elements of both? Aug 11 16:11:06 galak: not in master, we did have some test code Aug 11 16:12:10 galak: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=mhatle/ml&id=182aea612686fcdaced351e9fdeceead9072475f was an example Aug 11 16:12:28 galak: and/or http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=mhatle/ml&id=a9250c1fef264755c08d4161e52ffe30f69b9bd9 Aug 11 16:13:42 the second test does collision detection on both binaries and avoidance for things like ncurses headers. Aug 11 16:13:56 the first was just to see if I could get a multilib build to work Aug 11 16:17:22 do we plan on adding some standard example in? Aug 11 16:19:12 galak: Its difficult to come up with something generic Aug 11 16:19:51 multilib is specialized enough that I'm not sure we will... for me the obvious things are both libc's.. two zlibs.. etc.. Aug 11 16:20:02 about the only sample config I can think of would be a multilib LSB config Aug 11 16:20:16 since that is well defined as to what should be available Aug 11 16:20:44 my wife's 15 year old nephew killed himself today Aug 11 16:25:23 tzanger sorry to hear that. a sad day. Aug 11 16:30:13 bbl Aug 11 16:32:56 fray: I think even something as simple as libc would be fine (this might get solved by documentation) Aug 11 17:26:29 Anyone here has tried creating rpm packages instead of ipk/deb? Aug 11 17:28:40 I'm trying this. The RPM packages are created, but the rootfs isn't. Yum doesn't see any packages to install. Aug 11 17:44:31 khem: ping Aug 11 17:49:39 has anyone tried building RPM packages instead of ipk or debian? Aug 11 17:52:22 I use rpm packages almost exclusively Aug 11 17:52:35 cool Aug 11 17:52:48 there is a problem with arm that I sent a fix for earlier today.. but otherwise it should be good on oe-core Aug 11 17:53:05 hmm.. i'm trying on arm Aug 11 17:53:12 what is the problem on arm? Aug 11 17:53:49 *was the problem on arm? :-) Aug 11 17:53:55 on the target the platform settings don't match so you get incompatible package messages Aug 11 17:54:41 can you please point me to the patches? Aug 11 17:54:48 turns out the way we were using rpmbuild --target was not quite compatible with what we needed.. check the oe-core mailing list (or git.yoctoproject.org/poky-contrib.git mhatle/fix_1352 branch) Aug 11 17:55:13 http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mhatle/fix_1352 Aug 11 17:55:15 top two patches Aug 11 17:55:19 thanks! Aug 11 18:00:53 hmm, i have some catching up to do Aug 11 18:01:15 the package_rpm i have from oe is quite different from what you pointed to Aug 11 18:04:00 oe is broken.. oe-core works Aug 11 18:04:08 (rpm package support that is) Aug 11 18:08:59 03Joshua Lock  07master * r93bae8f223 10bitbake.git/lib/bb/ui/crumbs/tasklistmodel.py: Aug 11 18:08:59 bb/ui/crumbs/tasklistmodel: correctly uniquify dependency list Aug 11 18:08:59 Fix thinko - the squish method returns a uniquified list, it doesn't modify Aug 11 18:08:59 the list in place. Therefore the call to squish() was useless as its return Aug 11 18:08:59 value was never assigned. Aug 11 18:09:00 Signed-off-by: Joshua Lock Aug 11 18:09:10 03Joshua Lock  07master * r396bbc2206 10bitbake.git/lib/bb/ui/crumbs/tasklistmodel.py: Aug 11 18:09:10 bb/ui/crumbs/tasklistmodel: don't include an item in its own depends Aug 11 18:09:10 This causes the simple removal algorithm to perform needless circular logic Aug 11 18:09:10 Signed-off-by: Joshua Lock Aug 11 18:09:10 03Richard Purdie  07master * r6c382c2ee7 10bitbake.git/doc/manual/usermanual.xml: Aug 11 18:09:10 bitbake/usermanual: Update to be more in sync with bitbake codebase Aug 11 18:09:11 Signed-off-by: Richard Purdie Aug 11 18:09:11 03Joshua Lock  07master * rba9f2fe496 10bitbake.git/lib/bb/ui/crumbs/tasklistmodel.py: (log message trimmed) Aug 11 18:09:12 bb/ui/crumbs/tasklistmodel: fix some typos and add comments to mark() Aug 11 18:09:12 Two similarly named variables in the mark() method resulted in the wrong Aug 11 18:09:46 variable being used in a couple of places. This patch adresses this in Aug 11 18:09:46 several ways: Aug 11 18:09:46 1) Renames the variables to be less similar Aug 11 18:09:46 2) Uses the correct variables Aug 11 18:09:46 03Richard Purdie  07master * re7ade6dcd6 10bitbake.git/lib/bb/cooker.py: Aug 11 18:09:46 bitbake: Fix -e when used with -b option Aug 11 18:09:47 When using the -e and -b options together an expection was occuring. Aug 11 18:09:47 This was due to incorrect initialisation and this patch adds in the Aug 11 18:09:48 correct initialisation calls. Aug 11 18:09:48 Signed-off-by: Richard Purdie Aug 11 18:09:49 03Joshua Lock  07master * rcc4158db21 10bitbake.git/lib/bb/cache.py: Aug 11 18:09:49 bb/cache: rename confusing variable Aug 11 18:09:50 The bNeedUpdate variable doesn't reflect its purpose, and doesn't match Aug 11 18:09:50 coding style (type encoded in variable name, camel case) - rename to Aug 11 18:10:10 thanks fray, I have some work to do!! Aug 11 18:10:47 cache_ok. Aug 11 18:10:47 Signed-off-by: Joshua Lock Aug 11 18:31:12 Who runs the patch queue manager site for OE? Aug 11 18:31:32 I need someone to fix my account record, or delete it so I can re-create it, please. Aug 11 18:32:32 Also, BZR support in OE is broken. It only allows operation the first time fetching, Aug 11 18:32:43 thereafter the fetch fails 100% of the time. Aug 11 18:32:48 http://patches.openembedded.org/patch/4021/ is a fix. Aug 11 18:43:14 dickelbeck: possibly khem or ka6sox Aug 11 18:43:38 that would be a khem question. Aug 11 18:44:26 dickelbeck: that patch is against bitbake though not OE... it should be sent to bitbake-devel@lists.openembedded.org Aug 11 18:44:44 dickelbeck: sorry I didn't reply mentioning that earlier Aug 11 18:45:31 Thanks bluelightning. Aug 11 18:46:21 * bluelightning heads home Aug 11 18:48:04 dickelbeck: actually it seems you sent it to the bitbake-dev list earlier, just picked up on that... since the lists moved it's probably worth resending, I guess it got missed Aug 11 19:21:15 kergoth: ping Aug 11 20:06:26 hi all. I am trying some powervr GFX examples on an OMAP3530 board and I realize that after approximately 10 minutes (9 min fifty-something seconds) the whole board hangs. I believe it has to do with dpms, even though I think I have disabled it, any ideas? Aug 11 20:07:50 also, xset doesn't seem to do the right job disabling dpms **** ENDING LOGGING AT Fri Aug 12 02:59:59 2011