**** BEGIN LOGGING AT Tue Jan 26 02:59:58 2016
Jan 26 03:34:36 <smurray> It looks like https://www.yoctoproject.org/documentation/active is out of date, should be pointing at 1.8.1, 1.7.3, 1.6.3 not 1.7.2, 1.6.3, 1.5.4...
Jan 26 07:42:31 <frsc> Has someone got a solution for this: https://community.freescale.com/thread/382912 ?
Jan 26 07:43:13 <frsc> Im experiencing the same error when building linux-fslx-mx6 within Yocto
Jan 26 08:29:26 <mckoan> frsc: what did you do between git clone and make imx_v7_defconfig ?
Jan 26 08:34:26 <mckoan> frsc: I added a comment to that post thread
Jan 26 08:36:37 <frsc> mckoan: I'm not building for mx7d, but for mx6s and I'm using 3.14-1.1.x-mx6 branch from linux-fslc. Also I'm using the Yocto-recipes to build.
Jan 26 08:44:28 <nerdboy> did anyone submit an snmp patch for jethro yet?
Jan 26 08:46:50 <mckoan> frsc: it works
Jan 26 08:54:54 <nerdboy> yes/no/maybe?
Jan 26 08:56:40 <nerdboy> that's right, the patch file was there but it was never applied in jethro
Jan 26 08:58:35 * nerdboy has a slightly more flexible/comprehensive patch for jethro
Jan 26 08:59:40 <yann|work> nerdboy: with http://pastebin.com/rNVBHdEN the exact error is http://pastebin.com/MSHSGqh1
Jan 26 09:02:17 <nerdboy> apparently you're doing it wrong
Jan 26 09:02:36 * nerdboy is nothing if not observant and helpful
Jan 26 09:03:03 <nerdboy> i had to play with it a bit to get the rpi tuning i wanted
Jan 26 09:03:53 <nerdboy> all i can say is trace the includes and find the right place to modify it
Jan 26 09:04:36 * nerdboy does a lot of custom flags and there are lots of combinations that work
Jan 26 09:05:23 <nerdboy> iirc it should default to softfp with the tuning it thinks is correct for your machine
Jan 26 09:05:59 <nerdboy> it depends on bsp tune config, rpi started out kinda basic
Jan 26 09:06:56 <nerdboy> it looks like you have an extra vfp- in there
Jan 26 09:07:44 <nerdboy> hard to tell sometimes with all the variable substitution and include files
Jan 26 09:08:33 * nerdboy still tired from 4 days of scale...
Jan 26 09:14:44 <yann|work> well, I did trace the includes to find something roughly comparable to use as a base, but will apparently have to dig more to find out which variable is botched:)
Jan 26 09:19:24 <yann|work> well, in fact the H3 supports vfpv4, so the but won't impact me anyway, I'll just for hunt it later :)
Jan 26 09:21:33 <CTtpollard> yann|work: renesas h3?
Jan 26 09:22:39 <yann|work> no, allwinner h3
Jan 26 09:24:45 <CTtpollard> ah, cool
Jan 26 09:30:25 <frsc> mckoan: it doesn't work for me. I exactly followed your steps from the nxp thread, also using the jethro toolchain...
Jan 26 09:34:12 <aratiu> I'm getting this error while building gcc-4.9.2 "libgcc/gthr.h:148:26: fatal error: gthr-default.h: No such file or directory"
Jan 26 09:34:32 <aratiu> if I symlink the gthr-posix.h to gthr-default.h the build works
Jan 26 09:34:52 <aratiu> somehow the ghtr-default.h is not generated automatically
Jan 26 09:34:54 <aratiu> any ideas?
Jan 26 10:20:58 <mckoan> frsc: please pastebin your output of : arm-poky-linux-gnueabi-gcc -v
Jan 26 10:23:22 <frsc> mckoan: http://paste.ubuntu.com/14670927/
Jan 26 10:30:22 <mckoan> frsc: shoud be Target: arm-poky-linux-gnueabi
Jan 26 10:30:41 <mckoan> frsc: you have Target: arm-exceet-linux-gnueabi
Jan 26 10:31:14 <frsc> mckoan: I use a custom distro config "exceet", but it's not much different from poky
Jan 26 10:32:05 <mckoan> frsc: looks like that is the only difference, thus the cause
Jan 26 10:32:49 <frsc> mckoan: might be, I'll investigate. Thanks nevertheless!
Jan 26 11:54:01 <b00^wk2> are recipes written in Python in Yocto?
Jan 26 11:54:27 <b00^wk2> BitBake parses basically Python scripts, or python like scripts ..?
Jan 26 11:58:08 <jku> b00^wk2: recipes are collection of metadata with its own syntax. they can contain both python and shell functions
Jan 26 12:00:10 <b00^wk2> jku, ok  thanks
Jan 26 12:01:33 <b00^wk2> err, what's the difference between a metadata and a recipe .. ?
Jan 26 12:01:51 <b00^wk2> if i'm writing say a config to how to customize my u-boot, is that a recipe?
Jan 26 12:01:57 <b00^wk2> and can that recipe contain python
Jan 26 12:21:59 <b00^wk2> can i have with Yocto to automatically generate say 2 different hw system images?
Jan 26 12:22:18 <b00^wk2> so that, i don't go first, generate say qemu image, genreate now x86 image, generate arm
Jan 26 12:22:36 <b00^wk2> if i know that i always need 3 images for different boards, can i put it into my yocto config ?
Jan 26 12:22:58 <b00^wk2> and can it do all in same yocto root directory ..
Jan 26 12:24:18 <CTtpollard> b00^wk2: could you not just 3 bitbake processes, and have them share download dir sstate cache etc
Jan 26 12:24:50 <b00^wk2> i hope so
Jan 26 12:25:04 <b00^wk2> or asking if one can
Jan 26 12:25:05 <b00^wk2> :)
Jan 26 12:25:35 <CTtpollard> you can do that
Jan 26 12:28:13 <b00^wk2> CTtpollard, but you have to specially configure this, its not automatically supported in some magic 'default' setup with  > 1 hw target ?
Jan 26 12:28:20 <b00^wk2> another question :
Jan 26 12:28:26 <b00^wk2> Also, can you use distributed building with Yocto?  distcc
Jan 26 12:29:16 <rburton> it's currently hardcoded that MACHINE is set to one value in each bitbake run
Jan 26 12:29:27 <rburton> so if you want to build for multiple machines, run bitbake more than once
Jan 26 12:30:22 <b00^wk2> rburton, but you can do what CTtpollard suggests, no ?
Jan 26 12:30:32 <b00^wk2> (3 instances of bitbake, with shared stuff )
Jan 26 12:30:47 <rburton> yes
Jan 26 12:30:54 <rburton> the yocto autobuilder does that for ~10 machines
Jan 26 12:31:00 <b00^wk2> :D
Jan 26 12:31:06 <b00^wk2> ok, and distcc ?
Jan 26 12:31:10 <b00^wk2> is that option possible
Jan 26 12:31:45 <rburton> there's an icecc class
Jan 26 12:32:02 <b00^wk2> ok, i have one more question
Jan 26 12:32:02 <rburton> the win isn't as great as you'd expect as it won't spread configure, and that's about 30% of your build time
Jan 26 12:32:36 <b00^wk2> oh i see
Jan 26 12:34:44 <b00^wk2> one more question: does Yocto support RFS customization script and RFS overlay
Jan 26 13:01:46 <hanthings> Hello. How can I restrict a recipe to build only for a specific MACHINE
Jan 26 13:02:46 <joshuagl> COMPATIBLE_MACHINE http://www.yoctoproject.org/docs/2.0/ref-manual/ref-manual.html#var-COMPATIBLE_MACHINE
Jan 26 13:03:41 <hanthings> joshuagl, Thanks :)
Jan 26 13:04:04 <CTtpollard> :)
Jan 26 13:09:17 <joshuagl> np
Jan 26 13:11:49 <fsdun> moin. Is it possible to exclude all LGPL* licensed -staticdev packages from packaging?
Jan 26 13:15:50 <b00^wk2> from where the sources of packages are downloaded from?
Jan 26 13:16:08 <b00^wk2> does Yocto maintain a big source repo of the soft that goes into images?
Jan 26 13:16:10 <CTtpollard> b00^wk2: the recipe for the package will list the source
Jan 26 13:16:13 <rburton> b00^wk2: wherever the upstream source is
Jan 26 13:16:26 <rburton> we have a mirror in case upstream falls off the internet
Jan 26 13:16:39 <rburton> cough directfb cough
Jan 26 13:16:44 <b00^wk2> is the main source then  / upstream a Yocto source server ?
Jan 26 13:17:07 <rburton> no
Jan 26 13:17:19 <b00^wk2> so its not like many many different URLs from which all different sources are pulled from
Jan 26 13:17:28 <rburton> that's exactly what it is
Jan 26 13:17:34 <b00^wk2> is that safe ? :)
Jan 26 13:17:37 <rburton> you want gcc, downloads from gnu.org
Jan 26 13:17:46 <rburton> there's checksums to make sure you get what you wanted
Jan 26 13:21:21 <b00^wk2> rburton, what is say, after 5 years that url is not valid ? :)
Jan 26 13:21:42 <rburton> b00^wk2: then there's the mirrors, and we update stable branches in case URLs change
Jan 26 13:21:54 <b00^wk2> ok
Jan 26 13:24:02 <fsdun> and you can create your own mirrors if your product lifetime will exceed the lifetime of yocto's mirrors
Jan 26 13:24:35 <b00^wk2> fsdun, i know, i was just asking ..
Jan 26 13:24:45 <b00^wk2> in case :)
Jan 26 13:25:08 <b00^wk2> (Timesys provide their cloud like service seems, they have all sources that go into factory)
Jan 26 13:25:15 <b00^wk2> I would mirror it anyway, yocto or not
Jan 26 13:26:07 <aratiu> you can just save your downloads dir and move it between builds, mine now is only about 25 gigs
Jan 26 13:26:34 <rburton> awww mine is only 13G
Jan 26 13:26:58 <aratiu> yeah I need to clean that
Jan 26 13:27:30 <rburton> kernels only go back to 3.16 so i must have pruned at some point
Jan 26 13:28:16 <fsdun> sourcers: 23G, cached-binaries: 42G
Jan 26 13:28:28 <fsdun> in < 1 month
Jan 26 13:28:32 <rburton> this is a fun game!
Jan 26 13:28:49 <rburton> my /data is 866G, which is where i do my builds
Jan 26 13:29:22 <rburton> (616G of sstate)
Jan 26 13:29:37 <aratiu> rburton: no inherit rm_work?
Jan 26 13:29:59 <rburton> nah
Jan 26 13:30:11 <rburton> the tmp/ doesn't actually last that long
Jan 26 13:30:42 <aratiu> my poor ssd will cry if I don't rm_work
Jan 26 13:31:08 <rburton> get more ram and do builds in tmpfs!
Jan 26 13:31:13 <fsdun> rburton, do you expereince some issues with tcl/expect using your sstate cache?
Jan 26 13:31:28 <rburton> fsdun: literally never knowingly built tcl
Jan 26 13:31:37 <rburton> (because it's the devil's language)
Jan 26 13:32:27 <fsdun> I know. but I added ltp which requires tcl
Jan 26 13:33:08 <fsdun> and I had an issue I'm trying to reproduce while sharing sstate between 2 cortexa15 machines
Jan 26 13:34:58 <fsdun> it's hard to reproduce, because poky's machines do not share OVERRIDES
Jan 26 14:21:40 <b00^wk2> <fsdun> sourcers: 23G, cached-binaries: 42G
Jan 26 14:21:42 <b00^wk2> yoh !
Jan 26 14:29:47 <b00^wk2> anyone wants to add to my Yocto pros list:  1) Yocto is Open Source, 2) Support for major  CPU and SOC vendors, 3) Better build core (build tools, vs old make, KConfig); 4) support multiple target/ scale well within same project
Jan 26 14:29:48 <b00^wk2> :P
Jan 26 14:30:35 <CTtpollard> b00^wk2: are you studying different systems?
Jan 26 14:31:03 <b00^wk2> comparing vs Timesys Factory
Jan 26 14:31:14 <aratiu> maybe doing a presentation for management, more likely :) a study would look a lot less dull
Jan 26 14:31:16 <b00^wk2> ironically to me Timesys is listed as one of members of Yocto
Jan 26 14:31:26 <fsdun> b00^wk2, can add more packages by adding layers
Jan 26 14:31:31 <b00^wk2> aratiu, sure, im time limited too :P
Jan 26 14:31:50 <b00^wk2> fsdun, but you can add packages to TS Factory too
Jan 26 14:32:01 <b00^wk2> with Kconfig way ..
Jan 26 14:32:14 <b00^wk2> at least I beleive you can , i haven't done it
Jan 26 14:32:51 <fsdun> b00^wk2, poky is just the core. you cann add more layers for machines/packges/features: http://layers.openembedded.org/layerindex/branch/master/layers/
Jan 26 14:32:57 <rburton> looks like Timesys are moving to yocto
Jan 26 14:33:04 <rburton> "A future release of LinuxLink will be able to encompass both Factory and Yocto build systems, enabling customers to choose which path they want to take."
Jan 26 14:33:17 <b00^wk2> rburton, i think, they will dump their pet eventually ..
Jan 26 14:34:13 <aratiu> i suspect a lot more companies are in the process of dumping their pets in favor of Yocto
Jan 26 14:34:18 <b00^wk2> rburton, i saw that, and i was just thinking, what is there to LinuxLink except for Factory and Yocto..
Jan 26 14:34:46 <b00^wk2> aratiu, nice
Jan 26 14:34:57 <b00^wk2> hey, that UI tool Yocto has, Hob, that is being developed, right?
Jan 26 14:35:09 <rburton> hob? not really.  toaster is the replacment.
Jan 26 14:35:12 <aratiu> Toaster (never actually used it)
Jan 26 14:35:23 * rburton is a shell+emacs man though
Jan 26 14:35:25 <b00^wk2> ok, but its as user friendly as Hob .. ?
Jan 26 14:35:29 <b00^wk2> (i used Hob once, looked at it)
Jan 26 14:35:33 <b00^wk2> for a quick check
Jan 26 14:35:43 <aratiu> rburton: emacs + eshell
Jan 26 14:35:46 <rburton> hob was user friendly?
Jan 26 14:35:51 <b00^wk2> well,
Jan 26 14:35:59 <b00^wk2> it was all select select select press generate
Jan 26 14:36:16 <b00^wk2> without knowing really much about configs :)
Jan 26 14:36:36 <b00^wk2> may be Toaster will let you select all possible Yocto options :)
Jan 26 14:48:45 <b00^wk2> fsdun, are you here ? :)
Jan 26 14:49:09 <fsdun> yes
Jan 26 14:50:24 <b00^wk2> fsdun, wanted to interrogate you a bit more, on why layers in Yocto would allow you to add more packages vs another build system - Timesys Factory
Jan 26 14:50:25 <b00^wk2> :)
Jan 26 14:50:42 <fsdun> I never used timesys
Jan 26 14:50:46 <b00^wk2> ok
Jan 26 14:51:00 <fsdun> e.g. you can add meta-qt5 to get full qt support
Jan 26 14:51:09 <fsdun> which isn't in poky "core"
Jan 26 14:51:24 <fsdun> you want a browser -> meta-browser is your friend
Jan 26 14:51:33 <b00^wk2> fsdun,  on other words, you add 'meta', and it adds all that is required to get qt support
Jan 26 14:51:42 <fsdun> yes
Jan 26 14:51:42 <b00^wk2> which is alike , package, and old its dependencies
Jan 26 14:52:13 <fsdun> not all the dependecies, but if it require external layers it's normally stated in the readme
Jan 26 14:52:52 <b00^wk2> ah
Jan 26 14:52:57 <fsdun> sometimes without revision to use (HEAD is not a revision)
Jan 26 14:53:41 <rburton> qt4 isn't part of oe-core anymore
Jan 26 14:54:03 <b00^wk2> but now that did give me a point. Timesys has a few pre-selections or templates, but those are probably too few, way below yocto's available layers
Jan 26 14:54:28 <b00^wk2> so you can start off faster with Yocto, i guess, by not spending time selecting all dependencies, if timesys hasn't done it ..
Jan 26 15:00:30 <t0mmy> # Anybody would it what is the best solution to add Linux capabilities to a binary file for a recipe ?
Jan 26 15:14:35 <Ulfalizer> i remember hearing something about a script for checking that a package compiles standalone, regardless of what the current sysroot contents from previous builds happens to be. does anyone know what i'm talking about?
Jan 26 15:14:57 <Ulfalizer> i'm only aware of the manual method that involves (temporarily) throwing away tmp/
Jan 26 15:24:04 <b00^wk2> can Yocto folder which already contains a build be just c&p from one Linux machine to another, and be used same on another machine?
Jan 26 15:25:58 <kergoth> b00^wk2: unlikely, no. much of the native software (Tools that run on the build machine) aren't relocatable. possibly if the path to the directory is the same, and the build arch is the same, and the build distro is the same (otherwise the binaries might be incompatible)
Jan 26 15:28:37 <b00^wk2> yea this is what i found with timesys factory too
Jan 26 15:28:41 <b00^wk2> paths as a minimum must match
Jan 26 15:29:02 <b00^wk2> kergoth, i thought, OE 's one target is to be less dependent on host's OS & paths :)
Jan 26 15:31:03 <b00^wk2> is that possible to get a silent failure of a build of some sort, with Yocto?
Jan 26 15:31:46 <b00^wk2> probably very stupid question, of course if my layer is full of bugs, that can do anything
Jan 26 15:32:20 <b00^wk2> but does Yocto have some stronger checks of what goes into BitBake, to minimize build errors
Jan 26 15:33:03 <b00^wk2> hmm
Jan 26 15:33:26 <b00^wk2> seems all is upto me testing my meta-bla to make sure my bla doesn't screw up things
Jan 26 15:36:23 <kergoth> all shell tasks run with set -e, if that's what you mean
Jan 26 15:36:27 <kergoth> any failed process will fail the task
Jan 26 15:36:52 <kergoth> oe builds upstream projects. lif those upstream projects hardcode build paths into their binaries, well, then that's what they do. we cant' fix everything everywhere
Jan 26 15:37:30 <kergoth> to clarify
Jan 26 15:37:34 <kergoth> you can mov ea build dir, just not its tmpdir
Jan 26 15:37:51 <kergoth> and you can use an sstate cache from one machine on another, so most of it will come from the cache rather than building from scratch
Jan 26 15:38:27 <b00^wk2> i see
Jan 26 15:38:39 <b00^wk2> err, kergoth what is "ea" ?
Jan 26 15:38:57 <kergoth> that would be what we call a typo
Jan 26 15:39:01 <kergoth> mov ea = move a
Jan 26 15:39:06 <b00^wk2> lol
Jan 26 15:39:06 <b00^wk2> ok
Jan 26 15:39:21 <t0mmy> # Is it possible to set capabilities on files by calling setcap for example into a recipe ?
Jan 26 15:43:55 <t0mmy> Is it possible to set capabilities on files by calling setcap for example into a recipe ? I tried to call setcap to add permitted and effective caps but in a do_install_append function and I obtain the message below "unable to set CAP_SETFCAP effective capability: Operation not permitted"
Jan 26 15:45:20 <kergoth> not sure if pseudo supports capabilities or not. maybe check with seebs
Jan 26 15:45:40 <t0mmy> sorry, for spam, it due to a miss click
Jan 26 15:51:26 <t0mmy> kergoth: thanks you, I will keep looking while
Jan 26 15:52:41 <ryansturmer> Back to my question about layer priority
Jan 26 15:52:53 <ryansturmer> if I do bitbake-layers show-layers
Jan 26 15:53:18 <ryansturmer> The numeric layer priorities specified there are pretty much the priorities that are going to be used - is that right?
Jan 26 15:53:34 <ryansturmer> is there anything else that affects layer priority?
Jan 26 15:57:56 <b00^wk2> say i got some yocto core configuration , with some default or core layers, right, then I created my layers on top, to customize,fix,etc on top
Jan 26 15:58:31 <b00^wk2> then next year say yocto updated all core configurations, packages, etc .  and now my layers are not layering properly
Jan 26 15:59:16 <b00^wk2> i still have to fix all my local layers, right? with yocto changes
Jan 26 15:59:20 <kergoth> generally people maintain branches that align with yocto branches. each major release gets a branch, and same-named branches are compatible
Jan 26 15:59:36 <kergoth> but yes, when you go to update, you'd have to adjust the layer appropriately. how much work that is depends on how much yo're doing in the layer, and what that is
Jan 26 16:00:02 <b00^wk2> ok, so main benefit of layering, vs say , patching ..
Jan 26 16:00:12 <b00^wk2> im not sure
Jan 26 16:00:43 <b00^wk2> im just reading on layering as great huge concept in yocto, im trying to really get it
Jan 26 16:00:54 <kergoth> if you'd ever had to maintain a patch series over a long period of time, you'd already know the answer to that
Jan 26 16:01:02 <b00^wk2> :D
Jan 26 16:01:26 <kergoth> layers can be easily mixed and matched, added and removed, used in any number of projects. reorder two patches and watch them explode if they touch the same content..
Jan 26 16:07:35 <b00^wk2> http://www.newelectronics.co.uk/electronics-technology/yocto-is-challenging-traditional-thinking-and-solving-many-embedded-linux-problems/88287/
Jan 26 16:07:43 <b00^wk2> .. When a new release of Yocto/Poky comes out, you no longer need to recreate your changes and modifications: you simply update the lower layers, then check over your customisation layer for validity post-update (see fig 1b).
Jan 26 16:07:57 <b00^wk2> doesn't sound right, or is this right .
Jan 26 16:08:25 <kergoth> that's pretty much accurate
Jan 26 16:08:32 <b00^wk2> kergoth, once sec :P
Jan 26 16:08:37 <kergoth> if you override any classes, you'll have to update them, and any version specific appends may need updating to newer recipe versions, etc
Jan 26 16:08:46 <kergoth> as i said earlier, how much work it is depends on what's in your layer
Jan 26 16:09:10 <b00^wk2> yea, but way i understand above, you never had to even check your layer is still valid
Jan 26 16:09:14 <kergoth> ideally, any general fixes should go upstream to the core layers as soon as possible, so your layer only carries what's truly specific to what functionality that layer provides
Jan 26 16:09:29 <b00^wk2> what if, in my layer, say, i assumed u-boot version fixed = x, but yocto now moves to y in update
Jan 26 16:09:34 <b00^wk2> then my layer is scrwed up
Jan 26 16:09:38 <b00^wk2> i have to check that
Jan 26 16:09:45 <b00^wk2> not simple replace & play
Jan 26 16:10:27 <b00^wk2> kergoth, looks like some great skill in layring needed ? :)
Jan 26 16:10:39 <kergoth> the thing you just quoted says specifically that layers have to be checked for validity post-update
Jan 26 16:11:01 <kergoth> bitabke will error as soon as it sees you have an append that applies to a missing recipe. you rename it to the new version and make sure your patches still apply
Jan 26 16:11:11 <kergoth> but that's no different than any other project where you're patching a specific version of something and it gets updated
Jan 26 16:11:18 <b00^wk2> kergoth, but it says before that, "you no longer need to re-create your changes .. "
Jan 26 16:11:22 <kergoth> buildroot, etc, or even desktop distros
Jan 26 16:11:28 <b00^wk2> i thought kinda, no longer have to modify anything .. :)
Jan 26 16:11:29 <b00^wk2> sorry
Jan 26 16:11:34 <kergoth> you don't re-create them, you update them as appropriate
Jan 26 16:11:35 <b00^wk2> expecting magic here ..
Jan 26 16:11:38 <b00^wk2> yea
Jan 26 16:12:18 <olivier___> Hello everyone.
Jan 26 16:12:22 <olivier___> I have a question concerning a bootarg I need to set.
Jan 26 16:12:26 <olivier___> For the moment, I'm setting a 'linux.bootargs.video' variable direclty from my barebox command line.
Jan 26 16:12:30 <olivier___> I would like to insert it into my Yocto layer.
Jan 26 16:12:35 <olivier___> I found a 'linux.bootargs.base' file in the BSP layer; should I create a new one in my layer with the same path?
Jan 26 16:12:39 <olivier___> Or should I do it another way?
Jan 26 16:18:36 <ryansturmer> It really depends on how your BSP sets the bootargs, I would think.
Jan 26 16:19:12 <ryansturmer> It's possible you can bbappend in your layer and add args to the file, it just depends on how your bootloader is getting installed
Jan 26 16:26:39 <olivier___> ryansturmer: What do you mean by that? What should I look for to see how it's installed?
Jan 26 16:27:24 <ryansturmer> What board are you building for.  (I'm new to this stuff too, but might be able to help)
Jan 26 16:27:51 <ryansturmer> That file is most likely in the recipe for your bootloader in the BSP layer - is that correct?
Jan 26 16:30:08 <olivier___> I guesss yes
Jan 26 16:30:22 <olivier___> ryansturmer: I just need to create a bbappend file
Jan 26 16:30:31 <ryansturmer> Look at the recipe file, and it may reveal how that file is incorporated into the bootloader - you can then write a bbappend that modifies that recipe
Jan 26 16:30:53 <olivier___> ryansturmer: Ok; thanks, I'll try that!
Jan 26 16:31:05 <ryansturmer> It may be as simple as making a bbappend file that just tacks your arguments onto the end of that file - easy peasy, but I'd take a look at the recipe that calls on that file, just to make sure what you're doing makes sense.
Jan 26 16:31:26 <olivier___> ryansturmer: Ok; I'll check it carefully.
Jan 26 16:35:46 <t0mmy> kergoth: I found the solution, I use "setfattr -n security.capability -v <CAP>" instead of setcap <CAP>. Thanks again
Jan 26 16:37:09 <kergoth> ah, interesting
Jan 26 16:48:14 <abelloni> ah ouais
Jan 26 16:48:17 <ryansturmer> Is there a way to printout a recipe after all appends have been applied?
Jan 26 16:48:19 <abelloni> crap
Jan 26 16:49:15 <kergoth> ryansturmer: bitbake -e recipename shows you the metadata of a recipe after all parsing, including appends
Jan 26 16:54:28 <ryansturmer> kergoth: Do you have any suggestions for the situation where my bbappend order does not seem to be following my layer priority?
Jan 26 16:55:40 <ryansturmer> appends to my base-files recipe are clearly happening in the wrong order, no matter what I set my layer priority to
Jan 26 16:55:53 <ryansturmer> (confirmed now with bitbake -e base-files)
Jan 26 17:02:10 <ryansturmer> Maybe the way that I'm doing this altogether is incorrect - I wonder if someone here might have an insight.
Jan 26 17:02:50 <ryansturmer> I simply want to modify the /etc/fstab that is laid down by my BSP layer.  The BSP layer has a bbappend file that modifies the base-files recipe and replaces the /etc/fstab with its own.
Jan 26 17:02:51 <kergoth> by layer priority, you do mean LAYER_PRIORITY_* in the layer.conf, correct? an dyou're confirming the behavior by looking at the info about which files were parsed in the bitbake -e, not just the variables' value?
Jan 26 17:03:15 <ryansturmer> I mean BBFILE_PRIORITY ?
Jan 26 17:03:19 <kergoth> yeah
Jan 26 17:03:19 <kergoth> yeah, all you should need to do for that is have a layer higher priority than the bsp layer
Jan 26 17:03:34 <ryansturmer> Higher priority == higher number?
Jan 26 17:03:49 <ryansturmer> (I have tried both, in either case)
Jan 26 17:04:36 <ryansturmer> What I do in my append, is just use sed to modify the file that the underlying layer already laid down.
Jan 26 17:04:37 <kergoth> yep
Jan 26 17:05:09 <ryansturmer> sed -r 's:rootfs\s+/\s+auto\s+:&ro,errors=remount-ro,:' < ${D}${sysconfdir}/fstab > ${D}${sysconfdir}/fstab
Jan 26 17:05:22 <ryansturmer> (Make the root filesystem read-only)
Jan 26 17:06:10 <ryansturmer> if I say bitbake-layers show-appends | grep base-files, should that give me the appends in appended order?  or is it just random order?
Jan 26 17:06:34 <nerdboy> moin
Jan 26 17:08:03 <bluelightning> morning all
Jan 26 17:08:05 <bluelightning> ryansturmer: should be appended order
Jan 26 17:09:42 <ryansturmer> Yeah, no change in my BBFILE_PRIORITY variable (in conf/layer.conf) in my layer has any impact on the order that is represented there
Jan 26 17:10:03 <ryansturmer> even though I can bitbake-layers show-layers and see that the priority number changes
Jan 26 17:10:52 <ryansturmer> is this something that was likely fixed recently?  or has this worked forever and ever.  This is the build that ships with the Intel Edison, so it's back a bit, revision wise.
Jan 26 17:11:10 <ryansturmer> seems kind of fundamental to be a bug at this stage - gotta be something silly I'm doing here
Jan 26 17:12:03 <kergoth> are both appends using versions ,or both using %?
Jan 26 17:12:22 <kergoth> if one is versioned and the other is wildcard, the order was non-deterministic until relatively recently
Jan 26 17:12:26 <kergoth> richard fixed that bug a while back
Jan 26 17:12:32 <kergoth> well, short while
Jan 26 17:12:54 <_valle_> yocto/hmi/poky/build/tmp/sysroots/x86_64-linux/usr/lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/include/stdint.h:9:26: fatal error: stdint.h: No such file or directory
Jan 26 17:14:07 <bluelightning> _valle_: how are you invoking the compiler? are you using $CC ?
Jan 26 17:14:13 <kergoth> though, i think that was order within a layer, not between, now that i think about it
Jan 26 17:14:16 * kergoth shrugs
Jan 26 17:14:25 <bluelightning> I can't even find that patch :/
Jan 26 17:15:14 <ryansturmer> One of the appends is with a version
Jan 26 17:15:22 <ryansturmer> and the other is with %
Jan 26 17:15:32 <ryansturmer> would I be better off with the version in there?
Jan 26 17:15:59 <_valle_> bluelightning: Yes, EXTRA_OEMAKE += "'CC=${CC}' 'LD=${LD}' 'STRIP=${STRIP}' 'CROSS_COMPILE=${TARGET_SYS}-' 'HOSTCC=${CC}'"
Jan 26 17:16:17 <kergoth> ryansturmer: see 3cb87724a5b21550e99c18e97b665d6604bb2fa9 in poky, which is f980f060cd0d1e7fe5011f3c325c1b254f05eccf in the bitbake repo. you could try applying that if you don't already have it on the branch you're using.
Jan 26 17:16:25 <kergoth> not sure if it'll help, but worth checking
Jan 26 17:19:10 <_valle_> bluelightning: Then oe_runmake env
Jan 26 17:22:02 <bluelightning> _valle_: hmm, ok... not sure what to suggest
Jan 26 17:24:43 <ryansturmer> Ha.
Jan 26 17:24:45 <ryansturmer> That did it.
Jan 26 17:25:04 <ryansturmer> Well, it changed the order reported by bitbake-layers
Jan 26 17:25:08 <ryansturmer> rebuilding now to see how it goes.
Jan 26 17:25:12 <ryansturmer> Friggin frig.
Jan 26 17:25:17 <ryansturmer> I ran into this issue on another recipe
Jan 26 17:25:22 <ryansturmer> and I didn't understand how I fixed it.
Jan 26 17:25:25 <ryansturmer> This is how.
Jan 26 17:28:14 <_valle_> bluelightning: http://pastebin.com/hYPUwB9q
Jan 26 17:41:33 <seebs> no capabilities yet, no.
Jan 26 17:41:39 <seebs> in pseudo.
Jan 26 17:41:45 <seebs> I didn't even know that was a thing until I read the question.
Jan 26 17:46:13 <nerdboy> not a bad idea tho...
Jan 26 18:26:22 <seebs> I poked a bit at setcap documentation, and it looks like it's pretty pointless right now. And/or not entirely in place; most of the systems I've checked on have references to man pages they don't actually have, and I found one man page claiming that there's only a single capability bit, so either everything is permitted or nothing is.
Jan 26 18:26:30 <seebs> But we could probably fake it.
Jan 26 18:54:12 <nerdboy> that doesn't sound right...
Jan 26 18:55:44 <nerdboy> seebs: i see libcap and libcap-ng
Jan 26 18:56:03 <nerdboy> maybe the former is deprecated?
Jan 26 18:57:06 <nerdboy> they're both installed/pulled in by caps use flag
Jan 26 18:58:00 <nerdboy> i take that back, most stuff still depends on libcap
Jan 26 19:05:13 <seebs> The man page I found had a footnote about how the capability things were all fundamentally represented by a single bit, so if you enabledanything, you got everything. Surprised me a bit, but I guess it *is* the historical model.
Jan 26 20:02:07 <nerdboy> seebs: that still doesn't sound right
Jan 26 20:02:16 <nerdboy> eg, you should be able to get filecaps
Jan 26 20:05:06 <seebs> The docs could be wrong or out of sync.
Jan 26 20:16:14 <nerdboy> i see "fcaps cap_net_admin /path/to/foo"
Jan 26 20:16:35 <nerdboy> looks fairly granular/specific
Jan 26 20:17:07 <nerdboy> in qemu post_inst
Jan 26 20:18:17 <nerdboy> target file has no read perms except root
Jan 26 20:19:08 <nerdboy> looks it should depend on what capabilities you need to set
Jan 26 22:46:37 <wyrm> So, hey. I'm trying to build the cross-development qt5 SDK. The old-and-busted way is to use `bitbake meta-toolchain-qt5`. The new-hotness way is to just use `bitbake -c populate_sdk <main_image>`.
Jan 26 22:48:31 <wyrm> The old way builds both the nativesdk-packagegroup-qt5-toolchain-host and packagegroup-qt5-toolchain-target targets, while the new way only seems to want to build the ...-target one.
Jan 26 22:49:39 <wyrm> And I specifically notice that the new way doesn't provide a qmake to run on the development box, but it does provide one to run on the destination platform, which seems off.
Jan 26 22:49:50 <wyrm> So, what am I likely doing wrong?
**** ENDING LOGGING AT Wed Jan 27 02:59:59 2016