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.28 | ka6sox | I guess git.shr-project.org is offline |
04:00.33 | ka6sox | is that on purpose? |
04:14.03 | kergoth | damnit, i hate when i send something to the wrong list |
04:18.46 | ka6sox | kergoth, I thougth only I did that. |
04:18.58 | kergoth | :) |
04:21.17 | ka6sox | speaking 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.23 | toobluesc | is 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.31 | eFfeM_work | gm |
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.24 | mckoan | good 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.07 | mertsas | how 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.42 | bluelightning | morning all |
09:54.47 | Jin^eLD | mornin |
09:54.56 | bluelightning | mertsas: you probably want = rather than ?= |
09:55.06 | bluelightning | mertsas: ?= only sets if not already set |
10:01.42 | florian | good morning |
10:03.22 | pb_ | hi florian, bluelightning, all |
10:03.34 | bluelightning | hi 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.17 | likewise | gm |
10:15.29 | Jin^eLD | hey likewise |
10:15.55 | bluelightning | hi Jin^eLD, likewise |
10:16.36 | likewise | I have a recipe that uses srctree.bbclass, which inherits clean, but fails with: ERROR: Could not inherit file classes/clean.bbclass |
10:16.45 | likewise | this is with oe-core and meta-oe. |
10:17.23 | JaMa | likewise: 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.52 | likewise | JaMa: yes, it seems clean.bbclass is no longer with us. Maybe I should not use srctree? |
10:18.01 | JaMa | likewise: http://git.openembedded.org/meta-openembedded-contrib/commit/?h=jansa/test&id=5c3503d76cb6114b825bb34692ab29cfbcd4f310 |
10:18.17 | JaMa | yes it's not really usable now |
10:19.14 | likewise | JaMa: thanks for looking at this. What is the best way to work with source-in-meta recipes and sstate? |
10:19.54 | likewise | JaMa: did you mean your commit already has the "tweaks" applied for sstate, or that it still needs tweaks? |
10:20.24 | JaMa | no with this you will get srctree failing not because of missing clean.bbclass but like this http://paste.pocoo.org/show/547701/ |
10:20.52 | JaMa | and I haven't found time to fix it to work correctly yet |
10:20.57 | JaMa | feel free to do it |
10:22.46 | JaMa | or ping kergoth if he hasn't updated version for oe-core |
10:23.17 | pb_ | likewise: you don't necessarily need srctree, you might be able to just set ${S} appropriately. |
10:23.55 | slapin | by the by, how to get commit access to meta-openembedded-contrib? I have some gprs-gps-tracker recipes boiling |
10:24.07 | pb_ | 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.42 | ka6sox | does sources.openembedded.org have to be added manually or is it standard? |
10:27.51 | likewise | pb_: thanks. these are indeed simple test tools I would like to keep in-meta |
10:28.24 | likewise | ka6sox: I think khem submitted a patch to add both OE and Yocto mirrors, just the other day |
10:28.40 | ka6sox | good |
10:28.58 | ka6sox | because klibc-1.5.25.tar.bz2 isn't found at the kernel.org mirror they are specifying |
10:29.01 | likewise | ka6sox: http://cgit.openembedded.org/openembedded-core/tree/meta/classes/mirrors.bbclass |
10:29.04 | ka6sox | I can get to from another mirror. |
10:29.12 | ka6sox | and put it in ours. |
10:30.02 | likewise | ka6sox: 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.16 | likewise | ka6sox: but having mirrors is best |
10:30.47 | ka6sox | thanks, |
10:31.12 | ka6sox | I should check the md5sum before i fetch it and put it in our mirror. |
10:32.04 | likewise | pb_: in your proposed approach, will the package built inside the source dir, or copy to the workdir firsT? |
10:32.12 | likewise | built=>build |
10:35.17 | pb_ | 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.59 | ka6sox | okay, 3am here, either someone else can submit a patch or when I am more awake I can put it in our repo. |
10:43.03 | ka6sox | its here: http://ftp.osuosl.org/pub/linux/libs/klibc/1.5/ |
10:43.39 | ka6sox | klibc-1.5.25.* |
10:45.46 | *** join/#oe icanicant (~klawson@213.218.221.154) |
10:47.43 | likewise | ka6sox: who has access to the repo? |
10:47.53 | likewise | ka6sox: can khem add this? |
10:48.18 | likewise | ka6sox: 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.08 | mertsas | bluelightning: thanks, but PREFFERED_PROVIDER_virtual/kernel is the correct variable as well? |
10:56.18 | bluelightning | mertsas: yes |
10:58.59 | pb_ | well, not quite. fewer Fs and more Rs. |
10:59.34 | florian | :-) |
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.55 | cs_nbp | florian: hi |
11:15.03 | cs_nbp | florian: got emacs running^^ |
11:15.06 | bluelightning | mertsas: ah yes, ensure you spell PREFERRED correctly |
11:23.04 | likewise | maybe be should grep for PREFERE, PREFFE and fail :) |
11:31.17 | mertsas | bluelightning: 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.43 | bluelightning | likewise: 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.49 | cs_nbp | GNUtoo: hi, emacs compiling finally worked, there were a lot of 'tab's in some two Makefile.in that didn't belong there |
12:19.16 | GNUtoo | ok nice!!!! |
12:21.21 | cs_nbp | GNUtoo: now I need to figure out how to make a recipe/patch out of this o_O |
12:21.50 | GNUtoo | ok |
12:21.58 | GNUtoo | can you document what you did somewhere? |
12:22.17 | cs_nbp | well I have the Makefile.in's that I changed |
12:22.29 | cs_nbp | but the original ones have gone -.- |
12:23.12 | GNUtoo | ok |
12:23.14 | GNUtoo | save everything |
12:23.28 | GNUtoo | and clean it |
12:23.32 | GNUtoo | and do: |
12:23.37 | GNUtoo | bitbake -c unpack emacs |
12:23.41 | GNUtoo | go into workdir |
12:23.47 | GNUtoo | quilt new makefile.patch |
12:23.58 | GNUtoo | quilt add /path/to/Makefile.in |
12:24.08 | GNUtoo | vim /path/to/Makefile.in |
12:24.17 | GNUtoo | or rather |
12:24.27 | GNUtoo | cp the saved Makefile.in |
12:24.33 | GNUtoo | quilt refresh |
12:24.37 | GNUtoo | and you have a patch |
12:24.48 | GNUtoo | copy the patch back into the oe metadata |
12:24.56 | GNUtoo | and 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.22 | cs_nbp | sorry, it seems my build host is offline and not reacting to wakeonlan.,. |
12:26.43 | cs_nbp | will have to try that later in the day when I can turn it on manually |
12:26.49 | cs_nbp | but thanks for the hint |
12:26.51 | cs_nbp | ;) |
12:33.56 | likewise | GNUtoo: we should have bitbake -c refreshpatches package to do the latter :) |
12:34.52 | *** join/#oe JaMa (~martin@94.230.152.246) |
12:36.28 | GNUtoo | lol good idea |
12:36.45 | GNUtoo | cs_nbp, ok np, thanks a lot for working on emacs |
12:37.26 | ynezz | hm, porting operating system |
12:37.36 | likewise | ynezz: which? :) |
12:37.41 | ynezz | emacs |
12:37.44 | ynezz | :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.55 | ynezz | I've pressed enter too quickly, it should've been: "hm, porting operating system to another operating system?" :) |
13:11.11 | likewise | ynezz: 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.44 | cs_nbp | k 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.05 | mckoan | I 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.30 | kergoth | ftp:// is your friend |
15:43.44 | kergoth | you'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.36 | mckoan | kergoth: 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.49 | pb_ | morning kergoth |
15:55.15 | cs_nbp | GNUtoo: it's a bit different from what I thought - the build process removed the makefiles -.- |
15:55.44 | cs_nbp | GNUtoo: also I can only bitbake -b */*/emacs_23.1.bb |
15:55.55 | cs_nbp | GNUtoo: because nothing 'provides' it |
15:56.13 | cs_nbp | GNUtoo: 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.19 | GNUtoo | cs_nbp, ok what Makefiles are there? |
16:04.25 | GNUtoo | .in is usually generated |
16:04.31 | GNUtoo | at least with the current autotools |
16:04.48 | GNUtoo | usually what is not generated is configure.ac and Makefile.am |
16:05.03 | khem | and configure.in :) |
16:05.18 | khem | in this context and makefile.in.in |
16:05.23 | GNUtoo | ok |
16:05.30 | khem | oh well time to drop kids to school |
16:06.12 | GNUtoo | http://www.lrde.epita.fr/~adl/autotools.html has a good manual |
16:06.15 | cs_nbp | GNUtoo: none, the directory is empty after build |
16:06.21 | GNUtoo | s/manual/tutorial/ |
16:06.23 | GNUtoo | ok |
16:06.27 | GNUtoo | maybe you run rm_work |
16:06.35 | GNUtoo | did you save the directory somewhere |
16:06.36 | GNUtoo | ? |
16:06.42 | GNUtoo | can you pastebin your work? |
16:11.58 | cs_nbp | sry stuff going on here(at work) |
16:12.09 | cs_nbp | you mean bitbake -c rm_work? |
16:12.30 | cs_nbp | and then path to emacs_23.1.bb? |
16:12.51 | cs_nbp | nope I didn't save the directory |
16:13.02 | cs_nbp | didn't think it would suddenly vanish |
16:13.27 | slapin | hi, all! |
16:13.30 | cs_nbp | could pastebin the emacs.inc but only added LIC_FILES_CHKSUM in there |
16:13.37 | cs_nbp | will have to redo everything |
16:13.41 | cs_nbp | .,. |
16:13.44 | slapin | is it possible to disable rm_work for some packages? |
16:14.56 | pb_ | yes, you can put "do_rm_work() { : }" in the recipe |
16:14.57 | cs_nbp | how do I clean up after a bitbake -b package.bb? |
16:14.58 | mckoan | kergoth: 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.06 | pb_ | or something along those lines |
16:15.22 | mckoan | cs_nbp: bitbake -cclean package.bb |
16:15.47 | mckoan | kergoth: device_table is different from the conffile in the new package |
16:15.55 | cs_nbp | mckoan: doesn't work, nothing 'PROVIDES' my package |
16:16.07 | kergoth | unless you added /home to your package's FILES variables, that wont do squat |
16:16.18 | kergoth | packages shouldn't be touching home directories anyway |
16:17.02 | mckoan | kergoth: yes was an example (probably the worst) |
16:18.54 | mckoan | kergoth: trying install -m 0644 ${S}/binoetest ${D}${bindir} |
16:19.42 | mckoan | kergoth: same error |
16:20.30 | kergoth | you 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.49 | kergoth | and don't forgot to clean or bump pr as appropriate |
16:25.38 | mckoan | kergoth: sucess! thank you so much |
16:25.43 | kergoth | np |
16:25.49 | *** join/#oe msm (~msm@gate-tx3.freescale.com) |
16:26.07 | *** join/#oe msm1 (~msm@192.88.168.34) |
16:30.48 | cs_nbp | what do I have to do so that something 'PROVIDES' my package? the manual is not clear enough there for me |
16:31.28 | kergoth | nothing |
16:31.35 | cs_nbp | well... |
16:31.38 | kergoth | see hte default value of PROVIDES in bitbake.conf |
16:31.56 | kergoth | every recipe provides ${PN}, ${PN}-${PV}, and ${PN}-${PV}-${PR} |
16:32.50 | cs_nbp | PROVIDES = "" |
16:33.09 | cs_nbp | from bitbake.conf |
16:34.13 | cs_nbp | bitbake checked out from git |
16:34.26 | cs_nbp | changed nothing there |
16:35.14 | cs_nbp | so I should put ${PN} ${PN}-${PV} ${PN}-${PV}-${PR} between those quotation marks? |
16:35.18 | bluelightning | cs_nbp: that version of bitbake.conf is never used in practice, look at conf/bitbake.conf in oe-core |
16:36.17 | kergoth | bluelightning: we should think about renaming the bitbake.conf in bitbake to bitbake.conf.sample or something |
16:36.20 | kergoth | to make its purpose clear |
16:36.29 | bluelightning | kergoth: 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.22 | cs_nbp | PROVIDES = "" |
16:37.22 | cs_nbp | PROVIDES_prepend = "${P} ${PF} ${PN} " |
16:37.22 | cs_nbp | RPROVIDES = "" |
16:37.32 | cs_nbp | that's what's in it |
16:37.37 | kergoth | yes, it is |
16:37.46 | kergoth | as i just told you, every recipe provides ${PN}, ${PN}-${PV}, and ${PN}-${PV}-${PR} |
16:37.55 | cs_nbp | nevertheless it will complain about nothing providing my package |
16:38.02 | kergoth | then you're doing something else wrong |
16:38.02 | bluelightning | cs_nbp: what's the real question? |
16:38.40 | cs_nbp | bluelightning: I compiled a package with bitbake -b *.bb and am trying to clean up after it |
16:39.01 | cs_nbp | bluelightning: giving bitbake -c clean will complain about nothing providing my package |
16:39.26 | cs_nbp | bluelightning: so will bitbake packagename |
16:39.27 | bluelightning | cs_nbp: you should be able to do -c clean -b <filename>.bb |
16:39.53 | bluelightning | cs_nbp: presumably that's because the bb file you've created is not anywhere within BBFILES |
16:39.54 | kergoth | then 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.44 | cs_nbp | well it's in oe-tworaz/meta-jlime/recipes-apps/emacs/* right next to other apps found by bitbake |
16:42.31 | kergoth | well, 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.38 | kergoth | you 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.55 | mckoan | ~pastebin |
16:44.55 | ibot | [~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.58 | cs_nbp | emacs.in: http://pastebin.com/Qg9WXbZP |
16:47.11 | cs_nbp | emacs_23.1.bb: http://pastebin.com/SARUUFCe |
16:50.11 | mckoan | cs_nbp: are you using oe (oe-classic) or oe-core? |
16:50.15 | *** join/#oe nitink1 (nitink@nat/intel/x-ugxyonpsauzkeond) |
16:50.17 | cs_nbp | oe-core |
16:50.32 | cs_nbp | porting a recipefrom oe-classic |
16:50.50 | mckoan | cs_nbp: why don't you start testinf if everything works putting your 2 files in recipes/emacs/ ? |
16:51.09 | mckoan | cs_nbp: then learn how to manage oe layers |
16:51.22 | cs_nbp | what is testinf? |
16:51.30 | mckoan | cs_nbp: a typo :_D |
16:51.34 | mckoan | :-D |
16:51.43 | mckoan | s/testinf/testing |
16:52.14 | mckoan | a bit of dyslexia |
16:52.37 | cs_nbp | not getting what you want me to do. I could build the package with bitbake -b *.bb, what is to test? |
16:52.58 | cs_nbp | now trying to remove the remains of the build so I can do another one |
16:55.27 | cs_nbp | and 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.51 | mckoan | have 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.16 | cs_nbp | kergoth: its not in the recipes, is it? |
17:10.37 | cs_nbp | and i have this layer.conf:BBFILES += "${LAYERDIR}/recipes-*/*/*.bb" |
17:11.04 | cs_nbp | and this oe-tworaz/meta-netbookpro in bblayers |
17:11.24 | cs_nbp | srz oe/tworaz/meta-jlime |
17:11.46 | cs_nbp | and the recipe is in oe-tworaz/meta-jlime/emacs/emacs_23.1.bb |
17:12.09 | cs_nbp | so according to BBFILES it should be found |
17:12.14 | cs_nbp | but its not |
17:12.53 | cs_nbp | sry path was incomplete oe-tworaz/meta-jlime/recipes-apps/emacs/emacs_23.1.bb |
17:13.28 | cs_nbp | and bbfiles says "${LAYERDIR}/recipes-*/*/*.bb" |
17:13.39 | cs_nbp | that's a match in my book |
17:14.16 | cs_nbp | all other recipes in meta-jlime/recipes-apps/ are found |
17:18.24 | cs_nbp | nvm I'll just delete my tmp/ completely again, this seems too weird |
17:18.33 | bluelightning | cs_nbp: don't do that |
17:18.37 | cs_nbp | k |
17:19.05 | *** join/#oe jekhor (~jek@178.121.32.235) |
17:19.11 | bluelightning | cs_nbp: I can't understand what could be wrong |
17:19.34 | *** join/#oe risca (~risca@wi-secure-1813.cc.umanitoba.ca) |
17:19.47 | cs_nbp | bluelightning: me neither. if emacs_23.1.bb exists I should be able to do bitbake emacs, right? |
17:20.02 | bluelightning | cs_nbp: the path looks correct, so yes |
17:20.04 | cs_nbp | at least when its like i said it is |
17:20.47 | bluelightning | cs_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.17 | cs_nbp | same result-.- |
17:41.30 | bluelightning | cs_nbp: ok, that rules out any cache weirdness at least |
17:46.26 | bluelightning | cs_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.23 | bluelightning | Crofton|work: I think I've fixed the qmake thing |
17:53.27 | bluelightning | Crofton|work: just running some tests |
17:56.50 | hbeck | would there be collision/conflict issues when building for different machine confs if we used the same TMPDIR ? |
17:57.33 | bluelightning | hbeck: no, that should work fine |
17:57.39 | cs_nbp | bluelightning: it goes straight to do_compile now |
17:58.00 | bluelightning | cs_nbp: ??? |
17:59.42 | hbeck | bluelightning: thanks. |
18:00.36 | *** join/#oe B_Lizzard (~havoc@athedsl-117471.home.otenet.gr) |
18:01.01 | hbeck | another 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.59 | hbeck | so 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.23 | bluelightning | hbeck: I'm not sure, I'd assume not but maybe someone else here has a better idea |
18:04.44 | hbeck | I 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.44 | cs_nbp | bluelightning: the last bitbake -c clean -b recipe.bb seems to have worked but anyways yielded the "nothing PROVIDES" error like before |
18:08.54 | cs_nbp | so I didnt notice it actually cleaned |
18:08.58 | cs_nbp | -.- |
18:09.50 | cs_nbp | k think this is a good place for me to try to do some steps w/o daddy ;) |
18:09.59 | kergoth | you should just stop using -b as a matter of principle. you should never need to use it |
18:10.27 | cs_nbp | I did't want to, but nothing 'provides' my package so no other way to compile until I found out why |
18:11.14 | kergoth | then find out why and fix it, don't hide it :) |
18:11.38 | cs_nbp | if it's not too embarassing I won't hide it :D |
18:11.45 | bluelightning | yes, -b is evil |
18:13.06 | kergoth | we 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.33 | cs_nbp | k gotta go home bb in 60 mins |
18:13.55 | kergoth | heh |
18:16.41 | hbeck | kergoth: 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.01 | bluelightning | kergoth: you'd get violent objection to removing -b in some quarters |
18:20.13 | kergoth | heh, fair enough |
18:20.24 | bluelightning | (not from me, but I know others use it) |
18:26.33 | hbeck | hmmm...can anyone explain the MUTLIMACH_*** vs non MUTLIMACH vars and their usage? |
18:27.27 | pb_ | 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.59 | pb_ | 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.48 | pb_ | I suppose that should be "BiTB4k3_h4X0r_M0d3=1337" for consistency. |
18:34.03 | hbeck | to 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.17 | hbeck | ok 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.32 | msm | how does one get gcc to link object files together? |
19:43.46 | msm | im getting errors about not finding main() - but we are building an .so |
19:43.52 | msm | i think thought CCLD would have these already |
19:53.42 | pb_ | msm: what command are you using, exactly? |
19:56.25 | msm | pb_: i was missing a "-shared" |
19:56.38 | msm | i assumed CCLD might provide that |
19:57.00 | msm | or rather I'm just wingingit |
19:57.14 | msm | turns out we need to override LDSHARED for distutil builds because it uses a cache value which could be wrong |
19:57.18 | msm | to sort of summarize my issue |
19:57.29 | msm | i'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.01 | khem | hbeck: thats a lot of work to put together a multimachine SDK |
20:15.30 | khem | hbeck: OE is intentionally simple minded in this regard |
20:16.36 | khem | CCLD means use CC to do linking |
20:21.07 | hbeck | khem: 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.19 | hbeck | and then keep the generic files as they are with ARCH-VENDOR-OS |
20:22.26 | hbeck | so I'd get something like arm/bin/<generic binaries> and arm/armv4t-blah-blah-linux plus arm/armv7a-blah-blah-blah |
20:22.36 | hbeck | after 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.45 | msm | khem: that's what's goign on |
20:37.59 | *** join/#oe risca (~risca@wi-secure-6257.cc.umanitoba.ca) |
20:38.02 | msm | khem: or that's what distutil's is using to do linking |
20:38.03 | msm | AFAIK |
20:42.57 | *** join/#oe Russ (foobar@ip68-106-254-4.ph.ph.cox.net) |
20:47.00 | khem | hbeck: what specific libs go into say arm-oe-linux-gnueabi convention |
20:48.20 | khem | compilers should go into <usr/bin/MULTIMACH-VENDOR-OS> dir |
20:48.31 | khem | but they will still be called |
20:48.42 | khem | arm-oe-linux-uclibceabi-<TOOL> |
20:49.23 | hbeck | khem: 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.33 | hbeck | ah, we didn't install to root...but we have a /opt/distro/arm/bin/ which has the binaries |
20:51.09 | hbeck | and 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.40 | hbeck | what's the main thought in difference between BASE_PACKAGE_ARCH and TARGET_ARCH ? |
20:53.36 | khem | base package arch is lowest supported sub family |
20:57.47 | hbeck | would 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.03 | khem | hbeck: a lot depend on these vars |
21:03.20 | khem | I cant even envision what all can break because of these vars |
21:03.27 | hbeck | heh |
21:04.24 | khem | multimach was done to accomodate multiple builds of similar enough arches |
21:04.33 | hbeck | right |
21:04.37 | khem | in same tmpdir |
21:05.01 | hbeck | but no real carry-over to building SDKs in the same fashion |
21:05.11 | khem | yeah |
21:05.19 | hbeck | I 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.35 | khem | one day I will revisit SDK and straighten some niggles in there |
21:06.29 | khem | hbeck: it should live together for armv4 and armv7 |
21:06.43 | khem | hbeck: but sysroot might be what conflicts hmm |
21:06.58 | khem | can you post the install tree org chart |
21:08.07 | hbeck | hrm. Lost me a bit in what you're asking for |
21:08.26 | khem | issue a find command in your install tree of SDK |
21:08.29 | hbeck | how we install the SDK? |
21:08.32 | khem | and paste that output |
21:09.12 | khem | yes I want to see where what goes in install |
21:10.24 | hbeck | heh. pastebin says it is too big |
21:10.36 | hbeck | somewhere else I can stick it? |
21:11.48 | hbeck | http://paste2.org/p/1898307 |
21:12.24 | hbeck | khem: 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.38 | rlrosa | hi |
21:15.01 | rlrosa | is there any tutorial on how to modify a board.c file and get bitbake to use the new file? |
21:18.03 | rlrosa | i 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.23 | hbeck | rlrosa: you need to modify one of the source files in a recipe? |
21:18.46 | hbeck | or rather, from the source a recipe uses |
21:22.49 | *** join/#oe Ironnads (~Ironnads@host86-144-173-232.range86-144.btcentralplus.com) |
21:24.13 | rlrosa | hbeck, yes. i want to change the beagleboard board file, i want to modify i2c speed |
21:24.47 | hbeck | do you know of which package that file is a part? |
21:24.57 | rlrosa | hbeck, 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.06 | hbeck | rlrosa: 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.51 | hbeck | rlrosa: 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.57 | rlrosa | i 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.57 | rlrosa | hbeck, 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.01 | hbeck | yes |
21:31.23 | hbeck | as 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.28 | rlrosa | hbeck, i foind the manual. is it easy/possible to get the classic oe instead of the new one? |
21:35.48 | khem | rlrosa: why would you want classic oe |
21:36.24 | *** join/#oe ALoGeNo (~alogeno@unaffiliated/alogeno) |
21:36.42 | rlrosa | khem, 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.24 | rlrosa | khem, do you *not* recommend this? |
21:37.37 | khem | rlrosa: actually I would not |
21:40.36 | rlrosa | khem, ok. i'll see if i can "port on the go" |
21:42.41 | khem | rlrosa: actually it will be better if you can document the problems and things that need update |
21:45.10 | rlrosa | khem, 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.56 | hbeck | khem: any insight from the install paste for SDK? |
21:49.11 | khem | rlrosa: 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.19 | khem | that should cover oe-core to some extent |
21:49.56 | *** join/#oe XorA (~XorA@188-220-34-37.zone11.bethere.co.uk) |
21:52.23 | khem | old documentation is here http://git.openembedded.org/openembedded/tree/docs/usermanual |
21:55.46 | khem | hbeck: I see. there is no multimachine there |
21:58.20 | hbeck | not 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.40 | hbeck | I've built in separate build dirs the sdk for both arm machines |
21:59.08 | hbeck | khem: but they build a nearly identical tree for ./arm/ ... |
22:00.12 | khem | hbeck: yeah I think propagating multimachine to target triplet might be the solution |
22:00.21 | khem | but thats quite fundamental |
22:00.43 | hbeck | fundamental as in easy or as in a low level change that could screw up everything else? :) |
22:03.37 | hbeck | khem: and would that be a distro override or something you're thinking could change in bitbake.conf (or maybe the sdk class?) |
22:03.50 | khem | no it has to be deeply rooted |
22:04.03 | khem | but for you I think you can define a variable |
22:05.15 | khem | hbeck: btw. is it using oe.classic |
22:05.29 | hbeck | khem: yes |
22:05.35 | khem | oh boy |
22:05.41 | khem | nothing will get fixed there |
22:06.34 | *** join/#oe woglinde (~woglinde@g225164080.adsl.alicedsl.de) |
22:07.22 | hbeck | khem: 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.02 | khem | hbeck: hmm ok |
22:08.09 | woglinde | hbeck poor boss |
22:08.51 | khem | woglinde: wie gehts |
22:08.56 | hbeck | woglinde: 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.24 | khem | hbeck: migration should be easier but its some work |
22:09.31 | khem | but opens up your future |
22:09.49 | hbeck | khem: 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.28 | khem | hbeck: you can try |
22:10.54 | hbeck | khem: 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.37 | khem | hbeck: oh well. Its done for a reason and stability and dead code were main reasons |
22:13.27 | hbeck | khem 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.19 | khem | hbeck: yes it was disussed on ml a lot |
22:17.59 | hbeck | khem: 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.05 | khem | hbeck: I pretty much gave you |
22:19.10 | hbeck | got it |
22:19.22 | khem | hbeck: other reasons were we used push model which was not scaling |
22:19.43 | khem | as the meta-data grew so large it was broken every instant |
22:20.26 | khem | so we bit the bullet and I am happier than before |
22:20.26 | hbeck | well a simple TARGET_SYS = ${MULTIMACH_TARGET_SYS} fails on build due to provider issues :( |
22:20.39 | khem | I am not surprised |
22:20.50 | hbeck | actually wait, those are just notes. |
22:20.55 | hbeck | ERROR: 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.59 | hbeck | ^ is the error |
22:21.26 | khem | yeah we have sanitized toolchains quite a bit in oe-core |
22:21.32 | khem | separated the target bits out |
22:21.38 | khem | for better dep tracking |
22:21.45 | khem | created 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.32 | ant____ | 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.13 | woglinde | good nite |
22:44.33 | khem | ant____: 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.39 | cs_nbp | bluelightning: sorted it, filesystem was corrupted |
23:36.18 | bluelightning | cs_nbp: wow, ok... never would have guessed that :o |
23:36.42 | bluelightning | no wonder weird stuff was happening... |
23:36.48 | cs_nbp | y |
23:36.58 | khem | hmm did someone bribe it or what :) |
23:37.04 | khem | how did it got corrupted |
23:37.14 | cs_nbp | there was a power surge in my office |
23:37.31 | cs_nbp | when I went to restart the computer it took really long |
23:37.43 | cs_nbp | but no error messages |
23:37.50 | cs_nbp | so I didn't bother at first |
23:37.59 | cs_nbp | then weird things happening in oe |
23:38.08 | cs_nbp | and later in other applications too |
23:38.29 | Russ | which fs? |
23:38.37 | khem | yeah I have seen OE is pretty upset when I run out of diskspace and then restart the build after freeing up some |
23:38.48 | khem | it does not like the intermediate files |
23:38.56 | cs_nbp | xfs |
23:39.17 | khem | xfs isnt that like storage server recommended one |
23:39.32 | khem | proabbly you are better off with ext4 |
23:39.46 | khem | I hard reboot my box many times |
23:39.57 | khem | when ubuntu compiz bites me backsize |
23:39.58 | bluelightning | I have heard a lot about XFS being poor at handling unexpected events like surges |
23:39.59 | khem | side |
23:40.01 | cs_nbp | yes that machine needs a new setup anyway |
23:40.17 | cs_nbp | it was my first xfs failure ever |
23:40.25 | bluelightning | khem: RP__ tells me that's gcc |
23:40.31 | cs_nbp | and I didnt like how sneaky it was |
23:40.45 | bluelightning | cs_nbp: never tried it myself, only going by what I read... |
23:41.15 | cs_nbp | well probably there is some people who didnt notice their xfs is corrupted |
23:41.16 | khem | bluelightning: you mean the one which bites the backside :) |
23:42.05 | bluelightning | khem: well, I guess it just has no code to delete files that are partially written in the case of insufficient space |
23:42.15 | RP__ | bluelightning: gcc? |
23:42.30 | bluelightning | RP__: isn't that what you were suggesting when we talked about this last time? |
23:42.30 | RP__ | 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.07 | RP__ | bluelightning: I'm not making sense of the conversation, sorry |
23:43.20 | RP__ | bluelightning: the out of disk space being a gcc issue? |
23:43.25 | bluelightning | RP__: yes |
23:43.40 | RP__ | bluelightning: its not gcc as such, just that you can end up with zero length files lying around |
23:43.41 | bluelightning | RP__: it's a side bit in a discussion about general file system corruption |
23:43.43 | khem | when 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.45 | RP__ | and gcc doesn't like that |
23:43.58 | bluelightning | right, that's what I was referring to |
23:44.05 | khem | yes 0 length files is the real problem |
23:44.10 | RP__ | can also confuse make |
23:44.45 | khem | yeah but with sstate it does not matter that much |
23:44.48 | bluelightning | yes, I would imagine that could happen as well |
23:45.01 | bluelightning | khem: well ideally you'd like it to be resumable |
23:45.12 | khem | RP__: btw. for fun since machine was bored I am doing a funny build where I am building each recipe from scratch |
23:45.28 | khem | with sstate it helps |
23:45.43 | khem | and I hope to get some missing dependencies |
23:45.47 | RP__ | khem: yes, I've meant to script that |
23:46.19 | khem | http://paste.ubuntu.com/834624/ |
23:47.14 | RP__ | khem: nice and simple :) |
23:47.26 | RP__ | khem: It will be interesting to see how many issues we really have |
23:47.45 | khem | yes |
23:48.23 | bluelightning | even more interesting if you enabled buildhistory while doing that |
23:48.40 | bluelightning | that would pick up any unstated dependencies |
23:48.43 | khem | bluelightning: yes i will do that once I get through one pass |
23:48.45 | bluelightning | or, at least some of them |
23:48.53 | khem | hmmm |
23:49.03 | bluelightning | great idea though |
23:49.03 | khem | this time I will just rely on build failure |
23:49.57 | khem | so far 1 package is done |
23:49.59 | khem | :) |
23:50.09 | khem | but it worked |
23:50.31 | cs_nbp | which is it? hello_world? .p |
23:50.39 | khem | libffi |
23:51.38 | cs_nbp | 'portable foreign function library' omg |
23:51.52 | khem | if that can work |
23:51.57 | khem | means lot will work |
23:52.46 | khem | RP__: btw. I have a working toolchain with llvm + compiler-rt + libc++ + binutils |
23:52.47 | khem | for arm |
23:53.00 | khem | it just needs the linker from binutils |
23:53.21 | cs_nbp | ah yeh the gcc seems broken on my target |
23:53.54 | khem | RP__: for x86 it did not need binutils |
23:53.59 | cs_nbp | 'cannot find crtbegin.o' when compiling a hello-world level code |
23:54.07 | khem | I am not sure if it sneaked the host one :) |
23:54.29 | khem | cs_nbp: that definitely means your runtime is borked |
23:55.27 | khem | if llvm was so mature we would build cross compiler only _once_ for all arches how cool is that |
23:55.32 | RP__ | khem: cool :) |
23:55.38 | khem | and it does not need any deps on libc and crap |
23:55.41 | cs_nbp | very kewl |
23:56.26 | cs_nbp | khem: does that mean im missing a package or that the gcc recipe doesnt work well for that target? |
23:56.28 | RP__ | khem: might help some of our build time issues? :) |
23:56.47 | khem | RP__: yes indeed |
23:56.53 | khem | will simplify the things |
23:57.07 | khem | cs_nbp: do you have gcc-runtime installed on target ? |
23:58.00 | cs_nbp | khem: seems only gcc-runtime-dbg is there -.- |
23:58.14 | khem | I think there is a lot of gcc'ism in the packages that it will take ages for it to really become prominent |
23:58.29 | khem | cs_nbp: not good. |
23:59.23 | ka6sox | oe infra full stop on wiki/git(master) in 2 minutes |
23:59.26 | ka6sox | window for 2hrs |
23:59.53 | khem | ka6sox: thanks |