**** BEGIN LOGGING AT Fri Feb 17 03:00:01 2017 Feb 17 03:02:12 modifying FILES isn't the fix, you'll need to figure out why its buildsystem is installing files to the wrong path Feb 17 03:07:31 kergoth: ok Feb 17 08:00:33 What's the trick again to get something installed for a DEPENDS when the thing that one wants is ASSUME_PROVIDED? Feb 17 08:00:49 Example: DEPENDS=bzip2-native for libbz2. Feb 17 08:01:17 bzip2-native is ASSUMED_PROVIDED and thus the DEPENDS doesn't actually provide libbz2. Feb 17 08:03:12 Hah, found it in cmake-native, with the exact same example: bzip2-replacement-native Feb 17 11:43:59 hello everybody. I'm working here with a Heterogeneous ARM Cortex™-A5, Cortex™-M4 System. On the A5 Processor runs Linux. I have for this plattform a bitbake openembedded toolchain (http://git.toradex.com/cgit/). All my recpies are compiled with the self compiled x86-arm compiler. But this compiler is for the arm a5 processor. Feb 17 11:44:28 But now I need to compile a bunch of c code and place it under /lib/firmware which is compiled with the arm-m4 architecutre Feb 17 11:44:35 How can I realize that? Feb 17 11:46:04 Inside the Kernel is a kernel module which is loading this compiled c code (under /lib/firmware) and writes this programm into the other processor Feb 17 11:46:25 Thats the reason why I need compiled arm-m4 code under an linux cortex-a5 plattform Feb 17 11:46:35 HyP3r: technically the compiler is the same, as they are both armv7. but the linux compiler targets gnueabi, whereas for the baremetal part you have no os. Feb 17 11:47:11 HyP3r: i'm relatively sure that you can beat the compiler into building for the m4 too with clever makefiles Feb 17 11:47:58 HyP3r: the other option is to inherently set up a distinct toolchain, basically introducing a third architecture Feb 17 11:49:26 LetoThe2nd: I was also thinking about a makefile which should be able to handle this. Feb 17 11:50:16 LetoThe2nd: but this c project for the co-processor (m4) is actually based on CMake and is using this compiler: gcc-arm-none-eabi-4_9-2015q3 Feb 17 11:50:20 HyP3r: you could look up the buld process for zephyr as suggested by jurob in poky-contrib. this beats OE to building zephyr for a desired board, which is basically doing a baremetal compile. so with some digging, what you need should be in there. Feb 17 11:50:21 arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 227977] Feb 17 11:50:44 HyP3r: if hte project is nailed to a specific compiler, you are doomed anyways. Feb 17 11:51:08 I don't think that this is a special compiler: https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q3-update Feb 17 11:51:20 http://developer.toradex.com/knowledge-base/freertos-on-the-cortex-m4-of-a-colibri-vf61 (take a look at the beginning of linux) Feb 17 11:51:48 then your only proper way is to rather treat it as an asset and compile externally, including it as a binary blob into your image. Feb 17 11:52:48 LetoThe2nd: so you would do it like that: foo.bb and the folder foo with thie freertos.elf including it. And inside the recpie, just copy the freertos file into the specific directory? Feb 17 11:52:57 LetoThe2nd: so no dynamic compilation, just static? Feb 17 11:53:22 HyP3r: thats the lame way, yes. including binary assets is properly documented by the yocto project. Feb 17 11:53:31 (AFAIK) Feb 17 11:54:39 LetoThe2nd: and what about to dynamically compile this specific compiler and then compile the c project with that compiler? Feb 17 11:55:53 HyP3r: thats what i mentioned above: "inherently set up a distinct toolchain" Feb 17 11:56:13 certainly should be doable and sounds interesting, but probably requires quite a bit of effort. Feb 17 11:56:33 LetoThe2nd: ok Feb 17 12:33:32 Hi all. (On jethro) how do i control in a recipe whether i gets placed in the SDK or not? I've got some recipes building libraries but they don't end up in the SDK Feb 17 12:35:53 Well to be even more precise. the actual libs do end up in the SDK however the headers don't Feb 17 12:54:47 ant_work, do they end up in the image? Feb 17 12:54:56 are you using -c populate_sdk ? Feb 17 13:32:53 Crofton|work: yea Feb 17 13:33:01 sorry i totally missed, that you where talking to me Feb 17 13:33:07 no worries Feb 17 13:33:24 I forgot to reply to you so no blinky Feb 17 13:35:44 well the headers don't end up in the image of course. Only the libs are installed so my binaries can use them Feb 17 13:36:04 however when dealing with an SDK i need the headers for compilation aswell Feb 17 13:49:40 that should happen in sdk Feb 17 15:54:25 pohly: https://autobuilder.yocto.io/builders/nightly-no-x11/builds/162/steps/BuildImages/logs/stdio :/ Feb 17 15:55:14 RP11: empty page for me? Feb 17 15:56:04 pohly: hmm. halstead needs to look at that Feb 17 15:56:57 pohly: http://pastebin.com/WNbyusLe Feb 17 15:57:32 oh such fun Feb 17 15:57:48 presumably the patch was correct and git "fixed" the line endings Feb 17 15:58:57 rburton: yes. I might even have mentioned that in my cover letter ;-} Feb 17 15:59:02 rburton: hmm, possible. Feb 17 15:59:08 pohly: ok, so my fault :/ Feb 17 16:00:06 Beware that "git am --keep-cr" must be used to import the ovmf patches Feb 17 16:00:06 correctly. Feb 17 16:00:16 pohly: right Feb 17 16:00:22 maybe i should add that to my applyotron script Feb 17 16:00:29 might as well kill that build Feb 17 16:03:03 pohly: sadly doesn't import with --keep-cr due to the mailing list encodings Feb 17 16:03:09 pohly: is there a branch somewhere? Feb 17 16:07:12 pohly, Can you run curl and let me know what response you get? Feb 17 16:07:15 pohly, curl -v 'https://autobuilder.yocto.io/builders/nightly-no-x11/builds/162/steps/BuildImages/logs/stdio' Feb 17 16:08:47 RP: https://github.com/pohly/openembedded-core commit e4b6ce68fb0676646a Feb 17 16:09:33 That's what I am currently using for the ELC demo. It's the unmodified v5 of the patch series applied on top of other pending patches. Feb 17 16:10:42 halstead: curl seems fine, it's just firefox which doesn't display anything. Feb 17 16:10:56 Chromium also works. Feb 17 16:14:13 pohly, That's interesting. I can load it with Firefox 51.0.1 on Fedora. Do you have an older version? Any interesting extensions? Let me know if you have any theories about what the issue could be. Feb 17 16:18:46 halstead: Iceweasel from Debian Stable, so probably older. No idea what's causing it. Feb 17 16:20:45 hello everyone Feb 17 16:20:48 pohly, Thanks for the info. I might be able to replicate now. Feb 17 16:21:07 is it possible to generate random MAC-address in runtime? Feb 17 16:21:10 It's 45.6.0 Feb 17 20:28:46 Has anything changed with BBMASK in morty Feb 17 20:29:30 I have a BBMASK that was working as expected in 2.1 and when I upgraded to Morty its pulling in the masked-out .bbapends again Feb 17 20:29:56 newer versions changed it to a space separated list of regexes, rather than a single regex Feb 17 20:31:28 BBMASK = "meta-freescale/dynamic-layers/qt4-layer/recipes-qt4/qt4/" Feb 17 20:32:27 And if I run "bitbake -e qt4-x11-free | grep ^BBMASK" I see that value, so I'm certain its not being overridden Feb 17 20:32:36 looks fine to me, should be working afaict Feb 17 20:35:24 Hrmm... even putting the exact filename in there fails to mask the bbapend Feb 17 20:50:59 i've made some progress with learning how to use libnl (netlink) version 3, but still need some additional help. I've sent a mail to their mailing list. I can use the cli sub lib to get mac and ip address, but using the non cli lib I can only get mac addr. I would like ot know how to get an ip addr for a given interface name. Here is what ive done so far. Any pointers is appreciated. Feb 17 20:51:04 https://gist.github.com/netskink/4f554ed6657954b17ab255ad5bc6d1f0 Feb 17 21:08:29 kergoth: It was a stupid misunderstanding. Someone had placed a BBMASK in a .bb file which apparently has no effect. They duplicated it in the local.conf and that was the instance that mattered. Feb 17 21:09:05 heh, that'd explain it Feb 17 21:09:11 where should BBMASK go then? Seems like more of a layers.conf thing Feb 17 21:09:40 generally you shouldn't set it at all :) but anywhere in the config metadata is legal Feb 17 21:09:56 bblayers.conf, local.conf, or the distro could be appropriate, depending Feb 17 21:10:56 unfortantely we have Qt patches that conflict with freescales Qt patches, although maybe I can just pull their Qt4 layer out via bblayers.conf... Feb 17 21:15:05 doesn't look like they provide any mechanism for that though :/ Feb 17 21:15:14 As always, thanks for the help Feb 17 21:29:46 RP, per our conversation yest -- I added FOOBAR to my package list, default ?= "" and then put this in my local.conf: Feb 17 21:29:50 # Basic test to see we are in pkglist Feb 17 21:29:50 #FOOBAR += " idontexist" Feb 17 21:29:50 # ARCH based tests Feb 17 21:29:50 FOOBAR_x86-64 += " idontexist-x64" Feb 17 21:29:50 FOOBAR_i586 += " idontexist-i5" Feb 17 21:29:50 FOOBAR_aarch64 += " idontexist-a6" Feb 17 21:29:52 FOOBAR_arm += " idontexist-arm" Feb 17 21:30:11 ...those are the TRANSLATED_TARGET_ARCH values according to bitbake -e Feb 17 21:30:26 i have a native recipe that installs files to ${S}/image/usr/sbin but never ends up in they sysroot's /usr/sbin. What could I be doing wrong? Feb 17 21:30:28 and yet only the "aarch64" one trips. Feb 17 21:30:47 (i've separate build dirs for each arch of course.) Feb 17 21:32:05 paulg: that makes no sense as I know _arm works Feb 17 21:33:28 well, the test as I've described it is trivial to re-implement. :) Feb 17 21:34:39 in our packagegroup, I added: Feb 17 21:34:43 +FOOBAR ?= "" Feb 17 21:34:45 paulg: http://pastebin.com/mL4jCpf2 Feb 17 21:35:00 ...and + ${FOOBAR} \ Feb 17 21:35:01 " Feb 17 21:35:12 paulg: my test seems to say everything works... Feb 17 21:36:16 I wonder if it is to do with locating it in the packagegroup... Feb 17 21:36:47 paulg: ah, packagegroups are allarch by default which would clear TARGET_ARCH Feb 17 21:37:00 let me try your simple test here to confirm there isn't a space time discontinuity Feb 17 21:37:15 oh, so my guess was right. Damn. Feb 17 21:37:34 ha... I never even thought about checking if he was talking about packagegroups.. d'oh! Feb 17 21:37:37 paulg: make the packagegroup not allarch Feb 17 21:37:45 and aarch64 prolly works 'cause it happens to also be in HOST_ARCH or some other OVERRIDE Feb 17 21:38:01 * paulg kicks fray in the shin Feb 17 21:38:21 :P Feb 17 21:39:18 * paulg goes in search of what makes pkgroups allarch Feb 17 21:40:17 paulg: set PACKAGE_ARCH = "${TUNE_PKGARCH}" after the inherit packagegroup Feb 17 21:40:45 * RP thinks that is right but its from memory Feb 17 21:43:23 RP, thanks -- even if it isn't right, it gives me something to grep for. Feb 17 21:53:39 RP: hi there in West Coast Feb 17 21:55:25 ant_home: hi Feb 17 22:07:35 lets say I was feeling generous and wanted to patch the docs to indicate overrides may not work in packagegroups... Feb 17 22:07:46 what was the original reasoning for that decision? Feb 17 22:09:50 since it violates the principle of least surprise, it probably warrants a note if there isn't one somewhere already. Feb 17 22:14:39 * paulg rotfl Feb 17 22:14:52 RP, apparently what you suggested is illegal. Feb 17 22:14:55 ERROR: /home/paul/poky/meta-overc/meta-cube/recipes-core/packagegroups/packagegroup-builder.bb: Please ensure recipe /home/paul/poky/meta-overc/meta-cube/recipes-core/packagegroups/packagegroup-builder.bb sets PACKAGE_ARCH before inherit packagegroup Feb 17 22:23:06 # By default, packagegroup packages do not depend on a certain architecture. Feb 17 22:23:07 # Only if dependencies are modified by MACHINE_FEATURES, packages Feb 17 22:23:07 # need to be set to MACHINE_ARCH after inheriting packagegroup.bbclass Feb 17 22:23:07 PACKAGE_ARCH ?= "all" Feb 17 22:23:27 (this is 2.2's packafgegroup.bbclass).. so as long as PACKAGE_ARCH is set BEFORE the inherit packagegroup it -should- work? Feb 17 22:24:05 (you need to make sure that the recipe doesn't also inherit allarch) Feb 17 22:24:41 * paulg is more confused Feb 17 22:24:51 fray, but RP said set it _after_ Feb 17 22:25:10 yes.. try before.. Feb 17 22:25:21 ok... Feb 17 22:25:26 * paulg has NFI what he's doing Feb 17 22:26:40 what I was understanding (which may be entirely wrong) was it was the inherit packagegroup that clobbered it, hence the need for it to be _after_ Feb 17 22:27:06 bitbake -e should tell you exactly what its value is and what set it when.. Feb 17 22:27:10 yes.. the PACKAGE_ARCH ?= "all" in the packagegroup.bbclass says "only set this to all if not already set" Feb 17 22:27:21 ah. whee. Feb 17 22:27:21 so you want to set PACKAGE_ARCH = "something else" and it'll magically work.. Feb 17 22:27:40 ${MACHINE} if it's BSP specific.. or ${TUNE_ARCH} (or whateevr RP said) if it's generic, but architecture specific Feb 17 22:27:41 my comment about this violating the principle of least surprise still stands. Feb 17 22:28:09 "These variables cause this magic, except in these special files." Feb 17 22:28:31 I suspect in the past things were PACKAGE_ARCH = "all", so you HAD to set it after.. Feb 17 22:28:37 but I don't remember for sure Feb 17 22:30:14 my comment about this violating the principle of least surprise still stands. :) Feb 17 22:30:24 * paulg tests Feb 17 22:31:25 there's no good way to make the recipes package independent without modifying the variables used in overrides. if the recipe is arch independent, we dont' *want* target arch dependent overrides applying Feb 17 22:31:33 s/package indep/arch indep/ Feb 17 22:32:07 what would be better behavior, in your opinion? I'm not seeing an alternative Feb 17 22:33:14 kergoth, I'm not arguing the behaviour -- I'm just saying for someone who doesn't know the innards as well as you, fray or RP, it simply isn't expected. Feb 17 22:33:26 and hence the need for a note in the OVERRIDES section. Feb 17 22:33:32 (doc section) Feb 17 22:39:38 In the past I've opened a bugzilla on the docs with what I'd like clarified and Scott has been able to do it pretty quickly.. Feb 17 22:40:14 just make the note like you have above. In the discussion of the overrides, it would be nice to indicate that when a package is set to allarch that some of the override values (target specific) are intentionally cleared. Feb 17 22:40:33 fray, RP -- good news ; with the magic line _before_ the inherit, it seems to work; I added fake packages (FAKE NEWS!) called grub-32 and grub-64 respectively and got the errors of them being not found when using those arch Feb 17 22:40:53 thanks ; I'd never have nutted that out myself in a month of Sundays. Feb 17 22:42:12 first step, when using OVERRIDES, use bitbake -e to see what OVERRIDES is actually set to :) Feb 17 22:42:35 did that. :) Feb 17 22:42:47 eventually ; maybe not as 1st step. Feb 17 22:42:56 that tells you that package arch isn't what you'd expect, then bitgbake -e on that would have shown where and how it got set to what it is Feb 17 22:42:59 * kergoth nods Feb 17 22:43:29 now that you mention it... Feb 17 22:43:58 another way I found pkgroups special, is that any vars declared within them never appear in bitbake -e Feb 17 22:44:14 ? Feb 17 22:44:49 that's not the case.. Feb 17 22:44:53 well, when I 1st started fighting with this, I wanted to inspect what a package list from a packagegroup was set to Feb 17 22:45:00 but it wasn't there. Feb 17 22:45:06 as if it didn't exist Feb 17 22:46:23 anyway. I've a fix now, so I'm happy. Feb 17 22:46:31 bitbake has a tendency to not always put its errors on stderr, which means quite often when doing a bitbake -e recipe | grep on a recipe that has an expansion or parse failure would just show no output in your grep, and you wouldn't realize it didn't actually output *anything at all* in bitbake -e Feb 17 22:46:43 so when my grep is showing nothing, my first step is to drop the grep and directly examine the output Feb 17 22:47:53 ya, did that. :) Feb 17 22:48:18 lets say you have RDEPENDS_packagegroup-builder-debug Feb 17 22:48:20 well, i just did a bitbake -e on a packagegroup and its variables are showing up just fine Feb 17 22:48:26 › bitbake -e packagegroup-core-sdk|grep \^SUMMARY Feb 17 22:48:26 SUMMARY_packagegroup-core-sdk-doc="Software development tools - Documentation files" Feb 17 22:48:26 SUMMARY="Software development tools" Feb 17 22:48:27 and you want to see if it contains gdb. Feb 17 22:48:29 so don't know what to tell you Feb 17 22:48:37 you'll never see that variable in bitbake -e Feb 17 22:48:39 you're falsely taking a specific failure and equating it with a general problem Feb 17 22:49:35 I'll do some more local testing and see if I can refine what I was seeing earlier ; it was a while ago and so perhaps I'm not recalling correctly. Feb 17 22:51:34 obviously there could certainly be a bug, but packagegroups aren't special in the way you're saying, so it's more likely a specific bug rather than a general one :) by all means open an issue if you can repro it Feb 17 22:51:41 $ bitbake -e packagegroup-base | grep '^RDEPENDS_' | head -n 1 Feb 17 22:51:41 RDEPENDS_packagegroup-base-3g=" ofono" Feb 17 22:56:05 ok, so let me rewind to that when I get a chance and poke around a bit ; it sounds like it should work as expected. Feb 17 23:00:51 anyway, again -- do appreciate the help from folks. Feb 18 00:14:42 Hello, someone knows how I can use 2 versions of GCC on the same build? I want to use the versions supported by my board manufacturer to build the system, but I want to use a newer version to build an application of my own Feb 18 00:22:40 WARNING: sysklogd-1.5.1-r0 do_populate_lic: Could not copy license file /home/paul/poky/build/tmp/work/core2-64-overc-linux/sysklogd/1.5.1-r0/sysklogd-1.5.1/klogd.c to /home/paul/poky/build/tmp/work/core2-64-overc-linux/sysklogd/1.5.1-r0/license-destdir/sysklogd/klogd.c: 'utf-8' codec can't decode byte 0xf6 in position 1629: invalid start byte Feb 18 00:22:50 ...don't recall ever seeing that before. **** ENDING LOGGING AT Sat Feb 18 03:00:01 2017