**** BEGIN LOGGING AT Mon Nov 16 02:59:58 2015
Nov 16 15:59:19 <spaszPL> Helo guys. Do you know sth about clock in SDIO? I have a wifi module AP6210 with mainline kernel 3.16. From my observations i see that 50MHz SDIO CLOCK is still ticking. Could i disable this? 
Nov 16 15:59:35 <spaszPL> For example on SD card clock is ticking only when data is sent.
Nov 16 16:00:04 <spaszPL> in my wifi, clock is all the time enable. It dosen't matter that data is coming, going etc
Nov 16 16:59:20 <otavio> rburton: hello
Nov 16 16:59:46 <otavio> can you update me regarding the patches I sent? anything waiting for me?
Nov 16 17:12:13 <rburton> otavio: anything in particular? 
Nov 16 17:12:39 <otavio> rburton: u-boot
Nov 16 17:12:43 <otavio> rburton: lttng
Nov 16 17:12:46 <otavio> rburton: weston
Nov 16 17:12:50 <rburton> lttng is in
Nov 16 17:12:57 <rburton> the colord weston one is in
Nov 16 17:13:02 <rburton> (mut, that is)
Nov 16 17:13:24 <rburton> u-boot 2015.10 is in mut too now
Nov 16 17:24:19 <otavio> rburton: good
Nov 16 17:42:21 <rburton> otavio: oh, oe-core master has the new gstreamer now
Nov 16 17:42:40 <otavio> rburton: and meta-fsl-arm is broken, right/
Nov 16 17:43:01 <rburton> yeah
Nov 16 17:43:56 <otavio> rburton: nobody has reported it yet on ml; I will wait a couple of days and see if someone looks at it for me ;)
Nov 16 17:44:01 <rburton> haha
Nov 16 17:44:25 <otavio> rburton: well, otherwise I do all the work
Nov 16 17:44:38 <rburton> i like your style
Nov 16 17:44:59 <otavio> lol
Nov 16 17:46:06 <otavio> rburton: when lttng gets merged, my master-next branch will move ahead and will get the error ;-)
Nov 16 18:38:12 <otavio> rburton: who is working at xwayland integration?
Nov 16 20:40:56 <rburton> otavio: joshuagl send something along those lines 
Nov 16 21:00:16 <jeroen_> hi, I added a deb file to a SRC_URI it seems to get extracted... is that a side effect of something or an intended feature?
Nov 16 21:07:35 <rburton> intended
Nov 16 21:07:38 <rburton> you can disable it though
Nov 16 21:07:50 <rburton> add ;extract=0 i think
Nov 16 21:08:19 <rburton> oh, huh
Nov 16 21:08:21 <rburton> maybe you can't!
Nov 16 21:08:39 <rburton> right, ;unpack=0
Nov 16 21:09:15 <rburton> so file://some-package.deb;unpack=0
Nov 16 21:09:22 <rburton> jeroen_: ^
Nov 16 21:36:59 <jeroen_> rburton: thanks, happen to know who unpacks it? fetcher I assume?
Nov 16 21:37:30 <jeroen_> rburton: the intend of it, since it likely overlaps with the hacks I have in mind...
Nov 16 21:38:25 <jeroen_> rburton: If it is possible to control where it is extracted to, but if I know who is extracting it, I can read the code as well..
Nov 16 22:02:14 <kergoth> subdir= will contorl where it's unpacked to
Nov 16 22:02:24 <kergoth> see bitbake/lib/bb/fetch2/__init__.py, the unpack() method
Nov 16 22:02:37 <kergoth> also the individual fetchers can exert control over unpack, e.g. the git one uses git clone
Nov 16 22:07:15 <jeroen_> kergoth, rburton: thanks, I will hack on tomorrow but that seems to work...
Nov 16 22:08:37 <jeroen_> kergoth, rburton: I am curious though who is interested in adding deb support, but git log can likely tell me... going to sleep for now... thanks again
Nov 16 22:08:56 <kergoth> that depends on what you mean by deb support
Nov 16 22:09:39 <kergoth> we already support emitting debian packages and feeds and building images based on them, and as you've seen, we can extract debs as input, but don't expect to be able to convert a binary .deb into our builds and have things actually work. metadata translation is non-trivial, and binary compatibility is a serious concern
**** ENDING LOGGING AT Tue Nov 17 02:59:58 2015