Monday, 2013-08-12

*** mulhern <mulhern!> has joined #yocto00:12
*** _julian_ <_julian_!> has joined #yocto00:37
*** _julian <_julian!> has quit IRC00:40
*** joey_saint <joey_saint!> has quit IRC01:00
*** mulhern <mulhern!> has quit IRC01:02
*** swex__ <swex__!~swex@> has quit IRC01:17
*** swex__ <swex__!~swex@> has joined #yocto01:21
*** behanw <behanw!> has quit IRC01:43
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto02:03
*** klinger_ <klinger_!> has joined #yocto03:07
*** klinger <klinger!> has quit IRC03:10
*** andyross <andyross!> has quit IRC03:32
*** bln <bln!> has joined #yocto03:45
*** bln <bln!> has quit IRC03:54
*** andyross <andyross!> has joined #yocto03:55
*** silviof3 <silviof3!> has joined #yocto04:01
*** silviof2 <silviof2!> has quit IRC04:03
*** amarsman <amarsman!> has quit IRC04:15
*** agust <agust!> has joined #yocto04:29
*** andyross <andyross!> has quit IRC04:53
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC05:01
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto05:02
*** nitink <nitink!~nitink@> has quit IRC05:10
*** uvan <uvan!7645dbc5@gateway/web/freenode/ip.> has joined #yocto05:25
*** zecke <zecke!> has joined #yocto05:26
*** melonipoika <melonipoika!> has joined #yocto05:28
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC05:34
*** zecke <zecke!> has quit IRC05:35
*** ndec|vacations is now known as ndec05:40
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto05:51
*** mshakeel <mshakeel!~mshakeel@> has quit IRC06:09
*** mshakeel <mshakeel!~mshakeel@> has joined #yocto06:14
*** zedd_ <zedd_!~ddez@> has joined #yocto06:15
*** zeddii <zeddii!~ddez@> has quit IRC06:19
*** slaine <slaine!~slaine@> has joined #yocto06:21
*** zecke <zecke!> has joined #yocto06:26
*** j8 <j8!~IceChat9@> has quit IRC06:30
*** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has quit IRC06:36
*** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has joined #yocto06:37
*** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has joined #yocto06:38
*** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has quit IRC06:38
*** shoragan <shoragan!~jlu@2001:6f8:1178:2:219:99ff:fe56:8d7> has joined #yocto06:38
*** shoragan <shoragan!~jlu@debian/developer/shoragan> has joined #yocto06:38
*** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has joined #yocto06:42
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto06:43
*** TuTizz <TuTizz!~TuTizz@> has quit IRC06:45
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto06:45
*** B4gder <B4gder!> has joined #yocto07:00
*** fabo <fabo!~fabo@linaro/fabo> has joined #yocto07:02
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC07:02
*** hico <hico!50966342@gateway/web/freenode/ip.> has joined #yocto07:04
*** silviof4 <silviof4!> has joined #yocto07:07
*** silviof3 <silviof3!> has quit IRC07:09
*** silviof <silviof!~silviof@unaffiliated/silviof> has joined #yocto07:09
*** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has joined #yocto07:10
*** silviof4 <silviof4!> has quit IRC07:11
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto07:14
*** amarsman <amarsman!> has joined #yocto07:21
*** zeeblex <zeeblex!apalalax@nat/intel/x-dyzdhscuxblwqdjz> has joined #yocto07:30
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto07:33
lpappgood morning07:33
*** klinger_ <klinger_!> has quit IRC07:46
*** bluelightning <bluelightning!~paul@> has joined #yocto07:51
*** bluelightning <bluelightning!~paul@> has quit IRC07:51
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto07:51
bluelightningmorning all07:59
thesignalmorning bluelightning07:59
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC08:00
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto08:00
*** mihai <mihai!~mihai@> has joined #yocto08:21
*** jackmitchell <jackmitchell!> has joined #yocto08:21
*** klinger_ <klinger_!~klinger@> has joined #yocto08:27
RPmorning all08:27
*** honschu_ <honschu_!~honschu@shackspace/j4fun> has quit IRC08:32
*** honschu <honschu!~honschu@shackspace/j4fun> has joined #yocto08:34
*** panda84kde <panda84kde!> has joined #yocto08:38
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto08:40
uvanmorning all. can anyone help me how to create ext2.gz.u-boot image? i already enable IMAGE_FSTYPE = "ext2.gz ext2.gz.u-boot" but image does not create08:46
lpappuvan: u-boot or kernel binary?08:46
lpappuvan: if kernel, what is the problem with uImage?08:47
uvani want to create a "ramdisk" with will work with u-boot08:47
lpappah, I see.08:48
lpappuvan: image built though?08:49
uvanand also want to create uImage too. right now i just only can create Image only. i think i miss something to enable u-boot mkimage08:49
lpappuvan: have you checked this?
uvanlpapp: yes, not yet. let me try08:52
*** mihai <mihai!~mihai@> has quit IRC08:54
*** mihai <mihai!~mihai@> has joined #yocto08:54
uvanthanks lpapp: it's building. wait for result08:57
lpappuvan: hope it helps.09:01
uvansame with that topic. i got ERROR: cannot map 'allarch' to a linux kernel architecture.09:03
*** belen <belen!~Adium@> has joined #yocto09:05
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto09:06
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC09:13
*** Krz_ <Krz_!c0c6972c@gateway/web/freenode/ip.> has joined #yocto09:17
*** JimBaxter <JimBaxter!> has joined #yocto09:21
*** smartin_ <smartin_!> has joined #yocto09:24
Krz_hi guys, I set my TCLIBC=uclibc and during build eglibc-initial gets compiled. Why is that? Can I stop it?09:27
lpappKrz_: are you using an external toolchain or not?09:28
zeckeKrz_: I don't know but you can use the '-g' option of bitbake and browse the dependencies09:29
Krz_now I'm using linux x64 as host, and setting SDKMACHINE to mingw32 (have my own machine configuration file)09:30
lpappKrz_: I only had such experience when the toolchain was set up wrong, but perhaps there are other scenarios, too.09:31
bluelightningKrz_: check that TCLIBC is actually being set to that value using bitbake -e | grep ^TCLIBC=09:31
Krz_TCLIBC gets set  properly. shows: "nativesdk-eglibc-initial" -> "automake-native" "nativesdk-eglibc-initial" -> "libtool-native" and few others09:33
Krz_so proably no way to stop eglibc-initial getting compiled :/09:33
zeckeshoragan: ping?09:37
bluelightningKrz_: right, that's the key thing - it's nativesdk-eglibc-initial not eglibc-initial09:44
bluelightningKrz_: I could be wrong but I don't know that we currently support building SDKs for other libcs - and this is demonstrated by the fact the TCLIBC="uclibc" configuration explicitly selects eglibc as the provider for the nativesdk variants09:46
bluelightningnot to say it can't be done, just that it's not supported out of the box09:47
RPKrz_: Is this related to the question on the mailing list about building mingw32 toolchains?>10:08
Krz_I just need a xcompiler toolchain under windows10:12
Krz_so trying everything10:12
RPKrz_: The key thing to realise is the way we build our normal cross compilers is to link them to their own libc. On windows you do not want to do that so you don't want any nativesdk-libc10:13
RPKrz_: you probably need to add something to ASSUME_PROVIDED along those lines10:13
*** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has quit IRC10:16
*** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has joined #yocto10:16
*** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has quit IRC10:17
*** OlivierG_ is now known as OlivierG10:18
*** OlivierG <OlivierG!> has left #yocto10:19
*** rburton <rburton!> has quit IRC10:20
*** rburton <rburton!> has joined #yocto10:22
uvanhi lpapp: add inherit image_types_uboot to images.bbclass can make ext2.gz.u-boot rule work10:22
lpappuvan: \o/10:22
uvanbut unfortunately mkimage not support arch is ARM64. so i need more work10:22
Krz_RP: I don't really get it. I still to link my xcompiler against some libc under windows10:22
lpappuvan: hmm? Have you passed the right parameters to mimage?10:23
Krz_RP: actually I have to link against what TCLIBC specifies10:23
bluelightninguvan: I think the correct method is to set IMAGE_CLASSES = "image_types_uboot" FYI10:23
RPKrz_: windows binaries don't have a libc, they have some kind of windows system dlls ?10:23
TuTizzHey, I have got some issu with QtE. I bitbake meta-toolchain-qte and now I want to cross_compile my Qt projects. I found tmp/sysroots/i686-linux/usr/bin/qmake2, but when i try to execute it I have got the "QMAKESPEC has not been set, so configuration cannot be deduced" issue.10:24
TuTizzCan someone tell me what I have to do?10:24
uvanthanks blueligtning. i will do.10:24
*** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has joined #yocto10:24
uvanlpapp: mkimage only support valid names are: alpha, arm, x86, ia64, m68k, microblaze, mips, mips64, nios2, powerpc, ppc, s390, sh, sparc, sparc64, blackfin, avr3210:25
uvanbut i need arm6410:25
lpappnot sure how that is Yocto related.10:25
uvanmaybe i missed confiure something10:25
uvanyes i known10:25
rburtonarm64 is very new, so you'll often be finding the limits of where the support is currently10:26
lpappI have never used arm64. :)10:26
lpappuvan: you may need to build for arm32, then.10:26
lpappand when the u-boot tools get more support, you can switch.10:26
lpappuvan: which u-boot version have you built btw?10:26
uvanmy jobs is support arm64 for Yocto10:26
uvanbut i'n new to yocto10:27
rburtonuvan: looks like you've found something to fix :)10:27
lpappuvan: but what can you do if u-boot does not support it?10:27
panda84kdeHi all, hi otavio. I'm getting this build error using meta-fsl-* from master-next:
lpappThat is not Yocto material if you use the latest u-boot.10:27
lpappthat is why I asked if you had been using that.10:27
uvanactually we already supported. but not for yocto yet10:28
lpappuvan: you are a u-boot dev?10:29
lpappuvan: well, I have the latest u-boot patches on the mailing list.10:29
lpappyou can grab them.10:29
uvanyes, we already ported uboot for arm64. but we not use yocto before10:30
uvanthanks lpapp10:30
lpappuvan: grab my changes, and be done. :)10:30
lpappyou may need to update the checksum... I could not update the change to be honest due to other blockers that no one cares about atm.10:30
uvani see. thanks10:30
bluelightningTuTizz: rather than executing the native qmake you should install the SDK and use that10:42
bluelightningTuTizz: i.e. install the SDK that was created when you built meta-toolchain-qte10:42
TuTizzbluelightning, tmp/deploy/sdk/ ?10:44
bluelightningTuTizz: yes10:44
TuTizzbluelightning, ok thanks you10:44
lpappuvan: g2g, good luck10:44
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto10:44
uvanlpapp: thanks10:45
*** joeythesaint <joeythesaint!~jjm@> has joined #yocto10:48
*** klinger_ <klinger_!~klinger@> has quit IRC10:54
*** exosyst <exosyst!~nick@> has joined #yocto10:54
*** mulhern <mulhern!> has joined #yocto10:55
*** JDuke128 <JDuke128!~kadir@> has joined #yocto11:00
*** uvan <uvan!7645dbc5@gateway/web/freenode/ip.> has quit IRC11:05
*** elmi82 <elmi82!> has joined #yocto11:31
*** belen <belen!~Adium@> has left #yocto11:33
*** belen <belen!~Adium@> has joined #yocto11:33
*** JDuke128 <JDuke128!~kadir@> has quit IRC11:43
*** cristianiorga <cristianiorga!~cristiani@> has joined #yocto12:16
*** challinan <challinan!> has joined #yocto12:27
*** wmat <wmat!> has quit IRC12:35
*** mulhern <mulhern!> has quit IRC12:36
*** SlashV <SlashV!> has joined #yocto12:40
*** mulhern <mulhern!> has joined #yocto12:46
Krz_where do I find recipes for all native tools?12:48
bluelightningKrz_: in the same place as all other recipes13:08
bluelightningKrz_: note that some native tools are produced via BBCLASSEXTEND = "native" in target recipes13:08
Krz_so e.g libtool-native uses recipe?13:08
bluelightningKrz_: no, libtool-native is its own recipe13:09
Krz_BBCLASSEXTEND means I have one recipe to handle native host and sdk host versions?13:20
bluelightningKrz_: depends on the value set for BBCLASSEXTEND13:20
bluelightningKrz_: BBCLASSEXTEND = "native nativesdk" would handle target (default), native (build host) and nativesdk (SDK)13:21
bluelightningKrz_: or you could just have BBCLASSEXTEND = "native" or BBCLASSEXTEND = "nativesdk"13:22
Krz_but then all of the steps in recipe are shared, right?13:22
Krz_if I want totally different do_configure13:22
Krz_then I need two recipes?13:22
RPKrz_: you can do a do_configure_class-native ()13:23
Krz_ok, that sounds13:23
Krz_i presume do_configure_class-nativesdk exists as well ?13:24
RPKrz_: yes, I believe so13:24
Krz_I have to provide bunch of bbappends for all nativesdk tools for mingw, since Yocto tries to build eglibc-initial-nativesdk for them, and they don't need it (and eglibc does not compile for mingw)13:26
*** behanw <behanw!> has joined #yocto13:29
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-gbniezduvrrtljfb> has joined #yocto13:32
*** joshc <joshc!~joshc@rhlug/joshc> has left #yocto13:34
*** simar_ <simar_!~simar@> has quit IRC13:37
*** munch <munch!> has joined #yocto13:41
*** vmeson <vmeson!~quassel@> has quit IRC13:45
*** e8johan <e8johan!> has joined #yocto13:45
RPKrz_: can't you just add virtual/nativesdk-libc to ASSUME_PROVIDED?13:47
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-gbniezduvrrtljfb> has quit IRC14:00
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-cmudzmcuaiscddpj> has joined #yocto14:02
*** mulhern <mulhern!> has quit IRC14:04
*** swex <swex!~swex@> has joined #yocto14:08
*** nerdboy- <nerdboy-!> has joined #yocto14:09
*** swex__ <swex__!~swex@> has quit IRC14:10
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC14:10
*** nerdboy- is now known as nerdboy14:10
*** mulhern <mulhern!> has joined #yocto14:14
*** zenlinux <zenlinux!> has quit IRC14:26
*** e8johan <e8johan!> has quit IRC14:34
Crofton|workRP, welcome back14:36
RPCrofton|work: thanks14:37
RPKrz_: I had a look at mingw32, its been a while. Its runtime libs look like an equivalent to nativesdk-libc so you probably need a recipe which PROVIDES that14:38
Krz_there is a guy: Francois, he is in the middle of the work here:14:39
Krz_so far the layer produces gcc-crosssdk14:39
Krz_for mingw14:39
Krz_and next step is exacty what you are talking about14:41
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC14:45
Krz_recipe which provides nativesdk is already done14:48
Krz_the trick is to tell all nativesdk packages to use it and where to find it14:48
Krz_recipe which provides nativesdk-libc is already done*14:49
*** davest <davest!~Adium@> has joined #yocto14:50
kergothsounds like you're just missing some PROVIDES or associated PREFERRED_PROVIDER_ variables.14:51
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-cmudzmcuaiscddpj> has quit IRC14:53
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-glrysxxjbkgaagbi> has joined #yocto14:53
*** hollisb <hollisb!> has joined #yocto14:54
*** cfo215 <cfo215!> has joined #yocto14:55
*** sroy_ <sroy_!~sroy@2607:fad8:4:6:3e97:eff:feb5:1e2b> has joined #yocto14:56
cfo215I'm having all sorts of issues getting poky working.  I've tried with ubuntu 12.04.2 lts and 13.04, same results.  getting lots of compile failures.  Tried all the docs, not really finding anything useful except I may be able to use external compiler, but which one is the best to use?14:57
*** andyross <andyross!> has joined #yocto14:58
cfo215not sure why poky doesn't work "clean out of box".  Ready to give up.14:58
RPcfo215: what kind of compile failures?14:59
Crofton|workp[astebin the messages14:59
cfo215rp: i'll grab an example.14:59
RPcfo215: also which version of poky are we talking about?14:59
cfo215git clone of current master15:00
cfo215ERROR: Function failed: Fetcher failure for URL: 'git://;protocol=git;bareclone=1;branch=standard/base,meta;name=machine,meta'. Unable to fetch URL from any source.15:00
cfo215I had 3 warnings and 29 failures trying to bitibake core-mage-sato for qemuarm.15:02
RPcfo215: ok, that isn't a compile failure, its a fetching failure15:02
cfo215yeah, sorry bout that, let me grab a compile error.15:02
Crofton|workfirewall issues?15:02
RPcfo215: its trying to clone a git repository and failing and also can't get to the mirrors for some reason15:02
cfo215ERROR: Logfile of failure stored in: /home/epic/poky/build/tmp/work/armv5te-poky-linux-gnueabi/gstreamer/0.10.36-r2/temp/log.do_unpack.651515:03
RPcfo215: that still isn't a compile failure, it is unable to unpack something15:04
RPcfo215: I'd start with fixing the download issues15:04
RPcfo215: can you wget files from the commandline?15:04
cfo215x86_64-linux-libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I/home/epic/poky/build/tmp/work/x86_64-linux/opensp-native/1.5.2-r1/OpenSP-1.5.2/lib -I.. -I/home/epic/poky/build/tmp/work/x86_64-linux/opensp-native/1.5.2-r1/OpenSP-1.5.2/include -I/home/epic/poky/build/tmp/work/x86_64-linux/opensp-native/1.5.2-r1/OpenSP-1.5.2/generic -isystem/home/epic/poky/build/tmp/sysroots/x86_64-linux/usr/include -isystem/home/epic/poky/build/tmp/sysroots/x86_64-linux/usr/includ15:05
cfo215e -O2 -pipe -c /home/epic/poky/build/tmp/work/x86_64-linux/opensp-native/1.5.2-r1/OpenSP-1.5.2/lib/ErrorCountEventHandler.cxx -o ErrorCountEventHandler.o >/dev/null 2>&115:05
cfo215../x86_64-linux-libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I/home/epic/poky/build/tmp/work/x86_64-linux/opensp-native/1.5.2-r1/OpenSP-1.5.2/lib -I.. -I/home/epic/poky/build/tmp/work/x86_64-linux/opensp-native/1.5.2-r1/OpenSP-1.5.2/include -I/home/epic/poky/build/tmp/work/x86_64-linux/opensp-native/1.5.2-r1/OpenSP-1.5.2/generic  -isystem/home/epic/poky/build/tmp/sysroots/x86_64-linux/usr/include  -isystem/home/epic/poky/build/tmp/sysroots/x815:05
cfo2156_64-linux/usr/include -O2 -pipe -c -o EventGenerator.lo /home/epic/poky/build/tmp/work/x86_64-linux/opensp-native/1.5.2-r1/OpenSP-1.5.2/lib/EventGenerator.cxx15:05
cfo215The bug is not reproducible, so it is likely a hardware or OS problem.15:05
cfo215make[3]: *** [EntityApp.lo] Error 115:05
RPcfo215: use pastebin for something that isn't a single line15:05
cfo215where would you like me to paste bin to?15:05
RPcfo215: building a linux OS from scratch does stress machines a bit so if you have broken hardware, this will likely expose it15:06
cfo215I've been strugling with yocto/poky for weeks now.15:06
*** zenlinux <zenlinux!> has joined #yocto15:06
bluelightningcfo215: pastebin.com15:06
cfo215my machine is i7 quad core with 12gb ram 1TB drive.15:06
cfo215bluelightning: thank you.15:07
*** B4gder <B4gder!> has quit IRC15:08
cfo215RP: I have no issues with wget:15:10
cfo215epic@epic-dev02:/tmp$ wget
cfo215--2013-08-12 11:09:32--
cfo215Resolving (
cfo215Connecting to (||:80... connected.15:10
cfo215HTTP request sent, awaiting response... 200 OK15:10
cfo215Length: 266202 (260K) [application/x-tar]15:10
cfo215Saving to: ‘mtdev-1.1.2.tar.bz2’15:10
cfo215100%[======================================>] 266,202      217KB/s   in 1.2s15:10
cfo2152013-08-12 11:09:34 (217 KB/s) - ‘mtdev-1.1.2.tar.bz2’ saved [266202/266202]15:10
cfo215RP: what OS do you use?15:10
kergothi'd try git cloning the linux-yocto-3.8 kernel that failed to fetch via bitbake, manually15:11
cfo215I thought the whole purpose of using poky was so I wouldn't have to do individual fetching and building of stuff.  I understand you're trying to help me.15:12
*** abelloni <abelloni!> has quit IRC15:12
kergothi'm saying you should clone so we know that cloning works15:12
kergothas a data point in trying to debug15:12
kergoththis is how debugging works, you eliminate possible sources of failure until one remains15:12
cfo215will do.  Clone into the poky directory or somewhere else?15:12
kergothdoesn't matter, the point is whether teh clone succeeds, not to put it somewhere bitbake will get it15:13
cfo215ok w115:13
*** abelloni <abelloni!> has joined #yocto15:15
*** mulhern <mulhern!> has quit IRC15:16
RPcfo215: As well as trying that, you could pastebin the output of one of your bitbake runs showing the error and warning messages you're seeing. We're trying to figure out what in your setup isn't working...15:16
RPcfo215: only seeing some of the messages makes things tricky for us as we don't have the complete picture15:17
cfo215will do. will the cooker log work or do you need something else?15:18
*** abelloni <abelloni!> has joined #yocto15:20
cfo215RP:kergoth: my gut tells me the order of downloads is out of wack somehow.  bitbake isn't waiting for things to finish before trying other things.  i.e. dependancies aren't there for the compiler to work properly.15:20
RPcfo215: a look at the cooker log would be a good start15:21
RPcfo215: the system is setup to do things in parallel so that may or may not be true15:22
cfo215kergoth:RP: git clone of linux-yocto-3.8 kernel running just fine right now.15:22
RPcfo215: I would have expected someone else to have seen it though15:22
cfo215I'll pastebin the latest log15:22
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-glrysxxjbkgaagbi> has quit IRC15:24
otaviopanda84kde: did you fix the build failure?15:24
*** mulhern <mulhern!> has joined #yocto15:26
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-krrsevvnwfehspar> has joined #yocto15:27
cfo215RP: "yocto-compile-issues-20130812-01" on pastebin that was my last try prior to the one that is currently running.15:30
cfo215RP: it also had compile failures.15:30
RPcfo215: do you have the pastebin url?15:31
cfo215kergoth: git clone worked without issue.  I use exact line shown in the log file.15:33
RPcfo215: so bintuils-native and gcc-cross-initial failed. If you try building them again with "bitbake binutils-native gcc-cross-initial" do they get any further?15:33
RPcfo215: also, why earlier did you wonder about hardware issues? You've seen something build that had previously failed?15:34
cfo215worrried that I'm outrunning bitbake with my hardware somehow.15:34
cfo215RP: trying that now...15:35
panda84kdeotavio: no :(15:36
cfo215RP: That didn't work either... "ERROR: Task 19 (/home/epic/poky/meta/recipes-devtools/gcc/, do_compile) failed with exit code '1'"15:36
bluelightningcfo215: that's extremely unlikely, the build system gets run regularly on such machines15:36
cfo215I'll pastebin the do_compile log15:37
cfo215bluelightinging: I wouldn't be here if I wasn't having trouble...  again. I know you're trying to help.15:37
kergothall he said was that your assumption about outrunning bitbake was extremely unlikely, not that you weren't having a problem15:39
bluelightningcfo215: of course... we'll do whatever we can to assist15:39
cfo215bluelightning: thank you.  I really,l really (no, I didn't stutter) do appreciate any help I can get.15:40
otaviopanda84kde: I will have lunch and then I check it with you. Ok? brb15:41
cfo215pastebin of ERRO: Task 19...
panda84kdeotavio: sure15:42
RPcfo215: ok, next can you try "bitbake gcc-cross-initial -c cleansstate; bitbake gcc-cross-initial"15:42
panda84kdegood lunch otavio15:42
bluelightningcfo215: silly question, but have you checked that your machine isn't having cooling issues?15:43
RPcfo215: if this rebuilds ok, it does sound like the error mentioned there might be a clue "The bug is not reproducible, so it is likely a hardware or OS problem." :/15:44
cfo215bluelightning: no, haven't checked that and wouldn't know where to begin to find out.15:44
cfo215RP: What OS do you use?15:44
RPcfo215: you could try two things, one would be to run memtest on it, check there isn't bad memory, you could also try turning down the parallism (PARALLEL_MAKE and BB_NUMBER_THREADS)15:45
RPcfo215: Ubuntu of various versions15:45
RPcfo215: I know of several people using it regularly which is why I don't think its the problem15:45
*** darknighte_znc is now known as darknighte15:45
cfo215I can try that.  my setting are "8" as per documents'....  quad core x 2.15:46
RPcfo215: equally I know of people using this on 24 core systems so I don't think this is a parallelism issue15:46
RPcfo215: I do suspect your hardware unfortunately :(15:46
cfo215That wouldn't surprise me none.  It was a hand me down from the IT department...  I'm a contractor....15:47
cfo215RP: "The bug is not reproducible, so it is likely a hardware or OS problem.15:48
cfo215| make[1]: *** [insn-recog.o] Error 115:48
cfo215| rm gcc.pod"15:48
*** slaine <slaine!~slaine@> has quit IRC15:48
cfo215RP: I'm going shopping.... time to get a new computer....15:48
RPcfo215: it failed in a different file? That has all the signs of hardware issues :/15:49
cfo215RP: Any recommendations?  I've not purchased a computer in years...15:49
RPcfo215: the spec you mentioned (i7 with 12GB ram and 1TB disk) sounded like the right ballpark15:49
cfo215I'll look for something in that neighborhood.  Thanks for all your help.  I'm going now to give back this POS computer.15:50
cfo215I'll come back later and let you know how it went with the new compter.15:51
rburtongood luck :)15:51
*** cfo215 <cfo215!> has left #yocto15:51
*** eren <eren!~eren@unaffiliated/eren> has quit IRC15:58
*** davest <davest!~Adium@> has quit IRC15:58
*** davest <davest!Adium@nat/intel/x-qwoewaemwcpabejt> has joined #yocto15:59
*** zenlinux <zenlinux!> has quit IRC16:00
*** nitink <nitink!~nitink@> has joined #yocto16:02
*** hico <hico!50966342@gateway/web/freenode/ip.> has quit IRC16:04
*** zecke <zecke!> has quit IRC16:05
*** klinger_ <klinger_!> has joined #yocto16:05
*** _Lucretia__ <_Lucretia__!~munkee@> has joined #yocto16:07
*** _Lucretia_ <_Lucretia_!~munkee@pdpc/supporter/active/lucretia> has quit IRC16:10
*** zenlinux <zenlinux!> has joined #yocto16:10
*** Krz_ <Krz_!c0c6972c@gateway/web/freenode/ip.> has quit IRC16:12
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC16:14
*** zeeblex <zeeblex!apalalax@nat/intel/x-dyzdhscuxblwqdjz> has left #yocto16:20
*** pidge <pidge!pidge@nat/intel/x-zgbeylcvueoipyqr> has joined #yocto16:23
*** mulhern <mulhern!> has quit IRC16:29
*** mulhern <mulhern!> has joined #yocto16:30
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:33
*** elmi82 <elmi82!> has quit IRC16:45
*** seebs <seebs!> has quit IRC16:46
*** Jefro <Jefro!> has joined #yocto16:47
*** belen <belen!~Adium@> has quit IRC16:47
*** zenlinux <zenlinux!> has quit IRC16:49
*** zecke <zecke!> has joined #yocto16:49
*** mihai <mihai!~mihai@> has quit IRC16:51
*** seebs <seebs!> has joined #yocto16:51
otaviopanda84kde:  I am around :)16:59
*** belen <belen!Adium@nat/intel/x-zilqhrnzjmbwojwh> has joined #yocto16:59
Crofton|workzedd_, I'm thinking line 10 is a bad idea here:
*** zedd_ is now known as zeddii17:03
zeddiiCrofton|work, saw your email this morning. is it causing you direct pain ?17:03
mr_scienceas opposed to indirect?17:06
* mr_science is in an extra-sarcastic mood today17:06
mr_scienceso i'll try to abstain...17:06
panda84kdehi. Try bitbaking mesa-demos and see if it builds for you17:06
panda84kde* hi otavio17:07
Crofton|workwell, I had to rename a scc file to get my bbappend to build17:08
Crofton|workthen I got wondering how mulitple bbappends across several bsps's will work17:08
Crofton|workit seems like the bbappends to linux-yocto will stack across all bsps?17:11
zeddiican you forward me the error/issue you saw, I can suggest a tweak if I have a better picture.17:11
Crofton|workbasically it looked for the file my-machine-standard.scc17:12
Crofton|workwhich did not exist17:12
zeddiiyup. and found that one ?17:13
Crofton|workwell, it found it after I renamed one of my .scc files17:14
zeddiiheh. let me try and get it straight in my head. it didn't find my-machine-standard.scc, but found another one of your .scc files that you didn't want it to find, and when you renamed that one, it found the xilinx one ?17:15
Crofton|workI add my layer that bbappends to linux-yocto and has a new machine name17:16
Crofton|workso it fails, because I do not have a file new-machine-standard.scc17:16
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC17:17
zeddiiright. it either fails or tries to generate you one.17:17
Crofton|workit tries to make one?17:17
Crofton|workbut this is anme from a xilinx bbappend?17:18
zeddiiwhat failure did you get ? I can diagnose why it failed if there was a message. or did you just get something built you didn't want ?17:18
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto17:18
*** zecke <zecke!> has quit IRC17:18
*** belen <belen!Adium@nat/intel/x-zilqhrnzjmbwojwh> has quit IRC17:18
*** davest <davest!Adium@nat/intel/x-qwoewaemwcpabejt> has quit IRC17:19
zeddiiright, the bbappend shouldn't demand that. now I understand. it should be something that you can override in your layers.17:19
*** gonzzor <gonzzor!> has quit IRC17:19
Crofton|workand I assume mulitple bbppends will stack?17:21
kergothCrofton|work: bsp layers should always use the machine overrides for both their variables and their files in filespath17:21
kergothso they don't break others, and so they have no impact when their machine isnt' used17:21
kergothth eonly exception is general bugfixes, but they don't belong in bsp layer anyway17:21
kergothimo the same is true of distro layers too, anything specific to taht distro should be using the distro override, again the only exception being general bugfixes17:22
bluelightningit would be nice to have a script that we could run against a layer to check if it's following that17:22
kergothHmm, yeah, that's a good idea17:22
bluelightningwith the variable history stuff it probably wouldn't be too hard17:22
*** panda84kde <panda84kde!> has quit IRC17:23
kergothcould just dump global and per-recipe metadata before and after inclusion of the layer, without changing hte config, and list what changes occurred solely due to layer inclusion17:23
* kergoth shrugs17:23
*** ftonello <ftonello!> has joined #yocto17:25
*** bluelightning_ <bluelightning_!~paul@> has joined #yocto17:28
*** bluelightning_ <bluelightning_!~paul@> has quit IRC17:28
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto17:28
*** davest <davest!~Adium@> has joined #yocto17:29
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:29
*** bluelightning_ is now known as bluelightning17:29
Crofton|workgah, I need these patches in the xilnx bbappend to apply for all zynq machines17:29
*** zenlinux <zenlinux!~sgarman@> has joined #yocto17:34
*** simar <simar!~simar@> has joined #yocto17:36
kergothCrofton|work: time to either add/use an override for that class of machines / soc, or define it using all the machien overrides :)17:42
Crofton|workthe headache is I add my new amchine in another bbappend, btu I still need the zynq specific patches17:43
Crofton|workI may go use their -dev recipe instead of linux-yocto17:44
Crofton|workthere still appear to be ascaling issues17:44
kergothpresumably you could just include both zyng and your machien in MACHINEOVERRIDES, fi both always apply17:44
kergoththats what i do for th emel distro, we apply both poky and mel overrides via DISTROOVERRIDES, since we're poky based17:45
kergoth/e/me shrugs17:45
mr_sciencehave a napkin...17:46
*** mulhern <mulhern!> has quit IRC17:50
*** e8johan <e8johan!> has joined #yocto17:52
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto17:55
simarCrofton|work: I'm currently trying to do something similar and need the linux-yocto-dev reciepe for the beagleboard. Where do I enable this?17:55
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto17:55
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:56
simarI thought it would be meta-yocto-bsp/conf/machine/beagleboard.conf but that didn't help.17:56
*** bluelightning_ is now known as bluelightning17:56
*** e8johan <e8johan!> has quit IRC18:03
*** davest <davest!~Adium@> has quit IRC18:05
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto18:05
*** Jefro <Jefro!> has quit IRC18:06
*** Jefro <Jefro!> has joined #yocto18:10
*** munch <munch!> has quit IRC18:10
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC18:10
*** davest <davest!~Adium@> has joined #yocto18:11
ftonellocan anyone tell me if its a bug or what18:11
ftonellolet say I have two versions of libfoo: and libfoo_git.bb18:12
ftonellosome other recipes RDEPENDS on it18:12
ftonelloI built first and then libfoo_git.bb18:13
ftonellothats fine18:13
*** phdeswer_ <phdeswer_!> has joined #yocto18:13
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto18:13
ftonellobut when I build any package that RDEPENDS on this libfoo, altough my recipe says that "please, give priority to libfoo_git", the package adds a dependency version on libfoo >= 1.018:14
ftonellobut if I do a bitbake -s, it shows the git version18:14
ftonelloactually everything looks correct, just this run time dependency for other packages is not correct18:15
*** Jefro <Jefro!> has quit IRC18:21
*** scot_ <scot_!> has quit IRC18:23
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC18:26
*** mihai <mihai!~mihai@> has joined #yocto18:27
*** Jefro <Jefro!> has joined #yocto18:29
*** JimBaxter <JimBaxter!> has quit IRC18:30
*** mulhern <mulhern!> has joined #yocto18:36
mr_scienceftonello: shouldn't it prefer git recipes over versioned ones?18:54
RPftonello: we don't support two different versions like that18:55
RPftonello: see clutter for how to namespace different ABIs18:55
*** swex_ <swex_!~swex@> has joined #yocto18:55
RP(as an example)18:55
mr_scienceis it really an ABI difference?  or just an "i need the latest in git instead of 1.0" thing?18:57
mr_sciencethe only thing i can think of is have libfoo_git RPROVIDE some (different) name to DEPEND on18:58
*** swex <swex!~swex@> has quit IRC18:59
*** mulhern <mulhern!> has quit IRC18:59
mr_sciencemight not be "proper" though...18:59
*** scot <scot!> has joined #yocto18:59
*** davest <davest!~Adium@> has quit IRC18:59
*** davest <davest!Adium@nat/intel/x-vstwbdbgjryivucb> has joined #yocto19:00
*** Garibaldi|work1 <Garibaldi|work1!~andydalt@nat/cisco/x-osugbugjnfifiode> has joined #yocto19:00
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-krrsevvnwfehspar> has quit IRC19:00
RPthe two things have the same provides namespace so only one can be built. If you need to build both, you need different PN namespaces19:01
ftonelloRP, mr_science: Yes. The think is that I have a env variable that selects that for me. I change the priority based on that19:02
ftonelloso what I did, I told bitbake to select the git recipe for the build19:02
ftonellobut when it generates the package information, is selecting the other version of the package19:02
RPthe other package information should have been cleaned out when the other recipe was built :/19:03
ftonelloRP: yes.. where this information is stored? Because I coudn't find it..19:03
ftonelloit seems to be a bug19:03
mr_scienceftonello: you already changed the priorities, right?19:03
ftonellomr_science: yes..19:03
ftonelloI do this:19:04
ftonelloDEFAULT_PREFERENCE = "${@use_git_or_not()}"19:04
ftonelloand this function checks for that variable and return -1 or 1,19:04
ftonelloit works well.. just this is not working19:04
*** Garibaldi|work1 <Garibaldi|work1!~andydalt@nat/cisco/x-osugbugjnfifiode> has quit IRC19:08
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-rbgddovrqsbejflx> has joined #yocto19:08
ftonelloI oppened a bug19:13
ftonellolet see19:13
rburtonand the winner of #5000 is belen!19:17
*** amarsman <amarsman!> has quit IRC19:32
*** sroy_ <sroy_!~sroy@2607:fad8:4:6:3e97:eff:feb5:1e2b> has quit IRC19:37
*** mulhern <mulhern!> has joined #yocto19:40
*** joeythesaint <joeythesaint!~jjm@> has quit IRC19:45
*** davest <davest!Adium@nat/intel/x-vstwbdbgjryivucb> has quit IRC19:53
*** Jefro <Jefro!> has quit IRC19:54
-YoctoAutoBuilder- build #225 of nightly-oecore is complete: Success [build successful] Build details are at
Crofton|workkergoth, is this a job for SOC_FAMILY?20:06
Crofton|workyou see the problem, there are files in a linux-yocto.bbppend that apply for all machines in a class20:11
Crofton|workand some that apply for specific machines20:12
RPCrofton|work: SOC_FAMILY is MACHINEOVERRIDES behind the scenes20:12
Crofton|work and is there a good example anywhere20:12
Crofton|workyeah, but the wording makes sense :)20:12
* Crofton|work is looking at :)20:13
*** davest <davest!Adium@nat/intel/x-olchujswrmbfrohi> has joined #yocto20:17
*** Jefro <Jefro!> has joined #yocto20:17
*** davest <davest!Adium@nat/intel/x-olchujswrmbfrohi> has quit IRC20:24
-YoctoAutoBuilder- build #248 of nightly-mips is complete: Success [build successful] Build details are at
*** mulhern <mulhern!> has quit IRC20:47
*** mulhern <mulhern!> has joined #yocto20:48
*** agust <agust!> has quit IRC20:52
*** agust <agust!> has joined #yocto20:52
-YoctoAutoBuilder- build #250 of nightly-x86 is complete: Success [build successful] Build details are at
*** davest <davest!Adium@nat/intel/x-pggiglqtvpduizka> has joined #yocto20:54
*** davest <davest!Adium@nat/intel/x-pggiglqtvpduizka> has quit IRC21:02
seebsRP, when you have a minute, I would be interested in feedback on the patch I sent recentlyish (July 26) for NO32LIBS. Basically, it makes the attempt to build a 32-bit pseudo more definite if NO32LIBS gets set to 0, on the grounds that if you are explicitly setting that, and it won't work, you probably want a failure message rather than a corrupted build.21:02
*** davest <davest!~Adium@> has joined #yocto21:03
*** bluelightning <bluelightning!> has joined #yocto21:06
*** bluelightning <bluelightning!> has quit IRC21:06
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto21:06
*** behanw <behanw!> has quit IRC21:22
JaMaseebs: even with NO32LIBS I can still see file attributes (permissions, owners) randomly changing when comparing builds on different hosts with buildhistory, do you have another idea what could be the cause?21:24
seebsThe most obvious thing is: Right now, NO32LIBS="0" doesn't actually cause 32-bit pseudo to get built.21:24
fray32-bit/64-bit split(s), and static binaries are the only cases where I know it can happen..21:24
JaMaseebs: still in the distro with 32bit external toolchain on 64bit builders21:24
frayunless of course something gets added/removed/modified outside of pseudo control21:25
seebsIt causes 32-bit pseudo to consider getting built if the host system has enough stuff that the build system is pretty sure it can do it, otherwise nothing happens and it's silent.21:25
seebsWhich is why I sent a patch to try to force it to do the rebuild in that case.21:25
JaMaok I'll backport that patch to dylan and test it in our scenario21:25
seebsYou should be able to check pretty easily.21:26
seebsCheck your sysroot's pseudo/lib* directories, see how many you have.21:26
seebsIf you only have a lib64/, then it's not building the 32-bit one.21:26
JaMaI've checked 2 builders and both have both 32+64 libpseudo built21:29
*** zenlinux <zenlinux!~sgarman@> has quit IRC21:30
*** zenlinux <zenlinux!> has joined #yocto21:30
*** _Lucretia__ <_Lucretia__!~munkee@> has quit IRC21:37
*** mulhern <mulhern!> has quit IRC21:44
*** _Lucretia__ <_Lucretia__!~munkee@> has joined #yocto21:45
seebsHuh, that's odd, then.21:52
seebsGot any failures to load in there? Anything interesting in the pseudo.log files?21:52
*** _Lucretia__ <_Lucretia__!~munkee@> has quit IRC21:52
*** _Lucretia__ <_Lucretia__!~munkee@> has joined #yocto21:57
*** challinan <challinan!> has quit IRC22:01
*** challinan <challinan!> has joined #yocto22:02
*** zenlinux <zenlinux!> has quit IRC22:02
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has joined #yocto22:03
*** reaperofsouls <reaperofsouls!> has quit IRC22:03
*** evanp <evanp!~evan@> has quit IRC22:04
*** evanp <evanp!evan@nat/intel/x-kntexqeuvwayhrgw> has joined #yocto22:05
*** mihai <mihai!~mihai@> has quit IRC22:05
*** Crofton|work <Crofton|work!> has quit IRC22:05
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has quit IRC22:05
*** nslu2-log <nslu2-log!~nslu2-log@> has quit IRC22:06
*** Crofton|work <Crofton|work!> has joined #yocto22:06
*** nslu2-log <nslu2-log!~nslu2-log@> has joined #yocto22:07
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto22:08
*** mihai <mihai!~mihai@> has joined #yocto22:08
*** davest <davest!~Adium@> has quit IRC22:13
*** agust <agust!> has quit IRC22:17
JaMaseebs: unfortunately I don't have simple reproducer I only know about it from buildhistory diffs and sometimes when it hits some file in image where it has fatal behavior for runtime22:18
JaMaseebs: but I haven't seen anything interested in pseudo.log or preload failures22:18
seebsYeah. We had that for a while, but NO32LIBS fixed it for us, and we haven't seen it since, that we know of.22:18
seebsIt's possible that there's also packages which are tripping pseudo some other way.22:19
seebsHmm. Any NFS involved? We know there are problems with NFS.22:19
JaMasstate mirror and premirror are over NFS22:19
JaMatomorrow I'll try to repeat clean builds few times on the same host to see if the problem can be reproduced also on the same host machine22:21
*** davest <davest!Adium@nat/intel/x-yztkzaahuirciyya> has joined #yocto22:21
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-rbgddovrqsbejflx> has quit IRC22:22
*** pidge <pidge!pidge@nat/intel/x-zgbeylcvueoipyqr> has quit IRC22:25
*** mulhern <mulhern!> has joined #yocto22:25
seebsI don't think the sstate mirror should matter. The usual failure mode is just that if you remount NFS file systems you don't always get the same device number. Also, pseudo's locking can and will fail if the pseudo directory is NFS-mounted. (Yes, there's a locking syscall that works over NFS, but the locks aren't inherited by child processes.)22:26
*** eren <eren!~eren@unaffiliated/eren> has quit IRC22:31
*** mulhern <mulhern!> has quit IRC22:41
*** mulhern <mulhern!> has joined #yocto22:42
*** behanw <behanw!> has joined #yocto22:44
*** b1gtuna <b1gtuna!~adam@> has quit IRC23:01
*** adam___ <adam___!~adam@> has joined #yocto23:02
*** adam___ is now known as b1gtuna23:02
*** andyross <andyross!> has quit IRC23:02
b1gtunahappy monday everyone! My image is built with GDM, but I don't get the universal access icon any longer (it was there some months ago..). I just need a virtual keyboard to login on a touch screen device23:03
b1gtunamy GDM recipe indicates i'm using 2.32.223:03
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:09
*** mulhern <mulhern!> has quit IRC23:18
*** zenlinux <zenlinux!> has joined #yocto23:19
*** davest <davest!Adium@nat/intel/x-yztkzaahuirciyya> has quit IRC23:26
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC23:33
*** Crofton <Crofton!> has quit IRC23:34
*** Crofton|work <Crofton|work!> has quit IRC23:34
*** andyross <andyross!> has joined #yocto23:35
*** mulhern <mulhern!> has joined #yocto23:37
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto23:40
*** Crofton|work <Crofton|work!> has joined #yocto23:46
*** trollixx <trollixx!> has quit IRC23:46
*** trollixx <trollixx!> has joined #yocto23:47
*** Crofton <Crofton!> has joined #yocto23:47
*** wmat <wmat!> has joined #yocto23:54

Generated by 2.11.0 by Marius Gedminas - find it at!