**** BEGIN LOGGING AT Thu Oct 25 03:00:00 2018 **** BEGIN LOGGING AT Thu Oct 25 07:28:08 2018 Oct 25 11:21:00 hi Oct 25 11:24:23 what was the reason for making /run non volatile? I am trying to work around that and make it volatile again, but it turned out not to be so easy Oct 25 13:56:27 Hi! I'm interested in using OE-Core as the base to build u-boot + Linux + a single binary go userland. I'm trying to read the guides and figure out how to do something like that, but OE seems to be quite opinionated in how the distro should look like - is this a supported / wanted use case of OE? Oct 25 13:57:13 i.e. I need OE to build my cross tools like GCC, musl, and Go compiler. But the way I build my userland is already solved using a Golang builder, and the way I assemble the image is extremely simple Oct 25 13:58:49 blueCmd: sounds like basically no problem at all. Oct 25 13:59:14 not sure what you mean by that. create a recipe for the single binary userland, make it depend on u-boot and the kernel, and either make it depend on the tools needed to build it, or use external ones. call it a day Oct 25 14:00:03 to me it sounds like in the extreme case its a single recipe/package to be installed to the rootfs. Oct 25 14:00:20 we're doing really similar stuff for containers Oct 25 14:00:22 LetoThe2nd: kergoth: something like that yes Oct 25 14:01:20 the reason oe has the learning curve it does is because flexibility is king. it's the opposite of opinionated Oct 25 14:01:23 so yes, it's doable Oct 25 14:01:39 great! Oct 25 14:01:56 kergoth, ++ Oct 25 14:01:56 kergoth: metal is king. but flexibility is also ok to heve. Oct 25 14:02:04 :) Oct 25 14:02:26 I was also wondering about the dependencies when building the SDK. it seems to depend on dbus, qemu, python3, perl etc. are all those needed? or can they be disabled without much hassle? Oct 25 14:02:45 I started removing some dependency lines in some bb files just to try it out and it seemed to work, but that was pretty messy Oct 25 14:03:50 if you're using the task, the sdk is based on the image, so create an image without all that and the sdk will reflect that. or just create a new sdk recpe and directly set TOOLCHAIN_HOST_TASK and TOOLCHAIN_TARGET_TASK Oct 25 14:04:08 but sdks are completely different than building recipes, taking on both at once is not going to be a good plan Oct 25 14:04:38 I'm fine interating, I just want to make sure it's reasonable Oct 25 14:04:39 sdks are what you build to let your app devs do their stuff without having to learn bitbake, for example. of no use whatsoever in getting bitbake to do what you want image wise Oct 25 14:04:40 When doing CI I'd like to if possible have at least something that does a fully clean build - and I'd like to avoid spending a lot of time building things that are not really used Oct 25 14:05:34 we don't depend on things randomly and without reason. recipes have dependencies, bitbake satisfies those dependencies. you just need an image that includes only what you want Oct 25 14:05:52 Ok, makes sense Oct 25 14:06:20 I didn't mean to imply they are meaningless - I'm sure they make sense in the general application Oct 25 14:07:13 so essentially I'd do my own version of "nativesdk" ? Oct 25 14:07:50 nativesdk packages are built for SDKMACHINE to add host binaries to an sdk Oct 25 14:08:16 creating your own version of that wouldn't make a great deal of sense, it's a type of recipe, variants to target a specific host Oct 25 14:08:22 hm ok Oct 25 14:08:51 * Crofton|work is building a bunch of nativesdk packages right now Oct 25 14:09:02 (in a nutshell, you're rebuilding u-root, right?) Oct 25 14:09:08 i think you'd do better to take a step back from sdk construction and just work on creating an image that includes just your single binary userland and a recipe for that userland, and if necessary any other recipes those depend on Oct 25 14:09:16 Maybe I should give an example instead. I don't see why I'd need qemu, and that brings up compile time quite a lot, so I removed it. But that seems to be pulled in by "SDK_DEPENDS" in "populate_sdk_base.bbclass" - so I'm not sure what the deal is there Oct 25 14:09:27 if it's like "OE depends on it, leave it alone" or "just override it if you don't want it" Oct 25 14:09:41 qemu is used in many, many places for many many things. and again, sdks aren't relevent unless you're building an sdk Oct 25 14:10:26 hm Oct 25 14:10:38 SDK as in a shippable artifact? Oct 25 14:10:50 \sdk as in 'bitbake meta-toolchain' or 'bitbake -c populate_sdk some-image' Oct 25 14:11:23 sdk as in 'this installer or tarball includes a target sysroot and host sysroot and setup scripts, and probably a toolchain, largely to facilitate development outside of bitbake, i.e. for your app developers' Oct 25 14:11:33 ooooh that might be what confused me. I thought that meta-toolchain was a "mid step" of the core-image-minimal Oct 25 14:11:36 i.e. likely not what you care about at all Oct 25 14:11:51 nope, completely different thing, not built as a part of a regular build of an image ata ll Oct 25 14:15:28 right, looking at taskexp now and indeed that's a relief Oct 25 14:16:01 this looks way more reasonable :) Oct 25 15:00:21 kergoth: I got it working, thanks! Oct 25 15:01:05 I had to manually patch rpm to not depend on python3 and dbus but after doing that I'm happy with the dependency graph. I'm also OK carrying a custom rpm bb so that's OK Oct 25 20:51:53 khem here? Oct 25 20:53:35 JPEW: yes Oct 25 20:55:22 khem: I sent a patch to upgrade rapidjson to a newer version (and incorrectly also asked for it to be backported to sumo). For sumo, I was going to backport just a patch to fix a bug on ARM, do you want that (just the patch) or to keep the recipe upgrade on master? Oct 25 20:56:12 khem: Forgot to mention, thats for meta-oe Oct 25 20:57:35 there were questions that Martin asked I was waiting for clarity on those Oct 25 20:59:15 khem: Ok. There were 2 independent patches, one for adding ALLOW_EMPTY_${PN} and one to upgrade the recipe. Oct 25 20:59:37 Yes Oct 25 21:01:38 I was wondering if ALLOW_EMPTY is was dependent on the upgrade patch Oct 25 21:01:55 It is not Oct 25 21:03:16 I tried to send them as two independent patches instead of a patch series.... I wasn't really sure how to make it clear that they weren't really releated :) Oct 25 21:07:29 you could have sent a followup reply to make it clear Oct 25 21:11:41 I picked the update part, thanks for reminder Oct 25 21:12:12 khem: Awesome! Thanks for the help. Oct 25 21:46:19 uhm, that's a weird one: ERROR: No active tasks and not in --continue mode?! Please report this bug. Oct 25 22:21:02 ah, apart this (seems ok for bfd reading around) the isue is the bitsize ELF 64-bit Oct 25 22:21:02 LSB relocatable, Oct 25 22:25:07 where does it get the wrong idea we have 64b...looking **** ENDING LOGGING AT Fri Oct 26 02:59:59 2018