**** BEGIN LOGGING AT Wed Sep 14 02:59:58 2016
Sep 14 03:00:25 <Ulfalizer> could open a devshell too and check if it's available in the FC environment variable. that seems to be the fortran equivalent to CC.
Sep 14 03:00:31 <Ulfalizer> if nothing else, it'll tell you where it's supposed to be :P
Sep 14 03:03:37 <Ulfalizer> or hrm... that just has the name it would have
Sep 14 03:07:53 <Ulfalizer> dangpzanco: are you trying to install a fortran compiler into the target compiler, or trying to cross-compile a fortran program btw?
Sep 14 03:09:53 <fenrig> Hi, Im having troubles with adding my own recipe and using hard floats
Sep 14 03:10:21 <fenrig> I'm getting "gnu/stubs-soft.h: No such file or directory"
Sep 14 03:10:21 <fenrig> for raspberry pi3
Sep 14 03:10:32 <fenrig> Its a cmake project, so probably have to change something in cmakelist ?
Sep 14 03:11:00 <fenrig> I've already tried "EXTRA_OECONF_GCC_FLOAT = "${@get_gcc_float_setting(bb, d)}" "
Sep 14 03:11:05 <Ulfalizer> the instructions on the page you linked seem to be the first case. if you're trying to cross-compile, you probably need the -cross version of the recipe that builds the fortran compiler. maybe that's the gcc-cross recipe though, and it'd be weird if that hadn't already gotten built.
Sep 14 03:12:33 <dangpzanco> i tried doing this: bitbake -f -c compile gcc
Sep 14 03:12:37 <dangpzanco> https://gist.github.com/dangpzanco/5e573970f42914bb7ac5bdbb0640f7f9
Sep 14 03:12:42 <dangpzanco> the log file ^
Sep 14 03:13:03 <dangpzanco> Ulfalizer
Sep 14 03:13:51 <Ulfalizer> ok, don't know what the problem is. mailing list might be more helpful.
Sep 14 03:13:52 <dangpzanco> i'm trying to install gfortran to the galileo board
Sep 14 03:14:04 <dangpzanco> yocto mailing list?
Sep 14 03:14:26 <Ulfalizer> yup, https://www.yoctoproject.org/tools-resources/community/mailing-lists
Sep 14 03:14:38 <dangpzanco> thanks for your help
Sep 14 03:14:42 <dangpzanco> : )
Sep 14 03:17:09 <fenrig> Can I maybe pass another CFLAG from within my recipe?
Sep 14 03:17:42 <fenrig> Can I maybe pass another CFLAG from within my recipe?
Sep 14 03:26:58 <Ulfalizer> dangpzanco: did you try a plain 'bitbake gcc' too?
Sep 14 05:11:40 <bluelightning> iskander: FYI, I just sent a fix for the eSDK bblayers path bug you mentioned yesterday
Sep 14 09:03:46 <present_> Hiiii
Sep 14 09:09:25 <iskander_work> hello
Sep 14 09:10:06 <iskander_work> the libgfortran packages installas files which are not packaged, installed-vs-shipped problem
Sep 14 09:10:31 <iskander_work> the reason is that rmdir is used to cleanup install dir but it works only for empty dirs
Sep 14 09:11:36 <iskander_work> a bug ?
Sep 14 09:11:49 <iskander_work> rm -rf fixed the issue
Sep 14 09:12:20 <boucman_work> what files are left behind ? who should theoretically package them ?
Sep 14 09:12:35 <iskander_work> mompls
Sep 14 09:13:24 <iskander_work> /usr/lib/gcc/arm-poky-linux-gnueabi/5.3.0/finclude/*
Sep 14 09:13:55 <iskander_work> finclude contains a couple of files:   /usr/lib/gcc/arm-poky-linux-gnueabi/5.3.0/finclude/ieee_exceptions.mod
Sep 14 09:13:55 <iskander_work>   /usr/lib/gcc/arm-poky-linux-gnueabi/5.3.0/finclude/ieee_features.mod
Sep 14 09:13:55 <iskander_work>   /usr/lib/gcc/arm-poky-linux-gnueabi/5.3.0/finclude/ieee_arithmetic.mod
Sep 14 09:13:55 <iskander_work>  
Sep 14 09:14:14 <iskander_work> the package is libgfortran
Sep 14 09:15:03 <iskander_work> the package uses 'rmdir' inside 'do_install' to clean up the install dir but it doesn't work due to 'rmdir' limitations
Sep 14 09:15:30 <iskander_work> i'm using the latest krogoth
Sep 14 09:16:28 <iskander_work> should i submit a bug report ?
Sep 14 09:20:09 <Ulfalizer> iskander_work: looks buggy to me too. if anything ends up in ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/finclude
Sep 14 09:20:17 <Ulfalizer> , you'll get a packaging error.
Sep 14 09:20:31 <iskander_work> it works only if finclude is empty
Sep 14 09:20:54 <Ulfalizer> yup
Sep 14 09:22:03 <Ulfalizer> my guess is that the rmdirs are there to remove the directories if they turn out empty
Sep 14 09:22:35 <Ulfalizer> but the case where finclude is not empty isn't properly handled. it'd need to included in one of the FILES variables so that it's packaged.
Sep 14 09:22:46 <Ulfalizer> dunno where it's supposed to go. i'm a fortran noob.
Sep 14 09:23:19 <Ulfalizer> prolly FILES_${PN}-dev
Sep 14 09:23:47 <iskander_work> my fix was to replace rmdir with 'rm -rf'
Sep 14 09:24:39 <Ulfalizer> i think that breaks the original intent. proper fix might be to extend FILES_${PN}-dev.
Sep 14 09:24:59 <Ulfalizer> but look up what those files are, and if it makes sense to package them
Sep 14 09:25:05 <Ulfalizer> def. looks like a bug in the recipe at least
Sep 14 09:27:03 <iskander_work> thanks
Sep 14 09:31:23 <fragfutter> why is my build folder build/tmp-glibc , wasn't that build/tmp ?
Sep 14 09:35:03 <iskander_work> what is the meaning of:  Invalid inode value in BB_DISKMON_DIRS: 1gK
Sep 14 09:35:06 <iskander_work> ?
Sep 14 09:35:29 <fragfutter> missing , ?
Sep 14 09:35:44 <fragfutter> check build/conf/local.conf
Sep 14 09:35:47 <jonver> belen: Hi! Do you know if (in toaster) the repo of embedded-core is set to 'remote:origin' or if this is a wrong configuration on my part? I have a build error which states I cannot clone ('git clone "remote:origin" "mylocaldir"). Thanks!
Sep 14 09:36:14 <iskander_work> fragfutter: thanks, that was a typo
Sep 14 10:18:55 <belen> jonver: I am not sure. Let me ask. When you created your project, which release did you choose?
Sep 14 10:19:42 <jonver> belen: Yocto Project 2.0 Jethro
Sep 14 10:25:18 <michaelw1> jonver: Is that the project release or the release of the poky that you're using?
Sep 14 10:25:54 <michaelw1> Usually only the "local project" will have those funny "remote:origin" as the source for oe-core
Sep 14 10:52:28 <RP1> rburton: Just as a status for -next, Bruce has fixed the kernel repo problem, robert the runqemu race, I've fixed the gplv3 issue with my patch and joshuagl fixed the vnc issue so I'm trying a new build
Sep 14 11:00:32 <rburton> great lets see what falls out of that
Sep 14 11:00:37 <rburton> shall rebase
Sep 14 11:19:59 <jonver> michaelw1: i've cloned via "repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-4.1.15-1.0.0_ga; repo sync" and then i start toaster from the poky dir. I now see that starting toaster displays this error: http://pastebin.com/XQWRTf2U
Sep 14 11:29:31 <michaelw1> jonver: hmm I'm not sure about the implications of using 'repo', have you tried using a clean poky clone, checked out at jethro? (if that's the release you're wanting) and then should be a matter of "source oe-init-build-env and then source toaster start" you should then get toaster up and running in the default state. You can then go to "import" layer if the layer isn't already available and put those details in to the import form and Toaster will manage c
Sep 14 11:29:38 <michaelw1> -> lunch
Sep 14 11:30:39 <jonver> michaelwl: thanks, will try that
Sep 14 11:36:08 <Anticom> Hi all. How would i write a recipe, that only installs a library and its headers (cmake based project) so i can include those headers and link against the lib in another recipe?
Sep 14 11:36:20 <Anticom> (without creating a package that would be installed on the device of course)
Sep 14 11:36:41 <rburton> write a recipe as you usually would, and statically link
Sep 14 11:36:56 <fragfutter> Anticom: normal recipe. DEPENDS and RDEPENDS are seperate.
Sep 14 11:37:49 <Anticom> fragfutter: is there a good example in oe-core i can take a look at?
Sep 14 11:37:59 <Anticom> it's been ages since i've written my last recipe :S
Sep 14 11:38:19 <rburton> just inherit cmake and you'll be done
Sep 14 11:38:29 <rburton> after SRC_URI etc
Sep 14 11:39:39 <Anticom> rburton: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/log4cplus/log4cplus_1.1.1.bb?h=jethro like so? (except with inherit cmake instead of autotools)
Sep 14 11:40:08 <fragfutter> and minus BBCLASSEXTEND
Sep 14 11:40:17 <Anticom> Okay thanks
Sep 14 11:41:03 <Anticom> And where would you place recipes of libraries? recipes-support ?
Sep 14 11:41:52 <rburton> your layer, so anywhere you want
Sep 14 11:42:55 <Anticom> rburton: Was just asking for a recommendation ;)
Sep 14 11:53:46 <Anticom> So this would be sufficient? http://pastebin.com/raw/b8i0kUpz
Sep 14 12:49:10 <rburton> roaring success
Sep 14 13:04:47 <fenrig> Hi does anybody know how I go about enabling sound in yocto build for rpi3? when I modprobe snd_bcm2805 I still have no audio devices
Sep 14 13:08:58 <fenrig> found dtparam=audio=on - this will probably fix it
Sep 14 13:29:33 <sveinse> How do you determine when to add some host build tools (used by recipes) as native recipes vs. just adding them as a part of the meta layers?
Sep 14 13:32:47 <rburton> sveinse: i think you need to expand your question as a native recipe is part of a layer
Sep 14 13:34:09 <RP> rburton: thankfully builds as looking much happier this time
Sep 14 13:36:06 <sveinse> rburton: E.g. we have our own product packager which takes a sdcard image coming from wic. This tool is thus run as a part of generating our artefacts. So we need to have a repo to put and maintain this tool. So either we put this tool in a separate repo and include it as we do for other metas. Or we make a native recipe and embed the tool into the host sysroot. With the latter one can...
Sep 14 13:36:08 <sveinse> ...distribute the tool in a SDK.
Sep 14 13:36:55 <sveinse> Did that make any sense?
Sep 14 13:38:10 <rburton> well, either works
Sep 14 13:38:19 <rburton> your software, your choice.
Sep 14 13:39:15 <sveinse> rburton: yes, but I'm trying to assess if there are any best practices to when to do what
Sep 14 13:39:28 <rburton> do you want the tool in a sdk?  if so then you need a recipe for it
Sep 14 13:43:31 <sveinse> Yes. I guess this once more boils down to change/repo management. Yocto has great downfacing CM, where specific upstream versions and repos are used. While on top its left to the system builder to provide one.
Sep 14 14:04:39 <fenrig> Hi
Sep 14 14:05:57 <fenrig> i would like to know how to add detection of hard and soft float in cmakelists.txt, yesterday I had to add my own "set(CMAKE_C_FLAGS "-std=gnu99 -Wall -mfloat-abi=hard -mfpu=neon")" but I would like to make it dynamic
Sep 14 14:34:19 <rburton> fenrig: why not just respect the cflags that are being passed in?
Sep 14 14:58:37 <rburton> RP: master looks well, just need that tiff patch from jku.
Sep 14 15:00:36 <fenrig> rburton: how do I respect the cflags, essentialy thats the question
Sep 14 15:01:00 <fenrig> rburton: or do I override them by setting them in cmakelists
Sep 14 15:02:07 <kergoth> setting them in cmakelists is wrong, obey our variables
Sep 14 15:02:09 <rburton> fenrig: CMAKE_C_FLAGS should contains all cflags that your BSP sets.  just use that and make sure you don't replace it with something else.
Sep 14 15:02:27 <rburton> (i've seen cmakelists assign to that for their extra flags instead of extending)
Sep 14 15:02:42 <RP> rburton: and the race fix from Anibal
Sep 14 15:03:02 <ZubairLK> Hi guys
Sep 14 15:03:03 <ZubairLK> In a linux-yocto bbappend file, I'm struggling to append SRC_URI 'just' for a specific machine. Its a kernel config fragment.
Sep 14 15:03:03 <ZubairLK> Is that possible?
Sep 14 15:03:03 <ZubairLK> I basically do a SRC_URI_machine += "file://fragment.cfg"
Sep 14 15:03:20 <fenrig> how do i go about extending them in for this cmake program compilation?
Sep 14 15:04:06 <kergoth> ZubairLK: SRC_URI_append_machine = " file://fragment.cfg"
Sep 14 15:04:08 <ZubairLK> oops. my bad.
Sep 14 15:04:15 <kergoth> ZubairLK: see the bitbake manual for details on how overrides work
Sep 14 15:04:21 <ZubairLK> thanks. typo in the machine string.
Sep 14 15:04:21 <rburton> fenrig: http://stackoverflow.com/a/29901579/1389358
Sep 14 15:04:27 <ZubairLK> thanks kergoth
Sep 14 15:04:35 <kergoth> ZubairLK: SRC_URI_machine += will override all of SRC_URI for that machine, not what you want
Sep 14 15:04:36 <fenrig> rburton: okay ill take a look
Sep 14 15:04:56 <kergoth> it'll first immediately append to 'SRC_URI_machine', then SRC_URI_machine will override SRC_URI
Sep 14 15:04:57 <rburton> fenrig: you're now into 'how do i use cmake' fwiw
Sep 14 15:05:26 <rburton> fenrig: our cmake class passes the BSP cflags to cmake, so if your build isn't respecting them then you need to fix the cmakelists
Sep 14 15:05:46 <rburton> RP: yes and that
Sep 14 15:05:48 <ZubairLK> kergoth: aah. thanks for the explanation!
Sep 14 15:06:20 <fenrig> rburton: THX :D that probably fixes it, the project i was using used to override them :)
Sep 14 17:29:53 <kergoth> khem: with gcc 5.3, when you get undefined __atomic symbols, do you just need to add a link to atomic? does the toolchain add that automatically, or does the buildsystem need to do it?
Sep 14 17:30:33 <khem> you have to link it manually
Sep 14 17:30:38 <kergoth> k, thanks
Sep 14 17:30:54 <khem> is it arm ?
Sep 14 17:31:37 <kergoth> i think so, a coworker is building a cmake project, but looks like it's missing handling of libatomic, so fails at link time
Sep 14 17:33:57 <kergoth> llvm's CheckAtomic.cmake looks promising
Sep 14 17:38:07 <khem> yes
Sep 14 18:02:42 <kergoth> khem: is the external libatomic-ops is for older toolchains that don't include libatomic?
Sep 14 18:52:55 <_markfeatherston> Could someone help me understand how the glibc-locales recipes is split to provide multiple packages?
Sep 14 18:53:51 <_markfeatherston> I see that it is using PACKAGES_DYNAMIC to claim to be multiple packages, but the documentation suggests there should be a do_split function for this recipe which I can't find.
Sep 14 18:58:49 <kergoth> _markfeatherston: generally a recipe prepends to populate_packages or adds a function to PACKAGESPLITFUNCS, but a certain amount of locale splitting is actually done for all recipes by package_do_split_locales in package.bbclass.
Sep 14 19:01:23 <_markfeatherston> ahh, there it is.  Thanks
Sep 14 19:02:39 <kergoth> np
Sep 14 19:02:44 <kergoth> reading package.bbclass may be informative
Sep 14 19:02:49 <kergoth> there's a lot done there
Sep 14 19:02:59 <_markfeatherston> Yeah, I'm looking through that now
Sep 14 20:35:11 <ionte_> hi. i'm writing here again in hope someone can help me. i have just switched from one kernel recipe to another and now i get this error: https://gist.github.com/jomag/50dadc4a7fe0d890aae21eb0a37aa987
Sep 14 20:35:47 <ionte_> i have no idea what's happening. it seems to look for a license in kernel 4.6.7, which is the old kernel.
Sep 14 20:36:55 <bluelightning> ionte_: what exactly did you change?
Sep 14 20:39:00 <ionte_> bluelightning: i changed "PREFERRED_PROVIDER_virtual/kernel" from "linux-amun" to "linux-amun-ti"
Sep 14 20:39:28 <bluelightning> hmm, if it's that simple I wonder if I can reproduce that here
Sep 14 20:39:43 <ionte_> i guess not
Sep 14 20:41:05 <ionte_> the linux-amun recipe has been working well for months. linux-amun-ti is new and it's a copy of linux-amun but with a different source and kernel version. that's it.
Sep 14 20:41:33 <bluelightning> ok, so it should be reasonably easy to trigger by the sounds of it
Sep 14 20:43:27 <ionte_> if i change back to linux-amun it builds with no errors
Sep 14 20:46:28 <ionte_> i've updated the gist with both kernel recipes: https://gist.github.com/jomag/50dadc4a7fe0d890aae21eb0a37aa987
Sep 14 20:58:52 <Ulfalizer> ionte_: try removing tmp/ and building again. looks like it can't find the package metadata for the new kernel some reason.
Sep 14 20:59:26 <Ulfalizer> it'll get repopulated from the sstate cache, so it probably won't cause horrible slowness
Sep 14 21:00:35 <Ulfalizer> the latest version of the reference manual (2.2) just got some more documentation on PKGDATA_DIR (that's that pkgdata/ directory) and what it's used for btw
Sep 14 21:03:14 <ionte_> Ulfalizer: ok, i'll try that
Sep 14 21:04:00 <ionte_> Ulfalizer: actually, i thought the sstate cache was in that directory as well so removing it would cause a complete rebuild. good to know!
Sep 14 21:05:15 <ionte_> OMG! that gave me a wall of errors!!
Sep 14 21:05:56 <Ulfalizer> heh
Sep 14 21:05:59 <ionte_> my error. i had configured deploy directory to be outside tmp
Sep 14 21:07:14 * Ulfalizer assumes no responsibility for any loss, be it loss of life, property, equipment, ... :P
Sep 14 21:08:12 <Ulfalizer> removing tmp/ is the yocto "have you tried rebooting it?". it's cheap though, so usually worth trying.
Sep 14 21:09:16 <ionte_> right. i have removed the entire build directory before on these kind of errors. but that is not cheap.
Sep 14 21:09:33 <Ulfalizer> nope
Sep 14 21:09:38 <ionte_> Ulfalizer: thanks! that fixed my kernel problem as well!
Sep 14 21:09:51 <Ulfalizer> np
Sep 14 21:09:55 <bluelightning> hmm, so I just tried changing linux-yocto to linux-yocto-rt and I got a different error
Sep 14 21:10:35 <Ulfalizer> probably something that's not getting invalidated as it should when you switch the virtual provider
Sep 14 21:11:24 <ionte_> strange. i have done that in the past if i remember correctly.
Sep 14 21:13:16 <bluelightning> I'm filing a bug for the specific issue I just hit, FWIW
Sep 14 21:22:38 <bluelightning> ionte_: which version of the build system are you using? also which packaging backend (ipk, rpm, deb)?
Sep 14 22:01:00 <ionte_> i just turned on ipk. previously i did not use package management. same error no matter.
Sep 14 22:01:36 <kergoth> it's not possible to build without package management. you can remove the packaging tools and metadata from the image, that's about it
Sep 14 22:02:18 <yann> when qemu gets SIGILL when running an intercept hook, I guess that points to some missing information in the BSP, right ?
Sep 14 22:02:29 <ionte_> bluelightning: build system? bitbake 1.30.0, krogoth, ...
Sep 14 22:03:43 <ionte_> kergoth: ok, i meant EXTRA_IMAGE_FEATURE package-management...
Sep 14 22:25:58 <davis> i have a build system for native which works and the same source fails on target. My current failure appears to be libpcap.  On native its getting pulled in, but I can seem to find the reight depends line to pull it in. i've tried libcap, libcap-devel, etc.  How do I determine what provides in a native build?
Sep 15 01:26:37 <fenrig_> Hi, how do i enable systemd services to run at boot from within yocto
Sep 15 01:26:49 <fenrig_> and how do I add journalctl to the image?
Sep 15 01:31:33 <Ulfalizer> fenrig_: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-SYSTEMD_AUTO_ENABLE
Sep 15 01:31:58 <bluelightning> that's of course assuming you have already switched over from sysvinit to systemd
Sep 15 01:32:12 <fenrig_> how do I do this from the image.bb file
Sep 15 01:32:18 <bluelightning> you cannot
Sep 15 01:32:20 <fenrig_> yeah i switched to systemd already
Sep 15 01:32:38 <bluelightning> it must be done at the configuration level or in the recipe installing the service
Sep 15 01:33:00 <fenrig_> though I am missing systemctl and journalctl from my image
Sep 15 01:33:04 <bluelightning> the default is to enable the service though so if you find one that's not enabled either the recipe is disabling it or something is broken
Sep 15 01:36:30 <fenrig_> i probably should grep for it then
Sep 15 01:38:23 <bluelightning> it sounds a bit odd that systemctl and journalctl aren't there
Sep 15 01:38:31 <fenrig_> its odd
Sep 15 01:39:35 <fenrig_> but i have some messages from systemd-udevd
Sep 15 01:39:44 <fenrig_> and I have systemd files in my sysroot
Sep 15 01:39:54 <bluelightning> that doesn't mean much, since that's a separate program
Sep 15 01:40:10 <bluelightning> I suspect you're still running sysvinit in the image
Sep 15 01:40:26 <fenrig_> I did had to switch
Sep 15 01:40:39 <fenrig_> I did this in the local.conf
Sep 15 01:41:03 <bluelightning> what exactly did you put in there?
Sep 15 01:41:24 <fenrig_> VIRTUAL_RUNTIME_init_manager = "systemd"
Sep 15 01:41:27 <fenrig_> and
Sep 15 01:41:34 <fenrig_> DISTRO_FEATURES = "ext2 opengl usbhost ${DISTRO_FEATURES_LIBC} pulseaudio systemd"
Sep 15 01:42:05 <fenrig_> this is the correct way?
Sep 15 01:43:12 <fenrig_> Im building for the raspberry pi
Sep 15 01:50:21 <bluelightning> fenrig_: confusingly it's VIRTUAL-RUNTIME not VIRTUAL_RUNTIME
Sep 15 01:50:46 <bluelightning> if you have the latter in your config that may explain why it's not working
Sep 15 01:51:28 <fenrig_> okay lets rebuild
Sep 15 01:52:02 <fenrig_> so "inherit systemd" makes the service enabled for boot
Sep 15 01:52:07 <fenrig_> unless there is a
Sep 15 01:52:22 <fenrig_> SYSTEMD_AUTO_ENABLE = "disable"
Sep 15 02:01:26 <Ulfalizer> fenrig_: behind the scenes, a post-installation script is added to the package. when the package is installed, 'systemctl enable <service>' is run if SYSTEMD_AUTO_ENABLE is "enable".
Sep 15 02:01:53 <Ulfalizer> search for systemd_postinst in systemd.bbclass to see it
Sep 15 02:02:15 <Ulfalizer> the underlying mechanism is pkg_postinst. you'll find that in the reference manual.
Sep 15 02:02:27 <Ulfalizer> not directly relevant, but it helps me to understand how it's implemented
Sep 15 02:02:55 <Ulfalizer> urr... *in the development manual
Sep 15 02:06:50 <Ulfalizer> fenrig_: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-PROVIDES has a note on VIRTUAL-RUNTIME btw
**** ENDING LOGGING AT Thu Sep 15 02:59:58 2016