Tuesday, 2015-12-15

*** ChrP <ChrP!2403659f@gateway/web/freenode/ip.36.3.101.159> has joined #yocto00:04
*** cbzx <cbzx!~cbzx@CPE0015f275ecd5-CM00195edd810c.cpe.net.cable.rogers.com> has quit IRC00:05
*** sameo <sameo!~samuel@192.55.54.40> has quit IRC00:07
*** madisox <madisox!~madison@216-75-232-11.static.wiline.com> has quit IRC00:17
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto00:23
*** paulg <paulg!~paulg@198-84-207-67.cpe.teksavvy.com> has quit IRC00:24
ChrPHello, is there someone in here who can help me with a problem I have while using bitbake to build Yocto?00:29
-YoctoAutoBuilder- build #573 of nightly-ppc is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-ppc/builds/57300:29
Crofton|workI suspect you are tryin gto build Poky with openEMbedded :)00:30
Crofton|workbut what exactly is the error?00:30
ChrPWell, the issue is, I'm trying to build it with dwarf 3 debugging info instead of dwarf 4, but I just cannot get it to compile with dwarf 300:31
ChrPit always ends up either failing or building with dwarf 400:31
Crofton|workhmm, I don't know much about that00:31
Crofton|workbut maybe someon eelse does00:31
ChrPhave been trying quite long already to get it to work, but without avail :(00:32
Crofton|workI've never even heard anyone ask that before00:33
* kergoth also knows nothing about changing the debugging info00:33
fledermausyou should probably open by saying what you did to try and get dwarf 3.00:33
* deviosity is glad I'm not the only one confused by this one.00:34
fledermausas it is you've only stated your aim, not what you actually did, and you may not be doing what you think you're trying to do, iyswim.00:34
ChrPsure, let me explain00:34
ChrPI've built the yocto project with the help of the quickstart, without any special adjustments and this build just fine, however, it builds with the use of dwarf 4 (seeing as that's the standard in gcc)00:36
ChrPto adjust this, I've looked around and some people suggested adding/changing flags in the bitbake.conf file, so that you tell the compiler to build with the dwarf 3 debugging info00:37
ChrPthese flags would be BUILD_CFLAGS, CFLAGS, TARGET_CFLAGS00:37
kergothto start with, you should never need to touch bitbake.conf, you can do everything from local.conf just fine. but tell us exactly what changes you made to those flags00:38
ChrPI added -gdwarf-300:38
kergoththere's no need to mess with the flags directly either00:39
kergothwe have a variable for this00:39
kergothDEBUG_FLAGS ?= "-g -feliminate-unused-debug-types"00:39
kergothjust set DEBUG_FLAGS in local.conf to whatever you want00:39
ChrPso, like DEBUG_FLAGS = "-gdwarf-3"?00:39
ChrPin local.conf?00:40
kergothyep00:41
ChrPsure, let me try that00:41
*** cbzx <cbzx!~cbzx@CPE0015f275ecd5-CM00195edd810c.cpe.net.cable.rogers.com> has joined #yocto00:43
ChrPmaybe silly question, but is there a way to quickly see that it works, without building entire yocto?00:44
fledermausbuild just one of the early recipes, I guess.00:44
ChrPsure, thanks in advance guys, if it works you'll be my heroes :D00:46
*** cbzx <cbzx!~cbzx@CPE0015f275ecd5-CM00195edd810c.cpe.net.cable.rogers.com> has quit IRC00:50
Crofton|workgood luck00:53
* armpit wonders if I would get reprimanded if I log a bug from OSS that contained the F word01:13
*** yann|work <yann|work!~yann@nan92-1-81-57-214-146.fbx.proxad.net> has quit IRC01:25
*** IvanSB <IvanSB!~IvanSB@host136-114-dynamic.54-79-r.retail.telecomitalia.it> has quit IRC01:33
-YoctoAutoBuilder- build #578 of nightly-arm is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-arm/builds/57801:38
*** nighty^ <nighty^!~nighty@q029220.ppp.asahi-net.or.jp> has joined #yocto01:41
*** fledermaus <fledermaus!~vivek@78.32.176.249> has quit IRC02:03
*** cbzx <cbzx!~cbzx@CPE0015f275ecd5-CM00195edd810c.cpe.net.cable.rogers.com> has joined #yocto02:05
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC02:10
*** cbzx <cbzx!~cbzx@CPE0015f275ecd5-CM00195edd810c.cpe.net.cable.rogers.com> has quit IRC02:11
*** khem` is now known as onoffon02:21
*** Crofton <Crofton!~balister@pool-108-44-110-59.ronkva.east.verizon.net> has joined #yocto02:32
*** cbzx <cbzx!~cbzx@CPE0015f275ecd5-CM00195edd810c.cpe.net.cable.rogers.com> has joined #yocto02:34
*** deviosity <deviosity!~deviosity@66.235.61.189> has quit IRC02:34
*** cbzx <cbzx!~cbzx@CPE0015f275ecd5-CM00195edd810c.cpe.net.cable.rogers.com> has quit IRC02:39
-YoctoAutoBuilder- build #577 of nightly-x86 is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/57702:47
*** rburton <rburton!~Adium@35.106.2.81.in-addr.arpa> has joined #yocto03:01
*** rburton <rburton!~Adium@35.106.2.81.in-addr.arpa> has quit IRC03:06
-YoctoAutoBuilder- build #559 of nightly-x32 is complete: Failure [failed BuildImages Running Sanity Tests Running Sanity Tests_1] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/55903:14
-YoctoAutoBuilder- build #213 of nightly-arm64 is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-arm64/builds/21303:23
-YoctoAutoBuilder- build #563 of nightly-fsl-arm-lsb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm-lsb/builds/56303:35
*** cjp256 <cjp256!~cjp256@chrispatterson.net> has quit IRC04:00
*** rburton <rburton!~Adium@35.106.2.81.in-addr.arpa> has joined #yocto04:02
*** hsychla <hsychla!~hsychla@pd95c9392.dip0.t-ipconnect.de> has quit IRC04:04
*** rburton <rburton!~Adium@35.106.2.81.in-addr.arpa> has quit IRC04:07
*** cbzx <cbzx!~cbzx@CPE0015f275ecd5-CM00195edd810c.cpe.net.cable.rogers.com> has joined #yocto04:09
*** hsychla <hsychla!~hsychla@pd95c9392.dip0.t-ipconnect.de> has joined #yocto04:11
*** Anarky <Anarky!~Anarky@2601:600:8a00:2f76:ba27:ebff:fe12:2a3> has quit IRC04:15
*** Anarky <Anarky!~Anarky@2601:600:8a00:2f76:ba27:ebff:fe12:2a3> has joined #yocto04:20
*** Anarky <Anarky!~Anarky@2601:600:8a00:2f76:ba27:ebff:fe12:2a3> has quit IRC04:24
-YoctoAutoBuilder- build #579 of nightly-x86-64-lsb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-lsb/builds/57904:24
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has joined #yocto04:26
*** dfrey <dfrey!~dfrey@d173-180-73-51.bchsia.telus.net> has joined #yocto04:29
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has quit IRC04:44
*** Anarky <Anarky!~Anarky@2601:600:8a00:2f76:ba27:ebff:fe12:2a3> has joined #yocto04:45
*** cbzx <cbzx!~cbzx@CPE0015f275ecd5-CM00195edd810c.cpe.net.cable.rogers.com> has quit IRC04:48
*** Cardoe <Cardoe!~Cardoe@gentoo/developer/Cardoe> has quit IRC04:49
*** jcreekmore <jcreekmore!~jcreekmor@2601:7c0:c300:dad6:21d:92ff:fef3:50e> has quit IRC04:49
*** Cardoe <Cardoe!~Cardoe@gentoo/developer/Cardoe> has joined #yocto04:55
*** jcreekmore <jcreekmore!~jcreekmor@2601:7c0:c300:dad6:21d:92ff:fef3:50e> has joined #yocto04:56
*** AndersD <AndersD!~anders@h83-209-191-235.dynamic.se.alltele.net> has joined #yocto05:06
*** hamis_lt_u <hamis_lt_u!~irfan@110.93.212.98> has joined #yocto05:12
*** pohly <pohly!~pohly@194.136.87.227> has joined #yocto05:30
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC05:39
*** rburton <rburton!~Adium@35.106.2.81.in-addr.arpa> has joined #yocto05:42
*** rburton <rburton!~Adium@35.106.2.81.in-addr.arpa> has quit IRC05:47
-YoctoAutoBuilder- build #552 of nightly-mips-lsb is complete: Failure [failed Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-mips-lsb/builds/55205:50
*** onoffon is now known as khem`05:54
*** pohly <pohly!~pohly@194.136.87.227> has quit IRC06:00
*** morphis <morphis!~morphis@pD9ED624C.dip0.t-ipconnect.de> has joined #yocto06:14
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC06:17
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto06:20
*** TobSnyder <TobSnyder!~schneider@ip923450f2.dynamic.kabel-deutschland.de> has joined #yocto06:30
*** tasslehoff <tasslehoff!~Tasslehof@77.40.182.98> has joined #yocto06:45
*** frsc <frsc!~frsc@80.149.173.67> has joined #yocto07:16
*** khem` is now known as onoffon07:16
*** frsc <frsc!~frsc@80.149.173.67> has joined #yocto07:16
*** ChrP <ChrP!2403659f@gateway/web/freenode/ip.36.3.101.159> has quit IRC07:33
-YoctoAutoBuilder- build #575 of nightly-multilib is complete: Failure [failed BuildImages_2 Running Sanity Tests_2 BuildImages_3 Running Sanity Tests_3 BuildImages_4] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/57507:34
*** rburton <rburton!~Adium@35.106.2.81.in-addr.arpa> has joined #yocto07:43
*** morphis <morphis!~morphis@pD9ED624C.dip0.t-ipconnect.de> has quit IRC07:46
*** morphis <morphis!~morphis@pD9ED624C.dip0.t-ipconnect.de> has joined #yocto07:47
*** rburton <rburton!~Adium@35.106.2.81.in-addr.arpa> has quit IRC07:47
*** csanchezdll <csanchezdll!~user@80.38.102.19> has joined #yocto07:49
*** yann|work <yann|work!~yann@nan92-1-81-57-214-146.fbx.proxad.net> has joined #yocto07:49
*** yann|work <yann|work!~yann@nan92-1-81-57-214-146.fbx.proxad.net> has quit IRC07:55
*** roccof <roccof!~roccof@93-51-177-218.ip268.fastwebnet.it> has joined #yocto07:55
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/irccloud.com/x-cykuikpgticyhkbw> has joined #yocto07:58
*** jbrianceau_away is now known as jbrianceau07:58
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto08:02
*** halstead <halstead!~halstead@crown.incitedev.com> has quit IRC08:05
*** townxelliot <townxelliot!~ell@176.251.193.69> has joined #yocto08:07
mrKongeWhat is the cleanest way to add a static ip to boot configuration? Should an existing recipe be appended, or should one create a recipe that installs a custom interfaces file?08:16
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-wqpwdazofmvglfzl> has joined #yocto08:17
*** toscalix <toscalix!~agustinbe@149.100.1.63> has joined #yocto08:19
-YoctoAutoBuilder- build #563 of nightly-fsl-arm is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm/builds/56308:22
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has joined #yocto08:23
frscmrKonge: use a bbappend for init-ifupdown recipe with your custom interfaces file. See for example: https://github.com/netmodule/meta-netmodule-extras/tree/master/recipes-core/init-ifupdown08:27
*** belen <belen!Adium@nat/intel/x-gmcgmigdwikouztd> has joined #yocto08:31
*** fl0v0 <fl0v0!~fvo@p54AF40B3.dip0.t-ipconnect.de> has joined #yocto08:31
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-wqpwdazofmvglfzl> has quit IRC08:32
*** rburton <rburton!~Adium@35.106.2.81.in-addr.arpa> has joined #yocto08:35
*** ant_work <ant_work!~ant__@95.232.250.89> has joined #yocto08:36
*** aragua <aragua!~flahouder@2a01:6600:8083:4700:60f6:a1ba:79e9:6fa2> has joined #yocto08:43
*** rburton <rburton!~Adium@35.106.2.81.in-addr.arpa> has joined #yocto08:47
*** ftonello <ftonello!~felipe@81.145.202.106> has joined #yocto08:49
*** vdehors <vdehors!~vdehors@193.56.60.161> has joined #yocto08:56
*** rob_w <rob_w!~bob@93.104.205.194> has joined #yocto09:03
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto09:03
*** yann|work <yann|work!~yann@LFbn-1-1026-146.w86-247.abo.wanadoo.fr> has joined #yocto09:03
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC09:04
*** jani_ is now known as jani09:12
*** IvanSB <IvanSB!~IvanSB@host136-114-dynamic.54-79-r.retail.telecomitalia.it> has joined #yocto09:14
*** seezer <seezer!quassel@quassel/developer/seezer> has quit IRC09:16
*** seezer <seezer!quassel@quassel/developer/seezer> has joined #yocto09:19
*** nighty^ <nighty^!~nighty@q029220.ppp.asahi-net.or.jp> has quit IRC09:19
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has quit IRC09:24
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has joined #yocto09:25
*** dv_ <dv_!~quassel@chello062178118086.5.14.vie.surfer.at> has quit IRC09:32
*** darkhorse_ <darkhorse_!3ebd1c82@gateway/web/freenode/ip.62.189.28.130> has quit IRC09:33
*** Antagonist <Antagonist!c5eac6a2@gateway/web/freenode/ip.197.234.198.162> has quit IRC09:33
*** CTtpollard <CTtpollard!~tom@82-70-136-246.dsl.in-addr.zen.co.uk> has quit IRC09:35
*** dv_ <dv_!~quassel@chello062178118086.5.14.vie.surfer.at> has joined #yocto09:35
*** CTtpollard <CTtpollard!~tom@82-70-136-246.dsl.in-addr.zen.co.uk> has joined #yocto09:37
*** sameo <sameo!~samuel@192.55.54.43> has joined #yocto09:43
*** DatGizmo <DatGizmo!~mogwai@ipbcc0d996.dynamic.kabel-deutschland.de> has joined #yocto09:51
*** edbart <edbart!~ebartosh@192.198.151.43> has joined #yocto09:51
DatGizmoMorning, does somebody have time to help me figure out why a kernel config option I wan't to disable is set back to 'y'?09:53
DatGizmoI see a message in the missing_required.cfg where it tells me that the 'Acural value set: "CONFIG_MXC_GPU_VIV=y"'09:54
DatGizmoBut I have no idea how to figure out, why the option is reenabled during the config step09:54
*** blitz00 <blitz00!stefans@nat/intel/x-xtafghghtxuaqhmr> has joined #yocto09:56
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto09:56
araguaDatGizmo, maybe another kernel features enabled depends on it09:57
araguawhat recipe, version do you use?09:58
DatGizmoaragua yocot is version 2.0, and our recipe is based on the linux-yocto.inc09:59
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-piizlqaxzlsrtoct> has joined #yocto09:59
DatGizmoaragua: My problem is, I have no idea how to find out which other config option need the one I want to disable10:00
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-piizlqaxzlsrtoct> has left #yocto10:00
*** fl0v0 <fl0v0!~fvo@p54AF40B3.dip0.t-ipconnect.de> has quit IRC10:00
*** fl0v0 <fl0v0!~fvo@p54AF4622.dip0.t-ipconnect.de> has joined #yocto10:00
araguatry bitbake -c menuconfig virtual/kernel and help give the dependencies10:01
*** jonathanmaw <jonathanmaw!~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk> has joined #yocto10:01
araguabut  if you disable the option , quit and then do bitbake -c diffconfig v/k then you must have a correct defconfig10:03
DatGizmoIn the help for MXC_GPU_VIV I only see, which dependencies this config option has. But I need to know wich other config options have MXC_GPU_VIV as a dependency.10:03
*** Crofton <Crofton!~balister@pool-108-44-110-59.ronkva.east.verizon.net> has quit IRC10:05
*** Crofton|work <Crofton|work!~balister@pool-108-44-110-59.ronkva.east.verizon.net> has quit IRC10:05
*** mntpellier <mntpellier!~mntpellie@162.38.213.240> has joined #yocto10:05
araguaok and if you search for MXC_GPU_VIV , all features depending on it should be displayed10:07
DatGizmowired... the search has only the config option as a result...10:10
araguaarf10:10
araguaok10:10
araguado you use a standard defconfig or a custom10:11
DatGizmoIn the recipe I use KCONFIG_MODE="--alldefconfig" and KBUILD_DEFCONFIG_mx6 ?= "imx_v6_v7_defconfig"10:12
DatGizmoAnd some config fragments to en/disable specific config options10:13
araguadid you verifiy with bitbake -e v/k that your fragment is used?10:14
DatGizmoyes, it is used, another option i'm disabeling in the fragment works just fine.10:15
*** IvanSB <IvanSB!~IvanSB@host136-114-dynamic.54-79-r.retail.telecomitalia.it> has quit IRC10:17
DatGizmooh I don't belive it... the config option is hard set to 'y' in a classfile in another layer I need to use.10:24
*** morphis <morphis!~morphis@pD9ED624C.dip0.t-ipconnect.de> has quit IRC10:24
*** morphis <morphis!~morphis@pD9ED624C.dip0.t-ipconnect.de> has joined #yocto10:24
*** Guest67223 <Guest67223!~quassel@106.120.101.38> has quit IRC10:25
araguathis is the drawback of the concept10:25
*** Jackie <Jackie!~quassel@106.120.101.38> has joined #yocto10:25
DatGizmoat least I know now why the option keept setting back to y.10:25
*** Jackie is now known as Guest2621210:25
DatGizmoaragua: thanks for your help :)10:25
*** IvanSB <IvanSB!~IvanSB@host136-114-dynamic.54-79-r.retail.telecomitalia.it> has joined #yocto10:28
*** Crofton <Crofton!~balister@pool-108-44-110-59.ronkva.east.verizon.net> has joined #yocto10:36
*** Crofton|work <Crofton|work!~balister@pool-108-44-110-59.ronkva.east.verizon.net> has joined #yocto10:36
janisorry if this is too noobish question but im getting "no such file or directory" when i tried run some binaries on jetson pro running on yocto/genivi. Binary is compiled with proper arch, no libraries missing reported ldd either from the actual binary and from 3rd party libs the binaries depend on ..10:40
*** ilgios <ilgios!4f3cd6e2@gateway/web/cgi-irc/kiwiirc.com/ip.79.60.214.226> has joined #yocto10:40
ilgioshi everybody10:40
ilgioscan someone help me? i'm looking for a nagios recipes for dizzy10:41
ilgiosi googled with unsuccess10:41
*** belen <belen!Adium@nat/intel/x-gmcgmigdwikouztd> has quit IRC10:43
*** belen <belen!Adium@nat/intel/x-bryauksyldrjcmnw> has joined #yocto10:46
*** RzR <RzR!~RzR@82.236.136.171> has joined #yocto10:53
*** RzR <RzR!~RzR@82.236.136.171> has quit IRC10:54
*** RzR <RzR!~RzR@unaffiliated/rzr> has joined #yocto10:54
araguamaybe try https://github.com/redoop/meta-redoop/tree/master/recipes-monitoring/nagios11:01
araguaand adapt depending on issue11:01
araguailgios, ^11:01
araguajani, can you be more precise about what do you do to have this error11:02
ilgiosthanks, aragua. i try11:03
janiaragua: solved it .. i was trying to run a binary - found a reason, it was compiled with sfp, not hf.11:06
*** anselmolsm <anselmolsm!~anselmols@192.55.54.43> has quit IRC11:10
*** IvanSB <IvanSB!~IvanSB@host136-114-dynamic.54-79-r.retail.telecomitalia.it> has quit IRC11:11
*** jonathanmaw_ <jonathanmaw_!~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk> has joined #yocto11:13
*** jonathanmaw <jonathanmaw!~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk> has quit IRC11:17
*** maxin <maxin!~maxin@2001:998:22:0:fd29:df50:bf9d:84f4> has joined #yocto11:22
*** nighty^ <nighty^!~nighty@q029220.ppp.asahi-net.or.jp> has joined #yocto11:24
*** Anarky <Anarky!~Anarky@2601:600:8a00:2f76:ba27:ebff:fe12:2a3> has quit IRC11:26
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has joined #yocto11:27
*** JaMa <JaMa!~martin@ip-86-49-34-37.net.upcbroadband.cz> has joined #yocto11:29
*** jonathanmaw_ <jonathanmaw_!~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk> has quit IRC11:31
*** edbart <edbart!~ebartosh@192.198.151.43> has quit IRC11:32
*** ftonello <ftonello!~felipe@81.145.202.106> has quit IRC11:39
*** edbart <edbart!~ebartosh@192.198.151.45> has joined #yocto11:40
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has quit IRC11:46
*** ant_work <ant_work!~ant__@95.232.250.89> has quit IRC11:48
*** anselmolsm <anselmolsm!~anselmols@192.55.54.40> has joined #yocto11:49
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:51
*** Antagonist <Antagonist!~Charl@197.234.198.162> has joined #yocto11:57
Antagonist| /home/charl/workspace/fsl-community-bsp/build-ar6mxq/tmp/work-shared/gcc-4.9.2-r0/gcc-4.9.2/libgfortran/../libgcc/gthr.h:148:26: fatal error: gthr-default.h: No such file or directory << Anyone know why 'bitbake libgfortran' fails? Using fido11:57
*** ftonello <ftonello!~felipe@81.145.202.106> has joined #yocto12:03
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has joined #yocto12:03
Antagonistgthr-default.h exists in tmp/work and in the sysroot, so its not like it doesn't exist12:12
AntagonistIs there any nice hack to add a -Ifolder into a .bbappend?12:13
*** ant_work <ant_work!~ant__@95.232.250.89> has joined #yocto12:22
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has quit IRC12:27
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has joined #yocto12:28
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC12:31
*** rob_w <rob_w!~bob@93.104.205.194> has joined #yocto12:31
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto12:31
-YoctoAutoBuilder- build #548 of nightly-arm-lsb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-arm-lsb/builds/54812:32
*** fledermaus <fledermaus!~vivek@pakora.collabora.co.uk> has joined #yocto12:35
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has quit IRC12:40
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has joined #yocto12:40
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has quit IRC12:44
*** cbzx <cbzx!~cbzx@CPE0015f275ecd5-CM00195edd810c.cpe.net.cable.rogers.com> has joined #yocto12:45
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has joined #yocto12:45
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has quit IRC12:50
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has joined #yocto12:52
sujith_hThere is a comment I read in bb/server/xmlrpc.py "# we don't allow connections if the cooker is running "12:53
sujith_hIs there any issue if we allow connections when cooker is running?12:53
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has quit IRC12:56
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has joined #yocto12:57
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has quit IRC13:01
*** vmeson <vmeson!~rmacleod@24-212-184-107.cable.teksavvy.com> has quit IRC13:01
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has joined #yocto13:02
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has left #yocto13:03
*** hugovs <hugovs!~hugo@189.112.127.225> has joined #yocto13:04
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has quit IRC13:11
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has joined #yocto13:12
*** jonathanmaw <jonathanmaw!~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk> has joined #yocto13:12
*** cbzx <cbzx!~cbzx@CPE0015f275ecd5-CM00195edd810c.cpe.net.cable.rogers.com> has quit IRC13:13
*** Anarky <Anarky!~Anarky@c-73-169-244-174.hsd1.wa.comcast.net> has quit IRC13:16
*** pohly <pohly!~pohly@2001:998:22:0:ea2a:eaff:fe1f:16f2> has joined #yocto13:17
*** Anarky <Anarky!~Anarky@2601:600:8a00:2f76:ba27:ebff:fe12:2a3> has joined #yocto13:17
*** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto13:25
*** maxin <maxin!~maxin@2001:998:22:0:fd29:df50:bf9d:84f4> has quit IRC13:31
*** pohly <pohly!~pohly@2001:998:22:0:ea2a:eaff:fe1f:16f2> has quit IRC13:31
*** PaowZ_ <PaowZ_!~vince@94.103.130.217> has joined #yocto13:34
PaowZ_hi there ! Regarding BB_NUMBER_THREADS and PARALLEL_MAKE, are these values to be set in local.conf ?13:36
*** IvanSB <IvanSB!~IvanSB@host136-114-dynamic.54-79-r.retail.telecomitalia.it> has joined #yocto13:37
*** belen <belen!Adium@nat/intel/x-bryauksyldrjcmnw> has quit IRC13:38
*** ftonello <ftonello!~felipe@81.145.202.106> has quit IRC13:38
CTtpollardPaowZ_: you can yes13:39
*** belen <belen!Adium@nat/intel/x-glodmminjzaopggl> has joined #yocto13:40
PaowZ_CTtpollard: thks.13:42
*** blueness_ <blueness_!~blueness@cpe-74-77-145-97.buffalo.res.rr.com> has quit IRC13:49
*** blueness_ <blueness_!~blueness@gentoo/developer/blueness> has joined #yocto13:49
*** hamis_lt_u <hamis_lt_u!~irfan@110.93.212.98> has quit IRC13:54
*** ftonello <ftonello!~felipe@81.145.202.106> has joined #yocto14:04
*** hugovs_ <hugovs_!~hugo@177.159.144.73> has joined #yocto14:05
sujith_hPaowZ_: I was wondering the reason for that. Just asking :)14:08
*** hugovs <hugovs!~hugo@189.112.127.225> has quit IRC14:08
PaowZ_sujith_h: regarding what ? the use of these defines or where to add them ?14:09
t0mmy114:12
sujith_hI was trying to use xmlrc.py's connect function ( In class BitBakeXMLRPCServerConnection) which was failing. Debugging a bit I found that its because of the if condition in registerEventHandler14:12
*** aime-Pierre <aime-Pierre!~Thunderbi@193.56.60.161> has joined #yocto14:13
*** pohly <pohly!~pohly@2001:998:22:0:ea2a:eaff:fe1f:16f2> has joined #yocto14:15
RPsujith_h: "running" is a cooker state where a build is in progress14:16
RPsujith_h: it doesn't make sense to allow more connections once something is in progress like that14:16
*** belen <belen!Adium@nat/intel/x-glodmminjzaopggl> has quit IRC14:16
RPsujith_h: This is related to memory resident bitbake where you wouldn't want to allow knotty to connect to the same server multiple times and try and control it. We did start to create the notion of a read only connection but that work is only partially developed iirc. What issue are you seeing more specifically?14:17
sujith_hRP: I am trying to implement cancellation of build from toaster. While doing so, when I call the connect function from class BitBakeXMLRPCServerConnection, it was causing me trouble in registering event handler14:20
RPsujith_h: doesn't toaster have an open command channel to the build that is running?14:20
RPsujith_h: or are you saying toaster drops that connection once it starts the build?14:20
Crofton|workzeddii, you awake?14:22
*** pohly <pohly!~pohly@2001:998:22:0:ea2a:eaff:fe1f:16f2> has quit IRC14:22
sujith_hRP: Toaster doesn't drop the connection. I was getting exception when I call establishConnection function which eventually calls connect and registerEventHandle. So I started wondering how to pass runCommand(["stateForceShutdown"]) to stop bitbake server14:24
*** edbart <edbart!~ebartosh@192.198.151.45> has quit IRC14:24
RPsujith_h: how did toaster start the build?14:25
sujith_hRP: it starts by executing command : bash -c 'source /home/sujith/build/poky-contrib/bitbake/bin/toaster restart-bitbake'14:26
RPsujith_h: that is pretty horrible :(14:27
RPsujith_h: so I'm guessing that starts bitbake using knotty as the controlling UI behind the scenes?14:27
*** lamego <lamego!~jose@134.134.139.76> has joined #yocto14:29
sujith_hRP: I am not that sure about that.. :(14:29
*** morphis <morphis!~morphis@pD9ED624C.dip0.t-ipconnect.de> has quit IRC14:29
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-andfpglwsdwxgqpm> has joined #yocto14:30
*** morphis <morphis!~morphis@2001:67c:1560:8007::aac:c152> has joined #yocto14:30
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-andfpglwsdwxgqpm> has left #yocto14:30
-YoctoAutoBuilder- build #553 of nightly-mips-lsb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-mips-lsb/builds/55314:31
RPsujith_h: I think we may need to enhance the code in bitbake to allow "take over" of a cooker instance if there are only readonly UIs connected, then make knotty connect as a read only UI14:33
*** AndersD <AndersD!~anders@h83-209-191-235.dynamic.se.alltele.net> has quit IRC14:34
sujith_hRP: ok14:36
*** pidge <pidge!~pidge@2a02:8084:0:3000:f17b:53b5:54d:bf4e> has joined #yocto14:40
*** Antagonist <Antagonist!~Charl@197.234.198.162> has quit IRC14:41
*** sameo <sameo!~samuel@192.55.54.43> has quit IRC14:49
*** hugovs_ <hugovs_!~hugo@177.159.144.73> has quit IRC14:54
*** hugovs <hugovs!~hugo@189.112.127.225> has joined #yocto14:54
*** kspr <kspr!~Kasper@193.104.83.223> has quit IRC14:55
*** dv_ <dv_!~quassel@chello062178118086.5.14.vie.surfer.at> has quit IRC14:56
*** dv_ <dv_!~quassel@chello062178118086.5.14.vie.surfer.at> has joined #yocto14:58
*** hugovs <hugovs!~hugo@189.112.127.225> has quit IRC14:59
*** hugovs <hugovs!~hugo@177.159.144.73> has joined #yocto14:59
*** IvanSB <IvanSB!~IvanSB@host136-114-dynamic.54-79-r.retail.telecomitalia.it> has quit IRC15:01
*** ls <ls!~ls@ns376889.ip-5-196-95.eu> has quit IRC15:01
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC15:01
*** focus <focus!~Doug@164.39.177.154> has quit IRC15:07
*** hugovs <hugovs!~hugo@177.159.144.73> has quit IRC15:09
*** onoffon <onoffon!~khem@unaffiliated/khem> has quit IRC15:11
*** hugovs <hugovs!~hugo@189.112.127.225> has joined #yocto15:11
*** sameo <sameo!~samuel@192.55.54.36> has joined #yocto15:12
*** focus <focus!~Doug@164.39.177.154> has joined #yocto15:13
*** raykinsella78 <raykinsella78!~rkinsell@192.198.151.43> has joined #yocto15:14
*** hugovs_ <hugovs_!~hugo@189.112.127.225> has joined #yocto15:20
*** hugovs <hugovs!~hugo@189.112.127.225> has quit IRC15:24
*** madisox <madisox!~madison@12.30.244.5> has joined #yocto15:24
*** mrKonge <mrKonge!~andreas@46.19.18.122> has quit IRC15:27
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto15:28
*** raykinsella78 <raykinsella78!~rkinsell@192.198.151.43> has quit IRC15:29
*** challinan <challinan!~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has quit IRC15:32
*** frsc <frsc!~frsc@80.149.173.67> has quit IRC15:37
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto15:38
*** sjolley <sjolley!~sjolley@134.134.139.70> has quit IRC15:43
-YoctoAutoBuilder- build #285 of nightly-world-lsb is complete: Failure [failed Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-world-lsb/builds/28515:44
*** tasslehoff <tasslehoff!~Tasslehof@77.40.182.98> has quit IRC15:45
*** roccof <roccof!~roccof@93-51-177-218.ip268.fastwebnet.it> has quit IRC15:53
*** khem` is now known as onoffon15:53
*** challinan <challinan!~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has joined #yocto15:56
*** aehs29 <aehs29!aehernan@nat/intel/x-grbisevkxizulrfm> has joined #yocto16:04
*** TobSnyder <TobSnyder!~schneider@ip923450f2.dynamic.kabel-deutschland.de> has quit IRC16:07
*** challinan <challinan!~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has quit IRC16:07
*** challinan <challinan!~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has joined #yocto16:07
*** challinan <challinan!~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has joined #yocto16:12
*** hugovs_ <hugovs_!~hugo@189.112.127.225> has quit IRC16:13
-YoctoAutoBuilder- build #567 of nightly-world is complete: Failure [failed Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/56716:14
*** challinan <challinan!~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has quit IRC16:16
*** challinan <challinan!~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has joined #yocto16:16
*** onoffon is now known as khem`16:16
*** mrKonge <mrKonge!~andreas@46.19.18.114> has joined #yocto16:18
*** dvhart <dvhart!dvhart@nat/intel/x-plgyvjldtkaptffg> has joined #yocto16:19
*** csanchezdll <csanchezdll!~user@80.38.102.19> has quit IRC16:25
*** cbzx <cbzx!~cbzx@CPE0015f275ecd5-CM00195edd810c.cpe.net.cable.rogers.com> has joined #yocto16:37
*** khem` is now known as onoffon16:42
*** ant_work <ant_work!~ant__@95.232.250.89> has quit IRC16:44
*** sjolley <sjolley!sjolley@nat/intel/x-umuknkivyxvwfjvb> has joined #yocto16:46
*** cristianiorga <cristianiorga!~cristiani@134.134.137.75> has quit IRC16:46
*** onoffon is now known as khem`16:47
*** sce <sce!~sce@connected-labs-gw1.ter2.neodc.mpl.cust.as8218.eu> has quit IRC16:48
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto16:50
*** sno <sno!~sno@p578b540c.dip0.t-ipconnect.de> has quit IRC16:50
*** Aethenelle <Aethenelle!~Aethenell@199.15.128.78> has joined #yocto16:50
*** Snert__ <Snert__!~snert_@69-161-21-126.static.acsalaska.net> has joined #yocto16:56
*** sno <sno!~sno@p578b540c.dip0.t-ipconnect.de> has joined #yocto16:56
*** pidge <pidge!~pidge@2a02:8084:0:3000:f17b:53b5:54d:bf4e> has quit IRC16:57
*** pohly <pohly!~pohly@194.136.87.227> has joined #yocto16:58
*** aehs29 <aehs29!aehernan@nat/intel/x-grbisevkxizulrfm> has left #yocto16:59
*** mntpellier <mntpellier!~mntpellie@162.38.213.240> has quit IRC17:03
*** yann|work <yann|work!~yann@LFbn-1-1026-146.w86-247.abo.wanadoo.fr> has quit IRC17:11
*** benjamirc <benjamirc!~besquive@134.134.137.71> has joined #yocto17:12
*** sno <sno!~sno@p578b540c.dip0.t-ipconnect.de> has quit IRC17:13
*** matteo <matteo!~matteo@openwrt/developer/matteo> has quit IRC17:14
*** Snert__ <Snert__!~snert_@69-161-21-126.static.acsalaska.net> has quit IRC17:20
*** deviosity <deviosity!~deviosity@66.235.61.189> has joined #yocto17:21
*** fl0v0 <fl0v0!~fvo@p54AF4622.dip0.t-ipconnect.de> has quit IRC17:23
-YoctoAutoBuilder- build #566 of nightly-non-gpl3 is complete: Failure [failed BuildImages] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-non-gpl3/builds/56617:24
-YoctoAutoBuilder- build #572 of poky-tiny is complete: Failure [failed BuildImages Publishing Layer Tarballs] Build details are at http://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/57217:24
-YoctoAutoBuilder- build #217 of ptest-x86-64 is complete: Failure [failed BuildImages Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org/main/builders/ptest-x86-64/builds/21717:24
-YoctoAutoBuilder- build #556 of build-appliance is complete: Failure [failed BuildImages BuildImages_1 Publishing Layer Tarballs] Build details are at http://autobuilder.yoctoproject.org/main/builders/build-appliance/builds/55617:25
-YoctoAutoBuilder- build #555 of buildtools is complete: Failure [failed BuildImages Publishing Layer Tarballs] Build details are at http://autobuilder.yoctoproject.org/main/builders/buildtools/builds/55517:25
-YoctoAutoBuilder- build #555 of nightly-qa-extras is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Running Sanity Tests_1] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-qa-extras/builds/55517:25
-YoctoAutoBuilder- build #218 of ptest-x86 is complete: Failure [failed BuildImages Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org/main/builders/ptest-x86/builds/21817:25
-YoctoAutoBuilder- build #115 of nightly-wic is complete: Failure [failed BuildImages BuildImages_1 CreateWicImages CreateWicImages_1 BuildImages_2 BuildImages_3 CreateWicImages_2 CreateWicImages_3] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-wic/builds/11517:26
-YoctoAutoBuilder- build #561 of nightly-qa-pam is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-qa-pam/builds/56117:26
-YoctoAutoBuilder- build #562 of nightly-oecore is complete: Failure [failed BuildImages Running Sanity Tests Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-oecore/builds/56217:26
*** armpit <armpit!~akuster@2601:202:4000:1239:b850:fd27:ad42:7471> has quit IRC17:26
-YoctoAutoBuilder- build #559 of nightly-qa-logrotate is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-qa-logrotate/builds/55917:27
-YoctoAutoBuilder- build #560 of nightly-qa-skeleton is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-qa-skeleton/builds/56017:27
-YoctoAutoBuilder- build #563 of nightly-qa-systemd is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Running Sanity Tests_1 BuildImages_2 Running Sanity Tests_2] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-qa-systemd/builds/56317:28
*** belen1 <belen1!Adium@nat/intel/x-rlgarxcfqukncoii> has joined #yocto17:28
-YoctoAutoBuilder- build #578 of nightly-x86-64 is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 Running SDK Sanity Tests_1 Publishing Layer Tarballs] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-x86-64/builds/57817:28
-YoctoAutoBuilder- build #575 of nightly-ppc is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 Running SDK Sanity Tests_1 Publishing Layer Tarballs] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-ppc/builds/57517:29
-YoctoAutoBuilder- build #580 of nightly-arm is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 Running SDK Sanity Tests_1 Publishing Layer Tarballs] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-arm/builds/58017:29
-YoctoAutoBuilder- build #581 of nightly-x86-64-lsb is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Publishing Layer Tarballs Publishing Layer Tarballs_1 Publishing Layer Tarballs_2] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-lsb/builds/58117:29
-YoctoAutoBuilder- build #216 of nightly-mips64 is complete: Failure [failed BuildImages Running Sanity Tests Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 Running SDK Sanity Tests_1 Publishing Layer Tarballs] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-mips64/builds/21617:29
-YoctoAutoBuilder- build #565 of nightly-fsl-arm-lsb is complete: Failure [failed BuildImages BuildImages_1 BuildImages_2 Publishing Layer Tarballs Publishing Layer Tarballs_1 Publishing Layer Tarballs_2 Publishing Layer Tarballs_3] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm-lsb/builds/56517:29
-YoctoAutoBuilder- build #221 of nightly-rpm-non-rpm is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-rpm-non-rpm/builds/22117:30
-YoctoAutoBuilder- build #224 of nightly-deb-non-deb is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-deb-non-deb/builds/22417:30
-YoctoAutoBuilder- build #541 of nightly-deb is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-deb/builds/54117:30
-YoctoAutoBuilder- build #567 of nightly-x86-lsb is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Publishing Layer Tarballs Publishing Layer Tarballs_1 Publishing Layer Tarballs_2] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-x86-lsb/builds/56717:31
-YoctoAutoBuilder- build #555 of nightly-ipk is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-ipk/builds/55517:31
-YoctoAutoBuilder- build #550 of nightly-rpm is complete: Failure [failed BuildImages Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-rpm/builds/55017:31
-YoctoAutoBuilder- build #558 of nightly-ppc-lsb is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Publishing Layer Tarballs Publishing Layer Tarballs_1 Publishing Layer Tarballs_2] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/builds/55817:31
-YoctoAutoBuilder- build #565 of nightly-fsl-arm is complete: Failure [failed BuildImages Building Toolchain Images Building Toolchain Images_1 BuildImages_1 BuildImages_2 Publishing Layer Tarballs Publishing Layer Tarballs_1] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm/builds/56517:31
-YoctoAutoBuilder- build #571 of eclipse-plugin-kepler is complete: Failure [failed Publishing Layer Tarballs Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org/main/builders/eclipse-plugin-kepler/builds/57117:31
-YoctoAutoBuilder- build #579 of nightly-x86 is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 Running SDK Sanity Tests_1 Publishing Layer Tarballs] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/57917:32
-YoctoAutoBuilder- build #549 of nightly-arm-lsb is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Publishing Layer Tarballs Publishing Layer Tarballs_1 Publishing Layer Tarballs_2] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-arm-lsb/builds/54917:32
-YoctoAutoBuilder- build #167 of eclipse-plugin-mars is complete: Failure [failed Publishing Layer Tarballs Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org/main/builders/eclipse-plugin-mars/builds/16717:33
-YoctoAutoBuilder- build #554 of nightly-mips-lsb is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Publishing Layer Tarballs Publishing Layer Tarballs_1 Publishing Layer Tarballs_2] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-mips-lsb/builds/55417:33
-YoctoAutoBuilder- build #215 of nightly-arm64 is complete: Failure [failed BuildImages Running Sanity Tests Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 Running SDK Sanity Tests_1 Publishing Layer Tarballs] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-arm64/builds/21517:33
-YoctoAutoBuilder- build #339 of eclipse-plugin-luna is complete: Failure [failed Publishing Layer Tarballs Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org/main/builders/eclipse-plugin-luna/builds/33917:33
*** belen1 <belen1!Adium@nat/intel/x-rlgarxcfqukncoii> has quit IRC17:34
-YoctoAutoBuilder- build #569 of nightly-mips is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 Running SDK Sanity Tests_1 Publishing Layer Tarballs] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-mips/builds/56917:35
*** karobar <karobar!4432d82d@gateway/web/freenode/ip.68.50.216.45> has joined #yocto17:38
*** jbrianceau is now known as jbrianceau_away17:42
*** halstead <halstead!~halstead@drupal.org/user/301087/view> has joined #yocto17:43
*** Biliogadafr <Biliogadafr!~User@62.214.49.206> has quit IRC17:43
*** Biliogadafr <Biliogadafr!~User@62.214.49.206> has joined #yocto17:44
*** Biliogadafr <Biliogadafr!~User@62.214.49.206> has quit IRC17:48
*** aehs29 <aehs29!~aehernan@134.134.139.77> has joined #yocto17:50
RPhalstead: autobuilder looks like it has diskspace issues17:53
halsteadRP, I cleared space and messages Ross who started the last build.17:54
RPhalstead: thanks!17:55
halsteadThank you.17:55
RPhalstead: he's afk but I'll restart17:55
JaMahalstead: any update on openembedded-commits ML?17:59
*** obsrwr <obsrwr!~obsrwr@188.24.254.35> has joined #yocto18:01
halsteadJaMa, I think there are newer hooks to accomplish our goals with that. I'll switch and ask for your help testing. I don't want to leave it broken again.18:01
*** berton <berton!~fabio@177.220.212.62> has joined #yocto18:01
*** sno <sno!~sno@static-87-79-200-121.netcologne.de> has joined #yocto18:03
*** cbzx <cbzx!~cbzx@CPE0015f275ecd5-CM00195edd810c.cpe.net.cable.rogers.com> has quit IRC18:03
JaMahalstead: ok, thanks18:05
*** jonathanmaw <jonathanmaw!~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk> has quit IRC18:05
*** cbzx <cbzx!~cbzx@CPE0015f275ecd5-CM00195edd810c.cpe.net.cable.rogers.com> has joined #yocto18:06
*** toscalix <toscalix!~agustinbe@149.100.1.63> has quit IRC18:14
*** moto-timo <moto-timo!~timo@fsf/member/moto-timo> has quit IRC18:14
*** berton <berton!~fabio@177.220.212.62> has quit IRC18:14
Anarkyso about the problems I had with libdrm, now it is fixed when I use the Arago build environment18:16
AnarkyBut now I have a problem with omapdrm-pvr and functions not defined in the kernel, can I get help here or should I write on Arago's mailing list?18:16
*** berton <berton!~fabio@177.220.212.62> has joined #yocto18:20
denixAnarky: SGX driver (omapdrm-pvr) is quite fragile and is currently in a transitional stage to get unified across our platforms. at the moment it requires specific kernel version.18:23
denixAnarky: you can get more info on meta-ti list, if interested18:23
Anarkydenix: thank you for the information; so as of now, is it possible to have Qt5 (or kmscube) working for a TI A15 board?18:27
Anarkydenix: I have a lot of errors if I try to start kmscube, even pvrsrvinit doesn't seem to work18:28
*** belen1 <belen1!Adium@nat/intel/x-nuahcbasxttizwpv> has joined #yocto18:28
tripzerowhy can't I menuconfig uclibc ? ERROR: uclibc was skipped: incompatible with host18:30
denixAnarky: yes, Qt5 and kmscube work just fine on X15 platform - all that is part of our product offering18:30
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has quit IRC18:30
*** townxelliot <townxelliot!~ell@176.251.193.69> has quit IRC18:31
denixAnarky: please send your specific errors to meta-ti list - we may be able to help you18:31
*** paulg <paulg!~paulg@184-94-55-234.dedicated.allstream.net> has joined #yocto18:38
Anarkydenix: oh, are you talking about the BeagleBord X15? I have both but I was trying with the OMAP5432 uEVM (A15)18:43
denixAnarky: ah, haven't tried that on uEVM lately, but in general it should work18:45
Anarkydenix: ok, I'm trying with the X15 and will post the results18:46
*** cbzx <cbzx!~cbzx@CPE0015f275ecd5-CM00195edd810c.cpe.net.cable.rogers.com> has quit IRC18:47
Anarkydenix: just to be sure, omapdrm-pvr and pvrsrvinit are necessary to load/start to get kmscube working?18:48
denixyes18:48
*** belen1 <belen1!Adium@nat/intel/x-nuahcbasxttizwpv> has quit IRC18:54
*** soderstrom <soderstrom!~soderstro@c-608be555.015-59-6c6b7013.cust.bredbandsbolaget.se> has joined #yocto18:56
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has quit IRC18:59
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has joined #yocto19:02
*** fledermaus <fledermaus!~vivek@pakora.collabora.co.uk> has quit IRC19:20
*** armpit <armpit!~akuster@64.2.3.194> has joined #yocto19:21
denixshould DEPENDS="virtual/kernel" cause the package to rebuild between machines?19:27
*** sameo <sameo!~samuel@192.55.54.36> has quit IRC19:33
*** madisox <madisox!~madison@12.30.244.5> has quit IRC19:34
*** berton_ <berton_!~fabio@201.22.227.56> has joined #yocto19:35
*** berton <berton!~fabio@177.220.212.62> has quit IRC19:35
*** JaMa <JaMa!~martin@ip-86-49-34-37.net.upcbroadband.cz> has quit IRC19:37
*** bluelightning <bluelightning!~paul@125-239-159-60.jetstream.xtra.co.nz> has joined #yocto19:37
*** bluelightning <bluelightning!~paul@125-239-159-60.jetstream.xtra.co.nz> has quit IRC19:37
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:37
bluelightningmorning all19:38
denixbluelightning: NZ morning? :)19:39
bluelightningdenix: indeed, but also UGT ;)19:39
denixbluelightning: ah, right :)19:40
denixbluelightning: maybe you know the answer - should DEPENDS="virtual/kernel" cause the package to rebuild between machines?19:41
bluelightningdenix: it should I believe, are you finding it is or isn't?19:42
denixbluelightning: it does. but then shouldn't all packages that depend on virtual/kernel be semi-automatically marked as machine-specific (PACKAGE_ARCH=MACHINE_ARCH)?19:45
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/irccloud.com/x-cykuikpgticyhkbw> has quit IRC19:45
bluelightningI don't think we have that functionality, though we probably ought to19:45
*** cbzx <cbzx!~cbzx@99.224.129.102> has joined #yocto19:46
bluelightningIIRC that only happens automatically through machine-specific FILESOVERRIDES and SRC_URI19:46
deviosityIs it possible to specify a different virtual/kernel recipe via an image recipe, or am I only stuck defining that in a machine definition?19:46
bluelightningdeviosity: I'm afraid that needs to be specified at the configuration level; the image cannot affect anything within other recipes - it only chooses the composition of the image19:47
denixbluelightning: ok, I didn't mean to do it automatically, but in general, that's the correct way, right? should then recipes (such as ipsec-tools from meta-oe) be updated to make them machine-specific?19:47
deviosityso either local.conf or via machine? Or is there another method I am missing19:48
kergothdeviosity: there's effectively no difference from bitbake's perspective between local.conf and the machine. it's set in the configuration metadata either way19:48
kergothlocal.conf and ${MACHINE}.conf are both included by bitbake.conf19:48
kergothas bluelightning says, that's where it has to be set, at the configuration level19:49
bluelightningdenix: possibly yes - I do think we ought to have a wider look at this whole problem; ideally we wouldn't have to go around being explicit about PACKAGE_ARCH (and silly things like python recipes being arch-specific purely because they depend on python)19:49
deviositybasically I need to maintain two different images, but they need different kernels due to differing functionality.19:49
kergoththen you'll need two machines19:50
bluelightningmultiple kernel support is being discussed on the mailing list right now, as it happens19:50
denixdeception: either 2 machine configs or build in separate work directories and switch preferred provider19:50
kergothon an unrelated note, I threw together this prototype of something, but I can't decide if it's actually of any real use: https://github.com/kergoth/meta-named-configs-prototype#ii-usage, https://github.com/kergoth/meta-named-configs-prototype/blob/master/recipes-core/busybox/busybox_1.23.2.bbappend19:50
deviositythat's what I thought, I was hoping there may have been some hidden secret somewhere.19:50
bluelightningunfortunately it's rather complicated; just one issue is that there are lots of things that depend on files from the kernel in the sysroot - and which kernel should be used for that when there's more than one?19:51
denixand yes, as bluelightning said, building multiple kernels for the same machine is being discussed on the list right now :) it's a hot topic it seems19:52
*** madisox <madisox!~madison@12.30.244.9> has joined #yocto19:52
bluelightningkergoth: interesting - I had an idle thought about using BBCLASSEXTEND for this some years ago but it never went beyond that19:52
deviosityGlad there is dialog around it, but unfortunately by the time it is implemented, I'll probably have the drivers I need ported or available in the mainline kernel. :)19:52
kergothbluelightning: the basics turned out to be quite simple (as seems to be often the case with that sort of thing). it adds the base recipe to PROVIDES and adds the base packages to RPROVIDES/RCONFLICTS/RREPLACES for all the parse time known packages. doesn't handle dynamic yet, planning to inject a packagefunc for that.. Tested building core-image-base with busybox-minimal instead of busybox, which worked after setting the appropriate VIRTUAL-RUNTIME19:54
mario-goulartkergoth: s/propogate/propagate/ in https://github.com/kergoth/meta-named-configs-prototype#iii-limitations19:55
kergothI just don't know if it'd be useful in practice..19:55
kergothah, thanks19:55
mario-goulartyw19:55
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto19:56
deviositykergoth: super useful19:56
denixbluelightning: as of kernel deps - would it be safe to add the specific kernel recipe name to ABISAFE list, as long as both machines use it from the same source tree with the same configuration?19:58
deviosityI was just thinking how I would manage my u-boot configs, and custom files due to how the 3.x series kernels work versus the 4.x19:59
*** madisox <madisox!~madison@12.30.244.9> has quit IRC20:00
RPkergoth: that is interesting...20:02
RPkergoth: did you see the <taskname>- patch? curious if you agree its a good thing or not...20:03
kergothhaven't seen it, will take a look20:03
RPkergoth: I keep getting asked for something like this but have held off until this idea of syntax came to mind...20:03
kergoththe one thing i'm not sure about with the config variants thing is how to make it easy to switch back and forth at runtime with a feed. i think i'd need the rconflicts/rreplaces also set in the non-variant recipe, with the names of all the variants, otherwise i don't think you could switch back from a variant to the main recipe, and switching between variants could be problematic too unless they all refer to one another, but that's theoretical, untested20:04
kergothoh, that's interesting. so you could e.g. populate the sstate for an image without building the image itself20:04
RPkergoth: right20:04
kergothseems like sane syntax, I like it20:05
RPkergoth: It seems to fit the rest of the system, slightly crazy but effective :)20:05
kergothheh, indeed :)20:05
kergothThe other thing I was experimenting with using bbclassextend to generate recipe variants was to cover a case where you can legally distribute binaries of something, but not its sources. so it generates variants to explicitly generate a tarball of the binary output and then use that in the binary-only variant, so your CI or release builds could explicitly build the source-to-binary variants and then ship the binary tarballs with the sources20:07
kergothhaven't worked all the kinks out of that one yet20:07
RPkergoth: changing named configs might not make too much sense with packagefeeds...20:07
RPkergoth: you'd certainly not want to be doing that often20:07
RPkergoth: the other way of solving the binary thing would be locked sstate objects in some form20:08
kergothI think it could be useful for folks that want to build images from feeds, just select your provider at that level20:08
RPkergoth: agreed on that, but the system would uninstall any unwanted packages from the feed anyway20:08
kergothHmm, that's true. But of course our locking system today only allows aborting a build on the checksum changing, not forcing their use despite the change :)20:09
RPkergoth: the design actually allows you to force a checksum20:09
RPkergoth: just nobody is doing that20:09
RPI'm 99% sure I've done that locally during testing20:09
RPkergoth: the named config thing reminds me of what I'd like to do with bitbake to extend to multiple configurations in one runqueue and finally get multimachine builds as a side effect20:10
RPkergoth: the main problem is the syntax for it and the fact we'd have to support multiple data stores properly in the core20:10
*** ftonello <ftonello!~felipe@81.145.202.106> has quit IRC20:10
bluelightningdenix: I'm not sure they are completely ABI-safe in this case though20:10
RPor the alternative is we make MACHINE and DISTRO very late includes instead of the way they work today I guess20:11
RPthen they'd become BBCLASSEXTEND capable20:11
kergothHmm, yes, that does sound interesting. I'd worry about some of the remaining semi-global state we have, like the events system, unless the runqueues are handled in different processes. It could be interesting to attach the events to the metadata20:12
bluelightningkergoth: force use despite checksum changing does work, at least last I tested it20:12
bluelightningkergoth: the code doesn't have an explicit option for "don't warn" in that circumstance, but it turns out you can set the variable to any other value and that will be the result because it doesn't validate it ;)20:13
bluelightningwe should probably fix that20:13
*** IvanSB <IvanSB!~IvanSB@host136-114-dynamic.54-79-r.retail.telecomitalia.it> has joined #yocto20:14
*** berton_ <berton_!~fabio@201.22.227.56> has quit IRC20:15
denixbluelightning: by "this case" do you mean ipsec-tools specifically or dependency on kernel in general?20:16
kergothis force use global across all the locked checksums? if so, that'd be of somewhat limited usefulness, IMO. I think there are recipes I'd want to force, and recipes I'd want to fail if they change. For example, consider a case where we don't want rebuilds, and don't want the person downstream to be changing those things, but we want to allow forcing a single checksum to build a CVE fix for a single recipe.20:16
-YoctoAutoBuilder- build #561 of nightly-x32 is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/56120:16
* kergoth ponders20:16
*** madisox <madisox!~madison@12.30.244.5> has joined #yocto20:17
bluelightningdenix: ipsec-tools... if it depends on interfaces in the kernel then it's not going to be safe against any changes in that interface20:17
bluelightningdenix: the problem with SIGGEN_EXCLUDERECIPES_ABISAFE is it effectively says there will be no ABI issue ever, which is hard to be sure of20:18
denixbluelightning: we've discussed this topic before using oprofile as an example. khem was claiming it should be safe to re-use the same binary between kernels... unfortunately I ran out of time then and ended up with oprofile.bbappend to PACKAGE_ARCH=MACHINE_ARCH...20:21
bluelightningdenix: right, it's a long standing problem... I just think somewhere in here there's an architectural problem to be solved rather than band-aiding it every time it breaks, but I'm not quite sure how at the moment20:23
denixbluelightning: ok, I see your point about ABISAFE - it will potentially mask real ABI changes for other packages... :(20:24
bluelightningunfortunately yes20:25
bluelightningthere is also SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS for specific relationships between two recipes, but that still has problems if that ABI ever changes in future20:26
denixbluelightning: is there a bugzilla to track this "architectural problem" or should we start another discussion on the new Architecture list? :)20:27
bluelightningthere isn't... we probably ought to have one, although it would be nice to have some idea of how we might solve the issue first assuming it's practical to do so20:28
*** paulg <paulg!~paulg@184-94-55-234.dedicated.allstream.net> has quit IRC20:30
denixbluelightning: how does libc handle kernel ABI and any potential changes? it's not machine-specific...20:31
RPthat is the key part of the issue, its a question of a workable way of dealing with the problem20:31
RPdenix: libc has pretty strong version checks and is compiled to work with a certain kernel version range. The kernel syscall API is also pretty backwards compatible20:32
kergothI think the only viable option would be to have some sort of abi / output analysis / tracking so we can determine when a build resulted in changed output, but we'd need either pluggable methods to anlalyze different types of output, or we'd need fully bit-for-bit ReproducibleBuilds, or both20:32
RPI know we've started looking at binary reproducible builds but it will be a long haul20:33
kergothdebian is making good progress, but every single package needs fixing up on a per-package basis, it seems20:34
kergothwell, not every, but a hell of a lot :)20:34
kergoththey have good tools for comparing build output and stuff for that project though20:34
RPkergoth: right, its going to take a while. We looked as we'd like to feed that data into PR Server20:34
denixkergoth: any links to read up on that debian work?20:34
kergothhttps://reproducible.debian.net/, https://reproducible.debian.net/dbd/unstable/amd64/avrprog_0.2.2-2.diffoscope.html20:34
denixthanks20:35
kergothhttps://wiki.debian.org/ReproducibleBuilds20:35
*** soderstrom <soderstrom!~soderstro@c-608be555.015-59-6c6b7013.cust.bredbandsbolaget.se> has quit IRC20:35
*** morphis <morphis!~morphis@2001:67c:1560:8007::aac:c152> has quit IRC20:36
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has quit IRC20:36
kergothI think a good start would be to initiate a project to make bitbake able to dynamically adjust the runqueue based on some form of pluggable output check. assume everything needs to be rebuilt if something it depends on changes its input checksum, but break that point in the chain if its output is identical to previous20:37
kergothwhether we just checksum the binaries or use some form of abi comparison, we'd need that either way20:37
kergothafaict anyway20:37
RPkergoth: there is a bit of a conflict here since you really need to know what the task graph looks like in advance? Why? So you can build in parallel. For example if you need to build the git based recipe X, you need git-native and would want to build that in advance if you can20:39
RPkergoth: not disagree, just saying that output based changes to the task graph are rather problematic :/20:40
RPkergoth: we have this issue with sstate too, we can't tell in advance which sstate will be available and therefore how much we need to download20:40
RPe.g. if the sstate for X failed to unpack, we'd need git-native from sstate, otherwise we might not20:41
RPwhich is why sstate doesn't download everything at once but does it in stages20:41
kergothI don't really see a problem with that. Assume its tasks are being rebuilt, so build or pull from sstate things like git-native, worst case we don't end up needing them if the graph gets short-circuited. It might not be perfect, but you'd still avoid rebuilding/building much20:43
* kergoth shrugs, clearly a lot would need to be worked out, non-trivial20:44
RPkergoth: my experiences with sstate suggest the amount that would be rebuilt or even downloaded from sstate is significant :/20:45
RPkergoth: as you say, a lot would need to be worked out, just sharing what I've seen...20:45
kergoththe alternative would be to assume that the tasks depending on a changed task don't need to be rebuilt until we build it and check its output, but then you'd need to dynamically add to the runqueue, and you could potentially underuse your resources until those tasks are run, so they'd have to be prioritized. regardless, i'd expect it to be opt-in20:47
bluelightningI'd definitely like to experiment with this; finding the time is a problem though20:49
RPI suspect the best way of moving towards this would be to scrap the setscene stage and have that happen dynamically throughout the build20:50
RPthen the equailvalence of output becomes a mapping between two different sstate checksums effectively20:50
RPwhat scares me is we once tried setscene dynamically in the build and it was a nightmare. Admittedly we have a lot better system to start with now at least20:51
*** IvanSB <IvanSB!~IvanSB@host136-114-dynamic.54-79-r.retail.telecomitalia.it> has joined #yocto20:57
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC20:58
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto20:58
*** obsrwr <obsrwr!~obsrwr@188.24.254.35> has quit IRC20:59
*** khem` is now known as onoffon20:59
*** onoffon <onoffon!~khem@unaffiliated/khem> has quit IRC21:00
*** cbzx <cbzx!~cbzx@99.224.129.102> has quit IRC21:06
*** paulg <paulg!~paulg@OTWAON23-1279379696.sdsl.bell.ca> has joined #yocto21:07
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto21:08
*** khem` is now known as onoffon21:09
*** onoffon <onoffon!~khem@unaffiliated/khem> has quit IRC21:10
*** fledermaus <fledermaus!~vivek@78.32.176.249> has joined #yocto21:11
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto21:14
*** dreyna4529 <dreyna4529!~dreyna@unknown-216-197.windriver.com> has joined #yocto21:15
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has joined #yocto21:19
*** vmeson <vmeson!~rmacleod@128.224.252.2> has quit IRC21:31
-YoctoAutoBuilder- build #551 of nightly-rpm is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-rpm/builds/55121:43
-YoctoAutoBuilder- build #556 of nightly-ipk is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-ipk/builds/55621:52
*** pohly <pohly!~pohly@194.136.87.227> has quit IRC21:56
*** karobar <karobar!4432d82d@gateway/web/freenode/ip.68.50.216.45> has quit IRC22:02
*** sno <sno!~sno@static-87-79-200-121.netcologne.de> has quit IRC22:08
*** lamego <lamego!~jose@134.134.139.76> has quit IRC22:10
*** lamego <lamego!~jose@134.134.139.76> has joined #yocto22:11
*** soderstrom <soderstrom!~soderstro@c-608be555.015-59-6c6b7013.cust.bredbandsbolaget.se> has joined #yocto22:22
-YoctoAutoBuilder- build #542 of nightly-deb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-deb/builds/54222:24
-YoctoAutoBuilder- build #222 of nightly-rpm-non-rpm is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-rpm-non-rpm/builds/22222:29
*** Aethenelle <Aethenelle!~Aethenell@199.15.128.78> has quit IRC22:32
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC22:32
*** IvanSB <IvanSB!~IvanSB@host136-114-dynamic.54-79-r.retail.telecomitalia.it> has quit IRC22:34
*** vmeson <vmeson!~rmacleod@24-212-184-107.cable.teksavvy.com> has joined #yocto22:34
*** dreyna4529 <dreyna4529!~dreyna@unknown-216-197.windriver.com> has quit IRC22:35
*** dreyna_ <dreyna_!~dreyna@unknown-4-76.windriver.com> has joined #yocto22:35
*** rburton <rburton!~Adium@35.106.2.81.in-addr.arpa> has quit IRC22:41
*** paulg <paulg!~paulg@OTWAON23-1279379696.sdsl.bell.ca> has quit IRC22:44
*** vmeson <vmeson!~rmacleod@24-212-184-107.cable.teksavvy.com> has quit IRC22:45
*** vmesons <vmesons!~rmacleod@24-212-184-107.cable.teksavvy.com> has joined #yocto22:45
*** sno <sno!~sno@p578b540c.dip0.t-ipconnect.de> has joined #yocto22:47
-YoctoAutoBuilder- build #577 of nightly-multilib is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/57722:55
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto22:55
*** fmeerkoetter <fmeerkoetter!~quassel@service.basyskom.com> has quit IRC23:01
*** bfederau <bfederau!~quassel@service.basyskom.com> has quit IRC23:01
*** fmeerkoetter <fmeerkoetter!~quassel@service.basyskom.com> has joined #yocto23:01
*** bfederau <bfederau!~quassel@service.basyskom.com> has joined #yocto23:01
kergothhmm, odd, buildhistory-collect-srcrevs is emitting an srcrev for this recipe without specifying -a when the recipe has SRCREV set, it's not using AUTOREV23:02
*** hanDerPeder <hanDerPeder!~peder@li307-49.members.linode.com> has quit IRC23:02
-YoctoAutoBuilder- build #168 of eclipse-plugin-mars is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/eclipse-plugin-mars/builds/16823:04
*** madisox <madisox!~madison@12.30.244.5> has quit IRC23:04
-YoctoAutoBuilder- build #572 of eclipse-plugin-kepler is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/eclipse-plugin-kepler/builds/57223:12
*** lamego <lamego!~jose@134.134.139.76> has quit IRC23:14
*** soderstrom <soderstrom!~soderstro@c-608be555.015-59-6c6b7013.cust.bredbandsbolaget.se> has quit IRC23:16
kergothah, i see, it compares the unexpanded and expanded form, so any intermediate variable use in SRCREV causes it to be emitted by collect-srcrevs by default, autorev or no23:18
kergothgood to know23:18
-YoctoAutoBuilder- build #225 of nightly-deb-non-deb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-deb-non-deb/builds/22523:19
*** Aethenelle <Aethenelle!~Aethenell@166.175.184.141> has joined #yocto23:20
*** yann|work <yann|work!~yann@nan92-1-81-57-214-146.fbx.proxad.net> has joined #yocto23:30
*** fledermaus <fledermaus!~vivek@78.32.176.249> has quit IRC23:38
*** nighty^ <nighty^!~nighty@q029220.ppp.asahi-net.or.jp> has quit IRC23:46
-YoctoAutoBuilder- build #116 of nightly-wic is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-wic/builds/11623:47
-YoctoAutoBuilder- build #561 of nightly-qa-skeleton is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-qa-skeleton/builds/56123:50
*** aehs29 <aehs29!~aehernan@134.134.139.77> has left #yocto23:51
*** Aethenelle <Aethenelle!~Aethenell@166.175.184.141> has quit IRC23:56
*** anselmolsm <anselmolsm!~anselmols@192.55.54.40> has quit IRC23:56
-YoctoAutoBuilder- build #580 of nightly-x86 is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/58023:59

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!