**** BEGIN LOGGING AT Wed Sep 27 03:00:01 2017 Sep 27 06:11:31 bmouring, correct! Sep 27 13:56:20 Dvorkin: the major problem that you're facing is that you are attempting to push information backwards in the dependency chain (the leaf node here is the image recipe, but you need it to influence a recipe earlier in the flow). This is the sort of thing that is usually handled by build-level conf files (which have the chance to influence everything on the build), so without work to add in the plumbing that your use-case needs, I'm unaware of Sep 27 13:56:20 a way to get the results that you're looking for outside of a configuration change (e.g. in one of the .conf files or adding a variable to the EXTRAWHITE variable and setting it at build-time). Sep 27 14:01:37 bmouring, I see. The unconvinience is that I have several configurations and I have to create several machine configs for them in this case Sep 27 14:36:30 Dvorkin: what, exactly, is the nature of the difference in the images that would lead to the earlier package using one config file over another? Sep 27 14:39:38 bmouring, I had the same question Sep 27 14:52:46 Crofton|work: FOSDEM stand is on my to-do list. Do you know who did this last year so I can pick their brain a bit? Sep 27 14:53:02 And has anyone else already done the FOSDEM stand application for this year? Sep 27 14:53:06 belen did the application Sep 27 14:53:14 er in priotr years Sep 27 14:53:15 paulbarker: belen did Sep 27 14:53:20 no one has done the appliation Sep 27 14:53:26 Crofton|work: meh y u fastr? Sep 27 14:53:29 also Paul E has applied Sep 27 14:53:54 so we need to do this years, hopefully one of them has what we used before Sep 27 14:54:06 Hard part is staffing Sep 27 14:54:11 and display stuff Sep 27 14:54:20 Ok I'll email them both now and see what I get Sep 27 14:54:25 bmouring, it differs in linux kernel DTS (pinmux config) and some software packages. one of the packages have a config file that says: use this GPIO for button. that config differs for different configurations. that's Sep 27 14:54:31 we barely got sdr devroom app in :) Sep 27 14:54:55 Dvorkin, can't you handle that with different MACHINE's? Sep 27 14:54:56 I don't mind staffing the stand, I'll put out a shout on the mailing list for extra help once the stand is confirmed Sep 27 14:55:05 yeah Sep 27 14:55:11 I want to talk about it at OEDEM also Sep 27 14:55:26 trying to motivate some of the companies that attend fosdem and use OE to help Sep 27 14:56:13 Crofton|work, it is too expensive to create different machines for only one config file, used in the image Sep 27 14:57:10 well, that is what I would suggest, otherwise you are likely to end up carrying some ugly hacks Sep 27 14:57:50 Dvorkin: I'm with Crofton on this one, even if you could get something working with the "same" MACHINE, it opens some possibly confusing and problematic breaks Sep 27 15:01:25 we internally tried to get away with the idea that a MACHINE defined just a SoC and ran into some nasty issues (stemming from another unusual, not-often-used feature: BUILD_IMAGES_FROM_FEEDS, but the basic issues it opens can lead to other problems elsewhere) Sep 27 15:06:40 bmouring, I understand. What will be if I'll create two machines? how can I maximally optimize the build process? Sep 27 15:11:23 Dvorkin: for example, in the different MACHINE .conf files, one calls for one (or more) KERNEL_DEVICETREEs, in your image definition you can append different software packages depending on what MACHINE you're building for (e.g. using something like IMAGE_INSTALL_append_$MACHINE), and in the package that you want to handle different configs, split the SRC_URI based on the $MACHINE in a similar manner to how the packages defined for the image Sep 27 15:11:24 were split Sep 27 15:13:34 then, depending on the system that you're using to build the actual images itself, you simple set a different MACHINE (which, by default, is in the BB_ENV_EXTRAWHITE variable, allowing you to set the variable in the environment that calls "bitbake"), build the image, and by virtue of setting the MACHINE differently, it will include different packages in the image and configure the one package differently Sep 27 15:20:41 further, because you've defined a different MACHINE, it's nice and separated as far as SSTATE and packaging is concerned. Further, since you're making your package MACHINE-sensitive, you should do so formally and set the recipe's PACKAGE_ARCH to MACHINE_ARCH Sep 27 15:56:48 Dvorkin, only machine specific packages get built for each machines, most will be sured as they are not machine specific Sep 27 15:57:04 changing machine doesn't rebuild world, unless needed Sep 27 15:57:32 [balister@thuvia build]$ ls tmp-glibc/work Sep 27 15:57:32 all-oe-linux raspberrypi3-oe-linux-gnueabi Sep 27 15:57:32 cortexa7hf-neon-vfpv4-oe-linux-gnueabi x86_64-linux Sep 27 15:57:59 the cortex... ones are generic packages to that arch, the rpi ones are machine specific Sep 27 15:58:18 I see about 27 in the rpi dir Sep 27 15:58:37 and way more in cortex one Sep 27 18:03:07 so what is the difference between openembedded and yocto exactly? is yocto openembedded for dummies? should I use yocto or openembedded directly? Sep 27 18:03:53 lol Sep 27 18:04:03 OPenEmbedded is the Yocto project build system Sep 27 18:04:18 ANything else just confuses the issue Sep 27 18:04:31 and yes, there is lots of confusing information Sep 27 21:55:03 hey khem? I need to narrow this way down and replicate on just say oe-core, but have you heard of GDB getting 'call' stuff very wrong in OE? Sep 27 21:55:46 I have a trivial test app that calls ceil(double), and as part of debugging that, throwing it at on-device gdb, break main, printf "%f\n", ceil(32.0) does not give a sane at all looking result Sep 28 01:01:43 Yeah, oe-core morty Sep 28 01:01:47 https://www.irccloud.com/pastebin/B4A0eoyO/ Sep 28 01:22:07 * Tartarus shuffles over to master **** ENDING LOGGING AT Thu Sep 28 03:00:01 2017