**** BEGIN LOGGING AT Fri Oct 09 02:59:59 2015 Oct 09 08:10:33 Jefro: s/OEDAM/OEDEM :-) Oct 09 08:27:46 otavio, good morning, I did, they answered me to contact the Debian freenode team, or to ask somebody having that cloak who to contact Oct 09 08:27:49 :) Oct 09 08:27:59 anyway, I have a serious problem, yocto related Oct 09 08:28:24 we have an Ubuntu 12.04 we use as build machine. everything works correctly, we build, and flash on i.MX28 targets Oct 09 08:29:53 the problem is: I did pass my yocto recipes to the customer, and he has a server with Ubuntu 14.04 Oct 09 08:30:13 he does the builds correctly, but when he flash them he get a tar error during the untar in the target Oct 09 08:30:27 you know, the tar is passed with mfgtool, and extracted inside the target Oct 09 08:34:29 I tried to downgrade tar on 14.04 to the 12.04 version, but I failed Oct 09 08:35:01 I tried to troubleshoot the issue, and seems that the tar inside busybox (the one used by mfgtool AFAIK) has some problems with recursive directories or similar Oct 09 08:35:06 or magic octal somewhat Oct 09 12:16:37 is there an option to disable the alternatives system so symbolic links aren't created in the target filesystem? Oct 09 12:22:44 correct me if I'm wrong, but IMAGE_FEATURES only affects what gets installed and rootfs postprocessing, while DISTRO_FEATURES & MACHINE_FEATURES affect how the packages get built (with certain features being on or off)? Oct 09 13:06:54 bboozzoo: AFAIK thats only by convention, not enforced by technical means. Oct 09 13:10:19 LetoThe2nd: hmm. i think this is by design actually. so to me it is enforced. Oct 09 13:12:10 ndec: correct... design & convention & semantic meaning. i just meant to say it isn't going to explode if you misuse it, so that this misuse might go unnoticed. Oct 09 13:14:04 LetoThe2nd: thanks Oct 09 15:41:22 hi guys Oct 09 15:42:08 <_taw_> is there a way to suppress the 'volatile' folder in base_files, -- building an initramfs, without /etc/init.d/populate-volatile.sh, /var/run link points to nowhere Oct 09 15:44:11 does anyone know why this call to gcc /var/yocto/build/tmp/sysroots/i686-linux/usr/bin/i586-poky-linux/i586-poky-linux-gcc --print-sysroot gives "/not/exist" ? Oct 09 15:44:49 drou: to make sure the sysroot is exlicitly defined. Oct 09 15:45:10 drou: just ran over the line tha causes it a few hours ago in the gcc recipe includes Oct 09 15:46:55 LetoThe2nd: hmm, because before updating from dizzy to fido a couple of days ago, the cmd returned the machine name, which seemed ok Oct 09 15:47:09 you mean there is a fix for that? Oct 09 15:47:59 drou: --sysroot= is supposed to be explicitly passed when the toolchain is run at this time. we don't want anything relying on its built in one Oct 09 15:49:56 usually the answer is to use the pre-defined CC variable, whether you're in the SDK or in the build system itself Oct 09 15:52:31 actually i'm trying to build something based on cmake, and the toolchain.cmake file generated has the --sysroot=/var/yocto/build/tmp/sysroots/machine but it's not working Oct 09 15:54:58 but what i cant understand is that the gcc --print-sysroot gave something valid where i was under dizzy and now it's not under fido. i just updated all the meta Oct 09 15:56:50 you're switching to a newer release and are surprised things changed? Oct 09 15:56:51 that's how it works Oct 09 15:57:12 no, obviously :p Oct 09 15:59:17 drou: one of the reasons it changed is we now use one compiler per architecture as opposed to a compiler per machine, and then the difference is simply the command line used Oct 09 15:59:46 (among other command line options, we point to a different sysroot for each machine) Oct 09 16:01:22 drou: another good reason is that this change allows to find out which recipes are not respecting CC variable, before this they were usually building successfully, but once gcc-cross was reused from sstate (and included sysroot wasn't pointing to correct directory) it started to fail without clear indication why Oct 09 16:01:47 now the built-in sysroot is always wrong and all recipes were already fixed Oct 09 16:03:31 ok i got it. so --sysroot must be explicitely given to gcc. Oct 09 16:03:53 yes and it was always meant to be like that Oct 09 16:06:13 ok then i'll have to understand why this option is not given to gcc whereas CMAKE_C_FLAGS defines it Oct 09 16:31:15 I'm having an issue with python not finding modules (such as plistlib.py and ast.py) with the fido release. Should I not be using the fido branch? Oct 09 16:33:30 FileNotFound: i recently discovered that python-misc doesn't get pulled in automatically, so you might need to add that package Oct 09 16:33:40 (fixed in master, joshuagl should backport it) Oct 09 16:34:33 rburton: thanks, i'll give that a try Oct 09 16:44:12 rburton: that worked btw. Thanks again. Oct 09 16:45:55 np Oct 09 17:57:03 hi. I'm trying to build the Eclipse plugin for Eclipse Mars 4.5.1. I followed the instructions here http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html and generated the archive. The problem is it fails during the installation Oct 09 17:58:32 is states that the ADT plug in and the Bitbake commander plugin won't be installed Oct 09 17:59:09 Cannot complete the install because one or more required items could not be found. Software being installed: Yocto Project ADT Plug-in 1.4.0.201510090935 (org.yocto.sdk.feature.group 1.4.0.201510090935) Missing requirement: Yocto Project Plugin Remote Tools 1.4.0.201510090935 (org.yocto.sdk.remotetools 1.4.0.201510090935) requires 'package org.eclipse.rse.internal.terminals.ui 0.0.0' but it could not be found Cannot satisfy d Oct 09 18:24:55 :) Oct 10 00:28:17 hey. Oct 10 00:28:20 hey. i'm using yocto and -> http://permalink.gmane.org/gmane.linux.embedded.yocto.general/25143 <- i've hit this problem and i'm on meta-raspberrypi master, any idea what i can do? Oct 10 00:28:32 i want x11 and xterm Oct 10 00:28:42 and later i want to install qt5 **** ENDING LOGGING AT Sat Oct 10 02:59:59 2015