**** BEGIN LOGGING AT Thu Oct 18 03:00:00 2018 Oct 18 13:58:13 hi. please point me towards the solution: what's the best way to instruct bitbake to include a number of ipk packages of my own in a final build? Oct 18 14:02:33 waterscale: i've never heard of a direct way to do that, other than to write wrapper recipes Oct 18 14:04:18 i may be lost then. the reason i want to do this is i don't have necessary software available in my branch ("morty"), and copying it from the master branch into my layer just throws python exception all around (unsurprisingly) Oct 18 14:04:33 but i have ipk on hand and it installs okay. any other way i should be doing that? Oct 18 14:05:56 backport the recipes properly? it might be a little more work than just copying over from master, but if theres already a blueprint available it should be doable. Oct 18 14:07:13 i mean, which ones are we talking about? Oct 18 18:10:26 hmm, did anyone manage to use the KERNEL_PACKAGE_NAME option and if yes - how? I tried following the instructions in the message of commit 5b4aab6b40cf21471442e21abc8051b38985de84, but I end up with an error "The recipe linux-4.1.45 is trying to install files into a shared area when those files already exist." Oct 18 18:10:53 am I missing something or does it not work as intended? Oct 18 18:13:29 for quick reference, here's that commit message: https://paste.ee/p/Lc6a8 Oct 18 18:16:20 does it matter if KERNEL_PACKAGE_NAME_pn-linux-yocto-tiny = "tiny-linux" is set in the actual recipe instead of local.conf? Oct 18 19:44:57 Jin^eLD: in the recipe just set KERNEL_PACKAGE_NAME, that full syntax is for local.conf Oct 18 19:50:48 rburton: I tried both and this step does not seem to be the problem, it tries to compile as it should Oct 18 19:50:59 but it fails in do_packagedata Oct 18 19:51:07 seems that it conflicts with the default kernel provider for some reason Oct 18 19:51:25 which it should not... at least according to the feature description Oct 18 20:58:43 where are kernel modules packaged, also in kernel.bbclass? Oct 18 20:59:13 or is package.bbclass taking care of it in 2.5.1? Oct 18 20:59:27 (remember I come from 2.0 so may have missed a lot) Oct 18 21:01:08 to me it seems that the packaging of kernel modules doe snot take the KERNEL_PACKAGE_NAME feature into account at all Oct 18 21:29:34 doh.. ok sorry, ignore everything I wrote above :) I had a forgotten old bbclass that was overloading and messing up the kernel module split class of 2.5.1, KERNEL_PACKAGE_NAME works as it should :P sorry for the confusion **** ENDING LOGGING AT Fri Oct 19 03:00:00 2018