**** BEGIN LOGGING AT Thu Dec 04 02:59:59 2014
Dec 04 03:06:50 <chankit> anyone had x264 package working?
Dec 04 07:06:35 <kanupatar> hi
Dec 04 07:06:46 <kanupatar> how can I enable mesa during bitbake?
Dec 04 07:17:41 <chankit1> kanupatar: just put CORE_IMAGE_EXTRA_INSTALL += " mesa " inside local.conf
Dec 04 07:18:27 <kanupatar> chankit1: thanks
Dec 04 07:18:36 <kanupatar> chankit1: how to check if it is already built
Dec 04 07:18:40 <chankit1> kanupatar: np
Dec 04 07:20:56 <chankit1> kanupatar: you can boot it and do smart query mesa...if you mean checking without booting the image then I don't really know how
Dec 04 07:22:55 <kanupatar> chankit1: where should I put in local.conf?
Dec 04 07:31:17 <chankit1> kanupatar: I guess anywhere would do but putting it at the end would the best I think
Dec 04 07:31:22 <chankit1> *end of the file
Dec 04 07:32:10 <kanupatar> chankit1: thanks...but does CORE_IMAGE_EXTRA_INSTALL += " mesa " will build the mesa?
Dec 04 07:32:26 <chankit1> kanupatar: it should
Dec 04 07:32:34 <kanupatar> install ->> build + install ?
Dec 04 07:32:54 <kanupatar> DISTRO_FEATURES_append = "mesa"
Dec 04 07:32:55 <kanupatar> ?
Dec 04 07:33:01 <kanupatar> only builds?
Dec 04 07:33:34 <chankit1> kanupatar: I lost you at "install ->> build + install ?"
Dec 04 07:33:47 <kanupatar> chankit1: sorry
Dec 04 07:34:02 <chankit1> no problem I do that all the time with the maintainers
Dec 04 07:34:10 <kanupatar> chankit1: okay
Dec 04 07:34:18 <kanupatar> so why not DISTRO_FEATURES_append = "mesa" ?
Dec 04 07:36:04 <kanupatar> chankit1: also to get opengl support, CORE_IMAGE_EXTRA_INSTALL += " opengl" is enough?
Dec 04 07:41:54 <chankit1> yeah......
Dec 04 07:44:44 <kanupatar> chankit1: okay
Dec 04 07:44:53 <kanupatar> chankit1: I have a default local.conf
Dec 04 07:45:19 <kanupatar> chankit1: if possible, can you point me an ideal local.conf for a high end system?
Dec 04 07:46:11 <chankit1> kanupatar: depending on your usage, everyone's local.conf can be very different
Dec 04 07:46:27 <chankit1> I would suggest reading up http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html to get more insight :-)
Dec 04 07:46:31 <kanupatar> chankit1: I understand...
Dec 04 07:48:51 <kanupatar> chankit1: Do I get a reference local.conf as I am a newbie
Dec 04 07:57:22 <chankit1> there is one in meta-yocto/conf/local.conf.sample
Dec 04 07:58:11 <kanupatar> chankit1: thanks
Dec 04 07:58:24 <kanupatar> also, how can I open bitbake image creator GUI ?
Dec 04 07:58:37 <chankit1> hob command
Dec 04 07:58:46 <kanupatar> ?
Dec 04 07:59:10 <chankit1> type hob in terminal..assuming you did source oe-init..something command
Dec 04 07:59:32 <kanupatar> chankit1: assuming you did source oe-init..something command?
Dec 04 07:59:55 <chankit1> it's oe-init-build-env to be exact
Dec 04 08:01:43 <kanupatar> chankit1: so how to set up the env?
Dec 04 08:01:53 <kanupatar> ./oe-init-build-env  ?
Dec 04 08:02:11 <kanupatar> chankit1: where it is present?
Dec 04 08:03:19 <kanupatar> chankit1: let me also search
Dec 04 08:05:26 <chankit1> it should be in the main project directory
Dec 04 08:05:43 <chankit1> I guess you should be able to read that up on the documentation link i gave you just now
Dec 04 08:11:29 <kanupatar> chankit1: thanks
Dec 04 08:11:53 <kanupatar> I given the source oe-init-build-e
Dec 04 08:12:05 <kanupatar> source oe-init-build-env
Dec 04 08:12:11 <kanupatar> then given hob
Dec 04 08:12:18 <kanupatar> and it is counting objects
Dec 04 08:12:22 <kanupatar> out of 63
Dec 04 08:12:40 <kanupatar> will the bitbake image creator window appear?
Dec 04 08:16:07 <LetoThe2nd> better just use command line instead of some hob magic.
Dec 04 08:34:13 <lager> chankit1: LetoThe2nd wil hob support custom board build?
Dec 04 08:34:22 <lager> it is not showing my board
Dec 04 08:34:32 <lager> instead some qemu options are shows
Dec 04 08:34:47 <lager> Add layer is not detecting my board conf
Dec 04 08:35:12 <lager> where should I point to get my board conf in hob?
Dec 04 08:35:19 <LetoThe2nd> lager: i don't know what hob supports or not, as i don't use it. i just know that cli supports everything and is not troubled by a mediocre(sorry to the implementers) gui
Dec 04 08:35:40 <lager> LetoThe2nd: okay
Dec 04 08:35:58 <lager> chankit1: any clues?
Dec 04 08:36:07 <lager> LetoThe2nd: anybody aware of hob here?
Dec 04 08:36:31 <lager> what is the expansion of hob?
Dec 04 08:36:38 <LetoThe2nd> lager: why do you ask me?
Dec 04 08:37:00 <LetoThe2nd> lager: i already told you i don'T know what hob exactly supports or does, i don't use it, i don'T recommend it,.
Dec 04 08:37:10 <LetoThe2nd> lager: better learn to do things the proper way.
Dec 04 08:37:16 <lager> LetoThe2nd: sorry
Dec 04 08:37:31 <LetoThe2nd> lager: that means: understand things, instead of clicking random buttons and hoping to do something that you like
Dec 04 08:38:06 <LetoThe2nd> lager: i repeat, because his/her suggestion was good:
Dec 04 08:38:07 <LetoThe2nd> 08:46 < chankit1> I would suggest reading up  http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html to get more  insight :-)
Dec 04 08:38:35 <lager> LetoThe2nd: surely I will try
Dec 04 08:43:23 <mcfrisk> Q: is the yocto task hierarchy/sequence documented somewhere? How to make sure that a task is executed after all all packages have been compiled?
Dec 04 09:01:57 <stiandre> ndec: thank you.. haha, sorry for asking the obvious :)
Dec 04 09:12:29 <mcfrisk> answering to myself: bitbake -c listtasks target name will show which tasks will be executed
Dec 04 09:54:39 <bluelightning> morning all
Dec 04 10:02:01 <stiandre> Hi, I am trying to build my c project using a Makefile-based recipe, and the binary seem to build but when I try to install it, I get "ERROR: objcopy failed... File format not recognized", "ERROR: Function failed: split_and_strip_files". It seem like the binary is build for the host architecture and not the target one.. Any ideas?
Dec 04 10:02:37 <bluelightning> stiandre: you probably need to ensure that the makefile is using the right compiler, cflags etc.
Dec 04 10:03:22 <bluelightning> stiandre: that usually means ensuring it uses CC, CFLAGS etc. and then you pass those in on the make command line from the environment set up automatically by the build system
Dec 04 10:09:38 <stiandre> bluelightning: ahh, thank you, I need to take a look at that
Dec 04 10:18:53 <stiandre> bluelightning: still getting the same architecture error... can you seen anything wrong in my recipe?
Dec 04 10:18:55 <stiandre> DESCRIPTION = "testing makefile-based recipe"
Dec 04 10:18:55 <stiandre> LICENSE = "MIT"
Dec 04 10:18:55 <stiandre> LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
Dec 04 10:18:55 <stiandre> PR = "r0"
Dec 04 10:18:55 <stiandre> SRC_URI = "file://test.tgz"
Dec 04 10:18:56 <stiandre> S = "${WORKDIR}"
Dec 04 10:18:58 <stiandre> EXTRA_OEMAKE = "'CC=${CC}' 'CFLAGS=${CFLAGS} -I${S}' BUILDDIR=${S}"
Dec 04 10:19:00 <stiandre> do_install() {
Dec 04 10:19:02 <stiandre>     oe_runmake
Dec 04 10:19:04 <stiandre>     install -d ${D}${bindir}
Dec 04 10:19:06 <stiandre>     install -m 0755 test ${D}${bindir}
Dec 04 10:19:08 <stiandre> }
Dec 04 10:19:32 <bluelightning> stiandre: you would need to look at the compile log and see what actual commands are being run
Dec 04 10:19:44 <bluelightning> then trace that back to how they are being expressed in the makefile
Dec 04 10:20:19 <bluelightning> I'd recommend not building in ${WORKDIR} as well, that could lead to issues
Dec 04 10:21:05 <bluelightning> you can extract the files into a subdirectory with ;subdir= in SRC_URI
Dec 04 10:21:29 <bluelightning> (if they aren't already in a subdirectory in the tarball, that is)
Dec 04 10:21:53 <stiandre> okay, no all files are in the top level of the tar ball.
Dec 04 10:22:43 <stiandre> okay, and then set S = ${subdir} or ?
Dec 04 10:24:09 <bluelightning> well, it would be S = "${WORKDIR}/<subdirname>" (where <subdirname> is whatever you specified in the subdir= value; of course you could set and use your own variable for that if you want but I usually don't bother)
Dec 04 10:25:13 <stiandre> bluelightning: okay, thanks
Dec 04 10:57:18 <chankit> bluelightning: btw I fixed the proxy issue that I had earlier..turns out that my git-proxy script doesn't agree with bitbake for some reason
Dec 04 11:23:09 <bluelightning> chankit: ah ok, great
Dec 04 12:34:17 <[Sno]_> RP: seen the message regarding http://grokbase.com/t/perl/perl5-porters/141gz52519/remodeling-the-cross-compilation-model
Dec 04 12:38:46 <RP> [Sno]_: I had not, I think that sounds positive for us?
Dec 04 12:39:58 <[Sno]_> half and half ;)
Dec 04 12:40:23 <[Sno]_> it says, the way Perl is cross-compiled in Yocto nowadays is depreciated and needs to be reworked
Dec 04 12:42:40 <[Sno]_> OTOH it sounds as if cross-compiling will be easier in recent versions
Dec 04 12:51:13 <RP> [Sno]_: they do mention building a host miniperl and that is afaict what we do
Dec 04 12:51:40 <RP> [Sno]_: using something officially supported rather than the mess we have right now would be nice.
Dec 04 12:51:49 <[Sno]_> RP: but we cross-compile using -Dusecrosscompile
Dec 04 12:52:13 <[Sno]_> mom - we use Cross/
Dec 04 12:53:04 <[Sno]_> and we should use -Dusecrosscompile
Dec 04 12:54:35 <[Sno]_> RP: I would dig into it after Chrismas (no free minute before)
Dec 04 12:56:32 <RP> [Sno]_: ok, some help in sorting through this and updating would be very much appreciated. I know the time I'm going to get to dive into it is limited
Dec 04 12:56:46 <RP> [Sno]_: we have the same issue with the python recipes too :(
Dec 04 12:57:49 <[Sno]_> the only thing I know about python is how to avoid it ^^ (I know the py-guys know the same about Perl ^^)
Dec 04 12:59:08 <[Sno]> RP: current problem is: I'm still on daisy - when I work on that, the result needs to be "up-ported" ;)
Dec 04 13:01:41 <RP> [Sno]: I guess on the positive side, we've not changed perl much
Dec 04 13:01:53 <RP> (which is good and bad)
Dec 04 13:02:03 <[Sno]> good for up-porting ;)
Dec 04 13:02:06 <RP> right
Dec 04 13:02:58 <[Sno]> the problem with makemaker-native (doesn't install to vendor_perl) remains even with the patch from wolfgang@denx
Dec 04 13:03:15 <[Sno]> I try to fix that together with -Dusecrosscompile
Dec 04 13:05:27 <[Sno]> what is the idea of http://cgit.openembedded.org/meta-openembedded/tree/meta-perl/recipes-perl compared to https://github.com/rehsack/meta-cpan ?
Dec 04 13:07:57 <mcfrisk> How to debug meta package rebuild problems? My meta package is not re-building images but only sdk.
Dec 04 13:17:02 <jmleo> hello ! I am using dizzy right now, and on my board, I have a sd card with two partitions mmcblk0p1 and mmcblk0p2. The last one (ext3) is mount automatically, that's fine, but the first one (vfat) is not. Any idea ?
Dec 04 13:26:22 <bluelightning> [Sno]: we'd love people to submit more recipes to meta-perl, but not everyone is prepared to do that
Dec 04 13:26:36 <bluelightning> [Sno]: jens said he didn't have time last time I asked him to submit a patch...
Dec 04 13:27:08 <bluelightning> [Sno]: ah, didn't realise that's you ;)
Dec 04 13:28:18 <bluelightning> it's fair to say that meta-perl isn't really all that actively maintained at the moment, we could use some help there
Dec 04 13:29:37 <bluelightning> mcfrisk: perhaps try bitbake -g and look at the task dependencies
Dec 04 13:31:06 <[Sno]> bluelightning: meta-perl is more Debian style addicted ...
Dec 04 13:31:59 <[Sno]> I could modify Packager::Utils to write to meta-perl, too
Dec 04 13:31:59 <bluelightning> [Sno]: that's true, that's the style we have been using up to now in OE for perl recipes
Dec 04 13:32:08 <abelloni_> jmleo: I guess the first one is the one you use to boot
Dec 04 13:32:14 <[Sno]> but I do not like that style
Dec 04 13:32:16 <abelloni_> why would you want to mount it ?
Dec 04 13:32:37 <[Sno]> as CPAN author I have a lot of trouble with debian style packaged cpan-modules
Dec 04 13:33:09 <bluelightning> [Sno]: I'm not really a perl person, it could be that we need to change how we do things there; by all means propose it on the mailing list
Dec 04 13:33:24 <[Sno]> which mailing list?
Dec 04 13:33:24 <jmleo> abelloni_: yes
Dec 04 13:33:30 <[Sno]> there're to much ;)
Dec 04 13:33:43 <jmleo> because I want to update my kernel
Dec 04 13:33:48 <jmleo> and it is inside
Dec 04 13:34:01 <bluelightning> [Sno]: openembedded-devel I think probably
Dec 04 13:35:00 <[Sno]> will join these days and start whining ;)
Dec 04 13:35:27 <bluelightning> [Sno]: :)
Dec 04 13:35:34 <[Sno]> will cc you+rp then :)
Dec 04 13:36:08 <bluelightning> [Sno]: sure; I don't know if I will have anything valuable to offer in the way of input but I'll certainly read your posting :)
Dec 04 13:38:37 <[Sno]> bluelightning: I generally loose wordplaying with native speakers when debating technical situations
Dec 04 13:39:08 <[Sno]> so having some people recognizing the postings and stop wordplay battles is helpful
Dec 04 13:39:21 <bluelightning> [Sno]: certainly, no problem
Dec 04 13:41:55 <otavio> Do someone know how I can explicit link with libgcc.a using LD? not gcc.
Dec 04 13:42:10 <otavio> I don't want to pass full gcc path as it is bad for maintenance.
Dec 04 13:47:22 <RP> [Sno]: if gaining active maintainership means some style/name changes, it may well be something worthwhile that we can just make happen
Dec 04 13:47:54 <RP> [Sno]: I didn't even realise there was an issue there so discussing it sounds good. I'll try and help the discussion if/as/where needed
Dec 04 13:49:18 <soderstrom> Hi, I've been playing around a little with the meta-xilinx-community layer, mostly by patching it with support for digilents zybo board. However, I am doing something stupid a long the way. I get two recipes both providing the virtual/kernel. And since one of the things I needed to change is the SRC_URI, only one of those recipes will compile. Actually, I don't even wish for the one that comes with the meta-xilinx layer to be built in the first place. O
Dec 04 13:51:31 <RP> soderstrom: did you set PREFERRED_PROVIDER_virtual/kernel ?
Dec 04 13:52:03 <soderstrom> yes, the problem is it is also set in the other recipe from meta-xilinx
Dec 04 13:52:56 <soderstrom> (or at least I belive that is the problem)
Dec 04 13:56:12 <soderstrom> actually, one of the things I find even more strange is when I run "bitbake -c compile linux-digilent" it uses my recipe and compiles no problem, but when I use "bitbake linux-digilent" to deploy etc then it starts trying to compile the other recipe also.
Dec 04 14:01:58 <RP> soderstrom: recipe don't set PREFERRED_PROVIDER so that doesn't make sense
Dec 04 14:12:23 <bluelightning> soderstrom: I guess you mean it's set in the machine configuration in meta-xilinx?
Dec 04 14:16:02 <mcfrisk> hmm, dot and xdot seem to die on yocto task-depends.dot.. too big and complex?
Dec 04 14:22:54 <bluelightning> mcfrisk: it is a huge file yes... you're better off looking at it directly or just grepping it
Dec 04 14:33:20 <soderstrom> RP,bluelightning: oh, well it is set in meta-xilinx/conf/machine/include/machine-xilinx-default.inc
Dec 04 14:34:23 <bluelightning> soderstrom: you could override it by setting PREFERRED_PROVIDER_virtual/kernel_<machinename> = "<recipename>"
Dec 04 14:35:38 <soderstrom> RP,bluelightning: The actual error message might tell you more "ERROR: Multiple .bb files are due to be built which each provide virtual/kernel (meta-xilinx-community/recipes-kernel/linux/linux-digilent_git.bb meta-xilinx/recipes-kernel/linux/linux-xlnx_3.14.bb)" meaning that for some reason the linux-xlnx_3.14.bb is getting matched when running "bitbake linux-digilent", or at least this is my assumption.
Dec 04 14:36:06 <soderstrom> bluelightning: will try that directly
Dec 04 14:36:20 <bluelightning> soderstrom: probably because that still ends up with a dependecny on virtual/kernel
Dec 04 14:36:31 <bluelightning> the system isn't really designed to support building multiple kernels at once
Dec 04 14:39:18 <soderstrom> bluelightning: that makes since :) And I do only want one kernel also ;)
Dec 04 14:52:22 <mcfrisk> bluelightning: -g files show that correct dependencies are there but in poky 1.5.3 the images are not being rebuild via this dependency. In 1.6 this seems to work.
Dec 04 14:53:28 <bluelightning> mcfrisk: just so I understand, what exactly is being changed that should influence the image recipe?
Dec 04 14:53:52 <mcfrisk> bluelightning: rm -rf tmp
Dec 04 14:55:15 <bluelightning> mcfrisk: and you are building a meta recipe which has a dependency on the image recipe, is that correct?
Dec 04 14:55:47 <mcfrisk> bluelightning: yes, DEPENDS += " image sdk " and only sdk gets built
Dec 04 14:56:16 <bluelightning> and if you bitbake the image it does build the image, right?
Dec 04 14:56:40 <mcfrisk> yes
Dec 04 14:56:59 <mcfrisk> maybe I need to inherit image stuff on the meta package too?
Dec 04 14:57:10 <bluelightning> no, that would only cause more pain
Dec 04 14:57:17 <bluelightning> can you file a bug for this please (noting that it affects 1.5 and not 1.6)?
Dec 04 14:57:22 <mcfrisk> pn-depends.dot has the dependencies correctly
Dec 04 15:01:28 <mcfrisk> bluelightning: ok, I'll try to get the bug filed but will also try to debug this...
Dec 04 15:06:20 <bluelightning> mcfrisk: I'd suspect a fix was applied to bitbake in 1.6 that wasn't backported
Dec 04 15:15:16 <mcfrisk> bluelightning: maybe b60ed2d0fd86a3ae5ce7facbb044677aa7ec2889 ?
Dec 04 15:16:03 <bluelightning> mcfrisk: no, that looks unrelated to me
Dec 04 15:18:15 <rburton> otavio: http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-graphics/drm/libdrm_%25.bbappend <— can you put a space before the value in the _append pls
Dec 04 15:18:33 <soderstrom> bluelightning: Thank you for your help :) Seems like specifying the machine and recipe together with the PREFERRED_PROVIDER_virtual/kernel solved the issue. Still compiling do, but the should have appeared already if it was still there.
Dec 04 15:22:40 <bluelightning> soderstrom: FYI, the _<machinename> is an override specific to the machine; it's a construct available for any variable (although overrides should really only be used where necessary)
Dec 04 15:35:31 <ndec> rburton: not sure i understand your last email. are you going to merge using the snippet i sent, or are you expecting a proper patch/email from me?
Dec 04 15:36:51 <rburton> ndec: i'll either merge with your snippet, or wait for anibal to send a revised one today - he's already reworking mesa/xserver anyway.
Dec 04 15:37:11 <ndec> ok.. so nothing needed from me then ;-)
Dec 04 16:24:08 <otavio> rburton: http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-graphics/drm
Dec 04 16:24:26 <otavio> rburton: this does not seem to exist
Dec 04 16:25:14 <rburton> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-graphics/drm/libdrm_%25.bbappend <— line 3
Dec 04 16:25:29 <rburton> append needs whitespace
Dec 04 17:44:03 <rburton> otavio: also, can you test the new uboot v3 patches?
Dec 04 18:05:52 <otavio> rburton: I will look at it
Dec 04 18:16:19 <Guma> I have img file that I need to autoresize on first boot (sd card). I can write a script to do this with fdisk/resizefs. But I am not sure where to hook it before root partition is mounted. The idea here is that root should be autoresized to take advantage of all space available on sd card. Users can have different sd card sizes. Any ideas?
Dec 04 18:23:21 <ntl> Guma: ext3/ext4 can be enlarged online, so you don't necessarily need to to it before mounting
Dec 04 22:08:09 <paulg> anyone know anything about the htmlentitydefs being missing failure  that happened in nightly build #93?
Dec 04 22:08:20 <paulg> https://autobuilder.yoctoproject.org/main/builders/nightly-mips-lsb/builds/93/steps/BuildImages/logs/stdio/text
Dec 04 22:09:34 <paulg> I've just got the same thing happening in a buildappliance variant.
Dec 05 02:10:18 <chankit1> anyone had luck with comping clang recipe in yocto?
**** ENDING LOGGING AT Fri Dec 05 02:59:58 2014