**** BEGIN LOGGING AT Wed Sep 26 03:00:01 2018 Sep 26 07:59:14 Hello All... Sep 26 08:00:12 Is it possible with OE, to create a toolchain, into which I can boot and compile those packages which are either not in OE or which are propriertory ? Sep 26 08:06:57 SHW_: well you create a toolchain implicitly anyways, and it can be packed into an sdk. yet, theres no reason why to not build your proprietary packages with the OE mechanisms anyways, we do it all the time. just because you use the OE build infrastructure, this has no effect on the license of the package itself Sep 26 08:13:06 LetoThe2nd: Ok. But is it possible the thing I am looking at ? Sep 26 08:14:06 SHW_: you can build a toolchain. if that suits your needs, then: yes Sep 26 08:14:49 LetoThe2nd: Thanks. Sooner, I will call myself proud OE User then. Sep 26 09:01:11 How can I create multilib system which can run X86_64 and i386 ELF binaries ? Sep 26 09:53:58 SHW_: https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#combining-multiple-versions-library-files-into-one-image Sep 26 10:02:24 Thanks rburton Sep 26 12:37:08 I am trying to use DB recipe: https://layers.openembedded.org/layerindex/recipe/544/ with my image but apart from `libdb.so` files, binaries and headers are missing from my image. Sep 26 12:40:33 I looked in the package folder, it has all usr/include, usr/lib/ usr/bin/ etc.... Sep 26 12:52:55 baali: what files and executables are you specifically missing? and usually one does not install/ship header on an images - no need for as there's no toolchain to use them either. Sep 26 12:55:34 even binaries are missing from image, executable such as, db_dump db_hotbackup db_load db_log_verify db_printlog, header files like, db.h. Actually I was building python bindings for same and that needs these header files ....... Sep 26 12:56:36 baali: see: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/db/db_5.3.28.bb#n41 Sep 26 12:58:40 aahh.... understood..... Sep 26 13:00:13 and I am doing the real database management on system .... or atleast trying to use it ... :( Sep 26 13:03:51 baali: http://cgit.openembedded.org/openembedded-core/tree/meta/classes/lib_package.bbclass suggests that therefore you want to install db-bin Sep 26 13:08:05 Thanks LetoThe2nd for the help.. I had tried that earlier but got stuck at, ERROR: Nothing PROVIDES 'db-bin'. Close matches: Sep 26 13:08:06 db RPROVIDES db-bin Sep 26 13:08:19 I think its different from just doing, `bitbake db-bin` Sep 26 13:09:07 it is, yes. bitbake db builds both packages, and in IMAGE_INSTALL they are seperate. recipe vs. package, that is. Sep 26 13:12:25 Understood.... adding it IMAGE_INSTALL... again, thanks LetoThe2nd _/\_ Sep 26 13:38:17 hello. i have set a bunch of DISTRO_FEATURES_remove = " 3g zeroconf ..." in my local.conf, but according to bitbake -e , all (or many) of those DISTRO_FEATURES are still enabled. what could be the problem? Sep 26 13:39:47 mmm, maybe that's just all available features. but where is the list of enabled features? Sep 26 13:40:09 "pulseaudio" is also in DISTRO_FEATURES according to bitbake -e, but pulseaudio isn't in the image. Sep 26 13:44:12 distro features != what is in the image you built Sep 26 13:45:08 the block above the DISTRO_FEATURES assignment in the -e output will show you how it was evaluated and why your remove isn't working Sep 26 13:45:20 nice, thanks! checking... Sep 26 13:45:33 i'm assuming you're not using a really old version of oe Sep 26 13:49:16 nah, it's... yocto 2.4/rocko Sep 26 13:49:54 what the hell, the evaluation order of local.conf is somewhere in the middle, i expected it to be last to have highest priority. Sep 26 13:50:14 nope Sep 26 13:50:35 but DISTRO_FEATURES_remove in local.conf works fine as i do it here Sep 26 13:50:42 _remove happens last Sep 26 13:54:47 am i screwing up the DISTRO_FEATURES_remove then then? relevant -e output: http://ix.io/1nBn Sep 26 13:54:58 remove line: DISTRO_FEATURES_remove += " 3g bluetooth bluez5 nfs pci pcmcia pulseaudio smbfs zeroconf " Sep 26 13:55:17 it appears as a "set" but it should be a "remove", right? Sep 26 13:56:07 well, _remove similar to the _append Sep 26 14:00:19 apparently, apparently the syntax is magic and alway VAR_remove, not VAR_remove += Sep 26 14:01:07 *VAR_REMOVE = Sep 26 14:01:11 no error message or warning either, just silent wrong result >:| Sep 26 14:16:27 nah, that's not it... the second _remove in local.conf actually seems to be ignored entirely. only one _remove per file? Sep 26 14:16:33 and variable Sep 26 14:20:25 or is it that only _remove before DISTRO= is considered... checking Sep 26 14:25:34 nvm, forgot to update the environment dump. it's just that VAR_remove += does not work as expected. Sep 26 14:30:49 ok, i have no idea anymore. i can't reproduce the original problem. and i really don't see what is different this time. Sep 26 15:31:08 maelcum: += works fine, it's just ambigious so frowned upon Sep 26 15:31:13 you can pile up _remove no problem Sep 26 15:31:30 my local.conf has about six DISTRO_FEATURES_append and DISTRO_FEATURES_remove lines in Sep 26 15:32:41 maelcum: oh, the backfill will be hitting you for some of thse Sep 26 15:32:44 only some though Sep 26 15:32:52 look up DISTRO_FEATURES_BACKFILL_CONSIDERED Sep 26 15:33:06 that's what # append utils.py:127 [features_backfill] is Sep 26 16:06:11 rburton: thanks, but it's working now and i have *no idea* why. i was looking at the backfills but they made no difference in this case. Sep 26 16:07:12 (i had to solve something else though, packagegroup-basic always RDEPENDS on avahi-daemon and avahi-utils) Sep 26 16:07:20 solved with a .bbappend file Sep 26 16:08:12 the problem with DISTRO_FEATURES was not that i forgot to update something - the DISTRO_FEATURES_remove line has been in local.conf for a long time. Sep 26 16:08:30 i don't know what else could have changed the result. Sep 26 16:10:50 removing zeroconf from DISTRO_FEATURES is the fix for that Sep 26 16:11:53 regarding packagegroup-basic? no, it's unconditional, at least in my version. Sep 26 16:12:10 ${@bb.utils.contains('DISTRO_FEATURES', 'zeroconf', 'packagegroup-base-zeroconf', '',d)} \ Sep 26 16:12:41 oh, *basic* Sep 26 16:12:50 yeah http://ix.io/1nCz Sep 26 16:12:58 so when it says simplier, it means more broken Sep 26 16:12:59 i guess that's a bug Sep 26 16:13:03 yeah its a bug Sep 26 16:13:10 the one in core doesn't have that bug Sep 26 16:13:31 i'm using some modified toradex setup, they like to use -basic Sep 26 16:13:39 sure there's a good reason why it recommends htop too Sep 26 16:13:49 surely Sep 26 16:15:44 i guess it is possible that the DISTRO_FEATURES_remove line always worked but zeroconf and avahi survived due to the broken packagegroup-basic, and when i generated the environment dump it was temporarily screwed for reasons. Sep 26 18:55:01 I run bitbake -c populate_sdk if I want to build an sdk. but does this also generate the full image, including tarball, .wic.gz files, .dtb's , kernel Image files etc in deploy/ ? Sep 26 20:27:07 hi, without this patch https://patchwork.openembedded.org/patch/155125/, long running bash processes create zombies and spinning processes Sep 26 20:27:49 for some reason it is not included yet, what can I do about that? Sep 26 20:29:11 this one https://patchwork.openembedded.org/patch/155125/ Sep 26 21:03:18 it's only been 2 days.. Sep 26 22:49:01 It would help to say why its needed at freeze time... Sep 26 22:49:13 but they've left :/ Sep 26 22:50:07 I guess follow up by email, but yes it isn't great when people don't wait for a response Sep 26 23:06:12 bluelightning: I have just done so Sep 26 23:06:30 perhaps slight gumpily as empty commit messages really don't help Sep 26 23:39:33 Note: the layerindex is offline due to filesystem corruption. I've provisioned a new server and am in the process of restoring from backups. Sep 26 23:41:51 thanks Sep 26 23:52:44 (we're in the progress of upgrading the code - I say we, Michael is doing all of the work and I'm standing by to assist) Sep 27 00:39:52 Infra update: layerindex is online on a new server. Upgrade is still in progress. Sep 27 00:52:45 thanks halstead Sep 27 00:53:20 khem, You're welcome. Apologies about the unexpected downtime. I really couldn't have predicted this one though. Sep 27 00:53:40 yeah sometimes machines have mind of their own **** ENDING LOGGING AT Thu Sep 27 02:59:59 2018