Friday, 2015-07-31

*** staylor <staylor!> has quit IRC00:01
*** manuel_ <manuel_!> has joined #yocto00:05
*** manuel_ <manuel_!> has quit IRC00:09
*** manuel_ <manuel_!> has joined #yocto00:11
*** paulg <paulg!> has joined #yocto00:12
*** vmeson <vmeson!> has joined #yocto00:15
*** manuel_ <manuel_!> has quit IRC00:16
*** sameo <sameo!samuel@nat/intel/x-fnwbszfhpsnuqlwe> has quit IRC00:36
-YoctoAutoBuilder- build #422 of nightly-world is complete: Failure [failed BuildImages] Build details are at
*** roric <roric!> has quit IRC00:44
*** manuel_ <manuel_!> has joined #yocto01:02
*** paulg <paulg!> has quit IRC01:20
seebs <-- this is possibly one of the most beautiful things i have ever read01:45
*** Jefro <Jefro!> has quit IRC01:46
-YoctoAutoBuilder- build #424 of nightly-mips is complete: Success [build successful] Build details are at
*** Jefro <Jefro!> has joined #yocto02:05
*** Jefro <Jefro!> has quit IRC02:13
*** jmleo <jmleo!> has quit IRC02:15
*** simmel80___ <simmel80___!> has joined #yocto02:16
*** simmel80_ <simmel80_!> has quit IRC02:19
*** jmleo <jmleo!> has joined #yocto02:29
*** _jmleo <_jmleo!> has joined #yocto02:36
*** jmleo <jmleo!> has quit IRC02:37
*** _jmleo is now known as jmleo02:37
*** _jmleo <_jmleo!> has joined #yocto02:41
*** jmleo <jmleo!> has quit IRC02:42
*** _jmleo is now known as jmleo02:42
-YoctoAutoBuilder- build #421 of nightly-fsl-arm is complete: Failure [failed BuildImages_1] Build details are at
-YoctoAutoBuilder- build #421 of nightly-arm is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #141 of nightly-world-lsb is complete: Failure [failed BuildImages] Build details are at
*** manuel_ <manuel_!> has quit IRC03:43
*** wobbly <wobbly!d0573896@gateway/web/freenode/ip.> has quit IRC03:45
*** Jefro <Jefro!> has joined #yocto03:55
*** fabo <fabo!~fabo@linaro/fabo> has quit IRC03:56
-YoctoAutoBuilder- build #77 of nightly-arm64 is complete: Success [build successful] Build details are at
*** staylor <staylor!~staylor@> has joined #yocto04:17
*** dlan_ <dlan_!~dennis@gentoo/developer/dlan> has quit IRC04:19
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto04:20
*** staylor <staylor!~staylor@> has quit IRC04:38
*** behanw <behanw!~behanw@> has quit IRC04:38
*** miandonmenmian <miandonmenmian!~miandonme@> has joined #yocto05:03
*** miandonmenmian_ <miandonmenmian_!~miandonme@> has joined #yocto05:03
*** miandonmenmian__ <miandonmenmian__!~miandonme@> has joined #yocto05:03
*** grma <grma!> has joined #yocto05:20
*** Jefro <Jefro!> has quit IRC05:37
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto05:58
*** hamis <hamis!~irfan@> has joined #yocto06:02
*** Jay7 <Jay7!> has quit IRC06:09
*** sameo <sameo!~samuel@> has joined #yocto06:16
*** pohly <pohly!> has joined #yocto06:27
*** Jefro <Jefro!> has joined #yocto06:33
*** redengin <redengin!> has quit IRC06:40
*** redengin <redengin!> has joined #yocto06:44
*** egavinc <egavinc!> has quit IRC06:46
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has joined #yocto06:48
*** jbrianceau_away is now known as jbrianceau06:48
*** diego_r <diego_r!> has joined #yocto07:08
*** sameo <sameo!~samuel@> has quit IRC07:25
*** Biliogadafr <Biliogadafr!~User@> has joined #yocto07:27
*** pohly <pohly!> has quit IRC07:28
*** LocutusOfBorg1 <LocutusOfBorg1!> has joined #yocto07:33
*** psnsilva <psnsilva!> has joined #yocto07:35
*** Biliogadafr <Biliogadafr!~User@> has quit IRC07:37
*** Biliogadafr <Biliogadafr!~User@> has joined #yocto07:38
*** sameo <sameo!~samuel@> has joined #yocto07:42
*** jonathanmaw <jonathanmaw!> has joined #yocto07:48
*** TobSnyder <TobSnyder!> has joined #yocto07:52
*** Biliogadafr1 <Biliogadafr1!~User@> has joined #yocto07:54
*** Biliogadafr <Biliogadafr!~User@> has quit IRC07:54
*** Jefro <Jefro!> has joined #yocto07:56
*** ant_work <ant_work!> has joined #yocto07:57
*** xata <xata!c3188e8a@gateway/web/freenode/ip.> has joined #yocto08:04
xataIs this supposed to be a help channel or developers-only? I've got trouble with receipes trying compile image for my dev board (missing orc and bluez5-bluez4 conflict)08:05
*** Jay7 <Jay7!> has joined #yocto08:06
*** lordzen <lordzen!> has joined #yocto08:06
*** ddalex <ddalex!> has quit IRC08:15
*** sameo <sameo!~samuel@> has quit IRC08:21
*** arfoll <arfoll!~arfoll@> has left #yocto08:28
*** arfoll_ <arfoll_!~arfoll@> has quit IRC08:29
*** arfoll <arfoll!~arfoll@> has joined #yocto08:30
*** zaman1 <zaman1!zaman@nat/intel/x-awlasgsjevruhjzf> has joined #yocto08:33
*** Biliogadafr1 <Biliogadafr1!~User@> has quit IRC08:35
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:36
*** Biliogadafr <Biliogadafr!~User@> has joined #yocto08:36
*** zaman <zaman!~zaman@> has quit IRC08:36
*** belen <belen!~Adium@> has joined #yocto08:39
*** Jefro <Jefro!> has quit IRC08:43
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-haheqhisdlitzdew> has joined #yocto08:47
vtechHi ! i solved my problem for a custom-xlnx kernel. There is no problem anymore on the recipe. Except that now the version taken is not the good one. It's back to the default (3.14) instead of mine (3.8) i settet LINUX_VERSION = "3.8" and KBRANCH ?= "xlnx_3.8" in my recipe and this in my local.conf : PREFERRED_PROVIDER_virtual/kernel = "linux-xlnx" and PREFERED_VERSION_linux-xlnx = "3.8". Somewere the version seems to be overrided. But i08:51
*** karotin <karotin!4d5007b2@gateway/web/freenode/ip.> has joined #yocto08:51
vtechdo you have any ideas ?08:51
karotinhello, someone may have a sample makefile, which is running with a simple recipe?08:52
*** LetoThe2nd <LetoThe2nd!> has quit IRC08:53
vtechsorry i don't understand :/ you mean that the version might be hardcoded in a makefile or something ?08:53
bluelightningmorning all08:54
bluelightningvtech: you meant PREFERRED not PREFERED right ?08:55
bluelightningvtech: run bitbake -e linux-xlnx | less and search for LINUX_VERSION - see if it's being overridden08:56
ndecvtech: you probably want 2 'R' at PREFERRED ;-)08:56
vtechoh there is indeed PREFERED_VERSION_linux-xlnx = "3.8" in my local.conf, i test it with the correction  right now ><08:56
ndeckarotin: the user manual has that.08:57
bluelightningsometimes I think it would be nice if we could detect such typos, but I don't think it's practically possible with how our system works08:57
*** redengin <redengin!> has quit IRC08:58
*** redengin <redengin!> has joined #yocto08:58
ndecbluelightning: we could integrate aspell in bitbake ;-)08:58
vtechOk i have another output, there was indeed a problem here , sorry ><  . It tries to take my version but : NOTE: preferred version 3.8 of linux-xlnx not available (for item kernel-image) seems to be the problem.08:58
vtechi am using but i don't thkink linux-yocto has a 3.8 kernel :/08:59
bluelightningvtech: that in and of itself shouldn't be a problem, as long as you are pointing at your own source08:59
ndecvtech: if you made your own layer, did you add it to bblayers.conf?09:00
vtechyes i did. And i am using the xlnx repo on the 3.8 BRANCH as specified by the KBRANCH variable.09:02
vtechthe stange things is that it seems to see the 3.8 as available and then it's not : NOTE: preferred version 3.8 of linux-xlnx not available (for item kernel-image) NOTE: versions of linux-xlnx available: 3.14-xilinx+gitAUTOINC+2b48a8aeea 3.8-xilinx+gitAUTOINC+297a37ee4009:02
bluelightningvtech: ah right, to match that you need to set PREFERRED_VERSION_linux-xlnx = "3.8%"09:04
bluelightning(% is a wildcard in PREFERRED_VERSION)09:04
vtechbluelightning ndec: That solved it :) Thanks again for you help :)09:06
[Sno]bluelightning: wrt. two machines in one build-dir09:19
[Sno]$ MACHINE=bohr bitbake rdm-core-image09:19
[Sno]ERROR: Unable to determine endianness for architecture 'INVALID'                                                                                                                                           | ETA:  --:--:--09:19
[Sno]ERROR: Please add your architecture to siteinfo.bbclass09:19
[Sno]ERROR: Failed to parse recipe: /home/sno/fsl-community-bsp/sources/meta-jens/recipes-extended/libstatgrab/libstatgrab_git.bb09:19
*** rdmtob <rdmtob!> has joined #yocto09:19
[Sno]ERROR: Unable to determine endianness for architecture 'INVALID'09:19
[Sno]ERROR: Please add your architecture to siteinfo.bbclass09:20
bluelightning[Sno]: and that definitely does not happen if you set MACHINE = "bohr" in local.conf ?09:22
[Sno]bluelightning: yes09:22
bluelightning[Sno]: is this with master?09:22
[Sno]bluelightning: I'm using that local.conf:
[Sno]and for the error I commented out the first line ;)09:23
[Sno]we have two machines, curie and bohr09:23
bluelightning[Sno]: what does bitbake -e | less report about how MACHINE is being set?09:24
[Sno]and even in I don't see anything which should cause such error09:24
[Sno]bluelightning: PATTERN not found09:25
bluelightningerm ... ?09:26
karotinndec: still cant't find the error in the makefile..I'd like to compile a driver09:26
[Sno]I tried to add "MACHINE = ${@os.getenv('MACHINE', 'nope')}" to local.conf - and it reports "nope"09:26
ndeckarotin: for kernel module it's slightly different. one sec.09:27
[Sno]bluelightning: sno@waldorf:~/fsl-community-bsp/ornithologie$ MACHINE=bohr bitbake -e | grep MACHINE=09:27
[Sno]same when grepping for "bohr" with above bitbake command09:29
karotinndec: the only thing i see, what is different, is the "inherit module"09:29
bluelightning[Sno]: firstly, the environment is sanitised so that os.getenv isn't expected to work; secondly MACHINE is unexported so that grep isn't expected to work either09:29
bluelightning[Sno]: you really do want to use bitbake -e | less and search, not grep09:30
[Sno]bluelightning: I used less and "/" - that results in "pattern not found" ;)09:30
bluelightning[Sno]: MACHINE isn't in there at all? I find that hard to believe...09:31
[Sno]I can upload the output of bitbake -e09:32
[Sno]# $MACHINE [2 operations]09:33
[Sno]#   set /home/sno/fsl-community-bsp/sources/poky/meta/conf/documentation.conf:27109:33
[Sno]#     [doc] "Specifies the target device for which the image is built. You define MACHINE in the conf/local.conf file in the Build Directory."09:33
[Sno]#   set /home/sno/fsl-community-bsp/sources/poky/meta/conf/bitbake.conf:76009:33
[Sno]#     [unexport] "1"09:33
[Sno]# pre-expansion value:09:33
[Sno]#   "None"09:33
[Sno]unset MACHINE09:33
karotinndec: looks good :)09:33
*** roric <roric!> has joined #yocto09:35
bluelightning[Sno]: ah... in your external environment as set up by the environment setup script, does the value of BB_ENV_EXTRAWHITE include MACHINE? (it should by default)09:35
[Sno]bluelightning: I check that ...09:36
*** LetoThe2nd <LetoThe2nd!> has joined #yocto09:36
[Sno]bluelightning: it doesn't - we initially used such an environment created by fsl-release-bsp which broke more than it helped and we removed most of that without sane replacements09:40
[Sno]I dig deeper on that - maybe that solves the 2nd problem I had with different machines in one build-dir ;)09:40
bluelightning[Sno]: ah, well, there's your problem then (well, at least an explanation of why it doesn't work)09:40
bluelightning[Sno]: as I said earlier though there's nothing saying you can't just set the other machine in local.conf each time instead of passing it in from the environment, if you prefer09:41
[Sno]the BB_ENV_EXTRAWHITE explains a lot ;)09:41
[Sno]thanks a lot09:43
[Sno]rdmtob: I miss the PR for meta-cpan :)09:44
[Sno]I wanted this afternoon update some modules and add support for Tim's Slic3r wish09:44
karotinSlic3r support? does that make even sense on embedded devices?09:45
[Sno]karotin: depends on what you embed where ;)09:46
[Sno]car infotainment is also embedded device and BMW uses Yocto for there infotainment platform09:47
bluelightningtelecommunications infrastructure is another oft-cited counterexample09:47
[Sno]my customer put's an xbmc on it's device paired with a bunch of Java services09:48
karotink :)09:49
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has quit IRC10:03
*** Daemon404 <Daemon404!~who_knows@> has joined #yocto10:09
*** LocutusOfBorg1 <LocutusOfBorg1!> has quit IRC10:22
*** Net147_ <Net147_!~Net147@unaffiliated/net147> has quit IRC10:23
*** LocutusOfBorg1 <LocutusOfBorg1!> has joined #yocto10:25
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto10:25
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC10:26
*** sameo <sameo!~samuel@> has joined #yocto10:26
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-haheqhisdlitzdew> has left #yocto10:29
*** Net147 <Net147!~Net147@unaffiliated/net147> has quit IRC10:30
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto10:32
*** nighty^ <nighty^!> has joined #yocto10:33
*** xata <xata!c3188e8a@gateway/web/freenode/ip.> has quit IRC10:37
*** egavinc <egavinc!> has joined #yocto10:42
*** pidge <pidge!~pidge@2a02:8084:0:3000:983d:44d9:bffd:929> has joined #yocto11:26
*** manuel_ <manuel_!> has joined #yocto11:35
*** karotin <karotin!4d5007b2@gateway/web/freenode/ip.> has quit IRC11:37
*** blitz00 <blitz00!~stefans@> has joined #yocto11:40
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto11:40
*** rdmtob <rdmtob!> has quit IRC11:43
*** miandonmenmian <miandonmenmian!~miandonme@> has quit IRC11:44
*** miandonmenmian_ <miandonmenmian_!~miandonme@> has quit IRC11:44
*** miandonmenmian__ <miandonmenmian__!~miandonme@> has quit IRC11:44
*** darkspike_2 <darkspike_2!~darkspike@> has joined #yocto11:46
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto11:47
*** darkspike <darkspike!~darkspike@> has quit IRC11:48
*** darkspike_2 is now known as darkspike11:48
*** Biliogadafr1 <Biliogadafr1!~User@> has joined #yocto11:50
*** Biliogadafr <Biliogadafr!~User@> has quit IRC11:50
*** belen <belen!~Adium@> has quit IRC11:55
*** belen <belen!~Adium@> has joined #yocto11:56
*** karotin <karotin!4d5007b2@gateway/web/freenode/ip.> has joined #yocto11:58
*** TobSnyder <TobSnyder!> has quit IRC12:07
*** psnsilva <psnsilva!> has quit IRC12:18
*** grma <grma!> has quit IRC12:19
vtechHi ! I am still trying to build my 3.8 kernel for xilinx , i have a problem with the meta. I have several .scc and .cfg in my layer and i am trying to use several .scc and .cfg from meta-xilinx layer. I think there is a conflict on that. as the error shown is : | ERROR. Could not locate meta series for zynq in the do_patch function. am i right on the cause of the problem ?12:24
*** darkspike <darkspike!~darkspike@> has quit IRC12:25
*** darkspike <darkspike!~darkspike@> has joined #yocto12:28
*** andrewsh <andrewsh!> has joined #yocto12:29
andrewshjoshuagl: ohai :)12:30
*** psnsilva <psnsilva!> has joined #yocto12:31
* joshuagl doffs cap12:33
*** realBigfoot <realBigfoot!~realBigfo@> has joined #yocto12:36
vtechIf a .inc uses the variable ${THISDIR} , how can i use it from another folder without having conflict ?12:41
*** realBigfoot_ <realBigfoot_!~realBigfo@> has joined #yocto12:42
*** realBigfoot <realBigfoot!~realBigfo@> has quit IRC12:42
*** hugovs <hugovs!~hugo@> has joined #yocto12:43
*** jonathanmaw <jonathanmaw!> has quit IRC12:45
*** jonathanmaw <jonathanmaw!> has joined #yocto12:48
*** zenx <zenx!~quassel@> has joined #yocto12:49
bluelightningvtech: you may be getting into a situation where the .inc file isn't going to work for what you're trying to do12:50
karotinhow to write a do_compile for a simple c++ program with dependencies? i can compile the main.cpp now, but i faile to make a dependecie on clas.cpps..12:55
karotin${CXX} ${CXXFLAGS} ${LDFLAGS} ${WORKDIR}/main.cpp -o ttkeys12:55
*** imrehg <imrehg!> has joined #yocto12:56
vtechbluelightning: I think it is related to the usage of ${THISDIR} in the .inc which forbid it's use from anywhere else :/ overinding the THISDIR variable might do the job but this is the ugliest thing to do no ? :/12:57
bluelightningvtech: how is ${THISDIR} being used ?12:58
*** davis <davis!> has quit IRC12:59
*** behanw <behanw!~behanw@> has joined #yocto12:59
vtechbluelightning: this way : FILESEXTRAPATHS_prepend := "${THISDIR}/linux-xlnx:" but the folder pointed is containing patches for 3.14 and 3.19 kernel which i don't use. I can't figure out why the meta xilinx cannot be found13:00
vtechbluelightning: and the second one , which is , i think, the cause of the problem : FILESEXTRAPATHS_prepend := "${THISDIR}/config:"13:01
*** psnsilva <psnsilva!> has quit IRC13:02
vtechbluelightning: in the config folder (located inside the meta-xilinx layer) there are the base configs for the board. in a config folder located in my layer i have my .cfg and . scc. it seems that the meta paths are lost and do_patch fail :/13:03
bluelightningvtech: FILESEXTRAPATHS just specifies additional paths where do_fetch should look for for items specified in SRC_URI13:04
bluelightningvtech: you can prepend your own paths there, or you can not have the items you don't want in SRC_URI, depending on what it is you need13:04
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto13:05
vtechbluelightning: yes, that's why i started using this .inc but how can the base meta be lost. i am just appending my files with : FILESEXTRAPATHS_prepend := "${THISDIR}/config:" (this one is in MY layer). So the meta i added should be found no ?13:05
*** melio_cc <melio_cc!> has quit IRC13:08
bluelightningvtech: if by "meta" you mean local files specified with file:// in SRC_URI, yes13:08
*** tsramos <tsramos!~tsramos@> has joined #yocto13:09
vtechbluelightning: In the .inc , the THISDIR variable is refering to my recipe location or the .inc location ? because they are in separated layers. It might be the problem . I know THISDIR is relative to the recipe currently being parsed. But what about a .inc ?13:11
*** egavinc <egavinc!> has quit IRC13:13
*** psnsilva <psnsilva!> has joined #yocto13:14
bluelightningvtech: I believe THISDIR will point to the path in which the current file is being parsed, and the current file at that point would be the inc file13:16
vtechbluelightning: hmm seeing the error i'm getting i would say the opposite.. are you sure about that ?13:19
bluelightningvtech: well, you can easily confirm what's really happening by using bitbake -e recipename | less and searching for FILESEXTRAPATHS13:20
vtechbluelightning: indeed, you are right. it is relative to the .inc location. I have no clue about the error so.. thanks for you help once again.. ^13:23
*** dorileo <dorileo!~dorileo@> has joined #yocto13:23
bluelightningvtech: additionally you should be able to see in log.do_fetch where it is looking for each item13:23
*** mie_ <mie_!5c6797da@gateway/web/freenode/ip.> has joined #yocto13:25
vtechbluelightning: every path is correct... i have no idea why the meta xilinx cannot be found..13:29
bluelightningvtech: what is the exact error you are receiving ?13:29
vtechbluelightning: the error is : | ERROR. Could not locate meta series for zynq13:30
bluelightningvtech: are you pointing at a repository that has a linux-yocto style meta branch + source branch, or only a source branch?13:31
mie_Hi ! I would like to disable c++ languages during the build of gcc-runtime . So I override LANGUAGES by "c" and disable "--disable-libstdcxx-v3" on the EXTRA_OECONF.  But it fail during gcc-runtime configuration . Somebody knows this error : "checking for exception model to use... configure: error: unable to detect exception model "13:33
vtechbluelightning: i think it's a source only. But i'm using the the xlnx .inc and variables which are able to build a 3.14 and 3.19 kernels from a source only repository. (
* zeddii reads13:34
* zeddii actually just improved the error messages in that area. 13:35
zeddiivtech: what release are you using ?13:35
*** JaMa <JaMa!> has joined #yocto13:37
vtechi'm using yocto fido13:38
vtechzeddii: i'm using yocto fido13:38
*** manuel_ <manuel_!> has quit IRC13:39
zeddiiok. so my latest changes in master don't come into play .. that's good. but yes, chances are it isn't finding one of the references files and failing to generate a meta-series (which is the messages I've been working on).13:39
zeddiiis any of this somewhere you can pastebin, and I can see it ?13:39
zeddiiI'm heading out on vacation tomorrow, so have little time to get set up. but if I can jump start a debug of it, I can probably point it out quickly.13:40
vtechzeddii:  you want the error log ?13:40
zeddiiit won't be helpful. but sure. it doesn't have much information, that's what I've been improviing.13:40
zeddiiif you can find the log for the do_configme and do_patch phases, something may be lurking in there to point out the exact file it couldn't find.13:41
vtechzeddii: ok, i'm posting that right now on a pastbin13:41
*** raykinsella781 <raykinsella781!rkinsell@nat/intel/x-cjbldaitjfnzprxf> has joined #yocto13:44
arfollotavio: i'm using meta-java and trying to get a decent JAVA_HOME for my lib using openjdk7/8. Was hoping java.class would provide this, any tips?13:44
bluelightningmario-goulart: also ^13:45
vtechzeddii: here is the do patch log : but i have no log in the temp folder for do_kernel_configme13:46
vtechzeddii: are you talking about the do_kernel_metadata instead ?13:47
zeddiiyah. that's where I moved it. old habits :)13:47
vtechok i'm posting it too13:47
zeddiiyah. as expected zero of value in
zeddiithat's why I made some logging more verbose.13:48
vtechzeddii: here is the metadata log :
zeddiiok. so that shows us something.13:49
zeddiibear with me if I ask you qusetinos that bluelightning already did. I didn't churn through the history.13:49
*** karotin <karotin!4d5007b2@gateway/web/freenode/ip.> has quit IRC13:50
zeddiixilinx-drivers-linux-xlnx.scc, that is what you are trying to add ?13:50
* zeddii updates his meta-xilinx13:50
* zeddii sees that in the layer13:51
vtechzeddii: no this one is in the xlnx layer13:51
vtechi'm trying to add : framebuffer.scc and wifi.scc (they both have a corresponding .cfg and are located in meta-adeneo/recipes-kernel/linux/config/adeneo/features13:52
zeddiithat .scc file is wrong in the layer. they don't actually reference it in any of the configs in meta-xilinx, and it is in fact referring to a file that doesn't exist.13:54
zeddii xilinx-ip-linux-xlnx.cfg isn't anywhere to be found ... are you saying that you are creating or importing that via another layer ?13:55
mario-goulartarfoll: I'd suggest to take a look at some lib recipes in meta-java13:55
vtechit does exist, i added it in my layer. and used   SRC_URI_append += " \ file://adeneo;type=kmeta;destsuffix=adeneo \ "  to reference it.13:55
vtechno i don't use xilinx-ip-linux-xlnx , it is not mine...13:55
vtechis that the one causing the issue ? Oo13:55
* ant_work thinks that layer is the only one using type=kmeta in SRC_URI13:56
zeddiiant_work, nope. all of master is now :)13:56
*** manuel_ <manuel_!~manuel@> has joined #yocto13:56
vtechhow can the xilinx layer build a 3.14 kernel if there are missing files.. Oo13:56
ant_workyep but only in the master recipe, not in further appends/inc iirc13:57
zeddiivtech, because they don't actually reference that fragments.13:57
zeddiiwhen I grep the fido branch of meta-xilinx, I get zero hits on xilinx-drivers-linux-xlnx.scc13:58
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC13:58
zeddiiant_work, aha. I see. I do that locally in a meta-local, just to be sure it works.13:58
vtech ok.. but neither i do.. well i thought so13:58
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto13:59
zeddiiit is worth pinging the meta-xilinx list, it is probably just an orphan .. but not using it in your work is probably a good thing as well.13:59
ant_workzeddii: fwiw I have still to study the very last changes13:59
ant_work" After this change, linux-yocto can no longer process combined trees,13:59
ant_work  and is simplified as a result."13:59
zeddiino more meta branch to cause confusion :)14:00
vtechbut i never reference it directly from my recipe14:01
*** hugovs <hugovs!~hugo@> has quit IRC14:02
vtechlooking at the fido branch of the xilinx repo i find both the .scc and the .cfg14:03
vtechoh no my bad14:04
vtechi made a mistake , there is nothing indeed.14:04
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC14:04
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto14:05
arfollmario-goulart: do you have in particular? I see the inherit java-library seems to be the main thing but I dont see how that exports JAVA_HOME location which I need for my code to build14:05
zeddiivtech. something, somewhere must be referencing that .scc file if it is coming into the mix though. I'm not seeing it. hmm.14:09
*** cference <cference!> has quit IRC14:11
vtechzeddii: arf my last day of internship , so sad :p i'm looking for it too right now :)14:12
vtechi have a reference to it in : meta-xilinx/recipes-kernel/linux/config/xilinx-base/bsp/xilinx/xilinx-drivers-linux-xlnx.scc14:13
vtechzeddii: well it's referencing the cfg file14:14
ant_workzeddii: time permitting I'll try again to create some macro-groups of fragments. I.e. fs compiled in plus block devices to boot from anywere14:14
zeddiiexactly. but unless a SRC_URI references that .scc, or another one includes it. it won't come into the build, and I'm not seeing that reference.14:14
vtechyeah, me neither :/14:15
zeddiiif the layers or recipes were public, I could track it down. but looking at what I have to go on, I'm not seeing it.14:16
darkspikeHi All... I want to override a do_configure_prepend function in a .bbappend recipe. This does not seem to work. It will call both my do_configure_prepend and the one from original recipe.14:16
zeddiilike anything there's no magic. a .scc file has to be referenced someewhere to be used.14:16
darkspikeHow do I do this ?14:16
vtechzeddii: i'm currently searching my whole HDD for the file14:18
vtechzeddii: well no match.. i'll give up maybe :/14:19
* zeddii wants to know where that is coming from!14:20
vtechzeddii: yeah me too >< i'm still searching14:20
zeddiiif you do a bitbake -e and dump it to a file. Is it someone on the SRC_URI ?14:20
vtechi tell you in a second14:21
*** hamis <hamis!~irfan@> has quit IRC14:22
vtechnot a single reference :/14:23
vtechhow is that possible ?14:23
zeddiihaving written all the code that processes those files. there's nothing that would go out and reference it by itself. barring a horrible bug of course.14:24
zeddiivtech. can you go look at the meta-series itself ? it's in the kernel source directory14:24
zeddiitmp/worked-shared/<your machine>/kernel-source/.meta/meta-series14:25
vtechi can't find any .meta folder.. i'm in /tmp/work/zc702_zynq7-poky-linux-gnueabi/linux-xlnx/3.8-xilinx+gitAUTOINC+297a37ee40-r0/linux-zc702_zynq7-standard-build14:27
zeddiithat's the build14:27
zeddiithe source is in split in fido to work-shared/14:27
vtechoh yes work-shared sorry <<14:27
*** jbrianceau <jbrianceau!uid10952@gateway/web/> has quit IRC14:27
*** jbrianceau <jbrianceau!uid10952@gateway/web/> has joined #yocto14:28
vtechthere is no file or folder names meta-series in .meta, i'm looking for it14:28
vtechzeddii: there is nothing named like that in .meta14:30
*** lamego <lamego!~lamego@> has joined #yocto14:30
zeddiiin .meta, what do you see ? a file called top_tgt ?14:30
zeddiisince that failure was in the generation of the meta series it won't be thre14:31
zeddiimy bad for not being clear.14:31
vtechyes there is top_tgt , no problem :)14:31
zeddiicat that file. where does it point ?14:32
vtechi can't put it here >< don't know why here is the pastbin :
*** sdh11 <sdh11!> has quit IRC14:35
*** sdh11 <sdh11!> has joined #yocto14:36
zeddiivtech. ok. so that file is the start of everything. it includes other .scc files (and they can do the same), or fragments. if you open that file, and chase everything it includes, something must be yanking in that bad .scc file. if it isn't there, it is either via SRC_URI or KERNEL_FEATURES. exhaust those searches and it has to be found.14:36
vtecho i'll look for that :)14:37
vtechthaks :)14:37
vtechthanks *14:37
*** realBigfoot_ <realBigfoot_!~realBigfo@> has quit IRC14:39
*** hugovs <hugovs!~hugo@> has joined #yocto14:44
mario-goulartarfoll: oh, sorry.  So you _need_ JAVA_HOME set to build you library.  Can't you just use the STAGING_... variables as defined in java.bbclass?14:46
*** realBigfoot <realBigfoot!~realBigfo@> has joined #yocto14:53
ant_workvtech: found it? it seems config/xilinx-common/bsp/xilinx/soc/zynq.scc14:55
*** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has quit IRC14:55
* ant_work lurking interested about new ways to (ab)use of fragments in the metadata14:55
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC14:56
*** jmpdelos <jmpdelos!> has quit IRC14:59
*** jmpdelos <jmpdelos!> has joined #yocto15:04
*** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has joined #yocto15:08
*** sameo <sameo!~samuel@> has quit IRC15:09
*** sameo <sameo!~samuel@> has joined #yocto15:09
*** AlexVaduva <AlexVaduva!~AlexVaduv@> has quit IRC15:13
*** ant_work <ant_work!> has quit IRC15:13
arfollmario-goulart: I could use those to translate I was just thinking there would be something pretty much good to go for people using JAVA_HOME15:17
*** madisox <madisox!> has joined #yocto15:20
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has quit IRC15:25
kergothRP: stupid question, are mirrors & sstate mirrors replacements applied recursively?15:26
RPkergoth: yes, I think so15:26
RPkergoth: I do have some sstate mirror pieces locally I keep meaning to submit...15:26
*** twirck-user-1320 <twirck-user-1320!~twirck-us@> has joined #yocto15:27
kergothK, I figured that was probably the case. One related question: can it recurse infinitely? I'm assuming the same pattern won't be re-applied in the recursion, just all the others, but in theory two patterns could keep appending to one another recursively, forever15:27
*** psnsilva <psnsilva!> has quit IRC15:27
kergoththats just a thought, obviously haven't tested such a thing15:27
kergothhappened across your 'Add basic sstate dsitro version mapping for file urls' and was wondering if the distro fallbacks would recurse, so each new distro only has to fall back to the previous, not to all previous versions explicitly15:28
kergothsounds like the answer is yes15:28
*** acedude <acedude!~acedude@> has joined #yocto15:28
RPkergoth: yes, I did that deliberately. There are simplistic checks for recursion15:29
RPkergoth: I don't doubt someone could make it break15:29
*** acedude <acedude!~acedude@> has quit IRC15:29
*** twirck-user-1320 <twirck-user-1320!~twirck-us@> has quit IRC15:29
*** cazze <cazze!> has quit IRC15:29
*** acedude <acedude!~acedude@> has joined #yocto15:29
kergothfigured as much :)15:29
acedudehackers I have a question on how to structure a derivitative machine15:30
-YoctoAutoBuilder- build #411 of nightly-intel-gpl is complete: Success [build successful] Build details are at
acedudeI have tweaked the beaglebone.conf file and added and include to the linux-yocto kernel recipe to add some features, and everything works well. Should I now create my own bsp layer using the yocto-layer create and move those changes in there, with my own machine.conf file, to keep them separate from meta-yocto-bsp layer?15:32
*** aehs29 <aehs29!aehernan@nat/intel/x-oxauwzvuakowydxz> has joined #yocto15:33
*** raykinsella781 <raykinsella781!rkinsell@nat/intel/x-cjbldaitjfnzprxf> has left #yocto15:33
*** vtech <vtech!500fd832@gateway/web/freenode/ip.> has quit IRC15:34
acedudethis is for internal use on a beablegone prototype, just wondering what the best way to package changes are for a machine that is almost the same as stock beagleboard but with a few minor additions15:34
*** aehs29 <aehs29!aehernan@nat/intel/x-oxauwzvuakowydxz> has left #yocto15:35
*** staylor <staylor!> has joined #yocto15:37
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-awmraemjbzrfpkdb> has joined #yocto15:39
*** sameo <sameo!~samuel@> has quit IRC15:44
*** varibull_ <varibull_!> has quit IRC15:45
*** varibull_ <varibull_!> has joined #yocto15:46
*** mie_ <mie_!5c6797da@gateway/web/freenode/ip.> has quit IRC15:48
*** roric <roric!> has quit IRC15:48
*** benjamirc <benjamirc!~besquive@> has joined #yocto15:51
*** sujith_h <sujith_h!~sharidas@kde/developers/sujithh> has left #yocto15:57
acedudepeaceful here15:59
kergothcreating your own bsp layer sounds fine. if you wanted to, you could use a different machine name and have your own machine.conf require the other one, to avoid duplicating content there, and then use MACHINEOVERRIDES to that both your override and the original machine override apply16:00
kergothwe've done that before, e.g. mel-omap5-evm instead of omap5-evm16:00
*** imrehg <imrehg!> has quit IRC16:01
acedudethat sounds cleaner, thanks16:01
*** simmel80___ <simmel80___!> has quit IRC16:01
*** diego_r <diego_r!> has quit IRC16:01
kergothe.g. require/conf/machine/<original machine>.conf in the machine.conf, yous hould be able to grep to see examples of MACHINEOVERRIDES, but it's just a section of OVERRIDES, colon separated, with the last winning over the former. so e.g. MACHINEOVERRIDES = "<original machine name>:<your machine name>"16:02
*** roric <roric!~roric@> has joined #yocto16:02
*** atuleu <atuleu!80b2941b@gateway/web/freenode/ip.> has joined #yocto16:02
kergoththat might not be needed, but it's a good idea just in case the original override is used anywhere, so you don't miss anything16:02
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-awmraemjbzrfpkdb> has left #yocto16:02
acedudei think that sounds good. How would I handle the kernel fragment that I included in the kernel recipe for this machine?16:03
*** atuleu <atuleu!80b2941b@gateway/web/freenode/ip.> has quit IRC16:03
kergothyou could bbappend the kernel recipe to add your fragment, in your bsp layer16:04
kergothor provide your own kernel recipe, really up to you, whatever works best16:05
acedudeI see. I will give this all a try. Thanks!16:05
kergothyou'll discover there are lots of ways to just about everything, and only sometimes are there conventions over what's best, often it's case-by-case, and the project covers a lot of use cases, so you end up going with whatever is best for your situation16:08
*** atuleu <atuleu!80b2941b@gateway/web/freenode/ip.> has joined #yocto16:09
atuleuHi, I have a question about using qemu to generate some file in a recipe (like emacs recipe). I used the same template than the old emacs recipe and I get the same segfault error16:10
atuleuI investigated and it seems that qemu is loading the host libc and not the target libc, thus the segfault16:11
atuleuSo my idea is that the emacs recipe is doing it the wrong way. Does someone now another recipe with the same mechanism that use qemu to run a program compiled for thetarget platform ?16:12
kergothafaik any recipes needing to do that should be inheriting qemu, using qemu_run_binary(), and DEPENDS on qemu-native16:14
*** acedude <acedude!~acedude@> has quit IRC16:18
atuleuthanks, I think that would help me a lot16:18
kergothRP: am i missing something, or is it impossible to add back a task which was removed with deltask? i think either it needs to be able to add it back (ideal) or the addtask command should result in some form of failure, rather than just doing nothing16:19
RPkergoth: I suspect its an oversight16:20
RPkergoth: I've never tried that16:20
kergothI was wanting to experiment with appending a recipe and making it no longer build, but instead e.g. pull binaries. Since in the general case I don't know what tasks have been added between patch and install, i don't want to just override the configure/compile task content, it'd be ideal to wipe and reconstruct part of the task graph :)16:21
*** dfaught <dfaught!> has joined #yocto16:22
-YoctoAutoBuilder- build #413 of build-appliance is complete: Success [build successful] Build details are at
*** belen <belen!~Adium@> has quit IRC16:27
*** aehs29 <aehs29!aehernan@nat/intel/x-huorlpyipszfeiac> has joined #yocto16:36
*** paulg <paulg!~paulg@> has joined #yocto16:38
*** adelcast <adelcast!~adelcast@> has quit IRC16:39
*** adelcast <adelcast!~adelcast@> has joined #yocto16:40
otavioarfoll: what is the problem you are trying to fix? the javs should work out of box16:40
*** Jefro <Jefro!> has joined #yocto16:43
*** jbrianceau is now known as jbrianceau_away16:45
*** lordzen <lordzen!> has quit IRC16:46
*** skfax <skfax!c147b472@gateway/web/freenode/ip.> has joined #yocto16:49
*** zenx <zenx!~quassel@> has quit IRC16:59
*** jonathanmaw <jonathanmaw!> has quit IRC17:06
*** Biliogadafr <Biliogadafr!~User@> has joined #yocto17:09
*** Jefro <Jefro!> has quit IRC17:09
*** Biliogadafr1 <Biliogadafr1!~User@> has quit IRC17:10
*** lamego <lamego!~lamego@> has quit IRC17:12
*** lamego <lamego!lamego@nat/intel/x-dzqomiamjxrpfuln> has joined #yocto17:14
*** LocutusOfBorg1 <LocutusOfBorg1!> has quit IRC17:21
*** felipealmeida <felipealmeida!~felipealm@> has quit IRC17:22
*** pidge <pidge!~pidge@2a02:8084:0:3000:983d:44d9:bffd:929> has quit IRC17:34
*** berton <berton!~fabio@> has joined #yocto17:36
skfaxI'm attempting to create a package for use with meta-ros which encapsulates a catkin package. When I add my package to IMAGE_INSTALL in my image it install correctly; however when I try to install the generated RPMs directly it doesn't install the files I want17:40
skfaxIs there supposed to be a difference between using IMAGE_INSTALL and installing an rpm?17:40
bluelightningskfax: erm, definitely not17:41
bluelightningthat sounds very strange...17:42
*** madisox <madisox!> has quit IRC17:42
skfaxI tried to understand what goes into the install; is this determined by the FILES variable? The information put into it seems a bit weird:
skfax(I also tried to get one of their examples "chatter_talker" to install properly; however I have the same issue where using IMAGE_INSTALL works but the RPM does not)17:44
skfax3 RPMs are generated; release, debug and dev. They are very small and can be installed producing a few files - but not the actual application17:44
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:47
*** belen <belen!> has joined #yocto17:48
*** belen1 <belen1!> has joined #yocto17:50
*** belen <belen!> has quit IRC17:52
*** madisox <madisox!> has joined #yocto18:05
*** madisox <madisox!> has left #yocto18:05
*** hugovs <hugovs!~hugo@> has quit IRC18:16
*** ntl <ntl!> has quit IRC18:20
*** belen1 <belen1!> has quit IRC18:24
*** ntl <ntl!> has joined #yocto18:31
*** cference <cference!> has joined #yocto18:32
*** benjamirc <benjamirc!~besquive@> has quit IRC18:34
*** lamego <lamego!lamego@nat/intel/x-dzqomiamjxrpfuln> has quit IRC18:34
*** Jefro <Jefro!> has joined #yocto18:35
*** cference <cference!> has quit IRC18:37
*** belen <belen!> has joined #yocto18:40
*** berton <berton!~fabio@> has quit IRC18:42
*** belen <belen!> has quit IRC18:42
*** berton <berton!~fabio@> has joined #yocto18:43
fishey1Has anyone tried to use lto (link time optimization) on a yocto build yet? (I'm considering it)18:45
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has quit IRC18:46
*** Jefro <Jefro!> has quit IRC18:51
*** Biliogadafr <Biliogadafr!~User@> has quit IRC18:55
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC18:56
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto18:56
*** berton <berton!~fabio@> has quit IRC19:01
*** Jefro <Jefro!> has joined #yocto19:02
*** aehs29 <aehs29!aehernan@nat/intel/x-huorlpyipszfeiac> has left #yocto19:04
*** staylor_ <staylor_!> has joined #yocto19:12
*** staylor <staylor!> has quit IRC19:16
*** Jefro <Jefro!> has quit IRC19:21
*** Jefro <Jefro!> has joined #yocto19:21
*** Jefro <Jefro!> has quit IRC19:28
*** paulg <paulg!~paulg@> has quit IRC19:28
*** paulg <paulg!~paulg@> has joined #yocto19:30
*** Jefro <Jefro!> has joined #yocto19:32
*** Jefro <Jefro!> has quit IRC19:37
*** Jefro <Jefro!> has joined #yocto19:37
* kergoth wonders whether its most intuitive for deltask to also clear the task deps.. if you deltask and then re-addtask, does it keep its old task deps? I'm inclined to say no, it should start fresh19:48
*** zeddii <zeddii!~bruce@> has quit IRC19:49
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC19:52
*** Jefro <Jefro!> has quit IRC19:55
-YoctoAutoBuilder- build #423 of nightly-world is complete: Success [build successful] Build details are at
*** Jefro <Jefro!> has joined #yocto20:12
*** Jefro <Jefro!> has quit IRC20:19
*** behanw <behanw!~behanw@> has quit IRC20:19
*** Jefro <Jefro!> has joined #yocto20:26
*** grma <grma!> has joined #yocto20:30
*** Jefro <Jefro!> has quit IRC20:31
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto20:41
*** paulg <paulg!~paulg@> has quit IRC20:43
*** nighty^ <nighty^!> has quit IRC20:47
*** madisox <madisox!> has joined #yocto20:48
*** madisox <madisox!> has left #yocto20:48
*** behanw <behanw!~behanw@> has joined #yocto21:01
*** LocutusOfBorg1 <LocutusOfBorg1!> has joined #yocto21:03
*** Jefro <Jefro!> has joined #yocto21:03
-YoctoAutoBuilder- build #80 of nightly-rpm-non-rpm is complete: Failure [failed Running Sanity Tests] Build details are at
*** JaMa <JaMa!> has quit IRC21:11
*** tsramos <tsramos!~tsramos@> has quit IRC21:11
*** moto-timo <moto-timo!~timo@fsf/member/moto-timo> has quit IRC21:13
*** moto-timo <moto-timo!~timo@fsf/member/moto-timo> has joined #yocto21:21
-YoctoAutoBuilder- build #20 of nightly-qa-systemd-load is complete: Success [build successful] Build details are at
*** ant_home <ant_home!> has joined #yocto21:23
*** skfax <skfax!c147b472@gateway/web/freenode/ip.> has quit IRC21:54
-YoctoAutoBuilder- build #112 of nightly-oe-selftest is complete: Success [build successful] Build details are at
*** manuel_ <manuel_!~manuel@> has quit IRC21:57
*** LocutusOfBorg1 <LocutusOfBorg1!> has quit IRC21:58
*** bfederau <bfederau!> has quit IRC22:01
*** bfederau <bfederau!> has joined #yocto22:01
*** dfaught <dfaught!> has quit IRC22:12
*** ant_home <ant_home!> has quit IRC22:20
*** Jefro <Jefro!> has quit IRC22:31
*** Jefro <Jefro!> has joined #yocto22:45
*** Jefro <Jefro!> has joined #yocto22:52
*** Jefro <Jefro!> has joined #yocto22:53
*** paulg <paulg!> has joined #yocto22:58
*** Jefro <Jefro!> has quit IRC23:02
*** LocutusOfBorg1 <LocutusOfBorg1!~Gianfranc@> has joined #yocto23:05
-YoctoAutoBuilder- build #417 of nightly-qa-systemd is complete: Failure [failed Running Sanity Tests Running Sanity Tests_2] Build details are at
*** imrehg <imrehg!> has joined #yocto23:19
*** imrehg <imrehg!> has quit IRC23:23
*** dorileo <dorileo!~dorileo@> has quit IRC23:26
*** Jefro <Jefro!> has joined #yocto23:32
*** Jefro <Jefro!> has quit IRC23:35
*** Crofton|work <Crofton|work!> has quit IRC23:37
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC23:37
*** Crofton <Crofton!> has quit IRC23:37
*** bboozzoo <bboozzoo!> has quit IRC23:39
*** Jefro <Jefro!> has joined #yocto23:44
*** Crofton <Crofton!> has joined #yocto23:50
*** SoylentYellow <SoylentYellow!> has quit IRC23:50
*** Crofton|work <Crofton|work!> has joined #yocto23:50
*** Jefro <Jefro!> has quit IRC23:50
*** bboozzoo <bboozzoo!> has joined #yocto23:53
*** vmeson <vmeson!> has quit IRC23:56

Generated by 2.11.0 by Marius Gedminas - find it at!