**** BEGIN LOGGING AT Thu Nov 24 02:59:58 2011 Nov 24 08:14:36 gm Nov 24 08:48:39 good morning Nov 24 09:05:14 morning Nov 24 09:06:55 hi mckoan, XorA, all Nov 24 09:07:08 yo bluelightning Nov 24 10:33:23 hi all Nov 24 10:33:31 hi pb_ Nov 24 10:34:36 JaMa: we have been too optimistic wrt ipaq...patchset just needing a liitle rework after last changes in 3.1 Nov 24 13:00:43 bluelightning: should I update the CMDLINE_DEBUG patch in jansa/pull? Nov 24 13:01:08 bluelightning: or add patch on it removing it from both linux.inc and linux-kexecboot.inc? Nov 24 13:01:39 JaMa: well, I've been uncomfortable about using IMAGE_FEATURES in that way for a while now, I just hadn't said anything except in discussions with ant_work a while ago Nov 24 13:02:08 if you wouldn't mind I think it would be great to avoid using it in meta-handheld if we can Nov 24 13:07:25 bluelightning: https://gitorious.org/shr/meta-handheld/commit/500b3f98d0df54c4d610127e5edc9ea8c887f92d?format=patch Nov 24 13:07:32 added on top of jansa/pull Nov 24 13:07:46 yes, +1 Nov 24 13:08:32 looks good to me also Nov 24 13:08:38 git grep IMAGE_FEATURE is empty now in meta-hh Nov 24 13:08:51 great stuff Nov 24 13:09:00 since it's lunchtime I'll merge that stuff now :) Nov 24 13:09:16 and about LOGO_SIZE? thst's another unfinished thing Nov 24 13:09:46 ant_work: and this: recipes-bsp/kexecboot/kexecboot-cfg_0.1.bb:CMDLINE_DEBUG ?= "${@base_conditional('DISTRO_TYPE', 'release', 'quiet', 'debug',d)}" Nov 24 13:10:11 it was like this but DISTRO_TYPE seems unused in oe-core tree Nov 24 13:10:39 ant_work: yes... are you guys happy if I just move the LOGO_SIZE default from zaurus.inc to linux.inc / linux-kexecboot.inc ? Nov 24 13:11:13 * JaMa doesn't like LOGOs so fine for me Nov 24 13:11:20 I think in meta-handheld we always want a bootlogo Nov 24 13:11:33 both in linux and linux-kexecboot Nov 24 13:11:47 that's why I added it to SRC_URI Nov 24 13:11:58 * JaMa wants to be able to disable it Nov 24 13:12:16 distro flag? Nov 24 13:12:21 as it breaks integrity of kernel output ;) Nov 24 13:12:34 well, don't you debug on serial? Nov 24 13:12:54 I'm fine with possibility to disable it from local.conf Nov 24 13:13:02 I am starting an image that will run on a beagleboard ... I noticed that oe-core doesn't has a beagleboard machine definition .. where I can take one? Nov 24 13:13:14 meta-ti? Nov 24 13:13:15 otavio: meta-ti? Nov 24 13:13:54 JaMa: gr .. indeed Nov 24 13:14:26 JaMa: so we have to append to SRC_URI only if var in local.conf is not empty? like this? Nov 24 13:15:37 ant_work: or make logo SRC_URI variable with weak assignment Nov 24 13:15:47 like SRC_URI_LOGO = file://sth Nov 24 13:16:09 and then always append it to SRC_URI and I'll set SRC_URI_LOGO empty to disable it Nov 24 13:16:25 bluelightning: go and eat, then think about that ;) Nov 24 13:16:45 ant_work: serial is fine when I'm at home and I plan to debug something Nov 24 13:16:55 ant_work: I've eaten, it's my post lunch break :) Nov 24 13:17:11 ant_work: but to see what's taking so long when I'm rebooting it and I'm away from computer then it's better to see it directly Nov 24 13:21:00 JaMa: I'm a bit concerned about this one: http://gitorious.org/shr/meta-handheld/commit/19b573f112f191ea9dd166e3be7edc8310725198 Nov 24 13:21:15 do you really want it to be conditional on the value being "loglevel=3" ? Nov 24 13:22:21 those options mean 100-120Kb Nov 24 13:24:03 yeah I'm not concerned about them being disabled I'm concerned about the conditional statement, it's a bit weak Nov 24 13:24:08 bluelightning: I'm not so happy about it, but I didn't want to use IMAGE_FEATURES here as well Nov 24 13:24:25 bluelightning: in fact there is a relation, once you disable printk the 'debug' and loglevel= are nonsenses Nov 24 13:25:02 I'd be less worried about it if we reversed the statement (i.e. check for "debug") although I still think it's a little ugly Nov 24 13:25:23 does that make sense? Nov 24 13:25:46 bluelightning: if we do it like CMDLINE_DEBUG contains "debug" then yes Nov 24 13:26:24 JaMa: that's what I was thinking Nov 24 13:26:42 but should be possible to set CMDLINE_DEBUG "debug and something else" Nov 24 13:27:00 earlyprintk comes to mind Nov 24 13:27:06 looks good to me then Nov 24 13:27:08 base_contains should help there..? Nov 24 13:27:24 hmm, but not in shell script Nov 24 14:50:08 where do the package addon version strings come from .. like u-boot_2009.08-r1.6 <- r1.6 ?? Nov 24 14:50:48 rob_w: that's the PR Nov 24 14:51:36 if it contains a decimal point it's usually because INC_PR is also being used Nov 24 14:52:11 so can i force a package to increment that on each compile/build ? Nov 24 14:53:11 rob_w: it's intended to be incremented on some change to the input, rather than the output Nov 24 14:55:01 i ve a case where when i recompile my own package and ofcourse something then changed .. the package still recieves the same version string in its ipk.. then also sometime s opkg refuses to install the pacakge as it supposed to be "the same" Nov 24 14:55:44 rob_w: if you've made a change that you know is significant you should increment PR by hand, that will solve that issue Nov 24 14:56:12 e.g. you add a patch to SRC_URI, increment PR in the recipe at the same time Nov 24 14:56:26 or use something like gitver if your source is in a local tree under revision control Nov 24 14:56:37 both of these alternatives do suck, but this is about as good as it gets at the moment. Nov 24 14:56:47 right, if you're building from source control that's another option Nov 24 14:56:53 git stuff would be cool Nov 24 14:56:59 I think kergoth has been doing some work on making oe more bearable to use for development Nov 24 14:57:03 most of my stuff is git sourced Nov 24 14:57:19 presumably he is busy gorging himself on turkey today, though, so might not have much to say Nov 24 14:57:42 hehe Nov 24 14:59:43 hmm i checked my linux kernel recipe and also linux.inc but they dont supply PR , yet they got that strin in the pacakge also .. is tehre a generic source of PR if a recipe doesnt supply it ? Nov 24 15:00:28 rob_w: is it r0 ? that's the default value if none is specified Nov 24 15:01:03 r91.6 Nov 24 15:01:12 k i grep for it .. nevermind Nov 24 15:02:47 there's a special thing called MACHINE_KERNEL_PR for kernels Nov 24 15:02:55 which might be what you're seeing, or might not Nov 24 15:03:03 hmm cool thx Nov 24 15:03:59 machine/include/omap3.inc:7:MACHINE_KERNEL_PR = "r91" - pb_ gets the points Nov 24 15:04:34 # Increase this everytime you change something in the kernel Nov 24 15:04:34 MACHINE_KERNEL_PR = "r91" Nov 24 15:04:59 .. OK, Mr. Comment . i do that from now ! Nov 24 15:20:01 hi all Nov 24 15:20:16 anyone has ideas for kernel module debug on OE ? Nov 24 15:36:40 printk? Nov 24 16:18:06 Hi everyone Nov 24 16:18:10 I have an image bb file which I use to generate my rootfs Nov 24 16:19:04 When I call clean command with this image it almost delete nothing except ipk under tmp/work/ Nov 24 16:19:44 Is there a way to tell bitbake to clean all packages which installed that rootfs via IMAGE_INSTALL environment in image bb Nov 24 16:20:26 I dont want to remove whole tmp directory and rebuild bootloader+kernel+rootfs again Nov 24 16:20:35 just want to rebuild rootfs related packages Nov 24 16:22:57 any idea? Nov 24 16:41:08 mgundes: the question is why do you want to do that specifically? Nov 24 16:44:11 sometimes I do more changes on my recipes and want to re-generate rootfs image to test Nov 24 16:44:21 so that I need this case Nov 24 16:45:18 by the way I figured out clearall command and tried it. But it has removed almost everything under tmp :) Nov 24 16:46:15 mgundes: just rebuilding your-image.bb should take care of all changes (if properly marked by PR increase) Nov 24 16:49:10 mgundes: what ant_work said - any changes to the recipes should be accompanied by a PR bump for each one Nov 24 16:49:12 I usually do not update PR so that I think rebuilding wont take care of all changes at this case, right? Nov 24 16:50:06 then do -c clean and (-c cleansstate) for each modified recipe Nov 24 16:50:18 latter only if using oe-core Nov 24 16:50:39 and remember to bump PR next time ;) Nov 24 16:50:49 I still use oe-classic Nov 24 16:52:02 you are right but our recipes are changed many times nowadays so that I avoid using new PR for each changes Nov 24 16:52:29 then I will do -c clean for modified recipes Nov 24 16:52:46 yeah, that's the alternative Nov 24 16:52:50 mgundes: if contents of the package change you have to bump PR Nov 24 16:52:52 thanks ant_work, bluelightning Nov 24 16:53:50 khem, you are right but we change our own recipes and there is not necessary to commit anything on OE side. Nov 24 16:54:15 usually they are minor updates Nov 24 16:58:22 khem: hi, long we don't see you on irc Nov 24 16:59:42 traveling around the world? Nov 24 17:04:41 ant_work: yes, was away for a month Nov 24 17:04:45 vacationing Nov 24 17:04:56 nice Nov 24 17:11:26 khem: I smell a breakage for klibc if/when RP decides to touch the cross recipes in oe-core wrt PACKAGE_ARCH. I'll commit soon klibc_2.0, pls have a look at it, it still needs to be packaged for development on target Nov 24 17:12:43 hmm cross-klcc Nov 24 17:12:52 has parts for target ? Nov 24 17:13:06 no, vanilla klcc could have Nov 24 17:13:24 (we call klcc-cross the other) Nov 24 17:13:42 isnt klibc a target recipe ? Nov 24 17:13:51 and klcc-cross a separate one Nov 24 17:14:00 atm yes Nov 24 17:14:14 ok then it should work might need some adjustment Nov 24 17:14:15 but we don't ship the klcc for target Nov 24 17:14:24 do we neeed to Nov 24 17:14:35 maybe for an -sdk ? Nov 24 17:14:44 I have no use of it Nov 24 17:15:45 sdk will need cross Nov 24 17:16:26 well, the paths in klcc are pointing to sysroot atm :/ Nov 24 17:16:33 hmmm Nov 24 17:16:43 so I removed it from packaging ;) Nov 24 17:16:46 that would make it unfit for sdk Nov 24 17:17:06 klcc-cross is ok Nov 24 17:17:36 in fact klibc has this double nature... Nov 24 17:17:42 hmm Nov 24 17:17:54 i think I have to have a look at it Nov 24 17:17:59 pls do ;) Nov 24 17:18:54 most of util-linux can be compiled against klibc nowaday Nov 24 17:19:02 I could beat kexec to compile too Nov 24 17:19:06 starts to be fun Nov 24 17:19:46 well, for an initramfs Nov 24 17:40:51 I am trying to use oe-core to build to qemuarm and it is failing with: Nov 24 17:40:56 Error, the PACKAGE_ARCHS variable does not contain TUNE_PKGARCH (armv5te). Nov 24 17:41:00 expected? Nov 24 18:31:28 otavio: I dont see it here Nov 24 18:31:40 otavio: do u have some local changes Nov 24 18:48:24 khem: well, have layers Nov 24 18:48:31 khem: let me check Nov 24 19:15:54 khem: it seems to be broken somehow Nov 24 19:15:59 * otavio try to drop tmp and check Nov 24 19:35:00 doesn't work et all Nov 24 19:35:56 ahhh Nov 24 19:57:45 otavio: drop your layer Nov 24 19:57:49 and try pure or-core Nov 24 19:58:13 otavio: I've been getting green builds of qemuarm on master so its likely something local Nov 24 19:58:53 RP__: I am looking where SDK_VERSION should be. its used in places Nov 24 19:58:56 is it local.conf ? Nov 24 19:59:00 it should come from Nov 24 19:59:47 khem: comes from the distro config I think? Nov 24 20:00:00 I am in oe-core Nov 24 20:00:03 no distro Nov 24 20:00:19 khem: defaultdistro needs a default Nov 24 20:00:36 i see Nov 24 20:01:29 conf/distro/include/default-distrovars.inc ? Nov 24 20:01:33 is it apt place Nov 24 20:01:39 khem: I think so Nov 24 20:03:26 should it default to be empty strings Nov 24 20:03:31 or some value Nov 24 20:04:22 what is common convention Nov 24 20:05:20 khem: 0.0 ? Nov 24 20:05:35 ok I called it oe-core.0 Nov 24 20:11:28 RP__: khem: I found what was that. In our layer we change the extra arches since we need to have distro specific packages without duplicating all build but this was buggy; fixed it now Nov 24 20:23:48 RP__: http://pastebin.com/bADhq68V Nov 24 20:24:02 RP__: this is when exiting the runqemu script Nov 24 20:24:55 khem: very odd. python 2.7 should include sqlite3 Nov 24 20:33:27 RP: yes strange it is see http://pastebin.com/JgjfavUr this is complete log Nov 24 20:33:35 when I Ctrl+c the qemu session Nov 24 20:34:49 I wonder why it does not happen when the session starts Nov 24 20:35:17 since this happens in scripts/oe-find-native-sysroot Nov 24 20:35:27 and that script is called during start up too Nov 24 20:36:48 It calls the corrrect bitbake script if I trace it /home/kraj/work/angstrom/sources/openembedded-core/scripts/bitbake Nov 24 20:37:00 hiho khem Nov 24 20:37:07 woglinde: howdy Nov 24 21:00:16 RP__: this little program reproduces the error for me Nov 24 21:00:23 http://pastebin.com/pi3R3DRx Nov 24 21:00:53 when running with python from build box it works Nov 24 21:01:05 but with python from native sysroot it fails Nov 24 21:02:48 hm? Nov 24 21:05:05 woglinde: can you try it for my sanity Nov 24 21:06:15 hm looks good Nov 24 21:06:19 but I am watching tv Nov 24 21:06:25 cannt test it here Nov 24 21:11:47 heh ok Nov 24 21:36:14 khem: sounds like sqlite3 is broken in python-native for some reason on your machine Nov 24 21:39:22 RP__: one difference is that I built it using TCLIBC=uclibc Nov 24 21:39:44 its native package so I would have expected it to be identical to eglibc Nov 24 21:39:47 khem: would that affect native pyton? Nov 24 21:40:28 btw. I see same problem with TCLIBC=eglibc native sysroot on other box Nov 24 21:40:49 but let me kill everything and rebuild Nov 24 21:43:19 RP__: does that sample work for you ? Nov 24 21:43:30 khem: let me try Nov 24 21:45:04 khem: yes Nov 24 21:45:23 The python-native in my sysroot reports back a version Nov 24 21:45:38 khem: I wonder which import error you're seeing Nov 24 21:45:40 RP__: ok, thats something wrong with my build them Nov 24 21:45:42 then Nov 24 21:46:02 but since I see it on both boxes and both are ubuntu 11.10 x86_64 Nov 24 21:46:04 That except is only there for python 2.5 and earlier Nov 24 21:46:18 khem: ah, this is also ubuntu 11.10 x86_64 Nov 24 21:46:24 cool Nov 24 21:46:38 then only extra patch I have is libtool 2.4.2 Nov 24 21:46:52 khem: so it must be that or uclibc Nov 24 21:46:56 cant imagine how that can impact python Nov 24 21:47:06 no Nov 24 21:47:21 ok let me rebuild and see Nov 24 22:08:17 RP__: no cookie, build from scratch shows same problem Nov 24 22:08:25 khem: :( Nov 24 22:08:35 now I am trying with other box with eglibc Nov 24 22:08:36 khem: whats the exact importerror? Nov 24 22:08:51 khem: remove the try except Nov 24 22:09:56 03Richard Purdie  07master * r035c673c46 10bitbake.git/lib/bb/runqueue.py: Nov 24 22:09:56 runqueue.py: Fix debug message to reference the correct task Nov 24 22:09:56 Signed-off-by: Richard Purdie Nov 24 22:10:03 03Richard Purdie  07master * ra34ff490a4 10bitbake.git/lib/bb/ui/knotty.py: Nov 24 22:10:03 knotty: Add support for logging the console to logfile Nov 24 22:10:03 The BB_CONSOLELOG variable is used to specify the console log file Nov 24 22:10:03 to use. This means people can look up things that happened during a Nov 24 22:10:03 build by may have scrolled off the screen. Nov 24 22:10:03 [YOCTO #1771] Nov 24 22:10:04 Signed-off-by: Richard Purdie Nov 24 22:10:04 03Richard Purdie  07master * ra0246bf09c 10bitbake.git/lib/bb/fetch2/__init__.py: (log message trimmed) Nov 24 22:10:05 fetch2: Improve uri_replace to handle paths with no trailing '/' Nov 24 22:10:05 Currently if you specify a mirror like: Nov 24 22:10:06 file://.* http://linux.freescale.net/yocto/sstate-cache Nov 24 22:10:06 it won't work as you expect whilst: Nov 24 22:10:07 file://.* http://linux.freescale.net/yocto/sstate-cache/ Nov 24 22:10:07 will since it has the trailing slash. Nov 24 22:10:11 RP__: ImportError: No module named pysqlite2 Nov 24 22:10:19 http://pastebin.com/Lt4fE6qQ Nov 24 22:10:31 data/siggen: Add vardepvalue mechanism to allow the variable dependency code to be forced to specific values Nov 24 22:10:31 We have a problem if we want to inject specific information into the variable Nov 24 22:10:31 dependency code. There are cases for example where we want a dependency Nov 24 22:10:31 on the value of X but it doesn't matter how X was constructed or what Nov 24 22:10:31 dependencies it might have had, we only care about the absolute value. Nov 24 22:10:31 With the current code, its near enough impossible to do this. Nov 24 22:10:32 03Richard Purdie  07master * r5597a68fac 10bitbake.git/lib/bb/fetch2/local.py: (log message trimmed) Nov 24 22:10:32 fetch2/local: Don't default to files in DL_DIR for file:// urls Nov 24 22:10:33 Defaulting to any file in DL_DIR as the first match for a file:// url Nov 24 22:10:33 doesn't make much sense and can lead to unexpected results. Nov 24 22:10:34 This patch changes the logic so this is the last fallback location Nov 24 22:11:31 instead. Whether it should be using DL_DIR at all for this is a Nov 24 22:11:31 good question but something for another patch. Nov 24 22:13:35 khem: no, why is the first import failing - that is the real problem Nov 24 22:14:48 khem: the second is only useful as a fallback on python 2.5 Nov 24 22:14:50 import sqlite3 ? Nov 24 22:14:54 yeah I wonder too Nov 24 22:15:10 the files are there I checked Nov 24 22:15:28 khem: that must be raising an importerror of its own Nov 24 22:15:55 khem: so just do "import sqlite3" and see why that fails (without the try/except/import pysqlite bit" Nov 24 22:18:41 http://pastebin.com/UjW6u2Wx Nov 24 22:20:13 _sqlite3 is not there Nov 24 22:20:35 $ find /usr/lib/python2.7/ -name "_sq*"/usr/lib/python2.7/lib-dynload/_sqlite3.so Nov 24 22:20:44 but its there on my host Nov 24 22:23:03 open("/usr/lib/python2.7/lib-dynload/_sqlite3.so", O_RDONLY) = 5 Nov 24 22:23:08 cool. my netwalker bsp could build core-image-minimal Nov 24 22:23:14 and in case of my host it really uses it Nov 24 22:25:33 RP__: its looking for it in /home/kraj/work/angstrom/sources/openembedded-core/build/tmp-uclibc/sysroots/x86_64-linux/usr/lib/python2.7/plat-linux3/ Nov 24 22:25:42 but that dir only has IN.py IN.pyo regen Nov 24 22:26:38 khem: same here but I do have ./x86_64-linux/usr/lib/python2.7/lib-dynload/_sqlite3.so Nov 24 22:27:04 RP__: hmm and I dont Nov 24 22:28:23 http://pastebin.com/FFmFEFjM is content of my lib-dynload Nov 24 22:31:15 khem: mine is the same with the difference of sqlite and I have crypt_failed.so not crypt.so Nov 24 22:31:40 RP__: do u have sqlite3.h in /usr/include ? Nov 24 22:32:09 I think what on build host creeps in Nov 24 22:34:08 README in python sources top dir says you need sqlite dev package installed for it to be enabled Nov 24 22:34:26 setup.py is interesting Nov 24 22:34:29 do we run it Nov 24 22:39:16 RP__: btw. do u have log.do_install of your python-native handy ? Nov 24 22:39:24 RP__: I think I see the error Nov 24 22:39:30 khem: I can find one Nov 24 22:40:02 RP__: there is a compiler error Nov 24 22:40:11 and it then does not build the module Nov 24 22:40:26 gcc: error: unrecognized option '-R' Nov 24 22:41:17 Failed to build these modules: Nov 24 22:41:20 _sqlite3 Nov 24 22:45:22 lol Nov 24 23:11:05 good nite Nov 25 00:31:47 03Matthew McClintock  07master * rd7f9edda65 10bitbake.git/lib/bb/utils.py: Nov 25 00:31:48 Nothing uses USERNAME, remove it - can cause sstate-cache conflicts Nov 25 00:31:48 USER is the correct variable to use, also this can affect sstate Nov 25 00:31:48 cache as well. Nov 25 00:31:48 Signed-off-by: Matthew McClintock Nov 25 00:31:48 Signed-off-by: Richard Purdie Nov 25 01:05:43 does anyone build yocot in a chroot? Nov 25 01:05:56 im doing a setarch and chroot to try to build 32 bit on a 64 bit machine Nov 25 01:06:03 or is there another easier way to force this? Nov 25 01:56:58 i think i found my problem, my supposed 32bit rfs was poluted with 64bit stuff Nov 25 01:58:06 heh, oops **** ENDING LOGGING AT Fri Nov 25 02:59:57 2011