**** BEGIN LOGGING AT Tue May 23 03:00:02 2017
May 23 06:17:32 <CostinC> morning all
**** BEGIN LOGGING AT Tue May 23 06:32:00 2017
May 23 07:03:56 <ed2> RP1: I couldn't reproduce that build failure. on OpenSuse 42.2 it works just fine, on my older machines build breaks this way: https://gist.github.com/bartosh/741ea816bf944e2601c51fdc3c865010
May 23 07:04:10 <ed2> RP1: any ideas?
May 23 08:01:48 <PinkSnake> @ed2 sometimes glibc-locale: 820 installed and not shipped files. [installed-vs-shipped] means you don't have set FILES varibale correctly
May 23 08:02:48 <ed2> PinkSnake: well, it's master-next as it is. i didn't set any variables. it's a clean build.
May 23 08:03:18 <ed2> PinkSnake: and it works on latest OpenSuse. It doesn't work on 42.1 and 13.2
May 23 08:05:26 <PinkSnake> @ed2 ok so there is maybe some touble on master-next, it's dirty but you can maybe add INSANE_SKIP+="installed-vs-shipped" in a .bbappend
May 23 08:10:38 <Smitty_> I'm losing it !    https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#bitbake-user-manual-execution  states, very clearly,  "The layer.conf files are used to construct key variables such as BBPATH and BBFILES."  If that is the case, why are these variables always being set in conf/bblayers.conf  and not conf/layers.conf ?
May 23 08:26:59 <rj_> Smitty_: They are set in /poky/meta-something/conf/layer.conf
May 23 08:27:11 <Ramose> Can a flag OE_QMAKE_CXXFLAGS defined in one meta layer meta-qt5 be used in some other meta layer ?
May 23 08:34:20 <ChrysD> Morning everyone!
May 23 08:37:24 <Smitty_> Trying to understand what (the hell) bitbake is doing is an exercise in frustration.  The "-e" option to bitbake (e.g. bitbake -e customtarget) produces output like this:  https://pastebin.com/ksWzrkZn    Why are files like conf/bitbake.conf, conf.site.conf, conf.auto.conf not provided with full path names.   Where do they come from ?   Why doesn't this show the order of processing from the very first file bitbakes opens (bblayers.co
May 23 08:37:38 <Smitty_> ...are processed ?
May 23 08:48:26 <Smitty_> Why doesn't my layer appear in BBLAYERS variable?  https://pastebin.com/81XdwB2g
May 23 08:48:50 <Smitty_> My Layer being meta-custom, which is present
May 23 08:50:12 <rj_> Smitty_: Have you added the layer path to the bblayer.conf file?
May 23 08:52:03 <Smitty_> meta-custom is "included" by way of an line in templateconf.cfg  "..meta-custom/conf" - which apparently is adding in the layer - unless I am mistake
May 23 08:52:47 <rj_> Smitty_: As far as i know you just have to add the path to bblayers.conf and you should be able to use the layer
May 23 09:18:50 <sobczyk> is it possible to limit a recipe to architecture features? ie. only for cortexa15hf? COMPATIBLE_MACHINE matches not what I want
May 23 09:21:19 <ChrysD> Smitty_ : For adding a layer, is just simple as adding a line into bblayers.conf
May 23 09:22:13 <ChrysD> Smitty_ : You also need to check into your layer, if you have a layer.conf. If you have followed the guide, you have used the tools to create one and in the layer.conf it should select every recipe in your layer.
May 23 09:22:43 <ChrysD> Smitty_ : Something like BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \         ${LAYERDIR}/recipes-*/*/*.bbappend"
May 23 09:29:15 <ChrysD> sobczyk : Does " soc_familly" could help you?
May 23 09:31:34 <ChrysD> sobczyk : Look into also TARGET_ARCH / TUNE_ARCH
May 23 09:33:35 <cornel> hello
May 23 09:33:38 <ChrysD> sobczyk : you are limitating a recipe for an arch, but as you have to define the machine target, is it really needed? Maybe you should consider makingn a recipe image for your arch.
May 23 09:33:51 <cornel> is there a plan to move to meson away from autotools?
May 23 09:34:03 <ChrysD> sobczyk : and you bitbake the image that suit your arch.
May 23 09:41:11 <sobczyk> ChrysD: my image is tuned for odroid, but the specific recipe is a blob that should not be used on other boards like imx6
May 23 09:42:28 <sobczyk> so the blob recipe should only build for all odroid machines (cortexa15hf)
May 23 09:42:55 <ChrysD> sobczyk : What don't you make an image for odroid machines especially including that recipe for example?
May 23 09:43:18 <PinkSnake> @sobczyk maybe with someting like that:  machine = d.getVar('COMPATIBLE_MACHINE', True)
May 23 09:44:34 <sobczyk> ChrysD: I do include it explicitly, but I don't want others include it in other arch by mistake
May 23 09:46:58 <PinkSnake> @sobczyk @ChrysD is right, you can also maybe split you work in 2 meta-layers and add the board dependent part in bbalyer
May 23 09:50:46 <ChrysD> sobczyk : you couldn't avoid any "humans problems". If someone do the wrong bitbake and flash it into the board, yocto couldn't help you for that. Even if you do a kind of system that could select the recipe depending the machine put, if the one that bitbake forgot to tell the right arch/machine, it won't work.
May 23 09:51:17 <ChrysD> sobczyk : so maybe doing a recipe image which explicitely tell you that is an image for odroid ou imx6 will help to not bitbake the wrong image
May 23 09:51:29 <ChrysD> sobczyk : odroid-image-gui-qt or whatever
May 23 09:51:37 <ChrysD> sobczyk : imx6-image
May 23 11:09:22 <Ramose> can a flag like OE_QMAKE_CXXFLAGS used between different layers ?
May 23 11:13:11 <binarym> Ramose: i guess it depends on where you defined it ...
May 23 11:13:41 <Ramose> binarym: I defined it in meta-qt5 layer
May 23 11:15:09 <Ramose> and wanted to use value of that flag in some other layer
May 23 11:15:15 <Ramose> https://lists.yoctoproject.org/pipermail/yocto/2012-February/004596.html
May 23 11:15:18 <Ramose> something like it
May 23 11:17:53 <rj_> Does anyone know why "multiprocessing" is not installed with the python3 package?
May 23 11:18:45 <rburton> rj_: because until very recently python3 just installed python3-core which is just the critical bits.  install python3-modules.
May 23 11:18:59 <rburton> (I fixed this a few weeks ago)
May 23 11:19:11 <rj_> Ah alright, thanks!
May 23 11:21:15 <rj_> rburton: Where exactly can i find the recipe?
May 23 11:21:43 <binarym> Ramose: but where ? In a recipe ?
May 23 11:21:53 <Ramose> Yes
May 23 11:21:57 <binarym> if defined in a recipe (.bb file), the flag will only apply to it
May 23 11:22:09 <binarym> if you want system-wide flags, you have to put it in a .conf
May 23 11:22:11 <binarym> but
May 23 11:22:13 <rburton> rj_: its built by python3, just install python3-modules instead of python3 in your image
May 23 11:22:34 <binarym> i'm not sure that it works for OE_QMAKE_CXXFLAGS
May 23 11:22:36 <Ramose> yeah I am trying this .conf approach
May 23 11:22:49 <binarym> Ramose: try with your build/conf/local.conf
May 23 11:22:53 <Ramose> export OE_QMAKE_CXXFLAGS
May 23 11:22:57 <binarym> in my opinion, best place to do it
May 23 11:22:57 <rj_> rburton: ah okay
May 23 11:23:16 <Ramose> and then lets the recipe file in meta-qt5 set its value
May 23 11:23:46 <Ramose> and see if this flag can be used system-wide.
May 23 11:28:08 <LocutusOfBorg> hello bluelightning did you send the patch about upper case PN files? (the variables not being evaluated when PN is upper case)
May 23 11:33:25 <rj_> rburton: It works now, thanks ^^
May 23 11:33:59 <rburton> rj_: annoying bug in the metadata, might push it back into 2.3 as its annoying
May 23 11:34:38 <rj_> rburton: Well if you know about it's no problem. But when you don't it can be hard to find whats wrong
May 23 12:57:14 <Smitty_> runqemu hangs at:  runqemu - INFO - Running tmp-glibc/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin//qemu-system-i386  -drive file=tmp-glibc/deploy/images/qemux86/customimage-qemux86-20170522132558.rootfs.ext4,if=virtio,format=raw -vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci   -cpu qemu32 -m 256 -serial mon:vc -serial null -kernel tmp-glibc/deploy/images/qemux86/bzImage--4.10.15+g
May 23 12:58:04 <Smitty_> Do I need some kind of special privilege to run qemu under linux ?
May 23 13:15:27 <fmeerkoetter> how does the yocto project handle security fixes for its layers? from what I can see/read there are security updates for around a year? my impression is that after that point i either move to a new yocto release (wont happen for a product...) or i monitor all the packages in my system and apply patches accordingly. Is this correct?
May 23 13:16:23 <rburton> fmeerkoetter: yes, either monitor yourself or pay a OSV such as wind river/mentor/montavista to do it for you (by providing a supported yocto-based system for N years)
May 23 13:17:28 <fmeerkoetter> rburton: ah. thanks! that is of course also an option. good point
May 23 13:17:57 <fmeerkoetter> rburton: sadly enough that is not what I am seeing in practice. :-(
May 23 13:18:14 <fmeerkoetter> there everybody and its dog is just doing neither...
May 23 13:18:59 <rburton> yeah, that's the sad truth
May 23 13:19:21 <rburton> the "community" doesn't have the manpower to support four year old releases for security updates
May 23 13:19:45 <fmeerkoetter> what other OSVs are there?
May 23 13:20:34 <fmeerkoetter> that also use yocto underneath
May 23 13:20:44 <rburton> fmeerkoetter: https://www.yoctoproject.org/ecosystem/yocto-project-participants is a list of all project members, a fair proportion of those do supported products
May 23 13:23:51 <fmeerkoetter> thank you!
May 23 13:44:35 <BaloneyGeek|work> Hi, is there a recipe/target that enables me to include the entire python standard library in my image?
May 23 13:44:43 <BaloneyGeek|work> There
May 23 13:45:17 <BaloneyGeek|work> There's stuff like argparse and importlib and gettext missing and I don't want to hunt down each package manually and generate an image every time
May 23 13:45:21 <rburton> BaloneyGeek|work: include python3-modules or python-modules in your image
May 23 13:45:32 <rburton> really going to have to backport the fix for this
May 23 13:46:01 <BaloneyGeek|work> rburton:  ERROR: Nothing PROVIDES 'python-modules'. Close matches:
May 23 13:46:19 <BaloneyGeek|work> codecs, idle, dbus, python RPROVIDES python-modules
May 23 13:46:30 <BaloneyGeek|work> But I have python in my IMAGE_INSTALL
May 23 13:46:44 <rburton> yeah, IMAGE_INSTALL should have python-modules in
May 23 13:46:46 <BaloneyGeek|work> That's if I try to bitbake python-modules
May 23 13:47:03 <rburton> python-modules is a *package* built by the python *recipe*
May 23 13:47:12 <BaloneyGeek|work> Ah
May 23 13:47:19 <rburton> just add python-modules to your image and build the image, bitbake will do the rest
May 23 13:48:35 <BaloneyGeek|work> Yeah, that's working
May 23 13:48:37 <BaloneyGeek|work> Thanks
May 23 13:51:36 <Smitty_> Still can't do the simplest thing - this time:  change a project to  also produce an ISO.  It appears there is a variable that I want to use "IMAGE_FSTYPES", and from what I can tell, for some reason I want to put this variable in the file build/conf/local.conf (in the *build directory*).  But this produces an error
May 23 13:52:00 <Smitty_> ERROR: /home/smitty/my_yocto/customdistro/openembedded-core/../meta-custom/recipes-example/images/customimage.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'ISO' - possibly invalid type name or missing support class
May 23 13:52:09 <rburton> lowercase
May 23 13:52:28 <Smitty_> Huh ?
May 23 13:52:33 <rburton> 'iso' not 'ISO'
May 23 13:52:47 <Smitty_> oh my god
May 23 13:57:00 <Smitty_> I guess nobody cares that in fact the FS Type is ISO, and the image file extension is iso - if the system is going to be case sensitive over such things, it should get it right.
May 23 13:58:50 <rburton> Smitty_: the entry in FSTYPES is used to look up variable overrides, which are lowercase
May 23 13:59:03 <rburton> if the documentation is buggy point to where it says ISO and we can fix it
May 23 13:59:04 <top22> Hello, I have the following error "The license listed Proprietary was not in the licenses collected for recipe XXX"; however the Proprietary license does appear in poky/meta/files/common-licenses/
May 23 14:09:34 <Smitty_> So, I totally don't understand how add "iso" to a variable could ahve casue bitbake to have to build so much extra stuff
May 23 14:11:08 <Smitty_> how adding "iso".... could have caused
May 23 14:12:38 <Smitty_> Because the ability to wrote in ISO format is not enabled by default, so the tools required to do so haven't been built ?
May 23 14:12:58 <rburton> assuming that's what its building, yes
May 23 14:18:19 <top21> Hello ! I have a recipe who build a kernel module, i do see the module in the sysroot when i add my recipe to IMAGE_INSTALL. I'm trying now to load the module when booting, I have tried to add my module in KERNEL_MODULE_AUTOLOAD, but it doesn't load the module when booting my image. Can someone help me on this?
May 23 14:21:19 <Smitty_> So, if I always want the ability to  to write an ISO image in my project, I need to provide a local.conf and ensure it somehow gets copied/moved to build/conf/local.conf (probably by way of a customized oe-setup-environment script) ?
May 23 14:24:13 <rburton> Smitty_: or, put it in your distro configuration
May 23 14:24:26 <rburton> which if you say "always" is the correct solution
May 23 14:24:31 <Smitty_> put what in my distro configuration ?
May 23 14:24:35 <rburton> IMAGE_FSTYPES
May 23 14:24:56 <Smitty_> but, it doesn't belong there, it's supposed to go in local.conf
May 23 14:25:01 <Smitty_> isn't it ?
May 23 14:25:06 <rburton> it can go in a configuration file
May 23 14:25:16 <rburton> local.conf is your configuration file for that specific build tree
May 23 14:25:25 <rburton> the distro config is another one, for distro-wide choice
May 23 14:25:36 <rburton> some BSP configuration files set specific IMAGE_FSTYPES too
May 23 14:26:52 <Smitty_> *NOT* understanding this paradigm at all.
May 23 14:27:51 <rburton> if your product is saying "i want an ISO image" then put it in your distro configuration file
May 23 14:28:26 <rburton> whereas if you were saying "i want an iso to test something" then local.conf is appropriate.
May 23 14:30:32 <Smitty_> OK, so, what if I just want the ISO to be a build target ?   Which is really the sensible thing to do, IMHO.  In other words, I'd like to be able to say "bitbake <option to output an iso> customimage"
May 23 14:31:07 <Smitty_> or perhaps "bitbake customimage-iso"
May 23 14:33:51 <Smitty_> I'm guessing that is somehow already supported by adding a new layer which would include that configuration item and define a build target like "customimage-iso"  ??
May 23 14:39:35 <rburton> "bitbake myimage" will make myimage in all the types that you've said myimage can be built in
May 23 14:39:55 <rburton> so you could set IMAGE_FSTYPES inside the image recipe if you only care that one specific image is built as an ISO
May 23 14:40:33 <rburton> ie our build-applicance-image sets IMAGE_FSTYPE=vmdk as it only generates a VM image
May 23 14:41:15 <rburton> whereas qemu machines set IMAGE_FSTYPES to ext4 as it only wants a file system
May 23 14:42:07 <vm_> hi, here https://community.nxp.com/thread/308722 otavio tells, that you can build u-boot with meta-toolchain "by hand" , what commands is he using?
May 23 14:42:42 <Smitty_> Seeprate topic.  I've run up the ISO image inside VMWare Player.  I am being prompted for a root password, I thought it was empty, so press enter.  It is not logging me in
May 23 14:42:47 <rburton> vm_: bitbake meta-toolchain will make a tarball with cross compilers and stuff in
May 23 14:43:30 <vm_> so its better to reconfigure/build with bitbake ?
May 23 14:43:46 <rburton> Smitty_: EXTRA_IMAGE_FEATURES has debug-tweaks enabled by default, worth checking you haven't overridden that
May 23 14:44:06 <Smitty_> I haven't
May 23 14:44:48 <Smitty_> just using your customimage build
May 23 14:44:59 <Smitty_> sorry, customdistro
May 23 14:45:34 <rburton> then you haven't set it
May 23 14:45:39 <rburton> by default != what i did in customdistro
May 23 14:46:15 <rburton> have a look at local.conf.sample for more variables you'll be interested in, such as EXTRA_IMAGE_FEATURES
May 23 14:49:32 <Smitty_> meta-custom/conf/local.conf.sample does not contain EXTRA_IMAGE_FEATURES
May 23 14:50:53 <rburton> sorry, meta/conf/local.conf.sample
May 23 14:51:04 <rburton> the oe-core one, not my almost-nothing one
May 23 14:51:37 <Smitty_> But, I end up using  meta-custom/conf/local.conf.sample, not the one from met
May 23 14:51:39 <Smitty_> meta
May 23 14:51:53 <rburton> yes i know
May 23 14:52:07 <rburton> but i'm saying that for meta-custom i literally deleted almost evertyhing from it
May 23 14:52:22 <Smitty_> are you saying I have to add somehting to EXTRA_IMAGE_FEATURES variable in order for to log in as root with no password ?
May 23 14:52:23 <rburton> and you need more assignments somewhere, which is why the default local.conf.sample is so long
May 23 14:52:25 <rburton> yes
May 23 14:52:36 <rburton> by default, images are not compromisable
May 23 14:52:49 <Smitty_> but, what's the password ?
May 23 14:52:55 <rburton> it isn't set
May 23 14:53:05 <rburton> as i said,  not compromisable
May 23 14:53:43 <rburton> you can add debug-tweaks to EXTRA_IMAGE_FEATURES to get a blank root password so you can login for testing
May 23 14:54:41 <Smitty_> OK, I am starting to understand things a little better.   How would a newbie like me ever figure out that such a thing is essentially a requirement in order to use a totally basic image
May 23 14:55:29 <rburton> beacuse generally a newbie would be using the local.conf.sample which comes in oe-core instead of attempting to construct their own metadistro first.  the one in oe-core has lots of bits enabled out of the box, and lots of comments.
May 23 14:56:05 <rburton> the advice last week was "get it working with local.conf and then adapt to a custom distro when you understand the model"
May 23 14:57:53 <Smitty_> Yeah, must say, this has not been a shallow learning curve.   I'm somehow just not quite "groking" this build system model yet
May 23 14:58:35 <rburton> i really advice one step at a time - ignore building a custom distro and repos, just stick with local.conf modifications to get what you want working
May 23 14:58:54 <nvld> Hi guys, is there any way to "append" or override a bbclass file ? I don't want to edit directly the bbclass file, and if I put a different version in another layer (even with a greater priority), it is not used.
May 23 14:58:54 <Crofton|work> +1
May 23 14:59:13 <kergoth> nvld: you can override it by using the correct order in BBLAYERS. the first one found will be used
May 23 14:59:43 <kergoth> specifically the first one found in BBPATH will be used, but the two are usually the same given how layer.conf files adjust BBPATH
May 23 15:00:03 <Crofton|work> clearly we need to apply machine learning to distro building
May 23 15:04:04 <Smitty_> So, why doesn't including the meta layer bring in its conf ?
May 23 15:04:10 <Smitty_> I mean, how does that work
May 23 15:04:23 <Smitty_> How does mandatory stuff not get lost ?
May 23 15:05:17 <nvld> Oh thank's, I checked the BBPATH var but did not know how to ajdust the order. I'm trying to build it right now :)
May 23 15:05:51 <kergoth> nvld: each layer in bblayers gets its layer.conf parsed. each layer.conf adds the layer to BBPATH (so bitbake can find .conf and .bbclass files) and adds its recipes to BBFILES, so they can be parsed
May 23 15:05:53 <kergoth> np
May 23 15:07:27 <Smitty_> So, why would meta/conf/layer.conf get parse, but not meta/conf/local.conf ?
May 23 15:37:11 <rburton> Smitty_: every layer has a layer.conf.  oe-core has a local.conf.sample, which is a template.
May 23 15:38:24 <kergoth> generally speaking we don't like it when layers automatically enable functionality when they're included. we prefer the ability to include any number of layers, and control what functionality is enabled from the distro, machine, or local.conf. distros shouldn't affect the build unless we change our distro to that one, same for machines with their layers, and other random layers as well. It's actually part of the yocto compliance/compatibility criteria
May 23 15:41:27 <rburton> Smitty_: the important thing is that meta/conf/local.conf doesn't exist.
May 23 15:42:28 <Smitty_> aha
May 23 15:45:12 <Smitty_> where's the guidance over what belongs in each file.  because looking at the various flavors of conf, bb, etc.. files, I see lots of duplication sometime I find, for example BBFILES and BBPATH being set in more than one file in the same layer's configuration files (e.g. both layer.conf and bblayers.conf)
May 23 15:46:41 <rburton> all layers will *extend* those
May 23 15:46:59 <rburton> as that's pretty much what the job of layer.conf is for
May 23 16:42:08 <SomeDumbBumb_> So, why do they also show up in bblayers.conf ?
May 23 17:32:16 <SomeDumbBumb_> rburton: why do BBFILES and BBPATH get modified in layer.conf and bblayers.conf ?
May 23 17:56:55 <Crofton|work> hmm, where is the yocto-layer script?
May 23 18:02:42 <kergoth> Crofton|work: meta-yocto/meta-poky, for some reason. i guess due to its name?
May 23 18:03:11 <kergoth> should really go into oe-core or bitbake-layers + oe-core templates or something
May 23 18:03:16 * kergoth shrugs
May 23 18:03:47 <Crofton|work> yeah
May 23 18:03:51 <Crofton|work> in dev manual
May 23 18:04:08 <Crofton|work> can be done by hand, just confusing how the stuff is split
May 23 18:04:19 <kergoth> it's pretty obviously generally useful, particularly combined with bitbake-layers, for scripting
May 23 18:04:19 <Crofton|work> especially once you create your own distro, you lose tools
May 23 18:04:25 <kergoth> yocto-layer create + bitbake-layers add-layer, ..
May 23 18:07:03 <kergoth> should open a bug to get it moved into oe-core
May 23 18:08:51 <joshuagl> please do
May 23 18:13:55 <Crofton|work> I'll do it
May 23 18:36:17 <vm_> if i do bitbake -e u-boot  it tells me Nothing provides "u-boot"    but i build raslpberry-pi with u-boot
May 23 18:38:30 <vm_> how can i find out what u-boot the raspberry recipe uses
May 23 18:38:36 <kergoth> bitbake -e virtual/bootloader | grep \^FILE=
May 23 18:38:43 <kergoth> or PN=, take your pick
May 23 18:39:55 <vm_> both return nothing
May 23 18:40:27 <kergoth> remove the grep, what's the error?
May 23 18:40:57 <vm_> nothing provide virtual/bootloader
May 23 18:41:41 <vm_> i have build this image with toaster, perhaps this changed something
May 23 18:42:29 <Crofton|work> Done: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11567
May 23 18:42:30 <yocti> Bug 11567: normal, Undecided, ---, paul.eggleton, NEW , Trying to create an new layer with the yocto-layer script fails.
May 23 18:45:39 <vm_> also the last command was bitbake meta-toolchain, with this pkg-name i get an environment back with bitbake -e meta-toolchain
May 23 18:46:12 <vm_> do i need to run bitbake core-image-minimal again to get bitbake -e virtual/bootloader
May 23 18:50:21 <vm_> seemed that building with toaster and then try to go on on cmdline is a bad thing
May 23 18:51:10 <vm_> why does toaster not simply goes the normal way
May 23 21:12:23 <joshuagl> seebs: hi! a colleague just sent a pseudo patch to yocto@, your feedback would be appreciated
May 23 21:16:14 <ant_home> zeddii, around?
May 23 21:29:21 <seebs> I'm not sure I'm on yocto@. forward?
May 23 21:30:52 <joshuagl> will do
May 23 21:32:20 <joshuagl> seebs: sent
May 23 21:35:43 <Crofton|work> -ETOOMANYLISTS :(
May 23 22:29:45 <seebs> joshuagl: thank you. yeah, i'll merge that. so funny trivia point: clinically, i am not *quite* dyslexic. but i'm sorta close.
May 23 22:30:59 <paulg> I dnot beleive taht.
May 23 22:39:44 * paulg has known seebs for quite a few years -- just in case anyone thought I was just being a drive-by jerk.
May 23 22:40:13 <seebs> no the funny thing is i read that and thought "haha he switched letters in 'that' to make fun of me"
May 23 22:40:52 <Crofton|work> lol
May 23 22:41:05 <seebs> about 70-80% of pseudo's "i thought i fixed this but it won't compile" have involved things like reversing the orders of words in #defines, etc
May 23 23:23:22 <berndhs> hello folks, I'm trying to build for a raspi3
May 23 23:24:03 <berndhs> when I run bitbake, it tells me that MACHINE=raspberrypi3 is invalid
May 23 23:24:28 <berndhs> how do I add the meta-raspberry stuff to the configurations ?
May 23 23:25:51 <berndhs> is anyone here?
May 23 23:37:57 <itseris> Have you added meta-raspberry to your conf/bblayers.conf file?
May 23 23:38:48 <paulg> for example...
May 23 23:38:50 <paulg> --------------
May 23 23:38:54 <paulg> BBLAYERS ?= " \
May 23 23:38:54 <paulg>   /home/paul/poky/meta \
May 23 23:38:55 <paulg>   /home/paul/poky/meta-poky \
May 23 23:38:55 <paulg>   /home/paul/poky/meta-raspberrypi \
May 23 23:38:55 <paulg>   /home/paul/poky/meta-openembedded/meta-oe \
May 23 23:38:55 <paulg>   /home/paul/poky/meta-openembedded/meta-oe \
May 23 23:38:59 <paulg>   /home/paul/poky/meta-openembedded/meta-python \
May 23 23:39:01 <paulg>   /home/paul/poky/meta-openembedded/meta-networking \
May 23 23:39:03 <paulg>   /home/paul/poky/meta-yocto-bsp \
May 23 23:39:05 <paulg>   "
May 23 23:39:07 <paulg> -------------
May 23 23:39:41 <berndhs> ah let me try that
May 23 23:39:47 * paulg notes he has meta-oe 2x
May 23 23:40:06 <paulg> that makes it twice as good, right?
May 23 23:41:47 <berndhs> ah it is much mroe persistent now
May 23 23:41:54 <berndhs> there is hope :)
May 23 23:42:53 <paulg> good to hear.
May 23 23:43:28 <berndhs> i figured for my robots, i will use a raspi and soem arduinos to control the legs
May 23 23:43:50 <berndhs> so i want yocto for the raspi main body brain
May 23 23:44:10 <berndhs> rahter than fedora or opensuse or something
May 23 23:45:27 <paulg> GNU Hurd on rpi3.    I'd pay $ to see that.  :)
May 23 23:47:17 <berndhs> oh i'm not that ambitious
May 23 23:47:47 <berndhs> just want to make small robots for house and garden
May 23 23:47:56 <berndhs> maybe for small farms
May 23 23:48:05 <berndhs> so the people can eat :)
May 23 23:51:27 <paulg> well, good luck ; we'll help with questions as we can.
May 23 23:52:35 <berndhs> all right, thank yiou
May 24 00:47:23 <Crofton|work> clearly we need meta-hurd
May 24 00:49:43 <paulg> Crofton|work, don't be pinning that crime on me.  :)
May 24 00:50:23 <Crofton|work> meta-buildroot exists
May 24 00:50:45 <paulg> you mean meta-brainrot ?
May 24 00:51:00 <Crofton|work> lol
May 24 02:13:52 <berndhs> so after bitbake is done building, where does it put the resulting image?
May 24 02:47:27 <Crofton|work> berndhs, tmp-glibc/deploy/image....
May 24 02:48:29 <dolapevich> Good Morning, afternoon, night, I am getting 14 kb while clonning yocto kernel
May 24 02:48:33 <dolapevich> is it expected?
May 24 02:48:39 <dolapevich> linux-yocto-4.8.12+gitAUTOINC+c19322afb1_021b4aef55-r0 do_fetch (pid 25171)  10% |##                     | 16.3K/s
May 24 02:49:06 <berndhs> Crofton|work: yes, i found it, thank you
**** ENDING LOGGING AT Wed May 24 03:00:04 2017