**** BEGIN LOGGING AT Mon Jun 13 02:59:57 2011 Jun 13 06:12:33 hello I had created x11-image for mini2440... but i m getting wrong touchscreen calibration.... can anyone help me which scripts handles touchscreen calibration... Jun 13 08:58:37 morning all Jun 13 09:14:55 can anyone help how tvout work... I had one development board of MIPS... it 1 tv out port.... i want some basic application to run tvout... Jun 13 11:26:10 how to change display port from VGA to TV out can anyone help me... Jun 13 11:27:36 see the topic Jun 13 11:51:02 morning folks Jun 13 11:51:08 hi mickey|daddy Jun 13 11:51:10 congratulations daddy Jun 13 11:51:14 thanks pb_ :) Jun 13 11:51:18 mickey|daddy: how's the little one? Jun 13 12:02:02 heh Jun 13 12:02:20 mine said just yesterday he'd marry mum ;) Jun 13 12:03:29 gratz mickey|daddy Jun 13 12:03:36 pb_:if you have still some sugar before lunch... Jun 13 12:04:03 I tried to remove PACKAGE_ARCH from klibc Jun 13 12:04:22 but th ekernel is staged per-machine :/ Jun 13 12:05:07 so ln -sf ${STAGING_KERNEL_DIR} linux will fail Jun 13 12:05:58 now,if we only had one third of the vars, these would still be too many... Jun 13 12:06:32 heh Jun 13 12:06:33 indeed Jun 13 12:06:36 I think I'll have to put the arch-sysroot string together Jun 13 12:07:15 I'm not entirely convinced it is good/desirable/necessary for the kernel headers to be staged per arch. Jun 13 12:07:26 er, per machine that is Jun 13 12:07:55 in fact the only specific file is a .config Jun 13 12:08:06 yeah Jun 13 12:08:06 machine-specific Imean Jun 13 12:09:03 how do uclibc solv ethat? Jun 13 12:09:35 * ant_work apologizes for the broken SPACE key Jun 13 12:10:12 uclibc uses linux-libc-headers, not the kernel itself Jun 13 12:10:20 ah, right Jun 13 12:10:25 afaik, neither uclibc nor eglibc DEPEND on any kernel package Jun 13 12:10:25 hm..udev then Jun 13 12:21:06 I have to rephrase KLIBCKERNELSRC=${STAGING_KERNEL_DIR} Jun 13 13:18:55 hello, the tcl revipe may be broken, ERROR: The checksums for "/var/lib/jenkins/jobs/shr-unstable-image-clean-build/workspace/shr-unstable/downloads/tcl8.5.8-src.tar.gz" did not match. Jun 13 13:18:55 MD5: expected "7f123e53b3daaaba2478d3af5a0752e3", got "ebf87808253b9892ef15bdfdbd1b7203" Jun 13 13:18:55 SHA256: expected "6b090c1024038d0381e1ccfbd6d5c0f0e6ef205269ceb9d28bd7bd7ac5bbf4a7", got "4a756dfd83816c8680b9def66eb282d1639436a59d19c5321bd020dd9dc8fda9" Jun 13 13:19:26 can anybody fix it please ? Jun 13 13:23:31 thanks eFfeM Jun 13 13:25:29 bluelightning: everything ok so far, mummy and Lara Marie are back at home since saturday. she's often hungry and we're tired, but i'm afraid that's how things are going to be usually ;) Jun 13 14:02:11 morning kergoth Jun 13 14:06:29 03Richard Purdie  07master * rc1d978d7bd 10bitbake.git/lib/bb/fetch2/__init__.py: (log message trimmed) Jun 13 14:06:29 bitbake/fetch2: When replacing URLs in mirror handling mask out empty entries Jun 13 14:06:29 The symptom of this problem is something like a cvs url which specifies Jun 13 14:06:29 a username where the username is then passed through to something like Jun 13 14:06:29 an http mirror. Jun 13 14:06:30 This patch fixes things by ensuring empty entries are preserved in the Jun 13 14:06:31 new URL. Jun 13 14:51:20 Is there way to tell bitbake to be a bit more verbose about what commands for the individual tasks (i.e. the actual command "make .." "cp ..") . I've already tried the -D -n -v options Jun 13 14:51:31 *commands it will execute Jun 13 14:57:30 joelagnel: can you not just consult the logs in /tmp/work///temp/ ? Jun 13 15:00:07 joelagnel: -D should show you the output from the individual tasks, and they already run with set -x for the shell ones Jun 13 15:01:59 bluelightning, sure I can :) thanks Jun 13 15:03:07 kergoth, uhm, ok I will try and see if I can get it to spit that out. thanks Jun 13 15:03:47 the problem with -D is generally the opposite -- that it shows too much :) Jun 13 15:03:54 but you can turn it up further, up to -DDD Jun 13 15:04:03 i doubt it will help you in this particular case, as one level is enough to show task output Jun 13 15:33:02 oe.dev can't be parsed with bitbake master Jun 13 15:35:06 http://pastebin.com/V6RcmULR Jun 13 16:50:06 Heinervdm: hmm, you're right... I have a one-liner workaround but I'd like to know what really caused this and if there are other implications Jun 13 17:23:05 bluelightning: are you still looking at qt issues? Jun 13 17:23:34 otavio: yes although I have not yet looked at bringing over the native* patches from oe... I know you are waiting, sorry... Jun 13 17:24:15 bluelightning: not only it; meta-oe still provides 4.6.2 packages while oe-core provides .3 Jun 13 17:24:28 bluelightning: it would be nice to move those to a small set of .bbappend files Jun 13 17:25:16 RP__: ping Jun 13 17:25:36 RP__: I am running into a strange parsing error on oe-core/angstrom Jun 13 17:25:39 otavio: slightly ahead of you ;) I have a patch ready that replaces all of the recipes in meta-oe with bbappends that just set the db driver options Jun 13 17:25:46 haven't submitted it yet Jun 13 17:26:20 khem: pong Jun 13 17:26:23 bluelightning: so please do that; I was going to work on that Jun 13 17:26:39 bluelightning: and duplicate your work heh Jun 13 17:26:47 RP__: a strange parsing error happens on qemux86 and qemux86_64 only Jun 13 17:26:56 otavio: will send the patch out this evening Jun 13 17:26:59 khem: what kind of error? Jun 13 17:27:04 bluelightning: please do Jun 13 17:27:12 bluelightning: i will wait for it then Jun 13 17:27:37 RP__: I will paste the error http://paste.ubuntu.com/626013/ Jun 13 17:27:50 RP__: I tracked it down to allarch Jun 13 17:28:17 so when I remove BASE_PACKAGE_ARCH = "all" from allarch.bbclass the parsing goes through Jun 13 17:28:31 but then that fix was added to get away with those endianness things Jun 13 17:28:53 and the same works fine for no x86 so I am not sure if that the real problem Jun 13 17:31:24 khem: Can you find out which task is causing that error (add a bb.error(task) in the for loop) Jun 13 17:32:47 khem: The AddTaskNode handler in ast.py very clearly calls bb.data.setVarFlag(var, "deps", existing, data) Jun 13 17:33:01 RP__: ok Jun 13 17:33:20 khem: So I can't immediately see how "deps" would end up unset, it should at least be empty Jun 13 17:33:50 RP__: so its the loop in asp.py you meant right ? Jun 13 17:34:41 for dep in flags['deps']: ah thsi one Jun 13 17:34:42 khem: no, add it before the loop in build.py, line 468 Jun 13 17:34:49 or 469 Jun 13 17:37:14 RP__: NOTE: do_rm_work Jun 13 17:37:42 * khem added notes instead of bberror Jun 13 17:38:35 Do someknow knows why this fails? Jun 13 17:38:35 ERROR: Nothing PROVIDES 'virtual/i686-oesdk-linux-gcc' Jun 13 17:38:36 ERROR: Required build target 'task-ostt-osnt-toolchain-host' has no buildable providers. Jun 13 17:38:52 otavio: oe-core master? Jun 13 17:38:57 otavio: bitbake -g Jun 13 17:38:58 RP__: yes Jun 13 17:39:19 otavio: try http://git.openembedded.net/cgit.cgi/openembedded-core-contrib/commit/?h=rpurdie/for-master&id=c3d317014f417ca895458b797afdf6c40e5b5a57 Jun 13 17:41:26 RP__: I pulled your for-master branch to test. Jun 13 17:42:43 khem: hmm, I can't reproduce :/ Jun 13 17:43:27 RP__: add INHERIT += "rm_work" to your local.conf Jun 13 17:43:35 khem: I did Jun 13 17:43:48 RP__: because if I remove that then it starts to parse Jun 13 17:44:21 hmm Jun 13 17:44:52 there is no ghost of this class in meta-oe Jun 13 17:44:59 so that possibility is out Jun 13 17:45:09 RP__: koen is seeing same problem too Jun 13 17:45:10 RP__: now it fails to include the required file Jun 13 17:45:17 so its not something in my env Jun 13 17:45:47 otavio: checkout out the renaming commit in what you just pulled Jun 13 17:46:22 khem: What is OVERRIDES for you? Jun 13 17:46:30 (bitbake -e | grep ^OVERRIDES) Jun 13 17:46:39 na, nativesdk Jun 13 17:46:44 ok, testing Jun 13 17:47:28 RP__: same Jun 13 17:47:29 ERROR: Nothing PROVIDES 'virtual/i686-oesdk-linux-gcc' Jun 13 17:47:30 ERROR: Required build target 'task-ostt-osnt-toolchain-host' has no buildable providers. Jun 13 17:47:57 otavio: touch local.conf Jun 13 17:48:47 RP__: it cant do that dies before that Jun 13 17:48:59 RP__: same Jun 13 17:49:51 khem: Ok, can you add something to ast.py around line 244 "bb.data.setVarFlag(var, "deps", existing, data)" and provide that it sets "deps" for var == "do_rm_work" ? Jun 13 17:50:00 s/provide/prove/ Jun 13 17:53:31 otavio: no idea then, sorry Jun 13 17:53:59 RP__: what I could check to try to track it down? who ought to set the virtual? Jun 13 17:54:36 otavio: It looks very like the nativesdk error that patch I pointed at fixes Jun 13 17:54:44 otavio: It should have -crosssdk on the end Jun 13 17:56:05 RP__: if var == "do_rm_work": Jun 13 17:56:05 bb.data.setVarFlag(var, "deps", [], data) Jun 13 17:56:05 else: Jun 13 17:56:05 bb.data.setVarFlag(var, "deps", existing, data) Jun 13 17:56:10 same error Jun 13 17:56:52 khem: Can you turn that into a bb.note and prove its setting that flag for do_rm_work ? Jun 13 17:57:21 khem: It won't change the error, I just want to figure out if the data store loses the flag or we never set it Jun 13 17:57:45 * otavio trying to figure the sdk issue Jun 13 17:58:45 RP__: I added a bb.note but its not printed Jun 13 17:58:58 bb.note("Setting do_rm_work deps") Jun 13 17:59:26 khem: so it looks like addtask is never called for do_rm_work? Jun 13 17:59:57 hmmm but why only for qemux86 Jun 13 18:00:17 in my local.conf I have INHERIT += "rm_work" Jun 13 18:00:23 which should be picked up all the time Jun 13 18:00:26 khem: Can you try and work this backwards through the parser, see if its seeing the addtask at all? Jun 13 18:00:48 e.g. whether handleAddTask() is called? Jun 13 18:01:04 * RP__ -> afk, sorry Jun 13 18:01:47 RP__: hmm I missed it last time Jun 13 18:01:57 but yes the original bb.note is printed Jun 13 18:01:59 NOTE: Setting do_rm_work deps Jun 13 18:02:14 I missed it in output last time Jun 13 18:02:23 and also handleAddTask is called Jun 13 18:02:57 does any1 know the state of the tx25 conf? is it supposed to be useable or still WIP ? I just tried it - the kernel it builds wont boot, i tried another kernel but that results in a cycle of erros scrolling up the screen as soon as it start to do userland bit (i.e. once kernel has finished loading) Jun 13 18:08:48 hi, are ${MACHINE_ARCH} preferred over another arch(like ALL for instance),even if the recipe's PR is higher withthout MACHINE_ARCH Jun 13 18:08:55 *without Jun 13 18:14:10 you mean opkg's behavior? Jun 13 18:14:35 yes Jun 13 18:14:38 on target for instance Jun 13 18:14:56 I've to remove a machine specific gtkrc Jun 13 18:15:01 for htcdream Jun 13 18:15:24 I vaguely remember JaMa having issues with that Jun 13 18:16:09 roughly will that work: http://www.pastie.org/private/jshvvtuqfwtiuhirxjiw Jun 13 18:16:12 can I push it? Jun 13 18:18:10 RP__: FWIW this error happens on all x86 machines Jun 13 18:18:20 I tried few from meta-intel Jun 13 18:34:41 mangomake, what's tx25? the karo modules for mx25? Jun 13 18:48:26 hmmm it seem to have been installed Jun 13 18:48:29 I'll push then Jun 13 18:54:48 03Denis 'GNUtoo' Carikli  07org.openembedded.dev * ra36d53f780 10openembedded.git/recipes/shr/ (2 files in 2 dirs): Jun 13 18:54:48 gtk-theme-e17lookalike: fix htcdream's gtkrc Jun 13 18:54:48 Without that fix we have all the gtk appliactions that looks too big: Jun 13 18:54:48 The htcdream's DPI was added to match its real DPI, Jun 13 18:54:48 So now we have to remove the htcdream's specific gtkrc, Jun 13 18:54:48 else the gtk applications looks too big. Jun 13 18:54:48 Signed-off-by: Denis 'GNUtoo' Carikli Jun 13 19:21:16 anyone using INITRAMFS_IMAGE? I get a circular dependency when setting that in a machine conf file Jun 13 19:54:04 hello, libgiso does not compile: posix-ext.vapi:7.5-7.30: error: `Posix' already contains a definition for `INET_ADDRSTRLEN' Jun 13 19:54:05 | const int INET_ADDRSTRLEN; Jun 13 19:54:05 | ^^^^^^^^^^^^^^^^^^^^^^^^^^ Jun 13 20:48:47 khem: so if I understand correctly, its setting deps but not finding it in the datastore? :/ Jun 13 20:53:55 yes Jun 13 20:54:19 RP__: and it only happens for x86 thats kind of confusing Jun 13 20:54:35 point of failure is not to much related to reason Jun 13 20:55:08 khem: Can you reproduce this if you disable the angstrom layer? Jun 13 20:55:16 no Jun 13 20:55:22 I tried with slugos Jun 13 20:55:24 it works Jun 13 20:55:59 I removed all the layers only left with oe-core meta-oe and meta-angstrom still the problem happened Jun 13 20:56:20 I am sure its something in angstrom layer thats triggering it Jun 13 20:57:14 I tried to find if its something to do with COMPATIBLE_MACHINE but did not happen Jun 13 20:57:28 khem: its a really odd one :/ Jun 13 20:57:56 RP__: if you have time then you can git clone git://git.angstrom-distribution.org/setup-scripts angstrom Jun 13 20:58:15 khem: Not right now, maybe tomorrow Jun 13 20:58:19 cd angstrom; git checkout -b oe-core origin/oe-core Jun 13 20:58:29 ok Jun 13 20:58:56 it use to work well with angstrom Jun 13 20:59:05 I dont think its something angstrom is doing wrong Jun 13 20:59:19 it has not changed much since it worked Jun 13 20:59:23 khem: no, it just sounds like some kind of bug maybe in bitbake Jun 13 20:59:31 recent changes have just happened to trigger it Jun 13 20:59:33 yeah thats what I think too Jun 13 21:00:03 I can try few things if you have some thoughts Jun 13 21:29:42 khem: ping Jun 13 21:30:48 ant__: yes Jun 13 21:31:00 hi sunny California Jun 13 21:31:33 sunny? let me look outside. Jun 13 21:31:42 trying to unbind klibc from $MACHINE, I stumble in the fact the kernel headers are staged per-machine :/ Jun 13 21:32:25 KLIBCKERNELSRC=${STAGING_INCDIR}/linux Jun 13 21:33:01 was my try but theb I reflected: why are sources staged per-machine? Because of the patches? Jun 13 21:33:54 ant__: it will be hard job to untangle klibc Jun 13 21:34:17 sun is out Jun 13 21:34:23 ant__: if it can work with installed kernel headers then you might succeed Jun 13 21:34:32 and the climate is best by government test! Jun 13 21:35:12 yes, but those are in sysroots/$MACHINE-*abi/kernel Jun 13 21:38:04 hm.. Jun 13 21:38:08 I'll test STAGING_KERNEL_DIR = Jun 13 21:38:08 "${STAGING_DIR}/${MACHINE_ARCH}${TARGET_VENDOR}-${TARGET_OS}/kernel" Jun 13 21:46:01 khem: well, it builds Jun 13 21:46:41 now, what happens if 1st machine uses 2.6.39 and 2nd machine uses 2.6.26 ? Jun 13 21:46:58 in the case I build for different archs? Jun 13 21:47:22 or see if the library has dependency of kernel like that Jun 13 21:47:30 then you need to make it go with kernel Jun 13 21:47:39 so it will remain machine specifiv Jun 13 21:48:09 but if it is immune to kernel versions then we can think of making it non machine specific Jun 13 21:48:29 the thing you need to determine is Jun 13 21:48:37 if it needs kernel or kernel-headers Jun 13 21:48:50 if its kernel-headers then its arch specific Jun 13 21:48:53 it just needs the headers, anyway each buyuild will have a fake .so Jun 13 21:48:57 if its kernel then its machine specifiv Jun 13 21:49:11 so you cannot use a different klibc for linking Jun 13 21:49:37 well, I'll build for armv4 now Jun 13 21:52:59 ok, armv4 has klibc-EIBwDrOZCHE0IZzMnwZ4uLnn52I.so while armv5te has a different klibc-KJIXXU905NmdsAhH9CDvjaMiMpU.so Jun 13 21:53:25 seems just fine Jun 13 22:24:10 03Andrea Adami  07org.openembedded.dev * r89adc55282 10openembedded.git/recipes/klibc/klibc.inc: (log message trimmed) Jun 13 22:24:10 klibc: remove PACKAGE_ARCH = "${MACHINE_ARCH}" Jun 13 22:24:10 * paraphrasing uclibc discussion: Jun 13 22:24:10 * there is no good reason for klibc to be machine specific. Jun 13 22:24:10 * remove local assignment to PACKAGE_ARCH so that it gets the default target Jun 13 22:24:10 * architecture and bump INC_PR for that change. Jun 13 22:24:11 * Jun 13 23:05:16 i have 2 native recipes. B depends on A. A puts something in staging that I want B to replace. Is the best approach to, in B's recipe, delete what A added to staging? Or is there a cleaner approach? Jun 13 23:06:51 i think the cleaner approach is 'don't do that' Jun 13 23:06:52 but.. :P Jun 13 23:07:23 :) Can once recipe 'clean' another? Jun 13 23:07:36 this is all during a bootstrapping phase Jun 13 23:08:13 ie package A is only necessary during the bootstrapping of B. Once B-native is installed A should not be needed. Jun 13 23:08:29 is there a way to embed A inside of B? Jun 13 23:24:03 RP__: ping Jun 13 23:25:26 heh, I was going to tell him to go the bed :) Jun 13 23:29:06 gn Jun 13 23:31:52 gn AnssiN_ Jun 14 00:01:55 Tartarus: pong Jun 14 00:02:08 fetch2 funny issue Jun 14 00:02:37 One box get_srcrev gives me "git[0" Jun 14 00:02:53 Another parses it out correctly from SRCREV=171 (which is a tag) Jun 14 00:03:20 Where do I even start digging on that? Jun 14 00:03:44 Tartarus: same git-native version? Jun 14 00:03:51 yeah Jun 14 00:04:01 both machines are on the same set of repos Jun 14 00:04:14 Tartarus: git-native built in both cases? Jun 14 00:04:25 these are both on things like udev_171.bb or linux-omap_2.6.39.bb Jun 14 00:04:49 and yeah Jun 14 00:04:57 Tartarus: both with fetch2 being used? Jun 14 00:04:58 whole world for systemd-gnome-image is built, sans those two recipes Jun 14 00:05:23 # SRCPV=${@bb.fetch2.get_srcrev(d)} Jun 14 00:05:24 SRCPV="1+git.kernel.org[0:" Jun 14 00:05:31 So I assume yes, all the fetch2 stuff is set right Jun 14 00:06:02 Tartarus: corrupt cache of some kind? Jun 14 00:06:34 nuking 'em all now Jun 14 00:07:55 * RP__ needs to sleep I'm afraid Jun 14 00:08:04 k Jun 14 00:08:05 later Jun 14 00:08:50 very crazy Jun 14 00:30:23 the left coast/eu time differential is rough **** ENDING LOGGING AT Tue Jun 14 02:59:57 2011