IRC log for #oe on 20160321

00:34.25*** join/#oe evanmeagher (~MongooseW@73.71.33.109)
02:10.43*** join/#oe NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey)
02:16.45*** join/#oe coolmouse (~coolmouse@113.201.248.106)
02:19.24*** join/#oe coolmouse_ (~coolmouse@113.201.248.106)
02:20.47*** join/#oe evanmeagher (~MongooseW@73.71.33.109)
03:25.49*** join/#oe dlan (~dennis@gentoo/developer/dlan)
03:38.02*** join/#oe zxc678 (~zxc678@192.3.173.186)
03:39.37*** join/#oe zxc678 (~zxc678@192.3.173.186)
03:44.02zxc678i have a question, it is i add package i2c-tools by IMAGE_INSTALL in local.conf (core-image-x11.bb also tried), after compile deploy image, the download to sdcard to boot arm board, and get error :  sh: cannot set terminal process group (-1): inapropriate ioctl for device, so  how to  solve it? why
03:52.19*** join/#oe bpittman (~bill@130.164.62.212)
03:54.25*** join/#oe zxc678 (~zxc678@192.3.173.186)
03:55.42zxc678expect answer for my question. what confict for i2c-tools with sth in kernel
04:06.24bluelightningzxc678: installing i2c-tools seems like an unlikely trigger for such a bootup error
04:06.46bluelightningzxc678: have you tried commenting that out again to see if it's really that?
04:42.03zxc678no, shell not work ,so i cant try it
04:45.33zxc678the last output lines is
04:46.12zxc678freeing unused kernel memeory:328k(80d23000-80d75000)
04:46.38zxc678sh: cannot set terminal process group (-1) : inappropriate ioctl for device
04:46.46zxc678sh: no job control in this shell
04:46.53zxc678sh-4.3#
04:47.15zxc678shell not wok, i cant input command to try anything
04:48.51zxc678ok, i also delete the IMAGE_INSTALL += "i2c-tools", then recomplie and run image, it work well
04:49.05zxc678so the issue is from i2c-tools
04:53.12zxc678bluelightning: and then?
05:13.43*** join/#oe fischerm (~mfischer@207-114-172-147.static.twtelecom.net)
05:17.42bluelightningzxc678: it sounds a bit like for some reason the init system isn't being started, instead you're being put into a shell
05:17.47bluelightningI have no idea why that would be the case
05:20.36*** join/#oe _fortis (~fortis@static.100.25.4.46.clients.your-server.de)
05:22.51bluelightningzxc678: oh, I think I figured it out
05:23.21bluelightningzxc678: I suspect that IMAGE_INSTALL is trashing your initramfs because it applies to every image built by the system (which includes the initramfs)
05:23.52bluelightningzxc678: I would suggest CORE_IMAGE_EXTRA_INSTALL += "i2c-tools" instead
05:24.21bluelightningzxc678: even better, create your own custom image recipe instead - it's trivially easy, just copy the image recipe you want to start with and edit it
06:08.18*** join/#oe AndersD (~anders@213-64-219-84-no126.business.telia.com)
07:10.19*** join/#oe morphis (~morphis@2001:67c:1560:8007::aac:c152)
07:17.22*** join/#oe Nilesh__ (uid116340@gateway/web/irccloud.com/x-sldijhvxxknewisp)
07:42.59*** join/#oe georgem (~georgem@216-21-169-52.slc.googlefiber.net)
07:56.37*** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-uubkbwhvncwvouzb)
07:58.30*** join/#oe mckoan (~marco@unaffiliated/mckoan)
07:58.54*** join/#oe anarsoul (~anarsoul@S0106848dc7ec0367.vs.shawcable.net)
08:00.35*** join/#oe jku (jku@nat/intel/x-bxbnxlcdhaobxooi)
08:07.53*** join/#oe ant_work (~ant__@host71-255-dynamic.4-87-r.retail.telecomitalia.it)
08:16.00*** join/#oe AndersD (~anders@213-64-219-84-no126.business.telia.com)
08:23.04*** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net)
08:24.52*** join/#oe phdeswer (~phdeswer@auth.nomovok.info)
08:25.34*** join/#oe t0mmy (~tprrt@217.114.201.133)
08:28.40*** join/#oe coolmouse (~coolmouse@113.201.248.106)
08:30.58*** join/#oe coolmouse_ (~coolmouse@113.201.248.106)
08:32.50mckoangood morning
08:38.40zxc678I will try, thanks
08:45.58*** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian)
08:50.58*** join/#oe joshuagl (~joshuagl@192.198.151.43)
08:57.46*** join/#oe joseppc (~Josep@sestofw01.enea.se)
09:00.41*** join/#oe yann|work (~yann@LFbn-1-1026-146.w86-247.abo.wanadoo.fr)
09:04.23*** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029)
09:23.52*** join/#oe jonathanmaw (~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk)
09:31.46*** join/#oe ecloud (quassel@nat/digia/x-fclwnvhtnzhsskqs)
09:38.34*** join/#oe JaMa (~martin@ip-86-49-34-37.net.upcbroadband.cz)
09:40.07*** join/#oe diego_r (~diego@host65-246-static.10-188-b.business.telecomitalia.it)
09:48.36*** join/#oe edbart (~ebartosh@192.198.151.44)
10:11.54*** join/#oe belen (~Adium@134.134.139.77)
10:13.53*** join/#oe belen (~Adium@134.134.139.77)
10:39.32*** join/#oe rburton (~Adium@home.burtonini.com)
10:46.59*** join/#oe vdehors (~vdehors@LAubervilliers-656-1-228-141.w80-14.abo.wanadoo.fr)
11:03.55mario-goulartHi.  Does PREMIRROR actually mirror git repositories?  As far as I can see, it doesn't, unless BB_GENERATE_MIRROR_TARBALLS is used.  Is that correct?
11:05.13*** join/#oe cesdv (~cesdv@client-188-168-43-165.spb-teleport.ru)
11:14.50rburtonthe mirror needs to use that variable, yes
11:17.40mario-goulartrburton: isn't it possible to make the mirror provide a git repo that can be cloned by the requester?  The scenario I have here is a dedicated build environment which doesn't actually build, only runs "bitbake -c fetchall image" to populate DL_DIR, which is shared among the actual builders.
11:18.52mario-goulartBut requests for git repos are not resolved in the mirror, so builders end up fetching from upstream repos.
11:19.34mario-goulartIIUC, BB_GENERATE_MIRROR_TARBALLS would generate a tarball for each revision in SRCREV, right?
11:22.22rburtonerm, pass.
11:27.09mario-goulartOk, thanks anyway.
11:37.32*** join/#oe ldnunes (~ldnunes_@187.23.154.250)
11:46.18*** join/#oe morphis_ (~morphis@p50862416.dip0.t-ipconnect.de)
11:47.03*** join/#oe vdehors (~vdehors@LAubervilliers-656-1-228-141.w80-14.abo.wanadoo.fr)
11:50.29*** join/#oe morphis (~morphis@p50862416.dip0.t-ipconnect.de)
11:54.07*** join/#oe berton (~fabio@187.23.154.250)
11:54.31*** join/#oe phdeswer (~phdeswer@auth.nomovok.info)
12:05.55*** join/#oe cesdv (~cesdv@client-188-168-43-165.spb-teleport.ru)
12:08.45*** join/#oe blitz00 (stefans@unaffiliated/blitz00)
12:25.32*** join/#oe vmeson (~rmacleod@128.224.252.2)
12:29.49dv_is it just my impression, or has it become easier to use oe/yocto with arch linux?
12:29.53dv_in the past, it was a complete disaster
12:30.37*** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net)
12:35.57*** join/#oe caiortp (~inatel@131.221.240.204)
12:50.58*** join/#oe maxin (~maxin@2001:998:22:0:704c:6bd:f245:deb5)
13:20.32*** join/#oe dv_ (~quassel@chello062178118086.5.14.vie.surfer.at)
13:23.59*** join/#oe coolmouse (~coolmouse@113.201.248.106)
13:26.28*** join/#oe coolmouse_ (~coolmouse@113.201.248.106)
13:38.16*** join/#oe joshuagl (joshuagl@nat/intel/x-hawslilaviguvryz)
13:44.22*** join/#oe vmeson (~rmacleod@128.224.252.2)
13:44.42*** join/#oe dv_ (~quassel@chello062178118086.5.14.vie.surfer.at)
13:52.21rburtondv_: other distros have caught up and arch hasn't yet gone blazing ahead yet
13:52.35rburtonits not like arch is the only distro shipping gcc5, for example
13:53.09rburtonthe the most recent "build breaks on my host distro" was on gentoo, so arch is slacking to be honest
13:56.52*** join/#oe kscherer (~kscherer@128.224.252.2)
14:16.39*** join/#oe vdehors (~vdehors@LAubervilliers-656-1-228-141.w80-14.abo.wanadoo.fr)
14:22.37*** join/#oe ChrisD1_Away (~ChrisD@merak.alcor.co.uk)
14:50.31*** join/#oe morphis (~morphis@p50862416.dip0.t-ipconnect.de)
14:54.21*** join/#oe galak (~galak@104-57-189-103.lightspeed.austtx.sbcglobal.net)
15:01.24*** join/#oe ChrisD1_Away (~ChrisD@merak.alcor.co.uk)
15:21.06kergothmario-goulart: premirrors should be able to handle fetching from an actual git repo mirror, if the right side resolves to a git:// uri
15:29.36mario-goulartkergoth: you mean it cannot be a file:// uri? (It is in the current case, as it is an NFS share).
15:29.48kergothyou're misunderstanding how the fetcher works
15:29.58kergoththe url scheme controls which fetcher is used, not the underlying communications protocol
15:30.05kergothfile:// will literally just copy some files locally
15:30.09kergothgit:// will use git
15:30.18kergothif you want to fetch a local git repo, use ;protocol=file on the end of the uri
15:30.34mario-goulartI see.  Thanks for the explanation.
15:30.37kergothnp
15:30.53mario-goulartWould that work for svn too?
15:30.55kergothlooking back, it'd be nice to support the + separated scheme which is used by lots of projects nowadays
15:31.00kergothi.e. pip will use git+https://
15:31.14mario-goulartgood point
15:31.16kergothnot sure offhand, you could check the svn fetcher code
15:31.26kergothor just try it :)
15:31.33mario-goulartWill do.  Thanks again. :-)
15:31.49kergothnp
15:33.31kergoththe use of scheme for fetcher does lead to confusion, perhaps we should have gone the other way around, i.e. file://foo.git;fetcher=git, or something, but it's a bit late for that now :)
15:35.08mario-goulart:-)
15:37.47*** join/#oe riz___ (4a69aefe@gateway/web/freenode/ip.74.105.174.254)
15:44.12*** join/#oe hrw (~hrw@redhat/hrw)
15:45.09*** join/#oe mattsm (uid128834@gateway/web/irccloud.com/x-dmezvmztbvieetbj)
15:49.20*** join/#oe AndersD (~anders@h83-209-191-235.dynamic.se.alltele.net)
15:51.09*** join/#oe edbart (~ebartosh@192.198.151.44)
16:11.42riz___After adding meta-q5, what is the process to add eglfs as a platform aside from xcb, minimal, offscreen, etc.
16:11.45riz___?
16:13.45*** join/#oe berton (~fabio@187.23.154.250)
16:16.29*** join/#oe berton (~fabio@187.23.154.250)
16:17.14*** join/#oe adelcast (~adelcast@130.164.62.82)
16:30.47*** join/#oe evanmeagher (~MongooseW@50.1.57.30)
16:31.30*** join/#oe Aethenelle (~Aethenell@199.15.128.78)
16:41.53*** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian)
16:42.23rburtonJaMa: are you aware that the oe patchwork appears to have no patches in?
16:42.58XorArburton: quick ship it, its DONE :-D
16:46.57*** join/#oe belen (~Adium@134.134.139.77)
16:53.42*** join/#oe belen (~Adium@134.134.139.77)
16:57.19*** join/#oe evanmeagher (~MongooseW@50.1.57.30)
16:58.14*** join/#oe evanmeag_ (~MongooseW@50.1.57.30)
17:06.21*** join/#oe jku (~jku@212-149-212-50.bb.dnainternet.fi)
17:18.21*** join/#oe koen (~koen@cl-267.ams-05.nl.sixxs.net)
17:37.03*** join/#oe anarsoul|2 (~kvirc@205.250.92.228)
17:40.03*** join/#oe kristoffer (~kristoffe@ua-83-227-162-207.cust.bredbandsbolaget.se)
17:43.40*** join/#oe evanmeagher (~MongooseW@50.1.57.30)
17:58.38*** join/#oe jackmitch|home (~Thunderbi@cpc2-slam8-2-0-cust880.2-4.cable.virginm.net)
18:00.17*** join/#oe jackmitch|home (~Thunderbi@cpc2-slam8-2-0-cust880.2-4.cable.virginm.net)
18:04.29*** join/#oe evanmeagher (~MongooseW@50.1.57.30)
18:12.38*** join/#oe Crofton (~balister@207-114-172-147.static.twtelecom.net)
18:24.37*** join/#oe evanmeagher (~MongooseW@50.1.57.30)
18:26.35*** join/#oe galak (~galak@104-57-189-103.lightspeed.austtx.sbcglobal.net)
18:28.14*** join/#oe bottazzini (~realBigfo@192.55.54.38)
18:38.02*** join/#oe belen (~Adium@134.134.139.77)
18:39.45*** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029)
18:42.22*** join/#oe maxin (~maxin@dsl-espbrasgw1-54fa7d-42.dhcp.inet.fi)
19:25.11*** join/#oe paulg_ (~paulg@OTWAON23-3096772825.sdsl.bell.ca)
19:26.25*** join/#oe bluelightning (~paul@2406:e007:5383:1:5e51:4fff:febb:401d)
19:26.25*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
19:36.10eengieI have a recipe that for some reason isn't going through the installation to sysroot prior to a dependency running through it's configure task.  The recipe inherits from nothing and only implements do_install, where it throws an executable to the STAGING_BINDIR_CROSS and some headers over to the STAGING_INCDIR.  Is there a better way to do this that will ensure these steps happen before a dependent tries to run configure?
19:43.55bluelightningeengie: the recipe should not be poking things directly into those directories within do_install
19:44.08bluelightningeengie: the correct way to do it is to install to the appropriate location under ${D}
19:44.27bluelightningfrom there, a select list of directories get automatically staged to the sysroot
19:49.15*** join/#oe jackmitch|home (~Thunderbi@cpc2-slam8-2-0-cust880.2-4.cable.virginm.net)
19:50.40*** join/#oe jackmitch|home (~Thunderbi@cpc2-slam8-2-0-cust880.2-4.cable.virginm.net)
19:51.56eengiebluelighting: thanks!
19:52.44*** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl)
19:54.12eengiebluelightning: actually though, what would be the appropriate ${D} for something that is going to be executed from the STAGING_BINDIR_CROSS (i.e., native to the build host)?
19:54.37kergothlook at one of the many existing -cross recipes we have
19:54.46eengieAlright
19:55.25bluelightningeengie: ${D}${bindir_crossscripts} I believe
19:56.40*** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net)
20:01.28*** join/#oe ChrisD1_Away (~ChrisD@merak.alcor.co.uk)
20:05.47*** join/#oe moto-timo (ttorling@nat/intel/x-exywgvpvxqcfhvti)
20:07.15JaMarburton: what you mean by no patches?
20:07.32JaMarburton: I was taking few patches from it today
20:07.48JaMarburton: are you aware that patches are marked as archived after they are sorted to separate bundles?
20:09.32*** join/#oe moto-tim1 (~ttorling@134.134.139.72)
20:31.19*** join/#oe moto-timo (~ttorling@fsf/member/moto-timo)
20:34.50*** join/#oe evanmeagher (~MongooseW@50.1.57.30)
21:03.13*** join/#oe moto-timo (ttorling@nat/intel/x-jfpicakqdgajwool)
21:03.13*** join/#oe moto-timo (ttorling@fsf/member/moto-timo)
21:06.52*** join/#oe evanmeagher (~MongooseW@50.1.57.30)
21:17.23*** join/#oe evanmeagher (~MongooseW@50.1.57.30)
21:22.14*** join/#oe yann|work (~yann@nan92-1-81-57-214-146.fbx.proxad.net)
21:25.16*** join/#oe evanmeagher (~MongooseW@50.1.57.30)
21:52.12*** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl)
21:52.48*** join/#oe evanmeagher (~MongooseW@50.1.57.30)
21:53.52*** join/#oe evanmeag_ (~MongooseW@50.1.57.30)
21:56.38*** join/#oe evanmeagher (~MongooseW@50.1.57.30)
21:58.36*** join/#oe evanmeagher (~MongooseW@50.1.57.30)
22:02.21CroftonWARNING: perf-1.0-r9 do_package_qa: QA Issue: /usr/libexec/perf-core/tests/attr.py contained in package perf requires /usr/bin/python, but no providers found in RDEPENDS_perf? [file-rdeps]
22:04.19*** join/#oe evanmeag_ (~MongooseW@50.1.57.30)
22:05.47rburtonyeah thats been annoying me for ages
22:05.49rburtonthere a bug somewhere
22:06.21Croftonin bugzilla?
22:06.23rburtonyes
22:06.29Croftonk
22:06.32CroftonI just saw it
22:06.46rburtonfirst question is why does perf need something called /tests/
22:08.05Croftonsome many problems, so little time
22:09.40kergothCrofton: i have that fixed in meta-mentor
22:10.02*** join/#oe rburton1 (~Adium@home.burtonini.com)
22:10.06kergothtwo fixes, one to fix the files to go into the subpackages properly (it hardcodes lib/perf rather than using libexecdir in FILES), and the other to fix the 'python2' thing
22:10.15kergothwill add to the list to submit to oe-core
22:11.14rburton1<PROTECTED>
22:11.22Crofton+1
22:11.32kergothhttps://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mentor-staging/recipes-kernel/perf/perf.bbappend
22:11.41kergothalso need to push the bits to obey LD while i'm at it
22:14.12Croftonis there a problem with boost-atomic in sdks?
22:14.51*** join/#oe evanmeagher (~MongooseW@50.1.57.30)
22:21.57*** join/#oe evanmeag_ (~MongooseW@50.1.57.30)
22:25.23*** join/#oe SoylentYellow (~SoylentYe@207-114-172-147.static.twtelecom.net)
22:26.21*** join/#oe evanmeagher (~MongooseW@50.1.57.30)
22:38.45*** join/#oe evanmeag_ (~MongooseW@50.1.57.30)
22:39.18*** join/#oe evanmea__ (~MongooseW@50.1.57.30)
22:44.54*** join/#oe evanmeagher (~MongooseW@50.1.57.30)
22:48.28*** join/#oe phdeswer_ (~phdeswer@91-159-55-220.elisa-laajakaista.fi)
22:55.55*** join/#oe evanmeagher (~MongooseW@50.1.57.30)
23:02.22*** join/#oe ant_home (~ant__@95.236.250.16)
23:37.22*** join/#oe rburton (~Adium@home.burtonini.com)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.