**** BEGIN LOGGING AT Thu Sep 11 02:59:58 2014
Sep 11 06:00:21 <Aleksandr> Hello all here. Having some troubles with adding Unicode support to core-image-base. Should I add ICU to IMAGE_INSTALL_append?
Sep 11 07:25:08 <mckoan> good morning
Sep 11 07:25:51 <Aleksandr> hello, mckoan
Sep 11 07:33:48 <Aleksandr> Guys, where can i get some boost recipes for my system?
Sep 11 07:46:06 <gebreselaisi> hi room
Sep 11 07:46:19 <gebreselaisi> silly question: is there a cross compiled python in yocto?
Sep 11 07:48:07 <LetoThe2nd> gebreselaisi: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/python
Sep 11 07:48:11 <LetoThe2nd> looks like it :)
Sep 11 07:48:28 <LetoThe2nd> plus, its in poky, not in yocto :P
Sep 11 07:51:35 <gebreselaisi> isn't that a native python?
Sep 11 07:52:05 <LetoThe2nd> native python is amongst the things given.
Sep 11 07:52:27 <gebreselaisi> thing is, I am trying to build some project using python qt bindings
Sep 11 07:52:37 <gebreselaisi> i've build pyqt for target
Sep 11 07:52:50 <gebreselaisi> but the native python cannot open the pyqt libs
Sep 11 07:53:03 <LetoThe2nd> gebreselaisi: well so what is your actual problem? that the bindings don't build? don't work?
Sep 11 07:53:36 <LetoThe2nd> well the pyqt stuff probably links to qt, which is architecture dependent.
Sep 11 07:53:54 <gebreselaisi> from PyQt5 import QtCore | ImportError: tmp/sysroots/i686-linux/usr/lib/python2.7/site-packages/PyQt5/QtCore.so: cannot open shared object file: No such file or directory
Sep 11 07:54:08 <gebreselaisi> yes, it's built for arm
Sep 11 07:54:14 <LetoThe2nd> gebreselaisi: wha not just include python or python3 in your image recipe and see then?
Sep 11 07:54:35 <LetoThe2nd> gebreselaisi: so of course your x86-native python can't do anything with the arm qt.
Sep 11 07:55:12 <gebreselaisi> that is why I was asking if there is some sort of cross compiled python
Sep 11 07:55:42 <LetoThe2nd> of course there is a crosscompiled python. but that is going to run on your target, not on your dev host.
Sep 11 07:56:11 <gebreselaisi> yes, I am a bit dazzled
Sep 11 07:56:30 <gebreselaisi> I mean, one compiled for x86 that is able to load arm libs
Sep 11 07:56:41 <gebreselaisi> the sort of toolchain like
Sep 11 07:56:51 <LetoThe2nd> sounds like what you mean is "a native python that can use other-arch binary libs". and not, i think that does not exist.
Sep 11 07:57:10 <gebreselaisi> so how would I solve my problem then?
Sep 11 07:57:16 <LetoThe2nd> i don't see no problem.
Sep 11 07:57:19 <gebreselaisi> :)
Sep 11 07:57:50 <LetoThe2nd> compile your stuff for the arch you want it to run on. thats no problem, thats technically required.
Sep 11 08:00:12 <LetoThe2nd> and if you want to test arm libraries on your devhost, you're gonna need some means of emulation, e.g. running all together in qemu or such.
Sep 11 08:00:33 <LetoThe2nd> but then again, that is basically not different from running the complete image on your target
Sep 11 08:32:03 <gebreselaisi> LetoThe2nd, the problem is that my pckage has a Makefile which uses pyuic5
Sep 11 08:32:27 <gebreselaisi> which is a file that should be generated by pyqt
Sep 11 08:32:44 <gebreselaisi> looking at my host pyuic5 file, I see it is like:
Sep 11 08:32:59 <gebreselaisi> #!/bin/sh
Sep 11 08:32:59 <gebreselaisi> exec /usr/bin/python3.4 -m PyQt5.uic.pyuic ${1+"$@"}
Sep 11 08:33:42 <LetoThe2nd> gebreselaisi: sounds like your build process is not crosscompile aware. so if you want to actually build your stuff with yocto, you'll have to fix that
Sep 11 08:33:45 <gebreselaisi> if I have the same installed in the x86 sysroot in my build, it will error out saying that it cannot loat libQtCore module, which is a module generated by pyqt, but it's for arm
Sep 11 08:34:48 <gebreselaisi> what do you mean it is not crosscompile aware?
Sep 11 08:35:00 <gebreselaisi> crosscompile in regards to what eaxctly do you mean?
Sep 11 08:35:04 <LetoThe2nd> its a common problem that software builds are written only with native compilation in mind. but for your specific package, this is nothing that oe/poky/yocto can fix, IMHO
Sep 11 08:35:48 <LetoThe2nd> gebreselaisi: you said your build does something like exec /usr/bin/whatever. this means it uses whatever runs on the host. so its not crosscompile aware.
Sep 11 08:37:08 <gebreselaisi> no, my build looks for a certan script
Sep 11 08:37:21 <gebreselaisi> which should be generated by pyqt, but it is not
Sep 11 08:37:30 <gebreselaisi> so I can have it installed in the x86 sysroot
Sep 11 08:37:48 <gebreselaisi> the script is called pyuic5
Sep 11 08:37:52 <LetoThe2nd> maybe also pyqt is not crosscompile aware, it's nothing that i have expertise in.
Sep 11 08:37:56 <gebreselaisi> on my host, pyuic5 looks like:
Sep 11 08:38:24 <LetoThe2nd> or maybe it is, and you are still trying to run arm software on your x86 box, which is just not going to work.
Sep 11 08:38:37 <gebreselaisi> the problem is this
Sep 11 08:38:52 <gebreselaisi> exec python -m PyQt5.uic.pyuic ${1+"$@"}
Sep 11 08:38:58 <gebreselaisi> this is in a script
Sep 11 08:39:07 <gebreselaisi> used by my package's Makefile
Sep 11 08:39:26 <gebreselaisi> when it does the -m PyQt5.uic.pyuic
Sep 11 08:39:33 <gebreselaisi> it will try to load the pyqt modules
Sep 11 08:39:37 <gebreselaisi> but those are for arm
Sep 11 08:40:14 <LetoThe2nd> "not cross compile aware". some part in your tool chaining is that. but i cannot help you there, sorry. i'm no pyhton guy.
Sep 11 08:41:46 <gebreselaisi> so yeah, the problem boils down to python
Sep 11 08:41:52 <gebreselaisi> thanks anyway
Sep 11 08:58:08 <bluelightning> morning all
Sep 11 10:19:56 <Aleksandr> is here anyone from Freescale?
Sep 11 11:35:57 <mckoan> Aleksandr: maybe otavio may help you, ask your question
Sep 11 11:40:38 <Aleksandr> mckoan: Thank you.
Sep 11 11:43:02 <jaro123> hello
Sep 11 11:48:20 <Aleksandr> jaro123: hello. What kind of issue you deal with?
Sep 11 11:48:43 <jaro123> how can I move my autotools steps I did manually (aclocal -Iaclocal-copy / automake -a / ./configure --host=arm-poky-linux-gnueabi / make ) to my recipe?
Sep 11 11:48:55 <rburton> jaro123: "inherit autotools"
Sep 11 11:49:01 <jaro123> Aleksandr : how do you know that?
Sep 11 11:49:24 <rburton> Aleksandr: if you have a question, just ask it.
Sep 11 11:49:36 <jaro123> good, I have: inherit autotools lib_package binconfig pkgconfig
Sep 11 11:51:03 <jaro123> basicaly I am creating a sdl2-image recipe, unfortunately it ends with: | libtool: Version mismatch error.  This is libtool 2.4.2, but the
Sep 11 11:52:04 <jaro123> so I do follow steps descrbed in a adt manual so I can build the sdl2-image library manually
Sep 11 11:52:13 <jaro123> which is great
Sep 11 11:52:51 <Aleksandr> you can try cmake instead of aototools
Sep 11 11:53:06 <jaro123> but builder does know my steps... so I do think there is missing sometting in my recipe
Sep 11 11:53:25 <jaro123> Aleksandr :) great!
Sep 11 11:54:33 <rburton> jaro123: pastebin the recipe?
Sep 11 11:54:38 <jaro123> exactly
Sep 11 11:54:43 <jaro123> moment please
Sep 11 11:56:22 <jaro123> here is the recipe: http://pastebin.com/7dPeJPML
Sep 11 11:57:53 <rburton> it doesn't use cmake, so remove that commented line
Sep 11 11:58:01 <jaro123> WITH: inherit autotools lib_package binconfig pkgconfig : http://pastebin.com/E6Kr07nM
Sep 11 11:58:22 <jaro123> rburton: exactly - the next step
Sep 11 11:58:25 <rburton> don't set —host yourself, let the build do that
Sep 11 11:58:36 <jaro123> let the build... ok
Sep 11 11:58:38 <rburton> why the EXTRA_AUTORECONF line?
Sep 11 11:58:49 <jaro123> #EXTRA_OECONF = " --host=armv7-none-linux-gnueabi"
Sep 11 11:59:00 <jaro123> #inherit autotools lib_package binconfig pkgconfig
Sep 11 11:59:10 <jaro123> inherit cmake
Sep 11 11:59:24 <rburton> sdl2-image uses autotools, not cmake.
Sep 11 12:00:21 <jaro123> I do think also...
Sep 11 12:00:38 <jaro123> with cmake: http://pastebin.com/u1CFxiAj
Sep 11 12:01:30 <rburton> sure.that breaks because it doesn't use cmake
Sep 11 12:01:49 <jaro123> ok, step back toward autotools
Sep 11 12:02:22 <jaro123> so now the youtput is http://pastebin.com/u1CFxiAj
Sep 11 12:02:42 <rburton> that still says cmake
Sep 11 12:03:33 <jaro123> rbutron : my error : http://pastebin.com/E6Kr07nM
Sep 11 12:03:50 <rburton> so why did you add EXTRA_AUTORECONF?
Sep 11 12:03:56 <rburton> doing that can cause problems like that
Sep 11 12:04:01 <jaro123> removed - EXTRA_OECONF and EXTRA_AUTORECONF
Sep 11 12:04:21 <jaro123> and simplier inherit - just : inherit autotools
Sep 11 12:05:18 <jaro123> I do every time a clean : bitbake libsdl2-image -c cleanall
Sep 11 12:06:20 <rburton> if you look at libsdl2.bb youll see it deletes some broken files from the tarball
Sep 11 12:06:28 <rburton> you might have to do the same for libsdl2-image
Sep 11 12:06:37 <jaro123> when I build it manually - it works
Sep 11 12:06:39 <jaro123> http://pastebin.com/7VCNUPSS
Sep 11 12:07:49 <jaro123> rburton - thanks I will check it
Sep 11 12:07:56 <jaro123> but manually it works, can I tell to my recipe just do it same way as I do manually ?
Sep 11 12:09:33 <jaro123> rburton: the problem I have is wrong libtool version (from http://pastebin.com/E6Kr07nM) :  libtool: Version mismatch error.  This is libtool 2.4.2, but the definition of this LT_INIT comes from libtool 2.2.6.
Sep 11 12:10:40 <rburton> which is roughly what the deletions in libsdl2.bb are to fix
Sep 11 12:14:54 <jaro123> oh my good, this one, fight? # Remove old libtool macros.
Sep 11 12:14:59 <jaro123> right?
Sep 11 12:18:44 <jaro123> rburton: thank you I will go this way
Sep 11 12:31:56 <jaro123> rburton: works
Sep 11 12:37:44 <jaro123> Does anyone use the apache2 + mariadb + phpmyadmin ( from meta-openembedded/meta-oe ) ?
Sep 11 12:39:18 <jaro123> is an initial database configuration needed ? because the phpmyadmin can not connect the sql daemon and it even seems no sql daemon is running
Sep 11 12:45:05 <bluelightning> jaro123: mysqld should be running
Sep 11 12:45:24 <bluelightning> jaro123: FWIW I maintain that set of recipes basically
Sep 11 12:45:41 <bluelightning> although to be fair I probably don't do the best job of it
Sep 11 12:46:07 <jaro123> bluelightning: hi :) really? nice
Sep 11 12:46:54 <jaro123> bluelightning: usually I am using ps aux but the parameters does not work on my target (probably ps comes from busybox)
Sep 11 12:47:09 <bluelightning> the only thing you should need to do is to set a mysql user password, then you should be able to use phpmyadmin
Sep 11 12:47:32 <jaro123> bluelightning: how can I see the mariadb daemon is running?
Sep 11 12:47:54 <bluelightning> ps | grep mysql
Sep 11 12:49:02 <jaro123> bluelightning: I will check it again
Sep 11 13:02:00 <jaro123> bluelightning: bye
Sep 11 14:30:03 <WarheadsSE> bluelightning: rburton found another issue with ca-certificates & c_rehash. It seems that if you enable it by removing the patch, you're now going to get issues about not being able to configure the package offline due to ro rootfs
Sep 11 14:30:30 <WarheadsSE> Looks like I will have to keep digging/dicking around to make this happy.
Sep 11 14:52:40 <WarheadsSE> Yup, indeed. the do_isntall_append has update-ca-certificates, which of course would break this
Sep 11 14:52:56 <WarheadsSE> since c_rehash would get called, and not handle the SYSROOT's
Sep 11 16:46:08 <helpme> hi
Sep 11 16:46:20 <helpme> can someone help me please with my EM2440 ?
Sep 11 17:15:30 <fishey1> Is there a way to force refetch of a local git package that I'm actively updating? -c cleanall doesn't seem to cut it
Sep 11 17:16:29 <fishey1> (niether does -c fetch)
Sep 11 17:16:37 <WarheadsSE> Are you using srcrevs?
Sep 11 17:28:35 <fishey1> WarheadsSE: no
Sep 11 17:29:59 <fishey1> WarheadsSE: well, SRCREV="${AUTOREV}"
Sep 11 17:30:13 <fishey1> not really sure what that does, though.
Sep 11 17:31:08 <WarheadsSE> I can't say AUTOREV has been perfect for me..
Sep 11 18:36:23 <fishey1> I've fallen back on doing `find yocto-obj-dir -name 'package-im-tweaking' -exec rm -rf \{\} \;`
Sep 11 18:36:37 <fishey1> it's a real shame I can't rely on bitbake's cleanall :(
Sep 11 19:04:59 <WarheadsSE> K: here's a convoluted one
Sep 11 19:05:51 <WarheadsSE> After re-enabling c_rehash, I get an issue where during postinst for an image, it is complainig about my native sysroot not having usr/bin/env
Sep 11 19:06:00 <WarheadsSE> (which it apparently doesnt)
Sep 11 19:06:12 <WarheadsSE> And then, looking further, it would not have perl either.
Sep 11 19:06:23 <WarheadsSE> so the openssl perl c_rehash = pain.
Sep 11 19:44:33 <WarheadsSE> Anyone have a thought on the right way to fix that?
Sep 11 20:04:05 <camaronut> so I'm trying to use bitbake <image> -g -u depexp to explore image dependencies.  And I'm updating my custom image bitbake file.  In particular, I removed "EXTRA_IMAGE_FEATURES += "tools-debug"".  But it appears the update of my image.bb file didn't take.
Sep 11 20:04:40 <camaronut> It seems that depexp is using a cached version of my recipe.  Anyway to purge that cache
Sep 11 20:04:43 <camaronut> ?
Sep 11 20:05:17 <camaronut> I've tried touching my meta-custom/conf/layer.conf, didn't help
Sep 11 20:05:39 <camaronut> I also tried bitbake -c cleanstate <image>, still no dice.
Sep 11 20:06:53 <camaronut> I do not have a PR variable in my image recipe, I'll try that next.
Sep 11 20:09:07 <camaronut> PR = "r1" didn't help.
Sep 11 20:51:28 <camaronut> I think I found my problem... local.conf also had "EXTRA_IMAGE_FEATURES += "tools-debug"".  Dangit.
Sep 11 20:57:35 <WarheadsSE> Figure out my ca-certs thing: DEPENDS_class-native
Sep 11 23:45:59 <khem> what does this warning needs /tmp/sstate-control/manifest-image-tools.populate_sysroot not found
Sep 12 01:50:37 <mranostay> no pidge?
**** ENDING LOGGING AT Fri Sep 12 02:59:58 2014