IRC log for #oe on 20120208

00:08.43*** join/#oe ibot (~ibot@rikers.org)
00:08.43*** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Repositories: http://git.openembedded.org/ | Primary Repo Mirrors: https://github.com/openembedded | This is not a distro or machine support channel
00:11.49*** join/#oe Russ (foobar@ip68-106-254-4.ph.ph.cox.net)
00:26.06*** join/#oe kurre2 (~tomimo@xdsl-83-150-88-111.nebulazone.fi)
00:35.34*** join/#oe msm (~msm@99-47-177-27.lightspeed.austtx.sbcglobal.net)
00:37.09*** join/#oe msm (~msm@99-47-177-27.lightspeed.austtx.sbcglobal.net)
00:44.25*** join/#oe tmbinc (abcd@83.141.3.59)
00:59.18*** join/#oe khem (~khem@99-57-140-209.lightspeed.sntcca.sbcglobal.net)
01:05.48*** join/#oe lamawithonel__ (~lucas@pool-96-231-116-115.washdc.east.verizon.net)
01:06.08*** join/#oe khem (~khem@99-57-140-209.lightspeed.sntcca.sbcglobal.net)
01:24.28*** join/#oe Openfree` (~Openfreer@116.228.88.131)
01:31.58*** join/#oe hollisb (~hollisb@c-67-169-221-181.hsd1.or.comcast.net)
01:37.12*** join/#oe dijenerate (~dijenerat@173.225.251.175)
01:55.03*** join/#oe risca (~risca@wi-secure-1813.cc.umanitoba.ca)
01:59.09*** join/#oe dijenerate (~dijenerat@173.225.251.175)
01:59.09*** join/#oe devzero_ (devzero@xdsl-89-0-139-129.netcologne.de)
01:59.09*** join/#oe ericben (~ebenard@pac33-2-82-240-38-71.fbx.proxad.net)
01:59.09*** join/#oe notespace (~notespace@dsl081-118-011.dfw1.dsl.speakeasy.net)
01:59.09*** join/#oe rje`cf (~rje@c-67-161-99-149.hsd1.wa.comcast.net)
01:59.09*** join/#oe mrmoku` (~mrmoku@host-188-174-159-7.customer.m-online.net)
01:59.10*** join/#oe tzanger (tzanger@wallace.mixdown.ca)
01:59.10*** join/#oe robtaylor (~robtaylor@floopily.codethink.co.uk)
01:59.10*** join/#oe uwe_ (~uwe_@dslb-088-066-186-052.pools.arcor-ip.net)
01:59.10*** join/#oe RushPL (~quassel@89-69-171-30.dynamic.chello.pl)
01:59.16*** join/#oe RushPL (~quassel@89-69-171-30.dynamic.chello.pl)
02:01.56*** join/#oe XorA (~XorA@208.51.138.10)
02:08.37*** join/#oe Openfree` (~Openfreer@116.228.88.131)
02:08.37*** join/#oe NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey)
02:08.37*** join/#oe muriani (~james@internal.directron.us)
02:08.37*** join/#oe eFfeM_work (~frans@D4B26BC1.static.ziggozakelijk.nl)
02:08.37*** join/#oe drw (~drw@cpe-24-242-194-227.tx.res.rr.com)
02:08.37*** join/#oe RP (~richard@93-97-173-237.zone5.bethere.co.uk)
02:08.37*** join/#oe aloril (~aloril@84.249.126.153)
02:08.37*** join/#oe blindvt (~brf@85-127-80-99.dynamic.xdsl-line.inode.at)
02:08.37*** join/#oe spacecolonyone (~anonymous@jeanluc.astro.lsa.umich.edu)
02:08.37*** join/#oe fray (U2FsdGVkX1@gate.crashing.org)
02:08.37*** join/#oe reaperofsouls (~jpuhlman@nat/montavista/x-kafvfzajjkwlzmdd)
02:08.38*** join/#oe toofar (~toobluesc@rrcs-24-153-174-218.sw.biz.rr.com)
02:12.45*** join/#oe tmbinc (abcd@83.141.3.59)
02:12.45*** join/#oe Russ (foobar@ip68-106-254-4.ph.ph.cox.net)
02:12.45*** join/#oe mtr (~michael@v29762.1blu.de)
02:12.45*** join/#oe ka6sox (ka6sox@nasadmin/ka6sox)
02:12.45*** join/#oe toobluesc (~nitro@cpe-76-183-52-98.tx.res.rr.com)
02:12.45*** join/#oe CIA-108 (~CIA@cia.atheme.org)
02:12.45*** join/#oe papercrane (~papercran@c-76-103-172-115.hsd1.ca.comcast.net)
02:12.45*** join/#oe pigeon (~pigeon@eth5284.nsw.adsl.internode.on.net)
02:17.01*** join/#oe msm (~msm@99-47-177-27.lightspeed.austtx.sbcglobal.net)
02:17.01*** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes)
02:17.01*** join/#oe sterNiX (~LessIsMor@unaffiliated/nu253r/x-0655220)
02:17.01*** join/#oe htns (~htns@175.139.208.57)
02:17.01*** join/#oe rsalveti (~rsalveti@linaro/rsalveti)
02:17.01*** join/#oe Crofton (~balister@pool-96-240-160-175.ronkva.east.verizon.net)
02:17.01*** join/#oe zenlinux (~sgarman@c-76-105-137-48.hsd1.or.comcast.net)
02:17.01*** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst)
02:17.01*** join/#oe cryptk (cryptk@nasadmin/cryptk)
02:17.01*** join/#oe CcSsNET (~user@c-98-216-138-179.hsd1.ma.comcast.net)
02:17.01*** join/#oe vexorg (~vexorg@h216-18-7-221.gtconnect.net)
02:17.01*** join/#oe RP__ (~richard@dan.rpsys.net)
02:17.01*** join/#oe CanyonMan (~quassel@cpe-69-207-190-61.rochester.res.rr.com)
02:17.01*** join/#oe pb_ (~pb@mail.pbcl.net)
02:20.26*** join/#oe pb_ (~pb@mail.pbcl.net)
02:20.26*** join/#oe CanyonMan (~quassel@cpe-69-207-190-61.rochester.res.rr.com)
02:20.26*** join/#oe RP__ (~richard@dan.rpsys.net)
02:20.26*** join/#oe vexorg (~vexorg@h216-18-7-221.gtconnect.net)
02:20.26*** join/#oe CcSsNET (~user@c-98-216-138-179.hsd1.ma.comcast.net)
02:20.26*** join/#oe cryptk (cryptk@nasadmin/cryptk)
02:20.26*** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst)
02:20.26*** join/#oe zenlinux (~sgarman@c-76-105-137-48.hsd1.or.comcast.net)
02:20.26*** join/#oe Crofton (~balister@pool-96-240-160-175.ronkva.east.verizon.net)
02:20.26*** join/#oe rsalveti (~rsalveti@linaro/rsalveti)
02:20.26*** join/#oe htns (~htns@175.139.208.57)
02:20.26*** join/#oe sterNiX (~LessIsMor@unaffiliated/nu253r/x-0655220)
02:20.26*** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes)
02:20.26*** join/#oe msm (~msm@99-47-177-27.lightspeed.austtx.sbcglobal.net)
02:20.26*** join/#oe pigeon (~pigeon@eth5284.nsw.adsl.internode.on.net)
02:20.26*** join/#oe papercrane (~papercran@c-76-103-172-115.hsd1.ca.comcast.net)
02:20.26*** join/#oe CIA-108 (~CIA@cia.atheme.org)
02:20.26*** join/#oe toobluesc (~nitro@cpe-76-183-52-98.tx.res.rr.com)
02:20.26*** join/#oe ka6sox (ka6sox@nasadmin/ka6sox)
02:20.26*** join/#oe mtr (~michael@v29762.1blu.de)
02:20.26*** join/#oe Russ (foobar@ip68-106-254-4.ph.ph.cox.net)
02:20.26*** join/#oe tmbinc (abcd@83.141.3.59)
02:20.26*** join/#oe toofar (~toobluesc@rrcs-24-153-174-218.sw.biz.rr.com)
02:20.27*** join/#oe reaperofsouls (~jpuhlman@nat/montavista/x-kafvfzajjkwlzmdd)
02:20.27*** join/#oe fray (U2FsdGVkX1@gate.crashing.org)
02:20.27*** join/#oe spacecolonyone (~anonymous@jeanluc.astro.lsa.umich.edu)
02:20.27*** join/#oe blindvt (~brf@85-127-80-99.dynamic.xdsl-line.inode.at)
02:20.27*** join/#oe aloril (~aloril@84.249.126.153)
02:20.27*** join/#oe RP (~richard@93-97-173-237.zone5.bethere.co.uk)
02:20.27*** join/#oe drw (~drw@cpe-24-242-194-227.tx.res.rr.com)
02:20.27*** join/#oe eFfeM_work (~frans@D4B26BC1.static.ziggozakelijk.nl)
02:20.27*** join/#oe muriani (~james@internal.directron.us)
02:20.27*** join/#oe NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey)
02:20.27*** join/#oe Openfree` (~Openfreer@116.228.88.131)
02:20.27*** join/#oe XorA (~XorA@208.51.138.10)
02:20.27*** join/#oe RushPL (~quassel@89-69-171-30.dynamic.chello.pl)
02:20.27*** join/#oe uwe_ (~uwe_@dslb-088-066-186-052.pools.arcor-ip.net)
02:20.27*** join/#oe robtaylor (~robtaylor@floopily.codethink.co.uk)
02:20.27*** join/#oe tzanger (tzanger@wallace.mixdown.ca)
02:20.27*** join/#oe mrmoku` (~mrmoku@host-188-174-159-7.customer.m-online.net)
02:20.27*** join/#oe rje`cf (~rje@c-67-161-99-149.hsd1.wa.comcast.net)
02:20.27*** join/#oe notespace (~notespace@dsl081-118-011.dfw1.dsl.speakeasy.net)
02:20.27*** join/#oe ericben (~ebenard@pac33-2-82-240-38-71.fbx.proxad.net)
02:20.27*** join/#oe devzero_ (devzero@xdsl-89-0-139-129.netcologne.de)
02:20.27*** join/#oe dijenerate (~dijenerat@173.225.251.175)
02:20.27*** join/#oe lamawithonel__ (~lucas@pool-96-231-116-115.washdc.east.verizon.net)
02:20.27*** join/#oe kurre2 (~tomimo@xdsl-83-150-88-111.nebulazone.fi)
02:20.27*** join/#oe e-ffi (~cybercom@HSI-KBW-046-005-058-024.hsi8.kabel-badenwuerttemberg.de)
02:20.27*** join/#oe jkridner (~jason@pdpc/supporter/active/jkridner)
02:20.27*** join/#oe darkschneider (~gab@93-32-39-141.ip31.fastwebnet.it)
02:20.28*** join/#oe rednul (~rednul@216.187.171.98)
02:20.28*** join/#oe rah (rah@myrtle.6gnip.net)
02:20.28*** join/#oe anarsoul (~anarsoul@212.98.184.86)
02:20.28*** join/#oe methril (~methril@188.141.121.132)
02:20.28*** join/#oe cminyard (~cminyard@pool-173-57-157-96.dllstx.fios.verizon.net)
02:20.28*** join/#oe playya_ (~playya@unaffiliated/playya)
02:20.28*** join/#oe ensc|w (~ensc@www.sigma-chemnitz.de)
02:20.28*** join/#oe plm (~plm@65.111.170.40)
02:20.28*** join/#oe HeinervdmOff (~zimmerman@cookie.physik.uni-bonn.de)
02:20.28*** join/#oe tom_say (~pain@cpe-68-203-248-184.stx.res.rr.com)
02:20.28*** join/#oe fullstop (~quassel@173.210.91.4)
02:20.28*** join/#oe SilicaGel (~quassel@leavenworth78.main.ad.rit.edu)
02:20.28*** join/#oe MMx (mmx@2001:6f8:12e0:0:5054:ff:fe12:3456)
02:20.28*** join/#oe dm8tbr (dm8tbr@cl-790.ham-01.de.sixxs.net)
02:20.28*** join/#oe slapin (~slapin@slapinbuild.ihdev.net)
02:20.28*** join/#oe pwgen (~ew@pp29-254.phys.au.dk)
02:20.28*** join/#oe valhalla (~valhalla@81-174-22-63.dynamic.ngi.it)
02:20.28*** join/#oe mwester__ (~mwester@nslu2-linux/mwester)
02:20.28*** join/#oe nullpuppy (~nullpuppy@freematrix/staff/nullpuppy)
02:20.28*** join/#oe penghb (~penghb@202.108.130.153)
02:20.28*** join/#oe jmpdelos (~polk@delos.delos.com)
02:20.28*** join/#oe liamMT (~Liam@173-164-164-245-SFBA.hfc.comcastbusiness.net)
02:20.28*** join/#oe ensc_ (~irc-ensc@p54ADFF7B.dip.t-dialin.net)
02:20.28*** join/#oe stuffcorpse (stuffy@amarok/developer/rickc)
02:20.28*** join/#oe hrw (~hrw@linaro/hrw)
02:20.28*** join/#oe ynezz (ynezz@ibawizard.net)
02:20.28*** join/#oe jevin (~jevin@napalm.jevinskie.com)
02:20.29*** join/#oe awozniak (~awozniak@74.82.132.35)
02:20.29*** join/#oe ALoGeNo (~alogeno@unaffiliated/alogeno)
02:20.29*** join/#oe soltys (soltys@czaj.net)
02:20.29*** join/#oe HokieTux (~HokieTux@157.22.28.13)
02:20.29*** join/#oe jonmasters (~jcm@edison.jonmasters.org)
02:20.29*** join/#oe Tartarus (trini@pixelshelf.com)
02:20.29*** join/#oe openfree (~dennis@116.228.88.131)
02:20.29*** join/#oe yann (~dwitch@nan92-1-81-57-214-146.fbx.proxad.net)
02:20.29*** join/#oe ivan`` (~ivan@unaffiliated/ivan/x-000001)
02:20.29*** join/#oe nslu2-log (~nslu2-log@140.211.169.184)
02:20.29*** join/#oe jconnolly (~jconnolly@66.43.64.66)
02:20.29*** join/#oe kergoth (~kergoth@covenant.kergoth.com)
02:20.29*** join/#oe Ironnads (~Ironnads@host86-164-43-17.range86-164.btcentralplus.com)
02:20.29*** join/#oe tdebrouw (~tdebrouw@91.182.32.103)
02:20.29*** join/#oe radhermit (~radhermit@gentoo/developer/radhermit)
02:20.29*** join/#oe thaytan (~thaytan@113.94.233.220.static.exetel.com.au)
02:20.29*** join/#oe sgw (~sgw@c-71-193-189-117.hsd1.wa.comcast.net)
02:20.29*** join/#oe sakoman (~sakoman@static-74-41-60-154.dsl1.pco.ca.frontiernet.net)
02:20.29*** join/#oe mertsas (~martin@nat/cisco/x-ffghhyebeoarmybo)
02:20.29*** join/#oe ChrisD1 (~ChrisD@2001:470:1f08:1e71::2)
02:20.29*** join/#oe mag (~mgreer@ip68-2-83-159.ph.ph.cox.net)
02:20.29*** join/#oe Romke|off (~Romke@cl-2087.ams-05.nl.sixxs.net)
02:20.29*** join/#oe cbrake (~cbrake@oh-69-34-21-229.sta.embarqhsd.net)
02:20.29*** join/#oe Dodji (~musashi@torimasen.com)
02:20.29*** join/#oe wmat (wmat@wallace.mixdown.ca)
02:20.29*** join/#oe otavio (~otavio@debian/developer/otavio)
02:20.29*** join/#oe otwieracz (~gonet9@v6.gen2.org)
02:20.30*** join/#oe broonie (broonie@cassiel.sirena.org.uk)
02:20.30*** join/#oe _chase_1 (~a0271661@nat/ti/x-uwninglxfmzgpevg)
02:20.30*** join/#oe Unhelpful (~quassel@rockbox/developer/Unhelpful)
02:20.30*** join/#oe denix (~denix@pool-71-178-225-66.washdc.fios.verizon.net)
02:20.30*** join/#oe xxiao (~xxiao@li41-126.members.linode.com)
02:20.30*** join/#oe henryk (henryk@shiny.ploetzli.ch)
02:20.44*** join/#oe markusg (83476@diamant.ifi.uio.no)
02:20.44*** join/#oe kenws (~ken@elliptique.net)
02:20.44*** join/#oe tomimo (~kurre@xdsl-83-150-88-111.nebulazone.fi)
02:20.44*** join/#oe mickeyl (~mickey@openmoko/coreteam/mickey)
02:20.44*** join/#oe ecloud (quassel@nat/trolltech/x-rkorucjepfgfyjfk)
02:20.44*** join/#oe captainigloo (~nico@lan31-4-82-227-130-131.fbx.proxad.net)
02:20.44*** join/#oe PaulePanter (~paul@mail.gw90.de)
02:20.44*** join/#oe scoutcamper (scoutcampe@nasadmin/webteam/scoutcamper)
02:20.44*** join/#oe pix1 (~pix@ks357967.kimsufi.com)
02:20.44*** join/#oe housel (~user@mccarthy.opendylan.org)
02:20.44*** join/#oe Marex (vasum7am@u-pl13.ms.mff.cuni.cz)
02:20.44*** join/#oe Gaston|Home (Gaston@ua-83-227-239-139.cust.bredbandsbolaget.se)
02:20.44*** join/#oe Jin|away (~jin@belief.htu.tuwien.ac.at)
02:20.44*** join/#oe signal11 (esteban@abq.quaddro.net)
02:20.44*** join/#oe Crofton|work (~balister@pool-96-240-160-175.ronkva.east.verizon.net)
02:20.44*** join/#oe rphillips (~rphillips@unaffiliated/rphillips)
02:20.44*** join/#oe uwe_mobile (~uwe@static.88-198-8-117.clients.your-server.de)
02:20.44*** join/#oe mario-goulart (~user@67.205.85.241)
02:20.44*** join/#oe ChanServ (ChanServ@services.)
02:20.44*** mode/#oe [+o ChanServ] by verne.freenode.net
03:05.08*** join/#oe devzero_ (devzero@xdsl-89-0-181-68.netcologne.de)
03:10.34*** join/#oe cs_nbp (~sackratte@ip-78-94-223-103.unitymediagroup.de)
03:30.57*** join/#oe NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey)
03:39.54*** join/#oe XorA (~XorA@208.51.138.10)
03:49.07*** join/#oe ensc (~irc-ensc@fedora/ensc)
03:54.03*** join/#oe lamawithonel (~lucas@pool-96-231-116-115.washdc.east.verizon.net)
03:57.27*** join/#oe RushPL_ (~quassel@89-69-171-30.dynamic.chello.pl)
04:00.28ka6soxI guess git.shr-project.org is offline
04:00.33ka6soxis that on purpose?
04:14.03kergothdamnit, i hate when i send something to the wrong list
04:18.46ka6soxkergoth, I thougth only I did that.
04:18.58kergoth:)
04:21.17ka6soxspeaking of which...i need to send one...
04:33.19*** join/#oe XorA (~XorA@208.51.138.10)
04:37.51*** join/#oe snkt (~snkt@122.170.104.85)
05:10.26*** join/#oe aloril (~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi)
05:15.26*** join/#oe rje`cf_ (~rje@c-67-161-99-149.hsd1.wa.comcast.net)
05:19.26*** join/#oe notespace (~notespace@barracuda.ventureresearch.com)
05:19.57*** join/#oe ensc|w (~ensc@www.sigma-chemnitz.de)
05:26.16*** join/#oe darkschneider (~gab@93-32-39-141.ip31.fastwebnet.it)
05:26.16*** join/#oe rah (rah@myrtle.6gnip.net)
05:26.16*** join/#oe MMx (mmx@2001:6f8:12e0:0:5054:ff:fe12:3456)
05:26.16*** join/#oe pwgen (~ew@pp29-254.phys.au.dk)
05:32.08*** join/#oe mrmoku (~mrmoku@host-188-174-159-7.customer.m-online.net)
05:35.09*** join/#oe darkschneider (~gab@93-32-39-141.ip31.fastwebnet.it)
05:35.09*** join/#oe rah (rah@myrtle.6gnip.net)
05:35.09*** join/#oe MMx (mmx@2001:6f8:12e0:0:5054:ff:fe12:3456)
05:35.09*** join/#oe pwgen (~ew@pp29-254.phys.au.dk)
05:36.58*** join/#oe dijenerate (~dijenerat@173.225.251.175)
05:37.34*** join/#oe uwe__ (~uwe_@dslb-088-066-186-052.pools.arcor-ip.net)
05:44.57*** join/#oe notespace1 (~notespace@barracuda.ventureresearch.com)
05:46.42*** join/#oe kergoth (~kergoth@covenant.kergoth.com)
05:46.50*** join/#oe jconnolly (~jconnolly@66.43.64.66)
05:49.23toobluescis there an easy way to remove alsa from COMBINED_FEATURES  ?
06:26.57*** join/#oe jekhor (~jek@leased-line-46-53-195-5.telecom.by)
06:29.26*** join/#oe tasslehoffwrk (~Tasslehof@84.49.231.147)
06:32.27*** join/#oe JaMa (~martin@94.230.152.246)
06:48.17*** join/#oe HeinervdmOff (~zimmerman@cookie.physik.uni-bonn.de)
07:03.10*** join/#oe Russ (foobar@ip68-106-254-4.ph.ph.cox.net)
07:04.31eFfeM_workgm
07:47.55*** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de)
07:50.39*** join/#oe amarsman (~marsman@90-145-17-249.wxdsl.nl)
07:54.27*** join/#oe Spider-Pork (~Spider-Po@host39-232-static.225-95-b.business.telecomitalia.it)
07:56.57*** join/#oe tscheck1 (~t@83.151.21.119)
08:07.30*** join/#oe rschus (~rschus@vsr56-1-89-84-156-196.dsl.sta.abo.bbox.fr)
08:17.53*** join/#oe uwe_mobile (~uwe@static.88-198-8-117.clients.your-server.de)
08:29.03*** join/#oe mwester_ (~mwester@nslu2-linux/mwester)
08:36.11*** join/#oe jkridner__ (~jason@pdpc/supporter/active/jkridner)
08:54.50*** join/#oe anarsoul (~anarsoul@212.98.189.142)
08:58.55*** join/#oe lamikr (lamikr@nat/nokia/x-osckezhhivqprqqj)
09:00.29*** join/#oe sgw (~sgw@c-71-193-189-117.hsd1.wa.comcast.net)
09:07.24mckoangood morning
09:09.39*** join/#oe rob_w (~bob@93.104.205.194)
09:09.40*** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029)
09:13.08*** join/#oe mickey_office (~mickey@e182221015.adsl.alicedsl.de)
09:19.10*** join/#oe Russ (foobar@ip68-106-254-4.ph.ph.cox.net)
09:19.13*** join/#oe bluelightning (~paul@83.217.123.106)
09:19.13*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
09:20.03*** join/#oe rschus (~rschus@vsr56-1-89-84-156-196.dsl.sta.abo.bbox.fr)
09:25.49*** join/#oe jekhor (~jek@178.121.32.235)
09:39.36*** join/#oe aloril (~aloril@84.249.126.153)
09:49.11*** join/#oe mertsas (~martin@nat/cisco/x-demittnmctocycjk)
09:51.07mertsashow do you set preffered provider of virtual/kernel? I tried sett PREFFERED_PROVIDER_virtual/kernel ?= "my-kernel" in the conf file for angstrom. Is this the correct approach, or should it be set in local.conf?
09:51.16*** join/#oe florian (~fuchs@Maemo/community/contributor/florian)
09:54.42bluelightningmorning all
09:54.47Jin^eLDmornin
09:54.56bluelightningmertsas: you probably want = rather than ?=
09:55.06bluelightningmertsas: ?= only sets if not already set
10:01.42floriangood morning
10:03.22pb_hi florian, bluelightning, all
10:03.34bluelightninghi pb_, florian
10:06.38*** join/#oe honk (5fdffabe@gateway/web/freenode/ip.95.223.250.190)
10:10.55*** join/#oe likewise (~likewise@116-66-ftth.onsneteindhoven.nl)
10:12.49*** join/#oe Cubi_ (~cubi@static-87-79-65-72.netcologne.de)
10:13.18*** join/#oe ao2 (~ao2@2001:1418:117::1)
10:15.17likewisegm
10:15.29Jin^eLDhey likewise
10:15.55bluelightninghi Jin^eLD, likewise
10:16.36likewiseI have a recipe that uses srctree.bbclass, which inherits clean, but fails with: ERROR: Could not inherit file classes/clean.bbclass
10:16.45likewisethis is with oe-core and meta-oe.
10:17.23JaMalikewise: even with clean.bbclass it will fail because it needs few tweeks to work with sstate
10:17.46*** join/#oe pespin (~pespin@90.163.78.104)
10:17.52likewiseJaMa: yes, it seems clean.bbclass is no longer with us. Maybe I should not use srctree?
10:18.01JaMalikewise: http://git.openembedded.org/meta-openembedded-contrib/commit/?h=jansa/test&id=5c3503d76cb6114b825bb34692ab29cfbcd4f310
10:18.17JaMayes it's not really usable now
10:19.14likewiseJaMa: thanks for looking at this.  What is the best way to work with source-in-meta recipes and sstate?
10:19.54likewiseJaMa: did you mean your commit already has the "tweaks" applied for sstate, or that it still needs tweaks?
10:20.24JaMano with this you will get srctree failing not because of missing clean.bbclass but like this http://paste.pocoo.org/show/547701/
10:20.52JaMaand I haven't found time to fix it to work correctly yet
10:20.57JaMafeel free to do it
10:22.46JaMaor ping kergoth if he hasn't updated version for oe-core
10:23.17pb_likewise: you don't necessarily need srctree, you might be able to just set ${S} appropriately.
10:23.55slapinby the by, how to get commit access to meta-openembedded-contrib? I have some gprs-gps-tracker recipes boiling
10:24.07pb_the only real technology in srctree is to cope with multiclassed recipes.  if yours isn't one of those then you don't need it.
10:26.42ka6soxdoes sources.openembedded.org have to be added manually or is it standard?
10:27.51likewisepb_: thanks. these are indeed simple test tools I would like to keep in-meta
10:28.24likewiseka6sox: I think khem submitted a patch to add both OE and Yocto mirrors, just the other day
10:28.40ka6soxgood
10:28.58ka6soxbecause klibc-1.5.25.tar.bz2 isn't found at the kernel.org mirror they are specifying
10:29.01likewiseka6sox: http://cgit.openembedded.org/openembedded-core/tree/meta/classes/mirrors.bbclass
10:29.04ka6soxI can get to from another mirror.
10:29.12ka6soxand put it in ours.
10:30.02likewiseka6sox: I wrote a tool to google for a package based on the MD5 sum, that I use when I package is not fetchable.
10:30.16likewiseka6sox: but having mirrors is best
10:30.47ka6soxthanks,
10:31.12ka6soxI should check the md5sum before i fetch it and put it in our mirror.
10:32.04likewisepb_: in your proposed approach, will the package built inside the source dir, or copy to the workdir firsT?
10:32.12likewisebuilt=>build
10:35.17pb_depends on the build system.  if it would normally compile inside ${S} then that's what will happen (though you can make a forest of hardlinks inside ${TMPDIR} and build there if you want.
10:41.59ka6soxokay, 3am here, either someone else can submit a patch or when I am more awake I can put it in our repo.
10:43.03ka6soxits here: http://ftp.osuosl.org/pub/linux/libs/klibc/1.5/
10:43.39ka6soxklibc-1.5.25.*
10:45.46*** join/#oe icanicant (~klawson@213.218.221.154)
10:47.43likewiseka6sox: who has access to the repo?
10:47.53likewiseka6sox: can khem add this?
10:48.18likewiseka6sox: anyway, good nite if you still are going to zzz
10:51.53*** join/#oe hexor (~thehexa@187.121.112.21)
10:53.28*** join/#oe dos1 (~dos@unaffiliated/dos1)
10:56.08mertsasbluelightning: thanks, but PREFFERED_PROVIDER_virtual/kernel is the correct variable as well?
10:56.18bluelightningmertsas: yes
10:58.59pb_well, not quite.  fewer Fs and more Rs.
10:59.34florian:-)
11:00.44*** join/#oe PaowZ (~vince@LAubervilliers-153-53-17-165.w217-128.abo.wanadoo.fr)
11:14.42*** join/#oe cs_nbp (~sackratte@ip-78-94-223-103.unitymediagroup.de)
11:14.55cs_nbpflorian: hi
11:15.03cs_nbpflorian: got emacs running^^
11:15.06bluelightningmertsas: ah yes, ensure you spell PREFERRED correctly
11:23.04likewisemaybe be should grep for PREFERE, PREFFE and fail :)
11:31.17mertsasbluelightning: yeah, that shit happens. I'll double check my spelling
11:34.19*** join/#oe HeinervdmOff (~zimmerman@cookie.physik.uni-bonn.de)
11:38.45*** join/#oe jekhor (~jek@mx2.promwad.com)
11:41.43bluelightninglikewise: I have wondered about trying to catch common typos in variable names... it could be valuable
11:51.33*** join/#oe Spider-Pork (~Spider-Po@host39-232-static.225-95-b.business.telecomitalia.it)
11:57.01*** join/#oe pepermint (~pepermint@host241-12-dynamic.58-82-r.retail.telecomitalia.it)
11:57.22*** join/#oe GNUtoo (~GNUtoo@host29-81-dynamic.48-82-r.retail.telecomitalia.it)
12:06.19*** join/#oe HeinervdmOff (~zimmerman@cookie.physik.uni-bonn.de)
12:18.49cs_nbpGNUtoo: hi, emacs compiling finally worked, there were a lot of 'tab's in some two Makefile.in that didn't belong there
12:19.16GNUtoook nice!!!!
12:21.21cs_nbpGNUtoo: now I need to figure out how to make a recipe/patch out of this o_O
12:21.50GNUtoook
12:21.58GNUtoocan you document what you did somewhere?
12:22.17cs_nbpwell I have the Makefile.in's that I changed
12:22.29cs_nbpbut the original ones have gone -.-
12:23.12GNUtoook
12:23.14GNUtoosave everything
12:23.28GNUtooand clean it
12:23.32GNUtooand do:
12:23.37GNUtoobitbake -c unpack emacs
12:23.41GNUtoogo into workdir
12:23.47GNUtooquilt new makefile.patch
12:23.58GNUtooquilt add /path/to/Makefile.in
12:24.08GNUtoovim /path/to/Makefile.in
12:24.17GNUtooor rather
12:24.27GNUtoocp the saved Makefile.in
12:24.33GNUtooquilt refresh
12:24.37GNUtooand you have a patch
12:24.48GNUtoocopy the patch back into the oe metadata
12:24.56GNUtooand add it in SRC_URI
12:26.00*** join/#oe CMoH (~cipi@95.76.68.223)
12:26.00*** join/#oe CMoH (~cipi@unaffiliated/c-moh)
12:26.22cs_nbpsorry, it seems my build host is offline and not reacting to wakeonlan.,.
12:26.43cs_nbpwill have to try that later in the day when I can turn it on manually
12:26.49cs_nbpbut thanks for the hint
12:26.51cs_nbp;)
12:33.56likewiseGNUtoo: we should have bitbake -c refreshpatches package to do the latter :)
12:34.52*** join/#oe JaMa (~martin@94.230.152.246)
12:36.28GNUtoolol good idea
12:36.45GNUtoocs_nbp, ok np, thanks a lot for working on emacs
12:37.26ynezzhm, porting operating system
12:37.36likewiseynezz: which? :)
12:37.41ynezzemacs
12:37.44ynezz:p
12:38.21*** join/#oe rob_w (~bob@93.104.205.194)
12:38.21*** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029)
12:38.55ynezzI've pressed enter too quickly, it should've been: "hm, porting operating system to another operating system?" :)
13:11.11likewiseynezz: ok, less interesting :)
13:16.41*** join/#oe troth (~troth@nat/hp/x-lemhjzjpktstwqpd)
13:18.23*** join/#oe vivijim (vivijim@unaffiliated/vivijim)
13:29.18*** join/#oe pepermin1 (~pepermint@host241-12-dynamic.58-82-r.retail.telecomitalia.it)
13:34.39*** join/#oe jekhor (~jek@mx2.promwad.com)
13:40.20*** join/#oe rschus (~rschus@vsr56-1-89-84-156-196.dsl.sta.abo.bbox.fr)
13:50.03*** join/#oe mhnoyes (~mhnoyes@184-12-250-129.dr01.myck.or.frontiernet.net)
13:50.04*** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes)
13:52.32*** join/#oe anarsoul_ (~anarsoul@86.57.155.118)
14:05.44cs_nbpk changin location bb
14:19.50*** join/#oe rschus (~rschus@89.1.20.66)
14:22.08*** join/#oe jekhor (~jek@mx2.promwad.com)
14:30.30*** join/#oe kevinsc (~a0214685@nat/ti/x-lgmftveespehwwqv)
14:36.23*** join/#oe pepermint (~pepermint@host241-12-dynamic.58-82-r.retail.telecomitalia.it)
14:53.40*** join/#oe penghb (~penghb@202.108.130.153)
15:03.27*** join/#oe cs_nbp (~sackratte@2001:638:504:c00e:1a03:73ff:fec1:395c)
15:05.33*** join/#oe devzero_ (devzero@xdsl-78-35-54-63.netcologne.de)
15:20.36*** join/#oe tdebrouw (~tdebrouw@91.182.71.254)
15:20.50*** join/#oe vivijim (~vivijim@unaffiliated/vivijim)
15:27.08*** join/#oe user1 (~3MX@41.207.20.247)
15:30.34*** join/#oe vivijim (vivijim@unaffiliated/vivijim)
15:33.34*** join/#oe XorA (~XorA@208.51.138.10)
15:43.05mckoanI need to create a recipe that download a binary file from ftp and place it into the final root image, does exist anything like this where to learn how do it?
15:43.30kergothftp:// is your friend
15:43.44kergothyou'd make it like any other recipe. add to SRC_URI, install in do_install, add the package to the image
15:45.26*** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029)
15:45.31*** join/#oe risca (~risca@wi-secure-1813.cc.umanitoba.ca)
15:46.08*** join/#oe Crofton (~balister@wsip-98-191-4-50.rn.hr.cox.net)
15:46.36mckoankergoth: that's what I did, I must have missed something
15:46.55*** part/#oe _chase_1 (~a0271661@nat/ti/x-uwninglxfmzgpevg)
15:50.11*** join/#oe GNUtoo (~gnutoo@host29-81-dynamic.48-82-r.retail.telecomitalia.it)
15:53.49pb_morning kergoth
15:55.15cs_nbpGNUtoo: it's a bit different from what I thought - the build process removed the makefiles -.-
15:55.44cs_nbpGNUtoo: also I can only bitbake -b */*/emacs_23.1.bb
15:55.55cs_nbpGNUtoo: because nothing 'provides' it
15:56.13cs_nbpGNUtoo: so no bitbake -c clean emacs
16:00.06*** join/#oe ibot (~ibot@rikers.org)
16:00.06*** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Repositories: http://git.openembedded.org/ | Primary Repo Mirrors: https://github.com/openembedded | This is not a distro or machine support channel
16:03.10*** part/#oe kevinsc (~a0214685@nat/ti/x-lgmftveespehwwqv)
16:04.19GNUtoocs_nbp, ok what Makefiles are there?
16:04.25GNUtoo.in is usually generated
16:04.31GNUtooat least with the current autotools
16:04.48GNUtoousually what is not generated is configure.ac and Makefile.am
16:05.03khemand configure.in :)
16:05.18khemin this context and makefile.in.in
16:05.23GNUtoook
16:05.30khemoh well time to drop kids to school
16:06.12GNUtoohttp://www.lrde.epita.fr/~adl/autotools.html has a good manual
16:06.15cs_nbpGNUtoo: none, the directory is empty after build
16:06.21GNUtoos/manual/tutorial/
16:06.23GNUtoook
16:06.27GNUtoomaybe you run rm_work
16:06.35GNUtoodid you save the directory somewhere
16:06.36GNUtoo?
16:06.42GNUtoocan you pastebin your work?
16:11.58cs_nbpsry stuff going on here(at work)
16:12.09cs_nbpyou mean bitbake -c rm_work?
16:12.30cs_nbpand then path to emacs_23.1.bb?
16:12.51cs_nbpnope I didn't save the directory
16:13.02cs_nbpdidn't think it would suddenly vanish
16:13.27slapinhi, all!
16:13.30cs_nbpcould pastebin the emacs.inc but only added LIC_FILES_CHKSUM in there
16:13.37cs_nbpwill have to redo everything
16:13.41cs_nbp.,.
16:13.44slapinis it possible to disable rm_work for some packages?
16:14.56pb_yes, you can put "do_rm_work() { : }" in the recipe
16:14.57cs_nbphow do I clean up after a bitbake -b package.bb?
16:14.58mckoankergoth: in do_install() I do install -d ${D}/home/root and install -m 0644 ${S}/binoetest ${D}/home/root/binoetest and I get * opkg_install_cmd: Cannot install package binoetest
16:15.06pb_or something along those lines
16:15.22mckoancs_nbp: bitbake -cclean package.bb
16:15.47mckoankergoth: device_table is different from the conffile in the new package
16:15.55cs_nbpmckoan: doesn't work, nothing 'PROVIDES' my package
16:16.07kergothunless you added /home to your package's FILES variables, that wont do squat
16:16.18kergothpackages shouldn't be touching home directories anyway
16:17.02mckoankergoth: yes was an example (probably the worst)
16:18.54mckoankergoth: trying install -m 0644 ${S}/binoetest ${D}${bindir}
16:19.42mckoankergoth: same error
16:20.30kergothyou need to take a step back. ignore the image. build the recipe, watch for warnings, and check deploy/ipk for the package. inspect its contents
16:20.49kergothand don't forgot to clean or bump pr as appropriate
16:25.38mckoankergoth: sucess! thank you so much
16:25.43kergothnp
16:25.49*** join/#oe msm (~msm@gate-tx3.freescale.com)
16:26.07*** join/#oe msm1 (~msm@192.88.168.34)
16:30.48cs_nbpwhat do I have to do so that something 'PROVIDES' my package? the manual is not clear enough there for me
16:31.28kergothnothing
16:31.35cs_nbpwell...
16:31.38kergothsee hte default value of PROVIDES in bitbake.conf
16:31.56kergothevery recipe provides ${PN}, ${PN}-${PV}, and ${PN}-${PV}-${PR}
16:32.50cs_nbpPROVIDES = ""
16:33.09cs_nbpfrom bitbake.conf
16:34.13cs_nbpbitbake checked out from git
16:34.26cs_nbpchanged nothing there
16:35.14cs_nbpso I should put ${PN}  ${PN}-${PV}  ${PN}-${PV}-${PR} between those quotation marks?
16:35.18bluelightningcs_nbp: that version of bitbake.conf is never used in practice, look at conf/bitbake.conf in oe-core
16:36.17kergothbluelightning: we should think about renaming the bitbake.conf in bitbake to bitbake.conf.sample or something
16:36.20kergothto make its purpose clear
16:36.29bluelightningkergoth: yes, that sounds like a good idea
16:36.53*** join/#oe rschus (~rschus@vsr56-1-89-84-156-196.dsl.sta.abo.bbox.fr)
16:37.22cs_nbpPROVIDES = ""
16:37.22cs_nbpPROVIDES_prepend = "${P} ${PF} ${PN} "
16:37.22cs_nbpRPROVIDES = ""
16:37.32cs_nbpthat's what's in it
16:37.37kergothyes, it is
16:37.46kergothas i just told you, every recipe provides ${PN}, ${PN}-${PV}, and ${PN}-${PV}-${PR}
16:37.55cs_nbpnevertheless it will complain about nothing providing my package
16:38.02kergoththen you're doing something else wrong
16:38.02bluelightningcs_nbp: what's the real question?
16:38.40cs_nbpbluelightning: I compiled a package with bitbake -b *.bb and am trying to clean up after it
16:39.01cs_nbpbluelightning: giving bitbake -c clean will complain about nothing providing my package
16:39.26cs_nbpbluelightning: so will bitbake packagename
16:39.27bluelightningcs_nbp: you should be able to do -c clean -b <filename>.bb
16:39.53bluelightningcs_nbp: presumably that's because the bb file you've created is not anywhere within BBFILES
16:39.54kergoththen your recipe probably isnt' in BBFILES, check your configuration
16:40.14*** join/#oe hbeck (~hbeck@69.41.94.157)
16:40.59*** join/#oe vivijim (~vivijim@unaffiliated/vivijim)
16:41.32*** join/#oe hollisb (~hollisb@c-67-169-221-181.hsd1.or.comcast.net)
16:41.44cs_nbpwell it's in oe-tworaz/meta-jlime/recipes-apps/emacs/* right next to other apps found by bitbake
16:42.31kergothwell, as i already explained, your recipe already PROVIDES things unless you overrode it. so either your recipe is breaking it, or your configuration is
16:42.38kergothyou could try pastebin'ing the recipe
16:43.17*** part/#oe rschus (~rschus@vsr56-1-89-84-156-196.dsl.sta.abo.bbox.fr)
16:43.30*** join/#oe blindvt_ (~brf@85-127-81-247.dynamic.xdsl-line.inode.at)
16:44.55mckoan~pastebin
16:44.55ibot[~pastebin] A "pastebin" is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://bin.cakephp.org/ , http://asterisk.pastey.net/ , or install pastebinit with yum or aptitude.
16:45.01*** join/#oe vivijim1 (vivijim@nat/intel/x-hlqjdpzegiqrfvkf)
16:46.58cs_nbpemacs.in: http://pastebin.com/Qg9WXbZP
16:47.11cs_nbpemacs_23.1.bb: http://pastebin.com/SARUUFCe
16:50.11mckoancs_nbp: are you using oe (oe-classic) or oe-core?
16:50.15*** join/#oe nitink1 (nitink@nat/intel/x-ugxyonpsauzkeond)
16:50.17cs_nbpoe-core
16:50.32cs_nbpporting a recipefrom oe-classic
16:50.50mckoancs_nbp: why don't you start testinf if everything works putting your 2 files in recipes/emacs/ ?
16:51.09mckoancs_nbp: then learn how to manage oe layers
16:51.22cs_nbpwhat is testinf?
16:51.30mckoancs_nbp: a typo :_D
16:51.34mckoan:-D
16:51.43mckoans/testinf/testing
16:52.14mckoana bit of dyslexia
16:52.37cs_nbpnot getting what you want me to do. I could build the package with bitbake -b *.bb, what is to test?
16:52.58cs_nbpnow trying to remove the remains of the build so I can do another one
16:55.27cs_nbpand that's failing because nothing 'provides' my package
16:55.42*** join/#oe jekhor (~jek@178.121.32.235)
16:57.42*** join/#oe risca (~risca@wi-secure-1813.cc.umanitoba.ca)
17:02.51mckoanhave a nice rest of the day
17:05.47*** join/#oe CMoH (~cipi@95.76.68.223)
17:05.48*** join/#oe CMoH (~cipi@unaffiliated/c-moh)
17:08.16cs_nbpkergoth: its not in the recipes, is it?
17:10.37cs_nbpand i have this layer.conf:BBFILES += "${LAYERDIR}/recipes-*/*/*.bb"
17:11.04cs_nbpand this oe-tworaz/meta-netbookpro in bblayers
17:11.24cs_nbpsrz oe/tworaz/meta-jlime
17:11.46cs_nbpand the recipe is in oe-tworaz/meta-jlime/emacs/emacs_23.1.bb
17:12.09cs_nbpso according to BBFILES it should be found
17:12.14cs_nbpbut its not
17:12.53cs_nbpsry path was incomplete  oe-tworaz/meta-jlime/recipes-apps/emacs/emacs_23.1.bb
17:13.28cs_nbpand bbfiles says "${LAYERDIR}/recipes-*/*/*.bb"
17:13.39cs_nbpthat's a match in my book
17:14.16cs_nbpall other recipes in meta-jlime/recipes-apps/ are found
17:18.24cs_nbpnvm I'll just delete my tmp/ completely again, this seems too weird
17:18.33bluelightningcs_nbp: don't do that
17:18.37cs_nbpk
17:19.05*** join/#oe jekhor (~jek@178.121.32.235)
17:19.11bluelightningcs_nbp: I can't understand what could be wrong
17:19.34*** join/#oe risca (~risca@wi-secure-1813.cc.umanitoba.ca)
17:19.47cs_nbpbluelightning: me neither. if emacs_23.1.bb exists I should be able to do bitbake emacs, right?
17:20.02bluelightningcs_nbp: the path looks correct, so yes
17:20.04cs_nbpat least when its like i said it is
17:20.47bluelightningcs_nbp: this shouldn't make a difference, but try "touch conf/local.conf" then bitbake emacs again
17:34.45*** join/#oe drw (~drw@24.242.194.227)
17:35.32*** join/#oe sterNiX (~LessIsMor@2.176.204.40)
17:35.32*** join/#oe sterNiX (~LessIsMor@unaffiliated/nu253r/x-0655220)
17:41.17cs_nbpsame result-.-
17:41.30bluelightningcs_nbp: ok, that rules out any cache weirdness at least
17:46.26bluelightningcs_nbp: if you touch oe-tworaz/meta-jlime/recipes-apps/emacs/emacs_23.1.bb then bitbake -p, does it indicate any files were parsed?
17:53.23bluelightningCrofton|work: I think I've fixed the qmake thing
17:53.27bluelightningCrofton|work: just running some tests
17:56.50hbeckwould there be collision/conflict issues when building for different machine confs if we used the same TMPDIR ?
17:57.33bluelightninghbeck: no, that should work fine
17:57.39cs_nbpbluelightning: it goes straight to do_compile now
17:58.00bluelightningcs_nbp: ???
17:59.42hbeckbluelightning: thanks.
18:00.36*** join/#oe B_Lizzard (~havoc@athedsl-117471.home.otenet.gr)
18:01.01hbeckanother question...is there a way to create a multi-system SDK for the same TARGET_ARCH (but different varieties of the hardware) using OE? Or would I have to do some kind of manual merge of the separately built SDKs?
18:01.59hbeckso like arm/armv4t-etc-etc-etc/ and arm/armv7-etc-etc-etc into the same SDK?
18:02.19*** join/#oe kristoffer (~kristoffe@c-e3d8e555.010-30-6c6b7012.cust.bredbandsbolaget.se)
18:02.23bluelightninghbeck: I'm not sure, I'd assume not but maybe someone else here has a better idea
18:04.44hbeckI would think so but it would require some mucking with TARGET_SYS, which I'm not sure I want to do...
18:04.50*** join/#oe florian (~fuchs@sign-4db6ad45.pool.mediaWays.net)
18:04.50*** join/#oe florian (~fuchs@Maemo/community/contributor/florian)
18:08.44cs_nbpbluelightning: the last bitbake -c clean -b recipe.bb seems to have worked but anyways yielded the "nothing PROVIDES" error like before
18:08.54cs_nbpso I didnt notice it actually cleaned
18:08.58cs_nbp-.-
18:09.50cs_nbpk think this is a good place for me to try to do some steps w/o daddy ;)
18:09.59kergothyou should just stop using -b as a matter of principle. you should never need to use it
18:10.27cs_nbpI did't want to, but nothing 'provides' my package so no other way to compile until I found out why
18:11.14kergoththen find out why and fix it, don't hide it :)
18:11.38cs_nbpif it's not too embarassing I won't hide it :D
18:11.45bluelightningyes, -b is evil
18:13.06kergothwe should thinka bout deprecating it, actually. the main reason it existed was due to parse times, iirc, and thats less of an issue nowadays unless your'e on a single core machine
18:13.33cs_nbpk gotta go home bb in 60 mins
18:13.55kergothheh
18:16.41hbeckkergoth: would there be any issue with doing TARGET_SYS = ${MULTIMACH_TARGET_SYS} in my meta-toolchain-distro.bb ?  related to what I asked above
18:20.01bluelightningkergoth: you'd get violent objection to removing -b in some quarters
18:20.13kergothheh, fair enough
18:20.24bluelightning(not from me, but I know others use it)
18:26.33hbeckhmmm...can anyone explain the MUTLIMACH_*** vs non MUTLIMACH vars and their usage?
18:27.27pb_I would miss -b if it went away, though I don't think I would object all that violently.
18:28.10*** join/#oe playya_ (~playya@unaffiliated/playya)
18:29.59pb_If you wanted to make it undocumented and have it only work if you had exported BiTB4k3_h4X0r_M0d3=1 in the environment or something then I would be fairly relaxed about that.
18:31.48pb_I suppose that should be "BiTB4k3_h4X0r_M0d3=1337" for consistency.
18:34.03hbeckto answer my own question above about issues assigning TARGET_SYS - yes there are! Apparently a change like that would have to be done at an earlier point (in a conf file)
18:35.55*** join/#oe eFfeM (~frans@a2038.upc-a.chello.nl)
18:43.15*** join/#oe troth (~troth@nat/hp/x-lemhjzjpktstwqpd)
18:43.15*** join/#oe mertsas (~martin@nat/cisco/x-demittnmctocycjk)
18:53.26*** join/#oe JaMa (~martin@94.230.152.246)
18:59.11*** join/#oe msm (~msm@192.88.168.34)
19:02.18*** join/#oe phdeswer (~phdeswer@HSI-KBW-46-223-253-0.hsi.kabel-badenwuerttemberg.de)
19:02.41*** join/#oe dijenerate (~dijenerat@173.225.251.175)
19:37.28*** join/#oe rcf (~rcf@198.108-243-81.adsl-dyn.isp.belgacom.be)
19:38.28*** join/#oe bluelightning (~paul@cpc2-lewi17-2-0-cust101.2-4.cable.virginmedia.com)
19:38.28*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
19:40.08*** join/#oe Heinervdm (~thomas@p5B0F3E94.dip.t-dialin.net)
19:40.17hbeckok so I've sort of worked out the multimachine concept after hunting in the commit logs. It seems like it mainly applies to the build area.  I'm still curious how one would build an SDK for a single TARGET_ARCH that would play nicely with the various machines. For example we're building for an armv4t (which uses software emulation for floating point stuff) and armv7a (which has hardware FP support)
19:43.32msmhow does one get gcc to link object files together?
19:43.46msmim getting errors about not finding main() - but we are building an .so
19:43.52msmi think thought CCLD would have these already
19:53.42pb_msm: what command are you using, exactly?
19:56.25msmpb_: i was missing a "-shared"
19:56.38msmi assumed CCLD might provide that
19:57.00msmor rather I'm just wingingit
19:57.14msmturns out we need to override LDSHARED for distutil builds because it uses a cache value which could be wrong
19:57.18msmto sort of summarize my issue
19:57.29msmi'll be sending a patch to the list shortly
20:04.49*** join/#oe Russ (foobar@ip68-106-254-4.ph.ph.cox.net)
20:10.19*** join/#oe tmbinc__ (abcd@83.141.3.59)
20:15.01khemhbeck: thats a lot of work to put together a multimachine SDK
20:15.30khemhbeck: OE is intentionally simple minded in this regard
20:16.36khemCCLD means use CC to do linking
20:21.07hbeckkhem: well, I have no issues just building two separate machine SDKs which both have a TARGET_ARCH="arm" and then combining them into a single directory structure if that's possible. What I'm trying to solve right now is to change the name given to the system specific files/libraries from something like ARCH-VENDOR-OS to MULTI_ARCH-VENDOR-OS
20:21.19hbeckand then keep the generic files as they are with ARCH-VENDOR-OS
20:22.26hbeckso I'd get something like arm/bin/<generic binaries>  and arm/armv4t-blah-blah-linux  plus  arm/armv7a-blah-blah-blah
20:22.36hbeckafter combining
20:32.29*** join/#oe devzero_ (devzero@xdsl-89-0-141-28.netcologne.de)
20:34.27*** join/#oe jsabeaudry (~jsabeaudr@242.161.18.64.static.oricom.ca)
20:34.45*** join/#oe vivijim (~vivijim@unaffiliated/vivijim)
20:36.11*** join/#oe jkridner___ (~jason@pdpc/supporter/active/jkridner)
20:36.15*** join/#oe rah (rah@myrtle.6gnip.net)
20:37.45msmkhem: that's what's goign on
20:37.59*** join/#oe risca (~risca@wi-secure-6257.cc.umanitoba.ca)
20:38.02msmkhem: or that's what distutil's is using to do linking
20:38.03msmAFAIK
20:42.57*** join/#oe Russ (foobar@ip68-106-254-4.ph.ph.cox.net)
20:47.00khemhbeck: what specific libs go into say arm-oe-linux-gnueabi convention
20:48.20khemcompilers should go into <usr/bin/MULTIMACH-VENDOR-OS> dir
20:48.31khembut they will still be called
20:48.42khemarm-oe-linux-uclibceabi-<TOOL>
20:49.23hbeckkhem: gcc, pthread, stdc++, util, thread. I was more looking at which things were an ARM file vs x86 file for the dev machine
20:50.33hbeckah, we didn't install to root...but we have a /opt/distro/arm/bin/ which has the binaries
20:51.09hbeckand then tehre's /opt/distro/arm/arm-vendor-linux-gnueabi/bin/ which has the short names for the binaries but are symlinked to the above dir
20:51.10*** join/#oe playya__ (~playya@unaffiliated/playya)
20:52.40hbeckwhat's the main thought in difference between BASE_PACKAGE_ARCH and TARGET_ARCH ?
20:53.36khembase package arch is lowest supported sub family
20:57.47hbeckwould it be completely against the "point" of the variables to force-set TARGET_SYS to use MULTI or BASE (which end up being the same in the cases I have looked at) ?
21:00.53*** join/#oe rlrosa (~rodrigo@r186-50-77-12.dialup.adsl.anteldata.net.uy)
21:03.03khemhbeck: a lot depend on these vars
21:03.20khemI cant even envision what all can break because of these vars
21:03.27hbeckheh
21:04.24khemmultimach was done to accomodate multiple builds of similar enough arches
21:04.33hbeckright
21:04.37khemin same tmpdir
21:05.01hbeckbut no real carry-over to building SDKs in the same fashion
21:05.11khemyeah
21:05.19hbeckI think what we're trying to avoid is having to provide different SDK downloads/installs to the users who get the SDK. We'd like to be able to give them a single SDK install that covers all the targets we support
21:05.35khemone day I will revisit SDK and straighten some niggles in there
21:06.29khemhbeck: it should live together for armv4 and armv7
21:06.43khemhbeck: but sysroot might be what conflicts hmm
21:06.58khemcan you post the install tree org chart
21:08.07hbeckhrm. Lost me a bit in what you're asking for
21:08.26khemissue a find command in your install tree of SDK
21:08.29hbeckhow we install the SDK?
21:08.32khemand paste that output
21:09.12khemyes I want to see where what goes in install
21:10.24hbeckheh. pastebin says it is too big
21:10.36hbecksomewhere else I can stick it?
21:11.48hbeckhttp://paste2.org/p/1898307
21:12.24hbeckkhem: there we go.  Note that right now we have a x86 SDK and only a single arm (v4) SDK in the install. We want to add the armv7
21:14.38rlrosahi
21:15.01rlrosais there any tutorial on how to modify a board.c file and get bitbake to use the new file?
21:18.03rlrosai don't understand how recipes work. i know that "bitbake console-image" will get me the files i need to run my beagleboard, but i don't know how to get from there to the source code
21:18.23hbeckrlrosa: you need to modify one of the source files in a recipe?
21:18.46hbeckor rather, from the source a recipe uses
21:22.49*** join/#oe Ironnads (~Ironnads@host86-144-173-232.range86-144.btcentralplus.com)
21:24.13rlrosahbeck, yes. i want to change the beagleboard board file, i want to modify i2c speed
21:24.47hbeckdo you know of which package that file is a part?
21:24.57rlrosahbeck, and i would like to learn a bit more about how to change stuff in oe, it's all kind of "magical" to me (magical == i have no idea what does what)
21:26.06hbeckrlrosa: well there's the (outdated) OE user manual pdf that's pretty easy to find. Some of it is still valid and might give you a general idea.
21:28.51hbeckrlrosa: and the short answer for your board.c question is that if it is a source-level change you will want to create a patch for board.c and add the patch file to the appropriate recipe...usually I do that in my distro overlay directory and just use a .bbappend to the recipe in the main tree area.
21:28.57rlrosai found the file in at setup-scripts/build/tmp/work/beagle.../linux-3.../git/arch/arm/mach-omap2/board-omap3beagle.c, but i put garbage into it and console-image compiled without complaining, so i'm pretty sure it's not using it
21:29.57rlrosahbeck, i'm not familiar with the concepts you're using, such as "main tree area" and bbappend, should the old pdf give me and idea of that stuff?
21:30.01hbeckyes
21:31.23hbeckas a warning though it is written for the oe-classic tree (which I am still using) and not the new oe-core. So I couldn't tell you if some of the concepts have been replaced or changed
21:33.34*** join/#oe msm1 (~msm@gate-tx3.freescale.com)
21:34.58*** join/#oe msm (~msm@gate-tx3.freescale.com)
21:35.28rlrosahbeck, i foind the manual. is it easy/possible to get the classic oe instead of the new one?
21:35.48khemrlrosa: why would you want classic oe
21:36.24*** join/#oe ALoGeNo (~alogeno@unaffiliated/alogeno)
21:36.42rlrosakhem, because the manual is about the classic one. i'd think it would be easier to understand following the manual, and then port whatever i learned to the new version
21:37.24rlrosakhem, do you *not* recommend this?
21:37.37khemrlrosa: actually I would not
21:40.36rlrosakhem, ok. i'll see if i can "port on the go"
21:42.41khemrlrosa: actually it will be better if you can document the problems and things that need update
21:45.10rlrosakhem, i found this pdf http://code.google.com/p/openembedded/downloads/detail?name=usermanual.pdf any clue where to find the .tex version of it? (assuming it exists)
21:46.56hbeckkhem: any insight from the install paste for SDK?
21:49.11khemrlrosa: you could clone git://git.yoctoproject.org/yocto-docs
21:49.12*** join/#oe ant____ (~andrea@host83-248-dynamic.16-79-r.retail.telecomitalia.it)
21:49.19khemthat should cover oe-core to some extent
21:49.56*** join/#oe XorA (~XorA@188-220-34-37.zone11.bethere.co.uk)
21:52.23khemold documentation is here http://git.openembedded.org/openembedded/tree/docs/usermanual
21:55.46khemhbeck: I see. there is no multimachine there
21:58.20hbecknot currently. and I don't think we have a way to do a multimachine install, because of the higher level TARGET_ARCH specification (arm) on most stuff instead of using the MULTI (armv4, v7)
21:58.40hbeckI've built in separate build dirs the sdk for both arm machines
21:59.08hbeckkhem: but they build a nearly identical tree for ./arm/ ...
22:00.12khemhbeck: yeah I think propagating multimachine to target triplet might be the solution
22:00.21khembut thats quite fundamental
22:00.43hbeckfundamental as in easy or as in a low level change that could screw up everything else? :)
22:03.37hbeckkhem: and would that be a distro override or something you're thinking could change in bitbake.conf (or maybe the sdk class?)
22:03.50khemno it has to be deeply rooted
22:04.03khembut for you I think you can define a variable
22:05.15khemhbeck: btw. is it using oe.classic
22:05.29hbeckkhem: yes
22:05.35khemoh boy
22:05.41khemnothing will get fixed there
22:06.34*** join/#oe woglinde (~woglinde@g225164080.adsl.alicedsl.de)
22:07.22hbeckkhem: didn't expect so, but the boss doesn't want to pay for the time to move all our stuff over to oe-core
22:08.02khemhbeck: hmm ok
22:08.09woglindehbeck poor boss
22:08.51khemwoglinde: wie gehts
22:08.56hbeckwoglinde: heh. To make it worse we started using oe and got everything working ... just barely a couple months before the switch to oe-core happened
22:09.19*** join/#oe xxiao (~xxiao@li41-126.members.linode.com)
22:09.24khemhbeck: migration should be easier but its some work
22:09.31khembut opens up your future
22:09.49hbeckkhem: so for a variable do you mean just a reassignment of TARGET_SYS triplet to the MULTI_TARGET_SYS in my distro conf file or something?
22:10.28khemhbeck: you can try
22:10.54hbeckkhem: yeah well a couple things holding us from migration - priorities, time investment required, and not entirely sure as to the "method to the madness" as it were (why was the switch done?)
22:12.37khemhbeck: oh well. Its done for a reason and stability and dead code were main reasons
22:13.27hbeckkhem is there a summarized list discussion or blog or something that covers the impetus for the move? such as those reasons you mention.
22:15.51*** join/#oe Russ (foobar@ip68-106-254-4.ph.ph.cox.net)
22:16.19khemhbeck: yes it was disussed on ml a lot
22:17.59hbeckkhem: right, but I assume that was multiple threads over a decently long period of time. was hoping for a summary of some kind :)
22:19.05khemhbeck: I pretty much gave you
22:19.10hbeckgot it
22:19.22khemhbeck: other reasons were we used push model which was not scaling
22:19.43khemas the meta-data grew so large it was broken every instant
22:20.26khemso we bit the bullet and I am happier than before
22:20.26hbeckwell a simple TARGET_SYS = ${MULTIMACH_TARGET_SYS} fails on build due to provider issues :(
22:20.39khemI am not surprised
22:20.50hbeckactually wait, those are just notes.
22:20.55hbeckERROR: Task /oe/openembedded/recipes/gcc/gcc-cross-intermediate_4.5.bb (do_setscene) has circular dependency on /oe/openembedded/recipes/eglibc/eglibc_2.12.bb (do_setscene)
22:20.59hbeck^ is the error
22:21.26khemyeah we have sanitized toolchains quite a bit in oe-core
22:21.32khemseparated the target bits out
22:21.38khemfor better dep tracking
22:21.45khemcreated intermediate sysroots
22:33.59*** join/#oe CMoH (~cipi@95.76.68.223)
22:34.00*** join/#oe CMoH (~cipi@unaffiliated/c-moh)
22:37.07*** join/#oe MikeTadyshak (~a0182185@nat/ti/x-dwkpdypbjjxlwfyf)
22:37.32ant____khem: in sight of meta-oe reorganization, what should happen to klibc?
22:41.01*** join/#oe risca (~risca@wi-secure-6257.cc.umanitoba.ca)
22:44.13woglindegood nite
22:44.33khemant____: that belongs to meta-initramfs may be
23:18.12*** join/#oe liamMT1 (~Liam@173-164-164-245-SFBA.hfc.comcastbusiness.net)
23:35.09*** join/#oe cs_nbp (~sackratte@ip-78-94-223-103.unitymediagroup.de)
23:35.39cs_nbpbluelightning: sorted it, filesystem was corrupted
23:36.18bluelightningcs_nbp: wow, ok... never would have guessed that :o
23:36.42bluelightningno wonder weird stuff was happening...
23:36.48cs_nbpy
23:36.58khemhmm did someone bribe it or what :)
23:37.04khemhow did it got corrupted
23:37.14cs_nbpthere was a power surge in my office
23:37.31cs_nbpwhen I went to restart the computer it took really long
23:37.43cs_nbpbut no error messages
23:37.50cs_nbpso I didn't bother at first
23:37.59cs_nbpthen weird things happening in oe
23:38.08cs_nbpand later in other applications too
23:38.29Russwhich fs?
23:38.37khemyeah I have seen OE is pretty upset when I run out of diskspace and then restart the build after freeing up some
23:38.48khemit does not like the intermediate files
23:38.56cs_nbpxfs
23:39.17khemxfs isnt that like storage server recommended one
23:39.32khemproabbly you are better off with ext4
23:39.46khemI hard reboot my box many times
23:39.57khemwhen ubuntu compiz bites me backsize
23:39.58bluelightningI have heard a lot about XFS being poor at handling unexpected events like surges
23:39.59khemside
23:40.01cs_nbpyes that machine needs a new setup anyway
23:40.17cs_nbpit was my first xfs failure ever
23:40.25bluelightningkhem: RP__ tells me that's gcc
23:40.31cs_nbpand I didnt like how sneaky it was
23:40.45bluelightningcs_nbp: never tried it myself, only going by what I read...
23:41.15cs_nbpwell probably there is some people who didnt notice their xfs is corrupted
23:41.16khembluelightning: you mean the one which bites the backside :)
23:42.05bluelightningkhem: well, I guess it just has no code to delete files that are partially written in the case of insufficient space
23:42.15RP__bluelightning: gcc?
23:42.30bluelightningRP__: isn't that what you were suggesting when we talked about this last time?
23:42.30RP__found xfs painful for OE use
23:42.34*** join/#oe msm (~msm@99-47-177-27.lightspeed.austtx.sbcglobal.net)
23:42.58*** join/#oe liamMT (~Liam@173-164-164-245-SFBA.hfc.comcastbusiness.net)
23:43.07RP__bluelightning: I'm not making sense of the conversation, sorry
23:43.20RP__bluelightning: the out of disk space being a gcc issue?
23:43.25bluelightningRP__: yes
23:43.40RP__bluelightning: its not gcc as such, just that you can end up with zero length files lying around
23:43.41bluelightningRP__: it's a side bit in a discussion about general file system corruption
23:43.43khemwhen disk is full and build halts free some space restart the build and it does not start from where it left like it usually will do
23:43.45RP__and gcc doesn't like that
23:43.58bluelightningright, that's what I was referring to
23:44.05khemyes 0 length files is the real problem
23:44.10RP__can also confuse make
23:44.45khemyeah but with sstate it does not matter that much
23:44.48bluelightningyes, I would imagine that could happen as well
23:45.01bluelightningkhem: well ideally you'd like it to be resumable
23:45.12khemRP__: btw. for fun since machine was bored I am doing a funny build where I am building each recipe from scratch
23:45.28khemwith sstate it helps
23:45.43khemand I hope to get some missing dependencies
23:45.47RP__khem: yes, I've meant to script that
23:46.19khemhttp://paste.ubuntu.com/834624/
23:47.14RP__khem: nice and simple :)
23:47.26RP__khem: It will be interesting to see how many issues we really have
23:47.45khemyes
23:48.23bluelightningeven more interesting if you enabled buildhistory while doing that
23:48.40bluelightningthat would pick up any unstated dependencies
23:48.43khembluelightning: yes i will do that once I get through one pass
23:48.45bluelightningor, at least some of them
23:48.53khemhmmm
23:49.03bluelightninggreat idea though
23:49.03khemthis time I will just rely on build failure
23:49.57khemso far 1 package is done
23:49.59khem:)
23:50.09khembut it worked
23:50.31cs_nbpwhich is it? hello_world? .p
23:50.39khemlibffi
23:51.38cs_nbp'portable foreign function library' omg
23:51.52khemif that can work
23:51.57khemmeans lot will work
23:52.46khemRP__: btw. I have a working toolchain with llvm + compiler-rt + libc++ + binutils
23:52.47khemfor arm
23:53.00khemit just needs the linker from binutils
23:53.21cs_nbpah yeh the gcc seems broken on my target
23:53.54khemRP__: for x86 it did not need binutils
23:53.59cs_nbp'cannot find crtbegin.o' when compiling a hello-world level code
23:54.07khemI am not sure if it sneaked the host one :)
23:54.29khemcs_nbp: that definitely means your runtime is borked
23:55.27khemif llvm was so mature we would build cross compiler only _once_ for all arches how cool is that
23:55.32RP__khem: cool :)
23:55.38khemand it does not need any deps on libc and crap
23:55.41cs_nbpvery kewl
23:56.26cs_nbpkhem: does that mean im missing a package or that the gcc recipe doesnt work well for that target?
23:56.28RP__khem: might help some of our build time issues? :)
23:56.47khemRP__: yes indeed
23:56.53khemwill simplify the things
23:57.07khemcs_nbp: do you have gcc-runtime installed on target ?
23:58.00cs_nbpkhem: seems only gcc-runtime-dbg is there -.-
23:58.14khemI think there is a lot of gcc'ism in the packages that it will take ages for it to really become prominent
23:58.29khemcs_nbp: not good.
23:59.23ka6soxoe infra full stop on wiki/git(master) in 2 minutes
23:59.26ka6soxwindow for 2hrs
23:59.53khemka6sox: thanks

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