**** BEGIN LOGGING AT Mon May 21 03:00:04 2018 May 21 05:07:44 Hi May 21 05:08:25 Have anyone used meta-toolchain SDK as a prebuilt binary for gcc-cross toolchain? May 21 05:24:45 closes you have is linaro external toolchain IIRC May 21 05:25:15 Sorry I didnt understand May 21 05:28:07 i thought you wanted to generate SDK out of cross-gcc generated toolchain but it seems you simply want a SDK May 21 05:28:26 in that case. I think bitbake meta-toolchain will do it for you May 21 05:28:51 Yeah. I want to use this meta-toolchain sdk as a prebuilt binary. May 21 05:29:55 But then from sdk toolchain + other libraries will be also present. Then will I have to give task[no_exec] = "1" for all the packages that comes from SDK? May 21 05:30:26 you might want to try released ones from here http://downloads.yoctoproject.org/releases/yocto/yocto-2.5/toolchain/x86_64/ May 21 05:31:24 oh so you do want to insert it as external toolchain ? May 21 05:31:52 usually thats not a common usecase May 21 05:32:17 probably you should look into extensible SDK May 21 05:32:30 thats a better approach for using prebuilt artifacts May 21 05:32:51 The actual purpose is, I can use the binaries that ships with the SDK to skip do_compile() for toolchains and directly proceed with do_install() from the binaries that comes with SDK May 21 05:35:17 I understand what you want to do, but thats not a normal way May 21 05:35:48 those SDKs are meant for application development and not for doing full platform May 21 05:36:32 usually someone writes recipes for the applications and then let yocto build system generate the full platform image May 21 05:37:08 but now there is extensible SDK which ships prebuilt platform along so one can use pretty much everything prebuilt May 21 05:37:26 and then just build the apps and be able to generate images quickly May 21 05:37:59 Pointing to install the sdk in the sysroot using do_install() and the trying to run a full build. WIll it work? May 21 05:38:00 see this https://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html May 21 09:57:18 Hello, yocto-folks! May 21 09:59:09 I am struggling with a problem connected with TUNE_FEATURES settings so one would reflect the hardware features and compiler functionality. May 21 09:59:36 The thing is my MIPS SoC support MSA instructions, which support has been added to gcc 7.3 only May 21 09:59:49 * s/7.3/7.1 May 21 10:00:50 So when I add -mmsa to TUNE_FEATURES , the yocto build process works pretty much well only for gcc 7.3. May 21 10:01:34 The older compilers are whining about the incompatible option. May 21 10:02:05 Of course I tried to make msa feature optional. May 21 10:02:56 TUNE_FEATURES_tune-p5600le += "${@'msa' if int('${GCC_VERSION}'.split('.')[0]) >= 7 else ''}" May 21 10:07:43 Since I'm using meta-external-toolchain to build yocto, GCC_VERSION is determined based on the external binaries by calling "mips-unknown-version-gcc -v". The corresponding function (like this: external_run('gcc', '-dumpversion')) is declared in a class globallt inherited way after TUNE_FEATURES actually referenced, so I keep getting an error: May 21 10:07:43 "Failure expanding variable GCC_VERSION, expression was ${@external_run(d, 'gcc', '-dumpversion').rstrip()} which triggered exception NameError: name 'external_run' is not defined" May 21 10:09:22 kergoth: the question is mostly for you, man, since you are familiar with external-toolchain layer. What is the best way to exclude msa feature unsupported by compiler from TUNE_FEATURES? May 21 10:14:25 So to speak I got a triple dependency here: May 21 10:14:25 TUNE_FEATURE -> GCC_VERSION -> external_run(). The function is declared in a class of meta-external-toolchain and globally inherited in tcmode-external.inc. But TUNE_FEATURE is declared and referenced somewhere before the tcmode-external.inc included to bitbake.conf. May 21 10:14:51 It causes the error above.( May 21 10:48:42 Hi folks! May 21 10:49:37 What should I do if it isn't any LICENSE in recipe sources? May 21 10:49:40 I got ERROR: libzip-0.9-r1 do_populate_lic: QA Issue: libzip: Recipe file fetches files and does not have license file information (LIC_FILES_CHKSUM) [license-checksum] May 21 10:50:11 there is no any LICENSE files to be added to LIC_FILES_CHKSUM May 21 10:50:57 acrap: you can point it at the header in a source file May 21 10:52:14 rburton: it seems like temporary stab. Is there a prettier solution? May 21 10:52:41 tell upstream to clearly document the license terms? May 21 10:52:59 if the only place the license is documented is in a comment in a C file, thats what you add to LIC_FILES_CHKSUM May 21 10:53:17 (you can tell it a line range) May 21 10:53:30 I see May 21 10:53:35 Thanks! May 21 10:53:40 of course a comment with /* GPL */ isn't really legally binding so upstream *should* fix it May 21 12:56:51 hello guys.. I have added TOOLCHAIN_HOST_TASK_append += "nativesdk-cmake-dev" to my local.conf. Hence I have run: bitbake core-image-minimal -c populate_sdk. I have foudn the sdk in tmp/work/raspberrypi/core-image-minimal/1.0-r0/sdk/image/opt/poky/2.4.2/. I have this recipe being built https://pastebin.com/rKUA54Kc which provides libjsmn.a and jsmn.h. I can't figured why jsmn.h is not added to the sdk sysroot. I can see it in May 21 12:56:52 cortexa7hf-neon-vfpv4-poky-linux-gnueabi/jsmn/1.0.0-r0/image/usr/include/jsmn.h. Does anyone has any hint ? May 21 13:04:56 oe meeting is starting in #oe-meeting, https://www.openembedded.org/wiki/2018_05_General_Meeting May 21 13:12:40 should the license-ignoring magic we do for CLOSED be also done for Properiatery? May 21 13:12:44 oh oe meeting! May 21 14:15:23 rburton: probably although two things which do the same thing can be frustrating May 21 15:25:14 New news from stackoverflow: Stripping base path off the unpacked source tree with bitbake SRC_URI file:// fetcher May 21 16:36:49 I have a small out-of-tree kernel module. I tried to follow the instructions in https://www.yoctoproject.org/docs/2.4.1/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules However, neither KERNEL_SRC nor KERNEL_PATH seem to be defined when my recipe gets executed. What could be wrong here? May 21 16:40:37 my user space has always been built under tmp/work/corei7-64-poky-linux , but my kernel under tmp/work/corei7-64-intel-common-poky-linux/ I don't know where this difference comes from, it has not cause any trouble so far. But now this out-of-tree kernel recipe gets also built in the "user space location" and I am not sure whether that could be part of the problem May 21 16:51:35 So I have a custom board with a custom layer. I have my machine config in MY-LAYER/conf/machine/MYMACHINE.conf and I have some images in MY-LAYER/recipes-core/images/. My issue is I have some DISTRO_FEATURES changes I need to make [namely removing X11, wayland and alsa]. Where is the 'proper' place to put DISTRO modifications? May 21 16:53:08 Any questions or comments appreciated. May 21 16:54:39 Up to this point, this DISTRO_FEATURES_remove line has lived in THISBUILD/conf/local.conf but I'm trying to get my baseline system config completely into my custom layer May 21 17:00:13 I'm quite new to Yocto internals, but while I wait for an answer to my quation let me try: I think the manual gives a clear answer: You define your distribution features in the distribution configuration file. May 21 17:00:32 https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#var-DISTRO_FEATURES May 21 17:01:47 u1106: Ah, thanks, I was looking in there but not finding file names. I think that's what I needed. Thanks. May 21 17:05:44 the filename should be conf/layer/distro/.conf I guess May 21 17:07:39 Sounds reasonable. May 21 17:20:23 it's .conf, as implied by both the path and the documentation May 21 17:20:25 not layer May 21 17:21:10 kergoth: Thanks. May 21 17:25:36 New news from stackoverflow: add touchscreen support imx6 May 21 17:25:43 of course May 21 17:29:06 while we are at it, yocto-check-layer checks that in a distro layer the .conf does not set the DISTRO variable. But poky does just that. Any explanation for that. (Hope I remeber the details right now, it's been a while when I wondered how that is really supposed to work) May 21 17:29:53 no, that's not what it checks. and that question doesn't make any sense May 21 17:30:22 bitbake.conf includes conf/distro/${DISTRO}.conf. DISTRO by definition has to be set before the distro config file is loaded, hence must be set in the environment or local.conf May 21 17:30:43 very rarely it gets altered by the included distro after the fact, but there are very very few reasons to do it, it's pointless May 21 17:31:59 * kergoth ponders May 21 17:33:29 kergoth: thanks for the answer, I will check again what error message exactly I got on my own layer (or some old version of it...) and ask again tomorrow if that's OK. May 21 17:34:10 np May 21 17:38:11 at least poky does set its own DISTRO, which is ineed a bit weird because of conf/distro/${DISTRO}.conf being included May 21 17:38:11 $ grep "DISTRO " poky/meta-poky/conf/distro/poky.conf May 21 17:38:11 DISTRO = "poky" May 21 17:53:44 Now I remember better, the point is if a distro changes the distro name yocto-check-layer will complain May 21 17:53:49 git grep -A5 "def test_distro_no_set_distros(self)" May 21 17:53:49 scripts/lib/checklayer/cases/distro.py: def test_distro_no_set_distros(self): May 21 17:53:49 scripts/lib/checklayer/cases/distro.py- from oeqa.utils.commands import get_bb_var May 21 17:53:49 scripts/lib/checklayer/cases/distro.py- May 21 17:53:49 scripts/lib/checklayer/cases/distro.py- distro = get_bb_var('DISTRO') May 21 17:53:50 scripts/lib/checklayer/cases/distro.py- self.assertEqual(self.td['bbvars']['DISTRO'], distro, May 21 17:53:52 scripts/lib/checklayer/cases/distro.py- msg="Layer %s modified distro %s -> %s" % \ May 21 17:56:22 and the "use case" was that my DISTRO foo required poky.conf to use mostly the same settings and override just a few later. But because poky.conf sets DISTRO = "poky" after requiring our foo.conf just set it back to DISTRO = "foo" May 21 17:56:34 and yocto-check-layer complained May 21 18:01:01 so to avoid the failing test one cannot "require" yocto.conf, but needs to copy most of the contents. I haven't understood the logic behind that, copying code is not good software engineering May 21 18:13:52 poky is meant as an example, demo, and testing distro, it's not recommended to include and modify, copying is recommeneded in this case May 21 18:26:51 I'll take that as it is, maybe some day I will understand the logic behind it :) May 21 21:10:23 grr, crops does not like me much May 21 21:10:53 trying to get my dotfiles and crap mapped in, and deal with ssh keys, but am using docker for windows from WSL so volume mapping is a pain in the ass May 21 21:12:39 suppose i could have it copy the bits for that over instead of mapping them in May 21 21:21:26 hmm May 21 22:32:16 kergoth: hey, man. I finally got a free time to the test external-toolchain from your repo - fancer-integrate branch. It seems working well with my crosstool-ng build. May 21 22:33:43 I got a small updates to merge into your repo. Just a few lines removed and few added. Shall we work by the same scheme as before? May 21 22:35:37 I'll submit that changes on top of fancer-integrate branch to my GitHub. Then u can pull it to your repo. May 21 22:42:40 fancer: sounds good, thanks May 21 23:34:53 if I'm stuck on yocto 2.0 (Jethro) how do I include files installed in /opt, in the sysroot? May 21 23:35:24 My testing shows that SYSROOT_DIRS += "/opt" doesn't work that far back May 21 23:47:19 is appending a function that stages the files to SYSROOT_PREPROCESS_FUNCS the right way to go about it? In jethro that is May 21 23:47:47 https://www.yoctoproject.org/docs/2.0/ref-manual/ref-manual.html#var-SYSROOT_PREPROCESS_FUNCS May 22 00:07:57 looks like i found an answer: https://stackoverflow.com/questions/35354802/how-to-create-do-populate-sysroot-append-task-in-yocto May 22 01:39:54 hey all, I'm looking for templating functionality. I would like to build images with different file content based on some env variable passed to bitbake. I wish there would be a built-in way of rendering some tokens like {{ MY_VAR }} while doing `install` step. I wish there would be a way to include jinja2 cli which take a template and renders it into a file. maybe I should install it on the host system..? May 22 01:41:36 create or find a jinja2-native recipe, then you can add it to DEPENDS and run it in do_Install May 22 01:42:20 I've considered that, I was thinking about creating a bbclass to at least partially automate it, with automatic template processing of files with a certain extension in SRC_URI May 22 01:44:49 yeah, creating a jinja2cli-native recipe would make sense. then i could include it instead of `install` command, i guess... May 22 01:45:22 is there anything special install does besides copying and permissions? May 22 01:45:40 could be that i would need to save the file to a temp location first and then install from there... May 22 01:47:12 Alright, i will try both ways, thanks for your advice May 22 02:02:42 np May 22 02:03:35 the real question is which variables get substituted in the template / supplied in the data to be used for template processing. doing all the vars in the metadata would be quite slow. likely good to create a variable that lists the metadata variables that get included/substituted **** ENDING LOGGING AT Tue May 22 03:00:04 2018