**** BEGIN LOGGING AT Fri Oct 18 02:59:58 2019 Oct 18 06:01:55 good morning! Oct 18 06:11:08 disagreed Oct 18 06:39:45 I have one embedded system with python 3.5 installed. I am looking to optimize the python footprint. Can anybody help me? I am planning to have only pyc files. Will it help? If yes, I am unable to find how to do it. Oct 18 06:40:53 there was soemthing lately on the topic but i can't remember you worked in it... Oct 18 06:41:02 s/you/who/ Oct 18 06:42:21 Is it right place to discuss such things. I am new to this group. Oct 18 06:42:51 the place is right, if you want to talk about how to automate the py->pyc compilation during build time :) Oct 18 06:42:56 I am trying to use yocto project to get linux for my board? Oct 18 06:43:08 and i really rememebr that there was some work on it. Oct 18 06:43:24 Yes. I want to talk about how to have only pyc files. Oct 18 06:43:53 Or anyother idea to reduce the footprint of the linux (only related to python) Oct 18 06:44:51 I googled and get to know i need to modify disutils-common-base.bbclass Oct 18 06:45:26 maybe Oct 18 06:45:48 wait a little until ross is around, i know he at least has knowledge about python. Oct 18 06:46:03 Sure Oct 18 07:28:06 New news from stackoverflow: After devtool build image, files can be found in rootfs, but not found when I run on QEMU Oct 18 07:40:31 When Ross will join us? Oct 18 07:40:55 abhiarora44: when he is ready Oct 18 07:41:18 abhiarora44: if you are impatient and feel like taking some action, you can also write to the yocto ML :) Oct 18 08:14:42 A small question. I tried mailing list and got a email from yocto-bounces Oct 18 08:14:56 Has my question posted? Oct 18 08:16:59 it has arrived, yes. Oct 18 08:17:02 abhiarora44: yes it's been posted Oct 18 08:18:54 abhiarora44: as you ask there that you want to reduce the footprint, what are we talking about anyways? how big is it now, how much do you want to cut down? Oct 18 08:25:15 Addition of python has increased the linux installation size by 80MB. I want to reduce it by half Oct 18 08:26:05 Pardon as I missed these details. How can I rectify it? Oct 18 08:26:11 abhiarora44: if you started out at 20m, that makes sense. if you started at 500m, its kinda pointless. Oct 18 08:26:34 and, have you checked if you are maybe just pulling in a lot of pyhton for no good reason? Oct 18 08:26:55 Yes. That has been checked. Only modules needed were pulled. Oct 18 08:27:08 and those do add it to 80m? Oct 18 08:27:18 or is it actually something else? Oct 18 08:27:35 because i don't think pyc will give you the cut down you mentionend Oct 18 08:27:59 Addition of python increased the size by 80MB including needed modules. Oct 18 08:28:58 i doubt that Oct 18 08:29:27 then you are either pulling in some giant modules, or actually some dependency Oct 18 08:29:49 have you looked at the sizes of the generated packages, etc.? Oct 18 08:32:06 Let me check again Oct 18 08:32:46 abhiarora44: which modules are we talking about, so that others can crosscheck it? Oct 18 08:34:06 abhiarora44: which version of Yocto do you have? Oct 18 08:34:36 qschulz: py 3.5, so probably thud Oct 18 08:34:37 http://cgit.openembedded.org/meta-openembedded/commit/meta-python/recipes-devtools/python?id=befa59e6de53ac72ebf5876156eb9192598967c8 Oct 18 08:36:19 we have this commit as a bbappend somewhere. Drastically reduces the size if python3-attrs is installed Oct 18 08:39:29 Hey guys, I can't use deploy-target with devtool using a recipe for a python module (inheriting setuptools3). I always get the error: ERROR: No files to deploy - have you built the python-random-module recipe? If so, the install step has not installed any files. This did work in the past, but I can't figure out why it isn't working now. If I build the image and flash the device with it all files are properly installed. Does anyone have any guidance? (I Oct 18 08:39:30 did inspect the environment and it seems that FILES="", maybe that is the issue?) Oct 18 08:39:57 I'm on warrior btw Oct 18 08:42:44 bisbarn: waht do you define as "past" then, and what di change since that? ;) Oct 18 08:43:51 yeah that's a good question :D Oct 18 08:44:35 bisbarn: if its FILES_${PN} thats empty, i would wonder, thats to be added. Oct 18 08:47:42 I'll check it. Did a pull to get the latest rev one the warrior branch of my layers. Currently rebuilding the image, this will take some time :D Oct 18 08:48:38 Am I the only one using meta-java/openjre-8 from master, and getting java crashing on startup ? Oct 18 08:48:48 kroon: "yes" Oct 18 08:48:52 Oct 18 08:49:02 :D Oct 18 09:13:14 Following images were installed: core, misc, async, six, websockets, requests, urllib3, chardet, websocket-client, pyopenssl, simplejson, cython Oct 18 09:17:43 Can someone help me with at what files to look for modules that are being installed so that i can control them? Oct 18 09:18:06 Pardon but I am new to yocto Oct 18 09:23:17 abhiarora44: you could try with NO_RECOMMENDATIONS and see if that's a route to evaluate (disable some packages that were pulled via *RRECOMMENDS) Oct 18 09:23:55 also, buildhistory might be of interest (INHERIT += "buildhistory" in your local.conf), show you the installed pckages and their sizes Oct 18 09:24:31 so if you save the ones after an image build without your new packages and the ones with, you can compare what grew in size or was added Oct 18 09:26:21 Hi! I'm trying to perform apt-get install on a yocto image. I enabled package-management and package_deb. On my yocto image I do have apt-get but I don't know which repository I can use in sources.list Oct 18 09:26:30 does anyone have an idea? Oct 18 09:26:45 alexb3600: non, unless you're starting the repository server yourself Oct 18 09:26:58 alexb3600: https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/package-manager-white-paper.pdf Oct 18 09:27:46 alexb3600: just because it uses apt as a tool, it doesn't magically make it compatible with debian and friends. so you have to run your own repository based on the build. Oct 18 09:28:04 LetoThe2nd: Ok thanks a lot! and do you know why I can't use the debian repository for instance? Oct 18 09:28:20 hum ok Oct 18 09:28:29 alexb3600: as a debian guy why you can't use centos as repository for instance Oct 18 09:28:34 *ask Oct 18 09:28:46 alexb3600: reason: "its jsut a completely different distibution" Oct 18 09:30:03 Where I can details about images? Like python3-core, python3-misc. They are listed in conf directory. Oct 18 09:30:18 abhiarora44: not images, packages. Oct 18 09:30:22 I want to know what they install. Oct 18 09:30:26 thanks for your explanation , do you mean a centos for the server ? Oct 18 09:30:33 Okay. Packages Oct 18 09:30:52 abhiarora44: and your deploy directory should hold a pretty detailed manifest about what was installed, even with sizes IIRC. you just have to dig a little Oct 18 09:31:47 alexb3600: centos was jsut an example. the meaning is: package repositories are not compatible across distributions, simple as that is. if you want to use debian packages, then you should run a debian system. Oct 18 09:34:22 LetoThe2nd: ok got it. But if I create my own repository as you said, what will be the difference between my repository packages and the debian repository packages? I'm a student sorry for these silly questions ^ Oct 18 09:36:10 alexb3600: they will bring a completely different ABI. other glibc version, other configuration of libraries, other directory structure.... there are similirities of course, but they're on the same level as if you were buying a bmw, then taking it to a mercedes shop and say: hey you got this engine that i like more than mine, please put it into my car. Oct 18 09:36:35 alexb3600: then they will say "yes, it is also an engine. but it does not *FIT*"" Oct 18 09:37:45 LetoThe2nd: Everything will fit using an angle grinder :D Oct 18 09:38:22 bisbarn: exactly. "it can be made to fit, but the effort is way bigger than just sticking to the correct brand" Oct 18 09:38:29 humm ok.. so I will follow your link , thanks Oct 18 09:38:47 bisbarn: ahah Oct 18 09:42:25 bisbarn: (i know that "joke", and it actually explains it even better than jsut the pure analogy) Oct 18 10:03:27 Hi all Oct 18 10:04:54 I'm currently working with several layers and I would like to remove unused ones to speedup parsing. Is there a way to list used layers or used recipes? Oct 18 10:06:35 ykrons: nice question Oct 18 10:07:04 a layer is by definition never unused as you can always build everything in it with "bitbake world" Oct 18 10:08:16 so the question rather is, "how can i find out if a certain layer has any effect on a given target" :) Oct 18 10:09:34 (which in turn is a nice and interesting quesiton, indeed!) Oct 18 10:10:45 ykrons: I've patched buildhistory to include layer name in recipe metadata Oct 18 10:11:14 (though it's slightly annoying that layer name is not exactly same as layer git tree name..) Oct 18 10:11:50 that info gives the recipes used from a layer, but not the bbappends or bbclasses Oct 18 10:14:39 LetoThe2nd, I just discover bitbake world command. What is it used for? Building all package for a package repository? Oct 18 10:16:01 folks Oct 18 10:17:28 mcfrisk, I'm not used to modify yocto "internals" so I initialy planned to work with dependency graph reported by bitbake Oct 18 10:18:25 ykrons: layer information is not in bitbake -g output, AFAIK Oct 18 10:19:40 mcfrisk, in the task-depend, I can extract layers but it will probably limited to tasks. So if a bbappend just set variable, I think I will miss it Oct 18 10:21:20 ykrons, bitbake-layers is probably the tool Oct 18 10:21:40 think about this: a layer that only modifies one variable. this variable has no visible effects, other than affecting the populate_sdk command of one given image target Oct 18 10:22:04 so, how do you decide now if that layer is unused or not? Oct 18 10:22:47 build with and without layer, review changes and test results :) Oct 18 10:23:49 buildhistory, bitbake -e output etc help seeing some of the effects Oct 18 10:31:10 mcfrisk: now what if the change is in a command of a depend'ing package? Oct 18 10:31:51 you would have to diff each and every recipe that is built somewhere in the process of building the main target Oct 18 10:32:33 and you can't look at the flattened layer state because it would always show up there Oct 18 10:33:25 so i'd say, by manual inspection you can guess and judge. in an automated and *RELIABLE* way that also works for non-trivial cases beyond simple dependencies, its incredibly hard. Oct 18 10:35:03 ykrons: and yes, thats one of the usecase of the world target Oct 18 10:39:02 Hey, does anyone here know why kernel startup successfully works, but for some reason it tries to mount mmcblk1p1 as ext3 and ext2 before it finally finds ext4 and then mounts it? Oct 18 10:39:41 (not directly yocto related) Oct 18 10:42:16 feilz: were is that noted? what tells the kernel to mount mmcblk1p1 at all? is there maybe something "auto" set, instead of ext4 specifically? Oct 18 10:42:40 it's mentioned in dmesg. Oct 18 10:43:10 feilz: then read more, to find out what triggers it. fstab? kernel cmdline? Oct 18 10:46:05 fstab doesn't specifically mention mmcblk1p1. It's triggered when booting from u-boot. Oct 18 10:46:36 feilz: then look at the cmdline Oct 18 10:46:46 something has to tell the kernel to look at it. Oct 18 10:48:38 some file called uEnv.txt probably contains it. Oct 18 10:48:50 *sigh* Oct 18 10:49:08 ? Oct 18 10:49:15 come back when you successfully got rid of your "probably" Oct 18 10:54:43 feilz: bootargs variable in U-Boot definitely sets the kernel commandline, I don't know about uEnv.txt, maybe Oct 18 10:55:30 Hi, I am new to yocto. I am trying to cross compile yocto on a OpenSuse Tumbleweed systgem for Raspberry Pi. "bitbake core-image-base" fails in "file-native" due to not finding the "seccomp.h" header file. I understand compilation of "file-native" succeeds if I uninstall the "libseccomp-devel" package, which I did. Oct 18 10:55:55 Then I tried "bitbake -f file-native" which gives me the message "WARNING: Explicit target "file-native" is in ASSUME_PROVIDED, ignoring", and thats when I get lost. Oct 18 10:56:32 bhoel|3: that means yocto thinks it doesn't need to build "file" to run on your host, as t should be there. Oct 18 10:56:37 Why is bitbake trying to builkd "file-native in the fiorst place, if it is listed in "ASSUME_PROVIDED"? Oct 18 10:57:28 LetoThe2nd: yep, remove a layer is hard and only full test cycle with sufficient test coverage will tell if removing a layer is ok. I've done it several times and both buildhistory and bitbake -e output of various things have helped. Oct 18 10:58:34 mcfrisk: thats what i mean. you can manually obtain a "good enough" decision, but we're nowhere near doing that automatically. Oct 18 11:00:39 bhoel|3: good question. do you have any particular requirements to build on tumbleweed? if not, you can just spin up a container running a tested distro, for example Oct 18 11:02:36 LetoThe2nd: I wanted to avoid another layer on my ancient AMD Athlon II X3 445 driven system, but I will give it a try. Oct 18 11:03:18 bhoel|3: heh, thats really not a problem. the impact of building in a docker container is negligible as far as i can tell. Oct 18 11:06:11 (yet, if you are doing this for a living, getting somewhat decent build box quickly pays off) Oct 18 11:11:21 I just try to learn the stuff privately. A decent building box is on my which list, but not in my budget :-( Oct 18 11:13:10 gotcha Oct 18 11:16:50 bhoel|3: oh thats interesting, we can fix the seccomp thing. if you want to build it explicitly, bitbake file-replacement-native. easy fix, just delete tmp and let it rebuild Oct 18 11:18:19 we assume that 'file' exists on the host as we need it to do even basic compilation, but we also need to build a libmagic to link against later on so that involves building file Oct 18 11:24:08 rburton: The fix for me with installed libseccomp-devel was to replace "#include " with "#include " in "git/src/seccomp.c:34:10". Where can I getz I tutorial how to fix this kind of issues correctly? Oct 18 11:24:49 the correct fix is to never build file with seccomp because it breaks things later Oct 18 11:28:35 bhoel|3: https://patchwork.openembedded.org/patch/165913/ Oct 18 11:30:10 hi, asking again in CET hours in case someone knows - with rpm builds (on thud), has anyone seen failures due to "file /usr/share/polkit-1/rules.d conflicts between attempted installs of polkit-0.115-r0.aarch64 and systemd-1:239-r0.aarch64" ? Oct 18 11:30:45 there's https://jira.automotivelinux.org/browse/SPEC-2588 but it has no solution at the moment Oct 18 11:35:55 bluca: two recipes try to install same file, remove one of them Oct 18 11:37:52 rburton: thanks :-) Oct 18 11:44:17 mcfrisk: nope, it's just a directory Oct 18 11:46:10 directories are files too Oct 18 11:46:22 are they both shipping content in the directory? Oct 18 11:47:30 one is, one isn't Oct 18 11:47:58 change the recipe that ships nothing to delete the directory? Oct 18 11:49:43 the packaging system supports having the same directory in multiple packages, obviously Oct 18 11:49:53 right Oct 18 11:49:56 are you saying yocto doesn't? that would be very weird Oct 18 11:50:02 of course it does Oct 18 11:50:12 how else would two packages ship a binary in /usr/bin :) Oct 18 11:50:27 right Oct 18 11:50:31 so why is it erroring out like that? Oct 18 11:50:33 i just can't remember what the catch is that causes this. maybe different permissions on the directories? Oct 18 11:50:43 what package manager, rpm opkg deb? Oct 18 11:50:46 rpm Oct 18 11:50:59 check the ownerships in the package, maybe thats the proble Oct 18 11:51:06 both recipes are installing with 700 polkitd:root Oct 18 11:51:27 and uid/gid 0 in the cpio headers Oct 18 11:52:24 rburton: did even notice you joining, can you maybe share some wisdom on python and compilation to pyc? we've had the question here this morning. Oct 18 11:52:33 abhiarora44: ^^^^^^^^ Oct 18 11:52:43 polkit: https://github.com/freedesktop/polkit/blob/0.115/src/polkitbackend/Makefile.am#L111 Oct 18 11:53:39 systemd: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/systemd/systemd_239.bb?h=thud#n287 Oct 18 11:53:58 we tried removing the directory from polkit's recipe, but that causes a further race condition Oct 18 11:54:22 where the directory has the wrong ownership - root:root instead of polkitd:root, which means polkitd fails at boot Oct 18 11:55:04 (that was a simple rmdir in do_install_append) Oct 18 11:56:33 no other package apart from systemd and polkit ships /usr/share/polkit-1/rules.d so it doesn't look like there's a third actor causing the race Oct 18 11:57:52 any suggestion to further debug this and figure it out? I am stumbling in the dark atm :/ Oct 18 12:01:03 rpm is a bit weird here, i can't remember what the trigger is Oct 18 12:01:13 rburton: s/here//g Oct 18 12:10:05 true that Oct 18 12:10:29 my best guess is that there's a race _somewhere_ that makes the systemd recipe fail to actually apply the ownership change Oct 18 12:10:51 but I haven't been able to prove that Oct 18 12:11:35 users created via USERADD_PARAM_ are available in a recipe's do_install step, right? Oct 18 12:29:10 mcfrisk, LetoThe2nd, weltling: I thinkk I will parse recipe-depends.dot to get the list of recipe and their layer. Then find related bbappend if they exists (and their layer) was bitbake-layers show-appends. From that I guess I must have used layers Oct 18 12:56:26 is it possible to set an override with d.setVar ? Oct 18 12:56:35 d.setVar("XPLATFORM_mingw32", "win32-oe-g++") Oct 18 12:59:18 hello again. Generic question: is it normal/usual/logical for a yocto layer to depend on specific linux distribution on host? Oct 18 12:59:39 i.e. the image build spits errors, the support says use Ubuntu 16.04.5 LTS 64-bit Oct 18 13:00:08 I'm a noob, but IMO it's not good Oct 18 13:00:19 our layer depends on latex of the host. but not on much else Oct 18 13:00:29 apart from stuff already in HOSTTOOLS by yocto Oct 18 13:00:38 kayterina: bad practise. it happens when a layer maintainer depends on things that run on the host, but is too lazy to properly package them up as -native recipes Oct 18 13:01:00 kayterina: read that as: strong sign that the layer is of low maintenance and code quality Oct 18 13:04:03 mcfrisk, LetoThe2nd, weltling: with some dirty shell, python and manual compare, I was able to identify 2 unused layers freescale-distro and qt4. Probably no false positive, so it already means that nearly all layers are used Oct 18 13:04:09 allright, found the issue: I used a machine specific override for DEFAULTTUNE (DEFAULTTUNE_olinuxino-a20lime2-emmc = "cortexa7hf-neon-vfpv4"). for some reason devtool doesn't like that, it kept looking for the package install files in build/tmp-glibc/work/cortexa7t2hf-neon-oe-linux-gnueabi/ instead of build/tmp-glibc/work/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/. is there a good workarround for this? since I'm building for multiple machines Oct 18 13:04:11 i can't really just set DEFAULTTUNE without a machine specific override :( Oct 18 13:11:36 kayterina: most likely because thats what they tested on and they didnt bother testing on anything else Oct 18 13:12:04 and as LetoThe2nd said, used host tools instead of documenting requirements and/or writing recipes Oct 18 13:12:07 curious what layer this was Oct 18 13:12:59 ok,what am I looking for now? "how to package openssl natively in yocto"? Oct 18 13:13:23 kayterina: whats the error? Oct 18 13:13:40 (we already have openssl native) Oct 18 13:14:07 bisbarn: shouldn't DEFAULTTUNE be in your machine conf file? Oct 18 13:14:21 rburton: openssl-native-1.0.2h-r0 do_configure: The perl module 'bignum' was not found but this is required to build openssl. Please install this module (often packaged as perl-bignum) and re-run bitbake. Oct 18 13:14:34 oh wow haven't seen that for a while Oct 18 13:14:39 do what it says :) Oct 18 13:14:43 install the perl bignum module on your hsot Oct 18 13:14:55 (some distros managed to break the default install of perl) Oct 18 13:15:59 i'm guessing you're using fedora Oct 18 13:16:19 if so, on fedora you just want to install perl-bignum Oct 18 13:19:19 I have, it is in "libcrypt-openssl-bignum-perl" and says I have latest version. Oct 18 13:19:58 i think you want perl-bignum Oct 18 13:20:16 https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#fedora-packages <-- fwiw, this is documented Oct 18 13:20:31 qschulz: right, would be a cleaner way. is it possible to override "append" the machine.conf supplied by meta-sunxi? Oct 18 13:22:35 I'd create a new machine which requires machine.conf from meta-sunxi and change DEFAULTTUNE, all that in your layer. Don't know if it's best practice though. Oct 18 13:23:22 our build scripts run with python (SCons), and I run the scons with the host's python Oct 18 13:23:26 I suspect that's frowned upon Oct 18 13:23:36 but then, yocto itself also uses host's python.. Oct 18 13:24:18 there's a difference between running a script using host's bash or python (IMO acceptable), and compiling something using hosts' python or gcc, and then shipping it (bad) Oct 18 13:28:36 rburton: I have read the manual entry before everything, but never found perl-bignum for debian(I'm on debian 9), except for that libmath package. I am missing something here. Oct 18 13:31:20 qschulz: found a neat solution on the mailinglist https://lists.yoctoproject.org/pipermail/yocto/2017-October/038448.html . basically add a conf/machine/xyz-extra.conf and include it in local.conf or distro.conf with include conf/machine/${MACHINE}-extra.conf :) Oct 18 13:32:52 and this does work with devtool :) thanks man Oct 18 13:36:53 kayterina: debian works out of the box there, bignum is part of per Oct 18 13:36:54 perl Oct 18 13:37:48 kayterina: try 'perl -Mbigint -e true' in a terminal, what does it say Oct 18 13:38:34 hm...nothing Oct 18 13:39:01 but there is bignum.pm in /usr/share/perl/ Oct 18 13:39:33 nothing is good Oct 18 13:39:49 in all -apparently- four versions that I have 5.22 5.22.2 5.24 5.24.1 Oct 18 13:39:53 that's all the test does, so the question is why is that aborting if it works for you Oct 18 13:40:00 maybe your perl is a bit knackered Oct 18 13:42:51 I never used perl, should I purge/reinstall it? Oct 18 13:44:37 rburton: I am also very unsure if I understood what you wrote Oct 18 13:45:46 might help, but you'll never manage to purge it as its needed by too much core stuff Oct 18 13:47:47 bisbarn: why do you need to change the DEFAULTTUNE BTW? Oct 18 13:49:36 knackered pearl => broken installation? (from urban dictionary:1. Exhausted 2. Sexually spent 3. Reprimanded 4. Broken / malfunctional.) Oct 18 13:50:08 yes :) Oct 18 13:50:38 rburton: ok! Oct 18 13:57:08 qschulz: those got recommended for the allwiner a20 by meta-sunxi for performance reasons ;) Oct 18 13:57:34 quick API question! Oct 18 13:58:07 bisbarn: I hope you're sending a patch so they fix it in meta-sunxi :) Oct 18 13:58:13 if I do setVar("foo_override", value) will it delete others override and the non-override value? or will it just add foo_override as if i had written it outside of functions? Oct 18 13:58:52 qschulz: I mean it's in the README.md from meta-sunxi :D don't know why they aren't adding it as default in their machine conf :P Oct 18 13:59:22 bisbarn: wtf Oct 18 14:00:55 qschulz: https://github.com/linux-sunxi/meta-sunxi/blob/master/README.md Oct 18 14:01:06 bisbarn: I know I know, I'm reading the github issue :) Oct 18 14:01:09 :D Oct 18 14:03:10 but i'm still confused why devtool wouldn't accept the DEFAULTTUNE_machine override Oct 18 14:03:22 smells like a bug to me :D Oct 18 14:08:00 bisbarn: their README is wrong as well, it does not enable thumb Oct 18 14:09:08 I'd hnoestly send a patch, I don't understand their justification of "The default machine settings are meant to be the lowest common denominator, maximizing generality" Oct 18 14:10:03 the only benefit is build time optimization if you build more than one machine Oct 18 14:11:56 qschulz: guess it would be cortexa7t2hf-neon-vfpv4 then for thumb2 Oct 18 14:13:24 although I'm going to stick with plain thumb for the time beeing, rebuilding the whole thing will be scheduled for next week :D Oct 18 14:15:31 does cortexa7t2hf-neon-vfpv4 even exist? Oct 18 14:15:39 I saw the one without the 2 in it Oct 18 14:17:58 it's just in PACKAGE_EXTRA_ARCHS_tune-cortexa7thf-neon-vfpv4 but I don't really know how everything in there is working :) Oct 18 14:20:30 mhhh ARM_THUMB_SUFFIX = "${@bb.utils.contains_any('TUNE_FEATURES', 'armv4 armv5 armv6', 't', 't2', d)}" Oct 18 14:21:02 seems like you have no control over what "thumb" it'll actually use, but i have no idea anyway :D Oct 18 14:24:43 rburton, now trying to make qt5 compile. man this is difficult. messy! It depends on qtbase-native. But qt has its own native-building mechanism for building its qmake Oct 18 14:24:59 so this is some convoluted toolchain soup going on Oct 18 14:44:29 litb: yes, qt is a pain to build Oct 18 14:45:34 why did the meta-qt5 layer decide to not use qt's own mechanism to build for the host? Oct 18 14:46:20 instead, they built the qtbase-native package. to get those binaries, like qmake et al Oct 18 14:46:47 probably because you need a standalone qmake anyway Oct 18 14:47:02 and the qmake that's built by the target qtbase seems useless, because it's built for the target. not yet sure how that's supposed to work. need to dig deeper... Oct 18 14:47:14 sure the target qmake is for use on the target Oct 18 14:47:22 to build on the build host, you need the native package Oct 18 14:47:46 rburton, but its built by qt's configure at build time, because it's used by its build scripts. but if it's used to run on the target, it can't be used at build time Oct 18 14:48:36 so I'm not sure how it's supposed to work. maybe the layer arranges that the previously built qtbase-native's qmake binaries will be used, instead of the qmake built by qt's configure Oct 18 14:58:43 yes Oct 18 14:58:53 qtbase-native provides the build tools to build qt Oct 18 14:58:58 fairly standard idiom Oct 18 14:59:13 file depends on file-native because file needs file to build Oct 18 15:03:29 rburton, yeah. Qt is non-standard. it builds its own tools for both the target *and* the build system Oct 18 15:04:25 rburton, therefore it accepts a -xplatform parameter and a -platform parameter. but meta-qt5 doesn't appear to use this "feature" of the qt configure/make system. so during configure, qt uses the -platform parameter to try and build its qmake Oct 18 15:04:51 speak to JaMa, i avoid qt Oct 18 15:05:07 I think it works now! for -platform , I just pass the host g++ now. Oct 18 17:55:50 rburton, some packages tend to install their dll files to libdir. so it could make sense to add a pass to autotools.class's do_install to move ${SOLIBS} from libdir to bindir Oct 18 17:56:47 only for the mingw32 machine, of course Oct 18 19:30:21 New news from stackoverflow: Yocto Image: user is not able to change his password due to be told old password is incorrect Oct 18 19:47:22 I have a simple Cmake application that I'm trying to create a recipe for. I had some issues earlier that it could not find standard headers like errno.h. I just discovered that this seems to be because I set the cflags in my CMakeLists.txt, and this seems to override the --sysroot flags etc that Yocto sets for the cross compilation. Oct 18 19:50:39 In CMakeLists.txt I set the flags using set (CMAKE_C_FLAGS....) Oct 18 21:42:47 https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/ Oct 18 22:11:55 iceaway_: just append instead of overwriting **** ENDING LOGGING AT Sat Oct 19 02:59:57 2019