**** BEGIN LOGGING AT Thu Dec 22 02:59:57 2011
Dec 22 04:14:24 <captain_morgan> What OpenEmbedded branch (from github) should I work out of? I'm currently facing non-stop MD5/SHA256 checksum and 'nothing provides derp' errors
Dec 22 04:15:19 <captain_morgan> and thats out of the org.openmbedded.dev branch, which I've had the best luck with so far
Dec 22 04:24:37 <captain_morgan> also, its binutils currently failing both MD5 and SHA256
Dec 22 04:36:25 <kergoth> oe is currently transitioning away from the monolithic repo to a broken up layer model. read the oe-core wiki page on the oe site for details. no active development is happening on master/org.openembedded.dev
Dec 22 04:36:44 <kergoth> (aside: org.openembedded.dev was renamed to master ages ago, it's a compatibility link, no reason to use it at all)
Dec 22 04:36:53 <kergoth> I'd suggest either using the branch from the last release, or moving to oe-core
Dec 22 04:40:08 <captain_morgan> cool, hopefully I will have better luck with this
Dec 22 04:50:13 <captain_morgan> Is there a list of valid machines for oe-core?
Dec 22 04:52:12 <captain_morgan> or is beagleboard just not supported now
Dec 22 04:53:16 <kergoth> TI maintains a layer that supports a number of their devices, including the beagleboard, pandaboard, and beaglebone.
Dec 22 04:53:19 <kergoth> http://www.openembedded.org/wiki/LayerIndex
Dec 22 04:53:37 <kergoth> http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/
Dec 22 04:54:33 <xxiao> there is angstrom for arm and yocto for x86, yes i know yocto tries to support more archs but still it's more about x86
Dec 22 04:55:12 <xxiao> is there a meta layer that is arch-neutral for common packages? other than the limited oe-core recipes?
Dec 22 04:55:20 <kergoth> yocto's core machines are qemu
Dec 22 04:55:32 <kergoth> qemux86, qemuarm, qemuppc, qemumips all exist, and should build fine
Dec 22 04:55:38 <kergoth> yes, you want meta-oe
Dec 22 04:55:48 <kergoth> its the place where most oe recipes get migrated to if they dont' have a better place
Dec 22 04:55:57 <xxiao> ok thanks.
Dec 22 04:55:57 <captain_morgan> I see
Dec 22 04:56:03 <kergoth> things are of, course, migrated on an as needed basis.
Dec 22 04:56:13 <kergoth> s/ of,/, of/
Dec 22 04:57:41 <xxiao> the oe wiki still refers to legacy oe, hope it gets updated to reflect the oe-core,meta-oe someday
Dec 22 04:57:54 <kergoth> if it wasn't clear: poky (which is part of yocto) == oe-core/meta + meta-yocto + scripts/integration
Dec 22 04:58:05 <kergoth> agreed. the OE-Core wiki page is a start
Dec 22 04:58:12 <xxiao> while angstrom/yocto both makes release, will oe make any its own release in the future?
Dec 22 04:59:13 <xxiao> i.e. oe-core/meta-oe release 1.0, or something like that
Dec 22 04:59:32 <xxiao> that can be used as a starting point for, say, other chips
Dec 22 04:59:45 <xxiao> non x86, non arm chips
Dec 22 05:00:39 <xxiao> i guess my question is that, what is oe these days? part of yocto, or still an independent entity
Dec 22 05:00:55 <xxiao> if the latter is true, will it make its releases for all archs to use
Dec 22 05:03:19 <kergoth> perhaps, not sure what the release plans are
Dec 22 05:03:30 <kergoth> oe is an independent entity that works with yocto
Dec 22 05:04:01 <xxiao> will try to use only oe-core and see if can boot it up on a few boards here
Dec 22 05:04:26 <xxiao> oe-core is supposedly able for a minimalist rootfs
Dec 22 05:23:42 <Basith> When loading Filesystem in at91sam9263ek I get the error: Failed to open /dev/kmsg for logging: No such file or directory
Dec 22 05:24:12 <xxiao> does it boot up eventually?
Dec 22 05:24:15 <xxiao> do you have /dev?
Dec 22 05:24:19 <xxiao> are you using devtmpfs?
Dec 22 05:25:30 <xxiao> or, is this because of systemd
Dec 22 05:26:27 <Basith> after I fusing angstrom consoleimage, i got the error.  is this beacause of kernel or filesystem?
Dec 22 05:27:48 <Basith> I build the kernel now. 
Dec 22 05:27:58 <xxiao> i would check: 1. /dev is created. 2. devtmpfs is enabled(kernel), with both you should be fine
Dec 22 05:34:45 <Basith> Yeah. i have not added the feature in the kernel
Dec 22 05:53:39 <MrCurious_> i built gumstick kernel make oldconfig; make uImage modules modules_install. copied uImage to the boot partition, and on reboot i get kernel panic.  
Dec 22 05:53:46 <MrCurious_> building on the gumstick
Dec 22 05:54:00 <MrCurious_> i get the feeling i am missing a step
Dec 22 06:06:57 <khem> MrCurious_: where did u put the modules ?
Dec 22 06:07:24 <khem> and what kind of panic do u get
Dec 22 06:07:27 <MrCurious_> where ever make modules_install put them
Dec 22 06:08:03 <khem> by default they get installed into your /lib 
Dec 22 06:08:18 <khem> I hope you dont want arm modules on your x86 box
Dec 22 06:08:34 <MrCurious_> i am building on the target arm device
Dec 22 06:08:42 <khem> oh ok
Dec 22 06:08:53 <MrCurious_> so i figured the procedure would be like a reg intel box
Dec 22 06:09:08 <MrCurious_> except for cp uImage to the fat boot fs
Dec 22 06:09:12 <MrCurious_> ls /lib
Dec 22 06:09:37 <khem> where did u get the .config from ?
Dec 22 06:10:02 <MrCurious_>  zcat /proc/config.gz > .config
Dec 22 06:10:29 <MrCurious_> as in theory i am building the same kernel sources taken from sakoman's git, and advanced to the 3.0.0 tag
Dec 22 06:11:10 <MrCurious_> searching teh web, it appears NOBODY EVER builds a kernel "on" the arm device
Dec 22 06:11:17 <MrCurious_> always cross compiling with bitbake
Dec 22 06:11:47 <khem> hmm lot of folks build on the target may be not kernel 
Dec 22 06:11:53 <khem> but other packages
Dec 22 06:11:59 <khem> kernel is no exception
Dec 22 06:12:06 <MrCurious_> i wonder if the load address is off by defaault
Dec 22 06:12:56 <khem> you have to check by default when you cross compile we generate uimage ourselves on OE i.e. not use kernel built uimage
Dec 22 06:13:22 <MrCurious_> THAT may be it...
Dec 22 06:15:37 <MrCurious_> getting a working boot and a non working boot for comapre now
Dec 22 06:15:45 <Basith> When I cross compile Qt program using my angstrom toolchain I got the error: string: No such file or directory 
Dec 22 06:15:46 <MrCurious_> can paste the panic in a moment
Dec 22 06:16:25 <MrCurious_> the panic http://pastebin.com/CxC6NZMU
Dec 22 06:18:10 <MrCurious_> virtual kernel memory layout has a .bss section in the working one, but not in the broke one
Dec 22 06:20:51 <MrCurious_> now i wonder if i have to rebuild mlo or u-boot.bin when i recompile the kernel
Dec 22 06:24:55 <MrCurious_> i suppose i need to ask what MLO  u-boot.bin  do
Dec 22 06:25:03 <MrCurious_> i thought MLO was a generic boot loader
Dec 22 06:48:35 <MrCurious_> is there a depmod step?
Dec 22 06:48:53 <MrCurious_> after make modules_install, do you need to do something to get them inventoried into a table or something?
Dec 22 06:58:33 <Basith> How to add Qt package with console-image?
Dec 22 07:20:58 <MrCurious_> hmmmm nothing in /boot has a timestamp from today. i bet that is the problem
Dec 22 07:24:23 <MrCurious_> guess i forgot the target "install"
Dec 22 07:37:21 <MrCurious_> nope maie install was not the answer
Dec 22 08:44:24 <kenws> good morning
Dec 22 09:46:51 <likewise_> gm
Dec 22 09:47:22 <woglinde> hi likewise
Dec 22 09:48:01 <likewise> hi woglinde 
Dec 22 09:48:32 <woglinde> hm zecke should wake up
Dec 22 09:49:10 <ka6sox> time for bed
Dec 22 09:49:34 <woglinde> haha
Dec 22 09:54:46 <ka6sox> woglinde, that because I am headed out or the nick that just joined?
Dec 22 10:39:33 <bluelightning> morning all
Dec 22 10:41:01 <anarsoul> hi, bluelightning
Dec 22 10:47:35 <ant_work> good morning
Dec 22 12:47:54 <rlrosa1> hi
Dec 22 12:48:07 <rlrosa1> i'm getting this error when trying to bitbake console-image
Dec 22 12:48:09 <rlrosa1> http://www.heypasteit.com/clip/05HX
Dec 22 12:48:12 <rlrosa1> any tips?
Dec 22 13:07:57 <ant_work> hi woglinde 
Dec 22 13:08:23 <woglinde> jo ant
Dec 22 13:08:39 <woglinde> last day before christmas holiday?
Dec 22 13:10:34 <woglinde> ant or do you have to work tomorrow
Dec 22 13:19:34 <bluelightning> ericben: think I may have found the cause of the qt arch issue
Dec 22 13:19:46 <ericben> hi bluelightning 
Dec 22 13:19:47 <woglinde> bl very good
Dec 22 13:19:51 <woglinde> gm ericben
Dec 22 13:19:54 <ericben> hi woglinde 
Dec 22 13:19:59 <bluelightning> hi guys
Dec 22 13:20:01 <otavio> Hello
Dec 22 13:20:06 <woglinde> hi otavio
Dec 22 13:20:11 <ericben> bluelightning: I can test if you have patches.
Dec 22 13:20:11 <woglinde> ericben images still building?
Dec 22 13:20:13 <ericben> hi otavio 
Dec 22 13:20:32 <ericben> woglinde: yes, I built and rebuilt several images without any problem since yesterday
Dec 22 13:20:39 <woglinde> hm
Dec 22 13:20:40 <woglinde> strange
Dec 22 13:20:47 <ericben> khem's fix seems right. That doesn't explain why sometiumes this was working
Dec 22 13:20:55 <woglinde> the last thing comes to my mine
Dec 22 13:21:00 <woglinde> is the host env
Dec 22 13:21:05 <ericben> in fact that's the same thing with the qt problem, somethime that works
Dec 22 13:21:28 <ericben> well on the same host I managed to have successful builds and failed builds so that's not only the host env
Dec 22 13:22:18 <ant_work> woglinde: I'll be still here tomorrow but it will be calm ;)
Dec 22 13:25:08 <ant_work> otavio: how's going the udev merge? iirc the one in meta-oe is too new for the pre 2.6.27 kernels. Now, should oe-core support those?
Dec 22 13:28:26 <ant_work> otavio: one more note about udev cache, failing in some cases because rootfs is still RO. In oe-classic there was this patch  http://cgit.openembedded.org/openembedded/commit/recipes/udev?h=org.openembedded.dev&id=b6838a476a9c448cd994634688ead0815226b9fe
Dec 22 13:29:05 <otavio> ant_work: I need someone to test current patches
Dec 22 13:29:06 <ant_work> but was rejected when I proposed it so I have to add a custom etc/defaults/udev in the BSP 
Dec 22 13:29:33 <ant_work> finally this device cache seems not so usefull nowadays...
Dec 22 13:29:35 <bluelightning> ericben: could you try the paule/qt4-arch-fix OE-core contrib branch?
Dec 22 13:29:38 <otavio> ant_work: yes; newer requires 2.6.36 kernels for arm, for example
Dec 22 13:30:13 <otavio> ant_work: but I don't think we ought to support such too old kernels in master
Dec 22 13:30:20 <ant_work> neither me
Dec 22 13:30:22 <foerster> rlrosa1: update meta-oe, a fix went in yesterday for it
Dec 22 13:30:31 <bluelightning> ericben: pretty simple fix but it worked for me for qemumips and seems to be for qemuarm
Dec 22 13:31:34 <ericben> bluelightning: will do after meal thanks
Dec 22 13:32:08 <woglinde> bl wehere is the branch?
Dec 22 13:32:09 <bluelightning> ericben: ok cool
Dec 22 13:32:28 <bluelightning> woglinde: http://cgit.openembedded.org/openembedded-core-contrib/log/?h=paule/qt4-arch-fix
Dec 22 13:32:33 <woglinde> hm
Dec 22 13:32:38 <woglinde> why cgit didnt show me it
Dec 22 13:32:43 <ant_work> otavio: related to this there is the 'issue' of initial device_tables: when I asked to extend those the answer was 'use devtmpfs'. Well, why udev-cache then? If one needs something special can write an ad-hoc rule
Dec 22 13:32:45 <otavio> ant_work: seems already support by current code
Dec 22 13:32:48 <bluelightning> I only just pushed it, perhaps some delays occurred :)
Dec 22 13:33:43 <woglinde> yeah patch sounds reasonable
Dec 22 13:35:25 <otavio> ant_work: is it possible for you  to test current set?
Dec 22 13:35:49 <otavio> ant_work: am updating it regarding fixes and improvements done on meta-oe before doing the version update
Dec 22 13:36:37 <ant_work> otavio: yes, I'll try later this evening
Dec 22 13:38:24 <ant_work> otavio: I meant this patchset:
Dec 22 13:38:46 <ant_work> http://patches.openembedded.org/patch/11719/   11717   11715
Dec 22 13:39:05 <ant_work> (sorry, posted link to wrong patch)
Dec 22 13:39:10 <ant_work> (before)
Dec 22 13:40:32 <JaMa|Wrk> otavio: I'm currently working on something else.. so please update xserver-nodm-init when you have time
Dec 22 13:42:35 <otavio> ant_work: be careful to not use meta-oe or it can end getting the wrong files
Dec 22 13:42:49 <ant_work> otavio: ah, ok...
Dec 22 13:43:27 <ant_work> otavio: in fact atm meta-oe is toxic because of xserver-nodm-init too ;)
Dec 22 13:43:50 <ant_work> ..but I need xfbdev from it...
Dec 22 13:46:47 <kenws> Hi there, what's the preferred may of adding/overriding compile options?
Dec 22 13:47:46 <kenws> I'm using a toolchain that defaults to thumb which causes issues when using building oe-core. The quemuarm machine configuration adds -mno-thumb (ARM_THUMB_M_OPT) but that doesn't prevent recent GNU toolchains from emitting thumb code anymore.
Dec 22 13:48:01 <kenws> ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47930 )
Dec 22 13:49:17 <kenws> So, I'd like to add "-marm" to the list of options
Dec 22 13:49:20 <woglinde> kenws hm khem will fix it for us
Dec 22 13:49:56 <kenws> there is this TOOLCHAIN_OPTIONS variable but I'm not sure if this is appropriate
Dec 22 13:51:17 <kenws> woglinde: ok, I see. But in general. How do you add or change compiler flags in oe-core?
Dec 22 13:51:50 <kenws> lets say you'd like to use -Os for all your builds
Dec 22 13:52:01 <woglinde> for arm we have a special option
Dec 22 13:53:03 <woglinde> ARM_INSTRUCTION_SET = "ARM"
Dec 22 13:53:14 <kenws> yep, saw that.
Dec 22 13:53:38 <kenws> ARM_THUMB_M_OPT depends on that
Dec 22 13:53:55 <kenws> and sets -mthumb or -mno-thumb
Dec 22 13:54:41 <kenws> imo, it would be better to use -marm instead of -mno-thumb
Dec 22 13:55:02 <woglinde> kenws hm write to the oe-core ml
Dec 22 13:55:12 <woglinde> but until know we saw no problems
Dec 22 13:58:44 <kenws> yep, I didn't see any patches in meta/recipes-devtools/gcc/gcc-4.6
Dec 22 13:59:03 <kenws> it seems oe-core is using 4.6.3 by default
Dec 22 13:59:03 <woglinde> kenws did you saw any problems?
Dec 22 13:59:25 <kenws> nope
Dec 22 13:59:56 <kenws> I suspect that change isn't in 4.6.3
Dec 22 14:00:27 <kenws> it was comitted to trunk on 2011-05-06
Dec 22 14:00:48 <kenws> hm
Dec 22 14:01:05 <kenws> however
Dec 22 14:01:20 <kenws> woglinde: in general, how do you add/change gcc options?
Dec 22 14:01:31 <kenws> for example to add -Os
Dec 22 14:01:32 <woglinde> hm
Dec 22 14:01:52 <woglinde> in the gcc recipes
Dec 22 14:04:53 <kenws> hm? I don't mean building the gcc with -Os : )
Dec 22 14:04:57 <kenws> but adding this option to the list of gcc option
Dec 22 14:05:28 <kenws> so that every package for the target gets compiled with -Os
Dec 22 14:05:59 <woglinde> hm or was it distro options
Dec 22 14:06:00 <woglinde> mom
Dec 22 14:06:00 <kenws> there is the TOOLCHAIN_OPTIONS variable
Dec 22 14:07:55 <woglinde> hm FULL_OPTIMIZATION variable
Dec 22 14:08:04 <woglinde> but should be set by distro
Dec 22 14:08:12 <woglinde> or is overriden by it
Dec 22 14:09:11 <kenws> maybe optimization flags are a bad example because they tend to be overwritten by the makefiles
Dec 22 14:09:18 <woglinde> yes
Dec 22 14:09:26 <woglinde> sometimes we override them in recipes
Dec 22 14:09:31 <woglinde> when we know its broken
Dec 22 14:10:10 <kenws> yup
Dec 22 14:19:01 <kenws> ah, I think I know why oe-core doesn't see any issues with -mno-thumb yet
Dec 22 14:19:16 <kenws> probably because it's not configured --with-mode=thumb
Dec 22 14:19:42 <kenws> which means it doesn't default to ARM mode
Dec 22 14:21:05 <woglinde> kenws wait for khem
Dec 22 14:21:16 <woglinde> he knows the actual toolchain better than me
Dec 22 14:21:28 <kenws> ok, thanks woglinde!
Dec 22 14:22:56 <kenws> woglinde: one last thing: could you paste the gcc -v output of the default oe-core cross toolchain?
Dec 22 14:23:32 <kenws> unfortunately I deleted the build dir and switched to an external toolchain
Dec 22 14:24:05 <woglinde> mom
Dec 22 14:24:09 <woglinde> hm
Dec 22 14:24:15 <woglinde> I am using angstroem
Dec 22 14:24:20 <woglinde> where the default gcc is 4.5
Dec 22 14:24:43 <kenws> ok : )
Dec 22 14:24:53 <kenws> it's not really urgent, I'm just curious
Dec 22 14:25:28 <woglinde> do you want it anyway?
Dec 22 14:26:21 <kenws> woglinde: yep, it would be interesting anyway
Dec 22 14:29:33 <kenws> I guess it doesn't default to thumb
Dec 22 14:29:42 <woglinde> http://pastebin.com/hQWSFtsB
Dec 22 14:29:51 <kenws> *click*
Dec 22 14:30:20 <kenws> yep, this one defaults to ARM mode
Dec 22 14:35:59 <kenws> woglinde: are you using http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-angstrom/ ?
Dec 22 14:36:08 <kenws> or the classic one
Dec 22 14:36:32 <woglinde> yes
Dec 22 14:43:15 <woglinde> hi kgilmer and xxiao
Dec 22 14:45:37 <rlrosa1> foerster: worked now, thanks!
Dec 22 14:49:39 <kgilmer> hi woglinde :)
Dec 22 14:51:03 <gchiii> If I am working on the AM3517evm should I be using the arago repositories based on an old maintenance-2011.03 branch or should I use the newer oe-core stuff?
Dec 22 14:51:51 <woglinde> gchiii checkout what is in meta-texasinstrument and decide yoursel
Dec 22 14:51:51 <woglinde> f
Dec 22 14:52:12 <ericben> gchiii: oe-core + meta-oe + meta-angstrom + meta-ti  : https://github.com/Angstrom-distribution/meta-ti/blob/master/conf/machine/am3517-evm.conf
Dec 22 14:53:08 <gchiii> thanks!  I will check that out!  is anyone doing work with PREEMPT_RT for the AM3517evm?
Dec 22 14:53:52 <ericben> gchiii: and for the instructions : http://www.angstrom-distribution.org/building-angstrom
Dec 22 14:54:17 <ericben> no idea concerning preempt_rt on am3517evm
Dec 22 14:55:12 <woglinde> hm rt will come to kernel 3.2 or 3.3
Dec 22 14:55:50 <otavio> ant_work: xserver-nodm-init? why?
Dec 22 14:56:53 <ant_work> otavio: 2 main reasons are different RDEPENDS (e.g. xinput-calibrator), wrong xsettings
Dec 22 14:58:00 <ant_work> fundamentally one is for systemd
Dec 22 14:58:15 <ant_work> while oe-core is still to sysvinit
Dec 22 14:59:07 <ant_work> the settings are due by the different x11-common or xserver-common pulled by xserver-nodm-init
Dec 22 14:59:37 <ant_work> which is another rdependency
Dec 22 16:15:10 <bluelightning> ericben: qemuarm with that patch went through OK here
Dec 22 16:15:30 <bluelightning> did you have a chance to test it on your side?
Dec 22 16:16:42 <otavio> ant_work: I will look that
Dec 22 16:17:22 <otavio> ant_work: ran a test using the udev patches?
Dec 22 16:20:25 <ant_work> no sorry, still in office
Dec 22 16:25:19 <likewise> gchiii: are you planning to work on PREEMPT_RT?
Dec 22 16:25:54 <likewise> is systemd any better for embedded systems? I didn't see a good comparison anywhere, only discussions.
Dec 22 16:26:15 <otavio> likewise: it is impressive
Dec 22 16:26:29 <otavio> likewise: it uses more storage space but it is quite fast
Dec 22 16:26:51 <bluelightning> likewise: see koen's talk from ELCE for the speed improvements
Dec 22 16:27:00 <likewise> bluelightning: thanks
Dec 22 16:27:17 <bluelightning> it only occurred to me today I should have asked about the size comparison during his tests
Dec 22 16:27:17 <gchiii> likewise: the project we are working on requires some hard realtime, so yes we are using PREEMPT_RT.  the problem is that the modified kernel from TI's sdk for the AM3517 doesn't have realtime, and doesn't have it's patches upstreamed.
Dec 22 16:28:56 <likewise> gchiii: ok, i am interested as well, but do not know the state of affairs on 3517 yet.
Dec 22 16:31:50 <gchiii> likewise: we have started hacking together a 2.6.33-rt31 with stuff mashed in from the 2.6.32 from TI's SDK that we need to make it work.  later today I can set up github and put our stuff up there
Dec 22 16:32:44 <fcooper> gchiii: the kernel for the Sitara (which includes am3517) doesn't have support for PREEMPT_RT. Like you noted the kernel used by those devices are a modified version of the Linux kernel which means there is a chance the PREEMPT_RT patch won't apply cleanly to the kernel. If you still end up applying the patch to the kernel then there is no guaranteed that any of the drivers TI supplied will work.
Dec 22 16:33:27 <gchiii> yeah, that is what we are struggling with now
Dec 22 16:34:14 <gchiii> is there a better forum to get help for the PREEMPT_RT and am3517 stuff?
Dec 22 16:37:41 <fcooper> gchiii: If you are looking for a TI forum then your best bet is E2E but to be honest you probably won't get too much help with it. The team that works on the kernel has stated that they don't plan on supporting the real time.
Dec 22 16:38:22 <gchiii> yeah, the E2E forum hasn't been very useful so far
Dec 22 16:38:49 <gchiii> if only we had chosen to build around the beaglebone! :)
Dec 22 16:39:32 <fcooper> gchiii: What is the product you are working on that you need the real time OS support?
Dec 22 16:39:46 <gchiii> a medical device
Dec 22 16:41:17 <likewise> gchiii: Topic for #linux-rt is “Please move to irc.oftc.net #linux-rt”
Dec 22 16:41:56 <likewise> gchiii: but also stay in touch here, OE definitely has RT interest (I have a tree for PowerPC that is used in products, and XScale ARM)
Dec 22 16:50:38 <fray> fyi, the Yocto Project has preempt RT stuff in it's kernel as well
Dec 22 16:51:10 <fray> I believe the preempt rt (I may be wrong as I don't work on that stuff normally) works on all four major architectures.. ia, arm, mips and ppc
Dec 22 17:06:11 <like|food> fray: yes and no, support varies per release per arch and sometimes even per-machine (cache related)
Dec 22 17:07:14 <fray> Yes, but the core preempt-rt work is there for each fo the four main architectures and many cpus..
Dec 22 17:07:34 <fray> It's available in one tree vs scattered in local trees.. thats all I was trying to say
Dec 22 17:30:49 <gchiii> fray: we tried using the kernel from the yocto project with the preempt-rt stuff but the kernel wouldn
Dec 22 17:30:56 <gchiii> 't run 
Dec 22 17:31:19 <fray> be sure to file a bug then.  preempt-rt is something we're really trying to keep current and working
Dec 22 17:31:34 <bluelightning> yes, and feel free to ping dvhart, he's our rt expert
Dec 22 17:34:43 <gchiii> ok, i suspect that it is either an am3517evm issue, or I was doing something wrong with building the kernel.  I didn't actually use yocto project, i just pulled the kernel from git and did a checkout of the preempt-rt/base branch from the 3.0
Dec 22 17:35:26 <fray> thats a reasonable place to start..  there are patches that sit on top of the base for various architectures.. (they should have their own branch names as necessary)
Dec 22 17:35:37 <fray> (again, I may be wrong there, but thats how it was last time I used it)
Dec 22 18:00:46 <ka6sox-away> fray, I also tried and failed with it.
Dec 22 18:03:01 <ericben> bluelightning: unfortunatly I can't tell if your patch fix the problem as I didn't reproduce it in all my last builds. I'll launch it tonight to check if doesn't break my builds.
Dec 22 18:09:10 <fray> ka6sox-away definitaly post your comments or contact dvhart..  we need feedback when it doesn't work as expected
Dec 22 18:13:35 <bluelightning> ericben: if my hunch about how the problem is triggered is correct it may only happen if you build qt4-native and qt4-(embedded|x11-free) in the same build
Dec 22 18:13:46 <bluelightning> or very close together timewise
Dec 22 18:14:04 <bluelightning> ultimately if it doesn't break the builds it should be fine to go in
Dec 22 18:59:41 <likewise> hi stefan_schmidt 
Dec 22 19:00:02 <stefan_schmidt> hi likewise 
Dec 22 19:23:25 <woglinde_> hi stefan_schmidt
Dec 22 19:23:49 <stefan_schmidt> moin woglinde_ 
Dec 22 19:51:33 <likewise> otavio: ping, git question time :)
Dec 22 19:59:10 <otavio> likewise: i replied on pvt
Dec 22 20:34:22 <ka6sox-away> fray, will do
Dec 22 20:59:22 <JaMa> any hint why 'INHERIT_append_pn-phoneuid = "srctree gitpkgv"' doesnt' work anymore? it worked with OE-classic
Dec 22 20:59:44 <woglinde> hm so lets see if openjdk jamvm works too
Dec 22 20:59:48 <woglinde> than I can commit all stuff
Dec 22 21:10:26 <bluelightning> JaMa: maybe try INHERIT_pn-phoneuid_append ?
Dec 22 21:10:55 <bluelightning> I know there was a bitbake patch for that kind of thing not that long ago
Dec 22 21:12:05 <bluelightning> although we do _append_machine all the time and that works, so maybe not...
Dec 22 21:14:42 <JaMa> bluelightning: but that will overwrite any INHERIT which is already applied for pn-phoneuid I want to add more
Dec 22 21:25:14 <JaMa> bluelightning: even INHERIT_pn-phoneuid +=/INHERIT_pn-phoneuid_append doesn't work, INHERIT += does, but that's not usefull from local-builds.inc file :)
Dec 22 21:38:16 <reactor16> hi all
Dec 22 21:39:54 <reactor16> is there way to modify a program recompile it self in opendreambox project ?
Dec 22 21:43:55 <woglinde> ?
Dec 22 23:17:34 <likewise> what should LICENSE be for firmware? "CLOSED" ??
Dec 22 23:17:55 <likewise> it's a proprietary license from Freescale, what should I put there?
Dec 23 00:27:52 <khem> likewise commercial
Dec 23 00:28:34 <likewise> khem: thanks, I could not find this
Dec 23 00:30:36 <khem> likewise: you could use something like
Dec 23 00:30:38 <khem> Proprietary
Dec 23 00:30:43 <khem> for LICENSE value
Dec 23 00:31:42 <ant____> otavio: the udev patches after v2-3 doesn't apply here
Dec 23 00:31:46 <khem> but then see if it has to be added to COMMERCIAL_LICENSE_DEPENDEES
Dec 23 00:32:06 <khem> ant____: after so many revs things lose relevance :)
Dec 23 00:32:32 <ant____> heh..I hope I got the last one from patchwork
**** ENDING LOGGING AT Fri Dec 23 02:59:56 2011