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.02 | zxc678 | i 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.42 | zxc678 | expect answer for my question. what confict for i2c-tools with sth in kernel |
04:06.24 | bluelightning | zxc678: installing i2c-tools seems like an unlikely trigger for such a bootup error |
04:06.46 | bluelightning | zxc678: have you tried commenting that out again to see if it's really that? |
04:42.03 | zxc678 | no, shell not work ,so i cant try it |
04:45.33 | zxc678 | the last output lines is |
04:46.12 | zxc678 | freeing unused kernel memeory:328k(80d23000-80d75000) |
04:46.38 | zxc678 | sh: cannot set terminal process group (-1) : inappropriate ioctl for device |
04:46.46 | zxc678 | sh: no job control in this shell |
04:46.53 | zxc678 | sh-4.3# |
04:47.15 | zxc678 | shell not wok, i cant input command to try anything |
04:48.51 | zxc678 | ok, i also delete the IMAGE_INSTALL += "i2c-tools", then recomplie and run image, it work well |
04:49.05 | zxc678 | so the issue is from i2c-tools |
04:53.12 | zxc678 | bluelightning: and then? |
05:13.43 | *** join/#oe fischerm (~mfischer@207-114-172-147.static.twtelecom.net) |
05:17.42 | bluelightning | zxc678: 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.47 | bluelightning | I 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.51 | bluelightning | zxc678: oh, I think I figured it out |
05:23.21 | bluelightning | zxc678: 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.52 | bluelightning | zxc678: I would suggest CORE_IMAGE_EXTRA_INSTALL += "i2c-tools" instead |
05:24.21 | bluelightning | zxc678: 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.50 | mckoan | good morning |
08:38.40 | zxc678 | I 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.55 | mario-goulart | Hi. 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.50 | rburton | the mirror needs to use that variable, yes |
11:17.40 | mario-goulart | rburton: 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.52 | mario-goulart | But requests for git repos are not resolved in the mirror, so builders end up fetching from upstream repos. |
11:19.34 | mario-goulart | IIUC, BB_GENERATE_MIRROR_TARBALLS would generate a tarball for each revision in SRCREV, right? |
11:22.22 | rburton | erm, pass. |
11:27.09 | mario-goulart | Ok, 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.49 | dv_ | is it just my impression, or has it become easier to use oe/yocto with arch linux? |
12:29.53 | dv_ | 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.21 | rburton | dv_: other distros have caught up and arch hasn't yet gone blazing ahead yet |
13:52.35 | rburton | its not like arch is the only distro shipping gcc5, for example |
13:53.09 | rburton | the 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.06 | kergoth | mario-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.36 | mario-goulart | kergoth: you mean it cannot be a file:// uri? (It is in the current case, as it is an NFS share). |
15:29.48 | kergoth | you're misunderstanding how the fetcher works |
15:29.58 | kergoth | the url scheme controls which fetcher is used, not the underlying communications protocol |
15:30.05 | kergoth | file:// will literally just copy some files locally |
15:30.09 | kergoth | git:// will use git |
15:30.18 | kergoth | if you want to fetch a local git repo, use ;protocol=file on the end of the uri |
15:30.34 | mario-goulart | I see. Thanks for the explanation. |
15:30.37 | kergoth | np |
15:30.53 | mario-goulart | Would that work for svn too? |
15:30.55 | kergoth | looking back, it'd be nice to support the + separated scheme which is used by lots of projects nowadays |
15:31.00 | kergoth | i.e. pip will use git+https:// |
15:31.14 | mario-goulart | good point |
15:31.16 | kergoth | not sure offhand, you could check the svn fetcher code |
15:31.26 | kergoth | or just try it :) |
15:31.33 | mario-goulart | Will do. Thanks again. :-) |
15:31.49 | kergoth | np |
15:33.31 | kergoth | the 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.08 | mario-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.42 | riz___ | After adding meta-q5, what is the process to add eglfs as a platform aside from xcb, minimal, offscreen, etc. |
16:11.45 | riz___ | ? |
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.23 | rburton | JaMa: are you aware that the oe patchwork appears to have no patches in? |
16:42.58 | XorA | rburton: 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.10 | eengie | I 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.55 | bluelightning | eengie: the recipe should not be poking things directly into those directories within do_install |
19:44.08 | bluelightning | eengie: the correct way to do it is to install to the appropriate location under ${D} |
19:44.27 | bluelightning | from 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.56 | eengie | bluelighting: thanks! |
19:52.44 | *** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl) |
19:54.12 | eengie | bluelightning: 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.37 | kergoth | look at one of the many existing -cross recipes we have |
19:54.46 | eengie | Alright |
19:55.25 | bluelightning | eengie: ${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.15 | JaMa | rburton: what you mean by no patches? |
20:07.32 | JaMa | rburton: I was taking few patches from it today |
20:07.48 | JaMa | rburton: 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.21 | Crofton | WARNING: 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.47 | rburton | yeah thats been annoying me for ages |
22:05.49 | rburton | there a bug somewhere |
22:06.21 | Crofton | in bugzilla? |
22:06.23 | rburton | yes |
22:06.29 | Crofton | k |
22:06.32 | Crofton | I just saw it |
22:06.46 | rburton | first question is why does perf need something called /tests/ |
22:08.05 | Crofton | some many problems, so little time |
22:09.40 | kergoth | Crofton: i have that fixed in meta-mentor |
22:10.02 | *** join/#oe rburton1 (~Adium@home.burtonini.com) |
22:10.06 | kergoth | two 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.15 | kergoth | will add to the list to submit to oe-core |
22:11.14 | rburton1 | <PROTECTED> |
22:11.22 | Crofton | +1 |
22:11.32 | kergoth | https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mentor-staging/recipes-kernel/perf/perf.bbappend |
22:11.41 | kergoth | also need to push the bits to obey LD while i'm at it |
22:14.12 | Crofton | is 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) |