**** BEGIN LOGGING AT Thu Jul 27 03:00:02 2017
**** ENDING LOGGING AT Thu Jul 27 03:17:27 2017

**** BEGIN LOGGING AT Thu Jul 27 10:48:22 2017
Jul 27 10:49:00 <pagios> hello, can someone please point me to how i can get apache or third party softwares compiled and run on my yocto? any documentation i can start with ?
Jul 27 10:49:49 <zero_note> gartin: use DISTRO_FEATURES_append += " systemd"  in your local.conf
Jul 27 10:51:02 <LetoThe2nd> pagios: i assume you have successfully worked through http://www.yoctoproject.org/docs/2.3.1/yocto-project-qs/yocto-project-qs.html
Jul 27 10:51:36 <pagios> LetoThe2nd, can i add the package to the OS, or i need to rebuild the whole image?
Jul 27 10:52:25 <LetoThe2nd> pagios: its seomthing in between. without explicitly enabling your image to have runtime package management you have to rebuild the image, but not compile everything from scartch
Jul 27 10:52:59 <pagios> LetoThe2nd, well i have the yocto up and running i can login to it , i just need to add apache, and i guess the package management works fine
Jul 27 10:53:35 <LetoThe2nd> pagios: usually its best to create a custom image recipe and modify that to your liking. some general ideas on how to modify an image build are at http://www.yoctoproject.org/docs/2.3.1/dev-manual/dev-manual.html#usingpoky-extend-customimage
Jul 27 10:54:17 <LetoThe2nd> pagios: erm. well first, you probably have some image created through a poky build up and running, as there is no such thing as 'the yocto' or 'yocto linux'.
Jul 27 10:54:34 <pagios> LetoThe2nd, i saw that i can edit conf/bblayers.conf and add {your-yocto-home}/meta-webserver \ but then i need to recompile the whole image, what i want mainly is just to generate an ipk file to install on the existing OS
Jul 27 10:54:55 <LetoThe2nd> pagios: and secondly, by default, there is no package management in the images - thats why i said that without having it explicitly enabled, you have to rebuild the image.
Jul 27 10:55:28 <pagios> LetoThe2nd, but i already installed an ipk already on that image using opkg install file.ipk and it works so i want to do the same for apache
Jul 27 10:56:03 <LetoThe2nd> pagios: you did not mention that so far, so i always have to assume the default setting :)
Jul 27 10:56:31 <pagios> ok :) sorry my bad
Jul 27 10:56:47 <LetoThe2nd> pagios: whats unsatifying with bitbake apache2 then?
Jul 27 10:56:48 <pagios> so what i want is a way to install apache,nginx and such packages using opkg apache.ipk or nginx.ipk
Jul 27 10:56:54 <LetoThe2nd> https://layers.openembedded.org/layerindex/recipe/5976/
Jul 27 10:57:07 <pagios> i just need some documentation on the steps to generate that ipk correctly
Jul 27 10:57:22 <pagios> i am lost in documentation
Jul 27 10:57:29 <pagios> and need guidance to do this specific task
Jul 27 10:57:31 <LetoThe2nd> bitbake $WHATYOUWANTTOBUILD
Jul 27 10:57:58 <LetoThe2nd> then the packages should be generated in tmp/deploy/$YOURPACKAGEFORMAT/$YOURTARGETARCH
Jul 27 10:58:07 <pagios> thats it ?
Jul 27 10:58:12 <LetoThe2nd> thats it.
Jul 27 10:58:30 <pagios> this works if whatiwanttobuild is already in the repo of yocto
Jul 27 10:58:34 <LetoThe2nd> people just usually don't do that, except for tinkering purposes.
Jul 27 10:58:43 <LetoThe2nd> yes of course. no recipe, nothing to build
Jul 27 10:59:30 <pagios> ERROR: Nothing PROVIDES 'nginx'
Jul 27 10:59:47 <pagios> or apache
Jul 27 10:59:55 <LetoThe2nd> http://layers.openembedded.org/layerindex/branch/master/recipes/?q=nginx
Jul 27 11:00:15 <LetoThe2nd> so nginx certainly has a recipe, and apache2 too
Jul 27 11:01:02 <LetoThe2nd> so if you actually added a checkout of http://layers.openembedded.org/layerindex/branch/master/layer/meta-webserver to your BBLAYERS, then they should be there.
Jul 27 11:01:02 <pagios> ok how can i get those?
Jul 27 11:01:45 <LetoThe2nd> checkout the repository and add the path to meta-webserver to your BBLAYERS variable in con/bblayers.conf of your build directory
Jul 27 11:02:25 <pagios>  ${BSPDIR}/sources/meta-openembedded/meta-webserver
Jul 27 11:03:29 <pagios> and git checkout -b master?
Jul 27 11:03:45 <LetoThe2nd> checkout the branch that matches your poky build.
Jul 27 11:03:57 <LetoThe2nd> like krogoth, morty, pyro ...
Jul 27 11:04:04 <LetoThe2nd> mixing is bad :-)
Jul 27 11:07:21 <pagios> how can i know my opy build branch
Jul 27 11:07:31 <pagios> i am very new as you see
Jul 27 11:07:46 <LetoThe2nd> pagios: well how did you set poky up?
Jul 27 11:08:03 <pagios> it came as setup
Jul 27 11:08:21 <LetoThe2nd> without git history?
Jul 27 11:08:39 <pagios> yea
Jul 27 11:08:42 <LetoThe2nd> sigh
Jul 27 11:11:31 <LetoThe2nd> look at meta-poky/conf/distro/poky.conf
Jul 27 11:12:09 <LetoThe2nd> in your poky directory. there the version should be noted
Jul 27 11:13:35 <pagios> fido
Jul 27 11:14:20 <LetoThe2nd> .. which is unsupported since about 2 years.
Jul 27 11:14:46 <LetoThe2nd> ok, 17 months accoring to meta-openembedded logs
Jul 27 11:15:50 <LetoThe2nd> but anyways, thats your branch then.
Jul 27 11:17:37 <pagios> LetoThe2nd, can i add something like that using http://? http://i.imgur.com/RPtuqeh.png
Jul 27 11:17:56 <LetoThe2nd> erm, no?
Jul 27 11:18:42 <LetoThe2nd> but as you already seem to have meta-openembedded/meta-networking, why not just add another line referring meta-openembedded/meta-webserver?
Jul 27 11:18:57 <pagios> i thought i have to include fido in somewa
Jul 27 11:18:58 <pagios> y
Jul 27 11:19:06 <LetoThe2nd> no
Jul 27 11:19:15 <pagios> and same for ruby?
Jul 27 11:19:33 <LetoThe2nd> this always refers to real files on your harddrive, not some URL
Jul 27 11:20:09 <LetoThe2nd> so if your source/ directory already contains meta-openembedded, then there should be the meta-webserver subdirectory. and that you can use
Jul 27 11:20:22 <pagios> next i need to bitbake
Jul 27 11:20:25 <LetoThe2nd> same for meta-ruby
Jul 27 11:22:12 <pagios> before doing bitbake meta-webserver i need to checkout right
Jul 27 11:22:15 <pagios> git checkout
Jul 27 11:22:45 <LetoThe2nd> why don't you just have a look in your source/meta-openembedded directory to see whats already there?
Jul 27 11:24:15 <pagios> meta-openembedded/meta-webserver$ ls conf  COPYING.MIT  licenses  README  recipes-httpd  recipes-php  recipes-support  recipes-webadmin
Jul 27 11:24:33 <LetoThe2nd> see, obviously everything is already checked out
Jul 27 11:24:46 <pagios> alright
Jul 27 11:24:59 <LetoThe2nd> so just add them to BBLAYERS, analogous to meta-networking
Jul 27 11:25:37 <pagios> i added this to bbylauers:   ${BSPDIR}/sources/meta-openembedded/meta-webserver
Jul 27 11:25:54 <pagios> now i did in the build directory bitbake meta-webserver
Jul 27 11:26:36 <LetoThe2nd> erm.
Jul 27 11:26:45 <LetoThe2nd> i told you: bitbake apache2
Jul 27 11:26:51 <LetoThe2nd> or bitbake nginx
Jul 27 11:27:15 <pagios> LetoThe2nd, where can i read about all this, i need a documentation that targets this, how to add and remove packages thats all i need honestly
Jul 27 11:28:01 <LetoThe2nd> again, its http://www.yoctoproject.org/docs/2.3.1/dev-manual/dev-manual.html
Jul 27 11:29:12 <pagios> http://www.yoctoproject.org/docs/2.3.1/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe
Jul 27 11:29:22 <pagios> we are writing now a ruby and a apache2 recipe
Jul 27 11:29:42 <pagios> ah no we are using a recipe ok
Jul 27 11:29:50 <LetoThe2nd> why would you want to write an apache2 recipe or a ruby recipe? yeah, you're using them
Jul 27 11:30:08 <pagios> thanks LetoThe2nd
Jul 27 11:30:21 <LetoThe2nd> https://www.yoctoproject.org/sites/default/files/ypdd-oct2013-into-hands-on-lab.pdf
Jul 27 11:31:00 <LetoThe2nd> this is a little more hands on. but the truth just is, that you're not *USING* a linux distribution, you're *BUILDING* one. and that is not trivial
Jul 27 11:31:08 <pagios> so to sum up: in order to use a recipe, i first need to check my version which is in my case fido and see if the recipe exist in the repo, if it does i need to add the layer to my bblayer and then bitbake the recipe using bitbake <recipename> an ipk file is generated for me to install on the embedded system
Jul 27 11:32:06 <LetoThe2nd> thats a very trimmed down version that only works for you probably, but it does sound usable, yes.
Jul 27 11:35:51 <pagios> meta-openembedded stands for what exactly coz i see different directories next to it too
Jul 27 11:36:47 <LetoThe2nd> there are other layers too. meta-openembedded is kinda the base distribution infrastructure
Jul 27 11:38:00 <pagios> alright bitbake nginx works :)
Jul 27 11:38:06 <pagios> now i should see the ipk somewhere right
Jul 27 11:38:23 <LetoThe2nd> 12:57 < LetoThe2nd> then the packages should be generated in tmp/deploy/$YOURPACKAGEFORMAT/$YOURTARGETARCH
Jul 27 11:38:26 <pagios> oh i see like 5 versions
Jul 27 11:38:27 <pagios> :)
Jul 27 11:39:10 <pagios> some in ./tmp/deploy/ipk/and someother in ./tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/nginx/1.4.4-r0/deploy-ipks/
Jul 27 11:39:29 <LetoThe2nd> please, look again what path i named.
Jul 27 11:39:49 <pagios> thank you
Jul 27 11:39:50 <LetoThe2nd> and there certainly was *NO* work directory involved
Jul 27 11:40:33 <pagios> what is that second work directory for?
Jul 27 11:40:35 <pagios> internally used?
Jul 27 11:41:08 <LetoThe2nd> you should treat everything except tmp/deploy as internal
Jul 27 11:41:29 <pagios> ok :)\
Jul 27 11:41:51 <pagios> now i install the ipk and then i do my nginx configuration just like on a regualr linux machine
Jul 27 11:42:36 <LetoThe2nd> if you want to do everything in-target, for a one time tinkering thing, you would be way better off with using a standard distro like debian, ubuntu, whatever
Jul 27 11:43:15 <LetoThe2nd> the real power of openembedded and therefore poky is that you can build images that are completely custom tailored and reproductible
Jul 27 11:43:46 <LetoThe2nd> its just a whole different usecase.
Jul 27 11:44:08 <pagios> you mean by custom tailored is that the nginx would be configured and automated
Jul 27 11:44:17 <pagios> so you do your configuration and then bake it
Jul 27 11:44:28 <LetoThe2nd> in a very generalized way, yes.
Jul 27 11:44:49 <LetoThe2nd> thats also why there is no package management usually. its just not needed.
Jul 27 11:46:52 <pagios> you mean by package management like apt or yum, but you can still bake an apt or yum but yea i get your point
Jul 27 11:47:45 <LetoThe2nd> and no rpm, no opkg, no...
Jul 27 11:48:17 <pagios> alright
Jul 27 11:48:43 <pagios> so say i want to work now on this embedded system and configure it manually , can i then export that image as is and clone it to another machine?
Jul 27 11:49:07 <pagios> i dont want to reinstall ipk everytime, just take a clone of  the whole embedded system and roll it out on another machine
Jul 27 11:49:18 <LetoThe2nd> there might be a way, but thats totally unrelated to yocto
Jul 27 11:49:20 <pagios> an identical hardware
Jul 27 11:50:07 <pagios> coz rolling out the ipks even if preconfigured would be time consuming
Jul 27 11:50:27 <LetoThe2nd> i don't want to reinstall ipks too, hence i just do bitbake my-image, and everything is set up :)
Jul 27 11:51:00 <pagios> and you configure my-image inside an emulator mainly?
Jul 27 11:51:12 <LetoThe2nd> why would i do that?
Jul 27 11:51:20 <pagios> how do you configure my-image?
Jul 27 11:51:26 <LetoThe2nd> by recipes
Jul 27 11:51:41 <LetoThe2nd> its all in the meta data. i do literally *NOTHING* manually
Jul 27 11:51:55 <LetoThe2nd> thats what i mean with the real power.
Jul 27 11:52:16 <pagios> you can invoke command line bash scritps  , write files etc?
Jul 27 11:52:28 <LetoThe2nd> why not?
Jul 27 11:52:33 <pagios> wow
Jul 27 11:53:06 <pagios> can you show me an example of such configuration? like a sample
Jul 27 11:53:27 <LetoThe2nd> lots and lots of examples in poky and meta-openembedded :)
Jul 27 11:53:47 <pagios> in the bblayers.conf?
Jul 27 11:53:53 <pagios> everything is done there
Jul 27 11:53:56 <LetoThe2nd> no
Jul 27 11:54:17 <LetoThe2nd> everything is done in the meta-* directories
Jul 27 11:56:50 <pagios> so mainly in your bblayer you make sure you are pointing to those recipes directories and inside those directories you have a .bb file that reads the configuration and some folders/files needed for that configuration
Jul 27 11:57:10 <LetoThe2nd> have you actually looked at the docs?
Jul 27 11:57:20 <LetoThe2nd> i mean, thats really well laid out there.
Jul 27 11:58:34 <pagios> alright
Jul 27 11:58:37 <pagios> i will
Jul 27 12:00:06 <LetoThe2nd> espcially the 2013 presentation
Jul 27 12:18:30 <pagios> LetoThe2nd, nginx: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or diretory , do i need to install those dependencies manually?
Jul 27 12:18:49 <LetoThe2nd> you have to, probably
Jul 27 12:19:10 <pagios> cant i include in my recipe to scan automatically all those dependencies and include them
Jul 27 12:19:27 <LetoThe2nd> pagios: the recipe knows about them and builds them
Jul 27 12:19:41 <LetoThe2nd> there's probably a libpcre.ipk
Jul 27 12:19:42 <pagios> so they are in that ipk directory somewhere
Jul 27 12:19:44 <pagios> ok
Jul 27 12:20:03 <LetoThe2nd> like i said, this is just not meant for manual tinkering
Jul 27 12:20:08 <LetoThe2nd> we automate things :)
Jul 27 12:20:36 <pagios> yea but i have to start somewhere :)
Jul 27 12:21:04 <LetoThe2nd> you're starting at the wrong place, really.
Jul 27 12:21:17 <pagios> whats the difference between neon and mx6 btw
Jul 27 12:21:30 <LetoThe2nd> try to set up a custom layer and a custom recipe for your image. then continue from there.
Jul 27 12:21:53 <LetoThe2nd> um, neon is a cpu core feature, and imx6 is a soc product by nxp/freescale?
Jul 27 12:22:13 <pagios> coz i see 2 directories in the deploy/ipk
Jul 27 12:22:51 <LetoThe2nd> imx6 should be the things that are absolutely machine specific. like bootloader, kernel, etc.
Jul 27 12:23:12 <LetoThe2nd> neon-... is the userland then. behind the kernel abi
Jul 27 12:24:36 <pagios> wow //var/lib/opkg/info/nginx.postinst: line 2: type: systemd-tmpfiles: not found
Jul 27 12:28:00 <pagios> btw LetoThe2nd say you install ruby, does the GEM command installs with it or need to also bake that , sorry for so many quesitons
Jul 27 12:28:03 <pagios> last one for today
Jul 27 12:28:44 <LetoThe2nd> no idea.
Jul 27 12:28:52 <LetoThe2nd> i don't use ruby
Jul 27 12:29:19 <LetoThe2nd> probably gem (AFAIK its some kind of package manager again) gets built into a seperate package
Jul 27 12:29:52 <LetoThe2nd> but again, one more time - if you want to set up things manually and then clone stuff, the mindset from the yocto project does not fit your usecase.
Jul 27 12:36:42 <pagios> it installs gem
Jul 27 14:07:45 <RP1> kanavin: https://autobuilder.yocto.io/builders/nightly-x86-64/builds/388/steps/BuildImages/logs/stdio - libcap is still breaking, not sure if that is gperf or something else? :/
Jul 27 14:19:55 <kanavin> RP1: it's gperf, maybe we should drop libcap altogether, as libcap-ng is a newer replacement?
Jul 27 14:20:12 <kanavin> RP1: considering that libcap people are not in a hurry to fix things :-/
Jul 27 14:21:51 <kanavin> RP: last commit, 18 months ago
Jul 27 14:22:20 <RP> kanavin: are other distros using that?
Jul 27 14:22:56 <kanavin> RP: using what?
Jul 27 14:23:07 <RP> kanavin: libcap-ng
Jul 27 14:24:05 <kanavin> RP: debian has it for instance, and the homepage is on redhat.com
Jul 27 14:24:21 <kanavin> RP: we have a recipe for it too in oe-core :)
Jul 27 14:26:24 <RP> kanavin: we should probably kill libcap then. Is libcap-ng a drop in replacement?
Jul 27 14:26:48 <fray> afaik, it is not
Jul 27 14:28:14 <kanavin> also, there is a ton of dependencies on libcap still :/
Jul 27 14:30:04 <RP> kanavin: hmm, doens't sound so simple then :(
Jul 27 14:31:05 <bluelightning> looks like a fork that so far hasn't been resolved
Jul 27 14:31:20 <kanavin> RP: debian unstable has the same combination of gperf and libcap versions that breaks for us, and that doesn't break for them :/
Jul 27 14:34:26 <RobbinParrish> Hi All, Can you suggest a branch or commit of meta-java that can successfully build on the poky-pyro release? We have tried poky-pyro-17.0.0 poky-pyro-17.0.1, and the master branch of poky-pyro without success.
Jul 27 14:43:30 <kanavin> RP: I made another patch, hopefully this one works
Jul 27 15:33:39 <PinkSnake> Hi all, what is th easiest way to deploy openCL/GL on a custom target inside Yocto ?
Jul 27 16:01:32 <mcfrisk> hmm, how is layer specific conf/layer.conf parsed? It looks like there can not be layer specific include statements there. For example multiple layers could have a common include file but with different content in each layer. It seems I must specify the include file in each layer.conf but if the file names are same I get "WARNING: Duplicate inclusion for $INCLUDEFILE in layer/conf/layer.conf"
Jul 27 17:07:27 <lodup29> Hi, I’m trying to use TARGET_CXXFLAGS += "..”  to add flags to TOOLCHAIN_PREFIX-g++ in a cmake based project but the compiler is systematically called without it. I’m just starting with Yocto but I used to do this with Buildroot using PACKAGENAME_MAKE_OPTS = CXXFLAGS="…" .  Is there a cmake specific syntax to add CXXFLAGS in Yocto? Thanks
Jul 27 17:19:15 <mcfrisk> lodup29: use cmake class from yocto and override the same variables you would override when calling cmake. grep poky tree for cmake examples..
Jul 27 17:41:35 <lodup29> mcfrisk: Thanks, the recipe already inherited cmake. I tried to override OECMAKE_CXX_FLAGS_RELEASE and OECMAKE_CXX_FLAGS both before and after the ‘inherit cmake’ directive without any success. cmake still pass a bunch of paramters to g++ which a clearly from Yocto but not based on those variables.
Jul 27 17:42:11 <khem> RP: rburton, can you try out this http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master&id=08d7a9b7c22da856288d7b76e62a21b7b7f28dd4
Jul 27 17:42:21 <khem> this adds llvm to OE-core
Jul 27 17:42:31 <khem> its based on upcoming 5.0 release
Jul 27 17:43:45 <khem> RP: its first cut, so there might be small problems left, but damn llvm takes forever to compile. so would be great if you can try it out on AB
Jul 27 17:43:54 <khem> and let me know of failures
Jul 27 17:44:36 <behanw> khem: Longer than gcc and related tech?
Jul 27 17:46:58 <khem> definitelt
Jul 27 17:47:10 <khem> its c++ what do you expect
Jul 27 17:47:23 <behanw> khem: LOL.
Jul 27 17:47:56 <behanw> compiling llvm with g++ or clang? ;)
Jul 27 17:48:06 <khem> it doesnt help.
Jul 27 17:48:08 * behanw kids
Jul 27 17:48:22 <khem> although gcc7 is better in speed than gcc6
Jul 27 17:48:28 <behanw> Agreed
Jul 27 17:49:09 <behanw> I am so glad gcc's rate-of-change accelerated.
Jul 27 17:49:37 <behanw> competition can be a wonderful thing.
Jul 27 17:50:17 <khem> yeah
Jul 27 17:50:37 <khem> the llvm for OE-Core is not getting in clang btw. just LLVM
Jul 27 18:00:25 <behanw> khem: Understood. I was kidding. ;)
Jul 27 18:13:05 <notupinhere> Does anybody know how to init more than just tty1 in a Poky distro?
Jul 27 18:14:53 <notupinhere> I'd like to be able to ALT-F2 to tty2 once booted
Jul 27 18:17:11 <neverpanic> notupinhere: That depends on which init system you use.
Jul 27 18:21:02 <notupinhere> I'm using the default init system included with Poky.  Will I need to add a more robust init system to do that?
Jul 27 18:22:21 <neverpanic> Is that systemd? Because enabling it for poky is probably not different from enabling it for any systemd distro out there.
Jul 27 18:23:46 <notupinhere> definitely not systemd right now, I was hoping to avoid systemd in this case
Jul 27 18:25:01 <neverpanic> Have you checked /etc/inittab?
Jul 27 18:26:21 <notupinhere> oh good call!  THen I'd like to have it autologin, so I guess I'll have to fiddle with Getty...
Jul 27 18:26:39 <notupinhere> Thanks for that!  don't know how I spaced inittab, haha
Jul 27 18:27:13 <gonzo-> notupinhere: Create bbappend for sysvinit-inittab and add following line there:
Jul 27 18:27:14 <gonzo-> SYSVINIT_ENABLED_GETTYS="1 2 3 4 5 6 7"
Jul 27 18:27:55 <notupinhere> oh wow, thanks gonzo!  that's about as easy as it gets
Jul 27 18:34:06 <tgoodwin> Is there a variable for what will ultimately be returned for the processor type in 'uname'?
Jul 27 18:57:42 <tgoodwin> kergoth: Is there a way to determine during a build what value will be returned for the processor when 'uname' is run?
Jul 27 19:00:42 <mawillia> Hello, I am trying to add sources for a package to a yocto target to allow native re-compiles (it's a sample application), is there an easy way to do that?
Jul 27 19:05:01 <tgoodwin> mawillia: In other words, you want to be able to compile on the target?
Jul 27 19:43:09 <kergoth> tgoodwin: you mean i.e. x86_64 or whatnot? it's most likely TARGET_ARCH, but it's the kernel that gives that info to uname
Jul 27 20:06:03 <RP> khem: ross is out atm and I'm drowning in patches and failures that result from them :(
Jul 27 20:06:33 <ythl> Is there a way to make a more slimmed down SDK than `bitbake image -c populate_sdk`?
Jul 27 20:06:58 <ythl> populate_sdk makes a self-installing shell script that unzips to like 2GB
Jul 27 20:07:10 <ythl> But I know the toolchain + RFS individually are not that big
Jul 27 20:08:26 <ythl> Toolchain is 700 MB and RFS is 400 MB
Jul 27 20:08:43 <ythl> Where's the other ~1GB coming from?
Jul 27 20:12:55 <bluelightning> ythl: debugging symbols perhaps?
Jul 27 20:25:41 <pagios> hi all
Jul 27 20:25:57 <pagios> i am trying to get my wifi minipci-e working on my embedded system and getting this error in dmesg: http://i.imgur.com/kHvAyMY.png
Jul 27 20:26:03 <pagios> any idea how to get that driver working
Jul 27 20:26:04 <pagios> ?
Jul 27 20:40:27 <khem> RP: ok no worries,
Jul 27 21:01:26 <pagios> hello, any idea about this error? https://pastebin.com/V6Rt8uzQ
Jul 27 21:04:20 <Snert_> likely a typo in the wpa_supplicant.conf file.
Jul 27 21:04:30 <Snert_> or other bad parameter in that file.
Jul 27 21:47:40 <ythl> Has anyone else ever generated a bad toolchain?
Jul 27 21:47:52 <ythl> I ran bitbake image -c populate_sdk
Jul 27 21:48:06 <ythl> And the resulting gcc 5.3.0 is unable to compile files that #include <memory>
Jul 27 21:48:37 <ythl> However, it seems to be able to compile anything else
Jul 27 21:51:24 <ythl> However, if I download a gcc 5.2.1 cross compiler from yocto's website, that is able to compile everything
Jul 27 23:40:32 <halstead> armpit, Did you see https://autobuilder.yocto.io/builders/nightly/builds/428 ?
Jul 27 23:41:56 <armpit> nope. just checked. thanks.
Jul 27 23:42:08 <armpit> sad thing is morty does not support that layer
**** ENDING LOGGING AT Fri Jul 28 03:00:00 2017