**** BEGIN LOGGING AT Mon Jan 09 03:00:00 2017 Jan 09 09:26:25 Hi, I'm trying to build an image using toaster (I'm following the toaster documentation), I've been able to start toaster, set a new layer, but when I try to add some recipes they just got on queue but do not start and the log gives "DEBUG runbuilds: No build env". I've set the enviroment wit the source oe-init-build-env command as the totorial says, any clues? Jan 09 09:34:22 hi Jan 09 09:39:38 how do I force bitbake to reevaluate layer priorities? Jan 09 09:40:09 it seems it uses some cached value and does not realize changed priorities :-/ Jan 09 10:23:27 Hi everybody (again). I'm still facing problems with an embedded initramfs in a fitImage (Using zImage was working fine!). The problem is that the initramfs isn't loaded during boot. I'm using "CONFIG_INITRAMFS_SOURCE="./initramfs/config.cfg"" in the kernel configuration as initramfs source. Does anybody of you have any clue what the problem could be? Thanks in advance! Jan 09 10:41:25 morning all Jan 09 10:43:23 morning ed2 Jan 09 10:54:07 rburton: I have 4 pending patches under review. Should I resend them to the ml or just show here that you can pick them up next time? Jan 09 10:55:22 ed2: have a look at ross/mut2, i've just pushed it. Jan 09 11:00:21 rburton: thank you. Can you pick up this one: http://lists.openembedded.org/pipermail/openembedded-core/2016-December/130505.html Jan 09 11:01:16 done Jan 09 11:07:14 ed2: rburton: do you think this one could be picked up as well? http://lists.openembedded.org/pipermail/openembedded-core/2016-December/130366.html Jan 09 11:10:33 thats already in mut2 Jan 09 11:10:52 in fact thats probably what i thought was already erged Jan 09 11:10:59 rburton: thank you Jan 09 14:05:12 hi! Can someone help me with this error plz?:Computing transaction...error: Can't install libcurl4-7.47.1-r0@cortexa7hf_neon_vfpv4: no package provides libgnutls.so.30(GNUTLS_3_4) Jan 09 14:05:45 looks like libnutls is missing, but cant find it on https://layers.openembedded.org/layerindex/branch/master/recipes/?q=libgnutls Jan 09 14:09:11 speedy, It's just called gnutls. ie. without the 'lib' prefix. Jan 09 14:09:28 not if you have the renaming class enabled it isn't Jan 09 14:09:31 which is on by default Jan 09 14:11:02 The package may be named libgnutls, the recipe is named gnutls. Jan 09 14:12:50 gnutls is part of oe-core and it must have been present for curl to link to it Jan 09 14:16:59 oh, thank you :) now i get many red lines, error is now: do_rootfs: libgnutls30 not found in the base feeds Jan 09 14:17:36 i'd do bitbake curl to check that it doesn't need a rebuild Jan 09 14:17:44 i have openembedded-core layer for gnutls Jan 09 14:17:56 i ll try Jan 09 14:33:20 hm i run bitbake curl, but how do i know if i have to rebuild? Jan 09 15:21:42 i do love touching the flex recipe and how it causes gcc to rebuild. Jan 09 15:27:47 Hello, is there a channel specifically focused on the Intel Edison? Jan 09 15:32:25 filter() in python 3.x returns a 'filter object', instead of a list grrrr Jan 09 15:36:16 "list like" Jan 09 15:37:04 rburton: apparently filter, map and especially reduce are all semi-deprecated in favor of list comprehension Jan 09 15:37:16 oh didn't know that Jan 09 15:38:07 rburton: https://docs.python.org/3.0/whatsnew/3.0.html#views-and-iterators-instead-of-lists Jan 09 15:38:39 i preferred comprehension anyway but now i have a good reason to Jan 09 15:38:40 "Removed reduce(). Use functools.reduce() if you really need it; however, 99 percent of the time an explicit for loop is more readable. Removed reload(). Use imp.reload()." Jan 09 15:39:10 rburton: yeah, I basically just wanted to show off my lisp-fu :D Jan 09 15:40:22 lol Jan 09 15:57:30 deva & rburton ty for your help, i rebuild complete new with gnutils and works like a charm now :) Jan 09 16:04:00 Hi there. I’m having troubles building the libgfortran_6.2.bb recipe in morty Jan 09 16:04:00 I’ve added to my conf/local.conf: Jan 09 16:04:02 FORTRAN_forcevariable = ",fortran" Jan 09 16:04:03 RUNTIMETARGET_append_pn-gcc-runtime = " libquadmath" Jan 09 16:04:04 but I get the error: Jan 09 16:04:05 fatal error: backtrace-supported.h: No such file or directory Jan 09 16:12:24 carlesfernandez: you need to grep the source code of libgfortran for mentions of that file, and look for clues of why is it needed and why is it missing Jan 09 16:12:52 ../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libgfortran/runtime/backtrace.c:37:33: Jan 09 16:12:52 fatal error: back$ Jan 09 16:12:53 #include "backtrace-supported.h" Jan 09 16:13:36 carlesfernandez: is this include conditional? is backtrace-supported.h present in the source tree somewhere? Jan 09 16:13:59 basically you need to read the source code :) Jan 09 16:14:26 the file is actually in tmp-glibc/work/armv7ahf-neon-oe-linux-gnueabi/libgfortran/6.2.0-r0/gcc-6.2.0/build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi/libbacktrace/backtrace-supported.h Jan 09 16:14:38 ok, I’ll work on it :-) Jan 09 16:17:16 carlesfernandez: then probably the include directories are set up incorrectly, excluding the one which contains the file Jan 09 16:19:16 it seems that the header get buried at tmp-glibc/sysroots/x86_64-linux/usr/include/gcc-build-internal-x86_64-oesdk-linux/libbacktrace/backtrace-supported.h and then libgfrotran is unable to find it Jan 09 16:19:51 carlesfernandez: depends on where libgfortran expects to find it Jan 09 16:42:25 can't FORTRAN just die? Jan 09 16:43:53 Crofton|work: the academic people likes fortran... Jan 09 16:43:55 haha Jan 09 16:44:20 I suspect they are all messing with blas/lapack derived things Jan 09 16:44:31 Fortran has a lot of serious math libraries which are super-optimized Jan 09 16:44:52 or at least that was the case when I was 15 years younger :) Jan 09 16:45:03 but what I wonder is how well they are optimized for current archs/compilers Jan 09 16:45:23 lets ask carlesfernandez why on earth he wants to use fortran! Jan 09 16:45:49 why oh why has nobody written a meta-fortran yet Jan 09 16:45:50 be nice to him Jan 09 16:45:52 :-) Jan 09 16:46:07 I’m working on a software-defined GNSS receiver Jan 09 16:46:24 but what drives the fortran? Jan 09 16:46:24 gotran is optional, but useful when computing position Jan 09 16:46:40 gotran? Jan 09 16:46:55 sorry, gfortran Jan 09 16:46:55 hello everyone.. i need to add this library to my recipe https://github.com/vsergeev/c-periphery Jan 09 16:47:01 anyone could help me? Jan 09 16:47:09 had a horrible moment where go+fortran was a thing then Jan 09 16:47:19 just wanted to doble check that is what you meant Jan 09 16:47:24 we use (optionally) fotran through the Armadillo library, for linear algebra Jan 09 16:47:37 ithis is useful when computing position Jan 09 16:47:42 so Armadillo is the library that drives the need? Jan 09 16:47:45 yes Jan 09 16:48:28 but I repeat, it is optional. It can wrap blas and lapack nicely Jan 09 16:49:22 it would be needed for big matrices; in our case (a GPS receiver), Armadillo without fortran can do the job Jan 09 16:49:24 not the first time I've heard of it though Jan 09 16:50:09 bernarrrrrrrrrrr: 'devtool add' will help you Jan 09 16:50:30 Crofton|work: given your interest in software based electromagnetic wobbles i'm a bit surprised you don't have fortran working already :) Jan 09 16:50:49 I bash my head at these things occasionally Jan 09 16:51:19 I have a recipe for Armadillo here: https://github.com/carlesfernandez/meta-gnss-sdr/blob/master/recipes-core/armadillo/armadillo_7.600.2.bb Jan 09 16:51:57 kanavin: is that a bitbake option? Jan 09 16:53:28 bernarrrrrrrrrrr: is a development tool for oe, for example support creating, upgrading recipes, also have other functionalities 'devtool -h' Jan 09 16:53:52 im reading some docs.. seems to be what i need Jan 09 16:53:55 thanks guys!! Jan 09 16:58:16 carlesfernandez, how well does it work? Jan 09 16:58:34 is it a problem you do not have lapack, blas etc? Jan 09 16:59:08 it would be for computing eigenvaules Jan 09 16:59:35 but for simple vector and matrix multiplication, you can live without blas and lapack Jan 09 17:00:35 seems like we should add that to meta-oe to get more exposure Jan 09 17:03:37 yes, it would be nice to have it working Jan 09 17:07:10 do you mind if I go ahad and submit it sometime? Jan 09 17:10:16 no, please go ahead Jan 09 17:28:46 oh, I’ve just realize that libgfortran is working in krogoth (but not in jetrho or morty) Jan 09 18:01:31 Is the Morty branch of meta-openembedded completely working? I'm pulling in the meta-oe layer and many of the recipes report "Exception: TypeError: getVar() missing 1 required positional argument: 'expand'" Is there something missing? Jan 09 18:03:19 it should be working, are you trying to use it with correct bitbake version? Jan 09 18:03:32 yeah, sounds like mismatched layers. same branches in all Jan 09 18:03:44 and right bitbake version for that branch (there's a wiki page) Jan 09 18:03:56 OT, but <3 git-tbdiff Jan 09 18:04:13 skrawn: you need 1.32 bitbake Jan 09 18:04:25 understood. I am using 1.30 Jan 09 18:04:56 Does https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=ld/ldfile.c;h=0943bb2dfa0fcc40565133773e86f72cf04d19f8;hb=HEAD#l339 *line 339) make sense to anyone? Why would you prepend the sysroot to an already sysrooted path? Jan 09 18:07:35 actually, I am using 1.32.0 Jan 09 18:13:16 skrawn: then maybe you're using meta-openembedded from master not morty branch Jan 09 18:13:37 JaMa: positive I'm on the Morty branch Jan 09 18:14:58 it there something special that needs to happen with the bblayers.conf file? I have ${TOPDIR}/../meta-openembedded/meta-oe appended to BBLAYERS Jan 09 18:15:28 nothing which would influence getVar() syntax Jan 09 18:15:43 what bitbake and meta-oe revisions do you have? Jan 09 18:18:06 I'm unsure how to check revision...but I did a fresh checkout of poky today, switched to the morty branch, did a fresh checkout of meta-oe and switched to morty there too Jan 09 18:21:16 I belive that you have this commit in meta-oe: http://git.openembedded.org/meta-openembedded/commit/?id=efd3696e70a6603f1a45faa4a172433514f0a487 which is only in master branch Jan 09 18:24:59 Hello all. I'm having trouble getting through package_qa without a pile of warnings about locations for -dbg, -dev, etc. I've collected all lib*.so in FILES_${PN}-dev, and all lib*.so.* into FILES_${PN}, for example, but packaging ${PN} causes QA to complain about those versioned libraries being present. Are they not supposed to be included in the main package? Jan 09 18:35:05 @eengie Take a look at https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries. Jan 09 18:35:36 I've been reading that one over trying to work with it for about an hour now... I'm not sure what I'm doing wrong in it. Jan 09 18:36:20 I think the bulk of my problem is that my libdir is offset into the filesystem (for familiarity for my users) Jan 09 18:36:50 So it's up in /usr/local/core/lib Jan 09 18:37:17 set libdir=, then fix any recipes that get qa warnings by making them obey libdir, not by changing FILES Jan 09 18:38:29 If I set libdir, wouldn't that impact all recipes? Jan 09 18:39:57 yes.. i interpreted 'my libdir' as being the person maintaining the distro or doing the building, not one random recipe Jan 09 18:40:07 that said, you can set libdir in the recipe, rather than the config Jan 09 18:40:10 have you tested that? Jan 09 18:41:30 No, not yet. Jan 09 18:41:57 JaMa: that was it. I did a clone of meta-openembedded, then a checkout of the morty branch instead of checking out the morty branch from the beginning. Thank you! Jan 09 18:42:28 I was being a bit skittish about messing with that one since I found it at the top level of the build environment. (I realize changing it in my recipe doesn't impact it for other recipes, but still...just felt like it might be a wrong path) Jan 09 18:43:47 Actually, wont' messing with libdir in my recipe affect its ability to link against things in the top-level defined libdir? Jan 09 18:43:51 won't* Jan 09 18:46:59 Yeah...setting libdir in this recipe does impact its ability to link against recipes elsewhere, so that's a no-go. Jan 09 18:46:59 should not, actually. we don't pass -L${libdir} to the toolchain, we pass —sysroot= and let it search its usual library search paths relative to there Jan 09 18:47:15 sounds like your recipe isn'tj obeying our CC/CFLAGS/LDFLAGS correctly, in that case Jan 09 18:48:11 Doesn't look like we're touching any of those. Only CXXFLAGS for -fpermissive. Jan 09 18:50:04 I was mainly just trying to get away from insane-skipping loads of files and it was suggested updating the various FILES variables to have our offset would be a reasonable way to go. Jan 09 19:12:53 why skip ? package them correctly, and you can use wildcards Jan 09 19:15:12 khem: that's what I was trying to do, however QA was complaining no matter where I placed versioned shared libraries vs. their links (I have versioned ones going to ${PN} and unversioned headed to ${PN}-dev, per the link mentioned by kergoth). The issue seemed to be that it didn't like the whole ${SOME_OFFSET}/lib/lib*.so.*, for example. Jan 09 19:16:02 (trying to do, i.e., get away from throwing the kitchen sink of insane skips at the recipes, instead just packaging things up with FILES_ variables.) Jan 09 19:27:18 hi! whats the easiest way to change the python3 recipe to install python3.4 instead of python3.5? Jan 09 19:32:36 or even better: why is python3-pip recipe on use (pip3 install ) failing with No module named 'enum'? The python-enum34 is not compatible with the python3 (3.5) recipe :/ i guess its for python2 Jan 09 19:34:26 oe-core/meta/recipes-devtools/python/python-3.5-manifest.inc:92:SUMMARY_${PN}-enum="Python support for enumerations" Jan 09 19:34:31 install the python3-enum recipe Jan 09 19:34:34 s/recipe/package/ Jan 09 19:35:10 sounds like hte manifest needs to add ${PN}-enum to RDEPENDS_${PN}-pip Jan 09 19:40:08 cool, the new tslib maintainer released 1.3: tslib-1.3 is fully backwards compatible and adds multitouch support (protocol type A and B) Jan 09 19:41:32 its working! how did u find this? i dont even know where to start searching for those stuff :/ Jan 09 19:41:46 i grepped oe-core's python directory for enum. Jan 09 19:41:59 git grep python.\*enum would do as well Jan 09 19:42:05 grep is your friend Jan 09 19:42:24 thank you very much :) Jan 09 19:42:31 np Jan 09 19:42:51 might want to report the missing dep as a bug in the yocto bugzilla, clearly if pip needs enum but doesn't depend on it, that's a bug Jan 09 20:27:26 khem: Does https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=ld/ldfile.c;h=0943bb2dfa0fcc40565133773e86f72cf04d19f8;hb=HEAD#l339 line 339 make sense to you? Why would you prepend the sysroot to an already sysrooted path? Jan 09 20:34:30 the absolute path may not be the sysroot.. Jan 09 20:34:47 the sysrooted is the -I and -L and --sysroot information passed t the utility itself.. Jan 09 20:35:04 while the filename may be absolute ('somewhere' on the disk) or relative to the CWD.. Jan 09 20:35:08 RP: its actually doing it if we have sysroot enabled Jan 09 20:36:12 ya.. so if someone does something like ld --sysroot=/foo/bar /foo/bar/myfile.o at some point it's going to look at '/foo/bar/myfile.o' and if not found in /foo/bar/foo/bar/myfile.o (by adding the sysroot) Jan 09 20:36:26 (at least that is my expectation looking at that chunk of code) Jan 09 20:43:43 fray: that isn't what the code is doing :( Jan 09 20:43:52 fray: at least in my test case :/ Jan 09 20:45:21 fray: ld_sysroot is the sysroot passed in with --with-sysroot, sysrooted is set if the path in question has had the sysroot prepended afaict Jan 09 20:48:24 fray, khem: I think there is a missing ! in there but it would see odd that its been missed by other Jan 09 20:48:26 others Jan 09 20:52:13 RP: actually sysroot is coming in as a flag Jan 09 21:00:28 and its like when we have -I/usr/include but it gets hoisted to /usr/include with --sysroot enabled Jan 09 21:00:53 or -isysroot specified path Jan 09 21:04:24 any ETA on Bruce's 4.9 kernel recipes getting merged? Jan 09 21:09:57 clsulliv: the queue is growing: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zedd/kernel Jan 09 21:18:01 zeddii_home: yup, working on 4.1/4.4/4.8 updates now Jan 09 21:18:09 suppose I can work off your branch for 4.9 Jan 09 21:19:07 oh nice, I see -rt patches for 4.9 as well Jan 09 22:16:56 RP: After playing around with the container images, I think initially all the container image type will do is pick .tar.bz2 as the fstype, and turn off the bootstrap code. There will be "extra" stuff in the image, but we can always at that point document that "PACKAGE_INSTALL" can be used in a recipe to ONLY install what is listed. So that way we preserve the current IMAGE_INSTALL behavior for whomever wants Jan 09 22:16:58 it. Jan 09 22:17:25 rewitt: at a first glance that sounds reasonable Jan 09 22:17:40 RP: I thought about by default yanking out everything, but since PACKAGE_INSTALL is a knob that will do that, I'll err for flexibility Jan 09 22:18:42 RP: It also becomes hard to yank it out anyway due to the way packagegroup-base-files is created with variables that are at the conf level and thus unchangable at the recipe datastore level Jan 09 22:19:47 rewitt: yes, that would make it tricky... Jan 09 22:36:36 RP: You don't happen to know why there is an "export PACKAGE_INSTALL = ....." in image.bbclass do you? I don't think I see any tasks that use PACKAGE_INSTALL, but if they did, that means the "inherit foo.bbclass" needs to come before the export, since that expands the variables Jan 09 22:37:40 RP: I mean tasks that use PACKAGE_INSTALL without calling d.getVar() or something similar Jan 09 22:38:38 rewitt: the export only has any effect at execution time, not parse time Jan 09 22:41:01 RP: Ok cool, so it shouldn't matter Jan 09 22:41:38 does sound pretty pointless, but it wouldn't be the only unnecessary export we have :) Jan 09 22:42:45 kergoth: I *may* try removing it at some point, but too scared to right now :) Jan 09 22:42:53 :) Jan 09 22:44:06 I started working on minimizing exports, but had focused on bitbake.conf, classes were to be visited later Jan 09 22:59:51 Wow, just turning off ROOTFS_BOOTSTRAP_INSTALL(run-postinsts) takes the image down to 663K from 2.6M :) Jan 09 23:00:20 the rest is libc/locales and package manager kruft leftover Jan 09 23:02:02 Is there any form that we support static linking of binaries? I know it's not supported with libc, but for instance with musl can we say "statically link everything"? Jan 09 23:21:00 rewitt: khem might know about musl Jan 09 23:21:13 rewitt: we stopped building static libs in the end Jan 09 23:42:07 rewitt: oe will happily build static libraries and link statically, it's just that poky disables static libraries for build speed Jan 09 23:42:49 the no-static-libs include file shows how you'd implement "statically link everything" Jan 09 23:51:26 where does the .config for linux-yocto come from? Seems like inheriting from linux-yocto.inc isn't enough to pick it up. Jan 10 00:07:56 rburton, RP1: Ok thanks, I'm just thinking farther ahead because my guess is the question will come up Jan 10 00:41:54 RP1: Hi! any chance this could be backported to Morty / 2.2 please ? http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-devtools/binutils/binutils-2.27.inc?id=764a7801361c6f57ff366be641b1410e7b36f56b Jan 10 00:42:07 it fixes a problem when compiling ie. ATF on Aarch64 Jan 10 00:42:11 bluelightning: ^ Jan 10 00:42:35 meta-xilinx (morty branch) builds with that backported Jan 10 00:43:06 Marex: looks like it should be fine at a glance, armpit is the one to talk to though Jan 10 00:43:18 I could of course submit it, but would that go to OE-core or poky ? Jan 10 00:43:24 bluelightning: ah, thanks :) Jan 10 00:43:45 I'm not entirely sure how it works around here when submitting backports Jan 10 00:44:44 Marex: It was intended to be backported to morty, https://patchwork.openembedded.org/patch/134158/ Jan 10 00:45:54 nrossi: ah cool :-) so why is it superseded ? Jan 10 00:46:10 Marex: there was a v2, so that it applied to master cleanly Jan 10 00:46:26 Marex: OE-Core since it's under meta Jan 10 00:46:37 this is also useful for these kinds of situations: https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Jan 10 00:46:59 bluelightning: oooh, thank you :-) Jan 10 00:48:53 merged to my stable Jan 10 00:48:59 nrossi: aha ! thanks :-) Jan 10 00:49:04 s/stable/stagging Jan 10 00:53:01 * armpit had no idea one needs Alcohol, Tobacco, an Firearms to work on Aarch64 Jan 10 00:56:02 armpit: what ? :-) Jan 10 00:56:58 ATF on Aarch64. ATF in the US is a governament agency for Alcohol, Tobacco, an Firearms Jan 10 00:57:43 * armpit dinner Jan 10 01:05:03 armpit: ah, hehe :) **** ENDING LOGGING AT Tue Jan 10 03:00:01 2017