Thursday, 2013-09-05

*** _julian_ <_julian_!> has joined #yocto00:08
*** _julian <_julian!> has quit IRC00:12
*** walters <walters!> has joined #yocto00:12
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC00:12
*** Anusko <Anusko!~anusko@> has quit IRC00:32
*** denix <denix!> has quit IRC00:37
*** mulhern <mulhern!> has joined #yocto00:42
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC00:46
*** oscailt <oscailt!~oscailt@unaffiliated/oscailt> has quit IRC00:49
*** scot_ <scot_!~scot@> has quit IRC00:49
*** mulhern <mulhern!> has quit IRC01:03
*** denix <denix!> has joined #yocto01:18
*** mulhern <mulhern!> has joined #yocto01:22
*** [simar|school] <[simar|school]!> has joined #yocto01:28
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto01:33
-YoctoAutoBuilder- build #249 of nightly-fsl-ppc-lsb is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #283 of build-appliance is complete: Success [build successful] Build details are at
*** silviof1 <silviof1!~silviof@unaffiliated/silviof> has joined #yocto02:02
*** Jefro <Jefro!> has quit IRC02:03
*** silviof <silviof!~silviof@unaffiliated/silviof> has quit IRC02:04
*** mulhern <mulhern!> has quit IRC02:04
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC02:11
*** behanw <behanw!> has quit IRC02:13
*** mulhern <mulhern!> has joined #yocto02:15
*** joeythesaint <joeythesaint!> has quit IRC02:27
*** nrossi <nrossi!~nrossi@> has quit IRC02:31
*** nrossi <nrossi!~nrossi@> has joined #yocto02:36
-YoctoAutoBuilder- build #94 of buildtools is complete: Success [build successful] Build details are at
*** Squix <Squix!> has joined #yocto02:40
*** zenlinux <zenlinux!> has quit IRC02:42
*** davest <davest!~Adium@> has joined #yocto03:03
*** phdeswer_ <phdeswer_!> has quit IRC03:05
-YoctoAutoBuilder- build #293 of nightly-mips-lsb is complete: Success [build successful] Build details are at
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC03:06
*** andyross <andyross!> has joined #yocto03:07
*** nerdboy <nerdboy!> has joined #yocto03:07
*** davest <davest!~Adium@> has quit IRC03:18
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto03:19
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC03:20
*** nerdboy <nerdboy!> has quit IRC03:29
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto03:29
*** oscailt <oscailt!~oscailt@unaffiliated/oscailt> has joined #yocto03:31
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto03:31
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC03:47
*** jmdelos_ <jmdelos_!> has joined #yocto03:55
*** Jefro <Jefro!> has joined #yocto03:56
*** jmpdelos <jmpdelos!> has quit IRC03:56
*** andyross <andyross!> has quit IRC03:58
-YoctoAutoBuilder- build #277 of nightly-x86-64 is complete: Success [build successful] Build details are at
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto04:00
*** Jefro <Jefro!> has quit IRC04:07
*** thesignal <thesignal!~deadbot@> has quit IRC04:10
*** thesignal <thesignal!~deadbot@> has joined #yocto04:11
-YoctoAutoBuilder- build #159 of nightly-qa-systemd is complete: Success [build successful] Build details are at
*** thesignal <thesignal!~deadbot@> has quit IRC04:24
*** thesignal <thesignal!~deadbot@> has joined #yocto04:25
*** Jefro <Jefro!> has joined #yocto04:44
*** Jefro <Jefro!> has quit IRC04:45
*** andyross <andyross!> has joined #yocto04:52
*** _alex_kag_ <_alex_kag_!~alex_kag@> has joined #yocto04:55
*** boz_v1 <boz_v1!> has joined #yocto05:02
*** walters <walters!> has quit IRC05:08
*** walters <walters!> has joined #yocto05:15
*** andyross <andyross!> has quit IRC05:19
*** kbart <kbart!~KBart@> has joined #yocto05:26
*** [simar|school] <[simar|school]!> has quit IRC05:27
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC05:34
-YoctoAutoBuilder- build #285 of poky-tiny is complete: Success [build successful] Build details are at
*** zecke <zecke!> has joined #yocto05:38
*** amarsman <amarsman!> has joined #yocto05:39
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto05:50
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC05:50
*** tor <tor!> has joined #yocto05:53
*** mbelisko <mbelisko!> has joined #yocto06:02
*** mihai <mihai!~mihai@> has joined #yocto06:13
*** zeeblex <zeeblex!apalalax@nat/intel/x-msnsgyjczioprznj> has joined #yocto06:19
-YoctoAutoBuilder- build #122 of minnow-lsb is complete: Success [build successful] Build details are at
*** jkridner <jkridner!> has joined #yocto06:22
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto06:22
*** msm <msm!> has quit IRC06:30
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC06:31
-YoctoAutoBuilder- build #258 of nightly-oecore is complete: Success [build successful] Build details are at
*** uvan <uvan!~uvan@> has joined #yocto06:38
-YoctoAutoBuilder- build #282 of nightly-non-gpl3 is complete: Success [build successful] Build details are at
*** silviof1 is now known as silviof06:47
*** mckoan|away is now known as mckoan06:49
mckoangood morning06:49
*** seebs <seebs!> has quit IRC06:50
*** seebs <seebs!> has joined #yocto06:50
*** amarsman <amarsman!> has quit IRC06:51
*** mike <mike!c2881242@gateway/web/freenode/ip.> has joined #yocto06:53
*** mike is now known as Guest8665006:53
Guest86650Hi I created a native recipe and copied stuff to the $datadir06:54
Guest86650How can I access that data from other recipes06:54
Guest86650If I copy to bin dir then I can just use the command directly06:54
Guest86650but from $datadir I am not sure. Anybody know??06:55
*** B4gder <B4gder!> has joined #yocto06:56
*** eballetbo <eballetbo!> has joined #yocto06:56
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto06:57
Guest86650[09:54] <Guest86650> Hi I created a native recipe and copied stuff to the $datadir [09:54] <Guest86650> How can I access that data from other recipes [09:54] <Guest86650> If I copy to bin dir then I can just use the command directly [09:55] <Guest86650> but from $datadir I am not sure. Anybody know??06:58
Guest86650Any help much appreciated06:58
*** blitz00 <blitz00!stefans@nat/intel/x-pexpeomkpvlmqply> has joined #yocto06:59
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto06:59
*** e8johan_ <e8johan_!> has joined #yocto07:02
*** e8johan <e8johan!> has quit IRC07:03
*** Guest86650 <Guest86650!c2881242@gateway/web/freenode/ip.> has quit IRC07:07
*** n01 <n01!> has joined #yocto07:08
-YoctoAutoBuilder- build #279 of nightly-x86-64-lsb is complete: Success [build successful] Build details are at
*** e8johan <e8johan!> has joined #yocto07:15
*** slaine <slaine!~slaine@> has joined #yocto07:15
*** e8johan_ <e8johan_!> has quit IRC07:16
*** florian_kc <florian_kc!> has joined #yocto07:19
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:19
*** florian_kc is now known as florian07:19
*** ant_work <ant_work!> has joined #yocto07:20
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto07:38
lpapphi, is the meta-networking maintainer, Joe using irc?07:38
*** zecke <zecke!> has quit IRC07:45
lpappwhat is this error again?
ndeci suppose that if you ask, you already check that the file exists, right?07:50
ndecNo such file or directory: '/home/lpapp/Projects/poky/meta-yocto-bsp/conf/layer.conf'07:50
*** mitz <mitz!> has quit IRC07:51
lpappit is a fresh denzil branch checkout.07:51
lpappI do not understand why it would complain about non-existent files with a fresh and default state.07:51
*** mitz <mitz!> has joined #yocto07:52
nrossithere is no meta-yocto-bsp in denzil?
ndeclpapp: you might be using conf/bblayer.conf fom dylan then.07:54
lpappndec: that might be true, yes.07:54
lpappit is better to delete that file, and add stuff manually again.07:55
lpappndec: ERROR: Layer dependency core of layer networking-layer not found07:58
nrossilpapp: make sure that meta-oe is on denzil branch also07:58
*** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has joined #yocto07:58
lpappnrossi: ??07:58
lpappI think it is because meta did not have the core name in denzil.07:58
lpappbut then how can I depend on a layer with denzil?07:59
*** elmi82 <elmi82!> has joined #yocto08:01
lpappI guess I simply cannot.08:02
-YoctoAutoBuilder- build #280 of nightly-ppc is complete: Success [build successful] Build details are at
nrossilpapp: are you using any other additional layers apart from meta-sourcery and the layers in poky?08:04
lpappnrossi: denzil does not need meta-sourcery08:05
lpappnrossi: yes, I am using additional layers.08:05
*** Stygia <Stygia!> has joined #yocto08:05
lpappJaMa: why is it called qt5-layer rather than qt5? core is also called "core" rather than "core-layer". The "layer" is somewhat duplication as it is implicit in the context.08:07
JaMalpapp: consistency with meta-oe layers08:08
lpappthat is unfortunate.08:08
tfnrossi: no, it's all in meta-yocto08:09
*** roric <roric!> has quit IRC08:11
lpappdo I understand correctly that SDK is good for people who would like to develop applications on your platforms built by Yocto?08:11
lpappi.e. if we do the whole stack ourselves, it is not much of use?08:12
*** bluelightning <bluelightning!~paul@> has joined #yocto08:12
*** bluelightning <bluelightning!~paul@> has quit IRC08:12
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:12
bluelightningmorning all08:15
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC08:16
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC08:24
ndeclpapp: i think you are right.08:25
ndecabout SDK, i mean.08:26
*** rodgort <rodgort!> has quit IRC08:26
*** zecke <zecke!> has joined #yocto08:27
*** sameo <sameo!samuel@nat/intel/x-hhlumnofczjfiuyv> has joined #yocto08:28
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto08:28
*** rodgort <rodgort!> has joined #yocto08:29
*** belen <belen!~Adium@> has joined #yocto08:30
*** honschu <honschu!> has joined #yocto08:32
*** honschu <honschu!~honschu@shackspace/j4fun> has joined #yocto08:32
*** drasko <drasko!> has quit IRC08:32
lpappbluelightning: good morning08:33
*** honschu_ <honschu_!~honschu@shackspace/j4fun> has quit IRC08:35
*** Noor <Noor!~noor@> has quit IRC08:40
*** Noor <Noor!~noor@> has joined #yocto08:46
*** jkridner <jkridner!> has joined #yocto08:50
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto08:50
*** volker <volker!> has joined #yocto08:52
-YoctoAutoBuilder- build #278 of nightly-arm is complete: Success [build successful] Build details are at
*** roric <roric!> has joined #yocto08:55
lpappndec: right.08:56
elbc_rburton:  hi ! my build have succeeded, however I still have /yocto/poky/thinkpad/tmp/sysroots/chiefriver/usr/lib/ etc ... does this mean it hasn't succeeded or is it normal ?09:00
*** swex_ <swex_!~swex@> has joined #yocto09:02
rburtonelbc_: if you didn't wipe your sysroot they won't have been deleted, so you should check the image09:02
elbc_ok thanks !09:03
*** swex <swex!~swex@> has quit IRC09:03
rburtonelbc_: the wipe-sysroot will cleanly delete just the sysroot so you can re-build quickly to verify09:03
elbc_rburton: how do I do use this exactly ? sorry for my lack of knowledge09:05
rburtonjust run wipe-sysroot09:05
elbc_ok thanks !09:05
rburtonsorry, forgot to say "the wipe-sysroot script"09:06 ?09:06
rburtonif its not on your path then you haven't sourced oe-init-build-env09:06
rburtonwhich you need to do so it knows what to delete09:07
rburton(as it runs bitbake)09:07
elbc_ok I've found, running it and after bitbake core-image-opencpn again ?09:08
*** uvan <uvan!~uvan@> has quit IRC09:13
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC09:14
elbc_rburton:  I still have the libx11 in several directories, but maybe it's not efficient, I don't know09:16
*** JimBaxter <JimBaxter!> has joined #yocto09:19
*** mike <mike!c2881242@gateway/web/freenode/ip.> has joined #yocto09:24
*** mike is now known as Guest4924509:24
Guest49245Hi how can I access data from datadir ?09:25
Guest49245I copy stuff to datadir in native recipe and what to access that data from other recipe09:26
elbc_rburton:  I think my problem is solved, thank you very much for your time !09:26
bluelightningGuest49245 / mike: if recipe a-native installs files to ${D}${datadir} in do_install and recipe b has "a-native" in DEPENDS, then the files should be available in ${STAGING_DATADIR_NATIVE} when b's do_configure (and later tasks) executes09:31
rburtonelbc_: no problem09:32
Guest49245ok thanks bluelightning. I try that09:35
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC09:35
StygiaHah.... found this article guys:
StygiaI'll be nice.09:41
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto09:46
*** hyang2 <hyang2!~hyang2@> has quit IRC09:49
*** roric <roric!> has quit IRC09:58
-YoctoAutoBuilder- build #283 of nightly-x86 is complete: Success [build successful] Build details are at
*** Stygia <Stygia!> has quit IRC10:00
*** jkridner <jkridner!> has joined #yocto10:01
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto10:01
*** Stygia <Stygia!> has joined #yocto10:03
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC10:06
*** roric <roric!> has joined #yocto10:11
*** smartin__ <smartin__!> has quit IRC10:34
*** smartin <smartin!> has joined #yocto10:40
Guest49245bluelightning : how can I access that variable if I call a shell script from the recipe without passing the variable to the shell script?10:40
*** bluelightning_ <bluelightning_!~paul@> has joined #yocto10:44
*** bluelightning_ <bluelightning_!~paul@> has quit IRC10:44
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:44
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:44
*** bluelightning_ is now known as bluelightning10:44
bluelightningGuest49245: you need to either pass the variable directly to the script on its command line, or export a variable containing the value (or export the variable itself, whichever is more appropriate)10:44
bluelightningGuest49245: some variables are exported by default, but STAGING_DATADIR_NATIVE is not one of them AFAIK10:45
*** BCMM_ <BCMM_!~BCMM@unaffiliated/bcmm> has joined #yocto10:49
*** behanw <behanw!~behanw@> has joined #yocto10:49
Guest49245bluelightning : what is the syntax to export variable10:50
bluelightningGuest49245: export VARIABLENAME10:50
bluelightningif you do that outside of a shell function it'll export the bitbake variable of that name10:51
bluelightningwithin a shell function you'd probably need to do export VARIABLENAME=${VARIABLENAME}10:51
bluelightningit's worth noting that outside of a shell function export will export the variable for all tasks associated with the recipe, not just a single one10:52
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC10:57
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC10:57
*** roric <roric!> has quit IRC11:09
*** roric <roric!> has joined #yocto11:23
*** jkridner <jkridner!> has joined #yocto11:23
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto11:23
*** padge_ <padge_!> has joined #yocto11:29
*** walters <walters!> has quit IRC11:31
*** panda84kde <panda84kde!> has joined #yocto11:32
*** mulhern <mulhern!> has joined #yocto11:33
*** silviof <silviof!~silviof@unaffiliated/silviof> has left #yocto11:41
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC11:47
*** cfo215 <cfo215!> has joined #yocto11:50
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto11:51
*** joeythesaint <joeythesaint!~jjm@> has joined #yocto11:52
Guest49245bluelightning : how to do addtask for a shell function12:09
Guest49245is syntax similar. At least its not running the function12:09
Guest49245I changed the function from python to shell12:09
bluelightningGuest49245: if it's not an already added task function it won't run automatically no...12:10
bluelightningaddtask yourfunction after do_someothertask12:10
bluelightningbut the question is do you really need another task for what you're doing?12:10
*** ant_work <ant_work!> has quit IRC12:10
Guest49245ok so syntax is same whether function is python or shell12:10
Guest49245its a long story12:11
Guest49245but this is way I attempt for now12:11
Guest49245it doesnt run the new task anymore for some reason12:14
-YoctoAutoBuilder- build #285 of nightly-x86-lsb is complete: Success [build successful] Build details are at
Guest49245ok it is running but doesnt print the bbwarn messages like in pyhon12:17
RPGuest49245: the shell logging only goes to the logfiles unfortunately12:18
elbc_rburton:  if you're available I might need your help12:22
elbc_ERROR: Nothing PROVIDES 'virtual/libx11' (but /home/elebideau/yocto/poky/meta/recipes-support/consolekit/ DEPENDS on or otherwise requires it)12:23
elbc_I've succeeded to build pulseaudio without any dependencies to libx11 at all, but doing a cleanall on my image before building displays me this error12:24
elbc_need to remove completeley this virtual/libx11 thing (still want to using wayland and just wayland)12:25
*** scot_ <scot_!~scot@> has joined #yocto12:28
StygiaDoes anyone here know about wget and SSL? The ca-certificates recipe contains a number of certificates, but it seems that since Amazon started using a new cert with a larger keysize I can't wget from https:// amazon urs, getting "self-signed certificate encountered"12:35
StygiaBut what bugs me is that all the ca-certs that have anything to do with DigiCert (The cert it complains about) have identical checksums to on my debian box, where things do work.12:35
StygiaThe only difference is that I have a certificate missing on the box, which I have on my own system. This seems to be the "right" certificate - But is only part of libpurple, and what's worse, moving it out of its proper location doesn't cause the failture.12:36
StygiaAny hints?12:36
*** panda84kde <panda84kde!> has quit IRC12:38
*** cfo215 <cfo215!> has quit IRC12:39
*** nrossi <nrossi!~nrossi@> has quit IRC12:42
*** dany <dany!> has quit IRC12:42
*** jmdelos_ <jmdelos_!> has quit IRC12:43
*** munch <munch!> has joined #yocto12:44
*** nrossi <nrossi!~nrossi@> has joined #yocto12:45
*** jmpdelos <jmpdelos!> has joined #yocto12:48
bluelightningelbc_: what are you building that needs consolekit?12:55
elbc_still the same image
elbc_my goal is to have this same image, but without any traces of virtual/libx11 (I just want to use wayland)12:57
bluelightningsure, I understand the requirements, but the question is what is it in what you are building that depends on consolekit, and is it really needed?13:00
*** padge_ <padge_!> has quit IRC13:05
elbc_I don't know is consolekit is needed, but I have no right to remove it13:05
elbc_by "what is it in what you are building that depends on consolekit" do you mean the RDEPENDS line13:06
*** e8johan <e8johan!> has quit IRC13:06
*** dany <dany!> has joined #yocto13:07
*** mulhern <mulhern!> has quit IRC13:12
*** dany <dany!> has quit IRC13:21
*** walters <walters!walters@nat/redhat/x-srxinhkeddtjsjkq> has joined #yocto13:21
*** BCMM_ <BCMM_!~BCMM@unaffiliated/bcmm> has quit IRC13:23
*** dany <dany!> has joined #yocto13:30
rburtonelbc_: the error where it says it can't build x11 might tell you the entire dependency chain13:32
*** padge_ <padge_!> has joined #yocto13:41
*** padge_ <padge_!> has quit IRC13:43
*** BCMM_ <BCMM_!~BCMM@unaffiliated/bcmm> has joined #yocto13:46
*** zz_ka6sox is now known as ka6sox13:55
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-nafyymtjltgnwlsu> has joined #yocto13:58
*** Anusko <Anusko!~anusko@> has joined #yocto13:58
*** jkridner <jkridner!> has joined #yocto13:58
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto13:58
*** tomz2 <tomz2!> has left #yocto13:58
*** _alex_kag_ <_alex_kag_!~alex_kag@> has quit IRC14:07
*** mbelisko <mbelisko!> has quit IRC14:07
*** kbart <kbart!~KBart@> has quit IRC14:09
*** _julian_ <_julian_!> has left #yocto14:35
*** cfo215 <cfo215!> has joined #yocto14:37
cfo215does the ADT support Qt out of the box?14:38
*** Anusko <Anusko!~anusko@> has quit IRC14:43
*** Anusko <Anusko!~anusko@> has joined #yocto14:44
*** smartin <smartin!> has quit IRC14:45
*** gjohnson <gjohnson!4542f923@gateway/web/freenode/ip.> has joined #yocto14:49
*** _alex_kag_ <_alex_kag_!~alex_kag@> has joined #yocto14:50
*** smartin <smartin!> has joined #yocto14:50
Crofton|workzeddii, I am having a wierd patch failure14:55
Crofton|workis there anyway to get more infor on how the patch failed to apply?14:55
*** hollisb <hollisb!> has joined #yocto14:59
kergothwe really  need to get some more *useful* debug messages in bitbake15:00
kergothnot just what it's doing, but *why*, would be ideal15:00
*** davest <davest!~Adium@> has joined #yocto15:01
tlwoernerCrofton: log.do_patch? or maybe run bitbake with just the failing recipe and use the "-v" option? or maybe set PATCHRESOLVE to ""?15:02
n01guys, is yocto-kernel much different from vanilla one?15:03
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has quit IRC15:09
rburtonn01: iirc, vanilla with fixes, mostly backports/reverts15:09
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto15:09
*** andyross <andyross!> has joined #yocto15:10
n01uhm the problem is that I have kernel patches made by customer on vanilla kernel15:12
n01rburton: do you suggest to go with linux-yocto-custom?15:12
rburtonn01: you may find they just apply to linux-yocto15:14
* rburton points at zeddii etc for real kernel advice15:14
*** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has quit IRC15:14
n01rburton: yep, but this could be not true for future patches15:14
n01I think it would be safer to work with vanilla kernel15:15
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto15:15
lpapphi, I am getting this error when trying to patch net-snmp,
*** mulhern <mulhern!> has joined #yocto15:16
lpappwhy is this patch not applying correctly?15:16
lpappthis is where I got the patch from,
lpappoh, wow15:16
lpappd'oh, my bad15:16
rburtonlpapp: :)15:16
*** cfo215 <cfo215!> has quit IRC15:16
rburtonlpapp: publicly announcing a problem is a sure way to make the obvious problems apparent straight away15:17
n01zeddii: any suggestion?15:17
*** msm <msm!> has joined #yocto15:17
lpapprburton: and shoot myself in the foot. :)15:18
lpappanyway, this should be applied against the latest as well15:18
lpappI need to figure out why it was dropped in latest meta-networking.15:19
lpappperhaps because they updated libnl15:19
lpappand it is not needed anymore accordingly.15:19
lpappalthough the patch would make meta-networking / net-snmp work against denzil, so I think it is still useful if otherwise it does not introduce any harm.15:19
lpapphow can I check if a patch is applied succesfully?15:22
*** Squix <Squix!> has quit IRC15:22
rburtonlpapp: the do_patch log will say what patches were applied15:22
rburtonif it doesn't apply cleanly, do_patch fails15:22
lpappis there a patch command for bitbake?15:23
* Crofton|work curses the do_patch log15:23
lpappbitbake -c patch or something15:23
Crofton|workbb after lunch to figure this out15:23
lpappNOTE: Applying patch 'net-snmp-libnl.patch' (../meta/recipes-foo/net-snmp/net-snmp-libnl.patch)15:24
lpapprburton: ^15:24
lpappbut I am still getting the same issue as before....15:24
lpappwhat the patch was supposed to solve....15:24
lpappbitbake net-snmp -c clean && bitbake net-snmp15:24
lpappthis is what I ran.15:24
*** tomz2 <tomz2!> has joined #yocto15:24
rburtonthen the patch doesn't actually solve your problem...15:25
kergothbest off just dropping into ${S} and running quilt push, i think. that'd try applying it again. it always does a dry-run first, so it doesn't leave the source in a half-applied state unless you quilt pu -f15:25
* lpapp will rm -rf everything except conf to make sure15:25
rburtonlpapp: -c clean will wipe out the work directory for that recipe15:26
rburtonso that's all the cleaning you need15:26
lpapppractice disagrees with that on my side.15:26
rburtonit doesn't wipe existing built packages, or the sstate15:27
lpappNOTE: package net-snmp-5.7.2-r1: task do_patch: Succeeded15:27
rburtonbut it most certainly does wipe the work directory15:27
lpappok, I am getting a different issue now15:28
lpapppatches welcome, they say... :D15:28
lpapphmm, no, it is the same'ish15:28
rburtonkhem: there?15:30
rburtonkhem: you added systemd-rpm-macros, but surely as we built own our spec files thats entirely useless in yocto15:30
lpapprburton: I have put the change accidentally beside the recipe15:33
lpappand it did not get apply15:33
lpappwhy did bitbake not complain it did not find the patch there?!15:33
lpappwhere it looked for it15:34
lpappas it was listed in the recipe ...15:34
lpappI would kinda expect an error, or at least warning...15:34
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC15:35
lpappstill does not apply even from files, sig15:35
lpappwhat am I doing wrong, seriously?15:35
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto15:35
lpappI downloaded the patch15:35
lpappand just removed the stuff for the recipe....15:35
lpappso I got a double patched patch...15:35
lpappis there any simple way on patchflow to get one raw file?15:37
lpapprather than the whole double patched stuff?15:37
lpappsigh, I do not even see a raw version on patchwork ...15:38
lpappisn't there a nicer solution for tracking changes?15:38
rburtonits the patch, which contains a patch15:38
rburtonso apply it to your local tree15:38
lpappof course I cannot15:38
rburtonif you can't do that, then just apply it to anywhere and you'll get the directory15:38
lpappsince it is a terribly old patch15:38
lpappand it is definitely not for the denzil tree with custom recipes, custom location, etc etc etc15:39
lpappso what I would need is the *raw* content15:39
lpappof the patch, and copy/paste stuff out what I need15:39
lpappseriously, this is where gerrit beats patchwork thousand times15:39
lpappyou can simply do this in gerrit without this pain an hour debugging.15:40
*** elmir <elmir!> has left #yocto15:41
lpappalso, that patch does not apply against the latest networking either. :(15:41
lpappwhat a mess15:41
*** pidge <pidge!> has joined #yocto15:43
rburtonlpapp: apply the patch to an empty directory, and you'll get the subpatch out15:46
lpapprburton: I already got the patch out.15:47
lpappthe current problem is that it does not apply against 5.7.215:47
lpappalthough it was made against 5.7.15:47
* lpapp will rewrite the patch from scratch15:48
*** mckoan is now known as mckoan|away15:48
lpappperhaps bitbake could help here?15:49
lpappI am sure there could be a feature to update changes automatically.15:49
lpappin the simplest cases.15:49
*** mulhern <mulhern!> has quit IRC15:50
*** seebs <seebs!> has quit IRC15:50
rburtonlpapp: patch will do its best when a patch almost applies15:51
rburtonif that doesn't work you don't want a machine stepping in!15:51
*** gjohnson <gjohnson!4542f923@gateway/web/freenode/ip.> has quit IRC15:52
lpapprburton: sigh15:52
lpappthen I blame Joe15:52
lpappdropping this change without any reasno15:52
*** seebs <seebs!> has joined #yocto15:54
*** slaine <slaine!~slaine@> has quit IRC15:57
*** Jefro <Jefro!> has joined #yocto15:57
*** belen <belen!~Adium@> has quit IRC15:58
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto15:58
*** elmi82 <elmi82!> has quit IRC15:58
*** padge_ <padge_!> has joined #yocto15:59
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC16:00
*** sameo <sameo!samuel@nat/intel/x-hhlumnofczjfiuyv> has quit IRC16:04
lpapprburton: does the patch task ignore whitespaces by default?16:06
rburtonlpapp: doubt it, but i'd have look at the source to find out16:07
lpappcan I pass it somehow?16:07
lpappI am afraid, patch is stupid to handle it.16:07
lpappthe patch task, that is.16:07
lpappit should not fail on damn whitespaces.16:07
*** eren <eren!~eren@unaffiliated/eren> has quit IRC16:08
lpappyeah, it does not ignore whitespaces16:10
lpapplooks like a GR16:10
lpappor I can already pass that somehow?16:10
bluelightning_does GNU patch support that? if not, then I doubt it16:10
*** bluelightning_ is now known as bluelightning16:10
lpappsure, it does.16:11
lpapppatch --help | grep whitespace -l  --ignore-whitespace  Ignore white space changes between patch and input.16:11
lpapppatch -v16:11
lpapppatch 2.6.116:11
lpappI need to reimplement do_patch?16:14
lpappor how can I customize patch?16:14
* lpapp is submitting a bugreport16:15
rburtonlpapp: probably easier to fix the whitespace in your patch16:15
bluelightningthat's what most people do16:16
lpapprburton: well, that is what bugreports are for.16:17
lpapprburton: I do not think it is easier in my case.16:17
lpapprburton: passing one option would be a few seconds.16:17
lpapprburton: I have been trying to fix that for half an hour16:17
rburtonapply manually with -ignore-whitespace, re-generate diff16:17
rburtonthat's a few seconds of work16:17
lpappand still does not apply.16:17
lpappyou are welcome to do it16:18
lpappI have been trying to resolve it for half an hour now.16:18
lpappand frankly, I do not wanna waste more time with it in the future16:18
*** belen <belen!Adium@nat/intel/x-nxnqefavextbppjs> has joined #yocto16:18
*** eballetbo <eballetbo!> has quit IRC16:20
lpappso, is there an option for this16:20
lpappor I should file a bugreport16:20
*** Stygia <Stygia!> has quit IRC16:23
*** n01 <n01!> has quit IRC16:26
lpappis it possible with Yocto to apply a patch if a dependency meets a certain requirement?16:28
lpappsay, it is 2.X, not 3.X16:28
rburtonlpapp: not through PV checks16:30
rburtonif you have foo_2 and foo_3 and a .inc, then apply the patch just in the foo_2.bb16:30
lpapprburton: no, I mean foo depends on bar16:31
lpappand apply a change agaisnt foo only if bar 2 is used, but not if bar 3.16:31
rburtonoh, right, no.16:31
*** ka6sox is now known as zz_ka6sox16:38
lpappdylan broke another thing... the toolchain is not called anymore how it was.....16:40
lpappso, is there a prettier way in my Makefile than this:16:41
lpappcd openflow; ./; ./configure --build=`gcc -dumpmachine` --host=`arm-foo-linux-gnueabi-gcc -dumpmachine`; $(MAKE)16:41
lpappthis seems to work with dylan, but not with denzil.16:41
lpapp- /bin/sh: 1: arm-foo-linux-gnueabi-gcc: not found16:41
lpappchecking whether we are cross compiling... configure: error: in  ...16:41
lpapp| configure: error: cannot run C compiled programs.16:42
lpapp| If you meant to cross compile, use `--host'.16:42
lpappis there a cross-platform way of doing this between dylan and denzil?16:42
lpappI am using the smae toolchain.16:42
lpappalthough I am not using meta-sourcery for denzil.16:42
lpappand I do not wish.16:42
lpappis there a way which works with meta-sourcery and the builtin stuff?16:42
mranostaylpapp: whoa watch the flooding :)16:43
lpappmranostay: ?16:43
*** Anusko <Anusko!~anusko@> has quit IRC16:43
*** Anusko <Anusko!~anusko@> has joined #yocto16:44
*** zecke <zecke!> has quit IRC16:44
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC16:46
*** zeeblex <zeeblex!apalalax@nat/intel/x-msnsgyjczioprznj> has left #yocto16:48
*** mulhern <mulhern!> has joined #yocto16:49
*** mihai <mihai!~mihai@> has quit IRC16:50
*** mr_science <mr_science!> has joined #yocto16:52
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:52
lpappbluelightning: ^16:55
*** belen2 <belen2!Adium@nat/intel/x-mnbpfovwvjjwuzhd> has joined #yocto16:58
*** belen <belen!Adium@nat/intel/x-nxnqefavextbppjs> has quit IRC16:58
*** bluelightning_ <bluelightning_!~paul@> has joined #yocto16:59
*** bluelightning_ <bluelightning_!~paul@> has quit IRC16:59
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto16:59
*** belen2 <belen2!Adium@nat/intel/x-mnbpfovwvjjwuzhd> has quit IRC16:59
lpappIMO, yocto has a pretty complex system to resolve it, so I would rather not copy and paste that bitbake stuff out17:00
lpappfor instance I would not know what TUNE_ARCH are, and how they are supposed to work.17:00
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:01
*** andyross <andyross!> has quit IRC17:02
*** BCMM_ <BCMM_!~BCMM@unaffiliated/bcmm> has quit IRC17:04
*** bluelightning_ is now known as bluelightning17:05
bluelightninglpapp: don't know17:06
bluelightninglpapp: re TUNE_ARCH there is a README file under meta/conf/machine/include/ that talks about how the tuning stuff works17:07
* lpapp dislikes that we have an imported stuff rather using a yocto package17:07
lpappthis whole misery would be pointless if we did not use an internal clone....17:08
lpappand trying to call its buildsystem from our makefile...17:08
lpappbecause oe would manage the build of it for us just fine.17:08
lpappthat happens when a software is not designed, just written. :(17:08
lpappbluelightning: right, but I cannot copy and paste the whole few ten/hundred lines out anyway.17:09
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC17:11
*** mulhern <mulhern!> has quit IRC17:20
lpappbluelightning: can I make my buildsystem Yocto specific for now as a workaround?17:22
lpappbluelightning: I would not build the software outside yocto anyway17:22
lpappi.e. can I get the host variable from Yocto and pass that in?17:22
lpappthat would be an acceptable shortcut for now...17:22
*** mulhern <mulhern!> has joined #yocto17:22
lpapprburton: ^17:25
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto17:29
Crofton|workzeddii, should I expect PATCHRESOLVE to work with
* lpapp thinks that something changed around the machine naming in dylan compared to denzil17:33
lpappprobably some undocumented stuff like the kernel name... :(17:33
*** Anusko <Anusko!~anusko@> has quit IRC17:36
*** rburton <rburton!> has quit IRC17:37
*** rburton <rburton!> has joined #yocto17:37
*** zecke <zecke!> has joined #yocto17:37
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has quit IRC17:42
*** andyross <andyross!> has joined #yocto17:46
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto17:52
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC17:54
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto17:55
*** pev <pev!~pev@> has joined #yocto17:55
pevWow. I think I can safely say that sstate-cache just utterly revolutionised my experience of Yocto...17:56
Crofton|workhopefully in a good way ....17:56
*** BCMM_ <BCMM_!> has joined #yocto17:56
*** BCMM_ <BCMM_!~BCMM@unaffiliated/bcmm> has joined #yocto17:56
*** eren <eren!~eren@unaffiliated/eren> has quit IRC17:56
pevYeah.... I'd got my full build time down to about 65 minutes with download caching and a VERY fast new dual-xeon build server17:57
pevThen finally got around to setting up sstate and its dropped to a spritely 18 odd minutes.17:57
pevI thought it had gone wrong it was so fast...17:57
pevNow I just need to work out how to get my board to do opkg nicely (i think I can serve up packages from my build machine easily somehow?) and I'll be laughing18:00
*** mulhern <mulhern!> has quit IRC18:06
pevActually now I've refreshed it, my *full* build takes 5 (five) minutes with sstate. Superb.18:07
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto18:11
lpappJaMa: where to put uthash inside meta-oe? support, devtools, etc?18:11
kergothRP: am I correct in saying that _remove can't undo an _append? such seems to be the case here.18:11
kergothpev: yep, you should be able to serve up tmp/deploy/ipk/ via a web server and add that uri as a feed to your opkg.conf on the target18:12
*** BCMM_ <BCMM_!~BCMM@unaffiliated/bcmm> has quit IRC18:14
*** BCMM_ <BCMM_!~BCMM@unaffiliated/bcmm> has joined #yocto18:16
kergothaha! nailed down the bitbake bug i've been fighting18:16
RPkergoth: it can't? :/18:19
pevkergoth: Ah, smart - so is it normal to serve straight from your development directory or would it be better to rsync to a common dir for the web server for example? Also is there some clever mappng required on the target?  My boards opkg seems to want to talk to Is this a convention?18:19
RPkergoth: I thought _remove was the last thing to be processed so it should be able to ?18:19
kergothif you have a git mirror tarball in your downloads, but no repo, the fetcher thinks it needs to be udpated (presumably to check and see if it has the refs we need), but this means it spawns off a premirror fetch even though i already have the damn tarball it'd be trying to fetch. then, if you have a git:// premirror, rather than just tarball mirrors, and it fails to fetch that, it calls clean(), removing my perfectly fine local mirror tarball, never e18:20
seebsSo, I have found a thing I want to do, but which I can't do, and maybe I shouldn't be able to.18:20
kergothRP: Hmm, I thought so too, but DISTRO_FEATURES_remove = "wayland" isn't removing the bits appended by the poky distro config for me. maybe I have appends being applied multiple times somehow18:20
* kergoth digs18:20
seebsWhat I have: A bunch of layers with names like foo-layer-x.y, and a value, MAGIC_NUMBER, which is some x.y.18:20
RPkergoth: it certainly was intended to be last but its possible something isn't right18:21
seebsWhat I want: To pick up foo-layer-x.y for the value MAGIC_NUMBER, which may be determined by interactions with overrides.18:21
kergothI'll try to nail down a bit more information and either fix it or open a bug18:21
seebsLike, I might have MAGIC_NUMBER_mips = "1.3" and MAGIC_NUMBER_x86 = "1.5"18:21
kergothwas looking to replace user_features (what otavio based EXTRA_DISTRO_FEATURES on) and found it wasn't doing hte equivalent18:21
seebsI was looking at the sanity_conf_update magic for rewriting bblayers.conf, but I am pretty sure that is brittle and should not get used for very much, as it seems highly dependent on no one else using it.18:22
RPseebs: can't you use normal variable expansion?18:22
seebsFor layer inclusion?18:23
seebsI don't *think* I can.18:23
kergothoverrides doesn't have a useful value when bblayers.conf is being parsed, as its default is in bitbake.conf18:23
seebsI don't know of a way to add another layer that doesn't involve bblayers.conf.18:23
RPseebs: well, its early in the config building so overrides probably aren't available18:23
RPright, its the interactions with overrides I missed18:24
*** padge_ <padge_!> has quit IRC18:24
seebsI mean, I could get away from overrides, I think.18:24
*** zecke <zecke!> has quit IRC18:25
seebsI could do it with variable expansion instead of overrides. Probably. But I still need a way to say "okay, now that I know you're on MIPS, I need to include layer X instead of layer Y".18:25
kergothby the time your local.conf is parsed, so you know what machine you have, it's too late to alter the layers18:25
seebsThe context: Our toolchain deliverables come with source-rebuilding layers. We sometimes have slightly different toolchains for different architectures. So I want to be able to pick up "the corresponding layer" for the binary toolchain, but I don't know which layer that is until I know which toolchain I'm using.18:26
RPseebs: why can't you include all the layers and then just have the one you need become active?18:27
seebsPossibly because I didn't know there was a distinction between "included" and "active".18:27
RPseebs: control the functionality in the layer with overrides18:28
seebsHmm. In general, is there a thing I can put in a layer.conf, or otherwise in something other than bblayers.conf, which would include other layers? Part of my goal is to reduce this to a single line in bblayers.conf (which is being pre-generated), and have my layer then do whatever magic it needs.18:28
RPseebs: that simply isn't part of the current design18:29
seebsOh, hey. I could in fact probably get the results I want by, instead of having multiple layers, having a single layer with multiple recipes-foo subdirectories, and using something in BBFILES.18:29
kergothseebs: what's your *real* underlying goal? take a step back and explain the goal and perhaps we can help you find a different way to get there18:29
seebsLike BBFILES += "${LAYERDIR}/recipes-${FOO}/*/*.bb"18:30
RPseebs: of just have a set of recipes which raise SkipPackage if they shouldn't be active18:30
seebsOkay, the underlying goal: We get binary toolchains from a vendor. Each binary toolchain has a corresponding source layer which uses bbappends so that, if you use that source layer, and just build the toolchain normally, the toolchain is built with roughly the same source used for the binary toolchain.18:30
seebsIf the user requests the source-build option, I want to pick up the corresponding source layer.18:31
RPseebs: look at how COMPATIBLE_MACHINE and COMPATIBLE_HOST work18:31
seebsBut I don't want to have to encode the awareness of which versions are which in the code that's doing the initial creation of local.conf/bblayers.conf, because that code shouldn't have to change with every uprev.18:32
*** arky <arky!~arky@> has joined #yocto18:32
kergothi'd say take RP's advice and just aalways suck it in but have it not always be active18:32
RPseebs: just put all the recipes in the BBFILES and then have them decide whether to be parsed or not18:32
seebsAnd ideally, I don't want to have to modify the contents of those source layers at all.18:32
kergothalternatively, build additional tooling at a higher level in oyur setup scripts18:32
seebsI'm sort of wondering whether ${LAYERDIR}/sources-${THIS_SPECIFIC_VERSION}/recipies/*/*.bb would work in BBFILES.18:33
seebsBecause if it would, that would solve the problem; all the recipes are present, but only the ones matching the selected version are picked up by BBFILES.18:33
kergothi think it should..18:34
seebsThat might be simpler.18:34
RPI really hate libtool18:36
RPI just want it to install the library. It has not moved. /usr/lib/../lib is /usr/lib/18:36
seebsBasically, my fundamental problem is that I've painted myself into a corner where I want to make very fundamental configuration choices based on information that I don't want to duplicate outside of my bitbake conf files.18:36
seebsYou may hate libtool, but libtool loves you.18:36
RPseebs: the BBFILES approach could work18:37
seebsPossibly a bit much, which is why it is clingy and wants to monopolize your time.18:37
*** mulhern <mulhern!> has joined #yocto18:37
seebsI might also want to do something similar in the BBPATH .= line.18:37
seebsOkay, I have an idea of how I could do this.18:37
seebs... This is so the wrong week for me to have mild sniffles or something. I cannot think clearly.18:38
*** arky <arky!~arky@> has quit IRC18:41
*** arky <arky!~arky@> has joined #yocto18:42
*** arky <arky!~arky@> has quit IRC18:43
*** _alex_kag_ <_alex_kag_!~alex_kag@> has quit IRC18:46
*** _alex_kag_ <_alex_kag_!~alex_kag@> has joined #yocto18:47
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC18:54
*** cfo215 <cfo215!> has joined #yocto18:55
cfo215I'm trying to work with cortexa8hf-vfp-neon-angstrom-linux-gnueabi-Linux-x86 with Netbeans and it doesn't find iostream?  I've added the include path to iostream.  Not sure where it's failing.18:56
Crofton|workwell, this question is loads better than last weeks questions :)18:58
cfo215Crofton|work, oh is it now? lol18:59
Crofton|workI barely know what netbeeans is19:00
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC19:00
RPiostreams is a standard C++ header so it suggests the SDK's C++ search path may be incorrect?19:01
RPdoes anything c++ work?19:01
*** JimBaxter <JimBaxter!> has quit IRC19:02
seebsSo, it appears that BBPATH =19:17
seebs... argh19:17
cfo215RP, I added the include path (found via 'find . -name iostreams) in my sdk directory.19:17
seebsBBPATH .= ":${FOO}" does not pick up overrides which affect the value of ${FOO}.19:18
hnoiostreams should be found automatically. It's a standard header.19:18
cfo215RP, if i just source the environment and run MAKE from the project directory it works.  If i source the environment and start netbeans it doesn't find the header files.19:18
hnocfo215, sounds as if netbeans stes some conflicting environmen variables.19:19
cfo215RP, ... when building the project from netbeans.  I also tried exporting CPATH19:19
Crofton|workcfo215, is nuts, he is actually tryin gto do work based on OE output :)19:20
cfo215Crofton|work, nice!  lol19:20
cfo215RP, I created a 'tool collection' in netbeans just for the angstrom toolchain.  Including (sorry for pun) the include paths.19:23
cfo215RP, "/home/cfo215/opt/angstrom/sysroots/cortexa8hf-vfp-neon-angstrom-linux-gnueabi/usr/include/c++"  which is where I found iostream19:25
cfo215I've been called worse Crofton|work :)19:26
cfo215RP, hno the build output is at if you care to look.19:31
cfo215RP, hno: I'm going to look at that .build-conf file that shows up in the output.19:32
*** mitz <mitz!> has quit IRC19:33
JaMaseebs: still around?19:42
cfo215So Crofton|work, does anyone actually use this #yocto stuff for real work?  Just wondering...  Since it's been oh so much fun getting to this point.19:47
kergothMy day job is working on yocto, all day every day, for a commercial product.19:48
JaMacfo215: yes, people use it for real work19:48
kergothone of quite a lot of companies that do so19:48
JaMacfo215: company can find experienced contractor to start with the fun a bit faster, I agree that learning curve is a bit steep19:50
*** mitz <mitz!> has joined #yocto19:51
*** pidge_ <pidge_!pidge@nat/intel/x-ribpabxjlcjkbtbb> has joined #yocto19:52
cfo215thanks everyone.19:53
kergothYeah, I doubt anyone would disagree that it's not as easy as it could be. The documentation is greatly improved over what existed before yocto, however, now that there are actual technical writers doing the work19:54
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC19:54
cfo215Are any of you using Netbeans?19:55
cfo215Or just Eclipse since you have the Yocto plugin for that?19:56
RPcfo: Is that build system removing some of the parameters from the commands like the --sysroot option?19:56
-YoctoAutoBuilder- build #160 of nightly-qa-systemd is complete: Failure [failed Running Sanity Tests Running Sanity Tests_2] Build details are at
cfo215RP, I put the output in, and to answer your question I don't see --sysroot anywhere.20:01
RPcfo215: I think that is the problem then, you need to get the option in there...20:02
RPcfo215: you could try a wrapper script which adds the extra option to prove its the issue...20:02
*** tor <tor!> has quit IRC20:06
cfo215RP, I also found this so I'll double check my includes for the toolchain.  i found the features.h so I'll double check my includes and then try the wrapper20:10
hnocfo215, does it work if you  from the shell (after sourcing the environmen): "cd /home/cfo215/NetBeansProjects/Welcome_1; arm-angstrom-linux-gnueabi-g++    -c -g -MMD -MP -MF build/Debug/cortexa8hf-vfp-neon-angstrom-linux-gnueabi-Linux-x86/welcome.o.d -o build/Debug/cortexa8hf-vfp-neon-angstrom-linux-gnueabi-Linux-x86/welcome.o"20:11
cfo215RP is --sysroot used with gcc or gmake?20:16
cfo215RP, I have some places where I can add switches...20:16
RPcfo215: you need to pass it in the compiler flags so that it calls arm-angstrom-linux-gnueabi-g++  with the option20:18
cfo215RP, thanks.20:18
cfo215RP, OK added --sysroot, now getting cc1plus: error: to generate dependencies you must specify either -M or -MM20:22
cfo215hno, trying your request now.20:23
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC20:25
cfo215hno, fatal error: iostream: No such file or directory20:27
hnocfo215, and with a proper --sysroot=... ?20:27
*** zecke <zecke!> has joined #yocto20:28
cfo215hno, all is well in the world again... ;-) thanks20:30
cfo215now working in netbeans... thanks everyone!!!  You guys ROCK!20:31
*** bluelightning <bluelightning!> has joined #yocto20:31
*** bluelightning <bluelightning!> has quit IRC20:31
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:31
*** BCMM_ <BCMM_!~BCMM@unaffiliated/bcmm> has quit IRC20:33
*** mulhern <mulhern!> has quit IRC20:43
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto20:45
*** jkridner <jkridner!> has joined #yocto20:45
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto20:45
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC20:46
*** swex_ <swex_!~swex@> has quit IRC20:47
*** jkridner <jkridner!> has joined #yocto20:48
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto20:48
*** swex <swex!~swex@> has joined #yocto20:48
*** scot_ <scot_!~scot@> has quit IRC21:02
*** RP <RP!> has quit IRC21:06
*** smartin_ <smartin_!> has joined #yocto21:06
*** RP <RP!> has joined #yocto21:07
RPcfo215: glad you got there! :)21:07
RPcfo215: so do we have any issues in the core?21:08
cfo215RP, not as far as I know, but I'm just getting started :-)21:09
cfo215RP, I did find this issue(?), I have my own recipe for the Phidgets Library (libphidget) inside of my meta layer (meta-cfo215) but the header files and libraries don't get included when I do a bitbake meta-toolchain-qte.  I have it included in my local.conf and bblayers.conf files.21:09
cfo215the ipk gets generated and the library is available when I bitbake console-image.21:10
kergothif it automatically included every recipe in all our layers, it'd be a *really* big toolchain :)21:10
cfo215kergoth, that's probably very true... lol.  So where is the majic done if you don't mind?21:11
cfo215I need to modify meta-toolchain-qte I'm guessing.21:11
khemcfo215: Do you have an image which includes your app ?21:11
khemif you do then just bitbake -c populate_sdk <your image> will do it21:12
cfo215khem, it gets included when I bitbake console-image (Angstrom)21:12
*** joeythesaint <joeythesaint!~jjm@> has quit IRC21:12
cfo215khem, i'll try that and get back to you.21:13
khemcfo215: if you want to specifically add it to a meta-toolchain target then you need to append it to TOOLCHAIN_TARGET_TASK21:13
kergothah good, thanks khem, i was going to look it up, sdk sutff isn't fresh in my mind :)21:13
khemkergoth: yeah and I cant get it out of my mind even though  I want to21:14
khemdrenched in lot of non OE stuff21:17
RPkhem: I just checked out libgfortran with gcc-4.8 and found problems with the libquadmath :(21:23
RPkhem: is that something you're interested in or not?21:23
RPkhem: anyhow, I cc'd you on my hacks, not sure I'll do anything more with it21:23
kergothhmm, if you use an override to define SSTATE_DIR and DL_DIR, the non-override dirs get created anyway, though they end up empty. guess we must have a rogue reference with non-finalized data21:25
*** mulhern <mulhern!> has joined #yocto21:25
RPkergoth: I think we have a few of these :/21:25
RPkergoth:  ls tmp/work/i586-poky-linux/bblayers/ shows "1.0-r0" here :/21:26
RPI don't recall such a recipe...21:27
*** pidge_ <pidge_!pidge@nat/intel/x-ribpabxjlcjkbtbb> has quit IRC21:28
cfo215kergoth, "if it automatically included every recipe in all our layers, it'd be a *really* big toolchain", was kind of under the impression that what I did in local.conf and bblayers.conf was sort of a global override.  I guess that is not the case.21:28
cfo215kergoth, I figured if I had it added there, then anything i bitbaked would include it.21:28
*** zecke <zecke!> has quit IRC21:29
kergothRP: hah :)21:31
kergothRP: i think we should, if we don't already, have an "official" finalized configdata in the cooker, which everyone should use for config values, and potentially also have an event that carries it for the common case of altering non-finalized configdata based on the finalized configdata values21:32
JaMaRP: I also see bblayers in every WORKDIR and another interesting fact is that it doesn't respect architecture set by DEFAULTTUNE21:32
RPJaMa: I'm not surprised. For better or worse, I have worse things to chase down atm though :(21:34
RPJaMa: I think I did find the mystery pseudo on arm issue though :)21:34
JaMaI'm already testing that one21:34
JaMaI'm surprised it was so deterministic in your test21:34
JaMabecause when I was trying to reproduce it it was behaving a bit strangly21:35
RPJaMa: you just had to understand what was triggering it. The bitbake -e history for the variable gave a very big clue in helping understand it21:35
RPJaMa: if you build for an arch which didn't set the suffix, you wouldn't see it21:35
*** _Lucretia_ <_Lucretia_!~munkee@pdpc/supporter/active/lucretia> has quit IRC21:36
RPJaMa: so you have to use MACHINE=<something arm> with the allarch package you were tageting not in sstate or the tmpdir21:36
*** sameo <sameo!~samuel@> has joined #yocto21:36
JaMaRP: yes it's possible that I was overlooking something in bitbake -e21:37
*** Jefro <Jefro!> has quit IRC21:38
JaMaRP: I've another reproducer for weird pseudo issue, but this one seems unrelated to this finding21:38
RPJaMa: just when I thought I could get my bug count under control? :)21:39
JaMaRP: if you build core-image-minimal (with procps added to IMAGE_INSTALL), then cleansstate procps and build core-image-minimal again, buildhistory usually shows couple of file attributes changed in procps files21:39
RPJaMa: that does sound rather odd21:40
JaMaI've already discussed it with seebs, he gave me some great tips (first with NO32LIBS flag)21:40
RPJaMa: you have mixed 32 and 64 bit binaries?21:40
JaMabut there is still something fishy in it and it shows the signs a bit randomly (different procfs files get different permissions etc)21:41
JaMaRP: that was where I found it first (mixed binaries) but now I can reproduce it even with latest oe-core and internal toolchain21:41
RPJaMa: hmm, sounds like something we should try and look into21:42
JaMamy last attempt was to build with PSEUDO_OPTS=-l and share logs.db with seebs but that doesn't seem to work21:42
JaMabut you don't need to worry about this one, I'll try to resolve it with seebs21:42
JaMaI just wanted to warn you that there is something fishy (and it was there in dylan already)21:43
*** sameo <sameo!~samuel@> has quit IRC21:44
RPJaMa: thanks for the heads up. I did see some of your conversation but thought it had been resolved as static binaries or 32/64 bit libs :/21:44
cfo215khem, I did the bitbake -c populate_sdk console-image... and now i have an sdk with the libphidget library, but it don't get my qte tools (no qmake, moc, etc.)  I need it all ;-)21:44
*** sameo <sameo!samuel@nat/intel/x-jlwnguofzyxphevy> has joined #yocto21:45
RPJaMa: perhaps worth putting the reproducer in bugzilla and we can assign it to you/seebs?21:45
JaMaRP: yes looks like static binaries were caused big part of the problem, but haven't resolved all the differences detected by buildhistory21:46
JaMaRP: I'll do that tomorrow (hopefully will resolve logs.db before that to provide more useful info too)21:46
kergothcfo215: then pick a qt image. console-image is .. console21:48
kergothcfo215: pick, or create, that is21:48
cfo215kergoth, I think the only Qt image in Angstrom is the gnome-cloud9 image.  I don't need the fatness of X11 for my project.  Just Qt console using -qws on the command line.21:49
seebsI am interested in this pseudo thing, although I am not sure what my availability is like in the next week or so.21:50
cfo215kergoth, I was actually just thinking of rsyncing the two sdks into one.21:50
khemcfo215: then follow the second approach I suggested above21:50
kergothindeed, just add to meta-toolchain-qte via TOOLCHAIN_TARGET_TASK, if none of the images suit, or create an image that ahs what you want21:51
JaMaseebs: any idea why export PSEUDO_OPTS="-l" doesn't cause logs.db to contain the log entries?21:51
kergoththat said, there apparently is a qte demo image in oe-core/poky, see meta/recipes-qt/images/qt4e-demo-image.bb21:51
cfo215khem, kergoth, I add the TOOLCHAIN_TARGET_TASK in the .bb for console-image then?21:51
JaMaseebs: I thought I had it working before, but now using the same (from bash history) doesn't seem to work21:52
kergothwell, you could, but it'd likely be easier to just add to the one in meta-tolchain-qte21:52
cfo215in my local.config21:52
seebsJaMa: No, although the obvious suspicion would be that PSEUDO_OPTS might not be in the environment whitelist.21:52
kergothrather than trying to add everything to a console image21:52
JaMaseebs: I even tried it to export it from local.conf21:52
JaMas/it //g21:52
cfo215kergoth, khem, sorry I'm very newb to all of this.  I just finally got OE/Yocto/Angtrom working a few days ago.  After many trials and tribulations.  You guys are way over my head now.  I'm trying to learn.  Guess I need to look at the manuals some more.21:55
*** mulhern <mulhern!> has quit IRC21:58
kergothecho 'TOOLCHAIN_TARGET_TASK_append_pn-meta-toolchain-qte = " somepackage"' >>conf/local.conf21:59
-YoctoAutoBuilder- build #292 of nightly-x32 is complete: Success [build successful] Build details are at
kergoththough a bbappend or custom recipe would be a cleaner long term approach, that may get you there for now22:00
*** cfo215 <cfo215!> has quit IRC22:01
*** walters <walters!walters@nat/redhat/x-srxinhkeddtjsjkq> has quit IRC22:02
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-nafyymtjltgnwlsu> has quit IRC22:06
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-eojzthpiulnqlaxn> has joined #yocto22:06
*** davest <davest!~Adium@> has quit IRC22:21
JaMaseebs: exporting it inside FAKEROOTBASEENV works, tomorrow I'll share bugzilla report with you :)22:21
*** swex <swex!~swex@> has quit IRC22:29
*** swex <swex!~swex@> has joined #yocto22:29
*** j8 <j8!~IceChat9@> has quit IRC22:31
*** seebs <seebs!> has quit IRC22:35
-YoctoAutoBuilder- build #281 of nightly-ppc is complete: Failure [failed Running Sanity Tests] Build details are at
*** smartin_ <smartin_!> has quit IRC22:36
*** seebs <seebs!> has joined #yocto22:37
RPJaMa: ah, I can see why exporting it there helps now. We should document that somewhere perhaps22:42
*** eren <eren!~eren@unaffiliated/eren> has quit IRC23:03
*** andyross <andyross!> has quit IRC23:03
*** davest <davest!~Adium@> has joined #yocto23:03
*** rtollert <rtollert!~rtollert@> has quit IRC23:05
*** sameo <sameo!samuel@nat/intel/x-jlwnguofzyxphevy> has quit IRC23:05
*** rtollert <rtollert!~rtollert@> has joined #yocto23:06
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:19
*** munch <munch!> has quit IRC23:40
*** amarsman <amarsman!> has joined #yocto23:40
*** hollisb <hollisb!> has quit IRC23:56

Generated by 2.11.0 by Marius Gedminas - find it at!