Wednesday, 2017-01-11

-YoctoAutoBuilder- build #1019 of nightly-qa-extras is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-qa-extras/builds/101900:02
-YoctoAutoBuilder- build #1019 of nightly-qa-logrotate is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-qa-logrotate/builds/101900:02
*** agust <agust!~agust@p4FCB656D.dip0.t-ipconnect.de> has quit IRC00:04
*** rewitt <rewitt!~rewitt@134.134.139.78> has joined #yocto00:06
*** bavery_fn <bavery_fn!~bavery@134.134.139.82> has quit IRC00:08
*** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has quit IRC00:10
*** zeddii_home <zeddii_home!~zeddii_ho@CPEe8de27b71faa-CMbcc810032faf.cpe.net.cable.rogers.com> has quit IRC00:11
*** m2 <m2!~m2@amy.ksub.org> has quit IRC00:11
*** cmos_dev_ <cmos_dev_!sid200148@gateway/web/irccloud.com/x-rnqvbjdibblhcrca> has quit IRC00:11
*** rob-oi-ma <rob-oi-ma!sid155560@gateway/web/irccloud.com/x-gixhxkjorjfplfqp> has quit IRC00:11
*** esennesh <esennesh!sid111300@gateway/web/irccloud.com/x-pzgstcyntbtldotp> has quit IRC00:12
*** rob-oi-ma <rob-oi-ma!sid155560@gateway/web/irccloud.com/x-tfhzjhocrgvwhveq> has joined #yocto00:12
*** cmos_dev_ <cmos_dev_!sid200148@gateway/web/irccloud.com/x-okvxerbdkewsamnw> has joined #yocto00:12
*** falstaff <falstaff!~quassel@95.58.150.83.ftth.as8758.net> has quit IRC00:12
*** zeddii_home <zeddii_home!~zeddii_ho@CPEe8de27b71faa-CMbcc810032faf.cpe.net.cable.rogers.com> has joined #yocto00:12
*** erbo <erbo!~erik@li444-24.members.linode.com> has quit IRC00:12
-YoctoAutoBuilder- build #1024 of nightly-x32 is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/102400:12
*** ionte <ionte!~ionte@c-31-209-59-170.cust.bredband2.com> has quit IRC00:12
*** tf <tf!~tomas@r-finger.com> has quit IRC00:12
*** rewitt <rewitt!~rewitt@134.134.139.78> has quit IRC00:12
-YoctoAutoBuilder- build #378 of nightly-no-x11 is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-no-x11/builds/37800:13
*** khem <khem!~khem@unaffiliated/khem> has quit IRC00:13
*** falstaff <falstaff!~quassel@95.58.150.83.ftth.as8758.net> has joined #yocto00:13
*** MiskaX <MiskaX!~jussi@rankki.sonarnerd.net> has quit IRC00:13
*** fabo <fabo!~fabo@linaro/fabo> has quit IRC00:13
*** reanguia1o <reanguia1o!~devnull@godel.ricardoanguiano.com> has quit IRC00:13
*** rewitt <rewitt!~rewitt@134.134.139.78> has joined #yocto00:14
*** reanguiano <reanguiano!~devnull@godel.ricardoanguiano.com> has joined #yocto00:14
*** fabo <fabo!~fabo@a91-156-68-16.elisa-laajakaista.fi> has joined #yocto00:14
*** fabo <fabo!~fabo@linaro/fabo> has joined #yocto00:14
*** MiskaX <MiskaX!~jussi@rankki.sonarnerd.net> has joined #yocto00:14
*** rewitt <rewitt!~rewitt@134.134.139.78> has quit IRC00:15
*** sameo <sameo!~samuel@192.55.54.40> has quit IRC00:16
*** paulg <paulg!~paulg@198-84-239-75.cpe.teksavvy.com> has joined #yocto00:17
*** ionte <ionte!~ionte@c-31-209-59-170.cust.bredband2.com> has joined #yocto00:17
*** m2 <m2!~m2@amy.ksub.org> has joined #yocto00:17
*** esennesh <esennesh!sid111300@gateway/web/irccloud.com/x-rfngwtolecvtnajx> has joined #yocto00:19
*** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has joined #yocto00:20
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto00:21
*** ionte <ionte!~ionte@c-31-209-59-170.cust.bredband2.com> has quit IRC00:25
*** fmeerkoetter <fmeerkoetter!~quassel@service.basyskom.com> has quit IRC00:25
*** fmeerkoetter <fmeerkoetter!~quassel@service.basyskom.com> has joined #yocto00:26
*** rewitt <rewitt!~rewitt@134.134.139.78> has joined #yocto00:26
*** ionte <ionte!~ionte@c-31-209-59-170.cust.bredband2.com> has joined #yocto00:26
*** rewitt <rewitt!~rewitt@134.134.139.78> has quit IRC00:26
*** erbo <erbo!~erik@li444-24.members.linode.com> has joined #yocto00:26
*** tf <tf!~tomas@r-finger.com> has joined #yocto00:27
*** rewitt <rewitt!~rewitt@134.134.139.78> has joined #yocto00:28
*** rewitt <rewitt!~rewitt@134.134.139.78> has joined #yocto00:32
*** t0mmy <t0mmy!~tprrt@ram31-1-82-234-79-177.fbx.proxad.net> has quit IRC00:35
*** rewitt <rewitt!~rewitt@134.134.139.78> has joined #yocto00:36
*** manuel_ <manuel_!~manuel@209.6.175.242> has quit IRC00:37
khemdl9pf: you can reply to thread and CC morty maintainer ( Armin ) with request to backport00:37
*** Son_Goku <Son_Goku!~King_InuY@ool-457cb820.dyn.optonline.net> has joined #yocto00:40
*** gtristan <gtristan!~tristanva@23.233.166.84> has quit IRC00:42
*** armpit <armpit!~akuster@50-233-148-156-static.hfc.comcastbusiness.net> has quit IRC00:43
*** anselmolsm_ <anselmolsm_!~anselmols@192.55.54.45> has quit IRC00:51
*** manuel_ <manuel_!~manuel@c-24-61-43-145.hsd1.ma.comcast.net> has joined #yocto00:51
*** armpit <armpit!~akuster@50-233-148-156-static.hfc.comcastbusiness.net> has joined #yocto00:59
*** esennesh <esennesh!sid111300@gateway/web/irccloud.com/x-rfngwtolecvtnajx> has quit IRC01:00
*** paulg <paulg!~paulg@198-84-239-75.cpe.teksavvy.com> has quit IRC01:02
*** chep <chep!~chep@LFbn-1-2968-236.w90-76.abo.wanadoo.fr> has quit IRC01:06
*** chep <chep!~chep@LFbn-1-2968-236.w90-76.abo.wanadoo.fr> has joined #yocto01:11
*** catch22 <catch22!~catch22@220.57.96.58.static.exetel.com.au> has joined #yocto01:14
catch22Is it possible to change the build options for native packages?01:15
catch22I want to debug my native packages before deploying to the target in gdb but they seem to be stripped.01:16
*** nighty <nighty!~nighty@d246113.ppp.asahi-net.or.jp> has joined #yocto01:17
*** rburton <rburton!~Adium@home.burtonini.com> has quit IRC01:17
rewittcatch22: https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-BUILD_CFLAGS01:17
catch22rewitt: excellent, thanks01:18
*** rewitt <rewitt!~rewitt@134.134.139.78> has quit IRC01:25
*** rewitt <rewitt!~rewitt@134.134.139.78> has joined #yocto01:28
*** chep <chep!~chep@LFbn-1-2968-236.w90-76.abo.wanadoo.fr> has quit IRC01:28
-YoctoAutoBuilder- build #673 of nightly-mips64 is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-mips64/builds/67301:28
*** Nilesh_ <Nilesh_!uid116340@gateway/web/irccloud.com/x-cqzrufbbvzqwdyck> has joined #yocto01:34
*** flynn378 <flynn378!sid63564@gateway/web/irccloud.com/x-sjcsmyoqzajgtdkv> has joined #yocto01:34
*** manuel_ <manuel_!~manuel@c-24-61-43-145.hsd1.ma.comcast.net> has quit IRC01:38
khemrewitt: static linking should be no problem with musl and its well supported, add -static to CFLAGS and LDFLAGS globally01:39
khemrewitt: although if you have many apps then it might not give you best results01:39
khemin terms for size opts01:40
khembut say if you just want busybox + your app01:40
khemwhich is a typical embedded scenario in some cases, this might be helpful01:40
-YoctoAutoBuilder- build #1022 of nightly-qa-systemd is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-qa-systemd/builds/102201:40
khemmusl based poky-tiny images are around 600K anyway01:41
khemfull musl size is approx 500K that includes all libraries e.g. libm/librt included01:41
*** phoo1234567 <phoo1234567!~phoo12345@c-75-69-172-183.hsd1.nh.comcast.net> has quit IRC01:49
catch22rewitt : adding BUILD_CPPFLAGS caues a rebuild of everything, I've found adding  OECMAKE_C_FLAGS_append_class-native = " -O0 -ggdb " to the specific recipe appears to gives me what I want just for those recipes.   Do you know if you can adjust build_cflags for specific packages from local.conf?01:52
*** stephano <stephano!~stephano@134.134.139.76> has quit IRC02:14
*** stephano <stephano!~stephano@134.134.139.76> has joined #yocto02:15
*** stephano <stephano!~stephano@134.134.139.76> has quit IRC02:15
*** stephano <stephano!~stephano@134.134.139.76> has joined #yocto02:15
-YoctoAutoBuilder- build #1050 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/105002:16
*** manuel_ <manuel_!~manuel@c-24-61-40-209.hsd1.ma.comcast.net> has joined #yocto02:19
*** manuel_ <manuel_!~manuel@c-24-61-40-209.hsd1.ma.comcast.net> has quit IRC02:27
*** manuel_ <manuel_!~manuel@c-24-61-40-209.hsd1.ma.comcast.net> has joined #yocto02:28
-YoctoAutoBuilder- build #1044 of nightly-ppc is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-ppc/builds/104402:31
*** chep <chep!~chep@LFbn-1-2968-236.w90-76.abo.wanadoo.fr> has joined #yocto02:31
*** JordonWu_ <JordonWu_!~quassel@221.226.9.57> has joined #yocto02:32
*** gtristan <gtristan!~tristanva@modemcable172.18-161-184.mc.videotron.ca> has joined #yocto02:32
*** aehs29 <aehs29!~aehernan@134.134.139.76> has joined #yocto02:33
*** JordonWu <JordonWu!~quassel@221.226.9.57> has quit IRC02:34
*** JordonWu_ <JordonWu_!~quassel@221.226.9.57> has quit IRC02:49
*** morphis_ <morphis_!~morphis@pD9ED6304.dip0.t-ipconnect.de> has joined #yocto02:50
*** JordonWu <JordonWu!~quassel@221.226.9.57> has joined #yocto02:51
*** morphis <morphis!~morphis@pD9ED63AB.dip0.t-ipconnect.de> has quit IRC02:54
*** armpit <armpit!~akuster@50-233-148-156-static.hfc.comcastbusiness.net> has quit IRC03:05
*** sgw_ <sgw_!~sgw_@134.134.139.82> has quit IRC03:05
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC03:11
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto03:12
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC03:23
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto03:28
*** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto03:32
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC03:33
*** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has quit IRC03:37
*** Son_Goku <Son_Goku!~King_InuY@ool-457cb820.dyn.optonline.net> has quit IRC03:45
*** bavery_fn <bavery_fn!~bavery@134.134.139.83> has joined #yocto04:01
*** aehs29 <aehs29!~aehernan@134.134.139.76> has quit IRC04:10
*** Son_Goku <Son_Goku!~King_InuY@ool-457cb820.dyn.optonline.net> has joined #yocto04:17
rewittkhem: That's for the response, in the case I'm thinking of there would typically be *one* app in the image04:21
rewitts/That's/thanks04:21
*** aehs29 <aehs29!~aehernan@134.134.139.82> has joined #yocto04:30
*** stephano <stephano!~stephano@134.134.139.76> has quit IRC04:42
rewittcatch22: I think you should be able to do it like so, SOMEVAR_pn-somerecipe05:05
*** redengin_ <redengin_!~redengin@2601:600:9200:a356:b175:5bf1:711f:d879> has joined #yocto05:26
*** redengin <redengin!~redengin@2601:600:9200:a356:a112:7024:d638:e2f0> has quit IRC05:27
*** manuel_ <manuel_!~manuel@c-24-61-40-209.hsd1.ma.comcast.net> has quit IRC05:33
*** xulfer <xulfer!~xulfer@random.cheapbsd.net> has joined #yocto05:37
*** sgw_ <sgw_!~sgw_@134.134.139.72> has joined #yocto05:48
*** aehs29 <aehs29!~aehernan@134.134.139.82> has quit IRC05:49
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto06:01
*** AndersD <AndersD!~anders@194.237.220.218> has joined #yocto06:10
*** Son_Goku <Son_Goku!~King_InuY@ool-457cb820.dyn.optonline.net> has quit IRC06:23
*** Sir_Gallantmon <Sir_Gallantmon!~King_InuY@ool-457cb820.dyn.optonline.net> has joined #yocto06:25
*** morphis_ <morphis_!~morphis@pD9ED6304.dip0.t-ipconnect.de> has quit IRC06:27
*** mdnneo <mdnneo!~umaucher@217.89.178.116> has joined #yocto06:45
*** catch22_ <catch22_!~aboseley@101.165.216.251> has joined #yocto06:49
*** Sir_Gallantmon <Sir_Gallantmon!~King_InuY@ool-457cb820.dyn.optonline.net> has quit IRC06:56
*** agust <agust!~agust@p4FCB4571.dip0.t-ipconnect.de> has joined #yocto06:56
*** t0mmy <t0mmy!~tprrt@ram31-1-82-234-79-177.fbx.proxad.net> has joined #yocto06:58
*** pohly <pohly!~pohly@p5DE8EC30.dip0.t-ipconnect.de> has joined #yocto07:00
*** rob_w <rob_w!~bob@93.104.205.194> has joined #yocto07:03
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:03
*** Son_Goku <Son_Goku!~King_InuY@ool-457cb820.dyn.optonline.net> has joined #yocto07:03
*** morphis <morphis!~morphis@pD9ED6304.dip0.t-ipconnect.de> has joined #yocto07:10
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@109.112.75.128> has joined #yocto07:11
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has joined #yocto07:11
*** hamis <hamis!~irfan@110.93.212.98> has joined #yocto07:14
*** t0mmy <t0mmy!~tprrt@ram31-1-82-234-79-177.fbx.proxad.net> has quit IRC07:23
*** stephano <stephano!~stephano@c-98-246-137-222.hsd1.or.comcast.net> has joined #yocto07:25
*** stephano <stephano!~stephano@c-98-246-137-222.hsd1.or.comcast.net> has left #yocto07:27
*** radzy <radzy!~radzy@unknown-216-77.windriver.com> has quit IRC07:29
*** radzy_ <radzy_!~radzy@unknown-216-77.windriver.com> has joined #yocto07:29
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto07:33
*** Cubi_ <Cubi_!~sstiller@b2b-94-79-174-114.unitymedia.biz> has joined #yocto07:37
*** rburton <rburton!~Adium@81.2.106.35> has joined #yocto07:38
*** qt-x <qt-x!~Thunderbi@217.10.196.2> has joined #yocto07:41
*** bavery_fn <bavery_fn!~bavery@134.134.139.83> has quit IRC07:53
*** fl0v0 <fl0v0!~fvo@p4FC0A081.dip0.t-ipconnect.de> has joined #yocto07:57
*** rajm <rajm!~robertmar@cpc14-macc3-2-0-cust149.1-3.cable.virginm.net> has joined #yocto08:00
*** poor-man <poor-man!d97eb626@gateway/web/freenode/ip.217.126.182.38> has joined #yocto08:01
*** Cubi_ <Cubi_!~sstiller@b2b-94-79-174-114.unitymedia.biz> has quit IRC08:04
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC08:04
*** mdnneo <mdnneo!~umaucher@217.89.178.116> has quit IRC08:04
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto08:06
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto08:06
*** AndersD <AndersD!~anders@194.237.220.218> has quit IRC08:11
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC08:11
*** aV_V <aV_V!~aV_V@146.66.253.137> has joined #yocto08:15
*** Kakounet <Kakounet!~Thunderbi@che44-1-88-163-87-53.fbx.proxad.net> has joined #yocto08:17
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto08:20
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has joined #yocto08:22
*** fl0v01 <fl0v01!~fvo@pD9F6B04A.dip0.t-ipconnect.de> has joined #yocto08:23
*** fl0v0 <fl0v0!~fvo@p4FC0A081.dip0.t-ipconnect.de> has quit IRC08:26
*** AndersD <AndersD!~anders@194.237.220.218> has joined #yocto08:26
*** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-zzxklovwdzonglby> has joined #yocto08:27
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has joined #yocto08:28
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto08:29
*** joseppc <joseppc!~josep@linaro/joseppc> has quit IRC08:43
*** mckoan|away is now known as mckoan08:44
mckoangood morning08:44
*** sameo <sameo!~samuel@192.55.54.36> has joined #yocto08:45
*** Martian <Martian!~martian@87.120.221.183> has joined #yocto08:48
*** graphiqs <graphiqs!~adrian.gr@217.6.37.53> has joined #yocto08:55
*** rubdos <rubdos!~rubdos@host-85-27-50-55.dynamic.voo.be> has joined #yocto08:58
*** jku <jku!~jku@192.198.151.44> has joined #yocto09:01
*** Biliogadafr <Biliogadafr!~PIN@nat-minsk-pool-46-53-202-120.telecom.by> has joined #yocto09:02
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has quit IRC09:04
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has joined #yocto09:07
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC09:08
*** catch22_ <catch22_!~aboseley@101.165.216.251> has quit IRC09:12
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has quit IRC09:14
*** toscalix <toscalix!~toscalix@90.170.203.139> has joined #yocto09:23
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has joined #yocto09:24
*** joseppc <joseppc!~josep@sestofw01.enea.se> has joined #yocto09:30
*** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto09:30
*** psnsilva_ <psnsilva_!~psnsilva@193-126-29-154.net.novis.pt> has quit IRC09:39
aV_Vmckoan: good morning09:40
*** ed2 <ed2!~Adium@192.198.151.45> has joined #yocto09:43
*** geoffrey_l <geoffrey_l!~geoffrey_@fw-alt.idf.smile.fr> has joined #yocto09:49
*** ziggo <ziggo!~ziggo@212.118.209.82> has joined #yocto09:56
*** mdnneo <mdnneo!~umaucher@217.89.178.116> has joined #yocto10:06
*** ziggo <ziggo!~ziggo@212.118.209.82> has quit IRC10:13
aV_Von the machine layer there is this: do_rootfs[depends] += "u-boot-script-compulab:do_deploy"10:16
aV_Vhow do I remove that? I don't want to install a u-boot script10:17
aV_VI tried do_rootfs_remove but it fails10:18
*** Kakounet <Kakounet!~Thunderbi@che44-1-88-163-87-53.fbx.proxad.net> has quit IRC10:18
nrossiaV_V: I don't think there is a clean way to remove that flag set without using python. Just modify the layer, it probably shouldn't be adding the depends like that anyways.10:22
abelloniaV_V: the clean way is to stop using crappy vendor layers :)10:22
nrossithat works too :)10:22
aV_Vthe layer is experimental, thats why is like that10:23
abelloniusing a new vendor layer is like opening a box of candy10:23
aV_VxD10:23
rburtonjku, maxin: can one of you please look at the connman/musl problem in ross/mut?  musl + kernel 4.9 headers = connman breaks10:24
nrossiall the candy is gone, and only the liquorish is left?10:24
*** joshuagl <joshuagl!joshuagl@nat/intel/x-zhdhhmpmaueewxdv> has joined #yocto10:26
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@109.112.75.128> has joined #yocto10:26
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has joined #yocto10:26
*** redengin <redengin!~redengin@2601:600:9200:a356:1137:edfe:5960:c4a7> has joined #yocto10:27
*** redengin_ <redengin_!~redengin@2601:600:9200:a356:b175:5bf1:711f:d879> has quit IRC10:28
aV_Vhow do I "ban" that recipe? u-boot-script-compulab10:29
aV_Vor still if I ban it then will fail because of do_rootfs statement?10:30
nrossiaV_V: that wont help because your image do_rootfs task depends on it. You just need to modify the layer that adds the dependency.10:31
*** TobSnyder <TobSnyder!~schneider@ip9234b0ae.dynamic.kabel-deutschland.de> has joined #yocto10:33
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC10:35
*** nighty <nighty!~nighty@d246113.ppp.asahi-net.or.jp> has quit IRC10:37
*** grma <grma!~gruberm@80.93.38.128> has joined #yocto10:46
*** armpit <armpit!~akuster@2601:202:4001:9ea0:ea2a:eaff:fe0e:629e> has joined #yocto10:51
*** berton <berton!~berton@189.114.111.135> has joined #yocto10:52
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:54
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has quit IRC10:56
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has joined #yocto10:57
RPrburton: I *think* we might be ready to try recipe specific sysroots on the autobuilder10:59
rburton!!!!11:02
rburtonRP: a bit surprised you didn't sneak a build on the cluster in secret11:02
* rburton -> dog walk, back shortly11:02
rburtongot the new libc building here now11:03
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has quit IRC11:06
*** ziggo <ziggo!~ziggo@217.89.178.116> has joined #yocto11:07
joshuaglRP: wow, sounds like great progress11:07
RPjoshuagl: I'll run an oe-selftest here and see how bad the breakage is there but I'm pleasantly surprised at how its working all of a sudden11:09
joshuaglRP: "all of a sudden" :-D11:10
RPjoshuagl: I fixed a bug at around 2am this morning which I'd kind of solved whilst trying to sleep but being unable to as it was bothering me11:11
joshuaglRP: hopefully you slept better once that was fixed?11:12
RPjoshuagl: yes although the wind kept me awake11:14
jkurburton: will do11:14
* RP wonders why oe-selftest takes 10mins just to load the tests11:15
*** Nerbrun <Nerbrun!~NathanI@mail.validmanufacturing.com> has quit IRC11:15
joshuagloe-selftest seems like a good area to point some of our perf minded folk?11:15
RPjoshuagl: it needs help for sure11:16
joshuaglRP: worth filing a bug?11:16
RPjoshuagl: for this specific thing, probably11:17
RP10mins to load tests is clearly nuts11:17
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto11:17
*** simfir <simfir!~quassel@mail.f9s.eu> has quit IRC11:24
*** simfir <simfir!~quassel@mail.f9s.eu> has joined #yocto11:25
joshuaglindeed :-/11:28
*** nighty <nighty!~nighty@s229123.ppp.asahi-net.or.jp> has joined #yocto11:32
*** JaMa <JaMa!~martin@217.30.68.212> has joined #yocto11:37
rburtondoesn't take 10 minutes to load here12:02
rburtonalso, there's a bug i now own filed yesterday that just 5 tests are responsible for 50% runtime, or something12:02
rburtoni suspect one is that the archiver causes a full rebuild so maybe it shouldn't be building an image12:03
*** JordonWu <JordonWu!~quassel@221.226.9.57> has quit IRC12:03
rburtonkhem: around?12:03
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has quit IRC12:07
geoffrey_lHi, does anybody think it wouldn't be a good idea to make a patch adding (in insane.bbclass) the following QA test : Check if all files in ${sysconfdir} are listed in CONFFILES ?12:08
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has joined #yocto12:09
*** ftonello <ftonello!~felipe@host81-152-92-225.range81-152.btcentralplus.com> has joined #yocto12:09
rburtongeoffrey_l: or you could just set CONFFILES=${sysconfdir} in bitbake.conf.  pretty sure there was a discussion about this on the list.12:12
aV_VThere is a driver on the kernel mainline that I use. The problem is that the driver version on the kernel that I'm using doesn't work. It does the driver version that is on the master branch. I don't want to change the branch, but just the master version of the driver. How I do that?12:14
geoffrey_lrburton: So there is a recursive effect with CONFFILES on directory ?12:15
aV_VI mean, to add the newer driver to my yocto build12:15
rburtongeoffrey_l: oe-core 0d446ef0e5bbca7058eec7259e34f2a1637dfab1 is interestingly, as is #520012:17
geoffrey_lrburton: Oh, thanks :)12:20
rburtonRP: build applicance failed on the AB as pip3 wasn't present :)12:23
kanavinrburton: can you give me an explanation of how rpm post-install scripts work in oe-core? I could figure out it from code, but maybe you talking is faster :)12:27
kanavinall that run-postinsts stuff12:27
rburtonhm now i need to remember ;)12:27
kanavinrburton: you can redirect me to someone else12:27
rburtonthe magic happens in the package_rpm class12:27
rburtongive me a second, i can remember12:28
rburtonno, package_manager.py12:29
rburtongrep for SCRIPTLET_FORMAT and you'll be close12:29
rburtoniirc, basically the postinsts are dumped by rpm instead of being executed, and then we execute them manually12:30
rburtonyes this is the sort of thing that needs to be written down in english as its non-obvious12:30
jkukanavin: scripts/postinst-intercepts/ is worth knowing as well but I assume you do from all the g-i  work12:33
rburtonjoshuagl: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10874 fwiw12:33
yoctiBug 10874: enhancement, Medium+, 2.3 M3, leonardo.sandoval.gonzalez, ACCEPTED , oe-selftest: 35% of the testing time is concentrated in 5 tests (out of ~200)12:33
kanavinjku: actually I don't, it was not necessary for g-i12:33
kanavinrburton: when does the manual execution happen, on first boot?12:34
rburtonat rootfs time first12:34
rburtonthen anything remaining on first boot12:34
kanavinrburton: ah, so rpm does attempt to run then?12:35
kanavinrburton: I'm at that point where dnf/rpm4 run them during bitbake core-image-minimal, and obviously there's an explosion of failures12:36
rburtoni *think* that we tell rpm not to, and we do explicitly at rootfs time instead12:36
kanavinrburton: but how is that different from just letting rpm run them?12:36
rburtoni'm guessing that rpm won't pass $D for target rootfs12:36
kanavinrburton: yeah, this is the kind of thing that ought to be documented in plain english12:37
rburtontotally12:37
kanavinrburton: in fact, we should insist on well-commented code, or lines in recipes that do unusual thing12:37
jkukanavin see rootfs.py: _run_intercepts()12:38
jkuhmm, does it actually run all postinsts there or just the intercepts?12:39
kanavinsee, this is the reason I threw away existing code :)12:42
jkuah here it is I think meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts12:45
jkuI guess that's just on first boot though12:47
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has quit IRC12:50
*** arkver <arkver!~arkver@host86-154-139-39.range86-154.btcentralplus.com> has joined #yocto12:53
*** Nilesh_ <Nilesh_!uid116340@gateway/web/irccloud.com/x-cqzrufbbvzqwdyck> has quit IRC12:54
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has joined #yocto12:57
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC12:59
*** vmeson <vmeson!~rmacleod@24-212-184-107.cable.teksavvy.com> has quit IRC13:00
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@109.112.75.128> has joined #yocto13:02
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has joined #yocto13:02
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has quit IRC13:06
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC13:06
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has joined #yocto13:07
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto13:07
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC13:08
ed2RP: rburton: what's correct way to define a task only if some variable is set and does it make sense to do it at all?13:10
*** manuel_ <manuel_!~manuel@c-24-61-40-209.hsd1.ma.comcast.net> has joined #yocto13:12
ed2for example: defining do_efi_populate and add it before do_image_wic makes sense only if EFI and USING_WIC variables are set13:12
ed2I don't see a lot of examples of this in meta/classes/, so I guess the overhead of defining tasks unconditionally is not that big13:15
rburtonone option would be to bail out o the task early if the variables are not let13:17
rburtonnot set, even13:17
rburtonor write anonymous python to define the tasks13:17
rburtonprobably neater to always have the task but let it do nothing if the variable isn't set13:18
rburtonyou know i wish rm_work wouldn't cause the world to rebuild if toggled13:25
*** fl0v01 <fl0v01!~fvo@pD9F6B04A.dip0.t-ipconnect.de> has quit IRC13:27
ed2rburton: thank you. that's what I did. Just wondering if it's correct way.13:30
*** kscherer <kscherer!~kscherer@128.224.252.2> has joined #yocto13:42
*** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto13:43
*** toanju <toanju!~toanju@185.27.182.30> has joined #yocto13:44
pohlyHas a qemu update to 2.8 been considered?13:45
*** qt-x <qt-x!~Thunderbi@217.10.196.2> has quit IRC13:46
*** lamego <lamego!jose@nat/intel/x-zthwfixgbckcnjhz> has joined #yocto13:47
*** hamis <hamis!~irfan@110.93.212.98> has quit IRC13:48
*** lemagoup <lemagoup!~lemagoup@195.190.86.18> has quit IRC13:53
*** poor-man <poor-man!d97eb626@gateway/web/freenode/ip.217.126.182.38> has quit IRC13:59
*** AndersD <AndersD!~anders@194.237.220.218> has quit IRC14:00
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC14:02
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto14:03
*** ziggo <ziggo!~ziggo@217.89.178.116> has quit IRC14:03
*** geoffrey_l <geoffrey_l!~geoffrey_@fw-alt.idf.smile.fr> has quit IRC14:03
*** geoffrey_l <geoffrey_l!~geoffrey_@gre92-5-82-237-199-7.fbx.proxad.net> has joined #yocto14:04
*** hamis <hamis!~irfan@110.93.212.98> has joined #yocto14:04
*** clement <clement!~clement@fw-alt.idf.smile.fr> has quit IRC14:06
*** paulg <paulg!~paulg@198-84-239-75.cpe.teksavvy.com> has joined #yocto14:06
*** clement <clement!~clement@fw-alt.idf.smile.fr> has joined #yocto14:06
rburtonpohly: afaik it hasn't been rejected.  anything in 2.8 to push for the upgrade?14:08
pohlyrburton: the qemu-tpm patches are based on it. But after looking at this more closely, I find that they also apply cleanly to 2.7, so that alone isn't a reason for updating.14:09
*** geoffrey_l <geoffrey_l!~geoffrey_@gre92-5-82-237-199-7.fbx.proxad.net> has quit IRC14:09
*** geoffrey_l <geoffrey_l!~geoffrey_@fw-alt.idf.smile.fr> has joined #yocto14:10
*** gnac <gnac!~gnac@or-71-0-52-80.sta.embarqhsd.net> has quit IRC14:10
*** boucman_work1 <boucman_work1!~jrosen@fw-alt.idf.smile.fr> has joined #yocto14:11
*** geoffrey_l <geoffrey_l!~geoffrey_@fw-alt.idf.smile.fr> has quit IRC14:11
*** geoffrey_l <geoffrey_l!~geoffrey_@fw-alt.idf.smile.fr> has joined #yocto14:11
kanavinpohly: alimon should be in charge of updating qemu14:12
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC14:12
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc> has joined #yocto14:13
kanavinpohly: also, there's always a default reason to update to new versions; we avoid updating if there's a specific reason not to :)14:13
*** Martian <Martian!~martian@87.120.221.183> has quit IRC14:13
aratiuquick question: I do chown 0:network ${D}${base_sbindir}/ip.iproute2 but the symlink /sbin/ip created by ALTERNATIVE_TARGET[ip] = "${base_sbindir}/ip.${BPN}" is still root:root14:14
aratiuhow do I change the owner of the symlink? is there a standard way or do I also have to chown it (googling revealed nothing)14:14
aratiu(i'm grepping the sources now for some hints)14:15
kanavinaratiu: chown -h14:17
kanavinman chown ;)14:17
rburtonbut the symlink is only created when update-alternatives run, so no14:18
rburtoni do wonder why the perms of the symlink matter?14:18
aratiurburton: good question, checking now14:19
*** ziggo <ziggo!~ziggo@212.118.209.82> has joined #yocto14:19
kanavinapparently there are systems where symlink ownership can't even be changed at all, so I'd say it does not matter14:19
kanavinyou can think of the symlink as a tiny file with the contents pointing to the actual file14:20
kanavinas long as you can read the pointer, nothing else should matter14:20
aratiuit doesn't matter! yupi14:21
aratiuthank you both14:21
*** jku <jku!~jku@192.198.151.44> has quit IRC14:22
rburtona symlink just tells the system to look somewhere else, so the perms on the target are what matter14:25
*** gtristan <gtristan!~tristanva@modemcable172.18-161-184.mc.videotron.ca> has quit IRC14:26
* kanavin has convinced rpm4 to install packages for yocto's weird architectures \0/14:26
aratiui do wonder what's the purpouse of having permissions on symlinks, they must be used for something...14:27
neverpanicI think Linux doesn't have permissions on Symlinks14:28
neverpanicOther systems do14:28
kanavinI guess to complicate unix file access logic even further14:29
kanavinby adding another layer14:29
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC14:29
*** jku <jku!~jku@192.198.151.44> has joined #yocto14:29
rburtonchgrp -h can change the ownership on a symlink, which is what aratiu was after14:30
pohlyWhen do I add BBCLASSEXTEND = "native" and when "BBCLASSEXTEND = "native nativesdk"?14:30
rburtonpohly: do you mean whats the difference between native and nativesdk?14:31
pohlyI only need <recipe>-native, but I think we had cases in Ostro where BBCLASSEXTEND = "native" then led to issues with producing an SDK.14:31
rburtonhm shouldn't have14:31
rburtonif you only need a native recipe then you might as well just inherit native14:31
rburtonbut if you want the tool in a sdk  as something you can run then you'll need to inherit nativesdk and put nativesdk-foo in the SDK14:32
pohlyrburton: so what's the rationale?14:32
rburtonstill not sure what you're actually asking to be honest :)14:32
*** Kakounet <Kakounet!~Thunderbi@che44-1-88-163-87-53.fbx.proxad.net> has joined #yocto14:33
aratiui think the only purpouse of permissions on symlinks is to provent other from unlinking them14:33
aratiu*prevent14:33
pohlyBasically I am enabling the native version of a recipe by adding BBCLASSEXTEND = "native", and I am wondering whether I should go for "native nativesdk" instead, because someone might also want it in an SDK.14:33
rburtonyeah probably safest14:34
pohlyarmpit: ping?14:34
neverpanicaratiu: unlinking only depends on write permissions of the containing directory (unless that directory has a sticky bit), so no, that's not it either.14:34
neverpanicThat's probably the only case where the owner of a symlink is relevant, though.14:34
alimonpohly: do you are planning upgrade qemu?14:38
pohlyalimon: no, I was just wondering.14:38
pohlyI might want to get some of Stefan's qemu-tpm patches included (currently experimenting with that), but that should work with both 2.7 and 2.8.14:39
alimonpohly: ok, i plan to upgrade qemu before m2 closes14:40
*** madisox <madisox!~madison@2601:647:ca00:4f00:ab08:5b70:453f:209d> has joined #yocto14:42
*** madisox <madisox!~madison@2601:647:ca00:4f00:ab08:5b70:453f:209d> has left #yocto14:42
rburtoni wonder if we actually need grub_git.bb14:43
rburtonwhy is the recipe totally different to grub_2.0014:44
rburtonah, its an arm thing, okay14:44
*** manuel_ <manuel_!~manuel@c-24-61-40-209.hsd1.ma.comcast.net> has quit IRC14:44
kanavingrub is one of those projects stuck in perpetual beta14:45
kanavinthey had another beta recently after years of commits14:45
rburtonnot sure i want to know why grub depends on diffutils14:46
*** ntl <ntl!~nathanl@99-127-51-4.lightspeed.austtx.sbcglobal.net> has joined #yocto14:48
*** morphis <morphis!~morphis@pD9ED6304.dip0.t-ipconnect.de> has quit IRC14:49
*** morphis <morphis!~morphis@pD9ED6304.dip0.t-ipconnect.de> has joined #yocto14:49
*** marka_home <marka_home!~marka@135-23-92-83.cpe.pppoe.ca> has joined #yocto14:51
*** AndersD <AndersD!~anders@h83-209-191-235.cust.se.alltele.net> has joined #yocto14:54
*** marka_home is now known as marka14:54
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto14:57
*** Nilesh_ <Nilesh_!uid116340@gateway/web/irccloud.com/x-hozpyllcyctczyhb> has joined #yocto14:57
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto14:59
aratiurburton: please don't delete grub_git I need it :)15:02
aratiualso grub-efi_git.bb which I get from meta-measured15:02
aratiuI was thinking maybe to move grub-efi_git.bb from meta-measured to OE-core, there's logic duplication between these recipes15:03
kanavinwe generally need to clean up all the grub stuff15:03
*** Son_Goku <Son_Goku!~King_InuY@ool-457cb820.dyn.optonline.net> has quit IRC15:03
kanavin(as in, tidy up the recipes, not remove them :)15:03
aratiukanavin: yes, agreed15:05
rburtonwhy do we need grub-2 and grub-git15:06
rburtonif 2.00 is ancient then lets just move to a git snapshot15:06
*** rovanceo_ <rovanceo_!~rovanceo@80.97.64.55> has joined #yocto15:06
aratiurburton: that's exactly what I did with my repos15:06
*** rovanceo_ <rovanceo_!~rovanceo@80.97.64.55> has quit IRC15:06
aratiuI'm only using the git versions15:06
*** rovanceo <rovanceo!~rovanceo@80.97.64.55> has joined #yocto15:06
pohlyaratiu, sgw, armpit: there's quite some overlap between meta-security and meta-measured (trousers, tpm-tools, ...). Perhaps it would make sense to consolidate recipes in one place?15:07
kanavinrburton: or that recent beta15:07
*** ed2 <ed2!~Adium@192.198.151.45> has quit IRC15:08
*** davis <davis!~davis@50-76-27-166-static.hfc.comcastbusiness.net> has joined #yocto15:10
*** joshuagl <joshuagl!joshuagl@nat/intel/x-zhdhhmpmaueewxdv> has quit IRC15:11
*** joshuagl <joshuagl!~joshuagl@192.198.151.43> has joined #yocto15:11
davisrburton: i did the memory test overnight as you suggested.  It ran two passes and did not detect an error.15:11
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC15:12
*** jku <jku!~jku@192.198.151.44> has quit IRC15:13
*** manuel_ <manuel_!~manuel@209.6.175.242> has joined #yocto15:15
kanavinany /bin/sh experts_? Why would it refuse to run a command even though the path to it is in PATH?15:17
kanavin/var/tmp/rpm-tmp.tc1PPh: 4: /var/tmp/rpm-tmp.tc1PPh: mkdir: not found15:17
kanavin/var/tmp/rpm-tmp.tc1PPh: 6: /var/tmp/rpm-tmp.tc1PPh: cat: not found15:17
kanavin/var/tmp/rpm-tmp.tc1PPh: 28: /var/tmp/rpm-tmp.tc1PPh: cat: not found15:17
kanavinboth are in /bin and /bin is in PATH15:18
rburtoni'd triple check that $PATH isn't mangled inside the script15:21
daviskanavin: i dont know, but if you have an exe in path, but it depends upon dynamic libs, then maybe the libs are not availabe15:21
kanavindavis: it works if I specify the command with full path15:21
davisyou can test that with tthe ldd command. if you run ldd /bin/mkdir and it shows missing entries thatg woluld be the prob15:22
kanavinrburton: base-passwd_3.5.29.bb, line 8115:22
rburtonput echo $PATH in that :)15:22
kanavinrburton:15:23
kanavin/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin15:23
kanavin/var/tmp/rpm-tmp.8J8V4R: 4: /var/tmp/rpm-tmp.8J8V4R: mkdir: not found15:23
kanavin/var/tmp/rpm-tmp.8J8V4R: 6: /var/tmp/rpm-tmp.8J8V4R: cat: not found15:23
kanavin/var/tmp/rpm-tmp.8J8V4R: 28: /var/tmp/rpm-tmp.8J8V4R: cat: not found15:23
rburtonbrute force by wrap it in strace?15:23
*** Ox4 <Ox4!~user@unaffiliated/zloy> has joined #yocto15:25
kanavinrburton: works like a charm if I prepend /bin/ to cat and mkdir15:25
kanavinI guess I have to try strace, yeah15:25
*** clement_ <clement_!~clement@LStLambert-657-1-76-184.w80-13.abo.wanadoo.fr> has joined #yocto15:27
kanavinbut now ---> sushi15:27
*** clement_ <clement_!~clement@LStLambert-657-1-76-184.w80-13.abo.wanadoo.fr> has quit IRC15:27
kanavinthanks for ideas!15:27
Ox4hey, guys15:28
*** morphis <morphis!~morphis@pD9ED6304.dip0.t-ipconnect.de> has quit IRC15:28
Ox4how can I install my shared library without pkgconfig?15:28
kergothpkgconfig has nothing to do with installing. it's used to get cflags/libs/ldflags for your dependencies, or check whether your deps are installed15:29
kergothso the question really doesn't make sense15:29
Ox4so I have to use do_install function?15:31
kanavinOx4: what build system are you using?15:31
Ox4qmake15:31
kergothagain, don't understand theq uestion. whether you need to define do_install depends on your buildsystem and whether you inherit a class that does it for you, pkgconfig is irrelevent15:33
kergothperhaps you meant autoconf/automake? autotools.bbclass does define a do_install, but plenty of other classes do as well15:33
kanavinOx4: I'm not an expert in that, but try 'inherit qmake5' - I would expect that to work15:33
kergothincluding ones for qmake15:33
kergothyeah, qmake5 is a good suggestion, assuming it's qt515:33
kanavinthen you don't need to define do_* steps at all, unless your code does weird things15:34
Ox4ok, but I need my.so library be installed to /usr/lib/15:34
Ox4with symlinks15:34
kergothagain, either you define do_install to do so, or a bbclass does so15:35
kergoththe qmake class will do it15:35
*** morphis <morphis!~morphis@pD9ED6304.dip0.t-ipconnect.de> has joined #yocto15:35
Ox4ah, understood. Thank you15:36
kergothgenerally manually copying or linking files in do_install is discouraged where possible in favor of having the underlying buildsystem do it, hence the bbclass for that buildsystem usually handles it15:37
kanavingenerally writing your own do_thing() is discouraged :)15:38
kergothso if the underlying buildsystem doesn't do so properly, for example, we're better off patching it to do so than manually hacking up do_install15:38
kergothindeed15:38
kanavinit's very likely there's a class that does all the necessary steps15:38
kergoththe only real exception is hand-crafted buildsystems, custom makefile-based setups, etc15:39
*** gtristan <gtristan!~tristanva@modemcable172.18-161-184.mc.videotron.ca> has joined #yocto15:41
*** sgw_ <sgw_!~sgw_@134.134.139.72> has quit IRC15:44
mdnneoanyone ever have seen an error like this:15:45
mdnneoFile: '~/poky/meta/classes/patch.bbclass', lineno: 118, function: patch_do_patch15:45
mdnneo*** 0118:    import oe.patch15:45
mdnneoException: ImportError: No module named patch15:45
kergothmeta/lib/oe/patch.py exists, yes?15:46
mdnneoyes it does15:47
*** ernstp <ernstp!uid168075@gateway/web/irccloud.com/x-uamgfnhgzevipecn> has joined #yocto15:48
mdnneo... maybe to give a first hint why I maybe run in this ... I try to have a structure where I have some meta layers next to the poky folder not inside15:48
mdnneoand also having the build folder then next to them ... so like15:49
kergothdoesn't matter where your layers are15:50
kergothbitbake doesn't care, nor does oe-core15:50
mdnneook ... also its not a problem if i source via ... . poky/oe-init-build-en15:51
*** smferris <smferris!~smferris@192.95.10.156> has joined #yocto15:51
darknighteRP: is there a way to control the way that bbappends are applied from different layers?15:52
darknightei *thought* layer priority would make a difference, but it doesn't *seem* to ,AFAICT.15:52
RPdarknighte: You'd have to look at the code, I don't remember offhand15:54
* kergoth had thought appends were applied in priority order, but hasn't looked at the code in a while15:54
*** lemagoup <lemagoup!~lemagoup@195.190.86.18> has joined #yocto15:55
RPkergoth: I know I put a sort() in there a while back to make it deterministic15:55
RPorder from the disc wasn't good15:55
kergothah. maybe the order of operations is incorrect. we probably wnat to obey layer priorities, but where the priority is the same, use the sorted value by path, or so15:56
darknightehmmm, i have avoided looking at bitbake code much until now.15:56
darknighteRP: kergoth: would one of you point me at the code?15:56
darknighteFWIW, I would agree with kergoth on that last bit.15:56
*** gtristan <gtristan!~tristanva@modemcable172.18-161-184.mc.videotron.ca> has quit IRC15:57
*** AndersD <AndersD!~anders@h83-209-191-235.cust.se.alltele.net> has quit IRC15:57
mdnneoany way to check which python path bitbake uses?15:58
*** rajm <rajm!~robertmar@cpc14-macc3-2-0-cust149.1-3.cable.virginm.net> has quit IRC16:00
*** sgw_ <sgw_!~sgw_@134.134.139.82> has joined #yocto16:00
RPdarknighte: collect_bbfiles() and get_file_appends() in cooker.py16:01
*** csanchezdll <csanchezdll!~user@galileo.kdpof.com> has left #yocto16:01
RPdarknighte: looks like it respects BBFILES, appends found in BBFILES first get applied first16:02
RPdarknighte: so depends how the layers build BBFILES16:03
kergothah, so it's based on BBLAYERS order, not layer priority. that's potentially confusing, since layer priority usually affects recipes, and bbpath/bbfiles is more about classes and config files and whatnot16:03
kergothhmm16:03
*** fl0v0 <fl0v0!~fvo@pD9F6B04A.dip0.t-ipconnect.de> has joined #yocto16:04
* darknighte checks on layer ordering16:05
kergothdarknighte: note that if you used the mel setup script and added all layers with -l, not manually, the bblayers order should reflect the bbfile priority, but you'd have to re-source after changing the priority to re-sort16:07
darknightekergoth: thanks for the tip.  in this case, I did that with all but my two manual layers, which I added to the bottom of bblayers.conf.16:08
kergothah, that would put them last in bblayers, so last in bbfiles (since your layers probably += to BBFILES, anyway)16:08
darknightethat sounds right16:09
darknightemore accurately, that jives with what I'm seeing.16:10
darknightenot sure if it makes a difference, but I'm using bitbake v.1.28.016:11
darknightehmmm, so, the order of the config fragment does not appear to follow the BBFILES or layer ordering16:14
*** graphiqs <graphiqs!~adrian.gr@217.6.37.53> has quit IRC16:18
darknightebblayers has layer-a, then layer-b, with prios of 5 and 6 respectively, both with appends to a kernel recipe16:21
darknightehowever, the frag in layer-b shows up before the frag in layer-a.16:22
darknightemaking the prio of layer-b a 4 has no apparent effect16:22
kergothas i said yesterday, use bitbake -e yourrecipe to examine how SRC_URI was constructed. you'll see what was applied to it in what order16:23
kergotheither source the setup scripts after changing priorities, or just manually move your layers to the top/beginning of BBLAYERS manually16:24
darknighteright, I have.  it shows the order in BBFILES of layer-a then layer-b, but SRC_URI shows config frag in the other order16:24
mdnneohmmm ... ok ... seems like it's a bad idea to change the default BBLAYERS variable from /the/absolute/path/prj/poky/meta \ to ../poky/meta in the bblayers.conf file16:24
kergoththat's correct, yes, as the current directory changes during the bitbake build16:25
mdnneoso it's also not smart to do it for "my" custom layers?16:25
darknightekergoth: k, I'll try manually re-ordering the bblayers and see if that has the desired result16:26
kergothmdnneo: you shouldn't be using relative paths in BBLAYERS at all. what layers you happen to include isn't relevant16:26
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC16:27
kergothmdnneo: you could, however, use paths relative to ${TOPDIR} if you know ahead of time where the build directory is relative to the layer paths16:27
*** jku <jku!~jku@dyj2xzycrv18---3wlh9y-3.rev.dnainternet.fi> has joined #yocto16:27
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto16:29
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has quit IRC16:32
Ox4one more question: I have hpp file installed to image/usr/include and in the another package I have #define "this_file.hpp" in the source code. But I have a compilation error that there is no this_file.hpp16:32
Ox4sorry for my english :-(16:32
*** dv_ <dv_!~quassel@62.178.118.86> has quit IRC16:33
*** fl0v0 <fl0v0!~fvo@pD9F6B04A.dip0.t-ipconnect.de> has quit IRC16:33
*** dv_ <dv_!~quassel@62-178-118-86.cable.dynamic.surfer.at> has joined #yocto16:33
*** aV_V <aV_V!~aV_V@146.66.253.137> has quit IRC16:36
kergothYou used "" rather than <>16:37
mdnneoOx4: just some wild guess but first it is #include "this_file.hpp", or and if can you try to change to #inlcude_<this_file.hpp>16:37
kergothwhich, incidentally, would have failed even outside of oe/yocto :)16:38
mdnneoOx4: if it is realy define shouldn't it look like #define MY_HEADER "foo.h"16:38
kergothindeed, i figured he was trying to include the thing16:38
kergothweird16:38
mdnneoactually AFAIK "" should look in the inc path as well ... but u never know16:39
*** aehs29 <aehs29!~aehernan@134.134.139.82> has joined #yocto16:41
Ox4yes, as I know "" looks in the local directory and then in the inc path16:43
mdnneoOx4: still would give it a try ... and maybe also just like kergoth mentioned the error should be independent of yocto ... try to build via the SDK for example maybe gives some clue on what went wrong16:46
*** joseppc <joseppc!~josep@linaro/joseppc> has quit IRC16:48
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto16:49
*** ziggo <ziggo!~ziggo@212.118.209.82> has quit IRC16:50
darknightekergoth: RP: I just found out that one of the layers I've 'inherited' has two 'collections' defined.  what problems might this create?16:52
kergothshouldn't be a problem, afaik16:52
*** locutus_ <locutus_!~Gianfranc@109.112.75.128> has joined #yocto16:52
RPdarknighte: right, shouldn't be an issue16:53
RPkergoth: wouldn't it me nice to go and simplify all this stuff...16:53
darknightethx16:53
RPkergoth: I've been idly thinking of merging process and xmlrpc server backends and removing the server abstraction16:55
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC16:56
*** mdnneo <mdnneo!~umaucher@217.89.178.116> has quit IRC16:56
kergothcould make sense. could always add an *option* to also listen on another port for xml/rpc control if someone really needs to control bitbake from a different language, rather than having it as a separate server type16:56
kergothanything we can do to simplify the codebase would be good16:57
RPkergoth: right, the idea would just be to optionally listen for xmlrpc on a port16:57
*** zeenix <zeenix!~zeenix@83.218.80.242> has quit IRC17:00
* kergoth nods, would be on board with that idea17:02
*** ziggo <ziggo!~ziggo@217.89.178.116> has joined #yocto17:06
Ox4kergoth: thank you, it works now17:09
*** boucman_work1 <boucman_work1!~jrosen@fw-alt.idf.smile.fr> has quit IRC17:10
*** geoffrey_l <geoffrey_l!~geoffrey_@fw-alt.idf.smile.fr> has quit IRC17:10
*** TobSnyder <TobSnyder!~schneider@ip9234b0ae.dynamic.kabel-deutschland.de> has quit IRC17:10
*** JosePerez <JosePerez!~jgperezc@134.134.139.83> has joined #yocto17:12
*** hamis <hamis!~irfan@110.93.212.98> has quit IRC17:13
*** mckoan is now known as mckoan|away17:13
*** JosePerez <JosePerez!~jgperezc@134.134.139.83> has left #yocto17:16
*** JosePerez <JosePerez!~jgperezc@134.134.139.83> has joined #yocto17:16
*** Kakounet <Kakounet!~Thunderbi@che44-1-88-163-87-53.fbx.proxad.net> has quit IRC17:19
*** stephano <stephano!~stephano@134.134.139.72> has joined #yocto17:20
*** locutus_ <locutus_!~Gianfranc@109.112.75.128> has quit IRC17:22
*** ed2 <ed2!~Adium@192.198.151.45> has joined #yocto17:23
*** Nilesh_ <Nilesh_!uid116340@gateway/web/irccloud.com/x-hozpyllcyctczyhb> has quit IRC17:24
*** anselmolsm <anselmolsm!~anselmols@2601:1c0:5402:7e90:adb0:54e3:3604:dd91> has joined #yocto17:26
* RP triggers a morty 2.2.1 build17:28
*** khem <khem!~khem@unaffiliated/khem> has quit IRC17:31
rburtonRP: huh i see what you mean about selftest taking ages to load tests17:32
rburtonit didn't do it earlier when i was running archiver tests, but just started the devtool tests and its hanging at loading tests17:33
rburtonbitbake cooker/processqueue/knotty are pinning the CPU17:33
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto17:38
*** Ox4 <Ox4!~user@unaffiliated/zloy> has left #yocto17:38
*** locutus_ <locutus_!~Gianfranc@109.112.75.128> has joined #yocto17:40
khemI am seeing Can NOT get PRAUTO, exception timed out17:43
khemon archlinux17:43
khemuses python 3.617:43
khemlatest master, I saw someone else reporting it as well17:44
rburtonyay arch ;)17:45
rburtonyes, someone else reported that 3.6 was broken and they moved back to 3.something else and it worked17:45
*** locutus_ <locutus_!~Gianfranc@109.112.75.128> has quit IRC17:46
*** Strike5150 <Strike5150!18de02de@gateway/web/freenode/ip.24.222.2.222> has joined #yocto17:51
*** Son_Goku <Son_Goku!~King_InuY@172.58.216.238> has joined #yocto17:52
georgemkhem: yeah. me too. had to downgrade to 3.5.217:52
georgemkhem: sudo pacman -U cd /var/cache/pacman/pkg/python-3.5.2-3-x86_64.pkg.tar.xz cd /var/cache/pacman/pkg/pyalpm-0.8-1-x86_64.pkg.tar.xz got it working again for me for now17:54
georgemerr...  sudo pacman -U /var/cache/pacman/pkg/python-3.5.2-3-x86_64.pkg.tar.xz /var/cache/pacman/pkg/pyalpm-0.8-1-x86_64.pkg.tar.xz17:54
*** Son_Goku <Son_Goku!~King_InuY@172.58.216.238> has quit IRC17:56
-YoctoAutoBuilder- build #427 of nightly-checkuri is complete: Failure [failed BuildImages] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-checkuri/builds/42717:58
ed2RP: image*.class code looks quite messy. Would it make sense to split it to several files - one file per image type?18:03
RPed2: definitely not, that would result in a lot of files18:04
RPed2: I'm open to better partitioning of the existing files though or splitting out where it makes sense and isn't too granular18:05
RPrburton: I have wondered why my build machine sounds like its chewing cpu18:05
*** toscalix <toscalix!~toscalix@90.170.203.139> has quit IRC18:05
* RP runs top, sees guile and decides to head afk18:05
ed2RP: I'm going to move wic-related code to wic.class. It's quite a bit of code, I'd say.18:05
RPed2: wic could make sense but maybe as image_wic.bbclass ?18:06
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC18:08
*** ernstp <ernstp!uid168075@gateway/web/irccloud.com/x-uamgfnhgzevipecn> has quit IRC18:08
ed2RP: image-wic.bbclass would be more consistent with existing image-vm.bbclass image-prelink.bbclass etc18:08
*** toanju <toanju!~toanju@185.27.182.30> has quit IRC18:08
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto18:08
Strike5150I've built the same image on qemux86 and "intel-core2-32" machine, on the "intel-core2-32" /var/log is linked to /var/volatile/log as one would expect but the folder /var/volatile/log is missing. As well as other things I may not be aware of.  Does this ring a bell with anyone?18:14
Strike5150I'm building on Ubuntu 16.04 Krogoth modified core-minimal18:14
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto18:15
*** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has quit IRC18:20
*** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has joined #yocto18:21
rewittStrike5150: It's missing on the device or in the build rootfs?18:23
rewittStrike5150: Because the directory is created by initscripts from what I can tell18:23
alimonpohly: i upgraded qemu to 2.8.0, i'm doing some testing in arm, ppc, mips, x86 before send the patch to the ML18:25
Strike5150rewitt: Its missing from the rootfs18:25
rewittStrike5150: Ok that makes sense because it gets created on boot18:26
Strike5150rewitt:  I'll have a look at initscripts see whats going on there18:26
rewittStrike5150: Hence the "volatile" part18:26
khemdowngrading python is a workaround, however sooner or later this will hit bitbake18:27
Strike5150rewitt:  does volatile in this context mean wiped each power cycle?18:27
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has quit IRC18:27
*** bavery_fn <bavery_fn!~bavery@134.134.139.77> has joined #yocto18:35
rewittStrike5150: It shouldn't I don't believe, that is to say once the directory is created it shouldn't need to created it next boot18:36
Strike5150rewitt:  Ok so volatile means might move around based on machine type or something along those lines, not volatile during runtime18:37
*** ftonello <ftonello!~felipe@host81-152-92-225.range81-152.btcentralplus.com> has quit IRC18:37
*** grma <grma!~gruberm@80.93.38.128> has quit IRC18:37
*** bavery_fn <bavery_fn!~bavery@134.134.139.77> has quit IRC18:41
Strike5150I can see that initscripts package installs ./populate-volatile.sh, and it is supposed to look at /etc/default/volatiles and add everything in those files.  Of which "l root root 0755 /var/log /var/volatile/log" is there.  But running it does nothing ...18:42
Strike5150not even an error18:43
*** paulg <paulg!~paulg@198-84-239-75.cpe.teksavvy.com> has quit IRC18:43
rewittStrike5150: It really is volatile between boot, and I'm not sure why it is that way by default. There is even a person asking about it in a bug. https://bugzilla.yoctoproject.org/show_bug.cgi?id=3397#c718:44
yoctiBug 3397: normal, Medium, 1.4 M4, Qi.Chen, RESOLVED NOTABUG, /var/log and /var/cache should not be on volatile storage (tmpfs)18:44
*** psadro <psadro!~Thunderbi@216.234.148.135> has quit IRC18:44
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has joined #yocto18:44
rewittStrike5150: Now why it isn't in the rootfs at build time I don't know, but it shouldn't be a problem because that script also gets ran on boot, everytime.18:45
*** likewise <likewise!~chatzilla@145.132.74.106> has joined #yocto18:46
Strike5150So I can verify the script does run, but it doesn't add /var/volatiles/log18:46
Strike5150I know this will work properly if I change machine type to qemux8618:47
*** pohly <pohly!~pohly@p5DE8EC30.dip0.t-ipconnect.de> has quit IRC18:47
Strike5150That is the only change I made between these two versions18:47
*** themikenicholson <themikenicholson!~nic47222@38.140.22.3> has joined #yocto18:47
rewittStrike5150: Ah so meta-intel changes it's behavior, I see18:47
Strike5150It seems to yea18:48
rewittclsulliv: You around to help out Strike5150?18:48
rewittStrike5150: I was missing the behavior being *different*, sorry18:49
Strike5150heh np, thanks for helping me understand it18:49
themikenicholsonThis might be a stupid question, but is there any kind of version manager for the ADT, similar to the android sdkmanager tool?18:50
Strike5150I can't find any reference to ./populate-volatile.sh or to initscripts in meta-intel18:50
rewittthemikenicholson: As far as I know there isn't. But if you build an extensible sdk, one of it's features is to be updatable.18:52
rewittStrike5150: Could you maybe in one sentence describe the issue again? That way I can easily chuck it to one of the meta-intel people18:54
rewittStrike5150: s/one sentence/concisely :)18:55
*** aehs29 <aehs29!~aehernan@134.134.139.82> has left #yocto18:55
Strike5150rewitt: Ok I'll do that18:56
Strike5150rewitt:  I hope I just messaged you, or that you at least received the sentance in some form :D18:59
rewittStrike5150: Yep got it18:59
Strike5150rewitt:  Ok great thanks for the support19:00
themikenicholsonrewitt: Looking at the user guide now,  specifically I'm looking for a way to rev the ADT and even let users install multiple ADT versions simultaneously. Ideally we'd have a file in our application repo calling out what ADT version a specific branch of the application should build against.19:00
rewittStrike5150: If you can I'd honestly suggest sending that to the meta-intel mailing list, easier for them to get back to you that way. https://lists.yoctoproject.org/listinfo/meta-intel19:01
rewittStrike5150: I should have said that originally, my bad19:01
Strike5150rewitt: no problem, knowing where to send it is half the battle.19:02
rewittthemikenicholson: You couldn't have multiple extensible sdk's at the same time, outside of having multiple directories19:03
rewittthemikenicholson: But theoretically you could change between revisions, i.e. update actually means "switch rev"19:03
*** jhar <jhar!~har@50-253-112-214-static.hfc.comcastbusiness.net> has joined #yocto19:03
themikenicholsonrewitt: switching rev might be a possibility, although our build machines would have to maintain a per-branch ADT somehow.. We need to do things like build hot-fix releases on an older version of an ADT while building an in-development version with a newer ADT19:05
themikenicholsonWe're coming from ltib where we had the entire ltib tree and packages checked into the applications repo so managing version of the rootfs happened naturally19:06
*** bluelightning <bluelightning!~paul@118.148.113.65> has joined #yocto19:06
*** bluelightning <bluelightning!~paul@118.148.113.65> has quit IRC19:06
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:06
rewittthemikenicholson: Well the way it works is that it's all based on the metadata/recipes, it leverages sstate. So just like we can backport things to yocto 2.1, you should be able to do a similar thing19:07
themikenicholsonrewitt: Just starting to look into this.  I'll spend more time with the user guide and mess around some more.  Thanks for sending me on the right path.19:08
rewittthemikenicholson: Don't thank me yet :), you may realize it doesn't meet your needs. But if it doesn't we'd really be interested in hearing where it could be improved.19:09
themikenicholsonrewitt: We're just starting to switch from LTIB and an internal build tool that did some of the same things as the extensible ADT, etc.  Should be interesting, hopefully we can give something back.19:11
*** themikenicholson <themikenicholson!~nic47222@38.140.22.3> has quit IRC19:12
*** nic47222 <nic47222!~nic47222@38.140.22.3> has joined #yocto19:13
*** hbruce <hbruce!~hbruce@134.134.139.82> has joined #yocto19:19
*** nic47222 is now known as themikenicholson19:21
*** paulg <paulg!~paulg@otwaon23-3096772825.sdsl.bell.ca> has joined #yocto19:26
*** JosePerez <JosePerez!~jgperezc@134.134.139.83> has quit IRC19:31
*** JosePerez <JosePerez!~jgperezc@134.134.139.83> has joined #yocto19:35
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC19:40
*** soderstrom <soderstrom!~soderstro@h-176-10-249-246.na.cust.bahnhof.se> has joined #yocto19:41
*** aehs29 <aehs29!~aehernan@134.134.139.74> has joined #yocto19:42
*** toanju <toanju!~toanju@x5ce49dff.dyn.telefonica.de> has joined #yocto19:43
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto19:43
*** sameo <sameo!~samuel@192.55.54.36> has quit IRC19:45
*** t0mmy <t0mmy!~tprrt@ram31-1-82-234-79-177.fbx.proxad.net> has joined #yocto19:53
Strike5150I have run into an issue where sort.coreutils when being run produces Illegal instruction.  This is why populate-volatile.sh is failing, its using a sort to sort the /etc/default/voltailes files and execute them in order19:59
Strike5150So unrelated to meta-intel or anything intel Yay :D20:01
*** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has joined #yocto20:01
*** gtristan <gtristan!~tristanva@206.108.167.141> has joined #yocto20:06
*** berton <berton!~berton@189.114.111.135> has quit IRC20:14
rewittStrike5150: So the compiler is generating bad code?20:22
*** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-zzxklovwdzonglby> has quit IRC20:23
*** hbruce <hbruce!~hbruce@134.134.139.82> has quit IRC20:25
rburtonStrike5150: illegal instruction sounds exactly like something related to meta-intel.  what hardware are you running on?20:26
* rburton reads backtrace a bit20:27
rburtonnote that if you're running a meta-intel intel-core2-32 image in qemu then you;ll need to pass options to qemu to tell it to emulate a core220:29
rburtonwe should make the bsp do that automatically now that runqemu is more flexible20:29
rburtonbut basically if you're running stuff in a qemu session then use a qemu machine, they're faster20:29
rburton(and better adapted for the virtual hardware)20:29
*** nighty <nighty!~nighty@s229123.ppp.asahi-net.or.jp> has quit IRC20:35
*** dmoseley1 <dmoseley1!~dmoseley@65-35-172-144.res.bhn.net> has joined #yocto20:36
*** dmoseley <dmoseley!~dmoseley@65-35-172-144.res.bhn.net> has quit IRC20:36
*** Son_Goku <Son_Goku!~King_InuY@47.19.105.250> has joined #yocto20:37
*** catch22_ <catch22_!~aboseley@101.165.216.251> has joined #yocto20:44
*** JaMa <JaMa!~martin@217.30.68.212> has quit IRC20:44
ed2aehs29: hi, I'm looking at your change gummiboot->systemd-boot. are we getting rid of gummiboot? we still have mkgummidisk.wks and gummiboot.bbclass though.20:46
ed2aehs29: wic fails to build mkgummiboot image: Error: unrecognized bootimg-efi loader: gummiboot20:47
JEEBdid gummiboot get anywhere after it was taken in by the systemd project?20:48
JEEBI just remember the changes stopping on the gummiboot side20:48
ed2JEEB: even if it didn't it's quite strange to be able to set EFI_PROVIDER = 'gummiboot' and not being able to build an image.20:49
JEEBtrue20:49
JEEBcould be an overlook in the testing department20:50
ed2it should be either completely removed or made backwards compatible20:50
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc> has quit IRC20:52
*** Son_Goku <Son_Goku!~King_InuY@47.19.105.250> has quit IRC20:53
*** t0mmy <t0mmy!~tprrt@ram31-1-82-234-79-177.fbx.proxad.net> has quit IRC20:54
kergothed2: there's a pending patch series to remove gummiboot entirely21:00
kergothhasn't been merged yet21:00
ed2kergoth: ah, now i understand. thank you21:01
*** seebs <seebs!~seebs@home.seebs.net> has quit IRC21:06
*** dcobbley <dcobbley!dacobble@nat/intel/x-mxodwjrwuuaiqops> has quit IRC21:13
aehs29ed2: theres a patch already to remove those as well21:14
aehs29ed2: systemd-boot already replaces gummiboot completely21:14
ed2aehs29: thanks. I'll not touch it then.21:15
aehs29ed2: so theres 4 patches regarding the gummiboot change I think, I dont know why only 2 are merged, the others are on ross/mut21:16
ed2aehs29: ok, let's wait then.21:16
*** kscherer <kscherer!~kscherer@128.224.252.2> has quit IRC21:22
*** vmeson <vmeson!~rmacleod@128.224.252.2> has quit IRC21:22
*** ed2 <ed2!~Adium@192.198.151.45> has quit IRC21:24
*** arkver <arkver!~arkver@host86-154-139-39.range86-154.btcentralplus.com> has quit IRC21:36
*** jku <jku!~jku@dyj2xzycrv18---3wlh9y-3.rev.dnainternet.fi> has quit IRC21:38
*** hbruce1 <hbruce1!~hbruce@134.134.139.82> has joined #yocto21:46
*** arkver <arkver!~arkver@149.254.248.116> has joined #yocto21:48
*** ftonello <ftonello!~felipe@host81-152-92-225.range81-152.btcentralplus.com> has joined #yocto21:54
*** arkver <arkver!~arkver@149.254.248.116> has quit IRC21:57
*** gtristan <gtristan!~tristanva@206.108.167.141> has quit IRC21:58
*** seebs <seebs!~seebs@home.seebs.net> has joined #yocto21:59
*** toanju <toanju!~toanju@x5ce49dff.dyn.telefonica.de> has quit IRC22:03
-YoctoAutoBuilder- build #1014 of build-appliance is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/build-appliance/builds/101422:03
*** clopez <clopez!~tau@neutrino.es> has quit IRC22:04
*** paulg <paulg!~paulg@otwaon23-3096772825.sdsl.bell.ca> has quit IRC22:08
*** clopez <clopez!~tau@neutrino.es> has joined #yocto22:09
*** arkver <arkver!~arkver@149.254.248.116> has joined #yocto22:10
*** bavery_fn <bavery_fn!~bavery@134.134.139.77> has joined #yocto22:11
*** arkver <arkver!~arkver@149.254.248.116> has quit IRC22:12
*** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has quit IRC22:13
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC22:14
*** bavery_fn <bavery_fn!~bavery@134.134.139.77> has quit IRC22:24
*** ftonello <ftonello!~felipe@host81-152-92-225.range81-152.btcentralplus.com> has quit IRC22:25
*** sameo <sameo!~samuel@192.55.54.45> has joined #yocto22:30
*** paulg <paulg!~paulg@198-84-239-75.cpe.teksavvy.com> has joined #yocto22:32
RParmpit: based on your build results and branch contents I merged morty-next, added the fixes for multiconfig and then have triggered a 2.2.1 build22:32
*** marka <marka!~marka@135-23-92-83.cpe.pppoe.ca> has quit IRC22:33
*** gtristan <gtristan!~tristanva@206.108.167.141> has joined #yocto22:40
*** joshuagl <joshuagl!~joshuagl@192.198.151.43> has quit IRC22:41
*** ntl <ntl!~nathanl@99-127-51-4.lightspeed.austtx.sbcglobal.net> has quit IRC22:44
*** JosePerez <JosePerez!~jgperezc@134.134.139.83> has quit IRC22:46
*** Snert_ <Snert_!~snert_@65.74.8.146> has quit IRC22:50
*** Snert_ <Snert_!~snert_@65.74.8.146> has joined #yocto22:51
*** manuel_ <manuel_!~manuel@209.6.175.242> has quit IRC22:55
*** bfederau <bfederau!~quassel@service.basyskom.com> has quit IRC23:01
*** fmeerkoetter <fmeerkoetter!~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
*** soderstrom <soderstrom!~soderstro@h-176-10-249-246.na.cust.bahnhof.se> has quit IRC23:09
*** lamego <lamego!jose@nat/intel/x-zthwfixgbckcnjhz> has quit IRC23:10
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has joined #yocto23:12
linuxjacqueshi, it's been a long time since I've used OE/yocto - how do I get around the fact that http://www.zlib.net/zlib-1.2.8.tar.xz is 404 ? I have the file, but just putting it in downloads does not work - I don't understand the format of the .done files23:13
*** aehs29 <aehs29!~aehernan@134.134.139.74> has left #yocto23:17
Crofton|worklinuxjacques, you need the .md5 file I think23:22
Crofton|workwhat version are you using?23:22
linuxjacquesCrofton|work, morty23:22
Crofton|workhmm23:22
Crofton|workthat should be fixed ASAP23:22
Crofton|workis it really 404, or just temporary fetch issue?23:23
linuxjacquesI see even master branch still uses 1.2.823:23
*** agust <agust!~agust@p4FCB4571.dip0.t-ipconnect.de> has quit IRC23:23
linuxjacquesCrofton|work, not sure - I can get to the site - it's possible it was removed because of a security issue (?)23:23
Crofton|workI get 404 also23:24
linuxjacquesI can download 1.2.10, but not 1.2.8 nor 1.2.923:24
RPlinuxjacques: that upstream just has a policy of sharing latest version only. If you configure other source mirrors it should work23:26
RPlinuxjacques: see poky.conf for an example mirror that no doubt has it23:26
RPlinuxjacques: we did change the url in master to one that works btw23:28
RPlinuxjacques: so you could use that too23:28
linuxjacquesRP, thanks23:29
*** likewise <likewise!~chatzilla@145.132.74.106> has quit IRC23:30
linuxjacquesyeah, it seems a lot happier now23:31
*** likewise <likewise!~chatzilla@145.132.74.106> has joined #yocto23:32
*** Noor <Noor!~quassel@110.93.212.98> has quit IRC23:32
*** manuel_ <manuel_!~manuel@honeydew.cictr.com> has joined #yocto23:33
*** Noor <Noor!~quassel@110.93.212.98> has joined #yocto23:33
*** Son_Goku <Son_Goku!~King_InuY@47.19.105.250> has joined #yocto23:37
*** Biliogadafr <Biliogadafr!~PIN@nat-minsk-pool-46-53-202-120.telecom.by> has quit IRC23:39
*** rburton <rburton!~Adium@81.2.106.35> has quit IRC23:40
*** manuel_ <manuel_!~manuel@honeydew.cictr.com> has quit IRC23:45
*** likewise <likewise!~chatzilla@145.132.74.106> has quit IRC23:51
*** manuel_ <manuel_!~manuel@204.9.220.50> has joined #yocto23:52
*** hbruce1 <hbruce1!~hbruce@134.134.139.82> has quit IRC23:59

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!