**** BEGIN LOGGING AT Wed Aug 10 02:59:58 2016
Aug 10 08:10:12 <jubr> sveinse: about those poky patches: I'm wondering too. Anybody?
Aug 10 08:10:31 <jubr> oh wait, he's gone. hehe
Aug 10 08:51:02 <boucman_work> hey all
Aug 10 08:51:50 <boucman_work> I have a problem compiling Jethro on latest linux host... apparently pkg-config-native can't be compiled with gcc6
Aug 10 08:52:07 <boucman_work> is there a way to specify what host compiler to use ?
Aug 10 09:27:15 <HyP3r> As final step for my image I have written a small recpie which is coping some files into the rootfs (configurations for everything). But now I get masses of check_data_file_clashes cause files are colliding
Aug 10 09:46:52 <HyP3r> Are those file collisions only solveable by creating bbappend recpies for those packages which are originally generating those files by patching them?
Aug 10 09:50:39 <boucman_work> HyP3r: i don't know, but im' interested... I'll have that problem soon in my project.
Aug 10 09:54:29 <HyP3r> boucman_work: seems like I'm again the first man on the moon :D
Aug 10 09:54:41 <HyP3r> Just a joke, but that looks like a mass of work
Aug 10 09:54:44 <boucman_work> hehe
Aug 10 09:55:14 <boucman_work> I did something that could help with your general problem (not the specific one you have right now)
Aug 10 09:55:16 <boucman_work> gimme a sec
Aug 10 09:55:59 <HyP3r> ?
Aug 10 09:56:18 <boucman_work> allowing images to use SRC_URI to get files
Aug 10 09:57:12 <boucman_work> in your image recipe, you can add the following
Aug 10 09:57:21 <boucman_work> python () {
Aug 10 09:57:22 <boucman_work>    d.delVarFlag("do_fetch","noexec")
Aug 10 09:57:22 <boucman_work>    d.delVarFlag("do_unpack","noexec")
Aug 10 09:57:22 <boucman_work> }
Aug 10 09:57:57 <HyP3r> With this you are deleteing those steps right?
Aug 10 09:58:01 <boucman_work> after that, you will be able to use SRC_URI to get the files you want to overlay (and have them as a tar.gz in files/ or as a separate git repo, or using patch on them)
Aug 10 09:58:08 <boucman_work> no
Aug 10 09:58:27 <boucman_work> I am deleting the flag do_fetch[noexec] (only the flag, not the var)
Aug 10 09:58:35 <boucman_work> the flag is what causes the task to not be executed
Aug 10 09:58:51 <HyP3r> Ok nice
Aug 10 09:59:23 <boucman_work> I am pushing a patch on bitbake to add a specific syntax to do that, but right now, embedded python is the only way to do it
Aug 10 10:08:12 <jubr> boucman_work: I noticed that too: not being able to use SRC_URI on image recipes
Aug 10 10:08:42 <jubr> but I'm pretty sure it'm meant that way: they don't want you to add files in images. packages add files
Aug 10 10:09:43 <boucman_work> jubr: yes,  but I think that's arguable. it makes sense for a particular image recipe to tweak a config file provided by a package...
Aug 10 10:09:54 <jubr> true
Aug 10 10:10:13 <boucman_work> if you want to have two images with different configuration, you would need two different recipes, .bbappend won't cut it
Aug 10 10:10:22 <jubr> more true
Aug 10 10:10:25 <boucman_work> and that's really tedious if you need to configure lots of software
Aug 10 10:10:59 <boucman_work> it would make sense to have a QA test for images that  would check that overlayed files are always new files or files that are part of CONFFILES for their particular recipe
Aug 10 10:11:23 <boucman_work> (I am looking how that can be done, but right now I'm a bit confused on how to get that info...
Aug 10 10:11:40 <jubr> I sometimes fixed that with `sed -i` or with: cat > ${IMAGE_ROOTFS}/sbin/setup.sh <<-_EOF_
Aug 10 10:24:12 <HyP3r> Did some created a recpie which checks out of hg server? We are working with an rhodecode enterprise hg server, and I have no idea how the SRC_URI should look like
Aug 10 10:25:19 <HyP3r> In the console I clone the repository this way: hg clone http://foo@bar:5000/Project/Name
Aug 10 10:26:21 <boucman_work> HyP3r: https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#other-fetchers
Aug 10 10:26:33 <boucman_work> so, there is something but it's not well supported :(
Aug 10 10:26:49 <HyP3r> No documentation currently exists for these lesser used fetcher submodules. However, you might find the code helpful and readable.
Aug 10 10:27:00 <boucman_work> yeah :(
Aug 10 10:27:21 <boucman_work> (if you reverse-engineer the code, updating the documentation would be really nice...
Aug 10 10:27:33 <HyP3r> wtf?
Aug 10 10:27:48 <jubr> I betcha they'll accept nice doc-patches easily :)
Aug 10 10:27:51 <HyP3r> Is the developer of this part of yocto dead?
Aug 10 10:28:26 <boucman_work> HyP3r: bitbake in general : no... but there are very few (propbably none in core) software that use mercurial, so it is not in a good shape
Aug 10 10:29:16 <jubr> HyP3r: physically deceased? :p
Aug 10 10:29:58 <HyP3r> its strange everything \o/
Aug 10 10:33:55 <HyP3r> Is this the code of the fetcher? http://git.yoctoproject.org/cgit.cgi/poky/plain/bitbake/lib/bb/fetch2/hg.py
Aug 10 10:34:02 <boucman_work> yes
Aug 10 11:05:00 <lpapp> hi
Aug 10 11:05:50 <dsathe> hey folks my board is on dizzy yocto 1.7 i wanted to apply the patch to upgrade python from 2.7.3 to 2.7.9
Aug 10 11:05:52 <dsathe> any tips
Aug 10 11:06:06 <dsathe> sorry i am sort of new to this
Aug 10 12:23:02 <HyP3r> boucman_work: mercurial is working magicall :3 (after I read the code)
Aug 10 12:24:26 <boucman_work>  awesome, can you submit a doc patch ?
Aug 10 12:27:07 <HyP3r> how?
Aug 10 12:27:22 <HyP3r> Its not that complex to use mercurial but you have to set a bunch of options
Aug 10 12:27:55 <boucman_work> all the doc fo the bitbake manual is in the doc subdirectory of the bitbake source
Aug 10 12:28:07 <HyP3r> k
Aug 10 12:28:16 <boucman_work> it's pretty easy to understand when you look into it, just update the manual, and generate a patch
Aug 10 12:28:23 <boucman_work> then submit it on the bitbake ML
Aug 10 12:57:41 <HyP3r> So, the next thing is a really small c++ project has some dependencys e.g. sigc++ and so on but my coworker never created for those load c-files a makefile, but if I want to use yocot with make and make install I need a Makefile. Is there somewhere an examplemakefile
Aug 10 12:57:57 <HyP3r> Which is handling things like *compilerprefix* and optional packages correct?
Aug 10 12:58:15 <HyP3r> A skeleton or something else
Aug 10 13:08:45 <boucman_work> if your coworker provided no makefile at all, I would suggest using cmake
Aug 10 13:09:13 <boucman_work> if you need to learn a build system from scratch, cmake is way easier than autotools... (it's still complicated, though)
Aug 10 13:12:58 <HyP3r> boucman_work: I know how to write makefiles (a bit) but I gues yocto is setting before running 'make' a lot of enviroment variables e.g. cross compiler prefix and so on, and those variables have to be used inside the makefile
Aug 10 13:15:27 <boucman_work> yes
Aug 10 13:16:34 <boucman_work> i don't remember the specifics... the simplest way to find out might be to write a simple makefile (not cross-compilable), run it and look how the genereated do_compile looks like
Aug 10 13:16:47 <boucman_work> all env vars will be set explicitely in there, so you'll see what they are
Aug 10 13:17:14 <HyP3r> hehe ok
Aug 10 13:17:33 <HyP3r> the other - hard - way would be to create a configure.ac
Aug 10 13:17:34 <HyP3r> hm
Aug 10 13:18:37 <boucman_work> HyP3r: configure.ac is autotools, and autotools is... well. if you need to do autotools, I would highly recommand learning cmake instead. much simpler, robust, and once you've learned it that whole category of problems is solved
Aug 10 13:21:21 <HyP3r> boucman_work: maybe you are right but those times I was using cmake were crazier than autotools, so I stay by autoools :)
Aug 10 13:21:42 <boucman_work> again... if you already know autotools, go for autotools...
Aug 10 13:21:55 <boucman_work> from a yocto point of view, both work more or less the same
Aug 10 13:59:36 <boucman_work> anybody knows the subtle difference between $CC and $BUILD_CC ? which one should I set to force yocto to use a specific (non-cross) compiler from my distro ?
Aug 10 14:01:26 <neverpanic> $CC is usually the cross-compiler, $BUILD_CC the compiler for the build host
Aug 10 14:02:32 <boucman_work> neverpanic: you sure ? I tried setting BUILD_CC but then gcc-cross fails because it uses g++ directly instead of using g++-5
Aug 10 14:03:02 <boucman_work> maybe it's a bug in the gcc-cross recipe, but that frightens me :P
Aug 10 14:03:12 <neverpanic> No, I'm not sure ;-)
Aug 10 14:03:20 <boucman_work> hehe
Aug 10 14:03:26 <boucman_work> (the yocto doc is not very clear)
Aug 10 14:04:11 <neverpanic> http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-HOST_CC_ARCH suggests BUILD* stuff is for the build machine
Aug 10 14:04:49 <neverpanic> but cross.bbclass might change some of those assumptions, so I'm not absolutely sure
Aug 10 14:06:28 <neverpanic> yeah, I checked $CC is a cross-compiler, $BUILD_GCC just defaults to ccache gcc ${BUILD_CC_ARCH}
Aug 10 14:06:35 <neverpanic> BUILD_CC**
Aug 10 14:07:07 <boucman_work> neverpanic: does yocto build -native with the compiler from your distro, or does it build its own native compiler ?
Aug 10 14:07:20 <boucman_work> to improve reproducibility
Aug 10 14:22:27 <neverpanic> boucman_work: it uses your distro compiler
Aug 10 14:22:47 <neverpanic> so if you run latest and greatest fedora with gcc-23, it'll likely break
Aug 10 14:23:00 <neverpanic> recommendation is to build in a container to avoid that
Aug 10 14:23:22 <CTtpollard> can't you specify compiler version?
Aug 10 14:23:38 <boucman_work> neverpanic: thx, not really helpfull in my case...
Aug 10 14:23:58 <neverpanic> That's what he was trying by setting BUILD_CC, I guess?
Aug 10 14:23:59 <boucman_work> (iiuc uninative is supposed to solve that in latest yocto, but i'm stuck with jethro in that particular case)
Aug 10 14:24:05 <boucman_work> yes
Aug 10 14:24:05 <neverpanic> boucman_work: also, is there BUILD_CXX?
Aug 10 14:24:41 <neverpanic> boucman_work: because setting BUILD_CC and not BUILD_CXX would explain why it uses g++ over g++-5
Aug 10 14:24:56 <boucman_work> there is, I set it too
Aug 10 14:25:34 <boucman_work> $CC is set by the following line in bitbake.conf
Aug 10 14:25:45 <boucman_work> export CXX = "${CCACHE}${HOST_PREFIX}g++ ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
Aug 10 14:25:59 <boucman_work> so it is a host compiler... not a target
Aug 10 14:26:24 <boucman_work> so I don't really understand the difference between $CC and $BUILD_CC
Aug 10 14:26:34 <boucman_work> (and yeah, I pasted the line for CXX, sorry)
Aug 10 15:09:40 <neverpanic> boucman_work: That's misleading; check the value of CC or CXX in bitbake -e $yourrecipe. ${HOST_PREFIX} is actually set depending on whether you're cross-compiling for target or SDK or building for the machine
Aug 10 15:10:30 <neverpanic> boucman_work: e.g. in a recipe that compiles for an arm target, HOST_PREFIX will be the triple describing your ARM cross-compiler
Aug 10 15:10:56 <neverpanic> in nativesdk- recipes ${HOST_PREFIX} will be referring to whatever your SDK architecture is
Aug 10 15:11:02 <neverpanic> and in -native recipes, it'll likely be empty
Aug 10 15:12:47 <boucman_work> yeah, I found that out :(
Aug 10 15:13:08 <boucman_work> I think I have spotted a but in the gcc recipe which means BUILD_CXX is not handled properly there
Aug 10 15:13:21 <boucman_work> that would explain it
Aug 10 15:13:58 <neverpanic> Yes, that's what I think as well. Did you try with master?
Aug 10 15:14:28 <boucman_work> no, I really need to fix that bug in jethro TODAY :P
Aug 10 15:14:38 <boucman_work> checking master will come when I have time to breath
Aug 10 15:14:56 <boucman_work> (but I quickly checked the master recipe, apparently the bug is there)
Aug 10 15:18:16 <boucman_work> and testing the bug in master is harder, since master compiles correctly with gcc6
Aug 10 15:31:27 <boucman_work> nope, didn't help
Aug 10 16:01:00 <HyP3r> how can I configure to what sysroots header files are populated? If I bitbake json-c I have the header files inside my colibri-vf folder but not under x86_64?
Aug 10 16:01:49 <kergoth> if you want it under the build machine's sysroot, it sounds like you want json-c-native, not json-c
Aug 10 16:02:01 <HyP3r> ah ok thanks :)
**** ENDING LOGGING AT Thu Aug 11 02:59:58 2016