**** BEGIN LOGGING AT Mon Apr 13 02:59:57 2020
Apr 13 03:28:33 <yocti> New news from stackoverflow: yocto: how do I install header files along with kernel module in sdk <https://stackoverflow.com/questions/60780322/yocto-how-do-i-install-header-files-along-with-kernel-module-in-sdk>
Apr 13 03:34:52 <nameclash> good morning gents, is there any sleek way to have production and development builds?
Apr 13 03:36:21 <nameclash> so for example, the devel build would have additional tools for testing and debugging, which I don't want to ship with the final product
Apr 13 03:39:42 <nameclash> I was thinking of partitioning the packages in .inc files and then include either the one or the other from core-image-minimal
Apr 13 03:40:06 <nameclash> depending on an environment variable
Apr 13 04:02:20 <opello> would it be unreasonable to add an additional -devel package that included the extra tools (or just use the existing -dev package)?
Apr 13 04:05:51 <nameclash> no, not at all.. but I think that would suffer from the same problem I have with my clumsy .inc file solution, which is dynamic control over what gets in and what not
Apr 13 04:06:21 <nameclash> oh, wait
Apr 13 04:06:31 <nameclash> yeah that makes sense
Apr 13 04:07:15 <opello> as in when you choose to include the development helpers package?
Apr 13 04:07:22 <nameclash> I coud just say: bitbake core-image-minimal for the production build and bitbake core-image-minimal core-image-minimal-dev for the devel build
Apr 13 04:08:26 <opello> yeah, then the image RDEPENDS covers including the additional helper package(s) in the -dev case
Apr 13 04:10:20 <nameclash> yeah, since bitbake doesnt support conditions, I just injected variables that I used to include additional stuff
Apr 13 04:10:58 <nameclash> like in core-image-minimal I had a line in the bottom, saying require core-image-minimal${SUFFIX}.inc
Apr 13 04:11:42 <opello> without knowing more about your workflow it seems like it could be nicer to pack stuff like that into a bbclass?
Apr 13 04:11:45 <nameclash> with an empty core-image-minimal.inc and core-image-minimaldev.inc, where the former was empty and the latter one kept all the devel stuff
Apr 13 04:12:26 <opello> or if it just covers packages some nicely named packagegroups?
Apr 13 04:12:55 <nameclash> yeah, packagegroups or meta-packages seem to be a good fit for it
Apr 13 04:13:17 <nameclash> thanks!
Apr 13 05:41:34 <nameclash> opello, you still around?
Apr 13 15:50:13 <matthewzmd> for anyone worked with meta-qt5 before, i have qt5everywheredemo in IMAGE_INSTALL_append, and the build succeeds, how to I trigger the demo after i boot into the image?
Apr 13 16:00:05 <matthewzmd> have i missed anything, my wifi dropped immediately after i post my question
Apr 13 16:00:49 <yocti> New news from stackoverflow: Multiple rootfs through .wks file fails in yocto <https://stackoverflow.com/questions/61191659/multiple-rootfs-through-wks-file-fails-in-yocto>
Apr 13 16:24:43 <kergoth> Anyone played around with using debian multiarch's filesystem layout? ex ld-linux naming, libdir paths
Apr 13 16:46:03 <kergoth> On a not directly related note, has anyone looked into multiple target sysroots in a yocto sdk? Ex. use multiconfig to build for multiple target configurations and then build an sdk that populates sysroots for all of them, and then one nativesdk sysroot?
Apr 13 16:46:10 <kergoth> hmm
Apr 13 17:31:04 <yocti> New news from stackoverflow: How to use bitbake to add static web files? <https://stackoverflow.com/questions/61193275/how-to-use-bitbake-to-add-static-web-files>
Apr 13 18:23:48 <khem> kergoth: mutliconfig sdk is on my wishlist
Apr 13 18:25:30 <kergoth> I basically want a toolchain built by bitbake with a variety of multilib configurations, but it's easier to just use separate machines to construct multiple sysroots, so a multiconfig sdk would be the next best thing to a multilib setup with sysroot suffixes
Apr 13 18:44:44 <khem> kergoth: yeah I think gcc's notion of multilib doesn not match with OEs and neither with debian multiarch
Apr 13 18:45:00 <khem> so its a bit sad
Apr 13 18:54:14 <jpuhlman> khem there really isn't a lot that needs to be done to bring the oe's idea of mutlilib inline with gcc's.
Apr 13 18:55:07 <fray> the worst part of gcc's multilib vs OE.. is that gcc 'defaults' have far far too many multilibs defined in a lot of configs..
Apr 13 18:55:28 <fray> but it's certainly possible to build and use the gcc multilibs w/in the YP environment -- assuming you defined all the multilibs on the YP side.
Apr 13 18:55:46 <fray> debian multiarch is broken by design IMHO, but again it can be done as well by adjusting paths..
Apr 13 19:08:49 <kergoth> broken in what way?
Apr 13 19:08:56 <kergoth> are postinsts not run for nativesdk packages? particularly for update-alternatives?
Apr 13 19:09:06 <kergoth> not looking like it, but not certain
Apr 13 19:19:22 <RP> kergoth: no, they're not. There is an open bug :(
Apr 13 19:21:43 <kergoth> ah, thanks
Apr 13 19:23:09 <kergoth> it makes sense that it'd be a bit of a pain, sdk_arch isn't necessarily build_arch, so we'd need to either postpone to install/relocation time or run qemu, but i don't know how hard it'd be to run qemu against SDKMACHINE rather than  MACHINE
Apr 13 19:23:50 <kergoth> if you assume compat a chroot would do, but lacking root we'd have to fake it anyway, might as well use qemu
Apr 13 19:25:44 <RP> kergoth: our qemu support is way better than it used to be FWIW and on the most part they're shell anyway. Just needs someone to figure it all out...
Apr 13 19:25:57 * kergoth nods
Apr 13 19:26:11 <kergoth> I'll have to decide if I care enough. which is often the problem. what do i use my precious spare minutes on
Apr 13 19:26:15 <kergoth> heh
Apr 13 19:29:23 <RP> kergoth: would love your help!
Apr 13 19:29:48 <RP> kergoth: oe-core feels a bit lonely these days at times :(
Apr 13 19:32:22 <kergoth> yeah, sorry, i haven't been able to contribute much, family is taking a lot of time nowadays, and work is hectic and often on tasks that don't directly contribute. even my backlog of meta-mentor submissions is piling up, and that's my bare minimum contributions usually..
Apr 13 21:55:24 <hirnschlag> Hi all
Apr 13 21:56:26 <hirnschlag> I'm curious, is this a place where one can ask some stupid questions about yocto?
Apr 13 21:57:16 <nameclash> hirnschlag, you're spot on dude
Apr 13 21:57:59 <hirnschlag> Okay, I have to say I never feel so lost like on days I'm touching my yocto build
Apr 13 21:58:44 <hirnschlag> So please bear with me. I have functioning ZYNQ arm7 build, in zeus, using meta-xilinx, and my own layer that adds a bunch of kernel patches
Apr 13 21:59:24 <hirnschlag> I sort of soldiered through that and got this to work. Now I like to add some packages, say openvpn
Apr 13 21:59:49 <hirnschlag> I copied some .bb files for it from various sources, but nope. Would have been too easy
Apr 13 22:00:03 <hirnschlag> Is there a tutorial or something on how to go about this?
Apr 13 22:01:53 <nameclash> hirnschlag, when I'm adding packages I first check if the standard poky layers contain a recipe for the package I'm looking for
Apr 13 22:02:30 <hirnschlag> I think
Apr 13 22:02:36 <hirnschlag> I did that
Apr 13 22:02:41 <nameclash> you can either do this with a simple find statement, e.g. find -name "*openvpn*bb"
Apr 13 22:03:29 <nameclash> or you just add the package to IMAGE_INSTALL in core-image-minimal.bbappend and run bitbake core-image-minimal
Apr 13 22:03:50 <nameclash> it will complain if it finds no recipes that provide openvpn
Apr 13 22:03:54 <hirnschlag> Yes
Apr 13 22:03:56 <hirnschlag> It did
Apr 13 22:04:01 <zeddii> http://layers.openembedded.org/layerindex/branch/master/recipes/
Apr 13 22:04:14 <zeddii> http://layers.openembedded.org/layerindex/recipe/4475/
Apr 13 22:04:33 <hirnschlag> Okay
Apr 13 22:04:34 <nameclash> in that case, just find the layer in the internet, here zeddii did it for you
Apr 13 22:04:39 <hirnschlag> I downloaded that recipe
Apr 13 22:04:50 <nameclash> you should add that layer to your workspace
Apr 13 22:04:51 <hirnschlag> the very same zeddii found
Apr 13 22:04:56 <nameclash> not just the recipe
Apr 13 22:05:03 <hirnschlag> Okay
Apr 13 22:05:15 <zeddii> yup. you need to clone the layer, add it to your bblayers.conf and then add the packge to your image install.
Apr 13 22:05:27 <zeddii> IIRC the yocto-mega-manual should have some samples of how to do that.
Apr 13 22:06:06 <hirnschlag> This will require me to get the whole meta-openembedded shebang
Apr 13 22:06:13 <nameclash> a good approach imo is to add the layer repo as submodule to your project
Apr 13 22:06:27 <hirnschlag> will that have other consequences besides me getting the openvpn package in my image?
Apr 13 22:06:51 <zeddii> nope
Apr 13 22:07:08 <zeddii> they will be parsed, but not built, unless you have them in your install, or a dependency of something being installed.
Apr 13 22:07:26 <hirnschlag> okay, ill try that
Apr 13 22:07:26 <zeddii> yocto compatible layers will not influence your build, simply by being in bblayers
Apr 13 22:07:27 <nameclash> yeah, you will also pull every other package into your project, i.e. not that they get into your image but you will be able then to add more packages from that layer
Apr 13 22:16:59 <hirnschlag> Cool!!!
Apr 13 22:17:05 <hirnschlag> This seems to be working
Apr 13 22:17:23 <hirnschlag> Sorry, I was just too nervous adding meta-openembedded before because its so huge
Apr 13 22:20:42 <nameclash> actually, you'll find many of the stuff you're gonna need in future in that layer
Apr 13 22:26:38 <hirnschlag> Thank you all
Apr 13 23:49:18 <nameclash> I have an SDK build that is baked via bitbake -c populate_sdk core-image-minimal
Apr 13 23:51:38 <nameclash> now I want to add meta-toolchain-qt5 to the SDK and, since this is a meta-package, I figured to just run bitbake -c populate_sdk core-image-minimal meta-toolchain-qt5
Apr 13 23:53:13 <nameclash> this does however fail in the end because both core-image-minimal and meta-toolchain-qt5 try create "the same" installable artifacts, which obviously fails
Apr 13 23:55:20 <nameclash> meta-toolchain-qt5 does not do anything special than inheriting populate_sdk_qt5, which generates a qt.conf and adds some packagegroups to the appropriate TOOLCHAIN_* variables
Apr 13 23:56:34 <nameclash> how do I get both core-image-minimal and meta-toolchain-qt5 together in one sdk?
Apr 13 23:57:08 <nameclash> should I just inherit populate_sdk_qt5 from core-image-minimal.bbappend or is that a bad idea?
Apr 14 00:01:21 <kergoth> yes, most likely just need to inherit it yourself
Apr 14 00:02:26 <nameclash> ok thanks, will give it a try now
Apr 14 00:33:28 <nameclash> that worked fine, kergoth
**** ENDING LOGGING AT Tue Apr 14 02:59:57 2020