**** BEGIN LOGGING AT Thu Jun 09 02:59:57 2011 Jun 09 08:32:31 RP__: ping Jun 09 08:32:38 yuke: pong Jun 09 08:32:44 yuke: I'm on the bridge? Jun 09 08:33:18 RP__: looks i can not enter the bridge, so i resend you a new bridge Jun 09 08:33:27 yuke: ah, ok Jun 09 08:33:36 RP__: strange, i can not enter the old bridge Jun 09 08:33:57 yuke: do you have the new number there? Jun 09 08:34:08 * RP__ is waiting for his mail to catch up Jun 09 08:39:25 RP__: thanks for bitbake sync! Jun 09 08:45:53 I have a (possibly silly) bitbake question -- in bitbake/lib/bb/cooker.py there is a check for the Psyco JIT compiler, and a warning is printed if the compiler is not present. However, Psyco is only available for Python 2.2 - 2.5 (AFAIK), and current bitbake requires Python 2.7 (again, AFAIK). Would it be reasonable to make the Psyco test conditional on a Python version check in cooker.py? Jun 09 09:26:15 JaMa|Wrk: its not quite there yet but close :) Jun 09 09:26:38 thhp: I'd accept a patch to remove it actually Jun 09 09:26:47 thhp: In fact I might just do that now... Jun 09 09:30:30 RP__: know from bitbake-devel announcement, but thanks to master-poky I noticed "persist_data: Add back code to retry in the case of locked database errors" which I really like, because on slow buildhost I get this at least on every 3rd image build and have to restart it manually Jun 09 09:31:11 JaMa|Wrk: That patch helps? Perhaps I should merge it to master then?... Jun 09 09:32:04 RP__: I did only 2 builds on that slow buildhost today.. let me test it a bit more and I'll report Jun 09 09:32:30 JaMa|Wrk: sounds good, thanks Jun 09 09:35:27 thhp: I've written a patch dropping it Jun 09 09:36:05 thhp: http://git.openembedded.net/cgit.cgi/bitbake/commit/?h=master-poky&id=ccb523f82fb432f552736eba2463b4ba40deac7a Jun 09 09:53:32 RP__: ah, grand. I'm behind the times, I guess Jun 09 09:53:53 thhp: Well, I only just wrote it when you reminded me Jun 09 09:55:10 RP__: sorry, my bad -- didn't read far back enough in the irc history... thanks making the mod :-) Jun 09 13:51:30 RP__: 16 builds today without single "database is locked" exception.. so I think that bitbake hack works right Jun 09 13:52:02 JaMa|Wrk: I will merge it on those grounds I think as your experience agrees with someone elses Jun 09 13:52:55 thanks Jun 09 14:01:34 Does anyone here have tar < 1.24 installed on their system? Jun 09 14:02:18 RP__: yep Jun 09 14:02:30 1.23 on my fedora 14 build box Jun 09 14:02:38 bluelightning: What is the first line of tar --version ? Jun 09 14:02:46 tar (GNU tar) 1.23 Jun 09 14:02:51 bluelightning: cool, thanks Jun 09 14:03:19 * RP__ is testing a patch to only build tar-replacement-native when tar is < 1.24 Jun 09 14:05:47 figured... I immediately wondered whether there was a better way to determine the version rather than parsing that output Jun 09 14:06:02 is the output dependent on system language? hopefully not... Jun 09 14:06:49 bluelightning: I'd hope that first line isn't Jun 09 14:07:05 well there's no English in it right now so it shouldn't Jun 09 14:07:07 * RP__ is open to better ideas Jun 09 14:07:13 * bluelightning is thinking ;) Jun 09 14:14:50 what there ought it be is a kind of xdg-utils type frontend for all package managers that gives you the version of a package Jun 09 14:16:34 bluelightning: sadly there isn't Jun 09 14:17:28 no :/ Jun 09 14:17:42 oh well, I guess parsing the tar output is the only real way Jun 09 14:20:02 I'm trying to support a CSL MIPS toolchain, basing my work on external-csl-toolchain_2008q3-72.bb and tcmode-external-csl2008q3.inc. Jun 09 14:20:52 In tcmode-external-csl2008q3.inc TARGET_VENDOR is set to "-none", meaning TARGET_SYS ends up being evaluated as "arm-none-linux" Jun 09 14:21:34 But for the CSL MIPS toolchain, the naming convention of the binaries is as per "mips-linux-gnu-gcc" Jun 09 14:22:01 Meaning that whatever I set TARGET_VENDOR to, I get the wrong TARGET_SYS, and my toolchain naming is broken Jun 09 14:22:36 thhp: sounds like you want TARGET_VENDOR = "" and TARGET_OS = "linux-gnu" ? Jun 09 14:22:43 I've tried hacking around this by forcing TARGET_SYS in local.conf -- this seems to work, but I get both "mips-linux-gnu" AND "mips-none-linux" strings in my environment, so something is clearly wrong Jun 09 14:23:02 RP__: would setting TARGET_OS have other side effects? Jun 09 14:23:29 thhp: I think it might work but I'm not 100% sure Jun 09 14:23:50 we do set it to linux-gnueabi for some targets Jun 09 14:23:56 so it can be overridden Jun 09 14:24:50 RP__: sounds worth a try, then. I'd sooner tell OE "this is the toolchain name" than e.g. add symlinks in my toolchain to suit OE (my current approach). Jun 09 14:25:41 thhp: Certainly worth a try. If it fails I'd be interested to know how Jun 09 14:29:34 bluelightning: Could you test http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/temp5&id=d002a207dc97987dc472b9382b2ca900992a0421 please? Jun 09 14:30:51 RP__: will do so now Jun 09 14:31:58 bluelightning: thanks Jun 09 14:41:42 hi ant_work Jun 09 14:42:32 hello bluelightning Jun 09 14:45:19 RP__: well, it has started to build tar-replacement-native on my tar 1.23-using system, so I guess it's working Jun 09 14:45:34 bluelightning: Thats what I needed to know, thanks :) Jun 09 14:46:32 Hm, I've added TARGET_OS = "linux-gnu" into tcmode-external-csl-mips-4.2-177.inc, but bitbake -e reports TARGET_OS is "linux". I suspect something else is overwriting my setting. Is there any way to tell how a variable is set in the bitbake -e output? Jun 09 14:47:31 bluelightning: have you already imported klibc recipe in your overlay? Jun 09 14:48:05 ant_work: I pulled in klibc.bbclass so it at least parses but not the recipe Jun 09 14:48:14 I could add the recipe though Jun 09 14:48:26 there are probably lots of bits missing Jun 09 14:48:37 I ask because I'm still doubtful about the arch Jun 09 14:48:54 (after reading uclibc is not more machine-specific) Jun 09 14:49:34 hmm, well I don't know much about that, I'll take your advice on what to include or exclude Jun 09 14:49:43 I plan to merge som epackaginf changes, following debian Jun 09 14:50:02 OK, I see that tclibc-glibc.inc sets TARGET_OS for me. I can prevent it overriding my setting by using "?=" rather than "=" in the glibc inc file Jun 09 14:50:29 But now I get this: http://pastie.org/2042996 Jun 09 14:55:24 Adding an entry for "mips-linux-gnu" to get_siteinfo_list() in siteinfo.bbclass allows the bitbake parsing to complete Jun 09 14:57:31 RP__: with the mod to TARGET_OS assignment in tclibc-glibc.inc, and the extra entry in siteinfo.bbclass, it seems I'm building at least as well as I was before using symlinks in the toolchain Jun 09 14:58:25 thhp: sounds like progress Jun 09 14:58:56 thhp: btw, if you fancied writing up what you had to do, it might act as a useful guide for others Jun 09 14:59:00 RP__: but the lookup table in siteinfo.bbclass raises another concern: the CSL toolchain binaries are all "mips-linux-gnu-XXX", but they support both little and big endianess via commandline args. The table in siteinfo.bbclass appears to make an endianess decision based on whether we're "mips" or "mipsel". Jun 09 14:59:34 RP__: once we've got something working I intend to do that, there's quite a learning curve for oe ;-) Jun 09 15:18:10 bluelightning: hold on with klibc, pb_ says I could try to remove PACKAGE_ARCH = "${MACHINE_ARCH}" Jun 09 15:18:27 ant_work: ok Jun 09 16:05:40 dvhart: I'm on task 3462 of 4169 so theoretically sometime in the next few days I'll be able to work with you :-) Jun 09 16:53:47 dvhart: oh, btw, thanks for the email about the BSP status Jun 09 17:24:23 * bluelightning -> home Jun 09 17:32:42 RP__, fyi I have a fix for the bitbake -s issue, prepping a pull request Jun 09 17:32:53 it's a trivial fix Jun 09 17:33:00 zenlinux_laptop: sounds good, I like fixes like that :) Jun 09 17:39:54 RP__, so this pull request - do I send it to bitbake-devel, oe-core, or poky? Jun 09 17:40:25 I created the commit based on poky master Jun 09 17:40:37 but the fix is in bitbake's cache.py Jun 09 17:40:38 zenlinux_laptop: send it to bitbake-devel Jun 09 17:40:41 ok Jun 09 17:40:54 ideally it needs to be based on the bitbake tree but I'm not worrying about that detail atm Jun 09 17:41:11 * RP__ -> afk Jun 09 17:45:26 I'll do it the right way - sending email is borked on the machine I created the fix on anyway Jun 09 18:16:59 jefferai, hehe Jun 09 18:17:07 jefferai, cores are king Jun 09 18:17:30 yeah, I need to get me a few dual-socket six-core procs Jun 09 18:17:41 24cores++ Jun 09 18:17:44 jefferai, that happens to be exactly what I'm running Jun 09 18:17:48 ah, nice Jun 09 18:17:56 well, working at Intel I imagine it's not a big problem for you Jun 09 18:17:57 :-) Jun 09 18:18:03 CPUs are cheap :) Jun 09 18:18:09 yes, and no Jun 09 18:18:17 most of them are cheap Jun 09 18:18:20 the super ultra fast ones are not Jun 09 18:18:24 at least, not initially Jun 09 18:18:32 but also mostly uncessary unless you're a speed freak Jun 09 18:19:51 it's almost time for me to get a new workstation, and this time I think I'm going to custom-build, so I should be able to put in some fun stuff Jun 09 20:19:52 nitink, ping Jun 09 20:20:34 dvhart: pong Jun 09 20:20:49 nitink, wondering if you have some advice on how to switch between toolchains Jun 09 20:21:02 I changed the GCCVERSION from 4.6 to 4.5.1 in tcmode Jun 09 20:21:10 that worked, but going back to 4.6 seems difficult Jun 09 20:21:20 just changing the GCCVERSION variables doesn't work Jun 09 20:21:35 I guess because the 4.5.1 is now installed in the host native paths Jun 09 20:21:58 when I tried to get out of this last time I hosed my build tree and had to scrap it all Jun 09 20:21:58 dvhart: 2 versions of toolchain won't work well together Jun 09 20:22:14 so I should completely rebuild? Jun 09 20:22:36 you can do cleanall on gcc recipes Jun 09 20:22:46 there seem to be several of those Jun 09 20:22:51 I did a cleanall of gcc-cross Jun 09 20:23:04 is there a set way to rebuild them all? Jun 09 20:23:08 clean/rebuild Jun 09 20:23:25 dvhart: i do cleanall on all (including nativesdk) Jun 09 20:23:41 ok, how do I enumerate what "all" is? Jun 09 20:24:05 cleanall and rebuild of gcc recipe fails Jun 09 20:24:06 holdon, I will get you the list Jun 09 20:24:14 fails ? Jun 09 20:24:31 | configure: error: could not find a working compiler, see config.log for details Jun 09 20:24:42 from: Jun 09 20:24:43 checking compiler arm-poky-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize --sysroot=/build/poky/master/beagleboard/tmp/sysroots/beagleboard -O2 -pipe -g -feliminate-unused-debug-types ... no Jun 09 20:25:12 this is from doing: "bitbake gcc -c cleanall; bitbake gcc" Jun 09 20:25:27 after having changed GCCVERSION from 4.5.1 to 4.6.0 Jun 09 20:27:10 dvhart: bitbake -f -c cleanall gcc gcc-cross gcc-cross-initial gcc-cross-intermediate gcc-runtime libgcc Jun 09 20:28:17 aha, libgcc Jun 09 20:28:22 I think that is what I was hitting Jun 09 20:28:32 probably need that to match the compiler :) Jun 09 20:29:04 I think u r using 4.5.1 just for arm kernel Jun 09 20:29:17 I'm trying to get back to all 4.6.0 now Jun 09 20:29:25 as khem has proposed a fix/workaround Jun 09 20:29:30 in that case sdk, nativesdk recipes should not bother you Jun 09 20:29:39 I see Jun 09 20:29:40 ok Jun 09 20:29:53 then clean sdk, nativesdk recipes too Jun 09 20:30:42 ERROR: Nothing PROVIDES 'sdk' Jun 09 20:30:55 bitbake -f -c cleanall libgcc-nativesdk gcc-runtime-nativesdk gcc-crosssdk gcc-crosssdk-initial gcc-crosssdk-intermediate Jun 09 20:31:45 thanks nitink Jun 09 20:31:58 I could have found those with bitbake -s | grep gcc Jun 09 20:31:59 btw do this cleaning while keeping 4.5.1 recipe in the configfile Jun 09 20:32:11 or I will be able to once zenlinux_laptop's patch goes in Jun 09 20:32:12 otherwise it may try to clean up 4.6.0 versions Jun 09 20:32:12 :) Jun 09 20:32:31 thanks nitink ! Jun 09 20:32:38 sure Jun 09 20:32:41 saved me an hour or so Jun 09 20:32:54 :) Jun 09 21:01:13 dvhart: jzhang: Do your homework! Jun 09 21:24:50 zenlinux_laptop's patch is in... Jun 09 21:25:30 zenlinux_laptop: so it was worth looking into :) Jun 09 21:25:48 bluelightning, indeed it was. Thanks for the nudge. :) Jun 09 21:25:57 np, well done Jun 09 21:26:21 What's koen's IRC nick? Jun 09 21:28:38 zenlinux_laptop: "koen" but he hangs out only in #beagle afaik Jun 09 21:30:44 ok, he seems to be replying quickly to email, I think I have the info I need Jun 09 21:31:11 looks like the defaults used in login.defs I include with shadow aren't especially nice Jun 09 21:47:07 dvhart: ping Jun 09 21:47:32 hrm? Jun 09 21:49:54 remember by strange failures on our shared machine? Turned out to be a bad ~/.ccache! Jun 09 21:50:12 dvhart: I removed the sucker and my problems cleared right up Jun 09 21:50:18 yeek - how did you sort that out? Jun 09 21:50:25 and why do you think it went bad? Jun 09 21:50:36 dvhart: sheer dumb luck Jun 09 21:50:55 :( Jun 09 21:51:25 I did a build and was looking at something else in my home directory at the same time noticed the .ccache and thought about and just zapped it and everything worked again. Jun 09 21:51:53 One of the pending tasks is to point CCACHE_DIR into TMPDIR Jun 09 21:55:02 RP__: speaking of ccache, just forwarded you a design doc for review Jun 09 21:59:48 sgw: the ccache-native bit is fine. Is this meant to include the CCACHE_DIR bit too or not? Jun 09 22:13:24 RP__: not initialy, but could Jun 09 22:13:43 sgw: Its just a question of whether thats coming separately Jun 09 22:13:56 i.e. whether they know its meant to be included somewhere Jun 09 22:14:07 ok it Jun 09 22:27:47 sgw: ? Jun 09 22:28:21 RP__: yes? Jun 09 22:28:39 sgw: what did you mean by "ok it"? Jun 09 22:29:55 RP__: sorry was on the phone, I will talk with the WR folks about including the CCACHE_DIR stuff also Jun 09 22:30:18 RP__: Did you reply to the questions at the bottom? Jun 09 22:30:38 sgw: I've not replied to anything Jun 09 22:31:52 Ok, I think I know the answers, I will reply. Jun 09 22:32:14 sgw: the answers are target is free with BBCLASSEXTEND and add to list of packages added to sdkdev Jun 09 22:32:28 right Jun 09 22:43:41 RP__: FYI, vanilla http://paste.debian.net/119397/ Jun 09 22:44:03 still a bit to polish then ready for oe-core Jun 09 22:44:19 ant__: nice Jun 09 22:44:43 I was testing re-enabling udev cache Jun 09 22:46:13 sgw: Your email reply transposes the answers :) Jun 09 22:47:28 yes, I think he can figure it out, it answers both questions. Jun 09 22:48:35 RP__: referring to logger: mount: mount point /proc/bus/usb does not exist Jun 09 22:48:49 I expect oe-core doing the same Jun 09 22:49:01 usbdevfs /proc/bus/usb usbdevfs noauto 0 0 Jun 09 22:49:16 is deprecated since acouple of years... Jun 09 22:54:48 * RP__ -> Zzzz Jun 09 23:17:48 wow, so he does actually sleep occasionally Jun 09 23:18:52 good habits Jun 09 23:19:37 bluelightning: nah, I just say that to create the illusion :) Jun 09 23:19:57 heh Jun 10 01:10:39 khem: ping **** ENDING LOGGING AT Fri Jun 10 02:59:57 2011