IRC log for #oe on 20120113

00:00.40cs_nbpbut anyways 23.1 is the correct version
00:00.58cs_nbpfirefox will be at 23.1 in 4 weeks
00:01.19floriancs_nbp: it is a good idea to follow common conventions so that the package manager is able todifferentiate between older and newer
00:01.24florian:-)
00:01.57cs_nbpflorian: well ill try to find some of those common conventions, i guess in the manual
00:02.14floriancs_nbp:
00:03.07floriancs_nbp: oops... no, but just like at some software around. usually its something like major.minor
00:03.32cs_nbpflorian: ah k, i do that anyways to less confuse myself
00:04.17cs_nbpflorian: so ill add some _23.1.2012_r1.bb or so
00:04.47cs_nbpok i really need some sleep today :D
00:05.13cs_nbpcyaZ tomorrow (and good luck w ur 'thing' tomorrow)
00:23.46*** join/#oe RP (~richard@93-97-173-237.zone5.bethere.co.uk)
00:56.06*** join/#oe dos11 (~dos@unaffiliated/dos1)
00:56.50*** join/#oe msm2 (~msm@99-47-177-27.lightspeed.austtx.sbcglobal.net)
00:57.05*** join/#oe rah_ (~rah@cpc8-live19-2-0-cust155.know.cable.virginmedia.com)
00:58.03*** join/#oe msm2 (~msm@99-47-177-27.lightspeed.austtx.sbcglobal.net)
00:58.20*** join/#oe halstead1away (~halstead@watts.incitedev.com)
01:02.02*** join/#oe kergoth` (~kergoth@covenant.kergoth.com)
01:10.13*** join/#oe sterNiX (~LessIsMor@unaffiliated/nu253r/x-0655220)
01:10.18*** join/#oe toofar (~toobluesc@rrcs-24-153-174-218.sw.biz.rr.com)
01:10.44*** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes)
01:12.38*** join/#oe blindvt (~brf@85-127-90-250.dynamic.xdsl-line.inode.at)
01:53.19*** join/#oe julianpid (~julianpid@62.200.22.2)
02:05.40*** join/#oe dmitry_ (~dmitry@69.26.58.252)
02:07.16dmitry_hello, I have a question regarding drivers for OE. If I have a driver for a device that works with x86 linux (lets say it's a USB video capture device), will this driver be compatible with an Angstrom distribution? If not is there a guide for writing/porting drivers to OE?
02:08.07dmitry_angstrom for Omap 3
02:29.50*** join/#oe zenlinux (~sgarman@c-76-115-40-64.hsd1.or.comcast.net)
02:45.23*** join/#oe julianpid (~julianpid@62.200.22.2)
03:05.38*** join/#oe devzero_ (devzero@xdsl-89-0-133-222.netcologne.de)
04:25.33*** part/#oe cminyard (~cminyard@pool-173-57-157-96.dllstx.fios.verizon.net)
04:41.53*** join/#oe snkt (~snkt@114.143.161.178)
05:32.07*** join/#oe erwt (~erwt@114.143.161.178)
05:43.48*** join/#oe captain_morgan (~captain_m@c-76-102-249-39.hsd1.ca.comcast.net)
05:56.31*** join/#oe julianpid (~julianpid@62.200.22.2)
06:12.55*** join/#oe ensc|w (~ensc@www.sigma-chemnitz.de)
06:57.53*** join/#oe JaMa (~martin@94.230.152.246)
06:58.46*** join/#oe sterNiX (~LessIsMor@unaffiliated/nu253r/x-0655220)
06:59.57*** join/#oe reisei (~reisei@n41-as54-1-ppp206.nordnet.ru)
07:06.11*** join/#oe captain_morgan (~captain_m@c-76-102-249-39.hsd1.ca.comcast.net)
07:06.38*** join/#oe tasslehoffwrk (~Tasslehof@147.84-49-231.nextgentel.com)
07:08.00*** join/#oe msm (~msm@99-47-177-27.lightspeed.austtx.sbcglobal.net)
07:09.50*** join/#oe tasslehoffwrk (~Tasslehof@147.84-49-231.nextgentel.com)
07:16.44*** join/#oe tscheck1 (~t@83.151.21.119)
07:27.41*** join/#oe anarsoul (~anarsoul@46.28.102.157)
07:49.24khemdmitry_: well you have to make sure that the driver is ok for your device
07:49.53khemangstrom might only choose a kernel for your device
07:50.14khemyou have to follow usual development method for kernel to generate the patch
07:50.42khemfor the driver and then stick it into the recipe so that it gets included when angstrom is built
07:51.59*** join/#oe vitus (~vitus@145.253.169.210)
07:59.29*** join/#oe stefan_schmidt (~stefan@guest213.ibr.cs.tu-bs.de)
08:02.12*** join/#oe hollisb (~hollisb@nat-dem.mentorg.com)
08:03.13*** join/#oe hollisb_ (~hollisb@nat-dem.mentorg.com)
08:03.54*** join/#oe HeinervdmOff (~zimmerman@hsaggate.physik.uni-bonn.de)
08:18.57*** join/#oe amarsman (~marsman@90-145-17-249.wxdsl.nl)
08:35.59*** join/#oe vexorg (~vexorg@h216-18-7-221.gtconnect.net)
08:36.03*** join/#oe lamikr (lamikr@nat/nokia/x-mhyfsqavkcxboflq)
08:37.00*** join/#oe rschus (~rschus@58.176.73.86.rev.sfr.net)
08:37.00*** join/#oe rschus1 (~rschus@58.176.73.86.rev.sfr.net)
08:39.56*** join/#oe ant_work (~andrea@host6-80-static.42-85-b.business.telecomitalia.it)
08:55.30reiseiI got segmentation fault after "Unmounting local filesystems". What can be the problem?
09:02.10*** join/#oe ao2 (~ao2@2001:1418:117::1)
09:05.22mckoangood morning
09:10.44reiseimckoan: morning
09:15.10*** join/#oe Spider-Pork (~Spider-Po@host39-232-static.225-95-b.business.telecomitalia.it)
09:19.22*** join/#oe mickey_office (~mickey@e182221015.adsl.alicedsl.de)
09:29.25*** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029)
09:33.43*** join/#oe pvanhoof (~pvanhoof@217.22.63.163.static.hosted.by.easyhost.be)
09:45.33*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
09:56.29*** join/#oe GarthPS (~quassel@qrc29-1-82-245-206-103.fbx.proxad.net)
10:18.42*** join/#oe florian (~fuchs@Maemo/community/contributor/florian)
10:26.27*** join/#oe pespin (~pespin@cisne-cn09.upc.es)
10:27.15*** join/#oe pepermint (~pepermint@host28-87-dynamic.4-87-r.retail.telecomitalia.it)
10:49.18*** join/#oe anarsoul (~anarsoul@46.28.102.157)
10:49.19*** join/#oe morphis (~morphis@dslb-088-071-241-111.pools.arcor-ip.net)
10:58.20*** join/#oe erwt (~erwt@114.143.161.178)
11:19.13DJW|HomeQuick 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.
11:27.10bluelightningDJW|Home: that definitely sounds strange and should not be happening...
11:37.06*** join/#oe darknighte (~darknight@pdpc/supporter/professional/darknighte)
11:45.46*** join/#oe penghb (~penghb@202.108.130.153)
11:49.14pb_hi all
11:50.09bluelightninghi pb_
11:53.42florianhi pb_
12:02.12*** join/#oe vivijim (~vivijim@unaffiliated/vivijim)
12:04.45*** join/#oe tzanger (tzanger@wallace.mixdown.ca)
12:06.58*** join/#oe hollisb (~hollisb@nat-dem.mentorg.com)
12:07.01*** join/#oe hollisb_ (~hollisb@nat-dem.mentorg.com)
12:14.37*** join/#oe lamikr (lamikr@nat/nokia/x-hpeqxhwmahalirgj)
12:17.30DJW|Homebluelightning: 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.
12:18.54bluelightningDJW|Home: so is it that you have substituted a different file in your layer (with the same name)? or added additional file(s)?
12:23.10*** join/#oe sterNiX (~LessIsMor@unaffiliated/nu253r/x-0655220)
12:23.19*** join/#oe joelagnel (~joel@188.116.243.214)
12:23.41DJW|Homebluelightning: 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
12:23.41DJW|Homelayer. 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.
12:24.35bluelightningDJW|Home: are you using OE-Core or OE-Classic?
12:24.52DJW|Homebluelightning: oe-core
12:25.17bluelightningDJW|Home: I think you probably ought to change that path setup in that case
12:25.41DJW|Homebluelightning: see, told you it was me ;)
12:26.06bluelightningtry FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
12:26.37DJW|Homebluelightning: got a good example and i'll work from that. I just tend to take examples from meta-angstrom.
12:26.50DJW|Homebluelightning: ahh, okies, i'll try that, thanks.
12:27.39bluelightningDJW|Home: you should remove the setting of THISDIR as well, it's now always defined for you
12:29.41DJW|Homebluelightning: well I did not know that :o, that makes things a lot cleaner :). Thanks for the heads up. Trying now.
12:29.59bluelightningDJW|Home: np, hope it solves your actual issue...
12:30.56*** join/#oe rsalveti (~rsalveti@186.214.63.24)
12:30.56*** join/#oe rsalveti (~rsalveti@linaro/rsalveti)
12:39.43*** join/#oe cs_nbp (~sackratte@ip-78-94-223-103.unitymediagroup.de)
12:41.48*** join/#oe rschus (daemon@gate.tarent.de)
12:49.17cs_nbpsmone seen iPhone launch in china? omg
12:51.09*** join/#oe HeinervdmOff (~zimmerman@hsaggate.physik.uni-bonn.de)
12:59.15*** join/#oe HeinervdmOff (~zimmerman@hsaggate.physik.uni-bonn.de)
13:00.40*** join/#oe HeinervdmOff (~zimmerman@hsaggate.physik.uni-bonn.de)
13:04.23*** join/#oe anarsoul (~anarsoul@46.28.102.157)
13:18.01DJW|Homebluelightning: 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 ;).
13:28.09bluelightningDJWillis: I did note it in the small amount of OE-Core migration info on the wiki
13:28.42bluelightningDJWillis: 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
13:29.42DJWillisbluelightning: 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.
13:33.15*** join/#oe cbrake (~cbrake@oh-69-34-21-229.sta.embarqhsd.net)
13:54.07*** join/#oe denisATeukrea (~GNUtoo@host55-202-dynamic.1-79-r.retail.telecomitalia.it)
13:58.33*** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes)
14:04.28*** join/#oe dos1 (~dos@unaffiliated/dos1)
14:13.27*** join/#oe rsalveti` (~rsalveti@186.214.62.152)
14:22.20denisATeukreaotavio, hi
14:33.40JaMadoes kernel.org work for someone now?
14:33.56JaMatimeouts for me
14:36.49denisATeukreatimeouts for me too
14:38.32JaMaalso 149.20.4.69 I guess?
14:39.03*** join/#oe hollisb (~hollisb@nat-dem.mentorg.com)
14:39.28denisATeukrea149.20.4.69
14:40.22*** join/#oe msm (~msm@99-47-177-27.lightspeed.austtx.sbcglobal.net)
14:41.54JaMaftp:// works, will download 3.2.1 for gta02 that way :)
14:42.01denisATeukreaok
14:42.14denisATeukreaI just tried the main website
14:42.49*** join/#oe uwe__ (~uwe_@dslb-088-064-223-216.pools.arcor-ip.net)
14:45.45*** join/#oe Tartarus (trini@pixelshelf.com)
14:56.03denisATeukreahi ericben
15:02.42*** join/#oe vivijim (~vivijim@unaffiliated/vivijim)
15:06.07*** join/#oe devzero_ (devzero@xdsl-89-0-157-196.netcologne.de)
15:07.04*** join/#oe peahonen (~peahonen@a88-115-25-242.elisa-laajakaista.fi)
15:11.52*** join/#oe hollisb (~hollisb@nat-dem.mentorg.com)
15:20.37*** join/#oe ensc (~irc-ensc@fedora/ensc)
15:31.59*** join/#oe rsalveti (~rsalveti@linaro/rsalveti)
15:33.09*** join/#oe cminyard (~cminyard@pool-173-57-157-96.dllstx.fios.verizon.net)
15:37.09*** join/#oe captain_morgan (~captain_m@c-76-102-249-39.hsd1.ca.comcast.net)
15:52.02pb_wow, this access point is teh suck
15:52.07pb_stabs netgear
15:52.22*** join/#oe morphis (~morphis@dslb-088-071-241-111.pools.arcor-ip.net)
15:53.12*** join/#oe captain_morgan (~captain_m@c-76-102-249-39.hsd1.ca.comcast.net)
15:53.16floriantakes a mental note
15:56.07murianiI've had pretty good experience with netgear
15:56.30murianiboth wired and wireless
15:56.47pb_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
15:56.48murianiusing an 8-port managed switch of theirs to tie the network at the house together.
15:56.55murianiIt's got some pretty awesome stuff
15:57.17kergoth`I don't think I've ever had a home AP that I didn't end up despising at some point
15:57.24kergoth`maybe its time to invest in a higher quality one :)
15:58.13*** join/#oe dos11 (~dos@unaffiliated/dos1)
15:58.22pb_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
15:58.24pb_suck
15:58.39pb_kergoth`: yeah, I think that's probably the moral of the story for me
15:59.30murianiyeha sometimes you get what you pay for :P
16:00.20pb_true enough
16:01.04kergoth`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 :)
16:06.09*** join/#oe captain_morgan (~captain_m@c-76-102-249-39.hsd1.ca.comcast.net)
16:07.54*** join/#oe rschus (~rschus@58.176.73.86.rev.sfr.net)
16:15.51*** join/#oe jconnolly (~jconnolly@66.43.64.66)
16:18.08*** join/#oe msm (~msm@192.88.168.34)
16:23.30kenwsHi 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).
16:23.56kenwsThe corresponding compiler flag is set by TUNE_CCARGS via meta/conf/machine/include/arm/feature-arm-thumb.inc.
16:24.36kenwsBy default the qemuarm machine config pulls in the following include files and respects the ARM_INSTRUCTION_SET just fine: http://paste.ubuntu.com/803132/
16:26.04kenwsI 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/
16:27.24cs_nbpflorian: just now see the amount of work :D need python and such
16:27.34*** join/#oe rschus (~rschus@58.176.73.86.rev.sfr.net)
16:28.19cs_nbpflorian: are we far away from using the sdk build capabilities?
16:29.27kenwsThe 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
16:31.38*** join/#oe woglinde (~heinold@g230117198.adsl.alicedsl.de)
16:32.49*** join/#oe CosmicPenguin (~nobody@soa.codeaurora.org)
16:41.21*** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029)
16:49.22*** join/#oe hollisb (~hollisb@93.83.48.174)
16:51.20*** join/#oe zecke (~ich@91-64-82-148-dynip.superkabel.de)
16:54.06kenwsbitbake -e shows that ARM_THUMB_M_OPT gets set properly but somehow TUNE_CCARGS doesn't contain this flag when using arch-armv7a.inc
16:54.11kenwsAny ideas?
16:54.49kenwsIn both cases it's using: ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)}
16:55.42frayand TUNE_FEATURES is getting "thumb" (or lacking it)?
16:58.04kenwsfray: yes, it looks like it's there in both cases
16:58.49kenwsoh
16:59.11kenwsarch-armv7a.inc sets default tune to armv7a
17:00.48kenwsand then: TUNE_FEATURES_tune-armv7a-neon ?= "armv7a vfp neon"
17:00.52kenwsso there is no thumb
17:01.54frayTUNE_FEATURES is set by whatever the DEFAULTTUNE is set to..
17:02.12frayif it has thumb, then changing the tune to a not thumb version will change the feature set..
17:03.12mckoanFYI I just pushed a new recipes/meta/meta-toolchain-qtx11.bb in my branch mckoan/kaeilos-2011, I hope it could be useful
17:03.19kenwsfray: as long as the recipe doesn' use  ARM_INSTRUCTION_SET, right?
17:05.51*** join/#oe HokieTux (~HokieTux@157.22.28.13)
17:07.34mckoanhave a nice weekend
17:17.23*** join/#oe NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey)
17:27.38*** join/#oe pidge (~pidge@c-71-236-152-235.hsd1.or.comcast.net)
17:30.51*** join/#oe captain_morgan (~captain_m@asp.tokbox.com)
17:33.36*** join/#oe pespin (~pespin@206.pool85-50-74.dynamic.orange.es)
17:43.58*** join/#oe nitink1 (~nitink@nat/intel/x-uisqwfqxshqjapiu)
17:49.06*** join/#oe rah (~rah@cpc8-live19-2-0-cust155.know.cable.virginmedia.com)
17:57.02*** join/#oe captain_morgan (~captain_m@asp.tokbox.com)
18:11.36*** join/#oe Russ (~russ@209.140.95.27)
18:20.16*** join/#oe HopsNBarley (~hops@nslu2-linux/HopsNBarley)
18:26.00*** join/#oe dos1 (~dos@unaffiliated/dos1)
18:26.50*** join/#oe GNUtoo (~gnutoo@host55-202-dynamic.1-79-r.retail.telecomitalia.it)
18:30.44*** join/#oe nschle85 (~kvirc@178-27-184-116-dynip.superkabel.de)
18:33.55nschle85hello, 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
18:35.07dm8tbrnschle85: tried asking on #pandaboard?
18:35.38woglindedm8tbr lol
18:35.40*** join/#oe pepermint2 (~pepermint@host28-87-dynamic.4-87-r.retail.telecomitalia.it)
18:36.14nschle85dm8tbr: woglinde: may be JaMa: fixed it now, ill test again :-)
18:36.20woglindenschle85 bitbake -g and look at the grpah
18:36.37nschle85woglinde: what is grpath for ?
18:37.10woglindegraph
18:37.14woglinde.dot files
18:37.33JaManschle85: maybe fixed, but still strange that it picked linux-hpveer as best virtual/kernel provider
18:38.15woglindehi jama
18:39.35nschle85JaMa: and strange that this nobody detected until now :-)
18:40.21woglindenschle85 because the panda kernel suckz
18:41.12JaManschle85: some people did... if you search ML you will find that you're not first building linux-hpveer for it
18:42.01nschle85but its not fixed, in shr bugs afixed very fast i can say :-)
18:42.13nschle85are
18:43.36nschle85JaMa: fix does not work yet (you can see on jenkins log) do i have to clean something ?
18:44.33JaManschle85: oebb.sh is not using shr branches
18:44.47nschle85JaMa: ups
18:46.46nschle85ok ill apply the patch manually
18:47.15JaMaI've pushed it to master now too
18:47.28nschle85JaMa: thank you
18:53.43nschle85woglinde: which kernel do you use ?
18:53.59nschle85woglinde: or which distribution do you use ?
18:54.26*** join/#oe tom_say (~pain@cpe-68-203-248-184.stx.res.rr.com)
18:54.27woglindeI have no pandaboard
18:58.57nschle85so where is written pandaboard kernel sucks ?
19:00.23woglindenschle85 I heard and read it from time to time
19:00.28woglindemaybee its better now
19:01.54nschle85woglinde: i read also old bugreports, which sounds horroble (corrupted memory, slow usb aso.) but this problems are fixed i think
19:29.25*** join/#oe rah (~rah@cpc8-live19-2-0-cust155.know.cable.virginmedia.com)
19:56.51*** join/#oe zenlinux (~sgarman@c-76-115-40-64.hsd1.or.comcast.net)
20:12.51*** join/#oe kevinsc (~a0214685@nat/ti/x-kgjcbukvuufnjhph)
20:20.34khempb_: where in CA will you be
20:21.34woglindehi khem
20:21.44khemwoglinde: hello
20:33.10Croftonanyone have an idea the time it takes to build a largish app with gcc varies a lot with gcc version?
20:33.26*** join/#oe rob_w_ (~bob@ppp-188-174-10-222.dynamic.mnet-online.de)
20:33.35khemCrofton: Answer is depends
20:33.39Croftonrofl
20:33.44Croftonkhem, on what :)
20:33.46khemCrofton: how far are the versions
20:33.56Croftontrying to work that out now
20:34.14khemif you compare say gcc 2.95 to gcc 4.6
20:34.16Croftonwhatever is in (classic) Angstrom between May of last year and November :)
20:34.25khemgcc 4.6 will seem hell slow compiling at -O2
20:34.34Croftonis trying to collect actual version
20:34.44Croftonclassic is still 4.5 in ANgstrom right?
20:34.45khemok classic has 4.5
20:34.56khemso 4.5 compared to what
20:35.05CroftonI think they are all 4.5 based, just varying minor version + Linaro patches
20:36.07Croftonwithin 4.5 or 4.4-4.5 things should be similar
20:36.16khemhmmm ok. there is one possibility that one of the patch is causing the regression
20:37.03khemwith 4.4 Vs. 4.5 should be similar but I wouldnt be surprised if 4.5 is slower
20:37.10Croftonok, we'll try and see if this is a real issue
20:37.18khemsince new opt passes keeps on adding
20:37.39khemif you see like it was 5 mins and now its 10 mins
20:37.49khemits quite alarmingly a problem
20:38.09khembut if its like it was 5 mins and now its 6 its still a problem but seemingly less
20:38.38khemalthough gcc tries to always reduce memory usage etc. and keep flat compilation speed
20:39.10khemits just not possible if you consider laws of physics
20:46.01*** join/#oe galak (~galak@192.88.168.34)
20:46.12khemCrofton: so its for gcc on target ?
20:46.30Croftonright
20:46.36Croftonthats why they noticed :)
20:46.45khemhmmm I think there is too much involved then
20:46.53Croftonright
20:46.53khemis the system otherwise ok
20:47.06CroftonThis is waht we are trying to figure out
20:47.10khemif you can reproduce it on cross build its easier to pinpoint
20:47.34khemso take gnuradio and compile it with two versions of gcc and time it
20:47.39khemon cross build
20:47.40Croftonthanks for the pointers
20:47.55khemI would think its not gcc
21:08.30*** join/#oe cminyard (~cminyard@pool-173-57-157-96.dllstx.fios.verizon.net)
21:15.16*** join/#oe kevinsc (~a0214685@nat/ti/x-cerlvoscjaiqmvtq)
21:15.59*** join/#oe joelagnel (~joel@188.116.243.214)
21:16.38*** join/#oe bluelightning (~paul@cpc2-lewi17-2-0-cust101.2-4.cable.virginmedia.com)
21:16.38*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
22:38.24msmis there an easy way to disable buildstats?
22:44.07*** join/#oe pespin (~pespin@206.pool85-50-74.dynamic.orange.es)
22:52.09*** join/#oe _alx_ (~alx@host85-131-dynamic.52-82-r.retail.telecomitalia.it)
22:55.01*** join/#oe captain_morgan (~captain_m@asp.tokbox.com)
22:55.17Jay7msm: iirc, it is disabled by default
22:56.02msmwhen did it get disabled by default?
22:56.09Jay7INHERIT += "oestats-client" is for enable
22:56.09msmi remember seeing emails on the ML
22:56.21Jay7I mean client-side
22:56.27khemmsm: remove buildstats from USER_CLASSES
22:56.32khemin your local.conf
22:56.33Jay7server part is disabled about year
22:56.44Jay7ah
22:56.54Jay7seems you are talking about oe-core's one
22:57.05msm(actually talking about yocto)
22:57.10Jay7sorry then
22:57.29msmkhem: its not in USER_CLASSES =)
22:57.49msmit seems to be inherited in meta/classes/base.bbclass
22:57.54msmAFAICT
22:57.55khemthen delete it however you are inheriting it
22:58.11msmkhem: i did that - it just felt wrong ;)
22:58.30khemit should not be in base class
22:59.19msmkhem: this is why i felt wrong
22:59.49khemis it oe-core ?
22:59.55khemor yocto
22:59.57msmkhem: im looking at oe-core now
23:00.01msmand comparing to yocto
23:00.14khemit might be yocto's policy
23:00.18khemin oe-core its optional
23:02.06msmkhem: i think this was all reworked after my current version
23:02.17khemok
23:14.17msmdoes anyone know if anyone has ever looked at using bitbake as the basic for automated testing?
23:15.22msmbasis*
23:28.59*** join/#oe playya__ (~playya@unaffiliated/playya)
23:39.46*** join/#oe risca (~risca@wi-secure-6059.cc.umanitoba.ca)
23:42.21*** join/#oe ensc_ (~irc-ensc@p54ADEFA3.dip.t-dialin.net)
23:42.25*** join/#oe zecke_ (~ich@91-64-82-148-dynip.superkabel.de)
23:42.56*** join/#oe sgw1 (~sgw@c-71-193-189-117.hsd1.wa.comcast.net)
23:43.13*** join/#oe udovdh_ (~udovdh@pindarots.xs4all.nl)
23:45.01*** join/#oe rsalveti` (~rsalveti@186.214.62.152)
23:46.53*** join/#oe rsalveti_ (~rsalveti@linaro/rsalveti)
23:47.20*** join/#oe stuffcorpse_ (stuffy@bnc.kollide.net)
23:48.30*** join/#oe stuffcorpse (stuffy@amarok/developer/rickc)
23:50.12*** join/#oe hollisb (~hollisb@93.83.48.174)
23:52.36*** join/#oe MMx (mmx@2001:41b8:200:0:5054:ff:fe12:3456)
23:53.15*** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes)
23:53.31*** join/#oe pespin_ (~pespin@206.pool85-50-74.dynamic.orange.es)
23:54.50*** join/#oe sterNiX (~LessIsMor@unaffiliated/nu253r/x-0655220)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.