**** BEGIN LOGGING AT Mon Nov 04 02:59:58 2013
Nov 04 07:51:33 <mrAlmond> Hi
Nov 04 07:51:48 <mrAlmond> I've build the sdk using meta-toolchain-sdk target
Nov 04 07:52:00 <mrAlmond> I've also installed it using the script
Nov 04 07:52:20 <mrAlmond> now how can I install missing headers etc etc using the *dev* tpm packages?
Nov 04 07:52:30 <mrAlmond> s/tpm/rpm
Nov 04 07:53:10 <mrAlmond> I can't find documentation for this
Nov 04 08:06:03 <tlwoerner> mrAlmond: if, instead of using the meta-toolchain-sdk target, you do "bitbake -c populate_sdk <image>" then your sdk will include all the header files and libraries based on the packages contained in <image>
Nov 04 08:06:55 <tlwoerner> so if you your image contains all the packages you want it to contain, your sdk will contain all the headers etc to match
Nov 04 08:07:36 <mrAlmond> tlwoerner :so it will create the installer script (self-extracting) with everything inside?
Nov 04 08:09:23 <tlwoerner> yes, in $TMPDIR/deploy/sdk, i.e. all the instructions are the same
Nov 04 08:10:01 <mrAlmond> ok tnx...is this command explained in the documentation?
Nov 04 08:11:34 <tlwoerner> http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#optionally-building-a-toolchain-installer
Nov 04 08:12:12 <mrAlmond> great!
Nov 04 08:12:15 <mrAlmond> thank you
Nov 04 08:12:17 <tlwoerner> enjoy!
Nov 04 08:12:21 <mrAlmond> :-)
Nov 04 09:02:13 <mckoan> good morning
Nov 04 09:05:03 <TuTizz> morning
Nov 04 09:37:36 <bluelightning> morning all
Nov 04 09:44:23 <Net147> bluelightning: moin
Nov 04 09:45:05 <bluelightning> hi Net147
Nov 04 09:46:49 <Net147> bluelightning: documentation for DISK_SIGNATURE still on todo?
Nov 04 09:47:05 <bluelightning> Net147: yep
Nov 04 09:47:26 <bluelightning> Net147: I have a list here, just need to take some time to run through it with Scott
Nov 04 09:49:27 <Net147> bluelightning: what would I need to do to arrange for the Qt patches to be cherry picked into the dora branch?
Nov 04 09:51:08 <bluelightning> Net147: just post a request (or the backported patches) on the mailing list; mark as [dora] in the subject and CC the dora branch maintainer (Robert Yang <liezhi.yang@windriver.com>)
Nov 04 09:51:52 <Net147> bluelightning: okay, thanks
Nov 04 10:16:05 <lpapp> hi, how can I run an ssh server on the core image minimal?
Nov 04 10:23:35 <beuh> lpapp, you can add ssh-server-openssh to IMAGES_FEATURES in your local.conf
Nov 04 10:30:43 <lpapp> beuh: so it is not available for a core minimal image?
Nov 04 10:30:48 <lpapp> that is kinda weird, isn't it?
Nov 04 10:31:23 <lpapp> core-image seems to have it though.
Nov 04 10:49:00 <beuh> lpapp, are you sure that core-image have it? I never build it.
Nov 04 10:49:39 <lpapp> beuh: yes, I grepped for it.
Nov 04 10:59:33 <beuh> lpapp, ok, well all I know is that I add it to my local.conf
Nov 04 11:00:39 <lpapp> beuh: is it possible to send the ipk over minicom to the board?
Nov 04 11:00:47 <lpapp> beuh: because I only need the server for a quick verification.
Nov 04 11:01:32 <beuh> lpapp, never try
Nov 04 11:02:48 <lpapp> beuh: so if you add it to IMAGE_FEATURES in your local.conf, it will be built for every image you build?
Nov 04 11:02:59 <beuh> lpapp, yes
Nov 04 11:04:04 <beuh> lpapp, if you need it juste for one image you can make a .bbapend file
Nov 04 11:04:17 <beuh> .bbappend *
Nov 04 11:11:14 <lpapp> Starting Bootlog daemon: bootlogd: cannot allocate pseudo tty: No such file or directory
Nov 04 11:11:20 <lpapp> hmm, that is kinda weird, isn't it
Nov 04 11:13:30 <mrAlmond> guys, I'm trying to compile qtbase (qt5-layers)...I've added ${LAYERDIR}/qt5-layer/recipes-*/*/*.bbappend to BBFILES in  meta-fsl-arm/conf/layer.conf but now the error is
Nov 04 11:13:39 <mrAlmond> ERROR: No recipes available for
Nov 04 11:14:12 <mrAlmond> "/mnt/sdk/sviluppo/yocto/fsl-community-bsp/sources/meta-fsl-arm/qt5-layer/recipes-qt/qt5/qtbase_5.1.0.bbappend"
Nov 04 11:14:29 <mrAlmond> "/mnt/sdk/sviluppo/yocto/fsl-community-bsp/sources/meta-fsl-arm/qt5-layer/recipes-qt/qt5/qtbase_5.0.2.bbappend"
Nov 04 11:14:37 <mrAlmond> what am I missing?
Nov 04 11:24:02 <lpapp> you are using oooold Qt 5.
Nov 04 11:24:16 <lpapp> beuh: how to run the ssh server?
Nov 04 11:25:11 <bluelightning> mrAlmond: meta-fsl-arm is not matching up with the version of meta-qt5 you are using - check you are using up-to-date versions of the same branch of both
Nov 04 11:25:34 <lpapp> also, do not use those old versions.
Nov 04 11:26:30 <lpapp> I guess it is some systemd or sysv service run stuff, but I do not know how....
Nov 04 11:26:36 <lpapp> I have been using systemd for a long while now.
Nov 04 11:28:20 <mrAlmond> I've repo sync the fsl-community-bsp...this was done 3 weeks ago more or less
Nov 04 11:28:30 <mrAlmond> now I've made another repo sync
Nov 04 11:28:50 <mrAlmond> and now the error is the same but about qtbase_5.1.1.bbappend
Nov 04 11:30:07 <lpapp> oh, simply /etc/init.d/sshd start
Nov 04 11:31:07 <mrAlmond> lpapp: are you talking to me?
Nov 04 11:31:16 <lpapp> no
Nov 04 11:31:26 <lpapp> talking to myself not to exploit others' time. :D
Nov 04 11:31:32 <mrAlmond> ah ok :-)
Nov 04 11:31:42 <lpapp> well, I am also interested qt 5, namely qt 5.2 in deceber.
Nov 04 11:31:44 <lpapp> december
Nov 04 11:31:49 <lpapp> so keep stabilizing the layer. :-)
Nov 04 11:32:01 <mrAlmond> that would be great
Nov 04 11:32:14 <mrAlmond> but now I'm still not able to compile the 5.1.1
Nov 04 11:33:09 <lpapp> you do not have a compilation issue
Nov 04 11:33:12 <lpapp> you have a packaging issue.
Nov 04 11:33:32 <lpapp> so, are you using the latest commit from git in the corresponding branch?
Nov 04 11:33:38 <lpapp> also, ask JaMa
Nov 04 11:34:20 <lpapp> mrAlmond: first things first, check what bluelightning said, and reply to that as "done" if done.
Nov 04 11:34:25 <lpapp> then paste the next error message.
Nov 04 11:34:31 <lpapp> (or the same if persistent ... )
Nov 04 11:35:41 <mrAlmond> let me check
Nov 04 11:42:03 <mrAlmond> lpapp : summarizing my steps....I've just done a repo sync to get the latests updates...now the qt5 recipe is for qt 5.1.1
Nov 04 11:43:11 <mrAlmond> I guess I've to manually add the qt5 recipes to meta-fsl-arm/conf/layer.conf ? Is this correct?
Nov 04 11:43:37 <JaMa> mrAlmond: no
Nov 04 11:43:49 <JaMa> mrAlmond: you need to add meta-qt5 layer to BBLAYERS in conf/bblayers.conf
Nov 04 11:44:07 <mrAlmond> I did this begore the repo sync
Nov 04 11:44:19 <mrAlmond> but I was getting errors...let me try again
Nov 04 11:44:54 <mrAlmond> ah no...is was the qt5-layer
Nov 04 11:45:00 <mrAlmond> not meta-qt5
Nov 04 11:45:12 <mrAlmond> so I need to clone meta-qt5?
Nov 04 11:45:25 <mrAlmond> JaMa
Nov 04 11:45:49 <JaMa> I don't know what fsl-arm is using, what's qt5-layer?
Nov 04 11:46:12 <mrAlmond> inside meta-fsl-arm there is the qt5-layer directory
Nov 04 11:46:37 <JaMa> as bluelightning said you need to use compatible versions of all layers (basically the same branch name)
Nov 04 11:46:38 <mrAlmond> maybe I've to ask Otavio Salvador who is the official mantainer of that layer
Nov 04 11:46:56 <JaMa> what's in qt5-layer directory? just 2 .bbappend?
Nov 04 11:47:17 <mrAlmond> qt5-layer/recipes-qt/qt5/qtbase_5.1.1.bbappend
Nov 04 11:47:21 <mrAlmond> yes
Nov 04 11:47:35 <JaMa> then it's not layer
Nov 04 11:47:44 <mrAlmond> yes I know :-)
Nov 04 11:48:03 <mrAlmond> that's why I was talking about layer.conf
Nov 04 11:48:05 <JaMa> you need to add meta-qt5 to repo Manifest or clone it manually
Nov 04 11:48:17 <JaMa> 12:45:04 < mrAlmond> ah no...is was the qt5-layer
Nov 04 11:48:17 <JaMa> 12:45:09 < mrAlmond> not meta-qt5
Nov 04 11:48:29 <JaMa> wasn't very clear what you mean by that
Nov 04 11:48:39 <mrAlmond> JaMa : excuse me but I'm still a bit confused about these things
Nov 04 11:48:51 <JaMa> I see :)
Nov 04 11:49:23 <mrAlmond> I thought you know qt5-layer from meta-fsl-arm
Nov 04 12:09:39 <bluelightning> JaMa: ok, I fixed the error... thanks
Nov 04 12:09:46 <bluelightning> (layer index one)
Nov 04 12:12:02 <lpapp> mrAlmond: why do you not use meta-qt5?
Nov 04 12:30:01 <JaMa> bluelightning: thanks
Nov 04 12:46:13 <mrAlmond> lpapp : I'm using it now
Nov 04 12:46:29 <mrAlmond> I just wanted to know which was the best option for freescale
Nov 04 12:46:55 <mrAlmond> but now I've just find out that meta-qt5 is a replacement for that old recipes
Nov 04 12:51:08 <mrAlmond> RROR: No recipes available for:   /mnt/sdk/sviluppo/yocto/fsl-community-bsp/sources/meta-qt5/recipes-devtools/cmake/cmake_2.8.12.bbappend
Nov 04 12:51:24 <mrAlmond> it seems I'm missing something else
Nov 04 12:52:12 <lpapp> well, cmake should be optional first of all.
Nov 04 12:52:19 <lpapp> second, cmake is not shipped by meta-qt5 AFAIK
Nov 04 12:52:26 <lpapp> so make sure bitbake cmake works
Nov 04 12:53:00 <mrAlmond> do you mean by simply compliling cmake using bitbake
Nov 04 12:53:03 <mrAlmond> ?
Nov 04 12:53:33 <mrAlmond> bitbake cmake gives me the same error
Nov 04 12:53:35 <lpapp> well, you need to have the layer that provides cmake
Nov 04 12:53:45 <lpapp> and of course it has to come before the meta-qt5 layer in the layer conf
Nov 04 12:54:07 <mrAlmond> let me understand...the bbappend are not real recipes
Nov 04 12:54:19 <mrAlmond> are just something added to the original recipe?
Nov 04 12:54:22 <lpapp> you should not have any bbappend
Nov 04 12:54:50 <mrAlmond> sources/meta-qt5/recipes-devtools/cmake/cmake_2.8.12.bbappend
Nov 04 12:54:59 <mrAlmond> this exists
Nov 04 12:55:43 <lpapp> sounds bad to me.
Nov 04 12:55:51 <lpapp> Qt5 should be fine with vanilla cmake
Nov 04 12:56:22 <mrAlmond> cmake is not installed on my dev pc
Nov 04 12:56:41 <mrAlmond> must I install it with apt-get ?
Nov 04 13:00:37 <mrAlmond> maybe JaMa knows...what about the cmake issue I'm having with qtbase?
Nov 04 13:01:04 <mrAlmond> ERROR: No recipes available for:   /mnt/sdk/sviluppo/yocto/fsl-community-bsp/sources/meta-qt5/recipes-devtools/cmake/cmake_2.8.12.bbappend
Nov 04 13:01:17 <lpapp> I have no idea what you are talking about. :D
Nov 04 13:02:23 <lpapp> I think that cmake patch is some native stuff.
Nov 04 13:02:27 <lpapp> for*
Nov 04 13:03:17 <JaMa> mrAlmond: you're using meta-qt5/master and older oe-core
Nov 04 13:04:09 <JaMa> lpapp: it isn't read what the .bbappend does
Nov 04 13:04:39 <lpapp> JaMa: I was just wondering what that is for.
Nov 04 13:04:58 <JaMa> mrAlmond: you need oe-core version which has cmake_2.8.12.bb (which is master branch) you probably have dora or older which has only 2.8.11.bb
Nov 04 13:05:21 <JaMa> mrAlmond: if you have oe-core/dora, then you should use meta-qt5/dora
Nov 04 13:23:43 <Krz-> hi all
Nov 04 13:23:53 <Krz-> in one of my recipes I have: DEPENDS_libc_uclibc += "libiconv"
Nov 04 13:24:10 <Krz-> which doesn't trigger libiconv build for TCLIBC = "uclibc"
Nov 04 13:24:23 <Krz-> in other words - this DEPENDS line doesn't work for me
Nov 04 13:24:26 <Krz-> any suggestions?
Nov 04 13:29:55 <RP> Krz-: try DEPENDS_append_libc_uclibc = " libiconv"
Nov 04 13:30:37 <RP> Krz-: you could also try DEPENDS += "virtual/libiconv"
Nov 04 13:33:14 <mrAlmond> JaMa : I'm currently using this repo https://github.com/Freescale/fsl-community-bsp-platform that as cmake 2.8.11.2
Nov 04 13:33:44 <mrAlmond> meta-qt5 master needs cmake 2.8.12
Nov 04 13:34:07 <mrAlmond> how can I stay aligned with that freescale repo using meta-qt5?
Nov 04 13:34:32 <mrAlmond> do I simply need to tell meta-qt5 to use cmake 2.8.11.2 ?
Nov 04 13:38:22 <JaMa> mrAlmond: you need to use compatile branch of meta-qt5
Nov 04 13:38:29 <JaMa> which is dora in your case
Nov 04 13:39:04 <JaMa> if you're using dora branch of https://github.com/Freescale/fsl-community-bsp-platform
Nov 04 13:39:30 <mrAlmond> I should be on dora...how can I check it from ly local copy?
Nov 04 13:39:35 <Krz-> RP: if I do DEPENDS += "virtual/libiconv" it means my recipe will not try to build libiconv for eglibc build?
Nov 04 13:39:37 <mrAlmond> my local copy
Nov 04 13:40:01 <JaMa> git branch
Nov 04 13:40:16 <RP> Krz-: for eglibc isn't virtual/libiconv provided by eglibc?
Nov 04 13:41:17 <Krz-> RP: I have no idea what virtual/ means, but for eglibc builds libiconv doesn't exist - eglibc provides functionality of libiconv on its own
Nov 04 13:42:25 <Krz-> RP: so my target is to have DEPENDS statement which will trigger libiconv only for uclibc build. If my layer tries to build libiconv for eglibc - then build fails
Nov 04 13:42:31 <RP> Krz-: recipes-core/eglibc/eglibc.inc:PROVIDES += "virtual/libintl virtual/libiconv"
Nov 04 13:42:50 <RP> Krz-: conf/distro/include/tclibc-eglibc.inc:PREFERRED_PROVIDER_virtual/libiconv ?= "eglibc"
Nov 04 13:42:58 <mrAlmond> JaMa : in repo manifest there is <default sync-j="4" revision="dora"/>
Nov 04 13:43:18 <Krz-> RP: so DEPENDS += "virtual/libiconv" is Yocto way to go?
Nov 04 13:43:26 <mrAlmond> all references are to "dora"
Nov 04 13:44:08 <RP> Krz-: yes
Nov 04 13:45:02 <Krz-> RP: cool, thanks
Nov 04 13:49:26 <mrAlmond> JaMa : http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/cmake?h=dora
Nov 04 13:49:40 <mrAlmond> cmake version of dora is 2.8.11.2
Nov 04 13:50:03 <mrAlmond> ah excuse me
Nov 04 13:50:15 <mrAlmond> now I understand...
Nov 04 13:50:23 <mrAlmond> I must switch to meta-qt5 dora
Nov 04 13:50:40 <mrAlmond> sorry...
Nov 04 13:55:25 <mrAlmond> now it's compiling...thanks!!
Nov 04 13:59:35 <Krz-> RP: btw. using += vs _append, which one is better? As I read in local.conf documentation it's better to use _append since it guarantees contents to get to variable, whereas += not always. Is that correct?
Nov 04 13:59:49 <j8> i want a conditional based on IMAGE_INSTALL inside of a recipe task. checking it with base_contains is not working... any other methods?
Nov 04 14:00:43 <bluelightning> j8: if you mean you want to do something different in another recipe depending on what your image recipe specifies for IMAGE_INSTALL, you can't do that
Nov 04 14:01:38 <bluelightning> j8: can you elaborate on what you want to do? it's likely there is another way to accomplish the same thing
Nov 04 14:03:16 <RP> Krz-: its all about context. += appends to any existing variable but can be overridden later by overrides
Nov 04 14:03:26 <j8> bluelightning: I need to create a symlink to the bzImage-* in /boot for grub. i wanted to do this with that conditional
Nov 04 14:05:15 <bluelightning> j8: ok, I would suggest doing that as part of postprocessing; i.e. in your image recipe create a shell function to create the symlink and then add that function to ROOTFS_POSTPROCESS_COMMAND
Nov 04 15:14:12 <lpapp> why is Yocto using /var/volatile for fstab by default?
Nov 04 15:31:15 <otavio> lpapp: this is the choosen default; you can override it
Nov 04 15:32:34 <lpapp> I mean, I worked for Fremantle and Harmattan, Meego, etc
Nov 04 15:32:37 <lpapp> but never seen this before.
Nov 04 15:32:49 <lpapp> I believe we used /var/tmp and /tmp there.
Nov 04 15:32:56 <lpapp> is there any other system outside Yocto using this?
Nov 04 17:47:36 <otavio> lpapp: OE ;-)
Nov 04 17:48:23 <lpapp> otavio: anything else than oe/yocto/poky?
Nov 04 17:49:38 <mr_science> moin
Nov 04 19:04:00 <Crofton> zeddii, perf sucks: http://pastebin.com/a2Xphuah
Nov 04 19:16:27 <zeddii> *sigh*
Nov 04 19:20:25 <Crofton> seems like older kernel newer gcc issue
Nov 04 21:11:21 <brm> Hi Guys, good morning!
Nov 04 21:12:09 <brm> Does anyone know why my c_can module does not get included in the rootfs?
Nov 04 21:12:22 <brm> I have : MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-can-dev" MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-c_can" in my .conf file
Nov 04 21:12:40 <brm> but only can-dev ends up in rootfs
Nov 04 21:13:34 <brm> both are built as kernel modules and end up in the modules* tarball ok
Nov 04 21:18:33 <mr_science> brm: one works and the other doesn't?
Nov 04 21:19:44 <brm> yes
Nov 04 21:20:21 <kergoth> hmm, grub-efi-native doesn't build on centos5, it seems
Nov 04 21:20:34 <kergoth> grub-setup.c:797: error: 'struct fiemap' has no member named 'fm_extents'
Nov 04 21:20:35 * kergoth digs
Nov 04 21:21:19 <brm> doing a search for kernel-module-can-dev in the linux tree shows it there, but only "c_can", it doesn't have the kernel-module- bit ...
Nov 04 21:23:30 <brm> mr_science: what do you think
Nov 04 21:24:13 <sgw_> kergoth: got it be related to gcc-multilib?
Nov 04 21:25:04 <kergoth> seems unlikely, the header lives in /usr/include/linux/, i'm guessing grub 2.0 might have a minimum kernel version that isn't met by the host
Nov 04 21:25:08 * kergoth shrugs
Nov 04 21:29:29 <mr_science> kergoth: kernel version on the host?
Nov 04 21:29:51 <mr_science> grub2 builds fine with newer kernels
Nov 04 21:30:00 <mr_science> 3.9, 3.10, etc
Nov 04 21:30:31 <mr_science> brm: not sure i have a thought, other than "that's weird..."
Nov 04 21:31:27 <kergoth> mr_science: centos 5 is ancient :)
Nov 04 21:31:47 <kergoth> i mean ancient. thats its value, in that we know that any native/cross sstates built there will work anywhere :)
Nov 04 21:31:51 <kergoth> 2.6.18 kernel :)
Nov 04 21:33:59 <mr_science> damn, that is old...
Nov 04 21:39:29 <kergoth> keeping it building has involved a number of hacks here and there, but i think this one might finally be the deal breaker for us, might have to switch to a different distro for our automated build systems
Nov 04 21:42:08 <mr_science> easy to use multiple kernels/bootloaders/toolchains on Gentoo
Nov 04 21:42:17 <mr_science> just sayin'...
Nov 04 21:48:57 <mr_science> damn, too many stale versions of json-c lying around...
Nov 04 22:40:32 <j8> how does one change boot root mount options?
Nov 04 22:55:10 <j8> the yocto kernel (initrd?) doesn't like me passing rootfs=relatime via grub - it kernel panics
Nov 04 22:57:13 <ant_home> doesn't seem a valid kernel parameter to me...
Nov 04 22:59:15 <j8> oops, i meant rootflags=relatime
Nov 04 23:43:29 <kergoth> Hmm, centos6 is listed as supported, but it really can't be without a buildtools-tarball or python-tarball, correct?
Nov 04 23:46:40 <bluelightning> kergoth: with dora+, correct
**** BEGIN LOGGING AT Tue Nov 05 00:58:43 2013
**** ENDING LOGGING AT Tue Nov 05 02:59:58 2013