**** BEGIN LOGGING AT Thu Nov 21 02:59:59 2013
Nov 21 07:49:51 <ndec> hi JaMa, i am trying to understand your 'state of bitbake world', and trying to reproduce some build failures. i don't see where you configure Qt5 related stuff. e.g. you probably enabled 'icu' somewhere , where is that?
Nov 21 08:04:45 <mckoan> good morning
Nov 21 08:48:08 <koen> RP_: what's the goal of linux-dummy.bb?
Nov 21 08:48:21 <koen> 'git log --follow' is being useless for that
Nov 21 08:48:57 <koen> I'd like to enhance it so it will actually stage headers and allow 'perf' to build, but I'm not sure if that's in the scope for linux-dummy
Nov 21 09:04:13 <RP> koen: it was intended to allow someone to build a system without a kernel
Nov 21 09:04:41 <RP> koen: perf and headers are therefore kind of out of scope
Nov 21 09:09:18 <koen> RP: right, I expected as much
Nov 21 09:09:40 <koen> the situation I am in now calls for perf, but also for not building a kernel
Nov 21 09:38:07 <ZetaNeta> i were sent here from #angstrom to ask how to use sysvinit instead of systemd
Nov 21 09:38:18 <ZetaNeta> as systemd needs CONFIG_DEVTMPFS
Nov 21 09:38:27 <ZetaNeta> And my kernel got no such option
Nov 21 09:44:31 <ZetaNeta> or anything else (like OpenRC), but not systemd
Nov 21 09:52:49 <JaMa> ndec: have you seen the wiki page related to that?
Nov 21 09:53:02 <ndec> yes...
Nov 21 09:53:52 <JaMa> ndec: check some recent world_fixes.inc file
Nov 21 09:54:14 <JaMa> e.g. this one http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/log.world.20131120_212012.log/world_fixes.inc
Nov 21 09:54:34 <ndec> ah, sorry... i didn't notice that the one linked on the wiki was an old one...
Nov 21 09:54:38 <ndec> i see it now...
Nov 21 09:55:16 <JaMa> I'll update the link, but the point is that every world report has own file
Nov 21 09:55:50 <ndec> ok, got it. now.
Nov 21 09:57:50 <bluelightning> morning all
Nov 21 09:58:48 <bluelightning> ZetaNeta: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#selecting-an-initialization-manager
Nov 21 10:09:02 <RP> koen: you could have a perf recipe which just downloads kernel source directly?
Nov 21 10:19:25 <koen> RP: right
Nov 21 10:19:40 <koen> I'm not sure how to 'fix' this situation
Nov 21 10:19:53 <koen> in the long run I want every machine to build a real kernel :)
Nov 21 10:31:47 <Noor> hello all
Nov 21 10:32:17 <Noor> I was trying to understand what SPDXLICENSEMAP[GPLv3] = "GPL-3.0" means
Nov 21 10:32:17 <Noor> can anybody explain it to me
Nov 21 10:32:42 <Noor> I googled to get explanation of SPDXLICENSEMAP but did not find any
Nov 21 10:35:17 <bluelightning> Noor: it means that LICENSE = "GPLv3" will be mapped to "GPL-3.0" so that the licensing code can find the appropriate matching license text file in meta/files/common-licenses
Nov 21 10:35:41 <Noor> aahhhh OK 
Nov 21 10:36:04 <Noor> bluelightning: but it will have no impact on INCOMAPTIBLE_LICENSES
Nov 21 10:36:55 <Noor> if we have INCOMPATIBLE_LICENSE ?= "GPLv3 LGPLv3" set then will that recipe will be built which have GPL-3.0
Nov 21 10:38:01 <bluelightning> hmm, looking at the code, that might be the case
Nov 21 10:38:39 <Noor> bluelightning: can you point me which piece of code you are looking
Nov 21 10:38:50 <Noor> just for knowledge increase
Nov 21 10:39:11 <bluelightning> Noor: classes/base.bbclass
Nov 21 10:39:30 <bluelightning> that's where you will find most of the INCOMPATIBLE_LICENSE handling code
Nov 21 10:39:43 <bluelightning> everything else is in classes/license.bbclass
Nov 21 10:40:41 <Noor> bluelightning: thanks
Nov 21 10:40:43 <Noor> got it
Nov 21 10:40:44 <silvio_> morning all
Nov 21 10:40:47 <bluelightning> hi silvio_
Nov 21 10:40:49 <mrAlmond> hi
Nov 21 10:41:17 <mrAlmond> how can I make a build in oe-yocto for an armv4 processor?
Nov 21 10:41:37 <mrAlmond> must I write a machine config file?
Nov 21 10:42:43 <bluelightning> mrAlmond: you should yes
Nov 21 10:42:52 <bluelightning> unless one exists already
Nov 21 10:43:14 <mrAlmond> bluelightning : how can I check if one already exists?
Nov 21 10:43:26 <mrAlmond> where should I look?
Nov 21 10:43:33 <bluelightning> mrAlmond: http://layers.openembedded.org/layerindex/branch/master/machines/
Nov 21 10:44:43 <mrAlmond> I've search for armv4 and the only result is generic-armv4t
Nov 21 10:45:02 <mrAlmond> I must check the differences between armv4 and armv4t
Nov 21 10:55:44 <bluelightning> thumb vs non-thumb I think
Nov 21 10:55:54 <bluelightning> (well, other way round respectively)
Nov 21 11:15:42 <mrAlmond> bluelightning : I'm trying to use meta-handheld layer with yocto because it seems there are some machine files that could be ok for armv4
Nov 21 11:15:57 <mrAlmond> I've downloaded the meta-handheld layer using git
Nov 21 11:16:05 <mrAlmond> I've configured it in layers.conf
Nov 21 11:16:13 <bluelightning> mrAlmond: FWIW, I'm one of the maintainers of that layer as it happens ;)
Nov 21 11:16:24 <mrAlmond> great!
Nov 21 11:16:31 <bluelightning> mrAlmond: what do you plan on setting MACHINE to?
Nov 21 11:16:47 <mrAlmond> I've tried with poodle
Nov 21 11:16:56 <bluelightning> ok, that should be fine
Nov 21 11:17:09 <mrAlmond> but now klibc class file is missing
Nov 21 11:17:25 <mrAlmond> what am I missing?
Nov 21 11:17:29 <bluelightning> meta-handheld also requires meta-initramfs
Nov 21 11:17:43 <bluelightning> this is documented in the README file and in the layer index entry
Nov 21 11:17:48 <mrAlmond> ok
Nov 21 11:17:56 <mrAlmond> are there other dependencies?
Nov 21 11:18:17 <bluelightning> no, shouldn't be
Nov 21 11:23:10 <mrAlmond> here I am again...damned connection...
Nov 21 11:27:22 <mrAlmond> bluelightning : I've seen that poodle uses tune xscale
Nov 21 11:27:40 <mrAlmond> in which the armv5te architecture is used but also armv4 is mentioned
Nov 21 11:28:06 <mrAlmond> PACKAGE_EXTRA_ARCHS += "${@['armv4b armv4tb armv5teb', 'armv4 armv4t armv5te'][ bb.data.getVar('TARGET_ARCH', d, 1) == 'arm']}"
Nov 21 11:30:14 <mrAlmond> so which arch is used for rootfs?
Nov 21 11:30:24 <bluelightning> depends what DEFAULTTUNE says I think
Nov 21 11:31:35 <silvio_> some suggest to show "fast" an imag on framebuffer on oe?
Nov 21 11:33:54 <mrAlmond> BLUELIG
Nov 21 11:33:58 <mrAlmond> sorry
Nov 21 11:34:21 <mrAlmond> bluelightining : so I should use DEFAULTTUNE in the machine file?
Nov 21 11:34:27 <mrAlmond> using armv4?
Nov 21 11:38:45 <mrAlmond> bluelightning
Nov 21 11:39:25 <bluelightning> well, tune-xscale isn't really right if your hardware isn't xscale
Nov 21 11:39:58 <bluelightning> (xscale is armv5 in any case)
Nov 21 11:40:27 <mrAlmond> it's a marvell armada pxa166
Nov 21 11:40:48 <mrAlmond> in wikipedia they say it should be armv5te
Nov 21 11:40:59 <mrAlmond> but I can compile binaries only using armv4
Nov 21 11:41:40 <bluelightning> hmm, ok, so it ought to be xscale
Nov 21 11:41:44 <bluelightning> and it ought to be armv5te yes
Nov 21 11:42:30 <mrAlmond> http://www.marvell.com/application-processors/armada-100/assets/armada_16x_software_manual.pdf
Nov 21 11:43:48 <mrAlmond> The ARMADA 16x Applications Processor Family contains one embedded high-performance Marvell® SheevaTM PJ1 core that is compatible with the ARM V5TE instruction set processors
Nov 21 11:43:59 <bluelightning> that sounds a bit like kirkwood
Nov 21 11:44:13 <bluelightning> at least it sounds like it might have a similar core
Nov 21 11:44:28 <mrAlmond> but they compile using march armv4
Nov 21 11:44:38 <mrAlmond> I really don't understand this mess
Nov 21 11:44:41 <bluelightning> who is "they"?
Nov 21 11:44:59 <mrAlmond> it's another company that worked on this chip
Nov 21 11:45:08 <bluelightning> hmm ok
Nov 21 11:45:10 <mrAlmond> they released us an old "sdk"
Nov 21 11:45:25 <mrAlmond> and everywhere they use armv4
Nov 21 11:45:34 <mrAlmond> otherwise binaries will not work
Nov 21 11:45:35 <bluelightning> it could possibly be that at the time gcc was producing incorrect code for armv5 for that chip perhaps
Nov 21 11:46:04 <mrAlmond> it's a project done 5-6 years ago
Nov 21 11:46:25 <bluelightning> anyway, xscale + DEFAULTTUNE set to armv4 may work
Nov 21 11:46:51 <mrAlmond> so you said that an old compiler may use armv4 because it's compatible will all arm architectures?
Nov 21 11:50:11 <mrAlmond> bluelightning : should I specify DEFAULTTUNE_poodle ?= armv4 in my local.conf ?
Nov 21 11:50:59 <bluelightning> use = not ?=, otherwise yes
Nov 21 11:51:06 <mrAlmond> ok thank you!!!!
Nov 21 11:51:15 <mrAlmond> you are great!
Nov 21 11:51:24 <bluelightning> but to be honest it's probably best if you create your own machine conf file (by copying that file as a start)
Nov 21 11:51:37 <bluelightning> you'll want one later anyway
Nov 21 11:54:49 <ensc|w> mrAlmond: for pxa168, I use require conf/machine/include/tune-xscale.inc
Nov 21 12:13:25 <pb_> hi all
Nov 21 12:14:45 <florian> hey pb_ 
Nov 21 12:15:33 <pb_> afternoon florian
Nov 21 13:13:40 <mrAlmond> ensc|w yes I am using that one too
Nov 21 13:13:45 <mrAlmond> thank you
Nov 21 14:46:34 <koen> JaMa: can you push that "Restore few MIRROR variables" patch today?
Nov 21 15:49:14 <JaMa> koen: y
Nov 21 18:23:46 <Crofton|work> Does anyone understand this?
Nov 21 18:23:47 <Crofton|work> http://pastebin.com/3HXV1HaZ
Nov 21 18:23:56 <Crofton|work> semi random I think
Nov 21 18:24:48 <pb_> rp has a patch for that, see the list
Nov 21 18:24:55 <Crofton|work> k
Nov 21 18:25:04 <Crofton|work> I thought it sounded familiar
Nov 21 18:25:46 <pb_> in fact, I thought the patch had already been applied, but maybe not.
Nov 21 18:26:07 <Crofton|work> yeah, thi sis oe-core from a few days back, but I didn't see anything obvious in git log
Nov 21 18:26:13 <Crofton|work> but I can bump the rev
Nov 21 18:26:23 * Crofton|work is testing repo for managing layers
Nov 21 18:28:07 <pb_> I think you need a new bitbake as well.
Nov 21 18:28:25 <pb_> iirc, the bug was fundamentally a bitbake one.
Nov 21 18:31:01 <Crofton|work> hmm, nothing obvious there, must conslt list archive 
Nov 21 18:31:06 <Crofton|work> thanks pb_ 
Nov 21 18:33:14 <pb_> http://lists.openembedded.org/pipermail/bitbake-devel/2013-November/004136.html
Nov 21 18:33:15 <pb_> is the one
Nov 21 18:55:44 <cmorgan> i'm seeing the texinfo issue with setup-scripts.git master and f19
Nov 21 18:57:22 <cmorgan> i was under the impression that the texinfo issues with eglibc were fixed some time ago...
Nov 21 18:57:56 <cmorgan> (angstrom setup-scripts.git btw)
Nov 21 19:01:35 <cmorgan> koen?
Nov 21 19:15:27 <Crofton|work> I bet the Angstrom build is using an unifxed version
Nov 21 19:15:32 <Crofton|work> this rings a bell
Nov 21 19:18:02 <koen> 2012.12, 2013.06 and 2013.12 build on f19 and f20
Nov 21 19:32:08 <cmorgan> koen: I'm using git master from today
Nov 21 19:58:48 <cmorgan> koen: as I mentioned, I'm using git master from today, ran ./oebb.sh update and then a build of console-image and seeing the eglibc texinfo thing with 'vsep' and 'hsep'
Nov 21 20:06:00 <cmorgan>  i found the previous discuss here about the issue so i thought things were fixed but can't quite understand what might be going on here
Nov 21 20:29:44 <dv_> koen: you too use gstreamer with yocto , right?
Nov 21 20:29:59 <dv_> what is your opinion on this .text relocation issues with libav and gst-libav?
Nov 21 20:48:07 <kergoth> pb_: ping
Nov 21 20:56:24 <pb_> kergoth: yo
Nov 21 20:57:20 <kergoth> pb_: iirc you've messed with emitting a standalone/parallel debug data filesystem before? how are you doing that sort of thing?
Nov 21 20:59:17 <pb_> yeah.  I think nowadays the IMAGE_INSTALL_COMPLEMENTARY thing does most of the heavy lifting.  I'll have a quick look and see what extra bits/changes we have on top of that.
Nov 21 21:02:55 <pb_> kergoth: http://pbcl.net/debugtree.diff seems to be it
Nov 21 21:03:22 <kergoth> ah, nice. thanks
Nov 21 21:03:43 <pb_> add dbg-pkgs to IMAGE_FEATURES, set IMAGE_ROOTFS_DBG to where you want the debug bits put
Nov 21 21:05:28 <kergoth> cool. i could see that being useful. shove the debug fs onto a usb stick or so
Nov 21 21:12:30 <pb_> dv_: iirc, there is no good reason for gst-libav to have relocations in .text on any platform other than x86.
Nov 21 21:12:36 <pb_> I thought that was all fixed ages ago.
Nov 21 21:12:50 <dv_> only for some architectures
Nov 21 21:13:18 <dv_> the fixes were to add cases for armv5te etc. to enable pic for everything
Nov 21 21:13:21 <pb_> ah.  well, send patches to fix it for the others. :-}
Nov 21 21:13:58 <dv_> I thought of that. but hunting after architectures is no long term solution
Nov 21 21:14:00 <pb_> right, libav should be built -fpic for everything except x86.
Nov 21 21:14:10 <pb_> it shouldn't really be necessary to enumerate all the architectures that are not x86.
Nov 21 21:14:18 <pb_> it would be quicker to just enumerate the one that is.
Nov 21 21:14:21 <dv_> yes
Nov 21 21:14:28 <dv_> same problem exists in the libav package btw
Nov 21 21:14:51 <dv_> which is why I didnt fix this in the gstreamer 1.2.0 patch. this is a separate problem.
Nov 21 21:15:16 <pb_> right.  well, if you wanted to send a patch to enable -fpic in libav for (literally) anything other than x86 then I think that would be a fine idea.
Nov 21 21:16:31 <pb_> if it still has the big list of "things that are not x86" that needs updating every time a new architecture is invented then I agree that this is silly.
Nov 21 21:39:50 <oneQubit> anyone ever have oe-init-build-env fail the 'test -d "$BITBAKEDIR"' portion even if $BITBAKEDIR exists?
Nov 21 21:40:08 <kergoth> it's not a symlink, is it? :)
Nov 21 21:40:13 <oneQubit> kergoth, nope
Nov 21 21:40:16 <kergoth> weird
Nov 21 21:41:26 <oneQubit> I appear to have encountered some strange problem (possibly dealing with SIGPIPE), running: 'test -d "$BITBAKEDIR"; echo $?' returns 0, however '(test -d "$BITBAKEDIR"); echo $?', which parenthesis, return 141.
Nov 21 21:41:28 <oneQubit> VERY weird.
Nov 21 21:42:34 <oneQubit> only on this one system however, on my others systems, both return 0.
Nov 21 21:43:10 <kergoth> sounds like a bug in the version of the shell you're using on that machine
Nov 21 21:44:19 <oneQubit> both are "GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu)", they're Ubuntu 12.04 systems
Nov 21 21:44:27 <kergoth> very strange
Nov 21 21:45:06 <oneQubit> makes-me-want-to-pull-my-hair-out strange
Nov 22 02:03:14 <boost12>  satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-image-core |  *    libc6 (>= 2.17) * 
Nov 22 02:03:22 <boost12> how to solve this error
**** ENDING LOGGING AT Fri Nov 22 03:00:00 2013