**** BEGIN LOGGING AT Fri Jan 13 02:59:57 2012 Jan 13 07:49:33 dmitry_: well you have to make sure that the driver is ok for your device Jan 13 07:50:02 angstrom might only choose a kernel for your device Jan 13 07:50:23 you have to follow usual development method for kernel to generate the patch Jan 13 07:50:51 for the driver and then stick it into the recipe so that it gets included when angstrom is built Jan 13 08:55:39 I got segmentation fault after "Unmounting local filesystems". What can be the problem? Jan 13 09:05:32 good morning Jan 13 09:10:53 mckoan: morning Jan 13 11:19:23 Quick question, are there any problems with bbappends in the recent bitbake heads (and heads of everything else for that matter)? Just noticed that some of my bbappends stuff is not actually packaging the files from the bbappends in my layers (but they are getting added to the controls as part of the part of the package). It may well be me but wanted to check if I am going mad. Jan 13 11:27:20 DJW|Home: that definitely sounds strange and should not be happening... Jan 13 11:49:24 hi all Jan 13 11:50:19 hi pb_ Jan 13 11:53:52 hi pb_ Jan 13 12:17:40 bluelightning: that was my take on it, got me scratching my head as I have not checked the recipes for a while so it may be a local problem I have. All looks fine and my BSP has a layer priority of 6 so should sit fine in the priority stack. Jan 13 12:19:04 DJW|Home: so is it that you have substituted a different file in your layer (with the same name)? or added additional file(s)? Jan 13 12:23:52 bluelightning: in this case the most simple example I have is a pointercal_0.0.bbappend that just has the usual http://pastebin.com/t9kH1b89 in it and a files/omap3-pandora/pointercal (i.e. the machine this specific BSP targets). bitbake pointercal ends up with no files packaged but the pointercal file referanced. Similar situation for formfactor but the config file in oe-core gets packaged just not the marchconfig in the Jan 13 12:23:52 layer. PRINC correctly bumps the PR for the whole recipe so I know the files are being parsed ok. Sure it is me being stupid as usual. Jan 13 12:24:45 DJW|Home: are you using OE-Core or OE-Classic? Jan 13 12:25:02 bluelightning: oe-core Jan 13 12:25:27 DJW|Home: I think you probably ought to change that path setup in that case Jan 13 12:25:51 bluelightning: see, told you it was me ;) Jan 13 12:26:16 try FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" Jan 13 12:26:47 bluelightning: got a good example and i'll work from that. I just tend to take examples from meta-angstrom. Jan 13 12:27:00 bluelightning: ahh, okies, i'll try that, thanks. Jan 13 12:27:49 DJW|Home: you should remove the setting of THISDIR as well, it's now always defined for you Jan 13 12:29:51 bluelightning: well I did not know that :o, that makes things a lot cleaner :). Thanks for the heads up. Trying now. Jan 13 12:30:09 DJW|Home: np, hope it solves your actual issue... Jan 13 12:49:27 smone seen iPhone launch in china? omg Jan 13 13:18:12 bluelightning: the FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" looks to have helped wonderfully :D. Just as an aside is this change noted somewhere, I just notice a load of recipes in some of the distro tied layers like Angstrom/meta-ti etc. still have the old style so I assume are not actually working but failing silently ;). Jan 13 13:28:20 DJWillis: I did note it in the small amount of OE-Core migration info on the wiki Jan 13 13:28:53 DJWillis: I do believe the maintainer of those layers knows about this; it might depend on the situation - sometimes the old method might work, I've not looked into it closely Jan 13 13:29:52 bluelightning: thanks, I missed that, your a great help however and sorry for not RTFM'ing ;). Yep, I guess Koen and co. must know about it. Easy fix and the newer way actually makes it a lot more human readable. Jan 13 14:22:31 otavio, hi Jan 13 14:33:51 does kernel.org work for someone now? Jan 13 14:34:06 timeouts for me Jan 13 14:37:00 timeouts for me too Jan 13 14:38:43 also 149.20.4.69 I guess? Jan 13 14:39:39 149.20.4.69 Jan 13 14:42:04 ftp:// works, will download 3.2.1 for gta02 that way :) Jan 13 14:42:12 ok Jan 13 14:42:25 I just tried the main website Jan 13 14:56:14 hi ericben Jan 13 15:52:13 wow, this access point is teh suck Jan 13 15:52:18 * pb_ stabs netgear Jan 13 15:53:27 * florian takes a mental note Jan 13 15:56:18 I've had pretty good experience with netgear Jan 13 15:56:42 both wired and wireless Jan 13 15:56:59 yeah, admittedly this one is fairly old. I was just a bit shocked to discover that, with two clients copying across wifi at about 1MB/s, the network basically stops working for everyone else Jan 13 15:56:59 using an 8-port managed switch of theirs to tie the network at the house together. Jan 13 15:57:06 It's got some pretty awesome stuff Jan 13 15:57:28 I don't think I've ever had a home AP that I didn't end up despising at some point Jan 13 15:57:35 maybe its time to invest in a higher quality one :) Jan 13 15:58:34 since lenovo let me down yesterday it seems that I have to take my old R50 to california, which means copying a pile of stuff off my other machine onto it Jan 13 15:58:35 suck Jan 13 15:58:50 kergoth`: yeah, I think that's probably the moral of the story for me Jan 13 15:59:41 yeha sometimes you get what you pay for :P Jan 13 16:00:31 true enough Jan 13 16:01:15 heh, it's funny how much people try to save money on the wrong things. e.g. not investing in a quality chair or mattress. maybe an AP should go in that category, given how much it's used, though it doesnt' involve actual physical pain :) Jan 13 16:23:42 Hi there, I noticed that some recipes are setting ARM_INSTRUCTION_SET (mostly in cases where the source contains some inline asm that won't compile in thumb mode). Jan 13 16:24:07 The corresponding compiler flag is set by TUNE_CCARGS via meta/conf/machine/include/arm/feature-arm-thumb.inc. Jan 13 16:24:48 By default the qemuarm machine config pulls in the following include files and respects the ARM_INSTRUCTION_SET just fine: http://paste.ubuntu.com/803132/ Jan 13 16:26:15 I changed the qemuarm config to pull in arch-armv7a.inc instead of tune-arm926ejs.inc which gives the following tree: http://paste.ubuntu.com/803135/ Jan 13 16:27:35 florian: just now see the amount of work :D need python and such Jan 13 16:28:30 florian: are we far away from using the sdk build capabilities? Jan 13 16:29:39 The feature-arm-thumb.inc still gets used and I expected recipes who set ARM_INSTRUCTION_SET to work but somehow the gcc is called without the -mthumb/-mno-thumb flags Jan 13 16:54:18 bitbake -e shows that ARM_THUMB_M_OPT gets set properly but somehow TUNE_CCARGS doesn't contain this flag when using arch-armv7a.inc Jan 13 16:54:22 Any ideas? Jan 13 16:55:01 In both cases it's using: ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} Jan 13 16:55:54 and TUNE_FEATURES is getting "thumb" (or lacking it)? Jan 13 16:58:16 fray: yes, it looks like it's there in both cases Jan 13 16:59:01 oh Jan 13 16:59:23 arch-armv7a.inc sets default tune to armv7a Jan 13 17:01:00 and then: TUNE_FEATURES_tune-armv7a-neon ?= "armv7a vfp neon" Jan 13 17:01:04 so there is no thumb Jan 13 17:02:06 TUNE_FEATURES is set by whatever the DEFAULTTUNE is set to.. Jan 13 17:02:24 if it has thumb, then changing the tune to a not thumb version will change the feature set.. Jan 13 17:03:23 FYI I just pushed a new recipes/meta/meta-toolchain-qtx11.bb in my branch mckoan/kaeilos-2011, I hope it could be useful Jan 13 17:03:31 fray: as long as the recipe doesn' use ARM_INSTRUCTION_SET, right? Jan 13 17:07:46 have a nice weekend Jan 13 18:34:08 hello, i know my problem seems to be wrong in this channel but #angstrom channel is very silent at the moment so may be someone here can help me: i am compiling angstrom for pandaboard but it fails to compile a HP veer kernel (why using this kernel?) who can help to analyse/fix ? a console log is here: http://norman-schleicher.de/jenkins/job/pandaboard-angstrom/9/console Jan 13 18:35:20 nschle85: tried asking on #pandaboard? Jan 13 18:35:50 dm8tbr lol Jan 13 18:36:27 dm8tbr: woglinde: may be JaMa: fixed it now, ill test again :-) Jan 13 18:36:33 nschle85 bitbake -g and look at the grpah Jan 13 18:36:49 woglinde: what is grpath for ? Jan 13 18:37:22 graph Jan 13 18:37:26 .dot files Jan 13 18:37:45 nschle85: maybe fixed, but still strange that it picked linux-hpveer as best virtual/kernel provider Jan 13 18:38:27 hi jama Jan 13 18:39:47 JaMa: and strange that this nobody detected until now :-) Jan 13 18:40:34 nschle85 because the panda kernel suckz Jan 13 18:41:25 nschle85: some people did... if you search ML you will find that you're not first building linux-hpveer for it Jan 13 18:42:13 but its not fixed, in shr bugs afixed very fast i can say :-) Jan 13 18:42:25 are Jan 13 18:43:49 JaMa: fix does not work yet (you can see on jenkins log) do i have to clean something ? Jan 13 18:44:45 nschle85: oebb.sh is not using shr branches Jan 13 18:45:00 JaMa: ups Jan 13 18:46:59 ok ill apply the patch manually Jan 13 18:47:27 I've pushed it to master now too Jan 13 18:47:40 JaMa: thank you Jan 13 18:53:55 woglinde: which kernel do you use ? Jan 13 18:54:11 woglinde: or which distribution do you use ? Jan 13 18:54:39 I have no pandaboard Jan 13 18:59:09 so where is written pandaboard kernel sucks ? Jan 13 19:00:35 nschle85 I heard and read it from time to time Jan 13 19:00:40 maybee its better now Jan 13 19:02:06 woglinde: i read also old bugreports, which sounds horroble (corrupted memory, slow usb aso.) but this problems are fixed i think Jan 13 20:20:47 pb_: where in CA will you be Jan 13 20:21:47 hi khem Jan 13 20:21:57 woglinde: hello Jan 13 20:33:23 anyone have an idea the time it takes to build a largish app with gcc varies a lot with gcc version? Jan 13 20:33:48 Crofton: Answer is depends Jan 13 20:33:52 rofl Jan 13 20:33:57 khem, on what :) Jan 13 20:33:59 Crofton: how far are the versions Jan 13 20:34:09 trying to work that out now Jan 13 20:34:27 if you compare say gcc 2.95 to gcc 4.6 Jan 13 20:34:29 whatever is in (classic) Angstrom between May of last year and November :) Jan 13 20:34:38 gcc 4.6 will seem hell slow compiling at -O2 Jan 13 20:34:47 * Crofton is trying to collect actual version Jan 13 20:34:57 classic is still 4.5 in ANgstrom right? Jan 13 20:34:57 ok classic has 4.5 Jan 13 20:35:09 so 4.5 compared to what Jan 13 20:35:18 I think they are all 4.5 based, just varying minor version + Linaro patches Jan 13 20:36:20 within 4.5 or 4.4-4.5 things should be similar Jan 13 20:36:29 hmmm ok. there is one possibility that one of the patch is causing the regression Jan 13 20:37:16 with 4.4 Vs. 4.5 should be similar but I wouldnt be surprised if 4.5 is slower Jan 13 20:37:23 ok, we'll try and see if this is a real issue Jan 13 20:37:31 since new opt passes keeps on adding Jan 13 20:37:52 if you see like it was 5 mins and now its 10 mins Jan 13 20:38:02 its quite alarmingly a problem Jan 13 20:38:22 but if its like it was 5 mins and now its 6 its still a problem but seemingly less Jan 13 20:38:51 although gcc tries to always reduce memory usage etc. and keep flat compilation speed Jan 13 20:39:23 its just not possible if you consider laws of physics Jan 13 20:46:25 Crofton: so its for gcc on target ? Jan 13 20:46:43 right Jan 13 20:46:49 thats why they noticed :) Jan 13 20:46:58 hmmm I think there is too much involved then Jan 13 20:47:05 right Jan 13 20:47:05 is the system otherwise ok Jan 13 20:47:19 This is waht we are trying to figure out Jan 13 20:47:23 if you can reproduce it on cross build its easier to pinpoint Jan 13 20:47:47 so take gnuradio and compile it with two versions of gcc and time it Jan 13 20:47:52 on cross build Jan 13 20:47:53 thanks for the pointers Jan 13 20:48:08 I would think its not gcc Jan 13 22:38:37 is there an easy way to disable buildstats? Jan 13 22:55:31 msm: iirc, it is disabled by default Jan 13 22:56:16 when did it get disabled by default? Jan 13 22:56:22 INHERIT += "oestats-client" is for enable Jan 13 22:56:22 i remember seeing emails on the ML Jan 13 22:56:35 I mean client-side Jan 13 22:56:41 msm: remove buildstats from USER_CLASSES Jan 13 22:56:46 in your local.conf Jan 13 22:56:47 server part is disabled about year Jan 13 22:56:58 ah Jan 13 22:57:08 seems you are talking about oe-core's one Jan 13 22:57:19 (actually talking about yocto) Jan 13 22:57:24 sorry then Jan 13 22:57:42 khem: its not in USER_CLASSES =) Jan 13 22:58:02 it seems to be inherited in meta/classes/base.bbclass Jan 13 22:58:08 AFAICT Jan 13 22:58:08 then delete it however you are inheriting it Jan 13 22:58:25 khem: i did that - it just felt wrong ;) Jan 13 22:58:44 it should not be in base class Jan 13 22:59:32 khem: this is why i felt wrong Jan 13 23:00:03 is it oe-core ? Jan 13 23:00:08 or yocto Jan 13 23:00:11 khem: im looking at oe-core now Jan 13 23:00:14 and comparing to yocto Jan 13 23:00:28 it might be yocto's policy Jan 13 23:00:32 in oe-core its optional Jan 13 23:02:19 khem: i think this was all reworked after my current version Jan 13 23:02:31 ok Jan 13 23:14:30 does anyone know if anyone has ever looked at using bitbake as the basic for automated testing? Jan 13 23:15:36 basis* **** ENDING LOGGING AT Sat Jan 14 02:59:57 2012