**** BEGIN LOGGING AT Thu Apr 09 02:59:58 2015
Apr 09 06:59:30 <mag0> what does it mean when a patch gets archived in patchwork? Such as this one: http://patchwork.openembedded.org/patch/90961/
Apr 09 06:59:48 <mag0> I would really like to see it get merged, not sure what the hold-up is 
Apr 09 07:11:23 <JaMa> mag0: that it was sorted to correct bundle
Apr 09 07:11:51 <JaMa> waiting for dizzy maintainers to pick it up
Apr 09 07:22:01 <mag0> JaMa: ok, cool
Apr 09 08:27:52 <bluelightning> morning all
Apr 09 08:28:01 <nrossi> morning :)
Apr 09 08:37:08 <Jin^eLD> mornin
Apr 09 10:31:16 <Crofton|work> gm
Apr 09 13:20:14 <funman> hello
Apr 09 13:20:47 <funman> my Linux do_compile is on an infinite loop of:
Apr 09 13:20:48 <funman>   GEN     /media/SSD/odroid-c1/build/tmp-glibc/work/odroid_c1-angstrom-linux-gnueabi/linux-hardkernel/3.10.70+gitrAUTOINC+103250bf03-r0/build/Makefile
Apr 09 13:21:00 <funman> not sure how to debug this, make -d doesn't give me much insight
Apr 09 13:21:44 <funman>    File 'outputmakefile' does not exist.
Apr 09 13:21:49 <funman>   Must remake target 'outputmakefile'.
Apr 09 13:22:38 <funman> here's the eternally regenerated makefile: http://pastie.org/10082469
Apr 09 13:24:28 <funman> and a verbose make log: http://pastie.org/10082472
Apr 09 13:32:59 <funman> wonder if it could be that the upstream kernel minor version was updated and i didnt change the version number in .bb
Apr 09 13:33:28 <funman> nope ..
Apr 09 13:41:42 <funman> seems to originate fromhttps://github.com/hardkernel/linux/commit/e7e558176262e7f284e7dd0b923c35514c44ce49
Apr 09 14:00:57 <funman> not sure why but the fix is http://pastie.org/10082543
Apr 09 17:43:37 <Jin^eLD> hmm, when there is a kernel.bbclass in the default yocto dir and I have a layer with higher prio and I put a kernel.bbclass in my layers class dir - mine should be taken, not the stock one, right?
Apr 09 17:44:26 <bluelightning> Jin^eLD: priority doesn't factor into how bitbake locates classes / included files I'm afraid
Apr 09 17:44:37 <Jin^eLD> hmm
Apr 09 17:44:46 <bluelightning> that's handled through BBPATH, which each layer.conf will either prepend or append
Apr 09 17:44:54 <Jin^eLD> ah
Apr 09 17:45:00 <Jin^eLD> ok let me check if I messed up there maybe
Apr 09 17:45:02 <bluelightning> thus it depends on the order that each layer.conf is parsed, which is controlled by the order they appear in bblayers.conf#
Apr 09 17:45:24 <Jin^eLD> ok, my layer is at the very end
Apr 09 17:45:47 <Jin^eLD> i.e. I have BBLAYERS = "" and then listing all layers
Apr 09 17:45:54 <bluelightning> generally overlaying bbclasses isn't recommended because it can easily go wrong like this
Apr 09 17:46:29 <Jin^eLD> in bbpath my layers is last in the list also
Apr 09 17:47:03 <Jin^eLD> well, what would be the "suggested" way? rename to own classes?
Apr 09 17:47:36 <Jin^eLD> but then I would not be able to reuse some kernel .inc files from other layers because those inherit the "regular" classes
Apr 09 17:47:53 <Jin^eLD> coming back to the order in BBPATH
Apr 09 17:47:58 <Jin^eLD> who "wins"? the first or the last in the list?
Apr 09 17:48:03 <Jin^eLD> i.e. whats the priority order there?
Apr 09 17:50:10 <bluelightning> BBPATH is like PATH - the first location in which the requested file exists wins
Apr 09 17:50:23 <Jin^eLD> ok got it, thanks
Apr 09 17:50:30 <bluelightning> re the class, the question is what kind of change are you trying to make?
Apr 09 17:50:47 <Jin^eLD> bluelightning: I am not sure if I was talking to you about it, I may have, I need multiple kernels in the rootfs
Apr 09 17:50:55 <Jin^eLD> I know I also discussed it with kergoth 
Apr 09 17:51:07 <bluelightning> ah, right - I remember at least seeing you discussing it with him
Apr 09 17:51:10 <Jin^eLD> but I think I was also talking to you couple of weeks ago
Apr 09 17:51:16 <bluelightning> possibly yes
Apr 09 17:51:27 <Jin^eLD> or maybe someone else? someone told me it was kind of a wanted feature but not really on any list yet
Apr 09 17:51:42 <Jin^eLD> I hacked up a solution that seems to work, need to test it more
Apr 09 17:51:55 <bluelightning> this is something where for now it might make sense to overlay it, but we'd definitely want to see the changes in OE-Core
Apr 09 17:52:07 <Jin^eLD> I'll probably ask for your opinions on the dev ml
Apr 09 17:52:38 <Jin^eLD> and I'm willing to tune it if you think my approach would have a chance of making it upstream
Apr 09 17:53:03 <bluelightning> ok, personally I'm not likely to have many opinions as I'm not really a kernel person, but I'm sure others will
Apr 09 17:53:24 <Jin^eLD> well I'm not a kernel person either hehe, I just need multiple kernels in the rootfs :P
Apr 09 17:53:45 <Jin^eLD> we're fiddling around with a kexec based approach of "safe" kernel updates in the field
Apr 09 17:54:17 <Jin^eLD> where you basically have one kernel that is flashed and never changes and updated kernels in the rootfs which are handled by the package manager / live update machanism
Apr 09 17:54:35 <Jin^eLD> that's what I need this multiple-kernels thing for
Apr 09 18:03:44 <bluelightning> right, that's definitely one use case
Apr 09 20:07:51 <Crofton|work> if I drop BB_THREADS and PARALLEL_MAKE from local.conf, bitbake now guesses values? And this is true in dizzy also?
Apr 09 20:11:26 <kergoth> Crofton|work: looks like it, yes, see 1529ef05 in poky
Apr 09 20:11:42 <Crofton|work> I thought it had been done for a while
Apr 09 20:11:56 * Crofton|work notes he has never used Poky :)
Apr 09 20:11:57 <kergoth> (from a quick blame)
Apr 09 20:12:19 <kergoth> see also git log —grep="move BB_NUMBER_THREADS and PARALLEL_MAKE to bitbake.conf" in oe-core
Apr 09 21:01:24 <Crofton|work> kergoth, thanks
Apr 09 21:01:27 <Crofton|work> stressul day
**** ENDING LOGGING AT Fri Apr 10 02:59:59 2015