**** BEGIN LOGGING AT Fri Nov 30 03:00:00 2018
Nov 30 07:34:19 <thebigj> I am trying to customize Raspbian distribution. Can anyone share any good tutorial teaching customizing Raspbian using Yocto?
Nov 30 07:35:19 <thebigj> Please clear me if I am making any mistake in understanding the Yocto tool.
Nov 30 08:36:04 <yocti> New news from stackoverflow: DEBUG_FLAGS in Yocto is always used <https://stackoverflow.com/questions/53553756/debug-flags-in-yocto-is-always-used>
Nov 30 08:36:25 <mckoan> thebigj: raspbian != yocto
Nov 30 08:40:28 <thebigj> mckoan: I agree with you. This is mainly because I landed on Yocto from Google search.
Nov 30 08:40:34 <thebigj> mckoan: Thanks for clearification. :)
Nov 30 09:06:12 <yocti> New news from stackoverflow: Error occurred when run application with -platform eglfs <https://stackoverflow.com/questions/53554227/error-occurred-when-run-application-with-platform-eglfs>
Nov 30 10:27:36 <kanavin> RP: cheers :)
Nov 30 11:18:07 <la_croix> Can anybody point me in the right direction to implement this: https://github.com/seemoo-lab/nexmon I currently have a wifi functioning on the pi, but no monitor mode. I have, in the past, got these instructions working on raspbian, but I'm not sure how to do it during the yocto build process
Nov 30 11:36:42 <yocti> New news from stackoverflow: How to include files in Cstom recipe for yocto build <https://stackoverflow.com/questions/53556701/how-to-include-files-in-cstom-recipe-for-yocto-build>
Nov 30 14:16:36 <laumann> LetoThe2nd: hi, just wanted to thank you for your assistance the other day. Turned out I also needed to set the date to make SSL certificates work ¯\_(ツ)_/¯
Nov 30 14:44:16 <yates> does yocto "tweak" CXXFLAGS to its liking when do_compile()ing C++ code? or am i free to set these flags in my own make file as i wish?
Nov 30 14:46:46 <yates> my current makefile builds up a nice list of options and sets CPPFLAGS, but if I disable that, then i have to duplicate all the flag settings in the recipe's CXXFLAGS += xyz, which seems like a maintainaability issue
Nov 30 14:47:58 <yates> (noting that my makefile is used to compile in other environments, e.g., natively under desktop linux)
Nov 30 14:49:17 <yates> or am i missing something? some way to do this in a more sane manner?
Nov 30 14:52:31 <kergoth> oe exports CXXFLAGS and other similar variables. there are ways to allow such to be set in you rmakefile and still append or alter them
Nov 30 14:53:11 <kergoth> ?= and hten += is enough if it's set in the environment, but if it's being passed on the cmdline or otherwise forced iwth make -e (check your EXTRA_OEMAKE) then you might need constructions like "override CXXFLAGS += foo"
Nov 30 14:53:28 <kergoth> see also the gnu make online manual, which is quite well done imo, i've often used it as a reference when working on my makefiles
Nov 30 14:54:08 <kergoth> alternatively, use a separate variable for flags that are required to build from those the distro/packager might want to set
Nov 30 14:54:26 <kergoth> i.e. the latter could set optimization flags, but the former flags required to compile
Nov 30 14:54:31 <kergoth> which is fairly common
Nov 30 14:59:42 <yates> ok, thanks for the ideas kergoth
Nov 30 15:00:44 <kergoth> it's common for distro and packaging folk to need to set such flags. gentoo, debian, etc. pretty common practice, so there's value in supporting it
Nov 30 15:00:50 <kergoth> we're no exception there
Nov 30 15:07:20 <yates> what's the difference between BUILD_CXXFLAGS and CXXFLAGS?
Nov 30 15:07:25 <yates> i read the man, but i don't get it
Nov 30 15:07:37 <yates> what is "the build host"
Nov 30 15:42:00 <rburton> yates: BUILD_* is for native
Nov 30 15:57:53 <kergoth> aye, build host is the machine you're building on, not the board you're targeting
Nov 30 16:36:29 <kergoth> Hmm. I want vmlinux built and installed in my sdk target sysroot, but *not* installed in every freaking image by default, since I only want it for debugging. there's no clean way to do this, since kernel.bbclass uses rdepends for both kernel-image and kernel-base. suppose i can alter RDEPENDS_kernel-base to not puill in kernel-image, but explicitly pull in every image but vmlinux by default, only in the case where vmlinux is in KERNEL_IMAGETYPES but
Nov 30 16:36:29 <kergoth>  isn't the only entry in imagetypes.. or i could use a packagefunc to convert the aforementioned rdepends to rrecommends so i could use PACKAGE_REMOVE to remove vmlinux only from specific images..
Nov 30 16:36:33 <kergoth> thoughts?
Nov 30 16:37:50 <kergoth> s/built/built, deployed,/
Nov 30 17:42:46 <rburton> kanavin: are you working on a meson upgrade?
Nov 30 17:53:24 <Dvorkin> How to easily build linux kernel without patches from kernel-meta ? I'm setting LINUX_KERNEL_TYPE = "tiny", but it doesn't help. The KTYPE is tiny, but all patches are applyed anyway
Nov 30 18:37:33 <khem> Dvorkin: patches are not going to make your resulting kernel bigger
Nov 30 18:37:39 <khem> its the config you choose
Nov 30 19:14:55 <khem> RP: I am not able to reproduce the exportfs crash, it seems AB testng is doing something more than bitbake -ctestimage core-image-sato-sdk
Nov 30 19:15:18 <khem> I tried to run exportfs manually
Nov 30 19:15:25 <khem> and it never crashed on me
Nov 30 20:08:15 <yocti> New news from stackoverflow: Kernel compilation in Yocto, what to define? <https://stackoverflow.com/questions/37764174/kernel-compilation-in-yocto-what-to-define>
Nov 30 20:34:39 <yates> shouldn't the {S} directory change accordingly when bitbaking inside a devtool modify context?
Nov 30 20:34:49 <yates> it snot
Nov 30 20:35:05 <yates> still pointing inside tmp/work
Nov 30 20:35:14 <kergoth> it uses externalsrc, which uses different variables to adjust it
Nov 30 20:35:22 <kergoth> i don't recall why offhand
Nov 30 20:36:35 <yates> do you mean ${externalsrc} points to the temporary src directory?
Nov 30 20:37:13 <yates> i.e., build/src/blah?
Nov 30 20:40:29 <kergoth> no, i mean externalsrc.bbclass in oe-core
Nov 30 20:41:03 <kergoth> see the contents of the class for details
Nov 30 20:41:30 <kergoth> devtool modify just enables the class for the recipe in question
Nov 30 20:43:06 <kergoth> there we go, https://github.com/MentorEmbedded/meta-mentor/compare/sumo...kergoth:vmlinux does what i was asking about earlier, along with KERNEL_IMAGETYPES_append = " vmlinux"
Nov 30 20:43:09 <kergoth> (OT)
Nov 30 20:51:25 <yates> if i am NOT in a devtool modify context (i.e., normal build environment), and i do a "bitbake <recipe> -c do_compile()", will yocto always do JUST the do_compile, or might it do_unpack() (e.g.)?
Nov 30 20:51:48 <kergoth> -c doesn't s kip dependencies
Nov 30 20:52:11 <kergoth> so yes, it'll unpack and patch if necessary normally
Nov 30 20:52:15 <kergoth> externalsrc obviously skips those
Nov 30 20:52:57 <yates> is there an option to perform an isolated task without dependencies (apart from using devtool)?
Nov 30 20:54:53 <yates> kergoth: i had a look at externalsrc. my python-foo is very weak, and i'm not getting it. it looks like i must modify my recipe to account for the possibility that the build is external (e.g., conditional B settings and whatnot), which seems nasty...
Nov 30 20:56:05 <kergoth> i don't see why you'd have to do that, or why your buildsystem would care where it's being built at all for that matter
Nov 30 21:01:56 <yates> i don't see why yocto can't provide the top level src directory independent of mode
Nov 30 21:02:28 <yates> ${S} is not always as defined, which is not good.
Nov 30 21:03:55 <khem> RP: finally I am able to reporduce it !!!
Nov 30 21:04:27 <khem> I need to have / *(rw,no_root_squash,async,no_subtree_check) in /etc/export and then launch it like exportfs -a
Nov 30 21:04:43 <khem> I wonder why this does not work with plain oe-core
Nov 30 21:04:47 <khem> are there differences ?
Nov 30 21:05:09 <khem> between how core-image-sato-sdk is built for poky and for oe-core
Nov 30 22:03:55 <yates> in my log.do_compile i'm getting positive integer numbers at the beginning and end of the the lines right after the compile command. what do they mean? https://paste.fedoraproject.org/paste/bfc-ZSJXo7HC6AFyO58Q7Q
Nov 30 22:05:45 <yates> or are those from the compiler/preprocessor?
Nov 30 22:24:14 <yates> nm
Nov 30 22:24:59 <yates> wall
Nov 30 22:25:01 <yates> ^^^
Nov 30 22:25:04 <yates> |||
Nov 30 22:25:07 <yates> head
Nov 30 22:26:46 <yates> why is main not being picked up from the crt1 assembly code? https://paste.fedoraproject.org/paste/i9BfuqRgXju6DEXKj9UN7Q
Nov 30 22:27:16 <yates> or rather from start.S
Nov 30 22:31:26 <RP> khem: There may be an extra package for qemu images in poky
Nov 30 22:31:33 <RP> khem: glad you could reproduce though
Nov 30 22:38:03 <yates> nm, another brain-fart.
Nov 30 22:53:46 <khem> RP: Its a bug in nfs-utisl
Nov 30 22:53:59 <khem> RP: I will send a fix + upgrade for nfs-utils
Nov 30 22:55:49 <RP> khem: sounds good thanks! Weird we didn't hit it before then?
Nov 30 22:57:46 <khem> RP: we did not hit it since musl implemented freeaddrinfo lately see https://github.com/kraj/musl/commit/d1395c43c019aec6b855cf3c656bf47c8a719e7f#diff-672f96f3c22a03ffd10dca4ef0bc6f11
Nov 30 22:58:41 <khem> exportfs passes null pointer which is valid for free but the new implementation does not use simple free and it was undefined behaviour anyway so exportfs is/was relying on ub from libc
Nov 30 23:01:10 <RP> khem: ah, hmm
Dec 01 01:11:45 <khem> RP: posted the patches, please add them + musl v2 patch
**** ENDING LOGGING AT Sat Dec 01 03:00:00 2018