**** BEGIN LOGGING AT Wed Jul 27 02:59:57 2011 Jul 27 07:53:34 morning all Jul 27 07:54:10 night all! Jul 27 07:54:58 RP__: I did not test or pull the 3.0 kernel changes Jul 27 07:55:46 morning RP__ Jul 27 07:55:54 * sgw needs to find a way to make a time stop machine Jul 27 07:56:02 dvhart: what are you still doing up? Jul 27 07:56:05 sgw: Should I consider pulling them or are you saying not to? Jul 27 07:56:15 Late night for some people! Jul 27 07:56:17 I've been bustin' my arse all day on a 3.0-rt bug Jul 27 07:56:26 I _just_ fixed it Jul 27 07:56:32 if I drank, I'd be drinking Jul 27 07:56:34 ;-) Jul 27 07:56:45 dvhart: that bad! Jul 27 07:56:48 RP__: haven't got a clue about the 3.0 since I did not build it Jul 27 07:57:01 If you have time to do a build go for it Jul 27 07:57:19 RP__, requeue_pi failure from bad pi_state rtmutex raw wait lock initialization Jul 27 07:57:28 so ... yeah... nasty Jul 27 07:57:41 at least it wasn't my fault this time :-) Jul 27 07:57:43 dvhart: that does sound fun Jul 27 07:57:52 dvhart: If I said anything I would but guilty Jul 27 07:58:02 -ENOPARSE Jul 27 07:58:23 dvhart: to me or RP__? Jul 27 07:58:28 to you Jul 27 07:58:48 that sez it all doesn't it Jul 27 08:00:12 it took a bit longer b/c I tried kdb and kgdb - which failed at single stepping :/ Jul 27 08:00:31 back to printk :-) Jul 27 08:01:01 * dvhart builds/tests the final fix Jul 27 08:01:30 printk is hard to beat Jul 27 08:01:47 * RP__ uses bb.error in a similar way in bitbake Jul 27 08:02:11 I'm feeling better about the feedback I gave to that Peter guy about what is required to support early OS debugging Jul 27 08:02:19 SERIAL CONSOLE SERIAL CONSOLE SERIAL CONSOLE Jul 27 08:02:20 * sgw had way to much fun with BB today Jul 27 08:03:21 * sgw really needs to sleep now, RP__ hope to catch you in your afternoon (or later ) tomorrow. Jul 27 08:03:31 dvhart: totally agreed Jul 27 08:03:40 sgw: 'night! Jul 27 08:04:09 night sgw Jul 27 08:33:37 and game Jul 27 08:33:47 14 hours of debug, 1 line fix Jul 27 08:33:50 * dvhart goes to bed Jul 27 08:35:20 'nite Jul 27 08:43:14 JaMa: I was rebuilding before sending youthe patchset and I've been hit by BASE_PACKAGE_ARCH abduction Jul 27 08:43:31 I'll fix this evening and finally send out to you Jul 27 08:43:51 yes and I had to remove few tune-*.inc from your changes Jul 27 08:44:06 my bad I did know about the overhaul;) Jul 27 08:44:32 ant_work: http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=5d1fe7a7144efe3792d89f981e3efd25ab5d6506 Jul 27 08:44:46 ant_work: but tune-strongarm isn't in oe-core yet Jul 27 08:45:00 is for collie Jul 27 08:48:54 I sent you latest tarball, pls see if there is anything more to change Jul 27 08:50:03 ah, yes, what about LICENSE = "unknown" Jul 27 08:50:24 RP__: ping Jul 27 08:53:06 ant_work: change that to valid LICENSE :) Jul 27 08:53:57 dongxiao: pong Jul 27 08:54:24 RP__: I have a question on multilib. For the BASE_LIB_tune-xxx value, on your latest branch (rpurdie/ml4), I saw for x86, it is named as "lib", and for x86_64, it is named as "lib64", so there is no "lib32" exists? Jul 27 08:54:49 dongxiao: hmm, yes, good point Jul 27 08:55:03 dongxiao: the defaults follow LSB but lib32 should work if the user sets it Jul 27 08:55:29 lib32 makes a good test value and I think we should put that in the example multilib config in local.conf.sample Jul 27 08:56:52 RP__: ok. but for mips we still keep lib32? Jul 27 08:57:33 dongxiao: mips has different layouts people are used to using Jul 27 08:57:47 and no LSB compliance to worry about iirc Jul 27 08:58:12 ant_work: please no more tar.gz.. just send patches to apply Jul 27 08:59:51 JaMa: Isn't there a tune-strongarm in OE-Core? Jul 27 09:00:25 RP__: tune-strongarm1100.inc only Jul 27 09:00:36 JaMa: ah, right Jul 27 09:00:54 so collie config needs to be updated to use that Jul 27 09:01:02 * RP__ notes the tune files are about to get overhauled Jul 27 09:01:31 or something like tune-strongarm1110.inc Jul 27 09:02:05 yeah this can wait after overhaul is finished and then create tune-strongarm1110.inc from tune-strongarm1100.inc easily Jul 27 09:05:43 RP__: on the latest master branch, I noticed the baselib change from lib to lib64 for qemux86-64 machine. Is it intentional? Jul 27 09:07:12 lianhao: Doesn't it only do that if you require multilib.conf ? Jul 27 09:07:30 lianhao: but in that case it is intentional, yes Jul 27 09:11:04 hi all Jul 27 09:12:03 RP__: but in that case, would the patch "64bithack.patch" in gcc4.6 which changes the default dynamic loader from "/lib64" to "/lib" be still correct? Jul 27 09:14:50 JaMa: do we want to start with linux 3.0 ? Jul 27 09:15:06 sure :) Jul 27 09:15:58 koen has it already on hx4700, would be good to have it in meta-handhelds too Jul 27 09:17:56 lianhao: simply put, no :( Jul 27 09:20:12 RP__: I don't understand for the same qemux86-64 machine, why the baselib is different for multilib situation? Jul 27 09:20:50 lianhao: ultimately we really should change the default to lib64 Jul 27 09:22:00 RP__: i find the reason why BPN is not set correctly. in the prune_suffix it use "MLPREFIX" to check. while in multilib.bbclass, the PN and MLPREFIX is not set in same place. so there is case where PN is remapped, but MLPREFIX is not set yet Jul 27 09:22:37 yuke: ah, so we need to set MLPREFIX earlier? Jul 27 09:23:03 RP__: yeah, i wonder if i could move the MPLPREFIX setting to multilib_virtclass_handler Jul 27 09:23:28 lianhao: we can probably drop the 64bithack patch since we now dynamically change it with: Jul 27 09:23:28 gcc-configure-common.inc: 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( *"/lib.*\)#\1 SYSTEMLIBS_DIR\2#' Jul 27 09:23:47 lianhao: or at least drop part of it Jul 27 09:23:55 RP__: or you have special consider when writing the code of setting MLPREFIX Jul 27 09:24:33 yuke: no, I think we can move it Jul 27 09:24:42 RP__: ok Jul 27 09:27:27 yuke: If you can confirm that works I can add that change to the patch Jul 27 09:27:51 lianhao: I'll drop the GLIBC_DYNAMIC_LINKER part of that patch Jul 27 09:29:43 RP__: yes, is pass the recipe parsing which breaks w/ this patch. the building is still ongoing, i will update you when the build is done Jul 27 09:29:55 yuke: thanks Jul 27 15:47:40 RP__: I am seeing an issue building armeb Jul 27 15:49:21 SITEINFO_ENDIANNESS is determined based on endian-little or endian-big being part of siteinfo_data and this endian-* is added based on HOST_ARCH and HOST_ARCH for cross-gcc is x86_64 so it gets set to 'le' for cross-gcc armeb builds Jul 27 15:51:00 question here is SITEINFO_ENDIANNESS it it for host machine that package being compiled will run on ? or is it for the target ? in cross compiled packages both will be same but we need to make distinction for cross package like cross-gcc Jul 27 15:51:36 Sounds like what Enrico reported Jul 27 15:51:42 problme shows up in Jul 27 15:51:43 meta/conf/machine/include/tune-xscale.inc:TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANNESS', d, 1) == 'le']}" Jul 27 15:51:48 Yup, it is Jul 27 15:51:56 now we get wrong TUNE_PKGARCH Jul 27 15:52:03 Re: [OE-core] [PATCH v2 1/1] siteinfo.bbclass: Port over oe.dev logic for site files Jul 27 15:52:55 we could use TRANSLATED_TARGET_ARCH instead of HOST_ARCH in siteinfo.bbclass Jul 27 15:53:20 but that may not be so correct for gcc-cross itself Jul 27 15:53:51 Tartarus: is there a solution ? Jul 27 15:54:00 I dont have my email fired up Jul 27 15:54:20 stop using an anon function for SITEINFO_ENDIANNESS :( Jul 27 15:55:38 I dont think its a problem in SITEINFO_ENDIANNESS if we have semantics clear Jul 27 15:55:52 SITEINFO_ENDIANNESS if its for host then its correct Jul 27 15:55:58 look for the email on gmane Jul 27 15:56:11 btw. I think we should not be caching siteinfo for cross and native recipes Jul 27 15:56:11 Enrico explained it a bit (and, sorry, multitasking) Jul 27 15:56:34 will do Jul 27 15:56:42 laterss gotta get ready Jul 27 15:56:43 We should be using the right siteinfo for some of the native* and cross* stuff Jul 27 15:56:45 k Jul 27 15:57:44 may be we dont need it at all for native and cross ? Jul 27 15:57:50 why would be need to use it Jul 27 15:58:09 main purpose imo is for cross compiling Jul 27 15:59:49 speed Jul 27 16:00:46 Morning all. Jul 27 16:01:15 Tartarus: sorry about grabbing up the rppppoe thing, I just forgot to remove it from my testing set. Jul 27 16:01:55 no worries Jul 27 16:02:05 khem: Doesn't this problem go away with the recent tune changes? Jul 27 16:03:54 RP__: that specific one? yeah. But isn't there the underlying issue Enrico pointed out? Jul 27 16:03:59 or did I read his email too quickly? Jul 27 16:07:03 Tartarus: Well, the tune files no longer use SITEINFO_ENDIANNESS Jul 27 16:07:24 Tartarus: so it being expanded early becomes a non-issue for TUNE_PKGARCH Jul 27 16:07:36 ok Jul 27 17:14:57 RP__: infact this shows up with the recent changes Jul 27 17:15:44 RP__: it might be that with the new tune overhaul it will become a bit better Jul 27 17:16:35 RP__: but original problem where we use site files even for native and cross packages needs some thought Jul 27 17:18:14 I disagree, we should use the site files Jul 27 17:18:22 It helps make sure that just maybe they'll be correct :) Jul 27 17:19:02 using then as test case ? Jul 27 17:19:15 for cross compilers that will churn your whole rfs ? Jul 27 17:19:50 I'm saying that yes, we should be loading the site files we have that are appropriate to the host Jul 27 17:19:56 Since either it's a small speed win Jul 27 17:20:02 Or it's going to show bugs that we would have on the target Jul 27 17:21:32 it wont show bugs per say most probably it will inject them unless they show up as build problems Jul 27 17:21:50 and make it hard to detect Jul 27 17:22:16 Not as hard as on the target Jul 27 17:22:30 Buggy siteinfo files are things we need to fix Jul 27 17:22:53 I don't like saying "oh, our x86/x8664 ones are crap, lets just not load them" Jul 27 17:22:57 I have debugged issues on target packages that were introduced by wrongly build cross compiler Jul 27 17:23:03 they are not easy to find Jul 27 17:23:25 agreed Jul 27 17:23:29 arg, I had bitbake git pointed at oe.net Jul 27 17:23:40 So lets get our site info stuff fixed so we have the minor speed win and no bugs :) Jul 27 17:23:47 * Tartarus is poking at some of the x8664 stuff now Jul 27 17:26:41 PACKAGE_ARCH=${TUNE_PKGARCH} Jul 27 17:27:04 so I wonder if that should be set for recipes inheriting cross bbclass Jul 27 17:29:24 I think package arch for cross recipes should be set to point to host arch Jul 27 18:16:08 hey.. hows it going? Jul 27 18:32:56 See my Q yesterday in #oe? Jul 27 18:33:20 I forget what the 32bit ppc on 64bit hw is, but for Freescale anyhow it is something like "classic" Jul 27 18:33:37 * Tartarus doesn't know about IBM stuff tho Jul 27 18:36:02 RP__: merging sgw's pull request yet? I wanna rebase this stuff :) Jul 27 18:37:05 Tartarus: I thought he did, I have not sent emails yet. Jul 27 18:41:54 * Tartarus updates Jul 27 18:44:31 yeah, there it is Jul 27 18:44:47 khem:this is why I don't think we should wait to fix the mls Jul 27 19:04:03 Tartarus what do you mean? is there another PPC abi or? Jul 27 19:06:43 Well, I don't have access to IBM 64bit hw Jul 27 19:06:46 just Freescale Jul 27 19:07:02 I believe for 64bit, they can run the same binaries Jul 27 19:07:57 (Or rather, I understand the CS folks have a 64bit PPC they've tested stuff on, and it wasn't a Freescale board since we didn't get one after I queried the CS folks on what they had) Jul 27 19:08:12 and I know for 32bit binaries, classic ppc stuff runs on the Freescale board Jul 27 19:08:33 On the ML you said ppc603e-m64 wasn't a valid multilib, just an example Jul 27 19:08:43 but, uh, to me that sounds like the 32+64bit multilib case for ppc Jul 27 19:10:49 Tartarus there is no such thing as a 64-bit ppc603e.. ;) Jul 27 19:11:09 The freescale 5500? is the 64-bit one.. it will run both ppc64 and regular ppc apps at the same time (in a normal multilib config) Jul 27 19:11:16 Right Jul 27 19:11:25 So how do you describe the 64bit+32bit multilib for ppc Jul 27 19:13:17 Since galak will try and build that and I might too if I have the time Jul 27 19:16:55 I guess classic ppc multilib will not work on freescale ppc Jul 27 19:17:09 but otherwise it should be same Jul 27 19:18:35 what classic multilib? Jul 27 19:18:43 Ahh.. Jul 27 19:18:56 I'm saying, how do you describe, for powerpc, give me 32bit "classic" and 64bit too Jul 27 19:18:57 With the code we have there now, you'll need to describe a new ppc64 tune... Jul 27 19:19:09 (since there's just, as far as I know, 1, 64bit abi) Jul 27 19:19:19 You'll likely want to describe say a 5500.. set the options for 5500 feature list to -mcpu=... Jul 27 19:19:37 bah let me write it up and paste it.. Jul 27 19:19:38 Well, 970, etc, would care too Jul 27 19:19:41 Thanks :) Jul 27 19:20:01 But, in CS terms anyhow, we don't have a specific 970 multilib and a specific e5500 multilib, etc Jul 27 19:20:13 we kind of do Jul 27 19:20:14 Just the normal 32bit sysroot also has 64bit libs Jul 27 19:20:38 But in OE terms, we'll be wanting to have 32+64bit be a thing, for powerpc Jul 27 19:20:42 the multilibs are in the sysroot.. at least the CS deliveries we get at WR.. the libc directory is just a sysroot with some funky directory namings.. Jul 27 19:20:43 So lets have that from the get-go :) Jul 27 19:20:51 but PPC is just /lib and lib64 Jul 27 19:20:55 fray, right Jul 27 19:21:03 There's no te500v2 sysroot-alike Jul 27 19:21:06 (there is a separate soft directory as well) Jul 27 19:21:08 just the main sysroot has both cases Jul 27 19:21:19 yes, thats hte intention.. it'll always be lib or some variation of that Jul 27 19:21:29 k Jul 27 19:21:30 sysroot only contaisn the libraries relevant to that machine Jul 27 19:21:35 Yeah Jul 27 19:21:40 So, I'll give you a few to writesomething up Jul 27 19:21:44 and/or update the branch :) Jul 27 19:22:02 If you give me a set of branches/etc to pull, I can even try and build+boot it I think Jul 27 19:22:04 * Tartarus checks the lab Jul 27 19:22:21 5500 board is still in the lab, so, yeah, I can try stuff :) Jul 27 19:25:26 http://pastebin.com/46BZt1xV Jul 27 19:25:36 I pulled the naming out of my butt.. so it might be a bit funky.. Jul 27 19:25:44 the point is that both a 32-bit and 64-bit are defined.. the 32-bit is the default.. Jul 27 19:26:00 if you want to generate 64-bit, you would specify ppc970-64 as the alternative tuning Jul 27 19:26:27 (I'm also not 100% sure that ppc970 -m32 is a valid gcc tune.. if it's not then we'd need to expand it to something that is valid for 32-bit.. Jul 27 19:28:29 I know -mcpu=e5500 -m32/-m64 is fine Jul 27 19:28:59 ya.. replace 970 w/ e5500 and this should work Jul 27 19:29:28 Can you and toss it into your branch? Jul 27 19:29:31 (Note, the tunings on PPC are a bit weak currently.. so I'm sure there are missing options) Jul 27 19:29:34 which one? Jul 27 19:29:36 Save Kumar and I a few min Jul 27 19:29:56 e5500 tune files, like the paste above with %s/ppc970/e5500/g Jul 27 19:56:40 Tartarus: I have fixed automailer for git commits Jul 27 19:56:53 from now on you should get email notifications Jul 27 19:57:11 ARM_INSTRUCTION_SET is no longer used right? Jul 27 19:57:19 eglibc no longer builds on armv4t.. Jul 27 19:58:11 JaMa: hmm it is used Jul 27 19:58:22 are you on oe-core Jul 27 19:58:26 yes Jul 27 19:58:42 it should build Jul 27 19:58:42 khem: http://paste.pocoo.org/show/447620/ Jul 27 19:59:29 how old is your snapshot Jul 27 20:00:16 head Jul 27 20:00:31 before merging todays tune- changes it worked fine Jul 27 20:00:47 yeah tuning overhaul has made it redundant Jul 27 20:01:17 khem: thanks Jul 27 20:02:05 tune-thumb.inc is no longer used Jul 27 20:02:13 which means ARM_INSTRUCTION_SET is useless Jul 27 20:02:20 hmmm Jul 27 20:03:12 yes Jul 27 20:03:39 that's what I meant.. and I guess that's the reason why eglibc fails now Jul 27 20:05:42 not sure if there is better way to disable thumb for some package for all arm archs.. setting TUNENAME_pn-eglibc = "armv4" for every armvN seems wrong Jul 27 20:05:52 JaMa: you have to add thumb to TUNE_FEATURES Jul 27 20:06:14 err step back Jul 27 20:07:09 actually thumb is a DISTRO_FEATURE Jul 27 20:07:27 JaMa: about gnu-tar license, in 2004 was GNU General Public License as published by Jul 27 20:07:27 the Free Software Foundation; either version 2, or (at your option) Jul 27 20:07:27 any later version. Jul 27 20:07:45 dtoday it is GPLv3 I understand Jul 27 20:07:54 khem: and its in TUNE_FEATURES from meta/conf/machine/include/arm/arch-armv4.inc already Jul 27 20:08:20 khem: I'm looking for way to disable it in few recipes Jul 27 20:08:35 while keeping interwork enabled Jul 27 20:08:56 ant__: GPLv2+ Jul 27 20:09:01 JaMa: ok Jul 27 20:09:50 JaMa: correct. Jul 27 20:10:18 JaMa: I guess We need to DISABLE_TUNE_FEATURE Jul 27 20:11:13 khem: klibc 1.5.24 released today incorporates our kexec_load syscall patch. One less. Now, if you only could confirm me the -isystem patch is unnecessary... Jul 27 20:12:20 I tested without and could not find issues Jul 27 20:12:23 ant__: will check havent looked into klibc lately Jul 27 20:12:38 it well be easy to remove, anyway Jul 27 20:12:48 thx Jul 27 20:13:27 khem: from last Mark's reply in Re: [OE-core] [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle Jul 27 20:13:35 Say you want all of your system thumb, except for a few specific programs.. Jul 27 20:13:35 TUNENAME = "armv4t" Jul 27 20:13:35 TUNENAME_pn-mysql = "armv4" Jul 27 20:14:25 but DISABLE_TUNE_FEATURE looks better Jul 27 20:14:33 ant__: isystem should not be needed with sysroot Jul 27 20:14:46 as we don't want to list all archs where thumb should be disabled Jul 27 20:16:53 I guess armv4t TUNENAME implies thumb mode is compulsory Jul 27 20:17:17 but in general terms its confusing since armv4t means it supports thumb Jul 27 20:17:23 but is optional Jul 27 20:17:37 fray: ^^ can you shed some light on it? ^^ Jul 27 20:17:39 so TUNENAME has a different semantic Jul 27 20:18:02 imo it should be renamed to armv4+thumb+x+x Jul 27 20:18:04 etc Jul 27 20:18:46 * khem should have spent time reviewing those patches Jul 27 20:19:22 hmm from my understanding TUNE_FEATURES should be used to say what some machine supports and distro can disable/ignore some features Jul 27 20:19:43 but to say what I want to be used for some recipe it's something else Jul 27 20:19:46 yes Jul 27 20:19:55 this sort of thing belong thee Jul 27 20:20:03 like ARM_INSTRUCTION_SET was Jul 27 20:20:36 not saying if current machine supports thumb or not Jul 27 20:20:39 * khem does post commit review Jul 27 20:20:58 just saying what can be used in code if available Jul 27 20:21:18 code/resulting binary Jul 27 20:25:00 khem: ok, thx. patch was from pre-sysroot era Jul 27 20:38:20 JaMa: it is SITEINFO_ENDIANESS in oe-core isn't? Jul 27 20:38:47 ant__: no its fixed to have NN Jul 27 20:39:08 ah, ok, we still have them in linux.inc and co. Jul 27 20:40:03 * JaMa going to bed Jul 27 20:40:29 in meta-oe ? Jul 27 20:40:43 atm in meta-zaurus Jul 27 20:40:48 ah ok Jul 27 20:40:53 since I fixed oe-core Jul 27 20:41:45 ant__: this is right: meta-zaurus/recipes-kernel/linux/linux-kexecboot.inc: if [ "${SITEINFO_ENDIANNESS}" = "be" ]; then Jul 27 20:42:02 that should be fine Jul 27 20:42:05 ok, I've already reverted Jul 27 20:42:13 thx Jul 27 20:43:18 JaMa: we'll clean the inc files afterwards Jul 27 20:45:13 I'm tempted to do it now but I'm resisting pretty well... Jul 27 20:46:44 after today changes I won't be able to test it before leaving for vacation, I guess.. :/ Jul 27 20:48:15 sorry I'm back.. had a "construction" emergency.. :P (Amy's building me a shed and she needed help so she didn't die..) Jul 27 20:49:39 heh Jul 27 20:49:44 JaMa: I'll just switch to latest klibc Jul 27 20:49:52 So, clearly, her foot is much better now :) Jul 27 20:50:00 So to answer the question of why we don't have a disable tune feature.. it's because that would affect the output package arch.. Jul 27 20:50:13 the contents of armv4 and armv4t are different.. so we want a different package arch Jul 27 20:50:37 if you set up a package feed, and mix and match arm and thumb compiled code w/o a different package "arch" then people will have no idea whats there Jul 27 20:50:39 fray: thumb is an optional feature Jul 27 20:50:53 and currently if you chose armv4t then its forced Jul 27 20:51:00 that seems wrong to me Jul 27 20:51:14 remember these are TUNEing names.. not canonical arches Jul 27 20:51:30 the tuning name if you want thumb to be used includes a 't'.. if it doesn't have a Jul 27 20:51:34 't' then thumb isn't there Jul 27 20:51:51 it's not just armv4.. it's all of them BTW.. Jul 27 20:52:52 the key thing to remember is tunings are more hten just CC options.. they affect (on some arhcitectures) teh canonical arch, the pkg arch, the compatible machine settings, and potentially other settings liek ABI, FPU, etc.. Jul 27 20:53:20 ARM is somewhat unique that it has two instruction sets with a common ABI... AFAIK nothing else really has that.. Jul 27 20:56:11 currently the only difference between "armv4" and "armv4t" is the later tune name enables thumb.. Jul 27 20:56:24 and in most of ARM thats the case Jul 27 20:57:54 but how to disable thumb for all armv[4567] if for some recipe it's known to produce build error or runtime issues? Jul 27 20:58:04 sgw: Any opinion on turning on DESKTOP on busybox in oe-core? Jul 27 20:58:14 It's needed, I think (and am testing) for some of the tests for core-image-sato to pass Jul 27 20:58:22 since it wants ps -e, which isn't in busybox w/o it Jul 27 20:58:27 * Tartarus goes to confirm now Jul 27 20:58:35 fray: without repeating TUNENAME_pn-mysql 4 times? Jul 27 20:58:49 core-image-sato should be using the discrete items, not busybox Jul 27 20:59:16 JaMa, I don't understand that comment Jul 27 20:59:26 Well, ps isn't from procps or util-linux Jul 27 20:59:30 eglibc fails to build if thumb is enabled Jul 27 20:59:37 i'll poke the rootfs image in a sec Jul 27 20:59:42 I have the same problem with om-gta02 (arm920t) Jul 27 20:59:49 and nokia900 cortex-a8 Jul 27 20:59:52 JaMa, then eglibc needs to be fixed then.. Jul 27 21:00:13 so there is ARM_INSTRUCTION_SET = "arm" in eglibc.inc Jul 27 21:00:25 fray: Yeah, a ton of things come from busybox Jul 27 21:00:29 which was forcing no-thumb while building eglibc Jul 27 21:00:55 even for architectures/machines which have thumb enabled by default Jul 27 21:01:08 now ARM_INSTRUCTION_SET from tune-thumb.inc is ignored Jul 27 21:01:20 because tune-thumb.inc is no longer included Jul 27 21:01:43 and thumb is enabled based on TUNENAME without respecting ARM_INSTRUCTION_SET Jul 27 21:02:38 I'm looking, but it was my understanding that the latest eglibc would build with thumb enabled Jul 27 21:02:58 see the log I pasted Jul 27 21:03:19 if we check ARM_INSTRUCTION_SET before setting thumb here: Jul 27 21:03:20 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb", "-mno-thumb", d)}" Jul 27 21:03:42 please repaste the location of the log, I don't have it on my screen Jul 27 21:03:54 And yes, from what I can find, eglibc should be capable of being built with thumb enabled.. Jul 27 21:03:56 http://paste.pocoo.org/show/447620/ Jul 27 21:04:44 same error on cortex? Jul 27 21:05:34 there is at least 14 recipes disabling it the same and whole qt4e and qt4x11 bbclass are disabling too Jul 27 21:05:46 iirc yes.. but I've removed whole tmpdir already Jul 27 21:06:49 I'll have to play with this to get further.. but the expectation was that you would be able to build a fully thumb based system, including eglibc and everything else.. Jul 27 21:07:02 if it doesn't compile with thumb.. then likely there is bad assembly in the package and that should be fixed Jul 27 21:07:30 I can't speak of qt4 in OE.. but I know the commerical version does that a thumb version Jul 27 21:08:15 fixing broken compiler won't be so easy for every recipe we have in oe-core and then the same with every layer Jul 27 21:09:20 thats understandable.. but calling a non-thumb version of eglibc "armv4t" (package arch) is simply wrong.. since it isn't built with thumb then.. Jul 27 21:09:39 I don't have an immediate answer for this.. we'll have to fix it.. but simply disablign thumb in select packages seems like the wrong answer to me Jul 27 21:11:13 agreed about armv4t.. but if we can disable thumb in ie eglibc and with that changing package arch to armv4 only, then there won't be any armv4t eglibc which is fine as armv4t machines have also armv4 feeds enabled Jul 27 21:11:37 currently the way you do that is with the TUNENAME-pn... Jul 27 21:11:55 let me continue to look up how to do this stuff.. and see if I can come up with a less hacky solution Jul 27 21:12:09 and as soon as someone fixes eglibc to build with thumb then it would be upgraded from armv4t feed where possible Jul 27 21:12:41 fray: but then we have to keep TUNENAME-pn-eglibc in ie tune-arm920t.conf? Jul 27 21:13:01 potentially.. (for now) Jul 27 21:13:09 fray: what if we need TUNENAME-pn-foo and foo is recipe in some obscure layer somewhere? Jul 27 21:13:49 it can go in the layer configuration file.. but I agree.. it's hacky for now.. we'll get it fixed.. Jul 27 21:14:07 I'm just not yet sure how we'll be fixing it.. perhaps something like: Jul 27 21:14:10 and we cannot say TUNENAME-pn-eglibc = "armv4"\nTUNENAME-pn-eglibc = "armv5"\nTUNENAME-pn-eglibc = "armv6"\nTUNENAME-pn-eglibc = "armv7" in the recipe I guess Jul 27 21:14:56 fray: if it's layer configuration file then we need to read that configuration file only for some machines right? Jul 27 21:15:09 TUNENAME = "${@["arm920", "arm920t"][${ARM_INSTRUCTION_SET} == "arm"]}" Jul 27 21:15:20 (I'm guessing that is slightly wrong, but thats the idea) Jul 27 21:15:40 that would preserve the existing control, but use the newer mechanism to control the tunename. Jul 27 21:15:47 fray: this is for openembedded-core/meta/conf/machine/include/arm/feature-arm-thumb.inc right? Jul 27 21:16:02 no, that would be the default tune in the tune-*.inc files Jul 27 21:16:23 each of them would need something similar so that a reasonable switch would occur based on individual core tunings Jul 27 21:16:52 but does it keep thumb-interworking enabled? Jul 27 21:16:53 I'm not sure thats the right answer either, but it's likely part of it Jul 27 21:17:23 as I answered on the oe-core mailing list.. my expectation was thumb-interworking was always enabled.. but that might have been incorrect.. if it is.. then we've got another variant we need to deal with Jul 27 21:17:33 I need to sleep() now.. but I hope it's clear what's the problem .. Jul 27 21:17:56 yes, I think I understand the issue.. just not sure of an immediate solution... I'll keeping looking into it.. Jul 27 21:18:19 but it's likely fix the packages first.. put an automatic TUNENAME setting based on arm configurations in place as well.. and make sure interworking is enabled whenever it should be Jul 27 21:20:43 JaMa: do I include old tune-strongarm.inc finally?? Jul 27 21:21:28 (in m-z layer) Jul 27 21:28:20 Blah, this is quite silly Jul 27 21:28:30 There's a way to say what tests to run on an image by default, right? Jul 27 21:28:41 core-image-sato does zyppher and rpm, and doesn't install them Jul 27 21:29:04 And the connman test is a tiny bit silly (but will patch!) since it does ps -eo cmd | cut | grep -c Jul 27 21:29:13 when it could just ps -eo comm | grep -c and get its result Jul 27 21:29:21 and work with busybox ps -o formatting options Jul 27 21:45:03 * Tartarus wonders what ps -ef cmd was supposed to mean since real ps pukes and busybox just gives a ps -e Jul 27 21:45:18 * Tartarus assumes ps -eo cmd, updates Jul 27 21:46:13 ... to ps -ef instead since it's a "what's wrong?" output Jul 27 21:57:23 RP: does this patch need rebuilding all recipes or just the image recipe Jul 27 22:03:11 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=0960f3e0502b7b26a09d4eed599e5f31cd9aeca0 Jul 27 22:08:27 sgw: Sending patch to oe-core list now, as a patch not pull request. Lemme know when you've queued it please so I don't worry it's lost :) Jul 27 22:12:47 Tartarus: ack Jul 27 22:15:58 thanks Jul 27 22:16:08 * Tartarus readies the siteinfo pull request Jul 27 22:16:55 hmm, what? sgw, can you see if oe-core + qemux86_64 + world parses for you? Jul 27 22:17:16 http://pastebin.com/rKEPPNLG is what I just saw Jul 27 22:17:32 but my build dirs were kinda odd / dirty Jul 27 22:17:34 trying clean now Jul 27 22:17:50 Tartarus: I will fire up an oe-core Jul 27 22:18:57 thanks Jul 27 22:19:01 Tartarus: eglibc or uclibc? Jul 27 22:19:05 eglibc Jul 27 22:19:18 * Tartarus is gonna do one or two world builds after posting (done some already on this series) Jul 27 22:19:28 and then get to the empty siteinfo test Jul 27 22:23:03 Tartarus: I did not even get that far! Jul 27 22:30:24 * Tartarus is waiting on the psuedo cycle to finish Jul 27 22:31:52 Tartarus: see this one: Jul 27 22:31:52 ERROR: Unable to parse conf/bitbake.conf: Failure expanding variable None, expression was ${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)} ${@bb.utils.contains("TUNE_FEATURES", "m64", "-m64", "", d)} which triggered exception AttributeError: 'module' object has no attribute 'contains' Jul 27 22:32:13 clean master / clean build area / Jul 27 22:32:46 I know, I need an updated bitbake, Jul 27 22:33:00 * sgw is so used to it being part of yocto Jul 27 22:34:46 heh Jul 27 22:35:02 * Tartarus uses kergoths scripts/git submodules and make updates fetches everything Jul 27 22:40:13 heh, either our grub doesn't support x86_64 Jul 27 22:40:22 or initramfs-live needs to say only x86 Jul 27 22:42:24 * Tartarus makes grub do x86_64 Jul 27 22:43:26 Tartarus: I think you need to use grub2, we need to import that from the meta-intel/common into oe-core I think. Jul 27 22:44:15 and fix initramfs-image-live Jul 27 22:44:17 Probably better for me to fix initramfs-live to have compatible Jul 27 22:44:21 :) Jul 27 22:44:25 right Jul 27 22:44:35 Also, there's some funny multi provides Jul 27 22:45:24 what do you mean by that? Jul 27 22:46:13 it's already scrolled by, bla Jul 27 22:46:35 but, glibc removal has made some a/b/c/d provide glibc-utils, etc, things pop up Jul 27 22:46:49 sec, i'll re-parse and pastebin it Jul 27 22:47:08 I understand what you are talking about, so you patched in phil's change? Jul 27 22:47:25 took me a second longer to parse multi provides Jul 27 22:48:07 No, I'm on 1fe892a + contrib trini/update-siteinfo-round-2-v1 Jul 27 22:48:59 http://pastebin.com/KXz5UdGf is what I'm talking about Jul 27 22:49:02 it should also be RDEPENDS_${PN} Jul 27 22:49:43 Indeed, something is dorked up Jul 27 22:49:45 this is a world build right? Jul 27 22:49:49 Just trying to not start a 3rd branch right now Jul 27 22:49:50 yes Jul 27 22:50:07 qemux86-64 Jul 27 23:03:36 * Tartarus sends **** ENDING LOGGING AT Thu Jul 28 02:59:57 2011