**** BEGIN LOGGING AT Wed Aug 10 02:59:58 2016 Aug 10 08:10:12 sveinse: about those poky patches: I'm wondering too. Anybody? Aug 10 08:10:31 oh wait, he's gone. hehe Aug 10 08:51:02 hey all Aug 10 08:51:50 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 is there a way to specify what host compiler to use ? Aug 10 09:27:15 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 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 HyP3r: i don't know, but im' interested... I'll have that problem soon in my project. Aug 10 09:54:29 boucman_work: seems like I'm again the first man on the moon :D Aug 10 09:54:41 Just a joke, but that looks like a mass of work Aug 10 09:54:44 hehe Aug 10 09:55:14 I did something that could help with your general problem (not the specific one you have right now) Aug 10 09:55:16 gimme a sec Aug 10 09:55:59 ? Aug 10 09:56:18 allowing images to use SRC_URI to get files Aug 10 09:57:12 in your image recipe, you can add the following Aug 10 09:57:21 python () { Aug 10 09:57:22 d.delVarFlag("do_fetch","noexec") Aug 10 09:57:22 d.delVarFlag("do_unpack","noexec") Aug 10 09:57:22 } Aug 10 09:57:57 With this you are deleteing those steps right? Aug 10 09:58:01 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 no Aug 10 09:58:27 I am deleting the flag do_fetch[noexec] (only the flag, not the var) Aug 10 09:58:35 the flag is what causes the task to not be executed Aug 10 09:58:51 Ok nice Aug 10 09:59:23 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 boucman_work: I noticed that too: not being able to use SRC_URI on image recipes Aug 10 10:08:42 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 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 true Aug 10 10:10:13 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 more true Aug 10 10:10:25 and that's really tedious if you need to configure lots of software Aug 10 10:10:59 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 (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 I sometimes fixed that with `sed -i` or with: cat > ${IMAGE_ROOTFS}/sbin/setup.sh <<-_EOF_ Aug 10 10:24:12 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 In the console I clone the repository this way: hg clone http://foo@bar:5000/Project/Name Aug 10 10:26:21 HyP3r: https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#other-fetchers Aug 10 10:26:33 so, there is something but it's not well supported :( Aug 10 10:26:49 No documentation currently exists for these lesser used fetcher submodules. However, you might find the code helpful and readable. Aug 10 10:27:00 yeah :( Aug 10 10:27:21 (if you reverse-engineer the code, updating the documentation would be really nice... Aug 10 10:27:33 wtf? Aug 10 10:27:48 I betcha they'll accept nice doc-patches easily :) Aug 10 10:27:51 Is the developer of this part of yocto dead? Aug 10 10:28:26 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 HyP3r: physically deceased? :p Aug 10 10:29:58 its strange everything \o/ Aug 10 10:33:55 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 yes Aug 10 11:05:00 hi Aug 10 11:05:50 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 any tips Aug 10 11:06:06 sorry i am sort of new to this Aug 10 12:23:02 boucman_work: mercurial is working magicall :3 (after I read the code) Aug 10 12:24:26 awesome, can you submit a doc patch ? Aug 10 12:27:07 how? Aug 10 12:27:22 Its not that complex to use mercurial but you have to set a bunch of options Aug 10 12:27:55 all the doc fo the bitbake manual is in the doc subdirectory of the bitbake source Aug 10 12:28:07 k Aug 10 12:28:16 it's pretty easy to understand when you look into it, just update the manual, and generate a patch Aug 10 12:28:23 then submit it on the bitbake ML Aug 10 12:57:41 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 Which is handling things like *compilerprefix* and optional packages correct? Aug 10 12:58:15 A skeleton or something else Aug 10 13:08:45 if your coworker provided no makefile at all, I would suggest using cmake Aug 10 13:09:13 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 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 yes Aug 10 13:16:34 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 all env vars will be set explicitely in there, so you'll see what they are Aug 10 13:17:14 hehe ok Aug 10 13:17:33 the other - hard - way would be to create a configure.ac Aug 10 13:17:34 hm Aug 10 13:18:37 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 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 again... if you already know autotools, go for autotools... Aug 10 13:21:55 from a yocto point of view, both work more or less the same Aug 10 13:59:36 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 $CC is usually the cross-compiler, $BUILD_CC the compiler for the build host Aug 10 14:02:32 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 maybe it's a bug in the gcc-cross recipe, but that frightens me :P Aug 10 14:03:12 No, I'm not sure ;-) Aug 10 14:03:20 hehe Aug 10 14:03:26 (the yocto doc is not very clear) Aug 10 14:04:11 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 but cross.bbclass might change some of those assumptions, so I'm not absolutely sure Aug 10 14:06:28 yeah, I checked $CC is a cross-compiler, $BUILD_GCC just defaults to ccache gcc ${BUILD_CC_ARCH} Aug 10 14:06:35 BUILD_CC** Aug 10 14:07:07 neverpanic: does yocto build -native with the compiler from your distro, or does it build its own native compiler ? Aug 10 14:07:20 to improve reproducibility Aug 10 14:22:27 boucman_work: it uses your distro compiler Aug 10 14:22:47 so if you run latest and greatest fedora with gcc-23, it'll likely break Aug 10 14:23:00 recommendation is to build in a container to avoid that Aug 10 14:23:22 can't you specify compiler version? Aug 10 14:23:38 neverpanic: thx, not really helpfull in my case... Aug 10 14:23:58 That's what he was trying by setting BUILD_CC, I guess? Aug 10 14:23:59 (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 yes Aug 10 14:24:05 boucman_work: also, is there BUILD_CXX? Aug 10 14:24:41 boucman_work: because setting BUILD_CC and not BUILD_CXX would explain why it uses g++ over g++-5 Aug 10 14:24:56 there is, I set it too Aug 10 14:25:34 $CC is set by the following line in bitbake.conf Aug 10 14:25:45 export CXX = "${CCACHE}${HOST_PREFIX}g++ ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}" Aug 10 14:25:59 so it is a host compiler... not a target Aug 10 14:26:24 so I don't really understand the difference between $CC and $BUILD_CC Aug 10 14:26:34 (and yeah, I pasted the line for CXX, sorry) Aug 10 15:09:40 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 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 in nativesdk- recipes ${HOST_PREFIX} will be referring to whatever your SDK architecture is Aug 10 15:11:02 and in -native recipes, it'll likely be empty Aug 10 15:12:47 yeah, I found that out :( Aug 10 15:13:08 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 that would explain it Aug 10 15:13:58 Yes, that's what I think as well. Did you try with master? Aug 10 15:14:28 no, I really need to fix that bug in jethro TODAY :P Aug 10 15:14:38 checking master will come when I have time to breath Aug 10 15:14:56 (but I quickly checked the master recipe, apparently the bug is there) Aug 10 15:18:16 and testing the bug in master is harder, since master compiles correctly with gcc6 Aug 10 15:31:27 nope, didn't help Aug 10 16:01:00 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 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 ah ok thanks :) **** ENDING LOGGING AT Thu Aug 11 02:59:58 2016