**** BEGIN LOGGING AT Wed Jan 18 03:00:01 2017 Jan 18 03:02:22 bluelightning: well probably because Crofton|work is a big xilinx fanboi :) Jan 18 03:02:29 lol Jan 18 03:02:31 bluelightning: can you CC me on that thread ? Jan 18 03:02:37 no Jan 18 03:02:41 Crofton|work: I have a patchset, yu want it ? Jan 18 03:02:51 hang on Jan 18 03:02:55 Crofton|work: I also have a patch for meta-openembedded/meta-python Jan 18 03:02:58 not readin g back Jan 18 03:03:13 Crofton|work: better read forward ! Jan 18 03:03:16 https://patchwork.openembedded.org/patch/135639/ Jan 18 03:03:24 is in flight, does this help? Jan 18 03:03:37 also, we use OpenEmbedded, not yocto Jan 18 03:04:12 Crofton|work: there is no yocto, there is yocto project ! :-E Jan 18 03:04:23 Crofton: who said yocto? Jan 18 03:05:40 Crofton|work: yeah, I have similar patch for meta-openembedded here, so I can replace it , cool :) Jan 18 03:05:52 channel name :) Jan 18 03:06:00 gotta slap Marex around Jan 18 03:06:37 Crofton|work: I'll talk to fischerm to educate you a bit on the namings ... Jan 18 04:52:42 Marex: please make sure subject has "meta-python][PATCH" for --subject-prefix Jan 18 04:53:05 Marex: see the readme in meta-python layer Jan 18 04:54:08 Marex: http://git.openembedded.org/meta-openembedded/tree/meta-python/README Jan 18 06:32:34 nrossi: Hello, I need this qtquick1-qmlplugins packages and for the same I added it to packagegroup-qt5-toolchain-target.bb under DEPENDS_${PN} but I don't get this package Jan 18 06:32:46 is there any other to build this package ? Jan 18 07:20:12 there are two x.bb,y.bb, what if i want even compile y.bb. the system will recompile x.bb also. how to achieve this ?thanks Jan 18 07:20:53 like x.bb depends on y.bb, while x.bb does not support incremental compile. Jan 18 07:31:21 nrossi: Hello, I need this qtquick1-qmlplugins packages and for the same I added it to packagegroup-qt5-toolchain-target.bb under DEPENDS_${PN} but I don't get this package, is there any other to build this package Jan 18 07:32:38 there are two x.bb,y.bb, what if i want even compile y.bb. the system will recompile x.bb also. how to achieve this ?thanks like x.bb depends on y.bb, while x.bb does not support incremental compile. Jan 18 07:32:42 Ramose: you mean DEPENDS or RDEPENDS? Jan 18 07:33:01 sorrt, its RDEPENDS Jan 18 07:33:06 *sorry Jan 18 07:33:20 Ramose: np just wanted to make sure i understood correctly ;) Jan 18 07:34:11 ok, what extra I need to do to get this package Jan 18 07:35:48 Ramose: Not sure, it seems it should be built normally. Does it not generate a qtquick1-qmlplugins package in the workdir or deploy/... Jan 18 07:36:15 No , it doesn't Jan 18 07:36:42 nrossi: only related package I get is qtquick1 Jan 18 07:37:30 Ramose: dive into qtquick1's workdir, have a look at log.do_package. See what it says about -qmlplugins Jan 18 07:38:27 ok Jan 18 08:06:02 hello to all Jan 18 08:06:11 in krogoth branch I have an error QA Issue: No GNU_HASH in the elf binary: '...p2020rdb-poky-linux-gnuspe/linux-qoriq/4.1-r0/packages-split/kernel-vmlinux/boot/vmlinux-4.1.30-rt34+g4004071' [ldflags] Jan 18 08:06:20 when I change the default KERNEL_DEFCONFIG Jan 18 08:06:33 even if my KERNEL_DEFCONFIG matches the /arch/powerpc/configs/mpc85xx_smp_defconfig I see the error. But when I use the mpc85xx_smp_defconfig then the error dissapears Jan 18 08:07:16 does anyone has seen this error? Jan 18 09:07:21 good morning Jan 18 09:16:47 I've been asking how to build a specific module. I found how: meta-skeleton/recipes-kernel/hello-mod Jan 18 10:00:04 RP: late night hacking last night resulted in a green mut run apart from some checkuri failures (two transient, and ed which we need to fix) Jan 18 10:00:10 i'll fire a cpull shortly Jan 18 10:02:36 How can I change my GPIO (default) boot value? I'm using a gpio as output. But in boot up, this gpio is HIGH level. I need this gpio low level. Jan 18 10:03:54 I think I can change it from kernel. But I don't have any experience with kernel. Jan 18 10:10:38 Geera: hack your device tree! Jan 18 10:10:57 #openswan Jan 18 10:24:22 rburton: great, thanks! Jan 18 10:24:30 rburton: wish I could say the same about rss :/ Jan 18 10:24:48 ed2: we're going to need to do something about wic, most of the issues come from there :( Jan 18 10:26:20 RP: I'm almost done. it became slower though as wic has to run bitbake quite often. Jan 18 10:26:36 ed2: :( Jan 18 10:26:46 RP: it will go away with memres bitbake I hope. Jan 18 10:27:20 ed2: is this because you need variables or to actually build things? Jan 18 10:28:24 RP: yes, I need native sysroot location for every tool recipe. Jan 18 10:28:46 ed2: I thought I said you couldn't do that due to dependency problems? Jan 18 10:29:14 RP: btw, do you know why RECIPE_SYSROOT_NATIVE doesn't always point to the correct directory. Jan 18 10:29:37 ed2: I'm not sure what you mean by "correct" Jan 18 10:29:57 RP: e.g. $ bitbake -e parted |grep RECIPE_SYSROOT_NATIVE= Jan 18 10:29:57 RECIPE_SYSROOT_NATIVE="/home/ed/git/yocto/poky/build/tmp/work/core2-64-poky-linux/parted/3.2-r1/recipe-sysroot-native" Jan 18 10:30:17 $ find ./tmp/ -name parted |grep recipe-sysroot-native Jan 18 10:30:17 ./tmp/work/x86_64-linux/parted-native/3.2-r1/sysroot-destdir/home/ed/git/yocto/poky/build/tmp/work/x86_64-linux/parted-native/3.2-r1/recipe-sysroot-native/usr/include/parted Jan 18 10:30:17 ./tmp/work/x86_64-linux/parted-native/3.2-r1/sysroot-destdir/home/ed/git/yocto/poky/build/tmp/work/x86_64-linux/parted-native/3.2-r1/recipe-sysroot-native/usr/sbin/parted Jan 18 10:30:33 ed2: you ran bitbake parted, not bitbake parted-native Jan 18 10:31:34 "bitbake -e parted-native |grep RECIPE_SYSROOT_NATIVE=" would likely give you what you want Jan 18 10:46:11 RP: something is still going wrong here. parted binary is in ./tmp/work/x86_64-linux/parted-native/3.2-r1/sysroot-destdir/home/ed/git/yocto/poky/build/tmp/work/x86_64-linux/parted-native/3.2-r1/recipe-sysroot-native/usr/sbin/parted. Looks like a bug to me. Jan 18 10:46:50 RP: Can you suggest where to look? Jan 18 10:47:30 ed2: no, that is not a bug Jan 18 10:47:41 ed2: I did tell you this wouldn't work :/ Jan 18 10:47:59 ed2: A recipe's own output isn't installed into its own sysroot unfortunately Jan 18 10:48:09 ed2: there isn't any real need to do that Jan 18 10:49:54 Hi, does anybody know why there is the line "LICENSE = "MIT"" in image.bbclass ? Jan 18 10:50:03 RP: where is it installed then? Jan 18 10:50:56 ed2: it is placed into the sysroot-components directory in isolation and then installed into sysroots of recipes that depend upon it Jan 18 10:51:02 geoffrey_l: historical reasons Jan 18 10:51:32 geoffrey_l: it used to be mandatory for all recipes, now it depends on whether the recipe takes in any source Jan 18 10:52:20 geoffrey_l: it doesn't really make much sense to talk about the license for an image at least in output, since it's usually composed of quite a number of components with their own license - hence we produce a license manifest for that Jan 18 10:52:48 of course one can consider the license for the recipe itself, but that's not what LICENSE is about Jan 18 10:53:00 RP: heh :( ok, I'll go back to special recipe that depends on all native tools. It will work faster. Jan 18 10:55:01 RP: can you suggest what to put to the recipe to get all dependencies built? adding DEPENDS = "parted-native syslinux-native gptfdisk-native dosfstools-native mtools-native bmap-tools-native" doesn't make the m built for some reason. Jan 18 10:55:08 ed2: sorry, this is all a bit confusing :( Jan 18 10:55:24 ed2: that DEPENDS should work Jan 18 10:55:50 RP: this is the recipe: SUMMARY = "A meta recipe to build native tools used by wic." Jan 18 10:55:51 LICENSE = "MIT" Jan 18 10:55:51 DEPENDS = "parted-native syslinux-native gptfdisk-native dosfstools-native mtools-native bmap-tools-native" Jan 18 10:55:57 hi all Jan 18 10:57:06 bluelightning: It still fail if the image recipe take any source, because the checksum is not set. Actually I work on a way to add an overlay of config files in images recipe, so licence make more sense and I was wondering if there is any good reason to enforce it on "MIT". Jan 18 10:57:32 geoffrey_l: that's a separate issue Jan 18 10:58:09 geoffrey_l: it becomes a mess... this is one reason why we decided to disable fetching files in image recipes Jan 18 10:58:19 I know it seems like the easiest solution... Jan 18 10:58:32 RP: it builds just fine. after that I don't see parted binary in ./tmp Jan 18 10:58:49 RP: could it be that I'm missing something in the recipe? Jan 18 11:00:21 ed2: I added http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss&id=7d9cd0fdc9269d82467633e895c43de1712ca66f (the last couple of lines were added for speed) Jan 18 11:00:38 ed2: bitbake wic-tools, then ls tmp/work/i586-poky-linux/wic-tools/1.0-r0/recipe-sysroot-native/usr/sbin/pa* Jan 18 11:00:38 tmp/work/i586-poky-linux/wic-tools/1.0-r0/recipe-sysroot-native/usr/sbin/parted Jan 18 11:00:55 ed2: so it seems to work for me? Jan 18 11:01:55 RP: if you remove tmp and build this recipe again would it still work? Jan 18 11:01:58 bluelightning: Anyway, wouldn't it be more appropriate to do something like "LICENSE ?= "MIT"" in image.bbclass instead ? Jan 18 11:02:03 ed2: yes, it should Jan 18 11:02:24 RP: Can you try? Jan 18 11:02:24 ed2: I can try Jan 18 11:02:58 ed2: of course wic-tools is installed from sstate and therefore it doesn't populate the sysroot Jan 18 11:03:00 RP: I can see recipe-sysroot-native directories only for pseudo-native Jan 18 11:03:50 RP: yes, that's probably the reason. Jan 18 11:04:21 RP: so, how to make it to populate sysroot if it doesn't exist? Jan 18 11:05:28 hi guys! if i want to remove a recipe from a build is it enough to delete the folder? Jan 18 11:06:32 ed2: give me a minute to look at this, I see the problem :/ Jan 18 11:06:52 sure. Jan 18 11:09:33 ed2: this works: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss&id=020540e8843333f47b01c789c0e0fe7fa32bbab0 Jan 18 11:12:01 RP: magic :) ! It works! Jan 18 11:12:06 RP: thank you Jan 18 11:12:18 ed2: np, sorry I didn't realise that problem :/ Jan 18 11:12:53 RP: do name and path meta/recipes-support/wictools/wictools.bb look acceptable? Jan 18 11:14:09 ed2: I'd probably put it where I have it in my branch, the meta directory has several other artificial recipes like this Jan 18 11:15:02 RP: ok, thanks. i'll move it there. Jan 18 11:40:23 is there a guide to psplash settings? i customized my bootsplash logo but i'd like to change some stuff Jan 18 11:41:19 Talorno: I had to patch c-code to change background color. don't think there's any nice guide Jan 18 11:41:35 ernstp, would you tell me more please? Jan 18 11:42:49 'cause.... first of all i have a white line across the whole screen and i don't know from where is it coming Jan 18 11:43:12 and second i'd like to change the color of the progress bar {or move it} Jan 18 11:43:35 ah...another question...is there a nice way to change the color of the blanking parameter of u-boot? Jan 18 11:43:43 ernstp, save me! :P Jan 18 11:47:19 oh and also.... i'd like to preconfigure my yocto image (i mean system settings) so when i boot them they are already set up as i want (/etc/network/interfaces , for example) Jan 18 11:51:25 gypsy doesn't like gcc 6.3 much: http://paste.fedoraproject.org/529532/40133148/ Jan 18 11:52:18 why does pixbufcache.bbclass only set do_package_write_rpm[depends] but not deb/ipk ? Jan 18 11:52:46 Hi, I would like to add an additional field to the pkgdata of a package similar to the other fields like LICENSE. Is there a way to do that without modifying the package.bbclass? Jan 18 11:54:06 Talorno: network/interfaces is a classing bbappend on init-ifupdown, pretty standard stuff Jan 18 11:54:09 hmm, my own patch :/ Jan 18 11:56:15 Talorno: psplash example https://www.irccloud.com/pastebin/EG3YiX6k/ Jan 18 11:56:34 ernstp, maybe "classic bbappend' is classic for you :P i'm pretty new to yocto, is there something about that thing that i should read? Jan 18 11:56:49 and about psplash.... do you mean i am supposed to edit the source code? Jan 18 11:58:17 Talorno: checkout devtool btw Jan 18 12:07:18 hi, I would like to know how yocto is determining rdepends even if we have not added it as RDEPENDS Jan 18 12:07:59 I couldn't find any link even after searching on web Jan 18 12:08:34 grk: it looks at the binaries generated and adds anything they link against to the RDEPENDS (same as every mainstream linux distro does, basically) Jan 18 12:09:24 rburton: ok, thanks Jan 18 12:09:33 that was helpful Jan 18 12:21:05 jku, rburton: I think I'm going to need some help. We have a problem with postinstall dependencies. rss means we're going to have to actually document what the postinstalls need Jan 18 12:21:38 right Jan 18 12:22:27 I can pick off the first pass at this but I'm probably going to need some help to double check it all Jan 18 12:27:30 so this means building image with rss, checking which postinstalls fail on rootfs creation time (at least the ones that didn't fail without rss), fix one-by-one by adding new DEPENDS? Jan 18 12:27:49 RP ^ or were you thinking something more clever? Jan 18 12:28:26 jku: Probably more like going through the metadata looking at the postinsts and then adding the right markup. Thankfully we don't have too many postinsts. The dependency is in the form of a new variable, DEPENDS isn't enough Jan 18 12:28:39 ah I see Jan 18 12:28:40 jku, rburton: I'm going to try and finalise how this should work after lunch Jan 18 12:29:28 jku: Checking which postinsts fail is the other way but its not foolproof. I've seen several work locally only to fail on the autobuilder as it didn't have gconf installed or glib-2.0 etc Jan 18 12:29:47 jku: it did this with depmod on debian-testing :/ Jan 18 12:29:53 yeah, I was guessing that would be unreliable Jan 18 12:30:27 jku: I do have a first pass at it just to check its going to work, my last test failed though so its now rebuilding :/ Jan 18 12:31:22 ok, just let me know Jan 18 12:31:30 RP: sure Jan 18 12:32:11 this is the case where postinst does stuff on the host in rootfs so eg depends on native tools right Jan 18 12:33:51 rburton, jku: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss&id=b8eeb3c90428931b022fbbd658fa11bd5cb20e50 is my first pass Jan 18 12:34:01 rburton: yes, its the native tools we need to list Jan 18 12:34:15 DEPENDS can be cleaned out if the tools aren't needed at buildtime and only at postinst Jan 18 12:34:40 neat Jan 18 12:34:44 Right now sstate.bbclass has a hardcoded list but part of this magic should be that we can remove that Jan 18 12:34:50 That can come later though Jan 18 12:36:49 rburton, jku: I've giving a headsup as this is going to be pretty urgent :/ Jan 18 12:37:04 but lunch whilst this all rebuilds Jan 18 12:43:16 RP: wic seem to work with wic-tools approach. I'll still have to fix 3 selftest failures, but they're related to recent changes from master. Jan 18 12:54:30 Hi, how to suppress installing /etc/init.d/hostapd and it's rc links? Jan 18 12:58:37 kalpu: you still want the rest of hostapd? Jan 18 13:03:17 ernstp: Yes, I think I got it in my own hostapd_2.6.bb But now I'm facing the problem that hostapd_2.5.bb from meta-oe is getting built instead of mine from meta-my/recipes-connectivity/hostapd/hostapd_2.6.bb Jan 18 13:04:39 Hello everyone! I'm working with 1.7 yocto but I need to upgrade some recipes (python_pip and nodejs). I've cloned the 1.8 yocto version recipes on its layers (erasing the old ones), but when I try to bitbake them i get "ERROR: Nothing PROVIDES '______.bb'", any ideas why? thanks in advance Jan 18 13:04:46 How to prefer a recipe over another? bitbake-layers show-layers shows some priorities. Is smaller bette? Jan 18 13:05:52 How to change the priority of a meta-layer? Jan 18 13:08:24 kalpu: pretty sure higher is better Jan 18 13:08:31 kalpu: layer priority is in layer.conf: BBFILE_PRIORITY_ Jan 18 13:08:56 kalpu: but you can use "PREFERRED_VERSION_ = " in your local or distro configuration Jan 18 13:14:12 it should already select the higher version recipe, shouldn't it? Jan 18 13:14:31 no, because meta-oe has a higher priority... Jan 18 13:14:57 I want to configure this in my meta-my layer. How to do that? Jan 18 13:15:32 jku: what is a distro and what is a local configuration? Jan 18 13:16:59 kalpu: "local.conf" is for your personal configuration: good for testing things out Jan 18 13:17:17 ed2: sounds good Jan 18 13:17:47 is there a global way to enable multiple core compilation using bitbake? Jan 18 13:17:59 jku: But this is in poky/build/conf/local.conf I want the configuration in meta-my/conf ... is this possible? Jan 18 13:18:06 Talorno: BB_NUMBER_THREADS and PARALLEL_MAKE Jan 18 13:18:17 RP set as global variable? Jan 18 13:18:28 Talorno: usually set in local.conf Jan 18 13:18:38 oh, i will have a look, thanks Jan 18 13:18:46 Talorno: they should be autoset to someting related to the number of cores Jan 18 13:18:55 at runtime, you mean? Jan 18 13:19:05 Talorno: see local.conf.sample iirc Jan 18 13:19:08 i mean...when you run bitbake it looks for the number of cores? Jan 18 13:20:57 Talorno: meta/conf/bitbake.conf:BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}" Jan 18 13:21:24 meta/conf/bitbake.conf:PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}" Jan 18 13:21:30 moto-timo: thanks, but I don't think I need to do anything, the patch is already submitted by someone else :) Jan 18 13:21:52 Talorno: there is more documentation in local.conf.sample.extended Jan 18 13:22:12 oh thank! Jan 18 13:22:14 *s Jan 18 13:24:05 there is "meta-openembedded/meta-oe/recipes-connectivity/hostapd/hostapd_2.5.bb" and now I want to update this to hostapd version 2.6 from within my own layer "meta-my". Whats the best way to do? Jan 18 13:26:12 jku, rburton: tests were successful so this works. I'll write up something for the arch list Jan 18 13:26:49 kalpu: that would be distro configuration. The default distro is "poky", see meta-poky/conf/. If you are creating an operating system with yocto you should probably define your own distro that configures things like this -- but I don't do things like that often so I don't have practical advice... Jan 18 13:27:58 kalpu: also, if you're building on top of yocto master you could just upgrade the hostapd in oe-core and send the patch to mailing list Jan 18 13:33:04 hi. is there a cmake .toolchain file distributed with the SDK ? thanks Jan 18 13:49:11 hello, are any of you successfully using meta-snappy and snaps on your embedded systems? Jan 18 13:49:46 any information on the state of snap support in Yocto would be greatly appreciated Jan 18 13:51:06 you'll have to ask whoever wrote meta-snappy Jan 18 13:53:42 rburton, I found this on the mailing list https://lists.yoctoproject.org/pipermail/yocto-ab/2016-September/001777.html Jan 18 13:54:34 so I assume even though snapcraft.io uses the OE and Yocto logos, Yocto project is not going to support snaps by itself and it is basically a community effort? Jan 18 13:55:05 there is no official support, correct. but the point of layers etc is that there doesn't need to be. Jan 18 13:56:25 their layer, so its up to you to gauge how much canonical care about meta-snappy Jan 18 13:57:25 rburton, understood... I suppose that is pretty much what I expected to hear. Just wanted to be sure. Jan 18 13:57:34 i'm not pleased that meta-snappy uses its own go recipe instead of meta-go Jan 18 14:02:39 using meta-go in production here, works well, quick response from dev Jan 18 14:12:06 rburton: is there a .lz fix that I can cherry pick? Jan 18 14:16:16 Is there any way to tell to bitbake that a task must be rerun everytime we build a recipe (without remove sstate-cache) ? Jan 18 14:17:19 geoffrey_l: what is the context? Jan 18 14:25:01 jku, rburton: I've sent an email to the arch list about it along with my patch so far. I think the patch should work outside of my rss work, would be interesting to test that though and see if we can complete the patch either way Jan 18 14:25:12 geoffrey_l: nostamp should work. eg: do_install[nostamp] = "1" Jan 18 14:25:14 jku, rburton: I think core-image-sato works with this Jan 18 14:26:15 kanavin: I have a recipe with a task that copy files after do_rootfs and before do_image (at ${IMAGE_ROOTFS}) Jan 18 14:28:36 maxin: it works, thanks ! :) Jan 18 14:29:46 RP, so what's the state now? (as in what should i do with it, apart from testing it out) Jan 18 14:30:22 kanavin: no, lzip is in meta-oe anyway right now Jan 18 14:35:36 jku: could you test it and see if it works outside my branch, then see if there are postinst deps I've missed? Jan 18 14:36:20 RP, will do Jan 18 14:36:39 Hi all! I'm struggling with installing an extensible SDK as generated by Yocto. Trying to cut out any project-specific detail, I nailed it down to running a 'bitbake core-image-minimal -c populate_sdk_ext' on a current poky/master tree and I try to install the SDK executing the generated script (built from scratch, no previous sstate-cache). It works just fine on the Yocto build host, where the installation ends with no Jan 18 14:36:41 error and I can verify a minimal devtool development cycle. My specific need is to install the SDK as a provisioning step in a vagrant-generated VirtualBox-backed VM. Here the installation fails the SDK setup stage, with a ton of 'ERROR: Sstate artifact unavailable for util-macros-native.do_populate_sysroot'. All the mentioned artifacts belong to *-native packages. Moreover, I'm not very familiar with sstate-cache cont Jan 18 14:36:43 ent but: Jan 18 14:36:44 jku: thanks Jan 18 14:36:47 vagrant@vagrant-ubuntu-trusty-64:~$ find poky_sdk/sstate-cache/ | grep util-macros | grep native Jan 18 14:36:49 poky_sdk/sstate-cache/91/sstate:util-macros-native::1.19.0:r0::3:9195390c16195e2d6ca0ffc31c412bdf_populate_lic.tgz.siginfo Jan 18 14:36:51 poky_sdk/sstate-cache/91/sstate:util-macros-native::1.19.0:r0::3:9195390c16195e2d6ca0ffc31c412bdf_populate_lic.tgz Jan 18 14:36:53 poky_sdk/sstate-cache/universal/20/sstate:util-macros-native:x86_64-linux:1.19.0:r0:x86_64:3:20612fbaf93f558b1e57d2641bec5236_populate_sysroot.tgz Jan 18 14:36:55 poky_sdk/sstate-cache/universal/20/sstate:util-macros-native:x86_64-linux:1.19.0:r0:x86_64:3:20612fbaf93f558b1e57d2641bec5236_populate_sysroot.tgz.siginfo Jan 18 14:36:59 Am I missing something? The VM is x86_64 while SDKMACHINE="x86_64" as per default... Jan 18 14:37:26 jku: talking with rburton we wondered about changing it so you didn't need the :do_populate_sysroot bits and the system did that automagically Jan 18 14:46:05 Good morning, all Jan 18 14:46:21 gizero76: current master or something older? Jan 18 14:46:40 Is there a straightforward way to "version" an SDK - I'm reading through the reference manual and SDK docs and nothing jumps out at me Jan 18 14:47:55 themikenicholson: this kind of problem was why we're moving to the eSDK (extensible sdk) Jan 18 14:48:45 halstead: did you get anywhere with the OOMing builder? shall i add it back to the pool now? Jan 18 14:48:46 how does the extensible SDK solve the versioning issue? Sorry if its a stupid question, still pretty new to this Jan 18 14:59:42 RP: master:63f899a950daf1018999455bafa7a2be8b22f164 is the commit I used to build the SDK Jan 18 15:01:12 btw the problem I'm seeing is *with* eSDK... I'm eager to expose some devtool based workflows to app devels ;-) Jan 18 15:01:56 themikenicholson: it ties the SDK and the metadata and means that by updating the metadata, the local SDK would rebuild to match Jan 18 15:02:39 gizero76: not sure then as the patches I was thinking of are in that Jan 18 15:03:01 gizero76: you are using uninative? Jan 18 15:05:31 RP: I'm pretty ignorant on the topic, sorry... How can I check? Anyway my last test (still failing) was with "everything at default", just reusing a DL_DIR. IIRC, something uninative-related (downloading uninative-something?) happens during the initial stages Jan 18 15:05:50 RP: Understood. Does the eSDK provide a mechanism where a version of the metadata may be specified? We're looking to support a workflow where various branches of our application repo can be tied to different versions of the SDK via a file checked into the repo. When a dev builds the application our tooling could switch to the proper version of the SDK Jan 18 15:06:33 gizero76: are you using poky as the distro? Jan 18 15:07:06 themikenicholson: basically, yes Jan 18 15:07:11 RP: We accomplish this today by checking the entire SDK sources into our application repo. Not a great approach for reuse/sharing between apps but makes it easy to keep SDK synced with your current version of the application Jan 18 15:07:40 themikenicholson: eSDK pulls the SDK from sstate based on a .inc file specifying the lockdown Jan 18 15:08:07 themikenicholson: the sstate can be included in the SDK or pulled from a remote server Jan 18 15:12:22 RP: yep! DISTRO="poky" Jan 18 15:14:17 gizero76: right, so you're using uninative Jan 18 15:14:27 (which is good) Jan 18 15:15:53 gizero76: when it generates the eSDK, there is a locked-sigs.inc file somewhere and it should list a hash for these natives. Those should match the hash in the sstate cache. I'd compare those next Jan 18 15:17:10 RP: Are you referring to locked-sigs.inc? Jan 18 15:17:37 themikenicholson: yes Jan 18 15:23:18 RP: we are testing with different OS in the VM and successfully completed an installation on a Ubuntu 16.04 (no vagrant, hand made VBox VM)... my failing scenario was with Ubuntu 14.04. Will investigate further if it is a guest distro related issue. Does this suggest something? Jan 18 15:24:32 gizero76: which gcc versions do they have? Jan 18 15:25:08 gizero76: its possible that something built on 16.04 won't work on something as old as 14.04 :( Jan 18 15:25:45 if 14.04 is gcc 4.8/4.9 and 16.04 is later which seems likely then that is likely the cause. There is an open bug to add a check for this and error Jan 18 15:28:04 RP: oh! interesting... sounds bad, indeed... not as portable as expected the SDK ;-) Will double check by upgrading the vagrant box to 16.04 and report back Jan 18 15:30:25 gizero76: we did try but ran into a problem with gcc here :( Jan 18 15:35:02 RP: I see! Just wandering what exactly goes wrong here: not that easy to figure out from the way it errors out. As you say, probably something we can only protect against by testing distro/gcc versions in advance Jan 18 15:39:11 gizero76: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c21cec84886d9c70396e9be0ceb9a8ef300b54be http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=5fd4cada2e49a0a12f54b8e37b7f18c44101457f Jan 18 15:43:13 RP: thanks for the pointer. I successfully installed the eSDK by upgrading vagrant VM specs to a xenial (16.04) box. Again, thanks for helping! Jan 18 15:54:31 Hello is there any special sauce required so serial ports work in the yocto project? Jan 18 15:54:58 I've got poky/krogoth on genericx86 Jan 18 15:55:18 Serial ports appear configured in every way but do literally nothing, not even errors Jan 18 15:59:44 This link can help? http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html#var-SERIAL_CONSOLES Jan 18 16:00:31 I'd really like to test out the eSDK but meta-qt5 is still causing issues. I think I understand the problem but I'm not sure if I have the right solution Jan 18 16:01:31 in meta-qt5 a recipe has a create_sdk_files_prepend() that attempts to create a file in a nonexistant directory Jan 18 16:03:03 themikenicholson: should likely report that to the maintainers of the layer Jan 18 16:03:03 It works fine in the regular SDK, but I'm assuming this breaks populate_sdk_ext because the Qt package (qtbase-native) responsible for creating the directory does not get installed to the sysroot when preparing the eSDK Jan 18 16:03:33 kergoth: already fired an email to oe-issues mailing list Jan 18 16:04:02 just trying to see if I can solve it in a fork for now Jan 18 16:05:30 ronan__: I believe that is for consoles, what I'm looking for is a port which I can use to transfer data Jan 18 16:05:39 The file getting created in the create_sdk_files_prepend() is a configuration file that contains a number of paths (where libs, headers, etc are located within the SDK) Jan 18 16:06:09 is create_sdk_files_prepend() the right place to do this thing? It seems like something that should happen after the install? Jan 18 16:06:32 RP: I'm almost there. 1 test case is left. Jan 18 16:17:46 gizero76: cool, we need to make that exit with a better error. Note that if you build on something old it is forward compatible, just the opposite isn't always tue Jan 18 16:24:19 https://wiki.yoctoproject.org/wiki/TipsAndTricks Jan 18 16:38:36 what does this mean QA Issue: Architecture did not match, happens when I build genericx86 machine, add a machine feature and make a new machine conf out of that and build it in the same build directory Jan 18 16:39:00 This happens during linux-yocto build Jan 18 16:39:10 see if it happens after wiping the tmp/ Jan 18 16:39:24 rburton: :( see you in 4 hours Jan 18 16:39:26 it means your build has a binary that doesn't match the expected type for the target Jan 18 16:39:30 Ok Jan 18 16:39:52 keep sstate, just rebuild the recipe that caused that message Jan 18 16:40:12 rburton: would a cleanall on that recipe be enough? Jan 18 16:40:17 just clean Jan 18 16:48:44 RP: so the patch builds fine on top of master, core-image-sato looks perfect (postinsts succeed). I'm not sure if I can really check if the new postinst dependency machinery is _really_ working though (since I don't have the recipe specific sysroots)? Jan 18 16:48:52 zeddii_home: zeddii are you around? Jan 18 16:48:53 maybe by wiping sysroot and forcing the package task to re-run? Jan 18 16:50:48 jku: Testing that that does help as it means we can merge this before rss merges Jan 18 16:51:00 jku: you could switch to my rss branch for subsequent testing? Jan 18 16:51:45 yeah I can try that later Jan 18 16:52:07 jku: but yes, wiping tmp, then running something like do_rootfs is a good test Jan 18 16:52:25 jku: the right pieces should get installed and if they don't we have a problem Jan 18 16:52:38 got it Jan 18 16:53:40 so about fontcache.bbclass: It uses qemu at rootfs time to run 'fc-cache' from fontconfig-utils if I've understood correctly Jan 18 16:55:09 does it even depend on fontconfig-utils at all ? Jan 18 16:57:09 jku: I think there are a lot of dependency bugs in the system like this :/ Jan 18 16:57:57 RP so let's assume it should, would the PACKAGE_WRITE_DEPS then be something like "qemu-native:do_populate_sysroot fontconfig-utils:do_populate_sysroot" Jan 18 17:01:43 jku: fontconfig-utils-native, these would always be -native deps Jan 18 17:02:14 RP: but it really seems to use qemu-wrapper to run fc-cache Jan 18 17:04:15 (it's a postinst-intercept) Jan 18 17:08:20 jku: it still means qemu-native is needed Jan 18 17:08:41 jku: ah, in that case we just need to make sure the package has the right RDEPENDS for the target Jan 18 17:08:48 aha Jan 18 17:08:50 jku: there is then no native dep Jan 18 17:09:27 so RDEPENDS will be in the target sysroot automatically Jan 18 17:11:14 jku: right Jan 18 17:11:49 thanks. anyway, heading home now. I'll go through the recipes that have postinsts and will then post to ML with at least comments Jan 18 17:11:54 jku: so it would just be qemu-native in that case Jan 18 17:12:05 yep, got it Jan 18 17:12:56 RP: first significant stumble, dnf does not support 'recommended' packages and considers only hard package dependencies, while we basically treat recommended as required in all of our configurations Jan 18 17:13:18 RP: I guess I can add that feature to upstream code though Jan 18 17:14:23 kanavin: I think there was some alternative solution added in rpm4 space but I don't remember what Jan 18 17:41:14 ed2: are your patches on a branch? I could do with rerunning builds on the autobuilder and would like to avoid some of the wic errors Jan 18 17:53:42 rburton, It passed all the memory and cpu stress tests and appears to OOM correctly. I'm adding it back to the pool now. Jan 18 18:01:56 RP: yes, I pushed my changes to ed/wic/rss Jan 18 18:02:30 RP: running selftest just to be sure all tests pass Jan 18 18:07:28 RP: one test still fails. I expect some silly typo there as previously it was passed. Jan 18 18:16:04 RP: fixed the failure. pushed again. running oe-selftest -r wic again Jan 18 18:27:17 RP: all tests passed: Jan 18 18:27:18 Ran 38 tests in 760.697s Jan 18 18:27:18 OK Jan 18 19:51:19 Hi folks, I'm seeing a build failure of qt4-embedded for armv7-a when using morty: https://ptpb.pw/RuLc . Basically relocation R_ARM_MOVW_ABS_NC can't be used when making a shared object; recompile with -fPIC Jan 18 19:52:11 Is the correct solution to append -fPIC to CFLAGS for the entire qt4-embedded recipe? I'm concerned that that may not really be the right solution Jan 18 20:16:42 jmesmon: I don't mean to be unhelpful, but qt4 is very obsolete Jan 18 20:17:24 I'm very aware. This isn't something I'm trying to bring up anew, it's something I need to keep working. Jan 18 20:17:58 As in: the build of qt4-embedded succeeded not too long ago, and is now failing Jan 18 20:18:20 jmesmon: in that case you might want to bisect? Jan 18 20:22:49 jmesmon: a bit of a discussion of the issue here: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/503448 Jan 18 20:23:12 seems like maybe enabling PIC is the right answer, assuming there aren't practical reasons why that's a problem Jan 18 20:23:20 kanavin_home: each qt4-embedded build takes quite some time to build from clean (>20minutes), and I'm not even sure what would be the item to bisect: meta-qt4 itself has not changed, and I'm trying to figure out what changes in the morty branch may have been the issue Jan 18 20:24:11 bluelightning: yep, saw that bug. Unfortunately, I've been running a much newer gcc than 4.4 for a while, and I'm pretty sure the binutils is very recent too :) Jan 18 20:24:23 oh, jmesmon, I think yes -fPIC is probably the thing. Jan 18 20:24:44 If memory serves: Some things need -fPIC for no reason more complicated than "the code is too large". Jan 18 20:24:59 Also I have vague recollections of horrible things happening if libraries aren't built -fPIC in some cases. Jan 18 20:25:17 jmesmon: bisection doesn't mean rebuild from scratch at every step, it will reuse things that can be reused Jan 18 20:25:18 I'm doing a rebuild of qt4-embedded right now with CFLAGS_append = " -fPIC" in a bbappend, so we'll see if that works. Jan 18 20:25:22 And... I think if memory serves this is especially an issue on arm when thumb might be involved. Jan 18 20:25:35 We ran into this a ton at WR because our ARM default was to use thumb when it was available. Jan 18 20:25:43 So a lot of stuff wouldn't build that would have built in ARM mode. Jan 18 20:26:42 25 minutes in. Jan 18 20:27:00 seebs: hmm, I'll make sure I pay attention to any thumb vs arm bits then Jan 18 20:27:21 But it's also a thing you can hit just from "gcc changed code generation slightly, and a think which was previously 17 bytes less than a size limit is now 3 bytes over it". Jan 18 20:27:48 kanavin_home: without cleaning I can't be sure the changes are actually being applied. My experience has been that many configure's don't properly apply changes over top of what is already there Jan 18 20:28:15 seebs: :( Jan 18 20:29:28 In general, if gcc says it needs -fPIC, it's usually right. Jan 18 20:30:00 ... it turns out that a goodly chunk of my role as "toolchain person" was to look at compiler messages, and say "hmm, it says file not found, is it possible that the file is missing?" Jan 18 20:30:28 seebs: I suppose I'm just wondering what will happen given that qt4-embedded isn't just libraries. CFLAGS_append = " -fPIC" might not have the right level of granularity Jan 18 20:31:07 welcome to a deep and fundamental problem with every Linux build system everywhere Jan 18 20:31:24 which is that there is no way to express "flags I want used only on libraries" and "flags I want used only on executables" sanely. Jan 18 20:31:30 I figure there should be some way to convince qmake4 (or whatever) to pass -fPIC only to libraries, but I'm not sure what the process is for that within both qmake4 itself and within yocto Jan 18 20:31:38 yep, painful Jan 18 20:31:46 in theory i think libtool should be able to do it, maybe? Jan 18 20:35:05 hmm... some other error is getting hit (compilation error this time). and it's still trying to compile code in do_install. funky Jan 18 20:35:13 jmesmon: I don't think bitbake will run configure on top of previous configure, it will either reuse previous build without any building, start building from scratch, or attempt to resume compilation. Or I misunderstand bitbake fully :) Jan 18 20:38:00 a lot of things seem to be doing at least some compilation in do_install, and there's always a reason, but I usually hate the reason. Jan 18 20:45:02 kanavin_home: I'm definitely seeing do_configure re-run, and then compilation tries to continue from whatever compilation happened last. Because almost all buildsystems (including qmake) don't recognize that objects depend on the commands that product them, it doesn't re-build objects that need rebuilding Jan 18 20:46:14 s/product/produce/ Jan 18 20:58:00 on libtool: it doesn't look like it is used by default in qmake, and the qt4 build system doesn't appear to turn it on Jan 18 21:17:31 can i get some basic help on writing a recipe? is there a way to specify SRC_URI to just point at a local directory for testing? Jan 18 21:18:48 eg instead of a tarball that gets extracted Jan 18 21:19:17 I don't think I've seen it used with just a local directory, but a local tarball is usually fine for small stuff. Jan 18 21:19:55 devtool can do external source, which could be local dir Jan 18 21:21:58 http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#devtool-getting-help Jan 18 21:22:21 see the srctree argument Jan 18 21:22:23 srctree? thanks Jan 18 21:24:31 appending -fPIC to both CFLAGS and CXXFLAGS has fixed the qt4-embedded build for me. Jan 18 21:27:08 yeah, devtool modify -x is your friend.. Jan 18 21:29:46 kergoth: FYI in the last release or so, -x is a no-op Jan 18 21:30:13 jmesmon: I wonder if we should add that into the qt4 recipes? Jan 18 21:30:14 ed2: thanks Jan 18 21:30:14 yeah, thanks for the reminder. force of habit. i still have to mess with previous release from time to time :) Jan 18 21:30:33 kergoth: any thoughts on this postinst package dependency problem thread? Jan 18 21:35:31 RP: just that i also don't like that variable name, but also don't have a better idea offhand :) Jan 18 21:35:37 so.. yeah. not very helpful Jan 18 21:35:44 kergoth: I'm not sure I like it either Jan 18 21:36:36 i feel like while the name accurately represents how it's used, it exposes details about the implementation. admittedly you sort of need to know that for this, but even so. Jan 18 21:36:57 perhaps keep this variable name under the hood, but expose a more pleasant one for the particular common case that'd be more intuitive to the user Jan 18 21:37:05 and just reference that in the other for now, unless the implementation has to change Jan 18 21:37:06 * kergoth shrugs Jan 18 21:56:03 hrmm... has anyone used linux-yocto-rt_4.4 on morty recently with arm? A bunch of standard meta data seems to be leaking into preempt-rt which fails when it tries to apply patches that won't apply to standard/preempt-rt/base Jan 18 21:57:45 bluelightning: it might: I'm not really sure what suddenly triggered it's need in my case, but it seems like it would be useful to have it not randomly break for folks. Only hazard is what happens to non-libraries in qt4-embedded that are built with -fPIC (I believe it also includes the qt4 tools) Jan 18 22:00:32 Another issue now: I'd like to build `perf`, which depends on `slang`, but it is failing due to trying to examine host paths (or at least bitbake believes it does) https://ptpb.pw/KWBh Jan 18 22:10:13 looks like adding `--with-x=no` to EXTRA_OECONF fixes that Jan 18 22:22:26 kergoth: I know what you mean. I don't want to rush it, equally, this will block rss Jan 18 22:22:33 kergoth: did you look at rss at all? Jan 18 23:56:30 zeddii: zeddii_home: do you know if the cd ${B} is necessary in kernel_do_deploy? Jan 19 00:03:03 what on earth is the proper way to invoke install to do a recursive install? is this even possible? i'm trying to copy all header files from ${S}/include to ${D}${includedir} Jan 19 00:03:30 ${S}/include has a whole bunch of subdirectories Jan 19 00:16:17 miceopede: its not. use cp. Jan 19 00:16:59 @rburton cp -R to the rescue...okay Jan 19 00:17:27 remember to fix owners though Jan 19 00:20:38 @rburton to who? Jan 19 00:21:29 root:root Jan 19 00:23:19 clsulliv: it was at one point. but the working directories and assumptions have changed over time. Jan 19 00:24:28 clsulliv: in the past tasks would cd to $B automatically before executing, now it doesn't change directory. when i removed the automatic cd I went around and generally made all paths absolute, or used [dirs] explicitly to set the working directory. Jan 19 00:24:40 @rburton thanks. Jan 19 00:24:57 clsulliv: so the ideal is cwd is irrelevant, use absolute paths. Jan 19 00:26:07 * zeddii_home nods Jan 19 00:26:53 * zeddii_home goes back to doing bird population calculations with his grade7-er Jan 19 00:56:19 rburton: zeddii_home: thanks. Thinking of doing a refactor of that function. If that end up being what I do I'll convert to absolute paths while I'm at it. Jan 19 01:19:45 you are a brave man :D Jan 19 01:46:48 Hi David Reyna! Jan 19 01:50:22 exit **** ENDING LOGGING AT Thu Jan 19 03:00:01 2017