| *** ant_home <ant_home!~andrea@host133-7-dynamic.20-79-r.retail.telecomitalia.it> has quit IRC | 00:04 | |
| *** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has joined #yocto | 00:05 | |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC | 00:09 | |
| *** sameo <sameo!samuel@nat/intel/x-qsyfmyoziqmtdiqq> has quit IRC | 00:29 | |
| *** davest <davest!~Adium@134.134.137.75> has quit IRC | 00:41 | |
| *** RagBal <RagBal!~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl> has quit IRC | 00:48 | |
| *** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC | 00:50 | |
| *** RagBal <RagBal!~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl> has joined #yocto | 00:55 | |
| *** _julian <_julian!~quassel@x2f0c2e5.dyn.telefonica.de> has joined #yocto | 00:59 | |
| *** _julian_ <_julian_!~quassel@x2f17b6e.dyn.telefonica.de> has quit IRC | 01:02 | |
| *** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has quit IRC | 01:02 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 01:27 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 01:28 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 01:36 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 01:44 | |
| mulhern | What provides all those perl-module-* packages? | 01:44 |
|---|---|---|
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 01:59 | |
| *** silviof1 <silviof1!~silviof@188.174.193.40> has joined #yocto | 02:15 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 02:17 | |
| *** silviof <silviof!~silviof@host-188-174-200-171.customer.m-online.net> has quit IRC | 02:18 | |
| *** silviof1 <silviof1!~silviof@188.174.193.40> has quit IRC | 02:24 | |
| *** silviof1 <silviof1!~silviof@188.174.193.40> has joined #yocto | 02:25 | |
| frank | Anyone can tell me the difference between PACKAGE_INSTALL and IMAGE_INSTALL ? | 02:51 |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 03:59 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 04:01 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 04:12 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 04:14 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 04:34 | |
| *** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has quit IRC | 04:42 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 04:45 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 04:47 | |
| *** mihai <mihai!~mihai@188.27.93.142> has quit IRC | 04:47 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 04:52 | |
| *** davest <davest!Adium@nat/intel/x-dlyunrwrchgivtln> has joined #yocto | 05:06 | |
| *** agust <agust!~agust@pD9E2F2EB.dip0.t-ipconnect.de> has joined #yocto | 05:08 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 05:15 | |
| *** davest <davest!Adium@nat/intel/x-dlyunrwrchgivtln> has quit IRC | 05:20 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 05:25 | |
| *** nslu2-log_ <nslu2-log_!~nslu2-log@140.211.169.184> has joined #yocto | 05:27 | |
| *** nslu2-log <nslu2-log!~nslu2-log@140.211.169.184> has quit IRC | 05:29 | |
| *** nslu2-log_ is now known as nslu2-log | 05:29 | |
| *** zerus <zerus!~epetmab@90-224-44-236-no67.tbcn.telia.com> has joined #yocto | 05:32 | |
| *** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 05:34 | |
| *** mihai <mihai!~mihai@80.97.15.150> has joined #yocto | 05:36 | |
| *** zeeblex <zeeblex!apalalax@nat/intel/x-qlaydvncefhbgowr> has joined #yocto | 05:38 | |
| *** zerus <zerus!~epetmab@90-224-44-236-no67.tbcn.telia.com> has quit IRC | 05:38 | |
| -YoctoAutoBuilder- build #226 of poky-tiny is complete: Failure [failed Building Images Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org:8011/builders/poky-tiny/builds/226 | 05:38 | |
| *** runexe_ <runexe_!~douggeige@pool-108-28-180-251.washdc.fios.verizon.net> has quit IRC | 05:40 | |
| -YoctoAutoBuilder- build #235 of nightly-intel-gpl is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-intel-gpl/builds/235 | 05:44 | |
| *** swex_ <swex_!~swex@178.17.200.22> has joined #yocto | 06:00 | |
| *** zenlinux_ <zenlinux_!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto | 06:03 | |
| *** qiang__ <qiang__!~qiang@1.202.252.122> has joined #yocto | 06:03 | |
| *** swex <swex!~swex@178.17.200.22> has quit IRC | 06:04 | |
| *** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC | 06:04 | |
| *** frank <frank!~qiang@1.202.252.122> has quit IRC | 06:04 | |
| *** scottrif <scottrif!~scott-len@b482.ip17.netikka.fi> has joined #yocto | 06:05 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 06:14 | |
| *** qiang__ <qiang__!~qiang@1.202.252.122> has quit IRC | 06:15 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 06:17 | |
| *** qiang__ <qiang__!~qiang@1.202.252.122> has joined #yocto | 06:17 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 06:25 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 06:35 | |
| *** mthalmei_away is now known as mthalmei | 06:42 | |
| *** mckoan|away is now known as mckoan | 07:07 | |
| mckoan | good morning | 07:07 |
| *** ka6sox is now known as ka6sox-away | 07:08 | |
| *** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has joined #yocto | 07:10 | |
| *** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has joined #yocto | 07:10 | |
| *** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto | 07:11 | |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto | 07:15 | |
| *** tbn <tbn!~tbn@84.55.160.118> has joined #yocto | 07:19 | |
| *** tbn is now known as Guest99011 | 07:20 | |
| -YoctoAutoBuilder- build #61 of minnow-lsb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/minnow-lsb/builds/61 | 07:21 | |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has quit IRC | 07:23 | |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto | 07:23 | |
| -YoctoAutoBuilder- build #222 of nightly-mips is complete: Failure [failed Running Sanity Tests Building Images_1 Building Toolchain Images Building Toolchain Images_1 Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-mips/builds/222 | 07:29 | |
| lpapp | is there anyone who can help me with external toolchains? I still did not move forward a bit. | 07:29 |
| *** ivali <ivali!~ivali@unaffiliated/ivali> has joined #yocto | 07:31 | |
| -YoctoAutoBuilder- build #232 of nightly-x32 is complete: Failure [failed Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x32/builds/232 | 07:34 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 07:38 | |
| *** slaine <slaine!~slaine@84.203.137.218> has joined #yocto | 07:40 | |
| *** shoragan <shoragan!~jlu@2001:6f8:1178:2:219:99ff:fe56:8d7> has joined #yocto | 07:42 | |
| *** shoragan <shoragan!~jlu@debian/developer/shoragan> has joined #yocto | 07:42 | |
| *** qiang__ <qiang__!~qiang@1.202.252.122> has quit IRC | 07:46 | |
| *** roric <roric!~roric@194-237-7-146.customer.telia.com> has joined #yocto | 07:46 | |
| *** frank <frank!~frank@1.202.252.122> has joined #yocto | 07:47 | |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto | 07:47 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 07:52 | |
| *** sameo <sameo!~samuel@192.55.54.36> has joined #yocto | 07:55 | |
| -YoctoAutoBuilder- build #75 of minnow is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/minnow/builds/75 | 07:58 | |
| *** blitz00 <blitz00!stefans@nat/intel/x-ujnyqczvwfimodhe> has joined #yocto | 08:01 | |
| *** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto | 08:01 | |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC | 08:03 | |
| bluelightning | morning all | 08:08 |
| lpapp | why cannot I interrupt the bitbake process with ctrl-c? :O | 08:09 |
| lpapp | bluelightning: http://paste.kde.org/~lpapp/p7d4e8a59/ | 08:12 |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto | 08:12 | |
| lpapp | also, it made my system super laggy that I pressed ctrl-z. | 08:13 |
| *** zerus <zerus!~epetmab@90-224-44-236-no67.tbcn.telia.com> has joined #yocto | 08:18 | |
| *** honschu_ <honschu_!~honschu@p508F615E.dip0.t-ipconnect.de> has joined #yocto | 08:27 | |
| *** honschu_ <honschu_!~honschu@shackspace/j4fun> has joined #yocto | 08:27 | |
| *** Daemon405 <Daemon405!~who_knows@S0106586d8f4832af.tb.shawcable.net> has joined #yocto | 08:28 | |
| *** belen <belen!Adium@nat/intel/x-ujhpkvutugyenvkm> has joined #yocto | 08:28 | |
| *** lpapp_ <lpapp_!~lpapp@cpc11-cmbg15-2-0-cust30.5-4.cable.virginmedia.com> has joined #yocto | 08:28 | |
| *** tor_ <tor_!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 08:28 | |
| ivali | kill solves it | 08:29 |
| *** yzhao2_ <yzhao2_!~yzhao2@128.224.252.2> has quit IRC | 08:29 | |
| *** lpapp <lpapp!~lpapp@cpc11-cmbg15-2-0-cust30.5-4.cable.virginmedia.com> has quit IRC | 08:29 | |
| *** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has quit IRC | 08:29 | |
| *** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has quit IRC | 08:29 | |
| *** pidge <pidge!~pidge@c-24-21-207-18.hsd1.or.comcast.net> has quit IRC | 08:29 | |
| *** sgw_ <sgw_!~sgw@c-71-193-189-117.hsd1.wa.comcast.net> has quit IRC | 08:29 | |
| *** pidge <pidge!~pidge@c-24-21-207-18.hsd1.or.comcast.net> has joined #yocto | 08:30 | |
| lpapp_ | ctrl-c should just work of course. | 08:30 |
| lpapp_ | I consider it a serious bug. | 08:30 |
| *** honschu <honschu!~honschu@shackspace/j4fun> has quit IRC | 08:30 | |
| *** scottrif <scottrif!~scott-len@b482.ip17.netikka.fi> has left #yocto | 08:31 | |
| lpapp_ | so I am more interested in fixing the bug. | 08:31 |
| lpapp_ | rather than working around, and have it non-working for the next user. | 08:31 |
| *** yzhao2 <yzhao2!~yzhao2@128.224.252.2> has joined #yocto | 08:33 | |
| *** sgw1 <sgw1!~sgw@c-71-193-189-117.hsd1.wa.comcast.net> has joined #yocto | 08:33 | |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has joined #yocto | 08:34 | |
| *** lpapp_ <lpapp_!~lpapp@cpc11-cmbg15-2-0-cust30.5-4.cable.virginmedia.com> has quit IRC | 08:37 | |
| *** Crofton <Crofton!~balister@guardian-2.svamberk.cz> has quit IRC | 08:45 | |
| *** ivali <ivali!~ivali@unaffiliated/ivali> has quit IRC | 09:01 | |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto | 09:16 | |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has quit IRC | 09:17 | |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has joined #yocto | 09:19 | |
| *** belen <belen!Adium@nat/intel/x-ujhpkvutugyenvkm> has quit IRC | 09:22 | |
| *** belen <belen!~Adium@134.134.139.70> has joined #yocto | 09:23 | |
| *** silviof1 is now known as silviof | 09:30 | |
| *** sameo <sameo!~samuel@192.55.54.36> has quit IRC | 09:33 | |
| *** belen <belen!~Adium@134.134.139.70> has quit IRC | 09:41 | |
| *** belen <belen!Adium@nat/intel/x-iaawovgiocbyaxil> has joined #yocto | 09:45 | |
| *** belen <belen!Adium@nat/intel/x-iaawovgiocbyaxil> has quit IRC | 09:50 | |
| *** belen <belen!~Adium@134.134.139.70> has joined #yocto | 09:59 | |
| *** lpapp <lpapp!~lpapp@212.44.19.228> has joined #yocto | 10:00 | |
| *** eren <eren!~eren@unaffiliated/eren> has joined #yocto | 10:07 | |
| eren | o/ morning all | 10:08 |
| lpapp | yo | 10:09 |
| lpapp | anyone got a clue for this bitbake issue? http://paste.kde.org/p6570e219/ | 10:13 |
| rburton | lpapp: fwiw, first control-c requests a graceful shutdown when the current tasks have finished, second should abort the current tasks. you'll often find you've then got a pile of data to still get to disk, so it may appear to hang for a bit. | 10:13 |
| rburton | lpapp: did you compare the files? | 10:14 |
| lpapp | rburton: I waited 20 minutes. | 10:15 |
| lpapp | rburton: yes | 10:15 |
| rburton | lpapp: so, did you resolve any differences and set the version in your conf/bblayers.conf to match the sample? | 10:16 |
| lpapp | rburton: ? | 10:17 |
| lpapp | there are no differences other than expected. | 10:17 |
| rburton | lpapp: and the versions match? | 10:18 |
| lpapp | rburton: http://imagebin.org/265472 | 10:18 |
| rburton | lpapp: do a find for other bblayers.conf.sample files | 10:20 |
| rburton | maybe your layer has one in? | 10:20 |
| lpapp | rburton: ? | 10:20 |
| ndec | iirc VERSION is 5 in dylan. | 10:21 |
| lpapp | ndec: ? | 10:21 |
| rburton | lpapp: search for other files in your tree called bblayers.conf.sample, as bitbake it clearly not looking at the file you're comparing. | 10:22 |
| rburton | lpapp: my suspicion is that your layer has a bblayers.conf.sample too | 10:22 |
| lpapp | ndec: surely, it is not? | 10:22 |
| lpapp | http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/bblayers.conf.sample?h=dylan | 10:23 |
| lpapp | rburton: unfortunately, nope. | 10:23 |
| lpapp | find ./ -name bblayers.conf.sample | 10:23 |
| lpapp | ./meta-yocto/conf/bblayers.conf.sample | 10:23 |
| lpapp | this is the only result. | 10:23 |
| rburton | how odd. | 10:23 |
| lpapp | it is ! | 10:24 |
| rburton | what happens if you wipe away your bblayers and re-run oe-init-build-env? | 10:24 |
| lpapp | it is with wiping away | 10:24 |
| lpapp | but I can do it again. | 10:24 |
| lpapp | rburton: http://paste.kde.org/p19df8b0f/ | 10:27 |
| rburton | hm | 10:27 |
| rburton | i bet your distro is setting LAYER_CONF_VERSION itself | 10:28 |
| lpapp | that means what? | 10:28 |
| rburton | thats the number that the layer version is compared against | 10:29 |
| rburton | if your distro is forcing it to something that it shouldn't be, you'll get this | 10:29 |
| rburton | does your layer define a distro? | 10:29 |
| lpapp | yes | 10:29 |
| lpapp | since it is a semi-distro layer | 10:30 |
| lpapp | weird thing is that, I do not get such issues with denzil though. | 10:30 |
| rburton | of course | 10:30 |
| rburton | because the version is older then | 10:30 |
| lpapp | ? | 10:30 |
| lpapp | ../meta-foo/conf/ff-local.conf:102:DISTRO ?= "poky" | 10:31 |
| lpapp | ../meta-foo/conf/foo-local.conf:102:DISTRO ?= "poky"* | 10:31 |
| lpapp | s/poky/foo/ maybe? | 10:31 |
| lpapp | as I have this: | 10:31 |
| lpapp | ../meta-foo/conf/distro/foo.conf | 10:31 |
| lpapp | in any case, the error message is not so intuitive | 10:31 |
| lpapp | it would be nice to improve it. | 10:31 |
| rburton | what distro does your local.conf specify? | 10:32 |
| lpapp | foo-tiny | 10:32 |
| rburton | its best not to change the value of DISTRO in several places | 10:33 |
| rburton | and have a look in your distro conf files, as i said i expect it's setting LAYER_CONF_VERSION | 10:33 |
| lpapp | as I said, it is not setting. | 10:34 |
| lpapp | "grep -rn LAYER_CONF_VERSION meta-foo" yields nothing. | 10:34 |
| lpapp | change the distro in several places mean what? | 10:34 |
| rburton | right, you didn't say that. | 10:34 |
| lpapp | I did. ;-) | 10:34 |
| rburton | you're setting DISTRO in multiple places | 10:34 |
| lpapp | I only replicate poky. | 10:34 |
| lpapp | I have a foo | 10:34 |
| lpapp | and foo-tiny | 10:34 |
| rburton | just set it in your local.conf | 10:34 |
| lpapp | similarly to poky. | 10:34 |
| lpapp | interesting, I have not written the LAYER_CONF_VERSION | 10:35 |
| lpapp | then I just intended. :) | 10:35 |
| lpapp | as I checked right after you wrote. | 10:35 |
| rburton | set LCONF_VERSION in your bblayers.conf to 5 | 10:35 |
| rburton | bet that makes it work | 10:36 |
| *** slaine <slaine!~slaine@84.203.137.218> has quit IRC | 10:36 | |
| lpapp | so, probably I should not have foo-local.conf in meta-foo/conf | 10:36 |
| lpapp | as meta-yocto does not seem to have that either. | 10:36 |
| *** slaine <slaine!~slaine@84.203.137.218> has joined #yocto | 10:36 | |
| lpapp | 5? | 10:36 |
| rburton | yeah, drop it one | 10:36 |
| lpapp | but ... but, it is 6. | 10:36 |
| lpapp | why ? | 10:36 |
| rburton | yes, so change it to 5 | 10:37 |
| * lpapp is lost | 10:37 | |
| lpapp | http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/bblayers.conf.sample?h=dylan | 10:37 |
| lpapp | that is meta-yocto from dylan | 10:37 |
| lpapp | it is 6 in there. | 10:37 |
| rburton | lets start with "its moaning when the value is 6, so lets change it to 5" | 10:37 |
| lpapp | why ? | 10:37 |
| rburton | but importantly, you're distro isn't poky | 10:37 |
| rburton | so don't copy poky files. | 10:37 |
| lpapp | well, it is almost poky | 10:37 |
| lpapp | and I still do not understand why 6 should not work. | 10:37 |
| rburton | 6 is the layer conf version set by poky | 10:38 |
| lpapp | in any case, I will drop meta-foo/conf/foo-local.conf then | 10:38 |
| rburton | if you're not running poky, you'll get the default of 5 | 10:38 |
| lpapp | we probably do not need it. | 10:38 |
| rburton | (that bump was a poky-specific change) | 10:38 |
| lpapp | ok, nice trap then. | 10:38 |
| rburton | you can drop meta-yocto entirely if you're not using poky, as it's actively causing harm | 10:38 |
| lpapp | no no | 10:39 |
| lpapp | it is better to keep it as upstream has. | 10:39 |
| lpapp | I mean it is easier to update stuff | 10:39 |
| lpapp | I will try again: can I drop meta-foo/conf/foo-local.conf or it has any significance? | 10:39 |
| lpapp | apparently, me predecessor put it there. | 10:40 |
| lpapp | but I would not know why it is neede. | 10:40 |
| lpapp | d | 10:40 |
| rburton | no idea, never seen that filename style before. | 10:40 |
| lpapp | err... it is not about the file name. | 10:40 |
| lpapp | it is about the concept having a local.conf inside the mylayer/conf | 10:40 |
| lpapp | rather than build/conf/local.conf | 10:40 |
| rburton | well, you said foo-local.conf | 10:40 |
| rburton | a local.conf inside a layer would be wrong | 10:41 |
| lpapp | it is probably a local.conf with custom stuff. | 10:41 |
| lpapp | and what about site-foo.conf inside the layer? | 10:41 |
| lpapp | should that also be gone? | 10:41 |
| rburton | i guess inside the layer is somewhere to put it | 10:42 |
| rburton | put a site.conf wherever you want | 10:42 |
| lpapp | so the bblayers.conf is generated with 6 because it generates meta-yocto by default? | 10:42 |
| rburton | no, because it found a bblayers.conf.sample in meta-yocto | 10:43 |
| rburton | and assumed that that's the one you wanted | 10:43 |
| lpapp | yeah, so renaming to site.conf makes sense | 10:43 |
| lpapp | especially since it is literally the sample. | 10:43 |
| lpapp | rburton: how can I override that? | 10:43 |
| rburton | if you're not using poky you can wipe those layers entirely | 10:43 |
| lpapp | or how can I make 6 work? | 10:43 |
| rburton | or just keep the bsp layer | 10:43 |
| rburton | you make the 6 work by using poky | 10:43 |
| lpapp | ok, it will be weird to check the build folder in. | 10:44 |
| rburton | yes, very weird | 10:44 |
| rburton | don't do that | 10:44 |
| *** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has joined #yocto | 10:44 | |
| lpapp | ? | 10:44 |
| lpapp | that is the only solution for upgradability? | 10:44 |
| rburton | just remove meta-yocto* from your setup, you don't need it | 10:44 |
| lpapp | I mean, clearly, it should be fixed once, and then shared. | 10:44 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 10:44 | |
| rburton | as you've said, your distro isn't poky. | 10:44 |
| lpapp | which means, build/conf/local.conf ends up in the repository | 10:44 |
| lpapp | ah, sorry. | 10:45 |
| lpapp | that is not bblayers.conf | 10:45 |
| lpapp | well well .... | 10:45 |
| lpapp | it is kinda sucky then. | 10:45 |
| lpapp | well removing poky is also suboptimal. | 10:45 |
| ant_work | lpapp: why don't you customize starting from the core? | 10:45 |
| lpapp | because then it will be more work to upgrade upstream poky. | 10:45 |
| lpapp | oh, and btw | 10:45 |
| lpapp | we do need poky. | 10:45 |
| ant_work | I'm working with distro-less defaults and all seems ok | 10:46 |
| panda84kde | hi otavio | 10:46 |
| lpapp | we only have hardware adaptation in our layer, mostly. | 10:46 |
| lpapp | rburton: we do not wanna reinvent the wheel. | 10:46 |
| rburton | lpapp: but your setting the distro to something else, so what do you need "poky" for? | 10:46 |
| ant_work | lpapp: it is easy if you start adding to http://www.openembedded.org/wiki/OE-Core_Standalone_Setup | 10:46 |
| lpapp | rburton: for the whole stuff | 10:46 |
| lpapp | rburton: every package pretty much should come from poky. | 10:46 |
| lpapp | replicating the poky layer in my layer would not make much sense. | 10:46 |
| lpapp | rburton: so my distro is poky + minor custom stuff | 10:47 |
| ant_work | poky or oe-core? | 10:47 |
| rburton | lpapp: are you actually aware of what recipes poky adds over oe-core? | 10:47 |
| rburton | 1) a changed splashscreen 2) a tiny configuration for busybox. | 10:47 |
| rburton | lpapp: if you want to "inherit" poky, then your distro.conf should require conf/distro/poky.conf | 10:49 |
| rburton | so you get poky and then can change it | 10:49 |
| rburton | that will also solve your conflicting version problem | 10:49 |
| rburton | (that's what guacamayo does, inherits poky and changes a few values) | 10:49 |
| mulhern | I'm building a Perl package. It seems to rely on a bunch of CPAN modules that are not in a standard distribution. But now I'm not so sure. How can I figure out what Perl modules are already available via some package? | 10:50 |
| mulhern | I see packages that DEPEND on some perl-module-.*. What provides these modules? | 10:50 |
| lpapp | rburton: and busybox | 10:56 |
| rburton | lpapp: yes, a tiny configuration for busybox | 10:56 |
| lpapp | rburton: we have our own custom kernel | 10:57 |
| lpapp | our own busybox | 10:57 |
| lpapp | our own splash screen | 10:57 |
| lpapp | perhaps then poky is not much of value for us | 10:57 |
| rburton | indeed | 10:57 |
| *** zeddii <zeddii!~ddez@128.224.252.2> has quit IRC | 10:57 | |
| rburton | depends how much you want to change. poky is a good starting point, or you can start from scratch. | 10:58 |
| lpapp | rburton: I guess poky would make more sense if we could upstraem our changes. | 10:58 |
| lpapp | kernel, busybox, etc | 10:58 |
| *** zeddii <zeddii!~ddez@128.224.252.2> has joined #yocto | 10:58 | |
| rburton | the problem you've got is that you've pulled in the layers but are not using it, so you get samples files that don't work with your setup. | 10:58 |
| lpapp | I think the end goal should be poky. | 10:58 |
| lpapp | but since we have custom patches for pretty much everything in poky. | 10:59 |
| rburton | well, having your own distro is fine, it lets you make changes specfic to your distro. | 10:59 |
| rburton | just either inherit poky, or remove the meta-yocto layers | 10:59 |
| ndec | i think the main problem here is that poky comes with its own 'init' script that does : TEMPLATECONF=${TEMPLATECONF:-meta-yocto/conf}. so you end up using the templates from meta-yocto. | 10:59 |
| ndec | so if you don't use poky, but download 'poky' (as opposed to oe-core), you probably want to tweak that. | 11:00 |
| ndec | but, if you have your own distro , you might want to provide your own template conf files directly. that's what i do. | 11:00 |
| ant_work | remembering that distro/defaultsetup.conf is providing valid defaults | 11:02 |
| rburton | poky does do more qa, iirc | 11:02 |
| *** swex__ <swex__!~swex@217.197.246.33> has joined #yocto | 11:02 | |
| -YoctoAutoBuilder- build #194 of nightly-fsl-arm is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-fsl-arm/builds/194 | 11:04 | |
| mulhern | Ummm, can I be a squeaky wheel and get a little grease? | 11:05 |
| ndec | rburton: it does more QA because it sets QA in the distro vars, right? but if we reproduce the same config in another distro, we should get same QA, right? | 11:05 |
| ant_work | it's just matter of changing local.conf | 11:05 |
| ndec | ok. | 11:05 |
| *** swex_ <swex_!~swex@178.17.200.22> has quit IRC | 11:06 | |
| mulhern | Also, if I do have to fetch, build, and install a lot of tiny Perl modules is there some standard way to do that in one recipe, instead of a whole bunch of separate recipes? | 11:06 |
| rburton | ndec: its just distro vars, yeah. set them wherever you want. | 11:06 |
| ant_work | so the Distro abstraction is useful because is stable and commercially affordable | 11:06 |
| ant_work | but is not necessary | 11:06 |
| rburton | mulhern: not really. there was someone who'd packaged up about 80 modules from cpan though... | 11:07 |
| rburton | mulhern: assuming your modules come from cpan, metadata boilerplate + inherit cpan should be close to all you need | 11:07 |
| rburton | bluelightning: can you remember who was packaging vast amounts of perl? | 11:08 |
| mulhern | Oh, yeah, I can set up little recipes and everything happens automatically. But what if all those little recipes are redundant? And they sure do clutter everything up. | 11:08 |
| bluelightning | rburton: that was Stygia | 11:08 |
| ant_work | and erbo | 11:08 |
| bluelightning | ant_work: ah ok, didn't know he was also doing that | 11:09 |
| bluelightning | hope they are talking to eachother :) | 11:09 |
| ant_work | heh | 11:09 |
| rburton | package deathmatch! | 11:09 |
| mulhern | When a package DEPENDS on a perl-module-.* that must come from somewhere but I can't even figure out what provides these modules. It's unusually mysterious. | 11:12 |
| rburton | mulhern: got one specifically? | 11:13 |
| rburton | hm maybe perl magically provides those for the modules it contains | 11:13 |
| -YoctoAutoBuilder- build #193 of nightly-fsl-arm-lsb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-fsl-arm-lsb/builds/193 | 11:13 | |
| lpapp | rburton: so poky or not? | 11:16 |
| rburton | lpapp: personally i like inheriting poky, but it depends on how much you want to change the distro variables. | 11:16 |
| mulhern | I see a recipes with RDEPENDS containing a whole list: perl perl-module-text-wrap perl-module-getopt-long …. | 11:17 |
| rburton | mulhern: right, a lot of those are the subpackages that perl splits into | 11:17 |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 11:18 | |
| mulhern | OK, now I see that in perl-rprovides.inc. | 11:19 |
| rburton | mulhern: for reducing installed size, perl (and python) split their library modules into as many packages as possible | 11:21 |
| rburton | so you can just install what is needed | 11:21 |
| rburton | the downside of this is that there are ~fifteen quadzillion packages for each | 11:21 |
| mulhern | rburton: That's perfectly sensible. | 11:22 |
| *** Daemon405 is now known as Daemon404 | 11:23 | |
| *** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has joined #yocto | 11:23 | |
| mulhern | But, the interesting thing is that for instance with perl-module-text-wrap that I mentioned is that perl depends on it, it doesn't provide it. | 11:23 |
| rburton | ah | 11:24 |
| rburton | i suspect the names are generated automatically | 11:25 |
| rburton | and that rprovides.inc is only for manually additions | 11:25 |
| lpapp | rburton: what distro variables? | 11:25 |
| rburton | mulhern: yes, perl_5.14.3.bb has a populate_packages_prepend() that does do_split_packages(). that chops each module directory into a package with the right name. | 11:26 |
| rburton | "Your version of bblayers.conf has the wrong LCONF_VERSION (has 62, expecting 6). Please compare the your file against bblayers.conf.sample and merge any changes before continuing." | 11:27 |
| rburton | that's a slightly better error message | 11:27 |
| rburton | lpapp: well, what what your distro setting so far? DISTRO_FEATURES, the QA checks, global compilation flags, etc are all distro variables. | 11:27 |
| lpapp | rburton: DISTRO_FEATURES_append = " largefile --disable-zlib" | 11:28 |
| rburton | that's not how DISTRO_FEATURES works | 11:28 |
| lpapp | ? | 11:29 |
| rburton | (specifically, --disable-zlib doesn't make sesnse there) | 11:29 |
| lpapp | what makes sense there then? | 11:30 |
| lpapp | anyway, that is all we set. | 11:30 |
| lpapp | I still need to understand whether I should go for poky, or not. | 11:30 |
| rburton | its up to you, really. | 11:30 |
| lpapp | obviously, but I need to understand what that decision is based on. | 11:30 |
| lpapp | and yes, I mean technical considerations. | 11:30 |
| *** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has joined #yocto | 11:31 | |
| rburton | it entirely comes down to how much customisation you expect to make to the distro | 11:32 |
| rburton | you can start with inheriting poky and and switch to your own distro entirely if you want in the future, whatever. | 11:32 |
| rburton | just be aware that --disable-zlib in DISTRO_FEATURES isn't doing anything | 11:32 |
| rburton | the list of valid distro features is in the documentation | 11:32 |
| lpapp | as far as I can tell, poky is really not much | 11:34 |
| lpapp | 95% is in oe-core. | 11:34 |
| rburton | oh, more than that | 11:34 |
| rburton | its 99% policy in poky.conf | 11:34 |
| rburton | a new splash screen and the poky-tiny confguration for busybox. | 11:34 |
| lpapp | what is the point of poky then? | 11:34 |
| lpapp | It does not contribute much | 11:34 |
| lpapp | most of the stuff is done by oe-core. | 11:35 |
| rburton | and some more BSPs | 11:35 |
| rburton | yes | 11:35 |
| rburton | its a reference distribution | 11:35 |
| rburton | a known-working component that is tested by QA | 11:35 |
| *** synthnassizer <synthnassizer!~quassel@143.233.242.130> has quit IRC | 11:35 | |
| lpapp | the problem is that we have own linux adaptation changes (huge patches) | 11:35 |
| lpapp | own patches against busybox. | 11:35 |
| lpapp | own splash screen | 11:35 |
| lpapp | so not much left in poky we could actually reuse. | 11:36 |
| lpapp | tiny-init maybe? | 11:36 |
| rburton | that's for poky-tiny, where by "init system" you mean "busybox sh" | 11:36 |
| *** synthnassizer <synthnassizer!~quassel@143.233.242.130> has joined #yocto | 11:36 | |
| rburton | as i said, poky is mostly policy in poky.conf | 11:36 |
| rburton | you can happily inherit and tweak that, or start from the defaults in oe-core. | 11:37 |
| rburton | people do both, there is no "right" answer | 11:37 |
| lpapp | happily is a bit exaggeration | 11:38 |
| lpapp | it has caused a headache for half a day | 11:38 |
| lpapp | with the version thingie and wrong error message. | 11:38 |
| rburton | sure, i'm writing the commit message now to clarify that error | 11:39 |
| lpapp | rburton: how would I solve it with inheriting anyway? | 11:41 |
| lpapp | I would still need to roll back to version 5? | 11:41 |
| rburton | no | 11:41 |
| rburton | the problem is that oe-core and poky have different layer versions | 11:41 |
| rburton | you're using poky templates because you're using the poky tarball, but not using poky | 11:41 |
| rburton | so 5!=6 | 11:41 |
| lpapp | inheriting poky means we cannot have our own distro definition? o_O | 11:42 |
| rburton | sure you can | 11:42 |
| * lpapp is lost then | 11:42 | |
| lpapp | how can I make 6 work then with inheritance? | 11:43 |
| rburton | rburton: lpapp: if you want to "inherit" poky, then your distro.conf should require conf/distro/poky.conf | 11:43 |
| rburton | rburton: so you get poky and then can change it | 11:43 |
| rburton | rburton: that will also solve your conflicting version problem | 11:43 |
| rburton | rburton: (that's what guacamayo does, inherits poky and changes a few values) | 11:43 |
| lpapp | is that something people often do? | 11:45 |
| rburton | some. others don't use a distro. others roll their own distro from scratch. | 11:45 |
| *** ivali <ivali!~ivali@unaffiliated/ivali> has joined #yocto | 11:46 | |
| lpapp | from scratch means based upon oe-core? | 11:47 |
| rburton | yes | 11:51 |
| lpapp | is there an example for this require thingie? | 11:51 |
| -YoctoAutoBuilder- build #184 of nightly is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly/builds/184 | 11:51 | |
| rburton | lpapp: my line was literally an example, but https://github.com/Guacamayo/meta-guacamayo/blob/master/meta-guacamayo/conf/distro/guacamayo.conf is the source of what i was saying. that's a distro based on poky. | 11:53 |
| lpapp | weird | 11:54 |
| *** joeythesaint <joeythesaint!~jjm@128.224.252.2> has joined #yocto | 11:54 | |
| *** slaine <slaine!~slaine@84.203.137.218> has quit IRC | 12:00 | |
| lpapp | rburton: WARNING: Unable to get checksum for foo SRC_URI entry authorized_keys: file could not be found | 12:01 |
| lpapp | rburton: WARNING: Unable to get checksum for foo SRC_URI entry bar: file could not be found | 12:01 |
| lpapp | this was not a problem with denzil | 12:01 |
| lpapp | this enforcement was introduced later? | 12:01 |
| rburton | something probably changed | 12:02 |
| rburton | show some context and we can help | 12:02 |
| lpapp | nothing changed in our package. | 12:03 |
| lpapp | oh, btw, we have custom user space tools as well in meta-foo | 12:03 |
| lpapp | it is called recipes-foo | 12:03 |
| lpapp | that kinda yields a reason for an own distro, too? | 12:03 |
| rburton | nope | 12:04 |
| rburton | a distro is mostly policy, global cflags, distro-features, etc. | 12:04 |
| lpapp | ? | 12:07 |
| lpapp | additional packages are distro features | 12:07 |
| lpapp | which are not present in one, but does present in another. | 12:07 |
| *** sveinse <sveinse!~chatzilla@79.160.140.131> has joined #yocto | 12:07 | |
| lpapp | those are distro features. | 12:07 |
| rburton | they are not "DISTRO_FEATURES" | 12:08 |
| rburton | which is what i meant | 12:08 |
| lpapp | SRC_URI = "file://bar \ | 12:08 |
| lpapp | in foo_foover.bb | 12:08 |
| lpapp | well... | 12:08 |
| lpapp | we cannot upstream our custom commercial utils. | 12:08 |
| rburton | sure, of course not | 12:08 |
| lpapp | so it is very unlikely to end up in poky | 12:08 |
| rburton | you're not forced to either, yocto is all MIT | 12:09 |
| lpapp | in which case, not having our own distribution is kinda moot. | 12:09 |
| lpapp | what shall I run for bitbake to return the checksum for me? | 12:09 |
| sveinse | I'm trying to wrap my head around the layers concept. What is a BSP in yocto's sense of the word? Is that a collection of low-level rules which provides kernel, bootloader, etc. Or is a BSP a highlevel description saying: "My system consists of this kernel, this bootloader, this app, these libs" and so on. | 12:10 |
| lpapp | "bitbake foo" did not help. | 12:10 |
| rburton | lpapp: you shouldn't need checksums for file:// uris | 12:10 |
| lpapp | sveinse: the former. | 12:10 |
| rburton | so what's the actual src_uri? | 12:10 |
| sveinse | Because if its the former (which I presume), you need a meta- for the BSP and another meta for describing the entire system, right | 12:10 |
| lpapp | rburton: ? | 12:10 |
| lpapp | sveinse: yeah | 12:10 |
| rburton | lpapp: you shouldn't need checksums for file:// URIs | 12:11 |
| rburton | lpapp: so what's the full SRC_URI? | 12:11 |
| ndec | bluelightning: hehe... i was able to do what i wanted in bblayers.conf. BBLAYERS += "${@' ${LL} ' if os.path.isfile('${LL}/conf/layer.conf') else ''}" works. | 12:11 |
| lpapp | daaaaaaamn | 12:11 |
| sveinse | lpapp: are there any yocto OOB examples how this top-level is setup? | 12:11 |
| lpapp | I cannot stop bitbake again. :( | 12:11 |
| lpapp | this is annoying, really. | 12:11 |
| lpapp | ctrl-c should just work. | 12:11 |
| lpapp | any hackaround? | 12:11 |
| ndec | i got the idea from the guacayamo conf file that was just posted above... | 12:11 |
| lpapp | kill? | 12:11 |
| rburton | lpapp: as i said earlier, there's a race. control-z then kill works. | 12:11 |
| lpapp | rburton: http://paste.kde.org/p63cf3a6c/ | 12:13 |
| lpapp | is there a shortcut to clean up the build folder except the already set config files? | 12:14 |
| lpapp | to avoid this command manually: | 12:14 |
| rburton | lpapp: that file doesn't match your errors? | 12:14 |
| lpapp | rm -rf bitbake.lock cache downloads sstate-cache tmp | 12:14 |
| lpapp | rburton: ? | 12:14 |
| lpapp | rburton: that is the foo_ver.bb file. | 12:14 |
| lpapp | referring to bar. | 12:14 |
| rburton | maybe it just can't find the file and will later ignore doing a checksum | 12:15 |
| rburton | there was a change to the file lookup, where is it? | 12:15 |
| rburton | when it was changed was almost zero fallout, but you may have used a bad place. | 12:15 |
| rburton | (i.e. where is bar in relation to the recipe) | 12:15 |
| rburton | if its alongside it, don't do that. put it in files/ or foo/ | 12:16 |
| ndec | lpapp: you should remove WORKDIR from LIC_FILES_CHECKSUM no? | 12:16 |
| lpapp | rburton: beside it. | 12:16 |
| lpapp | rburton: why ? | 12:16 |
| rburton | it causes problems | 12:17 |
| rburton | put files in a directory | 12:17 |
| rburton | call it files, or $PN, or $PN-$PV | 12:17 |
| rburton | alongside working was luck as iirc that wasn't documented anywhere | 12:17 |
| lpapp | rburton: well, in an ideal world, it should not cause problems, I believe. | 12:17 |
| rburton | lpapp: well, it caused problems. if you're curious you can dig out the commit and read the rationale. | 12:18 |
| lpapp | ndec: that sounds like a good idea to me... | 12:18 |
| lpapp | rburton: ok, I will ignore the warning for now. | 12:18 |
| lpapp | that recipe, as you can see, is just about installing a file. | 12:18 |
| lpapp | a conf file, pretty much. | 12:18 |
| lpapp | will bitbake clean or so help me with the other issue? | 12:19 |
| rburton | lpapp: just rm -rf tmp | 12:19 |
| rburton | keep downloads and sstate-cache unless you know you've managed to taint your cache | 12:19 |
| lpapp | should not there be an option doing that? | 12:20 |
| lpapp | ndec: I removed. | 12:20 |
| lpapp | rburton: I moved stuff into files | 12:20 |
| lpapp | although I am still getting this: | 12:21 |
| lpapp | WARNING: Unable to get checksum for foo SRC_URI entry bar: file could not be found | 12:21 |
| lpapp | WARNING: Unable to get checksum for root-ssh-authorized SRC_URI entry COPYRIGHT: file could not be found | 12:21 |
| lpapp | WARNING: Unable to get checksum for foo SRC_URI entry COPYRIGHT: file could not be found* | 12:21 |
| lpapp | SRC_URI = "file://files/bar \ | 12:22 |
| bluelightning | lpapp: file://bar not file://files/bar | 12:22 |
| lpapp | bluelightning: ? | 12:23 |
| lpapp | we have just discussed to move into files. | 12:23 |
| rburton | yes, move the files, the src_uri references were find | 12:23 |
| rburton | fine | 12:23 |
| rburton | bitbake will hunt around for the right ones | 12:24 |
| lpapp | ok | 12:24 |
| lpapp | COPYRIGHTS should also move to files? | 12:24 |
| bluelightning | lpapp: yes, files/ is already in the search path for a recipe by default, so you don't need to specify it | 12:24 |
| rburton | by default as discussed you can use files, $PN, or $PN-PV. | 12:24 |
| lpapp | k | 12:24 |
| rburton | so you can have files for all recipes in that directory, then files for a specific recipe, and other files for specific versions of specific recipes | 12:24 |
| lpapp | yeah, I know | 12:24 |
| lpapp | but what about COPYRIGHT? | 12:24 |
| lpapp | everything is supposed to go into those except foo_bar.bb? | 12:25 |
| lpapp | which is supposed to go into the package root? | 12:25 |
| lpapp | WARNING: Variable package_do_filedeps contains tabs, please remove these (/home/lpapp/Projects/Yocto/poky-dylan-9.0.0/meta-foo/recipes-core/busybox/busybox_1.20.2.bb) | 12:26 |
| lpapp | that warnings must have been introduced after denzil, too. | 12:26 |
| rburton | lpapp: yes | 12:26 |
| rburton | python functions need to be four-space indented | 12:26 |
| lpapp | kinda | 12:26 |
| rburton | might be easier to re-base your patches against our busybox with a bbappend? | 12:27 |
| JaMa | bluelightning: Hi, is meta-openembedded-contrib/log/?h=paule/mosh ready to be merged? | 12:27 |
| lpapp | rburton: nope, it is really custom | 12:27 |
| lpapp | not expected to be upstreamed. | 12:27 |
| lpapp | is there a reformatting tool? | 12:27 |
| bluelightning | JaMa: if people are happy with where the recipes are going, yes (and I think they are) | 12:27 |
| *** mthalmei is now known as mthalmei_away | 12:27 | |
| JaMa | bluelightning: I'm lost a bit in discussion about it and verification build will take another day at least, so I'll trust your word and merge | 12:27 |
| lpapp | some astyle thingie? | 12:27 |
| rburton | lpapp: sadly not | 12:28 |
| JaMa | rburton: test-dependencies run finished today (finally), I'm sending few more patches with deps discovered in smaller builds (with less layers) | 12:28 |
| rburton | lpapp: search/replace on "\t" to " " should work nicely though | 12:28 |
| rburton | JaMa: woo | 12:28 |
| lpapp | rburton: there is no tab in that file fwiw. | 12:29 |
| bluelightning | JaMa: great job btw, thanks for going through that exercise and fixing up the issues found | 12:29 |
| lpapp | rburton: again, poor error message. | 12:29 |
| lpapp | rburton: should spot the line? | 12:29 |
| rburton | lpapp: does it do an include? | 12:29 |
| lpapp | require you mean? | 12:29 |
| rburton | require or include | 12:29 |
| lpapp | yes, first line | 12:29 |
| rburton | check that file | 12:30 |
| lpapp | require busybox.inc | 12:30 |
| rburton | iirc the syntax check happens after the parse, so it doesn't know that | 12:30 |
| lpapp | well, it should report the right file anyway | 12:30 |
| lpapp | even if not line number | 12:30 |
| lpapp | I imagine this would have been a headache for me without help | 12:30 |
| lpapp | I would not really have known what the problem is | 12:31 |
| rburton | lpapp: patches welcome | 12:31 |
| rburton | it tells you what python function has the tabs in | 12:31 |
| lpapp | rburton: I welcome them, too. ;) | 12:31 |
| rburton | so this isn't exactly rocket science | 12:31 |
| lpapp | rburton: function is not enough | 12:32 |
| lpapp | I really need file. | 12:32 |
| rburton | dude, grep | 12:32 |
| lpapp | and even line number | 12:32 |
| rburton | the *entire function* | 12:32 |
| rburton | its not just one tab, the entire function needs re-indenting | 12:32 |
| * rburton -> food | 12:33 | |
| JaMa | rburton: bluelightning: what do you think about backporting those fixes to dylan after some time in master? | 12:33 |
| lpapp | rburton: well, it could list all the offending lines. | 12:33 |
| ant_work | lpapp: this only happens to the developers and he'd immediately notice it on next bitbake run | 12:33 |
| ant_work | -s | 12:33 |
| bluelightning | JaMa: if they're applicable to the versions in dylan, I don't see why not | 12:33 |
| JaMa | rburton: bluelightning: I have jansa/dylan-backports branch for oe-core/meta-oe which contains all needed changes for these dependencies in dylan (where I was running most of build tests) | 12:33 |
| bluelightning | JaMa: ok, thanks | 12:34 |
| lpapp | ant_work: ? | 12:34 |
| rburton | lpapp: it's the *entire function*, line numbers won't help any more than just the function name. and as i said, the error is happening at the wrong point in the parse to know about includes. if it bothers you that much feel free to rewrite the parser. | 12:34 |
| *** _Lucretia__ <_Lucretia__!~munkee@90.218.162.144> has quit IRC | 12:34 | |
| ant_work | if you are bitbaking your recipe you'll see you did some mistake | 12:34 |
| JaMa | bluelightning: ok I'll send pull-request after few weeks if nobody finds any issue in master | 12:34 |
| lpapp | ant_work: again, I would not have known without help. | 12:35 |
| lpapp | I would not have looked into inc files. | 12:35 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 12:36 | |
| lpapp | rburton: bluelightning http://paste.kde.org/p69f1bde6/ | 12:43 |
| bluelightning | lpapp: are you adding your own busybox recipe solely for changing the config? | 12:44 |
| lpapp | bluelightning: no | 12:45 |
| lpapp | bluelightning: we have custom patches to core utils. | 12:45 |
| bluelightning | lpapp: you are hitting this problem I suspect because you're bringing in an old busybox recipe which does not match up to the requirements based upon the current recipe | 12:45 |
| lpapp | bluelightning: ? | 12:46 |
| bluelightning | lpapp: even so, my suggestion would be to use a bbappend rather than a complete recipe; you can still apply patches and/or change the config / variables / whatever you need | 12:46 |
| bluelightning | lpapp: "This usually means one provides something the other doesn't and should." | 12:46 |
| lpapp | bluelightning: no no | 12:47 |
| lpapp | the patches are not meant to be updated. | 12:47 |
| lpapp | they are quite domain specific | 12:47 |
| bluelightning | er... | 12:47 |
| lpapp | upstreamed* | 12:47 |
| bluelightning | I'm not making any reference to upstreaming | 12:47 |
| lpapp | I am doing, | 12:47 |
| lpapp | you mentioned last time if we wanna maintain a software on our own, it is better to put into our own layer which I agree with. | 12:48 |
| bluelightning | lpapp: yep, and I'm not contradicting that | 12:48 |
| lpapp | bluelightning: ? | 12:48 |
| bluelightning | lpapp: I'm suggesting that rather than an additional busybox recipe, use a busybox bbappend to achieve the same thing | 12:49 |
| *** _Lucretia__ <_Lucretia__!~munkee@90.218.162.144> has joined #yocto | 12:49 | |
| bluelightning | lpapp: that way you avoid some of the compatibility problems when you upgrade, like the one you are hitting now | 12:49 |
| lpapp | bluelightning: ? | 12:49 |
| lpapp | the whole idea was to maintain it on our own | 12:49 |
| bluelightning | yes, and that won't change by using a bbappend | 12:50 |
| lpapp | if I use bbappend I *am* forced to update my change. | 12:50 |
| lpapp | even though when it is totally unreasonable due to our milestone. | 12:50 |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-wzqcdggrptpydfjq> has joined #yocto | 12:51 | |
| lpapp | so, I do not feel comfortable at all without external force. | 12:51 |
| lpapp | that is exactly the reason why I would like to maintain my version | 12:51 |
| lpapp | without any explicit requirement to upgrade it. | 12:51 |
| lpapp | so how can I fix this situation with my own recipe, et cetera? | 12:54 |
| melonipoika | morning | 12:55 |
| melonipoika | i am having some problems with arago-oe-dev, hope someone could help :-) | 12:56 |
| melonipoika | I added this layer to my bblayers.conf | 12:56 |
| lpapp | bluelightning: ^ | 12:56 |
| melonipoika | but when buliding the image, i get this error: | 12:56 |
| melonipoika | ERROR: ParseError at /home/jose/mcsdk/sources/arago-oe-dev/classes/java.bbclass:8: unparsed line: 'datadir_java ?= ${datadir}/java' | 12:57 |
| bluelightning | lpapp: ok, so if you want to keep to the fixed version, you can keep your full recipe; however since upgrading you'll need to base it on the current busybox recipe since that clearly provides some things that the old one does not and those things are required | 12:57 |
| bluelightning | melonipoika: looks like the value is missing enclosing quotes | 12:58 |
| lpapp | bluelightning: could you please be a bit more specific | 12:58 |
| lpapp | dylan uses exactly the same upstream version. | 12:59 |
| bluelightning | lpapp: compare the two files to see what the difference is | 12:59 |
| melonipoika | this is how the line 8 looks like | 12:59 |
| melonipoika | # Jar location on target | 12:59 |
| melonipoika | datadir_java ?= ${datadir}/java | 12:59 |
| lpapp | bluelightning: which files? | 12:59 |
| lpapp | .inc, .bb, etc? | 12:59 |
| bluelightning | lpapp: busybox_xyz.bb | 12:59 |
| bluelightning | lpapp: and the inc files | 12:59 |
| bluelightning | melonipoika: I think that needs to be datadir_java ?= "${datadir}/java" | 13:00 |
| lpapp | bluelightning: they have a shitload of patches. | 13:00 |
| lpapp | again, I think bitbake has a very poor error reporting. | 13:00 |
| melonipoika | bluelightning, thanks, will try it' | 13:00 |
| lpapp | it should write exactly what the problem is. | 13:00 |
| lpapp | that error message is just as vague as the previous ones. | 13:01 |
| lpapp | perhaps for 10.0 the error reporting system should be revamped. | 13:01 |
| bluelightning | lpapp: we'd all like to see such error messages be more helpful, but fixing that for all error messages isn't a straightforward task; in a lot of the cases we don't have the information needed in the context where the error needs to be thrown | 13:02 |
| lpapp | bluelightning: that is what I mentioned revamping. | 13:02 |
| lpapp | the architecture should make sure you do have the information. | 13:03 |
| lpapp | why* | 13:03 |
| *** frank_fighting71 <frank_fighting71!~frank@118.186.200.116> has joined #yocto | 13:21 | |
| *** JimNH2 <JimNH2!~jmchale@23-25-235-113-static.hfc.comcastbusiness.net> has quit IRC | 13:21 | |
| frank_fighting71 | How should I add libnfsidmap package to rootfs using IMAGE_INSTALL ? | 13:23 |
| frank_fighting71 | libnfsidmap package has been renamed to libnfsidmap0 by debian.bbclass | 13:23 |
| bluelightning | frank_fighting71: in IMAGE_INSTALL you use the name before the renaming, i.e. libndfsidmap | 13:24 |
| bluelightning | frank_fighting71: er, I meant libnfsidmap | 13:24 |
| frank_fighting71 | bluelightning: I did as you said, but I met do_rootfs error | 13:25 |
| bluelightning | frank_fighting71: please pastebin it | 13:25 |
| frank_fighting71 | indicating libnfsidmap not found in the feed | 13:25 |
| *** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has joined #yocto | 13:28 | |
| *** davest <davest!~Adium@134.134.139.72> has joined #yocto | 13:31 | |
| bluelightning | frank_fighting71: hmm, that works here with ipk... which version of the build system are you using? | 13:34 |
| frank_fighting71 | how to check the version ? I git clone poky repo several days ago. | 13:36 |
| sveinse | whats special about the yocto kernel compared to vanilla kernel? | 13:36 |
| frank_fighting71 | ipk also also rename the lib package name ? | 13:36 |
| bluelightning | frank_fighting71: oh so you're using master... FWIW, my test was with master so it should work... | 13:37 |
| sveinse | I have some custom HW where I have a complete custom 3.4.24 kernel. Can I use that with yocto as-is, or do I need to merge in some yoctoisms into the kernel? | 13:37 |
| *** sameo <sameo!~samuel@192.55.54.36> has joined #yocto | 13:38 | |
| bluelightning | sveinse: you should be able to use your own kernel config if that's what you prefer | 13:38 |
| sveinse | bluelightning: ok. Which brings me to my first question: Why a yocto kernel? | 13:39 |
| lpapp | bluelightning: any clue what the problem might be? | 13:42 |
| bluelightning | lpapp: have you compared the recipes and inc files? | 13:43 |
| lpapp | bluelightning: it is a lot of diff | 13:43 |
| lpapp | I honestly have no clue what can cause issues for oe-core | 13:43 |
| lpapp | and since it is not verbose, I would need to look into the oe-core code | 13:43 |
| lpapp | unless someone here can help me. | 13:43 |
| bluelightning | lpapp: perhaps you would be best off using the new recipes as a basis and putting your patches into that | 13:43 |
| lpapp | it should not be a problem at all to ship your own version. | 13:43 |
| lpapp | bluelightning: in the short term, yes. | 13:44 |
| lpapp | bluelightning: for long term thinking, not really, no. | 13:44 |
| bluelightning | lpapp: so what is it that you want? | 13:44 |
| lpapp | and I am considering yocto for long term, so I need to understand why it complains. | 13:44 |
| lpapp | I cannot just do things blindly. | 13:44 |
| lpapp | I need to understand what is going on. | 13:44 |
| lpapp | and if error reporting is not helpful. | 13:44 |
| bluelightning | lpapp: then, you need to look at and understand the differences | 13:45 |
| lpapp | and no one can help here, I will have hard time, but I will need to look into the code. | 13:45 |
| rburton | lpapp: have a look at the busybox in oe-core and see what it PROVIDES | 13:45 |
| rburton | then compare that with your own recipe | 13:45 |
| bluelightning | and RPROVIDES | 13:45 |
| rburton | yeah, and that | 13:45 |
| rburton | as the message says, one of them provides something the other doesn't, so it needs to build both to resolve all dependencies. | 13:45 |
| bluelightning | sveinse: I don't have a complete answer for you; I do know we maintain a tested patch series on top of the kernel that includes some things that are not in mainline, as well as providing tools to aid kernel development | 13:46 |
| lpapp | there is no such a thing as PROVIDES in the recipe though. | 13:46 |
| lpapp | nor in the .inc | 13:46 |
| bluelightning | lpapp: any difference in PACKAGES will also constitute a difference in effective PROVIDES | 13:46 |
| bluelightning | sveinse: dvhart or zeddii are your best bet for a proper answer to that question | 13:47 |
| sveinse | bluelightning: Thanks, I think that's enough info now. I just wanted to know if I lost something when deviating to a custom kernel. E.g. android requires many androidisms to be able to work | 13:47 |
| rburton | sveinse: i'm no expert, but if you want to roll your own kernel then feel free. yocto doesn't expect any patches to be applied, unlike android. | 13:48 |
| ant_work | sveinse: about yocto kernel the patchset is 'public' but the advantage you get are 1) is maintained 2) free stable patchsets, 3) almost zero maintenance | 13:48 |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto | 13:48 | |
| denix | are people now trying to add random stuff to their bblayers.conf? | 13:49 |
| denix | melonipoika: why are you even adding arago-oe-dev to yocto config? | 13:49 |
| lpapp | grep PACKAGES -rn ../meta/recipes-core/busybox/ | 13:50 |
| lpapp | ../meta/recipes-core/busybox/busybox.inc:18:PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev ${PN}-hwclock" | 13:50 |
| lpapp | ../meta/recipes-core/busybox/busybox.inc:27:INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev ${PN}-hwclock" | 13:50 |
| lpapp | ../meta/recipes-core/busybox/busybox.inc:36:SYSTEMD_PACKAGES = "${PN}-syslog" | 13:50 |
| sveinse | point is, we have a product on the marked where a custom kernel was developed for the custom HW (omap3 based display device). So now I'm considering yocto to be able to make a smaller, more lean system. | 13:50 |
| lpapp | grep PACKAGES -rn ../meta-foo/recipes-core/busybox/ | 13:51 |
| lpapp | ../meta-foo/recipes-core/busybox/busybox.inc:26:PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev" | 13:51 |
| lpapp | ../meta-foo/recipes-core/busybox/busybox.inc:34:INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-udhcpc ${PN}-mdev" | 13:51 |
| lpapp | hwclock maybe? | 13:52 |
| bluelightning | lpapp: not unlikely: meta/recipes-core/packagegroups/packagegroup-core-boot.bb: ${@base_contains("MACHINE_FEATURES", "rtc", "busybox-hwclock", "", d)} \ | 13:52 |
| *** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC | 13:52 | |
| lpapp | bluelightning: then what else to check, really | 13:54 |
| sveinse | So here I am n00b-ing and trying to figure out where to go after watching the getting started screencast and building my first image with the quick start manual | 13:54 |
| *** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has quit IRC | 13:55 | |
| bluelightning | lpapp: no, I mean it's likely to be the lack of busybox-hwclock that's causing the issue | 13:55 |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has quit IRC | 13:56 | |
| lpapp | btw, poky-denzil-7.0.1/meta/recipes-core/busybox/busybox.inc -> it contains tabs | 13:56 |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has joined #yocto | 13:56 | |
| lpapp | so old denzil code was bad, and it was not our mistake apparently. | 13:56 |
| ant_work | sveinse: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/tree/00-README | 13:56 |
| * zeddii has to bolt to the airport. grab me by email if there are questions. | 13:56 | |
| *** zeddii <zeddii!~ddez@128.224.252.2> has quit IRC | 13:56 | |
| bluelightning | lpapp: we introduced the requirement after denzil, before that it was an inconsistent mess, hence why we changed to enforce four spaces | 13:56 |
| bluelightning | lpapp: FWIW, this was mentioned in the migration info I linked yesterday | 13:57 |
| lpapp | do you have that link at hand? | 13:57 |
| bluelightning | lpapp: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#migration | 13:58 |
| sveinse | IMHO there is a gap in the docs from the tutorial building an existing image/system to the various dev manuals. Particularly I'm lacking a small howto to setup a new BSP and how to setup a new top-level configuration where you can select which packages go into the image. | 13:58 |
| *** belen <belen!~Adium@134.134.139.70> has quit IRC | 13:58 | |
| lpapp | bluelightning: yeah, hw-clock was it. | 13:59 |
| -YoctoAutoBuilder- build #227 of poky-tiny is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/poky-tiny/builds/227 | 14:00 | |
| lpapp | so how about the other toolchain errors? | 14:00 |
| sveinse | ant_work: Thanks. Another option is to rebase our kernel changes into a yocto kernel clone | 14:00 |
| lpapp | elibc, etc? | 14:00 |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 14:00 | |
| lpapp | and external-sourcery-toolchain | 14:00 |
| *** belen <belen!~Adium@134.134.139.70> has joined #yocto | 14:00 | |
| *** davest <davest!~Adium@134.134.139.72> has quit IRC | 14:00 | |
| ant_work | sveinse: it has been developed with git in mind but you really don't need a branch. You ca paraxite linux-yocto with a .bbappend | 14:00 |
| bluelightning_ | sveinse: or use linux-yocto-custom as a base (see meta-skeleton) | 14:01 |
| ant_work | righto | 14:01 |
| bluelightning_ | sveinse: the BSP guide should cover creating a simple BSP | 14:01 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 14:03 | |
| sveinse | bluelightning_: Perhaps it does. I'm trying to absorb and read as much as I can, so I have probably missed it. | 14:03 |
| bluelightning_ | sveinse: if you find shortcomings in the docs after looking there it would be useful feedback | 14:05 |
| lpapp | rburton: ^ | 14:06 |
| rburton | lpapp: never used an external toochain, sorry | 14:06 |
| lpapp | :( | 14:06 |
| lpapp | http://paste.kde.org/p69f1bde6/ -> so getting 3-10 basically. | 14:07 |
| lpapp | is it really external toolchain related? | 14:07 |
| lpapp | or does it happen to be a problem with that package, but a general yocto issue? | 14:07 |
| *** Crofton <Crofton!~balister@guardian-2.svamberk.cz> has joined #yocto | 14:08 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 14:08 | |
| sveinse | Let me see if I got the setup of this right: I download poky into poky/. I want to setup a git for our metas, so I use yocto-layers to create meta-laerdal as a top-level dir (only). From within that dir, I can use yocto-bsp to create a meta-myhw. And if I understand thing correctly, I should setup another meta- dir for specifying the top-level image contents | 14:09 |
| lpapp | is the external-sourcery-toolchain.bb maintainer in here? | 14:10 |
| lpapp | is it actually actively supported? | 14:10 |
| frank_fighting71 | bluelightning: you're right, I compiled with master and IMAGE_INSTALL += "libnfsidmap", succussful! Thanks! | 14:11 |
| bluelightning_ | frank_fighting71: great! | 14:11 |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has quit IRC | 14:12 | |
| bluelightning_ | lpapp: the person who usually maintains it is kergoth | 14:12 |
| frank_fighting71 | BTW, is there a way to compile multilib in yocto ? | 14:12 |
| lpapp | bluelightning_: ah, the one I ignored back then. | 14:12 |
| lpapp | bluelightning_: will ask on the mailing list anyway | 14:12 |
| bluelightning_ | frank_fighting71: yes we support multilib - http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#combining-multiple-versions-library-files-into-one-image | 14:12 |
| lpapp | not that I got solutions for my previous issues. :( | 14:13 |
| frank_fighting71 | bluelightning: Thanks ! | 14:13 |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 14:14 | |
| lpapp | bluelightning_: anyway, that issue has no relation to my layer | 14:14 |
| lpapp | not according to the error message, anyway. | 14:15 |
| lpapp | likely a platform bug. | 14:15 |
| lpapp | kergoth: bluelightning_ https://lists.yoctoproject.org/pipermail/yocto/2013-July/017394.html | 14:15 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 14:17 | |
| rburton | bluelightning_: the dev-so sanity check, i wonder if we should refine it to only warn if its a proper dev symlink, i.e. if libfoo.so points at libfoo.so.1.2.3. eg only warn if target starts with symlink name. | 14:17 |
| lpapp | but state it clearly: is the external sourcery thingie officially supported? | 14:18 |
| *** arky <arky!~arky@113.22.88.137> has joined #yocto | 14:21 | |
| lpapp | who maintains poky-dylan-9.0.0/meta/recipes-core/eglibc/eglibc_2.17.bb ? | 14:22 |
| lpapp | who maintains libiconv? | 14:23 |
| bluelightning_ | lpapp: eglibc, libiconv and the toolchain we actually build is mostly maintained by khem | 14:24 |
| lpapp | khem: idea? | 14:24 |
| lpapp | bluelightning_: I have the temptation of removing those provides from the external sourcery... | 14:25 |
| lpapp | not sure if it was blowing up... | 14:25 |
| lpapp | bluelightning_: are those supported officially? | 14:35 |
| lpapp | or just leisure time projects for someone? | 14:35 |
| bluelightning_ | lpapp: which? | 14:35 |
| lpapp | all those | 14:35 |
| frank_fighting71 | Is there a simple method to remove a default package from a image(eg,core-image-sato) ? __except__ hob. | 14:36 |
| bluelightning_ | lpapp: what we actually test: eglibc + the toolchain we actally build | 14:36 |
| *** shoragan <shoragan!~jlu@debian/developer/shoragan> has quit IRC | 14:36 | |
| lpapp | bluelightning_: so external toolchains are not supported by the yocto project? | 14:37 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 14:37 | |
| bluelightning_ | lpapp: there are a number of organisations involved in the Yocto Project that do use it in conjunction with external toolchains | 14:37 |
| lpapp | that is not what I asked. | 14:38 |
| *** ka6sox-away is now known as ka6sox | 14:38 | |
| bluelightning_ | lpapp: that is the only answer I have for you, I personally do not use an external toolchain | 14:38 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 14:39 | |
| lpapp | so you do not know, I take it. | 14:39 |
| lpapp | bluelightning_: one negative point in yocto is the lack of proper error reporting system | 14:41 |
| lpapp | hopefully it will improve over time. | 14:41 |
| bluelightning_ | lpapp: we have a proper error reporting system | 14:41 |
| lpapp | nope | 14:41 |
| bluelightning_ | lpapp: yep | 14:41 |
| lpapp | otherwise all the issues today would have been clear for everyone. | 14:41 |
| bluelightning_ | lpapp: we have some error cases where information is not displayed that would be helpful | 14:42 |
| lpapp | no no | 14:42 |
| lpapp | I mean error reporting system:- | 14:42 |
| lpapp | you have the information needed at the right place. | 14:43 |
| lpapp | bluelightning_: even bruteforce commenting of those offending packages in poky-dylan-9.0.0/meta/recipes-core/meta/external-sourcery-toolchain.bb did not help. :( | 14:47 |
| *** pidge <pidge!~pidge@c-24-21-207-18.hsd1.or.comcast.net> has quit IRC | 14:49 | |
| *** icanicant <icanicant!~klawson@195.88.236.129> has quit IRC | 14:51 | |
| lpapp | bluelightning_: what is a virtual, btw? | 14:51 |
| bluelightning_ | lpapp: it's a convention for items that may be provided by more than one provider | 14:52 |
| lpapp | bluelightning_: what is the expected result when they are? | 14:52 |
| bluelightning_ | lpapp: a PREFERRED_PROVIDER needs to be set to select which one should be built | 14:53 |
| lpapp | bluelightning_: where? | 14:54 |
| bluelightning_ | lpapp: at the global level | 14:54 |
| lpapp | means? | 14:54 |
| bluelightning_ | lpapp: local.conf, distro config, machine config depending on what you're selecting a preferred provider for | 14:56 |
| lpapp | bluelightning_: what is the point of virtual then? | 14:57 |
| bluelightning_ | lpapp: I thought I explained that above | 14:58 |
| rburton | lpapp: an example would be virtual/libgl. there's more than one GL implementation. | 14:58 |
| *** bluelightning1 <bluelightning1!~paul@83.217.123.106> has joined #yocto | 15:03 | |
| lpapp | bluelightning_: you did, but it does not make sense to me. | 15:03 |
| lpapp | bluelightning_: why do you need to tag something like that when you need to choose between two anyways? | 15:03 |
| lpapp | rburton: ? | 15:03 |
| lpapp | rburton: different implementations mean different projects with different packages. | 15:03 |
| rburton | yes | 15:03 |
| rburton | but applications just care that they get GL headers | 15:03 |
| lpapp | ? | 15:03 |
| lpapp | nope? | 15:04 |
| rburton | so packages can depend on virtual/libgl | 15:04 |
| bluelightning1 | lpapp: it's a convention, so that we know it's intended to be a selection rather than one specific recipe | 15:04 |
| *** bluelightning1 is now known as bluelightning | 15:04 | |
| lpapp | I specifically care about which gl implementation is implemented. | 15:04 |
| *** bluelightning <bluelightning!~paul@83.217.123.106> has quit IRC | 15:04 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 15:04 | |
| lpapp | i.e. not some open source crap | 15:04 |
| bluelightning | wow | 15:04 |
| lpapp | but real stuff from the vendor with 3d acceleration and so forth. | 15:04 |
| rburton | lpapp: sigh. of course *you* care, you're building the distro. | 15:04 |
| lpapp | rburton: no no | 15:04 |
| rburton | lpapp: thats why you get to pick, using PREFERRED_PROVIDER | 15:04 |
| lpapp | I care as a user of the library | 15:04 |
| lpapp | i.e. game engine developer. | 15:04 |
| rburton | but the library when its building doesn't care | 15:04 |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 15:06 | |
| *** roinn <roinn!~roinn@194.9.240.240> has quit IRC | 15:07 | |
| *** davest <davest!Adium@nat/intel/x-degonadqahyzvyum> has joined #yocto | 15:07 | |
| lpapp | so people have to pick now, but they did not need with denzil? | 15:07 |
| *** sveinse <sveinse!~chatzilla@79.160.140.131> has quit IRC | 15:07 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 15:08 | |
| rburton | virtuals have been around for many years | 15:08 |
| rburton | any errors you're seeing related to external toolchains are ... related to external toolchains. | 15:08 |
| rburton | at which point you'll need to find someone else to help as i've not used them either. | 15:08 |
| rburton | halstead: there? | 15:09 |
| *** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has quit IRC | 15:10 | |
| rburton | halstead: "Receiving objects: 13% (399274/2853620), 144.89 MiB | 5 KiB/s" <-- i was hoping for a faster clone than that from git.yocto :( | 15:10 |
| halstead | rburton, Here. On a call right now. How long has the bandwidth been constrained at that level? | 15:14 |
| rburton | halstead: it was like that for about five minutes until i noticed. aborted and re-started, now "flying" at 60K/s which still seems throttled for my connection. | 15:15 |
| *** dlern <dlern!~dlerner@128.224.250.2> has joined #yocto | 15:15 | |
| lpapp | bluelightning: rburton http://paste.kde.org/p9c2e493f/ | 15:15 |
| lpapp | r.e. busybox | 15:15 |
| lpapp | what is this again? :O | 15:15 |
| *** darknighte is now known as darknighte_znc | 15:16 | |
| lpapp | fwiw: 131 do_configure () { | 15:16 |
| lpapp | 132 do_prepare_config | 15:16 |
| lpapp | 133 merge_config.sh -m .config ${@" ".join(find_cfgs(d))} | 15:16 |
| lpapp | 134 cml1_do_configure | 15:16 |
| lpapp | 135 } | 15:16 |
| rburton | lpapp: according to grep, that's defined in busybox.inc | 15:17 |
| lpapp | this happens when using external-sourcery | 15:17 |
| lpapp | instead of external-csl | 15:17 |
| lpapp | for the TCLMODe thingie | 15:17 |
| lpapp | rburton: sure | 15:18 |
| lpapp | rburton: so what is the problem then? | 15:19 |
| lpapp | it is requiring that | 15:19 |
| rburton | lpapp: no idea, works for me. | 15:20 |
| rburton | maybe that external toolchain is breaking some other things | 15:20 |
| lpapp | rburton: but it is not toolchain scope. | 15:20 |
| lpapp | it looks like a bitbake issue. | 15:20 |
| rburton | sorry, no idea. | 15:21 |
| lpapp | yeah, I replied to bill. | 15:21 |
| lpapp | is he using irc? | 15:21 |
| wmat | am I the Bill you're referring to? ;) | 15:22 |
| lpapp | yep. :) | 15:22 |
| lpapp | hi | 15:22 |
| wmat | hello | 15:23 |
| *** zenlinux_ <zenlinux_!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC | 15:24 | |
| lpapp | wmat: got a clue for the error? | 15:24 |
| lpapp | rburton: I wonder why my predecessor thought --disable-zlib would be working ... | 15:25 |
| wmat | lpapp: not immediately | 15:25 |
| lpapp | rburton: oh, and fwiw, poky has opengl in there, but the handbook does not mention such a feature: http://pokylinux.org/doc/poky-handbook.html | 15:25 |
| rburton | lpapp: very true. http://www.yoctoproject.org/docs/current/ is the current docs, that site is old. | 15:26 |
| *** zeeblex <zeeblex!apalalax@nat/intel/x-qlaydvncefhbgowr> has left #yocto | 15:27 | |
| lpapp | rburton: perhaps it should be marked so then? | 15:27 |
| lpapp | rburton: also, the new link yields this, 403 Forbidden | 15:27 |
| rburton | lpapp: yes | 15:27 |
| rburton | https://www.yoctoproject.org/documentation/current, sorry | 15:27 |
| lpapp | rburton: well, cannot find opengl there either. | 15:28 |
| rburton | lpapp: yeah needs to be added. probably a few others missing too. | 15:28 |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto | 15:28 | |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has quit IRC | 15:29 | |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto | 15:29 | |
| lpapp | so who is the python master here? | 15:29 |
| *** frank___ <frank___!~Android@118.186.200.116> has joined #yocto | 15:30 | |
| lpapp | who can tell more about the busybox thingie? | 15:30 |
| lpapp | the function is clearly defined in the inc. | 15:30 |
| lpapp | also, why does it care about the meta / busybox? | 15:30 |
| lpapp | shouldn't it pick up my busybox from my layer? | 15:30 |
| lpapp | so the real question is: why does it not ignore the "default" from oe-core? | 15:30 |
| rburton | lpapp: its probably trying to parse it, so this is before it decides to not execute anything there | 15:31 |
| *** frank___ <frank___!~Android@118.186.200.116> has quit IRC | 15:31 | |
| lpapp | rburton: that sounds bad ordering. | 15:31 |
| rburton | lpapp: very hard to ignore something unless you know what it is | 15:32 |
| lpapp | rburton: you should know in advance what to ignore. | 15:32 |
| lpapp | it* | 15:32 |
| rburton | lpapp: but it doesn't know what it is until the file has been parsed | 15:32 |
| lpapp | it should parser the whitelist file. | 15:33 |
| lpapp | parse* | 15:33 |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 15:33 | |
| lpapp | that is what it should start with. | 15:33 |
| lpapp | and then the relevant version that is whitelisted. | 15:33 |
| lpapp | in any case, how parsing a python file can be related to an external toolchain? | 15:34 |
| lpapp | I am using python 2.7 fwiw. | 15:35 |
| lpapp | let us see if they get a clue on #python. | 15:40 |
| rburton | lpapp: #python can't help | 15:41 |
| lpapp | well, tell me a better place for help. | 15:41 |
| rburton | well, here | 15:41 |
| lpapp | yeah, like no one has been giving solutions for external toolchain issues for two days? | 15:41 |
| rburton | if you can reliably replicate changing the toolchain means the error disappears and appears, then that's a good data point | 15:42 |
| *** lpapp <lpapp!~lpapp@212.44.19.228> has quit IRC | 15:42 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 15:42 | |
| rburton | and bitbake -e will be very useful to find the differences that causes | 15:42 |
| *** mihai <mihai!~mihai@80.97.15.150> has quit IRC | 15:42 | |
| rburton | here is best, but also a limited number of people use external toolchains, so you'll have to be patient | 15:42 |
| lpapp | business does not work with patient. | 15:42 |
| lpapp | if I do not get help, I need to go the hard way. | 15:42 |
| rburton | doesn't help that you'd blocked the one guy who is best placed to help | 15:42 |
| lpapp | well, he could reply on the mailing list? | 15:43 |
| rburton | business can pay for support from a commercial support partner | 15:43 |
| lpapp | no no | 15:43 |
| lpapp | business does not mean people have money for everything. | 15:43 |
| rburton | sure | 15:43 |
| rburton | two options. 1) pay for support. 2) community support. | 15:43 |
| lpapp | 3) solve it yourself. | 15:43 |
| rburton | sure | 15:43 |
| lpapp | meh, even bitbake help is broken with dylan. :( | 15:45 |
| rburton | really sounds like you've broken your setup somehow | 15:45 |
| lpapp | ? | 15:45 |
| lpapp | bitbake help -> starts building | 15:45 |
| lpapp | it should not start | 15:45 |
| rburton | sure | 15:45 |
| rburton | why not? | 15:46 |
| lpapp | it should print the help output. | 15:46 |
| rburton | you've told it to build "help" | 15:46 |
| rburton | did you mean --help? | 15:46 |
| lpapp | huh? | 15:46 |
| wmat | lpapp: bitbake help is not broken on my dylan setup | 15:46 |
| lpapp | wasn't the "help" the same for the bblayer util? | 15:46 |
| lpapp | and for this, it is --help? | 15:46 |
| lpapp | isn't that tad confusing? | 15:46 |
| *** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has joined #yocto | 15:46 | |
| rburton | patches welcome | 15:46 |
| *** darknighte_znc is now known as darknighte | 15:47 | |
| rburton | bitbake-layers is a tiny little convenience tool | 15:47 |
| bluelightning | lpapp: FWIW, --help on bitbake-layers will trigger the help output anyway | 15:47 |
| lpapp | bluelightning: not for me, anyhow | 15:47 |
| lpapp | also, why is that not the official way? | 15:48 |
| lpapp | I have been told stuff help here yesterday | 15:48 |
| lpapp | so I tried that for bitbake | 15:48 |
| rburton | if we're going to argue about command syntax, bitbake-layers is the outlier | 15:48 |
| rburton | i suggest living with it | 15:48 |
| lpapp | rburton: the bitbake -e output is quite spammy. | 15:49 |
| rburton | lpapp: that's not spam, it's the entire configuration space | 15:49 |
| rburton | you might be able to identify why changing toolchain breaks busybox with that | 15:49 |
| lpapp | rburton: bitbake -e busybox should do it? | 15:50 |
| rburton | lpapp: yep | 15:50 |
| lpapp | k | 15:51 |
| lpapp | rburton: did not help | 15:54 |
| lpapp | bitbake -e busybox > sourcery.log | 15:54 |
| lpapp | rburton: http://paste.kde.org/p29f3c3a3/ | 15:55 |
| *** eren <eren!~eren@unaffiliated/eren> has quit IRC | 15:55 | |
| lpapp | it is not actually printing such stuff. | 15:55 |
| *** volker <volker!~volker@host-80-81-19-29.customer.m-online.net> has quit IRC | 15:56 | |
| *** Guest99011 <Guest99011!~tbn@84.55.160.118> has quit IRC | 15:56 | |
| lpapp | rburton: so something even before -e is broken in the pipeline. | 15:57 |
| wmat | lpapp: what version of Python and what version of BitBake? | 15:58 |
| *** belen <belen!~Adium@134.134.139.70> has quit IRC | 15:58 | |
| wmat | lpapp: and what CSL toolchain? I'll try to reproduce your error. | 15:59 |
| *** zenlinux <zenlinux!~sgarman@c-24-20-23-64.hsd1.or.comcast.net> has joined #yocto | 15:59 | |
| lpapp | wmat: CSL toolchain means? | 16:00 |
| wmat | lpapp: CodeSourcery? | 16:00 |
| lpapp | wmat: arm-2009q1 if that is what you mean. | 16:00 |
| wmat | lpapp: yes | 16:00 |
| *** belen <belen!Adium@nat/intel/x-qmhwzbggigudgfzl> has joined #yocto | 16:01 | |
| lpapp | sorry, I was wrong | 16:01 |
| lpapp | I regenerated sourcery.log and now it is more complete. | 16:01 |
| wmat | lpapp: the EABI or GNU/Linux toolchain? | 16:02 |
| lpapp | wmat: arm-none-linux-gnueabi | 16:05 |
| kergoth | it's worth noting that mentor themselves haven't given much attention to the external-sourcery in oe-core, leaving it primarily as an example. we maintain https://github.com/MentorEmbedded/meta-sourcery | 16:06 |
| kergoth | we intend to sort out this situation to reduce confusion in the near future | 16:06 |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has quit IRC | 16:07 | |
| *** zenlinux <zenlinux!~sgarman@c-24-20-23-64.hsd1.or.comcast.net> has quit IRC | 16:10 | |
| lpapp | denzil external-cs worked just fine | 16:11 |
| lpapp | it is so sad that dylan broke the external toolchain usage. :( | 16:11 |
| lpapp | external-csl* | 16:11 |
| *** arky <arky!~arky@113.22.88.137> has quit IRC | 16:12 | |
| *** zenlinux <zenlinux!~sgarman@c-24-20-23-64.hsd1.or.comcast.net> has joined #yocto | 16:13 | |
| lpapp | what was the reason of not keeping external-csl around? | 16:13 |
| lpapp | until you have a _stable_ and _mature_ external-sourcery? | 16:13 |
| lpapp | for embedded developers, probably denzil is the way to go then... but that is not maintained. :( | 16:14 |
| lpapp | so in the end of the day, embedded developers are screwed. | 16:14 |
| lpapp | using cross-toolchain. :( | 16:14 |
| wmat | the fix may be a simple patch once the problem is determined | 16:16 |
| lpapp | sure, but it is beyond my league. | 16:16 |
| lpapp | and a patch will not get into the release now. :( | 16:16 |
| *** ivali <ivali!~ivali@unaffiliated/ivali> has quit IRC | 16:16 | |
| lpapp | cat csl.log | ix | 16:24 |
| lpapp | http://ix.io/6QZ | 16:24 |
| lpapp | cat sourcery.log | ix | 16:25 |
| lpapp | http://ix.io/6R1 | 16:25 |
| lpapp | if anyone can check the mystery with diff. | 16:25 |
| lpapp | I do not see significant diffs. | 16:25 |
| *** mckoan is now known as mckoan|away | 16:26 | |
| *** alexhairyman <alexhairyman!~alexhairy@c-174-52-149-118.hsd1.ut.comcast.net> has joined #yocto | 16:30 | |
| *** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has quit IRC | 16:30 | |
| lpapp | wmat: I wonder if you could check the diff. | 16:33 |
| lpapp | wmat: also, could you reproduce the issue? | 16:33 |
| wmat | lpapp: I'm still waiting for Mentor to send me the link to download the toolchain :/ | 16:34 |
| rburton | lpapp: the diff doesn't appear to contain anything apart from an extra include and timestamps | 16:35 |
| rburton | lpapp: you can reliably switch between the two toolchain modes and the error changes? | 16:35 |
| lpapp | wmat: I can send it to you if that is quicker. | 16:36 |
| lpapp | rburton: as written, yes. | 16:36 |
| lpapp | rburton: + image name. | 16:36 |
| lpapp | + do_devshell hash | 16:37 |
| lpapp | rburton: so you think, the diff is ok, then? | 16:42 |
| lpapp | rburton: and the issue cannot be figured out from it? | 16:42 |
| rburton | lpapp: nope | 16:43 |
| lpapp | rburton: nope? | 16:44 |
| lpapp | for which question, that is | 16:45 |
| rburton | the diff is fine, but its not useful | 16:45 |
| wmat | lpapp: how large is the toolchain file? is it email-able? | 16:47 |
| lpapp | wmat: of course no. :) | 16:47 |
| lpapp | wmat: but I can put it on dropbox. | 16:47 |
| wmat | ok, make it so | 16:47 |
| lpapp | wmat: which host do you use? | 16:47 |
| wmat | lpapp: linux x86_64 | 16:48 |
| lpapp | wmat: I mean which distro | 16:48 |
| lpapp | arch looks the same as mine | 16:48 |
| lpapp | so my binaries should work then. | 16:48 |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 16:49 | |
| lpapp | wmat: phew, it takes ages to just compress. | 16:50 |
| lpapp | lot of translation stuff. :/ | 16:51 |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 16:51 | |
| wmat | lpapp: for dany, did you download the tarball or clone the repo? | 16:52 |
| lpapp | wmat: it is dylan | 16:52 |
| lpapp | I downloaded the release 9.0.0 | 16:52 |
| lpapp | wmat: hmm, sorry, I cannot send the toolchain. | 16:53 |
| lpapp | it contains our git history. | 16:53 |
| lpapp | again, what is your linux host? | 16:53 |
| lpapp | I would be surprised if they did not provide ready-made binaries off-hand. | 16:53 |
| -YoctoAutoBuilder- build #223 of nightly-mips is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-mips/builds/223 | 16:54 | |
| lpapp | what toolchain was the sourcery thingie tested? | 16:55 |
| lpapp | with* | 16:55 |
| *** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 16:56 | |
| lpapp | rburton: is there a zlib disabling distro feature? | 16:56 |
| rburton | lpapp: nope | 16:56 |
| *** belen <belen!Adium@nat/intel/x-qmhwzbggigudgfzl> has quit IRC | 16:57 | |
| rburton | if you really don't want zlib installed you'll have to use bbappends to disable it in each recipe that links to it | 16:57 |
| lpapp | phew... | 16:58 |
| lpapp | that is kinda crazy. :) | 16:58 |
| mr_science | not as crazy as what i just did lat night... | 16:59 |
| lpapp | that does not comform me, I am afraid. | 16:59 |
| lpapp | comfort* | 16:59 |
| lpapp | but my sympathy is there though. | 16:59 |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-wzqcdggrptpydfjq> has quit IRC | 17:00 | |
| *** belen <belen!Adium@nat/intel/x-ivyjprgxklmanphc> has joined #yocto | 17:00 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-xjmbwkbvrlwhnoel> has joined #yocto | 17:01 | |
| *** fitzsim <fitzsim!~user@nat/cisco/x-gatiaonknqjnejaw> has joined #yocto | 17:04 | |
| wmat | lpapp: mentor does provide binaries, I just haven't received the link to download them yet | 17:05 |
| rburton | lpapp: if you're even considering removing zlib you've clearly got a tiny install image, so it won't be a lot of effort | 17:05 |
| wmat | lpapp: x86_64 | 17:05 |
| lpapp | rburton: well, we are using nor flashes | 17:05 |
| lpapp | 32 MB | 17:05 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 17:06 | |
| lpapp | wmat: yeah, but the distribution package would not need waiting. | 17:06 |
| wmat | lpapp: i found a link in an old email. You said a 2009 version? | 17:09 |
| lpapp | wmat: quarter 1, yes. | 17:10 |
| *** iwamatsu___ <iwamatsu___!~iwamatsu@www1015ue.sakura.ne.jp> has quit IRC | 17:11 | |
| *** iwamatsu___ <iwamatsu___!~iwamatsu@www1015ue.sakura.ne.jp> has joined #yocto | 17:11 | |
| *** sameo <sameo!~samuel@192.55.54.36> has quit IRC | 17:14 | |
| *** eren <eren!~eren@unaffiliated/eren> has joined #yocto | 17:19 | |
| lpapp | wmat: did you get the link? | 17:22 |
| lpapp | wmat: btw, you do not need to await any link | 17:22 |
| lpapp | https://developer.ridgerun.com/wiki/index.php/Code_Sourcery_ARM_toolchain_2009q1-203 | 17:22 |
| lpapp | the one from here can be downloaded off-hand. | 17:22 |
| lpapp | wmat: could you obtain it a way or another? | 17:26 |
| *** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has quit IRC | 17:26 | |
| wmat | lpapp: i have it now | 17:27 |
| lpapp | wmat: can you repro the issue? | 17:27 |
| wmat | lpapp: so the only customizations you did were what? | 17:27 |
| lpapp | my layer | 17:27 |
| lpapp | and that is pretty much it | 17:27 |
| wmat | to conf files? | 17:28 |
| lpapp | MACHINE ?= "polatisnic" | 17:28 |
| lpapp | oopsie | 17:28 |
| lpapp | sorry, for the spam | 17:28 |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has quit IRC | 17:28 | |
| lpapp | MACHINE ?= "mymachine" | 17:28 |
| lpapp | DISTRO ?= "mydistro-tiny" | 17:28 |
| lpapp | and that is it | 17:28 |
| lpapp | and of course TCMODE = "external-csl" | 17:29 |
| lpapp | EXTERNAL_TOOLCHAIN = "/usr/local/arm-2009q1" | 17:29 |
| lpapp | TARGET_PREFIX = "arm-none-linux-gnueabi-" | 17:29 |
| lpapp | I can try with poky-tiny as well | 17:29 |
| lpapp | or even "poky" for now. | 17:29 |
| lpapp | perhaps I should not, though. | 17:29 |
| * lpapp is not sure | 17:29 | |
| lpapp | help is appreicated. | 17:29 |
| lpapp | appreciated* | 17:29 |
| wmat | lpapp: I'll use beagleboard | 17:30 |
| lpapp | for the machine, right? | 17:30 |
| wmat | yes | 17:30 |
| lpapp | for the DISTRO? | 17:30 |
| wmat | poky | 17:30 |
| lpapp | ok, let me try with that | 17:31 |
| wmat | and what command like bitbake did you issue? | 17:31 |
| lpapp | unparsed line: 'MACHINE ?= beagleboard' | 17:31 |
| lpapp | bitbake core-image-minimal | 17:32 |
| lpapp | ah, missing quotes. | 17:32 |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 17:32 | |
| lpapp | hmm, I cannot reproduce the issue with those setups. | 17:33 |
| *** jkridner <jkridner!~jkridner@67.23.204.2> has joined #yocto | 17:34 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 17:34 | |
| lpapp | is there a way to surpress the host distribution warning about unsupported stuff? | 17:35 |
| bluelightning | lpapp: SANITY_TESTED_DISTROS = "" in your local.conf | 17:36 |
| lpapp | thanks | 17:38 |
| lpapp | I do not like the syntax of that, but it will do it for now. | 17:38 |
| bluelightning | it's a list of distros that have been tested as used by sanity.bbclass; if no list is specified the host distro isn't checked | 17:39 |
| bluelightning | (since there's nothing to check it against) | 17:40 |
| lpapp | it would be nice to have a boolean syntax for this. | 17:41 |
| lpapp | for enabling/disabling | 17:41 |
| *** galak <galak!~galak@99-51-185-173.lightspeed.austtx.sbcglobal.net> has joined #yocto | 17:41 | |
| lpapp | wmat: I use armv5 fwiw. | 17:42 |
| lpapp | wmat: yeah, I can definitely reproduce it with poky and beagleboard | 17:44 |
| lpapp | although with my layer inside the bblayers.conf | 17:44 |
| lpapp | not sure that should matter. | 17:44 |
| *** zenlinux <zenlinux!~sgarman@c-24-20-23-64.hsd1.or.comcast.net> has quit IRC | 17:45 | |
| wmat | as soon as you issue the bitbake command, do you see the two errors about the missing toolchain? | 17:45 |
| lpapp | wmat: no | 17:45 |
| lpapp | only at home. | 17:46 |
| lpapp | here at the company, I do not see that error. | 17:46 |
| wmat | you did say you were using arm-none-eabi-* correct? | 17:47 |
| wmat | not arm-none-linux-gnueabi-*? | 17:48 |
| lpapp | wmat: gnueabi what I use. | 17:50 |
| lpapp | but this is now strange... I can even reproduce with external-csl | 17:50 |
| lpapp | if I use the poky+beagleboard setup. | 17:50 |
| lpapp | wmat: so could you reproduce the issue? | 17:51 |
| wmat | lpapp: I ahve to grab the gnueabi toolchain, as I only have the eabi toolchain now | 17:54 |
| lpapp | wmat: I already gave you the link, https://developer.ridgerun.com/wiki/index.php/Code_Sourcery_ARM_toolchain_2009q1-203 | 17:55 |
| lpapp | wmat: btw, what errors did you get? | 17:55 |
| lpapp | is it similar to what I got at home? | 17:55 |
| lpapp | some INVALID stuff in the error? | 17:55 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 17:55 | |
| wmat | lpapp: gimme a sec | 17:56 |
| lpapp | wmat: it could potentially help me a lot if you express that. | 17:57 |
| wmat | lpapp: i'm sure it would, I just need time to complete the test | 17:57 |
| lpapp | what test? | 17:57 |
| *** belen <belen!Adium@nat/intel/x-ivyjprgxklmanphc> has quit IRC | 17:57 | |
| lpapp | I thought you would have already done the experiment? | 17:57 |
| lpapp | for the wrong toolchain, so you could just paste the output you got? | 17:57 |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 17:59 | |
| *** belen <belen!~Adium@134.134.139.70> has joined #yocto | 17:59 | |
| wmat | lpapp: it's building now with the correct toolchain | 18:01 |
| lpapp | wmat: I do not think you need to go that far. | 18:01 |
| lpapp | it does not even start the building for me. | 18:01 |
| lpapp | so if it is building for you, you simply cannot reproduce the issue. | 18:02 |
| *** smartin_ <smartin_!~smartin@ivr94-4-82-229-165-48.fbx.proxad.net> has joined #yocto | 18:02 | |
| wmat | yep, mine is building fine | 18:03 |
| lpapp | so, can you give me the error message then? | 18:03 |
| wmat | I got an error about multiple .bb files are going to be built for eglibc | 18:04 |
| wmat | and an error about zlib fetch failed | 18:05 |
| lpapp | when? | 18:05 |
| lpapp | with the gnueabi toolchain? | 18:05 |
| wmat | yes | 18:05 |
| lpapp | "I got an error about multiple .bb files are going to be built for eglibc | 18:05 |
| lpapp | " | 18:05 |
| lpapp | that looks exactly my issue | 18:05 |
| lpapp | if you read my email | 18:05 |
| wmat | but with -k, it keeps building | 18:05 |
| lpapp | and with the right toolchain, you do not get those errors? | 18:06 |
| wmat | no, I do | 18:06 |
| wmat | because the eglibc recipe exists twice | 18:07 |
| lpapp | right, so you can actually reproduce then. | 18:07 |
| wmat | once in core and once in meta | 18:07 |
| lpapp | could you please make sure you are getting the same errors as me on the mailing list? | 18:07 |
| * wmat looks again | 18:07 | |
| lpapp | ok, so it is an upstream bug. | 18:07 |
| lpapp | nothing to do with my setup. | 18:07 |
| lpapp | also, could you please let me know the error with the wrong toolchain? | 18:09 |
| *** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto | 18:09 | |
| wmat | just that it couldn't find the toolchain, which is correct | 18:10 |
| lpapp | mind pasting the error message? | 18:10 |
| lpapp | is it the same I have on the mailing list? | 18:10 |
| lpapp | granted | 18:10 |
| lpapp | I can reproduce the busybox thingie even with dylan vanilla | 18:11 |
| lpapp | without my layer | 18:11 |
| wmat | lpapp: no, it wasn't the same. It was just a missing toolchain error, as I didn't have the right toolchain. | 18:11 |
| wmat | I didn't save it | 18:12 |
| lpapp | wmat: no, I mean I have two errors | 18:12 |
| lpapp | the one here at the company | 18:12 |
| lpapp | and in the same thread, I had another from home, yesterday. | 18:12 |
| lpapp | wmat: in any case, is this a hard fix upstream for the external thingie? | 18:12 |
| wmat | lpapp: once the build completes, I can paste the log somewhere | 18:13 |
| lpapp | hope the fix can come with a poky dylan bugfix release soon in the near future ... | 18:13 |
| lpapp | wmat: I do not particularly need the log. | 18:13 |
| lpapp | we already discussed it. | 18:13 |
| wmat | lpapp: well, a bug needs to be opened for it to be fixed | 18:13 |
| lpapp | or if you mean for the wrong toolchain, then ok. | 18:13 |
| lpapp | wmat: that is the less issue. | 18:13 |
| lpapp | the main thing is that do you have any clue how to fix it? | 18:14 |
| wmat | at present, no | 18:15 |
| lpapp | :( | 18:16 |
| lpapp | wmat: can you ask kergoth | 18:16 |
| lpapp | I think he is ignoring me | 18:16 |
| lpapp | otherwise he would have chimmed in already. | 18:16 |
| sgw1 | lpapp: I replied to your email, please file a bug with all your configuration files so that the information is all in one place | 18:17 |
| wmat | I have to move onto other work now, but I'd try opening a bug | 18:17 |
| lpapp | sgw1: I already did | 18:18 |
| *** belen <belen!~Adium@134.134.139.70> has quit IRC | 18:18 | |
| sgw1 | lpapp: where, I just checked the bugzilla.yoctoproject.org and do not see any bug from you | 18:19 |
| lpapp | sgw1: maybe you need to refresh or so | 18:20 |
| sgw1 | lpapp sorry, timing of bugzilla I guess | 18:20 |
| lpapp | I did it a couple of minutes ago | 18:20 |
| lpapp | anyway, even if no one can work on it, I need a workaround ASAP | 18:21 |
| lpapp | it is kinda blocking my company work right now. | 18:21 |
| lpapp | wmat: is the -k thingie an acceptable workaround? | 18:21 |
| lpapp | it will not blow up later? | 18:21 |
| sgw1 | lpapp: understood, I am going to try and repoduce this here now | 18:21 |
| wmat | lpapp: I use -k frequently | 18:22 |
| sgw1 | lpapp: to confirm, you are now using dlyan HEAD from git? | 18:22 |
| lpapp | sgw1: no | 18:22 |
| lpapp | dylan 9.0.0 | 18:22 |
| sgw1 | lpapp: I thought it was suggested that you use dylan HEAD, since there are some patches that you needed in it. | 18:23 |
| sgw1 | ok I will use the 9.0.0 tag | 18:23 |
| lpapp | sgw1: we cannot afford the risk as a company. | 18:23 |
| lpapp | if something is not working, we need to backport. | 18:24 |
| lpapp | the relevant stabilization patches. | 18:24 |
| kergoth | I've often thought that bitbake's -k argument would make a sane default behavior, if we did a little better job of summarizing the results and failures at the end | 18:24 |
| lpapp | but we definitely cannot base stuff on a rolling 'dev' branch. | 18:24 |
| lpapp | sgw1: please check the bugreport again, as I have just written a few additional information about the toolchain, and the dylan version. | 18:25 |
| lpapp | well, I can try HEAD | 18:25 |
| lpapp | it does not take long | 18:25 |
| lpapp | not that we will use it. | 18:25 |
| lpapp | but we can see if it got fixed in there. | 18:25 |
| wmat | kergoth: I'd agree with that. I'd rather complete a build and deal with a nice log file afterwards. | 18:27 |
| kergoth | it requires much less babysitting | 18:27 |
| kergoth | and developer time is valuable | 18:27 |
| lpapp | wmat: what is the workaround? | 18:28 |
| sgw1 | lpapp if not head how about the stable update of 9.0.1? | 18:28 |
| wmat | lpapp: use -k is all I did | 18:28 |
| lpapp | wmat: is that acceptable? | 18:28 |
| lpapp | will it not blow up later? | 18:28 |
| lpapp | can we breath the air safely afterwards? | 18:28 |
| wmat | lpapp: it's acceptable to me | 18:28 |
| sgw1 | lpapp what command did you issue to get the failure? | 18:29 |
| lpapp | sgw1: we can only use releases. | 18:29 |
| lpapp | and if we choose dylan now, we will stick to it for at least a year | 18:29 |
| sgw1 | lpapp: 9.0.1 is a release | 18:29 |
| *** alexhairyman <alexhairyman!~alexhairy@c-174-52-149-118.hsd1.ut.comcast.net> has quit IRC | 18:29 | |
| lpapp | and only stable bugfix releases would be acceptable. | 18:29 |
| lpapp | sgw1: not mentioned on the website. | 18:29 |
| sgw1 | it's the stable bugfix release for dylan | 18:29 |
| lpapp | sgw1: fix the website then. | 18:29 |
| wmat | lpapp: also, why not use a newer toolchain? | 18:30 |
| lpapp | wmat: because our software is based on old? | 18:30 |
| lpapp | wmat: and we did not have the time to fix stuff around it when even yocto does not work? | 18:30 |
| lpapp | you know ... step by step. | 18:31 |
| lpapp | we are not an engineer army. | 18:31 |
| lpapp | I would love to update to 2013.05 due to C++11 | 18:31 |
| sgw1 | lpapp: it's on the website, www.yoctoproject.org/downloads, first item on the list Poky 9.0.1 released 6/27, fix your eyes ;-) | 18:31 |
| lpapp | and later to c++14 | 18:31 |
| lpapp | sgw1: https://www.yoctoproject.org/download/yocto-project-14-poky-900 | 18:31 |
| lpapp | first result on google | 18:31 |
| sgw1 | lpapp: what command did you use to get the failure: bitbake ??? | 18:31 |
| lpapp | poky dylan download | 18:32 |
| lpapp | I get no selectable list | 18:32 |
| lpapp | sgw1: check bugzilla, please. | 18:32 |
| kergoth | Hmm. | 18:32 |
| sgw1 | lpapp: click on the downloads link and you will get the list | 18:32 |
| lpapp | bitbake core-image-minimal | 18:33 |
| lpapp | ERROR: ParseError at /home/lpapp/Projects/poky/meta/recipes-core/gettext/gettext_0.18.1.1.bb.BACKUP.13382.bb:8: unparsed line: '<<<<<<< HEAD' | ETA: 00:00 | 18:33 |
| lpapp | master is even more broken. :( | 18:33 |
| sgw1 | lpapp: I just checked the bug, so you mean core-image-minimal since image minimal is not a valid target | 18:33 |
| lpapp | sgw1: yeah, that is a typo, and the crappy bugzilla does not allow edit. | 18:34 |
| lpapp | so yeah, master is more broken. | 18:35 |
| lpapp | is there any stable release for dylan? | 18:35 |
| lpapp | my last try is 9.0.1 | 18:36 |
| sgw1 | lpapp, I have to go for a while lunch here, back later build is in progress | 18:36 |
| lpapp | I need to leave anyway | 18:36 |
| lpapp | it is getting 8 pm in here. | 18:36 |
| sgw1 | lpapp, I hope to have something for you later my afternoon | 18:37 |
| lpapp | that would be appreciated. | 18:37 |
| wmat | i see multiple eglibc recipes with git head as well | 18:38 |
| lpapp | kergoth mentioned the stuff is totally unmaintained in oe-core | 18:38 |
| lpapp | and they use meta-sourcery | 18:38 |
| lpapp | so perhaps it is a "not possible" fix. | 18:38 |
| lpapp | and the proper integration fix would come months later. | 18:38 |
| lpapp | that frankly scares me | 18:38 |
| *** JaMa <JaMa!~martin@ip-62-24-80-145.net.upcbroadband.cz> has quit IRC | 18:39 | |
| lpapp | but I will stop being pessimistic. | 18:39 |
| lpapp | denzil seems to have worked. | 18:39 |
| lpapp | too bad I spent 2-3 days with it if it is now worse. | 18:39 |
| lpapp | wmat: right, so it is probably not fixed in 9.0.1 either | 18:40 |
| lpapp | although I am trying, just in case ... | 18:40 |
| *** JaMa <JaMa!~martin@ip-62-24-80-145.net.upcbroadband.cz> has joined #yocto | 18:40 | |
| rburton | lpapp: that parse error is because its parsing the output of a merge, delete those files | 18:41 |
| lpapp | what worries me is that it seems there is no QA gate for external toolchains | 18:41 |
| rburton | both the filename and the line its failing to parse tell you its the output from a merge conflict | 18:41 |
| lpapp | rburton: there is no any merge. | 18:41 |
| lpapp | it is a fresh clone/pull. | 18:41 |
| lpapp | no QA toolchain because denzil worked, same stuff got broken by dylan. | 18:42 |
| lpapp | there is no proper regression test. | 18:42 |
| lpapp | which again, makes me unsafe about using Yocto | 18:42 |
| rburton | lpapp: "/home/lpapp/Projects/poky/meta/recipes-core/gettext/gettext_0.18.1.1.bb.BACKUP.13382.bb" | 18:42 |
| rburton | merge conflict | 18:42 |
| lpapp | rburton: well I just cloned and pulled. | 18:42 |
| lpapp | it can hardly my mistake. :) | 18:43 |
| rburton | ok, lets check git | 18:43 |
| rburton | what revision have you checked out? | 18:43 |
| lpapp | latest | 18:43 |
| lpapp | master HEAD | 18:43 |
| lpapp | I also mentioned in the bugreport. | 18:44 |
| *** jkridner|work <jkridner|work!~jkridner@nat/ti/x-legwuvlkjdmkydxm> has joined #yocto | 18:44 | |
| rburton | http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/gettext | 18:44 |
| rburton | i don't see a file called gettext_0.18.1.1.bb.BACKUP.13382.bb | 18:44 |
| rburton | so its local to you | 18:44 |
| lpapp | yeah, same issue with 9.0.1 | 18:44 |
| rburton | its a merge confict which bitbake is attempting to parse | 18:44 |
| rburton | delete it | 18:44 |
| lpapp | rburton: well I deleted the whole repository | 18:44 |
| rburton | do a git status and check there's nothing else sitting around like that too | 18:44 |
| lpapp | and I am cloning a brand new stuff | 18:45 |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 18:45 | |
| * rburton -> dinner/jog/etc | 18:45 | |
| lpapp | phew, clone is extremely slow. | 18:45 |
| * lpapp -> dinner/cycling/etc | 18:46 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 18:48 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 18:51 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-xjmbwkbvrlwhnoel> has quit IRC | 18:55 | |
| kergoth | sent out an rfc about some read-only-rootfs and tmpfiles bits to oe-core list, would appreciate comments/thoughts before i take any further steps with it | 18:57 |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-isyxsflkanupbgxu> has joined #yocto | 18:58 | |
| *** ant_home <ant_home!~andrea@host88-64-dynamic.8-87-r.retail.telecomitalia.it> has joined #yocto | 19:01 | |
| *** zeddii <zeddii!~bruce@65-114-90-17.dia.static.qwest.net> has joined #yocto | 19:03 | |
| *** tlwoerner <tlwoerner!~trevor@linaro/tlwoerner> has quit IRC | 19:07 | |
| *** djszapi <djszapi!~lpapp@kde/lpapp> has joined #yocto | 19:13 | |
| djszapi | wmat: what error did you get with the wrong toolchain? | 19:14 |
| wmat | djszapi: I can try it again if you like, buy I can't remember now | 19:15 |
| *** djszapi is now known as lpapp | 19:15 | |
| lpapp | please do if you can. | 19:15 |
| wmat | but why, as it's not the same toolchain you're using? | 19:15 |
| wmat | and I set the local.conf file to my 'wrong' toolchain as well | 19:16 |
| wmat | fwiw, with master HEAD and the same toolchain as you, I get 3 errors regarding multiple eglibc recipes and 1 error regarding do_install trying to cp to a nonexisting location | 19:17 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 19:17 | |
| kergoth | I really recommend using meta-sourcery with current sourcery g++ toolchains. it's 100% known working, used by me and others all day every day, and is fully supported by us | 19:19 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 19:19 | |
| lpapp | wmat: I missed it, I guess. | 19:19 |
| kergoth | it's also part of the mentor embedded linux commercial product | 19:19 |
| wmat | lpapp: exact same errors. 3 eglibc issues, and 1 issue with a missing location | 19:22 |
| *** forcev <forcev!~quassel@wafaa.eu> has joined #yocto | 19:22 | |
| wmat | lpapp: I'm done with this now. I'd try meta-sourcery. | 19:23 |
| kergoth | we moved to a separate layer because it was the only way to avoid having tuning argument overrides in the tcmode file, as there are certain sourcery-only tuning arguments that hae to be used in ertain contexts to ensure the correct multilib sysroot is used | 19:24 |
| lpapp | wmat: issue with what? | 19:24 |
| *** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC | 19:24 | |
| kergoth | either we need to add the tuning overrides to the tcmode in oe-core, despite the ugliness, or it should just be removed, or pointed out as an example only, not to be used directly | 19:24 |
| lpapp | wmat: well, this stuff worked 1.5 years ago. | 19:25 |
| kergoth | I'm currently working on breaking up the external-toolchain recipe into individual recipes for each component, but it's not my current priority | 19:25 |
| lpapp | it looks awkward that some de-evolution is taking place about it. | 19:25 |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has left #yocto | 19:25 | |
| lpapp | perhaps we should not use yocto, just a ready-made distribution. | 19:26 |
| lpapp | life might become a lot easier. | 19:26 |
| lpapp | currently there is no stable way of using a cross-compilation toolchain -> | 19:26 |
| lpapp | embedded developers are screwed mostly. | 19:26 |
| lpapp | hopefully the technology will become accessible enough in a few years to revisit the question. | 19:27 |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 19:30 | |
| -YoctoAutoBuilder- build #233 of nightly-x32 is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x32/builds/233 | 19:32 | |
| kergoth | damn, oe-core is still missing a heck of a lot of systemd services | 19:36 |
| lpapp | wmat: have you actually tested that layer/ | 19:40 |
| lpapp | ? | 19:40 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 19:40 | |
| *** lpapp <lpapp!~lpapp@cpc11-cmbg15-2-0-cust30.5-4.cable.virginmedia.com> has joined #yocto | 19:41 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 19:41 | |
| wmat | lpapp: no | 19:41 |
| lpapp | wmat: can you ask kergoth to unignore me to discuss the issue? | 19:43 |
| *** tor_ <tor_!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has quit IRC | 19:43 | |
| wmat | lpapp: i'd probably stick to the mailing list and bug report for communication with him | 19:49 |
| *** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC | 19:54 | |
| -YoctoAutoBuilder- build #222 of nightly-arm is complete: Failure [failed Running Sanity Tests Building Images_1 Building Toolchain Images Building Toolchain Images_1 Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-arm/builds/222 | 19:55 | |
| lpapp | wmat: well, he does not reply. | 19:56 |
| *** fenrig <fenrig!5bb53956@gateway/web/freenode/ip.91.181.57.86> has joined #yocto | 19:56 | |
| fenrig | Hi I can't seem to find how to add a conditional dependency (based on the machine) | 19:57 |
| wmat | lpapp: just keep trying, but also have patience | 19:57 |
| *** zeddii <zeddii!~bruce@65-114-90-17.dia.static.qwest.net> has quit IRC | 19:58 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 19:59 | |
| lpapp | wmat: to be honest, I do not care. | 20:00 |
| lpapp | if he wanted, he could have contributed to it. | 20:00 |
| fenrig | does anybody know how to add conditional dependencies based on the machine that is being built for? | 20:03 |
| fenrig | I want to add "gst-fsl-plugin" when I'm building for a freescale board (in this situation the I.Mx53 | 20:04 |
| bluelightning | fenrig: DEPENDS_append_machinename = " gst-fsl-plugin" | 20:05 |
| bluelightning | fenrig: note the leading space, that's important | 20:06 |
| fenrig | bluelightning: string concatenation? | 20:06 |
| kergoth | yep | 20:06 |
| lpapp | sgw1: I am here if you need any information from me. | 20:07 |
| fenrig | bluelightning: I also have a question about licenses when you built a recipe :) | 20:07 |
| lpapp | I am in a relaxing evening mood, but I will do my best. | 20:07 |
| fenrig | bluelightning: I understand you add the license file in the root of the layer (meta dir) | 20:08 |
| fenrig | bluelightning: Or is that a wrong assumption | 20:08 |
| kergoth | most recipes should be pointing to existing license file(s) or headers in the source of the thing, not things in the layer | 20:09 |
| bluelightning | fenrig: right, what kergoth said | 20:10 |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC | 20:11 | |
| *** fenrig <fenrig!5bb53956@gateway/web/freenode/ip.91.181.57.86> has quit IRC | 20:15 | |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto | 20:16 | |
| *** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC | 20:21 | |
| *** mr_science <mr_science!~sarnold@net-cf9a4e91.cst.impulse.net> has joined #yocto | 20:24 | |
| *** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 20:24 | |
| *** smartin_ <smartin_!~smartin@ivr94-4-82-229-165-48.fbx.proxad.net> has quit IRC | 20:27 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 20:29 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-isyxsflkanupbgxu> has quit IRC | 20:31 | |
| *** frank_fighting71 <frank_fighting71!~frank@118.186.200.116> has quit IRC | 20:34 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 20:34 | |
| *** frank_fighting71 <frank_fighting71!~frank@118.186.200.116> has joined #yocto | 20:34 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 20:34 | |
| *** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC | 20:34 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 20:35 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-mzbxovyidcikxrgi> has joined #yocto | 20:37 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 20:38 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 20:40 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 20:41 | |
| sgw1 | lpapp: so the external toolchain issue is solved now, it seems there might still be some kind of variable binding bug though | 20:42 |
| lpapp | sgw1: how did you solve it? | 20:43 |
| sgw1 | lpapp: I am asking you, you sent and email about MACHINE??= being set | 20:43 |
| lpapp | sgw1: that is another issue as written | 20:44 |
| sgw1 | lpapp: I guess I mis-understood your email, sorry. | 20:47 |
| lpapp | sgw1: see the email I replied to. | 20:49 |
| lpapp | sgw1: note how I have not replied to the issue we discussed in here. | 20:49 |
| lpapp | sgw1: you might wanna invite kergoth to the bugreport. | 20:51 |
| lpapp | sgw1: he seems to claim that meta-sourcery is the way. | 20:51 |
| lpapp | and the one in oe-core is unsupported. | 20:51 |
| lpapp | it is an uncool regression, but that is how they seem to have made it. :( | 20:52 |
| *** joeythesaint <joeythesaint!~jjm@128.224.252.2> has quit IRC | 20:54 | |
| kergoth | I feel like the new bitbake self restarting stuff doesn't cope well with SIGINT | 20:56 |
| *** galak <galak!~galak@99-51-185-173.lightspeed.austtx.sbcglobal.net> has quit IRC | 20:56 | |
| kergoth | periodically i have to ^Z kill %1; pkill -f bitbake | 20:56 |
| sgw1 | ls | 21:01 |
| *** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 21:05 | |
| *** eren <eren!~eren@unaffiliated/eren> has quit IRC | 21:18 | |
| *** jkridner|work <jkridner|work!~jkridner@nat/ti/x-legwuvlkjdmkydxm> has quit IRC | 21:26 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 21:27 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 21:31 | |
| *** sameo <sameo!~samuel@192.55.54.40> has joined #yocto | 21:33 | |
| * kergoth notices in a systemd environment, alsactl itself handles save/restore of state, but in sysvinit, alsa-state does, and sighs | 21:41 | |
| * kergoth grumbles | 21:41 | |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto | 21:42 | |
| kergoth | not sure what the cleanest way to resolve this is.. | 21:42 |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has quit IRC | 21:43 | |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has joined #yocto | 21:50 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 21:58 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 21:59 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 22:00 | |
| *** jkridner <jkridner!~jkridner@nat/ti/x-yekwtoisiudgrzki> has joined #yocto | 22:01 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 22:01 | |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has quit IRC | 22:01 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 22:04 | |
| *** jkridner <jkridner!~jkridner@nat/ti/x-cyryhpswzlhnfujy> has joined #yocto | 22:05 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 22:05 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 22:09 | |
| *** davest <davest!Adium@nat/intel/x-degonadqahyzvyum> has quit IRC | 22:12 | |
| *** ivali <ivali!ivali@unaffiliated/ivali> has joined #yocto | 22:14 | |
| *** tlwoerner <tlwoerner!~trevor@linaro/tlwoerner> has joined #yocto | 22:16 | |
| *** ivali <ivali!ivali@unaffiliated/ivali> has quit IRC | 22:18 | |
| *** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has quit IRC | 22:24 | |
| sgw1 | khem: you around to talk about the ppc floor() issue? | 22:30 |
| *** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto | 22:47 | |
| *** zerus <zerus!~epetmab@90-224-44-236-no67.tbcn.telia.com> has quit IRC | 22:47 | |
| *** sameo <sameo!~samuel@192.55.54.40> has quit IRC | 22:52 | |
| *** frank____ <frank____!~Android@118.186.200.116> has joined #yocto | 22:56 | |
| *** frank____ <frank____!~Android@118.186.200.116> has quit IRC | 22:57 | |
| *** zeddii <zeddii!~bruce@64.88.227.134> has joined #yocto | 23:02 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 23:03 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 23:08 | |
| *** fray <fray!U2FsdGVkX1@63.228.1.57> has quit IRC | 23:12 | |
| *** jkridner <jkridner!~jkridner@nat/ti/x-jypfijnrdliiofju> has joined #yocto | 23:17 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 23:17 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 23:23 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 23:25 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 23:26 | |
| *** agust <agust!~agust@pD9E2F2EB.dip0.t-ipconnect.de> has quit IRC | 23:31 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-mzbxovyidcikxrgi> has quit IRC | 23:33 | |
| *** vmeson <vmeson!~quassel@128.224.252.2> has quit IRC | 23:38 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 23:39 | |
| *** vmeson <vmeson!~quassel@128.224.252.2> has joined #yocto | 23:43 | |
| *** ant_home <ant_home!~andrea@host88-64-dynamic.8-87-r.retail.telecomitalia.it> has quit IRC | 23:46 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 23:56 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!